IRC channel logs

<jamesrichardson>Finishing preparing a talk on functional package management for a GNU/Linux conference in a few weeks. Thinking I'm over my head.

<reepca>Downloading a 60.7 MiB linux-libre from hydra at 30KiB/s... should I just restart the command and hope for a different mirror?

<davidl>jamesrichardson: I found a pretty thorough collection of arguments for Guix "MakingTheCase.org" at https://github.com/malcook/sce/blob/master/MakingTheCase.org

<davidl>dunno, but might be helpful.

<jamesrichardson>davidl: thanks for the links

<davidl>yw. And good luck with the talk!

<OriansJ>days like this teach me that it is always far easier to keep from making a mess than cleaning up one

<bavier>why am I getting segfaults every time I try to build guix now?

<bavier>segfaults on loading (guix download)

<bavier>maybe I'm doing something wrong; first time I've tried to build guix from git in a while

<janneke>Morning Guix!

<reepca>o/

<reepca>I've noticed that emacs doesn't seem to be indenting package definitions and such the same way as it's done in the guix source. For example, the line after "origin" is at the same indentation level.

<janneke>reepca: there are formatting directions in the guix git tree in .dir-locals.el

<reepca>janneke: ah, thanks!

<janneke>they should get loaded automagically...

<reepca>yeah, I was trying to edit a package outside of that tree. So I just moved it in there, as I probably should have in the first place

<reepca>all good now

<janneke>(y)

<reepca>How would one go about getting 32-bit versions of certain packages? I'm trying to compile a program that's x86-only (32 bits, that is), but since I'm on x86_64 I've only got the header files for 64-bit stuff.

<rekado>reepca: you can use the --system=i686-linux option

<efraim>If you mean for a package the wine package is built targeting x86

<reepca>That seems to be for guix build only. Is there a way to make them available without packaging the program for guix?

<rekado>reepca: can you not enter an environment with i686-linux programs and libraries?

<reepca>oh, didn't realize that was an option for guix environment as well.

<rekado>I’m having a problem after upgrading to guile 2.2.2

<rekado>I entered “guix environment guix”

<rekado>then “make clean”, then “make”

<rekado>everything has finished compiling

<rekado>but substitute keeps crashing

<rekado>substitute: guix/ui.scm:1264:8: Wrong type to apply: #<unknown-type (0x24f . 0x7fbecf28ad68) @ 0x7fbecf839318>

<rekado>trying without substitutes now

<rekado>probably a GUILE_LOAD_PATH problem

<rekado>fixed

<rekado>oof, ant-bootstrap fails to build on my server. Segfaults.

<civodul>Hello Guix!

<rekado>hi civodul!

<rekado>there’s no substitute for gtk and it fails to build on my machines

<rekado>the cairo test fails

<Digit>with a little help from https://stackoverflow.com/questions/692000/how-do-i-write-stderr-to-a-file-while-using-tee-with-a-pipe i managed to get http://ks392457.kimsufi.com/stuff/stderr.log output.

<civodul>rekado: has GTK+ changed?

<rekado>civodul: it seems to have changed, but I don’t know when and why

<rekado>hmm, again building gtk+

<rekado>hmm, I wonder why. I tried with substitute-urls=https://bayfront.guixsd.org, but there’s no difference.

<rekado>will try with hydra.gnu.org directly

<rekado>bleh, same.

