[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 13694 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 340 minutes.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 13782 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 409 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] app-admin/gwcc being removed
On Thu, 2005-09-22 at 16:33 -0400, Daniel Gryniewicz wrote: Hi, all. app-admin/gwcc has security issues, and has been unmaintained upstream for 3 years. The Gnome herd is no longer interested in maintaining it. I've masked it, and will remove it in a couple of weeks, if no one steps forward to maintain it. Daniel Last call for gwcc. If no one steps up, I'll remove it in the next couple of days. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Getting Important Updates To Users
Thierry Carrez wrote: But it's a good idea to have some kind of automatic replication of frontpage announcements to gentoo-announce and the forums, this will help getting important messages through. However, I'm not sure *all* frontpage contents should get replicated to gentoo-announce and the forums. GWN announcements for example do not need to appear elsewhere... While we're talking about replicating the front page, I just added the Gentoo News rdf feed to Planet Gentoo and Gentoo Universe. I hope this helps the overall situation a very little bit :) Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
On Fri, 2005-11-04 at 12:08 -0500, Nathan L. Adams wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Gianelloni wrote:
Yeah, see, this is a case where not understanding the structure of
Gentoo gives you the wrong impression. The GDP's policy applies to the
GDP. That is not a global developer policy of any kind. It is a policy
by a project, for that project.
If I were, for example, to write up a nice guide for something on the
games team and do it all in ASCII art, that policy has no bearing on
what I do. If I were to write something for the GDP, then it would.
At any rate, that has *zero* bearing on whether or not our update
information needs to be written in GuideXML, so there's no point in
arguing it with you.
So you're saying that Gentoo consists of projects that are completely
'silo'd up' and have no bearing whatsoever on each other. Then the
DevRel project only has bearing on those who actually join DevRel. Neat,
a group formed for the sole purpose of coordinating itself. Security
need only concern itself with securing its members (from who knows
what!), and infra can just ignore the needs of everyone else (different
project!). I wonder how any of the other projects *ever* made it onto
the website...
Yet more proof that you don't understand what you are talking
about...not meant to be insulting just stating that you don't. Just
because some groups (DevRel, Infra, etc.) have farther reaching tendrils
doesn't mean that every group does.
For example, each arch team has a slightly different way to go about
allowing package maintainers to keyword their own packages on a given
arch...some teams insist that the maintainer join the arch team...some
allow for special arrangements (they all follow the same basic
guidelines).
With documentation there are actually 2 different types, those bits that
fall under the GDP and those that fall under the herd that uses them.
Take Chris' games example, the games team is free to release an FAQ in
plain text in Pig Latin if they want to, so long as it is on their own
project page. The GDP policy -only- covers the GDP...not anyone else, so
if Chris wanted to move his plain text Pig Latin doc to the official
Docs repository he would have to make an English version and make it
GuideXML. That's it plain and simple.
The errata.g.o (not the summaries w/ link that emerge would output)
would obviously be documentation, would obviously be governed by the Doc
rules, and it would be irrelevant which staff member happened to publish
a particular guide. If Gentoo really is as balkanized as you state, then
it is a sad state of affairs indeed. Maybe the 'full fledged' versions
should be GuideXML-lite or something, I'm not sure, but your argument is
just silly.
Another thing you seem to be missing is that the GLEP specifically
separates the news from the documentation. The news or errata is just a
plain text *short* summary that something needs to be attended to. It
can, but does not always have to, link to further more detailed
*documentation*. Note then that what would go up on errata.g.o in this
case would be the *summary* (which would not necessarily be governed by
the GDP or it's policies) and *not* the full documentation. Said summary
would contain links to any relevant *documentation* which would then be
governed by the GDP if said documentation was in fact Gentoo created and
in the official Docs repository.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 13748 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 428 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
[snip]
After going through the list, I got the impression there is simply no
place where such messages clearly would go. gentoo-announce sounds as
the best option to go for, but its description somehow suggests not.
Though, subscribed to gentoo-announce means you get nothing but GLSA
announcements and sometimes a new release announcements.
So, what list should the user that wants to receive those **important**
messages sign up to?
I still think that *this* is the reason why people don't seem to know
about the important changes, because there is no obvious place where to
get them. It's quite likely that a user that wanted to see the
new-style apache message didn't see it because it simply didn't appear
on a list the user hoped to see it. It was in the GWN of 2005-09-12,
but I can imagine a user didn't expect it to be there, as there is no
description at al for GWN list, and the **important** information will
always have to be extracted from the GWN, since each GWN covers multiple
items in a few categories which not every user might interest.
Send **important** messages separate to a non-discussion mailing list,
and I'm sure that many people will be happy to read it -- just like
gentoo-announce.
[/snip]
Above and beyond Ciaran's point...
You are correct, there is no clear cut place for them to go...that's how
this thing got started in the first place. However why force users to
sign up for something which can't be appropriately filtered (installed
packages, keywords, use flags, profiles, etc.) when all of them are
already signed up for something that can track and filter, portage.
I wouldn't necessarily bother signing up for an errata list if said list
was going to provide me with *all* the errata out there. The reason that
a mailing list works for RedHat is because RHN tracks what packages you
have installed on your system on *their* server (again something you
have to sign up for, and worse send them info about your configuration),
so the filtering is done for you. We will *never* do something like
this, we have a client side tool that can identify what is installed
already...why not use it?
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
[snip]
After going through the list, I got the impression there is simply no
place where such messages clearly would go. gentoo-announce sounds as
the best option to go for, but its description somehow suggests not.
Though, subscribed to gentoo-announce means you get nothing but GLSA
announcements and sometimes a new release announcements.
So, what list should the user that wants to receive those **important**
messages sign up to?
I still think that *this* is the reason why people don't seem to know
about the important changes, because there is no obvious place where to
get them. It's quite likely that a user that wanted to see the
new-style apache message didn't see it because it simply didn't appear
on a list the user hoped to see it. It was in the GWN of 2005-09-12,
but I can imagine a user didn't expect it to be there, as there is no
description at al for GWN list, and the **important** information will
always have to be extracted from the GWN, since each GWN covers multiple
items in a few categories which not every user might interest.
Send **important** messages separate to a non-discussion mailing list,
and I'm sure that many people will be happy to read it -- just like
gentoo-announce.
[/snip]
Above and beyond Ciaran's point...
You are correct, there is no clear cut place for them to go...that's how
this thing got started in the first place. However why force users to
sign up for something which can't be appropriately filtered (installed
packages, keywords, use flags, profiles, etc.) when all of them are
already signed up for something that can track and filter, portage.
I wouldn't necessarily bother signing up for an errata list if said list
was going to provide me with *all* the errata out there. The reason that
a mailing list works for RedHat is because RHN tracks what packages you
have installed on your system on *their* server (again something you
have to sign up for, and worse send them info about your configuration),
so the filtering is done for you. We will *never* do something like
this, we have a client side tool that can identify what is installed
already...why not use it?
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
On Mon, 2005-11-07 at 14:02 -0500, Daniel Ostrow wrote:
[snip]
After going through the list, I got the impression there is simply no
place where such messages clearly would go. gentoo-announce sounds as
the best option to go for, but its description somehow suggests not.
Though, subscribed to gentoo-announce means you get nothing but GLSA
announcements and sometimes a new release announcements.
So, what list should the user that wants to receive those **important**
messages sign up to?
I still think that *this* is the reason why people don't seem to know
about the important changes, because there is no obvious place where to
get them. It's quite likely that a user that wanted to see the
new-style apache message didn't see it because it simply didn't appear
on a list the user hoped to see it. It was in the GWN of 2005-09-12,
but I can imagine a user didn't expect it to be there, as there is no
description at al for GWN list, and the **important** information will
always have to be extracted from the GWN, since each GWN covers multiple
items in a few categories which not every user might interest.
Send **important** messages separate to a non-discussion mailing list,
and I'm sure that many people will be happy to read it -- just like
gentoo-announce.
[/snip]
Above and beyond Ciaran's point...
You are correct, there is no clear cut place for them to go...that's how
this thing got started in the first place. However why force users to
sign up for something which can't be appropriately filtered (installed
packages, keywords, use flags, profiles, etc.) when all of them are
already signed up for something that can track and filter, portage.
I wouldn't necessarily bother signing up for an errata list if said list
was going to provide me with *all* the errata out there. The reason that
a mailing list works for RedHat is because RHN tracks what packages you
have installed on your system on *their* server (again something you
have to sign up for, and worse send them info about your configuration),
so the filtering is done for you. We will *never* do something like
this, we have a client side tool that can identify what is installed
already...why not use it?
Err...sorry for the double post...mail client error.
Oh...and before anyone goes nuts...note I said why force users to sign
up to such a list *not* we will not provide such a list.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council meeting Tuesday, November 15th, 20:00 UTC
On Tue, 2005-11-08 at 17:57 +, Ciaran McCreesh wrote:
On Tue, 08 Nov 2005 17:30:02 +0100 Thierry Carrez [EMAIL PROTECTED]
wrote:
| The November Gentoo Council meeting will be held on #gentoo-council
| next week, Tuesday, November 15th, 20:00 UTC, presided by Seemant
| Kulleen.
|
| The deadline for submitting items for the meeting agenda is set to
| Sunday, November 13th, 20:00 UTC.
Assuming there aren't any further comments between now and then, I'd
like GLEP 34 (GLEP File Hosting) to be approved please.
I assume you meant 43 yes?
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 14406 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 372 minutes.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 14544 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 2768 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Tue, 2005-11-22 at 12:03 -0600, Grant Goodyear wrote:
Chris Gianelloni wrote: [Tue Nov 22 2005, 09:15:27AM CST]
Well, if we could educate the users that stage2 tarballs are totally
pointless, and that running bootstrap.sh followed by emerge -e system
from a stage3 is pretty much *exactly* the same as starting a stage1
from scratch...
It isn't pretty much anymore. It *is* exactly the same.
I keep hearing this, isn't there a real difference between a stage 1 and
a stage 3 install inasmuch as somebody who needs (or wants) to
dramatically tailor what's in the system profile can choose to do so
from a stage 1 or 2, but would have to remove packages after the fact if
starting from a stage 3? I wouldn't have a problem with that, as long
as we document it, but it just seems that the claim that the old and new
methods produce _exactly_ the same results seems to be stretching things
a bit.
-g2boojum-
There are 3 purposes to a stage1/stage2 install (note all 3 can be
achieved with either a stage3 or a custom rolled stage though catalyst):
1). Modify the bootstrap.sh script to change what the stage2 target
produces.
2). Modify the system target to change what the stage3 target
produces.
3). Modify the CHOST/CFLAGS/USE et. al. early on to create a customized
and largely unsupported (things like hardened, uclibc, and embedded are
exceptions to the unsupported rule) stage3 target.
#3 is where the vast majority of user created bugs occur. The purpose of
highly encouraging users to start with a stage3, by making the handbook
only refer to it, is to make sure that users have a known working
configuration to start their customization from. There are many many
ways to mess up going from a stage1 to a stage3, there are fewer ways to
mess up customizing and recompiling a system that has already been
configured to boot on it's own.
By and large most users will never want to do any of the above for the
reasons that they are really valid for, and any user or developer that
does will have access to both the stages (with relocated documentation)
and catalyst itself to make their own. We are not removing choice
here...just *potentially* making someones initial download time longer.
Personally I wouldn't be at all opposed to moving the stage1 and stage2
tarballs to another directory on the mirrors (documented of course),
just to make it that much clearer that if you start from a stage1 or a
stage2 RelEng won't support you if any errors occur during system build.
If RelEng ever does get to the point of removing stage's 1 2 from the
mirrors (something that has been discussed but isn't on the table at all
right now) end users and developers alike will still be able to generate
them on their own using catalyst and the provided spec files...sure it
is an extra step and all but it's not all that huge...
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] R/O CVS access and its purpose for ATs (was Email subdomain)
On Tue, 2005-11-22 at 17:56 -0600, Lance Albertson wrote:
Marius Mauch wrote:
On Sun, 20 Nov 2005 09:32:55 +1100
Ben Skeggs [EMAIL PROTECTED] wrote:
Anyway, the most important reason for the GLEP (IMO) is giving AT's
r/o access to CVS. When working on bugs, it's always fun to find out
that the problem has already been resolved and just hasn't made it to
your local rsync mirror yet..
Out of curiosity, what's the more important aspect of r/o cvs:
- more up to date
Not necessarily true. We would not have the anon cvs access from our
primary cvs server. It would be synced on a regular basis to a separate
box. The newer cvs (which isn't on lark yet) may give us capabilities to
have a more 'live' cvs anon system. But as of now, the best infra can
provide is 30 minute updates. I don't want to poll the cvs more than
that to keep down the load.
- easier selective updates
Yup, that's definitely a plus.
And herein I think lies some confusion. Personally if I were an AT both
would be important but more to the point the more up to date issue
would be the most important. I think that there is a need for the ATs to
be able to work in direct conjunction with a dev, an AT catches an
error, a dev fixes it in CVS using a *well tested* patch, an AT does a
`cvs up` and retests to try and catch *other* errors all within a matter
of *single digit* minutes. This is a very powerful tool, rather then
what they have to do now which is either wait for it to hit the rsync
mirrors, a dedicated rsync mirror, a dedicated anoncvs box, or e-mail
the ebuilds (and patches) back and forth. Note the two highly stressed
things up there...this should not be used so ATs can vet patches (wither
to ebuilds or to source), the patches should be well tested long before
they reach our tree...
Lance:
I know this is a far cry from what you are proposing, and I understand
that the present CVS server cannot handle this sort of load but I
believe that this was the original intention at least...someone correct
me if I am wrong.
I think that this issue has to be nailed down *before* we get any
further in discussion.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, 2005-11-23 at 01:40 -0500, Curtis Napier wrote:
big_snip
Accessibilty guidelines say that all text links should be underlined. I
made an exception for the grey menu bar for aesthetic purposes but will
not make an exception for any other links.
/big_snip
Given the above shouldn't the text links below each advertisement
graphic also be underlined. The implication of the current text is that
they are not links at all when they are.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 14890 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 509 minutes.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 14377 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 522 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/dvdrip
On Friday 09 December 2005 08:19 pm, Mike Frysinger wrote: On Sat, Dec 10, 2005 at 01:09:50AM +0100, Luca Barbato wrote: Mike Frysinger wrote: so the video herd policy is to remove packages until you're left with a small enough subset of packages you can handle ? I'd rather say that we select packages that evolve and fit the needs and kill what isn't suitable anymore. fair enough, but i thought we've establish that there are *no* alternatives to dvdrip regardless of what diego may think -mike well, it's maintained now, better slow progress than certain death, works too well for me to see it go pgpTLSrvyBwb8.pgp Description: PGP signature
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 13568 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 529 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Last rites for media-video/dvdrip
On Sunday 11 December 2005 09:32 pm, R Hill wrote: Diego 'Flameeyes' Petten wrote: Oh well, media-video/dvdrip has many issues reported in bugzilla (some have patches, most haven't), and depends on a version of transcode with many issues, too (and force us to leave transcode 1 masked). Nobody in video herd is looking at it right now, last bump was done by morfic, and more would be needed. working on dvdrip is one of the things on my todo list, as soon as i finish rebuilding my system. please reconsider dropping packages just because they don't currently have a dedicated maintainer. if upstream is alive and people are using it, leave it alone. especially if it's a popular package with just a handful of bugs. also, it's a lot more likely you'll find a new maintainer for a package when it's already in the tree for people to discover and use. isn't this what the maintainer-needed alias is for? --de. sorry there hasn't happened much yet wrt dvd::rip the system i worked on with dvdrip had a disk die, art of a md0, system is gone, so i too reinstall, some real life worries and usual lack of enough time for everything i started out keeping icewm maintained, and eventually took on other things short version is better i guess: we always appreciate user contributions, if i am slow, it does not represent any lack of interest between you and chandler dvd::rip s hould stay, one concern is that transcode 1 i had on the laptop, on the system dvd::rip worked on has 0.6.14, when i tried dvd::rip on here, it seems to have finished the plugin scan the hangs, scanning plugins was what i did on the XP, then the hdd died :) i too am frightened to see good working apps go, i still consider readding kcpuload which worked then was gone, works still well from an overlay ;) you get the idea i will add your email to the dvd::rip filter in kmail so i hopefully do not miss things wife's surgery is friday, so i don't expect to do much before then Thanks, Daniel Goller pgpzxz08W7VDT.pgp Description: PGP signature
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 13634 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 798 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mac/xmms-mac licence issue
On Sat, 2005-12-24 at 19:17 -0800, Bret Towe wrote:
On 12/24/05, Carsten Lohrke [EMAIL PROTECTED] wrote:
This isn't politics, but copyright infringement on top of a ridiculous
license
(when you want to see it as one) we had a short discussion¹ about several
months ago.
im sorry i fail to see how copyright infringement or a ridiculous licence
matters when commiting a ebuild to portage just pick a licence if thats the
issue warn the user and leave it at that
What you are missing is that Gentoo (the foundation) is legally culpable
for making sure that none of the packages that we provide in our tree
violate any form of license. If we shipped these e-builds then the
original author would have the legal right to take action against us. It
is not just a question of letting the user decide if they want to use an
illegally licensed program, we would be facilitating such an act. That
is something we cannot and will not do.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] mac/xmms-mac licence issue
On Sat, 2005-12-24 at 19:35 -0800, Bret Towe wrote:
On 12/24/05, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Sat, 24 Dec 2005 19:17:05 -0800 Bret Towe [EMAIL PROTECTED] wrote:
| On 12/24/05, Carsten Lohrke [EMAIL PROTECTED] wrote:
| This isn't politics, but copyright infringement on top of a
| ridiculous license (when you want to see it as one) we had a short
| discussion¹ about several months ago.
|
| im sorry i fail to see how copyright infringement or a ridiculous
| licence matters when commiting a ebuild to portage just pick a
| licence if thats the issue warn the user and leave it at that
Would you like us to add the Windows XP source code to the tree with
LICENSE=gpl-2 as well?
whats the point i cant get the same crap from /dev/random
sarcasm aside considering its just an ebuild that points to the source
which could be not hosted on gentoo mirrors and the LICENCE bit
is to notify the user ahead of time what the licence is and,
assuming the functionality was there, allow said user to ignore
all applications that use that licence type but since that isnt there
it could be anything and it doesnt really matter now does it?
Read my last e-mail, it is a question of culpability do to the
facilitation of an illegal act, a crime in and of itself, nothing more,
nothing less. Sure we wouldn't be shipping the actual source, but what
we would be doing is facilitating your use of said source, which is
*illegal*.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 14140 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 396 minutes.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: shoving utils from xpdf to poppler...
On Wed, 2005-12-28 at 17:18 +0100, Carsten Lohrke wrote: Hi Daniel, what you've done breaks runtime dependencies, if not for other packages so at least for KDE. Such a change should be announced on the gentoo-dev mailing list before you do it. Also a tracking bug to coordinate stabilization of new ebuild revisions will be needed, once the changed ebuilds go stable. Moreover you're not free to put a 200k patch into cvs, 20k is the accepted maximum. It's not supposed to break runtime dependencies. Everything that was installed before is installed now, in the same location. I therefore didn't feel it should case problems and that it wouldn't require coordination. Could you please elaborate, possibly with a bug? I'll fix the patch. I didn't see repoman complain, but I may have just missed it. Sorry about that. Daniel signature.asc Description: This is a digitally signed message part
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 13904 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 397 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal: removing server profile variants from profiles.desc
Markos Chandras schrieb am 12.10.2012 10:08:
+1. I want these profiles to *staty*. I am using this profile on my
home boxes. It is the most minimal profile as the rest of the
profiles pull in too much useless stuff. What is wrong with these
profiles anyway?
If you want a minimal profile you don't need the server profile.
ln -s ${PORTDIR}/profiles/default/linux/${ARCH}/10.0 make.profile
gives you a minimal profile.
--
Regards
Daniel
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] cracklib, shadow, cracklib USE flag, cracklib in system
cracklib is a library which makes judgements on passwords. It tells you passwords weak as they are too short, based on a dictionary word, and stuff like that. It's a nice thing to have, is fairly standard, but is not a true requirement. Any thoughts on these changes: 1. Promote cracklib USE flag to global USE 2. Enable USE=cracklib by default in profiles/default-linux/make.defaults 3. Add cracklib USE flag to sys-apps/shadow. Right now shadow unconditionally depends on cracklib and includes cracklib support. 4. Remove cracklib from base/packages Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Alon Bar-Lev (alonbl)
Welcome Alon, Pleasure to have you on board. -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] 2.6.18 going stable in 1 week
This is your 1 week warning.. fix any packages which don't compile and ensure the fix is also in the stable tree. Thanks. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2.6.18 going stable in 1 week
Thomas Cort wrote: What package(s) are going stable in 1 week? I have no clue what you are writing about since you didn't mention it in your e-mail. I did a quick search and found the following 6 packages which have a version 2.6.18: gentoo-sources-2.6.18 linux-headers-2.6.18 suspend2-sources-2.6.18 usermode-sources-2.6.18 vanilla-sources-2.6.18 Sorry about that. I was referring to gentoo-sources, which is really the only truly supported kernel (excluding some arch-specific ones). You also neglected to mention which architectures are going stable. Are all arches going stable at the same time (in 1 week)? Will you still go ahead with the stable marking if http://bugs.gentoo.org/148429 is not resolved? x86 and amd64 immediately, and assuming they don't have showstoppers, ppc/ppc64/sparc usually follow up real quick. Yes, it will go stable even if some dependencies of bug 148429 are not fixed. These are *not* kernel bugs, they are bugs in the individual packages. However, I don't ignore them, I have already put many hours into fixing those bugs. I have been through every bug listed there and provided fixes/workarounds to all of them. I expect to have to spend even more time chasing up maintainers of the unfixed packages there. This is becoming a real problem for me as I'm having to waste excessive amounts of time on every kernel release fixing bugs in packages which are nothing to do with me. I'm considering dropping stable keywords from repeat offenders, but really there aren't any of those: external kernel packages are almost guaranteed to break every once in a while, and we simply have a large number of these packages which aren't given much attention by their maintainers. Any suggestions here are appreciated. Daniel P.S. The tone of your email didn't offend me, but that's probably because I completely agreed with it. Andrew is certainly right in that we should be really careful about how we write things. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: 2.6.18 going stable in 1 week
Christian Faulhammer wrote: Announce it here (or -core) which needs a fix and then just commit the fix if it is trivial and there has been no reaction. I think you didn't grasp the problem exactly. There are a large number of packages which build against the kernel and do not get much attention from their maintainers. To avoid too many sharp objects coming in my direction when a new kernel goes stable, I spend a lot of time providing fixes for these packages. The problem is that this (i.e. producing the fixes) is a big waste of time on my part, I'd rather work on real kernel stuff which is lagging behind. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: 2.6.18 going stable in 1 week
Mike Pagano wrote: This seems to me like a good opportunity to engage the arch teams for some assistance. So the arch teams would be happy to handle package foo doesn't compile with 2.6.18 bugs, for example, bug 148381? Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Wed, 2006-11-08 at 17:37 +, Kurt Lieber wrote: On Wed, Nov 08, 2006 at 07:19:44PM +0200 or thereabouts, Alin Nastac wrote: I say we should have +all (SPF-capable MTAs will consider any IP address as authorized to send mail on behalf of g.o - equivalent with Message source OK). this interpretation is correct. He says we should have ?all (when another SPF-capable MTA will check the my IP address, it will take my message with a grain of salt - equivalent with Message source unknown). this interpretation is not correct. What you are describing is ~all, not ?all. ?all instructs the MTA to make no interpretation at all related to a failure. In other words, do not add or subtract any salt whatsoever.[1] ~all tells the MTA to add some salt.[2] --kurt [1] http://new.openspf.org/RFC_4408#op-result-neutral [2] http://new.openspf.org/RFC_4408#op-result-softfail Not advocating either option...just pasting additional info. If anyone wants to see the VERY brief discussion that was had over at SA about why they decided to ignore the standard (or moreso what they decided the standard actually meant) check out [1]. --Dan [1] http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3616 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GNOME 1.x and GNOME 1.x dependent package masking
On Fri, 2006-11-10 at 08:56 +0100, Marius Mauch wrote: Ok, the list definitely isn't accurate. If there is a legitimate reason to mask sylpheed-claws-1.x you also have to mask it's reverse deps. However I'm still waiting for the explanation why it is on that list. (I don't mind if it's masked for a good reason, but I need to know that reason). There is no immediate reason, of course. However, gtk+-1 and glib-1 will be removed as soon after the big cleanup as is feasible, and sylpheed-clasws-1.x is a gtk+-1 app, and therefore must go as well. I didn't generate the list, but my understanding was that it was intended to include all packages with a hard dep on gtk+-1, in addition to gnome 1.x. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Xbox-sources
Mike Frysinger wrote: and is unmaintained. says you :P Following up from IRC earlier: You're interested in maintaining this until a new maintainer is found. Are you prepared to handle the security bugs here? Alternatively we could either put it in hardmask until a maintainer is found, or we could slap a warning in the ebuild saying that it's not supported from a security perspective, or something along those lines. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GNOME 1.x and GNOME 1.x dependent package masking
On Sat, 2006-11-11 at 22:55 +0200, Alin Nastac wrote: Paul de Vrieze wrote: On Friday 10 November 2006 16:28, Daniel Gryniewicz wrote: On Fri, 2006-11-10 at 08:56 +0100, Marius Mauch wrote: Ok, the list definitely isn't accurate. If there is a legitimate reason to mask sylpheed-claws-1.x you also have to mask it's reverse deps. However I'm still waiting for the explanation why it is on that list. (I don't mind if it's masked for a good reason, but I need to know that reason). There is no immediate reason, of course. However, gtk+-1 and glib-1 will be removed as soon after the big cleanup as is feasible, and sylpheed-clasws-1.x is a gtk+-1 app, and therefore must go as well. I didn't generate the list, but my understanding was that it was intended to include all packages with a hard dep on gtk+-1, in addition to gnome 1.x. Gtk1 actually is broken for --as-needed. It's linking is broken thanks to a libtool which refuses to link against a non-installed libgdk. I think gtk+-1.2.10-r12 solved this problem. Hope you guys aren't seriously considering dropping gtk+1. As long as we have packages that depend on it (packages that has nothing to do with gnome herd/team), gtk+1 should stay in the tree. We (gnome) are not going to maintain gtk+-1. We would very much prefer it get removed. If some other person or group wants to maintain it, I guess it's fine with me; it will only cause Jakub and company headaches for re-assigning all the bugs that mistakenly get assigned to gnome. Note that maintaining it basically means being upstream, as there is no upstream for it. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] /etc/udev/rules.d nightmare - orphaned files in /etc
Sven Köhler wrote: Have you ever thought about sollutions of that problem? It's not a real problem, that these files are orphaned - but they are neither removed nor renamed, so they stay in place and in one or the other way, they may start to disturb. Wasn't portage modified to remove unmodified config-protected files on unmerge a while back? If not, is this a sensible suggestion? Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] gentoo-sources-2.4 needs a maintainer
Hi, With Tim gone there is nobody working on gentoo-sources-2.4. I'm not sure what's left in the patchset but on last check there were users depending on it. If anyone is interested please step up, otherwise this will go through the usual mask/removal process. Recruiting a non-developer to take this is an option, provided the usual requirements are met. Please mention this in the next GWN. Thanks! Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] sys-fs/submount needs a maintainer
Hi, submount is an external kernel module which provides automounting functionality. It is currently under kernel herd but nobody there has interest in this package. I have had to fix it repeatedly in order to compile with newer kernels, it's broken again for 2.6.19 and I've had enough. Upstream appears to be dead as well. If nobody steps up within a week it will go in package.mask for removal 3 weeks later. Suitable replacements for this package include the in-kernel automounter, hal, ivman. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
Alec Warner wrote: This is to prevent people from sticking a random unchecksum'd ebuild in your tree and then having portage source it for depend() metadata and then getting bitten by some global scope nasties. Is this really the correct solution to this problem? I can't see the use case: do people really download (potentially malicious) ebuilds, stick them in their overlay, and then *not* use them? Somehow I don't think that's true - people will generally download ebuilds, and use them (even if they fail during compilation, they will have been used in some form). If you start requiring people to create Manifests for these ebuilds, they will do so, and this has not changed the security implications of these untrusted ebuilds. Am I missing something? Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] sys-fs/submount removal
Hi, After no response to my call for maintainers, submount will enter package.mask tomorrow for removal in 3 weeks. http://archives.gentoo.org/gentoo-dev/msg_141377.xml Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Linux 2.6.19 stabilization
Hi, I plan to get gentoo-sources-2.6.19 stable on x86 and amd64 around January 8th time. There are a couple of outstanding kernel issues to fix, and I hope to see the external kernel module tree in better shape: https://bugs.gentoo.org/show_bug.cgi?id=156669 this is your advance warning - fix your packages, and ensure they are fixed in the stable tree. Find me on IRC if you need help. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for net-wireless/ipw2100 and net-wireless/ipw2200
Rémi Cardona wrote: On second thoughts, I'll raise a small objection to the removal. Latest gentoo version is 1.2.0 while the kernel (gentoo-sources-2.6.19-r2) says to contain 1.1.4. I know that difference isn't exactly huge, but still, it's a step backwards. The only changes from 1.1.4 to 1.2.0 which aren't related to the out-of-kernel build system are very small, will only affect a very small number of users (i.e. people who do wireless development) and are merged for 2.6.20. I don't think you will see any behavioural difference at all between 1.1.4 and 1.2.0 and I don't think this is a showstopper to removal. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] openmosix maintainer needed
Hi, openmosix has been hardmasked for a long time: # Tim Yamin [EMAIL PROTECTED] (07 Aug 2006) # Security mask # Bugs #135167, #137623, #137626, #138617, #139321, # #139475, #139641, #140444, #141503, #142616, #142617 sys-kernel/openmosix-sources sys-cluster/openmosixview sys-cluster/openmosixtest sys-cluster/openmosix-user sys-cluster/openmosixwebview sys-cluster/openmosix-3dmon-stats It should be removed from portage, but as this is quite a big thing I'm expressing some haste before kicking it. Is anyone working on bringing this back up to date? Any strong objections to the actual removal (despite it being hardmasked already)? Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] bugs.gentoo.org migration - completed! -THANKYOU
Thanks to myself, kingtaco, ramereth, solar, jforman and cshields for all playing a part of getting this together so far! A special thank you to our sponsor GNi (gni.com) for the hardware. I hear there will be an article on them in an upcoming GWN. Thankyou all, You've spent many hours working towards a smooth transition and this has occurred really smoothly (as far as I have seen). I've noticed the usage of bugs.gentoo.org is now, dare i say it, pleasureable :-). Thankyou again GNI for your hardware. -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgpGh0CCsOUk5.pgp Description: PGP signature
Re: [gentoo-dev] 2.6.19 going stable in 1 week
Rémi Cardona wrote: About that bug, has anyone filed anything for it in Gentoo or is it the kind of bug that creeps up anywhere and can look like something else is responsible for it? Now that the problem is understood, it can be reproduced trivially on any kernel and can easily result in filesystem corruption. Daniel -- gentoo-dev@gentoo.org mailing list
Re: OT - Good skills (WAS: Re: [gentoo-dev] Through the looking glass: Reflections on Gentoo)
Michael Sullivan wrote: I would like to help with coding/debugging packages for Gentoo. I have some programming experience on a very small scale. I have an Associates of Computer Science from a small community college, and I've never had a job working for a software company. You spode of good enough skills; I don't think I have good enough skills to help with Gentoo, but I'd like to. Where should I start? Just to expand on everything that has already been said, here is my input. It sounds like you don't have any specific area of interest in mind, but you are keen on the principles and want to contribute to the community. So, the first thing you need to do is pick something moderately specific to get involved in, since packages are divided by category and roles are divided by projects, etc. The choice is fairly arbitrary but go for one that you have some kind of knowledge and interest in. For example, if you once did a college project evaluating different kinds of encryption, you might choose to get involved with the crypto packages. If you have some kind of uncommon hardware which needs its own out-of-kernel driver, firmware, or userspace utility then look into packages in that area. If you have a large music collection and spend a lot of time keeping it organised, pick the media-sound package group. And realistically your initial choice might not hold for very long, but that's fine. As long as you pick an area to start in, and you see it through the recruitment process, then you'll have found some footing and can move around and branch out later. At the moment I spend a lot of time maintaining and fixing the kernel in Gentoo. I was not even doing anything comparable to this when I originally became a developer. I am currently also involved upstream developing drivers and fixing bugs in the mainline kernel sources, and I certainly didn't have any knowledge of how to go about this when I originally joined Gentoo development. At some point you'll start finding some bugs which you can diagnose if not solve fully (diagnosis is often harder than fixing up the code). Or you'll find a personal itch that you are capable of scratching, so you'll be motivated to get involved in a very specific project (and you won't have the what can I do problem you have now). If this makes any sense to you, send me a list of software or areas that you might be interested in offlist, and I'll look into getting you in contact with appropriate people. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] gentoo-sources-2.4 needs a maintainer (a real one)
Hi, A few weeks ago I posted that gentoo-sources-2.4 needs a maintainer. antarus stepped up but realised his fatal mistake and has now fled from the scene. If anyone is interested please step up, otherwise this will go through the usual mask/removal process. Recruiting a non-developer to take this is an option, provided the usual requirements are met. Maintaining a kernel is a big job, plus maintaining a 'dead' kernel tree like 2.4 is even worse and is not really that interesting. A maintainer needs to have interest and energy (which probably indicates a genuine requirement to run 2.4), I'm not interested in seeing this maintained-but-neglected. Please mention this in the next GWN. Thanks! Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
Chris Gianelloni wrote: Submit your ideas here, so we can discuss them. I will be choosing one idea that we think we can accomplish to test out the idea of Council-driven projects. Construction of a dynamic website for tracking kernel security issues. There are too many of them and too many kernels to do this through the normal GLSA process, and currently users are kept in the dark about fixed security issues. Tim had started developing a site for this (KISS) but it was never finished and had the large downside that it relies upon an operator duplicating lots of information from bugzilla and the ebuild tree into KISS. Such a system would be able to automatically pull a large proportion of the required information relatively easily. It would offer functionality to allow users to sign up for security announcements and fixes for their kernel(s) of choice, as well as feeding the same info into a mailing list for all kernels. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-core] Re: [gentoo-dev] New profiles/ChangeLog
On Fri, 2007-01-12 at 10:00 -0800, Donnie Berkholz wrote: Chris Gianelloni wrote: There's a ChangeLog file in profiles/ChangeLog now. Please use it when making changes to things in profiles/*... Should we prefer this location for trees that already have a ChangeLog in them as well? It's kind of random which places have a ChangeLog and which don't. [EMAIL PROTECTED] profiles $ find . -name ChangeLog ./ChangeLog ./default-linux/alpha/ChangeLog ./default-linux/amd64/ChangeLog ./default-linux/hppa/ChangeLog ./default-linux/ia64/ChangeLog ./default-linux/ppc/ChangeLog ./default-linux/sparc/ChangeLog ./default-linux/x86/ChangeLog ./hardened/x86/ChangeLog Not really randomshould be something akin to one per arch (for releng/arch team purposes) and then on global one to accommodate everything else... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [RFC] Ideas for projects...
Steve Long wrote: Daniel Drake wrote: Construction of a dynamic website for tracking kernel security issues. There are too many of them and too many kernels to do this through the normal GLSA process, and currently users are kept in the dark about fixed security issues. Who put's up the fixed security issues? Nobody, that's the point of this project. We currently don't have GLSA or any other form of security announcements for kernel packages. Tim had started developing a site for this (KISS) but it was never finished and had the large downside that it relies upon an operator duplicating lots of information from bugzilla and the ebuild tree into KISS. Such a system would be able to automatically pull a large proportion of the required information relatively easily. It would offer functionality to allow users to sign up for security announcements and fixes for their kernel(s) of choice, as well as feeding the same info into a mailing list for all kernels. If you can put it thru repoman (or some other script) it can be automated. It can't be pulled at that level. But as I said, yes, it can be automated, thanks for agreeing ;) The existing data which needs to be aggregated is mostly held on bugzilla. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
While hanging around lca07 it was mentioned how bandwidth hungry Gentoo is. Given a lot of the world is still on dialup this could increase the potential userbase for Gentoo. As such the project idea is Automated Xdelta Generation. principles: no manual generation of xdeltas by gentoo devs simple user usage (FEATURES=xdelta) avoiding digesting problems remain compatible with existing ebuilds user interface: FEATURES=xdelta emerge ~sys-kernel/gentoo-sources-2.6.20 found /usr/portage/distfiles/linux-2.6.19.tar.bz2 fetching linux-2.6.19_xdelta_2.6.20.xdelta generating linux-2.6.20.tar digest /usr/portage/distfiles/linux-2.6.20.tar matches storing /usr/portage/distfiles/linux-2.6.20.tar.bz2 (more fetching) unpacking .. ... ... FEATURES=xdelta emerge ~sys-kernel/hardened-sources-2.6.20 found /usr/portage/distfiles/linux-2.6.20.tar.bz2 digest mismatch - checking linux-2.6.20.tar digest good - assuming it was xdelta generated (more fetching) unpacking . I'm thinking xdeltas that gets generated on the staging server and some portage support so facilitate a minimal download. Note: i haven't looked at previous xdelta portage patches from years ago. -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgpb4nnRYGEDq.pgp Description: PGP signature
Re: [gentoo-dev] amd64 help
Christian Faulhammer wrote: So, maybe we can discuss here another helping hand for amd64. Devs that work with a given software (not necessarily the maintainer) on amd64 architecture It seems like this should be discussed amongst the active amd64 developers internally first, and perhaps should do some kind of recruiting drive / call for help. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] eclass proposal - savedconfig.eclass
else? Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgpekacYAqKrP.pgp Description: PGP signature
Re: [gentoo-dev] eclass proposal - savedconfig.eclass
On Thursday 01 February 2007 18:48, Mike Frysinger wrote: On Thursday 01 February 2007, Daniel Black wrote: Also creates the following symlinks to it i dont see much value in these symlinks ... what do they gain us ? An easy way to find the closest config when merging a revision/version bump of the same package. There are probably some cleaner ways with portage foo. I see your point that it is a weak reason for symlinks to exist. The hard work should be done by the eclass to find the closest config. As some packages, like uclibc, have regular cross compile functionality which require separate config files for each host. This can be achieved with the -s option. i dont think the ebuild should care whether it's being cross-compiled ... any package should be cross-compilable so the ebuild should really be agnostic in other words, the search path for the .config should always check $CTARGET subdirs followed by $CHOST followed by the normal $CATEGORY Sure, makes sense. So clarifying by default the save_config will store it in normal $CATEGORY and allow the user to move it into under specific $CTARGET or $CHOST directory if that is their desire. -mike -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgpEiqgUFRzCx.pgp Description: PGP signature
Re: [gentoo-dev] eclass proposal - savedconfig.eclass
On Thursday 01 February 2007 18:55, Brian Harring wrote:
On Thu, Feb 01, 2007 at 06:21:01PM +1100, Daniel Black wrote:
Fellow devs,
WARN_CONFIG
warn_config (useflags)
warns the user that the useflags have been overridden by savedconfig
Anything else?
overriding use flags by a secondary configuration is a mess waiting to
happen... needs actual integration in some fashion imo, rather then
well... you probably should define it in both since it may ignore
it.
So some foo that says:
die you have enabled X USE flag but your saved config reflects the X USE flag
been unset. Please correct your saved config by setting GUI=yes
in /etc/portage/savedconfig/${CATEGORY}/${PXXX}/config.h or unset the USE
flag X.
Suggested implementation?
Goes without saying, ignoring manager forced use configuration also
means crap/missing deps are thus possible...
Yes. So a consistant USE flags/savedconfig is highly desireable.
Feel free to clarify that little snippet ;)
~harring
--
Daniel Black [EMAIL PROTECTED]
Gentoo Foundation
pgpTxvOLRTnEW.pgp
Description: PGP signature
Re: [gentoo-dev] New developer: Martin Jackson (mjolnir)
Please welcome Martin as a new fellow developer among us ! Welcome to Gentoo and netmon in particular. May your free time be filled with many solved bug reports, version bumps, and better integration activities. -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgpdhj1tgAqwk.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Dean Stephens (desultory)
On Friday 02 February 2007 06:02, Christian Heim wrote: It's my pleasure to introduce to you Dean Stephens (also known as desultory) our latest addition joining the forums monkeys. Dean is joining us from Bangor (that's in Maine). Don't know anything else about him, so feel free to harass him on IRC. The good thing about the Gentoo community is there is so many mediums to harass you. Its all about choice after all. So please welcome Dean as a new fellow developer among us ! Welcome. -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgppr2IEnyiqK.pgp Description: PGP signature
Re: [gentoo-dev] eclass proposal - savedconfig.eclass
On Friday 02 February 2007 06:27, Ciaran McCreesh wrote: On Thu, 1 Feb 2007 04:50:20 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: | easier to just say USE=savedconfig overrides everything else Which means no dep resolution... USE flags are still used for dependencies. On Thursday 01 February 2007, Daniel Black wrote: The savedconfig configuration control does NOT aim to: - replace the USE flag determination of dependencies It will be possible to configure an option that conflicts with a USE flag in some cases. Given the grief that would be caused by trying to determine this on every package that uses savedconfig it really isn't worth it. Having said that there are 2 pseudo options here: make USE=SAVEDCONFIG capitalised so that it looks and is assumed to be dominate. ewarn You have modified the saved configuration of this package. I assume you have set your USE flags to include the appropriate dependencies and/or emerged the dependencies already. -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgp821Hc5OAs6.pgp Description: PGP signature
Re: [gentoo-dev] new herd suggestion: religion
Wondering if the religion herd would kindly see over the last rites of packages on their journey into oblivion? -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgpJiNMiFzyiY.pgp Description: PGP signature
Re: [gentoo-dev] eclass proposal - savedconfig.eclass - draft commited
Added draft of eclass as savedconfig.eclass. Hope it includes all suggested technical options. There is a masked version of dropbear-0.48.1-r1 that uses it. Hope it suits your needs. Feel free to abuse my coding style (or lack there of). Or poor use of bash schematics. On my todo list is: - to move away from cp --parents with something BSD friendly. - understand what $PORTAGE_CONFIGROOT is Could consider if anyone is interested: - USE=SAVEDCONFIG capitalised so that it looks and is assumed to be dominate. - pkg_postinst - ewarn have modified the saved configuration of this package. I assume you have set your USE flags to include the appropriate dependencies and/or emerged the dependencies already. - implement warn_config (though I don't think its really needed) -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgpmidpUiJ7NI.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007, Roy Marples wrote: This email is about network configuration. Before I joined Gentoo, network configuration was done in bash arrays like so (note, that the variable name was changed in baselayout-1.11) ifconfig_eth0=( 10.1.1.1 netmask 255.255.255.0 10.1.1.2 netmask 255.255.255.0 ) This is all well and good, but only bash and zsh can use it. That's not true. Only bash and zsh can *source* it. Aside from the fact that most other shells don't have any way of storing the results of reading such a file in an accessible way, that format is easy enough to parse with a bit of sed. Who's got any bright ideas for a new config then? Lets brain storm! If it's necessary to change at all, I'd vote for sections in square brackets, applying to everything until the next square bracket, and lines with a key, followed by a ':' or '=', followed by optional whitespace, followed by any number of values, optionally in quotes with backslash-escaped quotes and backslashes, separated by whitespace, with the value lists for duplicate keys being concatenated. It's not hard to parse (assuming, again, that you have some way to store the results), users coming from Windows can write it as ini files, users who like Java can write it as resource files, and old-school Unix types can write RFC822 headers. And they're all mutually comprehensible if the parser is just reasonably lenient. -Daniel *This .sig left intentionally blank* -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] afflib licence (BSD4 like)
Was looking at http://www.afflib.org/LICENSE.txt and was wondering if it really had any Gentoo implications with adding it as a package. I asked a few questions. Does the following seem reasonable? [1] https://bugs.gentoo.org/show_bug.cgi?id=123175 -- Forwarded Message -- Subject: Re: afflib licence Date: Wednesday 07 February 2007 09:56 From: Simson Garfinkel [EMAIL PROTECTED] To: Daniel Black [EMAIL PROTECTED] Cc: Brian Carrier [EMAIL PROTECTED], Carl Hoffman [EMAIL PROTECTED] Hi, Daniel. Thanks for your email. We'd be happy to have you add AFFLIB to the Gentoo distribution. I'll answer your questions: Is inclusion in an online database like http://packages.gentoo.org? advertising and therefore subject to the clause 3? No, we do not consider that advertising. What happens if a security vulnerability is found and a GLSA (Gentoo Linux Security Advisory) is issued. We wouldn't consider that to be an advertisement either. What about a magazine article on Gentoo? We don't consider that to be an advertisement. The University of California, Berkeley revoked their clause 3 in 1999 I believe because of similar legal vagueness over advertising. (ref: http://www.freebsd.org/copyright/license.html) Yes, I'm aware that they did this. We've decided to keep the advertising clause because Basis Technology, the company that funded a substantial amount of the AFFLIB development, wishes to be acknowledged in computer forensic products that use AFF. We do not consider the bundling of AFFLIB on a CDROM or online distribution of Linux utilities to meet the requirements in section 3. Section 3 states: * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: If your advertising of Gentoo mentions features or use of AFFLIB, then we would expect you to say that AFFLIB is a product of Simson Garfinkel and Basis Technology. But if you are merely including the code and not mentioning the fact that you include AFFLIB in your advertisements, then you have no need to mention Simson Garfinkel or Basis Technology in your advertisements either. I hope that this email clears up any questions that you might have. But if you have others, please feel free to drop me an email. -Simson On Feb 6, 2007, at 6:58 AM, Daniel Black wrote: Simson, Was looking at the afflib product and was considering adding it to the Gentoo distribution when I looked at the license and found the BSD-4 license variant. The problem with the particular license is the condition 3 advertising clause and its vagueity. Is inclusion in an online database like http://packages.gentoo.org? advertising and therefore subject to the clause 3? What happens if a security vulnerability is found and a GLSA (Gentoo Linux Security Advisory) is issued. Is this an advertisement? If Gentoo does a booth at an Expo is this included? What about a magazine article on Gentoo? The University of California, Berkeley revoked their clause 3 in 1999 I believe because of similar legal vagueness over advertising. (ref: http://www.freebsd.org/copyright/license.html) Can you consider doing the same? Other references: http://farragut.flameeyes.is-a-geek.org/articles/2007/01/08/a- shadow-lies-upon-all-bsd-distributions -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation --- -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgpidPCO0WYp1.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
I sort of missed this conversation, so apologies in advance if this has already been covered, but wanted to say that gentoo's initscripts are generally not suited for embedded systems. So making baselayout busybox-compatible doesn't seem to be worth the disruption and headaches it would cause. It would be disruptive for gentoo developers who would need to be extra-careful in maintaining their initscripts to ensure busybox compatibility. Not to mention the potential disruption for users. If you are building an embedded system using busybox, then generally you will want a single /etc/init.d/rcS script that starts all the stuff you need. -Daniel On 2/8/07, Mike Frysinger [EMAIL PROTECTED] wrote: On Thursday 08 February 2007, Roy Marples wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Wednesday 07 February 2007, Roy Marples wrote: In the current code I'm running it's only the network stuff that uses arrays. If you're thinking about /sbin/functions.sh, well that can stay as bash as it's not used by baselayout anymore. some init.d scripts use arrays as well Do we know which ones? grep for it :p netmount for sure right now The actual scripts themselves can be re-worked if they need to be - this problem only when the arrays are used in config files. i guess my point was i think we really need to be consistent here ... either arrays are OK for init.d scripts or they're not OK did you get a chance to see how hard it would be to integrate the bash array code ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On 2/8/07, Ned Ludd [EMAIL PROTECTED] wrote: As somebody that's had to hand write many of those kinds of scripts. A single rcS is not very ideal. Our init scripts are in fact mostly usable by busybox. Granted there are a few special special cases, but then Roy is offering to update those for free. One of the larger problems really boils down to many packages provide default init.d scripts and these expect the existing baselayout only. That will be a bigger feat to deal with later on down the road. Developers will then need to test their init.d scripts to ensure that they are compatible with busybox. This is asking a lot of work of people just so you can use Gentoo's initscripts for something they are not really ideal for. Any time a script is updated a new rev of a package is required, and this does impact users and will cause packages to be rebuilt when a user does emerge -u. So I think this should be weighed against the potential benefits of baselayout + busybox. If you are targetting something smaller than 32MB, then maybe busybox is appropriate. But you are trying to go really small, then you probably don't want all the extra junk in our initscripts. And if you are _not_ trying to go really small, then put bash in your filesystem, not busybox, and the initscripts will work. If bash isn't fast enough from a boot time perspective, then the gentoo initscripts certainly aren't going to be fast enough either. In other words: busybox + single rcS file = fastest and simplest, smallest, best for very small filesystems, not as flexible bash + gentoo baselayout = most flexible, biggest, slower, best for feature-rich systems busybox + gentoo baselayout = ? I think that in 99 out of 100 cases, if you have room for baselayout, then you probably have room for bash too. And in 99 out of 100 cases, if you can deal with the load time of baselayout, then you can deal with the overhead that might be incurred from having bash. I'm just pointing out that it's not an obviously good combination. In the grand scheme of things, maybe it's not a great use of developer resources. Or, maybe I'm wrong and it is a great idea. Personally I think that baselayout + busybox may be cool, but adding an aftermarket sunroof to your car can be cool too. But that doesn't mean it's worth the effort :) Really, it's hard for me to imagine many scenarios where you really need the flexibility of baselayout but can't squeeze in bash. And I have a pretty good imagination. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
On 2/9/07, Mike Frysinger [EMAIL PROTECTED] wrote: forking the package is retarded. maintain backward compability and there's no reason to fork it. baselayout isnt Roy's package, it isnt my package, it isnt anyone's. it belongs to Gentoo as a whole which means changes to it affect everyone in the distribution. -mike I totally agree with Mike here. Roy, here is what I suggest you do: 1) maintain the existing baselayout and don't change things at all. 2) start a new package called fastlayout and do whatever you wanna do with it. Be as innovative as you want to be with it. Change all the stuff in it that you want to change. Get people to test it and work on it with you. 3) once fastlayout is done and mature and is obviously better/faster/more wonderful than the existing baselayout, *then* let's talk about it becoming baselayout-ng. I have learned from experience that you never want to start a project and call it something-ng. Doing so takes for granted that it will be the official replacement for the existing baselayout. Thus, every proposed change is now a potentially disruptive change, and people will want to review every design decision you make - and with good reason. People don't like change unless they can see the obvious benefits of such change. And it is hard for people to see these benefits when you are just in the planning stages. That's what we call a catch-22. Ever wonder why every official portage-ng project would die within weeks of being launched? This is why. The pkgcore/paludis model, where neither is blessed as being the eventual successor of portage, is a model that works. something-ng is not a model that works for any meaningful change for Gentoo. You have every right to scratch an itch, go scratch it. But it will be slow going if you refer to this effort as the eventual successor to baselayout. Making incremental changes to baselayout with no clear roadmap is a bad idea and people will be critical of anything you propose. It's *far* better for you to work independently and create something that, when it's ready, we can all switch over to because it is clearly better, well-integrated - and done. Structured this way, fastlayout is certainly a project that sounds like a great idea, and would I enjoy working on in some capacity - I have some ideas about this. I also think it would be a good idea to check out what other distributions are doing in this area. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Timezone /etc/conf.d/clock
I think the easiest approach then would be to have an /etc/timezone directory that should have a single file in it with the current timezone. This file could be copied from /usr and keep the original name. example: /etc/timezone/MST7MDT Pretty easy to understand and deal with. What do you think? -Daniel On 2/15/07, Anders Bruun Olsen [EMAIL PROTECTED] wrote: On Thu, Feb 15, 2007 at 08:01:11AM -0500, Caleb Cushing wrote: which most probably aren't since that was changed in the handbook (wonders why it was). It might have something to do with the fact that FHS specifies that /usr does not have to be on the root partition and thus using a symlink in /etc to somewhere in /usr is bad because most of the stuff in /etc is needed during boot, before other partitions are mounted. Moving away from using a symlink for localtime is therefore a step in the right direction for FHS compliance. -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=getsearch=0xD4DEFED0 -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Timezone /etc/conf.d/clock
Um, alternatively you could just copy /usr/share/zoneinfo/foo to /etc/localtime rather than having a symlink. Since the zoneinfo file has the name of the timezone in it already, it is probably not necessary to preserve the filename of the timezone file. -Daniel On 2/16/07, Daniel Robbins [EMAIL PROTECTED] wrote: I think the easiest approach then would be to have an /etc/timezone directory that should have a single file in it with the current timezone. This file could be copied from /usr and keep the original name. example: /etc/timezone/MST7MDT Pretty easy to understand and deal with. What do you think? -Daniel On 2/15/07, Anders Bruun Olsen [EMAIL PROTECTED] wrote: On Thu, Feb 15, 2007 at 08:01:11AM -0500, Caleb Cushing wrote: which most probably aren't since that was changed in the handbook (wonders why it was). It might have something to do with the fact that FHS specifies that /usr does not have to be on the root partition and thus using a symlink in /etc to somewhere in /usr is bad because most of the stuff in /etc is needed during boot, before other partitions are mounted. Moving away from using a symlink for localtime is therefore a step in the right direction for FHS compliance. -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=getsearch=0xD4DEFED0 -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
For speed, there are a *lot* of changes/improvements that could be made. What I would like to see is the ability to get to a login prompt before startup is actually completed. Have all the non-essential startup stuff run in the background. Yes, this would require a sophisticated system since you could log in and start something that requires something that has not yet been started, and it would need to understand and deal with this appropriately and gracefully. But I think it would be cool. The perception of speed is based on how long you have to wait before you can do stuff. -Daniel On 2/16/07, Paul de Vrieze [EMAIL PROTECTED] wrote: On Friday 09 February 2007, Roy Marples wrote: On Thu, 8 Feb 2007 14:49:57 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: In other words: busybox + single rcS file = fastest and simplest, smallest, best for very small filesystems, not as flexible bash + gentoo baselayout = most flexible, biggest, slower, best for feature-rich systems busybox + gentoo baselayout = ? FreeBSD sh + Gentoo baselayout = cold boot in around 4 seconds Going to multi-user from single user after a boot is under 2 seconds (times measured from when init starts rc - the difference is probably because the all my local mounts are still mounted) I have this running on a 2Ghz P4 Laptop right now. Admittedly, no network scripts are started expect for the loopback interface, but all default scripts + openvpn, ssh, dnsmasq, metalog and vixie-cron are started. Ladies and gentlemen, this has always been about one thing - speed. Ever since I got my 300Mhz Sparc64 to play around with FreeBSD, I've realised that baselayout + bash is just too damn slow. I think that's worth it. If that's what you want, don't use bash in the first place. I would agree that using bash for parsing is a pain in the but Daniel is right in that you're not going to be able to maintain posix compatibility. If you find an acceptable way to add the functionality to the network configuration files, it is ok, but sacrificing usability over an unmaintainable improvement doesn't work. If you want to speed up boot, the dependency generation is probably what's eating most time. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Timezone /etc/conf.d/clock
Well, sure, but the timezone-data ebuild could be upgraded to check to see if /etc/localtime is old or not and inform the user or even take appropriate steps to automatically fix this (dangerous?) This may not be possible with a direct copy to /etc/localtime, but it should work with the /etc/timezone/MST7MDT idea since the corresponding file can be located and compared. -Daniel On 2/16/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Fri, 16 Feb 2007 16:36:53 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: | Um, alternatively you could just copy /usr/share/zoneinfo/foo to | /etc/localtime rather than having a symlink. Since the zoneinfo file | has the name of the timezone in it already, it is probably not | necessary to preserve the filename of the timezone file. No good when timezone-data is updated. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Timezone /etc/conf.d/clock
OK, I did not understand how it was supposed to work. Is there documentation anywhere that explains how it works and why? -Daniel On 2/16/07, Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 16 February 2007, Daniel Robbins wrote: Well, sure, but the timezone-data ebuild could be upgraded to check to see if /etc/localtime is old or not and inform the user or even take appropriate steps to automatically fix this (dangerous?) as Ciaran said, this is plain not doable the new system works: declare timezone in /etc/conf.d/clock and the timezone-data ebuild will automatically update /etc/localtime with the correct value as for /etc/timezone/, i dont see how that solves anything -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] rfc: upstart on gentoo
Oh, and a bit of history - at one point, I used djb's supervise as part of the initscripts so that we could do stuff similarly to upstart. When the initscripts were rewritten, we went to bash and had the intention of adding process monitoring and restart eventually - but gentoo was growing so fast that we never really got to do this. -Daniel On 2/16/07, Daniel Robbins [EMAIL PROTECTED] wrote: I don't see any reason why not to add it. It would certainly make it easier to play around with. On 2/16/07, William Hubbs [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I saw that we have a request for an ebuild for upstart. I am looking it over and looking at the sample jobs that can be downloaded from the site. I think this would be an intresting idea, and I'm curious what others on this list would think about it. Thanks, - -- William Hubbs gentoo accessibility team lead [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF1mGtblQW9DDEZTgRAvWLAJ9OIkAA1KsEt3aHhaVs2x4kwO2nggCfQ4Mv D4ZZtxhpaV3N5G19iYJ8aOo= =TUtu -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] the destiny of the 2.4 headers
Mike, I think you have a good plan. Retiring the 2.4 headers sounds like the right thing to do. Building glibc against 2.6 and enabling backwards compatibility with older kernels should not be problematic. It all sounds good from a maintainability and stability perspective. Nothing should break in theory, but of course in this line of work there is no guarantee that there won't be unexpected transition problems for real users on real systems - but you know that already. With some reasonable amount of testing I think it is a great idea. -Daniel On 2/17/07, Mike Frysinger [EMAIL PROTECTED] wrote: now that the 2.6 headers have entered a sane state and are *quite* nice to work with, i have no inclination whatsoever to touch unsanitized headers (keep your puns to yourself :p) so here's the question i pose: what to do ? people file bug reports saying package FOO fails to build with linux-2.4.xx headers ... my answer is well, that sucks, but package FOO is not going to be changed as it builds correctly with sanitized linux-2.6.xx headers do we want to try and maintain our own sanitized 2.4 headers ? this would require our own git tree as trying to do development on a patch-based setup is an exercise in insanity ... or perhaps we want to unmask the sanitized 2.6 headers for use on a 2.4 profile ? the core ramifications: beneficial actually; we tell glibc what the min kernel version it needs to run on (2.4.1 currently), and it will enable all features required between that and whatever kernel version your headers are ... so if you were to upgrade your kernel, glibc would automatically take advantage of the newer system calls -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Summer of Code - worth repeating?
I agree that we should do it. Looking a the list for 2006, I think we should steer clear of projects that might require significant knowledge of Gentoo Linux internals or that may have a lot of difficult interdependencies and/or coordination. For example, moving to a different revision control system does not, at least on the surface, seem like a project that a single SoC student could pull off, considering the significant amount of coordination required. I think I good way to start 2007 would be to put together an informal guide for how to choose appropriate SoC projects. These guidelines should be geared towards helping to ensure a greater likelihood of rapid progress and successful completion. My list: 1) Should be a specific, focused problem or challenge 2) Should not have a large number of technical inter-dependencies 3) Should not require significant cross-team coordination/project management work 4) Anything that touches core gentoo functionality should be done as a proof of concept, not as an official replacement (changing official core stuff has distro-wide implications which is not suitable for SoC efforts and makes the design stage overly complex - officialness can be considered afterwards if the SoC effort is successful) 5) An emphasis on training and mentoring future Gentoo developers to bring lasting benefits to the project. This means: interesting, fun projects, good experiences are more important than solving incredibly thorny problems. 6) The challenges need not be hard - this is not our money so we need not set artificially high expectations. We should not expect a student with relatively little Gentoo experience to solve challenges that we have struggled to find solutions for. 7) Projects should be achievable by a single person working part-time over 3 months (this *is* summer, after all) and have clearly defined goals for completion. -Daniel On 2/20/07, Christel Dahlskjaer [EMAIL PROTECTED] wrote: Hiya all, Let's do a quick re-cap of Summer of Code '06: Gentoo had 14 project slots, out of these fourteen two were on Gentoo external Gentoo project which I will leave out of the re-cap. That leaves us with twelve projects, four of which were being worked on by at the time current Gentoo developers. Leaving us eight newcomers, out of these eight four has been recruited and I belicve an additional one is in the recruitment queue. Some of the projects have been picked up and are being worked on daily, some we've had problems getting acceptance for from the projects where they would be most suited (Beacon - GDP), and some may have fizzled off and died when SoC ended (be that because the student were no longer involved and didn't feel that they were welcomed into the community post-soc, or be that because it just didn't end up being a small idea turned explosion). Summer of Code 2006 was thrown together practically overnight, we jumped onboard after the deadline, by pure luck, and due to lack of planning ended up with whatever projects people could think up in no time and what mentors felt comfortable mentoring at said time. Based on the timeframe and having to jump into the deep end I'd say SoC was a tremendous success for us, not least as a recruitment tool. And of course, it feels great to put something back into the community. Summer of Code '07 is about to kick off, those of us who participated in one form or another last year are pretty geared up to do it again. This time around we've got a chance to plan better, apply in time.. Should we SoC? Of course we should! Can we think up projects? Do we have willing mentors? Will Google have us once more? (with feeling) Summer of Code itself should be a lot more organised this year, OSPO has put a fair chunk of work into getting things up to speed and has listened to the feedback of both students and mentoring organisations from last year. -- Christel -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] gentoo-sources-2.4 removal
Unfortunately I didn't find any suitable candidates from the call for help that went out in the GWN recently. I have contacted all applicants explaining how they can improve their skills, build up a series of contributions, and become more likely developer candidates in the future. Unless something changes, gentoo-sources-2.4 will be put in package.mask on March 1st and removed from portage on March 31st. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] let's clear things up (was Slacker archs)
On Tue, 2007-02-20 at 08:11 -0500, Stephen P. Becker wrote: On Tue, 20 Feb 2007 01:35:32 + Ciaran McCreesh [EMAIL PROTECTED] wrote: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. snip Wow, I almost don't know where to begin. The amount of FUD, misinformation, and outright lies floating around all of this bullshit is astounding. snip again I'd like to chime in here, if I may, with some personal experience. I've been involved with arch keywording from both sides (being in the amd64 herd, and being the current gnome lead), and I have to say that it's definitely blown out of proportion. Yes, keyword bugs slip through the cracks. Some of my gnome keyword bugs hang around forever; sometimes, in my bug sweeps for amd64, I find keyword bugs that have been hanging around forever. It happens. However, there have been a number of cases recently for gnome where we wanted to punt old versions of gnome. We like to only keep 1-2 old versions around, so we remove whole sets of packages every 6-8 months. In this, we're probably close to unique. Many of these are newest keyworded versions on some arch or other. Generally, all the arches have been responsive to the problem, either by keywording newer versions, or by agreeing to drop keywords. Again, there's the odd case; but that seems to mostly be oversight. Summary: I don't see a real problem with any arch, mips included, either from the arch side or from the gnome side. There's more gnome cruft in the tree from us failing to clean intermediate versions up than there is from slacker arches. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
Hi Ciaran, Can you please refrain from making inflammatory accusations in your posts? This is not a forum for airing personal grievances, and they do not serve any purpose besides encouraging others to do the same to you - as you have discovered. -Daniel On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 11:46:32 +0100 Francesco Riosa [EMAIL PROTECTED] wrote: | Better protect gentoo and it's developer, especially the more active | ones from the gravitational waves of those few, very annoying | satellites. Then it will be possible to actually work to the rest. You mean the developers who try to blackmail devrel into firing people they don't like? The developers who go around abusing arch teams at every given opportunity because they won't do exactly what that person wants when he wants it? The developers who manage to make a huge deal out of fixing up some small package by blogging about it incessantly instead of doing real work? The developers who resort to childish personal attacks like misspelling someone's name whilst skipping all factual content in their replies? The developers who refuse to handle bugs submitted by people they don't like? I agree entirely. Gentoo does need to be protected from those kinds of people. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
First, by directing this email at you, I am not in any way suggesting that others are justified in attacking you or that you are at fault in a technical sense. That being said, it's generally futile to bitterly demand that people treat you with respect. It doesn't work. So, that means that if you are falsely accused of something, and you post an equally accusatory or biting response, you have now become part of the problem by descending to their level, and it's no longer clear that only one party is at fault. The best strategy is to just be genuinely considerate and bambi-like even when people don't deserve it, and hope that it catches on. People tend to respond in kind. You have reaped a bit of a whirlwind with your regularly caustic/sarcastic posts, and I am sure that this has contributed to people perceiving you in a negative light and instinctively responding to you in a negative way. You also tend to keep the flame alive with your very good recollection of the faults of others. It really isn't an issue of who is right or wrong, but an issue of exercising basic social graces so that people aren't continually out to get you. It's not about changing the subject, but rather discussing the subject without engaging in biting dialogue. Really, I think the root of it is that your frequent caustic sarcasm is often interpreted as a personal attack or put down by nearly all cultures of the world. Sarcasm doesn't work well over email, and it's easily interpreted in a way that you might not intend. So from the perspective of many, right or wrong, it is you who is starting the fight. -Daniel On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 10:12:26 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: | Can you please refrain from making inflammatory accusations in your | posts? This is not a forum for airing personal grievances, and they do | not serve any purpose besides encouraging others to do the same to you | - as you have discovered. So, wait... It's ok for people to post wild conspiracies blaming the whole Diego thing on me, but it's not ok to post factual material in response? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Ciaran, Admittedly, I'm new to this PMS thing so in many cases I'm speaking from a position of ignorance, but I guess I need to jump in somewhere I think that standardization is a good thing and interoperability between paludis, portage, pkgcore and others is something we should strive for. If at all possible, I think that this standardization effort should be multi-lateral in the sense that Gentoo and pkgcore are also active participants in the standardization process. Also, I don't think that the council itself needs to be involved directly, as a standards/spec project can be created and worked on, and the conformance of Portage to this standard can be measured, and if desired Portage developers can tweak portage so that it is more conformant to this standard. This can be done voluntarily by all parties, as they deem it useful. The goal would be to have the ability to measure a package manager's behavior against a known standard, rather than force a certain package manager to behave a certain way. I would expect that the general concern for interoperability within the Gentoo community will encourage package manager developers to work towards resolving any interoperability problems that do exist. I think standardization should focus on real interoperability issues, rather than esoteric technical issues. I think a good way to start would be to create some kind of test/regression suite in the portage tree that can be used to measure the package manager's functionality. Some stuff would be of an obvious pass/fail nature but other things can be couched in more subjective terms - like will unmerge device nodes - yes/no That at least would allow us to measure where we are in terms of interoperability, and identify future areas of improvement. Like I said, I'm just getting familiar with all this but those are my thoughts. -Daniel On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 10:22:14 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Perhaps not all of the council; distinctly recall diego pushing about | it though. Quick look through council logs, robbat2 was asking about | timeline also (jan. meeting specifically). You've gotta ask *why* certain people are so keen on pushing it through... Perhaps if they explained why they needed it in such a hurry we would prioritise it differently. | Several council member have access to it - including me - and | are quite confident about what is already done. | | The question was specifically in regards to timelines; completion so | that ongoing paludis vs pkgcore vs portage crap can be put to rest. *shrug* I don't see PMS as being viable until there's a fully conformant independent implementation, personally. So that more or less means that for me, PMS will become a priority at around the same time that Paludis 1.0_pre is released. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
OK, my initial impression of this is:
1) ebuilds and *especially* eclasses do way too many weird things and
can often depend on idiosyncrasies of portage. The eclass bash scripts
can be quite complex and probably 9 out of 10 (99 out of 100?) times
I'd put the burden of compatibility on the eclass rather than the
package manager, because it's the eclass that's trying to do weird
stuff.
2) to ensure cross-package-manager compatibility, all one would need
to do is document what one can and cannot assume regarding Portage
functionality. I see no harm in having the ebuilds/eclasses assume
less and encourage others to write more robust and compatible ebuild
and eclass functions.
3) I regretfully added eclasses to portage. Although they're useful, I
don't think they ever made sense from an architecture perspective and
are certainly not pretty. Eclasses are nearly ubiquitous now, which is
unfortunate. I can't remember seeing an eclass that I ever liked, even
if the functionality was really useful and everything was
well-written, thought out, documented, etc.
4) Building on 3, I think there are two ways of life in the world of
Portage - either the eclasses control you, or you fight back a bit and
control the growth of eclasses. The eclasses are sort of an
anti-architecture so I think our will should to be imposed on them
rather than the other way around. Otherwise you are in a catch-22
where we are continually adding tons of weird legacy code in the
form of eclasses and this problem of cross-package manager
compatibility will never go away.
Those are my thoughts, anyway...
If you wanted to get me to agree with you by giving me lots of eclass
compatibility issues, then it worked :)
-Daniel
On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Tue, 20 Feb 2007 12:19:12 -0700 Daniel Robbins
[EMAIL PROTECTED] wrote:
| I think that standardization is a good thing and interoperability
| between paludis, portage, pkgcore and others is something we should
| strive for. If at all possible, I think that this standardization
| effort should be multi-lateral in the sense that Gentoo and pkgcore
| are also active participants in the standardization process.
Well, Gentoo already is a participant, in that there are a number
of Gentoo developers with access to the document... At this stage, we're
deliberately keeping the numbers down because we want to get it done
rather than spend huge amounts of time arguing with the peanut gallery
(the same approach we took with eselect, the devmanual and Paludis,
rather than the approach taken with portage-ng and Zynot).
| Also, I don't think that the council itself needs to be involved
| directly, as a standards/spec project can be created and worked on,
| and the conformance of Portage to this standard can be measured, and
| if desired Portage developers can tweak portage so that it is more
| conformant to this standard. This can be done voluntarily by all
| parties, as they deem it useful.
The reason the Council is involved is because someone has to give final
approval. This won't be asked for until late on in the process.
| I think standardization should focus on real interoperability issues,
| rather than esoteric technical issues.
The esoteric technical issues are the problem, though. The areas where
there are interoperability problems are the areas where ebuilds are
doing weird things, like relying upon side effects of one
implementation of inherit or trying to manually modify vdb or assuming
that certain variables that contain directory names will not include a
trailing slash. The question is whether the ebuilds are wrong in
expecting to be able to do this, or whether package managers have to
emulate weird quirks in how Portage is currently implemented.
I'll give you a perfect example. Paludis currently includes the
following workaround:
archives = strip_trailing(archives, );
all_archives = strip_trailing(all_archives, );
The reason that this is necessary is because kde-meta.eclass does this:
[[ -n ${A/${TARBALL}/} ]] unpack ${A/${TARBALL}/}
Which means that if a package manager includes trailing spaces in ${A},
the eclass will break. Personally I consider this to be an eclass bug,
but without some standard to back it up there's no concrete answer
either way.
Another example along the same lines (this one's now fixed in the tree,
but it's a good example of weird side effect behaviour): The PHP
eclasses used to set a global scope variable called EXT_DIR based upon
the value of a variable called PHPCONFIG. The PHPCONFIG variable was
set in pkg_setup, and the EXT_DIR variable was used later on. For
Portage as it is currently implemented, this happens to be ok, because
eclasses are re-sourced for every phase. For Paludis this breaks,
because we implement the environment saving that Portage is going to do
at some point to avoid the eclass API problems.
Another example: A certain eclass we all know and love used to use
SLOT=${PVR} and then force
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Ciaran, Is there any way that the public can view the PMS spec that you have created so far? I am not totally familiar with how you are going about developing PMS, but based on some of your comments in this thread I'm a little bit concerned. -Daniel On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 23:47:04 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: | On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: | This is standard practice for professional standards, and is the | | Now you talk about this, a standard is, in standard practice, the | result of a collaborative effort of representing members of the | organization(s) that is (are) supposed to adhere to said standard. I | believe I don't need then to explain you how far what happens around | PMS is from standard practice. You know that real standards aren't a free for all, right? They're usually written by a small group, and then commented on by interested parties when they're already well into being written. Which is exactly what we're doing... | You say you want to avoid endless discussions in the interest of | getting it finished. Now, if your work is that good, why would there | be any discussions about it? Because there are a lot of people with opinions out there, and they will all start saying things like well it would be better if things were like $blah, so you should change it to say $blah. Have a look at the amount of noise that comes up any time this kind of discussion takes place on this list... Heck, have a look at the number of people already trying to comment upon how the standard is being written without having seen it... | If it's not good enough, why wouldn't you let us talk about it and | make it better? We will let you (for values of you where your opinion is useful and relevant) discuss it when it is at an appropriate stage. | Also, if it goes in the wrong direction, one that | Gentoo devs won't follow, what's the point in finishing it? It isn't going in the wrong direction. The third parties who have access to it will tell you that. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Global ebuild variables and pkg_setup
Ciaran,
It looks like a fairly trivial thing to fix in ebuilds.
I think the problem you may be having is that people don't have any
incentive to make short-term changes to their ebuilds just so you can
get Paludis to work with them. It needs to be part of a larger
interoperability plan that includes all interested parties, and serves
the needs of everyone, not just the Paludis developers.
-Daniel
On 2/21/07, Ciaran McCreesh [EMAIL PROTECTED] wrote:
A number of ebuilds do things like this:
inherit foo
VAR=${FOO_VAR}
src_compile()
{
emake blah=${VAR}
}
where foo.eclass looks like this:
foo_pkg_setup()
{
export FOO_VAR=baz
}
and where VAR is usually one of the KV variables from linux-info.
This works with Portage as it is currently implemented because Portage
re-sources everything between every phase. However, it breaks with pure
environment-saving based ebuild implementations, including Paludis and
possibly Portage in the future (pure environment saving is the only way
to avoid the removing eclass problems). So, the question:
Is this something that has to work (at the expense of never allowing
eclass removal in the future), or is it a fluke and are ebuilds that
use it broken? An easy workaround is to move the ebuild global
variables into pkg_setup, and call the eclass_pkg_setup from within the
ebuild pkg_setup.
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On 2/21/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: Are you insane? What on earth could Jakub possibly contribute? If you want a rough indication of Jakub's level of ebuild understanding, take a look at bug 160328. Is there any process in place to ban people from the gentoo-dev mailing list who are chronically verbally abusive and make no effort at all to be polite? We shouldn't have to put up with this. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On 2/21/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: I'm perfectly polite when I'm not replying to the dozenth deliberate attempt to derail something into which I have put a lot of effort... Look, I don't want to waste everyone's time by dismantling in painful detail the foolishness of what you just said, and how it is not an adequate excuse for your behavior. Instead I'll just hit the key points: You can't just launch gratuitous insults at a developer when it appears to be a helpful way to derail someone's totally valid technical suggestions. This doesn't help Paludis, it doesn't help Gentoo, it wastes your time - it helps NO ONE. It's not just offensive to the person you just publicly humiliated, but it's also a slap in the face to all of us who have put a lot of work into making Gentoo a great and fun project to be a part of. Frankly, it would also be a slap in the face if it turns out that no one cares enough about the Gentoo community to remove you, and others that behave like you, if there are any others, from our mailing lists. Otherwise, a few are allowed to ruin the experience of all. Also, talk about derailing Paludis - *your behavior* is what's derailing the future of Paludis and making people uncomfortable with your solo development style. I will not use Paludis, contribute to it, or suggest that others use it simply because I don't like how you find it so easy to shamelessly berate other people. To have a successful open source project, you need to be at least somewhat successful at getting along with people. You at least need to try. You are not trying. Also, Paludis looks like it is, overall, a well-designed re-implementation of Portage, but I hope you don't think it's so wonderful that you think you can act like a total jerk and expect the project will be a long-term success. *No* project is that wonderful. In fact, I would expect that the way you are acting will lead to others working aggressively to try to ensure that Paludis becomes irrelevant by the time it is completed. It's just human nature, and human psychology and human nature typically drive open source projects. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On 2/22/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: And if you want a perfect example of reverting to ad hominem rather than technical discussion, I suggest you reread your own email. I did. I don't see any ad hominem attacks. I was very careful not to say anything nasty. Even assuming I am a hypocrite - philosophically speaking, I am sure we are all hypocrites to a certain extent, yes? - this doesn't give any of us permission to behave in flagrantly nasty ways over and over again and not be called on it. That's the fallacy in your argument. At this point, I am going to separate myself from this conversation and wait to see what action is taken, if any. Really, I think you are mis-using your debating skills, as you were clearly in the wrong, and what you said was indefensible, so you should have just apologized. I tend to get pulled into these things because a) I care about Gentoo and b) I don't like to see people get away with crap over and over again by using cheap debating tricks. But I will cut myself off from this thread now. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: What do you think about removing gtk-1.2 theme engines from tree?
On Sun, 2007-02-25 at 21:31 -0600, Ryan Hill wrote: Andrej Kacian wrote: It makes sense slowly removing *applications* depending on gtk1. Themes should go last, along with gtk1 itself. Gtk1 is already ugly enough, do you want it to be even more ugly? Point, set, and match. Much as I hate gtk1, I agree with this. Leave the themes as long as they're working and there's apps. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Introducing Daniel Robbins (drobbins)
Hey all, and thanks for the welcome back. It was a bit strange to find old stuff from 2005 in my dev.gentoo.org homedir. Sort of like a time capsule :) -Daniel On 2/27/07, Petteri Räty [EMAIL PROTECTED] wrote: It's my please to introduce to you Daniel drobbins Robbins. Daniel is going to work with the amd64 arch team but will probably venture to other areas too. Daniel doesn't have much experience with Gentoo so let's give him a helping hand in the start. In his dark past Daniel has worked for companies like Microsoft so maybe Gentoo/NT will be a reality after all? Please give him the usual warm welcome. Regards, Betelgeuse -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: What do you think about removing gtk-1.2 theme engines from tree?
Hey Chris, I pretty much agree with you in regards to themes. Without strict rules, we can suddenly have floods of ~300 theme ebuilds and they'll all get added to the tree. I'd suggest another exception: #3 It's ok to add themes to Portage if they are part of an official theme collection for a particular package. That way we have all the official themes - everything else would be up to the user to install. Portage was really designed for executable software, not for arbitrary collections of binary data (themes, ezines, etc.) Not that collecting/indexing those things is bad, just not really what Portage is aimed at. -Daniel On 2/26/07, Chris Gianelloni [EMAIL PROTECTED] wrote: On Mon, 2007-02-26 at 10:43 -0500, Daniel Gryniewicz wrote: On Sun, 2007-02-25 at 21:31 -0600, Ryan Hill wrote: Andrej Kacian wrote: It makes sense slowly removing *applications* depending on gtk1. Themes should go last, along with gtk1 itself. Gtk1 is already ugly enough, do you want it to be even more ugly? Point, set, and match. Much as I hate gtk1, I agree with this. Leave the themes as long as they're working and there's apps. I'm just curious, but why? It's not like people can't get GTK+ themes themselves quite easily. Personally, I don't think we should have themes (for anything) in the tree except for two cases: #1. The theme is considered part of an upstream package set, fex. if GNOME or KDE ship with a small set of themes, they should be included #2. The themes are made by Gentoo For anything else, let the user download what they want and use it as they see fit. There's not much reason to track them in the package manager. That being said, I'm not opposed to the themes staying in the tree, either. I'm just trying to find out people's motivations for either keeping them/removing them. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: What do you think about removing gtk-1.2 theme engines from tree?
On 2/28/07, Christian Birchinger [EMAIL PROTECTED] wrote: Those are theme-engines and not just a few pixmaps and with an rc file. The main part of those engines are compiled libraries. Don't treat them like a few files the user just has to copy in his homedir. Noted. Thanks for the reminder that it isn't always black and white :) -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] more up to date minimal install cd
On 3/1/07, Cory Visi [EMAIL PROTECTED] wrote: With Gentoo, once you are up and running, releases become very unimportant. What do you think? That's true, but ever wonder why so many people expend so much effort to have easy-to-use installers? It turns out that if installation is a pain, many fewer people actually end up using your software. Gentoo is more than just Portage. Now, maybe people in Linux land have been too obsessed with having a super-friendly installer - but it needs to be friendly-enough (and compatible-enough) and it might be a good idea to take a fresh look at how to streamline the Gentoo install experience. Right now, installing Gentoo is a chore, and the many wonderful choices of Gentoo end up making the install rather complicated. So I definitely support ideas to help make our installation process better/streamlined and less confusing. There are a lot of easy little things that could be done. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] A new security dev: Matt Drew (aetius)
Welcome Matt :) On 3/1/07, Petteri Räty [EMAIL PROTECTED] wrote: Please give the usual warm welcome to Matt aetius Drew. Matt pings us from Durham, North Carolina, USA. He says he lacks the skills that make someone a software engineer as opposed to a programmer. Well I hope he has never looked at Portage code. Insert random quotes: My best area of expertise is networking and firewalls - that's what I do at my job, along with security infrastructure like patching, maintaining software, and setting/enforcing security policy. I also did some pre-production testing on ia64, so I've suffered through many strange elilo problems and used to know my way around EFI (I've tried hard to forget it). I'm married and I have a 12-year-old adopted son. My wife has a Marine Science PhD and is currently working at NCSU with the BaSIC project trying to map out species lifecyles and movements in eastern North Carolina. My hobbies include guitar, computer gaming, board/role-playing games, political and social science, throwing my vote away on the Libertarian party, and encoding my old VHS tapes to digital media. Let's give him the usual welcome. Regards, Petteri (Betelgeuse) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
On 3/2/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: So, er, to whom does this deadline apply then, if not the people writing PMS? I have no clue. PMS is not a Gentoo project, so they can't impose a deadline on you. I don't think PMS is deserving of the council's time, as it is not an specification aimed at interoperability, but is a spec for a non-Gentoo project. The fact that it uses Portage as inspiration for its overall design, and is aiming to be compatible with Portage is irrelevant. In my opinion, it falls outside both the council's area of influence *and* intended focus. I believe that Paludis should be treated like any other upstream project. As such, I don't think the council should spend much time thinking about Paludis, and we should also not spend a disproportionate amount of time discussing its design on our mailing lists. If anyone is interested in Paludis cross-compatibility, they can join Paludis lists or irc channels and discuss this with Paludis developers on these lists (in my opinion.) I think there has been way too much blurring of these boundaries as well - partly your fault. I agree with Ciaran that the mention of PMS: deadlines and interested parties in the Council agenda trancends the actual authority of the Gentoo Council and should be reconsidered or at least massively clarified so we can understand why it is relevant for the Council to be discussing in the first place. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
In the interests of not being accusatory/one-sided, please replace this phrase: - partly your fault with the phrase due to ambiguity on the part of Gentoo and Paludis That is what I meant anyway. I shouldn't have expressed it in such a negative way. Sorry. -Daniel On 3/2/07, Daniel Robbins [EMAIL PROTECTED] wrote: On 3/2/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: So, er, to whom does this deadline apply then, if not the people writing PMS? I have no clue. PMS is not a Gentoo project, so they can't impose a deadline on you. I don't think PMS is deserving of the council's time, as it is not an specification aimed at interoperability, but is a spec for a non-Gentoo project. The fact that it uses Portage as inspiration for its overall design, and is aiming to be compatible with Portage is irrelevant. In my opinion, it falls outside both the council's area of influence *and* intended focus. I believe that Paludis should be treated like any other upstream project. As such, I don't think the council should spend much time thinking about Paludis, and we should also not spend a disproportionate amount of time discussing its design on our mailing lists. If anyone is interested in Paludis cross-compatibility, they can join Paludis lists or irc channels and discuss this with Paludis developers on these lists (in my opinion.) I think there has been way too much blurring of these boundaries as well - partly your fault. I agree with Ciaran that the mention of PMS: deadlines and interested parties in the Council agenda trancends the actual authority of the Gentoo Council and should be reconsidered or at least massively clarified so we can understand why it is relevant for the Council to be discussing in the first place. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
I don't understand half of what you said. You are saying that PMS is a sub-project of QA? Is the PMS spec hosted on Gentoo infrastructure? From all I have read, PMS is meant to define the functionality of Paludis itself, which is not a Gentoo project. Because of this, PMS can't be considered a Gentoo project. -Daniel On 3/2/07, Mike Frysinger [EMAIL PROTECTED] wrote: On Saturday 03 March 2007, Daniel Robbins wrote: On 3/2/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: So, er, to whom does this deadline apply then, if not the people writing PMS? I have no clue. PMS is not a Gentoo project, so they can't impose a deadline on you. except that it really is the council asked spb to put the EAPI spec together and it was moved to the space that is now dubbed PMS space -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
OK, but it appears that PMS is not hosted on Gentoo infrastructure, and its development is not controlled by Gentoo. Therefore it is not a Gentoo project, and therefore the Council, QA, etc. should not be treating it if it is a Gentoo project. Right? -Daniel On 3/2/07, Andrew Gaffney [EMAIL PROTECTED] wrote: Daniel Robbins wrote: I don't understand half of what you said. You are saying that PMS is a sub-project of QA? Is the PMS spec hosted on Gentoo infrastructure? From all I have read, PMS is meant to define the functionality of Paludis itself, which is not a Gentoo project. Because of this, PMS can't be considered a Gentoo project. That may be what it's meant to do now, but that was not the original purpose. It was originally to be a written specification of EAPI=0, which is essentially portage's current functionality. It's only later that the whole PMS == Paludis thing came about. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
On 3/2/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: PMS isn't Paludis. Paludis is an independent implementation (and the only completely independent implementation) of PMS, and it's necessary to have such an independent implementation to ensure that PMS is a specification rather than a description of one particular program. PMS (and Paludis) are not hosted on Gentoo infrastructure and their development is not controlled by Gentoo, so they are both not Gentoo projects and thus fall outside the scope of Gentoo. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
On 3/2/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: It's not hosted on Gentoo infrastructure purely because Gentoo infrastructure can't fulfil the requirements. It's not exactly unique in that respect... Nor are most Gentoo projects controlled by Gentoo. Try asking for a new feature in Portage sometime if you think that Gentoo has any say over how projects are developed... Gentoo projects are controlled by and generally run entirely by Gentoo developers. You are not a Gentoo developer, yet you define the direction of PMS and Paludis. Therefore, PMS and Paludis can't be considered official Gentoo projects. Paludis does not have a Gentoo Foundation copyright, does PMS? -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
On 3/3/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: No-one is claiming that Paludis is an official Gentoo project. This discussion, however, is about PMS, not Paludis, and the only reason I can see to keep confusing them is political, so please stop doing that. Sorry, the reason is not political. Nor do I define the direction of PMS. The requirements define its direction, and its contributors (the majority of which are Gentoo developers) do the writing. But you appear to act as the project lead for PMS. I am only trying to understand this as someone who has just recently started getting up to speed on PMS. It honestly appears as if you are the project lead for PMS, and you speak as if you have authority for the PMS project, and you are not a Gentoo developer, yet you claim that PMS is an official Gentoo project? That is confusing to me. I am not trying to pick on you or harass you but I am seeing something that appears on the surface to be a clear violation of what I understand to be Gentoo policy. That's confusing to me. Paludis does not have a Gentoo Foundation copyright, does PMS? Not currently, but then neither does devmanual, so it's hardly unique in that respect. That also means that the devmanual and PMS are not (currently) official Gentoo projects. Any official Gentoo project needs to hold a Gentoo Foundation copyright and be released under the appropriate license - otherwise it is not being adequately protected. I would be extremely surprised if this policy has changed. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] more up to date minimal install cd
On 3/3/07, Denis Dupeyron [EMAIL PROTECTED] wrote: What do you think of a simplified handbook ? One that presents a lot fewer choices to the user, in order to be less confusing. YES, it's needed. The handbook didn't turn out quite as I expected it to. It should document a typical installation process with small links to alternate approaches and options that a user might opt to follow. And it should be one (web) page. In my opinion. -Daniel -- gentoo-dev@gentoo.org mailing list
