[gentoo-dev] Base profile changes should be announced/discussed on this list.
Mostly everything is configurable, and revertable as user - granted. I'd like to see a announcement and an optional discussion on this list if base profile gets changed [0] - current case bug 449364 [1]. I'm not opposed to the specific change, or base system changes in general, but I don't like seeing them slip thru under the radar. Just have the honesty and brin gsuch changes to public. [In this case] having an working mouse copy'n'paste eases the way from stage3 to a set up X server, X server tends to break, and it doesn't collide with X anymore. So it only needs 1MB data [2], which is very usefull editing stage3 with it's default editor - nano. I see the point that's it's useless on headless virtual boxes. my 2 cents. [0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/releases/make.defaults?r1=1.4r2=1.5 [1] https://bugs.gentoo.org/449364 [2] michael@x ~ % equery size gpm * sys-libs/gpm-1.20.6 Total files : 55 Total size : 890.25 KiB -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2013 06:54 PM, Diego Elio Pettenò wrote: Because it would require us to change a whole load more than just the targets variable. This is sort of the same for PHP. We need to know the major and minor version based on the flag value. We technically could assume that major version would be one digit and the rest would be the minor version, but didn't feel quite right to unnecessary remove information from the variables and then try to hack it back in again. I don't really care what the separator is. The reason I chose dash for separation major/minor version was simply to distinguish between the value and variable part of USE_EXPAND. Just seemed natural at the time. The last time this discussion came up I offered to change the grammar, but people did not seem to care enough for me to send all PHP users through the hassle. I am also not quite sure how to change the grammar in a clean way. - -- Ole Markus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR+L7oAAoJEGurSuXEqSv1uesH/1NOpI/VN+F4HlZuX9aokh8G a2ycgHIQ+wdtoc3onIRqncJ8TRBZ610HGnim8e/70tsj0JkVGFEM5wuSC93m6nHi 3Uh4wX01LazdW5KnTlv4Pe2zKsfXwCO+mXvwXtrouUmhIhMzT8sP57kTr0cTeRsB V+N1EWZjE16Tz5z/l9+9hcd3uUhRtdDYSRa5msGp5y2vBz/CwG4JKSUBlp6q57aK 82ZeTqONh8B1PyNKFTDYw2MFkKoan5eRLqUChEgD/aiyOoejXWESjCGyhpjn5UvN WAEolV0NpW6ktZp8muMo0BxdLoI3Nmm/x8Ddbxgn65ISCNvC31lf0nn7auHNaPU= =H9Er -END PGP SIGNATURE-
Re: [gentoo-dev] Base profile changes should be announced/discussed on this list.
On Wed, Jul 31, 2013 at 8:21 AM, Michael Weber x...@gentoo.org wrote: I'd like to see a announcement and an optional discussion on this list if base profile gets changed [0] - current case bug 449364 [1]. I think that makes a lot of sense as a guideline. To me, it's a bit weird to change a USE flag default for everyone based on a discussion on the release team only. Cheers, Dirkjan
Re: [gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dnia 2013-07-31, o godz. 09:38:20 Ole Markus With olemar...@olemarkus.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2013 06:54 PM, Diego Elio Pettenò wrote: Because it would require us to change a whole load more than just the targets variable. This is sort of the same for PHP. We need to know the major and minor version based on the flag value. We technically could assume that major version would be one digit and the rest would be the minor version, but didn't feel quite right to unnecessary remove information from the variables and then try to hack it back in again. Well, I think the specific difference here is that ruby executables are named 'ruby18', 'ruby19' and that fits RUBY_TARGETS. Python executables have version separator in them so that makes dropping it at least inconsistent. - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJR+MpMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKab4P/2Ywho7CYuA1mo8eBuUPn24W 4LDLoavG44CLLeK2CS9TGk85JkpUyHCUY+X3Wx12VY/+itRmLS+vaLi0hwnS7BEA j9uU+4+MUc7EjoWPeq04trfbATQCon8FqQMdjuZkJs+fULrZfXG+4kjeR6vmmuXW l9zSEKuR8JxcSe5pcNk0cPEPX1EVwq62/o6xDhfXxP3k18/+w1XW1Fq7k3xgqohz XNk0xU6xTDurYAxroJfTiO1s8hldGIz3zGJODjOPTU5jzQQcCDe9uYg9yyT7WTCZ dYkPU3Xw1dQfQWxzKXuY4rkk+hAH94Njb4AkGV8j0BKps0R9GnuzM1YQuH53G+cL ihkCeypCiwc0GL7B4aSKLxI28S1fI+AxXvSv+X2DG1rWGUvgMTe+b4U+Ppedxx6j ozAXspkisBXy6V416ErSjqEuuZzhbsc2n9SKcohHSipzUUmgHoc9v/o7ppJXrqNb 1nNBUTO1BpO7h7Zk1UurZLUP/eHJTRZAmMZRd4uMAcGrwx2nmmtGGyf+KqXtVf+/ 6f6+VMbY9nzf2ofO7yHkvjkxvcJG3BtqOEXTw7Xe0OOJ5PY+iBn7mRqZjpcnUyMw KjuK6AjH62rTjfen/N8A6VbkS3sj7VMj5rSe6DwsJNxgKks27E3r7jk0Oz7Q5Gmu 8ngo89Rcqv+YeluommPp =ufaE -END PGP SIGNATURE-
Re: [gentoo-dev] Base profile changes should be announced/discussed on this list.
On Wed, Jul 31, 2013 at 08:21:20AM +0200, Michael Weber wrote Mostly everything is configurable, and revertable as user - granted. I'd like to see a announcement and an optional discussion on this list if base profile gets changed [0] - current case bug 449364 [1]. I'm not opposed to the specific change, or base system changes in general, but I don't like seeing them slip thru under the radar. Just have the honesty and brin gsuch changes to public. [In this case] having an working mouse copy'n'paste eases the way from stage3 to a set up X server, X server tends to break, and it doesn't collide with X anymore. So it only needs 1MB data [2], which is very usefull editing stage3 with it's default editor - nano. I see the point that's it's useless on headless virtual boxes. my 2 cents. Hold on a minute. There is a *MAJOR* difference between gpm the USE flag, and sys-libs/gpm the mouse server. I'm one of those weird guys who starts USE with -*. And I do not have gpm the USE flag enabled. I do, however, have sys-libs/gpm running just fine, thank you, minus the gpm flag. I can assure you that gpm works just fine during the install, even without the gpm flag. I see the point that's it's useless on headless virtual boxes Actually, if you ssh into the virtual box from a text console, it still works. If there was a move afoot to remove sys-libs/gpm from the install ISO, I would be part of the crowd up in arms about this. But that's totally a separate item from the USE flag. Since I've never used the gpm USE flag, I have to ask... what additional goodies does USE=gpm bring to the table? How exactly, does it improve things beyond the basic sys-libs/gpm? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-dev] New eclass: db-use-r1
Hi list, I'd like to propose a new eclass db-use-r1 [1]. While working on the dev-libs/Ice package I found it to fail with sys- libs/db:6.0 (see [2]) and I have found no way to use current db-use.eclass to make Ice compile against an older sys-libs/db slot if db:6.0 is installed. So I'd like to ask for a review of the new eclass which has a few important changes compared to the old db-use.eclass: - It requires ebuilds using the eclass to define DB_VERSIONS variable - It provides avariable DB_DEPEND containing all possible db:slot versions a package can use - db_findver() no longer blindly returns latest installed sys-libs/db version. it now returns the best version from DB_VERSIONS if any is installed. I'd like to commit this eclass into portage in about a week if no veto appears. Thanks Lars [1] http://dev.gentoo.org/~polynomial-c/db-use-r1.eclass [2] https://bugs.gentoo.org/476378 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Base profile changes should be announced/discussed on this list.
On 07/31/2013 11:53 AM, Walter Dnes wrote: Hold on a minute. There is a *MAJOR* difference between gpm the USE flag, and sys-libs/gpm the mouse server. [...] If there was a move afoot to remove sys-libs/gpm from the install ISO, I would be part of the crowd up in arms about this. It does affect the presence of sys-libs/gpm in stage3 tarballs. It gets pulled into stage3 via sys-libs/ncurses[gpm] [1]. Which will no longer be the case, since sys-libs/gpm is not in @system. About additional effects, see [2]. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-libs/ncurses/ncurses-5.9-r2.ebuild?revision=1.17view=markup [2] michael@x catalyst 1 % equery hasuse gpm * Searching for USE flag gpm ... [IP-] [ ] app-editors/emacs-24.3-r2:24 [IP-] [ ] app-editors/gvim-7.3.1214:0 [IP-] [ ] app-editors/vim-7.3.1214:0 [IP-] [ ] app-misc/mc-4.8.7:0 [IP-] [ ] media-libs/aalib-1.4_rc5:0 [IP-] [ ] sys-libs/ncurses-5.9-r2:5 [IP-] [ ] www-client/elinks-0.12_pre5-r2:0 [IP-] [ ] www-client/links-2.7:2 [IP-] [ ] www-client/w3m-0.5.3-r1:0 -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] Adding ABI_MIPS USE_EXPAND
On Tue, 30 Jul 2013 09:04:56 -0700 Matt Turner matts...@gentoo.org wrote: I committed it last night before your email. # Keep it sorted. Please do not add anything without prior discussion # on gentoo-dev. n32 n64 o32 This is not a valid format for a .desc file. You should use: flag - description jer
Re: [gentoo-dev] Base profile changes should be announced/discussed on this list.
On Wed, Jul 31, 2013 at 5:53 AM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Jul 31, 2013 at 08:21:20AM +0200, Michael Weber wrote Mostly everything is configurable, and revertable as user - granted. I'd like to see a announcement and an optional discussion on this list if base profile gets changed [0] - current case bug 449364 [1]. I'm not opposed to the specific change, or base system changes in general, but I don't like seeing them slip thru under the radar. Just have the honesty and brin gsuch changes to public. [In this case] having an working mouse copy'n'paste eases the way from stage3 to a set up X server, X server tends to break, and it doesn't collide with X anymore. So it only needs 1MB data [2], which is very usefull editing stage3 with it's default editor - nano. I see the point that's it's useless on headless virtual boxes. my 2 cents. Hold on a minute. There is a *MAJOR* difference between gpm the USE flag, and sys-libs/gpm the mouse server. I'm one of those weird guys who starts USE with -*. And I do not have gpm the USE flag enabled. I do, however, have sys-libs/gpm running just fine, thank you, minus the gpm flag. I can assure you that gpm works just fine during the install, even without the gpm flag. I see the point that's it's useless on headless virtual boxes Actually, if you ssh into the virtual box from a text console, it still works. If there was a move afoot to remove sys-libs/gpm from the install ISO, I would be part of the crowd up in arms about this. But that's totally a separate item from the USE flag. Since I've never used the gpm USE flag, I have to ask... what additional goodies does USE=gpm bring to the table? How exactly, does it improve things beyond the basic sys-libs/gpm? For most packages, USE=gpm builds them with the gpm library, which generally allows the built program to have the same mouse support on console as it does in an X environment. For example, with vim and USE=X, do ':set mouse=a', and you can use the mouse to navigate and do selections while in X. If you add USE=gpm, you can do the same things in the console environment, which is really handy if you haven't yet mastered vim's myriad of movement commands. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications -Doug
[gentoo-dev] Re: Base profile changes should be announced/discussed on this list.
Walter Dnes posted on Wed, 31 Jul 2013 05:53:50 -0400 as excerpted: Hold on a minute. There is a *MAJOR* difference between gpm the USE flag, and sys-libs/gpm the mouse server. I'm one of those weird guys who starts USE with -*. aolMe too./aol And I do not have gpm the USE flag enabled. It's enabled here. I do, however, have sys-libs/gpm running just fine, thank you, minus the gpm flag. Good point. If there was a move afoot to remove sys-libs/gpm from the install ISO, I would be part of the crowd up in arms about this. But that's totally a separate item from the USE flag. += Since I've never used the gpm USE flag, I have to ask... what additional goodies does USE=gpm bring to the table? How exactly, does it improve things beyond the basic sys-libs/gpm? equery hasuse gpm ... will tell you what packages on your system have the gpm USE flag. For me: [IP-] [ ] app-misc/mc-4.8.9:0 [IP-] [ ] sys-libs/ncurses-5.9-r2:5 [IP-] [ ] www-client/links-2.7:2 It's certainly useful in mc, the reason I keep it on. In links it's nice but I'm used to keyboard navigation, so it's no big deal. I don't know what ncurses-based apps (other than links and mc) use it, but it has never caused me a problem, so... So viewed from here, heavy mc users probably want it on, but for most others it's probably meh... Which means the base profile USE flag change is arguably worthwhile. Anything that really needs the flag will be (re)installed later anyway, after people setup their own USE flags, and while I don't use the gentoo liveCD enough to have a real valid opinion on it, I doubt there's much either there or in the stage3 that really needs the flag on. As you mention, having the actual package on the install medium remains useful, but that's an entirely separate question from what the USE flag default should be. -- 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] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
On Wed, Jul 31, 2013 at 3:38 AM, Ole Markus With olemar...@olemarkus.org wrote: I don't really care what the separator is. The reason I chose dash for separation major/minor version was simply to distinguish between the value and variable part of USE_EXPAND. Just seemed natural at the time. I think a hyphen/dash would have been a better choice for python as well, but it's a bit late to change that now. If someone has a way to do it without causing a lot of work and breaking people's systems, I would love to hear it.
[gentoo-dev] Re: s/disk space/drive space
Jeroen Roovers j...@gentoo.org writes: Also, drive space would be dead wrong. A drive[1] is a device which holds a storage medium (often a disk, as in, you know, a disk drive). Solid-state drive is even more confusing than solid-state disk (and both are common parlance). In the interest of linguistic accuracy, maybe solid state drives should be referred to as solid state data depositories. That would overload one of my favorite acronyms. -- Chris
Re: [gentoo-dev] s/disk space/drive space
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/07/13 10:53 AM, Rich Freeman wrote: On Tue, Jul 30, 2013 at 10:40 AM, viv...@gmail.com viv...@gmail.com wrote: does storage space make everyone happy? rich0 is confused and looks over at the storage space he keeps his bicycles in... 'filesystem space' would be the most correct technical term, I think - -- unless you're talking about partitioning or making/growing filesystems, chance are it's the filesystem that's running out of space, not the pyhsical (or virtual) layer underneath... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlH5N0kACgkQ2ugaI38ACPDFWQD/ShcsBoN46Lt93kgawdhFgk2E um0J6dG6QkSMnhsJoosA/3Q8rahq/mQLNBfHMeL2hQEG8VnPRB/K11WKu20+ldWl =YO21 -END PGP SIGNATURE-
Re: [gentoo-dev] Adding ABI_MIPS USE_EXPAND
On Wed, Jul 31, 2013 at 5:12 AM, Jeroen Roovers j...@gentoo.org wrote: On Tue, 30 Jul 2013 09:04:56 -0700 Matt Turner matts...@gentoo.org wrote: I committed it last night before your email. # Keep it sorted. Please do not add anything without prior discussion # on gentoo-dev. n32 n64 o32 This is not a valid format for a .desc file. You should use: flag - description Indeed, you are right. I'll add descriptions. Thanks for noticing. Matt
[gentoo-dev] How to know packages providing files under some directory
I would like to know if there is any kind of DB to check for packages providing files under a directory. Does any exist? Thanks
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)
Re: [gentoo-dev] How to know packages providing files under some directory
On 07/31/2013 12:03 PM, Pacho Ramos wrote: I would like to know if there is any kind of DB to check for packages providing files under a directory. Does any exist? portageq owners / /path/to/directory -- Thanks, Zac
Re: [gentoo-dev] How to know packages providing files under some directory
El mié, 31-07-2013 a las 12:11 -0700, Zac Medico escribió: On 07/31/2013 12:03 PM, Pacho Ramos wrote: I would like to know if there is any kind of DB to check for packages providing files under a directory. Does any exist? portageq owners / /path/to/directory But, doesn't it force me to try to merge all packages in the tree?
Re: [gentoo-dev] How to know packages providing files under some directory
On Wed, Jul 31, 2013 at 3:17 PM, Pacho Ramos pa...@gentoo.org wrote: El mié, 31-07-2013 a las 12:11 -0700, Zac Medico escribió: On 07/31/2013 12:03 PM, Pacho Ramos wrote: I would like to know if there is any kind of DB to check for packages providing files under a directory. Does any exist? portageq owners / /path/to/directory But, doesn't it force me to try to merge all packages in the tree? http://www.portagefilelist.de And related package app-portage/pfl
Re: [gentoo-dev] How to know packages providing files under some directory
El mié, 31-07-2013 a las 15:19 -0400, Mike Gilbert escribió: On Wed, Jul 31, 2013 at 3:17 PM, Pacho Ramos pa...@gentoo.org wrote: El mié, 31-07-2013 a las 12:11 -0700, Zac Medico escribió: On 07/31/2013 12:03 PM, Pacho Ramos wrote: I would like to know if there is any kind of DB to check for packages providing files under a directory. Does any exist? portageq owners / /path/to/directory But, doesn't it force me to try to merge all packages in the tree? http://www.portagefilelist.de And related package app-portage/pfl But looks like it lets me find exact files, not directories (Anyway thanks for the info, didn't know it)
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 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] Base profile changes should be announced/discussed on this list.
On Wed, Jul 31, 2013 at 12:58:37PM +0200, Michael Weber wrote On 07/31/2013 11:53 AM, Walter Dnes wrote: Hold on a minute. There is a *MAJOR* difference between gpm the USE flag, and sys-libs/gpm the mouse server. [...] If there was a move afoot to remove sys-libs/gpm from the install ISO, I would be part of the crowd up in arms about this. It does affect the presence of sys-libs/gpm in stage3 tarballs. It gets pulled into stage3 via sys-libs/ncurses[gpm] [1]. Which will no longer be the case, since sys-libs/gpm is not in @system. About additional effects, see [2]. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-libs/ncurses/ncurses-5.9-r2.ebuild?revision=1.17view=markup [2] michael@x catalyst 1 % equery hasuse gpm * Searching for USE flag gpm ... [IP-] [ ] app-editors/emacs-24.3-r2:24 [IP-] [ ] app-editors/gvim-7.3.1214:0 [IP-] [ ] app-editors/vim-7.3.1214:0 [IP-] [ ] app-misc/mc-4.8.7:0 [IP-] [ ] media-libs/aalib-1.4_rc5:0 [IP-] [ ] sys-libs/ncurses-5.9-r2:5 [IP-] [ ] www-client/elinks-0.12_pre5-r2:0 [IP-] [ ] www-client/links-2.7:2 [IP-] [ ] www-client/w3m-0.5.3-r1:0 -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Base profile changes should be announced/discussed on this list.
On Wed, Jul 31, 2013 at 12:58:37PM +0200, Michael Weber wrote On 07/31/2013 11:53 AM, Walter Dnes wrote: Hold on a minute. There is a *MAJOR* difference between gpm the USE flag, and sys-libs/gpm the mouse server. [...] If there was a move afoot to remove sys-libs/gpm from the install ISO, I would be part of the crowd up in arms about this. It does affect the presence of sys-libs/gpm in stage3 tarballs. It gets pulled into stage3 via sys-libs/ncurses[gpm] [1]. Which will no longer be the case, since sys-libs/gpm is not in @system. Arrrgh; I apologize for that fumble-fingers moment. I think I just sent an unfinished message. What I was going to say was that gpm appears to be active on the minimal install ISO. That comes before the stage tarball. Or is the proposal to remove gpm altogether from the install ISO? I would be unhappy with that, to say the least. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
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
On Wed, Jul 31, 2013 at 10:03 PM, William Hubbs willi...@gentoo.org 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 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, 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 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, 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