<rekado>I need gtk+ for the profile hooks :(

<rekado>this time it built. Something non-deterministic in its tests?

<rekado>on a different system I cannot do “guix pull” because it fails with this error:

<rekado>ERROR: no code for module (guix build utils)

<rekado>could it be that https://mirror.hydra.gnu.org/guix/nar/gzip/3i1rnjjq8sjfwc6312ri3wvl225yjy08-glibc-bootstrap-0 is a corrupt cache item?

<rekado>yes, it’s only 324K but should be much bigger

<cbaines>I'm having issues with the info-dir-builder this morning, I'm also getting "ERROR: no code for module (guix build utils)".

<cbaines>The builder file seems to lack the statements that are usually at the start to load Guile modules

<cbaines>This is on a machine I just did guix pull on this morning

<ryanwatkins>hey guys, do packages automatically update themselves in Guix given a git commit or is it when a version is bumped?

<cbaines>what do you mean by "given a git commit" ryanwatkins ?

<rekado>ryanwatkins: for git commits we usually also bump the version with a simple “revision” counter

<ryanwatkins>cbaines: well, for instance there a guix package called guile-wm right and I am seeing there has been a couple commits on the git repo but I am wondering if I now do a guix package -i guile-wm given I already have an old copy, will I get the commits?

<ryanwatkins>rekado: gotcha

<rekado>ryanwatkins: so the new version is “latest release version” + “-” + “revision counter” + “.” + “part of the hash”

<ryanwatkins>rekado: is there a command to view the revision counter?

<rekado>ryanwatkins: guix will not install the latest version unless that’s defined in guix

<rekado>so for guile-wm you will get exactly what the package expression describes.

<ryanwatkins>rekado: so I should modify the package exp?

<rekado>yes. To update it three things must be changed: the hash, the commit, the revision counter.

<ryanwatkins>rekado: okay, presumably this is not automated in the build farm because latest versions would be unstable?

<rekado>we generally don’t upgrade packages automatically.

<rekado>but it would be possible to try an upgrade and see if it builds fine.

<rekado>I’m working on something like this for R packages.

<rekado>cbaines: I don’t have a problem with info-dir-builder. For my problem I used the git checkout to upgrade :(

<ryanwatkins>rekado: okay cool

<cbaines>rekado, interesting, I've managed to revert to a older commit that seems to be working

<ng0>which subsystems of guix will I get a problem with when no virtualization support is available? That would just be system vm and the like, correct?

<ng0>ACTION has just asked a small commercial hoster for dedicated server because IN-Berlin is taking too long to restore my failed attempt

<cbaines>ng0, this is just a guess, but I think QEMU might even run without virtualisation support, but just slower

<cbaines>I managed to get a Bytemark VM running GuixSD setup a few days ago, and I'm looking forward to using that more

<cbaines>I failed at doing the installation from a Debian live system, so I installed Debian, did the binary install of Guix, and then did guix system init

<cbaines>It failed to boot a few times as /etc/ existed, but I managed to use the guile shell to move the files out of the way

<ng0>I crashed and burned the first IN-Berlin vserver attempt. 1984 vservers work when you follow their advice to switch to boot from Debian iso (which then includes grub on the disk)

<ng0>oh.. this is where I am stuck actually.. the guile shell

<cbaines>do you know why the guile shell has been started?

<ng0>yes

<ng0>but I have 0 experience or even understanding of that shell

<cbaines>what is the error message you get?

<ng0>the same as I had before in Debian which I wasn#t able to solve (unlike 1984 where I was able to solve it): /etc/ssl/ (and some more files) exist

<ng0>the exact message... I don't think I can connect anymore

<cbaines>What I did, was to rename /etc to /etc-bkp

<cbaines>e.g. (rename-file "/etc" "/etc-bkp")

<ng0>I have 10 different /etc-* because I tried to figure out what was different in the Debian they installed from the stock debian

<ng0>I'll connect to the console and see if I can use the guile shell with your instructions

<ng0>I don#t think that just the shell built-in help is enough. If this is not in our documentation, it should be.

<cbaines>I think it took me a few tries, possibly because I restarted before the changes had propagated to the disk

<cbaines>One of my thoughts while going through this process, is that guix system init could check for issues like this and raise errors earlier

<ng0>I only used init because my 'reconfigure' method did not work

<ng0>reconfigure tells you about files being in the way/existing

<cbaines>ah, interesting

<ng0>but the guile-shell is really unfortunate in my opinion. Take a look from the perspective of someone who doesn't know guile. He gets a shell which resembles a repl. First thought: what the hell is this? Second thought: okay, ,help didn't help... Next step: Search the Guix Documentation. Still nothing

<ng0>Even.. ,bournish … not documented in Guix documentation

<ng0>is ,bournish intended to become the default rescue shell once it has more features? Even I don't know

<ng0>cbaines: my etc/ is currently a full featured debian 8 minimal etc/. I know what's in GuixSD etc/, I know what I should've copied but it wasn't enough as everytime I copied only the minimal set Guix broke to some extent, so I had to copy back

<ng0>among the last problems I could see was that /etc/ssl already exists

<ng0>for starters, I think I can delete etc/vim/

<ng0>I'm using bournish now, not guile-shell

<cbaines>I remember /etc/ssl being a problem for me

<cbaines>do you know what error you got this time?

<rekado>ng0: bournish is better than a bare guile REPL.

<rekado>ng0: but it misses lots of features

<ng0>and now I made it hang

<ng0>it's similar to a not configured ksh or ash.. my backspace is not recognized as such, and 3 backspaces and one ^C made the whole process no longer respond

<rekado>the bournish shell has very few commands

<rekado>ideally you wouldn’t spend much time at all in the recovery REPL

<rekado>ending up there usually indicates that the root file system couldn’t be mounted

<ng0>ideally our documentation would have an easy accessible "Recovering from a boot failure - using Guile-shell and bournish" section.

<ng0>cbaines: no idea, I only get access to the console once I can log into the shell

<ng0>so all I see is the guile-shell

<rekado>what is the guile-shell?

<ng0>I could start deleting things

<cbaines>I think I had success with moving the entire /etc directory out of the way

<cbaines>but it sounds like you tried that already?

<rekado>if you mean the recovery REPL on boot then please look at the messages before that

<ng0>you still need something in etc

<ng0>I can't.

<ng0>It is technically impossible for me

<cbaines>What happens if you run ,bt

<cbaines>to get the backtrace in the recovery REPL

<cbaines>I think that gave me information

<rekado>ng0: okay, I guess I don’t understand what you’re doing.

<rekado>ACTION goes back to working on CRAN

<ng0>new vserver at IN-Berlin, I'm currently waiting for feedback on my email I've sent them but because they are few and I want to use this anyway I want to fix the installation. I know the system works because I generated it locally later on and because I can use the rescue server (which means that at least grub is working)

<ng0>cbaines: fails at symlinking profile/etc/ssl to /etc/ssl

<ng0>at least that's what I read fro mthe 5 lines

<rekado>ng0: yeah, but I don’t understand your constraints, e.g. the technical impossibility of checking the previous output, etc

<ng0>my shell access goes over a server which is hooked into the kvm machine

<cbaines>ng0, ok, so can you move /etc/ssl out of the way (or move /etc out of the way)?

<cbaines>I was using rename-file, and scandir from (ice-9 ftw) to do this

<ng0>cbaines: you mean simply moving all of /etc away?

<rekado>KVM meaning “keyboard, video and mouse“ here or Kernel-based Virtual Machine?

<ng0>don't I need /etc/mtab?

<cbaines>I think that helped me, I renamed the directory to /etc-bkp

<ng0>rekado: machine

<rekado>?

<ng0>cbaines: nothing more? no new /etc ?

<rekado>it’s not uncommon to have a machine in a data centre that’s serially attached

<rekado>(aka as a serial switch)

<rekado>s/aka //

<cbaines>ng0, I don't think so

<ng0>rekado: I think it helps if I paste the link to the IN-Berlin thread.. basically this was one of the reasons why we introduced grub options

<rekado>ACTION sighs

<ng0> https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00001.html the quote is enough

<ng0>> > IN-Berlin runs a Consoleserver which redirects ssh logins to it via

<ng0>> > "virsh console $vserver" to the /sbin/agetty (on debian vservers) on

<ng0>> > your server.

<ng0>ie: I really have no way to go back up before what I see, my view is just the view I get once I am logged in that way

<ng0>,bt is my only way to get the error messages

<ng0>cbaines: thanks, I'll try

<cbaines>let us know how you get on

<ng0>cbaines: no, simply removing /etc does not help

<cbaines>what is the backtrace now?

<ng0>0 (#<procedure 1a97080 ()>)

<ng0>ah wrong

<ng0>In unknown file:

<ng0> 0 (symlink "/proc/self/mounts" "/root/etc/mtab")

<ng0>there's aminimal set which is needed, as wingo noted

<ng0>and I here https://n0is.noblogs.org/post/2017/04/11/installing-guixsd-the-borg-way/

<ng0>so maybe I need to create these files now

<cbaines>"/root/etc/mtab" is unusual

<cbaines>on the GuixSD system I'm currently using, /etc/mtab is a symlink to /proc/self/mounts

<cbaines>I find the /root prefix unusual...?

<ng0>yeah

<cbaines>On another subject, I spoke too soon about the wierd info-dir build failure

<cbaines>My "reproducible" workflow for using Guix works on two machines, but I get that failure on the machine that matters... :(

<ng0>okay. when I do the reset and reconnect fast enough, I do get to see the full output

<cbaines>Does it say why the symlink is failing, assuming that is still the failure?

<ng0>I think to symlink a file into the directory, the directory must exist

<ng0>here etc no longer exists, so symlink fails because the destination does not exist

<cbaines>Ok, perhaps make /etc an empty directory, and then try rebooting?

<civodul>hey cbaines!

<civodul>cbaines: /etc should be populated when it boots

<ng0>but for that /etc must exist

<ng0>which in my case it currently does not

<ng0>In unknown file:

<ng0> 0 (symlink "/proc/self/mounts" "/root/etc/mtab")

<ng0>this is still happening

<ng0>hm

<cbaines>Even now that /etc exists?

<ng0>ah, no

<ng0>i thought I created it

<cbaines>I think I had this issue, where changes to the filesystem didn't actually happen

<cbaines>I was just exiting the REPL which upsets linux, and then rebooting forcefully

<cbaines>I don't know if there is a way to gracefully reboot, or sync the filesystem changes to disk

<ryanwatkins>okay so I am trying to edit a package that now fetches from git using a commit but now when I try to install it I am having some problems with autotools, it is saying I am missing makeinfo but I definitely have makeinfo, any ideas? :(

<cbaines>ryanwatkins, when you say install it, do you mean that the package is failing to build, or that it doesn't work when installed?

<rekado>ryanwatkins: do you have makeinfo in the package’s build environment?

<ryanwatkins>cbaines: failing to build

<rekado>ryanwatkins: by design Guix will ignore what you might have installed locally

<ryanwatkins>rekado: I thought (guix build-system gnu) would contain makeinfo?

<ryanwatkins>or is that stupid of me :P

<cbaines>makeinfo might be in the texinfo package

<cbaines>at least I see several packages who have an input called "makeinfo" which uses the texinfo package

<ryanwatkins>cbaines: I just imported and stuck it in the inputs, seems to do the job so far, nice

<cbaines>ryanwatkins, good good :)

<ng0>cbaines: "/etc" doesn survive a hard reset

<cbaines>hmm, that's annoying

<cbaines>maybe try creating it, and then leaving the system for a few minutes

<ng0>could work..

<cbaines>possibly using scandir also to check it exists before attempting a reboot

<ng0>like this I suppose:

<ng0>scheme@(ice-9 ftw)> (scandir "/")

<ng0>$2 = ("." ".." ".cache" "dev" "etc" "gnu" "init" "proc" "root" "sys")

<cbaines>That looks good...

<cbaines>Maybe run (scandir "/etc") as well

<ng0>is there another way to restart? I currently just disconnect and instrcut the console server to reset

<ng0>scheme@(ice-9 ftw)> (scandir "/etc")

<ng0>$4 = ("." "..")

<civodul>cbaines: try ",bournish" if possible

<civodul>it should be more convenient

<cbaines>Thanks, I've never tried that :)

<cbaines>civodul, do you have any wisdom to offer about getting out of the recovery REPL?

<ng0>servers with consumer hardware and their realtek onboard nic should be fully functional with linux-libre when Debian is one of the business supported systems is Debian, right

<ng0>cbaines: didn#t help

<cbaines>ng0, that's annoying :(

<cbaines>In good news, I think I've fixed the two broken machines I've been working on this morning

<cbaines>I've got around the info-dir problem by gc'ing some Guix derivations, no idea why that helped

<ng0>I'll try to just touch a file in there, maybe it help

<cbaines>and I managed to restore a GuixSD system that wouldn't boot by running guix system init again from the installation image

<cbaines>I might try creating another Bytemark VM running GuixSD, just to see if I can get the process down

<cbaines>ng0, does /var/guix/profiles/per-user/root/guix-profile/bin/sync exist?

<cbaines>if so, you could try running that

<ng0>one moment

<rekado>to exit the REPL you can just type ,q

<cbaines>I think that makes linux rather unhappy, ideally exiting would be a graceful shutdown

<ng0>cbaines: no

<ng0>that no was to say the file does not exist

<ng0>bah. at this point I'm paying so much for the vservers at in-berlin from the specifications I'm using, I could aswell tell this commercial hoster that I want a dedicated server.. it's not that I'm unhappy with in-berlin, just getting and running Guix and GuixSD on it currently requires too much resources.

<rain1>is there an absolute most minimal guix system configuration? just the kernel, a shell and maybe tools to set up networking and ssh

<cbaines>os-config-bare-bones.texi is quite minimal

<cbaines>you can probalby get rid of tcpdump though

<cbaines>and maybe the dhcp client service

<ng0>cbaines: never mind about my problem.. I told IN-Berlin to destroy it. I'll look out for the missing features for them and introduce GuixSD to them once it is functional enough for their VM workflow. I'll go with all our dedicated machines now and for my own stuff also dedicated.. chances that GuixSD works are very high.

<civodul>cbaines: use ",q" to get out of the recovery REPL

<civodul>(sorry for being somewhat AFK!)

<ng0>I think what cbaines means is a way to reset the machine from within the repl without a hard reset from outside of the repl

<civodul>oh right

<civodul>hmm

<civodul>",q" might help

<civodul>actually 'reboot' should work

<ng0>ah, ok

<ng0>I opened a bug so that eventually the often cited someone documents the recovery process.

<ng0>I would have opened a bug for the symlink to /root/etc/mtab aswell, but I don't know why this happened

<ng0>locally the system build just fine

<civodul>"the often cited someone" :-)

<ng0>well the failed server on IN-Berlin had some use

<ng0>I opened 2 bugs

<sirgazil>sneek: later tell paroneayea that there are zip-up hoodies now: https://teespring.com/stores/vestaro/page/2

<sneek>Okay.

<ng0>cool

<ng0>sirgazil: what's this campaign thing at teespring?

<ng0>"We reached our goal! You can keep buying until the campaign ends!"

<paroneayea>sirgazil: woo \\o/

<sneek>paroneayea, you have 1 message.

<sneek>paroneayea, sirgazil says: that there are zip-up hoodies now: https://teespring.com/stores/vestaro/page/2

<jlicht>'ello guix

<sneek>jlicht, you have 1 message.

<sneek>jlicht, civodul says: the switch to build-systems-on-gexp triggers a full rebuild; subsequent changes don't necessarily do

<civodul>'lo!

<civodul>so, i tried to install GuixSD on a relatively old Dell server

<civodul>and GRUB would just print "GRUB" and si there

<civodul>*sit there

<civodul>then i rebuilt an image with GRUB in console-mode only, but that didn't make a difference

<civodul>terrible!

<brendyn>Was it trying to display the GuixSD logo?

<ng0>there is no logo in the console-mode

<sirgazil>ng0: "campaign" is just the concept used in teespring to sell a number of products. That's all :)

<ng0>so it's not a one time offer of a number and then it will be gone

<jlicht>civodul: thanks for the pointer on gexp-based build systems

<jlicht>then I know not to expect a quick feedback loop while working on that

<civodul>jlicht: actually you don't need to actually build stuff when working on that

<civodul>most of the work can be done without building anything substantial

<jlicht>civodul: What else could I do to know my stuff is working properly?

<civodul>jlicht: i think there are tests, and also if you manage to compute a derivation that's already a good sign :-)

<civodul>so "./pre-inst-env guix build -d foo"

<civodul>i don't remember if that branch adds more tests

<jlicht>ah of course.

<sirgazil>ng0: no, the "campaign" restarts every 3 days. So the products are always available. Every 3 days, they send the apparel and other stuff for printing.

<ryanwatkins>hey guys, how can one put a "custom" package into the config.scm? :D

<rekado>ryanwatkins: (use-modules (the module name))

<rekado>then you only have to make sure that (the module name) is available on GUIX_PACKAGE_PATH

<ryanwatkins>rekado: but I should have a seperate namespace right?

<ryanwatkins>rekado: okay

<jsierles>greetings

<jsierles>anyone know if there's work going on for importing julia packages into guix?

<rekado>jsierles: I don’t think so.

<rekado>jsierles: would you like to give it a try?

<jsierles>good question :)

<jsierles>the problem is julia is in the midst of changing its own packaging tool

<rekado>I suppose the first step would be to write an importer

<sirgazil>sneek: later tell davexunit the black mug handle is white.

<sneek>Will do.

<jsierles>indeed. where's a good place to start to look at an importer?

<rekado>jsierles: you could take a look at guix/import/cran.scm

<rekado>ryanwatkins: note that the module name must match its path / directory structure

<rekado>$root/my/custom/packages.scm must have a module name (my custom packages)

<rekado>then you would add $root to the GUIX_PACKAGE_PATH

<dzecniv>Salut les français, j'ai écrit une note sur guix et guix pack sur linuxfr, je vous invite à la lire, signaler les erreurs et répondre aux questions ! :) https://linuxfr.org/users/dzecniv/journaux/creer-une-archive-d-application-conteneurisee-avec-guix-pack

<rekado>dzecniv: merci beaucoup!

<dzecniv>avec plaisir ! J'aimerais beaucoup que Guix soit plus connu, qu'on lise plus de tutoriaux, qu'on déploie des applis web plus facilement !

<dzecniv>(I wish it was more famous, that we had more tutorials and that we could deploy web apps more easily !)

<civodul>salut dzecniv !

<civodul>very nice!

<civodul>and appreciated :-)

<civodul>perhaps it would be better to leave the description of the new release for a separate news entry?

<dzecniv>thanks (there may one sentence not totally understood, hope it makes sense though ;) )

