Mailing List Archive: musl install conflicts

musl install conflicts

Mar 13, 2018, 7:32 PM

Post #1 of 6 (2591 views)

I'm trying to install musl (x86) on an old laptop. I start off with
x86 minimal install to boot an old laptop. After partitioning and mkfs,
I...

mount /dev/sda1 /mnt/gentoo
cd /mnt/gentoo
wget stage3-i686-musl-vanilla-20180304.tar.bz2
tar xpf stage3-*.tar.{bz2,xz} --xattrs-include='*.*' --numeric-owner

The first problem is...
=======================================================
tar: Pattern matching characters used in file names
tar: Use --wildcards to enable pattern matching, or --no-wildcards to suppress this warning
tar: stage3-*.tar.xz: Not found in archive
tar: Exiting with failure status due to previous errors
=======================================================

OK, change the command to...
tar xpf stage3-*.tar.bz2 --xattrs-include='*.*' --numeric-owner
...and it extracts.

I make 2 changes to make.conf...
1) add GENTOO_MIRRORS
2) add MAKEOPTS="-j2" (Laptop is a Core2 Duo with 2 cores)

Then I chroot and
emerge --sync
echo "dev-vcs/git -gpg" >> /etc/portage/package.use
emerge -q layman dev-vcs/git

Now the "fun" begins...

=======================================================
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-libs/openssl:0

(dev-libs/openssl-1.0.2n:0/0::gentoo, installed) pulled in by
>=dev-libs/openssl-1.0.1:0/0=[bindist] required by (net-misc/openssh-7.5_p1-r4:0/0::musl, installed)
^^^^^^^

(dev-libs/openssl-1.0.2n:0/0::gentoo, ebuild scheduled for merge) pulled in by
>=dev-libs/openssl-1.0.2:0=[-bindist(-)] required by (dev-python/cryptography-2.0.2-r1:0/0::gentoo, ebuild scheduled for merge)

The following USE changes are necessary to proceed:
(see "package.use" in the portage(5) man page for more details)
# required by dev-python/cryptography-2.0.2-r1::gentoo[-libressl]
# required by dev-python/pyopenssl-17.2.0::gentoo
# required by dev-python/urllib3-1.22::gentoo
# required by dev-python/requests-2.18.2-r1::gentoo
# required by dev-python/ssl-fetch-0.4::gentoo
# required by app-portage/layman-2.4.2::gentoo
# required by layman (argument)
>=dev-libs/openssl-1.0.2n -bindist
=======================================================

So I add the line...
>=dev-libs/openssl-1.0.2n -bindist
...to /etc/portage/package.use and run "emerge -q layman dev-vcs/git"
and get the following. How can I resolve this?

=======================================================
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-libs/openssl:0

(dev-libs/openssl-1.0.2n:0/0::gentoo, installed) pulled in by
>=dev-libs/openssl-1.0.1:0/0=[bindist] required by (net-misc/openssh-7.5_p1-r4:0/0::musl, installed)
^^^^^
(and 4 more with the same problem)

(dev-libs/openssl-1.1.0g-r2:0/1.1::gentoo, ebuild scheduled for merge) pulled in by
>=dev-libs/openssl-1.0.2:0=[-bindist(-)] required by (dev-python/cryptography-2.0.2-r1:0/0::gentoo, ebuild scheduled for merge)

NOTE: Use the '--verbose-conflicts' option to display parents omitted above

The following keyword changes are necessary to proceed:
(see "package.accept_keywords" in the portage(5) man page for more details)
# required by dev-python/cryptography-2.0.2-r1::gentoo[-libressl]
# required by dev-python/requests-2.18.2-r1::gentoo[ssl]
# required by dev-python/ssl-fetch-0.4::gentoo
# required by app-portage/layman-2.4.2::gentoo
# required by layman (argument)
=dev-libs/openssl-1.1.0g-r2 ~x86

The following mask changes are necessary to proceed:
(see "package.unmask" in the portage(5) man page for more details)
# required by dev-python/cryptography-2.0.2-r1::gentoo[-libressl]
# required by dev-python/requests-2.18.2-r1::gentoo[ssl]
# required by dev-python/ssl-fetch-0.4::gentoo
# required by app-portage/layman-2.4.2::gentoo
# required by layman (argument)
# /usr/portage/profiles/package.mask:
# Lars Wendler <polynomial-c@gentoo.org> (26 Aug 2016)
# Masked while being tested and reverse deps aren't fully compatible
=dev-libs/openssl-1.1.0g-r2
=======================================================

