[gentoo-dev] Re: Name change s/drac/ssuominen/ for people wondering.

2008-11-30 Thread Diego 'Flameeyes' Pettenò
Samuli Suominen [EMAIL PROTECTED] writes:

 This is for the people wondering who I am.

And there goes for people not knowing the realnames of colleagues I
guess ;)  I'm glad I started calling people by first name whenever I
write something :P

By the way, I really hope you feel better now, and I certainly
understand that sometimes when you hit the bottom you feel like changing
your appearence, which online is... your nick ;)

Keep it up and try to make it fun!

-- 
Diego E. Flameeyes Pettenò -- who recently legally changed his first name
http://blog.flameeyes.eu/


pgpfoekrffmOI.pgp
Description: PGP signature


[gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò

I have a very quick proposal: why don't we move the packages' homepage
in metadata.xml (since it's usually unique for all the versions) and we
get rid of the variable for the next EAPI version?

This makes it easier to get the package's homepage for submitting bugs
upstream (you just do a single lookup for the metadata.xml file rather
than checking the ebuild; ensures that homepage changes don't get stale
for old revisions, avoids commits on old ebuilds for home page changes
(and thus changes that propagates on mirrors, and so on. It also makes
searching by homepage easier (a search program would take much less time
to parse XML that an ebuild).

I would propose an implementation of this that takes in consideration
also older proposals of having a way to specify upstream and
gentoo-specific information, something among the lines of this:

link type=homepagehttp://package.foobar.com/link
link type=bugtrackerhttp://package.foobar.com/bugs/link

and for gentoo-specific

link type=gentoo:devel title=foobar maintainer's
guidehttp://www.gentoo.org/proj/en/foo/foobar/link

link
type=gentoo:user title=foobar usage
guidehttp://www.gentoo.org/doc/en/foobar.xml/link

Please submit all comments, as long as they are not I don't like XML
or XML is the wrong answer and similar since the point here is not to
discuss the format of metadata but rather where to have it.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgpKz8EqcCHvB.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Jan Kundrát

Diego 'Flameeyes' Pettenò wrote:

I have a very quick proposal: why don't we move the packages' homepage
in metadata.xml (since it's usually unique for all the versions)


I believe the reason was that HOMEPAGE might change with new versions 
and that metadata.xml didn't (doesn't?) support version-specific data.


Cheers,
-jkt

--
cd /local/pub  more beer  /dev/mouth



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò
Jan Kundrát [EMAIL PROTECTED] writes:

 I believe the reason was that HOMEPAGE might change with new versions
 and that metadata.xml didn't (doesn't?) support version-specific data.

At least the maintainer and (iirc, at least that's how we proposed
it the first time around) flag tags support a restrict attribute.

But I really expect that as long as the package is the same, homepage is
unlikely to change with version; maybe with slot I guess, but even that
is debatable and somewhat rare I think.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpB5SH1b5Viy.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Tomáš Chvátal
On Sunday 30 November 2008 14:23:48 Diego 'Flameeyes' Pettenò wrote:
 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions) and we
 get rid of the variable for the next EAPI version?
I would rather see something like:

packagename/metadata.xml
packagename/package-base.ebuild
packagename/packagename-version.ebuild
packagename/Manifest
packagename/Changelog

Where package-base would store everything basic for the ebuild, licences and 
so on, and in package-version would be only specific changes for the version 
(for example patching Makefile).

Variables will be overridable this way and thus i think it would be nicer.



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


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Tobias Scherbaum
Jan Kundrát:
 Diego 'Flameeyes' Pettenò wrote:
  I have a very quick proposal: why don't we move the packages' homepage
  in metadata.xml (since it's usually unique for all the versions)
 
 I believe the reason was that HOMEPAGE might change with new versions 
 and that metadata.xml didn't (doesn't?) support version-specific data.

In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
Does someone have an example where older versions stay at an old homepage
and newer versions moved to a new homepage? Which (and how many) packages would 
be affected by that?

If this does affect a larger number of packages (i doubt so) we might add 
something like this:
link type=homepage:oldhttp://package.oldbarfoo.org/link
or we allow more than 1 homepage item to be specified of which we can
use the title attribute to describe for which versions this homepage
item applies. Anyways, all of these would only be quick hacks for a
rather short timeframe which it takes to stable a new version and remove
the older one.

In general I do like that proposal, especially the addition of further
links for bug trackers, forums, irc-channels, gentoo-specific
documentation and so on.

  Tobias


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tomáš Chvátal yazmış:
 On Sunday 30 November 2008 14:23:48 Diego 'Flameeyes' Pettenò wrote:
 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions) and we
 get rid of the variable for the next EAPI version?
 I would rather see something like:
 
 packagename/metadata.xml
 packagename/package-base.ebuild
I've been thinking of something like this for a long time. It would
greatly improve maintanance (we could put some common ebuild logic
there,too) and reduce the tree size.
 packagename/packagename-version.ebuild
 packagename/Manifest
 packagename/Changelog
 
 Where package-base would store everything basic for the ebuild, licences and 
 so on, and in package-version would be only specific changes for the version 
 (for example patching Makefile).
 
 Variables will be overridable this way and thus i think it would be nicer.
 

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkymmIACgkQRh6X64ivZaKaNQCfYT0Db8zjcIYkzZcPPn83IxMM
UIgAniA8kdc511KJ9eaDNwp8YR7CqKkf
=JcT+
-END PGP SIGNATURE-



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tobias Scherbaum yazmış:
 Jan Kundrát:
 Diego 'Flameeyes' Pettenò wrote:
 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions)
 I believe the reason was that HOMEPAGE might change with new versions 
 and that metadata.xml didn't (doesn't?) support version-specific data.
 
 In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
 Does someone have an example where older versions stay at an old homepage
 and newer versions moved to a new homepage? Which (and how many) packages 
 would be affected by that?
 
 If this does affect a larger number of packages (i doubt so) we might add 
 something like this:
 link type=homepage:oldhttp://package.oldbarfoo.org/link
 or we allow more than 1 homepage item to be specified of which we can
 use the title attribute to describe for which versions this homepage
 item applies. Anyways, all of these would only be quick hacks for a
 rather short timeframe which it takes to stable a new version and remove
 the older one.
 
 In general I do like that proposal, especially the addition of further
 links for bug trackers, forums, irc-channels, gentoo-specific
 documentation and so on.
 
   Tobias

I don't know if there are others but I can give one specific example,
sun-{jdk,jre-bin} where homepage differs in SLOT's
1.4 pointing to http://java.sun.com/j2se/1.4.2/ , 1.5 to
http://java.sun.com/j2se/1.5.0/ , 1.6 to http://java.sun.com/javase/6/
and 1.7 will probably have something new.

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkym5wACgkQRh6X64ivZaKyWQCbBuzASFIYg+Ua5rifXVbig0RA
c+wAnRdETeKiyDESLKspQ52uNAHx+HrL
=OPAH
-END PGP SIGNATURE-



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Matti Bickel
Tomáš Chvátal [EMAIL PROTECTED] wrote:
 On Sunday 30 November 2008 14:23:48 Diego 'Flameeyes' Pettenò wrote:
  I have a very quick proposal: why don't we move the packages' homepage
  in metadata.xml (since it's usually unique for all the versions) and we
  get rid of the variable for the next EAPI version?
 I would rather see something like:
 
 packagename/metadata.xml
 packagename/package-base.ebuild
 packagename/packagename-version.ebuild
 packagename/Manifest
 packagename/Changelog

Correct me if i'm wrong, but this doesn't address the problem with
multiple versions having multiple homepages.
I'm with Diego here that this should be *very* rare.

Can somebody verify this? I mean just throw a little shell script on the
portage tree showing which ebuilds differ in HOMEPAGE but still have the
same path.. my poor ibook would take too long for such a thing, so
sorry, no data here.

And while your proposal sounds more compliant to the DRY principle, i
would object it on the basis that it makes a single ebuild actually
harder to understand as you have to read (1) eclasses, (2) -base.ebuild
and (3) -version.ebuild.
-- 
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)


pgpLZ47VAfi0Y.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Ciaran McCreesh
On Sun, 30 Nov 2008 14:46:39 +0100
Tomáš Chvátal [EMAIL PROTECTED] wrote:
 I would rather see something like:
 
 packagename/metadata.xml
 packagename/package-base.ebuild
 packagename/packagename-version.ebuild
 packagename/Manifest
 packagename/Changelog

All this really needs is per-package eclasses.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Tobias Scherbaum
Matti Bickel wrote:
 And while your proposal sounds more compliant to the DRY principle, i
 would object it on the basis that it makes a single ebuild actually
 harder to understand as you have to read (1) eclasses, (2) -base.ebuild
 and (3) -version.ebuild.

That's quite exactly what I wanted to write - plus this -base.ebuild
thingy would only make sense if we also allow versioning of
-base.ebuilds. And then we're quickly speaking of package-based eclasses
instead of -base.ebuilds.

