<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.
<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.
<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).
<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
<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>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>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
<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.
<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
<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)
<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
<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.
<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"
<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. :/
<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.
<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?
<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.
<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.