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 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 l
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
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 l
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
-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
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
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-pack
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
[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, f
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
> http://java.sun.com/j2se/1.4.2/
> (or a version attribute)? If slot and version aren't specified they'd be
> interpreted as wildcards.
The restrict attribute exists already and it's better
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 H
Diego 'Flameeyes' Pettenò wrote:
> Tobias Scherbaum <[EMAIL PROTECTED]> writes:
>
> > But what about additional slot or version attributes like
> > http://java.sun.com/j2se/1.4.2/
> > (or a version attribute)? If slot and version aren't specified they'd be
> > interpreted as wildcards.
>
>
>
>
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 wro
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 p
В Вск, 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 ne
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 al
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 we
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 "DESCRIPTIO
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 thi
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
В Вск, 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 overk
В Вск, 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 informa
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
> purp
Seems that we already have everything you dreamed about:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=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 lin
Peter Volkov wrote:
> Seems that we already have everything you dreamed about:
>
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=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
В Вск, 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
> > >
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=3&chap=1#doc_chap4
> >
> > Take a look at PORTAGE_ELOG_SYSTEM. It eve
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 probl
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
-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
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 impr
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=3&chap=1#doc_chap4
>>
>> Take a look at PORTAGE_ELOG_SYSTEM. It even can send
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 yo
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 th
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 fe
"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 metadata.x
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 20
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 "
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=3&chap=1#doc_chap4
>>
>> Take a look at PORTAGE_ELOG_SYSTEM. It even can send that messages by
>> mail :)
>>
>
> This is
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 ho
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=3&chap=1#doc_chap4
>>
>> Take a look at PORTAGE_ELOG_SYSTEM. It even can send that messages by
>> mail :)
>
> This is all cool, 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 ba
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 t
В Вск, 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 excus
55 matches
Mail list logo