If we're speaking of a list of whishes for 2009 - i'd prefer to see
eclass versioning instead of -base.ebuilds ;)

  Tobias


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes:

 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions) and we
 get rid of the variable for the next EAPI version?

I forgot to say that this also addresses, for the future EAPI, the
problem of what to do with missing HOMEPAGE. We still have to find a
solution for that on the EAPI 0, 1 and 2 though since it's a bit of a
big problem when we point to domain squatters.

If it was feasible to just make missing HOMEPAGE a softfail for the
other three it would be even better.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgp3NTn0n5kOR.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Tobias Scherbaum
Serkan Kaba wrote:
 I don't know if there are others but I can give one specific example,
 sun-{jdk,jre-bin} where homepage differs in SLOT's
 1.4 pointing to http://java.sun.com/j2se/1.4.2/ , 1.5 to
 http://java.sun.com/j2se/1.5.0/ , 1.6 to http://java.sun.com/javase/6/
 and 1.7 will probably have something new.

A special case in which HOMEPAGE=java.sun.com might work as well? ;)
Ok, of course this on purpose and might be of benefit to be pointed to a
specific website in that case.

But what about additional slot or version attributes like
link type=homepage slot=1.4http://java.sun.com/j2se/1.4.2//link
(or a version attribute)? If slot and version aren't specified they'd be
interpreted as wildcards.

  Tobias


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò
Tobias Scherbaum [EMAIL PROTECTED] writes:

 But what about additional slot or version attributes like
 link type=homepage slot=1.4http://java.sun.com/j2se/1.4.2//link
 (or a version attribute)? If slot and version aren't specified they'd be
 interpreted as wildcards.

link type=homepage restrict=dev-java/sun-jdk:1.4

The restrict attribute exists already and it's better to reuse the same
code, isn't it?

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpJJ5dlUYEV7.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Hans de Graaff
On Sun, 2008-11-30 at 14:50 +0100, Tobias Scherbaum wrote:
 Jan Kundrát:
  Diego 'Flameeyes' Pettenò wrote:
   I have a very quick proposal: why don't we move the packages' homepage
   in metadata.xml (since it's usually unique for all the versions)
  
  I believe the reason was that HOMEPAGE might change with new versions 
  and that metadata.xml didn't (doesn't?) support version-specific data.
 
 In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
 Does someone have an example where older versions stay at an old homepage
 and newer versions moved to a new homepage? Which (and how many) packages 
 would be affected by that?

I've seen this happen for at least one ruby package where the package
got forked, with the old stagnant versions still on the old homepage and
the new versions on the new homepage.

I still favor the move to metadata.xml, even though there are probably a
few more edge cases like this.

Kind regards,

Hans


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


Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Tobias Scherbaum
Diego 'Flameeyes' Pettenò wrote:
 Tobias Scherbaum [EMAIL PROTECTED] writes:
 
  But what about additional slot or version attributes like
  link type=homepage slot=1.4http://java.sun.com/j2se/1.4.2//link
  (or a version attribute)? If slot and version aren't specified they'd be
  interpreted as wildcards.
 
 link type=homepage restrict=dev-java/sun-jdk:1.4
 
 The restrict attribute exists already and it's better to reuse the same
 code, isn't it?

In general yes, but in that case you're duplicating info like
dev-java/sun-jdk unnecessarily. Reducing this to restrict=1.4 isn't
easily readable as you'd need to know that restrict would specify a
slot. If your plan is to make it easier to find useful information about
a package (without using a fancy frontend, just reading the metadata.xml
with $EDITOR) slot=1.4 (or a version attribute) might be a tad more
human readable. 

  Tobias


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò
Tobias Scherbaum [EMAIL PROTECTED] writes:

 dev-java/sun-jdk unnecessarily. Reducing this to restrict=1.4 isn't
 easily readable as you'd need to know that restrict would specify a
 slot. If your plan is to make it easier to find useful information about
 a package (without using a fancy frontend, just reading the metadata.xml
 with $EDITOR) slot=1.4 (or a version attribute) might be a tad more
 human readable. 

Well if we go to these things we should just apply the same to the other
attributes using restrict, since we want to have something coherent,
don't we? ;)

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpqrcOBdsryo.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Thomas Anderson
On Sun, Nov 30, 2008 at 02:23:48PM +0100, Diego 'Flameeyes' Pettenò wrote:
 Please submit all comments, as long as they are not I don't like XML
 or XML is the wrong answer and similar since the point here is not to
 discuss the format of metadata but rather where to have it.

XML is the wrong answer. Sorry, but in this case, I'm arguing that this
should not be in metadata.xml but in,say, a per-package eclass. Also,
you don't have to worry about different HOMEPAGE's for different
versions/slots because you get that for free as soon as you decide to
use per-package/per-category eclasses. Really, we might as well use
per-package eclasses for this(not to mention the fact that they are
useful in other cases.)

Regards,
Thomas


pgp1XA7WdbcXk.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Ciaran McCreesh
On Sun, 30 Nov 2008 14:23:48 +0100
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote:
 This makes it easier to get the package's homepage for submitting bugs
 upstream (you just do a single lookup for the metadata.xml file rather
 than checking the ebuild

...or you have a tool that uses the package manager API to show you the
homepage of the package in the current directory. I've attached a small
script that'll do that for you -- much easier than trying to dig your
way through an XML file.

 It also makes searching by homepage easier (a search program would
 take much less time to parse XML that an ebuild).

Search programs don't parse ebuilds. They parse the metadata cache,
which is an awful lot easier to parse than XML.

-- 
Ciaran McCreesh


show_homepage.rb
Description: application/ruby


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Peter Volkov
В Вск, 30/11/2008 в 14:50 +0100, Tobias Scherbaum пишет:
 In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
 Does someone have an example where older versions stay at an old homepage
 and newer versions moved to a new homepage?

Yes. This is quite a common case when one upstream stopped development
of the package and new developer took it. traceroute, flow-tools are
just examples from the top of my head. I remember I saw more such
things...

Also sometimes it's useful to have different HOMEPAGE for different
versions.


And in general, Diego. What are you trying to improve with this change?
The original intention was to separate common information from all
ebuilds into metadata.xml. But obviously, HOMEPAGE changes from ebuild
to ebuild. Now if intention is separate some information from ebuild
into metadata.xml then, please, tell me what is the criterion for such
information? Why not LICENSE? Currently I don't think this change worth
our efforts...

-- 
Peter.




Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Volkov yazmış:
 В Вск, 30/11/2008 в 14:50 +0100, Tobias Scherbaum пишет:
 In most (nearly all?) cases a HOMEPAGE change does also affect older 
 versions.
 Does someone have an example where older versions stay at an old homepage
 and newer versions moved to a new homepage?
 
 Yes. This is quite a common case when one upstream stopped development
 of the package and new developer took it. traceroute, flow-tools are
 just examples from the top of my head. I remember I saw more such
 things...
 
 Also sometimes it's useful to have different HOMEPAGE for different
 versions.
 
 
 And in general, Diego. What are you trying to improve with this change?
 The original intention was to separate common information from all
 ebuilds into metadata.xml. But obviously, HOMEPAGE changes from ebuild
 to ebuild. Now if intention is separate some information from ebuild
 into metadata.xml then, please, tell me what is the criterion for such
 information? Why not LICENSE? Currently I don't think this change worth
 our efforts...
 
LICENSE should definetely be avoided to be defined per-package. Upstream
may decide to relicense new version of packages.
- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkyrJ0ACgkQRh6X64ivZaI4EwCfWECIM3Hecu04yHCeoCKEJqki
VMQAnj+aIeQ5Bf9cA0iQm/wT8U7hZWAV
=wW6Q
-END PGP SIGNATURE-



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Santiago M. Mola
El dom, 30-11-2008 a las 14:23 +0100, Diego 'Flameeyes' Pettenò
escribió:
 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions) and we
 get rid of the variable for the next EAPI version?
 

 
 Please submit all comments, as long as they are not I don't like XML
 or XML is the wrong answer and similar since the point here is not to
 discuss the format of metadata but rather where to have it.

As suggested by Ciaran and Serkan, this could also be achieved with
per-package eclasses [1].

That way, it would be easy to avoid duplication of not only HOMEPAGE but
also SRC_URI, LICENSE, or any other part of an ebuild.

In fact, this idea is already being used in the tree in the form of bash
scripts in ${FILESDIR} that are source'd in the ebuild [2].

[1] https://bugs.gentoo.org/show_bug.cgi?id=69714
[2]
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/glibc/files/eblits/

Regards,
-- 
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente


[gentoo-dev] Time to say goodbye

