[gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[Pacho Ramos]

Hello

As discussed at:
https://bugs.gentoo.org/show_bug.cgi?id=478476

Upstream is dropping static libs from udev and, then, sys-apps/udev is
currently reverting that commit downstream (even if upstream says some
problems could appear in the future as nobody is taking care of static
stuff there).

Grepping in the tree, looks like only some old genkernel versions are
depending on it. Apart of that, what is requiring static libs in
cryptsetup and lvm2?

Thanks a lot

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[Rich Freeman]

On Mon, Jul 29, 2013 at 4:57 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> Grepping in the tree, looks like only some old genkernel versions are
> depending on it. Apart of that, what is requiring static libs in
> cryptsetup and lvm2?

This isn't the specific answer you're likely looking for, but the
obvious answers would be:
1.  Booting without /usr mounted if any of cryptsetup/lvm2's libs are
located in /usr (not the case for lvm2 on my system at least).
2.  Any initramfs creation tool that isn't smart enough to realize
what cryptsetup/lvm2 are linked to and copy those into the initramfs
(shouldn't be an issue in anything modern).

Rich

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[Francesco Riosa]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

2. should be nuked from orbit anyway, just curious do someone know any?


2013/7/29 Rich Freeman <rich0@gentoo.org>

> On Mon, Jul 29, 2013 at 4:57 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> > Grepping in the tree, looks like only some old genkernel versions are
> > depending on it. Apart of that, what is requiring static libs in
> > cryptsetup and lvm2?
>
> This isn't the specific answer you're likely looking for, but the
> obvious answers would be:
> 1.  Booting without /usr mounted if any of cryptsetup/lvm2's libs are
> located in /usr (not the case for lvm2 on my system at least).
> 2.  Any initramfs creation tool that isn't smart enough to realize
> what cryptsetup/lvm2 are linked to and copy those into the initramfs
> (shouldn't be an issue in anything modern).
>
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 1292 bytes --]

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[Pacho Ramos]

El lun, 29-07-2013 a las 17:13 -0400, Rich Freeman escribió:
> On Mon, Jul 29, 2013 at 4:57 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> > Grepping in the tree, looks like only some old genkernel versions are
> > depending on it. Apart of that, what is requiring static libs in
> > cryptsetup and lvm2?
> 
> This isn't the specific answer you're likely looking for, but the
> obvious answers would be:
> 1.  Booting without /usr mounted if any of cryptsetup/lvm2's libs are
> located in /usr (not the case for lvm2 on my system at least).
> 2.  Any initramfs creation tool that isn't smart enough to realize
> what cryptsetup/lvm2 are linked to and copy those into the initramfs
> (shouldn't be an issue in anything modern).
> 
> Rich
> 

How the /usr in other partition ended finally then? I though that, since
there are a lot of things in / that rely in others in /usr, people were
supposed to either use initramfs or busybox to get /usr mounted

Also, looks like Debian (apart of other distributions I have checked
like openSuSE, Fedora and Mageia) is not providing static libs for them
since 2011:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543163

Maybe are they handling splitted /usr in a different way? :/

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[yac]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

I have fully encrypted systems, including /, which requires an
initramfs with cryptsetup built staticaly.

On Mon, 29 Jul 2013 22:57:58 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> Hello
> 
> As discussed at:
> https://bugs.gentoo.org/show_bug.cgi?id=478476
> 
> Upstream is dropping static libs from udev and, then, sys-apps/udev is
> currently reverting that commit downstream (even if upstream says some
> problems could appear in the future as nobody is taking care of static
> stuff there).
> 
> Grepping in the tree, looks like only some old genkernel versions are
> depending on it. Apart of that, what is requiring static libs in
> cryptsetup and lvm2?
> 
> Thanks a lot
> 
> 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[Matt Turner]

On Mon, Jul 29, 2013 at 5:28 PM, yac <yac@gentoo.org> wrote:
> I have fully encrypted systems, including /, which requires an
> initramfs with cryptsetup built staticaly.

Doesn't it actually require them built statically, or simply that the
necessary libraries are also in the initramfs?

I think this has already been covered.

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[Dustin C. Hatch]

On 7/29/2013 19:33, Matt Turner wrote:
> On Mon, Jul 29, 2013 at 5:28 PM, yac <yac@gentoo.org> wrote:
>> I have fully encrypted systems, including /, which requires an
>> initramfs with cryptsetup built staticaly.
>
> Doesn't it actually require them built statically, or simply that the
> necessary libraries are also in the initramfs?
>
> I think this has already been covered.
>
I think the point is that users may have an initramfs (that they built 
manually or using some tool besides dracut or genkernel) that makes use 
of cryptsetup/lvm2 built statically, or perhaps they just like it that 
way, so why take away that ability and make them change?

-- 
♫Dustin
http://dustin.hatch.name/

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[Rich Freeman]

On Mon, Jul 29, 2013 at 9:01 PM, Dustin C. Hatch <admiralnemo@gmail.com> wrote:
> I think the point is that users may have an initramfs (that they built
> manually or using some tool besides dracut or genkernel) that makes use of
> cryptsetup/lvm2 built statically, or perhaps they just like it that way, so
> why take away that ability and make them change?

Presumably because it is harder to maintain?  If somebody wants to
maintain (proxy or otherwise) the needed changes to support the static
USE flag my opinion is that they should be able to do so.  They would
need to be responsive on bugs/etc and not be a burden on the other
maintainers.

However, if nobody wants to step up and do the work, then those who
are doing the work basically get the last word in how it gets done.
That's just how things roll around here.

Besides, you could make the same argument about every binary in
/(s)bin.  Initramfs builders manage to deal with a dynamically-linked
bash, so they should be able to handle lvm+cryptsetup.

Rich

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[Dustin C. Hatch]

On 7/29/2013 20:07, Rich Freeman wrote:
> On Mon, Jul 29, 2013 at 9:01 PM, Dustin C. Hatch <admiralnemo@gmail.com> wrote:
>> I think the point is that users may have an initramfs (that they built
>> manually or using some tool besides dracut or genkernel) that makes use of
>> cryptsetup/lvm2 built statically, or perhaps they just like it that way, so
>> why take away that ability and make them change?
>
> Presumably because it is harder to maintain?  If somebody wants to
> maintain (proxy or otherwise) the needed changes to support the static
> USE flag my opinion is that they should be able to do so.  They would
> need to be responsive on bugs/etc and not be a burden on the other
> maintainers.
>
> However, if nobody wants to step up and do the work, then those who
> are doing the work basically get the last word in how it gets done.
> That's just how things roll around here.
>
> Besides, you could make the same argument about every binary in
> /(s)bin.  Initramfs builders manage to deal with a dynamically-linked
> bash, so they should be able to handle lvm+cryptsetup.
>
> Rich
>
As I understood the OP's request, he was looking for current use cases 
of the option. yac offered one. As usual, he was met with "your argument 
is invalid." I was merely trying to help his point.

-- 
♫Dustin
http://dustin.hatch.name/

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Mon, Jul 29, 2013 at 11:32:12PM +0200, Pacho Ramos wrote:
> How the /usr in other partition ended finally then? I though that, since
> there are a lot of things in / that rely in others in /usr, people were
> supposed to either use initramfs or busybox to get /usr mounted

Unfortunately it hasn't ended; the debating over it just stopped. 

There was a council vote in April 2012 over this, but it isn't even
clear what they voted for.

My personal opinion though, is that if people  have /usr separate from
/, they should be using an initramfs to get /usr mounted. If they want
to use busybox[sep-usr] this is an option that we came up with
internally in gentoo, but it has many limitations.

William




[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

[Pacho Ramos]

El lun, 29-07-2013 a las 21:07 -0400, Rich Freeman escribió:
> On Mon, Jul 29, 2013 at 9:01 PM, Dustin C. Hatch <admiralnemo@gmail.com> wrote:
> > I think the point is that users may have an initramfs (that they built
> > manually or using some tool besides dracut or genkernel) that makes use of
> > cryptsetup/lvm2 built statically, or perhaps they just like it that way, so
> > why take away that ability and make them change?
> 
> Presumably because it is harder to maintain?  If somebody wants to
> maintain (proxy or otherwise) the needed changes to support the static
> USE flag my opinion is that they should be able to do so.  They would
> need to be responsive on bugs/etc and not be a burden on the other
> maintainers.
> 
> However, if nobody wants to step up and do the work, then those who
> are doing the work basically get the last word in how it gets done.
> That's just how things roll around here.
> 
> Besides, you could make the same argument about every binary in
> /(s)bin.  Initramfs builders manage to deal with a dynamically-linked
> bash, so they should be able to handle lvm+cryptsetup.
> 
> Rich
> 
> 

It also causes some problems (some of them broke during udev updated
from, for example, 200 to 204):
https://bugs.gentoo.org/buglist.cgi?quicksearch=lvm2%
20static&list_id=1914334
https://bugs.gentoo.org/buglist.cgi?quicksearch=cryptsetup%
20static&list_id=1914332

[gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Samuli Suominen]

On 29/07/13 23:57, Pacho Ramos wrote:
> Hello
>
> As discussed at:
> https://bugs.gentoo.org/show_bug.cgi?id=478476
>
> Upstream is dropping static libs from udev and, then, sys-apps/udev is
> currently reverting that commit downstream (even if upstream says some
> problems could appear in the future as nobody is taking care of static
> stuff there).
>
> Grepping in the tree, looks like only some old genkernel versions are
> depending on it. Apart of that, what is requiring static libs in
> cryptsetup and lvm2?
>
> Thanks a lot
>

cryptsetup upstream installed minimal Gentoo setup and tested our 
handling of 'static' and was disappointed finding them broken

https://bugs.gentoo.org/show_bug.cgi?id=438998 - cryptsetup static+pcre 
fails

https://bugs.gentoo.org/show_bug.cgi?id=468400 - cryptsetup 
static+selinux fails

https://bugs.gentoo.org/show_bug.cgi?id=472692 - cryptsetup static+ssl fails

https://bugs.gentoo.org/show_bug.cgi?id=462908 - lvm2 static-libs 
missing library

https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE flag 
missing proper description, yes this is minor

https://bugs.gentoo.org/show_bug.cgi?id=370217 - lvm2 fails to build due 
to missing -lrt, likely related to linking against libudev, yes the 
feature we are discussing to be dropped has been completely broken for ages

https://bugs.gentoo.org/show_bug.cgi?id=439414 - lvm2 static+selinux fails

So we are not talking about removing anything that works, but something 
users get hit by reading outdated guides that instruct them to enable 
USE=static

+1 for punting broken features

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Pacho Ramos]

El mar, 30-07-2013 a las 11:42 +0300, Samuli Suominen escribió:
> On 29/07/13 23:57, Pacho Ramos wrote:
> > Hello
> >
> > As discussed at:
> > https://bugs.gentoo.org/show_bug.cgi?id=478476
> >
> > Upstream is dropping static libs from udev and, then, sys-apps/udev is
> > currently reverting that commit downstream (even if upstream says some
> > problems could appear in the future as nobody is taking care of static
> > stuff there).
> >
> > Grepping in the tree, looks like only some old genkernel versions are
> > depending on it. Apart of that, what is requiring static libs in
> > cryptsetup and lvm2?
> >
> > Thanks a lot
> >
> 
> cryptsetup upstream installed minimal Gentoo setup and tested our 
> handling of 'static' and was disappointed finding them broken
> 
> https://bugs.gentoo.org/show_bug.cgi?id=438998 - cryptsetup static+pcre 
> fails
> 
> https://bugs.gentoo.org/show_bug.cgi?id=468400 - cryptsetup 
> static+selinux fails
> 
> https://bugs.gentoo.org/show_bug.cgi?id=472692 - cryptsetup static+ssl fails
> 
> https://bugs.gentoo.org/show_bug.cgi?id=462908 - lvm2 static-libs 
> missing library
> 
> https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE flag 
> missing proper description, yes this is minor
> 
> https://bugs.gentoo.org/show_bug.cgi?id=370217 - lvm2 fails to build due 
> to missing -lrt, likely related to linking against libudev, yes the 
> feature we are discussing to be dropped has been completely broken for ages
> 
> https://bugs.gentoo.org/show_bug.cgi?id=439414 - lvm2 static+selinux fails
> 
> So we are not talking about removing anything that works, but something 
> users get hit by reading outdated guides that instruct them to enable 
> USE=static
> 
> +1 for punting broken features
> 
> 

We should drop that broken support I guess, but will CC its maintainers
here too (they are CCed in bug report already)

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Robin H. Johnson]

As both a member of base-system, and the lvm2 maintainer, I'm going to
go and look at fixing them, because I'd prefer to keep them available as
static builds.

On Wed, Jul 31, 2013 at 09:07:39PM +0200, Pacho Ramos wrote:
> El mar, 30-07-2013 a las 11:42 +0300, Samuli Suominen escribió:
> > On 29/07/13 23:57, Pacho Ramos wrote:
> > > Hello
> > >
> > > As discussed at:
> > > https://bugs.gentoo.org/show_bug.cgi?id=478476
> > >
> > > Upstream is dropping static libs from udev and, then, sys-apps/udev is
> > > currently reverting that commit downstream (even if upstream says some
> > > problems could appear in the future as nobody is taking care of static
> > > stuff there).
> > >
> > > Grepping in the tree, looks like only some old genkernel versions are
> > > depending on it. Apart of that, what is requiring static libs in
> > > cryptsetup and lvm2?
> > >
> > > Thanks a lot
> > >
> > 
> > cryptsetup upstream installed minimal Gentoo setup and tested our 
> > handling of 'static' and was disappointed finding them broken
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=438998 - cryptsetup static+pcre 
> > fails
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=468400 - cryptsetup 
> > static+selinux fails
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=472692 - cryptsetup static+ssl fails
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=462908 - lvm2 static-libs 
> > missing library
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE flag 
> > missing proper description, yes this is minor
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=370217 - lvm2 fails to build due 
> > to missing -lrt, likely related to linking against libudev, yes the 
> > feature we are discussing to be dropped has been completely broken for ages
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=439414 - lvm2 static+selinux fails
> > 
> > So we are not talking about removing anything that works, but something 
> > users get hit by reading outdated guides that instruct them to enable 
> > USE=static
> > 
> > +1 for punting broken features
> > 
> > 
> 
> We should drop that broken support I guess, but will CC its maintainers
> here too (they are CCed in bug report already)
> 

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Pacho Ramos]

El mié, 31-07-2013 a las 19:42 +0000, Robin H. Johnson escribió:
> As both a member of base-system, and the lvm2 maintainer, I'm going to
> go and look at fixing them, because I'd prefer to keep them available as
> static builds.
> 

But, what is requiring it?
https://bugs.gentoo.org/show_bug.cgi?id=478110#c33

Looks like the static stuff isn't needed (that would allow us to not
need to keep static stuff in sys-apps/udev)

