IRC channel logs


back to list of logs

<lfam>Petter: The main error message there is this one: ERROR: In procedure stat: No such file or directory: "../misc/cgo/testcarchive/test.bash"
<lfam>And that file is referenced a few lines before
<myglc2>Hello Guix!
<lfam>Petter: I don't know whether or not the warnings about rc are a problem or not
<lfam>Petter: I would compare this to the build logs for 1.6.3, and see if the warnings are there too
<Petter>Thanks! I'll look in this direction and see what I see :)
<lfam>rc is a Bell Labs / Plan 9 thing, and those are the people behind Go. I think that the Golang source code might even include rc
<Petter>How do I make it rebuild the whole package? I tried: ./pre-inst-env guix build --no-substitutes go
<Petter>But it finishes very quickly with almost no output
<lfam>Petter: It will re-use the built package in /gnu/store if you haven't actually changed the package. To force a rebuild anyways, use --check
<lfam>But if you just want the build log, use '--log-file --no-grafts'
<lfam>Petter ^
<lfam>Assuming that's why you're asking...
<Petter>Yes, got it.
<Petter>Yes, the same 'rc' messages are there as well.
<lfam>I would ignore those messages for now, then. They aren't what caused your crash
<Petter>Right, I'm looking at the missing file
<Petter>Or, for I should say
<myglc2>Anyone using dovecot? Following the doc I get "error: invalid field specifier"
<lfam>myglc2: Maybe wingo has some ideas, since he added the dovecot service
<lfam>Any advice on using substitute* to add a line of text before a matching line?
<myglc2>lfam: Thanks I just found his config on wingolog, now I am cooking with Guix!
<lfam>Oh, nice :)
<lfam>Hope it tastes good
<myglc2>lfam: Usually does once I find the forks & spoons ;-)
<Petter>> After 9 attempts Petter was able to update his first package
<Petter>> ...and there was much rejoicing!
<Petter>How does it look?
<Petter>ACTION zZz
<lfam>Petter: Seems reasonable to me. You should send it to guix-devel!
<mwcampbell>Would the Guix project benefit from another ARM build slave? I can donate a Wandboard Dual.
<mark_weaver>mwcampbell: sure, that would be a very welcome addition!
<mark_weaver>we have a Wandboard Quad arm build slave, and it works well.
<mwcampbell>Would you like me to ship it somewhere, or run it in my home and let you access it remotely?
<mark_weaver>shipping it to the FSF would be ideal
<mark_weaver>c/o Lisa Marie Maginnis (Senior SysAdmin)
<mwcampbell>Alternatively, is anyone working on a GuixSD ARM port yet? If not, maybe I could keep my board and work on bootstrapping that port.
<mark_weaver>how much RAM does it have? also, just checking: it has a SATA port, right?
<mwcampbell>hmm, no, 1 GB of RAM and no SATA. So never mind
<mark_weaver>sure, that would be great too!
<mwcampbell>Only the Quad has SATA
<mark_weaver>oh, interesting. oh well.
<mark_weaver>but yeah, getting GuixSD running on it would be even better
<mwcampbell>I'm guessing the main challenge with a GuixSD ARM port will be that ARM boards generally use u-boot rather than GRUB
<mark_weaver>we just need a few components for that: ideally, we need a single linux-libre kernel that works on as many arm boards as possible
<mark_weaver>debian has a kernel that works on several boards
<mwcampbell>I'll see if Parabola has that
<mark_weaver>it would be good to do that, but for linux-libre. so collecting any patches needed to enable that, and crafting a suitable kernel configuration.
<mwcampbell>FWIW, I've successfully run Fedora with a generic kernel on my Wandboard Dual.
<mwcampbell>I know Fedora isn't a fully libre distro though
<mark_weaver>and the other part, as you noted, is either getting GRUB working as a secondary bootloader loaded from u-boot (preferable)
<mark_weaver>or generalizing guix to support other bootloaders directly
<mark_weaver>on the Wandboard Quad, I used stock Debian, and then installed Guix on top.
<mark_weaver>(for hydra-slave2)
<mark_weaver>but debian and fedora both use heavily patched kernels
<mark_weaver>the approach we should take is to try to get linux-libre doing a similar job.
<mark_weaver>as I recall, multi-board support for ARM was integrated into Torvalds' canonical "Linux", which Linux-libre follows, so linux-libre should hopefully already have most of what we need.
<mark_weaver>I'm guessing it's mostly about the configuration. it might not be hard. I just haven't looked into the details yet.
<mark_weaver>(and I'm spread thin, so it would be good if someone else could do it :)
<mwcampbell>I'll look into it.
<mwcampbell>By the way, what desktop environment(s) have been packaged for GuixSD so far?
<mark_weaver>the bootloader issue can be worked around for now. if we had a working kernel, I expect it wouldn't be hard to install GuixSD, and just configure u-boot by hand for now.
<mark_weaver>mwcampbell: GNOME 3, Xfce, Enlightenment, and several simpler window managers
<mwcampbell>I'm going to see if I can get Parabola GNU/Linux running on my Wandboard Dual. If so, I'll see how they're handling the kernel, since they use linux-libre
<mark_weaver>sounds good
<mark_weaver>thank you for the interest and offers of help!
<myglc2>Installed dovecot-service but got no man page or doc. Is this normal? Heh ;-)
<davexunit>myglc2: packages used in services aren't added to the system-wide profile
<myglc2>davexunit: Ok so if i want to read the doc just install the package?
<mwcampbell>It looks like MATE is packaged in GuixSD. Anyone know if that's actually usable yet?
<mwcampbell>I ask because mark_weaver didn't mention MATE when I asked about desktop environments
<lfam>mwcampbell: There is a patch waiting for review that would add u-boot and a device tree compiler to Guix:
<balduin>how can I add path for the `validate-runpath` phase?
<balduin>*a path
<mark_weaver>balduin: looks like we don't have anything exposed at the moment to do that easily. I could say how to hack it in, but I'm not sure its worth it.
<mark_weaver>I can see a clean way to enable this in the future, but iiuc, it would force a full rebuild of almost all packages, so it would have to wait until the next core-updates cycle
<mark_weaver>but that's a non-essential phase
<mark_weaver>it can be skimmed without harm. they are essentially tests.
<lfam>mark_weaver: I didn't realize it was okay to skip that phase. But I just checked and there are some packages that do it.
<mark_weaver>skipping that phase is analogous to skipping the 'check' phase. the only harm is that some problems might go unnoticed.
<lfam>I'm reading the comments in the places where we skip it. Interesting reading
<balduin>@mark_weaver: thanks. I think it would be a good idea to be able to add paths. Especially because in my case library is in `/gnu/store/hash-package-name/`, but the runpath-validate paths only include `/gnu/store/hash-package-name/subdir`
<mark_weaver>balduin: you mean a .so library is directly in /gnu/store/hash-package-name/ ?
<mark_weaver>if so, that's a problem. something is going wrong in the package build system, or you're using it wrong.
<mark_weaver>that would be analogous to a more traditional "make install" putting libraries or executables directly in /usr
<balduin>no sorry, it is in `/gnu/store/hash-package-name/lib`, but looks only in `/gnu/store/hash-package-name/lib/subdir`
<mark_weaver>balduin: what makes you think validate-runpath is not looking in /gnu/store/.../lib ? that's where most libraries in guix are installed, and afaict validate-runpath looks there.
<balduin>@mark_weaver: I could be wrong, but have a look here:
<mark_weaver>balduin: you need to augment LDFLAGS to add an rpath for $out/lib. here's how:
<mark_weaver>if the program has a gnu-style ./configure script, try adding (string-append "LDFLAGS=-Wl,-rpath=" (assoc-ref %outputs "out") "/lib") to #:configure-flags
<mark_weaver>that's preferable, if it can be done
<mark_weaver>see the python-2.7 package for an example of that
<mark_weaver>failing that, you can try adding that to #:make-flags instead, as is done in the 'pciutils' package.
<mark_weaver>balduin: guix automatically arranges to add rpaths for all inputs that contain /lib sub-directories.
<mark_weaver>but in this case, you also need to add an rpath for the not-yet-installed $out/lib
<mark_weaver>this happens when a package includes both a shared library and a program that needs to link to that shared library
<balduin>okay, the package uses cmake
<mark_weaver>ACTION looks in guix/build/cmake-build-system.scm for clues
<mark_weaver>hmm, looking at that file, it appears that cmake-build-system tries to handle this automatically on line 59: ,(string-append "-DCMAKE_INSTALL_RPATH=" out "/lib")
<mark_weaver>balduin: actually, now that I'm looking more closely, it looks like this error is harmless, a false positive.
<mark_weaver>these neko modules will probably be loaded by itself, and thus don't need an rpath for libneko because it will already be laoded.
<mark_weaver>we've disabled this validation for a few other packages that had something like this.
<balduin>adding `(string-append "-DCMAKE_INSTALL_RPATH=" (assoc-ref %outputs "out") "/lib")` did not work
<mark_weaver>balduin: I would add #:validate-runpath? #f to the 'arguments' field.
<mark_weaver>and remove the other hacks I suggested
<balduin>@mark_weaver: I think you are right
<balduin>@mark_weaver, it worked thanks :-)
<detrout>what does the % mean in that (assoc-ref %outputs...)?
<mark_weaver>detrout: in scheme, '%' can appear in identifiers, and it has no special meaning to the language itself.
<detrout>mark_weaver: but it seems to have meaning in guix build scripts?
<detrout>in a lambda with (#:key outputs) I can refer to the output variable
<detrout>but outside of the lambda... it doesn't seem to, unless maybe with the %?
<mark_weaver>I guess civodul started those identifiers with '%' to call attention to them, I guess because they are made available to the scheme code snippets in package definitions without being explicitly bound in a way the user can see.
<detrout>Ah ok
<mark_weaver>detrout: they are defined in the 'prologue' at the top of build-side scheme scripts, which ultimately contain all of the snippets of code created from package descriptions and build systems. see where 'prologue' is defined in guix/derivations.scm line 1195
<detrout>Ooh. thank you
<mark_weaver>bavier: where can I find your gpg key 1EBBD204781F962C ?
***lashdu is now known as drtan
<mark_weaver>rekado: the pulseaudio-update jobset on hydra completed very successfully. you can push the relevant commits to master at your convenience.
<bavier>mark_weaver: my key is on savannah
<yang>Hello , is there a section about "minimum hardware requirements" to run GUIX ?
<bavier>yang: no
<bavier>it kinda depends on what you install and run
<bavier>I run GuixSD on a low-end netbook often
<yang>How do I setup IP and sshd ?
<yang>so I can ssh inside ?
<bavier>yang: are you running the installation image, or GuixSD?
<yang>Its installed now already I assume, I am synced over VNC into VM
<yang>gotta setup ssh as VNC renders really very slow
<yang>I have root access
<bavier>basically, you need to add lsh-service or dropbear-service to your OS config, then reconfigure
<yang>guix package -i lsh-service
<bavier>yang: see the example at
<davexunit>installing packages does not add system services
<davexunit>the OS config is the place where the *complete* description of the system is stored
<yang>hey, I am from the apt-get world :)
<davexunit>ah yes :)
<davexunit>so yeah, that's a significant difference between apt and guix :)
<davexunit>package installation doesn't have global effects in Guix
<yang>Is guix alike any other distribution, or have you figured out a unique system ?
<davexunit>it's like NixOS in many ways
<yang>I mean the management and all
<davexunit>it's rather unique
<davexunit>NixOS is the most similar, but there are still differences.
<yang>So would anyone be interested to write me the basic command lines onto pastebin for setting up the network and sshd ? So I can ssh into the box and test it further ? The VNC renders really slowly for me
<yang>I'd really appreciate that
<OrangeShark>yang: sshd has to be configured in the config file used to configure the GuixSD install
<yang>cant it be done after the install ?
<OrangeShark>ya, you have to edit the config file and then reconfigure
<bavier>yang: yes, update your os config, then 'guix system reconfigure'
<OrangeShark>the idea is to keep the systems configuration like ssh into a config file. So you can copy that file into another system and get pretty much the same system
<yang>Sorry, but it looks too complex for me
<yang>I give up
<OrangeShark>yang, if you look at
<OrangeShark>the first example config has in (services ...) (lsh-service #:port-number 2222)
<OrangeShark>basically saying to run sshd on port 2222
<OrangeShark> is the documentation for configuring sshd service
<OrangeShark>look at Scheme Procedure: lsh-service
<OrangeShark>it shows all the defaults for the optional arguments like #:root-login? to #f for false
<OrangeShark>once you have the service added, you can reconfigure with "guix system reconfigure path/to/config.scm'
<ng0>there was a security fix for libgcrypt, I'll apply patches and the updates I had on core-updates and send them in today or as soon as I am finished
<jeaye>Are there any official GuixSD base virtualbox images?
<davexunit>jeaye: no.
<efraim>Its best to try it out with qemu
<jeaye>I'm looking to setup an image for use with vagrant and was just trying to save some work. No problem though, as I don't mind doing it manually.
<davexunit>neat :)
<davexunit>would be interested to see how that turns out
<myglc2>Hi Guix! got a question about services ...
<myglc2>To modify dovecot-service #:config I tried 'guix reconfigure' & 'herd restart dovecot', but the config did not change :-(
<myglc2>It does change after a reboot. Is there something I am missing?
<myglc2>... be right back, got to reboot anain ;-)
<paroneayea>davexunit: what's this (source ".") stuff you mentioned recently and guix environment stuff?
<paroneayea>got more info about it?
<paroneayea>or an example of it being used?
<paroneayea>oh wait
<paroneayea>irc logs!
<paroneayea>found it
<paroneayea> fwiw
<bavier>oh cool
<bavier>anyone know what's up with python2-tempest-lib package?
<efraim>Is that the one in openstack.scm that's been broken forever?
<efraim>The one in openstack has been deprecated upstream and its replacement didn't drop in nicely with 0 effort so that's on my long to do list
<davexunit>paroneayea: turns out that exact code doesn't work :/
<davexunit>I would like to patch guix to make it work, though
<davexunit>paroneayea: this actually works, but is more complex:
<paroneayea>davexunit: is the select? necessary, or just a good idea? :)
<davexunit>paroneayea: just a good idea
<bavier>efraim: it's a dependency of git-annex-remote-hubic
<davexunit>paroneayea: I'd like it if guix had a reusable procedure for this purpose
<davexunit>ludovic already wrote such a thing, but it just needs refactoring.
<davexunit>and to be exported
<paroneayea>davexunit: gotcha :)
<davexunit>I also want "." to work as a directory
<mark_weaver>davexunit: my browsers don't like the TLS setup on your web server. I suspect the problem is that you're using 'cert.pem' instead of 'fullchain.pem' for the web server.
<davexunit>mark_weaver: ah, thanks!
<mark_weaver>np :)
<davexunit>my certs are expiring soon, so I'll try to fix that.
<davexunit>my server is in disarray lately. I wish it ran GuixSD...
<balduin>I get this error if try to install opam: cannot build derivation `/gnu/store/9ry9s4822vw8pp0z16b7f8wgrcnkq313-profile.drv': 1 dependencies couldn't be built
<balduin>guix package: error: build failed: build of `/gnu/store/9ry9s4822vw8pp0z16b7f8wgrcnkq313-profile.drv' failed
<bavier>balduin: opam is a bit broken right now
<bavier>balduin: I've fixed and upgraded it locally, would you like a patch?
<balduin>@bavier: yes
<balduin>@bavier: thanks, but I have never worked with git patches. How should I apply the patch? I used the binary installer to install guix.
<bavier>balduin: I see
<bavier>hmmm, you could rather put the entire new package definition somewhere in GUIX_PACKAGE_PATH, and then guix commands would pick that one instead
<bavier>just a sec
<bavier>balduin: put that module as "opam.scm" somewhere, then make sure GUIX_PACKAGE_PATH includes the directory it's in
<bavier>balduin: see
<balduin>@bavier: the opam package can not find camlp4, but I installed it
<bavier>balduin: at runtime?
<balduin>@bavier: yes
<balduin>configure: error: You must install the Camlp4 pre-processor.
<bavier>balduin: ok, I haven't actually tried using the opam package after its built
<bavier>thanks for testing :)
<balduin>@bavier: I can not build opam, it fails because camlp4
<bavier>balduin: what's the version you get from `guix package --show=opam`?
<bavier>it should be 1.2.2
<balduin>I do not get your version 1.2.2
<bavier>balduin: guix must not be picking up the new package module then
<bavier>did you set GUIX_PACKAGE_PATH?
<bavier>and you have an "opam.scm" file in one of the directories in GUIX_PACKAGE_PATH?
<balduin>$ echo $GUIX_PACKAGE_PATH
<balduin>guix-try]$ ls
<balduin>gnu opam.scm
<balduin>but guix does not seem to pick up your file
<bavier>balduin: you exported GUIX_PACKAGE_PATH?
<balduin>yes, in the same terminal I am working in (see above)
<bavier>balduin: the other thing you can try is passing the -L flag to guix
<bavier>`guix package -L/home/user/guix-try --show=opam`
<balduin>@bavier: no, does not work
<balduin>name: opam
<balduin>version: 1.1.1
<balduin>location: gnu/packages/ocaml.scm
<bavier>balduin: omg, sorry, there's a typo in what I pasted
<bavier>balduin: you might see a "source expression failed to match any pattern" warning
<balduin>@bavier: yes, I do
<bavier>balduin: you can remove the lonely paren on line 23
<balduin>@bavier: I still get the warning: opam.scm:13:0: warning: source expression failed to match any pattern
<balduin>@bavier, sorry my fault. Now, it works :-)
<bavier>oh, lovely
<bavier>thanks for your patience
<balduin>@ build-succeeded /gnu/store/zvf2fh824v5yyjdwmw4ka29r17sgj83z-opam-1.2.2.drv -
<balduin>/gnu/store/3d5m9f1scyiy5q2kbgnqjrxrp6y1vm2x-opam-1.2.2 :-)