Hello *,

The sbcl upstream only supports glibc Linux systems. Building sbcl uses
sbcl binary (which fails to run on musl) to compile sbcl sources.

In principle, one can try a workaround: use some other lisp (say, clisp or
ecl) as the bootstrap lisp. This way is at best brittle: there is no
guarantee that these external lisps will compile the sbcl sources
successfully. People say that sometimes this works.

No user of musl profiles could successfully emerge sbcl from time
-infinity to the present moment. The natural solution is to pmask sbcl in
musl profiles.

So I've done. But this leads to unexpected consequences. dev-ros/roslisp
hard depends on sbcl. ros-meta/ros_core hard depends on roslisp. ros-meta/ros_base hard depends on ros_core.
ros-meta/{perception,robot,viz} hard depend on ros_core. Maybe, more
packages depend on {perception,robot,viz}, I haven't checked.

This means that no user of the musl profiles has ever been able to emerge
all these packages (because they did not have sbcl). And all these
packages should be pmasked in the musl profiles.

Before doing this drastic change I decided to ask for your advice. Should
I go forward and pmask them now? Or maybe for some of them the dependence
on sbcl can be made optional, and it would be sufficient to use.mask such
an option name? Or maybe roslisp can use some other lisp instead of sbcl?

Andrey

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2 Dec 2022, at 05:11, Andrey Grozin <grozin@woodpecker.gentoo.org> wrote:

Hello *,

The sbcl upstream only supports glibc Linux systems. Building sbcl uses sbcl binary (which fails to run on musl) to compile sbcl sources.

In principle, one can try a workaround: use some other lisp (say, clisp or ecl) as the bootstrap lisp. This way is at best brittle: there is no guarantee that these external lisps will compile the sbcl sources successfully. People say that sometimes

this works.

No user of musl profiles could successfully emerge sbcl from time -infinity to the present moment. The natural solution is to pmask sbcl in musl profiles.

So I've done. But this leads to unexpected consequences. dev-ros/roslisp hard depends on sbcl. ros-meta/ros_core hard depends on roslisp. ros-meta/ros_base hard depends on ros_core. ros-meta/{perception,robot,viz} hard depend on ros_core. Maybe, more

packages depend on {perception,robot,viz}, I haven't checked.

This means that no user of the musl profiles has ever been able to emerge all these packages (because they did not have sbcl). And all these packages should be pmasked in the musl profiles.

Before doing this drastic change I decided to ask for your advice. Should I go forward and pmask them now? Or maybe for some of them the dependence on sbcl can be made optional, and it would be sufficient to use.mask such an option name? Or maybe

roslisp can use some other lisp instead of sbcl?


Thanks for asking and for looking to sort it out for musl.

If the dependencies are optional (at least for some), we should indeed (package.)use.mask sbcl on musl to reduce the damage,
then package.mask the remaining unconditional reverse dependencies.

For things like this, I tend to use GitHub pull requests because you get CI for free to see if the masks
are sufficient, and if not, what the problems are. But you can emulate that using pkgcheck scan on the whole
tree locally.

Best,
sam

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCY4mVil8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kL5cAP9im/VmRmattWaSTS8HM5O5j8QbrlveBGzGrBr7bJaMRgEApkA5TKs+kbYZ 6pKVtv1hFK5k9ujGkqN8ZhYEqdfcGQY=
=gRn7
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2 Dec 2022, Sam James wrote:

If the dependencies are optional (at least for some), we should indeed (package.)use.mask sbcl on musl to reduce the damage,
then package.mask the remaining unconditional reverse dependencies.

But I cannot do these this myself. I use neither musl nor ros. I suppose
ros developers should update their ebuilds to conditionalize as many uses
of sbcl as possible. It would be good to call this USE flag "sbcl". 2
packages (sci-mathematics/maxima and sci-mathematics/fricas) already use
this name, and I have included it in profiles/features/musl/use.mask.

Thanks,
Andrey

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The sbcl ebuild from the Gentoo tree is useless on musl. And hence it

should be masked. Otherwise somebody would think that [s]he can simply
emerge sbcl on a musl profile, and will be disappointed.

Ah, I see. That makes sense, and I think I can just unmask it in my
custom musl profile.

Thanks!
Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For the record I've had sbcl building and running on musl for months
without issue (at one point I even had static linking working). You
have to cross compile a musl version and then side load the binary
instead of using one of the distributed binaries. See https://github.com/tgbugs/dockerfiles/blob/master/source.org#sbcl-bootstrap
for reference. See also https://hub.docker.com/r/tgbugs/musl/tags?page=1&name=sbcl. Thus I'd
very much appreciate if it sbcl were not masked on those profiles.
Best,
Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2 Dec 2022, Tom Gillespie wrote:

For the record I've had sbcl building and running on musl for months
without issue (at one point I even had static linking working). You
have to cross compile a musl version and then side load the binary
instead of using one of the distributed binaries. See https://github.com/tgbugs/dockerfiles/blob/master/source.org#sbcl-bootstrap for reference. See also https://hub.docker.com/r/tgbugs/musl/tags?page=1&name=sbcl.

Yes. Either cross-compiling, or (with some luck) using some other lisp for bootstrap.

Thus I'd very much appreciate if it sbcl were not masked on those profiles.