<civodul>i mean the "GNU GuixSD 0.13.0" section

<civodul>also, "Développé à l'INRIA Bordeaux." is not quite correct if i may :-)

<rekado>:)

<dzecniv>ah, please explain. You at least work there right ? but not all contributors I imagine :)

<civodul>well it's slowly becoming true, but there are also many other individuals/institutes involved

<civodul>i do work there, and i've just started working on Guix there (more on that later)

<civodul>until now Inria had nothing to do with that :-)

<dzecniv>oh ok my mistake, I thought you did work on that there. Any more info on the other institutions ?

<dzecniv>but if Inria has nothing to do with that… it's more impressive.

<dzecniv>btw I'm not eager to write a note on GuixSD 0.13 right now, two in a row would be too much IMO. I did write notes for GuixSD releases though and I shall for next releases.

<rekado>dzecniv: people who happen to work at other institutes also contribute to Guix. Soon there will be a more formal announcement on who and what :)

<dzecniv>great, thanks.

<rekado>argh, IT here changes SMTP authentication to … NTLM!

<rekado>of all the possible authentication methods they picked NTLM.

<rekado>msmtp supposedly supports it, but I haven’t been able to send any email yet.

<civodul>dzecniv: at any rate, thanks a lot for writing about Guix!

<dzecniv>you're welcome. I encourage you to write something in french once in a while, even short notices, and to catch mentions on linuxfr, so that someone experimented can answer questions and concerns !