If I understand properly, it wants...
echo "=dev-libs/openssl-1.1.0g-r2 ~x86" > /etc/portage/package.accept_keywords
echo "=dev-libs/openssl-1.1.0g-r2" > /etc/portage/package.unmask

But doing that, plus "emerge -q layman dev-vcs/git" gives me...
=======================================================
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-libs/openssl:0

(dev-libs/openssl-1.0.2n:0/0::gentoo, installed) pulled in by
dev-libs/openssl:0/0= required by (net-misc/openssh-7.5_p1-r4:0/0::musl, installed)
^^^^^
(and 4 more with the same problem)

(dev-libs/openssl-1.1.0g-r2:0/1.1::gentoo, ebuild scheduled for merge) pulled in by
>=dev-libs/openssl-1.0.2:0=[-bindist(-)] required by (dev-python/cryptography-2.0.2-r1:0/0::gentoo, ebuild scheduled for merge)

NOTE: Use the '--verbose-conflicts' option to display parents omitted above
=======================================================

Now what???

--
Walter Dnes <waltdnes@waltdnes.org>

Re: musl install conflicts [ In reply to ]

stuartl at longlandclan

Mar 13, 2018, 8:54 PM

Post #2 of 6 (2591 views)

Permalink

On 14/03/18 12:32, Walter Dnes wrote:
> =======================================================
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
>
> dev-libs/openssl:0
>
> (dev-libs/openssl-1.0.2n:0/0::gentoo, installed) pulled in by
> >=dev-libs/openssl-1.0.1:0/0=[bindist] required by (net-misc/openssh-7.5_p1-r4:0/0::musl, installed)
> ^^^^^^^
>
> (dev-libs/openssl-1.0.2n:0/0::gentoo, ebuild scheduled for merge) pulled in by
> >=dev-libs/openssl-1.0.2:0=[-bindist(-)] required by (dev-python/cryptography-2.0.2-r1:0/0::gentoo, ebuild scheduled for merge)
>
>
> The following USE changes are necessary to proceed:
> (see "package.use" in the portage(5) man page for more details)
> # required by dev-python/cryptography-2.0.2-r1::gentoo[-libressl]
> # required by dev-python/pyopenssl-17.2.0::gentoo
> # required by dev-python/urllib3-1.22::gentoo
> # required by dev-python/requests-2.18.2-r1::gentoo
> # required by dev-python/ssl-fetch-0.4::gentoo
> # required by app-portage/layman-2.4.2::gentoo
> # required by layman (argument)
>> =dev-libs/openssl-1.0.2n -bindist
> =======================================================
>
> So I add the line...
>> =dev-libs/openssl-1.0.2n -bindist
…
> ...to /etc/portage/package.use and run "emerge -q layman dev-vcs/git"
> and get the following. How can I resolve this?
>
> =======================================================
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
>
> dev-libs/openssl:0
>
> (dev-libs/openssl-1.0.2n:0/0::gentoo, installed) pulled in by
> >=dev-libs/openssl-1.0.1:0/0=[bindist] required by (net-misc/openssh-7.5_p1-r4:0/0::musl, installed)
> ^^^^^
> (and 4 more with the same problem)
>
> (dev-libs/openssl-1.1.0g-r2:0/1.1::gentoo, ebuild scheduled for merge) pulled in by
> >=dev-libs/openssl-1.0.2:0=[-bindist(-)] required by (dev-python/cryptography-2.0.2-r1:0/0::gentoo, ebuild scheduled for merge)
>
>
> NOTE: Use the '--verbose-conflicts' option to display parents omitted above

By default, stages are built with USE=bindist; and this should be the
default in make.conf.

OpenSSH requires that it is built with a version of OpenSSL that's built
with the bindist flag in the same state. So if you enable it on one,
you need it enabled on the other. Here, you're turning off bindist; so
you need to turn it off for OpenSSH too.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

Re: musl install conflicts [ In reply to ]

