Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
-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
-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
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
[gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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.dun...@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- 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
On Fri, Aug 2, 2013 at 7:31 AM, Steven J. Long 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
[gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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
[gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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 ;-)
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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
Dnia 2013-08-01, o godz. 23:03:11 Luca Barbato 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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
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
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 napisał(a): > > > On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny wrote: > > > Dnia 2013-08-01, o godz. 17:17:35 > > > Luca Barbato 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 signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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
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
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
Dnia 2013-08-01, o godz. 13:32:28 Rich Freeman napisał(a): > On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny wrote: > > Dnia 2013-08-01, o godz. 17:17:35 > > Luca Barbato 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny wrote: > Dnia 2013-08-01, o godz. 17:17:35 > Luca Barbato 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
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
Dnia 2013-08-01, o godz. 17:17:35 Luca Barbato 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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
On Thu, Aug 01, 2013 at 06:01:50AM -0400, Rich Freeman wrote: > On Wed, Jul 31, 2013 at 11:38 PM, William Hubbs 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 signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
01.08.2013 01:01, Pacho Ramos пишет: > El mié, 31-07-2013 a las 19:42 +, 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
On Wed, Jul 31, 2013 at 11:38 PM, William Hubbs 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
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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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 +, 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 signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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
On 01/08/13 04:03, William Hubbs wrote: > On Wed, Jul 31, 2013 at 07:42:26PM +, 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
On Wed, Jul 31, 2013 at 10:03 PM, William Hubbs wrote: > On Wed, Jul 31, 2013 at 07:42:26PM +, 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
On Wed, Jul 31, 2013 at 07:42:26PM +, 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 signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
El mié, 31-07-2013 a las 19:42 +, 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
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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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)
[gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
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
