<ryanprior>Right, that's a very handy thing! I've wondered before how I could provide a Guix package in the repository of a project, and this seems like it could be the answer. I'm going to play with it later.
<xelxebar>Holy hand grenade. guile-static is *still* building after 8+ hours. Its for armhf-linux via qemu-binfmt on a beefy vs. Is the qemu overhead really that apocalyptically heavy?
<ryanprior>Right, it prints that commit hash but then when you run `guix pull` it says a second time that it's updating to that same hash. Strange.
<nckx>I guess it's possible you're crossing some ‘feature boundary’ between old and new Guixes, for example the authentication mechanism. Pulling with the old Guix gives you a bleeding edge Guix but doesn't itself update the authentication cache; then pulling again with the ‘new’ guix does? I don't know.
<nckx>FlakyConnectionU: All I'm saying is that a second ‘guix pull’ should not be strictly necessary, but it's certainly possible (even likely) that it's the easiest sledgehammer to fix whatever underlying issue was really going on. Certainly seemed to work!
<nckx>Easy for me to say, but maybe that's worth a bug report...
<ryanprior>He tried following my instructions on Guix System and on Ubuntu with a binary installation, and he got errors both times, but the second pull finally allowed him to succeed.
<nckx>xelxebar: Emulated aarch64 builds are - *very* roughly, I'm sure it depends on the actual package - ½ as fast as native builds on my x86_64 Thinkpad.
<ryanprior>Fixing the "bug" might be as easy as making a new Guix 1.1.1 release so that people get a more modern stack when they boot a VM or do a binary install.
<nckx>That doesn't mean QEMU has a 100% overhead: native aarch64 machines are about that fast anyway.
<nckx>I don't see why armhf would be spectacularly worse.
<nckx>ryanprior: We (I definitely) have started recommending the ‘latest’ live installer image over the 1.1 one. Maybe it's time for a ‘latest’ binary tarball.
<xelxebar>nckx: Hrm. Okay. Doesn't 4+ hours still sound a bit long for guile-static though? Running on an 8 core 2.2ghz machine and all its cpus are pegged.
<ryanprior>A lot of people assume (with good reason, considering how many other projects do releases) that the "latest" image is more likely to be broken or confusing than the most recent stable release.
<ryanprior>That's especially true of security engineers, who I'm especially interested in trying to win over to Guix
<FlakyConnectionU>«Easy for me to say, but maybe that's worth a bug report...» I can't promise anything, but I'll try to properly document the issue and fill one once I manage to fix that ethereum package.
<nckx>I mean, mainly due to our own inability to do meaningful QA due to our size, not only because it's a simplistic prejudice. 😛
<FlakyConnectionU>«That's a flawed assumption.» ...that I've made when downloading the image
<FlakyConnectionU>Nevertheless, I see that fast paced projects are worth a master/main try
<nckx>I didn't mean to imply there's nothing we should do about it, just that ‘explain why that's not the case on the download page’ is at least as valid an option as ‘continue playing the game even though our answer to everything else is that were rollin'.’
<ryanprior>FlakyConnectionU: out of curiosity, how do you intend to build the go-ethereum package? Are you going to vendor in all the deps or do you want to package them properly?
<xelxebar>FlakyConnectionU: I'm a late to the party, but that log file is gnarly. Are you running on a foreign distro? Not sure if this is related, but it turns out that the repo's make actually escapes pure environments. I've had this wreak havoc before.
<ryanprior>I ask because I have somebody offering to sponsor me to package everything properly and get it accepted into upstream, so I'm super interested in combining efforts if that's also your goal.
<nckx>FlakyConnectionU: In Guix it just means a snapshot in time, with all the free unfixed bugs that come with that.
<FlakyConnectionU>ryanprior: I was planning to vendor everything, but individual packaging can be beneficial for the Guix philosophy
<ryanprior>xelxebar: yes I've run into that too, I now run `configure` in a container to prevent that escape.
<FlakyConnectionU>After all the community support I've received, being a bounty hunter is out of question for me, but I'll share with you the state of the art
<nckx>FlakyConnectionU: Even if we never find out what exactly went (mildly) wrong it's great that you have a detailed log file. Thanks for that.
<ryanprior>I do mean that! I'm glad that brought you here :)
<xelxebar>ryanprior: Do you have a precise idea what escaped for you? In my case it was /bin/sh getting called instead of guix's bin/sh. Was able to fix this by running configure with CONFIG_SHELL=$(command -v sh).
<ryanprior>You should ask them if they'd still pay some or all of the bounty for a package that works but isn't accepted upstream.
<ryanprior>I doubt Guix maintainers would accept it with all the deps vendored in, but it could still be useful to the person who's asking for it.
<FlakyConnectionU>I was wondering if we could dynamically toggle that value to on, off or auto per-package with the #: syntax
<FlakyConnectionU>Is there any sane way of dropping a shell just before the build stage of the build system?
<ryanprior>Yes definitely, you can use `modify-stages` in the package description to add a new stage before build and run some commands, set env variables, etc.
<ryanprior>Your proposal of making it an argument to the build system also makes sense to me.
<nckx>...but not an interactive shell as often meant by ‘drop’.
<ryanprior>True, Guix builds are non-interactive to help keep them deterministic
<FlakyConnectionU>I think I'm going to use one of my red team reverse shell snippets to break the build determinism for a while :smiling_imp:
<nckx>FlakyConnectionU: You can insert a phase before the build (or any) phase to print out some assumptions, or even abort the build which is useful in combination with -K.
<xelxebar>nckx: Fair point. I've ogled the length of the issue list and seriously appreciate the dev scramble. ~6 months is just way longer than any other patch I've submitted.
<ryanprior>That's badass, if you can do that and post another shell log that would be sweet.
<nckx>The build directory will contain a file with environment variable so you can get closer to the build environment, but there's no way to enter the container and you'll still be yourself poking around a regular directory in /tmp.
<ryanprior>If Guix's isolation system is robust, it should dissuade you from doing this. For example, simply listening on a port should fail because builds are done without network access (in theory.)
<xelxebar>Also, looking at the issue again, I was a bit unfair. Florian did respond at the beginning as I was flailing about in my newbieness. Once I figured out the issue and got a patch, however, it looks like nobody may have noticed.
<nckx>xelxebar: Yeah, it sucks, no sugar-coating that.
<nckx>xelxebar: No promises but what's the bug number?
<xelxebar>Okay, dumb question time. When running and aborting guix build sever times in a row, I notice that dependencies get built/downloaded in a non-deterministic order. I find that mildly surprising. What's going on?
<Brendan[m]2>im amazed i managed to read what i imagined happened rather than what my eye balls actually saw
<Passenger1112>Wondering about dual monitor setup in guix. Both monitors works when booting, they're both connected via HDMI, but when starting X, only one keep working, the other one goes black. Is there some setting in xorg.scm I need to configure, or something else?
<ryanprior>I hope to use it to unblock our effort to package nodejs 12 (currently we're held up on 10, which is still supported so not panic yet, but yay)
<vits-test>Hello Guixen. RE: my yesterday's (?): Yes, despite elogind-service enabled i need to be a member of the video group for sway to work.
<clone11>I tried to install guix, but the installer usb hangs on this text forever. I can'
<clone11>I can't type anything or go to a different tty. The installer works on my laptop so I know the usb isn't the problem. I have a ryzen cpu and amd video card. Does anyone have any ideas? Here's a picture of the screen it hangs on: https://0x0.st/i03c.jpg
<jtmar>is there a list of real-world system configuration examples anywhere?
<ryanprior>Not that I know of, that would be a real handy thing though!
<mfg>Hi, is there anything special i have to pay attention to, when i want to use i.e. (ice-9 match) inside a package definitions arguments list? i have seen that there is a #:modules keyword, so i just have to add the module to that?
<efraim>ice-9 match just needs to be imported into the module where the package is defined. Unless you're using the trivial-build-system or mixing build systems you shouldn't need to worry about it
<efraim>does linux-libre-arm64-generic take a long time to build?
<mfg>efraim: Hm, when i add it to the top #:use-modules list then it seems to not work, i get unbound variable errors inside the match part of a clause, at least this error goes away, when i add it to the #:modules list of the package itself
<str1ngs>efraim: yes mainly to deblobbing. if deblob sources are available its not to bad. also depends on the machine you are building on of course.
<efraim>i've already deblobbed 5.8.13, building on a pine64
<efraim>I really need to get my firefly3399 back up and running
<mfg>but then i get other errors (can't share atm, i'm at the wrong computer), so i just wanted to know how it should work and if i'm doing something simple wrong :D I will get back with the error messages later then :)
<str1ngs>efraim: I mainly offload my SOC builds I have a rockpro64 and a pinephone I build for.
<Brendan[m]2>been downloading from the substitute server at around 5KiB/s all day today
<jlicht>ryanprior: I just played around with getting a working llhttp build using esbuild; I got a build working, going from TS -> JS, and running the JS with our venerable version of Node to generate a parser in C. A tiny pebble on the road would be https://github.com/nodejs/llhttp/issues/52, but that seems doable.
<jlicht>roptat: what are your short-term plans for guix-home-manager, with framagit closing?
<wleslie>I have a question about cross compiling and how we do it in guix, but I'm probably way off base, so I'll give lots of context
<wleslie>I'm porting a cross toolchain which works like so: it patches (adding support for the target) and compiles gcc; then it compiles newlib, then it compiles gcc again. both gcc compiles use --with-newlib. none of the cross compilers in guix do this, so I just want to make sure I haven't missed something about the way gcc is built.
<wleslie>my first guess is that the first compile --with-newlib is somehow synonymous with "don't expect a supported C library for the target"
<wleslie>but maybe it's just "also build newlib because some targets require it"
<efraim>`git grep newlib' shows the string in gnu/packages/cross-base.scm and gnu/packages/embedded.scm
<wleslie>yes, cross-base just passes the flag to gcc configure if there is no glibc available
<wleslie>embedded has a newlib build for arm targets; but it doesn't do anything specific about the compiler used
<wleslie>oh, yes it does, in `arm-none-eabi-toolchain`
<civodul>efraim: i think it has the same capabilities as the host
<MSavoritias[m]2>I found a huge bug in the latest iso. If you install guix using the guided installation in the graphical installer you can't reconfigure the system because it says the boot is out of space.
<MSavoritias[m]2>I tried to also format the drive with parted separately and then start the installation but it didn't work.
<pkill9>would it be a good idea to change the --with-graft command to automatically create a symlink in the store to the new input, with a name that matches the length of the old input, if the new input's name's length doesn't match the old input's name's length?
<GNUtoo>hi, I'm still trying to test my patch and I've now a different error:
<GNUtoo>guix system: error: canonicalize-path: No such file or directory: "/usr/share/guile/site/2.2/gnu/installer/aux-files/logo.txt"
<GNUtoo>I did that to get this error: # guix system disk-image --target=arm-linux-gnueabihf -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")'
<mfg>i began using GNU/Linux because i wanted to use my computer to do learn/make something and not play video games all the time :D so arch was installed and i forced myself to not use a GUI for about 3 months...
<emacsen>mfg, if you wanted that, you could have used GNU/Hurd. No GUI. No network either. Really forces you to focus on the basics :)
<roptat>ouch, I only used my tty-only system for... what? 3 days?
<civodul>at the time the FSF would print stickers reading "GNU/Linux inside" and "GNU/Hurd inside"
<civodul>and they'd just print the same amount of each
<brettgilio>Just wanted to share an update on my new job. Got my work laptop in the mail, a nice T480. Got Debian installed on it, and installed Guix along side it, both working great. I got paid for four hours of refactoring my emacs config, and otherwise ive done nothing. lol
<ngz>Hello. Since Emacs 27.1 upgrade, I'm encountering encoding issues in some Gnus messages (French ones). I tried with and without (prefer-coding-system 'utf-8) in my setup, to no avail. Does that ring a bell?
<roptat>I don't know, I just feel like the manual is not very helpful when I'm looking for something
<civodul>ngz: works for me; what encoding issues, with outgoing messages?
<roptat>maybe what I need is "programming by example", because I always know what the function should do, but I don't know what it's called