<civodul>sounds like a good idea

<civodul>i wrote an article in GLMF a while back

<civodul>Steap did as well

<civodul> http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-194/Gestion-de-paquets-sure-et-flexible-avec-GNU-Guix

<Steap>ACTION did indeed

<Steap> http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-195/Python-un-environnement-vraiment-isole-avec-GNU-Guix

<dzecniv>cool je les référence dans les commentaires.

<Steap>ACTION wrote a Dockerfile this morning and feels ashamed

<alezost>sneek: hello

<sneek>Welcome back alezost, you have 1 message.

<sneek>alezost, Apteryx says: Do you think it'd make sense to use search-paths instead of the elisp glue code for module discoveries? I think I've got something working, but I've yet to test it (touching gnu-build-system search-path means rebuilding the world).

<alezost>Apteryx: how would that work? I mean the elisp code loads "...-autoloads.el" files and search-paths can't do that

<ryanwatkins>Hey, anybody know how to solve `guix system: error: symlink: Permission denied: "/var..." upon guix system reconfigure?

<alezost>ryanwatkins: did you run it as root?

<ryanwatkins>alezost: if I run as root I can't find the correct GUIX_PACKAGE_PATH it seems

<alezost>ryanwatkins: try with "sudo -E guix ..."

<ryanwatkins>alezost: okay, will do

<alezost>btw you need to be root to reconfigure a system, but you can be a user to do "guix system build"

<ryanwatkins>alezost: cool, seems to work, so I need to be root to administer an action but a user can run the daemon?

<rekado>ryanwatkins: I would not run the daemon as a regular user

<rekado>ryanwatkins: you would not be able to build reproducibly because chroot is unavailable.

<alezost>ryanwatkins: no, I mean that "guix system build" is a usual command to build something (the system) in /gnu/store, but "guix system reconfigure" also creates system generations in /var/..., so it must be run as root

<ryanwatkins>alezost: okay

<ryanwatkins>rekado: so sudo -E guix ... means non-reproducibility?

<rekado>ryanwatkins: no

<alezost>ryanwatkins: no, it is the same as "sudo" but with your user environment

<rekado>ryanwatkins: running the daemon as non-root causes problems

<ryanwatkins>rekado: ahh. okay got it, sorry for the noobiness :D

<Apteryx>sneek: later tell alezost: I was under the (wrong?) impression that autoloads would be autoloaded if they were found in EMACSLOADPATH. If this is not the case, then yes, we'd still need to do something in site-start.el like we're doing now, but at least we wouldn't need to rely on a profile existing (i.e., elisp dependencies resolution through search-paths would work fine at the build systemb level).

<sneek>Will do.

<Apteryx>While attempting to build guile-2.2, I got: building of `/gnu/store/i2p0gqxm378ydlh58qpy6jas7rdk79jg-guile-2.2.2.drv' timed out after 3600 seconds of silence. I'm retrying now.

