IRC channel logs


back to list of logs

<mbakke>g_bor: Yes, I think we can merge it to staging.
<rain1>i couldn't get guixsd installed
<lfam>rain1: What went wrong?
<rain1>guix system init has an weird error, so i tried guix pull but it faile
<rain1>some problem with SRFI
<lfam>Details are welcome :)
<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>Hello Guix!
<civodul>yay xorg can rotate my screen again \\o/
<snape>hi guix :-)
<g_bor[m]>hello guix!
<efraim> looks like monolithic qt failed several times on qt-updates
<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>oh, nice
<civodul>shepherd has nothing like that
<snape>and dangerous
<civodul>yes, that too
<civodul>but you can run arbitrary code in shepherd :-)
<g_bor[m]>ACTION sent a long message: < >
<g_bor[m]>This looks like suspicious...
<jonsger>nice, one can now just install guix on SLES15 from repos (only 2 additional required) :)
<snape>civodul: what do you think of
<rekado>g_bor[m]: this looks familiar somehow.
<snape>(or rekado)
<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>snape: lemme take a look
<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
<civodul>gcc in particular
<snape>civodul: and thus they would be built at each evaluation, which is annoying. Got it.
<snape>thanks for your reply!
<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 :)
<mbakke>Patches incoming.
<civodul>mbakke: woohoo!
<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
<rekado>mbakke: beautiful!
<civodul>brendarn: apparently it refers to nologin in its code, so it should remain in 'inputs'
***einarelen_ is now known as einarelen
<civodul>a nice read by khinsen, featuring a rant on deployment on Racket's Scribble:
<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>yeah, dunno
<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
<vagrantc>that was a change from 0.14.0 to 0.15.0
<civodul>right, that could be the explanation, nyberg ↑
<nyberg>ah, would make sense
<civodul>you need to have ~/.config/guix/current/bin in $PATH
<nyberg>Thank you
<nyberg>Seems to have been caused by naive use of guix package --search-paths
<jlicht>hey guix!
<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
<civodul>anyway, new article without CONDA:
<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.
<civodul>a "back link" of sorts?
<civodul>yeah, would be nice, but... tricky
<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
<mbakke>The patches are in!
<rekado>ACTION reads the new blog post
<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>mbakke: oh no!
<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!
<g_bor[m]>mbakke: Congrats! Really nice!
<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 :)
<snape>and nice pictures
<civodul>wonderful pictures ;-)
<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>hence the article
<civodul>vagrantc: i stumbled upon via the R-B weekly update
<dustyweb>hi hi
<civodul>i can't wait to listen to your talk!
<civodul>it's awesome to get feedback from an experienced DD
<civodul>hey dustyweb!
<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 :-)
<pkill9>why do people hate `guix pull`?
<civodul>brendarn: yeah performance, and better integration
<jonsger>pkill9: it was slow and computing itensive
<rekado>civodul: hah, yay!
<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.
<dustyweb>hey that debian talk looks great
<mbakke>civodul: Allright.
<vagrantc>dustyweb: it's still mostly vapourware :)
<dustyweb>the new guix pull is indeed really great btw
<dustyweb>I'm very happy with using it
<dustyweb>and civodul is right
<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"
<dustyweb>vagrantc: oh really???
<dustyweb>well heck then
<dustyweb>let's get it in Debian!
<vagrantc>dustyweb: indeed :)
<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>like npm and etc
<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
<pkill9>ah yeah
<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>much easier tab-completion
<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
<vagrantc>or not change it at all
<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>efraim: No news yet!
<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
<vagrantc>i'm sure something could be worked out
<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*'`
<wigust->Or ‘echo /gnu/store/*emacs*/’.
<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
<mbakke>bavier: I think that is
<bavier>mbakke: ahha, probably.
<bavier>ACTION really needs to start browsing before complaining here
<bavier>mbakke: thanks
<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.
<g_bor[m]>see bc73f673 for an example.
<nee`>Ah, okay I get some other errors about <stdlib.h> missing now, but good to know that's the right way.
<dustyweb>dmd precedes systemd by quite a while right? says shepherd is "inspired by" systemd
<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
<bavier>kballou: thanks! :)
<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!
<g_bor[m]>nee`: Have a look at here:
<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?