> On Wed, Jul 31, 2013 at 09:07:39PM +0200, Pacho Ramos wrote:
> > El mar, 30-07-2013 a las 11:42 +0300, Samuli Suominen escribió:
> > > On 29/07/13 23:57, Pacho Ramos wrote:
> > > > Hello
> > > >
> > > > As discussed at:
> > > > https://bugs.gentoo.org/show_bug.cgi?id=478476
> > > >
> > > > Upstream is dropping static libs from udev and, then, sys-apps/udev is
> > > > currently reverting that commit downstream (even if upstream says some
> > > > problems could appear in the future as nobody is taking care of static
> > > > stuff there).
> > > >
> > > > Grepping in the tree, looks like only some old genkernel versions are
> > > > depending on it. Apart of that, what is requiring static libs in
> > > > cryptsetup and lvm2?
> > > >
> > > > Thanks a lot
> > > >
> > > 
> > > cryptsetup upstream installed minimal Gentoo setup and tested our 
> > > handling of 'static' and was disappointed finding them broken
> > > 
> > > https://bugs.gentoo.org/show_bug.cgi?id=438998 - cryptsetup static+pcre 
> > > fails
> > > 
> > > https://bugs.gentoo.org/show_bug.cgi?id=468400 - cryptsetup 
> > > static+selinux fails
> > > 
> > > https://bugs.gentoo.org/show_bug.cgi?id=472692 - cryptsetup static+ssl fails
> > > 
> > > https://bugs.gentoo.org/show_bug.cgi?id=462908 - lvm2 static-libs 
> > > missing library
> > > 
> > > https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE flag 
> > > missing proper description, yes this is minor
> > > 
> > > https://bugs.gentoo.org/show_bug.cgi?id=370217 - lvm2 fails to build due 
> > > to missing -lrt, likely related to linking against libudev, yes the 
> > > feature we are discussing to be dropped has been completely broken for ages
> > > 
> > > https://bugs.gentoo.org/show_bug.cgi?id=439414 - lvm2 static+selinux fails
> > > 
> > > So we are not talking about removing anything that works, but something 
> > > users get hit by reading outdated guides that instruct them to enable 
> > > USE=static
> > > 
> > > +1 for punting broken features
> > > 
> > > 
> > 
> > We should drop that broken support I guess, but will CC its maintainers
> > here too (they are CCed in bug report already)
> > 
> 

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Wed, Jul 31, 2013 at 07:42:26PM +0000, Robin H. Johnson wrote:
> As both a member of base-system, and the lvm2 maintainer, I'm going to
> go and look at fixing them, because I'd prefer to keep them available as
> static builds.

