<lopsided98>
Could someone take a look at https://github.com/NixOS/nixpkgs/pull/83904? It fixes a pretty critical bug in the sanoid module, but hasn't gotten attention from anyone who can merge it.
<lopsided98>
yes, I have been testing it for the last few days. I have a review in progress, but I'm currently waiting to see if I fixed some of the transient failures it was causing.
orivej has quit [Ping timeout: 246 seconds]
<julm>
ok :)
justanotheruser has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 260 seconds]
<eyJhb>
Do we have any solutions, to ensure that the latest security patches are applied to a NixOS system? Channel blocks can make it take really long, before that the patches get there
saschagrunert has joined #nixos-dev
cole-h has quit [Ping timeout: 260 seconds]
<ivan>
I use nixpkgs from a git repo instead of channel and apply PRs early as needed
<ivan>
being in all the distro -security channels can be helpful as an early warning
<samueldr>
I think eyJhb was looking for a more proactive response for the general users
<samueldr>
do we have a process to fast track badly needed updates?
<ivan>
ah
<eyJhb>
ivan: But wouldn't it be nice, if we could automate this?
<eyJhb>
E.g. the chromium update this is being exploited in the wild, would be cool to fast track
<samueldr>
I think the last time it was discussed it was said that if the *-unstable channels were held back by something else, reverting it would be the way to go
<samueldr>
and that stable channels shouldn't have such issues
<samueldr>
but I guess if they do it's even more trivial to revert the breakage
<eyJhb>
But normally I wouldn't assume unstable to be more insecure, only if the latest packages are insecure
<eyJhb>
But I see what you are saying.
<samueldr>
they get more development in the master branch, so sometimes there's hiccups
<eyJhb>
But what would you revert, in what sense?
<samueldr>
identify the culprit change of the blockage
<samueldr>
then revert the change
<samueldr>
I mean, there _is_ something specific that is blocking in hydra in that hypothetical scenario
<eyJhb>
Would you do that is a intermediate fix? And then until it is fixed, not have that commit ?
<samueldr>
yeah, that breaking commit would have to be re-done, since _anyway_ it was breaking things :)
<samueldr>
though they can seem to happen often, it's not _that_ bad considering the amount of changes in the development branch
<samueldr>
there's so much being merged-in all the time
alp has joined #nixos-dev
<eyJhb>
Yeah that is true, it would be nice with not having the unstable channel get "behind" as quick
<eyJhb>
Also, I think that most of the time, the breakage is fixed quite quickly, but then it takes quite some hours before the next run. Maybe if comitters/maintainers were to force build/eval it again?
<samueldr>
without revamping the tooling, it would become a burden on each maintainer
teto has joined #nixos-dev
<eyJhb>
Also what I am fearing
<samueldr>
a solution would be like that tool I forget the name, where you queue commits and they are added to master only if merging master with it passes some tests
<samueldr>
I feel that would only be good if it was part of the hydra ecosystem, where those builds are cached
<samueldr>
"where you queue commits" => where you queue change sets
<samueldr>
let's not break up PRs needlessly!
<eyJhb>
Just spit balling, but if a test/drv fails, then maybe go into a state, where it will continuely pull the latest nixpkgs version, and try to evaluate that specific test/drv/package, untill it suceeds
<eyJhb>
And then eval the rest
<eyJhb>
And when I say continuely, I mean like... 10/30/60 minutes
<samueldr>
I don't get what you're aiming at
<eyJhb>
Basically what I am seeing most of the time, is that it will fail evaluation/build on a specific commit, and then it will queue a new build, that it will try in 6 hours or something like that
<samueldr>
that assumes the change would appear quickly enough
<samueldr>
the fix, I mean
<eyJhb>
And at that point, the queued commit might be old, and the fix is actually pushed to tho repo, but will not be evaluated for another day, etc.
<eyJhb>
True
<samueldr>
we can always requeue an eval manually in that case once the fix is in
<eyJhb>
"we" :( Some can
<samueldr>
yeah, exclusive "we" here
<eyJhb>
But yes. But how would you automate the revert of commit?
<samueldr>
in my description, there would be no revert to do
<samueldr>
we would lose master as it is
<samueldr>
(all hypotheticals)
<samueldr>
we don't have the tooling (e.g. github doesn't allow that outright)
<eyJhb>
Oh, I was thinking about your first solution. But yes, that could also work as well. Then you would commit security things directly to master, so that we get them quicker?
<samueldr>
but you wouldn't merge a PR to master, but rather approve a PR to get merged into master, and it would go through an hypothetical system where it'll be "tested", as in tested jobset, and only then would be merged into master
<samueldr>
you wouldn't get to commit to master for security fixes either
<samueldr>
but maybe a priority queue
<samueldr>
any fixes there are next to be tried-to-be-merged into master
<samueldr>
that would be my pitch for "let's get a team hired to fix the 'merging to master' problem"
<eyJhb>
Make a pitch for 'industriens fund', and they might give money :p
<samueldr>
I don't speak indistriens :)
<eyJhb>
Not sure where NixOS is on a scale from 0 to 10.000.000
<eyJhb>
D
<samueldr>
I also am tied up with wrangling phones at the time being
<eyJhb>
DKK, where 10.000.000 is anything security that can be used in the real world
<samueldr>
I am not privy to financials, so I really don't know
<eyJhb>
Hmm, maybe it could be looked into. I am not sure how such a deal/plan would work however
<samueldr>
first I guess there needs to be a plan to be conceived, right now it's all napkin-corner hpotheticals and quick thoughts :)
<samueldr>
that's the first time I've spoken about that still-forming idea
<eyJhb>
Yeah, but in general some more hands would be nice I assume
<eyJhb>
For now I might just run nixos-unstable-small
<eyJhb>
And see when my patience breaks
kalbasit has quit [Ping timeout: 240 seconds]
sgrunert has joined #nixos-dev
saschagrunert has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
<siraben>
Is it possible to create a distro from scratch (like in Linux From Scratch) but using Nix?
<siraben>
There's clever's not-os which is similar
<samueldr>
not-os might not be "from scratch" enough; it still uses Nixpkgs :)
<samueldr>
the answer is: yes, but there's a lot of work in there
<siraben>
Would doing Linux From Scratch using Nix be worthwhile? I haven't done it normally either.
<samueldr>
I don't know, I don't know if LFS is good actually
<samueldr>
it might be, but maybe things will get messy with Nix?
<siraben>
There's some areas of Linux I'm not so familiar with and so was quite confused when doing some of the cross compilation stuff, figuring out linking and so on.
<siraben>
Though maybe looking at operating systems texts would help
<samueldr>
btw, I really mean it when I say I don't know, but don't let that answer dissuade you from trying :)
<{^_^}>
nix-community/poetry2nix#205 (by Mic92, 1 week ago, open): Support source url type
orivej has quit [Ping timeout: 260 seconds]
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Max SendQ exceeded]
AlwaysLivid has joined #nixos-dev
alp has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
alp has joined #nixos-dev
<rajivr>
For nixpkgs, after a PR has "All Checks Passed" and approved by the maintainer, is there any additional step that we need to for it to get merged into master?
<rajivr>
"...that we need to do for it to get...
<qyliss>
rajivr: a committer needs to see it and be comfortable merging it
<rajivr>
Thanks qyliss. Do I have to manually add the PR into commit queue somewhere, or would the committer automatically review it when he/she gets to it?
<qyliss>
you don't need to do anything
<qyliss>
but it's also okay to post the PR in places and ask for committers to take a look
<qyliss>
because we unfortunately (fortunately?) get so many PRs it's difficult for committers to keep up with them
<rajivr>
I'll give it time. My hope is to have the package updated before master is forked for 21.03. Thanks again for all the great work you all do on NixOS. :-)
<qyliss>
Okay, well, feel free to draw attention to it if it's getting close and it seems like it's been missed :)
<etu>
rajivr: It's not uncommon that people link PR's in chats to have them merged faster, even among people with commit access to not "merge your own PR" to often.
orivej has quit [Ping timeout: 264 seconds]
justanotheruser has quit [Ping timeout: 260 seconds]