[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

[Rich Freeman]

On Mon, Jul 29, 2013 at 4:57 PM, Pacho Ramos <pa...@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

[Francesco Riosa]

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

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

[Pacho Ramos]

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? :/

[yac]

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

[Matt Turner]

On Mon, Jul 29, 2013 at 5:28 PM, yac <y...@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.

[Dustin C. Hatch]

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/

[Rich Freeman]

On Mon, Jul 29, 2013 at 9:01 PM, Dustin C. Hatch <admir...@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

[Dustin C. Hatch]

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/

[William Hubbs]

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

[Pacho Ramos]

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

[Samuli Suominen]

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

[Pacho Ramos]

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

[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�:

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

[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:

[William Hubbs]

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

[Rich Freeman]

On Wed, Jul 31, 2013 at 10:03 PM, William Hubbs <will...@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

[Luca Barbato]

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

[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.

[William Hubbs]

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

Thanks,

William

[William Hubbs]

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

[Pacho Ramos]

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

[Sergey Popov]

01.08.2013 01:01, Pacho Ramos пишет:

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

[Rich Freeman]

On Wed, Jul 31, 2013 at 11:38 PM, William Hubbs <will...@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

[William Hubbs]

On Thu, Aug 01, 2013 at 06:01:50AM -0400, Rich Freeman wrote:
> On Wed, Jul 31, 2013 at 11:38 PM, William Hubbs <will...@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

[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

[Michał Górny]

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

So esystemd and ekmod now?

--
Best regards,
Michał Górny

[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

[Michał Górny]

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

> On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny <mgo...@gentoo.org> wrote:
> > Dnia 2013-08-01, o godz. 17:17:35
> > Luca Barbato <lu_...@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.

[Rich Freeman]

On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny <mgo...@gentoo.org> wrote:

> Dnia 2013-08-01, o godz. 17:17:35
> Luca Barbato <lu_...@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

[Pacho Ramos]

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

[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)

[William Hubbs]

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

[Samuli Suominen]

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

[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

[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

[Michał Górny]

Dnia 2013-08-01, o godz. 23:03:11
Luca Barbato <lu_...@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...

[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

[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

[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 ;-)

[Rich Freeman]

On Fri, Aug 2, 2013 at 7:31 AM, Steven J. Long
<sl...@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

[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

[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-----

[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-----

[Sergey Popov]

01.08.2013 21:50, Pacho Ramos пишет:

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