<bjc>ah well, glibc-mesboot couldn't be built. so i guess that's the end of this adventure <horizoninnovatio>Wine64-staging (6.6) fails build - bug already reported. If I build from source (winehq staging 7.8) is it likely to fail to build? <bdju>anyone happen to know if nyxt is a long build? it's a web browser, so I'm thinking probably. just can't remember <bjc>…why would ‘guix pull --no-substitutes’ download linux-libre-5.10.35-gnu.tar.xz? ***unwired4 is now known as unwired
<jts>hey, I'm getting an error on system upgrade I can't find the cause of. I haven't changed my system config since the last successful upgrade. error: "guix system: erreur : #<<platform> target: "x86_64-linux-gnu" system: "x86_64-linux" linux-architecture: "x86_64" glibc-dynamic-linker: "/lib/ld-linux-x86-64.so.2"> : entrée G-expression invalide" anyone know what might be causing this? <jts>(erreur == error ; entrée G-expression invalide == invalid G-expression entry, i think, i've only used it in french) <lechner>bjc: Hi, gcc probably needed <linux/limits.h> when building something else <lechner>or was it the -gnu (instead of -guix) that you were after? <bjc>lechner: there's a separate -headers tarball for the kernel, i think. but then again, maybe that gets created as one of the outputs of the main kernel source ***roptat is now known as Guest8033
***Server sets mode: +Ccntz
<reza[m]>hello guix, I'm hitting this error with guix deploy: `[GSSH ERROR] Channel opening failure: channel 66 error (2) open failed: #<input-output: channel (closed) 7f10dd164c00>` has anyone experienced something similar? <zeta_reticuli>anyone know how to change terminal prompt color in GNU Guix System? <jonsger[m]>I think that depends on your Desktop Environment aka your terminal you are using (e.g. GNOME terminal or XFCE terminal), zeta_reticuli <jpoiret>you'd have to customize PS1 or something like this <hnhx[m]><zeta_reticuli> "anyone know how to change..." <- Edit $HOME/.bashrc <zeta_reticuli>I got this: PS1='\u@\h\[\033[00m\] \[\033[00;37m]\w [env]\$\[\033[00m\] ' but doesn't work <zeta_reticuli>I know how to change prompt color on Debian but this doesn't work on Guix System <abrenon>maybe something is sourcing a profile or bashrc you're not expecting <zeta_reticuli>abrenon: I can't change terminal prompt color in XFCE4, I tried use strings from my debian's bashrc but this doesn't work <zeta_reticuli>jpoiret: XFCE terminal. I can change text color and background color in preferences but I can't change hostname color <jpoiret>is anything able to use colors in your terminal? <jpoiret>if you echo the ANSI color codes with some text, does it work? <jpoiret>i don't think it's a guix system thing though <zeta_reticuli>jpoiret: maybe, I'll try to do something. Thanks for helping <cbaines>I've been looking more at the data.guix.gnu.org failures, and I think the linux-module build system is broken <cbaines>I think the change in this commit is leading to the #:arch passed to the linux-module-build procedure being a platform record, which leads to the invalid G-expression input exception <cbaines>trying to get the platform-linux-architecture from that record leads to another exception though: Wrong type to apply: #<syntax-transformer platform-linux-architecture> <jpoiret>cbaines: are you trying that locally? <jpoiret>you'd likely need to recompile the file you're testing <cbaines>I'm guessing it's because of the way module-ref is used to access these things from the build system module <jpoiret>the wrong type to apply: syntax-transformer issues often come from the compiler not having expanded the syntax <cbaines>haha, my laptop doesn't need to overheat more :) <jpoiret>you could selectively rm the .go files <jpoiret>what file/line are you talking about exactly <cbaines>I ended up making platform-linux-architecture a procedure that wraps the record accessor, and that seemed to help <jpoiret>right. doesn't seem like the proper way though, let me see if i can cook-up some ugly expand+compile-time thing <cbaines>the other thing to maybe look at here is why the linter seems to crash, rather than reporting the derivation issue <cbaines>e.g. ./pre-inst-env guix lint xpadneo errors, whereas ./pre-inst-env guix lint mescc-tools properly reports an issue creating the derivation <lembrun[m]>terraform hcl is so ugly, so painful after working with guix and scheme <mothacehe>zimoun: hi! berlin is unreacheable since saturday and the running system is in an unkown state. <zimoun>mothacehe: thanks. But why the website is available and only the recent posts are not there? Is it because a poor sync with Bordeaux or else? <mothacehe>mcron must be building an older version of the website <jpoiret>cbaines: seems to me that the change the (gnu platform) means that there are no longer risks of circular deps, and that one can just use-module it at the top <jpoiret>previously it was in (gnu packages linux) hence the need for the module-ref shenanigans <jpoiret>cbaines: do you want me to test a patch that would do that? <civodul>mothacehe: i don't think the mcron job could build an older revision of the web site, so my guess is that there are no mcron jobs running <civodul>plus we're somehow reading an old /srv <civodul>i can't wait to know the details :-) <cbaines>jpoiret, sure, I'm busy until this evening/tomorrow <jpoiret>a (guix ...) module shouldn't use-module a (gnu ...) module right? <jpoiret>shouldn't (gnu platform) be moved to (guix ...) instead then? <jpoiret>cause we'd need it in (guix build-system linux-module) <jpoiret>and it itself only uses (guix ...) modules <jpoiret>arf, the distinction is blurry sometimes :p <civodul>but yes, it could be that (guix platform) would be a better fit <mothacehe>platforms are also accessed by (gnu system image) <jpoiret>i'll try a s/(gnu platform)/(guix platform)/ <civodul>there are #:use-module (gnu packages linux) in there, but they're not actually used <jpoiret>right. Should I also move the (gnu platforms hurd) and friends? <mothacehe>seems fine yes, sorry i didn't notice those issues. (guix self) will also need to be adapted <efraim>hurd is exported from (gnu platforms x86) and (gnu platforms hurd) <jpoiret>what would you all recommend to mass replace some files? sed/awk/something else? <jpoiret>i also want to drop some lines though <efraim>I would be more likely to use 'grep -c' and some pipes and open all the files with vim then and do it by hand <ss2>there's wgrep for emacs. <ss2>gives you an writable grep buffer to edit all matches directly. <abrenon>jpoiret: I'd still use sed because when it comes to deleting lines I'm usually wary enough to want to create a new version of the files to be able to diff both versions afterwards and make sure nothing unintended happened <horizoninnovatio>If I compile an app from source, (wine64-staging-7.8) are there any special considerations to take into account? <tom1192>Hi, I have installed Guix System to my RockPro64 (aarch64). I'm having trouble finding a browser that compiles. Can anybody recommend a browser that's currently building on aarch64? <tom1192>icecat, ungoogled-chromium, and epiphany aren't. <tom1192>I do have Emacs Eww, but I'm hoping for a graphical browser. :) <PotentialUser-33>tom1192 I don't have a system like that, but you could try nyxt or qutebrowser <tom1192>PotentialUser-33: Thanks, qutebrowser installed from substitutes. Perfect! ***PotentialUser-33 is now known as bovid-19
***PotentialUser-33 is now known as bovid_19
<bovid_19>On my machine, `guix home reconfigure' currently fails because `emacs-deferred' gets stuck in the `check' phase (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55504). I've tried to find out more by building the package, but I couldn't get further than finding out that it stops at this error: `deferred error : (wrong-number-of-arguments (3 . 3) <bovid_19>I looked up how the package ended up in my profile and followed `emacs-dash', one of its dependants. Other packages propagate conflicting entries for it. When I try to upgrade those at the same time, I get the same problem for another package (emacs-ace-window). (https://paste.debian.net/1241735/) <bovid_19>Isn't this one of the kinds of problems that Guix is supposed to solve? Is there a way to upgrade everything at the same time with just one command instead of copying and pasting from error messages until you get the complete set of packages you need? <rekado>bovid_19: yes. You can use a manifest. <rekado>entries in a manifest are installed all together, all from the same version of Guix. <rekado>propagation is often required by some applications (e.g. R packages or Python modules as R and Python find packages through search paths), and there’s nothing Guix can do here. <rekado>in a single profile there should not be conflicts or multiple versions of the same packages. <rekado>use separate profiles if you need more than one package variant. <civodul>bovid_19: FWIW i'm also stuck because of emacs-deferred; i guess we should check whether there's a fix available upstream <bovid_19>then I haven't been able to get back to a working Emacs configuration. I should probably start again with a fresh installation. <civodul>bovid_19: nope, i was trying to upgrade to Emacs 28 (the default one) <silicius[m]>is emacs-magit with emacs 28 broken only for me? Can't commit, or do anything useful. ***Avichi is now known as Avici
<bovid_19>I keep getting "Could not find build log" errors when I run `guix pull' with my local channel enabled. The only reference to that error that I could find is this one: '“Could not find build log” typically happens if you’re talking to a remote daemon, via GUIX_DAEMON_SOCKET. In that case, the build log is in /var/log/guix/drvs (or similar) <bovid_19>on the machine where the daemon is running.' [https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47949]. I assume the context I experience the error in is just atypical, not a potential bug, so I'll try and find the cause in the log now that I know where it could be. Is there a reason why Guix shouldn't look there for the logs? <civodul>bovid_19: right, when you're talking to a remote daemon with GUIX_DAEMON_SOCKET, "guix" doesn't really know it's remote, so upon failure it looks for a build log under /var/log/guix and doesn't find it <civodul>build logs are not part of the client/daemon protocol, so all the command does is look for it in the "usual place" <jonsger[m]>civodul congrats on the reboot. On bare metal its always some kind of "adventure" :P *nckx has a 133-day uptime somewhere they'd rather not. <foobarxyz>HI I'm trying to install the clang:extra output, but it appears is not available in my enviroment <foobarxyz>guix package --list-available returns only one output, out, while I was expecting to get "extra" as well <foobarxyz>e.g. what I am getting is clang 14.0.3 out gnu/packages/llvm.scm:631:4 <bovid_19>civodul: Thanks. I must be missing or misunderstanding something. Does a channel located on the local file system and added to the `channels.scm' file with a `file' URI use a remote daemon? Adding that channel is the only thing different from when `guix pull' works. GUIX_DAEMON_SOCKET doesn't seem to be set at all. <jpoiret>raghavgururajan: i think there are some issues with 4cf7d0f836d08fd41aab02e1f6793146ce3cad8d <foobarxyz>I have performed a successful guix pull, but nothing changed <nckx>foobarxyz: That won't be possible I'm afraid, that output isn't coming back. It was merged into the main output. <nckx>Is there something missing? <jpoiret>recompiling ci.scm gives me 'dynamic linker name not known for this system "x86_64-linux"' <jpoiret>i'm thinking %current-system wasn't updated to hold a platform record when applicable <nckx>foobarxyz: Indeed, I have it here in 12 & 13 but it's gone in 14. <nckx>I don't think it's directly related to the removal of clang:extra… *nckx downloading llvm@14 sources at 95KiB/s… <foobarxyz>nckx: yes indeed I can see it in 13. What do you think it might be happening in 14? <nckx>That's what I wanted a look around the sources for, but this is prohibitive. Hm. <nckx>foobarxyz: All I can say is that Guix didn't deliberately remove or stop building clangd AFAICT. <nckx>Anyway, my recommendation for now is to use clang@13 unless you really need the edge. <nckx>OK, clang-14 is missing (as in, never had) an explicit #:tools-extra. Let's add one and see what happens. <nckx>I wonder how long this will take on a laptop. <bovid_19>nckx: Wouldn't a dedicated VM on a powerful machine (the build server maybe?) for debugging issues like these make sense? <nckx>I sometimes use bayfront for this, but the unreliable network gave me pause. <nckx>The laptop isn't that weak, to be clear, but OTOH this is clang. *nckx splits the baby, starts a remote build too, let's see if SSH holds. <bovid_19>If your connection is bad, tmux/screen (optionally over mosh) could be useful. <nckx>That sounds unsafe to answer in today's climate. <jpoiret>arf, i don't really follow what the platform changes are, but it seems that there's an issue in glibc-dynamic-linker in gnu/packages/bootstrap.scm <rekado>FYI: I’ll reboot berlin.guix.gnu.org now; ci.guix.gnu.org will be unavailable for a little while. <unmatched-paren>anyone know of any ath9k vendors other than thinkpenguin? their prices are -a little- very high, especially combined with the delivery charges to the UK. <bovid_19>unmatched-paren: I've bought from aliexpress. First a USB device, then a card for the laptop. I could look up the exact devices if you're interested. <jackhill>unmatched-paren: I'm in the USA, and have actually talked wth the thinkpenguin folks at conferences, so support their work, but I agree about prices. What form factor are you looking for? I've bough a Compex WLE200NX as mentioned here: https://community.mnt.re/t/parts-needed-to-finish-diy-kit/67/4 when gettign a mini-pcie card. It allegedly came out of some unsoled IoT toys or somesuch <jackhill>unmatched-paren: cool. I should probably get a dongle too for hostile systems :) <unmatched-paren>I might switch to using a full card once I get a framework laptop, which hopefully won't require me to do any soldering? <bovid_19>You shouldn't have to solder. What kind of laptop do you have? <tewi>hello, does anybody know if there's a problem with the ci.guix.gnu.org substitute server? <unmatched-paren>bovid_19: how does having your boot entries intermittently wiped sound? :P <jpoiret>it's making every guix build/package/friends error out though, which is annoying <tewi>jpoiret: thanks, wanted to make sure it's not just me <akonai>are services with #:log-files entries not extending rottlog intentional? it seems that neither ntp nor mail services ever do any log rotation <sohamg>Hey please can someone tell me the correct way to install a DE (xfce/mate) on the command line AFTER installing? I tried guix install xfce and mate but that doesnt seem to have set everything up <civodul>jpoiret: yeah, we should do something about that 'connect*' call <civodul>akonai: it's most likely an omission (and these services may predate the extensibility of rottlog-service-type) <sohamg>jpoiret yeah im playing with a guix system in a VM <jpoiret>you'd need to add the corresponding services to the (services ...) part of your system config and reconfigure <akonai>Would extending rottlog with the same files from different services cause issues? since all mail seem to log to the same maillog file <jpoiret>ouch, I can't even link the manual because berlin is down <sohamg>Well, guix.gnu.org itself seems to be down <jpoiret>you can consult it locally with `info` <bovid_19>unmatched-paren: It's always great when things break, but random occurrences are obviously the best. I guess I cannot compete, the problems I have with my system are probably all of my own making. Is there a chance a firmware update could help? <sohamg>jpoiret So I should be looking at the system configuration section correct? <sohamg>Oh my reconfigure is gonna be a pain in the butt with no substitutes <sohamg>Thanks for pointing me in the right direction jpoiret <sohamg>Feels very hacker-y to find the solution *without* the internet <nckx>sohamg: Make sure you've authorised bordeaux.guix.gnu.org and that it's in your substitutes list. It should have a good deal of (or even more than) what berlin would have served. <nckx>I think it should be by default, but if you see 0 substitutions, check. <unmatched-paren>bovid_19: Sadly, it's easy to fix by booting into the live USB, mounting the disk, and reinstalling grub. I really ought to file a complaint. <unmatched-paren>Outrageously, it's probably even easier than that. I haven't looked into it, but it seems likely to me that it might be fixable with efibootmgr. <rekado>status update: the disk controller seleceted the wrong disk to boot from; changed the boot device; waiting for initialization <rekado>several minutes pass from the time of reset until grub appears <rekado>the btrfs disks are not recognized again… <unmatched-paren>the Guix USB is 50$ and doesn't even seem to come with a support contract... <nckx>What kind of support are you expecting for a mere $50 o_O <rekado>I’m tempted to just boot the old system from the abandoned hard disk raid <unmatched-paren>fair enough, i was talking about "Support is available for 6 months from the date of purchase" below the tails usb. it's probably nothing like what Red Hat and Canonical offer. <sohamg>....why would anyone trust a store bought Tails USB? <rekado>in grub it sees the 6 SSDs, but for each of them says "No known filesystem detected“ <nckx>unmatched-paren: It would be interesting to find out. <unmatched-paren>sohamg: to be fair i don't see any reason to trust a USB that you flashed yourself either, unless you built the device :P but you do have a good point <unmatched-paren>sohamg: how do you know the rabbit hole isn't compromised unless you dug it yourself? *unmatched-paren .oO argh, "Big Bunny" would have been better <bovid_19>unmatched-paren: Maybe I should become a reseller. I wouldn't be cheaper, since the prices seem very fair, but I could paint them with golden colour so you can see and show the value. And maybe add some fake diamonds every few devices so it makes sense for clients to buy in bulk. <alanz>Is there a problem with ci.guix.gnu.org at the moment? I am getting a connection failed to it when doing "guix pull" <nckx>unmatched-paren: He's a chunky boi. <nckx>alanz: It's being rebooted. <nckx>All is under control, citizen, rumours of being stuck at GRUB with a failed btrfs array assembly have been spread by enemies of the state. <bovid_19>I thought it was supposed to be pronounced as "better", not "bitter" <nckx>Butter. As in, etch your precious data in a slab of butter to safely preserve it for future generations. <bjc>ci.guix's travails have done well to quash my desire to try swapping from zfs to btrfs <bjc>silver linings and all that <jackhill>is the problem really btrfs or the disk controller though? <KarlJoad>Has anyone else notices guile-fibers not building? Or is that just me locally? <bjc>dunno. but if its the controller causing these issues, that seems like something that needs fixing sooner rather than later <jackhill>KarlJoad: I sucessfully built it (locally on Linux x86-64) from guix commit 81f7bb1691dc9dc69fc6e584ad8c6e36e495c103 <nckx>OK, OK, I'll get the topic-changin' stick. <Haider>Do you know any particular reason? ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | 🚨 guix.gnu.org is down 🚨 use https://bugs.gnu.org/guix & https://bugs.gnu.org/guix-patches for now | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<KarlJoad>jackhill: Interesting... Mine fails due to a test on Guix commit 2f58393d995de9638140962cf4c40e5f2ba08c3a <KarlJoad>Very strange. The build log says "failed to create path for auto-compiled file "/tmp/guix-build-guile-fibers-1.1.0-0.c25dcb9.drv-0/source/./tests/speedup.scm"" <KarlJoad>Maybe I should manually specify the commit guix should use for now? <KarlJoad>Would this build failure be a good one to upload somewhere? <nckx>sneek: later tell foobarxyz: clang@14 now includes the extras in the main output just like previous versions. Pull! <nckx>Speaking of bordeaux that sorely need an update: bordeaux.guix.gnu.org: 353 days(!), 21:16:49 *nckx hands the cake to rekado instead. <cbaines>nckx, probably clearer to say bayfront <cbaines>like berlin, it's a little risky to reboot (probably more risky actually since there's no remote serial connection) <rekado>can I have my cake and eat it too? <rekado>the server behind ci.guix.gnu.org is up, but the postgres service fails (probably because we reset the server without giving it time to shut down), so cuirass and the cuirass web interface are not running now. <rekado>issues.guix.gnu.org is up, though. <sohamg>How do I force use a substitute when the derivation/.drv of the package exists in my store? ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<cbaines>sohamg, you can ask guix to build the output instead, so guix build /gnu/store/... <sohamg>cbaines does that pull from the substitutes server ? <nckx>You can't force Guix to use a substitute, you can only point it to a reachable & authorised substitute server that has the substitute you expect. If it doesn't find any, one of those conditions is not met. In that case, Guix will always fall back to building. <sohamg>guix weather <package> --substitute-url=<url> shows theres a sub available but both guix install and guix build start building from source <sohamg>im using the flag on all commands <nckx>Are the other assumptions met? <sohamg>I dont know what that would mean <nckx>Is the key in /etc/guix/acl? <sohamg>yes I imported the key with guix archive < key.pub (the command from the manual) <nckx>sohamg: Which derivation is this, exactly? <nckx>OK, that ought to have done it. <sohamg>IDK if im allowed to discuss that but its the full linux kernel (non free incl) <nckx>Ah. No comment, but: so it's not something I could reproduce here, OK. <dirtcastle>what does emacs-vterm package do? if I didn't compile emacs with --with-modules option will it still work. or what is it about <kaelyn>sohamg: I noticed issues with a package like that always wanting to rebuild on my computers despite having a local substitute server with the package; I got the substituting to work by using an inferior to pin the exact commit of all channels for the package I want to substitute properly. <kaelyn>(I also had imported the pub key of the substitute server to my other systems.) <nckx>Surely the exact derivation differed between the 2 systems? <jackhill>what does "command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "59745" "svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/doc/latex/qrcode/" "/tmp/guix-directory.XtDpCQ/doc/latex/qrcode/" failed with signal 11 <jackhill>guix import: error: failed to import package 'qrcode'" from `guix import texlive qrcode` mean? Did I invoke the import incorrectly? Did I use the wrong package name? Is that texlive package not supported? <nckx>svn had itself a segmentation fault. <nckx>sneek: later tell sohamg: As I feared, it just works here (identical derivation to yours): https://paste.debian.net/plainh/c1a0f6ed — I just noticed your message above: ‘I imported the key with guix archive < key.pub’, which is missing an ‘--authorize’. Maybe it was a typo, but could you actually verify that *that* key *is* in fact in /etc/guix/acl? <nckx>jackhill: It's bad, but reproducible. <nckx>I don't know what it ‘means’ beyond a bug or miscompilation in our svn binary. <jackhill>heh. At leat's it's a normal bug and not a spooky one <nckx>Yes, I am very pleased that I don't have to point you towards memtest. <nckx>Use that newly returned bug tracker real good. <jackhill>nckx: here you go: $ guix import texlive qrcode <jackhill>command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "59745" "svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/doc/latex/qrcode/" "/tmp/guix-directory.6aY7Gk/doc/latex/qrcode/" failed with signal 11 *nckx deletes ‘ha ha -_-’ <madage>civodul: Hi! Regarding #55399, I've tried sending merge requests by mail to guile-git, but the patches were auto rejected. The reject message is not clear, it just says I'm not allowed to 'perform this action'. <madage>so I've tried requesting access through the gitlab web interface, but afaik it's still pending approval and also I don't know if it's this that I'm missing <nckx>jackhill: I don't know why I didn't think of this sooner, but I ran that svn by hand (only replacing the output directory, say /tmp/foo) and… it ran fine. <nckx>…I'll add that to the mail. <jackhill>at any rate, it looks like that svn command is not going to get tin information needed import that package <nckx>It's actually guix that is segfaulting, sorry for not noticing that earlier. <nckx>In my defence: Unix error messages. <nckx>jackhill: The command line is actually valid AFAIK (not a Tex user). <nckx>It checks out a nice PDF & a README. <nckx>It's only when run inside the importer(?) that it crashes. <vagrantc>ooops... my last update to diffoscope included a wishful thinking fiction in the comments regarding libxmlb *vagrantc forgot to push the moneypatch upstream <vagrantc>luckily nckx didn't notice and left it in :) *nckx did, but forgot to update the comment. <nckx>I was just going to change it to 215 :) <nckx>Uh, that's what I meant. Jesus. <vagrantc>precision *and* accuracy, that's what we stand for! <nckx>vagrantc: Hey, you misspelled ‘monkey’. <vagrantc>nckx: i am proud of my failures sometimes <jpoiret>./pre-inst-env guix build acpi-call-linux-module tells me the hash is mismatched, however it was updated along with the last version <nckx>The current hash is for commit 9f1c0b5d046bdfdec769809435257647fd475473, 3 commits out :-/ <vagrantc>yeah, i don't see why people are so averse to just making a minor point release <nckx>I'll update it unless you've already done so jpoiret. <nckx>What's this fresh hell: guix build: error: #<<platform> target: "x86_64-linux-gnu" system: "x86_64-linux" linux-architecture: "x86_64" glibc-dynamic-linker: "/lib/ld-linux-x86-64.so.2">: invalid G-expression input <nckx>Somebody done broke the l-m-b-s? <cbaines>there was discussion of that earlier today <cbaines>jpoiret was looking in to fixing it I think <civodul>madage: re guile-git, not sure, maybe you can open an issue and explain what's wrong, for lack of a better idea? <sneek>Welcome back civodul, you have 1 message! <civodul>madage: re guile-git, not sure, maybe you can open an issue and explain what's wrong, for lack of a better idea? <jpoiret>i can send a wip patch that seems to work <jpoiret>should i just update the hash? theoretically it will change the package for everyone <nckx>jpoiret: What do you mean by that last line? <nckx>The patch itself would only update the hash, it's the commit message that's the most important (note which commit was the original, which I gave somewhere above, and the new commit, and what changed, plus a link to the GH issue). <ss2>nckx, oh, I'm getting this error to with invalid G-expression input while tryint to build a module. <ss2>I mean too, and this module is not part of Guix proper yet. <nckx>It affects all l-m-b-s packages. <jpoiret>i'm sending the patch now, just rereading my commit message <jpoiret>i ended up moving a bunch of modules for it <nckx>I prefer to let cbaines handle reviewing that, if they're around. <jpoiret>does guix/ have an equivalent to gnu/local.mk? <cbaines>I am around so I can have a look at things <nckx>Depends on what you want, but probably that jpoiret ☝ <jpoiret>ouch, forgot to add things to Makefile.am then, just sent the cover letter :p <jpoiret>with this and the updated hash i am able to build acpi-call-linux-module <jpoiret>that may be annoying to review though <jpoiret>nckx: was lmbs not deterministic from the start? <nckx>I don't know what you mean by deterministic? <nckx>(I haven't looked at you patches yet, if that matters.) <jpoiret>ie are its built outputs reproducible <jpoiret>i just `guix build --check acpi-call-linux-module` and it differed <jpoiret>although i don't think the patch that changes the hash will matter much <patched[m]>Is it possible to add local channels? The examples in the infopages assume the channel is published somewhere online <nckx>jpoiret: Oh, no, I don't think it ever was. Nor is the linux pacakge proper AFAIK. <ss2>patched[m]: use (url "path/to/local/channel") <nckx>Or (url "file:///home/you/foo") if you want. <cbaines>jpoiret, the patches at #55602 look OK to me, I'd wait a little while to give mothacehe a chance to see them though <nckx>gnu → guix looks so obviously right that I wonder why gnu was preferred. <jpoiret>right, i'm a little bit worried i might have missed something in the seds <nckx>I'd feel the same way :) <jpoiret>nckx: there was some (use-modules (gnu packages linux)) in all of the platforms, although they weren't used <nckx>(issues. is back up, by the way.) <nckx>Unless you verified it, I think my ‘3 commits’ above was bogus, I simply cannot count today (see previous discussion). I'll check that and merge. <ryanprior[m]>Thread: more Python packages are vendoring in huge opaque binaries to enable the Guix-like developer experience people want <ryanprior[m]>>Python Playwright - when you run "pip install playwright" you get a package including a binary copy of the Node.js runtime, which is how they offer the same API in both Python and JS - Python calls JS under the hood <ryanprior[m]>People badly want the experience Guix can provide, with multi-language environments, builds and deploys managed by their developer tools <patched[m]><nckx> "Or (url "file:///home/you/foo..." <- Tried this at first, but it won't show up when I do guix search. <nckx>I use it for all my channels; it works. <nckx>ryanprior[m]: It is jarring to me how the OP and all comments so far are a pretty much positive: ‘Nice’, what an ‘interesting new pattern’. Meanwhile, half of us here are banging our foreheads on our keyboards. <nckx>It's ‘this is fine’ personified. <ryanprior[m]>That's why I wanted to share, it points out to me that Guix is the near tip of the spear, thrusting towards a better developer experience <ryanprior[m]>But it's far from given that our approach with its various benefits will prevail <ryanprior[m]>If pypi provides an ugly vendored-in binary C compiler and node runtime that work on windows+mac+linux and come complete with language-specific tutorials and documentation for Python users, <ryanprior[m]>while Guix provides transparent modular reproducible versions of the same but only to Linux users and you have to figure out the details yourself, <nckx>jpoiret: I forgot to add a [source] field to the changelog. Next time! <KarlJoad>So Guix, I have a mystery. My Guix disk disappears from the EFI boot list when I replace it with another one, and put the Guix disk back in. I have verified that it always happens, does not depend on actual SSD, and SSD install method.