IRC channel logs


back to list of logs

<Apteryx>bavier1: thanks for suggesting Abiword, I'll try it out.
<nicklaf>so i'm trying to install guix-sd on a chromebook without an ethernet port. Trying a couple USB ethernet devices is giving me trouble
<nicklaf>ifconfig -a shows me a device called enp0s20u2u3Link but the normal syntax doesn't work to bring it up
<nicklaf>the link works fine on other machines, but on the guix-sd usb live install i get "ifconfig: SIOCGIFFLAGS failed: no such device"
<nicklaf>hm i'm a moron, nm. for some reason ifcongig was appending the word Link to the name spuriously
<bavier1>nicklaf: yeah, sometimes the name overflows the field width and gets squashed together with the following "Link"
<nicklaf>if i want to continue the installation via ssh, how can i set passwd? it doesn't seem to be in root's PATH
<mb[m]2>nicklaf: You can install 'shadow', but it might require some building... This is fixed in the next release :/
<mb[m]2>If you have another Guix installation (not necessarily GuixSD), you can also create a new USB image rather easily.
<nicklaf>that's fine, i can type at the terminal just for the install. the docs say something about passwd so i guess the distribution isn't caught up
<IpswichTriptych>where does the output of the compiling phase of "guix pull" get sent?
<IpswichTriptych>when running "guix pull --verbose" I see: "compiling... x% of n files" and "compiling 'gnu/store/...scm'
<IpswichTriptych>when guix pull is spending a long time compiling something in particular, i'd like to be able to inspect that output
<castilma>IpswichTriptych: try guix build --log-file <package-name>; that should tell you
<IpswichTriptych>castilma: Thank you!!!
<castilma>Im trying to set up guix offload with one raspbian system (on a pi) and with one guixsd x86-64 in qemu. # guix offload test; works on the pi. but it fails if run by a regular user because of permission problems with the ssh identity file. only root has access to it, and since guix-daemon runs as root, it should work, right? jamesrichardson experienced the same problem: <
<castilma>jamesrichardson: did you find the problem?
<castilma>another question: what's the state with crosscompilation on offload machines? does guix offload only to machines of the target architecture? if yes, why? if not, what is the (system) field in (build-machine) for?
<IpswichTriptych>castilma: doesn't guix-daemon run as its own user?
<IpswichTriptych>hi, lfam
<lfam>hey IpswichTriptych
<castilma>IpswichTriptych: not on my guixsd and not on my raspbian. afaik it only forks and switches uid to one of the guixbuilder users when it has something todo. but it seems to invoke guix offload as root
<IpswichTriptych>castilma: Ah, OK
<IpswichTriptych>In GuixSD, can I quit X (xfce) and step down to just the terminal/cli?
<IpswichTriptych>when I log out, x restarts and i'm brought back to the graphical login
<IpswichTriptych>secondly, i'm confused about the relationship between /gnu/store/...-guix-latest/gnu/packages/java.scm and the packages in # guix --list-available ... guix pull takes a really long time compiling java.scm, but I'm not sure how I can speed up or help facilitate that process. do I need to manually build every package related to java.scm?
<lfam>IpswichTriptych: When it builds java.scm, it's not building the packages in java.scm. Guile is compiling java.scm itself, into java.go
***fr33domlover is now known as Fr33domx
***Fr33domx is now known as fr33domx
***fr33domx is now known as fr33domlover
<civodul>Hello Guix!
<nee`>I ran a guix build command with ./pre-inst-env and it rebuilt gcc yesterday. gcc succeeded, the package I actually wanted to build failed. Today I wanted to rerun it and now it's building gcc again. Is there anything else I need to set at configure except --localstatedir=/var ?
<efraim>I set --sysconfdir=/etc
<nee`>ahh, I think my rebuild earlier has been triggered, because I changed the code of the gnu-build-system and that changes the hashes of almost everything.
<efraim>changing the gnu-build-system would do that
<TaoHansen[m]>does GuixSD have anything like NixOps?
<TaoHansen[m]>oh it’s Hydra
<ng0>no, Hydra is not like NixOps
<ng0>We have a work in progress "GuixOps" or what it would be called, but I'nm not up to date on the progress there
<civodul>not much progress yet :-)
<mekeor>civodul mentioned the idea of `guix deploy` at GHM 2017, i think
<cimol>sir, i've a problem when booting to guix it said "no boot file via --load , entering cozy REPL" what's wrong with my guix? o.o
<cimol>i dual boot with debian, and used grub from there ,, this is my custom grub config for guix >>>
<cimol>as i remember, i installed guix with no problems last night o.o
<taylan>guile-git depends on bytestructures? holy cow, I suddenly have Real Serious Users(TM)
<taylan>civodul: is there an easy way to add GNU Autotools to a Guile Scheme project? maybe an example I can look at?
<civodul>taylan: maybe guile-git is simple enough, or dustyweb's guile-gcrypt
<civodul>or haunt
<civodul>cimol: it means that your GRUB entry for GuixSD lacks a "--load" argument
<civodul>did you write grub.cfg by hand?
<civodul>mekeor: the idea is not new and not mine :-) davexunit started work on a prototype in
<cimol>ah my bad, i'll try fix it,,, ya i wrote it manually civodul hehe
<davexunit>I laid out more ideas for how 'guix deploy' should work on the mailing list recently
<davexunit>but I don't think anyone replied
<civodul>davexunit: oh really?
<civodul>i might have overlooked it
<civodul>i also have ideas for "guix system reconfigure", though i don't think it's written down
<civodul>i feel super-excited about it, but never got around to working in this direction
<civodul>i guess there's a time to write bugs, and a time to debug them
<civodul>these days i try to debug :-)
<davexunit>civodul: my post was on 9/22, if you wanted to look it up
<civodul>oh, found it, thanks!
***fr33domlover1 is now known as fr33domlover
<taylan>civodul: I *think* I did it :P
<civodul>taylan: woohoo! :-)
<civodul>see? autotools is super friendly
<bavier1>taylan: cool!
<ng0>when getmail 5.4 fixes my issue I'll send the patch to update getmail. It's been some responsive back and forth and version releases with it because of the issue I have
<ng0>\\o/ it's alive!
<mb[m]2>Can someone try restarting the staging build on Hydra? I'm busy today, but would like to merge it tomorrow unless there are new problems.
<laertus>when doing a "./pre-inst-env guix pull" from a guix build from git, i get an error: "Updating from Git repository at ''... guix pull: error: Git error -17"
<htgoebel>Hi, I need an example for defining a user in a package. Like make an executale run with SUID to certain user. Do we have this?
<bavier>htgoebel: that sounds like something better suited to a shepherd service
<ng0>htgoebel: could you go more into detail?
<ng0>do you need to define a user/group which is being used later in the runtime after the build?
<htgoebel>bavier: Maybe, but the executable is a dependence for some package :-\\
<ng0>we will definitely need a kde-desktop-service, that can include such suid
<ng0>or what is your problem?
<htgoebel>ngo: The package is "libutempter" which AFAIU uses a helper-exec with SUID to run commands.
<Apteryx>Has anyone noticed flickering of Abiword when using ratpoison (or any other WM)?
<htgoebel>More precisely the makefile does something like:
<htgoebel>chown root:utmp …/lib/utempter/utempter
<htgoebel>chmod 2755 …/lib/utempter/utempter
<htgoebel>/usr/sbin/groupadd -r -f utmp
<htgoebel>/usr/sbin/groupadd -r -f utempter
<Apteryx>it happens only when Abiword is in a ratpoison frame which has focused.
<ng0>is this helper-exec required by some application in a configure or build process? If not it fits the service case (see (gnu services desktop) and the gnome/xfce one), otherwise it should be fixed
<ng0>htgoebel: oh
<ng0>the makefile should never do this
<ng0>it should suggest to create the groups and users before setup, but running groupadd… you can patch it and/or talk to upstream
<bavier>Apteryx: I've noticed flickering in ratpoison, not just in abiword, but it usually only happens a few times right after resume from sleep
<Apteryx>OK. I haven't noticed that resume from sleep problem (but then I haven't used sleep since I used GuixSD maybe ;), and I don't have flickering issues in any other application than Abiword. Hmm.
<htgoebel>ng0: Maybe it's not the Makefile (I drafted this package weeks ago), but some RPM post-install script.
<htgoebel>But this is the key! Thanks. The groupadd needs to be tied to the desktop-service.
<ng0>is this required for KDE (optional or at its core)? then it can be part of a new service. otherwise there already is a setuid service
<civodul>cbaines: the ISO installation test was always(?) broken on hydra:
<civodul>weird stuff!
<civodul>well it's not the test itself
<mb[m]2>civodul: can you restart the staging build today at some point? I believe it's ready to merge after a last evaluation.
<ng0>I think I will send the new Mate patches tomorrow. I have removed the screensaver and the 2 caja+whatever addons from the meta package because this takes some time, 2 upstream feature wishes (filed as bugs) + I need time to test my ideas on the screensaver locking
<ng0>it's more important to merge the parts that work, which is quiet a big deal of software I have used since I started working on Mate and I can say that it works.
<civodul>heya mb[m]2
<civodul>mb[m]2: will do!
<civodul>i just started an eval of master
<civodul>mb[m]2: so i'll start 'staging' later today
<mb[m]2>Great, thanks :)
<civodul>well, thank *you*!
<ng0>any chance we could get the mate-desktop-service in before the next release, or is there already a build of master going on that leads to tagging a release?
<civodul>ng0: the release is not for today (nor tomorrow...), so that's still possible :-)
<ng0>Ok. But without the screensaver there is no point in the service, however it is more convenient to add it now and then just change the service instead of telling people to switch to it. There are some more changes to Mate which need to be done with the service as far as I can tell right now.
<ng0>oh, there is a reason for it :)
<laertus>when doing a "./pre-inst-env guix pull" from a guix build from git, i get an error: "Updating from Git repository at ''... guix pull: error: Git error -17"
<laertus>and right before that error these warnings: "guix pull: warning: cannot enforce use of the Let's Encrypt certificates" "guix pull: warning: please upgrade Guile-Git"
<Apteryx>Is anyone else having: gpg: error searching keyserver: No data when doing "gpg --search-key <some-keyword>" ?
<htgoebel>leartus: You may need to set
<htgoebel> export SSL_CERT_DIR="$GUIX_ENVIRONMENT/etc/ssl/certs"
<htgoebel> export SSL_CERT_FILE="$GUIX_ENVIRONMENT/etc/ssl/certs/ca-certificates.crt"
<htgoebel> export GIT_SSL_CAINFO="$SSL_CERT_FILE"
<laertus>htgoebel: thanks, but that didn't help
<laertus>i'm still getting the same error
<htgoebel>laertus: I typically use guix environment --fallback guix --ad-hoc nss-certs glibc-locales guile-git bash
<htgoebel>and the env-vars listed above
<htgoebel>laertus: Or jsut do not use the pre-inst-env. Since guix is pulled from git anway, you can use the installed version, too.
<bavier>anyone else get this error when running 'bootstrap': "automake: error: cannot open < ./%D%/guix.texi: No such file or directory"?
<Apteryx>bavier: is the fil doc/guix.texi present?
<bavier>Apteryx: yup
<bavier>file doc/guix.texi => 'doc/guix.texi: TeX document, UTF-8 Unicode text'
<Apteryx>strange. Happening on master?
<ng0>Apteryx: the default keyserver might be gone
<ng0>gnupg shut theirs down some versions ago.
<bavier>automake version 1.13.4
<bavier>oh.... I think 1.13 doesn't support %D%...
<Apteryx>bavier: couldn't reproduce using automake 1.15
<bavier>ah, yep, new in 1.14
<bavier>well, just one more thing to install...
<Apteryx>ng0: any server I try using --keyserver <server-uri> gives me the same error :/
<laertus>htgoebel: even with "env -i /usr/local/bin/guix environment --fallback --pure guix --ad-hoc guile-git nss-certs glibc-locales bash" i'm still getting the same "guix pull: error: Git error -17" when doing a "./pre-inst-env guix pull"
<laertus>htgoebel: oh... but wait... when i did those exports of SSL_CERT_DIR, etc, on top of that it didn't error out
<laertus>looking good
<laertus>thank you
<de11>is guix beta ready for daily use or breaks a lot ?
<mekeor>de11: Guix works good. but personally, i can't use GuixSD as my only OS: although i only have GuixSD installed on my laptop, i sometimes need my other laptop which runs Debian, e.g. for printing.
<bavier>de11: I have been running guixsd on my two main laptops for several years.
<bavier>de11: guix is solid in that you can always "roll-back" to a previous state
<de11>i will try it i survived on crux with less available packages
<de11>i think its good to go and try
<mbuf>what are the minimal hardware requirements to setup a Hydra farm for Guix?
<bavier>mbuf: I'd say the requirements are on a continuum
<bavier>mbuf: minimally, you need a system that runs 'guix publish' and builds packages
<bavier>woo! finally got guix building on this aarch64 system
<mbuf>bavier, any info on what hardware people use?
<de11>i see theres no cwm in packages ,can I create a package my self or request one ?
<bavier>de11: you can do either
<bavier>de11: see the manual for GUIX_PACKAGE_PATH
<de11>bavier: ok thanks
<bavier>mbuf: has a list of current donated build slaves. rekado also runs a large buildfarm at, and efraim is running 'guix publish' on their odroid
<mbuf>bavier, thanks!
<hwpplayer1>hi people what was the GNU Guix's most important feature a programmable package manager ?
<Apteryx>nevermind my observation about gpg earlier; I got it to work using: gpg --keyserver --search-keys ...
<hwpplayer1>Can we make a conference or when do you make conferences
<bavier>hwpplayer1: conference?
<bavier>do we need a version (or otherwise) check on texinfo's makeinfo somewhere?
<bavier>I get a "Unknown command `inlinefmtifelse'`" error, which suggests my version is old.
<bavier>I'm surprised to find no suggestions in the autoconf or automake manuals on this.
***fr33domlover1 is now known as fr33domlover
<bavier>many guix tests fail if guix wasn't configured with guile-ssh
<bavier>'guix: offload: command not found'
<bavier>in a way, guix is the perfect tool to check that builds still work with optional dependencies missing
***jonsger1 is now known as jonsger
<rekado>bavier: the problem here usually is that guile-ssh was found at configure time but isn’t present at runtime.
<bavier>rekado: there's no guile-ssh on this system
<bavier>the BUILD_DAEMON_OFFLOAD automake conditional is flagged as false
<bavier>so the guix/scripts/offload.scm isn't compiled
<bavier>but somehow the daemon still thinks it can run nix/scripts/offload
***jonsger1 is now known as jonsger
***jmi2k_ is now known as jmi2k
<jmi2k>Hello. I'm trying to make a system installation as small as possible. I'm starting with just base packages and services, and it uses ~900 MiB. Is there something I can do to lower it even more?
<cbaines>jmi2k, do you know about the guix size command?
<jmi2k>no, I've been using plain old `du`
<cbaines>ok, if you build the system with `guix system build ...` you get back something in the store
<cbaines>if you then run `guix size ...` on that, then you should see a breakdown of the size
<jmi2k>that seems quite nice! let me check.
<jmi2k>cbaines: thanks, it turns out to be a perfect tool :) TIL
<bavier>rekado: figured it out. pre-inst-env is exporting NIX_BUILD_HOOK if '[ -x <...>/nix/scripts/offload ]', but always creates nix/scripts/offload, whether or not offload support is enabled
<bavier>and some race conditions in tests/workers.scm it seems
<bavier>tests/workers.scm passes about 50% of the time