<Sn0wDay_>Hello everyone. I want to install last Guix into a UEFI system. I already have installed different systems on other partitions (ubuntu, fedora, windows). I was booted from Guix USB Stick, created a separate ext4 partition and want install it into UEFI with other OSes. Does you have any manual how to do this correctly ?

<Sn0wDay_>As I understand I don't need to install GRUB, because it already installed with ubuntu or fedora

<Sn0wDay_>But I need to add to UEFI Guix specific stuff

<Sn0wDay_>Am I right ?

<Sn0wDay_>And how to "You should pay attention to what your configuration file contains, and in particular: You also need to specify the grub-efi package if you wish to use native UEFI boot." ?

<mbakke>Sn0wDay_: Take a look at the "lightweight desktop" example in the manual

<mbakke>it contains everything needed for a working UEFI installation

<Sn0wDay_>Thanks a lot. Now will look on it.

<mbakke>Sn0wDay_: the main "gotchas" is that you need a dedicated partition for the Guix EFI loader, and it needs to be marked as "esp" (e.g. with parted)

<mbakke>(that's no different from other distros, but installers typically do this for you)

<Sn0wDay_>ok. will install for a some mintes :) Will tell you about result

<jsierles>so guix is not hosted on github anymore?

<mbakke>jsierles: guix was never hosted on github, and never will be :)