Robin,

I'm curious what the use case for keeping them as static builds is? I
would rather see that support dropped as well.

Udev and kmod upstream do not support static builds so I want
to drop that support from our ebuilds.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Rich Freeman]

On Wed, Jul 31, 2013 at 10:03 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Wed, Jul 31, 2013 at 07:42:26PM +0000, Robin H. Johnson wrote:
>> As both a member of base-system, and the lvm2 maintainer, I'm going to
>> go and look at fixing them, because I'd prefer to keep them available as
>> static builds.
>
> I'm curious what the use case for keeping them as static builds is? I
> would rather see that support dropped as well.

Honestly, I don't think maintainers should be asked to justify
features unless they're actually causing some kind of conflict.

If Robin wants to support USE=static for lvm2, he can do so.  If it
somehow caused problems with other packages that would be a different
matter, but I can't see how a static binary should hurt anything.  If
he wanted to drop dynamic linking support I'd also be concerned.
However, maintainers should be free to support options even if some
consider them a waste of time.

If Robin wants to satisfy our idle curiosity he can do so, but let's
not hound maintainers willing to do extra work unless they're actually
causing problems.

Rich

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 04:03, William Hubbs wrote:
> On Wed, Jul 31, 2013 at 07:42:26PM +0000, Robin H. Johnson wrote:
>> As both a member of base-system, and the lvm2 maintainer, I'm going to
>> go and look at fixing them, because I'd prefer to keep them available as
>> static builds.
> 
> Robin,
> 
> I'm curious what the use case for keeping them as static builds is? I
> would rather see that support dropped as well.
> 
> Udev and kmod upstream do not support static builds so I want
> to drop that support from our ebuilds.

I started fixing that in kmod and got something else more pressing to
do, today I'll spend the whole day trying to get that in shape.

Help welcome obviously.

As said before using correct C namespacing isn't rocket science.

(obviously when you start seeing unchecked mallocs and reallocs in
library code you might shiver a bit... but that can be fixed later as well)

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Alexandre Rostovtsev]

On Wed, 2013-07-31 at 22:12 -0400, Rich Freeman wrote:
> Honestly, I don't think maintainers should be asked to justify
> features unless they're actually causing some kind of conflict.
> 
> If Robin wants to support USE=static for lvm2, he can do so.  If it
> somehow caused problems with other packages that would be a different
> matter, but I can't see how a static binary should hurt anything.  If
> he wanted to drop dynamic linking support I'd also be concerned.
> However, maintainers should be free to support options even if some
> consider them a waste of time.
> 
> If Robin wants to satisfy our idle curiosity he can do so, but let's
> not hound maintainers willing to do extra work unless they're actually
> causing problems.

