IRC channel logs


back to list of logs

<Apteryx>how to proceed when a software cannot work unless the user take extra action (such as setting a setuid bit on jackd)?
<Apteryx>It seems the best I can do under Guix/GuixSD is to provide this information in the package description and let the user fend for themselves to do so. What do you think?
<atw>I think that's the best you can do. The manual has a section on this (6.2.8) and the GuixSD way is for the system administrator to whitelist it.
<atw>Apteryx: seems like the best way to do it. The manual says that the system administrator has to effectively whitelist a program for it to get setuid on a particular system
<atw>I couldn't find a good example, but it might be worth grepping the existing packages.
<rumpadump>Does guixsd and linux-libre work on amd 17 gen family? Aka AMD Ryzen processors.
<rumpadump>I was able to boot the installation media for guixsd 0.14 in bios boot mode
<rumpadump>But then I thought maybe I should install uefi grub, but rebooting into uefi mode didn't work.
<rekado>There are still 508 different pyc files after recompiling all .py files.
<rumpadump>What is the difference between nix and guix
<rekado>rumpadump: somebody asked a similar question on HN recently. Here’s my response:
<rekado>nix and guix are separate implementations of functional package management, so they have many differences.
<rumpadump>Nix had overlays and overrides, does guix have them too?
<rumpadump>I thought those were bad
<rekado>in Guix we have GUIX_PACKAGE_PATH where you can add custom modules providing custom package definitions. You can also inherit from other packages in your custom package definitions.
<rumpadump>Goes against, what I think functional means
<rekado>I don’t know how this relates to overlays and overrides, as I’m not a Nix user.
<rumpadump>Overlays and overrides do just what they sound like they do, override the configuration file
<rekado>override what configuration file?
<rumpadump>The configuration file, the file that is supposed to define the system
<rumpadump>Whole system and bit by bit
<rumpadump>I'm sorry I assumed nix and guix are similar and didn't explain myself properly
<rumpadump>Again, now I know I should pay more attention
<rumpadump>It would be equivalent to /etc/configuration.scm I suppose.
<rekado>GuixSD is specified with a configuration file in Scheme. There are no overrides, but we have syntax to replace services with custom services.
<rekado>that’s still functional, though.
<rekado>despite the interface that implies modification, nothing is really modified.
<rumpadump>Now it would be great if I get my system running guixsd quickly
<rumpadump>BTW, there is some issue with uefi and AMD 17 family processors
<rumpadump>aka AMD zen cores
<rumpadump>In uefi the installation media won't boot, but in bios mode it does
<rumpadump>Where should I file this?
<rekado>please send email to
<rekado>rumpadumpagain: please send email to
<rumpadumpagain>Ok thanks
<civodul>Hello Guix!
<snape>hi :-)
<snape>civodul: thanks for the load* fix and the mention in the commit message
<rekado>g_bor: do you know which of the tests we may disable for python-3.6?
<rekado>oh, never mind. It’s the tests that I already disabled :)
<rekado>with that patch even python-pandas built reproducibly; I didn’t patch the build system in my copy, so one pyc file (version…pyc) has a different timestamp.
<rekado>didn’t expect pandas would make fewer problems than numpy.
<MaliRemorker>since guix crew seems a bit livelier than guilers ... do you guys ever use guild?
<MaliRemorker>is it dead?
<MaliRemorker>more specifically doc-snarf :)
<thorwil>what the * is wrong with (bootloader (bootloader-configuration (bootloader grub-bootloader) (target "/dev/sdb2")))?
<thorwil>all guix had to say was that it failed to install grub
<pkill9>thorwil: i think you need to change 'sdb2' to just 'sdb'
<pkill9>i think there's a commend above that line saying you need to set it to /dev/sdX (X being variable)
<thorwil>pkill9: all i want is a /boot/grub/grub.cfg that i can use from the grub already present on /dev/sda
<thorwil>i don't think i want a grub in /dev/sdb mbr
<pkill9>oh then maybe try setting the target to '/dev/sda'?
<pkill9>not sure sorry
<mange>Even if it failed to install grub, I think it will still have generated a *-grub.cfg file in the store. I don't know how you could find out which one it is, though.
<rekado>mange: with “guix system build config.scm”
<mange>Where in the system is it?
<mange>I can't see it, or `find` it in /run/current-system, so I assumed it wasn't in the built system.
<snape>mange: there is a way to avoid bootloader installation
<mange>You could take a list of the files in /gnu/store, then try to reconfigure and see what's new? That sounds like a pretty terrible solution, though.
<snape>if that's what you want
<snape>(if you already have grub installed somewhere else)
<mange>Yeah, but then how do you get the guix-generated grub.cfg?
<snape>it won't prevent its generation. Wait a minute
<snape>(bootloader (bootloader-configuration (bootloader (bootloader (inherit grub-bootloader) (installer #~(lambda args #t))))))
<snape>In English: I want the grub bootloader, but with a custom install phase that will do nothing and return #t
<mange>Okay, but then where does grub.cfg go?
<snape>same place: /boot/grub/grub.cfg
<snape>#~(lambda args #t) could be rewritten as #~(const #t) I guess
<thorwil>hmmm, guess i have to try that
<snape>Oh I talked to mange but it was you thorwil who had the issue, sorry
<thorwil>i certainly don't mind, if people discuss my issue! ;)
<thorwil>if init fails after doing much of the work, should the command be reused, or should one switch to reconfigure?
<snape>thorwil: I think you needs to use init, because reconfigure doesn't know about your system being in /mnt. Unless you do it in a chroot? I have no idea, really, I've done this once, long time ago :-)
<snape>if it's just the bootloader install phase that failed, it's probably safe to consider that the installation is an overall success
<snape>and reboot :)
<snape>Assuming you have a bootloader installed somewhere else, that is able to read grub.cfg of course
<snape>(you should check that /boot/grub/grub.cfg has been generated)
<thorwil>yes, i already was at the point of having a grub in the store, but no grub.cfg, since i did use --no-bootloader. to only then notice that it's useless that way :}
<pmikkelsen>hi guix, I have a question that may be a bit strange. Would it make sense to have a package definition which builds a static website using one of the many static site generators, and then use the output directy in a nginx service configuration? This way, I think it would be possible to update the package definition, run 'guix system reconfigure ...' and then the new website will be used. Just an idea I had, but I would like your view on
<pmikkelsen>it :)
<rekado>pmikkelsen: yes, this would work. It may be a little heavy-handed to update the package definition each time, but it coudl be okay for sites that don’t change too often.
<pmikkelsen>rekado: okay, I guess I will have to package the software I use first then
<mange>At the moment it won't work, though, because I don't think reloading nginx config works using reconfigure. I was just reading some issues earlier, where nginx hardcodes its config and reconfigure doesn't touch running services, so it would take reboot to update.
<pmikkelsen>mange: oh i see. not so good then
<mange>You could do it by writing a system service that puts your package/website contents into a predefined folder that nginx reads from, but at that point you might as well just put it there yourself.
<pmikkelsen>What I have now is that I put it there myself via rsync from my laptop which works OK
<rekado>mange: you don’t need to reboot
<rekado>but you need to stop nginx before reconfigure.
<mange>Yeah, true.
<pmikkelsen>where can I read about those issues
<rekado>pmikkelsen: in the manual
<rekado>6.2.13 Invoking ‘guix system’
<mange>#22039 in debbugs has some details about the start/stop issues, too.
<pmikkelsen>rekado: thanks
<rekado>it says: if a service is currently running, it does not attempt to upgrade it since this would not be possible without stopping it first.
<mange>It's from before the rename, though, so you need to remember deco=herd and dmd=shepherd.
<pmikkelsen>okay i'll have a look
<AMDmi3>guix web site is partially broken
<AMDmi3> -> ok
<AMDmi3> -> 404
<thorwil>so (bootloader (bootloader-configuration (bootloader (inherit grub-bootloader) (installer #~(lambda args #t)))))
<thorwil>lead to a "invalid field specifier" at the inner "bootloader"
<thorwil>snape: ^ any idea?
<roptat>don't you need one more (bootloader …)?
<roptat>like (bootloader (bootloader-configuration (bootloader (bootloader (inherit grub-bootloader) (installer #~(lambda args #t))))))
<roptat>not sure though
<roptat>bootloader-configuration contains many fields, one of which is bootloader you must give a bootloader to
<thorwil>ah, could be that i misinterpreted and then ... misfixed what was posted :/
<roptat>and that bootloader inherits grub-bootloader and don't install it
<Apteryx>atw: thanks for confirming. Although now with a fresh head I'm seeing I might just need to propagate jackd, as the app is looking for the jackd binary.
<civodul>AMDmi3: thanks for the repo, that should be fixed now (the time for the update to propagate)
<atw>Morning #guix! Hello, Apteryx!
<Apteryx>morning, atw!
<civodul>rekado: could you take a look at the patch that removes Haskell packages already provided by GHC: ?
<civodul>hello atw & all :-)
<Apteryx>Is there a group my user should be in to allow this without being root: sched_setscheduler(23836, SCHED_FIFO, [1]) = -1 EPERM (Operation not permitted)
<atw>rekado: and speaking of which, I think my changes should be ok on top of 30501, but I should test
<Apteryx>apparently I could do this: setcap cap_sys_nice+ep ./your_program
<Apteryx>to allow that particular program to use sched_setscheduler when it's not being run as root.
<civodul>yes but you don't want to do this in the store
<civodul>the patch backlog is quite intimidating
<civodul>we should organize patch/bug squashing days!
<snape>thorwil: does it work now? :-)
<efraim>It'll be an e-meetup!
<rekado>so, the python-updates branch seems to be good. It allowed me to build python-pandas reproducibly.
<rekado>shall we build it all on hydra? It is based on staging.
<rekado>I guess I could also just build it on berlin and leave hydra alone.
<thorwil>snape: that'll be another reboot. soonish
<rekado>civodul: on berlin I’d like to build the python-updates branch. Is it enough to change cuirass-specs in (sysadmin services) and to reconfigure?
<rekado>I remember last time you modified the Cuirass database manually and ran things from your home directory.
<civodul>rekado: fiddling with the database manually is all it takes :-)
<civodul>lemme dig the command for you
<civodul>first you run: sudo sqlite3 /var/run/cuirass/cuirass.db
<civodul>then something like: insert into specifications values ('staging', '', '.', 'build-aux/cuirass/gnu-system.scm', 'cuirass-jobs', '((subset . "all") (systems "x86_64-linux" "i686-linux" "aarch64-linux"))', 'staging', NULL, NULL, 1);
<civodul>the first 'staging' is the jobset name, the 2nd one is the branch name
<thomassgn>I'm using emacs and guix-devel-mode, I changed a package definition press C-c . b to build it but it gives me the path to the "old" package already installed...
<thomassgn>how do I build the package defined at point?
<thomassgn>or can I?
<rekado>civodul: should I feel bad about doing it this way? Would be more correct to do this in the config file?
<rekado>wha…? For some reason none of the packages I install on the cluster are grafted.
<rekado>does b672a8160755bab07fb3c13dbc43dcc26525a7b7 not do what it should?
<rekado>the difference between that commit and the working patch is using package/inherit in commencement.
<rekado>I’m pretty sure that glibc-final ought to use package/inherit
<rekado>that would also explain why I thought that “guix environment -l” is broken wrt grafts. It is not. It’s just that the graft isn’t properly applied to glibc-final.
<rekado>I’m going to push a change to glibc-final.
<civodul>rekado: don't feel bad about doing it this way; Cuirass config has to be a dynamic thing, we don't want to reconfigure etc. every time we add a branch
<snape>thomassgn: you need to reevaluate the package before doing C-c . b
<civodul>rekado: re grafts, oh?
<civodul>indeed glibc-final is probably not being graft
<civodul>but we should not graft glibc-intermediate either, it doesn't make sense
<civodul>so ideally glibc-final would inherit from glibc, not from glibc-intermediate
<rekado>so I should graft both “glibc-final” and “glibc-final-with-bootstrap-bash” from commencement (by using package/inherit).
<rekado>or not graft “glibc-final-with-bootstrap-bash”, because that’s “glibc-intermediate”.
<rekado>(the names are a bit confusing to me)
<rekado>but when I don’t change glibc-final-with-bootstrap-bash then no grafts are applied when building “hello”.
<civodul>glibc-final-with-bootstrap-bash = glibc-intermediate
<civodul>this one should not be grafted
<civodul>so it can be left as is
<civodul>however, we should arrange to have:
<civodul>(define glibc-final (package/inherit glibc ...))
<civodul>it may be more difficult than it seems though, because currently it inherits from glibc-final-with-bootstrap-bash
<civodul>and we don't want to trigger a full rebuild, so care must be taken
<civodul>ACTION gives it a try
<rekado>I can’t believe I didn’t notice this until now.
<civodul>yeah and i've marked your message about 'guix env' but didn't get around to investigating
<rekado>it looks like guix env is fine after all.
<rekado>its operation for “-l” is weird, but the grafting problem is unrelated to “guix env” and just due to the botched commit :)
<civodul>still you were asking interesting questions in that message :-)
<thomassgn>hmm, geiser complains about "possibly unbound variables cppunit-1.14" and xmlsec-nss. And then when I try to build the definition it gives me "ERROR: xmlsec-nss: unbound variable" despite xml module being included/used... How to get around it?
<thomassgn>explicitly running (use-modules (gnu packages xml)) in geiser does not help
<resh> , ,
<resh>tried all 3 Always some error pops up
<resh>tried for 0.14 version in all 3 cases
<resh>Has anyone done installation of GUIX on ubuntu plz help
<rekado>resh: could you show us the errors?
<rekado>I have installed it on Ubuntu a bunch of times.
<rekado>resh: it’s best to use the official instructions from the last URL.
<rekado>if you could show me the error you got I’m sure we can help you.
<resh>Yups wait
<resh>will take time,doing it once more
<rekado>take your time.
<snape>thomassgn: you can either manually eval the unbound variables, or kill the REPL, start it again, and 'C-c . b'.
<resh>I tried sudo cd /tmp ,showing error
<resh>sudo: cd: command not found
<snape>resh: cd is built into the shell, you can't use sudo with it
<bavier`>resh: `su -` will switch to the root user
<snape>"as root" is unclear, it actually means that you need to switch to the root user because "sudo" doesn't work
<thomassgn>snape: allright, didn't work though. I get the same errors from both restarting geiser and evaluating and evaluating the variables and use-module exp. xmlsec-nss is in xml.scm - don't see how or what is causing this one to fail as there's plenty of other variables/packages from modules with different names.
<snape>thomassgn: did you try C-M-x within xmlsec-nss>?
<resh>ohh so I should not use su- and sudo before.
<snape>well for most commands, it's the same
<thomassgn>no, will do
<rekado>resh: at the beginning you just need to become the root user by running “su -”
<rekado>(you need to input the root user’s password for that)
<rekado>you could also do “sudo su -”, which will ask for your user password.
<snape>(or "sudo su", which may prompt for your password instead)
<roptat>or even "sudo -i"
<resh>sudo -i is working
<resh>thanks roptat
<thomassgn>snape: allright, that does the trick. quite cumbersome though, it keeps throwing these at me, resolving number 3 now... :)
<snape>thomassgn: as an alternative, you can just run "guix build <my-package>" in a shell
<thomassgn>hehe, yes. Or not really. 'guix build -f ./libreoffice.scm libreoffice' tells me it cannot build. how can I tell it to build this definition of package...?
<snape>you need to put it into GUIX_PACKAGE_PATH
<snape>thomassgn: see
<snape>if it's your own package file
<snape>if it's within the guix source, then guix build libreoffice should work
<thomassgn>ok. But how do I know which libreoffice it builds if I say guix package -i libreoffice? I'm just testing a few things, and would like to do just copy the file and test some changes...
<thomassgn>I guess I could start changing the names and so on in the package definition.
<snape>if you modify Guix's libreoffice definition and run: "guix build libreoffice", it will build the modified libreoffice
<thomassgn>but I'm not modifying in place
<efraim>GUIX_PACKAGE_PATH takes precedence over guix proper for leaf packages
<thomassgn>cause it's read only in my profile... :)
<snape>thomassgn: your custom libreoffice package should probably inherit Guix's one
<snape>so that you don't have to copy everything
<thomassgn>nice. So any package with duplicate variable-name in my GUIX_PACKAGE_PATH will always be chosen?! nice.
<snape>yes, but it's probably clearer if the name is different
<snape>say, my-libreoffice
<thomassgn>Yes, I don't entirely understand inheritance though :P I'm a bit slow :)
<snape>you're not slow, it takes time ;)
<snape>thomassgn: there are a few package inheritance examples in the Guix source. You can grep "inherit" in /gnu/packages/ to see them.
<thomassgn>cool, I'll have a look. I've used it once in a simple thing I mostly copied.
<snape>also, things in GUIX_PACKAGE_PATH need to be valid Guile modules
<rekado>inheritance is a way to avoid duplication.
<thomassgn>hehe, yes. I keep getting warnings from guix commands when I'm fiddling with somethings in there.
<rekado>a package can inherit all fields from another package.
<rekado>you can then override individual fields without having to specify others.
<roptat>resh: is the tarball in /tmp?
<rekado>resh: where is the tar.xz file?
<thomassgn>ah, but if I specify parts of a field will it append it to contents of the previous? or discard the previous?
<roptat>but you can get the value by using (package-<field-name> libreoffice)
<resh>roptat and rekado not inside any directory ... installed without cd to any directory
<rekado>resh: so it might still be in your home directory then.
<thomassgn>So if I just want to add something I have to copy the contents of the inherited field into the new def.? uh, sorry, what did you mean with (package-<field-name> libreoffice)? I ould just go read the docs ofc.
<thomassgn>roptat: ^^
<rekado>thomassgn: (package-synopsis libreoffice) gives you the synopsis of the libreoffice package, for example.
<rekado>thomassgn: (package-inputs libreoffice) gives you the inputs.
<roptat>for instance to add an input you would write (inputs `(("some-package" ,some-package) ,@(package-inputs libreoffice)))
<roptat>with enough parenthesis
<thomassgn>haha, Nice. Thanks :)
<rekado>i.e. the inputs field has a quasi-quoted list with the list ("some-package" ,some-package) followed by the items in the inputs field of the libreoffice package.
<resh>roptat , rekado oh okay so need to mention full directory
<rekado>resh: yes
<rekado>but you could also just move it to /tmp
<rekado>mv ~/the-tarball.tar.xz /tmp
<roptat>~ won't be the user's home when you're root though
<snape>resh: you can use the 'pwd' command to know where you are, and 'ls' to list files somewhere, it might help
<resh>roptat installed before entering root
<roptat>so it's probably in your user's home directory
<roptat>like /home/resh/guix-...
<roptat>just use the full path
<snape>resh: if the path starts with '/', it's full, or absolute. Otherwise it's relative to the result of the 'pwd' command.
<resh>it worked thanks :)
<bavier`>resh: do you have stuff in /var/guix from a previous attempt?
<rekado>a previous attempt included running the installer script
<rekado>it probably created /var/guix
<resh>i have deleted previous dir using rm -rf
<resh>not sure tho
<rekado>what does “ls -dl /var/guix” say?
<resh>its there
<rekado>then you should remove it.
<rekado>rm -rf /var/guix
<resh> it says this
<resh>even gnu is not empty,need deletion
<rekado>yes, that’s okay.
<rekado>it’s just left-overs from running the script.
<rekado>resh: in the first line you removed “var”
<rekado>so you can’t move “var/guix” any more, because you removed it.
<rekado>and you shouldn’t create the directory /var/guix
<rekado>please follow the instructions exactly.
<resh>yes, so what does that instruction on instruction page mean
<rekado>which in particular?
<resh>mv var/guix /var/ && mv gnu /
<resh>this one
<rekado>the goal here is to move the unpacked directories “var/guix” and “gnu” to their target locations.
<rekado>previously you unpacked the tar.xz file, which contains “var” and “gnu”.
<rekado>with this command you move them to /var/guix and /gnu, respectively.
<rekado>since you’ve deleted the unpacked “var” directory, you will need to unpack the tarball again.
<resh>okk got it :)
<rekado>please be careful with “rm -rf”. You are root now and can damage your system if you delete the wrong thing.
<rekado>do not accidentally remove /var
<rekado>just /var/guix
<vagrantc>in guix, is there some policy about maintaining multiple versions/forks for a given codebase?
<rekado>vagrantc: we try to avoid multiple versions.
<rekado>vagrantc: we keep them if there are “good reasons”
<vagrantc>rekado: ah, i was wondering regarding u-boot and arm-trusted-firmware ... of which commonly there are vendor folks of one or both
<rekado>oh, I don’t know much about that, I’m afraid.
<vagrantc>er, vendor forks
<rekado>AIUI we may need different variants for different ARM boards.
<rekado>but that’s already the full extent of my knowledge in this area.
<vagrantc>rekado: but the "good reasons" answer pretty much settles it, thanks :)
<vagrantc>obviously, there's a judgement call there somewhere
<rekado>in general we cannot commit to maintaining too many different versions at the same time, so we usually err on the side of picking the latest version.
<rekado>in some cases this won’t be the right decision and then we’ll correct it by adding variants (possibly using package inheritance to avoid having these copies diverge).
<vagrantc>ACTION saw a bunch of u-boot related commits and was hoping to add a few more arm boards
<rekado>civodul: when you need me to test the glibc graft fix just let me know.
<rekado>I’m eager to use latest version of Guix on the cluster again.
<snape>vagrantc: your patches to support new arm boards will be very welcome :-)
<vagrantc>snape: first i'll have to wrap my head around guile a bit, but i can probably get pretty far with cargo-culting based on other boards :)
<vagrantc>though simply running guix pull seems like it would be a remarkable excersize in patience on these boards
<efraim>vagrantc: I have some patches locally for arm trusted firmware, and I got u-boot booting on my pine64, but I wasn't able to get te board booted to TTY1
<vagrantc>efraim: ah, cool
<vagrantc>efraim: i've got an unused pine64 and pinebook that i'd be happy to experiment with
<g_bor>Hello guix!
<vagrantc>efraim: also have some wandboard/cubox-i/hummingboard variants i might be able to test
<g_bor>rekado: I've checked your message related to jeromq.
<g_bor>There are two possibilities, as the whole testsuite is being refactored. Either we go with this big patch, and we can drop that on release, or we can downgrade from 0.4.3 to 0.4.2, where we don't need the patch , and wit for the release WDYT?
<efraim>vagrantc: very cool. I have my branches also on gitlab
<efraim>I should toss my pine64 os config somewhere
<vagrantc>efraim: handful of other boards too, but mainline support is spotty
<efraim>I also have an odroid-c2, hikey something that I forgot, and a firefly 3399
<efraim>Odroid-c2 looked good, until I realized it needed blobs to build the ATF
<vagrantc>efraim: heh. ditto on all those :)
<vagrantc>yeah, i was surprised to see odroid-c2 support at all
<vagrantc>efraim: many of the boards i can test i've already got working in debian, so it's likely just a matter of making the right guix recipe
<efraim>I added the package for u-boot odroid before I realized I couldn't make it work
<efraim>vagrantc: does it work with grub or with extlinux?
<vagrantc>efraim: most should work with "extlinux" using the distro_bootcmd support in u-boot
<vagrantc>efraim: if it doesn't, i usually patch it in debian and submit upstream
<vagrantc>efraim: haven't done much testing with grub, but very recent versions of u-boot have fiarly complete EFI emulation, so grub-efi should work
<vagrantc>it's been a while since i've tested
<efraim>I get a non-standard grub screen from the pine64, and then during boot it looks like it initializes some hardware and then the screen cuts out
<efraim> <- my current pine64 os config
<efraim>and I'm back at my laptop
<efraim>vagrantc: is there a spot where the debian image scripts are kept?
<vagrantc>efraim: there aren't really images, other than the debian-installer images
<vagrantc>efraim: there's a bit of a legacy-keeps-growing-new-features package called "flash-kernel" which generates u-boot boot scripts
<vagrantc>efraim: there's also u-boot-menu which generates extlinux-style boot menus
<efraim>I don't think I've ever actually run the arm64 debian-installer, just debootstrapped a couple of times
<efraim>i'll check those out, should be cleaner than armbian's scripts
<vagrantc>yeah, usually i just debootstrap it
<vagrantc>and manually install u-boot
<efraim>they actually patched boot0 back in for the pine64
<rekado>g_bor: I’d rather not downgrade.
<rekado>civodul: looks like cuirass on berlin doesn’t do anything.
<rekado>I added a record for the python-updates branch and all I could see in the log was GC warnings.
<rekado>GC Warning: Repeated allocation of very large block (appr. size 186150912):
<rekado> May lead to memory leak and poor performance
<Sleep_Walker>do you have any idea, how can I solve or at least analyze this: ?
<Sleep_Walker>I don't know where the patch requirement comes from
<Sleep_Walker>command was: guix system build config.scm
<bavier`>Sleep_Walker: is the patch package in config.scm's 'packages' field?
<Sleep_Walker>bavier`: yes
<Sleep_Walker>removing it makes it go away :|
<Sleep_Walker>removing the package from the list makes problem go away :|
<Sleep_Walker>but why it is an issue?
<jonsger[m]>Sleep_Walker: guix seems to be broken again due to pkgconfig...
<Sleep_Walker>jonsger[m]: you mean in openSUSE?
<Sleep_Walker>jonsger[m]: scarabeus reverted guile back to 2.0 which caused all new problems, but home:sleep_walker:guile have it all good ;)
<Sleep_Walker>IOW, guix works for me well
<bavier`>Sleep_Walker: patch is in %base-packages
<bavier`>Sleep_Walker: so if you add it yourself, you'll get two versions, which leads to the error
<jonsger[m]>ah okay
<Sleep_Walker>bavier`: you are right, but why it ends with different hash?
<bavier`>Sleep_Walker: the 'patch' in %base-packages is the "canonical package"
<Sleep_Walker>OK, I'll try to understand that as reason
<Sleep_Walker>well, thanks!
<bavier`>Sleep_Walker: afaict, the patch in %base-packages is the one gnu-build-system uses, rather than the top-level package
<Sleep_Walker>ok... :b
<civodul>rekado: 2018-03-07T22:35:13 spec 'python-updates': fetched commit "accec9d67f78b5dab88eb815d17e92365b9d9ce4" (stamp was "")
<civodul>it seems that it's still evaluating the branch
<civodul>rekado: i just pushed the package/inherit thing for glibc-final
<axg>So, I'm trying to install java, and while there is many packages that come up, nothing looks like openjdk or openjre in any way. Who is using java successfully and what package did you grab to get the javac and java?
<civodul>mbakke: do you think we're ready to merge 'staging'?
<mbakke>civodul: not sure, we're still lacking many substitutes (evolution-data-server). There's also been a lot of activity on master, so IMO we should merge and do another eval first.
<civodul>ah right, gtkmm
<civodul>did you check whether berlin has more substitutes?
<civodul>i'd hope so, but i haven't checked
<mbakke>Also, I haven't actually tested GNOME yet after the EDS upgrade.
<bavier`>axg: icedtea
<mbakke>Me neither and "afk" atm. I don't expect any problems, so it should be safe to merge. But would like to test GNOME first.
<mbakke>I can merge and start a Hydra evaluation in a few hours if Hydra isn't too busy.
<mbakke>But feel free to merge if the weather is good ;)
<civodul>ok, i guess i should take a closer look first :-)
<rekado>civodul: thanks for taking care of the glibc graft!
<rekado>civodul: re cuirass on berlin: yeah, it’s finally doing something. I restarted it after about an hour.
<civodul>that shouldn't have been necessary, but maybe it went amiss
<jackhill>I'm looking at the postgresql package and would like a postgres build with SSL and gssapi support. How are optional features usually handled? Would it be okay to submit a patch that added those to the existing package, or something else so not to increase the current closure size?
<bavier`>pjotr's guix-no-root walkthrough doesn't seem to work anymore
<bavier`>hrmm, or, it might work if *all* the packages you want to install have substitutes available
<bavier`>confirmed, if the proot'd guix-daemon ever needs to build something, failure
<civodul>bavier`: how does it fail?
<bavier`>guix package: error: build failed: cannot change ownership of ?/gnu/store/af19ma2vm3qhvh3rw6cdivyp98s18bj3-guile-bootstrap-2.0.drv.chroot?: Operation not permitted
<bavier`>trying some other things...
<civodul>that doesn't seem related to proot though, does it?
<bavier`>maybe not, I was missing the '-0' flag...
<bavier`>ok, now I get "guix package: error: build failed: cloning builder process: Operation not permitted"
<bavier`>that's definitely a problem, probably my kernel is too old
<bavier`>what's the version that's needed for NEWNS?
<rekado>jackhill: it depends on how common this feature is and how much larger it makes the package closure. In some cases it may be good to add a “-minimal” variant for use with other packages and a regular variant for installation.
<bavier`>oh, 2.6-ish, my kernel has all those then, maybe processes cannot clone inside proot?
<civodul>bavier`: i think we had EPERM in containers too, but i can't remember why
<bavier`>the daemon refuses to build anything as root (faked inside proot), but I don't see any way to add fake users in proot or ask the daemon to just build as the current unprivileged user
<civodul>it may be that the clone thing requires "real" root
<jboy>during installation following the instructions at, I get the following error: "herd: service 'cow-store' not found"
<civodul>jboy: what does "herd status | grep cow" return?
<jboy>civodul: nothing
<jboy>I'm using the 0.14.0 qemu image
<rekado>jboy: the qemu image is just a virtual machine image, not an installer.
<rekado>ACTION –> zzZ
<jboy>rekado: ah, thanks. guess I misread the instructions in an earlier step
<jboy>Ludovic's PGP key has expired.
<vagrantc>pub rsa4096 2014-08-11 [SC] [expires: 2018-04-23]
<vagrantc> 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
<vagrantc>uid [ undef ] Ludovic Courtès <>
<vagrantc>that one?
<jboy>yes, it expired 2017-10-28
<jboy>oh, I see he changed the date of expiration
<soundtoxin>Any menu I open in icecat (right click, global menu, addon menus, etc.) closes instantly. Anyone else have this issue?