<jsierles>alright. why is that? just curious

<mbakke>Sn0wDay_: make sure to mark the partition as "ESP"! that's not mentioned in the example (though it is under the partitioning section)

<mbakke>jsierles: because github is not free software :)

<catonano>jsierles: the GNU project has published a liist o criteria of acceptability for repositories hhosting free software. Gitub is quite low in te rank

<rain1>bizarrely sourceforge got a high rating

<catonano>jsierles: you probably saw a mirror someone made and publiished on Github

<Sn0wDay_>It can't to install without internet connection ? Installation image is more than 1 GiB, but can't instal without internet ?

<ziz15>hi guys, i am trying to install guix inside a vm and after it finish the installation it says that it cannot install the grub because of blocklists..can someone help plz?

<Sn0wDay_>And it don't see my wi-fi. May be because it require proprietary driver or somethoing like that

<Sn0wDay_>Will try to find any ethernet cable...

<jsierles>catonano: ok thanks. does the free software limitation also mean that guix is unsuitable for packaging proprietary software? or just that such software will not be accepted upstream?

<ziz15>it says : failed to get canonical path of unionfs

<catonano>jsierles: such software will not be accepted upstream. Also, asing for support or discussing the packaging of proprietary software is not welcomed on the Guix chhannels (the mailing lists and the irc channel)

