Re: [gentoo-dev] New virtuals for libudev and libgudev
Dnia 2014-03-28, o godz. 19:53:07
Rich Freeman ri...@gentoo.org napisał(a):
On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
All in all, this isn't a bad idea on the surface, but the first
arguement shows immediately when this is scaled up. How many other
packages have multiple libs with different sonames? Off hand, I can
think of poplar, but I'm sure there must be more. Is it really
scalable, desirable, or sane, to break each package on the system into
multiple different virtuals like this?
Clever idea, actually, though I'd be interested in whether anybody
else can think of any unintended consequences.
I agree that there could end up being many cases of this, but that
really just amounts to clutter, and more granular dependencies (which
also make me think that a next step could actually be packages that
only install the necessary libraries, and somehow controlling this by
dependencies rather than USE flags which are a bit more cumbersome).
This is the other side of this. People already requested libudev
without whole udev, and this is a way of allowing it in the future.
There really isn't anything special about virtual packages other than
the fact that they don't install anything. I wonder if it would make
sense to actually create a new category for virtuals that only exist
to express library dependencies. Functionally it would be no
different, but it would split up the namespace so that we don't have
an additional 193 packages in the virtual category. Plus, when
looking at ebuilds it will be a bit more clear what each dependency is
actually pulling in.
I have already suggested separate category for perl virtuals but been
quieted down at the time. I doubt people really want another category
for virtuals since some of their poor tools rely on 'virtual/'.
One thing you didn't mention in your email is the interaction with
conventional virtuals. The dep string for libudev reads:
RDEPEND=
|| (
=sys-fs/udev-208:0/0[${MULTILIB_USEDEP},static-libs?]
=sys-apps/systemd-208:0/2[${MULTILIB_USEDEP},static-libs(-)?]
=sys-apps/systemd-208:0/1[${MULTILIB_USEDEP},static-libs(-)?]
=sys-apps/systemd-208:0/0[${MULTILIB_USEDEP},static-libs(-)?]
=sys-fs/eudev-1.3:0/0[${MULTILIB_USEDEP},static-libs?]
)
What happens if eudev-209 and udev-209 don't bundle the sane SONAME
for libudev, and thus need different subslots? The virtual libudev is
versioned 208.
There's an exact subslot dep in there (:M/N). If either of them changes
SONAME of any of the libraries, the provider subslot is bumped
and the virtual no longer matches it.
The systemd deps are a good example of that. The subslots 0, 1 and 2
correspond to changes in libsystemd.so. Now, if any of SONAMES
in systemd change, it will have subslot 3 and the virtual will no
longer match. If it's libudev or libgudev changing, we'd introduce
a new version (subslot) of the virtual; otherwise, a new revision with
systemd:0/3 added.
In fact, the versions are not even really necessary there.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 WRT to but 504616 I'd like to address my questions made in https://bugs.gentoo.org/show_bug.cgi?id=504616#c6 to this list again : Since the Debian debakel with fixing an uninitialized memeory I'm very skeptical to distribution specific corrections which are not included upstream. At least I'm wondering if the USE flag hpn should be enabled by the user explicitely - currently it is in IUSE already. - -- MfG/Sincerely Toralf Förster pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlM2m1kACgkQxOrN3gB26U4q+AD9EDAhx1aPXxu7kaHA80Dskyol 5ha1qFBG1b9Hx2Lcp/MBAI1T6VEjok7qXbOw50f4EFmGMJOOhsO+fcNcHq+a3hYY =/RPN -END PGP SIGNATURE-
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
On 29/03/14 06:07 AM, Toralf Förster wrote: WRT to but 504616 I'd like to address my questions made in https://bugs.gentoo.org/show_bug.cgi?id=504616#c6 to this list again : Since the Debian debakel with fixing an uninitialized memeory I'm very skeptical to distribution specific corrections which are not included upstream. At least I'm wondering if the USE flag hpn should be enabled by the user explicitely - currently it is in IUSE already. 1. Please use a spelling checker. 2. IUSE doesn't mean what you think it means. http://devmanual.gentoo.org/quickstart/#ebuild-with-use-flags signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New virtuals for libudev and libgudev
On 03/28/2014 07:53 PM, Rich Freeman wrote: On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: All in all, this isn't a bad idea on the surface, but the first arguement shows immediately when this is scaled up. How many other packages have multiple libs with different sonames? Off hand, I can think of poplar, but I'm sure there must be more. Is it really scalable, desirable, or sane, to break each package on the system into multiple different virtuals like this? Clever idea, actually, though I'd be interested in whether anybody else can think of any unintended consequences. My objection to what happened with the introduction of these virtuals was that they directly affected eudev and yet the eudev team was not consulted. The question of unintended consequences is precisely why design decisions should be discussed on this list. The following bug shows who was invovled in the discussion: https://bugs.gentoo.org/show_bug.cgi?id=506034. (I just added the eudev team but it was not there until just now.) We now face similar design idiosyncrasies with respect to a request that ABI information be included in CHOSTs for MIPS which does not conform to gnuconfig standards. To avoid engineering ourselves into corners, we really need to have as many smart people looking at a design change as possible before it is implemented, not after. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] New virtuals for libudev and libgudev
On Sat, Mar 29, 2014 at 4:34 AM, Michał Górny mgo...@gentoo.org wrote: I have already suggested separate category for perl virtuals but been quieted down at the time. I doubt people really want another category for virtuals since some of their poor tools rely on 'virtual/'. So, first the obvious - the poor tools are, well, poor. If we need a way of distinguishing virtual packages it might make sense to add a tag to metadata.xml or such, if not to the ebuilds themselves. Distinguishing by category/name seems like a really bad idea. But, second, if people really want to have tools that treat virtuals in a special way, then it seems likely to me that they'd want to be able to distinguish between traditional virtuals and these new SONAME-driven virtuals. Of course, I'd still advocate doing it with a different tag in metadata.xml/etc and not by doing it with the category when it is a script doing the interpretation. For us mere mortals, having multiple virtual categories might be useful. I can see the argument about perl (though I wouldn't have minded a virtual-perl category), but this is a bit different in that this isn't just another group of packages being virtualized, but a fairly different use of virtual packages entirely. Otherwise, thanks for pointing out the use of subslots in the udev/etc packages themselves. Rich
Re: [gentoo-dev] New virtuals for libudev and libgudev
On 29/03/14 14:30, Anthony G. Basile wrote: On 03/28/2014 07:53 PM, Rich Freeman wrote: On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: All in all, this isn't a bad idea on the surface, but the first arguement shows immediately when this is scaled up. How many other packages have multiple libs with different sonames? Off hand, I can think of poplar, but I'm sure there must be more. Is it really scalable, desirable, or sane, to break each package on the system into multiple different virtuals like this? Clever idea, actually, though I'd be interested in whether anybody else can think of any unintended consequences. My objection to what happened with the introduction of these virtuals was that they directly affected eudev and yet the eudev team was not consulted. eudev developer was contacted before any real impact on tree was made to make an ebuild-only change to build multilib libgudev like udev and systemd does at which point any objections could have been raised, instead, like expected, the version of eudev was provided to move forward, and we did so I don't agree with your assesment of not being consulted, when you were
Re: [gentoo-dev] New virtuals for libudev and libgudev
On 03/29/2014 08:58 AM, Samuli Suominen wrote: On 29/03/14 14:30, Anthony G. Basile wrote: On 03/28/2014 07:53 PM, Rich Freeman wrote: On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: All in all, this isn't a bad idea on the surface, but the first arguement shows immediately when this is scaled up. How many other packages have multiple libs with different sonames? Off hand, I can think of poplar, but I'm sure there must be more. Is it really scalable, desirable, or sane, to break each package on the system into multiple different virtuals like this? Clever idea, actually, though I'd be interested in whether anybody else can think of any unintended consequences. My objection to what happened with the introduction of these virtuals was that they directly affected eudev and yet the eudev team was not consulted. eudev developer was contacted before any real impact on tree was made to make an ebuild-only change to build multilib libgudev like udev and systemd does at which point any objections could have been raised, instead, like expected, the version of eudev was provided to move forward, and we did so I don't agree with your assesment of not being consulted, when you were Not before the decision was made to go ahead with the change. Consulting means input before the decision. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] New virtuals for libudev and libgudev
On 03/29/2014 09:23 AM, Anthony G. Basile wrote: On 03/29/2014 08:58 AM, Samuli Suominen wrote: On 29/03/14 14:30, Anthony G. Basile wrote: On 03/28/2014 07:53 PM, Rich Freeman wrote: On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: All in all, this isn't a bad idea on the surface, but the first arguement shows immediately when this is scaled up. How many other packages have multiple libs with different sonames? Off hand, I can think of poplar, but I'm sure there must be more. Is it really scalable, desirable, or sane, to break each package on the system into multiple different virtuals like this? Clever idea, actually, though I'd be interested in whether anybody else can think of any unintended consequences. My objection to what happened with the introduction of these virtuals was that they directly affected eudev and yet the eudev team was not consulted. eudev developer was contacted before any real impact on tree was made to make an ebuild-only change to build multilib libgudev like udev and systemd does at which point any objections could have been raised, instead, like expected, the version of eudev was provided to move forward, and we did so I don't agree with your assesment of not being consulted, when you were Not before the decision was made to go ahead with the change. Consulting means input before the decision. Following up on this, do you have any objection to me co-maintianing those virtuals? -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] New virtuals for libudev and libgudev
On 29/03/14 15:24, Anthony G. Basile wrote: On 03/29/2014 09:23 AM, Anthony G. Basile wrote: On 03/29/2014 08:58 AM, Samuli Suominen wrote: On 29/03/14 14:30, Anthony G. Basile wrote: On 03/28/2014 07:53 PM, Rich Freeman wrote: On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: All in all, this isn't a bad idea on the surface, but the first arguement shows immediately when this is scaled up. How many other packages have multiple libs with different sonames? Off hand, I can think of poplar, but I'm sure there must be more. Is it really scalable, desirable, or sane, to break each package on the system into multiple different virtuals like this? Clever idea, actually, though I'd be interested in whether anybody else can think of any unintended consequences. My objection to what happened with the introduction of these virtuals was that they directly affected eudev and yet the eudev team was not consulted. eudev developer was contacted before any real impact on tree was made to make an ebuild-only change to build multilib libgudev like udev and systemd does at which point any objections could have been raised, instead, like expected, the version of eudev was provided to move forward, and we did so I don't agree with your assesment of not being consulted, when you were Not before the decision was made to go ahead with the change. Consulting means input before the decision. Following up on this, do you have any objection to me co-maintianing those virtuals? With the inappropiate feedback I got from yesterday from you in #gentoo-dev, I'm not sure you are the best fit for maintaining any of these. However, I suppose both of eu...@gentoo.org and syst...@gentoo.org should still be in metadata.xml of the virtuals as co-maintainers. But it doesn't mean you get to do dramatical changes to them without first discussing it with the main providers maintainers, that is, sys-fs/udev, and WilliamH and me. Dramatical changes, such as unannouncedly reverting others changes, masking them, etc. I shouldn't even be needing to tell any of this, as common sense should prevail, but lately it has been lost, so covering basis. Don't take insult of it. +1 for adding systemd and eudev to metadata.xml
Re: [gentoo-dev] New virtuals for libudev and libgudev
On 03/29/2014 09:33 AM, Samuli Suominen wrote: On 29/03/14 15:24, Anthony G. Basile wrote: On 03/29/2014 09:23 AM, Anthony G. Basile wrote: On 03/29/2014 08:58 AM, Samuli Suominen wrote: On 29/03/14 14:30, Anthony G. Basile wrote: On 03/28/2014 07:53 PM, Rich Freeman wrote: On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: All in all, this isn't a bad idea on the surface, but the first arguement shows immediately when this is scaled up. How many other packages have multiple libs with different sonames? Off hand, I can think of poplar, but I'm sure there must be more. Is it really scalable, desirable, or sane, to break each package on the system into multiple different virtuals like this? Clever idea, actually, though I'd be interested in whether anybody else can think of any unintended consequences. My objection to what happened with the introduction of these virtuals was that they directly affected eudev and yet the eudev team was not consulted. eudev developer was contacted before any real impact on tree was made to make an ebuild-only change to build multilib libgudev like udev and systemd does at which point any objections could have been raised, instead, like expected, the version of eudev was provided to move forward, and we did so I don't agree with your assesment of not being consulted, when you were Not before the decision was made to go ahead with the change. Consulting means input before the decision. Following up on this, do you have any objection to me co-maintianing those virtuals? With the inappropiate feedback I got from yesterday from you in #gentoo-dev, I'm not sure you are the best fit for maintaining any of these. Others have these logs and are better judges of the responses. Let the community read the responses for themselves. However, I suppose both of eu...@gentoo.org and syst...@gentoo.org should still be in metadata.xml of the virtuals as co-maintainers. But it doesn't mean you get to do dramatical changes to them without first discussing it with the main providers maintainers, that is, sys-fs/udev, and WilliamH and me. Dramatical changes, such as unannouncedly reverting others changes, masking them, etc. This implies to the list that I made any changes. I did not touch or mask any of these packages. In fact, I asked you to please look at the eudev ebuilds to make sure they would work with the new virtual structure. Furthermore, I am in favor of discussion. You ask of me precisely what I ask of you. It is a good thing that we discuss these changes together. I shouldn't even be needing to tell any of this, as common sense should prevail, but lately it has been lost, so covering basis. Don't take insult of it. +1 for adding systemd and eudev to metadata.xml Again, let the community judge common sense. If eudev is added, then that means we get to follow these packages as needed. It is not my intention to obstruct what udev and systemd are doing, but to make sure that the eudev ebuilds are not marginalized. As for main providers, there are other distributions that are now adopting eudev such as Linux From Scratch [1] and Crux is considering it [2]. Ref. [1] http://www.linuxfromscratch.org/lfs/view/development/chapter06/eudev.html [2] http://crux.nu/Wiki/TODO31 -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
On Sat, 29 Mar 2014 07:15:14 -0400 Alex Xu alex_y...@yahoo.ca wrote: On 29/03/14 06:07 AM, Toralf Förster wrote: WRT to but 504616 I'd like to address my questions made in https://bugs.gentoo.org/show_bug.cgi?id=504616#c6 to this list again : Since the Debian debakel with fixing an uninitialized memeory I'm very skeptical to distribution specific corrections which are not included upstream. At least I'm wondering if the USE flag hpn should be enabled by the user explicitely - currently it is in IUSE already. 1. Please use a spelling checker. 2. IUSE doesn't mean what you think it means. http://devmanual.gentoo.org/quickstart/#ebuild-with-use-flags Toralf wants to indicate that it is implicitly enabled by default (by the '+' character); and thus, he would like to see it become disabled by default, such that the user can explicitly enable it. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] New virtuals for libudev and libgudev
Hi! El 29/03/14 05:13, Samuli Suominen escribió: I took the liberty to unbreak the tree for you. Don't ever touch my packages again unless they are broken. Udev is broken: * They have known off by one string handling errors on their libraries, the developers were warned of that but have chosen to ignore the issue. The issue is still on http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/strxcpyx.c on the function size_t strpcpyf(char **dest, size_t size, const char *src, ...) which can overflow the string boundaries in some case. This issue keeps coming up from time to time thanks to their nice efforts for cahnging the whole thing instead of fixing bugs. Also after a year nothing has been done. * They keep losing cohesion (http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29) by inserting more and more unrelated software into Udev/systemd. This helps things like the above happen again. * They have the bad habit of recoding functions that are already provided by their only supported c library. This helps things like the above happen.ç * They keep reengineering everything reintroducing bugs that were fixed on previous iterations. Thus given the potential security issues udev (and systemd) have, the poor design decissions, and the lack of interest in their maintainers of fixing these, I'd strongly recommend masking it as was done with packets like wordpress or at least putting a big warning to the users. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] crossdev and multilib interference
Dnia 2014-03-28, o godz. 02:33:09 Mike Frysinger vap...@gentoo.org napisał(a): the pango stuff is also broken because it uses /etc/pango/$CHOST in an attempt to get an ABI unique path. we probably should change that to /etc/pango/$ABI or /etc/pango/$(get_libdir) or move it the multilib dir like the gdk cache does. the gnome guys would know best. Because inventing distro-specific directories is always the best solution. the llvm impact doesn't look terribly big as very few things use it. Indeed, most of Gentoo amd64 users don't care about being unable to build Mesa at all. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/29/2014 08:12 PM, Tom Wijsman wrote: On Sat, 29 Mar 2014 07:15:14 -0400 Alex Xu alex_y...@yahoo.ca wrote: On 29/03/14 06:07 AM, Toralf Förster wrote: WRT to but 504616 I'd like to address my questions made in https://bugs.gentoo.org/show_bug.cgi?id=504616#c6 to this list again : Since the Debian debakel with fixing an uninitialized memeory I'm very skeptical to distribution specific corrections which are not included upstream. At least I'm wondering if the USE flag hpn should be enabled by the user explicitely - currently it is in IUSE already. 1. Please use a spelling checker. 2. IUSE doesn't mean what you think it means. http://devmanual.gentoo.org/quickstart/#ebuild-with-use-flags Toralf wants to indicate that it is implicitly enabled by default (by the '+' character); and thus, he would like to see it become disabled by default, such that the user can explicitly enable it. Yes - that's what I want. At least an einfo should be added to the package IMO telling the user that HPN is enabled by default. - -- MfG/Sincerely Toralf Förster pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF0EAREIAAYFAlM3RjsACgkQxOrN3gB26U5MqQD+Lvo4RUNmEE4YombGSzgFqI4C gOF7B1hD1j0S4/LjN5YA9ixAma2C12HUjBAnHndlR2SSBpDFwt/E6s4EWOlp2KE= =fhiX -END PGP SIGNATURE-
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Toralf Förster: On 03/29/2014 08:12 PM, Tom Wijsman wrote: On Sat, 29 Mar 2014 07:15:14 -0400 Alex Xu alex_y...@yahoo.ca wrote: On 29/03/14 06:07 AM, Toralf Förster wrote: WRT to but 504616 I'd like to address my questions made in https://bugs.gentoo.org/show_bug.cgi?id=504616#c6 to this list again : Since the Debian debakel with fixing an uninitialized memeory I'm very skeptical to distribution specific corrections which are not included upstream. At least I'm wondering if the USE flag hpn should be enabled by the user explicitely - currently it is in IUSE already. 1. Please use a spelling checker. 2. IUSE doesn't mean what you think it means. http://devmanual.gentoo.org/quickstart/#ebuild-with-use-flags Toralf wants to indicate that it is implicitly enabled by default (by the '+' character); and thus, he would like to see it become disabled by default, such that the user can explicitly enable it. Yes - that's what I want. We have had those debates whether the + should follow upstream decisions and such. Short answer: the maintainer decides. There is no consistency for this and there will never be. At least an einfo should be added to the package IMO telling the user that HPN is enabled by default. No, that's not the right approach. There are tools you can use to check what flags are enabled. Use 'eix' and 'equery' for example. -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJTN0nSXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAg/IUP/0TXUmCfrzFupp1QIyVYbhR7 0bKE3b1/9BE40nCHPTbnLGUQs5kOa8PtINF9RkfZZuJ/yHwhdN6dCu5MqMIK2avv HfQVqVQ7bNpe3M+Ljkc/UScVLecgab7hmFk/R/OTDArsCw5Z4BIFmqDu2lYN62NW 0iWm7fV/tbPqb+f91fg2/DdTuRTptiVnjPd3n8RnxUEfzdHfLzFP4D893C4zY6vU NtGP1erM61pzbvcVBFoecbgtve6X/VkP7Ctp2QE+/zES6/xkVlwASuvNrjfMog+Y b5tis/R+LUrwz6ngmPiu/a1mlh4oB0gVMJZbCgk1YfDGVPNSrhg5opVoAyN9uAaF QOgPmgPP/9ntYw4G3pPznb3GDXXnrZrLMFXwDFTRia69qfPNBO/+DL1eB0t//E16 RAJbambJqmqKtSZZZCcxaG/3QQmWGrC1hbkIej7FGAORDsWG3cV7me2wIYm/AYeH VfdciY95SxbD0WsvZfn8gCi+t8us6JAOKo0j1INsMywZ5ui5khNBdkW7+vunjkd5 z2m57bWDek7zoNPY5LdUYB2NNVjpaVzKwaeP08xIMKW9eR+rn5+JFZrZ5mB7HY1H 4/MnRZLdpIzKE0WpmfrEyGAGLEkhCwxAVZAqWtwv+W4lH0CxdBuAqlT9m9ZPtdSD lk08Oa5adjHBXDCflCUx =GVHS -END PGP SIGNATURE-
Re: [gentoo-dev] New virtuals for libudev and libgudev
On 29/03/14 22:27, Francisco Blas Izquierdo Riera (klondike) wrote: Hi! El 29/03/14 05:13, Samuli Suominen escribió: I took the liberty to unbreak the tree for you. Don't ever touch my packages again unless they are broken. Udev is broken: * They have known off by one string handling errors on their libraries, the developers were warned of that but have chosen to ignore the issue. The issue is still on http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/strxcpyx.c on the function size_t strpcpyf(char **dest, size_t size, const char *src, ...) which can overflow the string boundaries in some case. This issue keeps coming up from time to time thanks to their nice efforts for cahnging the whole thing instead of fixing bugs. Also after a year nothing has been done. * They keep losing cohesion (http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29) by inserting more and more unrelated software into Udev/systemd. This helps things like the above happen again. * They have the bad habit of recoding functions that are already provided by their only supported c library. This helps things like the above happen.ç * They keep reengineering everything reintroducing bugs that were fixed on previous iterations. Thus given the potential security issues udev (and systemd) have, the poor design decissions, and the lack of interest in their maintainers of fixing these, I'd strongly recommend masking it as was done with packets like wordpress or at least putting a big warning to the users. You are confusing the mailing list with bugzilla. Enough said.
[gentoo-portage-dev] [PATCH 2/2] emerge: call setlocale() to enable system locale.
This is necessary so that the size formatting function (and possibly other locale-dependant functions in the future) respect the system locale rather than using the 'C' locale. --- pym/_emerge/main.py | 4 1 file changed, 4 insertions(+) diff --git a/pym/_emerge/main.py b/pym/_emerge/main.py index cfe1332..eddb16c 100644 --- a/pym/_emerge/main.py +++ b/pym/_emerge/main.py @@ -3,6 +3,7 @@ from __future__ import print_function +import locale import platform import sys @@ -984,6 +985,9 @@ def emerge_main(args=None): args = portage._decode_argv(args) + # Use system locale. + locale.setlocale(locale.LC_ALL, '') + # Disable color until we're sure that it should be enabled (after # EMERGE_DEFAULT_OPTS has been parsed). portage.output.havecolor = 0 -- 1.9.1
[gentoo-portage-dev] [PATCH 1/2] Use a localized size formatting function and ISO/IEC prefixes.
A similar size formatting function was used in two places in emerge code. Instead, create a single function in portage.localization module that formats sizes using the current locale and a common set of rules. I'm not really convinced about 'ceiling' all sizes but I understand the original point about not outputting '0 KiB'. If you have better ideas, I'd be happy to change it. The code was overall simplified, and a proper number formatting function is used (instead of string splitting). Locale grouping rules are respected now, and ISO/IEC binary prefixes are used for unambiguity. --- pym/_emerge/resolver/output.py | 5 +++-- pym/_emerge/resolver/output_helpers.py | 20 +++- pym/_emerge/search.py | 10 +++--- pym/portage/localization.py| 12 4 files changed, 21 insertions(+), 26 deletions(-) diff --git a/pym/_emerge/resolver/output.py b/pym/_emerge/resolver/output.py index 5f550be..aefc3f4 100644 --- a/pym/_emerge/resolver/output.py +++ b/pym/_emerge/resolver/output.py @@ -18,6 +18,7 @@ from portage.dbapi.dep_expand import dep_expand from portage.dep import cpvequal, _repo_separator, _slot_separator from portage.eapi import _get_eapi_attrs from portage.exception import InvalidDependString, SignatureException +from portage.localization import localized_size from portage.package.ebuild.config import _get_feature_flags from portage.package.ebuild._spawn_nofetch import spawn_nofetch from portage.output import ( blue, colorize, create_color_func, @@ -30,7 +31,7 @@ from portage.versions import best, cpv_getversion from _emerge.Blocker import Blocker from _emerge.create_world_atom import create_world_atom from _emerge.resolver.output_helpers import ( _DisplayConfig, _tree_display, - _PackageCounters, _create_use_string, _format_size, _calc_changelog, PkgInfo) + _PackageCounters, _create_use_string, _calc_changelog, PkgInfo) from _emerge.show_invalid_depstring_notice import show_invalid_depstring_notice if sys.hexversion = 0x300: @@ -330,7 +331,7 @@ class Display(object): self.myfetchlist.add(myfetchfile) if pkg_info.ordered: self.counters.totalsize += mysize - self.verboseadd += _format_size(mysize) + self.verboseadd += localized_size(mysize) if self.quiet_repo_display: # overlay verbose diff --git a/pym/_emerge/resolver/output_helpers.py b/pym/_emerge/resolver/output_helpers.py index 58b2694..e0ee3e0 100644 --- a/pym/_emerge/resolver/output_helpers.py +++ b/pym/_emerge/resolver/output_helpers.py @@ -1,4 +1,4 @@ -# Copyright 2010-2013 Gentoo Foundation +# Copyright 2010-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 Contains private support functions for the Display class @@ -17,6 +17,7 @@ import sys from portage import os from portage import _encodings, _unicode_encode from portage._sets.base import InternalPackageSet +from portage.localization import localized_size from portage.output import (blue, bold, colorize, create_color_func, green, red, teal, turquoise, yellow) bad = create_color_func(BAD) @@ -158,7 +159,7 @@ class _PackageCounters(object): myoutput.append(, .join(details)) if total_installs != 0: myoutput.append()) - myoutput.append(, Size of downloads: %s % _format_size(self.totalsize)) + myoutput.append(, Size of downloads: %s % localized_size(self.totalsize)) if self.restrict_fetch: myoutput.append(\nFetch Restriction: %s package % \ self.restrict_fetch) @@ -234,21 +235,6 @@ class _DisplayConfig(object): self.pkg = depgraph._pkg -# formats a size given in bytes nicely -def _format_size(mysize): - if isinstance(mysize, basestring): - return mysize - if 0 != mysize % 1024: - # Always round up to the next kB so that it doesn't show 0 kB when - # some small file still needs to be fetched. - mysize += 1024 - mysize % 1024 - mystr=str(mysize//1024) - mycount=len(mystr) - while (mycount 3): - mycount-=3 - mystr=mystr[:mycount]+,+mystr[mycount:] - return mystr+ kB - def _create_use_string(conf, name, cur_iuse, iuse_forced, cur_use, old_iuse, old_use, is_new, feature_flags, reinst_flags): diff --git a/pym/_emerge/search.py b/pym/_emerge/search.py index bd74fb7..4b0fd9f 100644 --- a/pym/_emerge/search.py +++ b/pym/_emerge/search.py @@ -1,4 +1,4 @@ -# Copyright 1999-2013 Gentoo Foundation +# Copyright 1999-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 from __future__ import
Re: [gentoo-portage-dev] [PATCH 1/2] Use a localized size formatting function and ISO/IEC prefixes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please use a max 50 char commit message headline, without the period. On 29/03/14 19:45, Michał Górny wrote: +import locale +import math Why not explicitly import what you are going to use? (On the form of from foo import bar, baz.) - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlM3USUACgkQRtClrXBQc7WGjAD/Sw6gqHnkCKOYlfCcOtdmZGPp 18LK2gWvXZZCDmuVb8QA/1TrnyEb3vsQ/sBe6wyNF0cwmcGQTwjN7b0O2a0CHMUY =5gkp -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 2/2] emerge: call setlocale() to enable system locale.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please remove the period from the commit message. I would prefer if you used an explicit import here as well. Other than those minor complaints, these patches look good to me. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlM3UXEACgkQRtClrXBQc7V37QEAqqQxVz4TTCw2lrWOy8+rIJt4 uq1ygRb+4p3ohABkSa8A/1pkqg571xpC87mHDUT88957aUJHpWY5tzbB6GB1dHMW =TL14 -END PGP SIGNATURE-
