<vagrantc>when i see a thread that is primarily between two people, with multiple posts per hour over the course of several hours ... i get a little nervous <bjc>i'm too intimidated to butt in on the thread, but it's made me wonder if a lot of the search path problems could be solved with union/overlay mounts <bjc>like, on login, all the “special” profile directories (e.g., ~/.guix-profile/share) could be union mounted into one place <pashencija[m]><civodul> "pashencija: hi! what command did..." <- guix system init --skip-checks ./test.scm ./rootfs <civodul>apteryx: yeah i guess we can drop wicd <vagrantc>i used it recently on an aarch64 system when network-manager wasn't available <vagrantc>oh yeah, still need to bisect guix build failure on aarch64 :( *vagrantc wonders about making good life choices sometimes <vagrantc>i couldn't figure out how to do the most basic things with connman <civodul>pashencija[m]: (guix cpu) is used by the --tune option; is test.scm using it somehow? <vagrantc>and, show me what connections are running <civodul>i've never used it directly, but it seems to work ok in the installer <vagrantc>i'm sure it's just a learning curve thing, like many things :) <vagrantc>but when you're looking for a quick workaround... it doesn't fit the bill <civodul>pashencija[m]: ah you mean that's a test failure when running "guix build guix"? <f1refly>how can I tell guix to rfkill bluetooth on boot? I don't use it for anything, but the card is always enabled. blacklisting the kernel module would be overkill, just rfkilling it would be nice <civodul>pashencija[m]: unfortunately "guix build guix -s aarch64-linux --no-grafts --log-file" returns a useless log :-/ <civodul>if you have it, it'd be great if you could email an issue to bug-guix@gnu.org <pashencija[m]>civodul: No no no. You cannot reproduce it on your system if it's X86 machine. The test fails only on aarch64 host <vagrantc>oh, i've got a guix build guix failure log somewhere... <vagrantc>pashencija[m]: just get it into the bug tracker <vagrantc>i've got a system booting now, i'll see if i can't get started on the bug report <vagrantc>it's nice to file a bug, sleep, and wake up to a fix :) <civodul>pashencija[m]: oh sorry, i had overlooked the log; tx <civodul>pashencija[m]: i've reported it to bug-guix and will look at it later, thanks again ***rekado_ is now known as rekado
<lechner>singpolyma: i'm not sure the term "garbage"should cover inputs needed for rebuilding. for some reason they are fetched again even if substitutes are available, maybe for the system derivations? <lechner>Hi, for configuration files and other file references, which are in /etc (like letsencrypt) and which are in the store, please? <littlebobeep>Can anyone explain this architecture limitation for vapoursynth: ;; src/core/cpufeatures only allows x86, ARM or PPC <rekado>littlebobeep: have you looked at the file yet? <attila_lendvai>clang-toolchain symlinks a bin/cc but the gcc-toolchain doesn't. is there a reson for not doing it? or is that just omission? *attila_lendvai decides to just send a patch and see if it lands this time <rekado>GCC upstream doesn’t do it, and we don’t usually install symlinks. <rekado>see also python-wrapper vs python <civodul>attila_lendvai: the reason clang-toolchain has symlinks is that ./configure scripts don't know about "clang", but they do know about "gcc"and "cc" <civodul>so you're right that there's some kind of an inconsistency <civodul>but there's some kind of a justification too :-) <attila_lendvai>also note that it's a much better user experience when you don't need to repeatedly CC=gcc (it's been a frequent annoyance for me), but things just work. there are a lot of software packages that don't depend on autotools. <attila_lendvai>interesting tidbit: there does exist a 'bin/c++' in the gcc package, but not a 'bin/cc' <attila_lendvai>or put it another way: what's the downside/ugly in symlink'ing 'cc' in the gcc-toolchain package? <civodul>i guess you already read the arguments in the thread above :-) <civodul>overall, it's a tradeoff; in Guix packages, lack of 'cc' is sometimes annoying, but rarely enough <attila_lendvai>'And also, it turns out to work for 99% of the packages.' -- that is certainly not true for 99% of the packages that i'm building/packaging myself. <civodul>in all of Guix it's probably more like 80/20 <civodul>what kind of packages are you looking at? <civodul>idris has: (setenv "CC" ,(cc-for-target)) <attila_lendvai>civodul, i'm using a guix.scm and guix shell to enter an environment to work on idris. the issue manifests in that shell. ***Guest28 is now known as davidl
<nckx>lechner: I didn't follow the conversation but you might be interested in --gc-keep-outputs (and read the documentation for the next option, too). It tweaks the definition of 'garbage' to be closer to what you seem to prefer. <nckx>Note that it's a guix-daemon, not guix gc, option. ***furrymcg1e is now known as furrymcgee
<htgoebel>I'm seeking some guile-advice: How to create a list of 2-tuples (to be passed to for-each, giving 2 arguments for the for-each body) <cbaines>htgoebel, for-each doesn't accept 2-tuples, but multiple lists that form the arguments <cbaines>something like (for-each (lambda (a b) (peek a b)) '(1 2 3) '(4 5 6)) <htgoebel>Any other solution allowing to keep the tuples (which express a relevant relation) <cbaines>I'm not sure what you're asking, are you wanting to create a list of 2-tuples, or do something with a list of 2-tuples? <rekado>htgoebel: (for-each (match-lambda ((a . b) (pk 'a a 'b b 'a+b (+ a b)))) '((1 . 2) (3 . 4))) <efraim>janneke: re mescc-tools, guix doesn't actually support riscv32-linux <efraim>also mescc-tools builds and passes its tests on powerpc-linux <janneke>efraim: oops; i removed powerpc-linux because it cannot build binaries for it <janneke>while the latest M2libc has riscv32_defs.M1, so i hoped it would build <janneke>efraim: please fix how you see fit; i mainly wanted to enable riscv64 <civodul>janneke: great to see dezyne land in Guix! <civodul>BTW, you can run "guix style -S inputs dezyne" for the more fashionable style <janneke>oops, did /me get stylishly unhooked...tssk, tssk ***WesterWest[m] is now known as Maya[m]
*janneke rust guix style -S and wonders how that plays with assoc-ref...finding out <janneke>how do i rewrite "#:modules ((ice-9 popen) ,@%gnu-build-system-modules)" to the new and fancy gexp style? <mekeor[m]>is there documentation on how guix works internally? e.g. what packagr derivations are and how builds work etc? the manual is just about how to use guix but not how it works. <mekeor[m]>does guix (still) use nix internally / under the neath? <jpoiret>the build daemon (the one that builds derivations) is a fork of the nix one, although they've diverged now iiuc <cbaines>looks like ci.guix.gnu.org has been stuck processing the master branch since Monday <civodul>cbaines: really? "./pre-inst-env guix weather tcl-tls guix-modules" says that these two packages i pushed minutes ago have substitutes <cbaines>I guess I should be more specific, the last successful evaluation showing on the web interface is for 654f878, which dates from Monday evening <cbaines>even though the "Success" of the evaluations "In progress", you're right in that it looks like some things are being built <cbaines>clicking on the "In progress" evaluations shows builds happening recently <civodul>yeah, it's definitely building things, and very quickly <civodul>i'm trying "make cuirass-jobs" to see what's up <civodul>data.guix didn't have troubles processing those revisions, right? <cbaines>it's hard to tell, the large temproots issue seems to be back on data.guix.gnu.org, which has meant that it's a bit behind and has failed in processing some recent revisions <cbaines>it's been fine for the past few months as far as I can see, but in the past week there's been problems with running out of disk space, with 60+ GB worth of temproot files <cbaines>ah, now I've looked, I think what's triggered this is the processing of some old revisions dating from 2019-03-11 <cbaines>which is around the time of that revision I was previously looking at <apteryx>(the issue where GRUB ain't able to assemble a degraded LUKS + RAID1 array) <nckx>Why doesn't it work, Christoph[m]? <apteryx>it works if you 'guix shell -D guix', but there's a guix.scm source file that gets picked up otherwise (which is not designed to be a manifest.scm) *apteryx is locked from their desktop, and doesn't really want to do the chroot <apteryx>chroot + reconfigure dance; so if there are GRUB gurus around, I'm all ears <civodul>you seem to be doing crazy things :-) <Christoph[m]>nckx: Oh, the environment version.works, but not the shell version. <apteryx>yeah. That's my go to when I'm locked at the GRUB screen <civodul>as in GRUB isn't correctly installed or something? <nckx>Christoph[m]: ‘guix shell’ isn't an exact synonym of ‘guix environment’. <nckx>I mean it's not as simple as s/environment/shell/ & go. <apteryx>(GRUB doesn't successfully mount a degraded LUKS RAID1 array on which /boot resides) <apteryx>which partially defeats RAID. I guess the low cost solution would be to put /boot on different, unencrypted RAID1 partition (this should work, as we have a system test for degraded RAID1 sans LUKS) <apteryx>the best solution would be to fix GRUB <nckx>‘error: you only gave me one complete copy of the drive, I need 2 identical copies to continue’. <apteryx>to its credit, it already handles a zillion cases decently <apteryx>putting /boot on LUKS + RAID is probably pushing it <apteryx>I'll look at the sources in case I may be inspired today <nckx>Oh yeah, I just meant weird, not bad. <nckx>By raid you mean Linux (md) raid? <apteryx>but I suppose the same may hold true for mdadm raid, reading the internet <jpoiret>good luck, grub sources are, ehmmmm, pretty raw <apteryx>there's been almost 600 commits in GRUB since 2.04 ***PapuaHardyNet is now known as mesaoptimizer
<rekado>I need some help with a Rust package whose Cargo file mentions a dependency on a subdirectory; when building it that package defined in a subdirectory is not found. <rekado>do I need to build the sub-directory as its own package first? <maximed>attila_lendvai: A downside of a cc->gcc symlink: if there's a 'cc' and the Makefile uses 'cc', then that appears to work, but it will break when cross-compiling. <maximed>(upside): Whereas if there isn't a 'cc' at all, then you'll get an error message _directly_ instead of silently a binary for the wrong architecture. <maximed>(please don't do CC=gcc, do CC=(cc-for-target) instead) <htsr[m]>hi guix! I'm trying to cross-compile an image for an arm board (guix system image --image-type=rock64-raw --system=aarch64-linux configuration.scm) but it always fail with <htsr[m]>guix build: erreur : opening file `/gnu/store/1zqnv048bww5kqzylqyjyl879b74q7z1-patch-2.7.6.drv': No such file or directory <htsr[m]>Is it normal? I've heard that cross-compiling wasn't working <htsr[m]>Even guix build --system=aarch64-linux hello is failling <apteryx>htsr[m]: your later example is not cross compilation; it's native compilation using either a real or emulated aarch64-linux host <apteryx>to cross compile, you need to use --target and a valid GNU system triplet <apteryx>but I seem to recall that image embed their own target type, not sure, so perhaps you do't need to provide it when building images <cwebber>what's the magit command/keybinding for generating changelog style things again? <lilyp>cwebber: there's yasnippets for that <jackhill>I assume that's a bug? (expected behaviour would be to just exit I suppose?) <boomerChad>I'm trying to write a home-environement record that will keep an 'offlineimap' process running as a service but I am having trouble getting a configuration file to be created in the new environment for offlineimap. My code is pasted here https://paste.debian.net/1240126/ Right now it is saying that <boomerChad>guix home: error: invalid name: `.offlineimaprc' <cbaines>lechner, it will, as a normal file, are you asking how to find it? <cbaines>boomerChad, I'm guessing the dot may be causing this problem <cbaines>lechner, there's a few different ways, but one way is to start at the store item representing a system, then follow the references to find the config file <cbaines>so look at /var/guix/profiles/system and follow the symlinks until you get to something in /gnu/store <cbaines>then run guix gc -R on that store item, and grep for opensmtpd-configuration <boomerChad>Yes, I have also tried it without the dot and the file doesn't appear in the new environment, but ideally I would want to be able to create a hidden file right? <cbaines>unfortunately I don't know much about guix home <lechner>cbaines: i can't find the file in /var/guix/profiles/system <cbaines>lechner, it won't be in there, although it'll probably be referenced from there <cbaines>an alternative for looking at the current system, you can guix system build to get the store item, then follow the references from there <lechner>cbaines: that's what i meant. i can't find anything at the location, not even a link <cbaines>lechner, hmm, I'd assumed you were running Guix as a system, and this was part of your configuration. I'm pretty sure the system profiles normally appear in /var/guix/profiles <cbaines>does that /var/guix/profiles directory exist, and contain any system profiles? <cbaines>ok, maybe try the guix system build approach anyway <cbaines>get the store item for the system, then run guix gc -R on that <apteryx>cwebber: press C on the variable/thing on the diff while reviewing a diff in the magit commit buffer <apteryx>'C-h m' to visualize the bindings/actions in scope when your memory fails <cwebber>apteryx: yes I was looking at that and yet I wasn't seeing it in there <cwebber>because I kept thinking it was a C-c command <cwebber>lilyp: btw you mentioned yasnippets, which means I assume you don't know about this one. Give it a try. it's a killer feature. <cwebber>Putting your cursor over a diff hunk with a procedure and typing C in the magit staging interface will automatically create the changelog structure relevant to that file/expression, if it can. <apteryx>you may also be interested in running ./etc/committer.scm to commit simple changes such as upgrades <cwebber>apteryx: huh! didn't know about that one. <boomerChad>For anyone searching through the archive, I figured out my problem. You're supposed to include dotfiles through the home-files-service-type service. <lechner>cbaines: okay, i found it. thanks! unfortunately it does not appear to be used. do i have to boot into the new system, or is a herd restart enough? <cbaines>lechner, herd restart should be enough to apply configuration changes for a service like opensmtpd <lechner>cbaines: the recommended way to debug is to run the daemon without daemonizing, but on Guix it does not find the config. should i try guix environment ? <lilyp>cwebber: good to know for the projects in which I'm actually maintaining the ChangeLogs manually <cbaines>lechner, telling smtpd where to find the config should be sufficient <lechner>cbaines: with the explicit path into the store? <cbaines>yes, if that's the configuration you want to test with <cbaines>this is how the service is usually run through the shepherd <lechner>cbaines: thanks! the daemon works fine, but GNU mailutils refuses to send from localhost, possibly because sendmail from opensmtpd fails with "this program must be setgid smtpq" <lechner>vivien: ^ hi, can you use mail from mailutils on localhost? <vivien>lechner, could you elaborate? I don’t understand <cbaines>lechner, I've also encountered that, at least in the past. I'm not sure what the current situation is <vagrantc>anyone know how to subscribe to a bug with debbugs.gnu.org ? on debian's i email BUGNUMBER-subscribe@ and it's done. didn't seem to wok with debbugs.gnu.org <mekeor[m]>the --with-branch param for guix-package is not explicitly and dedicatedly documented, right? *mekeor[m] is gonna use it for emacs29 <lechner>vivien: port 25 works fine on localhost but the direct 'sendmail' access that is traditionally also provided seems to fail with the current opensmtpd <lechner>vivien: can you try 'which sendmail' and then sendmail self@toto.com <lechner>cbaines: did you encounter an issue with opensmtpd or with GNU mailutils? <vivien>I get Mprog: A= argument required <jab>I just saw on guix devel...the announcement of Dezyne as open source. Is this useful to guix in some way? <cbaines>lechner, that's different from the binary being setgid smtpq though <lechner>cbaines: my sendmail points to -r-xr-xr-x 2 root root 200904 Dec 31 1969 /gnu/store/3r78ppn17ckiqm6fm7g1xh8fanf18azp-opensmtpd-6.8.0p2/sbin/smtpctl <cbaines>On a Guix system, setuid/setgid stuff is handled outside of the store, look at sudo for example <jpoiret>setuid-programs get literally copied out of the store to be able to change perms <jpoiret>it should be a setuid-program record (setgid-program doesn't exist) but exactly yes <jpoiret>also, just a nitpick but (cons* el1 el2 rest) reads better than (append (list el1 el2) rest) :p <the_tubular>No i was reading their gitlab page, let me take a look at this. <lechner>cbaines jpoiret: do i have to reboot to test the setgid? <jpoiret>i think a reconfigure should be enough <lechner>also, what's this, please? shepherd: Evaluating user expression (and (defined? (quote transient?)) (map (# ?) ?)). <jpoiret>good question. Do you have something that looks like that in your config? i'm not sure i've seen a message similar to this one <jpoiret>maybe i'm blind and these have always happened <jpoiret>it's guix trying to determine which herd services to restart <apteryx>as fixing the root and prefix variables in the GRUB rescue shell allows GRUB to load <unmatched-paren>what does `warning: no tags were found for foo` mean from `guix lint`? <ulfvonbelow>trying to package a perl package (spamassassin) and several of the perl inputs in propagated-inputs aren't being seen in the build process. For example, perl-netaddr-ip is in propagated-inputs, but every test is autofailing because it can't find it. I've verified it (/gnu/store/61ifd25anvwvy6g1g439d1515ndzb68d-perl-netaddr-ip-4.079/lib) is in LIBRARY_PATH. <ulfvonbelow>it looks like the actual module is a fair bit deeper though, in something like /gnu/store/61ifd25anvwvy6g1g439d1515ndzb68d-perl-netaddr-ip-4.079/lib/perl5/site_perl/5.34.0/x86_64-linux-thread-multi/NetAddr/IP.pm <ulfvonbelow>anyone familiar with perl know how it decides where to look? <apteryx>there's an environment variable in guix for perl (search path) <ulfvonbelow>didn't see that because 'C-r perl' landed me at the LIBRARY_PATH part of the 'set-paths' phase <lechner>cbaines jpoiret: alas, my setgid attempt did not work. can i debug? <luishgh>hi guix, how could I download a remote file to my home directory through guix home? <jpoiret>lechner: is the program you want in /run/setuid-programs? <lechner>jpoiret: it is, with the right group +s <jpoiret>then, does `which theprogram` point to /run/setuid-programs/theprogram? <jpoiret>if not, is /var/setuid-programs in your $PATH, in front of the other locations? <nckx>Also, ‘hash theprogramme’ because bash doesn't check $PATH each time. <jpoiret>and /run/setuid-programs often appears after ~/.guix-profile/bin because of the order in which those env vars are set <jpoiret>so make sure you don't have that program in your profile <jpoiret>i blindly assumed (for no reason) it was set at the same time as the system profile's <nckx>Well, if you do ever notice Guix doing that out of the box, uh, say something 😉 <lechner>jpoiret: PATH=/gnu/store/wsgv3l0w6chglk2d51q1vvbjr3163gnj-glib-2.70.2-bin/bin:/run/setuid-programs:/home/lechner/.config/guix/current/bin:/home/lechner/.guix-profile/bin:/home/lechner/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin <jpoiret>looks okay to me, try `hash leprogramme` as nckx suggested <nckx>Yes. (Imma ignore that glib/bin thing completely.) <nckx>‘which’ is not a reliable way to know what your shell will actually run. <unmatched-paren>it's a builtin, so surely it'd be consistent with the shell's behaviour <nckx>unmatched-paren: I have always assumed so, but I have never actually verified it uses the same code path. That would certainly be the logical thing to do! <lechner>my problem is elsewhere. this link does not go to /run/setuid-programs lrwxrwxrwx 1 root root 7 Dec 31 1969 /gnu/store/3r78ppn17ckiqm6fm7g1xh8fanf18azp-opensmtpd-6.8.0p2/sbin/sendmail -> smtpctl <jpoiret>ohhh, you won't be able to make the store link to a setuid program <nckx>And it never will(/can). <nckx>Buut… why is that a problem? <nckx>Something is invoking /gnu/store/…/sendmail directly? <nckx>Welp, that won't work, for sure. <nckx>mailutils does not retain a reference to opensmtpd. <nckx>It should (if it's to blame at all) use $PATH. <lechner>if the modified executable is on the PATH, it should run <vagrantc>presuming it doesn't try to call it with a specified path... <lechner>maybe opensmtpd can ship #!/bin/sh smtpctl instead <nckx>vagrantc: It would (barring obfuscation) retain a reference to that path, no? <vagrantc>nckx: how would mailutils know what is providing sendmail to embed the path? <lechner>fwiw, i don't think the issue is in mailutils <nckx>vagrantc: That's really what I mean. <nckx>So saying that /gnu/store/…/sendmail is ‘wrong’ is… wrong. It's fine, it shouldn't be called at all, it should be irrelevant. <nckx>Something else is buggy. <nckx>Nobody's saying the contrary. :) <nckx>And sendmail works fine. <lechner>sendmail from opensmtpd fails with "this program must be setgid smtpq" <nckx>ls /run/setuid-programs/sendmail -l <nckx>-r-xr-sr-x 1 root smtpq 200904 Jan 31 02:25 /run/setuid-programs/sendmail <nckx>It just sent mail to myself. <nckx>We need to find out why it doesn't work or get called for you. <lechner>which package provided that copy of sendmail, please? <nckx>I thought that was what we were discussing. <lechner>ls: cannot access '/run/setuid-programs/sendmail': No such file or directory