The problem is when that extra work results in a flag on virtual/udev
which cannot be satisfied by some of the virtual's implementations (like
systemd) and which then leads to several screen lengths of uninformative
portage errors facing users who are upgrading to gnome-3.8.

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On Thu, Aug 01, 2013 at 04:22:29AM +0200, Luca Barbato wrote:
> On 01/08/13 04:03, William Hubbs wrote:
> > On Wed, Jul 31, 2013 at 07:42:26PM +0000, Robin H. Johnson wrote:
> >> As both a member of base-system, and the lvm2 maintainer, I'm going to
> >> go and look at fixing them, because I'd prefer to keep them available as
> >> static builds.
> > 
> > Robin,
> > 
> > I'm curious what the use case for keeping them as static builds is? I
> > would rather see that support dropped as well.
> > 
> > Udev and kmod upstream do not support static builds so I want
> > to drop that support from our ebuilds.
> 
> I started fixing that in kmod and got something else more pressing to
> do, today I'll spend the whole day trying to get that in shape.
> 
> Help welcome obviously.
> 
> As said before using correct C namespacing isn't rocket science.
> 
> (obviously when you start seeing unchecked mallocs and reallocs in
> library code you might shiver a bit... but that can be fixed later as well)

I would rather not carry distro-specific patches forever to support
something like this, so please forward your patches upstream.

Thanks,

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

On Wed, Jul 31, 2013 at 10:32:56PM -0400, Alexandre Rostovtsev wrote:
> On Wed, 2013-07-31 at 22:12 -0400, Rich Freeman wrote:
> > Honestly, I don't think maintainers should be asked to justify
> > features unless they're actually causing some kind of conflict.
> > 
> > If Robin wants to support USE=static for lvm2, he can do so.  If it
> > somehow caused problems with other packages that would be a different
> > matter, but I can't see how a static binary should hurt anything.  If
> > he wanted to drop dynamic linking support I'd also be concerned.
> > However, maintainers should be free to support options even if some
> > consider them a waste of time.
> > 
> > If Robin wants to satisfy our idle curiosity he can do so, but let's
> > not hound maintainers willing to do extra work unless they're actually
> > causing problems.
> 
> The problem is when that extra work results in a flag on virtual/udev
> which cannot be satisfied by some of the virtual's implementations (like
> systemd) and which then leads to several screen lengths of uninformative
> portage errors facing users who are upgrading to gnome-3.8.

Another problem is that udev and kmod actively ban static linking. They,
like systemd, use gcc symbol visibility, which is not fully supported in
static libraries [1], and if you look at the wiki I refer to, one of the
features they point out is that you don't have to worry about private
symbols clashing any more in libraries because you can just hide them.

If we want to continue supporting this, it will probably require custom
patches to udev, and kmod. Then we will have to make sure none of that
breaks systemd.

I would be willing to bet that these patches probably would not be
accepted upstream, so we would have to maintain them forever.

If we are going to try to maintain something like that, which will
affect multiple packages in base-system, I am just curious what the use
case for it is, especially since multiple other distros do not support
it.

William

[1] http://gcc.gnu.org/wiki/Visibility

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Pacho Ramos]

El mié, 31-07-2013 a las 22:32 -0400, Alexandre Rostovtsev escribió:
> On Wed, 2013-07-31 at 22:12 -0400, Rich Freeman wrote:
> > Honestly, I don't think maintainers should be asked to justify
> > features unless they're actually causing some kind of conflict.
> > 
> > If Robin wants to support USE=static for lvm2, he can do so.  If it
> > somehow caused problems with other packages that would be a different
> > matter, but I can't see how a static binary should hurt anything.  If
> > he wanted to drop dynamic linking support I'd also be concerned.
> > However, maintainers should be free to support options even if some
> > consider them a waste of time.
> > 
> > If Robin wants to satisfy our idle curiosity he can do so, but let's
> > not hound maintainers willing to do extra work unless they're actually
> > causing problems.
> 
> The problem is when that extra work results in a flag on virtual/udev
> which cannot be satisfied by some of the virtual's implementations (like
> systemd) and which then leads to several screen lengths of uninformative
> portage errors facing users who are upgrading to gnome-3.8.
> 
> 
> 

And also forces sys-apps/udev maintainers to keep patching it to
"support" static stuff on it, even when upstream don't care about it and
disabled it

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Rich Freeman]

On Wed, Jul 31, 2013 at 11:38 PM, William Hubbs <williamh@gentoo.org> wrote:
> If we want to continue supporting this, it will probably require custom
> patches to udev, and kmod. Then we will have to make sure none of that
> breaks systemd.

Seems like the simpler solution is to just have a dep on -static
lvm/cryptsetup for those packages.  Users who want to use static
lvm/cryptsetup will not be able to use udev/kmod.

The issue with the virtual and confusing error messages that result
seems less simple to resolve.  That sounds more like a bug in portage
though.  If I have virtual/udev[static] installed and I want to
install gnome I should just get an error indicating that to install
gnome I need to drop the static USE for virtual/udev.  Some of
portage's error messages are a bit cryptic but that shouldn't be a
reason to force a package to drop a non-default USE flag.

I'll freely admit that I could be missing some nuance here.

Rich

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]

01.08.2013 01:01, Pacho Ramos пишет:
> El mié, 31-07-2013 a las 19:42 +0000, Robin H. Johnson escribió:
>> As both a member of base-system, and the lvm2 maintainer, I'm going to
>> go and look at fixing them, because I'd prefer to keep them available as
>> static builds.
>>
> 
> But, what is requiring it?
> https://bugs.gentoo.org/show_bug.cgi?id=478110#c33
> 
> Looks like the static stuff isn't needed (that would allow us to not
> need to keep static stuff in sys-apps/udev)
> 
>> On Wed, Jul 31, 2013 at 09:07:39PM +0200, Pacho Ramos wrote:
>>> El mar, 30-07-2013 a las 11:42 +0300, Samuli Suominen escribió:
>>>> On 29/07/13 23:57, Pacho Ramos wrote:
>>>>> Hello
>>>>>
>>>>> As discussed at:
>>>>> https://bugs.gentoo.org/show_bug.cgi?id=478476
>>>>>
>>>>> Upstream is dropping static libs from udev and, then, sys-apps/udev is
>>>>> currently reverting that commit downstream (even if upstream says some
>>>>> problems could appear in the future as nobody is taking care of static
>>>>> stuff there).
>>>>>
>>>>> Grepping in the tree, looks like only some old genkernel versions are
>>>>> depending on it. Apart of that, what is requiring static libs in
>>>>> cryptsetup and lvm2?
>>>>>
>>>>> Thanks a lot
>>>>>
>>>>
>>>> cryptsetup upstream installed minimal Gentoo setup and tested our 
>>>> handling of 'static' and was disappointed finding them broken
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=438998 - cryptsetup static+pcre 
>>>> fails
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=468400 - cryptsetup 
>>>> static+selinux fails
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=472692 - cryptsetup static+ssl fails
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=462908 - lvm2 static-libs 
>>>> missing library
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE flag 
>>>> missing proper description, yes this is minor
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=370217 - lvm2 fails to build due 
>>>> to missing -lrt, likely related to linking against libudev, yes the 
>>>> feature we are discussing to be dropped has been completely broken for ages
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=439414 - lvm2 static+selinux fails
>>>>
>>>> So we are not talking about removing anything that works, but something 
>>>> users get hit by reading outdated guides that instruct them to enable 
>>>> USE=static
>>>>
>>>> +1 for punting broken features
>>>>
>>>>
>>>
>>> We should drop that broken support I guess, but will CC its maintainers
>>> here too (they are CCed in bug report already)
>>>
>>
> 
> 
> 
> 
Some cluster things in lvm does not work in mine setup with shared
builds. Only USE="static static-libs" is only working combination.
Something related with cluster file locking library - it does not load
if it is build shared. Probably i should file bugreport about this

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On Thu, Aug 01, 2013 at 06:01:50AM -0400, Rich Freeman wrote:
> On Wed, Jul 31, 2013 at 11:38 PM, William Hubbs <williamh@gentoo.org> wrote:
> > If we want to continue supporting this, it will probably require custom
> > patches to udev, and kmod. Then we will have to make sure none of that
> > breaks systemd.
> 
> Seems like the simpler solution is to just have a dep on -static
> lvm/cryptsetup for those packages.  Users who want to use static
> lvm/cryptsetup will not be able to use udev/kmod.

