<civodul>Zambonifofex: oh, on physical hardware! <civodul>it may be that you're lacking an in-kernel driver for the hard disk <civodul>Debian has a patch to support RAM disks in GNU Mach (!), which i think was motivated by the chicken-and-egg issue with user-space disk drivers ***lukedashjr is now known as luke-jr
<Zambonifofex>nojr: I wish I could help, I’m sorry I can’t. Also, maybe you should try asking at a different time, it seems around this time, generally people are away. <Brendan[m]2>nojr I suggest inspecting your environment variables and checking which guile you are running. are you accidently running a guile from the parent os for example <Brendan[m]2>perhaps you can create a --pure environment with emacs and guile and see if you can get it working there <nojr>Zambonifofex: thanks, yeah no worries <nojr>Brendan[m]2: ok thanks for the tip, I will try it <Brendan[m]2>sometimes a clang input is called clang, other time libclang <zimoun>roptat: Missing the 7 last patches. I will finish later this week. Thanks. <PotentialUser-87>Greetings, anyone have knowledge of what this error means? guix deploy: error: failed to deploy lr: build daemon handshake failed <joshuaBPMan>Ahh man...working night audit...and I'm baby sitting a severely intoxicated man. <joshuaBP`>I've never been able to use emacs-guix...I always seem to have problems using it. <apteryx>It used to work well until a year or two ago, where it started having problems often. It seems it's not being maintained as actively as it used to. <raingloom>egg info says it's BSD but that doesn't look like BSD to me <raingloom>well, i've read through the FSF page on licenses and i can't find this one <raingloom>guess i'll send the patch and hopefully someone on the mailing list can cofirm if this license is fine for packaging in Guix. <raingloom>btw i've still not received feedback on my yggdrasil patches *Brendan[m]2 starts a change.org compaign for guix contributor recognition <raingloom>asked for feedback a few weeks ago too, got some acknowledgement, but still no email <raingloom>tbh non-contributors could test it too. then contribtuors would have a higher degree of certainty that the patch works. <Brendan[m]2>i wonder if its a bit excessive to include the whole license exception in a comment <emys>hey, I am transferring a guix-based dev setup for a packate (Guix.scm) from git to mercurial <emys>And my git setup had the following `source' setting (source (local-file %source-dir #:recursive? #t #:select? (git-predicate %source-dir))) <emys>since there was the `git-predicate' filtering clause in there, how do I transfer that to a mercurial setup, or, do I actually need to transfer this? <raingloom>Brendan[m]2: it is. i wasn't aware of such a feature. <Brendan[m]2>raingloom for example (license:non-copyleft "file://COPYING" <raingloom>ooh. i think i'll use that for chicken-srfi-1. ***apteryx_ is now known as apteryx
<Brendan[m]2>I tried the installer without encryption and it still fails at installing grub, saying it cant be installed without blocklists, and then it bails out <Brendan[m]2>i think its doing some efi crap when bios is needed, but idont recall any option for that <Brendan[m]2>how do you figure? its so weird because it only happens when i pass --config with configuration file in the /gnu/store, and remove the etc-service for the /etc/greetd/config.toml. if i leave that their then it works, but then if i run the same command manually from the tty, it does work... <iyzsong-w>grub says 'blocklists' usually when you try to install it into a partition (the correct one should be device, eg: /dev/sda), and the partition's filesystem not support embed (some does, maybe btrfs..) <Brendan[m]2>i just used the installers default config from the menu how it auto formatted the drive <Brendan[m]2>oh dear. i tested it and it really does just seem to be ignoring the flag <efraim>oh, sorry. I wandered off. It looked like a dbus style collection of strings or something, but I see now it really wanted the file in the desired location <efraim>hmm, looks like I got corrupt items in my store from my other machine, which has hardware issues on the HDD :/ <efraim>yeah, although I might need to send each one manually to guix gc if I don't want to do a big gc on the whole store <efraim>it also explains why I was having a hard time offloading to my aarch64 board, it kept on choking on zero-length files <Brendan[m]2>so i have this shepherd service that launches /gnu/store/ri7xniwanc0xphkh1vg4nyfsifnaggb8-greetd-0.6.1/bin/greetd --config /gnu/store/xc4qf85kjq35blif08kh7h8vd703vysb-config.toml <Brendan[m]2>now if i run that manually from the shell it works, but when its ran automatically it seems it just doesnt recognise the arguments <efraim>do you have the code somewhere? it could be that it's missing some env variable or a wrapper of some sort <Brendan[m]2>you should be apply to apply the patches on master and run $(./pre-inst-env guix system vm config-greetd-test.scm) <Brendan[m]2>lower down at XXXXX there is the etc-service-type disabled. we shouldnt need that due to the use of --config. <Brendan[m]2>i created a deliberately broken config for that one to see if its being used or not <efraim>Computer froze on me. I'll have to return to it in a bit <efraim>I haven't fully configured the earlyoom service and simetimes it kills something important <OriansJ>with 1.1.0 binary on top a new debian system <jeko>Hello Guixters!! Hope you are fine ! <Brendan[m]2>OriansJ looks like the same kinda bug you found last time. the file may have been deleted and its just downloading a html web page <Brendan[m]2>we need to implement falling back to a mirror when that happens, and archive all tarbals <jeko>Is there a guild option such as -Wall for gcc ? <OriansJ>Brendan[m]2: with the added bad news it means out of the box guix can't even pull <OriansJ>So guix-binary-1.1.0.x86_64-linux.tar.xz can't pull and it can't even install emacs (or any thing else I tried) <OriansJ>effecting both guix pull and guix package -i <Brendan[m]2>did ludo link to a bug report for this last time? i think there is one <OriansJ>new users don't look at bug reports; they just give up and leave <Brendan[m]2>quit whining like a baby and just accept that there is a problem that needs to be fixed. you can work productively towards fixing it by posting a bug report, or writing the code to use the substitute server as a fallback, and then emplore the admins to archive all tarballs. there is a new release coming soon, maybe it could even be fixed by then, or if not, the next one. <Brendan[m]2>efraim they were swearing in here about it rudely the other day. <Brendan[m]2><OriansJ>zimoun: demanding the source code used for the binaries isn't fucking UI or whislist; it is the basic expectation of a GNU PROJECT APPLICATION! <efraim>ah, the libsndfile thing. It seems they've forgotten the part about "best effort of volunteers" <Brendan[m]2>hmm. i enabled -N for guix system vm and dns works, but, cant ping anything <jlicht>Is there a way to identify 'bad upstreams' (in the sense of them making in-place updates) and create a substitute server for at-risk sources only going forward? <jlicht>For github there is the practice of not downloading generated tarballs in guix packages, so perhaps it's good to know which upstreams have other priorities than guix <OriansJ>lets assume for a second someone wanted to just download every single tarball listed in guix; how much space would it require? and anyone have code handy that does it? <OriansJ>So I can atleast budget for the costs and have a mirror server up for everyone to use as a fallback. <Brendan[m]2>efraim im talking to the greetd dev about my issue, and they maybe think its a bug in his software, so please refrain from trying to debug my service for the time being :) <Brendan[m]2>turns out greetd launches a sub process that reads the default path for the configuration file, even though it doesn't need it, causing the no such file or directory error <efraim>OriansJ: IIRC the last time I checked was about 2 years ago, it was ~85GB for that snapshot in time <efraim>and that was "per architecture", so pristine upstream tarballs were fine, I think depending on the patching and/or snippet mechanisms it could differ based on which architecture (and therefore store path) touched the tarball <cbaines>OriansJ, while mirroring source material is great, it alone isn't going to solve the problems you're having. <cbaines>I can download that file you're missing by running: guix build --substitute-urls=https://ci.guix.gnu.org /gnu/store/0zh5mvhgcx0198k7j6p5pgrc5krgxyqj-icu4c-64_2-src.tgz <OriansJ>efraim: well that isn't bad at all; I could get 250GB of block storage for $5/month <OriansJ>cbaines: efraim's mirror link solved that one for me <Brendan[m]2>indeed, it looks like half the work has been done, whats left is to make guix use it even when --no-substitutes is used <efraim>I have a couple of tarballs from when I was trying to revive the mips64el port <OriansJ>now just to get a script that extracts all of the urls from guix and outputs them <zimoun>OriansJ: you could be interested by http://guix.gnu.org/sources.json which list all the sources of Guix. It is used by Software Hertiage to ingest all tarballs (even if we are not currently able to lookup then :-)) <OriansJ>zimoun: thank you, that really simplifies the task <zimoun>OriansJ: note that the issue if the lookup map when speaking about tarballs. You can go for sha256-checksumm -> content. SWH is doing SWH-ID -> content. And Guix is more or less doing nar-hash -> content. Well, if you are interested by such topic, you should give a look at https://git.ngyro.com/disarchive-db/tree ***stikonas_ is now known as stikonas
<jeko>Is there a guild feature such as -Wall for gcc ? <jeko>For example, guild compile and load a piece of code where I call a non defined procedure. I would rather see guild not loading and display the error or warning <OriansJ>well the bad news is I am getting alot of 404s <OriansJ>zimoun: wgeting all of the guix tarballs <Brendan[m]2>OriansJ what command did you use to list all the tarballs? <OriansJ>Brendan[m]2: sed 's/"/\n/g' sources.json | grep http | grep -E '.tar|.tgz|.zip|.jar' | sort | uniq >| target <OriansJ>and now using wget -ci target -o logfile to get everything obviously a tarball <OriansJ>It'll take a couple hours but then we should have a list of what is broken in guix (in regards to missing tarballs) <Brendan[m]2>now that we have icecat 78, i was wondering if webrtc can be enabled for jitsi meet? <zimoun>OriansJ: are you only trying to fetch or also to checksum the fetch? <OriansJ>zimoun: I am first going to see what isn't even available to fetch; then I am going to see how much of what is fetched would be valid <OriansJ>although I need to figure out how to get a checksum list for all of the tarballs in guix that I can compare against <zimoun>ok, nice! Please post the list on guix-devel or bug-guix. <zimoun>list of the unreachable upstream <OriansJ>and if someone could help me extract the checksum list from guix, we could also have a list of changed upstreams <zimoun>what do you need for the checksum? <zimoun>which kind of output? Because it could be quick with a piece of Scheme and “guix repl” using ’fold-packages’ <OriansJ>zimoun: just the hash and the name with a tab in between if not too much to ask <OriansJ>(name of the tarball to be precise): ah la 9cc4f80db1d15fe34ccc5d80219cf1593277e75119f49fc66f4e5a6699d5263c foo.tar.xz <civodul>yup, great to get feedback from them! <roptat>if we add "-j1" in our dune build system, I think all these issues will be fixed, but then all the builds will be slower :/ <zimoun>roptat: cool and no cool. :-) Well, the default could be -j1 and a parameter to the ocaml build system to modify it by expert or person wanting fast over repro <zimoun>roptat: the same discussion is happening about Haskell. <roptat>zimoun, another possibility is if dune generates all the cmi files first, then builds everything <roptat>in that case, all the cmi will be available, so the build should be reproducible <roptat>we could do it actually: run "dune build @install", then remove any *.cmo and *.cmt files, and rebuild <roptat>obviously, it's going to take twice as long, but on 4 cores, that's already twice as fast as running with one core <roptat>ah no, if I do that, the second run of dune removes the intermediate build products <roptat>mh, no it actually keeps them in place, but the cmt files seem to depend on other stuff (maybe the cmo?) <bdju>anyone ever had lsusb output get mixed together? I have a soundcard that has the second half of the output from my USB WLAN device <bdju>the latter device itself is all there too <zimoun>but be prepared by the output. :-) <zimoun>and basically, the hash is the same as “guix hash” (nix-base32) <rekado_>I need a little bit of help with rust. <rekado_>I’m trying to write a little typescript transpiler using swc as a library <rekado_>but “cargo build” says it cannot find the package “swc” <rekado_>does anyone know how to specify a search path or something similar? <rekado_>oh… the cargo-build-system suggests that everything should just be vendored <stikonas>does rust support anything else? I thought there is no stable ABI for libraries <efraim>rekado_: is there a package for swc? <rekado_>that’s pretty much what I had in mind for virtual conferences <rekado_>doesn’t seem to be free software, though, so there’s still a chance to build this myself with mumble + sdl + guile <rekado_>(it crashes with an unintelligible error message that indicates something hasn’t been implemented) <rekado_>stikonas: I don’t know anything about rust, except for the long incremental bootstrap path and the “rewrite in rust” meme. <stikonas>rekado_: I'm quite a noob in rust too, but from my limitted understanding, they just don't have any ABI <rekado_>I see that our new rust-swc doesn’t actually have anything useful in its output directory… <rekado_>do I just copy the source tarball then…? <jlicht>rekado_: there is now also a package for esbuild, which also allows transpiling typescript to javascript <jlicht>not to tell you that you shouldn't go on a educational adventure, but if it is only about doing the ts -> js stuff, there is an easier way :-) <roptat>whoops, one server down with nobody to reboot it :/ <apteryx>any idea what could provide backtrace.h? seem like gcc's libbacktrace, but that's not anywhere in our gcc-toolchain package <civodul>apteryx: libc has a backtrace.h file <apteryx>wouldn't that header be part of the gcc-toolchain used by the gnu build system? <rekado_>jlicht: oh, if that would work I won’t waste time on rust <mjw>gcc's libbacktrace is Ian Lance Taylor's libbacktrace, but it isn't meant to be a shared library (at least the gcc variant is only used static/internally so as to not confuse backtraces even more by having it dynamically loaded) <jonsger>does `guix system delete-generations` support ranges like 1-80 or so? <zimoun`>is it possible to temporary bypass the deduplication when “guix gc”? My store is too big compared to my DD performance and I am waiting… much too long when just delete one item. <janneke>zimoun`: other than stop the daemon, run it by hand with --disable-deduplication, run guix gc? <zimoun`>janneke: without going by root. BTW, thank you because it will be enough for my current tests :-) <apteryx>perhaps we need to add a flag to build and install it <ryanprior>rekado_ yes esbuild is a nice ts transpiler that already works on large real world ts code bases <nckx>apteryx: ¯\_(ツ)_/¯ I guess! <lost_enchanter>Hi there! I'm Jade, and I came from Outreachy, got curious about your project as Common Lisp user! Are you still looking for people to contribute? :) <roptat>we already have a few other people interested in contributing through outreachy, and can only get one intern in the end, but contributions are always welcome :) <nckx>lost_enchanter: Welcome! <roptat>if you haven't done that yet, you should try installing guix (the package manager) on your current distro. It won't interfere with your system, everything is installed in a separate location <zimoun`>lost_enchanter: Welcome! With you, 4 people seem interested by Outreachy and today we have only one funding. But 2 proposals. ;-) Feel to send an email to guix-devel to introduce yourself and you can try to contribute (at first package or bug fix or translation). <zimoun`>lost_enchanter: As roptat said, the simplest is to start by installing the package manager. It works on any distro without interfering with the distro apckage manager. <roptat>and don't hesitate to ask if you have questions or issues :) <apteryx>nckx: seems it's only used internally in GCC at build time to build other host tools <zimoun`>lost_enchanter: Feel free to drop an email to guix-devel@gnu.org. It is easier to follow who is interested (and then contact them back). And as roptat said (wise person :-)) do not hesitate to ask. <zimoun`>nckx: if you have mood and time, v3 of #43769 (guix-install.sh) :-) <jonsger>how can I garbage collect store items which are used by cuirass (/var/guix/profiles/per-user/cuirass/cuirass)? <neurohound>Hi guys, I have a huge problem. Since my university currently requires me to study from home, I have to have Windows (because of Office 365, Ms Teams, etc.) on one of the hard drives inside my computer (I signed the FSF petition, so maybe that will change...) and for some reason, my GuixSD, which resides on the second hard drive, has been overwriting Windows' boot sector, I think after updating. It has done so two times already. Is this <neurohound>intentional? Can something be done to prevent GuixSD from affecting other drives other than disconnecting Windows' power when Guix is used? I really wish I did not have to do this, but that's what my situation is... <ryanprior>Hi Jade it's cool to hear that your lisp experience led you here! <ryanprior>Let us know how your install goes. If you're looking for some getting-started projects I can walk you through creating a package or updating an existing one. <zimoun`>rekado_: setting (parellel-build? #f) by default seems fixing the unreproducible issue… still investifating. Which should be better than revert. Howver, in both case, the patch goes to core-updates, right? <nckx>neurohound: Wrong ‘target’ device in your (bootloader (bootloader-configuration ...)) ? <lost_enchanter>Thank you everyone! I think I had no problems in installing, now I'm doing the setup. <neurohound>nckx That is a possibility... I will check that in a moment. <roptat>neurohound, certainly not intentional, there's no code that specifically "seek and destroy windows" :) <neurohound>Anyway, I supposed it would not be intentional. I asked... just in case. <roptat>well, bootloaders are difficult to manage correctly... windows tends to do the same with grub so... :D <ryanprior>Did my message get copied and replayed or is my display bugged? <ryanprior>Hmm, it keeps showing up below whatever the bottom message is, so it's probably a display bug. <mfg>is it possible to ignore that a item already exists in teh store and rebuild it nayway? i haven't found such an option... <lost_enchanter>Hey there, what should I do if guix cannot change locale? They were successfully created, but in package installation setlocale fails <mfg>i tried that, it just does one graft and says it successfully built the derivation. So that is not exactly what i was searching for... or do i have to also use --no-grafts? <roptat>lost_enchanter, these are annoying warnings, not errors, so you can ignore them <mfg>yes that is exactly what i was searching for roptat :D <roptat>mfg, it's not really useful to rebuild stuff when they're reproducible, and that'll just ignore the result in any case and keep what you have in the store <roptat>but it's good to gain confidence that what you have is what you'd have built <roptat>lost_enchanter, during "guix install" that message is normal. Does it still appear after that? <roptat>what is your $LANG and what locale package did you install? <mfg>roptat: makes sense, does guix save build logs forever? i mean as i understand it successful build logs are never stored? because that is what i was actually trying to get :D <mfg>the build log of a successful build <roptat>yeah, if you get that warning, every guix command will print it <lost_enchanter>I successfully installed vlc, so I guess no major problems occured <nckx>ryanprior: Which client? <roptat>no, it's safe to ignore these warnings, but they're annoying <mfg>lost_enchanter: are you using guix as a package manager on another distro? if so, are you using bash or antoher shell? on ubuntu i always got those locale warnings. using bash helped, i guess this is due to /etc/{profile,environment} things which are not used by every shell. <ryanprior>Bugged display persists even after rebooting phone. Obnoxious. Haven't seen anything like this before. <roptat>well, "rebooting" on android preserves a lot of state <roptat>you can make bash your default shell with "sudo dpk-reconfigure bash" (or dash, can't remember exactly) <roptat>but ideally, we'd detect that in the installer, and install the corresponding files <OriansJ>thank you zimoun; I'll run that as soon as the wget finishes downloading all valid guix tarball; (Surprisingly even with a dedicated 100MB connection and several hours of downloading, only 5.9GB has been collected thus far) <terramorpha>Hi #guix, I am trying to set up multiple bootloader entries in my operating-system config. One for normal operation, one for loading vfio modules and running a vm with gpu passtrough. I found that it is possible to specify additional kernel modules to load in the initrd using <menu-entry>. However, I still need a way to pass options to those modules (in arch, I did that with /etc/modprobe.d/vfio.conf) that will be d <terramorpha>ependant on the bootloader entry I choose on boot. Is there a way to pass entry-dependant module options ? <roptat>options on the linux command line maybe? <roptat>in a menu-entry, you have the linux-arguments field <OriansJ>Thus far only 3,015 of 74,881 tarballs checked didn't return a 404 <raingloom>it's fine, there are a lot of commits. but ye, this one's been in limbo for a long time now. <roptat>I only see ten patches there, am I missing something? <ryanprior>I learned today that Guix actually has a facility for attaching CPE standard names to packages, which is great. <ryanprior>A lot of packages are missing this field. Would it be helpful for me to send patches to add them? If so, should I follow the one-patch-per-package guideline, even for hundreds of packages? Or would one-patch-per-file maybe be okay? <roptat>I would say one patch per file, but the CPE name is not useful if it's already the name of the package <ryanprior>I think it's nice to note explicitly that the package has CPE info that's the same as the name, as opposed to having no known CPE name. We might write for example (properties `((cpe-name . ,name))) <roptat>maybe discuss it with guix-devel? <apteryx>ryanprior: I think so far the consensus was that that having duplicated information (when the package name matches the cpe name) is not useful and adds clutter for no gain <terramorpha>If I look for the default grub entry in /boot/grub/grub.cfg, I see that grub passes a --system=... option to the kernel. What is this object and how can I retrieve it to pass to my custom bootloader entry ? <ryanprior>apteryx: that makes sense. Maybe a keyword property, like (properties '(#:cpe-same-as-name #t)) to make it explicit without duplicating data? <terramorpha>The thing is that the kernel parameters are generated only for the default entry, but not for the other ones. <apteryx>ryanprior: explicit is often good, but here I'd rather keep the package definition clean if the result is the same. <nckx>ryanprior: Ah. I asked because my Hexchat on Wayland on Guix System has a ‘similar’ last-line-buggering bug when using the search bar, which appears at the bottom. <terramorpha>I figured out what the --system kernel parameter is: it is the path of the operating-system derivation that was built. Which means that if I can't possibly pass the path: the operating-system derivation would be self-referencing <divoplade>Hello all, has anyone managed to push a guix image on docker hub? <rekado_>I used to just import the image with Docker and then push it, but jlicht(?) mentioned another tool to upload the image directly <divoplade>Would you know under what name I could find it? <civodul>"guix pack -f docker --upload-to-da-hub" anyone? *rekado_ sees that the log search is still out of date <rekado_>is it using the wrong Xapian database again…? <divoplade>Aah, yes, now I remember the frustration of not being able to have a generic guix image that everyone could just use <divoplade>I remember not being able to run the guix daemon <divoplade>I remember the horror of trying to cache the store on gitlab CI <divoplade>OK I'll just install the gitlab runner on my machine then ^^ <rekado_>oh, wait, you mean an image *containing* Guix, not an image *built* with Guix? <rekado_>I thought “hard” problems are a different class of problems, not “how do I use this tool”-kind of problems :) <divoplade>So in docker, you need to run it without the chroot protection of builds <divoplade>You need to convince all developers in the world that their software should build without the length guix goes on to make sure builds cannot mess with the system <divoplade>I hope one day gitlab CI will distribute guix jobs to runners <civodul>there's always "docker run --privileged" but hey <civodul>maybe we should implement a Guix backend or something for gitlab-runner <civodul>yeah i know but at work i ended up using a physical machine in part because of that <apteryx>is there a way to 'wrap' a shared object with a LDD_LIBRARY_PATH entry? <apteryx>I have this libleak.so thing that is used with LD_PRELOAD, but it wants a different glibc than the one on the target I want to use this with. <apteryx>If I set LDD_LIBRARY_PATH with the correct Guix-provided glibc, then it's the target application that fails to run <civodul>you mean LD_LIBRARY_PATH? there's RUNPATH in ELF files, which plays a similar role <divoplade>The truth is I would love to replace gitlab CI with guix CI (cuirass, I think it's named like that), but the only problem is I cannot use the same repository for the guix package definition and the actual code, because guix pull would try to compile the application code and it would miss the actual code dependencies... <apteryx>yes, I meant LD_LIBRARY_PATH. I built that libleak.so using a Guix package; the RUNPATH should have been embedded "automatically", right? <rekado_>divoplade: I don’t see why having things in a different repository would be a problem for Cuirass. I’m a bit dense. <divoplade>That would not be a problem for Cuirass. That would be a problem for the gitlab flow, because you would not be able to test a branch before merging it. <civodul>apteryx: yes, but they might also pass -rpath flags of their own; check "objdump -x libleak.so | grep PATH" <civodul>divoplade: Cuirass is still quite hard to set up, unfortunately <divoplade>civodul: cuirass can build different branches, but branches for the package definition, not the actual code. <divoplade>If you want to mirror the branches in the code and the branches in the package definitions, then guix pull will fail at one point because it would think you are under a downgrade attack. <divoplade>At least, that's what I interpreted from my last failed attempt. <civodul>or "guix pull --allow-downgrades" in this case, but really time-machine is a better fit <divoplade>Now that I think of it, it might work if I make one package definition per commit... <divoplade>I mean, having all buildable commits on the same channel at any time <cbaines>I have a Guix package/service, just need to sort the JavaScript out before merging it... <GNUtoo>guix system disk-image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")' <GNUtoo>I glanced over what it tried to install and it looks that it probably is installing a full graphical image <rekado_>I see that we have a cron job on bayfront to run “goggles index” every minute <rekado_>but I’ve never seen any such process <GNUtoo>Is there a target for a base system just to verify that a 'Lime2' is booting with Guix? <apteryx>civodul: interesting, libleak.so seems to work correctly, using its own RUNPATH, but when it is used the way it is intended with LD_PRELOAD=/path/to/libleak.so /usr/bin/mytarget, mytarget seems to inherit from that RUNPATH glibc and fails to launch <GNUtoo>(I want to send a patch for one or more bootloader (only 1 is ready so far) and I need to test it) <zimoun>cbaines: thanks for the update! :-) <GNUtoo>(and the 'installation-os' is just too much time consuming to compile as it doesn't cross compile) <civodul>apteryx: the /usr/bin stuff uses /lib/ld-linux.so, loads the "wrong" libc, and bam <civodul>cbaines: Laminar is the job queue side of things, right? <apteryx>civodul: I see. So I must build libleak with a glibc that matches that of the target... that complicates things a little bit. <cbaines>civodul, Yeah, I run it here https://laminar.cbaines.net/ It's pretty simple in terms of defining jobs, and the environment for them, which makes using it with Guix pretty easy <civodul>cbaines: yes, i remember this one, i was surprised to see them mention "CI" on the web site <cbaines>civodul, I think some people now treat "CI" as an alias for some kind of service you used to run tests against branches in a Git repository, rather than the notion of Continuous Integration <rekado_>divoplade: the thing I meant to upload Guix-generated docker images directly is called “skopeo” <rekado_>(goggles on bayfront got stuck so badly that it could only be killed with “kill -KILL”… Upon restart it loaded the up-to-date search index) <divoplade>I'm sure this work, but it would mean that the image would have exactly one user <divoplade>rekado_: (sorry I'm still learning to tag users I respond to...) <apteryx>civodul: do we have package transformation available that could help in defining a libleak-with-glibc-2.28? <ryanprior>I'm interested in running a non-root Guix daemon, which might be relevant to the Docker discussion <ryanprior>I haven't done much research yet, just starting to look at what options the Guix daemon has and what it does. <ryanprior>But I'd like to be able to run it as my own user and have it use ~/.cache/store <rekado_>ryanprior: non-root daemon at non-standard location means that you cannot use any substitutes. <rekado_>is using “guix pack -RR” an option for you? To run individual packages in non-standard locations. <ryanprior>Interesting, that is an implication that was not obvious to me and I don't know why that would be. <rekado_>it’s because the store location is often embedded in binaries <rekado_>e.g. the RUNPATH of binaries will include the exact location of libraries <rekado_>by using a different store location none of these locations would be correct, so you would need a full rebuild. <ryanprior>Ah okay, yeah I can see that. I don't suppose that could be grafted? <apteryx>civodul: I see package-with-c-toolchain, I'll try this! <rekado_>ryanprior: it’s possible if the store prefix is of the same length as /gnu/store, but you’d still need to write those graft derivations. <rekado_>we don’t have a built-in feature to add store grafts to arbitrary packages <rekado_>it might also fail for obscure reasons, because not all embedded locations might be transparent <civodul>apteryx: i think you not only need the right libc version, you really need the same .so <rekado_>ryanprior: Pjotr has done something like that outside of Guix in the past. <rekado_>with a bunch of scripts and all that <apteryx>civodul: oh! I'd have expected that using the same version would have been sufficient. <ryanprior>Yeah I think we can make it work, even without modifying the binaries at all <rekado_>I guess with some care and thought this could become a proper feature <apteryx>also... where is the glibc version used captured in the gcc-toolchain? <ryanprior>Run the bins in a namespace where we mount a fake filesystem with /gnu/store, but it's actually just ~/.config <divoplade>Can I run "guix hash" if guix is not installed? <ryanprior>The base32 implementation is nonstandard, you have to use the base32-nix algorithm. <ryanprior>The hash is standard, but it won't match what's in guix package definitions if you use standard base32 encoding <rekado_>ryanprior: right, “guix pack -RR” does something similar, but for individual packages <rekado_>I suppose having a feature to do this for the whole store would be neat. <ryanprior>divoplade: you walk the directory structure, sort the names in alphabetical (lexicographical) order, and then feed the data from each file in ordert into your sha1sum (part of coreutils) <apteryx>answering my question about what determines which glibc version is used: it's the glibc package that is found in the (guix build-system gnu)'s standard-packages procedure (aka %final-inputs). <apteryx>%final-inputs comes from (gnu packages commencement) <divoplade>The manual reads "the hash is computed on an archive containing file, including its children if it is a directory. " <apteryx>which defines glibc-final, which inherits 'glibc' from (gnu packages base), which is currently at version 2.31. <divoplade>"Some of the metadata of file is part of the archive; for instance, when file is a regular file, the hash is different depending on whether file is executable or not." <divoplade>(sorry I failed to tag you again ryanprior ) <ryanprior>divoplade: dang I gotta read up on this again, what you're quoting rings a bell <ryanprior>It was about a year ago that I did this and I didn't publish anything, it was just an itch-scratching thing and once I'd successfully replicated a few hashes I was like good bam done <divoplade>Has anyone published a guix image on docker hub containing just the guix program? ^^ <ryanprior>If I can figure it out again I'm definitely blogging about it <civodul>apteryx: thumbs up for checking and closing those ancient bugs! <ryanprior>divoplade: no but I can do that right now if you want. You would need to mount the socket for your docker daemon in there, or forward the appropriate port <apteryx>civodul: eh :-) Let's celebrate when it goes below the 1k count <ryanprior>divoplade: your command would be something like docker run --rm -v /var/guix/:/var/guix ryanprior/guix -- environment --ad-hoc hello -- hello <divoplade>ryanprior: I just want to run "guix hash" in it! <divoplade>ryanprior: Well, maybe it will need bash too... I'll do it <zimoun>apteryx: yeah thanks for closing all these old bugs. I have the same target. :-) <ryanprior>Oh yeah you could do that without a daemon for usre <apteryx>would package-input-rewritting with deep? #t allow me to alterate even the glibc version used by the gnu-build-system? <ryanprior>That's still gonna be a big honking docker container just for guix hash, but not egregious by honking docker industry standards <divoplade>Unfortunately, I need to add the extra 7 MB for bash (on top of the 512 MB of guix!) so that gitlab runner can use it <ryanprior>interesting, why does gitlab runner need bash <ryanprior>I don't know why it would. run it with guix as the entrypoint <divoplade>I can write things like "echo foo > file" in the CI configuration <ryanprior>if you run `docker some/image command >out.txt` that's not using bash in in the container, it's using bash on the host <divoplade>Right, but gitlab CI reads commands and pass them to the entrypoint's stdin <ryanprior>I don't have time to actually test it right now but ping me in the evening US central time if you want me to put together a proof of concept <divoplade>If the megabytes gap between guix and guix+bash was greater than 7/512, maybe I would care... <divoplade>But I think I'll take the risk and pack bash in! <divoplade>Or take no risks, depends on what risk you consider. <ryanprior>oh yeah not much difference in terms of size, but I like knowing what the requirements are and why - if bash really is required, that's interesting to me <divoplade>ryanprior: Ah, I know the problem: I need to redirect the output to a file, so that gitlab considers it an artifact. Since guix hash does not have a -o option, and gitlab CI artifacts cannot include the shell output, I need to redirect it myself... so bash. <rekado_>apteryx, zimoun Thanks for bug triage! It’s really valuable. <apteryx>it has to rebuild the world (including the bootstrap!) so it's gonna take a little bit of time <rekado_>and it’s tough, because sometimes bug discussions just peter out with inconclusive results <apteryx>indeed! I've been tackling those that look easy (but even these sometimes transform into deep rabbit holes) <rekado_>be sure to pack the Holy Hand Grenade of Antioch in case you run into the rabbit! <civodul>apteryx: but note that package-input-rewriting takes pairs of packages 