waltdnes at waltdnes

Mar 14, 2018, 5:59 PM

Post #3 of 6 (2589 views)

Permalink

On Wed, Mar 14, 2018 at 01:54:54PM +1000, Stuart Longland wrote
>
> By default, stages are built with USE=bindist; and this should be the
> default in make.conf.
>
> OpenSSH requires that it is built with a version of OpenSSL that's built
> with the bindist flag in the same state. So if you enable it on one,
> you need it enabled on the other. Here, you're turning off bindist; so
> you need to turn it off for OpenSSH too.

I unmasked 1 package and keyworded another as per my first message.

USE="bindist" emerge -q layman dev-vcs/git

...still has a ton of conflicts and refuses to do anything.

USE="-bindist" emerge -q layman dev-vcs/git

...wants to emerge 60 packages!!!
Total: 60 packages (1 upgrade, 55 new, 4 reinstalls),

I tried it, and resumed after build failures, but eventually ran into
unresolvable conflicts again. I'm in a chicken-and-egg problem. I
can't reliably run "emerge" without "layman" being present. But I can't
get "layman" without running "emerge". HELP! Maybe it used to be
possible, at one point, to emerge layman against the standard portage
tree under libmusl. But the tree changes over time.

Given how crucial "layman" is to the libmusl distro, why isn't the
libmusl stage 3 tarball shipped with a working "layman"? And while we're
at it, I'd like to see app-portage/cpuid2cpuflags as part of every stage
3. There are often situations where at some point in the early install,
you have to "emerge -e". It may as well be done with the right flags.

--
Walter Dnes <waltdnes@waltdnes.org>

Re: musl install conflicts [ In reply to ]

waltdnes at waltdnes

Mar 17, 2018, 6:07 PM

Post #4 of 6 (2588 views)

Permalink

On Tue, Mar 13, 2018 at 10:32:31PM -0400, Walter Dnes wrote
> I'm trying to install musl (x86) on an old laptop.

...and getting nowhere. Can I have some guidance on filing a bug report
on bugzilla? Is the 32-bit libmusl distro a "hosted project"? Using...

http://distfiles.gentoo.org/experimental/x86/musl/stage3-i686-musl-vanilla-20180304.tar.bz2

...I run into a "chicken-and-egg-problem". According to the HOWTO
http://distfiles.gentoo.org/experimental/x86/musl/HOWTO step 5...

5) Okay now we can update. ***IF WE TRY TO UPDATE WITHOUT THE OVERLAY,
WE GET A BUNCH OF DOWNGRADES TO EBUILDS THAT ARE SLIGHTLY BROKEN ON MUSL
AND WILL NOT BUILD.***

But to get the overlay we first have to do step 3...

3) We need to get git in order to add the overlay. Unfortunately, right
now we can't build git with gnupg support so do the following:

echo "dev-vcs/git -gpg" >> /etc/portage/package.use
emerge -q layman dev-vcs/git

So I can't do an "emerge" without first setting up the overlay, but I
can't set up the overlay without first running "emerge" to build layman
and git. Do you see the problem? As per the comment on step 5 I get
several "ebuilds that are slightly broken on musl and will not build".
The main symptom is that some ebuilds have a dependancy that requires
"bindist" USE flag and some ebuilds require USE="-bindist" for the same
dependancy. See this thread, which is archived at...
https://archives.gentoo.org/gentoo-embedded/message/38e4498aedc2817e96c57b13bc584030

Attempting to build with either all "bindist" or all "-bindist"
results in breakages.

Proposed "Patch"
================

Please ship the stage-3 tarball complete with functional "layman" and
"git" pre-built. It may have been possible to emerge layman and git
against the standard portage tree in the past, but the portage tree is
dynamic, and that does not seem to work for me now. Given how crucial
"layman" and "git" are to the musl distro, they should be shipped with
the stage-3 tarball.

--
Walter Dnes <waltdnes@waltdnes.org>

Re: musl install conflicts [ In reply to ]

m.j.everitt at iee

Mar 17, 2018, 6:24 PM

Post #5 of 6 (2588 views)

Permalink

