<mbakke>g_bor: Yes, I think we can merge it to staging. <rain1>i couldn't get guixsd installed <rain1>guix system init has an weird error, so i tried guix pull but it faile <mbowcutt>Any ideas or known reason why running guix commands sends a SIGPOLL and disconnects the user session? <brendyn>I discovered that the issue with file managers showing all the system mounts disappears when I run the program with dbus-launch. It also fixes my problem where evince doesn't remember the last page I was on for documents <efraim>Interesting, would be nice to make it permanently like that <g_bor[m]>Does shepherd have anything like systemd daemon reexec? <efraim>looks like my fdroidserver package depends on python-pyqt, which makes `guix size fdroidserver' more than 2GB <civodul>yay xorg can rotate my screen again \\o/ <g_bor[m]>civodul: Do we have something like systemd daemon-reexec in shepherd? <efraim>i love `guix gc -C 1', cleans up old lock and build files <civodul>g_bor[m]: what is it, something to start a different executable? <g_bor[m]>civodul: Actually it reexecs systemd itself, so that after a library upgrade you don't need to restart your system. <civodul>but you can run arbitrary code in shepherd :-) <jonsger>nice, one can now just install guix on SLES15 from repos (only 2 additional required) :) <rekado>g_bor[m]: this looks familiar somehow. <rekado>snape: we don’t currently check for non-deterministic outputs, but I think we *should* have that feature in the future. <snape>but the amount of extra work would be *huge* <snape>maybe it's current-work x 10000 <snape>we would need to build every package at each evaluation <snape>I agree it would be nice, but it seems unrealistic, even in the long term <civodul>rekado: note that we could run "guix-daemon --rounds=42", that's all it would take :-) <snape>maybe "guix-daemon --rounds=2" would be nice, and Cuirass would display non-deterministic builds as "failing", which is cool <efraim>rekado: we lost power yesterday apparently, overdrive2 is back up and reachable <civodul>snape: i'm afraid we'd have core packages failing <snape>civodul: and thus they would be built at each evaluation, which is annoying. Got it. <brendarn>lightdm fails to build for some mysterious reason <brendarn>seems like (which "false") or (which "nologin) is returning #f <mbakke>Ooh, I've managed to build Python 3.7 reproducibly :) <civodul>brendarn: it was "nologin", good catch! i can push a fix if you want <brendarn>civodul: sure, i was going to add shadow as in input but it's easier if you do it. I'm not 100% sure if it /needs/ those binaries or it just needs to know where they are to hide them <brendarn>it creates a hidden-shells variable out of them <brendarn>if so then it may only need to be a native-input <civodul>brendarn: yeah 'nologin' is only in shadow now <civodul>brendarn: apparently it refers to nologin in its code, so it should remain in 'inputs' ***einarelen_ is now known as einarelen
<brendarn>civodul: it does so in constructing a default hidden_shells variable <brendarn>not quite sure what it means but i assumed it mean it was going to hide those binaries or something like that <civodul>rekado: do you have a link to a page illustrating conda's policy wrt. keeping old package versions? <nyberg>guix pull seems to fetch the 0.14.0 release of guix packages rather than latest. Have already switched back to a 0.15.0 commit, just found it rather odd. <civodul>nyberg: by default 'guix pull' fetches the latest commit on 'master' <civodul>what makes you think it did something else? <nyberg>everything rolled back to 0.14.0 <civodul>nyberg: could you copy/paste the command and its output? <civodul>hmm looks like (ana)conda keeps old binaries, but not old "recipes" <vagrantc>maybe $PATH doesn't contain the guix that is being built <civodul>right, that could be the explanation, nyberg ↑ <civodul>you need to have ~/.config/guix/current/bin in $PATH <nyberg>Seems to have been caused by naive use of guix package --search-paths <rekado>civodul: I don’t know if they even have an official policy. <rekado>this is for bioconda, which provides bioinfo packages. <rekado>they update recipes but keep old binaries. <civodul>thanks, that was my understanding too <civodul>so it's not different from what we do, after all <civodul>except that it's maybe easier to get an older binary <rekado>civodul: one of my colleagues told me that it would be nice to make it easier to install known-to-exist old builds in the store. <rekado>currently, you need to know the full store path, but even after doing “guix package -i /gnu/store/…” the resulting package sticks out. <rekado>it does not behave like other packages in the profile in that its name and version info seem to be lost. <civodul>it sticks out as in it's badly integrated? <civodul>normally the name and version info are inferred, unless there's a bug <civodul>but all we can do is infer that info, so it could get it wrong <rekado>it’s also inconvenient to have to know the store path. <rekado>so, it would be sweet to record the state of Guix and associate store paths with old versions of Guix. <rekado>one could then install old versions given a known store path. <civodul>i would hope for 'guix pull' & co. to become convenient enough that this is not necessary <rekado>guix pull does quite a bit of that already <brendarn>That's one thing i've wondered about guix with regards to reprocible builds in science. If someone builds an environment in guix in 2018, then i try to reproduce it in 2020, i'm actually going to make an updated version of the environment, if possible, unless they archive a tarball of all the binaries they had and I have a way of instatiating it. <mbakke>rekado: I think the main problem with the original 'rebuild bytecode' phase was that you forgot to set PYTHONHASHSEED! <jlicht>brendarn: you would need to use the same guix commit in that case <brendarn>jlicht: which makes me wonder if we can produce some way of getting back to that old commit <rekado>civodul: is this your handwriting? <jlicht>brendarn: guix pull --commit=... might work in that case <civodul>rekado: who knows! i can tell it's my hand-inkscaping ;-) <mbakke>I built all the way to pytest with --rounds=2, no problem! <civodul>mbakke: congrats on that one, really cool! <mbakke>Thanks! Rekado did most of the work, I just fixed a bug and updated to 3.7 (which definitely helped) :-) <jonsger>civodul: nice blog post, nice features :) <rekado>the “inferior guix” feature is very cool <pkill9>nice i didn't consider doing this as in the blog post: ~/.config/guix/current-10-link/bin/guix package -i gimp <pkill9>i had that idea, of installing older versions of packages by doing a guix pull with the commit they were on <pkill9>but didn't consider you could just run the `guix` inside them, idk <civodul>i realized transactions were underrated, and 'guix pull' remained mysterious and/or frowned upon to many <civodul>i can't wait to listen to your talk! <civodul>it's awesome to get feedback from an experienced DD <rekado>“guix pull” has become super cool, and I’m always a bit sad when I read of people who want to avoid it. <rain1>Any thoughts on using activity pub to replace the gpg keyserver infrastructure? <vagrantc>civodul: hope it goes well, thanks for your interest! :) <civodul>dustyweb would prolly suggest taking it as an opportunity to discuss ways to provide a Debian package of Guix ;-) <civodul>regardless it's great if we can create bridges, socially speaking <vagrantc>i'll mention the relevent bug reports :) <brendarn>What's the next step for guix pull then? Better performance? <vagrantc>during debcamp people have started asking me questions ... i appear to have become the debian community expert on guix :) <civodul>and you're probably our local Debian expert as well :-) <civodul>rekado: a colleague of mine who i won't name kept saying bad things about 'guix pull', and yesterday i manage to get them to say that it's rather cool :-) <civodul>brendarn: yeah performance, and better integration <jonsger>pkill9: it was slow and computing itensive <civodul>tbh it's still slow and computing intensive, but substitutes mitigate that <civodul>it used to have other deficiencies on top of that <mbakke>I wonder if we can get Guile 2.2.5 before the next Big Rebuild. WDYT civodul? :-) <mbakke>Was that GC thread safety issue fixed yet? <brendarn>I hope one day I can contribute to guix it's self instead of just packages <civodul>mbakke: several big issues were fixed in 2.2.4; there's no big fix currently in stable-2.2. <vagrantc>dustyweb: it's still mostly vapourware :) <dustyweb>the new guix pull is indeed really great btw <dustyweb>I still think having it so that we generate Guix packages for Debian is important and would increase adoption! <dustyweb>I also wish we could get Guix packaged in Debian itself without fights over /gnu/ breaking out <pkill9>they reject guix because it uses the /gnu directory? <jonsger>couldn't it use something like /var/gnu or /usr/gnu? <efraim>I'm not too suprised by a rejection over that <jlicht>could we not work around that with the proot trick? <dustyweb>pkill9: it violates the "filesystem heirarchy standard" <dustyweb>jonsger: if we rename to or /opt/gnu we could maybe do it but there are two problems <dustyweb>1) you won't be able to use the same derivations <dustyweb>so the current infrastructure for substitutes won't work <pkill9>i think everything inside guix would have to be also run inside a proot to work <vagrantc>dustyweb: i mentioned the FHS issue with /gnu/ to one of the debian-policy maintainers and the response was "we could probably just add another exception for it" <vagrantc>my scheme isn't great, but i'm happy to help :) <dustyweb>so there's a big win on Debian's side for getting Guix in Debian <dustyweb>and that's the current nightmare of language package managers <dustyweb>where everyone just gives up and shoves things in Docker <dustyweb>this is bad for reproducibility, bad for debian, bad for guix <vagrantc>though /opt/gnu would definitely be better ... <dustyweb>but... if people used "guix environment" for their development environments when working on Debian <vagrantc>yup, big part of my interest is the language-specific or domain-specific package managers <dustyweb>that would result in code that was much easier to package in Debian <dustyweb>vagrantc: great, glad to hear we're thinking along the same lines :) <brendarn>why do we have /gnu/store anyway instead of just /store. will there ever be any other directories in /gnu? <pkill9>nix uses /nix/store, might have been a followup from that <pkill9>although i would have expected it to use /guix/store <dustyweb>pkill9: Guix was envisioned to be the embodiment of the "GNU OS", and hence /gnu/ IIRC <dustyweb>though RMS didn't let us use the distro names we wanted after all ;) <jlicht>what other names were considered, dustyweb? <dustyweb>oh, maybe I shouldn't be stirring up trouble :) <vagrantc>if there would be any consideration of changing everything, i'd change things to /opt/gnu/PACKAGE/VERSION/HASH instead ... or /opt/guix/ <vagrantc>not that people should really need to look at the store too much anyways <roptat>but where would you save derivations, configuartion files or the kernel then? <jlicht>vagrantc: I would remove the /opt prefix in that case: it adds no information, and besides compatibility with FHS does not offer any major advantage, right? <vagrantc>jlicht: it would remove one barrier to Debian adoption, possibly other distro <vagrantc>not that it's an insurmountable barrier; an exception might be possible ... but it would obviate the need for it entirely ... but t would break compatibility with existing guix stores <vagrantc>so if you're going to break compatibility with old guix, you may as well increase compatibility with something else <efraim>mbakke: any feedback on removing/replacing the python-updates branch? <jlicht>vagrantc: I do like the /PACKAGE/VERSION/HASH thing though, if only because it would mean that pressing <TAB> in emacs when navigating /gnu/store/... would not cripple my laptop that much anymore <mbakke>I'm tempted to switch OpenSSL to 1.1 now that Python and lots of other packages supports it. <snape>jlicht: vagrantc: all store elements don't have a version though <snape>more generally: all store elements aren't packages <jlicht>it does not seem insurmountable indeed :-) <daviid>ACTION also thinks using guix as a repo 'prefix' would be better then gnu <snape>I don't remember anyone else said it would be better ;) <daviid>snape: someone suggested guix earler, but I can drop the also if that's a problem :) <brendarn>I'm happy implicitly supporting the GNU project with it <daviid>brendarn: but in the store, you'll find free s/w that are not part of gnu ... to me, /guix or /opt/guix if for debian inclusion would be better, but nothing 'really' important, sorry I did shim in ... back to work now <brendarn>daviid: I was thinking of also suggested changing the package names from hash-name-version to name-version-hash but maybe that's just causing too much trouble :p <pkill9>brendarn: the reason the hash is first is so you can autocomplete to the hash easier <brendarn>pkill9: I thought it'd be nice to be able to type emacs and tab to show all versions of emacs in the store <pkill9>you could make a simple command for that. I don't use emacs so I dunno how in emacs, but just a script or bash alias like `find /gnu/store -maxdepth 1 -type d -iname '*-$1*'` <bavier>brendarn: having the hash at a predictable offset from the storedir significantly increases the speed of grafting. <efraim>Echo looks like it'd be better than ls <brendarn>nice with echo. i tried ls but it would show me the contents of the directory too <wigust->brendarn: ‘ls’ has a ‘-d’ option to show the directory itself. <kahiru>hey, is there an ETA on LVM support in mapped-devices? <mbakke>kahiru: No one is working on it, so "future" is my best estimate :) <kballou>mbakke: what would it take? the service? anything defined in file-system? I've only been poking around and those are the two that standout to me... <mbakke>kahiru: I've tried working on it (briefly), the main obstacle was that the static LVM package is broken (it depends on lots of things). Another is that the mapped-device interface somewhat ironically does not map well to the device-mapper command. <mbakke>None of these are insurmountable, but it will take considerable effort. You up for the challenge? :) <kballou>kahiru: sorry to hijack, but I've been curious about the same thing <kahiru>kballou, not problem, glad to see there's someone else interested <kballou>mbakke: we'll see, I'm still trying to dig in :) <kballou>mbakke: I probably need to submit some bug reports or help messages since guix on gentoo-hardened doesn't seem to be entirely working :| <mbakke>kballou: Oh, what seems to be the problem on gentoo-hardened? <mbakke>Speaking of which, we could use some hardening efforts in Guix too! <kballou>mbakke: I get some backtrace errors with ice-9 with most commands, `guix pull`, `guix refresh`, `guix lint`... `guix package` seems to be working, so, the main one works ;) <mbakke>kballou: Oh no! Did you compile guix from source using the hardened toolchain, or are you using the binary tarball? <kballou>mbakke: the former, hardened toolchain <kballou>mbakke: I don't think a non PIC exception has been made... that might fix somethings but I haven't thought to test it yet <kballou>mbakke: but that seems like a poor solution... <mbakke>kballou: I suspect a proper fix would have to dig deep into the Guix toolchain, since Guix "replaces itself" once you've `guix pull`-ed. <mbakke>Anyway a starting point could be to see if Gentoo has any hardening flags for Guile and try to adapt them to our package. <kballou>mbakke: it probably doesn't help that guile moves fairly slowly in gentoo, IIRC. I will look what's available there, maybe try disabling some of the hardening to test. I've been avoiding this because I thought I would have to recompile my entire profile... <bavier>the tests/pack.scm test requires either substituting or building a significant number of packages in order to complete. <bavier>currently for me it's so far bootstrapped glibc and is now working on gcc-5.5.0 <bavier>substitutes must not be available <bavier>ACTION really needs to start browsing debbugs.gnu.org before complaining here <mbakke>Oh no. I have to choose between Mark and rekados fix for (guix build meson-build-system) when merging master into core-updates. <mbakke>I'm taking the solutions with less LoC :P <nee`>How can I set the gcc version in gnu-build-system? I'm trying to upgrade openrct2 to 0.2.0 and it needs some new c++17 features that aren't in gcc5. <g_bor[m]>nee`: I guess you can just add the gcc you want to native inputs. <nee`>Ah, okay I get some other errors about <stdlib.h> missing now, but good to know that's the right way. <ng0>it is up to us to make suggestions on the Talk page of articles <ng0>I do this regularly with other projects <ng0>I do small changes by hand, but once they are more than just version release dates I tell wikipedia about it <ng0>due to their neutrality guideline. <efraim>IIRC dmd was started around 2003 <dustyweb>well, I just edited the page, oops. I guess the policy says I shouldn't do that since I'm a Guix/Shepherd contributor. <ng0>I think given a good reason and you don't change like 50% of the page to advertisment style, it is ok^^ <bavier>oops, typo in dustyweb's edit to that page <ecbrown>i'm considering adding a number of options to openssh configuration, akin to x11-forwarding? such as gateway ports. before embarking on this, i thought i would check in since its a central service and there might be strong opinions. <nee`>I can't figure out this missing <stdlib.h> error with openrct2. So if anyone else want's have a try upgrading it, go ahead, I probably won't. <snape>ecbrown: feel free to send a patch per option, and make sure to set the default values as they are upstream, unless you have a good reason not to do so <ecbrown>snape: right, that's exactly what I'm doing. i will make some small changes to ssh.scm and the documents and send it it for review. <snape>great, I'm looking forward to reviewing them! <kballou>has anyone done some customization for emacs and `guix environment`? I would like to keep the same emacs server running, and just be able to associate `guix environment`s with a projectile or similar... or are the nix-modes going to work for this?