<vcunat>
Hydra status: apart from the earlier problem with darwin not building at all, there's now also an x86 problem killing everything repeatedly:
<vcunat>
8ab4c224 (machine name) Aborted: creating log file ‘/var/lib/hydra/build-logs/ml/cd5hbc1hcqm51r6s48d0i7813kr5q0-phonon-qt4-4.10.1.drv’: No space left on device
pie_ has quit [Quit: No Ping reply in 180 seconds.]
<yorick>
we're going to debate the systemd timesync issue long enough that we get the upstream fix
<niksnut>
vcunat: hm yeah, the server is out of inodes
<vcunat>
First too many entries in /nix/store, now out of inodes. Maybe ext4 isn't ideal, but I have no experience with this on such a scale. For now it might be best to GC more aggressively.
orivej has joined #nixos-dev
<niksnut>
I remember on a previous hydra server I manually increased the number of inodes at mkfs time
<ivan>
XFS doesn't run out of inodes
<ivan>
well, not in any normal circumstances
orivej has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-dev
pie_ has quit [Quit: pie_]
pie__ has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
tv has quit [Quit: WeeChat 2.2]
<andi->
yorick: that would be the best solution IMO. I have yet to read through all the mails on the topic. Just saw that there is yet another discussion :-)
<andi->
If they migrate one way they should also take care of migrating the other way around or document the desired/required steps somewhere...
<andi->
Also with rollback in mind we are probably one of the few (the only?) people thinking about that scenario…
tv has joined #nixos-dev
<gchristensen>
yes quite likely
<gchristensen>
does anyone know *what* state timesync stores?
<andi->
it touches a file to store a last good known timestamp
<gchristensen>
this doesn't feel like a very important bit of state.
<gchristensen>
:|
<andi->
to protect against NTP servers sending you in the past
<andi->
e.g. to allow an expired certificate
<andi->
It isn't THAAT important but nothing I would voluntary throw away.
<andi->
(for all users)
<gchristensen>
right
<andi->
so the default should be forward migration and apparently backwards migration
<andi->
I was trying to safe us from having to carry around those 3 lines in the activation script for an undetermined amount of years… Probably shouldn't have tried. It wasted many hours already :/
<adisbladis>
ivan: XFS is my preference for a "traditional" filesystem, inodes being one of the reasons.
<yorick>
andi-: yes, they migrate the other way around in the next release
<andi->
yorick: ill try picking the patch and See if it works for us
<yorick>
andi-: there's a few fixups
<andi->
So maybe we should pick the latest stable branch..
vcunat has quit [Ping timeout: 250 seconds]
ixxie has joined #nixos-dev
drakonis has joined #nixos-dev
<jtojnar>
worldofpeace: I am not aware of anything like Coccinelle for Python
<jtojnar>
I think we would have to transform AST manually
<jtojnar>
and probably do the same for C too, as the coccinelle patches are too inflexible
drakonis_ has quit [Ping timeout: 268 seconds]
<thoughtpolice>
gchristensen: Interestingly, I found out why our S3 serves 403s and not 404s: it's probably because public directory listings are denied, meaning all non-existant-keys return 403, not 404, in order to stop info leaks: https://forums.aws.amazon.com/thread.jspa?threadID=56531
<gchristensen>
right
<thoughtpolice>
gchristensen: I don't think this is worth changing but it *does* solve the mystery of "why 403", which I remember we wondered
<gchristensen>
yeah
<gchristensen>
ahh :) yeah!
<gchristensen>
good find
drakonis has quit [Ping timeout: 264 seconds]
<worldofpeace>
jtojnar: We'll totally need something like this if we have to continue with the hardcode-gsettings patches. not sure what we'll do for vala though, but having something for C and Python would already be a lot of help.
<worldofpeace>
Though really glib should just change the way they're doing things 🤣
<jtojnar>
worldofpeace: maybe a tree-sitter parser could be used
<gchristensen>
arianvp: are you using gnome and wayland?
<worldofpeace>
arianvp: currently our xdg-desktop-portal is out of date and it emits a warning for too old gnome sceencast api
<worldofpeace>
pipewire bits, I don't think I've got to working on that yet. but jtojnar maybe knows
<worldofpeace>
(actually don't think it's a warning it's incompatible)
<jtojnar>
worldofpeace: I did not take very deep look at it other than making it compile and running the pipewire demos
<arianvp>
gchristensen: I think wayland on gnome is default on 19.03 is it not?
<gchristensen>
oh is it?
<gchristensen>
cool
<arianvp>
or is that on unstable. im confused now
<arianvp>
hmm I dont see XWayland running so I suppose I am on X11?
<worldofpeace>
gchristensen: it is.
<gchristensen>
great!
<arianvp>
oh wait. it is running
<arianvp>
nvm
* gchristensen
might have to switch from Sway
<worldofpeace>
arianvp: echo $XDG_SESSION_TYPE
<worldofpeace>
that will tell you
<arianvp>
Just not running under a systemd scope/service unit
<arianvp>
I guess we could add a scope unit for it; eventhough we're not starting it with systemd
<arianvp>
It's running under session-x.scope nvm there already is a scope unit for it
<arianvp>
worldofpeace: oh but Firefox is running under XWayland so perhaps thats the problem
<worldofpeace>
arianvp: I'd wager this is probably broken on unstable
Jackneill has quit [Remote host closed the connection]
ixxie has joined #nixos-dev
Guanin has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar has quit [Ping timeout: 245 seconds]
orivej has quit [Ping timeout: 268 seconds]
rycee has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 264 seconds]
jtojnar has joined #nixos-dev
orivej has joined #nixos-dev
drakonis has joined #nixos-dev
niksnut has quit [Quit: Lost terminal]
drakonis has quit [Quit: Leaving]
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
ixxie has quit [Ping timeout: 244 seconds]
drakonis has joined #nixos-dev
justanotheruser has quit [Quit: WeeChat 2.4]
justanotheruser has joined #nixos-dev
<emily>
thoughtpolice: hi there, I'm in the process of trying to update icestorm and the other FOSS EDA tools in nixpkgs, but running into pypy-related problems; I agree with your perf rationale in 18839e1 but unfortunately pypy3 is currently marked as broken due to not passing tests, meaning that icestorm/nextpnr/... aren't being built at all.
<emily>
thoughtpolice: I've updated the prebuilt PyPy version in nixpkgs locally and it works fine with that, but I'm guessing using a prebuilt binary like that would be a no-go in upstream nixpkgs? I tried updating and fixing the source-based PyPy builds too but there were a ton of failed tests and I'm not sure I have the tenacity for it.
<thoughtpolice>
emily: ahhh fuck. we should just turn off pypy then, tbh
<emily>
but it's so slow :'(
<thoughtpolice>
Yeah.... But I'd rather have them build! I haven't touched my EDA projects in a while so I let it slip, otherwise I'd have fixed this a while back
<thoughtpolice>
I'd probably just leave all the pypy code there and just gate it with a trivial conditional with a comment
<emily>
it's pretty easy to override to use pypy anyway
<thoughtpolice>
and a comment noting to remove it when pypy works
<simpson>
emily, thoughtpolice: Why not just fix PyPy?
<emily>
because it takes 6 hours to bootstrap and fails like 50 tests.
<simpson>
Or turn off PyPy's tests. We cheat on CPython's tests; I'm not sure why PyPy's are more important, other than that PyPy upstream actually cares about passing tests.
<simpson>
Ah, sure. Patience is required.
<emily>
patience and more understanding of pypy internals
<thoughtpolice>
Yes the turnaround cycles for pypy are like, really long. Don't blame anyone for skipping that trial.
<emily>
there was some utf-8 related failures that seemed known when i tried to track them down
<thoughtpolice>
But it should be fixed or a decision made about it, yeah.
<emily>
I'd be fine just turning off the tests though, like, it already disables like 20
<simpson>
The year slips longer and longer, and still I haven't written a PyPy RFC.
<emily>
another thing is that pypy trunk seems honestly more stable/recommended than the releases
<emily>
especially for py3
<simpson>
Sure. Python 3 is an active feature in development upstream.
<emily>
ok, I'll try bootstrapping pypy one more time and see if it passes nextpnr tests before giving up and just disabling it in icestorm :p
<thoughtpolice>
emily: Also, FWIW, pre-built binaries aren't *always* a no-go. Sometimes for various reasons they're preferable (even when the source is available, e.g. a massively complex or bizarro build system.) But for PyPy/Python-esque packages, it's way worse since you'd have to rebuild all of pythonPackages
<thoughtpolice>
For instance, we do have source-built and pre-packaged-binaries of Firefox, which is a much less problematic package since it has so few consumers. Another example is 'firecracker' from Amazon. Which has just a weird amount of stuff around its Rust packaging that made me give up on building from source, at the time.
<thoughtpolice>
(I think it's still a pre-built binary. In their defense they at least ship a statically linked pre-built binary so using it in Nixpkgs isn't really a big hassle)
<emily>
free PyPy gags for the audience: 1. you know you're compiling PyPy when a whole 100/cores% of your CPU is in use; 2. PyPy is a project dedicated to proving that Python isn't the worst language to write PyPy in
<emily>
thoughtpolice: *nods* in this case I was thinking of just overriding icestorm to use the pypy binary
<emily>
but it feels a bit icky for a fairly "pure" package to depend on third-party binaries like that, I guess
<thoughtpolice>
It's not the worst thing but yeah it's a bit overkill... To be fair it's probably *still* slower to use Python3 to build icestorm, vs just downloading and installing PyPy's binary and then using that, since it's like 3x faster.
<thoughtpolice>
Well, depending on your upstream download speed, I guess.
<simpson>
emily: Note that the binary PyPy, the "portable" prebuilt, is not the greatest. We can bootstrap from it, but self-hosting will yield a more predictable result.
orivej has quit [Ping timeout: 246 seconds]
vika_nezrimaya has joined #nixos-dev
ixxie has joined #nixos-dev
ixxie has quit [Remote host closed the connection]