<sphalerite>
Taneb: it'll get transitively marked as insecure when 1.0.x reaches EOL, and if nobody cares about it we can remove it at some point I guess
<Taneb>
That works for me
<sphalerite>
https://github.com/NixOS/nixpkgs/pull/70618 could I get a review for this to unblock all the full-size channels? I'll merge it myself if whoever reviews can't :)
<gchristensen>
it would be cool if someone designed an algorithm to estimate how many Packet machines we needed based on the current Hydra queue. preferably using data which can be queried from the Prometheus API. anyone interested in taking this on?
<gchristensen>
two reasons this is interesting: (a) reduce waste electricity consumption, (b) be good users of Packet's generous contribution
<samueldr>
I feel that this kind of issue may need a "build time factor" number, something informa, statistically the amount of time it takes in a generation compared to a known baseline build (that would stay 1)
<samueldr>
though this is something that could be useful even outside just hydra
<samueldr>
"how long will it take to build?"
<samueldr>
you could in theory build that baseline program, and then estimate for any given hardware
<samueldr>
ballpark estimates, that's for sure
<niksnut>
is it too late to restore sane coredump behavior in 19.09? (i.e. no systemd coredump madness)
<niksnut>
we explicitly disabled that stuff in the past
<samueldr>
disasm, sphalerite ^
<samueldr>
and, andi-, I know you're involved with systemd stuff, if you can ping other relevant people
<andi->
flokli: ^ you were pushing for that.
<gchristensen>
what makes it not sane, niksnut?
<niksnut>
it's very developer unfriendly
<flokli>
niksnut: a single sysctl config option is needed to restore the old behaviour, and documented in the release notes.
<niksnut>
it requires you to hunt down the coredump in /var/lib/systemd/coredump, figure out how to decompress lz4, etc.
<samueldr>
wouldn't you use coredumpctl?
<globin>
niksnut: coredumpctl debug -1 should do the job?
<andi->
Yeah, nix run gdb -c coredumpctl debug -1
<niksnut>
that's the sort of thing I'd prefer not to have to figure out
<niksnut>
it's a step back from "gdb command ./core"
<samueldr>
that's good I figure for something you ran in your shell, but if something started in your X session dumps core, having it centralized seems better to me
<samueldr>
or a service
<flokli>
niksnut: you can still get the basic coredump file if you set kernel.core_pattern. or just spawn gdb with the latest core file via coredumpctl debug.
<niksnut>
anyway why was systemd.coredump.enable removed? that was a lot more convenient than setting boot.kernel.sysctl."kernel.core_pattern"
<gchristensen>
+1
<flokli>
Because systemd provided sysctl snippets in $out that configures coredump per default, and we just apply those defaults.
<flokli>
The separate coredump module became somewhat obsolete, as soon as we started applying all those snippets
<niksnut>
sure, but we can still map systemd.coredump.enable = false to boot.kernel.sysctl."kernel.core_pattern" = "core"
<flokli>
Yes, that's something one could do. I'm just not sure if it's worth to add if it's just a 1:1 mapping to another option...
<infinisil>
flokli: Yes, discoverability
<infinisil>
And backwards compatibility
ris has joined #nixos-dev
<Profpatsch>
why do you have to string-index into this anyway
<Profpatsch>
why is it not mapped to nix values
<infinisil>
Profpatsch: Probably just not considered at the time
<worldofpeace>
flokli: I actually think that kind of option mapping is suggested in the nixpkgs manual for backwards compat
<worldofpeace>
also thanks again for that pr, it's truely confusing to some who switch distros and they're like "where's coredumpctl, this weird os"
<niksnut>
with "weird" you mean the default behaviour for the last 40 years or so :p
<worldofpeace>
lol, systemd was this weird thing and it seems people eventually got used to it
<qyliss>
depends how you look at it
<qyliss>
you could equally say "people eventually gave up resisting it"
<{^_^}>
#70202 (by alyssais, 5 days ago, open): [19.09] linux: drop non-LTS versioned kernel attributes
<qyliss>
I think it would be a shame if we didn't figure this out before release
<gchristensen>
When a non-LTS kernel is released, linux_latest is updated to be that kernel, but no attribute for that kernel is added. <- I don't understand this
<qyliss>
It means that `linux_latest = callPackage` directly, rather than `linux_5_5 = callPackage`, `linux_latest = linux_5_5`
<gchristensen>
that makes for surprising inconsistencies in override behavior
<qyliss>
it does?
<qyliss>
The thing that I'm confused about here is, I'm pretty sure we discussed this already
<gchristensen>
yeah. right now, you can't override linux_latest and have the kernelPackages be overridden. you have to override linux_x_y
<qyliss>
but I'm not sure if I misunderstood the outcome of that conversation?
<qyliss>
oh really? even though we use pkgs., rather than relying on rec?
<niksnut>
I think it's better to have a versioned attributed (i.e. linuxPackages_latest = linuxPackages_5_3) because then people who pinned a specific version will get an error message when it's removed
<gchristensen>
1+1
<niksnut>
which is better than silently being upgraded to another version
<gchristensen>
+1*
<qyliss>
but surely by using that attribute they've asked to be on "latest linux"?
<niksnut>
not if they asked to be on linuxPackages_5_3
<qyliss>
Do you think we should be letting people on stable pin unstable kernels?
<gchristensen>
but still being able to do linuxPackages_x_y and then get the error is a good thing
<qyliss>
That aren't supported for the lifetime of the relesae?
<gchristensen>
even if it disappears
<samueldr>
letting them pint to specific x_y makes it so both unstable and stable nixos use the same abstractions over kernel releases
<samueldr>
sorry for not circling back to the PR; been putting a lot of work in prepping stuff for my talk :(
<qyliss>
Okay then, let me ask the same question in a different way -- should we revert ekleog's paragraph in the manual that says we _should_ be doing what my PR does?
<qyliss>
because as it stands, the manual says we should be doing something that we're not actually doing
<samueldr>
and I think the pragmatic point here is that cherry-picks from unstable can stay untouched wrt kernel upgrades
<qyliss>
(that manual paragraph is linked in the PR)
<samueldr>
I don't know whether the example should just be dropped, or in addition, linux kernel releases singled out as an exception
<samueldr>
though maybe what needs to be done, rathe than singling out an exception, is document the way the kernel upgrades are backported
<qyliss>
gchristensen: does that mean you've changed your mind since you said we shouldn't be dropping kernels from stable in that discussion I linked?
<gchristensen>
I'm extremely torn :P
<gchristensen>
the only thing I feel good about is we shouldn't be keeping old and unsupported kernels in stable.
<qyliss>
It's frustrating to me, because we added that manual paragraph specifically because of kernel upgrades
<qyliss>
specifically kernel upgrades
<qyliss>
I'm not sure what the point of stable is if we're willing to drop attributes from it
<qyliss>
That doesn't feel at all stable to me
<gchristensen>
I think I generally agree with that, too, and under that, non-LTS kernels should be dropped
<gchristensen>
s/I think//
<qyliss>
I think we at least all agree that:
<qyliss>
- we should have a linux_latest in stable
<qyliss>
- we shouldn't package unsupported kernels in stable
<qyliss>
is that correct?
<gchristensen>
yeah
<niksnut>
I'm not sure about the first part
<gchristensen>
oh cool to know that
<qyliss>
niksnut: people want that for hardware support
<niksnut>
because the version of linux_latest can change during the lifetime of a NixOS release, then it's incompatible with stability
<gchristensen>
maybe lts kernels could be _lts_
<niksnut>
*because if
<niksnut>
maybe attributes like linux_latest should be feature-gated rust-style
<niksnut>
so you can't have them on a stable channel
<niksnut>
(unless you set some magic flag that everybody ends up using...)
<gchristensen>
:D
<qyliss>
niksnut: so people who need linux_latest would have to use unstable?
<qyliss>
or set a flag?
<samueldr>
we need linux_latest, we also need the iso for linux_latest, aarch64 sorely needs it, and even x86_64, new devices when lts is more than 6 months old we've seen the need for it
<samueldr>
though yeah, I understand how it's not stable, for at least one definition of stable
<qyliss>
"Don't break userspace" is some form of stability
<gchristensen>
hm
<qyliss>
in theory, at least.
<qyliss>
If we don't even agree on whether we should have a linux_latest, that might explain why it's been so difficult for me to understand this discussion
<qyliss>
and we probably need to resolve that first
<niksnut>
I mean, I'm fine with linux_latest where "latest" mean "latest at the time of release"
<gchristensen>
the "should we have a linux_latest?" is two things in one: should we have very new kernels? should we have a generic/mutable alias to it?
<niksnut>
but we can't just switch linux_latest from 5.3 to 5.4 on a stable branch
<samueldr>
latest at the time of release is probably going to EOL in the 1-2 months following the release date
<qyliss>
yeah, we can't have that. it would be a security nightmare.
<samueldr>
we've been upgrading _latest to the actual latest on the stable branch for a while, even before I started getting involved with NixOS
<samueldr>
there are derogations with stable and backports already
<samueldr>
things like browsers
<samueldr>
or should we keep firefox at 68?
<gchristensen>
maybe a linux_lts_latest, and a linux_mainline?
<samueldr>
the "linux" attrname is already lts_latest
<qyliss>
isn't linux_lts_latest just "linux"
<niksnut>
to be honest I don't think it would be a security nightmare. the important of kernel security is overrated
<gchristensen>
:o
<niksnut>
your system doesn't suddenly become insecure because the kernel is EOL
<niksnut>
I mean, your average router has a kernel from 10 years ago...
<qyliss>
and your average router is woefully insecure
<qyliss>
I'm sure shodan has plenty of examples
<niksnut>
but probably more because the shitty PHP web interface than the kernel
<qyliss>
An EOL kernel means you're just waiting for a critical security issue, and as soon as one comes out, you're out of luck.
<samueldr>
while it's true that EOL != insecure, just like best before != poison, I wouldn't prescribe the continued use of EOL'd kernel in a stable version
<niksnut>
how many remote root exploits are there in practice?
<qyliss>
remote root isn't the only security issue
<qyliss>
DoSes happen all the time
<samueldr>
those fancy instruction set leakage mitigations
<qyliss>
yeah, keeping your kernel up to date can even mostly save you from hardare vulnerabilities
<gchristensen>
I really don't want to make the question "are old kernels are okay?"
<samueldr>
gchristensen: s/old/EOL'd/ ?
<qyliss>
gchristensen: it seems like there's disagreement on that though
<gchristensen>
well... ya, but I don't want it to be that question :P
<qyliss>
i don't know how we can hope to move beyond that if we don't come to agreement
<samueldr>
old wouldn't be the right term, since _latest being stuck at a newer EOL would mean linux(_lts) is older
<qyliss>
It's pretty clear that we're at least not going to come to an agreement before 19.09
<qyliss>
so I shall close the PR
<gchristensen>
I'm not so sure that is true
<qyliss>
I also think we should revert the manual, since there's no point in a manual that encourages the opposite of current practice
<qyliss>
you think we can figure this out?
<gchristensen>
when else are we going to figure it out, if not now? :)
<qyliss>
I'm not hopeful we'll be able to figure it out ever, tbh
<qyliss>
But I'm certainly happy to try
<gchristensen>
yikes
<qyliss>
We've kept uncovering ever more fundamental layers of disagreement so far
<gchristensen>
yeah, we're making good progress!
<qyliss>
doesn't feel that way to me, but I shall trust your on that
<niksnut>
actually, let me take back some of what I said
<niksnut>
about that we shouldn't change what version _latest points to on a stable branch
<niksnut>
because the name "_latest" sufficiently conveys to the user that they're inherently asking for it
<niksnut>
so it's their own responsibility if things break
<qyliss>
makes sense to me
<gchristensen>
+1
<samueldr>
+1
<gchristensen>
I think being able to use more recent kernels is good for users. I think somehow conveying that "hey, these are not LTS and could disappear tomorrow" may be an important part of that
<samueldr>
I just want to restate my view on this, I fin the current approach is alright, though no strong feeling about it; my main concern is maybe the practicality of backports
<qyliss>
I'll do the same -- I don't think the current approach is alright, because I don't think it's clear to people that, despite using stable, they're opting into using an attribute that could disappear tomorrow
<qyliss>
apart from that I think we're doing good
<qyliss>
gchristensen, niksnut: want to restate your current thoughts?
<gchristensen>
I think I did :)
<qyliss>
okay, cool
<gchristensen>
niksnut: ^
<samueldr>
maybe we should ask the one doing the backportS (NeQuissimus) about the practicality of backports if they can't be wholesale simply cherry-picked?
<qyliss>
is NeQuissimus on Freenode?
<samueldr>
I don't think so
<gchristensen>
not often, anymore
<gchristensen>
I thin kcan be via email
<qyliss>
but also, we might be able to come up with a solution that doesn't make backports difficult
<{^_^}>
#70202 (by alyssais, 5 days ago, open): [19.09] linux: drop non-LTS versioned kernel attributes
<niksnut>
unless it makes backporting very hard
<niksnut>
but I don't really see why that would be the case
<samueldr>
I guess it depends how automated it is
<qyliss>
so am I right in thinking the only outstanding issue is whether this change would make backports difficult?
<samueldr>
NeQuissimus has been extremely responsive on GitHub, so asking on the PR is likely the better way
<gchristensen>
okay
<samueldr>
I may be overthinking it, but the way I see it is that in all-packages.nix, the changes wouldn't apply cleanly
<gchristensen>
I'm not too attached to the weirdness around overriding kernels. it is already super weird.
<qyliss>
While we're talking about it here, I'd like to make sure that backporting is the only issue people foresee, to reduce the liklihood that the PR gets stuck again
<samueldr>
imagine the introduction if linuxPackages_5_5 on master, new line, and linuxPackages_latest changed to point to linuxPackages_5_4 attrname
<qyliss>
So, does anybody see any *non-backporting-related* concerns with my PR?
<niksnut>
samueldr: only the initial commit that adds the new version wouldn't apply cleanly right?
<niksnut>
minor updates would apply cleanly
<samueldr>
niksnut: I guess so, you're right
<samueldr>
as I said, might be overthinking it
<niksnut>
qyliss: no
<samueldr>
I personally don't have concerns about it, as long as _latest is still a thing
<qyliss>
okay
<samueldr>
though overriding will become weirder, it's *already* hecking weird
<samueldr>
so I guess what would work better is fixing overriding the aliases on master
<qyliss>
then let's ask NQ to what extent this would make backports more difficult, and go from there
<samueldr>
+1
<qyliss>
Does someone else want to ask that? I'm not signed into GitHub on this machine, but more importantly I'm wary that it probably looks to people not on IRC that it's just me pushing for this
<emily>
dropping 5.2 while zfs still doesn't support it would be unfortunate
<emily>
er, doesn't support 5.3
<qyliss>
I think there should be a linux_latest_zfs
<samueldr>
it already would have happened with the current way of doing things
<qyliss>
But also what samueldr says
<qyliss>
This is just about whether 19.09 _ever_ gets versions that will be dropped at some point in the first place
<qyliss>
So I think zfs is a seperate issue
<samueldr>
I'll ask @NeQuissimus
<qyliss>
thank you samueldr
<qyliss>
gchristensen: thank you for encouraging me not to just give up
<gchristensen>
:)
<qyliss>
you were right :)
<aminechikhaoui>
gchristensen for president !
<qyliss>
i wouldn't wish that on poor gchristensen
<qyliss>
gchristensen++, though
<{^_^}>
gchristensen's karma got increased to 157
tilpner has quit [Remote host closed the connection]
<aminechikhaoui>
:D
tilpner has joined #nixos-dev
<emily>
fair enough, agreed re _latest_zfs
<samueldr>
asked; also re-requested review from NeQuissimus just in case
<qyliss>
samueldr++ too for handling asking and stuff
<{^_^}>
samueldr's karma got increased to 121
<gchristensen>
emily: I know I've mentioned it before and you're maybe not the right person, but I think it would be really cool to help upstream ZoL support new kernels more quickly.
<gchristensen>
(if they're interested in that, even)
psyanticy has quit [Quit: Connection closed for inactivity]
<{^_^}>
#70202 (by alyssais, 5 days ago, open): [19.09] linux: drop non-LTS versioned kernel attributes
drakonis has joined #nixos-dev
<qyliss>
I'll do it!
<qyliss>
hehe, conflicts
<qyliss>
there we go :)
Synthetica has quit [Quit: Connection closed for inactivity]
<qyliss>
Might be of interest to people here: a reply I just sent to an upstream I've been asking lots of questions to as part of creating a NixOS module. They expressed mild concern at a NixOS module fragmenting their ecosystem and making it more difficult for non-NixOS users to support NixOS users, and I did my best to put their fears to rest.
<qyliss>
It's email archival software with a twist, basically
<qyliss>
I've been writing a module for the past couple of weeks because I want Spectrum to be a shining example of a decentralised, email driven development workflow done right :)
<qyliss>
I'm going to have public-inbox for the mailing list pros, and hyperkitty for people who are either new to it or just don't really like email and would prefer a nice web gui
<qyliss>
I like it so much more than Discourse, and it has way better email interop to boot.
<edef>
so i'm looking at an option that *should* probably be aware that it contains comma-separated values
<edef>
and i'm not really sure what our policy is around those
<edef>
there's separatedString, there's making it a listOf with an either wrapped around it, etc
<edef>
i feel like we should have a clear answer for this
<qyliss>
I like to just go for listOf, no either
<edef>
well, this is services.xserver.xkbOptions
<edef>
which already exists
<edef>
so there has to be backcompat
<edef>
in general we're kind of lacking official, in-repo guidance on what our desired patterns are for stuff like this
<qyliss>
Although if you have no way of escaping commas a list is maye a bit misleading
<qyliss>
so i guess i don't really have strong feelings
<edef>
we've got the language-specific infrastructure documentation for nixpkgs, but the NixOS docs are more about using the modules that exist than about our style
<qyliss>
What do you think we should do here?
<edef>
types.str is definitely the wrong choice for this option, since it has a fairly clear merge strategy
<qyliss>
is order significant?
<edef>
separatedString "," is definitely valid, but feels a little dirty. my own configs would definitely use `opt = lib.concatStringsSep "," [ ... ]` to set it
<gchristensen>
maybe you can validate that none of the entries contain a ,
<qyliss>
what about an either, but with a warning for not using a list? + what gchristensen said
<edef>
that's reasonable, though i'd have to add a split to handle old-style entries
<qyliss>
then at some point we could drop the either
<edef>
yeah, the warning was definitely intended
<edef>
and yeah, i'd like to deprecate the non-list use
<edef>
i'm not sure whether it has meaningful ordering
<qyliss>
would be interesting, although we don't (to my knowledge) have a good way to handle it if it does
<edef>
but all of this is specific to this one case, and while searching in-tree i found a variety of patterns for handling this kind of thing
<edef>
so i'm pondering how to make it clearer, perhaps have a library function targeted at this fairly common case
<edef>
i've seen the whole "turn single string into listOf" happen a few times, we always want the same things
<edef>
we always want to deprecate for a release cycle (we could probably use a clear pattern for this)
<qyliss>
I'm not sure what we could reasonably do here, other than maybe have some vague-ish documentation
<qyliss>
A common function would be hard, because it would have to support stuff like validating not having commas
<qyliss>
and would be another thing to learn
<edef>
validating not having separators is common, i think
<qyliss>
i'm not sure the abstraction would be useful
<edef>
but some prose is useful here, at minimum
<qyliss>
+1 to prose
<qyliss>
Actually, that RFC might be useful
<qyliss>
one sec
<edef>
i don't think there's more than like, half a dozen different cases even combinatorially
<edef>
heh, glad to have an RFCologist at my disposal
* qyliss
notmuch search rfc config
<edef>
i should really keep up with RFCs better but github's email format for it indeed isn't great
<qyliss>
Even just reading the initial proposed text would help you a lot with this sort of thing
<qyliss>
But yes, GitHub is a terrible platform for RFC discussion
<edef>
"i want to add an option for $thing, what are the ways i could expose this" feels like a general thing
<qyliss>
That's a bit too specific to be directly applicable here, but the spirit behnid it is good
<edef>
yeah, it is
<qyliss>
Specifically, that configuration should be an structured as possible
<edef>
at some level i feel i could fill a book with NixOS patterns
<qyliss>
please do
<edef>
and .. idk, maybe i should just start writing that
<edef>
i could spend weeks just documenting all the patterns that exist already
<qyliss>
but for bonus points, put it in the manual
<edef>
and i bet i'd find several that do roughly the same thing
* gchristensen
'd help with manual-ification
<edef>
fwiw, as usual anything that involves "commit a huge amount of time myself" is kind of tricky for me to actually pull off, but fleshing out what would be useful to do if i could seems worthwhile
<edef>
and yeah, infinisil's RFC seems worthwhile
cjpbirkbeck has joined #nixos-dev
<infinisil>
:D
ixxie has quit [Ping timeout: 252 seconds]
<edef>
also, wildly unrelated: i started building the nixpkgs manual as part of my system (because it's useful), but now i get every lib.* deprecation warning
<edef>
because it walks those attrs
<edef>
kind of wish we'd have a "deprecate" thing that returns a functor you can easily inspect so the manual can skip them
<edef>
yet another unrelated thought: we have /etc/profiles/per-user, but the pattern seems more generally useful (i'm currently wanting to enable a systemd user service for one specific user)
<qyliss>
edef: have you seen what my XDG_CONFIG_HOME is set to?
<gchristensen>
environment.etc."NetworkManager/system-connections".source = "/rpool/persist/etc/NetworkManager/system-connections/"; is the only bit of persistence that I keep
<edef>
heh
<edef>
i think i might pick up some of those things