<{^_^}>
#68339 (by FRidh, 1 hour ago, open): Staging next with systemd 243
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
Taneb has joined #nixos-dev
__monty__ has joined #nixos-dev
orivej has joined #nixos-dev
psyanticy has joined #nixos-dev
NinjaTrappeur has quit [Quit: WeeChat 2.5]
NinjaTrappeur has joined #nixos-dev
<worldofpeace>
infinisil: I did a review on that PR after reading that 😄
<worldofpeace>
no idea what was going on with the indentation there though :D
<FRidh>
infinisil: worldofpeace: it's improving and a lot of effort has gone in it already. To me this seems like a good example of a service that could be outside of nixpkgs though. Just look at the python deps it has.
<FRidh>
especially the overrides
<worldofpeace>
Yeah I do understand that. In no means undercrediting the author, they seem to be very responsive to changes which is a good thing.
<worldofpeace>
Problem with directing people how to make a service outside of nixpkgs is there's no really clear way to do that. So most people attempt to make a submission to nixpkgs
<worldofpeace>
(though I wonder what the ❄️ will make that look like)
<aminechikhaoui>
Hey all, should we look at https://github.com/NixOS/nixpkgs/pull/61974 again since the release is getting close, I'd like to see that merged to drive more improvements to vulnix :)
<{^_^}>
#61974 (by AmineChikhaoui, 15 weeks ago, open): RFC: introduce a patches file in <pkg>/nix-support/
<niksnut>
aminechikhaoui: IMHO you should use nix-store -qd instead
<niksnut>
replicating (part of) the dependency graph in the output in an ad hoc way is not the way to go IMHO
<aminechikhaoui>
niksnut the issue is that derivations aren't always available especially when store paths are substituted from a binary cache
<niksnut>
well, that's your problem right there :-)
justanotheruser has quit [Ping timeout: 244 seconds]
<aminechikhaoui>
is it ? :) I don't think derivations should be assumed to be present in a server
<niksnut>
well, if you want to inspect the build-time dependency graph, you have to make sure it doesn't get GC'ed
<infinisil>
worldofpeace: NUR does support nixos modules
<{^_^}>
#57123 (by oxij, 26 weeks ago, open): Typed `nixpkgs.config` married to NixOS
<niksnut>
I have no idea whatsoever what this is supposed to do
<niksnut>
though I did learn from it that Nixpkgs now has a "mkMassRebuild" function, whatever the hell that means
<niksnut>
we should have an embargo on changes to the module system
<niksnut>
or nixpkgs/lib in general
<worldofpeace>
infinisil: NUR != nix ?
<infinisil>
worldofpeace: I mean that people can use NUR to make a service outside of nixpkgs, while still publishing it for others
<infinisil>
(not sure what you're asking with NUR != nix)
<worldofpeace>
niksnut: Don't you think it's unreasonable to prohibit changes? How about redirection to what's being worked on internally, so as to avoid conflicts with that work?
<infinisil>
niksnut: Ah regarding that PR
<infinisil>
The basic idea is really what the title says, but oxij has included some more weird parts
<infinisil>
And part of the changes were committed directly to master from a previous PR.. like the mkMassRebuild thing
<infinisil>
Which I'm not a fan of at all (the fact that it was committed to master)
<worldofpeace>
infinisil: Yeah NUR is an option and is already useful. I was meaning that, user wise, the path to do this shouldn't just be nixpkgs, and NUR functionality isn't within nix
<qyliss>
The one linked above is not one I would read, going by the subject, but one about looking for people to help with ZHF would be
<ddima>
disasm: whats usually the time it takes for hydra to do a full build? right now all of the tasks in the linked jobset are just queued, so just want to know when its worth checking back.
evanjs- has joined #nixos-dev
<disasm>
ddima: probably a dayish?
<qyliss>
does that mean it's too early to be able to easily find packages to fix?
<samueldr>
qyliss: in theory the last unstable eval applies
<ddima>
disasm: thanks
<qyliss>
ah, course
<samueldr>
oh, I just remembered I have that script to make reports for ZHF
<worldofpeace>
samueldr: was a quick hack. wasn't looking for merge so quickly
<worldofpeace>
samueldr: My thing was, what do you do when you change a default that people rely on, and get them to migrate to explicitly using xterm.enable
<samueldr>
yeah, worldofpeace, not trying to slap you :) looking in discussing this, I was hopeful others would hcime in
<samueldr>
since, exactly, I'm not sure what's the best way to transition
<srhb>
The easiest way would probably be a deprecation cycle with a rename of the xterm option.
<worldofpeace>
so currently people expect xserver.enable to do the same as xterm.enable
<samueldr>
could it be a trace on having only the xterm de/wm enabled urging the user to migrate to enabling something?
<srhb>
Yes, though we need the (explicit, non-default) xsession alternative first. :)
<adisbladis>
worldofpeace: Can I PM you?
<worldofpeace>
adisbladis: always welcome :)
<samueldr>
that something would likely be the xsession-based alternative lightly theorized
<srhb>
Sounds good to me.
justanotheruser has joined #nixos-dev
aristid has joined #nixos-dev
<adisbladis>
Oh this was just what I wanted to PM worldofpeace about :)
<adisbladis>
I was suggesting we create an `xsession` that does pretty much what `xterm` does now
<adisbladis>
Except by default it will show you a message saying that you need to create ~/.xsession
<FRidh2>
we currently still depend on python2 when building some core packages. We should get rid of that dependency and I have a PR for that, though it doesn't cover darwin. It's a bit late, but I do not expect any regressions because of it https://github.com/NixOS/nixpkgs/pull/63174
<{^_^}>
#63174 (by FRidh, 12 weeks ago, open): libxml2 and libxslt: build against python3 by default
<drakonis>
the image is downloading so slowly its causing me physical pain
aristid has quit [Quit: WeeChat 2.5]
aristid has joined #nixos-dev
<drakonis>
okay, that was not a good idea.
<drakonis>
its going to take anhour to finish
ixxie has quit [Ping timeout: 244 seconds]
<samueldr>
you could also nix-build it locally
<samueldr>
it should be quicker
<samueldr>
or uh
<samueldr>
even better
<samueldr>
nix-store --realise it
<samueldr>
the reason it's slow AFAIUI is that when you download through hydra it goes through the one hydra server instance rather than give you a cdn download location
<globin>
disasm, samueldr: would nonetheless be nice to have a working script in maintainers/scripts
<disasm>
samueldr: primarily, the biggest benefit I think to globin script in the repo is it pings the maintainers for broken packages.
<samueldr>
right, that's what I gathered from the quick overview
<disasm>
globin: yeah, I'll get it fixed and maybe get it added to CI :)
<samueldr>
worldofpeace: do you know if my assumption is right: the session a user selects in lightdm (and other DMs?) is saved under .dmrc to be re-used
<samueldr>
if so, would the spurious issues with accidentally getting in the xterm session come from .dmrc having a session not being currently active?
<worldofpeace>
samueldr: Not since I've added that patch to lightdm that ended that impurity :P But a similar thing happens with accountsservice just with dbus
<samueldr>
what does your patch does?
<samueldr>
(a correct answer could be linking to the PR/commit/file)
<samueldr>
I'm curious if it breaks the two users using different sessions use case
<samueldr>
(only speculating at very high level, I have no reason to think it would)
<worldofpeace>
Though I expect any lightdm greeter to discard sessions that don't exist anymore
<worldofpeace>
including ones that were previously used
<samueldr>
if I understand right, there's still one mechanism to save the user's session statefully, right?
<samueldr>
yeah, I expect it, too, to discard sessions, but which one would it fallback to? that's my thinking
<worldofpeace>
The issue I mentioned with the new upstream sessions is that session.default has no value, so maybe because xterm is/was default it gets selected
<worldofpeace>
samueldr: I'm not sure if I've seen any other distro have a feature like this, it's interesting
<samueldr>
we are in an interesting position though
drakonis has joined #nixos-dev
<jtojnar>
worldofpeace: did we want to do any changes to the GNOME docs before merging it?
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
drakonis has quit [Ping timeout: 246 seconds]
<worldofpeace>
jtojnar: Think we had some other todos. Personally I think time for docs might run a bit thin soon so we should probably just merge and backport it