IRC channel logs


back to list of logs

<singpolyma>lechner: depends on your goals
<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
<civodul>i used it too!
<civodul>twas terrible :-)
<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
<civodul>connman is a better substitute, no?
<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>like, bring up my networking
<vagrantc>and, show me what connections are running
<civodul>ah, that's problematic :-)
<civodul>i've never used it directly, but it seems to work ok in the installer
<pashencija[m]>civodul: But the problem is in autotests, isn't it?
<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"?
<pashencija[m]>civodul: I think so. Can you please check the log?
<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
<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>for aarch64
<pashencija[m]>I have sent my log here. What's wrong with it?
<pashencija[m]>I mean
<pashencija[m]>I can run your command tomorrow I suppose
<vagrantc>pashencija[m]: just get it into the bug tracker
<vagrantc>oh, i guess mine was different
<vagrantc>even better
<pashencija[m]>vagrantc: I'll try that tomorrow, thank you
<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
<pashencija[m]>civodul: ?
<civodul>pashencija[m]: i've reported it to bug-guix and will look at it later, thanks again
*civodul -> zZz
***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>i wish my define-configuration patch would get some love: i'm happy to reshape it as needed.
<civodul>Hello Guix!
<AceTheMercenary[>Sup, civodul!
<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>civodul, you had apparently rejected this issue several years ago: i wonder if your opinion has changed since then?
*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
<attila_lendvai>rekado, then what's the deal with clang-toolchain?
<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 :-)
<civodul>but yeah, it's a tradeoff
<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
<civodul>apteryx: i see we're running the new 'guix publish' with "minimal" narinfo signatures, neat!
<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?
<attila_lendvai>...but it's also not a hill worth dying on for me... :)
*civodul nods
<attila_lendvai>civodul, the last drop just now was idris2
<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.
<civodul>hmm i see
<abrenon>hi guix
<civodul>howdy abrenon :-)
<abrenon>: )
<abrenon>hi jpoiret
***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>Hello guix,
<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>cbains: IC. Thanks.
<htgoebel>Any other solution allowing to keep the tuples (which express a relevant relation)
<rekado>you can use match-lambda
<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)))
<htgoebel>rekado: This does the tick. Thanks.
<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>civodul: you mis nothing! \o/
<civodul>of course not! :-)
<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
<mekeor[m]>hey guix, how are y'all doing? :)
<janneke>how do i rewrite "#:modules ((ice-9 popen) ,@%gnu-build-system-modules)" to the new and fancy gexp style?
<civodul>janneke: that doesn't change
<civodul>there's a partial guide to the new style at
<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.
<janneke>civodul: thanks!
<jpoiret>for derivations and the build daemon, it's quite similar to nix, so the .drv explanation in eg should help mekeor[m]
<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
<mekeor[m]>s/ the //
<mekeor[m]>intresting :)
<cbaines>looks like 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
<civodul>mekeor[m]: also
<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, which has meant that it's a bit behind and has failed in processing some recent revisions
<civodul>"the large temproots issue"?
<cbaines>I did open an issue ( ) but I haven't had much luck tracking it down yet
<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>eh, one drive down on my main machine, and hitting
<apteryx>(the issue where GRUB ain't able to assemble a degraded LUKS + RAID1 array)
<Christoph[m]>Hi guix! instructs to use `git environment guix --pure` to hack on Guix. Will this be updated to `guix shell`? (Right now, the latter does not work.)
<nckx>Why doesn't it work, Christoph[m]?
<jpoiret>wdym by the latter does not work?
<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)
<jpoiret>it works for me™, just checked
<apteryx>there's a bug on the tracker for it
<civodul>Christoph[m]: you can check the /devel URL for the development version of the manual:
*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>chroot + reconfigure?
<civodul>you seem to be doing crazy things :-)
<Christoph[m]>nckx: Oh, the environment, but not the shell version.
<apteryx>yeah. That's my go to when I'm locked at the GRUB screen
<apteryx>failed GRUB screen
<civodul>as in GRUB isn't correctly installed or something?
<Christoph[m]>apteryx: Ah, I see! Thank you!
<nckx>Christoph[m]: ‘guix shell’ isn't an exact synonym of ‘guix environment’.
*civodul has to go
<nckx>I mean it's not as simple as s/environment/shell/ & go.
<apteryx>civodul: o/
<apteryx>civodul: this issue
<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’.
<nckx>OK GRUB.
<nckx>GRUB is weird.
<apteryx>to its credit, it already handles a zillion cases decently
<apteryx>but not mine :-)
<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?
<nckx>= …or btrfs?
*nckx away.
<apteryx>btrfs 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
<apteryx>ah, but we're already on 2.06
<apteryx>200 commits then
***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?
<sneek>maximed: Greetings :)
<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)
<maximed>sneek: botsnack
<maximed>sneek: later tell attila_lendvai:
<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
<htsr[m]>apteryx: Thanks!
<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>*brain breaks*
<cwebber>what's the magit command/keybinding for generating changelog style things again?
<lilyp>cwebber: there's yasnippets for that
<jackhill>sometimes my guix commands get stuck after printing messages like
<jackhill>I assume that's a bug? (expected behaviour would be to just exit I suppose?)
<jackhill>I went ahead and filed a report
<lechner>Hi, will this config-file appear in the store? How can I examine it? Thanks!
<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 Right now it is saying that
<boomerChad>guix home: error: invalid name: `.offlineimaprc'
<boomerChad>Is there a better way to do this? Thanks
<cbaines>lechner, it will, as a normal file, are you asking how to find it?
<lechner>cbaines: yes, please
<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?
<lechner>it does
<lechner>cbaines: ^
<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: ah yes capital-C!
<cwebber>apteryx: yes I was looking at that and yet I wasn't seeing it in there
<cwebber>but admittedly
<cwebber>because I kept thinking it was a C-c command
<cwebber>so I kept skipping over it
<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 ? on debian's i email BUGNUMBER-subscribe@ and it's done. didn't seem to wok with
<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
<lechner>cbaines: did you encounter an issue with opensmtpd or with GNU mailutils?
<vivien>I get Mprog: A= argument required
<lechner>cbaines: the group exists.
<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
<cbaines>this wasn't something possible to configure on a Guix system in the past, but it might be now
<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>lechner, right
<lechner>i am reading
<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
<lechner>just for root though, right?
<lechner>cbaines jpoiret: should i try something like this?
<jpoiret>it should be a setuid-program record (setgid-program doesn't exist) but exactly yes
<lechner>yeah, thanks
<jpoiret>also, just a nitpick but (cons* el1 el2 rest) reads better than (append (list el1 el2) rest) :p
<lechner>i am on my eighth day of schmem
<the_tubular>Is someone using guix-module ?
<the_tubular>I'm not sure I understand what is it for exactly
<rekado>the_tubular: have you read ?
<the_tubular>No i was reading their gitlab page, let me take a look at this.
<the_tubular>rekado, this article refers to this : correct ?
<the_tubular>Nevermind I just read it :P
<the_tubular>Ohh, that was actually released today.
<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
<lechner>jpoiret: i don't think si
<jpoiret>maybe i'm blind and these have always happened
<jpoiret>in any case, it's normal
<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/
<ulfvonbelow>anyone familiar with perl know how it decides where to look?
<apteryx>there's an environment variable in guix for perl (search path)
<nckx>Perl uses LIBRARY_PATH?
<apteryx>PERL_MODULES or something similar
<ulfvonbelow>oh huh, guess there is PERL5LIB
<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
<nckx>Often? That's bad.
<nckx>Never happened to me.
<jpoiret>oh, right, that's my bad
*nckx relaxes.
<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
<lechner>looks okay, right?
<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.
<nckx>Which sucks.
<unmatched-paren>nckx: can't you use `command -v`? at least in bash
<unmatched-paren>it's a builtin, so surely it'd be consistent with the shell's behaviour
*vagrantc chuckles
<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).
<vagrantc>there are safeguards for that
<nckx>Buut… why is that a problem?
<lechner>wrong executable
<nckx>Something is invoking /gnu/store/…/sendmail directly?
<lechner>GNU mailutils, possibly
<nckx>Boo mailutils.
<nckx>Welp, that won't work, for sure.
<lechner>it should though.
<nckx>mailutils does not retain a reference to opensmtpd.
<nckx>lechner: Why should it?
<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
<lechner>instead of the symlink
<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
<lechner>they just don't use port 25
<nckx>vagrantc: That's really what I mean.
<nckx>It doesn't.
<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.
<lechner>it's legal to call sendmail
<nckx>Nobody's saying the contrary. :)
<nckx>And sendmail works fine.
<lechner>it does not
<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>It works.
<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