<rekado_>there seem to be a lot of rebuilds now ***Piece_Maker is now known as Acou_Bass
<eric23>that's what happens when I do a guix pull <sturm>Gee, magit is very slow for me on the guix repository (running on Guix SD). Any suggestions for speeding it up? <eric23>guix package -u is compiling everything <ng0>Hey, is Rémi's email still the one at free.fr like back in 2015? <ng0>if not, can someone send me an email with Rémi's current address? I have questions on a software Rémi wrote back then. I think Rémi told me a while back I could ask <ng0>what's the full MIME type for nar and narinfo? application/nar and application/narinfo? <efraim>so many new packages to test building on aarch64 <efraim>"It has been 21 years since the last release." <nee`>efraim: sounds like extreamly stable software. <rekado>Guix makes me build glibc from source. <rekado>Neither berlin nor the mirror have it. <rekado>now building ghostscript-with-cups… <civodul>rekado: yes that's what i noticed yesterday (glibc) <civodul>that's hopefully fixed in gnu-system.scm, but hydra has probably not evaluated it yet <Achylles>I have put guix image on a usb and when it loads it. It says that it is an installation image... <rekado>civodul: it seems that a lot of archived sources have disappeared from hydra as well <rekado>Achylles: the installation image is a live system. <Achylles>But, it took some time for me to understand that Guix is other OS, than Linux... <mekeor>Achylles: Guix is a package manager. the Guix System Distribution (GuixSD) is made in such a way that it can use the Linux kernel or other unix-like kernels. <mekeor>Achylles: what do you expect from a live-CD? <Achylles>I expect to load as a sample and then install if someone wants... <Achylles>In Linux, if it is not a live non-gui server. Then, yes... <mekeor>Achylles: as far as i know, we don't have any live images with a desktop environment yet. <mekeor>Achylles: but after booting the installation image, it should be possible to apply a system-configuration which includes a desktop environment.. <Achylles>I think I will install it on a debian virtualbox image first then try it, instead of in my main system... <janneke>ACTION tracked down guile-emacs segfault <rekado>janneke: I had it segfaulting with my regular configuration <janneke>yes, it's emacs bug #24065: calloc loop when compiling with -O2 <civodul>rekado: prolly because i "purged" /var/cache/guix/publish/none, but they'll come back <civodul>efraim: so there was *really* a new GNU time release, woow <janneke>efraim: guile-emacs builds with libjpeg 9 <janneke>i added: (inputs `(("libjpeg" ,libjpeg) ,@(alist-delete "libjpeg" (package-inputs emacs)))) <efraim>i wonder if emacs itself actually needs libjpeg8 and not 9 <janneke>i suppose you don't want that in my guile-emacs patch? <janneke>i cannot imagine, guile-emacs is a fork of 24.5 <janneke>ok, then i'll remove it -- best if guile-emacs just reuses most of emacs' recipy <janneke>suddenly while building guile-emacs, creation of dir: src/deps/ starts to race :-( <rekado>what do you mean by “starts to race”? <janneke>rekado: guile-emacs used to `make' fine, now it fails because src/deps dir does not exist -- a mkdir -p src/deps "fixes" that <janneke>so i infer a race/missing make dependency -- but i'm not really sure <rekado>civodul: is (car (first outputs)) really correct? <rekado>shouldn’t it be just (first outputs)? <rekado>for the regexp, how about this: "^((COPYING.*|LICEN[CS]E.*|[Ll]icen[cs]e.*|Copy[Rr]ight)(\\\\.(txt|md))?)$" <rekado>i.e. permit COPYING.txt and COPYING.md alongside COPYING. <civodul>rekado: regarding the regexp, i wanted to allow COPYING.* because sometimes there's COPYING.GPL3, COPYING.LGPL, etc. <civodul>that also matches COPYING.txt, COPYING.md, COPYING-whatever <rekado>that leaves only the question about (car (first outputs)) <fps>has there been progress with getting go packages built? :) <civodul>rekado: yeah that one was wrong, i changed it to: <civodul>it's in the unlikely event where there's no "out" output though :-) <civodul>i think it covers some of what Dave Love was suggesting, WDYT? <vagrantc>hmmm... so i'm booting the 0.13 guixsd installer usb image ... and figured it would be nice to do an install via ssh ... but ssh-keygen (presumably from openssh) isn't installed ... so i have no way of verifying the host keys <rekado>civodul: I was wondering about the same problems wrt distributing application bundles <rekado>vagrantc: on the remote you’d have to install the openssh package first. <fps>btw: upgrading via the intermediate tgz (0.13) for guix pull fails because a package isn't available on hydra <fps>i think it was tiff.. <vagrantc>rekado: but the installer is a host ... how do i verify the host keys for the installer? <rekado>fps: it’s possible that this is just a temporary problem with the mirror. <vagrantc>and of course, i've now gotten into "updating" the installer system :) kind of cargo-culting guix commands here... <fps>and of course with my old guix the --fallback option is not supported for guix pull.. but i guess i might try installing the failed package first? <efraim>We should also mark some files/directories with 'chattr +C' for CoW filesystems, like the db for the store <rekado>vagrantc: I’m not sure I understand what you mean by “the installer is a host”. <rekado>ACTION goes afk for a little while <vagrantc>rekado: i ran "herd start ssh-daemon" and that presumably is using the keys in /etc/ssh/ssh_host* ... how do i verify when i connect to that ssh server is using the correct host keys? i would usually do ssh-keygen -l -f /etc/ssh/host_*.pub or something like that <vagrantc>and then compare the results from the machine ssh'ing from <vagrantc>as opposed to blindly typing "yes" when i connect to the machine for the first time <vagrantc>also, is it generally feasible to install to the same media you've booted the installer from? <efraim>i wonder if we can parallelize the 'strip phase <rekado>vagrantc: I have never tried to install GuixSD onto the installer media. <rekado>vagrantc: do you have direct access to the host that was booted with the GuixSD installer? <vagrantc>in theory, there's no real reason it shouldn't work ... <rekado>and you cannot run the above command to print the SSH host key fingerprint? <vagrantc>ssh-keygen isn't included in the installer image <vagrantc>so i decided to install openssh, hoping it was included there <rekado>on my machine it is part of the openssh package. <rekado>(I don’t have an installer-booted system right now to verify this) <vagrantc>which then advised me to run "guix pull && guix package -u" ... and now from within the installer, i'm apparently updating a bunch of things <rekado>0.13.0 is quite a few months old and we’re preparing for a new release <vagrantc>this is certainly a bit of a learning experience in guix, which was the intention <vagrantc>are there any pre-release installer images for testing? <rekado>“guix pull” is analogous to “apt-get update” <rekado>no, there are none, but one can build them with Guix <vagrantc>yes, i was just thinking it would be really helpful to create a list of apt -> guix correlaries <rekado>one thing that trips up many people is that all of these commands are per-user. <rekado>“guix pull” as root only affects the root user. <rekado>only commands like “guix system reconfigure …” have system-wide effects <vagrantc>ACTION is happy to be stumbling through this <rekado>(like installing a new generation of the operating system and registering it with the bootloader) <rekado>but since “guix system reconfigure” must be run with root privileges, some users end up using the wrong variant of guix <rekado>I always do “sudo -E guix system reconfigure…” to ensure that my current user’s guix is used. <rekado>I *think* you could have ignored the suggestion to run “guix pull && guix package -u” at this point <rekado>“guix pull” updates to whatever is currently in the master branch. <rekado>and this could mean that packages you want would have to be built from source. <rekado>we try to keep binaries for release tags, but storage has been a problem in the past, so that’s no guarantee. <vagrantc>from what i've gathered, releases have been happening about every 6 months or so? <rekado>when bugs are encountered in releases it becomes increasingly difficult to cater for buggy variants. <rekado>“guix pull” has been changed quite a bit since the last release, for example. <vagrantc>i should probably just reboot the installer and start over :) <rekado>I don’t know what the best way forward is. <rekado>I don’t often install from scratch :-/ <rekado>another idea is to check with “pgrep -fa ssh” to see which sshd is running <efraim>I found plenty of substitutes when I installed with the installer about 2 weeks ago <rekado>get the prefix directory /gnu/store/…-openssh-…/ and run ssh-keygen from “bin” <rekado>that’s a little clunky, but works for me <vagrantc>is the installer all running in ram? mount and df aren't showing any actual disks mounted <efraim>what's the minimum version on guile we target? is it still 2.0.7? <efraim>for bootstrapping on a foreign distro <civodul>vagrantc: maybe not, there's en_US.utf8 though <Achylles>gpgv: Can't check signature: No public key <Achylles>uscan die: OpenPGP signature did not verify. <vagrantc>guess the C.UTF-8 (or .utf8) support is not in upstream glibc <ng0>why would you want just C as a locale for the user? <ng0>the build environment uses C afaik <efraim>'par-for-each' in place of 'for-each' during the 'strip phase reduced glibc-final's strip phase from 235 seconds to 215 seconds <efraim>guix/build-system/gnu.scm:436 says the locale is "en_US.utf8" <vagrantc>ng0: why would i want a specific country as a locale? <ng0>I leave that up to others to explain… <vagrantc>ACTION would like a country-agnostic locale :P <ng0>seems like you don't understand locales fully. But you can construct your own locale, even with Guix. I had an en_DK+en_US+de_DE mixture for a while didn't bother to recreate it yet <vagrantc>ACTION doesn't claim to understand anything *fully* heh <rekado>ACTION admits to not understanding locales <ng0>vagrantc: basically currency, time, delimiters, blabla set in the locale affect what's displayed in (some) applications making use of that… and more. <ng0>that's how I understand it <ng0>for example en_DK.UTF-8 is the only locale (to my knowledge) featuring the ISO format (YYYY-MM-DD) for date <eric23>how long does it take for a newly released Linux-libre kernel to be included in guix substitute? <efraim>'guix pull' followed by 'guix package -u' <Achylles>why guix does not accept TAB autocompletion on my bash? <janneke>Achylles: possibly you haven't installed the bash-completion package? <Achylles>It says that my guix version is too old... <janneke>initial install/upgrade could be smoother <janneke>that should be the command to install guix-emacs, yes <Achylles>guix package: error: build failed: unexpected EOF reading a line <janneke>ACTION is not sure if and how this error should be reported <Achylles>It is supposed to be smoother than apt/apt-get... <Achylles>substitute: ;;; Failed to autoload make-session in (gnutls): <Achylles>substitute: ;;; ERROR: missing interface for module (gnutls) <janneke>Achylles: hmm, so you don't have gnutls package available... <Achylles>guix package: error: build failed: unexpected EOF reading a line <janneke>yes, berlin.guixsd.org is one alternative <bavier>Achylles: you can do it on the command-line with the --substitute-urls options janneke mentioned previously <janneke>you can add --substitute-urls=... on most every command <janneke>once you're up, you can add it to the guix-daemon <bavier>or set it in GUIX_BUILD_OPTIONS environment variable <Achylles>I need to locate the daemon config file... <janneke>usually mirror.hydra.gnu.org is fine though, you're just hitting some rough weather <janneke>ah...then you start the guix-daemon using systemd i presume? <bavier>Achylles: iirc the debian guix package is a very old version <bavier>so substitutes might have been gc'd on the mirrors and build farms <bavier>you'd probably be better off using the binary installation method <janneke>there's probably a /etc/systemd/system/guix-daemon.service or something, you can add --substitute-urls=... there and restart the guix-daemon service <Achylles>● guix-daemon.service - Build daemon for GNU Guix <Achylles> Loaded: loaded (/usr/local/lib/systemd/system/guix-daemon.service; enabled; v <Achylles> Active: active (running) since Wed 2017-11-08 16:53:54 -02; 49min ago <Achylles>I will install guix using the binary method tomorrow. My version is old... <civodul>janneke: hey! so i broke things on hydra.gnu.org uh <janneke>civodul: possibly, not sure. never sure with these things, Achylles was possibly using ancient .deb package <mekeor>is a mcron-service obligatory for the rottlog-service to work? <civodul>janneke: the 404 tarballs on hydra.gnu.org are my fault <civodul>it should auto-repair but it takes time, so i'm "forcing a repair" right now <civodul>that is, repopulating the 'guix publish' cache <janneke>i mean...we still often present newcomers with a pretty rough start <civodul>i agree, although there are issues i (re)discover only when i switch to a different machine <civodul>like the glibc rebuild we discussed earlier <efraim>is there a way to not strip the static output of a package? <civodul>janneke: so i think it's important to identify and write down all these issues newcomers face <civodul>because we as developers don't necessarily encounter them <civodul>and sometimes we're just used to them, which is terrible <janneke>that is exactly why i pinged you...we want some convergence esp. on these silly fresh install problems <janneke>but "we" never do that...it seems to be so much easier when you're "in" <efraim>we can add the "static" output to the "don't strip me" list, at guix/build/gnu-build-system.scm:400 <buenouanq>I can't guix pull right now either - Fails compiling at 75.2% `due to signal 9 (Killed)'. <vagrantc>ng0: yeah, i get that locale affects all that. heh. none of that really matters to me much. and you're not on irc now. oh well. <rekado>vagrantc: you are vagrant of debian fame, no? <vagrantc>ACTION still isn't convinced that C.utf8 isn't reasonable <vagrantc>rekado: i don't know about fame, but yes, i've got some solid roots in debian :) <vagrantc>rekado: the reproducible builds summit reminded me that i should really check out guixsd <rekado>we usually don’t patch upstream packages with extra features; if upstream doesn’t provide the C.utf-8 locale then we also don’t – for better or worse :-/ <vagrantc>a little bumpy so far, but still really exciting <rekado>vagrantc: yeah, looks like you already took a look at our razor-sharp corners. <vagrantc>having a bit of trouble getting the right syntax for an encrypted disk in the installer configuration <rekado>the initial installation is the worst part of it all. Everything else is just an acquired taste. <rekado>I have a fully encrypted disk and I unlock it with libreboot <rekado>I can share my os config with you <vagrantc>rekado: does it need to decrypt the rootfs from the bootloader, or can it be done from initramfs? <rekado>I have to decrypt it twice: once in libreboot to access /boot, then again from the initrd when booting. <vagrantc>ACTION just took the example lightweight-desktop.scm and tweaked it a bit <rekado>in the paste you see that I have one mapped device (line 78) and the root file system (line 83) depends on it. <vagrantc>ACTION vague recalls grub being able to handle encrypted disks, but has never tried <rekado>against parenthesis overload I recommend Emacs with paredit. <vagrantc>adventures in installing within the installation system have prevented me from getting too far with that so far <rekado>for the initial installation I do recommend keeping it simple. <rekado>reconfiguring the system after the initial install is safe and much more fun than fiddling with the installer. <vagrantc>yeah, maybe i should drop the idea of encrypted disks for now until i get a few working installs :) <vagrantc>ACTION has some history working on installers ... maybe could contribute at some point <efraim>i often run `guix system build os-config.scm' to see if my syntax is right <rekado>we have an almost usable ncurses-based installer, but I’m sure there’s more that we can do in that area. <civodul>also i really like the idea of statically detecting mistakes, providing hints, etc. <rekado>efraim: unfortunately, we don’t have mount checks yet; so while the syntax may be fine, we can’t guarantee things will work yet <efraim>also, reconfigure unmounted my swap, had to remount it <vagrantc>i've got a handful of arm devices to torture, er, experiment with <rekado>my bad, the result was the same for me: could not mount (because of missing modules). <civodul>efraim: you cannot inherit conditionally based on (%current-system) <civodul>because (%current-system) will always have its default value at this point <civodul>you could do a magic trick like we do for 'glibc', but that's not recommended <efraim>It'd probably be better to have a special default grub package per architecture then <vagrantc>hrm. i've got an instantiated system on an encrypted device, but can't get the syntax for mapped devices correct... and don't have a /boot that grub is likely to be able to read... but other than that, this is going well :) <vagrantc>can i re-instantiate it on another device without re-downloading and recompiling everything? <vagrantc>whenever i try to add the mapped device, i get this when running guix system init /mnt/etc/config.scm /mnt: /mnt/etc/config.scm:25:2: error: invalid field specifier <vagrantc>ACTION struggles to get a working setup to paste... <vagrantc>it "works" if i comment out either mapped-device entry <vagrantc>of course, i end up with an un-unsable system <civodul>vagrantc: so it should be something like: (operating-system (mapped-devices (list (mapped-device ...)))) <civodul>note that the first one is plural, the 2nd one is singular <vagrantc>should re-running "guix system init ..." multiple times be problematic? <vagrantc>alright, booting... grub managed to decrypt the disk after prompting for a passphrase, loaded kernel and initrd... but didn't find rootfs ... and i'm at a guile prompt <vagrantc>hmmm.. comparing against rekado's config, looks like i should have added some kernel modules and maybe other things <vagrantc>and probably added (dependencies mapped-devices) to the filesystem for rootfs <happy_gnu[m]>how do I calculate this (sha256 (base32 "1svzlbz2vripmyq2kjh0rig16bsrnbkwbsm558pjln9l65mcl4qq")) <lfam>The basic use is `guix hash foo` <kyamashita>Are there patent-related reasons why we don't build Totem and LibreOffice with gst-plugins besides base and good? <lfam>kyamashita: I don't recall previous discussions, but I think we can expect a high rate of security issues and defects in the the bad plugins <lfam>As for patent issues, we usually ignore them <lfam>At least, that's my understanding. I don't recall anything in Guix blocked by patent issues <rekado>vagrantc: the (dependencies mapped-devices) is important <rekado>otherwise it won’t know that it has to map the device before accessing the root file system <rekado>happy_gnu[m]: depends on which you use <lfam>happy_gnu[m]: You can use either one, it's up to you. If you use the Git repository, you have to check out the commit you want to build from and then use `guix hash --recursive --exclude-vcs foo` <lfam>You don't need to choose a format option <lfam>All the packages use nix-base32, which is the default <lfam>I'm struggling with the CMake update for core-updates. There are a handful of tests that fail non-deterministically <happy_gnu[m]>so my package should look like this (sha256 (nix-base32 "hash")) <lfam>No, (sha256 (base32 "...")) <lfam>'nix-base32' is the wording used for `guix hash --format=` <happy_gnu[m]>how can I send you a recipe for you to check if there is something wrong <happy_gnu[m]>the recipe for sly, which is the deprecated package and not maintained anymore <vagrantc>what magic do i need to chroot into a guixsd system... the paths don't appear to be set up at all <lfam>happy_gnu[m]: I don't know, either. What happens when you try to build the package? <lfam>Aha! That will help you answer these questions :) <happy_gnu[m]>lfam: I am not sure how to do this, I think I should have a clean enviroment right? <lfam>Where is your code? Is it in its own directory, or is it in a Guix source code directory? <happy_gnu[m]>I have to put that on guix source code directory, with guix import ?? <mekeor>it has been some time since i installed my GuixSD with full-disk encryption. i don't seem to have a boot partition. so how is grub encrypted and started then? – i guess grub is ony my encrypted root-partition. <mekeor>s/how is grub encrypted/how is grub decrypted/ <rekado>mekeor: on my machine this happens through libreboot <mekeor>how does it work on my computer? i don't understand my computer :O <rekado>have you booted this system before? <vagrantc>does grub prompt for a password when you boot? <mekeor>yes. i type in my password twice. once for grub, once for linux. <vagrantc>ACTION would guess that grub isn't encrypted, just reads the encrypted luks partition <vagrantc>at least, that's what i'm observing on my first grub install...