<catonano>jsierles: there's a set of guidelines, if you want someting more formal

<catonano>jsierles: too bad right now I don't remember ow that is called

<jsierles>i'll look around

<catonano>jsierles: that said, if you have te skills to package propriatery software, that's perfectly fine

<jsierles>but i was confused, as I saw there's some support for python Conda, which is compiled with intel MKL for example

<catonano>jsierles: support for conda ?

<catonano>I don't know abot conda, I can' find it among the packages

<jsierles> https://github.com/pjotrp/guix-notes/blob/master/CONDA.org

<catonano>jsierles: I see. I wouldn't know. Better someone more knowledgable talks about this

<bavier`>jsierles: pjotr's notes do not necessarily reflect the opinions and guidelines of the Guix project itself

<jsierles>ok. whose opinions should i be watching?

<Sn0wDay_>One more question. Is it possible to include for example .NET core (it absolutels open-source) into the guix repo, in case someone will port it ?

<Sn0wDay_>It under MIT or BSD license as I rememvber...

<Sn0wDay_>Or only GNU GPL software is acceptable to be included into the Guix repo ?

<bavier`>jsierles: with respect to which software is accepted, Guix follows the FSDG.

<bavier`>Sn0wDay_: as long as the license is considered free

<bavier`>Sn0wDay_: BSD MIT/X11 is fine

<Sn0wDay_>ok, thanks

<Sn0wDay_>Also. Are any good video / tutorials / etc/ about guix fundamentals. May be some guy told about how it working from beginning, from grub MBR part in loading and to end steps when for example desktop is starting ?

<Sn0wDay_>May be exists some portal about Guix different stuff ?

<Sn0wDay_>Or may be some guix events are coming ?

<Sn0wDay_>I found on site