2008-11-30 Thread Marius Mauch
So, time has come for me to realize that my time with Gentoo is over. I
haven't actually been doing much Gentoo work over the last months due
to personal reasons (nothing Gentoo related), and I don't see that
situation changing in the near future. In fact I've already reassigned
or dropped most of my responsibilites in Gentoo a while ago, so there
are just a few pet projects left to give away:
- my gentoo-stats project (in the portage/gentoo-stats svn repository).
I know quite a few people are interested in the idea of collecting
various statistic data from gentoo user systems, and I'd encourage
everyone who wants to implement such a system to at least look at it (I
may have even finished it if I wouldn't have wasted my time focusing on
the wrong problems). There is quite a bit of documentation also that
should help to get you started
- a graphical security update tool (see bug #190397)

So if anyone wants to adopt those, complete or just parts, just take
them. As for Portage, Zac has practically already filled my role.

So I guess that wraps it up. It's been a nice ride most of the time,
but now it's time for me to leave the Gentoo train.

Marius




Re: [gentoo-dev] Time to say goodbye

2008-11-30 Thread Tobias Scherbaum
Marius Mauch wrote:
 So I guess that wraps it up. It's been a nice ride most of the time,
 but now it's time for me to leave the Gentoo train.

... and time for another sad to see you go. :(

I'd link to thank you for contributions to Portage - but also for
being a very active forums user as well. It would be nice to see
you still being active in the forums - or to meet you again at FOSDEM :)

  Tobias


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Joe Peterson
Diego 'Flameeyes' Pettenò wrote:
 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions) and we
 get rid of the variable for the next EAPI version?

For that matter, whatever is decided, why not include DESCRIPTION?
This seems to me a candidate for something that does not change version
to version (or at least shouldn't - since there is only one displayed,
e.g., in emerge --search).

-Joe



[gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Joe Peterson
I recently had a user write to me after banging his head against the
wall for a while, trying to get a package working.  By the time he wrote
me, he had already figured it out, but he wanted to convey to me that
what finally helped was actually the emerge output (which stated exactly
how to get things working - in this case, the need to run emerge
--config).  He had not noticed this before and only saw it upon
re-installing, given the transient nature of the emerge messages.

Bottom line here is that there is extremely valuable and critical info
in our emerge output.  In a way, these messages are like Gentoo-specific
READMEs (or release notes and/or install instructions).  However, it is
not saved for a user to use as a resource later (well, except that it is
partially saved in the master emerge.log, but that's not quite useful
enough).  There is no official place to go to look for Gentoo
instructions; /usr/share/doc is one logical place, but it only contains
files actually installed, not the notes output by emerge (and these are
usually upstream-supplied, not Gentoo).

I propose that, upon merging a package, we save the emerge messages in
either: 1) a package-specific file that resides somewhere official or
2) in the portage DB, so that the messages can be re-read via a portage
utility.  In the latter case, either a new option to equery or a new
q command (e.g. equery readme pkg or qreadme pkg could
retrieve the text).

In either case, there would then be a place to go that is known and
consistent (and can be documented in the Gentoo doc).  It could, in
essense, serve as a kind of Gentoo package README collection.  I could
also imagine later expanding on this by letting a given package also
include more thorough README info from a file if the maintainer so desires.

-Joe



Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Marius Mauch
On Sun, 30 Nov 2008 09:25:51 -0700
Joe Peterson [EMAIL PROTECTED] wrote:

 Bottom line here is that there is extremely valuable and critical info
 in our emerge output.  In a way, these messages are like
 Gentoo-specific READMEs (or release notes and/or install
 instructions).  However, it is not saved for a user to use as a
 resource later (well, except that it is partially saved in the master
 emerge.log, but that's not quite useful enough).  There is no
 official place to go to look for Gentoo
 instructions; /usr/share/doc is one logical place, but it only
 contains files actually installed, not the notes output by emerge
 (and these are usually upstream-supplied, not Gentoo).
 
 I propose that, upon merging a package, we save the emerge messages in
 either: 1) a package-specific file that resides somewhere official
 or
 2) in the portage DB, so that the messages can be re-read via a
 portage utility.  In the latter case, either a new option to equery
 or a new q command (e.g. equery readme pkg or qreadme pkg
 could retrieve the text).

By default, messages generated by elog, ewarn and eerror are recorded
in /var/log/portage/elog/summary.log (emerge.log is just a
transaction log, so best to ignore it here). einfo isn't recorded on
purpose as it isn't intended for important information (that's the
purpose of elog). There are some tools available to simplify reading
these messages, and there several additional/alternative delivery
modules available (by mail, IM or in package specific files),
customizable via POTAGE_ELOG_* variables. Don't know if you just
haven't been aware of this, or if you're asking for something
completely different.

Marius



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Peter Volkov
В Вск, 30/11/2008 в 16:10 +0100, Santiago M. Mola пишет:
 per-package eclasses [1].
 That way, it would be easy to avoid duplication of not only HOMEPAGE but
 also SRC_URI, LICENSE, or any other part of an ebuild.

Having per-package eclasses (PPE) just to set common HOMEPAGE is
definitely overkill. What other reasons for PPE to exist?

If you want to separate common code, then PPE is very dangerous.

Take for example ebuilds which share same src_*() function which you had
to modify a bit with version bump. To be absolutely sure that you have
not broke anything you'll have to check all versions of the package or
there are chances that you broke stable tree and have not noticed that.
Of course the same stands for eclasses. The difference between PPE and
global eclasses is that 1. PPE covers less packages and it'll take
longer to notice that error 2. per-package things are changing more
rapidly and thus more changes to PPE will be required. All this means
that we'll have more breakages. So what are the benefits to overbalance
this minuses?

-- 
Peter.




Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Peter Volkov
В Вск, 30/11/2008 в 17:09 +0200, Serkan Kaba пишет:
 Peter Volkov yazmış:
  Also sometimes it's useful to have different HOMEPAGE for different
  versions.
  
  And in general, Diego. What are you trying to improve with this change?
  The original intention was to separate common information from all
  ebuilds into metadata.xml. But obviously, HOMEPAGE changes from ebuild
  to ebuild. Now if intention is separate some information from ebuild
  into metadata.xml then, please, tell me what is the criterion for such
  information? Why not LICENSE? Currently I don't think this change worth
  our efforts...
  
 LICENSE should definetely be avoided to be defined per-package. Upstream
 may decide to relicense new version of packages.

Well, actually the reason we should avoid LICENSES in metadata.xml is
that it's used by portage and possibly at some point of time it'll be
possible to filter packages based on LICENSE. But the general question
still stands: what is the criterion we should use to separate variables
from .ebuild into metadata.xml and what are the benefits of such
separation?

-- 
Peter.




Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Ciaran McCreesh
On Sun, 30 Nov 2008 19:50:17 +0300
Peter Volkov [EMAIL PROTECTED] wrote:
 В Вск, 30/11/2008 в 16:10 +0100, Santiago M. Mola пишет:
  per-package eclasses [1].
  That way, it would be easy to avoid duplication of not only
  HOMEPAGE but also SRC_URI, LICENSE, or any other part of an ebuild.
 
 Having per-package eclasses (PPE) just to set common HOMEPAGE is
 definitely overkill. What other reasons for PPE to exist?

In an awful lot of cases, there's a very high degree of code overlap
between ebuild versions.

 If you want to separate common code, then PPE is very dangerous.
 
 Take for example ebuilds which share same src_*() function which you
 had to modify a bit with version bump. To be absolutely sure that you
 have not broke anything you'll have to check all versions of the
 package or there are chances that you broke stable tree and have not
 noticed that. Of course the same stands for eclasses. The difference
 between PPE and global eclasses is that 1. PPE covers less packages
 and it'll take longer to notice that error 2. per-package things are
 changing more rapidly and thus more changes to PPE will be required.
 All this means that we'll have more breakages. So what are the
 benefits to overbalance this minuses?

You appear to be assuming that Gentoo developers are careless and
incompetent. The ebuild format already gives developers more than
enough rope to hang themselves and every single user -- per package
eclasses don't alter this in any way.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Joe Peterson
Marius Mauch wrote:
 By default, messages generated by elog, ewarn and eerror are recorded
 in /var/log/portage/elog/summary.log (emerge.log is just a
 transaction log, so best to ignore it here). einfo isn't recorded on
 purpose as it isn't intended for important information (that's the
 purpose of elog). There are some tools available to simplify reading
 these messages, and there several additional/alternative delivery
 modules available (by mail, IM or in package specific files),
 customizable via POTAGE_ELOG_* variables. Don't know if you just
 haven't been aware of this, or if you're asking for something
 completely different.

I'm really proposing something different - in essence, the above is to
obscure to really serve as a good official kind of readme source for
users.  There needs to be something simple and straightforward (and
well-documented) as the official thing to look at if one is having
trouble with a package.  In the case I mentioned all it took was for
that user to see the messages, but it did not occur to him that the info
would be there.  I could even imagine that einfo should be included in
what I am suggesting, since it may not be important for logging, but
might be nice to have, nonetheless.

-Joe



Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Peter Volkov
Seems that we already have everything you dreamed about: 

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=1#doc_chap4

Take a look at PORTAGE_ELOG_SYSTEM. It even can send that messages by
mail :)