udev and kmod do not have any dependencies on lvm2 or cryptsetup. The
issue is that lvm2/cryptsetup[static] need the libkmod.a and libudev.a
static libraries.

There is a hack in our udev and kmod ebuilds that makes it possible to
build the static libraries, but I think we should remove that hack since
upstream bans building them.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 17:04, William Hubbs wrote:
> There is a hack in our udev and kmod ebuilds that makes it possible to
> build the static libraries, but I think we should remove that hack since
> upstream bans building them.

linking statically makes the problem apparent, I guess isn't that wise
hiding it under a rug and hoping it won't ever bite you.

Anyway I volunteered Federico to sort out this mess and he got that part
more or less done.

My github has his changes and I started to track what picked my attention.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

Dnia 2013-08-01, o godz. 17:17:35
Luca Barbato <lu_zero@gentoo.org> napisał(a):

> On 01/08/13 17:04, William Hubbs wrote:
> > There is a hack in our udev and kmod ebuilds that makes it possible to
> > build the static libraries, but I think we should remove that hack since
> > upstream bans building them.
> 
> linking statically makes the problem apparent, I guess isn't that wise
> hiding it under a rug and hoping it won't ever bite you.
> 
> Anyway I volunteered Federico to sort out this mess and he got that part
> more or less done.
> 
> My github has his changes and I started to track what picked my attention.

So esystemd and ekmod now?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 17:36, Michał Górny wrote:
> So esystemd and ekmod now?

You know my stance on systemd, for me it is a jumble of bad and
interesting ideas not so soundly implemented, I do not have much time or
will to play with that thing.

kmod on the other hand had a pressing issue and getting it fixed-ish
took about an evening while having Federico see around it.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Rich Freeman]

On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-08-01, o godz. 17:17:35
> Luca Barbato <lu_zero@gentoo.org> napisał(a):
>
>> On 01/08/13 17:04, William Hubbs wrote:
>> > There is a hack in our udev and kmod ebuilds that makes it possible to
>> > build the static libraries, but I think we should remove that hack since
>> > upstream bans building them.

Thanks for the clarification - that makes sense.

>> Anyway I volunteered Federico to sort out this mess and he got that part
>> more or less done.
>>

If you're willing to do the work I think the teams should be willing
to allow you to support the necessary changes.  That is, assuming that
the changes aren't so intrusive that they create a real potential for
bugs/etc.  You would of course have to keep up.

>
> So esystemd and ekmod now?

If the changes are really extensive then that might be the better
solution unless upstream is interested in accepting the changes.

That all assumes lu_zero wants to support all these packages.  If not
then the maintainers can drop support if they wish, and just set
deps/blockers accordingly.  If portage doesn't handle the resulting
resolution issues properly that would seem to be a portage bug - this
isn't really a typical configuration in any case.  I'd be more
concerned if it came up by default if you installed a stage3 and did
an emerge gnome.

Rich

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

Dnia 2013-08-01, o godz. 13:32:28
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny <mgorny@gentoo.org> wrote:
> > Dnia 2013-08-01, o godz. 17:17:35
> > Luca Barbato <lu_zero@gentoo.org> napisał(a):
> >
> >> On 01/08/13 17:04, William Hubbs wrote:
> >> > There is a hack in our udev and kmod ebuilds that makes it possible to
> >> > build the static libraries, but I think we should remove that hack since
> >> > upstream bans building them.
> 
> Thanks for the clarification - that makes sense.
> 
> >> Anyway I volunteered Federico to sort out this mess and he got that part
> >> more or less done.
> >>
> 
> If you're willing to do the work I think the teams should be willing
> to allow you to support the necessary changes.  That is, assuming that
> the changes aren't so intrusive that they create a real potential for

If only people were that keen to fix the core issue. That is, to fix
static linking on Linux and make it useful without two batches of hacks
on top of it.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Pacho Ramos]

El jue, 01-08-2013 a las 18:11 +0200, Luca Barbato escribió:
> On 01/08/13 17:36, Michał Górny wrote:
> > So esystemd and ekmod now?
> 
> You know my stance on systemd, for me it is a jumble of bad and
> interesting ideas not so soundly implemented, I do not have much time or
> will to play with that thing.
> 
> kmod on the other hand had a pressing issue and getting it fixed-ish
> took about an evening while having Federico see around it.
> 
> lu
> 

But, what are the advantages of putting a lot of effort in keeping
static libs for udev? Looks like nothing really need them, and even
Debian (that doesn't use systemd by default) drops them

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Pacho Ramos]

El jue, 01-08-2013 a las 14:05 +0400, Sergey Popov escribió:
[...]
> Some cluster things in lvm does not work in mine setup with shared
> builds. Only USE="static static-libs" is only working combination.
> Something related with cluster file locking library - it does not load
> if it is build shared. Probably i should file bugreport about this
> 

You certainly should report it as looks like we are the only downstream
willing to still keep that option and, once upstream has dropped it and
people from other distributions won't likely help us fixing the bugs,
would be better to try to fix it (in a long term perspective)

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Samuli Suominen]

On 01/08/13 19:11, Luca Barbato wrote:
> On 01/08/13 17:36, Michał Górny wrote:
>> So esystemd and ekmod now?
>
> You know my stance on systemd, for me it is a jumble of bad and
> interesting ideas not so soundly implemented, I do not have much time or
> will to play with that thing.
>
> kmod on the other hand had a pressing issue and getting it fixed-ish
> took about an evening while having Federico see around it.
>
> lu
>

