<ekleog>
globin: I don't think I'll have more time than you have :/ but thank you!
<samueldr>
I still stand by mostly "shouldn't change the API/ABI of Nixpkgs, updating packages should always be done, unless it's a breaking update"
<samueldr>
but that last bit "updating packages unless it's a breaking update" is hard to define
<globin>
samueldr: that's the reason I the distinction of supported vs maintained in above draft
<samueldr>
>> Patches are either specially crafted or patch releases are used. Patch releases from upstream thereby have to only include security fixes and minor bugfixes (e.g. linux kernel, python, openssl)
<samueldr>
the kernel might need a special case; it's already done that way, where non-lts versions are removed after EOL, and new versions are always added, with latest being the latest
<ekleog>
debian's definition of « breaking update » is « anything that's not a security update »
<ekleog>
(including most bugfixes afair)
<globin>
samueldr: I agree, adding new attributes is fine IMHO
<samueldr>
mainly because "linux_latest" from the release might be a version that's going to be EOL'd during the lifetime
<globin>
samueldr: well linux_latest already includes the caveat in its attribute name :)
<samueldr>
yeah, just noting because at one point it was regressed in a stable release and I got in touch with the maintainer that updates it to ensure it wouldn't happen :)
<samueldr>
(_latest EOL'd, it was reverted to the previous LTS)
<globin>
I'd actually only call the non-latest "supported" and the other "maintained" in a first iteration
<samueldr>
well, the default is already an LTS that should be supported for the duration of our release, so I think it's already kinda that way
<globin>
yes, sure, the RFC would want to make that clear with an extra meta attr :)
<ekleog>
I personally like debian's approach to stability (ie. “exactly the same thing, but with security fixes”), but it would require more eyes to dissect changelogs before our backports (in exchange for likely reducing the number of backports we actually do because most wouldn't fit into such a policy)
<ekleog>
which would be “supported packages” in the RFC draft, but even more restricted
<ekleog>
(I think it's the only way we could reasonably start to think of making LTS nixpkgs releases, because if we do the filtering of security fixes for releases, it should simplify a lot backporting to LTS)
drakonis has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-dev
drakonis1 has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
<adisbladis>
matthewbauer: Interesting... Though imho a graphical installer ALSO needs to come with a graphical package manager interface to make sense.. It dösn't make sense to just have a graphical installer and then require you to edit your configuration.nix by yourself anyway
<adisbladis>
Haha sorry for umlauts (my input mode in irc buffers maps oe -> ö)
<tilpner>
Ha, dösn't
<adisbladis>
Or maybe it does make sense to just help you get over the initial install?
<tilpner>
One one hand it could be a welcome convenience for people who've done it manually before
<adisbladis>
For sure a GUI installer is a great first step regardless
<tilpner>
But on the other, we might end up with a bunch of people who don't understand their config
<tilpner>
It does set the wrong expectations, but maybe it's necessary to break the chicken-and-egg problem
<adisbladis>
For sure
<adisbladis>
And at least for KDE we could also create a Discover (KDE gui package manager) backend
<tilpner>
I don't think DE-specific frontends are a good idea for now
<tilpner>
Oh, I got that wrong
<adisbladis>
tilpner: It's both a package manager for KDE-specific stuff _and_ have distro specific backends
<adisbladis>
Which IIRC are going through packagekit (same as gnome)
<adisbladis>
So that would be two stoned birds ;)
<tilpner>
I've been thinking about a graphical option editor a few times
<tilpner>
It should be Fairly Easy™ to implement, but it wouldn't create a config the user can take over
<tilpner>
It would offer a tree editor for primitive options, probably from options.json, and output a config.json
<tilpner>
Then the configuration.nix is just config = lib.importJSON ./config.json;
<tilpner>
But I'm not convinced that's helpful to the user, it just eliminates editing text files from the process, the rest is just as complicated
<tilpner>
It should be possible to generate Nix from that config.json too, but the output would still be ugly, even after stripping defaults
<adisbladis>
tilpner++
<{^_^}>
tilpner's karma got increased to 27
<adisbladis>
tilpner: I don't know if you looked at nixui?
<tilpner>
I'm aware of it, but I haven't used it
<adisbladis>
matthewbauer: What's the state of packagekit?
init_6 has joined #nixos-dev
srk has quit [Ping timeout: 258 seconds]
srk has joined #nixos-dev
Cale has quit [Ping timeout: 248 seconds]
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 258 seconds]
averell has quit [Quit: .]
drakonis has quit [Ping timeout: 258 seconds]
Cale has joined #nixos-dev
init_6 has quit []
<dtz>
didn't upstream ("the folks behind packagekit") write a post saying it's dead or something? FYI don't have anything against it at all (other than perhaps not wanting to use abandoned things unwittingly :P)
* dtz
isn't the person being asked and by all means carry on regardless, just passing along :)
<dtz>
(i actually rather like packagekit and secretly-but-not-really-because-im-saying-it-now hope it makes a comeback ;))
<adisbladis>
dtz: I feel a bit sad after reading that
<dtz>
I'm sincerely sorry, and I'm sad again reading the headline and remembering its content :/
<dtz>
although I suppose good for the author recognizing a sinking ship.... I usually just burrow into the ship further and add some infra to keep me onboard all the more securely :P :P
* dtz
gazes into the distance and sighs, ... "webos......"
<adisbladis>
dtz: :D
<adisbladis>
It was something I was really looking forward to in my quest to get plasma mobile on nixos
<adisbladis>
I guess it's still the right way to do things
<dtz>
:D I am inclined to agree :3
* dtz
has helped with 'discover' a bit previously
<dtz>
I wonder if there are any serious technical problems for lack of proper nix support, or if it's just in need of a sufficiently motivated hacker or two ^_^...
* dtz
echoes the earlier query about its status
drakonis has joined #nixos-dev
drakonis1 has quit [Ping timeout: 257 seconds]
justanotheruser has quit [Ping timeout: 255 seconds]
justanotheruser has joined #nixos-dev
averell has joined #nixos-dev
callahad7 has joined #nixos-dev
_rvl_ has joined #nixos-dev
asymmetric_ has joined #nixos-dev
page_ has joined #nixos-dev
v0|d has quit [*.net *.split]
_rvl has quit [*.net *.split]
asymmetric has quit [*.net *.split]
page has quit [*.net *.split]
callahad has quit [*.net *.split]
delroth has quit [*.net *.split]
octe has quit [*.net *.split]
asymmetric_ is now known as asymmetric
callahad7 is now known as callahad
tv has quit [*.net *.split]
LnL has quit [*.net *.split]
obadz has quit [*.net *.split]
makefu has quit [*.net *.split]
cransom has quit [*.net *.split]
page_ is now known as page
kgz has quit [Ping timeout: 268 seconds]
octe has joined #nixos-dev
obadz has joined #nixos-dev
makefu has joined #nixos-dev
tv has joined #nixos-dev
cransom has joined #nixos-dev
kgz has joined #nixos-dev
kgz has quit [Client Quit]
kragniz has joined #nixos-dev
kragniz is now known as kgz
Guest62963 has joined #nixos-dev
v0|d has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 258 seconds]
delroth has joined #nixos-dev
drakonis1 has quit [Ping timeout: 258 seconds]
drakonis_ has joined #nixos-dev
v0|d has quit [Remote host closed the connection]
drakonis has quit [Ping timeout: 250 seconds]
Jackneill has quit [Ping timeout: 248 seconds]
v0|d has joined #nixos-dev
Jackneill has joined #nixos-dev
<matthewbauer>
dtz: wow didn't know that!
<matthewbauer>
adisbladis: When I wrote the packagekit backend, it was pre Nix-2.0, so it used nix-env, which never really fit well with packagekit (20s load times, name vs. attr mismatch, etc.)
<matthewbauer>
adisbladis: I was hoping that `nix search` would improve the situation
<matthewbauer>
but that would be at least a partial rewrite of the backend
<matthewbauer>
dtz: it doesn't look like packagekit is completely abandoned quite yet
<matthewbauer>
dtz: it might still be worth getting to work. The biggest problem was that the APIs were not really designed for functional style package management
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
<thoughtpolice>
Urgh. Can I propose something: could we build linux-testing on Hydra? 5.2.0-rc1 is completely busted since it doesn't get CI'd, I'm sure someone just did an auto-update. The problem with -rc is that it of course linuxPackages often breaks. But perhaps we could only test the .kernel package, somehow?
<thoughtpolice>
I mean in theory my name is in the maintainer slot so I should know how to do this (and can figure it out) but I'm wondering if anyone has any disagreements. I think the kernel itself being built would be an obvious good even if many of the modules won't work just yet.
<gchristensen>
thoughtpolice: I have no objection to doing that
<gchristensen>
but it'd just build, and not block upgrad eright?
<thoughtpolice>
gchristensen: You mean the channel(s) getting updated?
<gchristensen>
yea
<thoughtpolice>
Do all kernel packages/etc currently block updates? Just curious I actually have no clue what the criteria for channel blockers are, or even *what* they are.
<gchristensen>
no, they don't, just clarifying your intend
<thoughtpolice>
No, it wouldn't be special or anything. Just a normal package tracked by Hydra/borg like any other
<niksnut>
not sure if testing kernels should be channel blockers though
<niksnut>
I mean, it's the risk of running a bleeding edge kernel :-)
<samueldr>
_testing has hydraPlatforms = [];
<samueldr>
with "Should the testing kernels ever be built on Hydra?" as a comment
<samueldr>
I think we can answer MichaelRaskin's question from 2014 and say yes, and remove that
<globin>
+1 on at least building them
<samueldr>
tangentially related, it was observed late last friday that nixos-stable only builds the subset required for `tested` to work on aarch64
<samueldr>
I had made a wrong assumption about how jobs worked for nixos and release-combined
<samueldr>
it wasn't obvious from unstable due to how nixpkgs builds the leftover aarch64 stuff
<samueldr>
I guess the resolution would be either to add a nixpkgs eval for 19.03 or an aarch64 jobset for nixos (though I don't think a separate channel would be required)
<gchristensen>
backstory: the old URL is busted, so 19.03 can't build this package anymore. I could just fix the URL in a new commit in 19.03, or backport the bump too
<globin>
gchristensen: I'd go for including the bump for minor packages like this
<samueldr>
it's a font, looks like it shouldn't cause any compatibility issue and most likely is a leaf package so seems fine to me
<gchristensen>
cool
Melkor333 has joined #nixos-dev
<Melkor333>
Is there a way to locally build kernel packages? "nix-build ./ -A nvidia_x11_legacy390" obviously doesnt work...
<globin>
Melkor333: this kind of question generally would preferably asked in #nixos as it doesn't concern nixpkgs/OS development itself, but you're looking for `NIXPKGS_ALLOW_UNFREE=1 nix-build -A linuxPackages.nvidia_x11_legacy390`
<Melkor333>
Thank you globin and sorry for posting in the wrong irc chat
<globin>
Melkor333: no problem at all :)
<Melkor333>
Problem is this nvidia package is actually broken (the patch doesn't work) and I thought I may be able to fix it.. But it seems harder than I thought :D