bug#60106: [Shepherd 0.9.3] ‘system*’ replacement cannot be passed environment variables

[Ludovic Courtès]

Adam Faiz  skribis:

>> I think we’ll have to add a parameter to ‘spawn-command’ to specify
>> environment variables.
>> Ludo’.
> If you do this, can you add an #:append? flag which adds environment
> variables to the inherited environment instead of specifying the
> variables declaratively? It can be #f by default.
>
> It would be very useful for me using the shepherd as init on a foreign
> distro, so I don't have to use the `env` command.

You could always write something like:

  #:environment-variables `("EXTRA_VARIABLE=something" ,@(environ))

to append ‘EXTRA_VARIABLE’ to those of the environment.

So I don’t think we need #:append.

Thanks for your feedback,
Ludo’.

bug#60106: [Shepherd 0.9.3] ‘system*’ replacement cannot be passed environment variables

[Adam Faiz via Bug reports for GNU Guix]

I think we’ll have to add a parameter to ‘spawn-command’ to specify
environment variables.

Ludo’.
If you do this, can you add an #:append? flag which adds environment 
variables to the inherited environment instead of specifying the 
variables declaratively? It can be #f by default.


It would be very useful for me using the shepherd as init on a foreign 
distro, so I don't have to use the `env` command.

bug#37513: Subject: Installer finish backtrace, umount dispatch exception /mnt device busy

[free bird]

On 2022-11-12 16:40, Mathieu Othacehe wrote:
> Hello,
> 
> Sorry for the very late reply. We recently added a bunch of error
> reporting features to the installer. Any chance you still have the
> hardware around and would be able to test again using the latest
> installation image available here:
> https://guix.gnu.org/en/download/latest/?
> 
> That would be super useful for us :)
> 
> Thanks,
> 
> Mathieu


Hi Mathieu,

> very late

25 Sep 2019 to 12 Nov 2022 is over three years! :D

> Any chance you still have the
> hardware around and would be able to test again...

> That would be super useful for us :)

I do still have the hardware. Unfortunately, it is 
in the spare parts pile, because it does not power on now.

Sorry

bug#56709: (No Subject)

[Attila Lendvai]

> i'm also seeing this, and the solution was to comment
> out the (identity ...) field of my machine-ssh-configuration.

i spoke too soon. today it's again broken for me the same way, even though 
identity is commented out. lechner on IRC also reported that it's broken for 
him.

random hint, maybe not relevant: i may have pulled in the short time since i 
wrote my previous mail, and there may have been a guile-ssh update in that pull.

- attila

bug#59855: Guix Shell with FHS Feedback: lib/tls/x86_64/x86_64?

[John Kehayias via Bug reports for GNU Guix]

On Tue, Dec 06, 2022 at 09:07 AM, Marek Paśnikowski wrote:

Hello!

(resending as it seems debbugs in Emacs doesn't automatically add the
bug number email in the To/CC list.)

> I recently started attempting to execute an AppImage with
> guix shell --container --emulate-fhs .

Great! You may want to see this recent mailing list thread and draft
blog post which also covers exactly this in an example:

specifically: https://lists.gnu.org/r/guix-devel/2022-12/msg00156.html

and: https://issues.guix.gnu.org/60112

> I found a workflow, where I set LD_LIBRARY_PATH=$LIBRARY_PATH
> and trace the executable with strace -ffZ ./Program.AppImage .

In the FHS container you shouldn't need to set LD_LIBRARY_PATH. There
was a bug in the first weeks after it was merged (where this would work
around it), but assuming you have updated somewhat recently this
shouldn't be needed in genera.

> Its concept is that I want to turn each failing call to a successful
> one, until the program runs flawlessly.

I think this way lies madness. There will always be a ton of failing
calls, by nature of how things work. In particular, if you haven't see
this blog post, which covers exactly this (library loading), it was
enlightening for me at least:

https://guix.gnu.org/blog/2021/taming-the-stat-storm-with-a-loader-cache/

> I program as a hobby, and have no way of knowing if any of the
> trace calls can be safely ignored.
>
> I would like to encourage development of such an implementation,
> where strace -ffZ output is reduced as much as possible by default.

But in general I agree, I also use strace to find out what is breaking.
Often you want to see the last set of calls, but not always.

> Here is the head of the current trace I am stuck at:
>
>> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file
>> or directory)
>>
>> openat(AT_FDCWD, "/gnu/store/c8ndz685xbqm29r9zwlwsbjqj4ylh4m4-
>> profile/lib/tls/x86_64/x86_64/libdl.so.2", O_RDONLY|O_CLOEXEC) =
>> -1 ENOENT (No such file or directory)
>
> The second line is the interesting one.

Yes, the first one should be ignored as far as I know and is not
important.

The second one could be a failure, if that is where it stops looking for
libdl and errors out. So a more complete log, or at least the end where
an actual failure happens, would be helpful. As well as the exact
command you are running and the AppImage (if it is free software, of
course) would be good. Usually you'll see lots of these ENOENT errors
until it finds it in one of the search paths, or else an actual error
that the library could not be found and loaded.

> According to an ancient post on the Linux Questions forum[1],

This link didn't show for me.

> $PATH/lib/tls is the directory for glibc with thread support (NPTL).
> I do not know if the glibc in Guix has the thread support or not.
> However, it is the next two subdirectories that baffle me.
> x86_64/x86_64?  I have never seen anything like this.
> I thought, that maybe having a tls->. link in the lib directory
> would suppress the failure, but lib also does not have
> an x86_64 directory.
>
> I have spent a couple of hours chasing the libdl libry,
> only to realise that it is supplied by glibc, and it is
> the AppImage program trying to reach it in a different place.
> I strongly believe that solving this mode of failure will save
> countless hours of futile struggle for future users of Guix Shell.
> For the same purpose, the first error can be permanently silenced
> by creating an empty file at /etc/ld.so.preload .

I'm not certain you are actually failing at libdl. The FHS container
will show this library in /lib and in the ld cache, which should cover
just about everything trying to find it. More details would be helpful.

Hope this helps in the meantime!
John

bug#59971: iwd is packaged but there is no iwd shepherd service

[Hilton Chain via Bug reports for GNU Guix]

Hi Jeremiah,

> without a proper shepherd service, users are forced to manually start
> the iwd service as root and background the process.
>
> Nor is there any documentation provided to work around this defect.

AFAIK, Nikita Domnitskii has defined an iwd-service-type in their dotfiles: