How to find binaries in libexec dir?
Diffoscope uses *lots* of optional tools for which it would be impractical to embed all the tool references in the guix packaging... instead, for the most part, diffoscope relies on PATH to find helper utilities to decode various file formats into something more human readable... But libxmlb ships the xb-tool binary in libexec, which diffoscope cannot find on guix. For Debian, diffoscope just basically adds the corresponding directory to PATH, and it's basically a single directory, but I'm not sure how I'd do that with guix ... How do I find all the potential libexec dirs that a user might have in a given environment? On Guix System, I'll likely have at least the system profile's libexec, the user's libexec, but as soon as you start using guix shell, guix shell --container, or source multiple profiles, it's hard to know where would be "reasonable" to look. A workaround would be to adjust the libxmlb package so that xb-tool is also in PATH somehow, but maybe this is bad form? live well, vagrant signature.asc Description: PGP signature
Re: go libraries do not work in a guix shell
On Sat, 16 Apr 2022 12:48:16 -0400 Pier-Hugues Pellerin wrote: > Hello, > > Is that a new behaviour? I’ve recently updated go to package to 1.17.8. Hi Pier-Hugues, Did go libraries in a `guix shell` ever work for you? all best, jgart
Re: go libraries do not work in a guix shell
Hello, Is that a new behaviour? I’ve recently updated go to package to 1.17.8. Sent from my portable monolith. Ph > On Apr 16, 2022, at 12:09 PM, jgart wrote: > > Hi Guixers, > > go libraries do not work in a guix shell. > > Some user experience reports: > > 2022-04-13 23:40:32Go works in guix shell, but you have to add > other stuff like glibc and I think binutils > > http://litterbox.whereis.みんな/scooper/events?network=Libera.Chat=%23whereiseveryone=2022-04-13T23%3A44%3A15#4030 > > This is what I tried without success: > > guix shell go go-github-com-dchest-captcha go-github-com-matryer-is > go-github-com-mattn-go-sqlite3 sqlite --pure -L ~/guixrus > > Once in the shell, the go compiler would complain of not finding the > libraries. > > How should we start investigating this? > > My ideal experience with go libraries would be the same as for python, > haskell, common lisp, guile, etc... > > all best, > > jgart > >
go libraries do not work in a guix shell
Hi Guixers, go libraries do not work in a guix shell. Some user experience reports: 2022-04-13 23:40:32Go works in guix shell, but you have to add other stuff like glibc and I think binutils http://litterbox.whereis.みんな/scooper/events?network=Libera.Chat=%23whereiseveryone=2022-04-13T23%3A44%3A15#4030 This is what I tried without success: guix shell go go-github-com-dchest-captcha go-github-com-matryer-is go-github-com-mattn-go-sqlite3 sqlite --pure -L ~/guixrus Once in the shell, the go compiler would complain of not finding the libraries. How should we start investigating this? My ideal experience with go libraries would be the same as for python, haskell, common lisp, guile, etc... all best, jgart
Re: Update to bug 54919 gone missing
Tobias Geerinckx-Rice writes: > We don't have easy access to lower-level logs. Do you? You look like you > might self-host. > > Armed with a log snippet from you with a clear 250 'accepted' I'd feel less > bothersome asking the gnu.org folks to investigate. You know, I hadn’t even thought to check my mail queue. I can’t remember the last time I had a delivery problem (or maybe I’ve been having them the whole time and just not noticed ). I have my mail server set to require TLS, but it looks as though debbugs.gnu.org doesn’t support it: ---[snip]--- Apr 16 08:26:10 mx0 postfix/smtp[68543]: 347053CCD: to=<54...@debbugs.gnu.org>, relay=debbugs.gnu.org[209.51.188.43]:25, delay=78497, delays=78497/0.06/0.27/0, dsn=4.7.4, status=deferred (TLS is required, but was not offered by host debbugs.gnu.org[209.51.188.43]) ---[snip]--- This wasn’t an issue for other reports, as I used the bug-g...@gnu.org address, and eggs.gnu.org offers STARTTLS after the EHLO. I’m not sure what to do here. I’m kind of loathe to remove the TLS mandate on my server, and it seems to me like the debbugs MX should offer it for all the standard reasons. > Thanks for reporting both! Thanks for prodding me to dig further on my end. I honestly thought the mail just disappeared. -bjc
Re: Update to bug 54919 gone missing
Hi Brian, On 16 April 2022 11:36:52 UTC, Brian Cully wrote: > > I sent an email to 54...@debbugs.gnu.org to update it with more >specific information almost two days ago and I haven’t seen any changes >in https://issues.guix.gnu.org/54919 . I also never got a bounce or >other return communication saying what has happened; it’s as if my email >were silently sent to the bit bucket. I can't say what happened here: it's not in the moderation queue (5 unfortunates who were have been freed) and even if it had been that shouldn't have resulted in what you report. We don't have easy access to lower-level logs. Do you? You look like you might self-host. Armed with a log snippet from you with a clear 250 'accepted' I'd feel less bothersome asking the gnu.org folks to investigate. > There were more details in the lost bug report, but the above is >the gist of it. Thanks for reporting both! Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
Update to bug 54919 gone missing
I sent an email to 54...@debbugs.gnu.org to update it with more specific information almost two days ago and I haven’t seen any changes in https://issues.guix.gnu.org/54919 . I also never got a bounce or other return communication saying what has happened; it’s as if my email were silently sent to the bit bucket. Is there more to the procedure than sending an email to the address at the bottom of the ticket? For the record, since it’s apparently lost: I tracked the issue down to this line in my home.scm: ---[snip]--- (service home-shepherd-service-type (home-shepherd-configuration)) ---[snip]--- When I comment that out, everything runs correctly. It seems as though the addition of this empty configuration caused the ’herd’ process to try to communicate with the shepherd process, and even though it was able to connect, it never got a response to the version query. There were more details in the lost bug report, but the above is the gist of it. -bjc
