samueldr changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 Feature Freeze Feb 10 | | | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm |
dongcarl has quit [Quit: Ping timeout (120 seconds)]
dongcarl8 is now known as dongcarl
qyliss has quit [Quit: bye]
qyliss has joined #nixos-dev
ris has quit [Ping timeout: 260 seconds]
bhipple has joined #nixos-dev
drakonis has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
bhipple has quit [Ping timeout: 260 seconds]
bhipple has joined #nixos-dev
bhipple_ has joined #nixos-dev
bhipple_ has quit [Client Quit]
<disasm> flokli: should that be blocking the release?
<{^_^}> #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 has joined #nixos-dev
<emily> someone with hydra rights might want to look at (font files being redistributed in hydra builds against the license)
<{^_^}> #79679 (by emilazy, 57 seconds ago, open): fonts/gdouros: correct license to unfree
<emily> nasty licence change :s
<samueldr> I was curious, looks like it was at some point
<samueldr> whew!
<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
<worldofpeace> Things look good, I hope I still think that tomorrow 🤣
Taneb has quit [Quit: I seem to have stopped.]
Taneb has joined #nixos-dev
<emily> gchristensen: hm, is it intentional that ofborg can't test build non-free packages?
<emily> guess it makes sense since the generated artifacts would probably be radioactive, but ofborg doesn't share those right?
drakonis has quit [Quit: WeeChat 2.7]
<qyliss> ofborg doesn't necessarily even have a license to run that code
<qyliss> you can't assume anything at all from licenses.unfree
<genesis> i try to make it unfree.distributable for soulseek, dead end.
justanotheruser has quit [Ping timeout: 248 seconds]
justanotheruser has joined #nixos-dev
bhipple has quit [Remote host closed the connection]
marek has joined #nixos-dev
FRidh has quit [Remote host closed the connection]
FRidh has joined #nixos-dev
MoreTea has joined #nixos-dev
<FRidh> staging-next builds keep failing on hydra with g++: fatal error: Killed signal terminated program cc1plus
<FRidh> builds fine locally
__monty__ has joined #nixos-dev
jtojnar has joined #nixos-dev
<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.
orivej has joined #nixos-dev
page has quit [Ping timeout: 248 seconds]
page has joined #nixos-dev
<yorick> 4.2.1 is still the version in nixos-unstable
<yorick> this seems problematic for anyone running pinned nixpkgs
<Taneb> yorick: I think we're including the patch to make that fixes that issue
<yorick> Taneb: since when?
<Taneb> yorick: since 2017
<yorick> oh, then crisis averted :)
<Taneb> Still, thank you for noticing the potential issue and bringing it up
<yorick> flokli: infinisil: would be nice if we could get the buildkite-agent thing in before the fork
<{^_^}> #78373 (by yorickvP, 2 weeks ago, open): nixos/buildkite-agents: support multiple buildkite agents
<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?
<flokli> yes, as written in the issue
<flokli> bootstrap/hooks stuff
<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
<infinisil> Better error message, then merge :)
<yorick> okay, working on it
<flokli> also, rebase plase
<flokli> s/plase/please/
<yorick> okay, done
<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 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?
<vcunat> the metrics job doesn't work for me locally either
<{^_^}> #76776 (by vcunat, 5 weeks ago, open): metrics job issues
<vcunat> I've just been doing higher-priority nix* stuff so far. This somehow works so far.
<FRidh> ok
<FRidh> yes its really frustating you don't see at all where it fails
<vcunat> For the last error I did see it actually.
<vcunat> In Hydra's logs; locally it's the other issue.
<worldofpeace> Jan Tojnar: I hope it's ok I merged the flatpak PR
<jtojnar> worldofpeace I wanted to test it manually but still downloading the runtime 🤣️
<jtojnar> if it breaks, we will fix it during ZHF
<worldofpeace> true
<worldofpeace> those runtimes are sure a very long download 😃
<worldofpeace> samueldr: did you have a branch with
<samueldr> I didn't
<worldofpeace> ok cool, will do this
<samueldr> thanks!
<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.
<worldofpeace> I'm not sure what to do with
<{^_^}> #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: 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
<{^_^}> #64336 (by adisbladis, 31 weeks ago, merged): Drop nodejs-8_x
<FRidh2> any further changes will be cherry-picked
<worldofpeace> ooh goodness samueldr, that's for sure not a simple as what disasm suggested.
<yorick> FRidh2: the zstd thing would be..nice to have, but yeah, not sure how much it breaks
<worldofpeace> seems like you have to regen the package set as well
<disasm> oh :(
<disasm> guess that reveals how much I use nodejs :)
<worldofpeace> but this issue says it's active lts
<{^_^}> #79144 (by marsam, 1 week ago, open): Pin nodejs to 12.x for 20.03
<worldofpeace> is the current version EOL?
<samueldr> I guess it depends if 10 is relied upon as much
<worldofpeace> disasm: lol, same
<disasm> Node.js 12 becomes the newest LTS release along with 10 and 8 -- so we could just push this to 20.09 milestone?
<{^_^}> #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
<disasm> yeah, I'm thinking the same
<{^_^}> #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 ?
<qyliss> that's what I usually use, at least.
<aminechikhaoui> oh nice
<LnL> why-depends works with drvs AFAIK
<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 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 :)
<FRidh2> gchristensen: guess I was hitting f5 quite a bit on this afternoon :)
<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)
<{^_^}> #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? :) :) )
<gchristensen> one sec
<worldofpeace> cool, we're hoping to wrap things up. ping us when the jobsets are created so we can make the ZHF issue
<gchristensen> sorry, stepping back a second --
<gchristensen> you're ready for the jobsets to be created? :)
<worldofpeace> yes
<gchristensen> do you have a link to the manual section for that? I want to make sure I do it right
<worldofpeace> it's very very very brief
<worldofpeace> it also has to say about stableBranch being false
<gchristensen> okay cool
<worldofpeace> vcunat: how do handle the staging release branches?
<gchristensen> including making the staging jobset
<vcunat> I'm not aware of anything special about the staging-*.* branches
<vcunat> worldofpeace: ^^
<vcunat> IIRC they originated mainly because of the period of most ZHF activity.
<vcunat> But even later they are sometimes useful - for mass rebuilds that don't hurry.
<gchristensen> IMO they should be shut down after the initial ZHF rush, otherwise I worry things get forgotten in them
<worldofpeace> umm
<worldofpeace> it seems even after they get used just for mass rebuilding changes
<worldofpeace> and it's often a pain for anyone who wants to backport a security fix that does a mass rebuild
<worldofpeace> I'm asking because I'm wondering what to put when documenting the staging release branches, that's not in our docs at all
<gchristensen> I'm not sure stable branches have regular staging activity -- so I think it is possible we're breaking new ground here
<vcunat> It certainly isn't 100% clear to me how (not) to use them.
<vcunat> The risk of forgetting changes in there is real.
<vcunat> IIRC I occasionally found some stuff in staging-19.09 delayed by a couple weeks.
<worldofpeace> anyways, I created the branch because I didn't know I had to do this
<vcunat> Before ZHF is done it's certainly useful.
<vcunat> (I mean, "Until ZHF is finished".)
lovesegfault has joined #nixos-dev
<worldofpeace> yeah, that makes sense to me
vcunat has quit [Quit: Leaving.]
ixxie has quit [Ping timeout: 272 seconds]
drakonis_ has quit [Read error: Connection reset by peer]
<worldofpeace> So triggering evals on release-20.03 results in hydra-eval-jobs returned signal 9:
<worldofpeace> (no output)
<gchristensen> I can't look right now, but sometimes This Just Happens
<gchristensen> hopefully it will successfully evaluate soon
<gchristensen> I sort of suspect it happens when many many many jobs/drvs are being created for the first time
<worldofpeace> because of this I can't populate ZHF, so everyone can probably expect that being either posted like 5 hours from now or tomorrow
<gchristensen> +1
<worldofpeace> thanks for the help gchristensen
<gchristensen> yeah, sorry for the less than ideal news
<worldofpeace> lol no it's cool. this means I can finally log off for the afternoon
<worldofpeace> * evening (doesn't understand time)
claudiii has quit [Quit: Connection closed for inactivity]
<gchristensen> only 53,413,861 rows remaining. woo.
lovesegfault has quit [Quit: WeeChat 2.7]
<worldofpeace> (holds up a ❤️)
<samueldr> how much is that as a ratio?
<gchristensen> 50%
<samueldr> good progres
<samueldr> s
<gchristensen> averaging about 3,000 records per second
bhipple has joined #nixos-dev
__monty__ has quit [Quit: leaving]
johnny101 has quit [Ping timeout: 240 seconds]
Cale has quit [Remote host closed the connection]
Cale has joined #nixos-dev