<gchristensen>
we collectively make an effort to support 2 stable releases for 1 month after release, and after that leave it up to people intereted in keeping it alive to keep it alive
<edef>
ack. CVEs seem like a reasonable thing to cover post-release, tbh
<gchristensen>
sure
<edef>
like, post general EOL
<gchristensen>
but even just CVEs is quite a lot of work, which is why it is up to people interested in it to keep patching
<edef>
mm
<gchristensen>
so, definitelythank you for sending it to 19.03 too :)
drakonis has quit [Quit: WeeChat 2.6]
<edef>
anyway, i'm off to dreamland — g'night friends <3
<gchristensen>
good night edef, thank you for the PRs <3 :)
<gchristensen>
I wish my mac was better
<gchristensen>
anyone have 50k to buy the foundation a new mac pro? :)
<worldofpeace>
🦗
lassulus has joined #nixos-dev
<jtojnar>
worldofpeace giving it more thought, it is probably reasonable to not require setting defaultSession for autologin when there is only one session but we definitely should not abuse `default` options for that
<jtojnar>
though the fact that defaultSession only works single time in some DMs makes this murky
<jtojnar>
Will need to check if autologin really requires default session; is it unreasonable to want to autologin to last session?
<jtojnar>
Maybe adding `sessionData.autologinSession = defaultSession or head installedSessions or null` and switching DMs to that would work.
<jtojnar>
That would allow us to revert e79bb22f6533bec93d7a70e4b7a707dd3a758dd5 and 97a2d7e79e513292f9a958e241f5500c1f88f4f4
<worldofpeace>
Jan Tojnar: gdm doesn't even have a key to set the default session yet allows an autologin feature
<worldofpeace>
I honestly think it's bad ux
<worldofpeace>
if you autologin how do you even decide what session it is? Your system has to be configured with one session.
<worldofpeace>
So I'm not sure.
<jtojnar>
worldofpeace well it might be like profile manager in firefox (always using the last profile)
<worldofpeace>
Jan Tojnar: It's possible that sddm or lightdm require it though, will check. Because they actually have a config for the default session.
<jtojnar>
and if you want a different on, you log out / open profile manager
<worldofpeace>
I've honestly never used autologin so I'd have to play with it.
<jtojnar>
I should go to bed, it is tomorrow again
<worldofpeace>
Jan Tojnar: cool, I won't keep you.
<worldofpeace>
I'll followup on github if I find anything interesting
<jtojnar>
thank you for the help
<worldofpeace>
💖
<gchristensen>
maybe next time I suggest it, I'll open a discourse topic, but: stdenv bootstrapping should probably be all marked as big-parallel, and have a couple machines set at one job at a time with all cores dedicated to that one job, to blitz through bootstrapping as fast as possible, and expand the build tree as fast as possible
<clever>
gchristensen: maybe also use mandatoryFeatures
<clever>
gchristensen: if you dont, then non-big-parallel jobs can get allocated to it, and tie that 1 job up
<gchristensen>
yeah, seems smart
tilpner_ has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
<gchristensen>
I'd love to get rid of unionfs somehow in the nixos installer ISO, it seems to slow things down significantly
<samueldr>
is it unionfs or squashfs that slows things down?
<gchristensen>
furthehr testing needed, but iirc unionfs has high CPU usage
<samueldr>
though, it's unionfs-fuse, which maybe is a part of the slowdowns?
<samueldr>
I wonder why it's unionfs-fuse and not a unionfs/overlayfs that's in the kernel
<gchristensen>
great question
<samueldr>
(it may be causing issues with cross-compiled isos)
<samueldr>
(the current unionfs-fuse)
<gchristensen>
:D
<yorick>
niksnut: hey, I love the rust, but please pull-request it so we can have some people who know about rust look int it
<yorick>
into*
<yorick>
the tarfile thing introduces some crashes and security issues, for example
<yorick>
the security issue is that there are no path checks and tars can contain ../../ or even absolute paths that are being extracted as root
<yorick>
I was working on changing this out to libarchive, actually, since it can extract everything (except brotil)
<yorick>
brotli*
<yorick>
my branch has .nar.zstd support :D
<gchristensen>
probably should specifically open a bug report for the issues, separate from the code review
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<yorick>
gchristensen: nobody expected that code to be merged with all the fixme's and UB's intact
<yorick>
imho it should be unmerged
<gchristensen>
I'm not sure if you're agreeing an issue should be raised, or if you're disagreeing and saying that the code review which was left after the PR merged should be sufficient?
<yorick>
gchristensen: I submitted a pull-request which fixes the direct issues but not the rust FFI in general
<yorick>
more stuff depending on the rust FFI was just merged, though
drakonis has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 276 seconds]
<pie__>
might not been in the kernel yet when first used? <samueldr> I wonder why it's unionfs-fuse and not a unionfs/overlayfs that's in the kernel
<pie__>
idk the timeline at all, just a wild guess
orivej has joined #nixos-dev
Jackneill has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
FRidh has quit [Ping timeout: 265 seconds]
psyanticy has joined #nixos-dev
__monty__ has joined #nixos-dev
orivej has joined #nixos-dev
__Sander__ has joined #nixos-dev
<jtojnar>
worldofpeace yeah, the terminology is wonky
<worldofpeace>
Jan Tojnar: So I think, a user should be able to force which session is default in nixos config. Should there be an option just for autoLogin, idk.
ckauhaus has joined #nixos-dev
<jtojnar>
worldofpeace IMHO, the main difference is that defaultSession should have default = null, whereas autologin.session should `default = defaultSession || head installedSessions`
<jtojnar>
we do not need a separate option for that since the fallback can be used in situ
<jtojnar>
I prefer to use different qualifiers, rather than dropping the qualifier for the more common option
<jtojnar>
though maybe initial and default are not that semantically apart and better descriptors should be chosen
<worldofpeace>
ahh I see what you're saying. Initializing null is fine without an autologin. But with autologin, a default must have a valid value.
<worldofpeace>
There's an autologin-session in lightdm?
<jtojnar>
worldofpeace even worse, we need to support null to allow history
<worldofpeace>
This doesn't have history in lightdm right Jan Tojnar ?
<jtojnar>
maybe weakDefaultSession and strongDefaultSession will be less ambiguous
<jtojnar>
worldofpeace what do you mean?
<worldofpeace>
I set autologin-session, logout, it reaches the greeter and I login in to a different session. If I restart will it be initialized with the value of autologin-session?
<jtojnar>
worldofpeace I would not expect it to
<jtojnar>
but did not test
<worldofpeace>
Jan Tojnar: I think I might check, I did play with autologin when I did my research
<jtojnar>
I would expect strong and weak default session to be simply a minor UX thing
<worldofpeace>
Hmm, rethinking your purposed option. They do make sense
<jtojnar>
though re-using the NixOS option makes sense, since the uses of strong and autologin are mutually exclusive
<jtojnar>
(unless autologins are not saved to history at all)
<worldofpeace>
Jan Tojnar: I played with lightdm
<worldofpeace>
I did check before and autologin works that you can logout and select a different session (both lightdm, gdm, and sddm)
<worldofpeace>
I removed setting user-session in lightdm
<worldofpeace>
It logs into the specifed session automatic, but when you logout lightdm session chooser is just history in accountsservice.
<worldofpeace>
So I think we can expect autologin.session to be described as the session to autologin to for specifed users. and always.
<jtojnar>
what happens if you clean the history?
<jtojnar>
or manually relog to a different session?
<jtojnar>
worldofpeace I presume by **always** you mean the same thing I call strongDefault
<worldofpeace>
Yep. I tested and it doesn't care what AccountsService has.
<worldofpeace>
If I restart it logs into the session in autologin-session
FRidh has joined #nixos-dev
<jtojnar>
worldofpeace yeah, I would expect that, but what does it also reset the session chooser in every greeter session, or is it only updated from AccountService history
<worldofpeace>
The session chooser is always information the list of sessions. The greeter picks head if accountsservice knows none, or what accountsservice knows.
<worldofpeace>
So this tells me autologin is a separate operating feature
<jtojnar>
I think we would be fine with just dropping defaultSession altogeher
<jtojnar>
and implement autologin session per DM
<jtojnar>
it appears that it has been there from the start but with no obvious purpose
<jtojnar>
worldofpeace having single option combining defaultSession and autologin.session would be convenient but it feels too much like a SRP violation
<worldofpeace>
argh, this puts us in an even more confusing situation for migration because it didn't make sense in the first place
<worldofpeace>
I'm not sure what users might've thought one thing was for, but it probably was only useful for autologin
<worldofpeace>
So yeah, I think you can drop this weird global default/defaultSession and just have code paths useful for autologin.
<worldofpeace>
I should be able to bake in the autoLogin.session feature later for gdm and strongSession
<worldofpeace>
jtojnar++
<{^_^}>
jtojnar's karma got increased to 20
<jtojnar>
I guess it is kind of useful for tests, but that ties in to auto.nix you mentioned
<worldofpeace>
yeah, I don't use this word frequently but I think that module is stupid 🤣
<drakonis>
you cant actually overwrite a file managed by another package
<gchristensen>
replace the first bytes of the store path with the PPA name :P
<samueldr>
gchristensen: package each store path independently and make them requirements
<samueldr>
you get deduplication of shared dependencies that way
<gchristensen>
yeah that could be
<gchristensen>
thaht might be a Thrilling way to go about it
<gchristensen>
gosh this sounds like the best april fools joke
<samueldr>
and we have strong guarantees that a store path is isolated from another thing's store path
<jtojnar>
I vote /opt/nixed
<drakonis>
you'd have to automate writing package definitions here tho
<drakonis>
for managing the hellscape
<gchristensen>
well that settles that, jtojnar
<drakonis>
how do you handle package namespace conflicts?
<drakonis>
do you throw in the hash in the name of the package?
<gchristensen>
what does that mean?
<gchristensen>
oh absolutely yes
<drakonis>
you'll have to throw it after the name
<samueldr>
name the packages "nixed-${normalizedAttributeName}"
<drakonis>
yes that
<drakonis>
otherwise bash completion would be hell
<gchristensen>
I'm imagining a debian package repository which is dynamically generated by something like nix-serve
<drakonis>
other details to observe here is that you also have to handle package migration
<drakonis>
nixed-${packagename}-${hash} is probably a terrible idea
marek has quit [Ping timeout: 252 seconds]
<gchristensen>
the hash is necessarily part of the package name
<drakonis>
dpkg has a field for replacing packages
marek has joined #nixos-dev
<drakonis>
debian does some really awkward things like doing package versioning with the name of the package itself
<drakonis>
let me see if i can find a good example here
<gchristensen>
right but it doesn't matter
<gchristensen>
because nixed-hello doesn't depend on the idea of nixed-glibc, it depends on exactlny nixed-glibc-hash-of-the-expected-store-path
<gchristensen>
there could be conveniently named metapackages which point to the hash-named packages
<drakonis>
yes i was going to suggest that
<drakonis>
because debian doesnt work like that
<gchristensen>
what do you mean?
<gchristensen>
and actually the metapackage is probably critical for putting `bin` stubs in to the PATH
<drakonis>
i mean that debian has poor dependency handling
<gchristensen>
right :)
<drakonis>
transitioning packages is pretty bad
<drakonis>
imagine this particular situation
<drakonis>
you have a dozen users with a package that has a hash that changes frequently, roughly once a week, half of that updates monthly, half that updates like clockwork, how will you get the older version on the definition to be removed when you upgrade the metapackage?
<drakonis>
will you track the previous 8 hashes on the definition?
<gchristensen>
I think the older packages will be no longer "selected" and apt has autoremove support?
<drakonis>
autoremove only applies to orphaned automatically installed dependencies
<gchristensen>
right
<gchristensen>
I'm not understanding the problem you're proposing I guess
<samueldr>
:( I don't think I'm doing something wrong, though it looks like rust's nixpkgs ecosystem is not ready for cross-compilation
<samueldr>
anyone have info about this, like is there an issue tracking or a PR tracking that?
<drakonis>
i'm griping about dpkg's package definitions
<drakonis>
about generating them.
<drakonis>
if you use metapackages, it is a non issue unless the user actually installs a package with a specific hash
<gchristensen>
btw I don't know if dpkg has something called a metapackage, I invented that term for my own use here
<drakonis>
it doesnt
<drakonis>
it is done by adding dependencies to specific packages
<drakonis>
its ugly and generating something that allows a semi nix-like experience is the problem at hand
<drakonis>
look at emacs-common at the field breaks
<drakonis>
there's another package that offers a similar situation where a significant amount of packages have to be migrated to the new one
<drakonis>
the problem i was complaining is that you have someone who hasnt updated in a while that cannot go forward because the next step no longer exists
<drakonis>
and a metapackage would have to remember how many steps of the chain if the user runs a older pinned version
<drakonis>
dont let me stop you though
kreisys has quit [Read error: No route to host]
psyanticy has quit [Quit: Connection closed for inactivity]
ixxie has quit [Ping timeout: 268 seconds]
<andi->
do we have a preference between builtins.foo vs lib.foo in nixpkgs? I am tempted to use `lib` because that looks more consistent
<samueldr>
IIRC lib will also have future builtins implemented
<samueldr>
well, it happened in the past
<infinisil>
+1 for lib
<infinisil>
Although, I also like the idea of builtins getting more of lib
<andi->
yeah, builtins getting "better" is nice but for Nixpkgs I think using `lib` for compat is the way to go (for now?!)
marek has quit [Ping timeout: 268 seconds]
ckauhaus has quit [Quit: WeeChat 2.6]
drakonis has quit [Ping timeout: 265 seconds]
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
orivej has quit [Remote host closed the connection]