<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* "meson.build" (("^ \\['engine', .*$") "")) now. <nckx>The last ‘word’ doesn't matter, we care about the ‘engine’ entry. <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://gitlab.com/lle-bout/guix.git 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>push access is default when you added your key, and I made you maintainer of the project which means you can do everythng <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. <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. <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'. <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>I'm not sure comments change store hahses <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>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. <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>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/ld64.so instead of /ld64/ld64.so 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)? <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>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 <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 <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>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>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 "ld.so" normally <civodul>but then people came with that kernel "Linux", so there had to be a distinction <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, I'm progressing on bootstrapping, had to make a few changes <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' 'embedspu.sh' 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>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. <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 <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 debbugs.gnu.org <mbakke>wel'll have to ask rekado to be sure :) <Yasu>what is the best place to ask questions about GuixSD? <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>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: 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 <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 <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>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. <terpri>never got into helm, company etc. because they seemed too hard to configure manually <abralek>terpri: paredit is good, but there is parinfer <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? <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 would think so too. so im trying to enbale it now... <davidpgil>says: guix archive: error: either '--export' or '--import' must be specified <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 <mbakke>davidpgil: like 'export GUIX_BUILD_OPTIONS=--no-substitutes' ? <mbakke>right, something like 'guix config --disable-substitutes' <davidpgil>yes... actually this does not seem to be working <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>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? <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 <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? <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. <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 <bdju>looks like emacs-general failed to build for me last night <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 configure.ac 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? <mbakke>Guix DB transactions average around 50 minutes on Berlin currently <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 "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>I wish I could earn myself such an employment situation! Paid to work on a GNU project? What more to ask? <civodul>it was a bit of struggle on a few occasions, but the outcome is very nice <butterypancake>boss: ok, but let the record show I won't pay for you to do open source <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? <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? <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 sv.gnu.org/projects/guix <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>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>there's "make authenticate" in the source, which has some code to download 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 <nckx>vagrantc: ? I can't answer your question if you don't tell me what it is. <nckx>This is a weird conversation… <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. <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? <nckx>If it hadn't been delayed I would've seen it with my own eyes ☹ <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 :) <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 <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. <mbakke>nckx: yes, seems a bit silly to run an overzealous linter, I would not mind disabling that <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.