IRC channel logs
2024-05-29.log
back to list of logs
<ieure>fnat, What commit of Guix are you on? Manual indicates that the image field can be a string or oci-image record -- perhaps you're on an older commit which only accepts an oci-record? <ieure>So you're almost definitely on a slightly (> 3 days) older Guix which doesn't support that. <ieure>So... Update, or use an oci-image value in that field. <fnat>ieure: I guix pulled and reconfigured just today. 'guix system describe' says I'm on 542b18709a46e361de8f25e3fece29860532743c. <fnat>Perhaps I didn't run hash or something like that though? <ieure>Yes, possible. I've also noticed on at least one occasion that I didn't see changes reflected properly until I rebooted, even `sudo herd restart guix-daemon' wouldn't do it. <ieure>That was a recent change I made to stop offload from requiring the presence of a public key for the remote host, which it then didn't use, because public key cryptography doesn't work that way. <fnat>Oh, that's interesting. Thanks ieure, I'll try that and report back. <ieure>Generally, though, the most that's required to see changes after pull is a logout / login. <zjabbar>I have tried to build the =oci-container-service= from the manual and I could not get it to work either. <weary-traveler>can shepherd run under systemd? specifically, what's needed to be able to run shepherd services using guix as a package manager on a foreign distro? <lilyp>you only need to start it as a user service, i think `guix home` ought to have you covered on that <apteryx>hm, our chromium build is 1 year old <efraim>for core-updates, mesa on aarch64 wants libclc. libclc-15 wants llvm-18 which is too expensive <efraim>ugh, looks like I might try making a libclc variant that uses llvm-for-mesa, just switching it to llvm-15 still pulls in an extra llvm-15 and also llvm-13 <efraim>looks like its the addition of the asahi driver <noobest>Mainly asking because lack of ways to setup LUKS2 or have an unencrypted/seperate boot is what has been keeping me from switching to a guix system. Could not find any other updates or comments on the matter on the mailing list or issue tracker <pabs3>Altadil: Debian's debbugs also has the option to subscribe to bugs, presumably GNU ones do too <Altadil>pabs3: oh, nice, I’ll look for this , next time. Thanks! <Altadil>The Guix Foundation website says it’s possible to pay by wire transfer, but I can’t find the banking info required (like the account to give to). Is this not an option anymore? I couldn’t find anything on this in the mail/IRC archives, so I hope this is a correct place for this kind of question. <efraim>the Guix Foundation is currently between bank accounts, so there isn't anywhere to wire the money currently, unless you feel comfortable wiring it to the treasurer <Altadil>efraim: oh ok. Is there some place to look at to stay updated on the change? <Altadil>(Well, I guess wiring to the treasurer is the same as sending cash anyway) <efraim>it looks like the guix-europe mailing list is the best option ATM <Altadil>efraim: I wonder how I missed this list! Thanks a lot! <janneke>seems we all need to build the full rust stack locally? <efraim>looks like it. I'll try queueing up librsvg on berlin <jpoiret>janneke: i wish I could send mine :) <jpoiret>efraim: I found it difficult to merge the various mesa changes together <jpoiret>c-u had original changes for mesa that didn't end up in the merged mesa-updates <efraim>I thought about using llvm-15 and clang-15 to build a bunch of the bits needed, but I might try again using llvm and clang at their default 13 and see if that works <rekado>I'm using "guix shell nss-certs" and there's no ca-certificates.crt anymore <rekado>looks like I just need to propagate nss-certs; it's not enough to have it as an input to any of the other packages in the pack. <janneke>"<jpoiret> janneke: i wish I could send mine :)" -- it's about time this were trivially possible! ;) <ngz>Hmmm push error to repository: no rule for "authenticate" target. :( <ngz>Trying `guix git authenticate'… Authenticating 75981 new commits oO; <ngz>I have a bad feeling <PotentialUser-25>Considering a switch to Guix... question about kernels. I saw it is possibe to use the Linux and HURD kernels. <PotentialUser-25>Can they coexist? Can I have a system with both kernels and a shared set of binary applications, libraries, ...? Or does each need its own environment, basically having two complete and separate operating systems? <flypaper-ultimat>abbe: a few days ago you mentioned that you got an error of '#{ %make-platform-procedure/abi-check}#: unbound variable', i'm getting the same when error i do a `guix time-machine -q --commit=d6bd483cd53cedc8da39fcc6c419f7241080ed21 -- build nano` (which is admittedly a very old commit, but this is for a sientific project). I'm not getting the error when i'm doing it with a a very recent (e.g. dc8fb56724). did you ever figure out what <janneke>PotentialUser-25: the Hurd is experimental; I wouldn't call it a technology preview yet <janneke>it won't run on most hardware just yet and many packages are not supported in Guix yet <janneke>our installer doesn't support the Hurd yet... <janneke>having said that, i have a thinkpad-x60 that dual boots into a guix/hurd and guix/linux system <ngz>`guix git authenticate' didn't help. Any idea about this push error "no rule for 'authenticate' target"? <efraim>janneke: we're up to building rust-1.58 on berlin <PotentialUser-25>janneke, do you know which is the plan (if any) to make the Linux and HURD kernels coexist in the future? Will they be ever be able to share the same operating system environment (binary compatibility)? <singpolyma>It may happen but I'm not sure there's any point beyond "for fun". Which is of course a valid point <janneke>PotentialUser-25: what do you mean with binary compatibility, which kind of binary file would you expect to be compatible? <janneke>i think the best we could hope for is for a system to share /gnu (store) and /home and be dual-bootable <efraim>I think they're thinking of running binaries built for either system without rebooting <efraim>I suppose similarly to binfmt-emulation <janneke>ah, right; that might be feasible using a qemu service <jpoiret>ngz: your pre-push hook has not been updated since the authentication system changed <jpoiret>you want to copy the one in etc/git/ <jpoiret>don't know if that's supposed to be automated <janneke>singpolyma: what makes you think that, esp. given what's happened the past years? <singpolyma>janneke: it's effectively impossible for any kernel to catch up to Linux at this point. This is why Haiku, ReactOS, Hurd, even most BSDs, remain niche at best because of lack of hardware support <rekado>Hurd has a way of using NetBSD (and Linux) drivers. <janneke>also, Hurd is POSIX compatible and it has about 80% of all packages in Debian <singpolyma>rekado: if it can use Linux drivers mostly unmodified then maybe it will be able to reach parity. That's a good strategy <Googulator>AFAIK Hurd isn't supposed to use "drivers" in the sense most OSes have them <rekado>singpolyma: the Linux stuff is sadly pretty old; the NetBSD stuff is easier to keep up to date. It uses a NetBSD rumpkernel as a server process. <rekado>Googulator: you still need to talk to hardware one way or another. <Googulator>everything in Hurd is meant to be in userspace with restricted privileges, if at all possible, which is at odds with how drivers work in Linux <singpolyma>Googulator: yes I'm aware of how microkernels work. Though it *might* be possible to run Linux modules in a process wrapper. rekado seems to be saying this has ever been done <Googulator>That would potentially be possible if Linux provided a stable driver API <Googulator>but as of now, drivers on Linux are intimately bound to the particular kernel version they were packaged with or built against <efraim>I found why this test is failing on mozjs-102 on riscv64 and its already fixed on the mozjs that's part of icecat <efraim>I guess not quite as relevant, that's 115 <rekado>Googulator: see DDE. It was difficult to keep it up to date, so DDE is stuck at Linux 2.6. The new way is rumpkernel. DDE likely has no future. <ngz>jpoiret: Thanks. That worked! <sughosha>Hi! How can I add a keyboard layout with bracket, like "ca(eng)"? If I set like this, this error comes: invalid character `\' in name `console-keymap.ca\(eng\)-builder'. <sughosha>I also tried with escaping the brackets (with double backslashes), but it also gave similar error. <jfred>Drat, I tried using git-annex in a `guix shell` but I guess it's not available on aarch64? Is that the case for all Haskell packages? <futurile>Virtual meetup with David Wilson presenting his 5 years of Guix tips-n-tricks starts in 5 mins <PotentialUser16>Does anyone know how to configure guix to download source code from private repos? I'm trying to set up an internal channel for some of my organization's internal tooling and am having issues when I try to run "guix package -f my_package_definition.scm". Here's what I see in the logs https://paste.debian.net/plainh/d54e4488. It looks like guix <ieure>PotentialUser16, As far as I know, there isn't any good way to build from a private repo. Builds happen in isolation, as a different user, so it's expected that your user config has no effect on it. <ieure>You'd have to make your private key an input to the package, which means it has to go in the store somewhere, which is world-readable... Not at all what you want. <PotentialUser16>I know that private channels can be created and guix is able to pull from them via ssh just fine <PotentialUser16>It seems bizarre to me that the same isn't doable for building source code <ieure>They're different processes with different requirements. A major goal of Guix is reproduceable builds, which means they should work the same no matter what -- if there's an implicit dependency on your environment, they're not reproduceable. <ieure>I agree that it is annoying. <PotentialUser16>Well how can I pass a key into a package to make this work? I don't really care about it ending up in the store since this is all running on internal hardware and keys can be blown away and regenerated as needed <ieure>I am not aware of any reasonable mechanism to do what you want (this is not the same as "no such mechanism exists"). <PotentialUser16>I'll continue to look into it to see what I can find. We're liking guix quite a bit but if we can't build our own internal tools with it that's a hard stop for us <PotentialUser16>So I found that apparently "git-checkout" can clone a private repo, but I'm getting "could not find appropriate mechanism for credentials" so it's still not picking up my keys <tty9-mm>PotentialUser16: You could encrypt credentials and that's what goes into the store and then the mechanism to decrypt is retrieved by a server that has some other authorization mechanism. Yes, it would be convoluted but if you want reproducibilty then that's the price you pay. <ieure>tty9-mm, Issue is that you can't talk to a server during a build, since they're isolated from the network. <tty9-mm>ieure: Just with `guix build`? That's news to me. I thought I ran across some discussion about doing it this way (I haven't yet tried myself). <ieure>tty9-mm, Anything inside a package build has zero network access. <ieure>The simplest thing is to self-host your repos and have them public, but only accessible from inside your corporate network. <ieure>"self-host" could mean a pull mirror which has credentials on whatever the main work repo is. <ieure>Gitea lets you do this, it's pretty simple to set up. <tty9-mm>Okay. That would boil down to the same thing that I was thinking anyway. E.g.: Auth by IP restriction. <futurile>tty9-mm: are you building the package locally? <ieure>(PotentialUser16 is the one with the problem) <tty9-mm>futurile: No. PotentialUser16 is the one who is asking. :) <PotentialUser16>Apparently my key was just in the wrong format and guix wasn't reading it properly <ieure>Oh, this is that libssh2 issue where it needs PEM format? <PotentialUser16>This will work fine for us. I care about the reproducibility of the build itself but don't really care about reproducibility as far as the download is concerned since these are all private anyway. <PotentialUser16>One last question: is there a way to have an unknown or blank license? Since all of these packages are internal only we don't have an actual license, but I know that package definitions require a license type to be specified <ieure>PotentialUser16, I think you can do (license #f). Or you can make your own license structure. <ieure>(Nonguix has examples of this) <PierreChTux>I've been trying Guix for a little while, but unfortunately, I encountered a few problems, so far. <PierreChTux>When I run, as an ordinary user, `guix pull`, it systematically takes a very long time, and always ends with an error. <PierreChTux>Authentification du canal « guix », commits 9edb3f6 à 0f3a25a (8 nouveaux commits)... <futurile>do you get a more detailed log file if you do guix build --log-file /gnu/store/aymmp63sjs0507s9m4zq0lydg7ld8354-guix-translated-texinfo.drv <PierreChTux>Note that "guix pull" had ran successfully when I installed Guix, as root. I just tried to run it again, and unfortunately, it also failed. <PierreChTux>pierre@hprose ~$ guix build --log-file /gnu/store/aymmp63sjs0507s9m4zq0lydg7ld8354-guix-translated-texinfo.drv <zeropoint>are there vods of the guix meetups/code review sessions or is that not a thing? <futurile>zeropoint: there's only one so far which is Ludo's talk from a couple of weeks ago. <futurile>PierreChTux: can you try it as root maybe - but I guess it's saying there is no log file <PierreChTux>I'm trying to run "guix pull" as root now. It takes *time*. <futurile>OK it's the same - so bleugh not very helpful - maybe someone else will know what to do <civodul>PierreChTux: ‘guix build --log-file …’ should print the name of a log file <PierreChTux>civodul I suppose that I should give additional instructions: <PierreChTux>guix build: warning: no arguments specified, nothing to do <PierreChTux>civodul I've tried putting the package which was mentioned above, without success: <PierreChTux>root@hprose ~# guix build --log-file guix-translated-texinfo <PierreChTux>guix build: error: guix-translated-texinfo: unknown package <PierreChTux>root@hprose ~# guix build --log-file guix-translated-texinfo.drv <PierreChTux>guix build: error: guix-translated-texinfo.drv: unknown package <PierreChTux>I'm wondering if I shouldn't re-install the whole Guix OS from scratch. Or is there some way to "reset" it? <PierreChTux>Sorry, I'm a newbie in Guix, I'm very curious of it, but I'm much more used to Debian and Devuan distributions. <PierreChTux>I'm thinking that maybe my Internet connection could be a concern regarding the slowness of any "guix pull"? <PierreChTux>I'm connected through a Starlink device. The connection is very good, I can see videos (I'm listening to Ludovic), but some protocols may not appreciate this kind of connection? <Altadil>PierreChTux: If it’s installed version 1.4 and it’s your first guix pull after installing, I believe it is expected to take a long time, since there have been many commits since it was made. But of course it should not failed. <Altadil>PierreChTux: Also, don’t worry about feeling disoriented, it’s normal, since Guix is quite different from a "classical" OS. There is a lot to wrap your head around. :) <PierreChTux>Altadil ;-D I began Reading The French Manuals, but I stumbled upon the "guix pull" which seems to be a basic thing. <PierreChTux>This is free software: you are free to change and redistribute it. <freakingpenguin>Huh, I never realized guix --version was a thing, I'm so used to describe. <PierreChTux>freakingpenguin I'm so used to do "whatever --version" that I didn't even think about it... <PierreChTux>By the way, while typing "guix des<TAB>", I notice that the completion is very slow. Is this normal? <janneke>build of /gnu/store/0gqv2qb1kdfa22jzgsca4lgm747gj91b-gawk-5.3.0.drv failed <janneke>ACTION tries to reconfigure on core-updates <brendn>I've also noticed how slow completion of the guix subcommands is. I'm not sure if that's normal or not <PierreChTux>brendn so that's potentially a subject that I could try to contribute! <freakingpenguin>PierreChTux: $ guix build guix-translated-texinfo failing makes sense, that's not a public package and you aren't providing a full /gnu/store/blah.drv path. <freakingpenguin>Did you try running guix build /gnu/store/blah-guix-translated-texinfo.drv i.e. the full derivation path? <freakingpenguin>Don't know why the derivation failed but that would be how you try running it again without going through guix pull again. It should be deterministic so you should get the same error I'd imagine, but maybe not? <brendn>PierreChTux: Yep that would definitely improve the experience. Right now I find it faster to type out the full command rather than waiting for completion to finish. <PierreChTux>Actually, I'm just trying to make the Guix OS work, so far, I have no idea how the beast actually work. I must RTFM a lot. <PierreChTux>freakingpenguin at the moment, all I've been trying to do is "guix pull"... <PierreChTux>I'm wondering if something went wrong when I installed it, and it keeps on annoying me. I'm getting a bit hopeless... <PierreChTux>It is Guix OS, on bare metal, on a 32 bit old laptop computer. <PierreChTux>It is Guix OS, on bare metal, on an old 32 bit laptop computer. <PierreChTux>(it seems that one cannot correct a typo in here...) <PierreChTux>On another machine, I installed Guix on top of Devuan (Devuan is Debian without systemd). <PierreChTux> # pierre@latitude: ~ < 2024_05_29__22_59_03 > [bashpid_9436 3] <PierreChTux>ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. <PierreChTux>guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory <PierreChTux> # pierre@latitude: ~ < 2024_05_29__22_59_05 > [bashpid_9436 4] <PierreChTux>Actually, two of my machines are not able to run properly with systemd; that's why I switched from Debian to Devuan. <PierreChTux>Ah! I was running "guix pull" as root, in the meantime, it just finished (badly). <PierreChTux>freakingpenguin it's quite possible, the machine hasn't got a lot of RAM: <PierreChTux>By the way, I had setup the swap when I installed Guix, but it is not mounted, for some reason, and doesn't appear in the fstab. <PierreChTux>It's getting late on this part of the planet: good night/day/morning/evening, thanks for the help!