<apteryx>oh right, what I want is then package-input-rewriting/spec <divoplade>Oh, and the runner will send commands such as "mkdir" to the entrypoint too. <divoplade>(-> coreutils need to be added too... adding another 20 MB) <Brendan[m]2>roptat Thats a very professional looking bug report :) <kab-7734>Trying to run .pre-inst-env but it gives me the error:"In procedure resolve-interface:no code for module (gcrypt hash)".Is there a fix for this? <roptat>aren't you in a guix environment? <kab-7734>Welcome to freenode. To protect the network all new connections will be scanned for vulnerabilities. This will not harm your computer, and vulnerable hosts will be notified. <kab-7734>[#guix] Welcome to #guix, the channel of the GNU Guix project! Be kind to everyone. Leave messages with sneek: /msg sneek help. For other things: /msg milkman[bot] help. This channel is logged at http://logs.guix.gnu.org. <roptat>ouch, your client did something wrong :/ <roptat>is it in your current environment or in a separate profile? Can you check GUILE_LOAD_PATH can find it? <kab-7734>GUILE_LOAD_PATH is set to this- /home/username/.config/guix/current/share/guile/site/3.0 <roptat>you should enter a guix environment to hack on the sources, it's way easier: guix environment guix <kab-7734>is it in your current environment or in a separate profile? Can you check GUILE_LOAD_PATH can find it? <kab-7734>GUILE_LOAD_PATH is set to this- /home/username/.config/guix/current/share/guile/site/3.0 <terramorpha>has anyone ever tinkered with menu-entries in their operating-system configuration ? <terramorpha>It seems there is currently no way of selecting which kernel to boot from at boot time. <terramorpha>This is because no --system and --load kernel flag is generated for the custom menu-entries <roptat>I guess this is mostly for other distros... ***txt_file is now known as txt-file
<roptat>would you mind sending a bug report about that? ***terpri_ is now known as terpri
<zimoun>rekado_: does the parallel-build? set to #f by default could go to staging? since it is going to freeze now ***daviid is now known as Guest5988
***Guest5988 is now known as daviid
<apteryx>sneek later tell civodul: about that package-rewriting-inputs, I ended up getting: 1 output (/gnu/store/...-binutils-2.24') is not allowed to refer to path `/gnu/store/...-glibc-2.28' <apteryx>from inside the drv, that is because there was an allowedReferences like: ,("allowedReferences","out /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31"). <apteryx>Wonder if we could get those rewritten as well. <apteryx>(I'm attempting to rebuild a package using glibc-2.28 rather than the current 2.31) <apteryx>ah, this is because of the #:allowed-references given on the binutils-final package; since it's not part of the inputs, it is left untouched <wleslie>does anyone have automake packaged for guile at version 1.15.1? *raghavgururajan says anyone is welcome to listen though. Just a song. 🤷♂️ <yasu>Which Guix channel should I subscribe to, in order to take advantage of the binary cache from continuous integration? <yasu>sorry I haven't seen anything :-( <Brendan[m]2>I understand now what your a doing. Channels is actually a different concept. Channels means other third party repositorys of package definitions. its similar to PPA's with debian/ubuntu <yasu>Hmm I still don't understand: <yasu>This command : guix install ghc <yasu>The command guix install ghc <yasu>takes a long time to finish so I want to use the version already compiled by the server. <yasu>But I don't know what my current "substitutes" settings are <yasu>I have not done anything so I hope some default cache server is set <yasu>yasu@surface ~/co/guix$ guix pull <Brendan[m]2>ill try build ghc myself and see if mine does the same <Brendan[m]2>when you ran guix pull, did it download stuff from ci.guix.gnu.org? <yasu> /gnu/store/swmhs184zg6r6av8lddl9q2x3knr4axp-guix-cli-modules.drv <yasu> /gnu/store/0nj8bk4ycc376xvyiaqzap7k5zdskzjl-profile.drv <yasu> /gnu/store/1rkjpas18845709q1x1bbvhz5dylqzzw-inferior-script.scm.drv <yasu>8.5 MB will be downloaded <yasu> guix-manual 4.6MiB 387KiB/s 00:12 [##################] 100.0% <yasu> guix-core 1.3MiB 254KiB/s 00:05 [##################] 100.0% <yasu> guix-extra 2.0MiB 287KiB/s 00:07 [##################] 100.0% <yasu> module-import-compiled 9KiB 872KiB/s 00:00 [##################] 100.0% <yasu> module-import-compiled 109KiB 193KiB/s 00:01 [##################] 100.0% <yasu>I see things like this so I guess yes? <yasu>See in NixOS, there are channels such as production and unstable <yasu>I was wondering if there is an option in Guix that would give you mostly updated (say a few days behind the latest) in which most of the packages are guaranteed to be pre-compiled by some cache server <Brendan[m]2>Guix is currently doing something a bit ugly by default in that it updates to the latest master the same way the build server does, so its possible that you start downloading ghc before the server has even gotten around to building it <Brendan[m]2>Yes, rekado_ actually made a script that can do something similar <yasu>I am so uncomfortable with IRC - this thing is so hard to use... <apteryx>yasu: there are many clients available, but yes, it can take some getting used to! <Zambonifofex>yasu: I personally like to use IRCCloud, which I feel like provides a nice user interface. <Brendan[m]2>yep, so mine is also going to build ghc too. looks like its not available yet, or maybe its even broken <yasu>Is there a way to identify the last good commit-id in which everything compiled? <yasu>Is there a way to subscribe to only the series of commit-ids in which everything successfully compiled in by the cache server? <Brendan[m]2>i think this information is available but im not sure how to get it exactly <apteryx>yasu: nothing ever *all* successfully compiles for the total 15000 something packages; as some packages are in need of attention. <apteryx>but what you are asking I think is the ability to be able to 'guix pull' to a revisition of guix that has substitutes for all of your packages of interest (your profile packages, a manifest, etc). <Brendan[m]2>last i heard on average 5% of package are broken at a given time <apteryx>that's a commonly requested feature but it hasn't been implemented yet <ryanprior>but there is no end-user client for it yet afaik <apteryx>there's currently 'guix weather', which can give you a feel of how much substitutes coverage is available for your *current* guix revision. <yasu>oh i c, let me read more about this! <yasu>is it possible to install using the latest available package from the server? <yasu>guix install ghc --use-latest-from-ci <yasu>NixOS is overall much faster - do they simply have higher quality packages? <yasu>(faster in terms of installing packages) is it due to some kind of trade-offs in play? <ryanprior>I would like to have better performance in Guix, especially in building a profile from a manifest. But doing the profiling and tuning work to make that happen is a low priority for me at this point, and I don't know much about the internals of the Guile VM. <ryanprior>I think that's more or less the story though - hasn't been much investment in performance, it isn't measured and tracked over time afaik, so we don't notice when things get faster or slower except anecdotally. <Brendan[m]2>most of the time is spent doing thinks like building the manual page database <yasu>So, when a package like GHC (or some web browser, God forbid!) is not compiled yet by the server and if you are using a slow laptop '=D , what do you do? <yasu>I wonder if you go add some commit-id in channels.scm and guix pull --allow-downgrades or something? <Brendan[m]2>there is no --allow-downgrades. you can pull to any commit regardless <yasu>I forgot the exact command name but I used it before <yasu>I had to do so in order to fix the versions of both Guix and NoGuix <Zambonifofex>Apologies for interrupting, but I need to sleep soon! Feel free to respond whenever, though! <Zambonifofex>As some of you might have seen on #hurd, I was able to get Guix (with Hurd) running on actual hardware! 🎉 Now, before I get to do things with it, I wanted to try doing things on QEMU to make sure things don’t go too poorly. <Zambonifofex>Unfortunately, running `guix pull` fails with an error. Is that expected? <Zambonifofex>This is the error I get. (Apologies for the image URL, I can’t copy from QEMU.) *Zambonifofex goes to sleep. 💤 <lafrenierejm>Anyone know why I would be getting this sort of error all of a sudden on all `git fetch`? <Brendan[m]2>that is apparently the port for the http proxy for herd <lafrenierejm>`curl www.gnu.org` gives "curl: (7) Failed to connect to 127.0.0.1 port 8118: Connection refused" <lafrenierejm>Brendan[m]2: No, I haven't intentionally enabled any proxy and haven't done `sudo guix upgrade` in quite a while. <lafrenierejm>nyxt (browser) continues to work just fine without any config changes. <Brendan[m]2>guix environment --ad-hoc --pure curl -- curl www.gnu.org <lafrenierejm>I had completely forgotten about having set that env variable while I was messing with privoxy. <lafrenierejm>I have since decided against using privoxy and removed it from my profile, but forgot to cleanup those variables. <erkin>So I generated a patch that fixes a filed issue. How do I reference the issue when I mail guix-patches? <Brendan[m]2>I think you can just email it to hat bug post CCing the poster <erkin>So I directly e-mail the patch to xxx@debbugs.gnu.org? <erkin>Oh, I put [bug#xxx] in the title. <Brendan[m]2>either that or just notice in the email a link to the issues.guix.gnu.org page <Brendan[m]2>but i think responding to the bug report thread is correct. you can then see it on issues.... <zacts>I really want to run guix on my rpi4 <rekado>erkin: you don’t need to put anything special in the title <rekado>by sending an email to bug-guix@gnu.org all this is handled for you <rekado>for an existing one you just send mail to XXXX@debbugs.gnu.org <erkin>I sent it to guix-patches after all. <erkin>It was a patch for an existing bug. <rekado>then it would have been probably better as a reply to the existing bug address <rekado>I get a 502 trying to access the git repo <efraim>seems to be working now, I just pushed two commits <sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: about that package-rewriting-inputs, I ended up getting: 1 output (/gnu/store/...-binutils-2.24') is not allowed to refer to path `/gnu/store/...-glibc-2.28' <efraim>that was followed up with something about it refering to a somewhat specific glibc-2.31 <rekado>for 41140 I guess I just need to bind and re-export “delete” <civodul>rekado: ah yes, 'delete' in 'modify-services' would be nice! <efraim>we've had a couple of requests for beaglebone black images, I'm building the example one from (gnu system examples beaglebone-black) on my pine64 <efraim>so it may suffer from the aarch64->armhf issue but we basically have a couple of volunteers to test it :) <zimoun>janneke, civodul: thank you for this amazing blog post about Hurd. This morming I took the time to read it and try some commands. So neat! <zacts>ah I see, so the rpi4 requires non-free firmware? <zacts>hm... I might try the beaglebone instead <Brendan[m]2>do you work on it for enjoyment or because you think it or something like it will replace linux? <ani>even though I have "export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale" in my .bash_profile, I get the following warning "substitute: /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)" <PurpleSym>mbakke: Sorry about python-chardet. Should’ve checked `guix refresh` and added a note. I’m not entirely sure how to read its output though. It talks about rebuilding 229 packages and 508 dependent packages. Do I have to add these numbers? <mbakke>PurpleSym: for Python packages that have a Python 2 variant, use 'guix refresh -l python{,2}-chardet' to get the actual rebuild count. <mbakke>PurpleSym: only the number '508' is interesting from your example :) <mbakke>anyway no worries, I should have known/checked too :) <PurpleSym>Oh, you’re right, there’s a Python 2 variant as well. Thanks :) <Brendan[m]2>raingloom I synopsis like (synopsis "This is an implementation of WireGuard in Go") should be written like "Wireguard implementation written in Go" <raingloom>Brendan[m]2: i guess, but that's a very insignificant change. <numerobis>ani: do you get the warning when running commands as root, or as your normal user? ***NinjaTrappeur1 is now known as NinjaTrappeur
<numerobis>ani: at some point, I remember that I had the same issue, and I had to 'sudo su' then 'export GUIX_LOCPATH' before running 'guix system reconfigure'. I no longer have this issue, though. <ani>Brendan[m]2: yes, but let me troubleshoot as per numerobis's guidelines. <rekado>Brendan[m]2: I can only speak for myself, but when I work on the Hurd it is because I think it’s a great idea (e.g. fine-grain virtualization by design) that is only hindered by a lack of volunteer time. <rekado>Brendan[m]2: it is already usable for some real-world applications, and it has great potential for user freedom (me = user) that I’d love to see realized. <rekado>if I can help it along for a little bit of the way and others do the same when I don’t, we’ll eventually get there. <rekado>Brendan[m]2: one thing that’s exciting to me, for example, is that Mach could run on several different machines that together form *one* computer with distributed resources. The Hurd servers don’t need to implement anything special to make use of that feature. This is SSI (single system image), and it has applications for when you want a collection of small computer cards to cooperate. <rekado>Not as a Beowulf cluster but as a single system providing the sum of all resources as one computer. <rekado>performance is suboptimal unless you have fast local networking, but a variant of this is now again touted as the future of bioinformatics: a shared memory architecture <rekado>the fact that this is pretty *easy* to accomplish with the Hurd — the *only* multi-server microkernel system with a POSIX persona! — is intriguing and exciting to me. <kabui>I have my-hello package and also the GUIX_PACKAGE_PATH is set,but running guix package -i my-hello results to "unknown package" yet --install-from-file works <rekado>kabui: does the file define a Guile module? <apteryx>civodul: re package-rewriting-inputs, yes the problem I hit was that some packages such as binutils define the #:allowed-references in their arguments and refer to packgaes such as glibc-final there, which are not rewritten by package-rewriting-inputs <zimoun`>rekado: really interesting perspective: shared memory architecture using Hurd! <janneke>rekado: yes, that's an amazing perspective <civodul>apteryx: hi! but really, if you're planning to run code not built through Guix, this is not going to help <civodul>in general, you should choose between the host distro toolchain and the Guix one <civodul>rekado: MINIX 3 (the one many of us run on their machine...) also has a POSIX personality <civodul>but the great advantage of the Hurd is that it has a full-blown libc, and porting stuff from GNU/Linux requires little to no effort <zimoun`>civodul: playing with ’(package-with-c-toolchain p toolchain)’ then toolchain is a list. How can I easily get it from the package gcc-toolchain? <civodul>zimoun`: just `(("toolchain" ,gcc-toolchain)) <zimoun`>ah! yes that makes sense. :-) Thanks <apteryx>civodul: my use case was using libleak.so (built with Guix and guix pack'd for --system=armhf-linux) which is supposed to be used with LD_PRELOAD=libleak.so /usr/bin/target-app, where target-app was built using Buildroot <apteryx>The failure I was getting so far was that target-app was looking for glibc symbols in the glibc of libleak.so (version 2.31 from Guix). So my reaction was to build libleak.so with the same glibc as the one used by Buildroot (2.28). <apteryx>but you have much more experience with C libraries hacking than I do, so I'll trust your word that this wouldn't have worked anyway. I'll add a libleak package to buildroot! <civodul>zimoun`: looks like 'tcc' expects an input named "libc", which it now lacks <wleslie>has anyone tried porting the cross environment patch to gcc 10? <zimoun`>civodul: ah yes… so it is no simple. :-) Thanks <civodul>zimoun`: that's what you get with custom transformations! <civodul>wleslie: yeah it shouldn't be difficult to port <zimoun`>I thought that clang-toolchain could be a drop-in replacement of gcc-toolchain. *jonsger freed 1.7T with `guix gc` :P <jonsger>yeah, I deleted the cuirass gcroots folder otherwise they weren't released... <oliverp>I think there must no understatement that this represent quite an achievement hehe <leoprikler>The software I'm packing has a [GPL | GPL-compatible | non-GPL compatible] license. <civodul>leoprikler: the same one? or is there a trap? <leoprikler>I feel like there's some catch to this, since the guix pack may pull in GPL'd software. <leoprikler>I haven't looked at all of it, but the one I currently generated at least contains gcc:lib <oliverp>despite what some folks might say I think or say Hurd could be "beast" <leoprikler>It also contains some GPL2+ libraries, which are pulled in through some unknown corners. <civodul>leoprikler: doesn't it make more sense to say that the pack contains software under licenses X, Y, and Z, rather than talk about "the license of the pack" as a whole? <Zambonifofex>oliverp: Not sure if you’d been following #hurd, but I was able to get Guix with Hurd running on my computer recently! (Actual hardware.) <oliverp>zambonifoxfex: Thanks seems really cool. <Zambonifofex>Now I’ve been trying to get `guix pull` to work on QEMU before trying to run it on the computer I installed it. <oliverp>mind if I ask what hardware you got Hurd running on? <oliverp>Like a blog or something on subject might be interesting hehe <Zambonifofex>Ah, well, I’m not the first to achieve that or anything. 😅 I also don’t have a blog either! <oliverp>A really, a Samsung computer hm. What cpu? <Zambonifofex>Well, “impressive”, but it’s not my feat! It’s the feat of others who worked on Hurd. It kinda mostly just worked by default. <Zambonifofex>All I really had to do was change “hd0s1” to “sd0s1” on a line on GRUB, and it worked well. <Zambonifofex>Also, to whomever might be able to help me: I’m still unable to run `guix pull` on Guix on Hurd running under QEMU. If anyone has any idea of what the problem might be, I’d really appreciate any kind of advice or help! <Zambonifofex>The error remains more or less the same — a build failure. <leoprikler>civodul: under "normal" circumstances yes, but when it comes to copyleft licensing, wouldn't you have to distribute the entire pack under [insert copyleft license here]? <zimoun`>civodul: how can I easily create another C toolchain? For example, I would like to replace gcc by tcc (or pcc). Trying diverse double-compiling. But ’(make-gcc-toochain tcc)’ fails and ’(inherit gcc) (inputs [delete gcc, add tcc])’ fails too. <apteryx>leoprikler: I don't think the pack is considered a combined work; it's just a distribution of a bunch of packages <apteryx>so individual licenses of the packages within the pack should prevail <lemes>hi everyone, I decided to package this R package: calculus. So I wrote it and was able to install it using "guix package --install-from-filhow do I proceed now? <rekado>lemes: add it to gnu/packages/cran.scm <ani>numerobis, Brendan[m]2: I tried what you guys, exported guix_LOCPATH ? How do I run guix system reconfigure becuase its giving me error. Also I installed guix as a package manager <numerobis>ani: If you installed guix just as a package manager, you shouldn't need guix system reconfigure. This command is for guix system users, AFAIK <ani>yes in manual also it is for guix system. Let it be first I will make a package and will look into it afterwords. <rekado>lemes: if everything works please see the Contributing section in the manual to learn how to send us a patch to add that package to Guix. <zimoun`>lemes: Cool! Somehow you need to run ./bootstrap ./configure make in a fresh clone, then ./pre-inst-env guix build r-<your-package> then again ./pre-inst-env guix build r-<your-package> --no-grafts --check (for reproducibility). Then commit your addition (give a look at the format commit message with previous examples). Then “git format-patch -1” and last “git send-email --to=guix-patches@gnu.org <zimoun`>0001-blabla.patch”. Does it make sense? <lemes>zimoun: makes sense, now I'm stuck in the ./configure part <lemes>i'm getting "configure: error: Guile-JSON is missing; please install it." <lemes>it is installed so I guess it has something to do with --localstatedir=/var/ ? <zimoun`>lemes, ah because you need “guix environment guix –pure” before <zimoun`>and yeah I omitted the localstatedir, sorry. <lemes>zimoun`: I did that actually <zimoun`>hum? you did “guix environment guix –pure” and the ./bootstrap and then ./configure –localstatedir=/var/ ? <OriansJ`>day 2 of the guix tarball experiment: only 15GB of the 85GB set has been obtained; server timeouts continue to slow wget progress but even after shuf'ing the links to reduce server loads; progress remains embarassingly slow on the rented VPS <zimoun`>OriansJ`:have you seen my pastebin yesterday. It provides the list of all “checksum url” to be able to compare. <lemes>zimoun`: guix describe: error: failed to determine origin <lemes>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its <zimoun`>ok, so first you need to run “guix pull”. It could be a bit longer, so break time. ;-) <zimoun`>g_bor[m]: yes. Ah sorry your link does not work because the backtick I guess <OriansJ`>zimoun`: yes I did; however I am not able to run it using the command provided using the stock guix-1.1.0 binary (still waiting on guix pull to finish too) <OriansJ`>as this was a brand new vps using a stock ubuntu image from digital-ocean <g_bor[m]>It' just sometimes the irc bridge is not working as smoothly as it should. <OriansJ`>currently trying to get python-minimal@3.7.4 to successfully complete <apteryx>OriansJ`: I'm not sure what you are attempting (haven't read back), but you may be interested in the digital-ocean-configuration for guix deploy. <OriansJ`>apteryx: I am attempting to determine what percentage of guix source tarballs can be actually downloaded and what percentage of those actually match the checksums that guix download expects <OriansJ`>so I paid for a 200GB VPS from digitial ocean with a 100Mb/s internet connection and 1TB of bandwidth and used guix's source.json to start downloading <civodul>zimoun`: you'd need to provide a "meta-package" akin to gcc-toolchain that contains the compiler, linker, and C library <OriansJ`>Thus far; I got a shitload of 404s and timeouts but only 15GB of tarballs thus far <zimoun`>OriansJ`: the sources.json is not bullet proof. Any feeback is welcome. :-) ***pretzel is now known as hs
<OriansJ`>zimoun`: fair but this is just a rough estimate of the health of the guix build process <zimoun`>civodul: but if I only want to replace gcc by tcc (or pcc) in gcc-toolchain, with the same linker and C library. Just replace the compiler. Does it make sense? ***OriansJ` is now known as OriansJ
<lemes>zimoun`: guix pull finished, I did the guix environment guix --pure, ./boostrap and ./configure --localstatedir=/var/, still getting the same configure error <lemes>Generation 1 Oct 14 2020 11:57:20 (current) <pineapples>Hi! Would it be rude, if I interrupted and asked for help with writing a package declaration? <lemes> commit: 33c66110980adc4d582b7c86d4ce5759f3802579 <zimoun`>lemes: and “guix show guix” shows “guile-json@4.3.2” as dependency, right? <pineapples>My question is, what would you change about that code for autoconf-wrapper's package recipe to *also* symlink all other directories found in "/gnu/store/xxx-autoconf-2.69/*"? <roptat>so (find-files (dirname autoconf) ".*" #:directories? #t) <pineapples>roptat: I did add this to find-files, but then the build process yields a file exists error <roptat>ah, if it symlinks a directory, then all its content is available, so if it then symlinks a file in there, the file already exists <roptat>so... instead, I'd try to add this in the body of the for-each: (mkdir-p (basename file)) <roptat>so it'll ensure the directory in which you want to symlink exists when symlinking <pineapples>roptat, oh, so, if I understand correctly, it tries to symlink files inside a symlinked directory? <roptat>the directory itself won't be a symlink, but the content will be <roptat>yeah, with #:directories #t, it answers the list of files *and* directories, like ('a' 'a/b' 'a/c' 'd'), then it symlinks 'a' -> autoconf/a, then 'a/b' -> autoconf/a/b, but since a is a directory, 'a/b' already exists, it just follows the symlink and it's already autoconf/a/b <zimoun`>lemes: “guix environment guix –pure” then “guix help” should return “command not found”, is it the case? <OriansJ>using: /var/guix/profiles/per-user/root/current-guix-1-link/bin/guix build -c 1 python-minimal@3.7.4 <lemes>zimoun`: yes, it says "/bin/sh: 7: guix: not found" <OriansJ>which is the stock 1.1.0 version of guix <roptat>lemes, you're on fedora? I always get this issue on my work machine ^^', you have to ignore the bunch of "command not found, do you want to install X" messages when you enter a pure environment, but then it works well for configure <roptat>otherwise, the configure finds fedora's guile 2.2, instead of guix's guile 3.0 <roptat>oh, maybe it has the same kind of issues. During configure, it should tell you "found guile... /usr/bin/guile", that's a bad sign :) <roptat>instead, you want something like /gnu/store/...-guile-3.0.4/bin/guile <roptat>and the pure environment should help with that <roptat>once you've run configure, you can use a normal environment again <zimoun`>roptat: the issue is that “guix environment guix –pure” and then bootstrap and ./configure returns guile-json not found. <ani>zimoun`, roptat: I succeeded in making my first helloWorld package shown as in tutorial. So shall I write my own recipe to package "r packages", or shall I use ./pre-inst-env to make "r packages" <roptat>what I get in a normal environment is that fedora's guile is found, then guile-json is not found in the fedora system, and it's not the right version in the guix environment, that's why I thought it would be the issue <janneke>Zambonifofex: guix pull on the hurd, yes that woud be nice <roptat>ani, great! you should write your recipe in one of the files in the git repository, and use pre-inst-env. When it works, you can submit your patch! <zimoun`>lemes: could you pastebin the output of “./bootstrap && ./configure --localstatedir=/var/” and paste the link, please? <ani>roptat: So shall I submit my patch to mailing list as per manual or shall I push it to the git repo? <zimoun`>ani: you can write your own recipe and build the R package with “guix build -L path/to/folder/where/package/is/defined r-<the-name>”. It seems the easiest at first. *zimoun` is checking lemes output <roptat>ani, you can't push it to the repo :p send it to the mailing list, like the manual says <ani>Yes, I thought if I can :D <roptat>zimoun`, that's bad: configure: found guile 2.2 <roptat>yet guile is in the store: /gnu/store/wbpg666qkxhdwayssaix7jln0fs624gz-profile/bin/guile <roptat>lemes, outside the guix environment can you tell us what "type guix" says? <lemes>it says "guix is /home/magali/.config/guix/current/bin/guix" <roptat>sounds right... so in the same terminal, in a pure environment, configure doesn't work? <roptat>do you have guix or guile installed in your user profile by any chance? <lemes>roptat: sorry, I don't know what that means <roptat>did you install guile or guix with guix? <pineapples>roptat: https://paste.debian.net/1167132 - does it look alright? I'm still getting "symlink: File exists" Also, apologies for being dead-silent, but I got back to writing the wrapper as soon as you suggested what to do <roptat>pineapples, now, if find-files returns '("a" "b/a"), it will symlink a -> autoconf/a and a -> autoconf/b/a (because of filename) <zimoun`>lemes: what is weirdis that ./configure guile@2.2 and it should not. The question is why? <ani>I found mistake in doc. There is for for two times. How shall I report it? <roptat>bug-guix@gnu.org, or guix-patches@gnu.org if you can provide a patch <zimoun`>lemes: could you go out the “environment” and then try “guix environment -C guix” and then the ./configure <ani>its doc? How to provide patch? Is there tex version of the doc, which I should edit? <roptat>ani, doc/guix.texi is the soruce for the documentation, in guix repository <roptat>ani, there's also doc/contributing.texi if you're in that section <roptat>zimoun`, I suspect guix to be installed in the user profile, and that .bashrc is polluting the pure environment, so indeed a container might work better <lemes>I think PATH is messed up, cause I get "The command could not be located because '/usr/local/bin' is not included in the PATH environment variable. ", so I had to "export PATH="/usr/local/bin/:$PATH" and then proceed <ani>roptat: is texi a version of Tex? <ani>I thought GNU uses tex or groff etc? But what is texinfo, I will look into that. <roptat>lemes, the purpose of a pure environment is to get rid of any interference from the system through environment variables, so changing them back afterwards is a bit defeating its purpose :) <pineapples>roptat: I can't debug the symlink process and verify whether that's true, but that paste is a state that the code is currently in, and yet I'm still getting that error <zimoun`>lemes: what? I am lost… First could you from your fresh terminal run “guix environment -C guix” and then ./configure, just to check. Then we can investigate your .bashrc / .bash_profile and what mess ’–pure’. IMHO <zimoun`>ani: texinfo is something on the top of TeX. Another flavor as LaTeX or ConTeX are. If I understand correctly. <roptat>pineapples, try to add (pk 'file file) for instance, to see what files are being symlinked <lemes>just to confirm, I should run "guix environment -C guix" inside the guix folder I got from git, right <zimoun`>lemes: yes. And it should work. Not error expected :-) <ani>zimoun`: Okay got it. I am trying to send the path for the manual error, will look into contributing.texi <roptat>(lemes you might get some warning about some programs not found, ignore them and say "no" if ubuntu proposes to install them) <lemes>ok, ./configure worked just fine <ani>roptat, zimoun`: Also, am I supposed to pull whole git repository of guix and work as in local repository, or shall I just define package and then commit the changes but I guess that won't be helpful. I am confuse in this matter. Please enlighten me on this subject <roptat>before you can send a patch, you need to have the git repository, so the easiest way to contribute is to clone the repo, run bootstrap, configure, make, do your changes, try with pre-inst-env (guix build and guix lint your package), then commit and produce the patch with git format-patch <zimoun`>so the issue is from your config in PATH or related. <roptat>for the manual though, you don't need to make or use pre-inst-env <roptat>just clone, make your changes, commit and send patch :) *roptat needs to go, see you later! <pineapples>roptat: I added (pk 'file file) between (for-each (lambda (file) and (mkdir-p (basename file)), and the output now yields this line: ;;; (file "/gnu/store/xxx-gcc-7.5.0-lib/gcc/******") <pineapples>roptat: Thanks for help, and until the next time! <zimoun`>lemes: could you pastebin “guix package -A” and “env” and paste the link? please. <zimoun`>argh! I am failing to build locally the website. Warning: “;;; In procedure load-thunk-from-memory: incompatible bytecode version” . How can remove that? <zimoun`>ani: in any case, you need to clone the repo. So first try to clone. :-) <zimoun`>Ah sorry, I was meant -I, I always mix the both <ani>zimoun`: Yes, cloning the repo. <zimoun`>lemes: it was –list-installed (-I) and not –list-generations (-l). Subtile :-) But does not matter. The culprit is “guile@2.2.7” that you installed yesterday. And then GUILE_LOAD_PATH is set to “site/2.2” <zimoun`>what is weird is that “–pure” does not bypass it. So it should come from your .bashrc or .bash_profile <Zambonifofex>Is it normal that the Hurd image available for download appears to have exceptionally limited available disc space? It seems to have only less than two hundred MB available, at least on QEMU. <Zambonifofex>I get a `guix install: warning: at least 381.0 MB needed but only 194.3 MB available in /gnu/store`, and then later it fails with an error about there not being enough space. <ani>zimoun`: How to write commit message in GNU projects, must be in present tense as wide spread practice as well as anything specific <ani>like "fixes error in Guix manual line 10108"? <civodul>zimoun`: i think tcc has a built-in linker, so i'm not sure it makes sense <ani>civodul: How to write commit message in GNU projects, must be in present tense as wide spread practice as well as anything specific <lemes>zimoun`: I'll see what I can do. thank you for your help. if I get stuck at it, I'll come back and ask :) <ani>civodul: I mean is there any specif way to or guideline while writing commit message. ? <civodul>(make sure to add a question mark next time :-)) <ani>Noisytoot: thank you <roptat>ani, you would use "doc: Fix typo." as title, then "* doc/guix.texi (section): Fix typo." after a blank line <zimoun`>ani: “git log --grep=doc” could provide you inspiration. BTW, for the one you want to fix, it is something like “doc: Fix typos.” <zimoun`>civodul: ok, I will check. It is still a bit mystorious for me… I would like to be able to illustrate the Diverse Double-Compiling strategy, with a simple example. <pineapples>roptat: The furthest I got is Guix populating the root of '%outputs "out"' with directories named after files and directories from the root of the package I'm trying to wrap <pineapples>Can't find-files be told to not traverse contents of directories we want to be symlinked? <roptat>you can try to open-dir the directory, and traverse it with guile <roptat>(you'll have to open the guile manual, I don't remember precisely how to do that) <roptat>that will allow you to simply list the files and directories at the top-level <roptat>or maybe you actually want to use a union-build (or build-union, I don't remember ^^) <lemes>zimoun`, roptat:you were right about the PATH thing. I also read these e-mails from a past outreachy intern that had a very similar problem and I could understand better what was happening: https://www.mail-archive.com/search? <lemes>now ./configure is running alright <Zambonifofex>What is the best way to shutdown a Guix system on Hurd? `halt` (from the `hurd` package) or `shutdown` (from the `shepherd` package)? Or maybe something else altogether? <ryanprior>Here's a nice article on security practices for writing Docker container definitions: <ryanprior>I share it here not only because I know from previous conversation some of y'all are Docker users… <ryanprior>but especially because if you build your container using Guix you get all these things "for free" as a side effect ***stikonas_ is now known as stikonas
<mothacehe>Hey guix! The nginx server behind ci.guix.gnu.org is proxying Cuirass web-server. It looks like it timeouts really fast, around 5 seconds without Cuirass response. The "proxy_connect_timeout" should be 60 seconds by default. <sneek>Welcome back mothacehe, you have 1 message! <sneek>mothacehe, mbakke says: are you comfortable cutting a new guile-git release? <civodul>zimoun`: ah, DDC from the command line would be fun :-), but i don't think it's possible <civodul>for instance i doubt GCC can be built with Clang and vice versa <civodul>mothacehe: i'm updating NEWS for guile-git, BTW <civodul>mothacehe: for nginx, sure we can change it <lemes>zimoun`: just sent the patch :) <nly>how do i quickly test a new service? without a guix pull? <civodul>janneke: in other news, i'm cross-building Guix against the latest Guile-Git to check if that fixes "guix pull" on GNU/Hurd <janneke>civodul: ooh, yeah that was weird -- i forgot <janneke>civodul: sorry that i didn't catch that hurd_raise fix by youpi in june either <janneke>i did the same as you, i guess, check my stale glibc checkout <janneke>(after updating and checking all debian/patches glibc trees...) <civodul>janneke: yeah np, i should have pulled before i guess, i'm learning :-) <civodul>thing is, people keep repeating the project is inactive so you think your checkout is necessarily up-to-date ;-) <janneke>the work being done on libc-alpha is impressive <janneke>also, i really enjoy all the folks giving the hurd a spin <mothacehe>civodul: turns out timeout was 7 seconds, now set to 10. <jonsger>civodul: ehm, Phoronix at least makes an article for every release of the hurd/mach etc ^^ <mothacehe>i'm starting GUIX_DAEMON_SOCKET experiments on berlin to have Cuirass and guix-daemon on different machines <civodul>(GUIX_DAEMON_SOCKET=ssh:// is still a bit slow) <civodul>though i wouldn't be surprised if there are assumptions here and there that the files in the store can be accessed <civodul>Guix itself should be fine, but perhaps Cuirass has that <civodul>yeah, like the "evaluate" process returns a list of .drv file names <jonsger>I do cuirass (foreign) -> http -> cuirass (my own) which works nice ^^ <civodul>and then the other process prolly does read-derivation <civodul>jonsger: what do the arrows represent? <jonsger>civodul: that it's going only in one direction. I wanted to say that I use a personal cuirass server which uses substitutes from ci.guix.gnu.org... <mothacehe>civodul: and evaluating on the local store while building on a distant one seems difficult. Maybe I'll directly try to setup the coordinator then. <mfg>is it okeay to send patches to guix-patches even though they still have known problems? <mfg>or is there another list for that? <roptat>add wip in the subject, and it's fine <roptat>raingloom, if you're around: I forgot to keep you in CC when answering to your yggdrasil patch series, so maybe you didn't see it. I've pushed the first 4 patches, but you'll need to work a bit more on the rest :) https://issues.guix.gnu.org/41803#6 <kabui>Does changing the version of a package change its hash. <divoplade>Hello, I need to run "guix build" to debug my package definition but I already have it installed... How can I tell guix to forget that it has already built my package? <ss2>Can guix offload use a password protected key with ssh-agent, or does it always need to be without a password? <roptat>(if you mean the hash of the sources, not automatically, you need to do that manually before guix can build your new version) <mfg>divoplade: i had the same "problem" the closest you can get is guix build --no-grafts --check <civodul>mothacehe: yeah i guess that's the way to go, maybe cbaines started looking at it? <civodul>janneke: the "guix pull" bug is still there, looking into it... <mothacehe>civodul: now that Cuirass is more or less stabilized I'll start my experiments too! <zimoun`>civodul: yeah that’s why I would like to first illustrate with tcc or pcc. But even at Scheme level, some bits seem needed. Well, it is not as easy as I initially thought. <pineapples>Question: are configuration files in /run/current-system/profile/etc and ~/.guix-profile/etc read by any program? <civodul>zimoun`: chat with janneke or vagrantc who toyed with this before <civodul>BTW, there's another C compiler you can add to your list: mescc :-) <janneke>yeah, it's really zimoun` what you're looking at <janneke>hehe, yeah, but building tcc with mescc needs a special treatment (see tcc-boot0 build scripting) <zimoun`>janneke: well, this morming after my Blog reading about Hurd, I have gone to read the recent new about DDC that civodul linked couple of days ago. AndI thought that the new “with-c-toolchain” is a good toy for illustrating the point. <janneke>yeah, real cool idea -- even if it needs "some work" <janneke>zimoun`: note that much of the "magic" of building tcc-boot is hidden in scripts that comes with the tcc-boot0 tarball <zimoun`>yeah, I initially thought it would be “almost” straighforward… but it is not. :-) As usual. ;-) <janneke>it builds tcc with mescc once, then several times with itself, adding features (float, long long, ..) each round, until fixpoint <janneke>one day it will build in one go and be perfect ;) <zimoun`>well, the explanation of DDC by David Wheeler seems easier. :-) <rekado>it would be nice if we could use Guix System services on foreign distros. <rekado>it seems to me that there’s no good reason why that wouldn’t work <rekado>most services aren’t all that complicated, so perhaps we could just run Shepherd as root — just not as PID 1. <nly>how does one add their key to .guix-authenticate <nly>i hope this type of gpg key worksrsa2048 <janneke>interesting idea, not start guix-daemon directly, but have shepherd start it <lfam>sneek: later tell nckx: Yes, I'll take a look at #43838 (kernel support for XDP sockets) <janneke>there would have to be a place to define those services too <divoplade>Does cuirass work? I have a small config and both cuirass.log and cuirass-web.log end with an exception in fibers.scm <rekado>janneke: I’d imagine they would be defined with an operating-system configuration that would be built with “guix system build” <sneek>Welcome back nckx, you have 1 message! <sneek>nckx, lfam says: Yes, I'll take a look at #43838 (kernel support for XDP sockets) <rekado>divoplade: cuirass does work. It’s used for the build farm at ci.guix.gnu.org <divoplade>rekado: Do you think my config is correct? #~(list <janneke>rekado: just not a guix system, but a foreign system -- or something? that could work <rekado>sorry, I can’t debug anything right now <lfam>Is it expected that building Guix creates a `guile` executable in the Git tree? <rekado>janneke: right, obviously the interface for that is missing right now, but I think it would be enough to build the service graph and then start shepherd with it. <rekado>lfam: that’s new to avoid local warnings once and for all <janneke>880fe019ae build: Use a 'guile' executable that doesn't warn about locales. <lfam>rekado: That is awesome news <rekado>it’s a super neat hack by civodul <lfam>This might be the best one yet <janneke>(that broke building guix on the hurd ootb ;-) <janneke>well, you now need a silly patch, not a problem, just "funny" how everything seems related some times <civodul>re shepherd not as PID 1, that should work thanks to the prctl child_reaper thing <rekado>civodul: well, “gross” has one more letter ;) <civodul>it's actually quite easy to test if there are volunteers: you "guix system build" something, find the "shepherd.conf" out of it, and run "shepherd -c /gnu/store/...-shepherd.conf" <civodul>well that's going to try to mount file systems and stuff <civodul>and kill all user processes upon shutdown <jonsger>divoplade: can you paste the error to a pastebin, I have a look. I got experience in running cuirass :) <janneke>we'd need a new %default-operating-system-services/%essential-operating-system-services for a foreign system <janneke>but possibly not much more than that <civodul>but then there's the problem that most services in Guix extend not only shepherd but also user-accounts, activation, etc. <civodul>so you can't just take the shepherd bits <divoplade>jonsger: I'm almost sure I'm missing a required field in the configuration <jonsger>divoplade: which version of cuirass are you using <divoplade>jonsger: guix show cuirass tells me 0.0.1-52.38ee2c5 <divoplade>I just want it to build all packages defined in a specific repo <rekado>civodul: oh, right, that would require more hacking. User namespaces and all that, perhaps. <civodul>rekado: actually "guix system container" should produce something that can run on a foreign distro <zimoun`>argh, I should not start to play with Hurd, it is not on my TODO. :-) <zimoun`>trying to build something, I have a hash mismatch about binutils-2.34, is it expected? <zimoun`>and connecting with ssh I can do with Tramp and Emacs. Awesome! :-) <janneke>zimoun`: isn't that great! used it a lot while developing this <ss2>Hey, I'm having problems getting guix offload to work properly. As it stands, my environment is incomplete, that `guix offload test' will fail saying that guile modules aren't available. <ss2>But they are, and I've only found several bug reports, but I just can't figure out why my ssh connection doesn't have $GUILE_LOAD_PATH <ss2>But when I properly log in it is, but ssh $HOST env | grep $GUILE_LOAD_PATH is empty. <ss2>I have authenticated host and master, ssh seems to be okay (apparantly it isn't), and am bit lost now. <civodul>ss2: when you do "ssh HOST env", it's not the same shell start-up files that are sourced than when you log in interactively <civodul>typically on Guix System the default .bashrc has special provides for that <ss2>so guix isn't reading my .bashrc? Where to I put the $GUIX variables instead? <civodul>it's not Guix, it's the shell started by sshd on the remote machine <civodul>you can use the same trick as shown above <ss2>oh, I should have mentioned, that the offload daemon is on a foreign destribution. Hence maybe the variables are not properly exported? <apteryx>ss2: debian and perhaps other distro commonly exit from .bashrc early when run non-interactively; make sure you define the required environment variables correctly *before* that exit or remove that code completly. <ss2>apteryx: by exporting the variable before the exit clause? That isn't working either. hm.. <apteryx>The .bashrc on ubuntu for example checks $- and exits when Bash was not run interactively <nly>i've added myself to .guix-authors and signed my commits, still says not signed by authorized key ..., then goes on to mention my key in ... <apteryx>what guix does seems to be to source /etc/profile <apteryx>but then this is the /etc/profile installed by guix, not that of a foreign distro <apteryx>so you'll want to copy the interesting bits from there into yours, or directly into your ~/.bashrc. <ss2>I came across lshd early on, what does it stand for? <apteryx>it's an alternative implementatino of the secure shell (SSH). <ss2>ah, never heard of it. <Gooberpatrol66>Is there a way to create a file under an existing directory using etc-service-type? I get an error when I try <ss2>apteryx: got it working. I had to put the variables into .pam_environment. All other tries failed. 