still, first the patch goes upstream and after upstream review and 
commit to git it goes in tree
otherwise we opt to the fallback and disable udev from lvm2/cryptsetup 
when USE=static is enabled (like cryptsetup upstream suggested to me)
gentoo-specific patches mangling namespace of udev, kmod, whatever 
doesn't sound good at all
however working it with upstream sounds great

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On Thu, Aug 01, 2013 at 07:36:12PM +0200, Michał Górny wrote:
> Dnia 2013-08-01, o godz. 13:32:28
> Rich Freeman <rich0@gentoo.org> napisał(a):
> 
> > On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny <mgorny@gentoo.org> wrote:
> > > Dnia 2013-08-01, o godz. 17:17:35
> > > Luca Barbato <lu_zero@gentoo.org> napisał(a):
> > >
> > >> On 01/08/13 17:04, William Hubbs wrote:
> > >> > There is a hack in our udev and kmod ebuilds that makes it possible to
> > >> > build the static libraries, but I think we should remove that hack since
> > >> > upstream bans building them.
> > 
> > Thanks for the clarification - that makes sense.
> > 
> > >> Anyway I volunteered Federico to sort out this mess and he got that part
> > >> more or less done.
> > >>
> > 
> > If you're willing to do the work I think the teams should be willing
> > to allow you to support the necessary changes.  That is, assuming that
> > the changes aren't so intrusive that they create a real potential for
> 
> If only people were that keen to fix the core issue. That is, to fix
> static linking on Linux and make it useful without two batches of hacks
> on top of it.
 
 I wouldn't have put it this way, but yes, I have to agree with mgorny
 here. the real fix is in binutils.
 It needs to be fixed to support static linking and visibility
 correctly.

 William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 19:46, Pacho Ramos wrote:
> El jue, 01-08-2013 a las 18:11 +0200, Luca Barbato escribió:
>> On 01/08/13 17:36, Michał Górny wrote:
>>> So esystemd and ekmod now?
>>
>> You know my stance on systemd, for me it is a jumble of bad and
>> interesting ideas not so soundly implemented, I do not have much time or
>> will to play with that thing.
>>
>> kmod on the other hand had a pressing issue and getting it fixed-ish
>> took about an evening while having Federico see around it.
>>
>> lu
>>
> 
> But, what are the advantages of putting a lot of effort in keeping
> static libs for udev?

A lot of effort means not using random-clashing-names, not keeping
functions around just because.

> Looks like nothing really need them, and even
> Debian (that doesn't use systemd by default) drops them

Robbat said he wants to keep the stuff working, thus I lent him an hand
while introducing a friend to a small codebase with a good number of
practices I consider faulty but sort of easy to fix.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 19:54, Samuli Suominen wrote:
> still, first the patch goes upstream and after upstream review and 
> commit to git it goes in tree otherwise we opt to the fallback and
> disable udev from lvm2/cryptsetup when USE=static is enabled (like
> cryptsetup upstream suggested to me) gentoo-specific patches mangling
> namespace of udev, kmod, whatever doesn't sound good at all however
> working it with upstream sounds great

I just spent an evening introducing a friend willing to have a look the
codebase. My solution to the problem of clashing symbols had been 3 fold:

- many functions are small and already inline, they are using in the
tool (bad practice IMHO) and in the library once. Making them static is
easy and works.

- some functions are using inside the library a couple of times, adding
an (ugly) privkm_ is enough to avoid the problem.

- some functions were used just in the tool and not in the library,
moved where it belongs.

Instead of running around in circles screaming static linking is unholy
fixing it that way wouldn't had take much...

I won't expect upstream picking up what Federico wrote anytime out of
pride more than technical merit.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

Dnia 2013-08-01, o godz. 23:03:11
Luca Barbato <lu_zero@gentoo.org> napisał(a):

> On 01/08/13 19:46, Pacho Ramos wrote:
> > El jue, 01-08-2013 a las 18:11 +0200, Luca Barbato escribió:
> >> On 01/08/13 17:36, Michał Górny wrote:
> >>> So esystemd and ekmod now?
> >>
> >> You know my stance on systemd, for me it is a jumble of bad and
> >> interesting ideas not so soundly implemented, I do not have much time or
> >> will to play with that thing.
> >>
> >> kmod on the other hand had a pressing issue and getting it fixed-ish
> >> took about an evening while having Federico see around it.
> >>
> >> lu
> >>
> > 
> > But, what are the advantages of putting a lot of effort in keeping
> > static libs for udev?
> 
> A lot of effort means not using random-clashing-names, not keeping
> functions around just because.

That would be a lot of effort if upstream doesn't accept it and we end
up patching it all the way...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 23:53, Michał Górny wrote:
> That would be a lot of effort if upstream doesn't accept it and we end
> up patching it all the way...

kmod isn't complex and probably could be made even a bit more compact,
considering also the pace of its development and the kind of changes in
the last month I doubt would be so incredible.

b6adccd6ff819b8befc48ede41a13f2201dce443 is quite enlightening on which
are their best practises anyway.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 04:48, William Hubbs wrote:
> I would rather not carry distro-specific patches forever to support
> something like this, so please forward your patches upstream.

The code is in a public git, it is even not written by me, anybody can
forward it to upstream...

lu

[gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Steven J. Long]

Pacho Ramos wrote:
> How the /usr in other partition ended finally then? I though that, since
> there are a lot of things in / that rely in others in /usr, people were
> supposed to either use initramfs or busybox to get /usr mounted

As Rich said, lvm doesn't link outside rootfs so it's not an issue: you only really
need an initramfs if rootfs is on lvm/encrypted/raid, or you need udev to get through
localmount.
 
William Hubbs wrote:
> Unfortunately it hasn't ended; the debating over it just stopped. 
> 
> There was a council vote in April 2012 over this, but it isn't even
> clear what they voted for.

You know it was perfectly clear: zmedico had even posted the initial clarification
of chainsaw's agenda item, immediately it was raised, and as ulm made it clear the
last time this was discussed, that was what was voted on.

What happened after was that people who didn't like the decision tried to weasel out
of it by claiming that it wasn't really what was discussed, despite the clear trail.

More of "the stupidity of not accepting decisions" and moving on to implementation,
that is usually attributed to "traditionalists."

> My personal opinion though, is that if people  have /usr separate from
> /, they should be using an initramfs to get /usr mounted. If they want
> to use busybox[sep-usr] this is an option that we came up with
> internally in gentoo, but it has many limitations.

It's funny how you always discuss those two options and consistently fail to mention
the one option that allows people who never needed an initramfs before to continue
without one, and still use udev in line with upstream requirements, but there it is:

http://forums.gentoo.org/viewtopic-t-901206.html
(constructive feedback welcome, as ever: ie stuff that helps improve the situation,
not arguments about why udev's upstream requirement isn't really what GregKH said it
was.)

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Duncan]