HTH,
--
Peter.

В Вск, 30/11/2008 в 09:25 -0700, Joe Peterson пишет:
 Bottom line here is that there is extremely valuable and critical info
 in our emerge output.  In a way, these messages are like Gentoo-specific
 READMEs (or release notes and/or install instructions).  However, it is
 not saved for a user to use as a resource later (well, except that it is
 partially saved in the master emerge.log, but that's not quite useful
 enough).  There is no official place to go to look for Gentoo
 instructions; /usr/share/doc is one logical place, but it only contains
 files actually installed, not the notes output by emerge (and these are
 usually upstream-supplied, not Gentoo).
 
 I propose that, upon merging a package, we save the emerge messages in
 either: 1) a package-specific file that resides somewhere official or
 2) in the portage DB, so that the messages can be re-read via a portage
 utility.  In the latter case, either a new option to equery or a new
 q command (e.g. equery readme pkg or qreadme pkg could
 retrieve the text).
 
 In either case, there would then be a place to go that is known and
 consistent (and can be documented in the Gentoo doc).  It could, in
 essense, serve as a kind of Gentoo package README collection.  I could
 also imagine later expanding on this by letting a given package also
 include more thorough README info from a file if the maintainer so desires.





Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Joe Peterson
Peter Volkov wrote:
 Seems that we already have everything you dreamed about: 
 
 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=1#doc_chap4
 
 Take a look at PORTAGE_ELOG_SYSTEM. It even can send that messages by
 mail :)

This is all cool, indeed!  :)

I suspect, however, that most users have never played with these
variables.  I think that saving this info in the portage db or making it
more default/official in some way could be a great help.  The core
problem is, I think, that many users do not know where to look when
having trouble, so they may not even realize that what they need is in
the log info.

The reason I was phrasing it more in readme terms is that most people
can identify with that concept, and it could be made clear that there
exists Gentoo-specific readme info that is always available (regardless
of whether a user sets up the portage logging stuff).  The bare log
messages could exist as a minimal default for packages that do nothing
special to provide more readme info.

-Joe



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Peter Volkov
В Вск, 30/11/2008 в 16:54 +, Ciaran McCreesh пишет:
 On Sun, 30 Nov 2008 19:50:17 +0300
 Peter Volkov [EMAIL PROTECTED] wrote:
  В Вск, 30/11/2008 в 16:10 +0100, Santiago M. Mola пишет:
   per-package eclasses [1].
   That way, it would be easy to avoid duplication of not only
   HOMEPAGE but also SRC_URI, LICENSE, or any other part of an ebuild.
  
  Having per-package eclasses (PPE) just to set common HOMEPAGE is
  definitely overkill. What other reasons for PPE to exist?
 
 In an awful lot of cases, there's a very high degree of code overlap
 between ebuild versions.

So? Is size a big problem? If not then again what problem are you trying
to solve?

Don't mix good programming practice of with good ebuild maintenance
practice. They are solving different problems and that's why they are
different.

Commited ebuild corresponds to the package of some version. It was
written, tested and released (commited). Now never touch it without real
necessity even indirectly through PPE. If you wish to improve package do
that in ~arch tree.

If you wish to make ebuilds writing closer to the programming practice
then yes! There is similarity: being a good upstream you never touch
already released tarbals.

And yes. we still have eclasses but they are exceptions and that is why
we have exceptional rule for handling them: review on -dev before
commit. Should we have same rule for PPE?


  If you want to separate common code, then PPE is very dangerous.
  
  Take for example ebuilds which share same src_*() function which you
  had to modify a bit with version bump. To be absolutely sure that you
  have not broke anything you'll have to check all versions of the
  package or there are chances that you broke stable tree and have not
  noticed that. Of course the same stands for eclasses. The difference
  between PPE and global eclasses is that 1. PPE covers less packages
  and it'll take longer to notice that error 2. per-package things are
  changing more rapidly and thus more changes to PPE will be required.
  All this means that we'll have more breakages. So what are the
  benefits to overbalance this minuses?
 
 You appear to be assuming that Gentoo developers are careless and
 incompetent. The ebuild format already gives developers more than
 enough rope to hang themselves and every single user -- per package
 eclasses don't alter this in any way.

Nope, I assume we are all humans and even careful people do mistakes. If
package works do not to touch it.

-- 
Peter.




[gentoo-dev] Re: [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Ryan Hill
On Sun, 30 Nov 2008 10:11:49 -0700
Joe Peterson [EMAIL PROTECTED] wrote:

 Peter Volkov wrote:
  Seems that we already have everything you dreamed about: 
  
  http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=1#doc_chap4
  
  Take a look at PORTAGE_ELOG_SYSTEM. It even can send that messages
  by mail :)
 
 This is all cool, indeed!  :)
 
 I suspect, however, that most users have never played with these
 variables.  I think that saving this info in the portage db or making
 it more default/official in some way could be a great help.  The core
 problem is, I think, that many users do not know where to look when
 having trouble, so they may not even realize that what they need is in
 the log info.

How more official can you get?  :P  By default we do save the logs, and
we provide a complete logging facility that can even log to syslog,
mail them to you, or run arbitrary commands.  We link to the
build log on build failure.  We reprint all log messages at the end of
the emerge by default.  If the user ignores these, and doesn't read the
manual, then...

I think educating the user about systems we already have in place beats
adding new ones.


-- 
gcc-porting,  by design, by neglect
treecleaner,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Ciaran McCreesh
On Sun, 30 Nov 2008 21:07:00 +0300
Peter Volkov [EMAIL PROTECTED] wrote:
  In an awful lot of cases, there's a very high degree of code overlap
  between ebuild versions.
 
 So? Is size a big problem? If not then again what problem are you
 trying to solve?

Code duplication is a big problem.

 Commited ebuild corresponds to the package of some version. It was
 written, tested and released (commited). Now never touch it without
 real necessity even indirectly through PPE. If you wish to improve
 package do that in ~arch tree.
 
 If you wish to make ebuilds writing closer to the programming practice
 then yes! There is similarity: being a good upstream you never touch
 already released tarbals.

You're under the mistaken impression that people will go back and
retroactively change existing ebuilds. This won't happen -- if nothing
else, because it's an EAPI bump.

 And yes. we still have eclasses but they are exceptions and that is
 why we have exceptional rule for handling them: review on -dev before
 commit. Should we have same rule for PPE?

Really, I'd like to see *every* non-trivial new ebuild or major change
on bumps reviewed. But that's not going to happen...

  You appear to be assuming that Gentoo developers are careless and
  incompetent. The ebuild format already gives developers more than
  enough rope to hang themselves and every single user -- per package
  eclasses don't alter this in any way.
 
 Nope, I assume we are all humans and even careful people do mistakes.
 If package works do not to touch it.

We're talking for new packages, not for retroactively going and making
everything in the tree EAPI 3.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Steve Dibb

Peter Volkov wrote:

В В�к, 30/11/2008 в 14:50 +0100, Tobias Scherbaum пишет:

In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
Does someone have an example where older versions stay at an old homepage
and newer versions moved to a new homepage?


Yes. This is quite a common case when one upstream stopped development
of the package and new developer took it. traceroute, flow-tools are
just examples from the top of my head. I remember I saw more such
things...


Add libdvdread to the list.  Same as others, newer version is a forked one.

Steve



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Alec Warner
On Sun, Nov 30, 2008 at 8:53 AM, Peter Volkov [EMAIL PROTECTED] wrote:
 В Вск, 30/11/2008 в 17:09 +0200, Serkan Kaba пишет:
 Peter Volkov yazmış:
  Also sometimes it's useful to have different HOMEPAGE for different
  versions.
 
  And in general, Diego. What are you trying to improve with this change?
  The original intention was to separate common information from all
  ebuilds into metadata.xml. But obviously, HOMEPAGE changes from ebuild
  to ebuild. Now if intention is separate some information from ebuild
  into metadata.xml then, please, tell me what is the criterion for such
  information? Why not LICENSE? Currently I don't think this change worth
  our efforts...
 
 LICENSE should definetely be avoided to be defined per-package. Upstream
 may decide to relicense new version of packages.

 Well, actually the reason we should avoid LICENSES in metadata.xml is
 that it's used by portage and possibly at some point of time it'll be
 possible to filter packages based on LICENSE. But the general question
 still stands: what is the criterion we should use to separate variables
 from .ebuild into metadata.xml and what are the benefits of such
 separation?

Going to randomly jump in, partially because I have a comment here.

Ebuilds are already filterable by license in portage, Marius
implemented that a while ago.  I'm sure the other package managers
have similar filtering abilities.

To the general thread:

Anecdotal evidence is stupid.  No one cares if one of your packages
has a different homepage per version.
Go scan the tree and show how many packages have this problem and we
can at least have useful data then (X% of the tree).

Zac, if we ask you to prioritize elibs, how long do you think
implementation will take?

Diego, What are the concrete benefits of your proposal?

All,

