Re: [gentoo-dev] [rfc] layman-global.txt, repositories.xml, layman, overlays.gentoo.org

2009-10-01 Thread Tiziano Müller
Am Mittwoch, den 30.09.2009, 17:57 +0200 schrieb Sebastian Pipping:
 Fabian Groffen wrote:
  Point remains that it looks in-consistant, for repo, name is an
  attribute, while for owner it is a sub-element.  Why having attributes
  in the first place anyway?
 
 It's closer to the original layman-global.txt which also makes the
 converter scripts simpler (and faster) than the element approach.  I
 think it's just right.
Then you're doing something wrong in your converter script because that
would be a simple change.
A simple rule of thumb is: use attributes for values with predefined
contents, use elements otherwise. So, make name an element please.

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature


Re: [gentoo-dev] [rfc] layman-global.txt, repositories.xml, layman, overlays.gentoo.org

2009-10-01 Thread Tiziano Müller
Am Mittwoch, den 30.09.2009, 18:17 +0200 schrieb Sebastian Pipping:
 Ciaran McCreesh wrote:
  Sure. Just periodically fetch the repository centrally. Have a master
  list of sync URLs with expected repository names, and use that to
  generate the full master list that includes metadata.
  
  Added bonus: you can quickly remove any repository that no longer
  exists.
 
 How long do you want the time frame for add-meta-data-or-get-kicked
 to be?  If half the repos don't not make it will kicking them help
 anybody?
Yes, then they're not maintained. And unmaintained overlays tend to
contain even more broken ebuilds than others.

   What if that metadata format changes later or is extended by
 additional required entries?
How about using the power of xml and version the schemas? As long as the
metadata-file specifies the respective dtd/xsd/relaxng you know exactly
how to validate (and parse) it and may apply a xsl-trafo if necessary to
convert it to a new format on the fly. As long as you keep using xml you
can then change the complete format in a new schema version.


-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature


Re: [gentoo-dev] [rfc] layman-global.txt, repositories.xml, layman, overlays.gentoo.org

2009-10-01 Thread Robert Buchholz
On Thursday 01 October 2009, Tiziano Müller wrote:
 Am Mittwoch, den 30.09.2009, 18:17 +0200 schrieb Sebastian Pipping:
  Ciaran McCreesh wrote:
   Sure. Just periodically fetch the repository centrally. Have a
   master list of sync URLs with expected repository names, and use
   that to generate the full master list that includes metadata.
  
   Added bonus: you can quickly remove any repository that no longer
   exists.
 
  How long do you want the time frame for add-meta-data-or-get-kicked
  to be?  If half the repos don't not make it will kicking them help
  anybody?

 Yes, then they're not maintained. And unmaintained overlays tend to
 contain even more broken ebuilds than others.

There are plenty of unmaintained overlays. Keeping them in our index 
allows everyone to use what is still usable, and develoers to pick up 
maintenance. Removing them from the index makes it harder to do this.

I guess what you want to do is keep unsuspecting users safe from these 
overlays, and the quality levels (i.e. graveyard in this case) are 
there to serve this purpose.


Robert


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)

2009-10-01 Thread volkmar
On Thu, Oct 01, 2009 at 04:01:29AM +0200, Sebastian Pipping wrote:
 Zac Medico wrote:
  I propose support for license groups in ebuilds then, I guess.
  
  That seems like a reasonable solution. So, an ebuild can do
  something like LICENSE=@GPL-2+ and that will expand to whatever
  the definition of the GPL-2+ license group happens to be. When a new
  version of GPL license comes out, we simple add it to that group,
  and none of the corresponding ebuilds have to be updated.
 
 I made a bug from that so it doesn't get lost.
 
 https://bugs.gentoo.org/show_bug.cgi?id=287192

Actually, it's not lost. I've write a patch for the GLEP-23 and I'm
waiting for an answer from the glep team.

--
Mounir



Re: [gentoo-dev] [rfc] layman-global.txt, repositories.xml, layman, overlays.gentoo.org

2009-10-01 Thread Sebastian Pipping
Tiziano Müller wrote:
   What if that metadata format changes later or is extended by
 additional required entries?
 How about using the power of xml and version the schemas? As long as the
 metadata-file specifies the respective dtd/xsd/relaxng you know exactly
 how to validate (and parse) it and may apply a xsl-trafo if necessary to
 convert it to a new format on the fly. As long as you keep using xml you
 can then change the complete format in a new schema version.

We are version the schemas already.  My point is that we would need to
wait for the overlay maintainers once again to update their metadata.
Transforming does not save us as we are missing new data.


Sebastian



Re: [gentoo-dev] [rfc] layman-global.txt, repositories.xml, layman, overlays.gentoo.org

2009-10-01 Thread Sebastian Pipping
Tiziano Müller wrote:
 A simple rule of thumb is: use attributes for values with predefined
 contents, use elements otherwise. So, make name an element please.

Okay, let's give it a try.

http://git.goodpoint.de/?p=overlays-xml-specification.git;a=commitdiff;h=8b10c5c7fd5b42bb5540fd686e0d97f5d11ad841



Sebastian



[gentoo-dev] Xorg 1.6/libxcb 1.4 stabilization news item

2009-10-01 Thread Rémi Cardona

Hi guys,

Could anyone write up a one-liner news item for the xorg-server 1.6 
stabilization with there 2 upgrade guides :


http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml

I tried figuring out how to write one myself, but failed miserably 
because of the entirely non-intuitive GLEP.


Basically, all stable users should see that news item.

Thanks in advance to the benevolent soul who will write it and commit it :)

Thanks



[gentoo-dev] last rites: games-action/astromenace-bin

2009-10-01 Thread Michael Sterrett
# Doesn't work with newer openal.  Use games-action/openastromenace instead.
games-action/astromenace-bin



Re: [gentoo-dev] Xorg 1.6/libxcb 1.4 stabilization news item

2009-10-01 Thread Ciaran McCreesh
On Thu, 01 Oct 2009 22:42:22 +0200
Rémi Cardona r...@gentoo.org wrote:
 I tried figuring out how to write one myself, but failed miserably 
 because of the entirely non-intuitive GLEP.
 
 Basically, all stable users should see that news item.

You're failing miserably because you're looking at it entirely the
wrong way. Clearly, you don't want all stable users to see the news
item:

* You don't want stable users who don't have X installed to see the news
  item.

* You don't want stable users who have already done the upgrade, or who
  are installing from scratch after the news item has been written, to
  see the news item.

What you do want is for anyone who has an old X server / an old libxcb
installed to see the news item. Thus, you want to use the
Display-If-Installed header with a  dependency specification.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item

2009-10-01 Thread 7v5w7go9ub0o

Rémi Cardona wrote:

Hi guys,

Could anyone write up a one-liner news item for the xorg-server 1.6 
stabilization with there 2 upgrade guides :


http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml


http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml


I tried figuring out how to write one myself, but failed miserably 
because of the entirely non-intuitive GLEP.


Basically, all stable users should see that news item.

Thanks in advance to the benevolent soul who will write it and commit
it :)

Thanks


Perhaps something simple like this? (HTH):


xorg-server 1.6.

We're pleased to announce the stabilization of xorg-server-1.6. Users 
should review the following two guides before upgrading to 1.6:


http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml