В Вск, 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
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
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
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
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
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
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 "
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
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
"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
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
> 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
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
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
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
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
-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
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, 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
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
В Вск, 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
> > >
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
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
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
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.
В Вск, 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
В Вск, 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
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
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
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
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
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
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
-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
В Вск, 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
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
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
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
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.
>
>
>
>
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
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
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
[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
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
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
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
-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
-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
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
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 <[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
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
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
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
55 matches
Mail list logo