It is important to note that we are a large diverse group of folks and
when you propose global changes you have to be willing to sell your
idea to a large number of folks or implement it alone.  Coming to a
list with no data and no real 'pros/cons' data for your idea isn't not
a good way to sell it to anyone.

However cool the idea is, it is *never* obvious to everyone.  It is
never cost free.

-Alec


 --
 Peter.





Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Alec Warner
On Sun, Nov 30, 2008 at 9:11 AM, Joe Peterson [EMAIL PROTECTED] wrote:
 Peter Volkov wrote:
 Seems that we already have everything you dreamed about:

 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=1#doc_chap4

 Take a look at PORTAGE_ELOG_SYSTEM. It even can send that messages by
 mail :)

 This is all cool, indeed!  :)

 I suspect, however, that most users have never played with these
 variables.  I think that saving this info in the portage db or making it
 more default/official in some way could be a great help.  The core
 problem is, I think, that many users do not know where to look when
 having trouble, so they may not even realize that what they need is in
 the log info.

I suspect that no one really disagrees with more communication; but I
imagine many are not willing to put time into it.

So I suggest you come up with better ideas to communicate to users
about the existing logging solutions and then
implement them ;)

The gentoo homepage is one way, the GMN is another, Forums is a third.
 Just write one article about it and publish it everywhere.
Also Gentoo-Wiki ;)

-Alec


 The reason I was phrasing it more in readme terms is that most people
 can identify with that concept, and it could be made clear that there
 exists Gentoo-specific readme info that is always available (regardless
 of whether a user sets up the portage logging stuff).  The bare log
 messages could exist as a minimal default for packages that do nothing
 special to provide more readme info.

-Joe





Re: [gentoo-dev] Time to say goodbye

2008-11-30 Thread Matti Bickel
I normally don't do that. But i have to echo dertobi123 here. Sad to see
you go, Marius. I wish you all the best in your future endavours. May
the force be with you.

You've been inspiring in your rational arguments and analysis as well as
in the quality and quantity of your contributions. Thank you.

And i'll see to fulfill my promise to get gentoo-stats going.

See you on the other side (or some other event around here).
-- 
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)


pgpl5mKjPyzyw.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread James Cloos
If it does move to metadata, it will need to be copied into /var/db on
install.  It is important information which should not be lost if the
package is ever removed from portage.

-JimC
-- 
James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Ulrich Mueller
 On Sun, 30 Nov 2008, James Cloos wrote:

 If it does move to metadata, it will need to be copied into /var/db
 on install.  It is important information which should not be lost if
 the package is ever removed from portage.

Also, a scan shows that there are about 400 ebuilds in the tree that
access the ${HOMEPAGE} variable. For example, it is used to output
messages in fetch-restricted packages.

Ulrich



[gentoo-dev] Re: Proposal for how to handle stable ebuilds

2008-11-30 Thread Ryan Hill
On Mon, 10 Nov 2008 13:13:34 -0500
Mark Loeser [EMAIL PROTECTED] wrote:

 Instead of addressing archs as being slackers or not, this addresses
 it as a more granular layer of looking at ebuilds.  Thanks to Richard
 Freeman for the initial proposal that I based this off of.  Please
 give me feedback on this proposal, if you think it sucks (preferably
 with an explanation why), or if you think it might work.
 
 Ebuild Stabilization Time
 
 Arch teams will normally have 30 days from the day a bug was filed,
 keyworded STABLEREQ, the arch was CCed, and the maintainer either
 filed the bug or commented that it was OK to stabilize (clock starts
 when all of these conditions are met).
 
 Security bugs are to be handled by the policies the Security Team has
 established.
 
 Technical Problems with Ebuild Revisions
 
 If an arch team finds a technical problem with an ebuild preventing
 stabilization, a bug will be logged as a blocker for the keyword
 request.  The bug being resolved resets the time for the 30 days the
 arch team has to mark the ebuild stable.
 
 Removing Stable Ebuilds
 
 If an ebuild meets the time criteria above, and there are no
 technical issues preventing stabilization, then the maintainer MAY
 choose to delete an older version even if it is the most recent
 stable version for a particular arch.
 
 If an ebuild meets the time criteria above, but there is a technical
 issue preventing stabilization, and there are no outstanding security
 issues, then the maintainer MUST not remove the highest-versioned
 stable ebuild for any given arch without the approval of the arch
 team.
 
 Security issues are to be handled by the recommendations of the
 Security Team.
 
 Spirit of Cooperation
 
 Ebuild maintainer and arch teams are encouraged to work together for
 the sake of each other and end users in facilitating the testing and
 maintenance of ebuilds on obscure hardware, or where obscure
 expertise is needed.  Package maintainers are encouraged to use
 discretion when removing ebuilds in accordance with this policy.

Since I completely stalled out this conversation I guess it's only fair
that I try to restart it.  I'm in favor of the above.

I know it's not directly related to stabilization, but lately people
have been removing the only keyworded package for the mips arch, under
the excuse that's it's been over 30 days since they opened a keywording
bug.  This has been happening on bugs where there are technical issues
and on bugs where we just haven't replied (in which case i can see the
justification).  I don't think this is acceptable, just as I don't
think removing the only stable version of a package on an arch is
be acceptable, barring the circumstances Mark outlined above.

Yes?  No?  Get out of our treehouse?


-- 
gcc-porting,  by design, by neglect
treecleaner,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò
Alec Warner [EMAIL PROTECTED] writes:

 Diego, What are the concrete benefits of your proposal?

As I said:

- no need to replicate homepage data between versions; even though forks
  can change homepage, I would expect that to at worse split in two a
  package, or have to be different by slot, like Java;
- allows proper handling of packages lacking a HOMEPAGE;
- less data in metadata cache;
- users can check the metadata much more easily by just opening the xml
  file or interfacing to that rather than having to skim through the
  ebuild, the xml files are probably more user readable then ebuilds
  using multiple eclasses;
- displaying info about the package does not require parsing the full
  ebuild file, with its eclasses;
- extensible to provide more links than just the homepage (forums,
  trackers, gentoo-specific documentation, ...);
- if we also move DESCRIPTION, search software can ignore everything
  about ebuild parsing, and just use the metadata.xml files; considering
  how many people actually use or used eix, it would make sense to allow
  third-party applications to be able to search through the tree;
- webapps like packages.gentoo.org would be able to display basic
  information without having to parse the ebuilds or the metadata cache.
- as much as people might think metadata is easier to parse than
  anything, XML has one huge advantage: there are plently of parsers for
  any language without having to actually write one, even as easy as it
  can be, and it's easily interfaced with anything; I wrote a simple XSL
  file that outputs the basic metadata details for packages without
  having any parser or executable code but xsltproc (or any other XSLT
  software), correlating data with herds.xml too;
- it really is metadata, and it makes very little sense to need parsing
  of eclasses and EAPI handling to get some data from a package that is
  non-functional in nature and free form (just like DESCRIPTION, and
  unlike LICENSE like Alec said), and that changes at worse once each
  slot (unlike LICENSE that can change at any given version).

Disadvantages:

- it requires user-interface software to parse metadata.xml to show
  data for a package; which is already needed to show per-package USE
  flag meaning;

General points:

- it does not solve unrelated problems like code replication;

Can someone come up with any other point beside I don't like XML
(which I already said is a puny answer) and it can theorically be 10
different homepages for 10 different versions (which I have sincerely
some beef with myself since if you fork a software you might as well
change its name)?

As I said, moving out the HOMEPAGE field from a package manager
prospective is non functional; if you're showing to the user some data
about a package you might as well show as much as you can, like long
descriptions, other links, and USE flags. And the fact that you can ask
the package manager for something is for me not a valid reason to avoi
moving something in a more approchable place for other software.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpJevDGzJEf0.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Jan Kundrát

Diego 'Flameeyes' Pettenò wrote:

- no need to replicate homepage data between versions; even though forks
  can change homepage, I would expect that to at worse split in two a
  package, or have to be different by slot, like Java;


But also the need to replicate http://www.kde.org/ to metadata.xml of 
all KDE split ebuilds -- right now, this is set by an eclass.



- allows proper handling of packages lacking a HOMEPAGE;


Could you elaborate a bit about how different is handling of an 
empty/uninitialized shell variable from an empty XML element?



- less data in metadata cache;


Isn't it in the cache for some reason? Really, I'm just asking.


- users can check the metadata much more easily by just opening the xml
  file or interfacing to that rather than having to skim through the
  ebuild, the xml files are probably more user readable then ebuilds
  using multiple eclasses;


Haven't we already agreed that accessing ebuilds/... directly is broken 
by design?



- webapps like packages.gentoo.org would be able to display basic
  information without having to parse the ebuilds or the metadata cache.


Except for the ebuilds which still use the old format (that is 100% of 
the tree right now)


Cheers,
-jkt

--
cd /local/pub  more beer  /dev/mouth



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-11-30 23h59 UTC

2008-11-30 Thread Robin H. Johnson
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2008-11-30 23h59 UTC.

