samueldr changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 19.09 is released! | | | 19.09 RMs: disasm, sphalerite |
<{^_^}> #75466 (by edef1c, 14 minutes ago, open): git: 2.24.0 -> 2.24.1
<{^_^}> #75469 (by edef1c, 6 minutes ago, open): git: 2.23.0 -> 2.23.1
<{^_^}> #75470 (by edef1c, 2 minutes ago, open): git: 2.19.2 -> 2.19.3
<edef> or, well, plurality of git vulns getting fixed
<edef> unsure who should be cc'd on security things, ping worldofpeace
<gchristensen> probably should merge these direct to master indeed
Synthetica has quit [Quit: Connection closed for inactivity]
<worldofpeace> edef: I believe this team is interested in security
<worldofpeace> and the release managers for sure
<gchristensen> I wish I could find CVSS scores for CVE-2019-1387
red[evilred] has joined #nixos-dev
<red[evilred]> nothing in nvd?
<gchristensen> not yet
<worldofpeace> edef: I'm not sure 19.03 gets patches anymore, manual states it would be EOL
<gchristensen> nvd often doesn't get updated for some time after a CVE is announced
<red[evilred]> if there's enough public information we can calculate it ourselves pretty easily
<gchristensen> doesn't seem to be a lot
<red[evilred]> looking
* gchristensen is still impressed by live streaming logs from ofborg
* samueldr can't believe nothing had to be changed since the initial implementation
<gchristensen> :x
<samueldr> looks like remote code exec relies on hooks
<gchristensen> hm
<gchristensen> seems unlikely to be exploited, but also not inclined to send it to staging
<edef> basically, i want to go to bed
<gchristensen> edef: I'm planning on merging once the darwin build finishes
__monty__ has quit [Quit: leaving]
<edef> you have an ack from me if you want to hit the big green button
<edef> i was assuming we support the last *two* stable releases
<edef> having only one supported release at any given time means it's impossible to be on only stable releases and always be covered
<edef> so if "only last stable" is our security policy, consider #75470 my dissent
<{^_^}> (by edef1c, 17 minutes ago, open): git: 2.19.2 -> 2.19.3
<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
<gchristensen> yikes, mind opening a bug report?
<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
<gchristensen> that gives me hearburn
drakonis has joined #nixos-dev
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
<jtojnar> worldofpeace yup
<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 🤣
<worldofpeace> creating for testing is testing,, and should never be a public interface
<jtojnar> worldofpeace perhaps it should be merged with xinit
<jtojnar> oh, we have start.nix, not xinit.nix and that is different
<Profpatsch> worldofpeace: great work on that login manager migration!
<Profpatsch> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 48
<worldofpeace> Profpatsch: Jan and Hedning wrote the code though :D
<Profpatsch> worldofpeace: I only see you pushing it, so big props for that
<worldofpeace> I've just given a lot of creative input and detailed designs
<worldofpeace> Profpatsch: Thanks ❤️
<Profpatsch> whoa, the heart displays in color unicode. What magic is this.
<clever> that also caught my eye
<clever> i happened to glance at the laptop, and there was a giant red heart on xfce-term
<clever> but in xterm, its a tiny heart in a dashed-line box
<Profpatsch> 🕴️
<clever> also, xfce-term renders the heart as double-width!
<clever> Profpatsch: but thats just an inverted ? on both machines
<Profpatsch> The Man In Business Suit Levitating emoji doesn’t display anything for me
<clever> lol
<Profpatsch> So it’s not a full unicode-emoji-set, that. If it’s double-width, it has to be some kind of terminal magic?
<Profpatsch> worldofpeace: Did you do anything special there?
<clever> i could see that causing problems with curses stuff, does irssi know how wide it is? on both terms
<clever> a❤️b
<clever> lol
<clever> Profpatsch: how does that render for you?
<Profpatsch> b is overlapping the heart :D
<clever> same on xfce-term, but not in xterm
<clever> so it both is and isnt double-width
<Profpatsch> smells like a hack
<clever> rendering wise, its double, but layout wise, its single
<clever> so it wont break curses stuff, that thinks its single!
<jtojnar> IIRC, ICU has the info about width
<jtojnar> and pango, which is used for font rendering by VTE uses that or something
<clever> jtojnar: except, different terminals are rendering it as being different widths!
<jtojnar> well, xterm does not use VTE/pango
<clever> jtojnar: but xfce-term feels like its doing a worse thing, rendering one glyph ontop of another
<jtojnar> hmm, apparently the width is neutral:
<jtojnar> but the emoji font uses wide image
orivej has quit [Ping timeout: 268 seconds]
<clever> [ 0.000000] Division by zero in kernel.
<clever> jtojnar: and i borked my kernel some more, lol
<jtojnar> rofl
<clever> jtojnar: i'm attempting to boot linux on an rpi, without start.elf
<__red__> that"
<__red__> that's impressivly borked
marek_ has joined #nixos-dev
<clever> [ 0.000000] arch_timer: cp15 timer(s) running at 0.00MHz (virt).
<clever> __red__: i think its failing to query the timer freq, then it divides by the timer freq
<worldofpeace> Profpatsch: Jan Tojnar and I got color emoji in as a default in 19.09
<Profpatsch> worldofpeace: Ah, cool. I love that this stuff just happens in the background and you get all the cool new features all the time :)
<Profpatsch> Especially on master
marek_ has quit [Ping timeout: 268 seconds]
phreedom has quit [Ping timeout: 260 seconds]
tilpner_ is now known as tilpner
<jtojnar> We should probably check how Fedora handles the a❤️b in GNOME Terminal and potentially report a bug against VTE or Pango
zarel_ has joined #nixos-dev
zarel has quit [Ping timeout: 268 seconds]
<yorick> jtojnar: these unicodes are impossible to deal with
<yorick> jtojnar: for text rendering to go right your terminal has to agree with tmux and mosh and weechat about the width
<yorick> it's 1 wide in my font
<yorick> I think the font decides the width here
teehemkay has quit []
teehemkay has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
marek has joined #nixos-dev
tazjin has quit []
tazjin has joined #nixos-dev
<jtojnar> Hmm Unicode does not like East Asian width being used for emoji
drakonis has joined #nixos-dev
<jtojnar> Monospace fonts should just die
<gchristensen> :o
<drakonis> itc: hot takes about fonts
<gchristensen> jtojnar: you're probably right
<jtojnar> Really, it is 21st century, editors and terminals should just support proportional fonts
<gchristensen> but my ascii table/box drawing characters
<drakonis> ascii art y'all
orivej has joined #nixos-dev
<jtojnar> Who needs ASCII art when we can make graphics using XML
<gchristensen> now you're speaking my language
* Taneb imagines an XML-based raster image format
<drakonis> terrifying
<drakonis> unless the metadata is in xml
<gchristensen> <image><![CDATA[...base64data...]]></image>
phreedom has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
ixxie has joined #nixos-dev
* worldofpeace uploaded an image: Screenshot from 2019-12-11 13.18.40.png (96KB) < >
<worldofpeace> it don't look right tho
<worldofpeace> I'd want code to read like prose, but it's not.
<infinisil> I can see the need for some Monad action!
<samueldr> 🌶️ with tabs-based indentation rather than space-based indentation the indentation could look just fine
<infinisil> Like in Haskell you could do `do { dm <- dms; vm <- vms; return DesktopEntry { .. } }`
<infinisil> Hehe
<gchristensen> ^ take a look at this message, interesting things in here.
<worldofpeace> infinisil: monads would uplift my spirit today 🕊️
<worldofpeace> gchristensen: wow
<gchristensen> yes
<infinisil> worldofpeace: Translating this to Nix:
<gchristensen> I wonder if we can make a PPA out of nix-built tools
<infinisil> worldofpeace: Which can be simplified to
<samueldr> gchristensen: can we build debs? (I think so) so it's likely yes
<samueldr> though we might not be able to strictly do a PPA in the sense of the mechanisms behind the canonical provided launchpad PPAs
<worldofpeace> infinisil you lift me up 😃
<gchristensen> samueldr: like they probably build on their infra or something?
<samueldr> oh, hadn't thought about that bit, but it's possible
<gchristensen> which part were you thinking?
<samueldr> being hosted at launchpad
<gchristensen> ah
georgyo_ has quit []
georgyo_ has joined #nixos-dev
georgyo_ has quit [Client Quit]
georgyo has joined #nixos-dev
<gchristensen> not sure we can do a "source-based" PPA
<gchristensen> but maybe if nix is allowed as a build input :P
<drakonis> what's the goal here?
<gchristensen> just wondering if we could supplement these disappearing PPAs as a service to our Debian friends
<drakonis> to be fair, our debian friends wouldnt recommend mixing ubuntu's PPAs with debian
<drakonis> i have a better idea instead
<gchristensen> s/Debian/Ubuntu/
<drakonis> now, our ubuntu friends would definitely appreciate that
<cransom> have them all move to nixos?
<drakonis> well, being able to set up a debian repository with nix
<drakonis> a module that spins up a build system that outputs binaries that work normally under debian and derivatives without requiring nix
<drakonis> i dont think they'd adapt to nixos's constraints
<gchristensen> i don't want them to
<gchristensen> I'd want to generate packages that feel generally normal
<drakonis> then that'd require some alterations to the build process
<jtojnar> Did not we already decide Qtʼs mkDerivation is a bad idea?
<jtojnar> Oh, still not merged
<{^_^}> #71089 (by ttuegel, 8 weeks ago, open): Qt: Do not require mkDerivation
<drakonis> the probably correct way to do things is to spin up a container for this
<drakonis> its what the other distros usually do for clean builds
<gchristensen> I'd want to use the same nix-produced builds we already have
<gchristensen> we couldn't replace all of those PPAs, but probably several of them could easily
<drakonis> but how would you have them run without nix?
<samueldr> nix-built artifacts generally don't require nix to run
<drakonis> arent they linked against the store?
<samueldr> yes, this can be "solved" by leaving the store paths the way they are
<samueldr> (though would conflict with nix use)
<gchristensen> yep, have the .deb include the /nix/store paths
<samueldr> gchristensen: could something be done with patchelf to replace all /nix/store/ to /ext/store to not conflict with store paths?
<gchristensen> oh yeah sure, that'd be cool
<drakonis> /opt/store?
<samueldr> if someone wanted to use nix in addition to nix-built non-nix-managed software
<samueldr> oh, yeah, /opt/ would reduce the gut instinct to respond with "but my FHS"
<drakonis> the default would be to chuck into /opt/nix/store but that would conflict with the path length restrictions
<gchristensen> /opt/nixst
<drakonis> also fine
<drakonis> that would be very fine actually.
<gchristensen> it is valuable to keep the prefix the same number of bytes
<samueldr> yeah, which is why I was thinking /ext/ initially
<drakonis> i'll take /opt/nixst as the path for the store on distribution packages
<gchristensen> one question is how does dpkg handle two packages providing the same (identical) path-on-disk
<drakonis> hmm, it complains
<cransom> 'flagrant system error. computer over.'
<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 vs 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]
orivej has joined #nixos-dev
__monty__ has quit [Quit: leaving]
orivej has quit [Ping timeout: 268 seconds]