Steven J. Long posted on Fri, 02 Aug 2013 12:31:08 +0100 as excerpted:

> As Rich said, lvm doesn't link outside rootfs so it's not an issue: you
> only really need an initramfs if rootfs is on lvm/encrypted/raid, or you
> need udev to get through localmount.

Or, unfortunately, for root on mult-device btrfs[1], since the usual 
kernel commandline rootflags=device=/dev/whatever doesn't seem to work 
for some reason.[2]

Tho hopefully that bug will be fixed before the "experimental" label is 
stripped from btrfs...

---
[1] Yes, as appropriate for running on an experimental fs, I have 
backups, tho the dual-device raid1 mode I'm using is /reasonably/ stable, 
now.  I switched to btrfs when I upgraded to ssd, both for the ssd 
support and for checksummed data/metadata with a second copy to retrieve 
from if the first fails the checksum.

[2] I tried with a btrfs raid1 and could mount either device with root= 
and rootflags=degraded, so it was definitely parsing rootflags, but no 
way was it taking rootflags=device= to mount them undegraded without a 
userspace btrfs device scan first, and that requires an initr*.  Maybe it 
was a problem with the kernel splitting at the second = instead of the 
first, I don't know, but it definitely wasn't working.  So now I'm 
running dracut with several of its default modules stripped via 
INSTALL_MASK including the one pulling in kmod since I'm running 
monolithic kernel and have kmod package.provided, and USE=btrfs plus 
adding it to the module config.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Rich Freeman]

On Fri, Aug 2, 2013 at 7:31 AM, Steven J. Long
<slong@rathaus.eclipse.co.uk> wrote:
> It's funny how you always discuss those two options and consistently fail to mention
> the one option that allows people who never needed an initramfs before to continue
> without one, and still use udev in line with upstream requirements, but there it is:
>
> http://forums.gentoo.org/viewtopic-t-901206.html

If we clarify the decision (which seems increasingly likely as there
seems to be demand), I'd suggest we would vote on something like:

On Gentoo we (do, do not) support configurations that do not place
/usr on the root filesystem without an early-boot mechanism to mount
it (eg an initramfs, early-running script, init replacement, etc).

When I use the term initramfs it is intended just as a stand-in.  That
said, I think that the initramfs is honestly the cleanest solution for
early-boot setup as it supports a huge variety of configurations.
However, the actual policy would be more general, and the options that
are available to users will be whatever the community is willing to
supply/support.

If anybody considers that ambiguous in any way please speak up now.

As far as my own position goes, I'll be voting for do not.  That
doesn't mean that I think that maintainers should look to make
dramatic changes overnight - we should still be sending out news/etc.
I think that maintainers have made a sufficient case that this is
where the winds are blowing.  I was pretty concerned about this when
the topic came up early last year, but I found getting dracut working
wasn't hard (it is easier and more robust now) and brought a number of
benefits beyond just mounting /usr.  My root is now on lvm+mdadm, and
I have a separate /usr and /var and it all works just fine (they're
bind-mounts on top of yet another mount).  When I build a new kernel
it only takes one line to build an initramfs to go with it.

Rich

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Mike Gilbert]

On Fri, Aug 2, 2013 at 8:06 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Steven J. Long posted on Fri, 02 Aug 2013 12:31:08 +0100 as excerpted:
>
>> As Rich said, lvm doesn't link outside rootfs so it's not an issue: you
>> only really need an initramfs if rootfs is on lvm/encrypted/raid, or you
>> need udev to get through localmount.
>
> Or, unfortunately, for root on mult-device btrfs[1], since the usual
> kernel commandline rootflags=device=/dev/whatever doesn't seem to work
> for some reason.[2]
>
> Tho hopefully that bug will be fixed before the "experimental" label is
> stripped from btrfs...
>

Passing rootflags=device= is a little fragile anyway, since it depends
on the kernel detecting your devices in a certain order. Having a
multi-device btrfs root without an initramfs is asking for trouble.

> ---
> [1] Yes, as appropriate for running on an experimental fs, I have
> backups, tho the dual-device raid1 mode I'm using is /reasonably/ stable,
> now.  I switched to btrfs when I upgraded to ssd, both for the ssd
> support and for checksummed data/metadata with a second copy to retrieve
> from if the first fails the checksum.
>
> [2] I tried with a btrfs raid1 and could mount either device with root=
> and rootflags=degraded, so it was definitely parsing rootflags, but no
> way was it taking rootflags=device= to mount them undegraded without a
> userspace btrfs device scan first, and that requires an initr*.  Maybe it
> was a problem with the kernel splitting at the second = instead of the
> first, I don't know, but it definitely wasn't working.  So now I'm
> running dracut with several of its default modules stripped via
> INSTALL_MASK including the one pulling in kmod since I'm running
> monolithic kernel and have kmod package.provided, and USE=btrfs plus
> adding it to the module config.
>

If you just want a minimal initramfs that calls btrfs scan on boot
without hacking the crap out of dracut, feel free to use my little
homegrown project. Just adjust the paths, make sure your busybox is
static, and you should be good to go.

https://bitbucket.org/floppym/initramfs/src

[gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Duncan]

Mike Gilbert posted on Fri, 02 Aug 2013 10:32:10 -0400 as excerpted:

> On Fri, Aug 2, 2013 at 8:06 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Steven J. Long posted...
>>> you only really need an initramfs if [...]
>> 
>> Or, unfortunately, for root on mult-device btrfs, since the usual
>> kernel commandline rootflags=device=/dev/whatever doesn't seem to work
>> for some reason.
>>
> Passing rootflags=device= is a little fragile anyway, since it depends
> on the kernel detecting your devices in a certain order. Having a
> multi-device btrfs root without an initramfs is asking for trouble.

Well, yes and no.  Pre-btrfs I used kernel commandline assembled mdraid 
with initr*less root on top of it for years.  As I posted to the btrfs 
list when someone made the same argument, on my hardware anyway, /dev/sd* 
bring-up order is known stable for a particular kernel as long as I don't 
go changing the physical hardware or plugging. and if a new kernel ever 
changes that or I change the physical hardware, I can either drop to 
grub's commandline (grub2 here, but grub1 works too, with a bit more 
difficulty) and scan, then enter the new devices I need, or boot the old 
kernel and reconfigure as necessary.

IOW, depending on the existing stable scan order with a known and 
demonstrated ability to adapt to changing scan order if it happens, is 
definitely no MORE fragile or asking for trouble (and arguably rather 
less so), than running and dynamically adapting to pre-release brokenness 
in for example the live-git kernels I'm running most of the time, or the 
live-git openrc-9999 I run, because I've found it easier to troubleshoot 
a couple commits at a time while using the additional information git 
whatchanged provides, than to effectively operate blind, with far less 
information and far more commits stacked up that the problem could be in 
when I DO find one if I simply follow regular releases.