Removals:
net-dns/posadis 2008-11-26 17:04:29 matsuu
net-dns/dnsquery2008-11-26 17:08:12 matsuu
net-dns/mfedit  2008-11-26 17:08:12 matsuu
dev-cpp/poslib  2008-11-26 17:09:13 matsuu
x11-misc/e16menuedit2008-11-30 00:22:31 vapier

Additions:
media-sound/mpdas   2008-11-24 00:14:10 yngwin
app-i18n/adaptit2008-11-24 06:00:45 kanaka
net-analyzer/nagstamon  2008-11-24 19:42:37 dertobi123
dev-libs/libgamin   2008-11-24 23:07:56 eva
app-admin/gam-server2008-11-24 23:10:29 eva
app-cdr/mp3burn 2008-11-25 09:58:46 ssuominen
dev-dotnet/gnome-keyring-sharp  2008-11-25 13:45:42 loki_val
dev-dotnet/notify-sharp 2008-11-25 14:22:25 loki_val
dev-ruby/ruby-shadow2008-11-25 16:49:46 caleb
dev-dotnet/gnome-desktop-sharp  2008-11-26 00:56:15 loki_val
dev-dotnet/gnome-panel-sharp2008-11-26 00:56:37 loki_val
dev-dotnet/gnome-print-sharp2008-11-26 00:56:59 loki_val
dev-dotnet/nautilusburn-sharp   2008-11-26 00:58:56 loki_val
dev-dotnet/wnck-sharp   2008-11-26 01:00:06 loki_val
games-simulation/secondlife-bin 2008-11-27 06:39:18 lavajoe
net-wireless/wireless-regdb 2008-11-27 15:21:50 chainsaw
net-wireless/crda   2008-11-27 15:27:20 chainsaw
dev-python/reverend 2008-11-28 01:39:20 neurogeek
dev-libs/cygwin 2008-11-28 09:21:44 vapier
media-libs/glpng2008-11-28 19:57:34 scarabeus
net-wireless/bluez  2008-11-28 21:21:35 dev-zero
sys-fs/dmg2img  2008-11-29 16:01:16 josejx
app-emacs/emacs-daemon  2008-11-30 10:43:39 ulm

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
net-dns/posadis,removed,matsuu,2008-11-26 17:04:29
net-dns/dnsquery,removed,matsuu,2008-11-26 17:08:12
net-dns/mfedit,removed,matsuu,2008-11-26 17:08:12
dev-cpp/poslib,removed,matsuu,2008-11-26 17:09:13
x11-misc/e16menuedit,removed,vapier,2008-11-30 00:22:31
Added Packages:
media-sound/mpdas,added,yngwin,2008-11-24 00:14:10
app-i18n/adaptit,added,kanaka,2008-11-24 06:00:45
net-analyzer/nagstamon,added,dertobi123,2008-11-24 19:42:37
dev-libs/libgamin,added,eva,2008-11-24 23:07:56
app-admin/gam-server,added,eva,2008-11-24 23:10:29
app-cdr/mp3burn,added,ssuominen,2008-11-25 09:58:46
dev-dotnet/gnome-keyring-sharp,added,loki_val,2008-11-25 13:45:42
dev-dotnet/notify-sharp,added,loki_val,2008-11-25 14:22:25
dev-ruby/ruby-shadow,added,caleb,2008-11-25 16:49:46
dev-dotnet/gnome-desktop-sharp,added,loki_val,2008-11-26 00:56:15
dev-dotnet/gnome-panel-sharp,added,loki_val,2008-11-26 00:56:37
dev-dotnet/gnome-print-sharp,added,loki_val,2008-11-26 00:56:59
dev-dotnet/nautilusburn-sharp,added,loki_val,2008-11-26 00:58:56
dev-dotnet/wnck-sharp,added,loki_val,2008-11-26 01:00:06
games-simulation/secondlife-bin,added,lavajoe,2008-11-27 06:39:18
net-wireless/wireless-regdb,added,chainsaw,2008-11-27 15:21:50
net-wireless/crda,added,chainsaw,2008-11-27 15:27:20
dev-python/reverend,added,neurogeek,2008-11-28 01:39:20
dev-libs/cygwin,added,vapier,2008-11-28 09:21:44
media-libs/glpng,added,scarabeus,2008-11-28 19:57:34
net-wireless/bluez,added,dev-zero,2008-11-28 21:21:35
sys-fs/dmg2img,added,josejx,2008-11-29 16:01:16
app-emacs/emacs-daemon,added,ulm,2008-11-30 10:43:39

Done.

Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Ciaran McCreesh
On Mon, 01 Dec 2008 00:12:23 +0100
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote:
 - no need to replicate homepage data between versions; even though
 forks can change homepage, I would expect that to at worse split in
 two a package, or have to be different by slot, like Java;

You mean no way of handling generated homepages, use conditional
homepages, per version homepages or common homepages.

 - allows proper handling of packages lacking a HOMEPAGE;

Uh, we can do that using in-ebuild HOMEPAGE too. Just need to decide on
a convention.

 - less data in metadata cache;

Entirely a non-issue. Heck, we want more in there, not less. 

 - users can check the metadata much more easily by just opening the
 xml file or interfacing to that rather than having to skim through the
   ebuild, the xml files are probably more user readable then ebuilds
   using multiple eclasses;

...or they can just use a decent too. Try 'paludis --query' for an
example.

 - displaying info about the package does not require parsing the full
   ebuild file, with its eclasses;

Uhm. It doesn't anyway, because of the metadata cache.

 - extensible to provide more links than just the homepage (forums,
   trackers, gentoo-specific documentation, ...);

So's HOMEPAGE. You could extend the syntax to allow annotations:

HOMEPAGE=
http://example.com/
http://forums.example.com/ [[ role = forums ]]
http://www.gentoo.org/example [[ role = [ Gentoo specific docs ] ]]
gtk+? ( http://gui.example.com/ [[ role = [ Optional GUI docs ] ]]


 - if we also move DESCRIPTION, search software can ignore everything
   about ebuild parsing, and just use the metadata.xml files;
 considering how many people actually use or used eix, it would make
 sense to allow third-party applications to be able to search through
 the tree;

Except that any decent search client needs to be aware of masks,
visibility and so on anyway.

 - webapps like packages.gentoo.org would be able to display basic
   information without having to parse the ebuilds or the metadata
 cache.

But they already display complex information.

 - as much as people might think metadata is easier to parse than
   anything, XML has one huge advantage: there are plently of parsers
 for any language without having to actually write one, even as easy
 as it can be, and it's easily interfaced with anything; I wrote a
 simple XSL file that outputs the basic metadata details for packages
 without having any parser or executable code but xsltproc (or any
 other XSLT software), correlating data with herds.xml too;

...or you could use a proper ebuild-aware tool that displays metadata
details, including things like visibility. Again, paludis --query.

 - it really is metadata, and it makes very little sense to need
 parsing of eclasses and EAPI handling to get some data from a package
 that is non-functional in nature and free form (just like
 DESCRIPTION, and unlike LICENSE like Alec said), and that changes at
 worse once each slot (unlike LICENSE that can change at any given
 version).

It isn't non-functional.

 And the fact that you can ask the package manager for something is
 for me not a valid reason to avoi moving something in a more
 approchable place for other software.

More approachable is a decent package manager API. If you had that
you wouldn't need to mess around with XML APIs.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Dale
Joe Peterson wrote:
 Peter Volkov wrote:
   
 Seems that we already have everything you dreamed about: 

 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=1#doc_chap4

 Take a look at PORTAGE_ELOG_SYSTEM. It even can send that messages by
 mail :)
 

 This is all cool, indeed!  :)

 I suspect, however, that most users have never played with these
 variables.  I think that saving this info in the portage db or making it
 more default/official in some way could be a great help.  The core
 problem is, I think, that many users do not know where to look when
 having trouble, so they may not even realize that what they need is in
 the log info.

 The reason I was phrasing it more in readme terms is that most people
 can identify with that concept, and it could be made clear that there
 exists Gentoo-specific readme info that is always available (regardless
 of whether a user sets up the portage logging stuff).  The bare log
 messages could exist as a minimal default for packages that do nothing
 special to provide more readme info.

   -Joe


   

If you have a GUI on your system, give this a look: 
app-portage/elogviewer  That should help you a lot.  I been using it for
a good while and it works pretty well.  I do wish it had little flags in
the list of packages that have been installed.  Sort of a short and
sweet  notice there is something there without actually have to look. 
Maybe a red flag when there is something really serious to know and
other colors for other things.

Anyway, give that a look and see if that helps, if you have  a GUI.

Dale

