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
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
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
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
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
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
-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
-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
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
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
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
[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
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
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
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
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
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
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
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
В Вск, 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
-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
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
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
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.
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?
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
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
В Вск, 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
В Вск, 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
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.
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
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
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
В Вск, 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
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
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.
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
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
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
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
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
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
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
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,
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
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
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
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!
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
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
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
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
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
В Вск, 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
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
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 Developer
-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
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
58 matches
Mail list logo