<bavier`>Sn0wDay_: there are some conference videos about Guix fundamentals linked on the guix website

<Sn0wDay_>yep, already found. Thanks

<mbakke>I've been meaning to start a "guix drops" blog similar to "nix pills", but haven't gotten around to it yet :/

<Sn0wDay_>Thx!

<rekado>I don’t think Conda is built with Intel’s MKL

<alezost>Apteryx: yeah, the files are not autoloaded automatically when they are in EMACSLOADPATH. Regarding search-paths: I don't know, it should be discussed on mailing list

<sneek>alezost, you have 1 message.

<sneek>alezost, Apteryx says: I was under the (wrong?) impression that autoloads would be autoloaded if they were found in EMACSLOADPATH. If this is not the case, then yes, we'd still need to do something in site-start.el like we're doing now, but at least we wouldn't need to rely on a profile existing (i.e., elisp dependencies resolution through search-paths would work fine at the build systemb level).

<reggggieee>I have done a "guix package -r perl" which ran successfully. When I run it again, it says there's nothing to do, and yet when I issue 'which perl' it's still in my guix-profile - any idea what's up?

<reggggieee>(on a foreign distro)

<rekado>reggggieee: what is your PATH?

<reepca-laptop>It seems that building gcc-toolchain from scratch is a good way to perform a denial of service attack on yourself... desktop system has now been frozen for about an hour

<reggggieee>rekado: it's super long, but there is a /home/username/.guix-profile/bin${PATH:+:}$PATH at the end, which I want to keep for other packages

<reggggieee>do i need to garbage collect or something?

<rekado>reepca-laptop: I’m currently building core-updates on my puny laptop

<rekado>reepca-laptop: it gets very hot, and it often freezes my system (still hot when it’s frozen, though)

<rekado>reggggieee: is /gnu/store/…-profile/bin on your PATH?

<rekado>reggggieee: does ‘which perl’ show ~/.guix-profile/bin/perl or is it something else?

<rekado>reggggieee: does the file actually exist in ~/.guix-profile/bin/?

<reggggieee>rekado: yes, it's showing ~/.guix-profile/bin/perl

<rekado>(could it be a propagated input, maybe?)

<reggggieee>rekado: dunno. also /gnu/store.. is not in path

<reepca-laptop>rekado: is there a way to give the build processes a lower priority so that they don't freeze everything?

<rekado>reepca-laptop: I don’t know. You might be able to renice them, but I’m not sure this will help much.

<rekado>reggggieee: hmm, I don’t know then. I just checked in the REPL and if I did this right the only package that propagates perl is intltool.

<rekado>reggggieee: if you happen to have that installed (or a package propagating it) you would also end up with perl in the profile.

<catonano>I had the unfortunate idea to issue a "guix package -u" command tonight. Now it's compiling qemu, some softmmu thing :-/

<reggggieee>rekado: ok gotcha

<rekado>catonano: you can always abort this

<reepca-laptop>It'd be neat if there was a "guix plan" command that would explain what all was going to happen, to make it less surprising when a build-the-world comes along

<rekado>reepca-laptop: actually, we have that already

<catonano>rekado: right. Aborted

<rekado>reepca-laptop: but grafts make this more challenging

<rekado>reepca-laptop: in the distant past before grafts made security fixes less scary Guix would always tell us first what it would do.

<rekado>now this happens somewhere in the middle or near the end

<rekado>fixing this is tricky

<rekado>reepca-laptop: you can get close to ‘guix plan’ with ‘guix package … --no-grafts --dry-run’

<reepca-laptop>alright, I'll note that in the future

<rekado>Guix will do more than that because of grafts, but it’s a good start

<lfam>The grafting work is relatively fast unless there is lots of I/O contention, so I think it's okay that it doesn't get mentioned for now.

<sneek>lfam, you have 1 message.

<sneek>lfam, rekado says: Thanks for fixing my typo in gnu/local.mk

<lfam>You're welcome!

<rekado>civodul: /gnu/store/nkfgi6n46py1r5ciy4dsfp7wvwjs5j85-gcc-cross-boot0-5.4.0.drv (on core-updates) fails the unpack phase with corrupt compressed data. Does this need to be cleared out in the cache?

<rekado>lfam: true, but grafting can require building other packages first.

<lfam>That's true

<civodul>ACTION checks

<civodul>rekado: seems to work for me, and there are no substitutes anyway, right?

<lfam>civodul: "i do work there, and i've just started working on Guix there (more on that later)". Sounds like big news!

<rekado>civodul: hmm, how odd. Maybe it’s corrupted on my disk.

<civodul>lfam: :-)

<civodul>rekado: i'm letting it run just in case

<civodul>wasn't there a parallel xz patch floating around?

<lfam>civodul: Yes, and we pushed the parallel compression patch in 63102406f22412bb922de5549deb89d3594a38c0, IIRC. There was also a followup: 6c17422eace097aceac4b5994f0343bcbed6e3ab

<lfam>Parallel decompression is not yet implemented in xz, but passing the argument doesn't cause any problems.

<lfam>And parallel compression of source archives: c8a3dea847bb9f87fa1876d0c6c3356d6226f121

<civodul>lfam: awesome!

<civodul>i guess it's decompression of gcc that was taking tmie

<civodul>*time

<civodul>funny thing: i inadvertently hit the wifi-kill button on my laptop, and it actually killed the wifi of my external dongle

<civodul>it may sound obvious to normal people but somehow i didn't think it was possible :-)

<catonano>civodul: ;-)

<lfam>civodul: Interesting! I wonder how it's all wired up

<rekado>civodul: the gcc unpack problem really seems to have been local corruption on my disk. Sorry for the false alarm!

IRC channel logs

2017-05-30.log