> If you just want a minimal initramfs that calls btrfs scan on boot
> without hacking the crap out of dracut, feel free to use my little
> homegrown project. Just adjust the paths, make sure your busybox is
> static, and you should be good to go.
> 
> https://bitbucket.org/floppym/initramfs/src

Thanks, but...

I don't even have busybox installed[1] nor am I really familiar with it, 
tho I've probably used it in embedded context a few times without knowing 
it.  So hacking on dracut probably /is/ easier for me, here, especially 
since I already have that working.

But I've personally found replies nominally aimed at someone else useful 
enough often enough, that I believe chances are quite high someone else 
reading will find it useful, and indeed, I myself may find it 
instructional if I ever decide to hack up my own initr* lite, as I've 
thought about doing, so thanks, indeed. =:^)

---
[1] Busybox not installed:  Back in 2004 when I setup my first gentoo 
system, there was some bug that prevented busybox compilation, so I 
simply package.provided it and continued, thinking I'd get back to that 
later.  I did try it a couple times later without success, by that time I 
realized I didn't really need it since I use an operation system snapshot 
partition as both an emergency recovery method and backup and thus don't 
really need an additional tool such as busybox, so I really didn't have a 
lot of motivation to fix the problem, and probably last tried building 
busybox 7+ years ago, now.

These days of course I have an entirely empty @system, negating the 
entries in the cascading profile one by one and adding entries to one of 
the sets listed in world-sets instead where necessary, triggered as an 
effort to make portage's parallel build process more efficient since it 
serializes @system package and dependencies builds (and an empty @system 
really does help with that).  So for all I know busybox isn't even in the 
default @system any more, but in any case I no longer have to 
package.provide it. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Samuli Suominen]

Picked random mail from this thread.

So, I've seen many people raising intrest in keeping IUSE="static" in 
cryptsetup and lvm2 but I haven't really seen anyone working on it yet, 
except _AxS_ committed one patch but that isn't enough.

Take eg. http://bugs.gentoo.org/show_bug.cgi?id=472692#c4

The user raised very valid question in the bug... The current answer 
seems to be "Nobody maintains this package for static linking, sorry."

So I'll be removing IUSE=static from said packages if they still fail 
after week or so, like they do today and have for past months.

- Samuli

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/07/13 04:42 AM, Samuli Suominen wrote:
> 
> cryptsetup upstream installed minimal Gentoo setup and tested our 
> handling of 'static' and was disappointed finding them broken
> 
> https://bugs.gentoo.org/show_bug.cgi?id=438998 - RESO/TEST -
> cryptsetup static+pcre fails (fixed via resolution of bug 439414)
> 
> https://bugs.gentoo.org/show_bug.cgi?id=468400 - RESO/TEST -
> cryptsetup static+selinux fails (fixed via resolution of bug
> 439414)
> 
> https://bugs.gentoo.org/show_bug.cgi?id=472692 - RESO/FIXED -
> cryptsetup static+ssl fails (note, only cryptsetup-1.6.1 fixed, so
> this should get pushed stable)
> 
> https://bugs.gentoo.org/show_bug.cgi?id=462908 - RESO/FIXED - lvm2
> static-libs missing library
> 
> https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE
> flag missing proper description, yes this is minor
> 
> https://bugs.gentoo.org/show_bug.cgi?id=370217 - RESO/FIXED - lvm2
> fails to build due to missing -lrt, likely related to linking
> against libudev, yes the feature we are discussing to be dropped
> has been completely broken for ages
> 
> https://bugs.gentoo.org/show_bug.cgi?id=439414 - RESO/FIXED - lvm2
> static+selinux fails
> 

So dropping IUSE="static" becomes a no-op now, right?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlIBWb8ACgkQ2ugaI38ACPC44gD8CMJO4AdXLL1SWXPxhd4UBBsL
IJ4pl3zYgCCKrqS0jrcA/0geqa/gf0KTotkE0BqEeHm39pfr7VeEahKArSe8G9zE
=bpUn
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/08/13 04:17 PM, Ian Stakenvicius wrote:
> On 30/07/13 04:42 AM, Samuli Suominen wrote:
> 
>> cryptsetup upstream installed minimal Gentoo setup and tested our
>>  handling of 'static' and was disappointed finding them broken
> 
>> https://bugs.gentoo.org/show_bug.cgi?id=438998 - RESO/TEST - 
>> cryptsetup static+pcre fails (fixed via resolution of bug
>> 439414)
> 
>> https://bugs.gentoo.org/show_bug.cgi?id=468400 - RESO/TEST - 
>> cryptsetup static+selinux fails (fixed via resolution of bug 
>> 439414)
> 
>> https://bugs.gentoo.org/show_bug.cgi?id=472692 - RESO/FIXED - 
>> cryptsetup static+ssl fails (note, only cryptsetup-1.6.1 fixed,
>> so this should get pushed stable)
> 
>> https://bugs.gentoo.org/show_bug.cgi?id=462908 - RESO/FIXED -
>> lvm2 static-libs missing library
> 
>> https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE 
>> flag missing proper description, yes this is minor
> 
>> https://bugs.gentoo.org/show_bug.cgi?id=370217 - RESO/FIXED -
>> lvm2 fails to build due to missing -lrt, likely related to
>> linking against libudev, yes the feature we are discussing to be
>> dropped has been completely broken for ages
> 
>> https://bugs.gentoo.org/show_bug.cgi?id=439414 - RESO/FIXED -
>> lvm2 static+selinux fails
> 
> 
> So dropping IUSE="static" becomes a no-op now, right?
> 


It should also be noted that these bugs really boiled down to 2-3
changes that were quite trivial to fix.  It is quite unfortunate that
nobody had put the time in to figure them out and fix them, though.
IUSE="static" support is really not that broken, but we certainly need
to step up in addressing bugs like these (and others) instead of
letting them sit and fester for months.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlIBXZkACgkQ2ugaI38ACPBelAD+OLi+EC2pjfe2wGNkvbIL96YG
U3BmlMxHTj8OYKHUNXkBAJoHlriZmdTFClf0RYNpll1206rt0fnl9dl0gc7XUukS
=0bEa
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

01.08.2013 21:50, Pacho Ramos пишет:
> El jue, 01-08-2013 a las 14:05 +0400, Sergey Popov escribió:
> [...]
>> Some cluster things in lvm does not work in mine setup with shared
>> builds. Only USE="static static-libs" is only working combination.
>> Something related with cluster file locking library - it does not load
>> if it is build shared. Probably i should file bugreport about this
>>
> 
> You certainly should report it as looks like we are the only downstream
> willing to still keep that option and, once upstream has dropped it and
> people from other distributions won't likely help us fixing the bugs,
> would be better to try to fix it (in a long term perspective)
> 
> 

I have time(at last!) to check with new stable lvm/udev. All things are
fine without static and static-libs USEs. Do not know, what is changed,
probably this was some fault from my side :-/

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]