worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ | | | 20.09 RMs: worldofpeace, jonringer |
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
dongcarl1 is now known as dongcarl
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
ris has quit [Ping timeout: 258 seconds]
teto has quit [Ping timeout: 260 seconds]
stoile has quit [Ping timeout: 240 seconds]
stoile has joined #nixos-dev
kalbasit has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 260 seconds]
AlwaysLivid has quit [Ping timeout: 264 seconds]
AlwaysLivid has joined #nixos-dev
supersandro2000 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
<ivan> heh, if you add yourself to maintainers in the PR it gets tagged as 'by: package-maintainer'
<{^_^}> #103654 (by ivan, 3 hours ago, open): b3sum: 0.3.4 -> 0.3.7
<V> that seems like an oversight
<Mic92> niksnut: we need at least one person for the rfc meeting to have the majority of shepherds in the meeting:
<Mic92> niksnut: (you are also in the shepherd team for this RFC).
FRidh has joined #nixos-dev
FRidh has quit [Ping timeout: 272 seconds]
FRidh has joined #nixos-dev
jonringer has quit [Ping timeout: 264 seconds]
cole-h has quit [Ping timeout: 240 seconds]
alp has joined #nixos-dev
teto has joined #nixos-dev
saschagrunert has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
Gaelan has quit [Quit: ZNC 1.8.1 -]
Gaelan has joined #nixos-dev
orivej has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
alp has quit [Ping timeout: 260 seconds]
alp has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
<mkaito-> is there a separate channel for nix development?
mkaito- is now known as mkaito
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
<mkaito> we're running into some freezing issues on nix master that I'd like to debug, and I've got some trouble getting `nix develop` to compile nix at all. I don't know where I should bring this up.
rajivr has joined #nixos-dev
<mkaito> yes, I did.
<yorick> so what happens?
<mkaito> wish I could reproduce, but nix shell refuses to eval :P
<yorick> does nix develop refuse to eval as well?
<mkaito> but basically, I would get into the dev shell, bootstrap, configure, make, and then get a million glibc errors
<yorick> hm
<mkaito> yeah, it just gets stuck at some point and does nothing
<mkaito> yesterday it was on a .drv for lowdown, today it's brotli. yesterday it would get stuck acquiring a file lock, today it gets the lock and THEN gets stuck
<mkaito> I'm running fs checks just in case
<mkaito> once it gets stuck, I have to SIGKILL the nix-daemon, and then collect the entire store, or nothing works.
<mkaito> well, nothing that would touch the store anyway
<mkaito> oh well, gotta get ready for a wedding, guess I'll try again on monday with more patience.
utsl has quit [Quit: Textual IRC Client:]
<domenkozar[m]> mkaito: make sure to upgrade on recent Nix master
<domenkozar[m]> as some of these bugs were fixed
<siraben> Ericson2314: not quite sure how to proceed with the PR, how would I override the dynamic linker?
<siraben> It's quite tempting just to go ahead and tell Nix to use the prebuilt GCC instead of building one from source.
FRidh has quit [Ping timeout: 260 seconds]
costrouc has quit [Quit: costrouc]
<JJJollyjim> hmm, i'm pretty sure in the past, nixos-run-vms in a test driver would pop up interactive qemu windows, but that's not happening for me
<JJJollyjim> has that behaviour changed? i can't find anything in the file histories im checknig
<JJJollyjim> *checking
<JJJollyjim> ah it's driverInteractive now
<hexa-> JJJollyjim: how is try #7? :)
<JJJollyjim> ugh
<JJJollyjim> i can't remember
<JJJollyjim> and i don't want to
<JJJollyjim> i see what happened to the other 6 now
<hexa-> hehe
alp has quit [Ping timeout: 272 seconds]
kalbasit has joined #nixos-dev
cole-h has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
costrouc has joined #nixos-dev
<raboof> it seems building `python38Packages.pytest-testmon` on the `staging` branch currently fails. is that something I should report somewhere?
<raboof> (of course ideally I'd fix it myself, but I must admit I haven't figured out how to run the tests in nix-shell yet :) )
<hexa-> from a git checkout of the staging tree, run `nix-build -A python3Packages.pytest-testmon`
<hexa-> the tests are likely from the checkPhase
<raboof> hmm, looks like the test expectations indeed don't match with the implementation. weird thing is I do see the tests in the pypi tarball, but not in the sources in
jonringer has joined #nixos-dev
<Ericson2314> siraben: did you see what the other person linked in bintools-wrapper?
<Ericson2314> You add a new case in that big if-else chain
<abathur> does anyone have a sense of how safe/unsafe it is to run the last few store-modifying steps of a Nix install (installing nix itself, running nix-store --load-db, setting up/updating a channel, dealing with SSL certs, etc.) on an existing store installed with a previous installer version?
<siraben> Ericson2314: Yeah I tried that and added a new case like "${rmToolchain}/lib/" but it failed
<Ericson2314> siraben: what did it fail with?
<siraben> Erm, garbage collected now. I'll replicate it tomorrow and post on the PR.
alp has joined #nixos-dev
<Ericson2314> siraben: ok, thanks
rajivr has quit [Quit: Connection closed for inactivity]
__monty__ has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
<mkaito> domenkozar[m]: thanks for the tip; I'm running nix master from yesterday evening, actually.
ris has joined #nixos-dev
saschagrunert has quit [Quit: Leaving]
orivej has joined #nixos-dev
alp has joined #nixos-dev
leungbk has joined #nixos-dev
MichaelRaskin has joined #nixos-dev
<JJJollyjim> anyone able to review?
<{^_^}> #103704 (by JJJollyjim, 5 hours ago, open): vte-ng: update patches to apply on vte 0.62
<__red__> Oh - thank you for doing thta
<__red__> that package has been broken for me for a while
<JJJollyjim> a while = 3-4 days right?
<__red__> longer for me
<__red__> I think
<__red__> I would need to check
<__red__> one of the patches would fail to apply HUNK failure
<__red__> lemme check my logs, sec
<__red__> [root@evil:/home/red/projects]# nix-build nixpkgs -A vte
<__red__> /nix/store/1yvpilgmdm7lxrhcyjvb1x80n7qv0ypq-vte-0.62.1
<__red__> that comes down from cache
<__red__> but when I build it as a dependency - it fails
<__red__> eg:
<__red__> nix-build nixpkgs -A termite
<__red__> I've not dug into why to be honest
<__red__> okay - now I want to know and I'm going to hunt it down
<__red__> brb
<JJJollyjim> yeah termite has patches
<JJJollyjim> as in my PR
<JJJollyjim> they call it vte-ng upstream
<JJJollyjim> we've been applying the same patches from vte-ng 0.56, which have cleanly applied up until vte 0.62 was released
<__red__> but the version that came down shouldn't have changed - so why is it failing
<JJJollyjim> hm?
<JJJollyjim> someone update vte
<JJJollyjim> *updated
<JJJollyjim> we don't package vte-ng, we package vte and override it with the patches that make up vte-ng
<__red__> oh - now I see it
<__red__> lemme look at your PR
<__red__> sounds like you unraveled this altready
leungbk has quit [Remote host closed the connection]
leungbk` has joined #nixos-dev
cole-h has quit [Ping timeout: 260 seconds]
<jonringer> If anyone participated with the 20.09 release (ZHF or otherwise) please join, I'm hosting the retrospecitve meeting
<gchristensen> <3 jonringer
<{^_^}> jonringer's karma got increased to 15
<aanderse> free karma to anyone who joins
* gchristensen prepares a scary patch
<abathur> anyone have a sense of how safe/unsafe it is to run the last few steps of a Nix install (installing nix itself, running nix-store --load-db, setting up/updating a channel, dealing with SSL certs, etc.) on an existing store installed with a previous installer version? (this is already possible for single-user installs, and possible on master for multi-user; multi-user on 2.3.x still blocks it
<LnL> I would _definitively_ backup the db if you don't want to start your store from scratch
<LnL> but given that you restore the db I think it's pretty safe in principle, as long as you make sure not to trigger a gc
zarel has quit [Ping timeout: 272 seconds]
zarel has joined #nixos-dev
<ryantm> @jonringer is going to be submitting some RFCs for modifying the release process. I'm trying to proactively gather an candidate RFC shepherd team for the steering committee to approve. Is anyone interested in volunteering to help shepherd?
<jonringer> ryantm++
<{^_^}> ryantm's karma got increased to 26
<__red__> btw, "red" is fine, I just didn't want to derail the convo. Only my wife when she's pissed at me calls me by my full name :-)
<ryantm> Two of the RFCs he wants to make are 1. move release back 2 months 2. add branchoff period of 2 weeks where staging can't be merged into staging-next
<ryantm> or forward 2 months might be more appropriate*
<MichaelRaskin> ryantm: it's like UTC±2, just call it «later»
<gchristensen> why move the release 2mo?
<gchristensen> actually, I can wait for the RFC :)
<MichaelRaskin> Short answer: because GNOME
<ryantm> MichaelRaskin: Yes, thank you. 2 months later.
<gchristensen> cool
<jonringer> gchristensen: I already did an initial write-up here:
<jonringer> 2mo will allow for a better window in which desktop managers will be "in a good shape" on master
<jonringer> removing a lot of work with having the latest of everything, but older desktop managers
<jonringer> especially with how coupled both gnome and plasma are to systemd
<gchristensen> I'm really happy to see you put forth these proposals!
<jonringer> thanks!
<__red__> So - I was asked in a PR to reformat some of my propagatedBuildInputs and they gave some syntax
<__red__> I'm guessing I'm doing it wrong due to the type errors
<__red__> Can someoen please tell me what I'm doing wrong?
<__red__> Maybe I have to append that array to the other array
<__red__> (I'm quoting the whole thing so I don't XY problem it)
<LnL> [ python3.withPackages (p: ...) ] is a list of 2 functions
<jonringer> yea, you need parenthesis around the entire python3.withPackages expression
<__red__> Thank you
<__red__> I really need to better understand nixexpr
<__red__> I should re-read the docs
<__red__> it's like I instictively knew wha the issue was - just didn't know how to approach it
<jonringer> I have a video for doing python packaging in nix
<jonringer> don't remember if I cover withPackages though
<abathur> LnL re: "as long as you make sure not to trigger a gc" -- during the process, or is installing over going to nuke the gc-roots?
<LnL> I wouldn't expect it to mess with gcroots, but if you nuke the the db no paths are valid anymore which also triggers deletion
<abathur> oh, between nuking and restoring the db
<gchristensen> speaking of gnome, should merge?
<{^_^}> nixos-homepage#643 (by grahamc, 1 day ago, open): Revert "Revert "NixOS Download: recommend GNOME""
<LnL> yeah, I'm not sure there's much value to doing that tho
<abathur> I guess what I'm trying to fumble towards is whether install-over has unsafe parts and is a bit of a misfeature (unless those parts are skipped for reinstalls)
<LnL> ah, well the single user install can be used to upgrade so that doesn't drop the existing db
<abathur> so in nix#3128 one of the changes was to make it so multi-user reinstalls weren't blocked from reinstalling as well
<{^_^}> (by matthewbauer, 1 year ago, merged): Don't symlink org.nixos.nix-daemon.plist in installer
<abathur> that commit isn't in master, not quite sure if it's intentional or not yet
<abathur> er
<abathur> is in master, not in 2.3.x
__monty__ has quit [Quit: leaving]
<LnL> thought you where doing an actual uninstall, but not that making a backup hurts :)
bridge[evilred] has quit [Remote host closed the connection]
bridge[evilred] has joined #nixos-dev
<abathur> well, a few targets; I've been trying to square darwin volume updates with various possibilities and edge-cases here with a "curing" process that can currently ~undo the darwin-specific parts (and I think these bits naturally extend into a general uninstaller once other components have the same treatment), but I was assuming we'd already been living with reinstallable multi-user
<LnL> importing the store paths should be idempotent already, the conditions revolve more around making sure an old daemon isn't still running, etc.
<abathur> my general curing approach for the volume itself is prompting them to delete it (and requiring sudo as confirmation)
<LnL> upgrading the daemon by running the installer again isn't a thing currently AFAIK
<abathur> but the edge case of trying to "upgrade" old volume configs is a little different; the simple way to do it is to say: if you want to upgrade, you'll have to start a fresh store
<abathur> but I'm not sure that's actually useful to people with existing stores
<LnL> I think upgrading would definitively be valuable
<abathur> so if it lets those specific users keep their volume with an intact store, it needs to not break it
<LnL> but the implementation could be to uninstall and retrace all the steps except for the data itself
<abathur> that's basically how the curing step currently works--revert everything to roughly-clean state and then run the installer as normal
<jonringer> gchristensen: I'm fine with merging 643
<abathur> "everything" is a misnomer here; it's just the synthetic.conf, fstab, volume, keychain, and mounting daemon--but I'm imagining a next phase where curing and --uninstall the same routine, and every install would attempt to uninstall ~everything before trying to install it (in place of the current validate_assumptions steps that just blow up and tell you to fix it)
<abathur> *where curing and --uninstall _are_ the same routine
<abathur> LnL so in that next phase, expanding to cover everything, the daemon would get removed at the curing step
<abathur> in fact I've already got the statement to do that for macOS, but part of my reason for saying that's a next step is that it needs poly support on the Linux side as well
<LnL> yeah, that's what I also had in mind, with the exception that uninstall would ask to delete the actual data at the end
<abathur> by data, are you talking about all of /nix? config contents?
<abathur> (the way my curing step for darwin *currently* works it actually will nuke the whole Nix volume)
<abathur> but I'm fumbling with what it should do about people on existing macOS installs who might be inconvenienced by having to rebuild their full store
<LnL> I mean the volume or /nix directory depending on the context
kalbasit has quit [Ping timeout: 256 seconds]
<abathur> oh, I think I mis-understood you
<abathur> you mean curing == uninstall without deleting /nix
<abathur> yeah?
<LnL> yeah, so that part ends with only and unmounted volume as the remaining thing
<abathur> I'm mostly deleting it because of the complexity of the darwin setup; wiping it (it asks for a password) means we can create a known volume, encryption credential, keychain entry, fstab, synthetic.conf, launchdaemon mounter that embeds a reference to the volume UUID
<abathur> rather than have to try and triage a lot of annoying edge cases where each of those components could be set up incorrectly
<LnL> right, but all of those can get deleted/disabled and recreated afterwards
<abathur> they can, but for example we have to do a dance if they keep an encrypted volume to know whether we've got a good credential for it
<abathur> so we have to go find the credential, and dismount+lock it, and then try to use their keychain credential to unlock and mount it
<abathur> and then, of course, we can't delete that credential
<LnL> yeah, except for the encryption passphrase which is kind of a problem in general I feel like
<abathur> but if we couldn't find a credential then we have to make them give us one (or then, finally, tell them they can't continue without letting us delete the volume)
<LnL> that works but only if it came from the user initially no?
<abathur> so my tack has been to burn it to the ground and start fresh, and make an env for excluding all of this
<abathur> depends on the setup I guess; if we just assume we made the volume, if we can't find the credential then they've presumably deleted it or reset the keychain or something
<abathur> or moved/accessed the drive from another system if it is external
<abathur> but yeah, the other components are easy enough to delete and re-write
<abathur> I guess it could let them keep the volume (if installing over it is pretty safe) as long as it *can* find the credential readily