sbcl-cl-webkit doesn't protect webkitgtk from garbage collection

  • Open
  • quality assurance status badge
Details
3 participants
  • Guillaume Le Vaillant
  • Leo Famulari
  • pkill9
Owner
unassigned
Submitted by
pkill9
Severity
normal
P
P
pkill9 wrote on 17 Mar 2021 00:40
(address . bug-guix@gnu.org)
20210316234005.64e633b7@runbox.com
I have nyxt installed, which has sbcl-cl-webkit as an input, which has
webkitgtk as an input, and recently it produced an error which was
fixed by building webkitgtk, so it wasn't in the store.

sbcl-cl-webkit won't be deleted by `guix gc`, however webkitgtk will
be, so it seems it's not protected from garbage collection by
sbcl-cl-webkit. Am I wrong in this?
L
L
Leo Famulari wrote on 17 Mar 2021 00:54
(name . pkill9)(address . pkill9@runbox.com)(address . 47201@debbugs.gnu.org)
YFFFGqkT7XHHOGyo@jasmine.lan
On Tue, Mar 16, 2021 at 11:40:05PM +0000, pkill9 wrote:
Toggle quote (8 lines)
> I have nyxt installed, which has sbcl-cl-webkit as an input, which has
> webkitgtk as an input, and recently it produced an error which was
> fixed by building webkitgtk, so it wasn't in the store.
>
> sbcl-cl-webkit won't be deleted by `guix gc`, however webkitgtk will
> be, so it seems it's not protected from garbage collection by
> sbcl-cl-webkit. Am I wrong in this?

You can check on this with the `guix gc` tool.

Specifically, like this:

$ guix gc --references $(guix build sbcl-cl-webkit)

That will show you the "store references" of the built sbcl-cl-webkit
package. These store references are strings that refer to files in
/gnu/store, found by scanning the result of building sbcl-cl-webkit.

These references are recorded in the Guix database at
'/var/guix/db/db.sqlite'.

The built package must keep references to its runtime dependencies, or
they will be subject to garbage collection, and that would represent a
bug in the package definition.

Does that make sense?
G
G
Guillaume Le Vaillant wrote on 17 Mar 2021 09:49
(name . Leo Famulari)(address . leo@famulari.name)
87a6r2w4en.fsf@yamatai
Leo Famulari <leo@famulari.name> skribis:

Toggle quote (28 lines)
> On Tue, Mar 16, 2021 at 11:40:05PM +0000, pkill9 wrote:
>> I have nyxt installed, which has sbcl-cl-webkit as an input, which has
>> webkitgtk as an input, and recently it produced an error which was
>> fixed by building webkitgtk, so it wasn't in the store.
>>
>> sbcl-cl-webkit won't be deleted by `guix gc`, however webkitgtk will
>> be, so it seems it's not protected from garbage collection by
>> sbcl-cl-webkit. Am I wrong in this?
>
> You can check on this with the `guix gc` tool.
>
> Specifically, like this:
>
> $ guix gc --references $(guix build sbcl-cl-webkit)
>
> That will show you the "store references" of the built sbcl-cl-webkit
> package. These store references are strings that refer to files in
> /gnu/store, found by scanning the result of building sbcl-cl-webkit.
>
> These references are recorded in the Guix database at
> '/var/guix/db/db.sqlite'.
>
> The built package must keep references to its runtime dependencies, or
> they will be subject to garbage collection, and that would represent a
> bug in the package definition.
>
> Does that make sense?

I think this issue is identical to what has been reported a few years
ago in bug#33848 (https://issues.guix.gnu.org/33848)which is still
open.
The binaries created by SBCL store some pathnames as UTF-32 strings, and
the reference scanner of Guix doesn't support that, so it misses some
references.
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCYFHCsA8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j8LBwEApGHktB+uuXrt0sOZvz9Oh0pSw6knia/hOL2F
K7QpKmUA/RkiF/X58HrKl9Y+8iDjwPcEIToJl4BWzuIX0T7RJvD0
=FVhV
-----END PGP SIGNATURE-----

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 47201@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 47201
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch