<pie_[bnc]>
cole-h: i mostly get this stuff by having too many irc channels open
<pie_[bnc]>
I'm not sure about the strict immediate overlap with whats going on with what we do, but like, for example, maybe it gives a framework for thinking about how we integrate other packaging systems into nix/pkgs, ...or not, idk :D
<Profpatsch>
It’s definitely an important fundamental read.
<Profpatsch>
And afaik the first academic comparison of different build systems.
<gchristensen>
20.03.1422.1e90c46c2d9 (Markhor)
<gchristensen>
woo!
<hyperfekt>
pie: are you deliciouslytyped?
<Profpatsch>
he is
<pie_[bnc]>
gchristensen: wooooooo \o/
<pie_[bnc]>
a paper *and* a release, what a week ;p
ris has quit [Ping timeout: 256 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
<jtojnar>
worldofpeace the fact that qt's mkDerivation should be removed was acknowledged by Thomas
<jtojnar>
since it does not bring almost any benefits to wrapQtAppsHook I see no reason to continue using it, especially if it is to be deprecated
<jtojnar>
s/benefits to/benefits compared to/
<jtojnar>
the fact that documentation promotes it is unfortunate but it is a documentation bug, that can be rectified
<worldofpeace>
Jan Tojnar: he said it was going to continue to work and be deprecated. I just find it frusterating because the majority of people just have no idea what qt mkDerivation is, and we just basically had a big thing that it needs to be used
FRidh has quit [Ping timeout: 256 seconds]
<worldofpeace>
I personally wouldn't ask that person to change it, just because it wasn't done automatically. Those poor hands 🤣
FRidh has joined #nixos-dev
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
<jtojnar>
I guess we can merge it now and then do a removing sprint
<worldofpeace>
Jan Tojnar: right, and hopefully with a tool to do it
<jtojnar>
should I open an issue for the osinfo automation?
<worldofpeace>
Jan Tojnar: sure, it seem they suggested to do something like what they do in endless os.
<worldofpeace>
it'd sure be nice to not have to do stuff manually
<jtojnar>
yeah, it would just link to the comment
<jtojnar>
so I can close the browser tab 😀️
<jtojnar>
I have hundreds of browser tabs just for things I need to open issue about
<b42>
feel free to cc me on the issue, i can try to put the script together (unless one of you want to)
<worldofpeace>
b42: that would be awesome. it would probably take me maybe a week, so feel free
<b42>
worldofpeace: sure ... probably won't get to it until the months end though
<worldofpeace>
b42: I don't think we have to be in any particular hurry, we do have 6 months
<emily>
just flagging this up for anyone who cares, licensing issue in p7zip package: https://github.com/NixOS/nixpkgs/pull/85780 (package is non-free but not marked as such)
<qyliss>
Anyone have any thoughts on this? A package is marked free but shouldn't be. We can remove some functionality to make it free. On the release branches, should we mark as unfree and not modify, or modify to make free? https://github.com/NixOS/nixpkgs/pull/85780#issuecomment-617834292
<qyliss>
Either way is a breaking change but we can't have a package in a supported release branch with the wrong license
<qyliss>
Since I can't imagine why anybody would need to use that particular program for unarchiving rar files when we have other free ones available
<emily>
I suspect few people use p7zip for this anyway since there's already the unfree nixpkgs.unrar that most people seem to go for
<adisbladis>
I made a follow-up PR for the enableUnfree change.
<emily>
but not sure whether backporting or just changing the license is the best choice for release branches, yeah, so didn't submit a PR
<emily>
adisbladis: tbh, I'm biased, in that I think if you take one look at the p7zip source code you'll run away screaming and install one of the alternatives I mentioned instead
<emily>
no release since 2016 + outstanding CVEs + memory-unsafe legacy mess codebase that interacts with untrusted files
<emily>
if it wasn't the one of the ~only 7zip implementations I wouldn't even have it installed now
<{^_^}>
#85782 (by adisbladis, 3 minutes ago, open): p7zip: Make unfree features (rar support) optional
<qyliss>
But then you break free systems that only use it for more common formats
<adisbladis>
Damned if you do, damned if you don't.
<adisbladis>
Good point though
<qyliss>
I suppose breaking at evaluation time is better than breaking at runtime
<qyliss>
So we should keep it unfree in stable, and mark it as so appropriately
<qyliss>
I'm still not convinced we need an option for the unfree bit though
<adisbladis>
I'm not convinced either :>
<qyliss>
Using the unfree stuff would already require a configuration change, to enable the option
<emily>
I do think it's unfortunate that 20.03 would not have any free package that can unpack .7z files.
<emily>
so for 20.03 I think an option like adisbladis's PR, or just backporting the RAR removal code, is best
<emily>
"you have to use another RAR unarchiver" feels less breaking than "7zip is gone if you want a free software system (which is after all the nixpkgs/nixos default)"
<adisbladis>
I think we need the option tbh
<qyliss>
Yeah
<qyliss>
Alright
<emily>
(actually, maybe unar can handle 7zip? not sure. but I suspect 90% of people will go for p7zip and not look for anything else)
<adisbladis>
There are a lot of other software depending on p7zip that potentially wants to use it for rar support
<adisbladis>
There is*
<adisbladis>
If we have the config option at least we provide an escape hatch for those programs.
<qyliss>
Approved the PR :)
<gchristensen>
(20.03 already doesn't have any free package that can unpack .7z files)
<{^_^}>
#85782 (by adisbladis, 34 minutes ago, open): p7zip: Make unfree features (rar support) optional
<emily>
seems reasonable (but I don't have commit bit, so I can't :P )
<adisbladis>
Oh, I thought you had commit bit :)
justanotheruser has joined #nixos-dev
<gchristensen>
I wonder if we should have an idiom for something like this: foo.overrideAttrs ({ patches ? [], version, ... }: assert version == "1.3.2"; { ...
<qyliss>
to break eval if version changes+
<qyliss>
*?
<gchristensen>
yeah
<gchristensen>
like I'm making this override to bump the package up, but I really just want to only set the verion if I'm upgrading it. I've written a helper like this other plcaes too
<qyliss>
I couldn't see the use case I think because I just edit Nixpkgs if I want to upgrade something
<qyliss>
but probably makes more sense on stable
<gchristensen>
yeah, definitely
<qyliss>
why not just import packages from unstable?
<gchristensen>
I'm not sure
ris has joined #nixos-dev
<MichaelRaskin>
Well, different glibc output path sounds like a possible reason
<gchristensen>
right, yeah, I want all my packages to be stable except I want this one thing updated
<MichaelRaskin>
And if you still want it to use stable glibc despite itself being updated, you cannot just import from unstable
<qyliss>
i'm a big believer in just using git for this
<gchristensen>
yeah, I know, but that isn't the workflow I want to have :)
<qyliss>
fair :)
cole-h has joined #nixos-dev
<MichaelRaskin>
Hmmm. Technically, I guess you can import the package function from unstable, and call it on stable, all within Nix!
<worldofpeace>
What would you all say are base requirements for someone looking for the position of release manager?
<MichaelRaskin>
Having upgraded through at least two NixOS stable releases (X → X+1 → X+2), maybe?
<gchristensen>
care
<worldofpeace>
gchristensen: always care. #1 I think we all can agree is write access to nixpkgs.
<gchristensen>
maybe a little bit more than that .. :)
<worldofpeace>
Well duh gchristensen, but I had at least one person who hasn't recieved write access reach out to me. And it's confusing because in nixpkgs there's no process to get commit bit
<gchristensen>
interesting
<MichaelRaskin>
Is their experience on the level where some people have already received commit access, though?
<worldofpeace>
I believe none of us have problems granting people who are trustworthy commit access lately
<MichaelRaskin>
Well, there are still experience expectations that are not completely agreed upon but have some clearly enough and some clearly not enough states. If someone doesn't have access but could as well have, maybe this is a trigger to nominate them more than a failed prerequisite.
<gchristensen>
^
<qyliss>
MichaelRaskin++
<{^_^}>
MichaelRaskin's karma got increased to 30
<worldofpeace>
Well, for this particular instance I'm feeling it's the latter as you mention MichaelRaskin
<worldofpeace>
✨ MichaelRaskin
<{^_^}>
MichaelRaskin's karma got increased to 31
das_j has quit [Quit: killed]
ajs124 has quit [Quit: killed]
Scriptkiddi has quit [Quit: killed]
abathur has joined #nixos-dev
<MichaelRaskin>
Ah OK, surely happens.
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
<MichaelRaskin>
The drawback of care as requirement, is its bad intersubjective comparability. People who care most are also susceptible to thinking they do not care enough… (FTR: I actually do not care enough, but I have objective proof — like never using release branches of Nixpkgs)
<gchristensen>
lol
<gchristensen>
I assume anyone putting their hat in ticks the "cares" box :)
peelz has quit [Remote host closed the connection]
<gchristensen>
as it sort of automatically filters out the people who don't
<MichaelRaskin>
I agree with that — but this also means _mentioning_ care among requirements is typically redundant
<gchristensen>
yeah
peelz has joined #nixos-dev
<worldofpeace>
I guess I'm off to nixos discord to further advance my search :D
<drakonis>
there's a new and improved package and option search now?
<pie_[bnc]>
Ericson2314: ah well too bad, looks like Andrey wont be around
multun has joined #nixos-dev
<jtojnar>
FRidh I would like to test running staging-next before merging
<jtojnar>
since meson bumps are often runtme breaking
<FRidh>
jtojnar: most things are built already
<FRidh>
so you can give it a try
<FRidh>
otherwise I intend to merge today so we can start building the new openssl
<FRidh>
is it an idea to have a nixos test that runs several meson-build applications?
arianvp has quit [Quit: WeeChat 2.6]
arianvp has joined #nixos-dev
<cole-h>
First PR of nix-errors-enhancement was merged! 🎉
<drakonis>
nice!
<drakonis>
:toot:
<drakonis>
20.09 will be a fun release
arianvp has quit [Quit: WeeChat 2.7.1]
arianvp has joined #nixos-dev
<FRidh>
security updates on 3 branches...hydra is having a tough time
arianvp has quit [Quit: WeeChat 2.7.1]
arianvp has joined #nixos-dev
<Ericson2314>
pie_[bnc]: ah well at least you tried
<{^_^}>
#85800 (by arianvp, 27 seconds ago, open): Networkd doesn't restart anymore on unit changes in 20.03
<arianvp>
this change should be reverted I think
<worldofpeace>
ummm
<arianvp>
or am i mistaken
<worldofpeace>
it sounds difficult either way, maybe
<arianvp>
oh ok
<arianvp>
it is only 2 services it seems
<arianvp>
I think we got lucky :D
<arianvp>
I'll make a PR
<arianvp>
I was scared this thing was sed'd in many places, but seems only in two
<arianvp>
*breathes*
<worldofpeace>
arianvp: there's 70 files with restartTriggers, so even if it were every one it's fixable without a full revert
<worldofpeace>
that was rather difficult PR
<arianvp>
I think only two restartTriggers were touched in that PR no?
<arianvp>
or more?
<arianvp>
ah more
<arianvp>
nope only two... i think it's ok
<arianvp>
i'll make a fix; but we should probably backport it . we dont have to revert that entire commit
<worldofpeace>
arianvp: well, you'd have to revert maybe 20 commits. Sounds good for backport 👍️
<arianvp>
no need to revert commits
<arianvp>
I'll just make two commits fixing the two services
<arianvp>
sorry for immediately breaking things again. i have a gift to run into obscure bugs when i dont want to
<arianvp>
murphy's law I guess
peelz has quit [Remote host closed the connection]
<jtojnar>
FRidh seems like there are still some builds in progress for GNOME stack
<jtojnar>
47140 queued builds in the eval seems like too much to me still
<jtojnar>
over 16k on x86_64
<jtojnar>
I would run gnome3 tests at min
<jtojnar>
worldofpeace any inputs re wrapgappshook tests?
drakonis has quit [Quit: WeeChat 2.8]
<FRidh>
jtojnar: yea its going really slow now with builds for other branches going on as well
FRidh has quit [Quit: Konversation terminated!]
CRTified has quit [Quit: Gateway shutdown]
<MichaelRaskin>
infinisil: as for using the inspection dependencies to limit builds, my hopes for top-level-inotify-only were indeed silly, as approximately every input is scanned for existence of include/, so the full list of accessed files is needed
drakonis has joined #nixos-dev
thonkpod has quit [Ping timeout: 260 seconds]
thonkpod has joined #nixos-dev
<matthewbauer>
gchristensen: I actually do still have access to nixtravis. Although I don't remember what that was used for? I think travis-ci needed it for avoiding rate-limiting
<{^_^}>
matthewbauer: 1 day, 4 hours ago <gchristensen> to ping me when he's available
<gchristensen>
yeah
<gchristensen>
can you revoke its token
<gchristensen>
?
<matthewbauer>
yeah sure
<matthewbauer>
just did
<gchristensen>
cool, people keep emailing me telling me the key is compromised :P
<gchristensen>
thanks
<matthewbauer>
lol
<matthewbauer>
it didn't have any permissions, but I guess you could use it to spam github
<gchristensen>
yeah, I dunno
<matthewbauer>
niksnut: what's your preference regarding https://github.com/NixOS/nix/pull/3523? we can definitely hack it onto path-info, but wasn't sure if that really fit with the original intent. I do really like that the `--eval`, `--build`, `--run` flags mapping to `nix eval`, `nix build`, `nix run`, but we can do that with path-info as well.