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
<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
<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?
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
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
<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?
<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]: r13y.com 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 cache.nixos.org 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>
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]