:-)  :-) 


Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Alec Warner
On Sun, Nov 30, 2008 at 3:12 PM, Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
 Alec Warner [EMAIL PROTECTED] writes:

 Diego, What are the concrete benefits of your proposal?

 As I said:

 - no need to replicate homepage data between versions; even though forks
  can change homepage, I would expect that to at worse split in two a
  package, or have to be different by slot, like Java;
 - allows proper handling of packages lacking a HOMEPAGE;
 - less data in metadata cache;
 - users can check the metadata much more easily by just opening the xml
  file or interfacing to that rather than having to skim through the
  ebuild, the xml files are probably more user readable then ebuilds
  using multiple eclasses;
 - displaying info about the package does not require parsing the full
  ebuild file, with its eclasses;
 - extensible to provide more links than just the homepage (forums,
  trackers, gentoo-specific documentation, ...);
 - if we also move DESCRIPTION, search software can ignore everything
  about ebuild parsing, and just use the metadata.xml files; considering
  how many people actually use or used eix, it would make sense to allow
  third-party applications to be able to search through the tree;
 - webapps like packages.gentoo.org would be able to display basic
  information without having to parse the ebuilds or the metadata cache.
 - as much as people might think metadata is easier to parse than
  anything, XML has one huge advantage: there are plently of parsers for
  any language without having to actually write one, even as easy as it
  can be, and it's easily interfaced with anything; I wrote a simple XSL
  file that outputs the basic metadata details for packages without
  having any parser or executable code but xsltproc (or any other XSLT
  software), correlating data with herds.xml too;
 - it really is metadata, and it makes very little sense to need parsing
  of eclasses and EAPI handling to get some data from a package that is
  non-functional in nature and free form (just like DESCRIPTION, and
  unlike LICENSE like Alec said), and that changes at worse once each
  slot (unlike LICENSE that can change at any given version).

 Disadvantages:

 - it requires user-interface software to parse metadata.xml to show
  data for a package; which is already needed to show per-package USE
  flag meaning;

 General points:

 - it does not solve unrelated problems like code replication;

 Can someone come up with any other point beside I don't like XML
 (which I already said is a puny answer) and it can theorically be 10
 different homepages for 10 different versions (which I have sincerely
 some beef with myself since if you fork a software you might as well
 change its name)?

 As I said, moving out the HOMEPAGE field from a package manager
 prospective is non functional; if you're showing to the user some data
 about a package you might as well show as much as you can, like long
 descriptions, other links, and USE flags. And the fact that you can ask
 the package manager for something is for me not a valid reason to avoi
 moving something in a more approchable place for other software.

Ciaran covered most of my points already.

Third party programs should not parse ebuilds and eclasses by hand.
I'd expect half of them to get it wrong if they tried.
Ebuild parsing is hard, that is why we have three complex software
packages that for the most part do it properly.

Why is 'ask the package manager' an invalid reason to not making
something more accessible?
How accessible must this data be?

Writing an XML parser is not accessible enough (for me), we should
just put it in plain text on the hard drive, perhaps in
/var/cache/edb/dep/${PORTDIR}/$C/$PV

Oh wait, we do that already[1].

So really this is where I'm confused.
If third parties are using the package manager APIs to get at this
data; the only rationale to move it out of ebuilds is:

- Space savings.  Certainly your scheme may be smaller, but the XML
tag overhead may eat into the savings.  You should do some estimates
to show the community how much smaller the tree will be from this
proposal.

Randomly looking:

cd /var/cache/edb/dep/usr/portage
grep -hR HOMEPGE | wc -m
yields 1.1million characters.  Each character is 1 byte (is that so in UTF8?)
So at best you could save the 1.2GB tree 2.2 million bytes (about 2
megs) if your scheme was (more than) 100% efficient.
The extra 1.1 million characters comes from the space freed in the
cache (since we don't cache metadata.xml).

2 megs into 1200 megs is.. .16% of the tree.  As I thought, not
very compelling.

Looking at DESCRIPTION:

grep -hR DESCRIPTION | wc -m
yields ~1.5 million characters.  Nice!

So if we purge that from the cache and replace it with a (more than)
100% efficient metadata.xml solution we could save: 3 megs

3 megs saved + 2 megs saved = 5 megs saved.  5 / 1200 = .41% of
the tree.  Still again not very compelling.

- Extra Tags.  Extending HOMEPAGE is harder than 

Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Ben de Groot
Joe Peterson wrote:
 Peter Volkov wrote:
 Seems that we already have everything you dreamed about: 

 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=1#doc_chap4

 Take a look at PORTAGE_ELOG_SYSTEM. It even can send that messages by
 mail :)
 
 This is all cool, indeed!  :)
 
 I suspect, however, that most users have never played with these
 variables.  I think that saving this info in the portage db or making it
 more default/official in some way could be a great help.  The core
 problem is, I think, that many users do not know where to look when
 having trouble, so they may not even realize that what they need is in
 the log info.

The info is there, but most users never read more than part 1 of the
Handbook (that is, the installation part). We could, and should in my
opinion, add a big fat warning towards the end of the installation part,
that there is extremely useful information to be found in the other
parts of the Handbook. Maybe we could especially mention some of the
more useful topics, and the elog system would be one of them.

-- 
Ben de Groot
Gentoo Linux developer (lxde, media, desktop-misc)
Gentoo Linux Release Engineering PR liaison
__

[EMAIL PROTECTED]
http://ben.liveforge.org/
irc://chat.freenode.net/#gentoo-media
irc://irc.oftc.net/#lxde
__




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] debug/release builds extensions/clarification proposal

2008-11-30 Thread Maciej Mrozowski
Hi

I would like to give some idea into consideration.

Abstract
In short, adding following new variables to make.conf and implement handling 
of them in eclasses:
- CFLAGS_DEBUG (and friends like CXXFLAGS_DEBUG) - use defined debug compiler 
flags - by default set to -O0 -ggdb (and maybe -Wall as well)
- LDFLAGS_DEBUG - user defined debug linker flags - default to ${LDFLAGS}
- FEATURES_DEBUG - default to ${FEATURES} nostrip (or splidebug, according 
to preference)

Background
Currently handling debug/release builds is incoherent and misleading to say 
the least. We have got in Gentoo:
- CFLAGS/LDFLAGS - user needs to take care of adding -O0 and/or -ggdb
- user needs to take care of FEATURES=nostrip or FEATURES=splitdebug (not 
both)
- user may set debug USE flag

The drawbacks are as follows:
- USE=debug is useless  when CFLAGS/LDFLAGS or FEATURES are not appropriate
- CFLAGS/LDFLAGS must be set globally when they are about to be supported
- those who don't want to set them globally, they are forced to use (very 
flexible and great indeed) /etc/portage/env hack - which is undocumented and 
unsupported, because everything user set there, is not shown by emerge --info, 
thus bug reports from such machines  are not taken into consideration, as 
virtually everything that breaks can be there
- too much choice leads to confusion, and many users who enabled some of those 
(but not all), still don't get useful backtraces and only fool themselves when 
reporting something upstream.

Motivation:
The idea is modeled after handling such situations in CMake build system. I'm 
one of contributors to official Gentoo KDE team experimental overlay (kde-
crazy) and we provide live ebuilds and betas/snapshots for KDE4 and related 
applications. It's quite probable that many of our users participate in KDE 
testing, it's vital to provide for them an easy way of setting up testing box 
(though it's not the motive here).
KDE4 uses CMake as build system and CMake out-of-the-box provides build 
configurations: Release, Debug, RelWithDebInfo, MinSizeRel (one can easily 
figure out what they mean). For typical use, user doesn't want nor needs more 
than two configurations - let's call them Release and Debug - it fits in 
existing USE=debug handling scheme, where there are two build types with 
release as default. Overlay team and Gentoo KDE developers already make use 
of this feature and we provide debug USE flag for all KDE4 packages. The 
motive is to make handling build type in more coherent, predictable and less 
confusing way and I guess this proposal addresses it quite well.

Implementation:
Implementation would be provided by build system eclasses - for far cmake 
eclasses could benefit from this extension, though new USE=debug capable 
eclass could be introduced for other build systems (including autotools). 
Implementation is trivial - eclass would be responsible for handling USE=debug 
flag, when debug is set:
- replace CFLAGS with CFLAGS_DEBUG, LDFLAGS with LDFLAGS_DEBUG and possibly 
others
- replace FEATURES with FEATURES_DEBUG
Implementation could as well automatically add debug to IUSE as well - 
specific packages that are not interested in such flag - would just override 
IUSE in its ebuilds.
For cmake-utils - handling debug IUSE is already done, only replacing 
CFLAGS/LDFLAGS/FEATURES would be requited.
For autoconf based packages - some of them already provide 'support' for debug 
builds ('a'ka --enable-debug), but making use of debug USE would need special 
support here or separate eclass that could be introduced for packages that can 
benefit. If could be as well enforced globally (by adding either --enable-
debug or --disable-debug apart from switching CFLAGS - as confgiure scipt 
ignores unknown arguments) but that's just a matter or implementation.

Backward compatibility
As extension operates on newly introduced variables - backward compatibility 
is preserved. Backward compatibility may be broken for those who utilize 
/etc/portage/env hack as strange compiler/iinker flag/FEATURE combinations may 
appear.

In similar scheme more build profiles could be implemented, (like libs/apps 
ready for profiling) but let's leave it alone for now.

Discussion and constructive criticism is welcome :)

