[gentoo-dev] Re: Name change s/drac/ssuominen/ for people wondering.
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
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
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
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
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
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
-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
-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
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
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
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
[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
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
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
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
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
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
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
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
В Вск, 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
-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
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
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
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
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
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
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
В Вск, 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
В Вск, 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
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
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
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
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
В Вск, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
В Вск, 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
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
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
-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
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.
