IRC channel logs


back to list of logs

<nckx>raghavgururajan: Using begin & end could be something like (substitute "foo" (("\\['engine', .*, libdconf_mock\\],$") ""))
<nckx>You could golf this to ridiculous extremes but don't, keep it reasonable.
<nckx>Including the $ matches the trailing newline, so the line will actually be removed, not replaced with an empty one.
<nckx>raghavgururajan: Having seen the whole file, I'd write (substitute* "" (("^ \\['engine', .*$") "")) now.
<nckx>The last ‘word’ doesn't matter, we care about the ‘engine’ entry.
<nckx>I am.
<dftxbs3e>marusich, I got
<dftxbs3e>marusich, I'm about to try them now
<marusich>dftxbs3e, I looked for a few minutes on the GitLab site to try to see where I could give myself push access, but I can't find it. Do you know how to do that? I can't push to ssh:// on a branch with my arbitrary name (wip-marusich-be1)...SSH key is associated with my user, though.
<raghavgururajan>nckx: I wanted to remove test 10/13, as it times out. But it doesn't skip despite remove the line.
<dftxbs3e>marusich, I'm thinking your key is misconfigured locally, do you use an ssh-agent?
<dftxbs3e>do you get any error?
<dftxbs3e>push access is default when you added your key, and I made you maintainer of the project which means you can do everythng
<dftxbs3e>that's you, correct?
<nckx>raghavgururajan: My quickly typed snippets are meant to help you but they're not bug-free final code 🙂 I see you copied my ‘, ’ (two spaces) typo. But see my later remark. I think including libdconf_mock at all is ‘wrong’. Use the second snippet, and let me know if it still fails.
<raghavgururajan>nckx: xD
<nckx>What I do to debug substitutions is dirty: I add (invoke "punt") as the next line so the build fails, then invoke ‘guix build -K <package>’. Guix will tell you, in a Note: near the end, where it put the intermediate build files and you can inspect them.
<nckx>Now you can feel dirty too.
<marusich>That is me, yeah. I do use an SSH agent. It works for pushing/pulling to/from Savannah, but I'll try again.
<raghavgururajan>nckx: It worked. :-)
<nckx>Cool beans.
<dftxbs3e>marusich, do you use the same key for savannah and gitlab? Some times I get conflicts because I can't explicitly pin a key for a remote repo
<dftxbs3e>That is, when I use different keys for the same remote (say two gitlab accounts)
<tho1efx>How do I lookup info for the symbol or key that is under my pointer in emacs?
<marusich>dftxbs3e, I got it working. I entered an incorrect url for GitLab in the git config. The single change is now on branch 'wip-marusich-be1'.
<tho1efx>C-h S doesn't see to
<marusich>The "BE1" part is just a way for me to keep track of what changes will go where. BE = big endian. LE = little endian. And 1, is the first goal I want to achieve, which is to make it possible to build (hopefully reproducibly) the bootstrap binaries.
<dftxbs3e>marusich, great! I'm almost finished patching GNU Guix to use the new bootstrap binaries, I'll also push to a branch
<marusich>OK. The bootstrap binaries you produced have a different store hash than mine, but it could just be becuase the way in which you applied the simple change resulted in a different hash (e.g., if you didn't include the copyright line that I added, it would probably change the hash).
<dftxbs3e>marusich, hmm
<dftxbs3e>I'm not sure comments change store hahses
<dftxbs3e>hashes *
<marusich>Well in any case, it's the content hashes that matter, and if you try using the exact commit I just pushed, it might be different. Mine was: /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0
<tho1efx>C-h f seems only to bring up information for emacs lisp versions of functions despite having turned on guix-devel-mode
<marusich>The real question is, is the content the same? The sha-512 hashes are here:
<dftxbs3e>marusich, - I'll try building from your branch exactly
<marusich>Since you said your system is an amd64 system, I'm guessing it means the Guix "system" is x86_64-linux, right? That's what I'm using.
<marusich>yeah that would be best
<marusich>sorry for the extra work
<dftxbs3e>marusich, yes the server I used is x86_64-linux
<marusich>Looks like they are all the same except for gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz. That's also what I observed earlier when I tried to reproduce the binaries you built (using your original set of changes, with the guile that segfaults).
<marusich>I guess I'll expect the same results from my local build
<marusich>I need to step away for a little bit. I'll be back in an hour or two. My build will take a while, anyway.
<dftxbs3e>marusich, okay! see you
<dftxbs3e>guile 2.0 worked, so that's good, as efraim previously said
<dftxbs3e>efraim, btw do you want access to a beefy ppc64 VM?
<marusich>By the way, in the meantime, I had a few questions I was hoping you might be able to answer. (1) Why was it necessary to use gawk 4.2.1? (2) what are the bootstrapping implications of using gcc-7 instead of gcc-4.9 to build libstdc++-boot0 (maybe this is more of a question for the #bootstrappable people)? (4) At what point was it necessary to apply change 36104b56b8 "Use /ld/ instead of /ld64/ for powerpc64-linux" and why (I'm
<marusich>wondering if we really need it in order to generate usable bootstrap binaries, or if it's necessary for bootstrapping some problematic packages later on)?
<marusich>I can't count, but ignore that fact.
<dftxbs3e>marusich, there was a bug with gawk trying to spawn a non-existent sh binary (in the context of GNU Guix's bootstrap), and gawk is used to build glibc
<dftxbs3e>I don't remember if gawk version change was necessary, but the ld thingy for sure was, I think it's what caused the sh No such file or directory error in the first place, but I tried multiple things without reverting them (like bumping gawk version maybe)
<marusich>And the bug manifested with 5.0.1 but not 4.2.1? Other systems are using 5.0.1, so it seems fishy that we'd need to use 4.2.1 specifically for powerpc64
<marusich>Hm, OK. So you found this bug only after trying to use the bootstrap binaries to build stuff, right?
<dftxbs3e>marusich, oh! I remember that now. Basically Glibc explicitly tests on 4.2.1 and any other version is supported, and it appears I was meeting a bug with it
<dftxbs3e>any other version is unsupported *
<dftxbs3e>marusich, yes, only after using them
<dftxbs3e>We'll find out, as I'm using them right now
<marusich>Huh. Interesting. So you think the other platforms just happen to bootstrap OK using 5.0.1, but it ws by accident?
<dftxbs3e>marusich, I don't think other platforms bootstrap with 5.0.1, it may be what it is in GNU Guix's source code now, but nobody tests bootstrap continuously
<marusich>hah, that's fair
<dftxbs3e>GNU Guix's bootstrap-tarballs are built once and never again
<dftxbs3e>We should definitely pin the version to 4.2.1 as Glibc explicitly says that's the version they test (at least in the Glibc version I tried to build back then), and it actually causes bugs not to use 4.2.1
<marusich>I see.
<dftxbs3e>GNU Guix patches absolute /bin/sh or /bin/bash paths with relative paths so that it can supply arbitrary binaries without having to use a chroot or replace system binaries
<dftxbs3e>So I remember trying to fix an issue with that, by patching more areas where it referenced /bin/sh or /bin/bash in GNU Awk source code, but I don't remember if that worked - and then I met a bug somewhere later after bootstrapping with ld path, so I had to change it. I don't remember which package it was.
<dftxbs3e>But either way, that ld path patch is necessary, since it's what's defined somewhere else in GNU Guix, I think gnu/packages/bootstrap.scm
<marusich>OK. My only concern with changing from gawk 5.0.1 to 4.2.1 was that it would also change the gawk version used when building bootstrap binaries for all the other architectures, too. Maybe that isn't as bad as it sounds if it's the recommended version.
<marusich>At the very least, perhaps it would be prudent to confirm that the bootstrap binaries can at least be built for the other platforms after that change (assuming they can even be built before that changes).
<dftxbs3e>marusich, don't worry about that because they arent tested continuously and their hashes change regularly, what matters is the ones that were built once and uploaded
<marusich>I guess that's true
<marusich>we can always go back in time to the commit that was used to build them
<dftxbs3e>I think they're built continuously but not tested
<marusich>yeah you're right
<marusich>by the way, purely for my own personal curiosity, do you know how the file names are chosen in the glibc-dynamic-linker procedure of the gnu/package/bootstrap.scm file? It mentions a "SYSDEP_KNOWN_INTERPRETER_NAMES cpp macro in libc", and I looked at that out of curiosity, but I couldn't really understand why the names were the way they were.
<dftxbs3e>marusich, I have no idea, not even sure it's consistent
<marusich>Like...which software component decides which name to use? What other software components need to follow those names consistently?
<marusich>I get that they're shared libraries, but I don't really understand the "contract" per se.
<marusich>Maybe the kernel? I'm just curious and I ran out of steam to follow the breadcrumbs, so I was hoping you might just know.
<dftxbs3e>marusich, it seems that GNU Guix changes them AFAICT, but I may tell wrong
<dftxbs3e>I remember looking at that too, and seeing it wasnt the same between glibc and GNU Guix
<marusich>Some confusing things for me when trying to port Guix to a new platform are (1) what is the "right" triplet I'm supposed to use? and (2) what is the right dynamic linker name? Figuring that out seems way trickier than it ought to be. It just feels like somebody decides upon it (who?) and then it never changes.
<marusich>Anyways, I will go afk for a bit now, for real. See you later
<dftxbs3e>marusich, yeah it puzzles me as well but I'm more obsessed on having it working than solve these possible inconsistencies :P - see you
<civodul>nckx: the optional argument to git-authenticate.scm is a good idea
<civodul>marusich: the loader's name is purely a libc thing
<civodul>it should be just called "" normally
<civodul>but then people came with that kernel "Linux", so there had to be a distinction
<civodul>my guess :-)
*civodul -> zZz
<andreoss>I have (inputs ...) contain a lot of `("foo" ,foo) expressions. Is there a macro which would generate such redundant code? Something like (package foo) ==> `("foo" ,foo)
<marusich>dftxbs3e, good news. I built the bootstrap binaries twice (with a "guix gc" inbetween) on the same system, and the binaries are identical. I wonder how it turned out on your end?
<dftxbs3e>marusich, hey, I didnt rebuild them yet
<dftxbs3e>marusich, I'm progressing on bootstrapping, had to make a few changes
<dftxbs3e>marusich,;a=blob;f=binutils/;h=6a0fbea3d1df644d43068b58d9a36b95e09f78f9;hb=HEAD#l1 - there's a reference to /bin/sh here, specific to powerpc, which means, we need sh or bash for the built artifacts, so because at that stage (binutils-final) bootstrap's sh or bash isnt allowed, I made it use static-bash-for-glibc instead, which is used by glibc-final - in commencement.scm
<dftxbs3e>I think I solved it another way last time but this is much cleaner
<marusich>dftxbs3e, I see. That seems reasonable to me. The variable name might need changing, since it isn't really just for glibc any more if we do that. But it seems reasonable to me that if it is OK to embed a statically linked bash in glibc-final, it is OK to use the same bash as the 'sh' to drive binutils' '' script.
<lcatcat>How to cross-compile correctly in guix?
<lcatcat>guix build cataclysm-dda --system=armhf-linux --target=armhf-linux -M 1
<lcatcat>I used this command, but the toolchain seems to have failed to build.
<lcatcat>it fail:
<lcatcat>checking build system type... x86_64-unknown-linux-gnu
<lcatcat>checking host system type... x86_64-unknown-linux-gnu
<lcatcat>checking target system type... Invalid configuration `armhf-linux': machine `armhf-unknown' not recognized
<lcatcat>This output comes from 'binutils-cross-armhf-linux'
<marusich>lcatcat, if your goal is to cross-compile cataclysm-dda, you need to provide the correct GNU Triplet to --target, and you do not need to use --system.
<lcatcat>thank you, marusich.
<lcatcat>I will try it.
<marusich>armhf-linux is a Guix system identifier. It is not a GNU triplet. For example, arm-linux-gnueabihf is a valid GNU triplet.
<marusich>I believe that armhf-linux is associated with the arm-unknown-linux-gnueabihf "triplet", which I believe can be equivalently stated as arm-linux-gnueabihf. Anyway, try removing --system and adding --target with one of those.
<lcatcat>Okay, I remove --system, but it looks like it is compiling gcc-cross-x86_64-linux?
<lcatcat>Is this also a step in creating a cross toolchain?
<lcatcat>The following derivations will be built: /gnu/store/ybm97wlsa5y0ngr3ag6ir3h3d9in4x34-perl-5.30.2.drv /gnu/store/3bf3b1n8bqq30lygr9akffydfjacmxi3-gcc-cross-x86_64-linux-7.5.0.drv /gnu/store/x9kq2d2m83xhrk6xv47q7j0nda51bf80-glibc-cross-x86_64-linux-2.31.drv
<kamil_>mbakke, since I still can't directly respond to bug tracker issues, I will do it here: -- for a containerized Flatpak app to talk to processes outside its bubblewarp context the Portal API is used (, which is implemented by a portal service frontend, XDG Portal Desktop ( that's currently missing fro
<kamil_>m Guix (
<mbakke>kamil_: thanks for the info. By the way, I think you can reply to those issues directly via the web interface. :-)
<kamil_>mbakke, speaking of which, how is this web interface's direct reply feature protected from bots flooding issues with spam?
<mbakke>kamil_: dunno, I suspect it just offloads to the existing spam filtering infrastructure on
<mbakke>wel'll have to ask rekado to be sure :)
<abralek>Hi, I was needed flatten, so I checked the repo and found multiple definitions of it
<Yasu>what is the best place to ask questions about GuixSD?
<marusich>Here, or on
<marusich>At least, those are the best places I know of.
<ennoausberlin>Hello. I wonder if someone uses spacemacs inside GUIX SD. Usually I use spacemacs everywhere else, but on GUIX this can cause problems due to the different package management styles (elpa / guix)
<janneke>ennoausberlin: what problem do you have?
<abralek>ennoausberlin: I am not a spacemacs user, I use vanilla Emacs and used to to do an elpa/use-package/package dancing . I switched to manage all my packages with guix and everything became much easier.
<ennoausberlin>abralek: Before spacemacs I also used Vanilla emacs, but the design and integration of so many packages was amazing. Unfortunately I can not reproduce this setup with guix.
<ennoausberlin>Scheme / Lisp code is fine. Even Hy works mostly, but I can not copy the Python setup of spacemacs
<janneke>"Unbound variable: fomat" /me trying to do some debugging :-/
<abralek>ennoausberlin: yeah, don't say. Maybe if you could share some use-cases..? With guix i can now do `guix import elpa' and that is it.
<ennoausberlin>abralek:Do you use leader-key and which-key?
<abralek>ennoausberlin: yes which-key
<ennoausberlin>I even can not find any init files in GUIX. Where do you put your configs?
<ennoausberlin>There was a project to bring spacemacs to guix but its abandoned. Even the repository vanished :(
<abralek>ennoausberlin: Guix install emacs packages in share/emacs/site-lisp which available for emacs through ~/.guix-profile/share/emacs/site-lisp/ If you don't use some custom path for the profile. Most of the packages ships with autoloads, which means you don't even have to do anything. Guix also have a step to make autoloads for you.
<abralek>ennoausberlin: When I am in my emacs and install a new package, I just run guix-emacs-autoload-packages and new package becomes available for me
<abralek>ennoausberlin: In terms of configuration I use use-package and do something like this
<abralek>ennoausberlin: there is also emacs-guix package which let you do everything relates to guix from withing Emacs.
<ennoausberlin>I am a long term emacs user but most of the interna I dont know. I will read about autoloads. I am eager to learn.
<ennoausberlin>I installed the emacs-guix package, but some functions gave me backtraces. I will try it again
<abralek>ennoausberlin: C-h S autoload
<lcatcat>How does Guix know that it is cross-compiling?
<lcatcat>I want to fix the cross-compile of some packages, but I don't want to affect the native compile.
<janneke>lcatcat: when cross-compiling, (%current-target-system) is set
<sirmacik>hm emacs-edbi package doesn't detect perl-dbd-pg package :o
<lcatcat>thank you, janneke.
<terpri>what's so special about spacemacs packaging? does it rely on external executables, use a nonstandard build system, ...
<terpri>plain elpa packages work just fine ime, but some may have difficulties on guix if they call external programs, etc. and aren't pure elisp extensions
<terpri>(note that i know nothing about spacemacs, other than that it's some kind of super-evil with lots of customizations, preinstalled extensions, etc. iiuc)
<ennoausberlin>terpri: Yes. You are right. Its kind of superevil. Thats why I want to use my debian setup on GUIX. But somehow it interferes with the way guix handles packages.
<terpri>ennoausberlin, can you write reproduction instructions for the bug, testable on a vanilla guix system install?
<ennoausberlin>There is probably a lot of magic how spacemacs integrates his packages
<ennoausberlin>terpri: I can not name a bug right now, because I do use guix own emacs packages right now. But before many problems popped up. I will put everything in a fresh vm to reproduce some of them
<terpri>also is spacemacs a specialized emacs "distribution"/friendly fork or (inclusive or) is it an elpa package or something?
<terpri>ennoausberlin, ok, thank you
<terpri>not personally interested in spacemacs but i have friends who rave about it and it'd be nice to have it usable in guix
<ennoausberlin>terpri: Its emacs on steroids. You can specify "Layers" like scheme and it will automatically install geiser and related packages to give you a very nice user experience
<terpri>maybe i'll try it out once it's usable, my emacs config is very old-school though :)
<ennoausberlin>The python integration is awesome. And I rarely used vim before, but because of spacemacs I like modal editing now
<terpri>give me paredit, gnus, org and slime and i can get by :p
<terpri>i do remember liking vim before converting to emacsism (more than a decade ago)
<ennoausberlin>terpri: An example. For a very long time (20 years?) I switched windows by C-x o. I got used to. In spacemacs windows are numbered and you can easily switch, kill, resize, arrange them. Which-key, helm, company are well customized.
<ennoausberlin>Its really new blood in emacs development
<terpri>never got into helm, company etc. because they seemed too hard to configure manually
<ennoausberlin>Thats the point :)
<abralek>terpri: paredit is good, but there is parinfer
<abralek>The package needs some love
<abralek>smart mode is not production ready
<abralek>It can also break code from time to time, but I think the idea is great
<davidpgil>how do I re-enable building from source instead of substitutes?
<davidpgil>or how do i disable substitutes?
<davidpgil>that will persist?
<davidpgil>I want to do it permanently
<lcatcat>It can be used in the command line parameters of guix-daemon.
<lcatcat>If your machine's performance is not very good, it is recommended to use the substitute, many builds require a lot of memory.
<davidpgil>I have 32gb of memory
<davidpgil>8 cores
<davidpgil>is that enough?
<lcatcat>It must be enough.
<davidpgil>I would think so too. so im trying to enbale it now...
<davidpgil>guix archive --no-substitutes
<davidpgil>says: guix archive: error: either '--export' or '--import' must be specified
<davidpgil>not sure what to do
<lcatcat>You used it wrong
<davidpgil>i know :)
<lcatcat>you need 'guix archive --help'.
<davidpgil>im looking at it now
<davidpgil>thats why im asking
<davidpgil>i dont understand what im doing wrong
<lcatcat>So what do you plan to do with this command?
<davidpgil>when i installed guix, i used the install script. during the installation it askes you if you want to enable subsitutes, i declined and was building without substitutes for some time. then, i had an issue where i needed to authorize substitutes, and i resolved my issue. Now, i want to re-enable substitutes and I cannot find a direct answer on how.
<davidpgil>for my regualr "guix package -i program" installs, I want it to build from source
<davidpgil>... im also not used to using guix-daemon for anything. should i be doing this throught "guix-daemon"
<mbakke>davidpgil: you can add '--no-substitutes' to the guix-daemon arguments in /etc/systemd/system/guix-daemon.service
<davidpgil>only way to do this is from editing a text file?
<mbakke>permanently, yes; otherwise you can set $GUIX_BUILD_OPTIONS or pass --no-substitutes on the CLI
<mbakke>davidpgil: actually, deleting /etc/guix/acl might be easier ;-) but you'll get a warning unless you also use --no-substitutes
<davidpgil>i think ill just settle for :guix package -i program --no-substitutes
<davidpgil>would be nice to have a simplke CLI toggle
<mbakke>davidpgil: like 'export GUIX_BUILD_OPTIONS=--no-substitutes' ?
<davidpgil>more like guix archive --authorize
<mbakke>right, something like 'guix config --disable-substitutes'
<davidpgil>yes... actually this does not seem to be working
<davidpgil>i restarted the daemon
<davidpgil>"systemctl restarted guix-daemon"
<davidpgil>i mean systemctl restart guix-daemon"
<mbakke>davidpgil: when making changes to systemd units, you also need to 'systemctl daemon-reload' for them to take effect, otherwise you will restart the cached service
<davidpgil>ah ok cool
<davidpgil>so u know ive only started really doing anything with systemctl since last week. i was trying to use it to run a script upon hotplugging a serial to usb wacom device. i also started to mess with udev last week. so i know just enough to get into trouble. :/
***sputny1 is now known as sputny
<raingloom>if I want to package Yggdrasil (the mesh networking tool), should I put it in networking.scm or in its own file?
<alextee[m]>is the clang compiler supposed to work?
<xelxebar>raingloom: Did you try looking at the packages under networking.scm to see if it would make sense there?
<alextee[m]>i get a bunch of errors inside /home/alex/.guix-profile/include/c++/bits/cpp_type_traits.h
<alextee[m]>doing CC=clang CXX=clang before running meson
<raingloom>xelxebar: i did, and i'm still not sure. i guess i'll just put it there, since it is indeed a networking tool and doesn't need additional utilities.
<raingloom>most of the patch involves go dependencies anyways, that's the trickier part. idk if they should just go in golang.scm. gonna try to categorize them.
<xelxebar>raingloom: Sounds reasonable. It might be worth asking explicitly in the email when you submit the patch too, if you remain unsure.
<wxie>My web cannot display Chinese fonts correctly after reconfigure. [web 3.34.4](guix) Chinese fonts are displayed as blocks.
<wxie>fc-cache -rv does not solve the problem.
<wxie>NEXT in the meantime is ok.
<wxie>Has anybody similar issue?
<pkill9>good afternoon guix
<raingloom>hmm. is there a way to autogenerate those nice commit messages?
<mroh>raingloom: there are snippets in ~/etc/snippets/text-modes that can be used in emacs...
<PurpleSym>Is there a substitute* function for latin1 encoded files? I’m getting a decode-error.
<civodul>PurpleSym: in that case you need to bind %default-port-encoding around it
<civodul>search for "ISO-8859-1" in gnu/packages/*.scm, there are several examples
<xelxebar>I'm confused. Diagnosing non-determinism problems, I'm building with --check --rounds=2. Sometimes I'll get both foo and foo-check outputs in the store, making it easy to compare problems. However, most of the time I just get foo with an error that "output `foo' differs"
<janneke>oh my, another bootloader update on master
<xelxebar>How and when does the *-check output get generated?
***sneek_ is now known as sneek
<str1ngs>sneek: later guix-vits. hello your guix install issue with local nomad should work now. Make sure you git pull nomad and also guix pull commit 8d6ead32a09e31534ac4bab3a9ea8ca81f16e405 or greater. Let me know if you have any issues.
<str1ngs>sneek: later tell guix-vits. hello your guix install issue with local nomad should work now. Make sure you git pull nomad and also guix pull commit 8d6ead32a09e31534ac4bab3a9ea8ca81f16e405 or greater. Let me know if you have any issues.
<PurpleSym>civodul: Thank you!
<raghavgururajan>Hello Guix!
<janneke>i'm tempted to bump mcrl2,mcrl2-minimal to a nightly tarball; adding two -next versions seems a bit overdone?
<raghavgururajan>When using git-fetch, build-system automatically invoke autoconf right?
<ryanprior>Is there a way to go back and look at previous "guix pull --news" outputs?
<ryanprior>I'm thinking about hacking on a "news browser" interface and want to find some good examples.
<raghavgururajan>The package definition I am trying, the autoconf is not invokes by build-system and throws error about missing configure file.
<str1ngs>raghavgururajan: add autoconf to native-inputs
<str1ngs>hmm which you have done.. strange
<bdju>looks like emacs-general failed to build for me last night
<raghavgururajan>str1ngs: Yeah!
<raghavgururajan>Usually I experience this with autogen script and then I tweak the script to not run ./configure. But here there is no autogen script. Only file.
<guix-vits>bdju: "general Failure! You've been promoted to emacs-general rank." ; this package is on celebration and cannot be built.
<sneek>Welcome back guix-vits, you have 1 message!
<sneek>guix-vits, str1ngs says: hello your guix install issue with local nomad should work now. Make sure you git pull nomad and also guix pull commit 8d6ead32a09e31534ac4bab3a9ea8ca81f16e405 or greater. Let me know if you have any issues.
<guix-vits>str1ngs: ok, i'll try to update today, Thanks.
*guix-vits "Tell me all you know, Manual! How to specify the custom channels!? I wannabe like j s o o."
<boeg>anyone know if there is a package where "sgdisk" is available?
<bdju> here's the build log for emacs-general failing, btw
<guix-vits>boeg: sfdisk?
<bdju>boeg: maybe gptfdisk
<boeg>yes - indeed, gptfdisk
<mbakke>Guix DB transactions average around 50 minutes on Berlin currently
<lle-bout>sneek later tell marusich I built your branch:
<guix-vits>"The GNU C Library (glibc) has been upgraded to ..." -- finally i got the famous message about locales ^>^
<str1ngs>guix-vits: I pushed some autotools enhancements for nomad. make sure you git pull before trying guix install. which works now for me.
<guix-vits>str1ngs: Cool
*guix-vits "ok, i'll be off-line for some time due to updates."
<ArneBab>str1ngs: does this fix the bug I reported (build error in emacsy-minimal while upgrading nomad)?
<civodul>ryanprior: re --news, you can run "guix pull --list-generations"
<lle-bout>civodul, hello! I was wondering; are you paid by french academia to work on GNU Guix part or full time?
<civodul>lle-bout: yes, part of my work at Inria is about Guix for high-performance computing (HPC)
<lle-bout>civodul, very cool!
<civodul>yup, for 2.5 years
<lle-bout>I wish I could earn myself such an employment situation! Paid to work on a GNU project? What more to ask?
<civodul>heh :-)
<civodul>it was a bit of struggle on a few occasions, but the outcome is very nice
<butterypancake>me: asks boss to sign copyright papers to contrib to emacs
<butterypancake>boss: ok, but let the record show I won't pay for you to do open source
<ryanprior>civodul: perfect, thanks
<ryanprior>civodul: btw feel free to close my cc-wrapper issue if you're not interested in it, but I was hoping to get some more conversation going about alternative ways to manage aliases and env variables in guix manifests.
<ryanprior>Maybe I should write the dev mailing list next.
<civodul>ryanprior: yeah, i think that manifests are the wrong place for aliases etc.
<civodul>but perhaps some other tool is needed
<bdju>trying to use ftp from pcmanfm and getting "Operation not supported"... what do I do?
<lle-bout>sneek later tell marusich it's getting minimal! I could bootstrap successfully with only the following patch on top of GNU Guix's current master
<sneek>Got it.
<str1ngs>ArneBab: hello, emacsy-minimal should be working now. I have not tested nomad in guix yet. mainly we are testing and using feature-g-golf branch of nomad.
<guix-vits>Do someone had a situation when some service suddenly stop working (even without updates)?
<nckx>civodul: All right, thanks, will do.
<nckx>guix-vits: That's too vague. Everyone's had that situation. That's what services do 😛
<nckx>What exactly is no longer working, and how do you know?
<guix-vits>nckx: tor doesn't:
<guix-vits> (firewall)
<guix-vits> (L# 122)
<abralek>Guys, how can I import all your gpg keys? Seems like gpg allows to fetch a bulk of them from URL. But is there any?
<guix-vits>nckx: firewall (as posted) shows my current state: instead of running the service i run `tor --defaults-torrc TORRC` on behalf of test-user.
<vagrantc>abralek: there's a download link from
<sneek>vagrantc, you have 1 message!
<sneek>vagrantc, nckx says: Heh… That's just how long the big everything lock was held by ‘guix gc -F 3 flippin terabytes’ (about 4h) during which nothing is done. Those evaluations resumed ~3h after you pointed them out.
<vagrantc>on many days, there seem to be stalls right around the time i'm ready to push things :)
<vagrantc>i must be in a broken timezone
<abralek>vagrantc: Ah, I see thanks
<vagrantc>abralek: i'm not sure that's where you're supposed to get it from ... but it has most of the keys mostly updated
*vagrantc thinks there should be a guix-keyring package
<abralek>Yeah, i tried to do some xargs thingy, but decided not to)
<abralek>Maybe there is some fictionality in guix-authenticate
<vagrantc>not yet ... work in progress
<vagrantc>there's "make authenticate" in the source, which has some code to download keys
<vagrantc>and a list of "correct" keys
<nckx>vagrantc: <i'm not sure that's where you're supposed to get it from> It is.
<abralek>By the way, I ran it but it crashed on my commits. I added the key locally but still no luck
<vagrantc>nckx: ?
<abralek>Probably just me
<vagrantc>it was a bit fussy when i last tried it
<nckx>vagrantc: ? I can't answer your question if you don't tell me what it is.
<vagrantc>nckx: it is what?
<nckx>What I quoted.
<nckx>This is a weird conversation…
*nckx checks logs.guix
<vagrantc>nckx: < nckx> vagrantc: <i'm not sure that's where you're supposed to get it from> It is. .... to which my response is ?
<vagrantc>nckx: indeed, let's enjoy the weirdness rather than be frustrated :)
<nckx>‘I'm not sure if that's the place’ ‘It is’ <no response necessary?>
*vagrantc goes back to writing patches :)
<mroh>can someone confirm a build/test fail for gnome/totem (tests) on current master?
<nckx>mroh: Try reverting c2e19b6291cc4981e39d01aae85af0899614061d.
<mroh>ok, thank you
<nckx>mroh: It's just a guess but that commit has a guilty look on its face.
<nckx>Wasn't gnome already broken for some other reason?
<str1ngs>🐉 🚀 🌎 👏
<nckx>If it hadn't been delayed I would've seen it with my own eyes ☹
<str1ngs>was exciting to watch. :)
<guix-vits>str1ngs: i was though this means "some cosmic dragon was hit by missle sent from a western side of the Earth, so everyone applauses" before opening the Wikipedia.
<nckx>Honestly, it might be an improvement.
<nckx>All hail our cosmic overlords.
<efraim>sneek: later tell dftxbs3e just reading through the backlog now, I'd love access to a ppc64 VM :)
<efraim>sneek: botsnack
<ArneBab>str1ngs: thank you!
<TBC_x>Hi, how much is guix chrootable?
<ssb>you probably want to use 'guix system container'. Default layout requires "activation", which is done from initrd
<TZander>this is a great read;
<nckx>mbakke: Thanks for fixing. I'm very tempted to simply disable that stupid totem linting test. ‘Your code has been rated at 9.83/10’ — gee thanks, someone cares.
<nckx>Oh, it's not fixed.
<mbakke>nckx: yes, seems a bit silly to run an overzealous linter, I would not mind disabling that
<mbakke>wait what?
<nckx>It's reverted.
<nckx>Potahtoo ptayteo
<mbakke>ah yes :-)
<nckx>All the pretty conflicts.
<nckx>I'll continue working on the ‘fixed’ timeline but yeah, motivation sort of gone now that it just builds.