-- 
regards
MM



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


[gentoo-dev] Re: debug/release builds extensions/clarification proposal

2008-11-30 Thread Duncan
Maciej Mrozowski [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on  Mon, 01 Dec
2008 06:16:07 +0100:

 Implementation:
 Implementation would be provided by build system eclasses [snip]
 - replace FEATURES with FEATURES_DEBUG

FEATURES are package-manager implemented, above the bash level where 
eclasses are parsed and executed, thus for portage, at the python level.  
As such, neither /etc/portage/env nor eclasses can effectively deal with 
FEATURES in general, tho there are a few specific exceptions that do 
happen to be implemented at the bash level.

Thus, your GLEP (Gentoo Linux Enhancement Proposal) needs to specifically 
address this problem, either stating that this FEATURE can be implemented 
100% at the bash/eclass level with details, or omitting/changing the 
FEATURE portion so it will work at the bash/eclass level, or outlining 
specifically what the package manager implementation must be.  (Of 
course, if it's the latter, it will need to be an official GLEP, and 
you'll have three separate package managers and their developers to push 
the proposal thru to at least to general agreement, or the council will 
almost certainly reject the GLEP, if it gets even that far.)

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




[gentoo-dev] Re: [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Duncan
Ben de Groot [EMAIL PROTECTED] posted [EMAIL PROTECTED],
excerpted below, on  Mon, 01 Dec 2008 04:10:31 +0100:

 The info is there, but most users never read more than part 1 of the
 Handbook (that is, the installation part). We could, and should in my
 opinion, add a big fat warning towards the end of the installation part,
 that there is extremely useful information to be found in the other
 parts of the Handbook. Maybe we could especially mention some of the
 more useful topics, and the elog system would be one of them.

Well, at the end of the Handbook, Pt 1, Installation, in Chapter 12, 
Where to go from here, it already mentions Pt 2, Working with Gentoo.  It 
really should mention Pts 3  4, Working with Portage and Gentoo Network 
Configuration, as well, the chapter of interest here of course being in 
Working with Portage.

So yes, we really could improve the end of the Handbook, pt 1, Where to 
go from here, having it mention Pt 3  4 as well as Pt 2.  That's 
something we can and should do, absolutely.

Beyond that, however, Gentoo has never been about hand-holding.  It 
expects you to be big enough to cross the street on your own without 
further hand-holding if it provides the stop light telling you when it's 
safe to do so; to be able to find and read the documentation, which 
Gentoo does have a generally excellent reputation in the community for 
providing, on your own.  There are plenty of other distributions out 
there for those who prefer to let the distribution make the decisions and 
take the responsibility.  Gentoo has always been about giving the user 
the ability to decide and configure that for himself, after reading the 
documentation where necessary.  If the user can't do that after we've 
gone to all the work of providing both the means and the documentation on 
configuring, right there in the official handbook even, with links and 
references to the handbook quite well distributed already, well, maybe 
that user really /should/ be looking at a different distribution.

-- 
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] Re: Proposal for how to handle stable ebuilds

2008-11-30 Thread Peter Volkov
В Вск, 30/11/2008 в 16:59 -0600, Ryan Hill пишет:
 On Mon, 10 Nov 2008 13:13:34 -0500
 Mark Loeser [EMAIL PROTECTED] wrote:
  [proposal]

 I know it's not directly related to stabilization, but lately people
 have been removing the only keyworded package for the mips arch, under
 the excuse that's it's been over 30 days since they opened a keywording
 bug.  This has been happening on bugs where there are technical issues
 and on bugs where we just haven't replied (in which case i can see the
 justification).  I don't think this is acceptable, just as I don't
 think removing the only stable version of a package on an arch is
 be acceptable, barring the circumstances Mark outlined above.

That people should revert back that ebuilds then. Of course it's not
acceptable to remove keywords just because of one's wishes. As it was
told in this thread old ebuilds are not maintainer's concern and he/she
could touch them only after all arch teams finish their work. Until they
done all bugs in old ebuilds should be assigned on arch teams.

-- 
Peter.




[gentoo-portage-dev] Time to say goodbye

2008-11-30 Thread Marius Mauch
So, time has come for me to realize that my time with Gentoo is over. I
haven't actually been doing much Gentoo work over the last months due
to personal reasons (nothing Gentoo related), and I don't see that
situation changing in the near future. In fact I've already reassigned
or dropped most of my responsibilites in Gentoo a while ago, so there
are just a few pet projects left to give away:
- my gentoo-stats project (in the portage/gentoo-stats svn repository).
I know quite a few people are interested in the idea of collecting
various statistic data from gentoo user systems, and I'd encourage
everyone who wants to implement such a system to at least look at it (I
may have even finished it if I wouldn't have wasted my time focusing on
the wrong problems). There is quite a bit of documentation also that
should help to get you started
- a graphical security update tool (see bug #190397)

So if anyone wants to adopt those, complete or just parts, just take
them. As for Portage, Zac has practically already filled my role.

So I guess that wraps it up. It's been a nice ride most of the time,
but now it's time for me to leave the Gentoo train.

Marius




Re: [gentoo-portage-dev] Time to say goodbye

2008-11-30 Thread Andrew Gaffney

Marius Mauch wrote:

So I guess that wraps it up. It's been a nice ride most of the time,
but now it's time for me to leave the Gentoo train.


Enjoy your escape. You'll be missed.

--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead



Re: [gentoo-portage-dev] Time to say goodbye

2008-11-30 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
 So I guess that wraps it up. It's been a nice ride most of the time,
 but now it's time for me to leave the Gentoo train.
 
 Marius

Thanks for all your contributions and guidance. It's been nice
working with you. Take care of yourself.
- --
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkky574ACgkQ/ejvha5XGaM/9ACggmSozFHcmh/l6QALi1c4aYo/
aUMAnig5wniQHM3URg1B8/4OK2S+ctBE
=kd69
-END PGP SIGNATURE-



Re: [gentoo-portage-dev] search functionality in emerge

2008-11-30 Thread Emma Strubell
You guys all have some great ideas, but I don't think I'd have enough time
to be able to implement them before my project is due... especially because
they appear to be a bit beyond my current programming skills. I would love
to devote a lot more time to this project, but I just can't right now
because I already have a lot of other things on my plate. i am really
interested in contributing to Gentoo and portage in the future, though. I'm
thinking this summer I'll have a chance... Anyway, I'm going to try to keep
it simple and just implement a suffix trie, and hope that that provides some
measurable speed improvement :] Thanks again for everyone's help, though,
and I'll definitely share the (amature and minimal, sorry!) results of my
project if you're interested.

Emma

On Mon, Nov 24, 2008 at 12:15 PM, tvali [EMAIL PROTECTED] wrote:

 I take it shortly together as Rene didn't catch all and so I was fuzzy:

 Portage tree has automatically updateable parts, which should not changed
 by user, and overlay, which will be. Thus, index of this automatic part
 should be updated only after emerge --sync.

 Speedup should contain custom filesystem, which would be called PortageFS,
 for example. In initial version, PortageFS uses current portage tree and
 generates additional indexes.

 So, when you bootup, you have portage tree in /usr/portage. At some point,
 PortageFS is mounted into the same directory, /usr/portage. It will map real
 /usr/portage directory into /usr/portage mount point and create some
 additional folders like /usr/portage/search, which maps files to do real
 searches. /usr/portage/handler would be a file, where you can write query
 and read result. It also contains virtual files to check dependancies and
 such stuff - many things you could use with your scripts.

 When it's mounted, every change is noticed and indexes will be
 automagically updated (and sometimes after communication with portage - for
 example, updates when doing emerge --sync should not happen automagically
 maybe, as it makes things slower. When it's not mounted, you can change user
 files, but must run some notification script afterwards maybe to rebuild
 indexes.

 Indexes are built-in into FS.

 If PortageFS is not mounted, for example because of some emergency reboot,
 portage can work without indexes, using real directory instead of this mount
 point.



Re: [gentoo-portage-dev] Time to say goodbye

2008-11-30 Thread Emma Strubell
Thanks for the help, and good luck!

Emma

On Sun, Nov 30, 2008 at 2:21 PM, Zac Medico [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Marius Mauch wrote:


  So I guess that wraps it up. It's been a nice ride most of the time,
  but now it's time for me to leave the Gentoo train.
 
  Marius

 Thanks for all your contributions and guidance. It's been nice
 working with you. Take care of yourself.
 - --
 Thanks,
 Zac
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.9 (GNU/Linux)

 iEYEARECAAYFAkky574ACgkQ/ejvha5XGaM/9ACggmSozFHcmh/l6QALi1c4aYo/
 aUMAnig5wniQHM3URg1B8/4OK2S+ctBE
 =kd69
 -END PGP SIGNATURE-