<{^_^}>
#79532 (by fpletz, 1 day ago, open): nixos/stage-1: fix predictable interface names in initrd
<disasm>
I'm thinking no
<samueldr>
that's a "new feature", and not fixing something that worked previously and was broken, right?
<flokli>
samueldr: well
<samueldr>
that would be my rule of thumb about it if I had to choose
<flokli>
it finally fixes something that has been broken for quite some time
<samueldr>
about blocking, not about rejecting
<flokli>
and would allow people to get rid of their hacks
<samueldr>
sure
<samueldr>
just saying that if it was a fix for a new breakage, compared to the previous release, then I'd know for sure it's a blocker, otherwise it's still up in the air
<flokli>
I'm not exactly sure when this broke
<samueldr>
hm, I assumed predictable names never were part of stage-1
<samueldr>
(but I don't know)
<flokli>
right. there were some naming differences. might be it never worked in stage 1
<worldofpeace>
umm, let's maybe not touch stage-1 right before we branch off 😃
<flokli>
nah, that shouldn't be a problem. And it even has tests
<worldofpeace>
I don't think we'll block on it, I don't think fpletz expressed there was a need to
<gchristensen>
+1 on letting it simmer in unstable for a time
<emily>
yeah, I tracked down the dates of the change on the issue
<emily>
not sure where the language that was previously in the package that explicitly permitted modification and redistribution is from
<gchristensen>
sad
<samueldr>
:(
<emily>
honestly "allowed a single instantaton and no network installaton ... agrees not to adapt, modify, alter, translate, convert" makes me feel like it shouldn't even be in nixpkgs
<emily>
you add a ttf2otf in there and now nixpkgs is ~breaking the law~
<emily>
(except software licenses don't really work like that, but...)
<emily>
and presumably using the font on two NixOS machines is meant to be prohibited somehow...?
<samueldr>
do we have licenses.incomprehensible?
<worldofpeace>
samueldr: you managed to produce a smirk on my face with this
<worldofpeace>
😸
<emily>
lib.licenses.tenfootpole
<gchristensen>
emily: marking it as unfree is probably sufficient, if we get somebody asking us to take it down from hydra we will
<gchristensen>
s/hydra/the cache/
<emily>
part of me wants to say that on-demand license compliance is a Bad Thing but in this case the licence is so unreasonable and the change sufficiently under-the-rug that the pragmatics are probably for the best
<gchristensen>
it is of course our goal to comply with every license properly
<gchristensen>
but also it is not trivial to remove things from the cache
<jtojnar>
FRidh do you mind if I take over the duplicity PR?
<FRidh>
jtojnar: not at all!
colemickens has joined #nixos-dev
<colemickens>
Has anyone attempted to finish removing the need for qemu from make-disk-image.nix, or is there something that fundamentally blocks it? the rpi sdcard image, make-ext4-fs, etc don't need a VM. there was a PR to start the effort that was merged, it mentions other changes being necessary but they're not immediately obvious to me.
<FRidh>
worldofpeace: I hope we can get current staging-next in master before branch-off. if no new evalutions are started we should have sufficient results to judge whether it can go in by branch-off time.
<yorick>
any idea about what should be done re compatibility?
<yorick>
I can add an off-by-default legacy agent and alias it
<flokli>
yorick: well, we still have the 2 -> 3 bump in there, so personally I think NOT making it backwards compat might be a good idea, as people will stumble over it when building their configuration, not 1 month later, when suddenly something doesn't work anymore, because they assumed some buildkite v2 behaviour
<flokli>
just my 2ct ;-)
<yorick>
yeah, I agree
<infinisil>
flokli: But if the error just indicates that people should use buildkite-agents over buildkite-agent, this doesn't achieve that goal
<infinisil>
The fact that multiple agents are now possible has nothing to do with 2 -> 3
<yorick>
we can append the error message to "additionally, the buildkite-agent was updated to v3, please refer to the 20.03 release notes"
<infinisil>
Breaking backwards compat like this just to have something unrelated break it feels very off to me
<flokli>
infinisil: well, originally, there was a gigantic PR doing all of that
<flokli>
I split out the "multiple agents" stuff, as I didn't have the time to fix this properly
<infinisil>
flokli: Is there a concrete thing that's known to be not compatible for the new version?
<yorick>
flokli: bootstrap customization, environment variables in pipelines, docker support
<infinisil>
"The Buildkite Agent has changed a lot in v3, but we've tried to keep it as backwards compatible as possible"
<yorick>
that means it's gonna break in the middle of your ci pipelines :/
<infinisil>
Hmm..
<flokli>
infinisil: my point is, this is likely to break if people relied on it and just blindly switch
<flokli>
and I don't see much of work for users to quickly verify this still works
<flokli>
instead of handling with breakage in the mid of a CI run
<flokli>
and as we move to another config format anyways, why not take that opportunity?
<infinisil>
Hmm I get your point, and I still think breaking compat *like this* is the wrong way to do it, but I see no better way of doing it
<flokli>
Talking about the upgrade path 19.09 -> 20.03, we changed to buildkite v3 AND multiple agent support, please check things still work and update your config
<flokli>
that way, we also don't need to ship the backwards compat code all the time.
<gchristensen>
emily: "anybody" runs ofborg builders, and I didn't want to make some builders do unfree and some not
<infinisil>
Yeah alright, sounds good to me
<FRidh>
if people blindly switch it's really their own fault
<yorick>
FRidh: I blindly update nixos-unstable all the time
<FRidh>
from oldstable to new stable as well?
<infinisil>
FRidh: I wish we had mandatory to read release notes, tied to what the user has enabled in their config
<yorick>
no, I don't actually run stables, stables are just the backward-compatibility-fences :D
<infinisil>
That would be a better solution for this
<FRidh>
infinisil: release notes generator that takes your system config
<yorick>
infinisil: those are called mkRemovedModule :D
<gchristensen>
emily: I've thought about making them build unfree recently since I control pretty much all the builders now, but I haven't because maybe I'll move the builders to the foundation, and I'm not sure they'd want that
<infinisil>
yorick: That's very much a hack for that!
<infinisil>
But yeah, let's merge the buildkite pr like this
<infinisil>
Wait
<yorick>
better error message?
<infinisil>
Yeah
<gchristensen>
infinisil++ yorick++
<{^_^}>
infinisil's karma got increased to 210, yorick's karma got increased to 10
<yorick>
flokli: hmm, I guess that's useful for testing?
<yorick>
I can envision some usecases, like that default legacy agent :P
<flokli>
yorick: umm?
<flokli>
I don't really see the usecase anymore, but that's nothing to fight for. Just keep it if you want ;-)
<yorick>
flokli: okay, removed :)
bennofs has joined #nixos-dev
hl has quit [Quit: Quit]
<flokli>
infinisil: PTAL, approved myself
<infinisil>
flokli: yorick: Oh I didn't notice until now, but .enable options are actually really useful
<infinisil>
E.g. if you have a dozen modules that set some values in services.buildkite-agents.<name>.*, you couldn't simply turn it off without a .enable
<infinisil>
You'd have to go through each module and remove the definitions
<infinisil>
With a .enable you can just do `enable = false`
<infinisil>
To temporarily disable it
<infinisil>
(or permanently, if some third-party module defines a service that you don't want)
<yorick>
infinisil: okay, reverted
<yorick>
well, reset to HEAD^
<infinisil>
Cool, looks good to me once tests pass
<yorick>
tests for this commit already passed once I think
<infinisil>
Ah
<infinisil>
And merged :)
<FRidh>
metrics job is broken again on master
Emantor has joined #nixos-dev
<yorick>
infinisil: thanks! :)
<yorick>
how can I find all direct dependencies of a package?
<srk>
nix-store -q --references ?
<yorick>
srk: wouldn't that only work for already built packages?
<srk>
yes, only for store paths
<srk>
for .drv as well
hl has joined #nixos-dev
hl has joined #nixos-dev
hl has quit [Changing host]
johnny101 has quit [Quit: Konversation terminated!]
johnny101 has joined #nixos-dev
sogatori has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Read error: Connection reset by peer]
sogatori has quit [Remote host closed the connection]
<gchristensen>
w00t hydra.nixos.org is backfilling IDs for jobsets and builds now
<Taneb>
:D
drakonis_ has joined #nixos-dev
<FRidh>
gchristensen: if you feel like improving more hydra performance...when merging staging-next into master, and then evaluating nixpkgs:trunk, it always shows it has to do a huge amount of builds, even though they've already been build. I wonder how efficient it is with those "builds"
<gchristensen>
hehe
<gchristensen>
I think it is fairly efficient... maybe I could give you access to a machine which has a database dump which you could test with? =)
vcunat has joined #nixos-dev
<FRidh>
no thank you, like most around here there's enough on my plate :) I suppose it already determines from the database no new build is needed, or would you think it invokes a new build (and retrieves the artifact from the cache)?
<gchristensen>
:P
<gchristensen>
it knows before it tries to start a build that it is already completed
<FRidh>
okay, then it's fine
<vcunat>
FRidh: I fixed metrics earlier without noticing the message
<gchristensen>
there probably is a good improvement which can be made, but I'm not sure what it is
<vcunat>
I already asked Eelco about these apparent rebuilds earlier
<gchristensen>
and this particular performance improvement was a bit of a "the house is on fire" situation even though I didn't say that
<vcunat>
IIRC there are supposed to be two passes through the build queue - first one checks if the binary output is done already and second one schedules the real processing
<gchristensen>
the nixos-unstable-small channel was failing to update quite frequently because the query to find the most recently finished, successful, tested job was taking 10 minutes
<FRidh>
vcunat: ok great. It's crazy always around branch-off with amount of commits going in
<FRidh>
vcunat: parse error: Invalid numeric literal at line 1, column 6 still happens?
<disasm>
afternoon/evening folks! We're getting ready to branch off today. FRidh are there any final staging-next merges we're waiting on? Does anyone have any other PR's they want to raise as being critical? I'm not seeing anything jumping out at me on the milestone.
<{^_^}>
#79144 (by marsam, 1 week ago, open): Pin nodejs to 12.x for 20.03
<worldofpeace>
anyone know about nodejs things here?
<vcunat>
I only follow the libuv part.
<gchristensen>
usually for nodejs I put up the samueldr or __sanders__ signal
FRidh2 has joined #nixos-dev
<samueldr>
I wouldn't know for nodejs, I only *used* it
<samueldr>
though I think adisbladis was involved in the last efforts to change the LTS we pointed to
<disasm>
worldofpeace: https://github.com/NixOS/nixpkgs/pull/79753 should do it. Not sure what we need to actually test. We could probably just merge and deal with breakage in ZHF
<{^_^}>
#79753 (by disassembler, 51 seconds ago, open): nodejs: pin to 12.x by default
<worldofpeace>
hmm, I wonder what a samueldr signal would like gchristensen.
<FRidh2>
disasm: last staging-next went in this afternoon
<{^_^}>
#79144 (by marsam, 1 week ago, open): Pin nodejs to 12.x for 20.03
<worldofpeace>
note that 8 goes end-of-life in December (an exception to the regular LTS cycle due to the EOL of OpenSSL 1.02 so you should already be planning your migration off it to either 10 or 12.)
<FRidh2>
yorick: if its approved, pushed to staging, and no significant regressions, then it may be cherry-picked.
<worldofpeace>
disasm: sounds like a no-op for us :D
<{^_^}>
#78910 (by yorickvP, 1 week ago, open): libarchive: link to zstd (split zstd output)
<worldofpeace>
disasm: I closed it and pinged adisbladis
<worldofpeace>
The EOL ruby removal I just merged to staging, it was mass rebuilding.
<worldofpeace>
So I guess we have to get the staging release branch going to backport it
ixxie has joined #nixos-dev
<gchristensen>
it strikes me that branch-off day is maybe not the most ideal day to run a major database migration against hydra
* cransom
has a giant yellow foam novelty cowboy hat for just those occasions.
<gchristensen>
lol
<gchristensen>
oh well, we're already 17m rows in
<aminechikhaoui>
posting the same question I asked in #nixos here:
<aminechikhaoui>
is there a nice way to figure out why a derivation A is needed by a drv B, `nix why-depends drv-A.drv drv-B.drv` seems to try to build stuff and I don't want to wait for the build tho'
<qyliss>
nix-store -q --tree
<aminechikhaoui>
niksnut btw should nix why-depends support derivations as well ?
<aminechikhaoui>
it tries to build the derivation for me before emitting any output
<LnL>
yeah, this might not be in stable yet
<disasm>
samueldr: do you remember how the nixos services that were changed since last release that goes in release notes was generated?
<samueldr>
they were not, only judicious and careful use of `git` targeting the `nixos` directory
<samueldr>
where I dumped IIRC all merge commits, looked at all PRs, etc
<aminechikhaoui>
oh man, that sounds exhausting
<samueldr>
not that bad
<samueldr>
--merges-only and whatever the right param to target the nixos/ subdirectory
<disasm>
ah, yeah, I ran !r with that git log to the fork point and then did some vim surround fun in a macro to wrap it, I remember now.
<disasm>
it's coming back to me now :)
<samueldr>
the worst part is `pkgs`, but not that bad either, you first grep ' -> ' to get all package upgrades, comb quickly to see if anything major stands out
<FRidh2>
I'm using the 11.by: package-maintainer tag now to prioritize PR's that are made by the maintainer or add the author as maintainer. It's about 1/4th of all PR's. We also have a lot of PR's where the authors add themselves as maintainers, which is great.
<samueldr>
then grep `inits? at` to see new packages, comb quickly for anything that stands out
<LnL>
aminechikhaoui: hmm you're right it used to always diff the outputs, which was fixed, but it's still building first for some reason
<samueldr>
then grep *agains* both of those patterns and try to figure out if anything important
<gchristensen>
there have been a lot more search queries hitting the DB today than I think I've ever seen before, interesting :)
<gchristensen>
these are actually searches, like mono and chromium :)
<gchristensen>
(I'm watching the slow query log)
<gchristensen>
lol hi person
ris has joined #nixos-dev
phreedom has quit [Ping timeout: 240 seconds]
phreedom_ has joined #nixos-dev
<disasm>
does this look better for the nodejs pin PR? (not targeting 20.03, but since I started it, figure I'll see it through to the next release) https://github.com/NixOS/nixpkgs/pull/79753
<{^_^}>
#79753 (by disassembler, 1 hour ago, open): nodejs: pin to 12.x by default
drakonis_ has quit [Remote host closed the connection]
FRidh2 has quit [Quit: Konversation terminated!]
phreedom_ has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
drakonis_ has joined #nixos-dev
<disasm>
hey, can someone delete the release-20.03 branch? We have a typo and I'd rather not add an extra commit to fix it.
<gchristensen>
yep
<gchristensen>
disasm, worldofpeace: deleted
<gchristensen>
I am going to re-lock it
<disasm>
gchristensen: so nixos-org-configurations steps have changed a bit with a channels.nix. Should we be marking current to true or false?
<worldofpeace>
re lock is good btw
<worldofpeace>
gchristensen: pr was pm'd
<gchristensen>
please mark them as current (and if you could add a comment to the file at the top saying that, too)
<disasm>
is setting current = false telling hydra to stop building the channel?
<gchristensen>
no
<gchristensen>
(some docs on what current means would be good, eh? :) :) )