Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
Jeremy Olexa wrote: Andrey Grozin wrote: It was discussed (don't have a reference to the thread at hand) that it would be useful to have a table which shows which functions die by themselves, and which not. Andrey I see this asked every X months and never quite figured out why, (this isn't personal against you, Andrey) [...] Take a look for yourself and you will see why there has never been a table or anything created. (it is trivial - and you have the source on your computer already) It shouldn't be necessary to grep the source, if these things would follow a simple logical rule, in accordance with the principle of least surprise. It would be handy to be able to say: all e* functions die, but do* and new* do not. But tommy's list shows that emake is an exception to the rule. I'm not aware of any other exceptions, but I can't be sure unless I go digging through the source. Which really should not be necessary, in my opinion. -- Ben de Groot Gentoo Linux developer (lxde, media, qt, desktop-misc) Gentoo Linux Release Engineering PR liaison __ yng...@gentoo.org http://ben.liveforge.org/ irc://chat.freenode.net/#gentoo-media irc://irc.oftc.net/#lxde __
[gentoo-dev] Need to mask non-visible packages in package.mask?
Some time ago (31 Oct 2008) I renamed perl-core/File-Spec-3.2701 to perl-core/File-Spec-3.27.01 by adding the new file and removing the other. I expected portage to do an downgrade. It didn't. I realised it when i got this bug https://bugs.gentoo.org/248178 and after joining #-portage I add a mask for a non-existing package to package.mask. Today I was CC'ed to https://bugs.gentoo.org/105016 because package.mask contains invalid entries. In the meantime another bug was filed about portage doesn't attempt to downgrade packages on keyword changes... https://bugs.gentoo.org/252167 with a fix. I am confused. Will portage warn about the downgrade now and forever?
Re: [gentoo-dev] Need to mask non-visible packages in package.mask?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Torsten Veller wrote: Some time ago (31 Oct 2008) I renamed perl-core/File-Spec-3.2701 to perl-core/File-Spec-3.27.01 by adding the new file and removing the other. I expected portage to do an downgrade. It didn't. I realised it when i got this bug https://bugs.gentoo.org/248178 and after joining #-portage I add a mask for a non-existing package to package.mask. Today I was CC'ed to https://bugs.gentoo.org/105016 because package.mask contains invalid entries. In the meantime another bug was filed about portage doesn't attempt to downgrade packages on keyword changes... https://bugs.gentoo.org/252167 with a fix. I am confused. Will portage warn about the downgrade now and forever? Yes, my intention is for the masks to be unnecessary, because after thinking about it I decided that it's not desirable to maintain package.mask entries for packages such as these. Since bug 252167 has been fixed, newer versions of portage perform automatic downgrades like older versions of portage did. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklZK+YACgkQ/ejvha5XGaOYegCgvjU4KSjBE4/Lyr0LBvf+lcfY 624AoJoBzlpVGaKGOHr3C2gAtD9jUFfr =Z1t7 -END PGP SIGNATURE-
[gentoo-dev] RSBAC-related packages removal notice
RSBAC has been without a maintainer for some time and Hardened is discontinuing support for RSBAC. As such, the following packages are going into package.mask for eventual removal after January 31st, 2009. sys-apps/rsbac-admin sys-kernel/rsbac-sources Gordon Malm (gengor)
Re: [gentoo-dev] Python expat USE flag
2008-12-28 05:23:12 Jesus Rivero napisał(a): Hello everyone, ~A while ago there was a discussion about the new expat USE flag in dev-lang/python. The flag was first introduced by Vapier on December 08th. ~While having expat USE flag may be of great use for embedded systems or in bootstrapping/releasing phases, it is not so in both in Gentoo related projects and software in general. Vapier fixed this by making the USE flag +expat. ~Now, the issue is many people, me included, don't like that name for the USE flag for a variety of reasons one of them being that expat doesn't correlate directly with the use of xml in python provided that developers may choose another lib for handling xml other than that, like libxml2. ~I want to change the USE flag to something else if people don't like 'build' and make it 'minimal' or 'embedded' as Nirbheek suggested/ mailto:nirbheek.chau...@gmail.com//. /I think that is more suitable to the problem at hand. I don't want to start a silly fuss over this, just that there are some version bumps I'd like to make, but I would like to have a consensus on this before I make the bumps. ~ What do you think? +1 for 'minimal'. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, In response to bug 252748 I've implemented a new 'variable.invalidchar' repoman check that will trigger if an ebuild metadata variable contains any characters that aren't in the ASCII character set (0-127). Is this okay, or does anybody think that we should allow UTF-8 unicode? - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEUEARECAAYFAklZT9gACgkQ/ejvha5XGaMoZwCcC4ALWY/m+hOQenQZFINzD0jz B6AAmIB3uN6bHMPJF2zrIC6jOCwtPvg= =BQov -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: Hi, In response to bug 252748 I've implemented a new 'variable.invalidchar' repoman check that will trigger if an ebuild metadata variable contains any characters that aren't in the ASCII character set (0-127). Is this okay, or does anybody think that we should allow UTF-8 unicode? Nevermind, apparently GLEP 31 already requires ASCII anyway: http://www.gentoo.org/proj/en/glep/glep-0031.html - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklZUqoACgkQ/ejvha5XGaM9hACbB7ftF/NiGYce9uRohE0w7AW8 6IkAn2ifjwQxILUIh/FUBursWFoE0J78 =ms0N -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?
Zac Medico wrote: In response to bug 252748 I've implemented a new 'variable.invalidchar' repoman check that will trigger if an ebuild metadata variable contains any characters that aren't in the ASCII character set (0-127). Is this okay, or does anybody think that we should allow UTF-8 unicode? Nevermind, apparently GLEP 31 already requires ASCII anyway: http://www.gentoo.org/proj/en/glep/glep-0031.html The way I read that GLEP is that in ChangeLog and metadata.xml we should accept the full range of UTF-8. -- Ben de Groot Gentoo Linux developer (lxde, media, qt, desktop-misc) Gentoo Linux Release Engineering PR liaison __ yng...@gentoo.org http://ben.liveforge.org/ irc://chat.freenode.net/#gentoo-media irc://irc.oftc.net/#lxde __
Re: [gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?
On Tue, Dec 30, 2008 at 8:27 AM, Ben de Groot yng...@gentoo.org wrote: Zac Medico wrote: Nevermind, apparently GLEP 31 already requires ASCII anyway: http://www.gentoo.org/proj/en/glep/glep-0031.html The way I read that GLEP is that in ChangeLog and metadata.xml we should accept the full range of UTF-8. I read that as contents of portage tree should be in UTF-8, file paths should be in ASCII It is proposed that UTF-8 ([1]) is used for encoding ChangeLog and metadata.xml files inside the portage tree. [...]it is proposed that UTF-8 is used as the official encoding for ebuild and eclass files Patches must clearly be in the same character set as the file they are patching. Characters outside the ASCII 0..127 range cannot safely be used for file or directory names It is also worth mentioning that Python 3K uses UTF-8 as the default encoding for it's files rather than ASCII as Python 2.X did. Why should *we* go backwards? :p -- ~Nirbheek Chauhan
Re: [gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?
On Tue, 30 Dec 2008 09:37:24 +0530 Nirbheek Chauhan nirbheek.chau...@gmail.com wrote: On Tue, Dec 30, 2008 at 8:27 AM, Ben de Groot yng...@gentoo.org wrote: Zac Medico wrote: Nevermind, apparently GLEP 31 already requires ASCII anyway: http://www.gentoo.org/proj/en/glep/glep-0031.html The way I read that GLEP is that in ChangeLog and metadata.xml we should accept the full range of UTF-8. I read that as contents of portage tree should be in UTF-8, file paths should be in ASCII It is proposed that UTF-8 ([1]) is used for encoding ChangeLog and metadata.xml files inside the portage tree. [...]it is proposed that UTF-8 is used as the official encoding for ebuild and eclass files Patches must clearly be in the same character set as the file they are patching. Characters outside the ASCII 0..127 range cannot safely be used for file or directory names It is also worth mentioning that Python 3K uses UTF-8 as the default encoding for it's files rather than ASCII as Python 2.X did. Why should *we* go backwards? :p And none of that is relevant to Zacs original question, which is covered by the following section of the GLEP: However, developers should be warned that any code which is parsed by bash (in other words, non-comments), and any output which is echoed to the screen (for example, einfo messages) or given to portage (for example any of the standard global variables) must not use anything outside the regular ASCII 0..127 range for compatibility purposes. Marius
Re: [gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?
On Tue, Dec 30, 2008 at 10:03 AM, Marius Mauch gen...@gentoo.org wrote: And none of that is relevant to Zacs original question, which is covered by the following section of the GLEP: Oops, sorry, misread the question :) -- ~Nirbheek Chauhan
