<lovesegfault>
and I noticed very quickly that there are _large_ groups of failures there, by which I mean there are a few libs with many revdeps causing a snowball effect
<lovesegfault>
Any easy way to check this?
psyanticy has joined #nixos-dev
__monty__ has joined #nixos-dev
Jackneill has joined #nixos-dev
zarel has quit [Ping timeout: 240 seconds]
mmlb has quit [Quit: Ping timeout (120 seconds)]
chrisaw has quit [Ping timeout: 258 seconds]
mmlb has joined #nixos-dev
srhb has quit [Read error: Connection reset by peer]
zimbatm has quit [Read error: Connection reset by peer]
srhb has joined #nixos-dev
zimbatm has joined #nixos-dev
chrisaw has joined #nixos-dev
elvishjerricco has quit [Ping timeout: 240 seconds]
elvishjerricco has joined #nixos-dev
phil_d has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
Synthetica has joined #nixos-dev
phil_d has left #nixos-dev [#nixos-dev]
<bennofs>
do we have a label for PRs that still need code changes? Things like package updates that break something or which require some new binary patching
Profpatsch has quit [Remote host closed the connection]
carter has quit [Read error: Connection reset by peer]
nh2 has quit [Read error: Connection reset by peer]
feepo has joined #nixos-dev
nh2 has joined #nixos-dev
carter has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
ris has joined #nixos-dev
ixxie has joined #nixos-dev
<worldofpeace>
globin++
<{^_^}>
globin's karma got increased to 11
<worldofpeace>
yay
<worldofpeace>
reading material that was needed
<worldofpeace>
bennofs: that's actually a good idea, usually I comment on those PR "Hey mergers/integrators, this PR can't be merged on its own because it brings a bunch of breaking changes, thanks 🌈"
<bennofs>
worldofpeace: I thought about using the 2. status: stalled label, but that doesn't fit 100%
<bennofs>
should I just create a new label? (do normal contributors have the right for that?)
<worldofpeace>
Yeah, I think anyone can create a new label. But I think people who can do the labeling need to know what and how to use them first
<worldofpeace>
(a committer that is)
<worldofpeace>
like there's work in progress, but what you described is a unique situation a lot of changes can be in
kenjis1 has joined #nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
ixxie has quit [Ping timeout: 265 seconds]
<bennofs>
worldofpeace: ok, I created a topic on discourse to maybe have a broader discussion and make people aware of it if we create a new label for it
ddima has joined #nixos-dev
<lovesegfault>
Is there a way to view all failures in a hydra eval in a hierarchical (sorted) fashion?
<lovesegfault>
and I noticed very quickly that there are _large_ groups of failures there, by which I mean there are a few libs with many revdeps causing a snowball effect
<samueldr>
the eval report tool IIRC tries to match up common "parent" failures
<samueldr>
lovesegfault: not sure if that'll help you
<lovesegfault>
samueldr: I'll check it out :)
<lovesegfault>
Can we get a darwin community box as well :P
<gchristensen>
yeah maybe
<lovesegfault>
:D
<worldofpeace>
Honestly not sure what we should be doing with the aliases in aliases.nix. Maybe we should phase them out every two releases? It'd be a worthy task pre beta for nixos
<worldofpeace>
in particular, throws for removed attrs
<gchristensen>
one problem with ,inclusive-language is I don't want to spam someone with it, and I don't know if anyone else sent the message already
<worldofpeace>
gchristensen: it could be rate limited
<gchristensen>
that would be good
<worldofpeace>
maybe all pms should 👍️
<ajs124>
worldofpeace: re aliases: they don't warn or anything currently, right?
<worldofpeace>
ajs124: No they aren't, that would be a great improvement also
<infinisil>
worldofpeace: I believe this is already implemented?
<infinisil>
(feel free to try it out on me)
<worldofpeace>
,inclusive-language infinisil
<{^_^}>
Can only be used in PMs: ,inclusive-language #<channel> <user>: Anonymously send a PM to a user saying "Hello and welcome to #<channel> 👋. We'd appreciate when you address the whole channel using all inclusive words such as; everyone, all, folks, y'all, youz, or fellow humans. Thank you and enjoy your stay! <This is an anonymously sent, pre-written message. If you have any questions, feel free to ask in #nix-diversity>"
<gchristensen>
21:28 <{^_^}> This user was already informed recently
<arianvp>
gchristensen: all you still working on that secureboot pr?
<gchristensen>
yes-ish
<gchristensen>
IMO it is blocked on the test infrastructure being able to test that PR
<arianvp>
hmm
<gchristensen>
IMO we can't merge it without a test
<arianvp>
Wondering if we should add EFI shim support
<arianvp>
e.g. use Fedora's sigend EFI shim loader
<gchristensen>
making the test infra support it has been something I've looked at several evenings for a time, but have not managed to solve
<arianvp>
as changing secureboot keys is really annoying on most laptops
<ajs124>
worldofpeace: that warning would be very useful. Right now I'm trying to evaluate some systems with allowAliases = false and somewhere someone references gnome3.gtk, which fails, but I can't even figure out where that's coming from
<arianvp>
gchristensen: Step one would be to make the QEMU test VMs use EFI
<arianvp>
that's a good idea anyway I suppose
<samueldr>
tangentially related rfcs#33 where a user story was being worked on for all deprecated things
<worldofpeace>
infinisil: like a part of the release process, to get to beta or during, we could figure out how old each alias and removed is. if they've been there for two nixos releases we drop them. (public issue on this) And also making sure no removed attr is left without a `throw`, but that can easily be handled as a PR check
<arianvp>
ok i might pick this up in the near future
<arianvp>
looks fun
<gchristensen>
cool :)
<samueldr>
arianvp: the cliff notes is that the test harness must be configurable so that the initial boot is EFI, with NVRAM disk
<samueldr>
it would be required to *actually* test our EFI bootloaders right
<infinisil>
worldofpeace: Hehe yeah that rfc is exactly for something like that
<gchristensen>
and then setup the EFI thingy that qemu uses to register some generated keys
<samueldr>
as of right now it's kinda hacky as we're only testing the default paths and not custom paths
<ajs124>
does that rfc also talk about dropping "broken" things? because there are some (leaf) packages, which have been broken for years, but still haven't been dropped
<arianvp>
signing EFI bootloader is a PITA; and so is getting the keys onto your motherboard
<samueldr>
ajs124: IIRC the main thing was user-side story, nothing more
<samueldr>
anything more is orthogonal
<samueldr>
uh, well, making warnings
<worldofpeace>
infinisil: 😹 I wish a had time to pick it up because it's important for Releasing NixOS. I'm getting a bit worried if there will be a reaction for 20.03 because lots of packages are and are going to be removed
<worldofpeace>
ajs124: yeah I think that would be out of scope, but people already are encouraged to remove those
<infinisil>
Removing packages should be as normal as adding new ones imo
<lovesegfault>
infinisil++
<{^_^}>
infinisil's karma got increased to 195
<ajs124>
Seems like we have the same problem every project has at some point. Everyone likes adding features and things, but removing them is somebody elses problem™
kenjis1 has quit [Ping timeout: 260 seconds]
<worldofpeace>
It's a very nuanced topic, for sure can't be understood just black and white
<lovesegfault>
Do we track usage?
<lovesegfault>
like D/L counts from the binary cache
<infinisil>
Yeah, a big gripe i have is with new nixos modules. Because all of the options expose a public api of sorts, and you can't remove options without users not liking it. So ideally all options would be as good as possible from the start
<infinisil>
But many new modules don't have that..
<samueldr>
even the package set is a public API of sort
<samueldr>
external projects may depend on an attribute
<infinisil>
samueldr: Yeah
<worldofpeace>
lovesegfault: no we don't and that would help a tooonnnnnn
<infinisil>
I actually have a proposal for a project to track the public API of nix projects
<samueldr>
if I hadn't spotted the gcc49 removal PR, I would have been surprised down the line
<worldofpeace>
I think someone has a project for that, let my check lovesegfault
<arianvp>
we could also keep a reverse-index of some sorts.
<arianvp>
of NAR->attrName
<gchristensen>
NAR->[attrName]
<arianvp>
yes
<gchristensen>
ddima was just PMing me annoyed I hadn't talked to him about popcont yet
<worldofpeace>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 197
<worldofpeace>
*nudges
<arianvp>
is the narFile just drv.outPath + ".nar" ?
<gchristensen>
NARs are content-addressed
<arianvp>
how do we get the outPath => nar mapping?
<gchristensen>
via .narinfo
<gchristensen>
«outpath».narinfo
<arianvp>
I always forget this part of nix; is a bit confusing
<infinisil>
samueldr: worldofpeace: Here is a proposal I wrote for a Nix api tracker tool (originally intended for a bachelors thesis): http://public.infinisil.com/nixapi.pdf
<infinisil>
In short: Generate an API description from a repository commit, this can include file paths, what expressions are in these files and what the derivations should have in their outputs
<infinisil>
With a generated API description it can then be compared between different commits to detect which symbols/files were added/removed/changed, allowing a bot to run such a check for every PR, detecting backwards incompatibilities
<worldofpeace>
sounds fab infinisil ++
<worldofpeace>
will read
__monty__ has quit [Quit: leaving]
<arianvp>
building this recursive index of outPath -> [attrName] isn't too hard. just a few lines of nix
<arianvp>
at least for topLevel attributes
<arianvp>
based on that we can then correlate the amount of narinfo files downloaded to what attributes in nixpkgs are in use