On 18/03/18 01:07, Walter Dnes wrote:
> On Tue, Mar 13, 2018 at 10:32:31PM -0400, Walter Dnes wrote
>> I'm trying to install musl (x86) on an old laptop.
> ...and getting nowhere. Can I have some guidance on filing a bug report
> on bugzilla? Is the 32-bit libmusl distro a "hosted project"? Using...
>
> http://distfiles.gentoo.org/experimental/x86/musl/stage3-i686-musl-vanilla-20180304.tar.bz2
>
> ...I run into a "chicken-and-egg-problem". According to the HOWTO
> http://distfiles.gentoo.org/experimental/x86/musl/HOWTO step 5...
>
> 5) Okay now we can update. ***IF WE TRY TO UPDATE WITHOUT THE OVERLAY,
> WE GET A BUNCH OF DOWNGRADES TO EBUILDS THAT ARE SLIGHTLY BROKEN ON MUSL
> AND WILL NOT BUILD.***
>
> But to get the overlay we first have to do step 3...
>
> 3) We need to get git in order to add the overlay. Unfortunately, right
> now we can't build git with gnupg support so do the following:
>
> echo "dev-vcs/git -gpg" >> /etc/portage/package.use
> emerge -q layman dev-vcs/git
>
> So I can't do an "emerge" without first setting up the overlay, but I
> can't set up the overlay without first running "emerge" to build layman
> and git. Do you see the problem? As per the comment on step 5 I get
> several "ebuilds that are slightly broken on musl and will not build".
> The main symptom is that some ebuilds have a dependancy that requires
> "bindist" USE flag and some ebuilds require USE="-bindist" for the same
> dependancy. See this thread, which is archived at...
> https://archives.gentoo.org/gentoo-embedded/message/38e4498aedc2817e96c57b13bc584030
>
> Attempting to build with either all "bindist" or all "-bindist"
> results in breakages.
>
> Proposed "Patch"
> ================
>
> Please ship the stage-3 tarball complete with functional "layman" and
> "git" pre-built. It may have been possible to emerge layman and git
> against the standard portage tree in the past, but the portage tree is
> dynamic, and that does not seem to work for me now. Given how crucial
> "layman" and "git" are to the musl distro, they should be shipped with
> the stage-3 tarball.
>
May I ask whether you've posted to the -musl ML about this, at all? In
my limited experience of amd64 musl, you first install git without gpg,
and layman from the regular portage tree ONLY, per Step3 and THEN run
step 5 later on .. hence why 5 > 3. After that you can remove the
package.use entry, sync up, and reinstall git from the musl overlay ..
iirc.. So I'm not sure where I see your "circular dependency" issue?

It is conceivable that the relevant stage3 for *musl could have git and
layman pre-installed by tweaking their profile to add these packages if
it's felt necessary & appropriate. It would certainly make the install
process a lot simpler & smoother ...
Regards,

veremitz/Michael.

Re: musl install conflicts [ In reply to ]

waltdnes at waltdnes

Mar 18, 2018, 10:42 PM

Post #6 of 6 (2588 views)

Permalink

On Sun, Mar 18, 2018 at 01:24:59AM +0000, M. J. Everitt wrote

> May I ask whether you've posted to the -musl ML about this, at all?

I wasn't aware of it. I'll check it out.

> In my limited experience of amd64 musl, you first install git without
> gpg, and layman from the regular portage tree ONLY, per Step3

That's *EXACTLY* what I was trying to do (32-bit install). Let's just
say that I ran into various breakages. It refuses to build with the
default make.conf.

It wants me to change USE flags, keyword and unmask some packages,
etc. The net result is that it ends up trying to build almost 60
packages... and dying in the process, as mentioned in the comments of
step 5.

> and THEN run step 5 later on .. hence why 5 > 3. After that you can
> remove the package.use entry, sync up, and reinstall git from the
> musl overlay .. iirc.. So I'm not sure where I see your "circular
> dependency" issue?

I can't get past the emerge in step 3.

> It is conceivable that the relevant stage3 for *musl could have git and
> layman pre-installed by tweaking their profile to add these packages if
> it's felt necessary & appropriate. It would certainly make the install
> process a lot simpler & smoother ...

+1000

--
Walter Dnes <waltdnes@waltdnes.org>

Mailing List Archive

Attached Files:

Attached Files: