Re: [gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?

[Nirbheek Chauhan]

On Tue, Dec 30, 2008 at 10:03 AM, Marius Mauch  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

Re: [gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?

[Marius Mauch]

On Tue, 30 Dec 2008 09:37:24 +0530
"Nirbheek Chauhan"  wrote:

> On Tue, Dec 30, 2008 at 8:27 AM, Ben de Groot 
> 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?

[Nirbheek Chauhan]

On Tue, Dec 30, 2008 at 8:27 AM, Ben de Groot  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?

[Ben de Groot]

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?

[Zac Medico]

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

[gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?

[Zac Medico]

-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] Python expat USE flag

[Arfrever Frehtes Taifersar Arahesis]

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/
> //. /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] RSBAC-related packages removal notice

[Gordon Malm]

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] Need to mask non-visible packages in package.mask?

[Zac Medico]

-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 
> 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..." 
> 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] Need to mask non-visible packages in package.mask?

[Torsten Veller]

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 
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..." 
with a fix.


I am confused. Will portage warn about the downgrade now and forever?

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Ben de Groot]

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
__