The sbcl ebuild from the Gentoo tree is useless on musl. And hence it
should be masked. Otherwise somebody would think that [s]he can simply
emerge sbcl on a musl profile, and will be disappointed.

Andrey

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andrey Grozin wrote:

This means that no user of the musl profiles has ever been able to emerge
all these packages (because they did not have sbcl). And all these
packages should be pmasked in the musl profiles.

Is the last sentence actually true?

Shouldn't only ebuilds with actual problems be masked?

Even if there's currently no possibility to emerge other packages
which depend on that it seems incorrect to mask those other packages
only because a dependency can't be emerged?

I don't think portage cares; it will show sbcl masked if it is a
dependency, right?


Thanks

//Peter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2 Dec 2022, at 19:28, Peter Stuge <peter@stuge.se> wrote:

Andrey Grozin wrote:

This means that no user of the musl profiles has ever been able to emerge
all these packages (because they did not have sbcl). And all these
packages should be pmasked in the musl profiles.

Is the last sentence actually true?

Shouldn't only ebuilds with actual problems be masked?

Even if there's currently no possibility to emerge other packages
which depend on that it seems incorrect to mask those other packages
only because a dependency can't be emerged?

No, that's not how it works, because right now, you can end up
with something that depends on sbcl on a musl system where
you can't actually install it.

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCY4poJF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kJXvAQCu9XArIcr6aU3rEssAtjhR39/sCHDakdirLReqrrfQhgEAqUI2UQgcr9VZ 1egv29yuUAO2OSMJU1KX2yGHSYFsAw0=
=FGlS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Dec 2, 2022 at 11:28 AM Peter Stuge <peter@stuge.se> wrote:

Andrey Grozin wrote:

This means that no user of the musl profiles has ever been able to emerge all these packages (because they did not have sbcl). And all these
packages should be pmasked in the musl profiles.

Is the last sentence actually true?

Shouldn't only ebuilds with actual problems be masked?

Even if there's currently no possibility to emerge other packages
which depend on that it seems incorrect to mask those other packages
only because a dependency can't be emerged?

I don't think portage cares; it will show sbcl masked if it is a
dependency, right?

The project has a (somewhat implicit) goal to prefer installable
depgraphs. We use software like pkgcheck to verify these (and there
are CI failures if the depgraph is broken, and we make developers fix
such things.)

So if we had like, A -> B -> C, and C is profile-masked on some
profile, we should be masking A and B (so we avoid users seeing a
broken depgraph.)
You might think "well I see A -> B[foo] all the time, and portage will
make me set USE=foo on B." This is generally true except:
- Oftentimes if this is a sane default, B will have USE="+foo" (e.g.
foo will be on by default) and this requirement will not be visible to
users.
- USE flags are intended to be toggled and most USE flag values are
supported by Gentoo (except for REQUIRED_USE restrictions.)
- Portage has an autounmask flag that will configure things so B is installable (by flipping foo on for you); but this function does not
exist for profile-masks.

We do not expect users to "undo" profile-masks, so when things are profile-masked we value the user experience (if X is visible, X should
be installable) rather than minimal masking.

-A

Thanks

//Peter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[2022-12-02 05:11:15+0000] Andrey Grozin:

In principle, one can try a workaround: use some other lisp (say, clisp or >ecl) as the bootstrap lisp. This way is at best brittle: there is no >guarantee that these external lisps will compile the sbcl sources >successfully. People say that sometimes this works.

Well Alpine is using the ecl route: https://git.alpinelinux.org/aports/tree/community/sbcl/APKBUILD
And GNU GuixSD is using the clisp route but per the comments ecl would be better: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/lisp.scm#n424

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2022-12-03 at 02:59 +0100, Haelwenn (lanodan) Monnier wrote:

[2022-12-02 05:11:15+0000] Andrey Grozin:

In principle, one can try a workaround: use some other lisp (say, clisp or ecl) as the bootstrap lisp. This way is at best brittle: there is no guarantee that these external lisps will compile the sbcl sources successfully. People say that sometimes this works.

Well Alpine is using the ecl route: https://git.alpinelinux.org/aports/tree/community/sbcl/APKBUILD

ECL is a good choice. Upstream is active and friendly..... but:

The current and only version of ECL in the tree has a bug that makes it unusable for compiling SBCL:

* https://bugs.launchpad.net/sbcl/+bug/1956852
* https://gitlab.com/embeddable-common-lisp/ecl/-/issues/667

A fix was committed, but there hasn't been a new release yet.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 3 Dec 2022, Haelwenn (lanodan) Monnier wrote:

Well Alpine is using the ecl route: https://git.alpinelinux.org/aports/tree/community/sbcl/APKBUILD
And GNU GuixSD is using the clisp route but per the comments ecl would be better: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/lisp.scm#n424

In principle, we can do something similar:

1. If elibc_musl, sbcl should BDEPEND on ecls (or maybe clisp)

2. In the same case, the build system should be patched to use another bootstrap lisp

3. For elibc_glibc nothing should change

4. All this should be tested on a computer running a musl profile

Personally I can do nothing of this list. I have no computer with musl
profile. Does any developer running such a system volunteer to do this
work - to be a co-maintained of sbcl on musl?

If not, I'll go forward and pmask all packages which unconditionally
depend on sbcl (maybe via some intermediates) in profiles/features/musl/use.mask.

Andrey

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)