worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ | | | 20.09 RMs: worldofpeace, jonringer |
<hexa-> cole-h: thx
bennofs_ has joined #nixos-dev
bennofs__ has quit [Ping timeout: 264 seconds]
ris has quit [Ping timeout: 264 seconds]
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
Irenes[m] has quit [Quit: issued !quit command]
orivej has joined #nixos-dev
rajivr has joined #nixos-dev
<gchristensen> if anyone has opinions on postgresql upgrades:
<{^_^}> nixos-org-configurations#141 (by grahamc, 3 minutes ago, open): Scheduled downtime: Postgres 11 to 12
<cole-h> gchristensen++ thanks for the detailed writeup
<{^_^}> gchristensen's karma got increased to 434
{`-`} is now known as {`-`}_
{`-`}_ has joined #nixos-dev
asymmetric_ has joined #nixos-dev
niksnut_ has joined #nixos-dev
ekleog_ has joined #nixos-dev
Willi_Butz has joined #nixos-dev
lovesegfault_ has joined #nixos-dev
pmy_ has joined #nixos-dev
^_ has joined #nixos-dev
drakonis- has joined #nixos-dev
drakonis has quit [*.net *.split]
lovesegfault has quit [*.net *.split]
Rovanion has quit [*.net *.split]
alp has quit [*.net *.split]
danderson has quit [*.net *.split]
WilliButz has quit [*.net *.split]
lassulus has quit [*.net *.split]
tv has quit [*.net *.split]
dongcarl has quit [*.net *.split]
V has quit [*.net *.split]
pmy has quit [*.net *.split]
maljub01 has quit [*.net *.split]
asymmetric has quit [*.net *.split]
ekleog has quit [*.net *.split]
niksnut has quit [*.net *.split]
{`-`} has quit [*.net *.split]
asymmetric_ is now known as asymmetric
maljub012 is now known as maljub01
drakonis- is now known as drakonis
Rovanion has joined #nixos-dev
tv has joined #nixos-dev
lassulus has joined #nixos-dev
danderson has joined #nixos-dev
alp has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
<siraben> Dunno how I feel about #114449, lots of orthogonal changes beyond just bumping package version
<{^_^}> (by fare, 1 week ago, open): Update Gambit, Gerbil, Glow
<siraben> Including something that IMO should be moved into an RFC
<cole-h> at the very least, things touching lib/ should go in a separate PR...
orivej has joined #nixos-dev
WORLDofPEACE has left #nixos-dev ["User left"]
Emantor has quit [Quit: ZNC -]
Emantor has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
orivej has quit [Ping timeout: 276 seconds]
jonringer has quit [Ping timeout: 264 seconds]
bachp has quit [Disconnected by services]
bachp has joined #nixos-dev
bachp has quit [Disconnected by services]
bachp has joined #nixos-dev
evils has joined #nixos-dev
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #nixos-dev
__monty__ has joined #nixos-dev
cole-h has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
niksnut_ is now known as niksnut
AlwaysLivid has quit [Remote host closed the connection]
^_ is now known as V
terrorjack has quit [Ping timeout: 260 seconds]
mkaito has joined #nixos-dev
terrorjack has joined #nixos-dev
<infinisil> siraben: That user has been pointed to making an RFC for this thing before already. Just making a PR that includes that but labeling it as a package update feels like a sneaky way to try to get around an RFC..
<Taneb> supersandro2000: can you give package maintainers a chance to look at PRs before you merge them, please
<supersandro2000> Taneb: you mean
<{^_^}> #115533 (by siraben, 47 minutes ago, merged): metamath: fix cross-compilation and update license
<Taneb> supersandro2000: yeah, you merged it before I had a chance to check it
AlwaysLivid has joined #nixos-dev
<supersandro2000> Taneb: siraben is doing a lots of cross compiling fixes lately and most of the time they are just moving build inputs around or setting some cc flag to buildPackages. I don't really wait for maintainers on them.
<Taneb> I've got a responsibility to make sure that it continues to work. The derivation changed, and although it's unlikely to break, it seems like no-one even checked that the executable still executed before it was merged.
<supersandro2000> buildInputs and nativeBuildInputs make not difference when not cross compiling or using strictDeps
<supersandro2000> that change could have also been part of a treewide change to move autoreconfHook into nativeBuildInputs
<Taneb> Tree-wide changes have more scrutiny. This was a PR that only touched a package which I maintain. I should be given the opportunity to see it before it's merged.
<siraben> Taneb: I checked that it ran
<Taneb> siraben: you didn't check the box that said you checked it ran
<siraben> Didn't try running a proof through it though
<siraben> Ah forgot to
<Taneb> Which meant that I couldn't assume you had, even though you're generally trustworthy
<sterni> I agree with Taneb here, no matter and I think this is also about what role maintainers play in general
<sterni> if maintainers aren't given the chance to give feedback on any PR on package they maintain within a reasonable amount of time what's the point of having a maintainers field
<sterni> also in this case, this is not really a pressing matter and it's not like there aren't enough PRs by maintainers which sit around unmerged for weeks
<siraben> Perhaps 24 hrs is a good time
<sterni> I wouldn't say a strict time rule is the solution really
Graypup_ has quit [Quit: ZNC 1.6.1 -]
Graypup_ has joined #nixos-dev
jonringer has joined #nixos-dev
rj has joined #nixos-dev
<andi-> 24h really doesn't work if you can't dedicate hours every day to nixpkgs.
<andi-> You just have to make your PR super interesting and fancy and the a bunch of people - that never touched that package - will wave it through ;-)
<gchristensen> hehe
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
<andi-> If it is fancy enough none of those will even test your PR locally as long as it compiles.
<gchristensen> I don't suppose there is a handy nixos option for "just don't stop the network during shutdown"? my iscsi-backed VM stops the network before unmounting / and then it gets stuck
<andi-> gchristensen: add _netdev to the mount options
<andi-> see systemd.mount(5)
<gchristensen> incredible
<gchristensen> thanks!
<gchristensen> hmm that didn't do it, but I'll research that
orivej has quit [Ping timeout: 256 seconds]
<gchristensen> you know what, I sort of bet this is just fixed if I use networkd instead of scripted
rj has quit [Ping timeout: 268 seconds]
<gchristensen> it'd be great if the nixos test framework allowed for reconfiguring / rebuilding members of a network
<gchristensen> lol yes, yes it did
rj has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<supersandro2000> sterni: you have an example PR which got forgotten?
<siraben> Is "PROFILE=release" redundant for Rust packages?
edef has quit [Ping timeout: 272 seconds]
nbp has quit [Remote host closed the connection]
hl has quit [Ping timeout: 272 seconds]
edef has joined #nixos-dev
nbp has joined #nixos-dev
hl has joined #nixos-dev
hl has joined #nixos-dev
hl has quit [Changing host]
dongcarl has joined #nixos-dev
orivej has joined #nixos-dev
rj has quit [Ping timeout: 268 seconds]
rj has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
<tazjin> reading the conversation above, I think it's becoming more and more of an issue that every committer can commit to every thing in the tree
<tazjin> I think it might be time to think about an ownership structure for directories, and to enforce that ownership through a check on the PR. I think treewide permissions should only be granted to a small list of people who are known to be qualified for that sort of thing
<gchristensen> I suppose if I wanted to patch one of these units, I'd have to suffer a mass rebuild -- yeah?
<andi-> gchristensen: you should be able to set additional properties just like normal:
<andi-> gchristensen: if that doesn't work you can always set systemd.package = pkgs.systemd.overrideAttrs ( ....
<gchristensen> ehh I'll just suffer the MR for the sake of the PR
<gchristensen> my ryzen needs some exercise anyway
rj has quit [Ping timeout: 268 seconds]
<andi-> periodic ping regarding aarch64 channels: what is required to make this happen?
<{^_^}> #83049 (by akirakyle, 50 weeks ago, open): Suggestion: add an aarch64 channel
rj has joined #nixos-dev
<andi-> For 20.09 this seems to be all that is required:
<{^_^}> nixos-org-configurations#142 (by andir, 18 seconds ago, open): Add AARCH64 channels for NixOS 20.09
<gchristensen> do release notes include setting up that channel?
<andi-> No idea where the release stuff currently is. I only remember that it moved *somewhere*
<gchristensen> oofta
rj has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 276 seconds]
rj has joined #nixos-dev
<andi-> gchristensen: looking at I think it is covered as we already have multiple release channels and they seem to be mostly copied from previous releases.
<gchristensen> neat, 40 minutes from start to a passing test on rebuilding systemd
<andi-> Yeah, terrible :-)
<andi-> I have some changes that trim it down to like 18 or so but it isn't great
<gchristensen> it really wasn't as bad as I expected, but ... :)
<gchristensen> it would have sucked a lot more if the test failed
rj has quit [Ping timeout: 268 seconds]
rj has joined #nixos-dev
<siraben> supersandro2000: anything else I should do for #115242?
<{^_^}> (by dotlambda, 3 days ago, merged): libsForQt5.mauikit: init at 1.2.1
<siraben> Oops
<siraben> #115424
<{^_^}> (by siraben, 1 day ago, open): treewide (darwin): fix or enable darwin build for many packages (3)
<siraben> (never type PR numbers by hand heh)
ris has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<ekleog_> is it me or is r13y basically gaining new un-reproducibility at the same rate as we're eradicating stuff out? and if it's not me, is it because we are adding things to detect more issues or just because more issues pop up?
<supersandro2000> ekleog_: the minimal iso is still at 3
<supersandro2000> you mean 3 different?
<ekleog_> well, at some point we were down to 2 iirc
<ekleog_> (python and gcc, isl appeared since last I looked afair)
<supersandro2000> maybe an update broke something. This will probably happen from time to time
<andi-> Reading RFC46 yet again makes me wonder if we should downgrade x86_64-darwin to Tier3 as there is no ambition to reach Tier1 any time soon. Especially with no future for the platform once Apple pulls the plug. I also question the ambition to reach Tier1 coverage of packages.
<supersandro2000> tazjin: I really don't miss the days that something broke eval, no one to merge is around and reviewing PRs kinda stops
bpye has quit [Quit: Ping timeout (120 seconds)]
<supersandro2000> andi-: is it 2 right now?
<andi-> supersandro2000: yeah
<supersandro2000> I think aarch64 fails more often for strange reasons than darwin
bpye has joined #nixos-dev
<andi-> I am not arguing for aarch64 here just reading through the RFC as I totally forgot it existed.
<ekleog_> I wonder if it'd make sense to evaluate each PR in terms of regression in reproducibility, so people at least know when they're making something previously reproducible non-reproducible
<ekleog_> probably quite a lot of dev & infra needed to do that though I guess :/
<supersandro2000> I think darwin is the second most popular platform and moving it behind aarch64 makes no sense
<supersandro2000> When reviewing I don't even look at aarch64 because it segfaults or crashes for strange reasons
rj has quit [Ping timeout: 268 seconds]
<rmcgibbo[m]> (To be fair, I think a lot of the aarch64 crashes on the r-rmcgibbo comments are probably my fault.)
<supersandro2000> its also ofborg
<supersandro2000> probably less than I make it look right now
<supersandro2000> ekleog_: that would make sense to do for packages which where reproducible before
<rmcgibbo[m]> ekleog_: Do you have any idea what it would take to evaluate PRs for reproducibility regressions? Like just building the PR on two machines with clocks set differently or something? What are the mechanics?
rj has joined #nixos-dev
<rmcgibbo[m]> Is it usually sufficient to simply re-build the package twice on the same box, or do you need to randomize the environment more than that?
<gchristensen> rmcgibbo[m]: has some information
<gchristensen> check the text at the bottom
<gchristensen> note that reproducibility issues coming up in a PR don't necessarily reflect that PR breaking reproducibility, it could have been a long-existing problem only just now exercised. For example, the changing of the month or year.
<rmcgibbo[m]> yeah, for sure. i noticed some builds that failed on January 1st :P. I'm just thinking through the mechanics of whether it would be feasible (and whether it would be helpful) to have my bot build every package twice.
vikanezrimaya has joined #nixos-dev
vikanezrimaya has left #nixos-dev [#nixos-dev]
<supersandro2000> the varnish on just gave me some 503
<gchristensen> hopefully fastly fixes it soon
<supersandro2000> "no healthy backend"
<gchristensen> alternatively, hopefully AWS fixes it soon
<supersandro2000> making aarch64 a channel blocker is probably a bad idea until the core packages can't be cross compiled to it.
* supersandro2000 Looking at you systemd
<gchristensen> not sure why cross compilation should be a blocker when cross builds aren't tier-1
<supersandro2000> people can't test it
<supersandro2000> it is pretty safe to assume everyone as amd64 but there are not many aarch64 boxes to build out there
<gchristensen> people on aarch64 machines have equal testing ability for x86, with the availability of very cheap aarch64 VMs and also
<supersandro2000> yeah but when I change something in systemd that breaks aarch64 it will block the channel for everyone
<supersandro2000> which I can't test
<das_j> aarch64 emulation with qemu-user works pretty great actually and isn't as slow as one would expect
<samueldr> >> until the core packages can't be cross compiled to it.
<supersandro2000> compiling cryptography to aarch64 usually takes a long time on my machine
<samueldr> cross-compilation and native compilation are different enough with Nix and Nixpkgs that it wouldn't matter
<samueldr> note that using qemu-user (through binfmt) is not cross-compilation, it's native compilation with extra steps
<samueldr> aarch64 is already a channel blocker, partially
<samueldr> unless someone removed the artifacts from the tested set
<gchristensen> I'm ready for aarch64 to be tier-1
<rmcgibbo[m]> everyone chip in and we'll ship sandro one of these:
<gchristensen> hehehe
<samueldr> many aarch64 developers don't have anything better than a cheap aarch64 SBC
<samueldr> contributors/maintainers to Nixpkgs
<gchristensen> rmcgibbo[m]: no need :)
<supersandro2000> I know the story of the pi 4 in my space
<supersandro2000> freezes everytime it tries to eval nixpkgs
<supersandro2000> I can't convince my remote builders from nix to use binfmt?
<supersandro2000> without actually setting it up on the machine
<samueldr> binfmt is a mechanism that happens at `exec` in the kernel
<samueldr> to work, it needs to be configured on the system
<das_j> and nix needs to know the cpu "supports" it
<das_j> extra-platforms = aarch64-linux i686-linux
<supersandro2000> maybe I can convert my builders to binfmt
<supersandro2000> as long as it would be fast enough
<supersandro2000> still I think a separate channel would be a better idea to not block amd64
<gchristensen> it isn't sufficient when you're deploying to a heterogeneous environment
<supersandro2000> but better than nothing if channels are blocked for an arch you don't have at hand I suppose
<samueldr> channels block on things I don't care about often
<samueldr> maybe we should have separate channels for those things?
<gchristensen> Note also that nixos-unstable already blocks on aarch64-linux.
<samueldr> gchristensen: but it does not attempt to build the aarch64 package set AFAICT
<samueldr> the builds for aarch64 only happens through nixpkgs-unstable
<gchristensen> sounds like an easy fix :)
<gchristensen> /!\ I'm beginning the scheduled maintenance to upgrade Hydra's postgres from 11 to 12 as described here: /!\
<{^_^}> nixos-org-configurations#141 (by grahamc, 16 hours ago, open): Scheduled downtime: Postgres 11 to 12
pmy_ has quit [Ping timeout: 256 seconds]
<gchristensen> anyone available to help research a missing point in my instructions?
<das_j> huh?
<gchristensen> I need to find the options to pass initdb to match how the hydra schema was first initialized
<ehmry> I've been using an aarch64 laptop since last august and worse part is kernel support
<das_j> gchristensen: That's only collate and encoding, right?
<gchristensen> I think so, yeah, das_j
<{^_^}> undefined variable 'SHOW' at (string):489:1
<tazjin> supersandro2000: that's why you build such mechanisms with breakglass facilities
<tazjin> these are all well explored areas in software engineering
<das_j> gchristensen: locale should not matter because `--locale` Sets the default locale for the database cluster
<das_j> since the DB already exists, the encoding should be stored in the db afaik
<gchristensen> cool
<gchristensen> then we can probably continue with just `initdb` and not pass arguments
<gchristensen> agree?
<das_j> oh
rj has quit [Ping timeout: 268 seconds]
<das_j> you can `show lc_collate`
<das_j> for me (somewhat default installation iirc) my encoding is UTF8, and the collate is en_US.UTF-8
<gchristensen> cool, same
<das_j> nice, the rest of the lc_ variables is either C or en_US.UTF-8
<das_j> so you should be good to go (but verify the snapshot is in place before :D)
<das_j> mv ./* old || true
<das_j> doesn't that move old into itself?
pmy_ has joined #nixos-dev
<das_j> ah that's why you || true it, right…
rj has joined #nixos-dev
<gchristensen> das_j: lgty? "$newpg/bin/initdb" -U root --locale=en_US.UTF-8 --encoding UTF8 ./new
<gchristensen> btw I'm not feeling rushed or scrambling here: still compiling Nix on the dry activation deploy :)
<das_j> not 100% sure because --locale sets all lc_ variables and some of mine were set to "C"
<gchristensen> I don't feel super weird about changing that, should I?
<das_j> nah, hydra does probably not encode money as money :D
<das_j> I guess the only really relevant lc_ variable is the collate variable
<gchristensen> hydra 2.0 will have pay-per-build
<gchristensen> I ran the migration with that command in my experimental environment and it proceeded okay, I'm going to carry on
<das_j> are you brave enough to implement pay-per-build in perl? :P
<gchristensen> LOL
<gchristensen> actually, I'll wait until the dry activation finishes in case someone perks up
justanotheruser has quit [Ping timeout: 272 seconds]
<ekleog_> (just saw the answers wrt. evaluating reproducibility and notifying on regression: thank you for the answers :))
<gchristensen> hold on to your butts ...
<gchristensen> -- seems to be migrated
<das_j> that was quick
<gchristensen> I'm seeing the web interface is very slow, I wonder if it is a disk cache issue, or the tables being unanalyzed issue
justanotheruser has joined #nixos-dev
<gchristensen> thanks for the help, das_j !
<das_j> no problem
<gchristensen> The migration in is complete /!\
<{^_^}> nixos-org-configurations#141 (by grahamc, 17 hours ago, closed): Scheduled downtime: Postgres 11 to 12
<gchristensen> well that wasn't so bad, glad to know how to do it for 12 -> 13
rj has quit [Ping timeout: 268 seconds]
rj has joined #nixos-dev
<samueldr> the more I think about it, the more I think this aarch64 RFC is already confusing things up
<gchristensen> oh?
<samueldr> since we already have a base aarch64-linux system in the hot path, we've been exercising for 2+ years keeping the CI green
<samueldr> really what we need is to *add the rest of the owl*
<gchristensen> right
<gchristensen> does that mean aarch64 was in a partial tier-1 this whole time, and now we're finishing the job?
<samueldr> I guess so
<samueldr> >> Show there are enough resources and commitment to keep it green for half a year to a year
<samueldr> well, if my maths are correct, we're 2 years 2 months in showing aarch64-linux won't drag down the channels from being green
<gchristensen> sounds about right
<samueldr> a confusion that could happen is: people mistaking "channels are slow to bump" with "channel is blocked from bumping"
<samueldr> the main problem I see here is that it *could* make channels slower to bump if the scheduling in Hydra is being all weird, or the build power isn't there
bhipple has joined #nixos-dev
<gchristensen> sure it could
<gchristensen> I think that is addressed in the RFC though with hydra-provisioner
<samueldr> yes, sorry, I'm not saying it's not addressed
<samueldr> I'm saying that people might conflate both when thinking about the problem
<gchristensen> yeah, I think that is good clarification to include
cole-h has joined #nixos-dev
rj has quit [Ping timeout: 268 seconds]
rj has joined #nixos-dev
FireFly has quit [Ping timeout: 615 seconds]
FireFly has joined #nixos-dev
rj has quit [Ping timeout: 268 seconds]
rj has joined #nixos-dev
FireFly has quit [Quit: Goodbye]
rj has quit [Ping timeout: 268 seconds]
rj has joined #nixos-dev
rj has quit [Ping timeout: 268 seconds]
rj has joined #nixos-dev
FireFly has joined #nixos-dev
FireFly has quit [Read error: Connection reset by peer]
Effilry has joined #nixos-dev
__monty__ has quit [Quit: leaving]
Effilry has quit [Ping timeout: 619 seconds]
rj has quit [Ping timeout: 268 seconds]
rj has joined #nixos-dev
FireFly has joined #nixos-dev
orivej has joined #nixos-dev
hl has quit [Ping timeout: 245 seconds]
evils has quit [Ping timeout: 256 seconds]