GNU logs - #59855, boring messages

Message sent to bug-guix@HIDDEN:

Subject: bug#59855: Guix Shell with FHS Feedback: lib/tls/x86_64/x86_64?
Resent-From: Marek =?UTF-8?Q?Pa=C5=9Bnikowski?= <marekpasnikowski@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Tue, 06 Dec 2022 09:08:01 +0000
Resent-Message-ID: <handler.59855.B.167031765018691 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 59855 <at> debbugs.gnu.org
Date: Tue, 06 Dec 2022 09:07:04 +0000
From: Marek =?UTF-8?Q?Pa=C5=9Bnikowski?= <marekpasnikowski@HIDDEN>
Message-ID: <NbJYQlVen5V-zsMls3exLJFVDRFgMTn9DIXxdzyOXnIuOvgBgM3V1v2JZ9HSV-ElZosLymL4yGXW84HAE-jHkfDvHBVqMKyQa6fYNmGOY38=@protonmail.com>
Feedback-ID: 45828316:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=185.70.43.19;
 envelope-from=marekpasnikowski@HIDDEN; helo=mail-4319.protonmail.ch
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

I recently started attempting to execute an AppImage with
guix shell --container --emulate-fhs .
I found a workflow, where I set LD_LIBRARY_PATH=3D$LIBRARY_PATH
and trace the executable with strace -ffZ ./Program.AppImage .
Its concept is that I want to turn each failing call to a successful
one, until the program runs flawlessly.
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.
Here is the head of the current trace I am stuck at:

> access("/etc/ld.so.preload", R_OK)      =3D -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) =3D=20
> -1 ENOENT (No such file or directory)

The second line is the interesting one.
According to an ancient post on the Linux Questions forum[1],
$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 .

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Marek =?UTF-8?Q?Pa=C5=9Bnikowski?= <marekpasnikowski@HIDDEN>
Subject: bug#59855: Acknowledgement (Guix Shell with FHS Feedback:
 lib/tls/x86_64/x86_64?)
Message-ID: <handler.59855.B.167031765018691.ack <at> debbugs.gnu.org>
References: <NbJYQlVen5V-zsMls3exLJFVDRFgMTn9DIXxdzyOXnIuOvgBgM3V1v2JZ9HSV-ElZosLymL4yGXW84HAE-jHkfDvHBVqMKyQa6fYNmGOY38=@protonmail.com>
X-Gnu-PR-Message: ack 59855
X-Gnu-PR-Package: guix
Reply-To: 59855 <at> debbugs.gnu.org
Date: Tue, 06 Dec 2022 09:08:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 59855 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
59855: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D59855
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guix@HIDDEN:

Subject: bug#59855: Guix Shell with FHS Feedback: lib/tls/x86_64/x86_64?
References: <NbJYQlVen5V-zsMls3exLJFVDRFgMTn9DIXxdzyOXnIuOvgBgM3V1v2JZ9HSV-ElZosLymL4yGXW84HAE-jHkfDvHBVqMKyQa6fYNmGOY38=@protonmail.com>
In-Reply-To: <NbJYQlVen5V-zsMls3exLJFVDRFgMTn9DIXxdzyOXnIuOvgBgM3V1v2JZ9HSV-ElZosLymL4yGXW84HAE-jHkfDvHBVqMKyQa6fYNmGOY38=@protonmail.com>
Resent-From: John Kehayias <john.kehayias@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 23 Dec 2022 05:41:02 +0000
Resent-Message-ID: <handler.59855.B59855.167177400610748 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Marek =?UTF-8?Q?Pa=C5=9Bnikowski?= <marekpasnikowski@HIDDEN>, 59855 <at> debbugs.gnu.org
Date: Fri, 23 Dec 2022 05:39:47 +0000
From: John Kehayias <john.kehayias@HIDDEN>
Message-ID: <87v8m2k7a8.fsf@HIDDEN>
Feedback-ID: 7805494:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On Tue, Dec 06, 2022 at 09:07 AM, Marek Pa=C5=9Bnikowski 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=3D$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)      =3D -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) =3D
>> -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

Message sent to bug-guix@HIDDEN:

Subject: bug#59855: Emacs Debbugs reply (was Re: bug#59855: Guix Shell with FHS Feedback: lib/tls/x86_64/x86_64?)
Resent-From: Simon Tournier <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 05 Jan 2023 12:24:01 +0000
Resent-Message-ID: <handler.59855.B59855.167292140811567 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: John Kehayias <john.kehayias@HIDDEN>, Marek =?UTF-8?Q?Pa=C5=9Bnikowski?= <marekpasnikowski@HIDDEN>, 59855 <at> debbugs.gnu.org
From: Simon Tournier <zimon.toutoune@HIDDEN>
In-Reply-To: <87v8m2k7a8.fsf@HIDDEN>
References: <NbJYQlVen5V-zsMls3exLJFVDRFgMTn9DIXxdzyOXnIuOvgBgM3V1v2JZ9HSV-ElZosLymL4yGXW84HAE-jHkfDvHBVqMKyQa6fYNmGOY38=@protonmail.com>
 <87v8m2k7a8.fsf@HIDDEN>
Date: Thu, 05 Jan 2023 12:31:03 +0100
Message-ID: <86a62x8bgo.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi John,

On Fri, 23 Dec 2022 at 05:39, John Kehayias via Bug reports for GNU Guix <bug-guix@HIDDEN> wrote:

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

Well, I think it is about Gnus and not Debbugs.  There is bunch of
option to reply with Gnus. :-)

    9 candidates:
        gnus-summary-reply
        gnus-summary-wide-reply
        gnus-summary-very-wide-reply
        gnus-summary-reply-with-original
        gnus-summary-reply-broken-reply-to
        gnus-summary-wide-reply-with-original
        gnus-summary-reply-to-list-with-original
        gnus-summary-very-wide-reply-with-original
        gnus-summary-reply-broken-reply-to-with-original


Personally, I have this config (the only Gnus keybinding I use ;-))

  (define-key gnus-summary-mode-map "R" 'gnus-summary-wide-reply-with-original)
  (define-key gnus-article-mode-map "R" 'gnus-summary-wide-reply-with-original)

which is consistent with Emacs Notmuch key binding.


Hope that helps,
simon

Last modified: Thu, 5 Jan 2023 12:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.