[gentoo-dev] aging ebuilds with unstable keywords

[Daniel Ahlberg]

Hi,

This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 13973 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 413 minutes.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [dRFC] slotted mysql ready

[Kalin KOZHUHAROV]

Francesco Riosa wrote:
> Background, to make life easyer for people that use more versions of
> mysql (and just for fun) MySQL is going to be slotted.
> 
> Currently the slot enabled versions are mysql-4.1.16-r30
> mysql-5.0.18-r30 mysql-5.1.4_alpha-r30, in short those with "-r30".
> 
> The few patches needed are already included in current ~ mysql-4.1.16
> and mysql-5.0.18 but hidden due to SLOT=0, starting from 2005-11
> 
> An eselect-mysql module has been prepared to create simlinks for the
> desired version of mysql making easy to switch between them (hopefully)
> 
> The libraries (libmysqlclient & co) don't follow this logic and the
> higher version is always the default (similarly to sys-libs/db).

So how does this affect packages that use say dev-perl/DBD-mysql ?

If they can only use mysql-5, then the will be broken if they connect to a 
mysql-4 server using non
UTF-8 encoding. (bad wording, but generally speaking, there is an inconsistence 
in character
encoding betweet mysql-4 and mysql-5 that DOES break things on non ISO-8859-1 
encoded databases)

> The rc-scripts have been modified to use the logic of
> sys-apps/baselayout net.ethx => net.lo symlink to be able to start more
> servers at once (this is working from 2005-11 but reworked today)
> 
> Additionally the ebuilds code has been moved to two new eclasses,
> mysql_fx.eclass and mysql.eclass, the first own support functions, the
> last own the src_* pkg_* functions.
> The initial idea is that when a specific ebuild need to marked stable
> the code is moved from the mysql.eclass to the ebuild itself, to froze it.
> 
> Documentation on:
> o switch to slotted
> o upgrade with no downtime using this new capabilities
> need to be written from scratch (this is going to be the more difficult
> part for me).
> 
> there is a bash construct the eclass use to retrieve the latest two
> chars of a string, in the form: MYVAR="${MYARRAY[3]:(-2)}" , is this
> acceptable?
> 
> The intention is to made mysql-5.0.18-r30 stable on 2005-02-15 at
> maximum on the first archs.
> 
> AFAIK I'm the only one who have seen this stuff until now, any comment,
> any suggestion is highly apreciated.

Kalin.

-- 
|[ ~~ ]|
+-> http://ThinRope.net/ <-+
|[ __ ]|

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Last rites for www-apps/phpmp

[Jason Wever]

On Tue, 3 Jan 2006 16:44:22 +
Renat Lumpau <[EMAIL PROTECTED]> wrote:

> www-apps/phpmp has been package masked and will be removed from the
> tree in about a week. It is being superseded by www-apps/phpmp2.
> Please post comments to http://bugs.gentoo.org/74951 

In the future, if you are going to mask a package that will be
superseded by another, please make sure not to mask the original until
the replacement has matching keywords.  This is especially important
when the package has stable keywords.

Thanks,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead


signature.asc
Description: PGP signature

Re: [gentoo-dev] Projects and simple guides

[Brian Harring]

On Sun, Jan 08, 2006 at 11:30:16PM +, Stuart Herbert wrote:
> On Sun, 2006-01-08 at 12:54 -0600, Lance Albertson wrote:
> > > We could start a public wiki displaying all herds and projects. It would
> > > be great to add some low level docs, herds/project goals, ideas and so.
> > > Even the users could be allowed to edit and share information.
> > 
> > Anything like that will need to be approved by the GDP and a GLEP.
> 
> Are you sure?  The new metastructure makes it perfectly clear that
> "competing" projects are okay.  The GDP does not have a monopoly on
> documentation, only on what gets published through the /doc URLs on
> www.g.o.

Would like to see GDP reiterate this view actually, since I've a 
distinct memory last time I asked in irc about it I got an opposite 
answer from them.

Regardless, (imo) it's already been laid out why guideXML'ifying 
everything doesn't totally work.  Three reasons...

A) bit of work required just to jot down a quick list of "this is 
broke, fix it" that's going to be thrown out 2 weeks down the line.

B) guideXML requires actual vcs/shell access to commit the changes.  
Portage group relies fairly heavily on non-dev help to keep things 
going (throw cookies at antarus and zmedico, since they're the ones I 
speak of).  Yes (generally speaking) non-devs will be minted at some 
point as devs if they've put in the effort, but there _is_ a sizable 
delay built in, thus no vcs/shell till after we've deemed they're 
going to be around for the long haul.

C) delay in material commits to vcs actually hitting the web.  Kind of 
hard discussing in irc what needs to be done and having the list 
that's being built up delayed due to cvs up reasons- yes this seems 
minor, but it results in people writing up crap text/html pages 
temporarily for the need, then dumping it into docs.  Extra effort, 
I'd rather just modify the list in situ.

Basically... docs route maintains the artificial barrier between devs 
and non devs, which bluntly, is stupid.  If someone is contributing 
work, they're contributing work, as long as it doesn't suck I'm going 
to use their work regardless of whatever we've deemed them gentoo 
wise.

Yes, for portage docs we have to lock sizable chunks of it down, but 
that is locking it down to the groupping of portage devs- both gentoo 
dev and non-gentoo dev.

Note also I'm speaking mainly from a developmental angle- I'm not 
necessarily advocating that _non_ developmental docs be wikified, 
although there are pros to doing that.

~harring


pgpK9wa6fwjNf.pgp
Description: PGP signature

Re: [gentoo-dev] Projects and simple guides

[Marius Mauch]

On Sun, 8 Jan 2006 18:59:40 +0100
"Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote:

> I originally thought of putting it on my devspace, but using GuideXML
> there is a bit tricky, at least for me (as xsltproc seems to refuse
> working on the pure xml directly).
> 
> So I was thinking if we had a way to put some "how to fix" guides
> somewhere, on the lines of the ones written by soalr and vapier for
> hardened. A part the --as-needed thing, it might also be useful to
> put something about "how to solve parallel make issues" and similar
> things that are tricky but usually just requires little knowledge of
> tricks.
> 
> GDP might be the place where to put them, but as they are mainly 
> developer-oriented, they might be better accessed directly by devs
> (at least for the first steps until they are drafts).
> 
> What people think about this?

Find a nice place in www.gentoo.org/proj/

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature

Re: [gentoo-dev] GLEP 20 /srv - Services Home Directory Support

[Luca Barbato]

Kalin KOZHUHAROV wrote:

Luca Barbato wrote:


I'm thinking about adding the srvdir[1] global useflag.

Scream if I miss some discussion preventing it.

(fenice[2] will use it, that's why I'm adding it)

lu

[1] http://www.gentoo.org/proj/en/glep/glep-0020.html#implementation
[2] http://packages.gentoo.org/search/?sstring=fenice




Hi all,
not a dev, but please bear with me :-)


From [1] above:

GLEP:   20
Title:  /srv - Services Home Directory Support
Version:1.2
Last-Modified:  2004/11/11 21:35:53
Author: Stuart Herbert , Rob Holland 
Status: Approved
Type:   Standards Track
Content-Type:   text/x-rst
Created:09-Feb-2004
Post-History:   21-Feb-2004, 11-Nov-2004

It is 2006, any updates on this GELP?

Just a quick look turned out a 404 error on the FHS2.3 link. ( 
http://www.pathname.com/fhs/ ?)

I am not very read in LSB, but just saw there is a 3.x version...
What about LSB 3.x? Is it the same recomendation?

Although I run quite a bunch of services on a few boxes, I don't see this whole 
idea (/srv).
I read the GLEP, I read [FHS#srv] but still. And it says:
"The methodology used to name subdirectories of /srv is unspecified
 as there is currently no consensus on how this should be done."

So how does Gentoo implement it?

[FHS#svg]   
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM

And as the GLEP talks about webapps, what will an upgrade of a webapp (say 
Bugzilla) to/from srv?
I feel it breaking and user screaming.



that's an useflag you may use it or not, webapps use webapp-config that 
already handles /srv w/out any problem, having the base webroot using 
srvdir would be nice so you spare a couple of mv but that's all...


lu

--

Luca Barbato

Gentoo/linux Developer  Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] [dRFC] slotted mysql ready

[Francesco Riosa]

Background, to make life easyer for people that use more versions of
mysql (and just for fun) MySQL is going to be slotted.

Currently the slot enabled versions are mysql-4.1.16-r30
mysql-5.0.18-r30 mysql-5.1.4_alpha-r30, in short those with "-r30".

The few patches needed are already included in current ~ mysql-4.1.16
and mysql-5.0.18 but hidden due to SLOT=0, starting from 2005-11

An eselect-mysql module has been prepared to create simlinks for the
desired version of mysql making easy to switch between them (hopefully)

The libraries (libmysqlclient & co) don't follow this logic and the
higher version is always the default (similarly to sys-libs/db).

The rc-scripts have been modified to use the logic of
sys-apps/baselayout net.ethx => net.lo symlink to be able to start more
servers at once (this is working from 2005-11 but reworked today)

Additionally the ebuilds code has been moved to two new eclasses,
mysql_fx.eclass and mysql.eclass, the first own support functions, the
last own the src_* pkg_* functions.
The initial idea is that when a specific ebuild need to marked stable
the code is moved from the mysql.eclass to the ebuild itself, to froze it.

Documentation on:
o switch to slotted
o upgrade with no downtime using this new capabilities
need to be written from scratch (this is going to be the more difficult
part for me).

there is a bash construct the eclass use to retrieve the latest two
chars of a string, in the form: MYVAR="${MYARRAY[3]:(-2)}" , is this
acceptable?

The intention is to made mysql-5.0.18-r30 stable on 2005-02-15 at
maximum on the first archs.

AFAIK I'm the only one who have seen this stuff until now, any comment,
any suggestion is highly apreciated.


Francesco Riosa
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Stuart Herbert]

On Sun, 2006-01-08 at 12:54 -0600, Lance Albertson wrote:
> > We could start a public wiki displaying all herds and projects. It would
> > be great to add some low level docs, herds/project goals, ideas and so.
> > Even the users could be allowed to edit and share information.
> 
> Anything like that will need to be approved by the GDP and a GLEP.

Are you sure?  The new metastructure makes it perfectly clear that
"competing" projects are okay.  The GDP does not have a monopoly on
documentation, only on what gets published through the /doc URLs on
www.g.o.

Best regards,
Stu
-- 
Stuart Herbert [EMAIL PROTECTED]
Gentoo Developer  http://www.gentoo.org/
  http://blog.stuartherbert.com/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Projects and simple guides

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lance Albertson wrote:
> Luis Medinas wrote:
> 
>>On Sun, 2006-01-08 at 12:54 -0600, Lance Albertson wrote:

> 
> 
> I had thought about creating some kind of a site like this, but not
> necessarily in a wiki form. I don't like the idea of letting users add
> random docs. There's too much room for error and how do you deal with
> accountability? There has to be a developer who either will take the
> time to maintain it or accept responsibility for any errors it may have.
> I like the idea of having an area for herds to keep track of their
> internal thing, but I fear it will just end up replacing what the GDP
> (and our www site) does. Its too easy for them to just start adding docs
> there instead of on www because its 'too hard' to deal with guidexml.
> 
> If the issue here is guidexml, lets figure out the problem. We need to
> define what exactly is the problem before we decide on an
> implementation. Is the problem that there's no central place for herds
> to put updates/goals/etc? Is the problem that there's no easy way for
> users to submit new docs for people to use? Is the problem that guidexml
> hampers development time with regard to creating docs and you wish to
> have a better/easier way to create such docs?
> 
> Simply saying 'we need a public wiki' is great an all, but I'd rather
> ask 'What problem(s) does the wiki solve' before we even get farther.
> There might be better ways to solving the problem other than putting up
> a wiki.
> 

I think the big problem with certain pieces of documentation is the fact
that:
A) They change too often for any sort of static webpage.  If I'm writing
portage docs GuideXML is probably not how I want to go, the docs are
essentially fluid for most of the development time, they change often,
entire sections are ripped out and moved as I go.  In that type of case
any sort of static webpage is utterly horrible.  Rather go a wiki route
( or something similar ) to allow easy access & modification.

One could say, build the docs offline and then submit them later for GDP
to stick into GuideXML, but then only I can contribute to them ( myself
not being a developer ).  I guess I could host my own Anon-svn for the
docs while they are being written, but not particularly my cup of tea.

B) Non-developers want to contribute.  The devwiki currently doesn't
allow this, so I ended up asking Patrick at ge.org for an account to
start a wiki there, hoping eventually to move it somewhere else ( or if
events stay as they are, it can stay there )  Not many people want to
make diffs on guideXML ( I know I hate editing it ), and to fix a small
error or add a tidbit, no one wants to file a bug about it.

Those are the two biggest, docs change fast and non-devs want to
contribute to documentation in an easier way.

Problems with any sort of wiki solution thats Gentoo-wide comes down to
people editing projects they know nothing about, and managing
permissions should they be implemented.  I could probably do well
editing the Portage section, but perhaps no so much in any Hardened area
of the wiki.  Problem is maintaining that number of users/permissions is
a nightmare.

But those are the two biggest problems in my estimation.  No one wishes
to impede the GDP here,  Most of the docs I want to write are internal
portage API docs/FAQ/Howto's, and I doubt you will see users pounding on
the door to read them :)

Alec Warner (antarus)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ8GBPWzglR5RwbyYAQINoA//U6CGfhwWcIKWOdr2UmbtarIbPoiFZ7Hc
2TcITLjnEqNFq28Va7cjKsS3Ef4BdoWY4UbhP+YCWPhqCPiFEOG4hEjsxeBQC4/v
7mvaC9EB2kVJRRZtl5WCtWeOzrsxc/ebtgOL1F8TL040AevD5BTYQKngS/9sEdl6
HyfY/i6Jbg5m8oFRCzA2vvzZAVHDPV92qxzKpfdfcAPC6FMHtdzimlASmcjjhAy2
FcUkYazzyy4888eO8tYZqpPX7ps8wUYVKfeLe55+EHpCC2jBp82NE++V2g9B0KcY
9T4yfELm1UXs1C4GDaukpqjrhj+vUSrf1/fK9k1ebmEaW29cEGATjYqCxKEXqQ8R
iCTgvpWDkc9yFRBLjscVW5ZS+jjfST/YlyCuLFNbFKoze1fyj6xqVVwMbnONNklO
X3979tn8bz377ZRNdbURkllc3Rgs0U6hHhowM917s2KULis4XnNhQ01DIomTH3cO
a0BVZo0tCYcNxPLqqlMD2xqTpgRrN7NPOOSTJIWQyWrzctnF2RaeznJSd96zzVPB
XDY/OsmRLulJIrAQcGQHpkYnhlk0Oy1kglWqXlvF8+Zf8O65qoFeSYvy2Ettuh06
jziyI4rDzfdDSgBmDX9jcShLoKIfoIxIGH6HvuphSXTIVqgDEr/63tEcYbXnomMv
qNdS/bUOXAg=
=rMLi
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Diego 'Flameeyes' Pettenò]

On Sunday 08 January 2006 19:07, Renat Lumpau wrote:
> Devwiki
i thought of devwiki when I started writing Gentoo/Alt documentation. I then 
discarded the idea for a series of reason, the first of which is the one 
already stated by Brian, that the docs results unreadable by non-devs, and 
also not all devs have currently access to the wiki, sa they need to register 
and then ask infra for access. The method is for sure unintuitive for devs, 
and unacceptable to leave the documentation up (if some non-dev want to know 
how to fix something because it's currently unmaintained in tree and submits 
a patch, I think it's worth to leave the doc public).

I also don't find GuideXML so bad for documentation, also if developers' eyes 
only. The GDP style is simple enough as XML to allow using of CVS.

The idea of using devwiki for drafts is a bit better, but I tried that, too, 
when I moved the above noted Gentoo/Alt documentation in GuideXML out of the 
devwiki. Chris White helped me with the GuideXMLification, as the syntax is 
different enough to be unpractical to use devwiki for drafting. Also, drafts 
are usually better when they are visibile to as much eyes as possible, so I'd 
rather let them visibile to user too.

There are some ways that might be practical. The first one is the simplest I 
can think of: let general documentation like the "how to fix common problems" 
document to be handled by GDP as developers' documentation when they are 
finished, and work on them in a special "draft" directory inside /proj/en/ 
(with no access restrictions) so that they can be handled by many devs at a 
time. When the document is ready, it's submitted to GDP which will handle the 
future maintenance.

Another way is to provide GuideXML xslt on dev.gentoo.org so that we can put 
guidexml-formatted pages directly on our public_html before submitting to 
GDP.

The third way is somewhat more complex: provide a standanlone branch, aside of 
proj and doc, called "devs", where we can commit guidexml documents that 
aren't strictly referring to a single topic, but rather organized by who's 
working on them, still under CVS so we have history. There the drafts can be 
worked on, and then again passed to GDP when they're final.

I tried ordering the three ideas by order of flexibility and easyness for 
infra to enact them, and they are only what I came up after an afternoon 
spent thinking on it. There might be practical issues with all of them.

I don't like the idea of a wiki not for the public thing (I think it would 
still be limited in write access to devs), because not only it would be yet 
another tool to learn usage of, but it would be "off style" with the rest of 
the site.
Also, limiting it to devs to write it would lose the main feature of a wiki, 
so it would be like wasting the load that it would add...
I still like the idea of continuing using GuideXML, after have learned to use 
it it's really practical to me at least.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgp1kss5nhzpm.pgp
Description: PGP signature

Re: [gentoo-dev] Projects and simple guides

[Luis Medinas]

On Sun, 2006-01-08 at 13:31 -0600, Lance Albertson wrote:
> > Indeed it's GDP area but to expose project goals, status and low level
> > docs isn't even related with GDP. We can't maintain the high level of
> > docs like GDP does and it's not even your goal. I think the public wiki
> > idea will improve the communication between devs and users, add goals
> > and show the status of projects. IMO GDP can't do much in this area
> > simply because they don't have much to do about this and they have of
> > course high level of docs to maintain.
> 
> I had thought about creating some kind of a site like this, but not
> necessarily in a wiki form. I don't like the idea of letting users add
> random docs. There's too much room for error and how do you deal with
> accountability? There has to be a developer who either will take the
> time to maintain it or accept responsibility for any errors it may have.
> I like the idea of having an area for herds to keep track of their
> internal thing, but I fear it will just end up replacing what the GDP
> (and our www site) does. Its too easy for them to just start adding docs
> there instead of on www because its 'too hard' to deal with guidexml.
> 
Like i said GDP maintain High Level Docs i think no one want's to
replace that. Herds docs will not replace GDP. Even if that's for
somehow happen it could be easy backported to GDP maintaining an High
Level doc. A few months back Diego "Flameeyes" started writing
maintainer docs for some applications, X team started their own docs
about modular X, amd64 team does have their docs and it doesn't have
anything to do with GDP or will replace them. An example for this is the
AMD64 FAQ that is part of GDP and all writen by AMD64 team.
> If the issue here is guidexml, lets figure out the problem. We need to
> define what exactly is the problem before we decide on an
> implementation. Is the problem that there's no central place for herds
> to put updates/goals/etc? Is the problem that there's no easy way for
> users to submit new docs for people to use? Is the problem that guidexml
> hampers development time with regard to creating docs and you wish to
> have a better/easier way to create such docs?
> 
Indeed guidexml isn't a fast method to write information but we should
keep it for high level docs of course.
> Simply saying 'we need a public wiki' is great an all, but I'd rather
> ask 'What problem(s) does the wiki solve' before we even get farther.
> There might be better ways to solving the problem other than putting up
> a wiki.
> 
I think the wiki will have users cooperate directly into herds, herds
can expose all types of information there (like status and future goals)
and it could be useful for feature requests, ideas, interaction between
everyone and it's a simple method for doing all this stuff.
-- 
Luis Medinas <[EMAIL PROTECTED]>
http://dev.gentoo.org/~metalgod
Gentoo Linux Developer: AMD64,Printing,Media-Optical,Sound

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Lance Albertson]

Luis Medinas wrote:
> On Sun, 2006-01-08 at 12:54 -0600, Lance Albertson wrote:
> 
Devwiki is effectively inaccesable to non gentoo folks (whether in 
access, or in navigating the beast), thus it's a no go.

Any docs generated should be googable imo.
>>>
>>>
>>>We could start a public wiki displaying all herds and projects. It would
>>>be great to add some low level docs, herds/project goals, ideas and so.
>>>Even the users could be allowed to edit and share information.
>>
>>Anything like that will need to be approved by the GDP and a GLEP.
>>Creating any sort of public wiki will basically halt the efforts of the
>>GDP which I'd rather not do. Not to mention deciding who would be
>>monitoring it and such (allocating people's time to it). I'm opposed to
>>any public wiki until the GDP states their opinion on it. Its their area
>>and I don't want to take it away from them.
>>
> 
> Indeed it's GDP area but to expose project goals, status and low level
> docs isn't even related with GDP. We can't maintain the high level of
> docs like GDP does and it's not even your goal. I think the public wiki
> idea will improve the communication between devs and users, add goals
> and show the status of projects. IMO GDP can't do much in this area
> simply because they don't have much to do about this and they have of
> course high level of docs to maintain.

I had thought about creating some kind of a site like this, but not
necessarily in a wiki form. I don't like the idea of letting users add
random docs. There's too much room for error and how do you deal with
accountability? There has to be a developer who either will take the
time to maintain it or accept responsibility for any errors it may have.
I like the idea of having an area for herds to keep track of their
internal thing, but I fear it will just end up replacing what the GDP
(and our www site) does. Its too easy for them to just start adding docs
there instead of on www because its 'too hard' to deal with guidexml.

If the issue here is guidexml, lets figure out the problem. We need to
define what exactly is the problem before we decide on an
implementation. Is the problem that there's no central place for herds
to put updates/goals/etc? Is the problem that there's no easy way for
users to submit new docs for people to use? Is the problem that guidexml
hampers development time with regard to creating docs and you wish to
have a better/easier way to create such docs?

Simply saying 'we need a public wiki' is great an all, but I'd rather
ask 'What problem(s) does the wiki solve' before we even get farther.
There might be better ways to solving the problem other than putting up
a wiki.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Projects and simple guides

[Luis Medinas]

On Sun, 2006-01-08 at 12:54 -0600, Lance Albertson wrote:
> >>Devwiki is effectively inaccesable to non gentoo folks (whether in 
> >>access, or in navigating the beast), thus it's a no go.
> >>
> >>Any docs generated should be googable imo.
> > 
> > 
> > We could start a public wiki displaying all herds and projects. It would
> > be great to add some low level docs, herds/project goals, ideas and so.
> > Even the users could be allowed to edit and share information.
> 
> Anything like that will need to be approved by the GDP and a GLEP.
> Creating any sort of public wiki will basically halt the efforts of the
> GDP which I'd rather not do. Not to mention deciding who would be
> monitoring it and such (allocating people's time to it). I'm opposed to
> any public wiki until the GDP states their opinion on it. Its their area
> and I don't want to take it away from them.
> 
Indeed it's GDP area but to expose project goals, status and low level
docs isn't even related with GDP. We can't maintain the high level of
docs like GDP does and it's not even your goal. I think the public wiki
idea will improve the communication between devs and users, add goals
and show the status of projects. IMO GDP can't do much in this area
simply because they don't have much to do about this and they have of
course high level of docs to maintain.
-- 
Luis Medinas <[EMAIL PROTECTED]>
http://dev.gentoo.org/~metalgod
Gentoo Linux Developer: AMD64,Printing,Media-Optical,Sound

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Lance Albertson]

Luis Medinas wrote:
> On Sun, 2006-01-08 at 10:31 -0800, Brian Harring wrote:
> 
>>On Sun, Jan 08, 2006 at 06:07:48PM +, Renat Lumpau wrote:
>>
>>>On Sun, Jan 08, 2006 at 06:59:40PM +0100, Diego 'Flameeyes' Petten? wrote:
>>>
GDP might be the place where to put them, but as they are mainly 
developer-oriented, they might be better accessed directly by devs (at 
least 
for the first steps until they are drafts).

What people think about this?
>>>
>>>Devwiki
>>
>>Devwiki is effectively inaccesable to non gentoo folks (whether in 
>>access, or in navigating the beast), thus it's a no go.
>>
>>Any docs generated should be googable imo.
> 
> 
> We could start a public wiki displaying all herds and projects. It would
> be great to add some low level docs, herds/project goals, ideas and so.
> Even the users could be allowed to edit and share information.

Anything like that will need to be approved by the GDP and a GLEP.
Creating any sort of public wiki will basically halt the efforts of the
GDP which I'd rather not do. Not to mention deciding who would be
monitoring it and such (allocating people's time to it). I'm opposed to
any public wiki until the GDP states their opinion on it. Its their area
and I don't want to take it away from them.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Projects and simple guides

[Lance Albertson]

Brian Harring wrote:
> On Sun, Jan 08, 2006 at 06:07:48PM +, Renat Lumpau wrote:
> 
>>On Sun, Jan 08, 2006 at 06:59:40PM +0100, Diego 'Flameeyes' Petten? wrote:
>>
>>>GDP might be the place where to put them, but as they are mainly 
>>>developer-oriented, they might be better accessed directly by devs (at least 
>>>for the first steps until they are drafts).
>>>
>>>What people think about this?
>>
>>Devwiki
> 
> Devwiki is effectively inaccesable to non gentoo folks (whether in 
> access, or in navigating the beast), thus it's a no go.
> 
> Any docs generated should be googable imo.

If they are needing an initial place to start things off before they go
official, then the devwiki is a perfect place. Once they are ready to be
consumed by the other folks, they should be placed on www.g.o somewhere.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Projects and simple guides

[Luis Medinas]

On Sun, 2006-01-08 at 10:31 -0800, Brian Harring wrote:
> On Sun, Jan 08, 2006 at 06:07:48PM +, Renat Lumpau wrote:
> > On Sun, Jan 08, 2006 at 06:59:40PM +0100, Diego 'Flameeyes' Petten? wrote:
> > > GDP might be the place where to put them, but as they are mainly 
> > > developer-oriented, they might be better accessed directly by devs (at 
> > > least 
> > > for the first steps until they are drafts).
> > > 
> > > What people think about this?
> > 
> > Devwiki
> Devwiki is effectively inaccesable to non gentoo folks (whether in 
> access, or in navigating the beast), thus it's a no go.
> 
> Any docs generated should be googable imo.

We could start a public wiki displaying all herds and projects. It would
be great to add some low level docs, herds/project goals, ideas and so.
Even the users could be allowed to edit and share information.

-- 
Luis Medinas <[EMAIL PROTECTED]>
http://dev.gentoo.org/~metalgod
Gentoo Linux Developer: AMD64,Printing,Media-Optical,Sound

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Brian Harring]

On Sun, Jan 08, 2006 at 06:07:48PM +, Renat Lumpau wrote:
> On Sun, Jan 08, 2006 at 06:59:40PM +0100, Diego 'Flameeyes' Petten? wrote:
> > GDP might be the place where to put them, but as they are mainly 
> > developer-oriented, they might be better accessed directly by devs (at 
> > least 
> > for the first steps until they are drafts).
> > 
> > What people think about this?
> 
> Devwiki
Devwiki is effectively inaccesable to non gentoo folks (whether in 
access, or in navigating the beast), thus it's a no go.

Any docs generated should be googable imo.

~harring


pgpk95w9iqaLY.pgp
Description: PGP signature

[gentoo-dev] Meeting summary: Web-Apps Herd, January 2006

[Stuart Herbert]

Hi,

The minutes of the Web-Apps Herd's January meeting are now available
[1], including a full log if anyone needs it.

It was a busy meeting, with 12 separate agenda items delt with.  We
elected project leads, agreed who would deal with a number of
problematic ebuilds, and started looking at establishing new virtual
packages for web servers, amongst other things.

The next meeting will be on Sunday 5th Febrary at 18:00 UTC in
#gentoo-web.  All are welcome.  If anyone has a topic they'd like to see
on the agenda [2], please let a member of the herd know before the
meeting.

[1] http://tinyurl.com/b2xpd 
[2] http://tinyurl.com/ba7j4 

-- 
Stuart Herbert [EMAIL PROTECTED]
Gentoo Developer  http://www.gentoo.org/
  http://blog.stuartherbert.com/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Projects and simple guides

[Renat Lumpau]

On Sun, Jan 08, 2006 at 06:59:40PM +0100, Diego 'Flameeyes' Petten? wrote:
> GDP might be the place where to put them, but as they are mainly 
> developer-oriented, they might be better accessed directly by devs (at least 
> for the first steps until they are drafts).
> 
> What people think about this?

Devwiki

-- 
Renat Lumpau
all things web-apps
GPG key id #C6A838DA on http://pgp.mit.edu
Key fingerprint = 04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA


pgpwbY2PT4lBn.pgp
Description: PGP signature

[gentoo-dev] Projects and simple guides

[Diego 'Flameeyes' Pettenò]

Okay let's forget the flames and talk about something related to practical 
development today :)

As people reading my blog might already know, I've been experimenting with 
--as-needed LDFLAG in the past days. It seems pretty stable when you don't 
have GNOME installed (as many libraries from GNOME project don't like it), 
but it's usually also fixable when they fail.

Now, I wanted to try writing something up about that with a quick guide to fix 
the most common cases when --as-needed fails.

While --as-needed should remain unsupported (now and robably in the future), 
it might be helpful to have this sort of informations lying around for who 
wants to know how to fix the problems.

I originally thought of putting it on my devspace, but using GuideXML there is 
a bit tricky, at least for me (as xsltproc seems to refuse working on the 
pure xml directly).

So I was thinking if we had a way to put some "how to fix" guides somewhere, 
on the lines of the ones written by soalr and vapier for hardened. A part the 
--as-needed thing, it might also be useful to put something about "how to 
solve parallel make issues" and similar things that are tricky but usually 
just requires little knowledge of tricks.

GDP might be the place where to put them, but as they are mainly 
developer-oriented, they might be better accessed directly by devs (at least 
for the first steps until they are drafts).

What people think about this?

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpa0iC3APXTS.pgp
Description: PGP signature

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Lance Albertson]

Brian Harring wrote:
> On Sun, Jan 08, 2006 at 10:55:50AM -0600, Lance Albertson wrote:
> 
>>A few rough ideas that just popped in my
>>head is either packing all of these versions into one tarball (not even
>>sure if thats feasible)



>>, or creating a hashed suffix based upon the
>>useflags enabled/disabled at the time that you append to the tarball name.
> 
> +1 on mangling the name.  Need something for keywords anyways.
> 
> Alternative is expanding the bintree format, cat/pkg-ver being a 
> directory, with the binpkgs held with in...
> 
> Either way, bintree/binpkg format are all rolled into one mess, as 
> stated, open to proposals to make it less sucky.

Is there an alternative format outside of bzip2tarballs that might fit
this better? Ignoring backward compatibility, is there anything?

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Brian Harring]

On Sun, Jan 08, 2006 at 10:55:50AM -0600, Lance Albertson wrote:
> A few rough ideas that just popped in my
> head is either packing all of these versions into one tarball (not even
> sure if thats feasible)

Ugly, binpkgs are bzip2ed tarballs + xpak at the end of the bzip2 
stream, jamming multiple contents sets in would lose the ability to 
just untar the bugger to the fs in worst case.

Plus... it's nasty from a format standard, trying to determine which 
contents set to pull.  Basically have to jump to eof, read the footer, 
either store _all_ offsets there (extension of xpak format), or jump 
from there to the previous xpak, repeat till you've found what you 
want.

> , or creating a hashed suffix based upon the
> useflags enabled/disabled at the time that you append to the tarball name.
+1 on mangling the name.  Need something for keywords anyways.

Alternative is expanding the bintree format, cat/pkg-ver being a 
directory, with the binpkgs held with in...

Either way, bintree/binpkg format are all rolled into one mess, as 
stated, open to proposals to make it less sucky.

~harring


pgpImi4Qu9x9S.pgp
Description: PGP signature

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Lance Albertson]

Chris Gianelloni wrote:
> On Fri, 2006-01-06 at 17:32 -0600, Lance Albertson wrote:
> 
>>
>>
>>I think a key thing that is missing is build info that is only kept on
>>the installed system. If we were to ever create a build server setup, we
>>need to be able to have multiple binpkg's of the same version depending
>>on differences between sub-arch, use flags, cflag differences, gcc
>>version differences, etc. The key one i'm after is use flags. I'm not
>>sure of the technical details behind it, but we need something to make
>>the binpkgs more useful outside of the local system. Having the ebuild
>>packed at the end is a great idea! I think its just time to extend the
>>format to include more and possibly add things for build servers.
> 
> 
> USE flags are stored in the package.  The main thing is that portage
> doesn't consider them, at all, unless you use --newuse, in which case if
> the USE flags do not match, it will not use the package and will compile
> from source.  We use this every day in Release Engineering with
> catalyst.

That maybe true, but if you're going to use such things on a build
server, you need to be able to have multiple tars of the same package
for the different use flags you may use. Maybe for one server setup I
need useflag foo, but another setup I don't need it. This central
repository needs to differentiate between those two needs. I know you
could make two separate binpkg dirs for those cases, but thats not
scalable at all. I was looking for something more generic.

To summarize, differentiating use flags in gentoo binary packages isn't
very scalable at the moment. A few rough ideas that just popped in my
head is either packing all of these versions into one tarball (not even
sure if thats feasible), or creating a hashed suffix based upon the
useflags enabled/disabled at the time that you append to the tarball name.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Re: GLEP 42 (news) Round Seven

[Jan Kundrát]

Brian Harring wrote:
> It's not an issue.

Okay, if it will just somehow show up when using the --ask option, I'll
be happy :).

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] GLEP 20 /srv - Services Home Directory Support

[Kalin KOZHUHAROV]

Luca Barbato wrote:
> I'm thinking about adding the srvdir[1] global useflag.
> 
> Scream if I miss some discussion preventing it.
> 
> (fenice[2] will use it, that's why I'm adding it)
> 
> lu
> 
> [1] http://www.gentoo.org/proj/en/glep/glep-0020.html#implementation
> [2] http://packages.gentoo.org/search/?sstring=fenice
> 

Hi all,
not a dev, but please bear with me :-)


>From [1] above:

GLEP:   20
Title:  /srv - Services Home Directory Support
Version:1.2
Last-Modified:  2004/11/11 21:35:53
Author: Stuart Herbert , Rob Holland 
Status: Approved
Type:   Standards Track
Content-Type:   text/x-rst
Created:09-Feb-2004
Post-History:   21-Feb-2004, 11-Nov-2004

It is 2006, any updates on this GELP?

Just a quick look turned out a 404 error on the FHS2.3 link. ( 
http://www.pathname.com/fhs/ ?)

I am not very read in LSB, but just saw there is a 3.x version...
What about LSB 3.x? Is it the same recomendation?

Although I run quite a bunch of services on a few boxes, I don't see this whole 
idea (/srv).
I read the GLEP, I read [FHS#srv] but still. And it says:
"The methodology used to name subdirectories of /srv is unspecified
 as there is currently no consensus on how this should be done."

So how does Gentoo implement it?

[FHS#svg]   
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM

And as the GLEP talks about webapps, what will an upgrade of a webapp (say 
Bugzilla) to/from srv?
I feel it breaking and user screaming.


And a few general comments:

Hmm, the GLEP index page [a] shows GLEP 20 with status "SA" which according to 
the legend is
"Standards Track + Accepted". The [1] above has status "Approved" which might 
be the same, but why
is not there consistency in terms?

If it is approved/accepted doesn't it mean it is implemented by somebody?

[a] http://www.gentoo.org/proj/en/glep/

Kalin.

-- 
|[ ~~ ]|
+-> http://ThinRope.net/ <-+
|[ __ ]|
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Carsten Lohrke]

On Sunday 08 January 2006 15:01, Brian Harring wrote:
> Guessing you missed the previous flame war about how trying to force
> people to do something doesn't actually work?

When it's not common sense, that every dev is supposed to do a minimal on 
general QA, Gentoo has a problem.

> You're assuming seasoned devs don't occasionally go MIA on
> QA/maintenance?  It's not the case...

I did not assume anything, I propose better QA.

> > but would slowdown those who continually add new
> > packages [ snip vitriolic opinions ]

Thanks for calling something a vitriolic opinion, I did notice a few times, so 
it's a description of what's happening, but does not imply the majority of 
devs do so.

> If you've got an issue with certain devs (seems to be the case from
> your statement), take it up with QA/ombudsman, not the loop
> around attempt you're doing here.
>
> If you're after trying to decrease the unmaintained packages, like I
> said, generate a list _from the tree_, compare it to bugs, etc.  Do
> the legwork, kick off the effort to cover the gap.
>
> Basically, you want to decrease bugs for unmaintained, decrease the
> gap of maintained vs unmaintained, work on _that_ rather then trying
> to force everyone to drop what they're doing and fix an issue they're
> already working on at their own pace.
>
> Folks *are* handling retirement of unmaintained packages, and taking
> on maintainance of packages already- just watch -dev for the
> occasional announcements if you think otherwise.

To answer this paragraph in a short sentence: No, it doesn't work at the 
moment, and yes I'd like everyone would be urged to care a bit more, not 
leaving the legwork to a single person or small group, accepting that devs 
can feel as irresponsible as they like.


Carsten


pgpnK5iAULCHw.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo "Stable" Portage/Releases

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Muraco wrote:
| Another thing that I don't like, is the feel of this method does seem
| "offical" enough.. mostly because portage is not 'stable'-aware, Its
| just using a stripped down tree.

What do you want then? If an entire standalone tree distributed by
Gentoo doesn't feel official enough, what will?

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDwSWAXVaO67S1rtsRAo7rAJ9YAf+Z3UUsshKfURP71lKqL5PjLwCdGcem
czZJv0hCE0XbT9pjjZOtaiY=
=GdT8
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Chris Gianelloni]

On Sun, 2006-01-08 at 14:40 +0100, Carsten Lohrke wrote:
> > If you feel so strongly about this, why not setup a "cleaning crew"
> > project that goes around doing exactly this?
> 
> Don't you think that it is pretty much barefaced to let a small group do the 
> dirty, boring and annoying work, while those who don't care a bit can 
> continue to do so?!

Not really...  We already have a QA project.  Join it.  If certain
developers are constantly breaking QA, inform them.  If they continue to
do it after being warned, go to devrel.  While the QA team can go and
clean up some things, it should only really do so *once* and inform the
developer.  Otherwise, the developer might not honestly know that he is
doing something incorrectly, or that anyone is even paying attention.
Doing this allows for a cleanup of the tree, without putting
restrictions arbitrarily on the entire developer pool.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Paweł Madej]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Carsten Lohrke wrote:
> On Sunday 08 January 2006 01:35, Stuart Herbert wrote:
> 
> 
> 
> As Donnie already pointed out, I did not mean version bumps, but only new 
> packages. How about this idea: Everyone who adds a new package, has to check 
> and fix an unmaintained package before. This should be a non-issue for 
> seasoned developers, but would slowdown those, who continually add new 
> packages without caring for what they should maintain as well as those who 
> become new devs, add a bunch of packages and hide again, leaving the 
> maintenance to others. This would also have the benefit of continuous QA of 
> unmaintained stuff.
> 

In my opinion such prohibition will kill gentoo portage as there were no
new apps and dev's will be sitting with old toys like in a closed room
without windows and doors. If some package is unmaintained it's surely
because users and devs forgotten it, upstream is dead and noone cares if
its actual or not.


- --
Paweł Madej aka Nysander
http://quanteam.info  | http://forum-farmaceutyczne.org
http://nysander.quanteam.info | http://wiki.quanteam.info
GPG key: 5861680B | keyserver: http://pgp.mit.edu
key fingerprint: 34A9 B8BB DFA2 4F0B EFB5  CE50 82F4 8C82 5861 680B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDwR87gvSMglhhaAsRAleVAKCr7yxxDUUMExfL+r5QGoC5cIaD7gCglvp1
tAjLoNf2k9WqB+D1fSnz7VQ=
=1F6t
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

On Fri, 2006-01-06 at 17:32 -0600, Lance Albertson wrote:
> 
> 
> I think a key thing that is missing is build info that is only kept on
> the installed system. If we were to ever create a build server setup, we
> need to be able to have multiple binpkg's of the same version depending
> on differences between sub-arch, use flags, cflag differences, gcc
> version differences, etc. The key one i'm after is use flags. I'm not
> sure of the technical details behind it, but we need something to make
> the binpkgs more useful outside of the local system. Having the ebuild
> packed at the end is a great idea! I think its just time to extend the
> format to include more and possibly add things for build servers.

USE flags are stored in the package.  The main thing is that portage
doesn't consider them, at all, unless you use --newuse, in which case if
the USE flags do not match, it will not use the package and will compile
from source.  We use this every day in Release Engineering with
catalyst.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

On Fri, 2006-01-06 at 18:11 -0500, Olivier Crete wrote:
> On Fri, 2006-06-01 at 09:39 -0800, Brian Harring wrote:
> > On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote:
> > > On Fri, 2006-01-06 at 09:00 +, Chris Bainbridge wrote:
> > > > On 06/01/06, Brian Harring <[EMAIL PROTECTED]> wrote:
> > > > 1)  Manpower. There are already 10,000 open bugs in bugzilla (and
> > > > growing) without adding more.
> > > 
> > > This is probably the primary reason it died.  This, of course, ties in
> > > greatly to #2.
> > 
> > Automation can reduce workload, within limits.  Fex, scripting for 
> > yanking packages/deptree out of normal tree for merging into a g19 
> > tree.
> 
> Baz has developed a script that would yank a subtree with the proper
> deps for the original GLEP 19 effort. It wasn't that hard to do.

No, but it (at least from the last message that I saw) did not update
Manifests/digests.

> And the idea of having a subtree is that the backports would be done by
> a specific group of developers instead of the package maintainers and
> therefore not getting any more work on the other devs.

This would still be the case.  However, having a subtree such as the one
that was used by GLEP19 severely reduces the usability.  For one, the
number of USE flags was reduced to only "server" USE flags, and even
then it only included the "common" ones and omitted all of the others,
making it even less useful and impossible for supporting an "Enterprise
Workstation" from the same tree.

> I'm not really sure why the older one died... We were pretty close to
> being able to build the stages and starting to distribute it... I would
> be very favorable to seeing the whole thing restarted.

I'm pretty sure it died due to lack of involvement.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Brian Harring]

On Sun, Jan 08, 2006 at 02:40:47PM +0100, Carsten Lohrke wrote:
> On Sunday 08 January 2006 01:35, Stuart Herbert wrote:
> > I agree that some cleaning is needed (and some of my packages are
> > desperate for it!), but I'm totally opposed to this idea.  I think the
> > idea of shutting up shop for three months (presumably with a "closed
> > for refurbishment" sign on the door) would let down our users who rely
> > on us for regular package updates, and would be a massive PR disaster.
> >  Cleaning is something that has to happen all the time; it needs to be
> > a natural and sustainable part of what we do every day.
> 
> As Donnie already pointed out, I did not mean version bumps, but only new 
> packages. 

> How about this idea: Everyone who adds a new package, has to check 
> and fix an unmaintained package before.

Guessing you missed the previous flame war about how trying to force 
people to do something doesn't actually work?


> This should be a non-issue for 
> seasoned developers, 

You're assuming seasoned devs don't occasionally go MIA on 
QA/maintenance?  It's not the case...


> but would slowdown those who continually add new 
> packages [ snip vitriolic opinions ]

If you've got an issue with devs adding stuff and abandoning/not 
supporting their stuff, hey that's fine, bitch at QA.

Don't go freezing the whole tree just because you're after slapping at 
a couple of devs over perceived wrongs.


> Don't you think that it is pretty much barefaced to let a small group do the 
> dirty, boring and annoying work, while those who don't care a bit can 
> continue to do so?!

If you've got an issue with certain devs (seems to be the case from 
your statement), take it up with QA/ombudsman, not the loop 
around attempt you're doing here.

If you're after trying to decrease the unmaintained packages, like I 
said, generate a list _from the tree_, compare it to bugs, etc.  Do 
the legwork, kick off the effort to cover the gap.

Basically, you want to decrease bugs for unmaintained, decrease the 
gap of maintained vs unmaintained, work on _that_ rather then trying 
to force everyone to drop what they're doing and fix an issue they're 
already working on at their own pace.

Folks *are* handling retirement of unmaintained packages, and taking 
on maintainance of packages already- just watch -dev for the 
occasional announcements if you think otherwise.

~harring


pgpDAMqm725Du.pgp
Description: PGP signature

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Carsten Lohrke]

On Sunday 08 January 2006 01:35, Stuart Herbert wrote:
> I agree that some cleaning is needed (and some of my packages are
> desperate for it!), but I'm totally opposed to this idea.  I think the
> idea of shutting up shop for three months (presumably with a "closed
> for refurbishment" sign on the door) would let down our users who rely
> on us for regular package updates, and would be a massive PR disaster.
>  Cleaning is something that has to happen all the time; it needs to be
> a natural and sustainable part of what we do every day.

As Donnie already pointed out, I did not mean version bumps, but only new 
packages. How about this idea: Everyone who adds a new package, has to check 
and fix an unmaintained package before. This should be a non-issue for 
seasoned developers, but would slowdown those, who continually add new 
packages without caring for what they should maintain as well as those who 
become new devs, add a bunch of packages and hide again, leaving the 
maintenance to others. This would also have the benefit of continuous QA of 
unmaintained stuff.

Regarding PR: The quality of parts of the tree is more than enough bad PR.

> If you feel so strongly about this, why not setup a "cleaning crew"
> project that goes around doing exactly this?

Don't you think that it is pretty much barefaced to let a small group do the 
dirty, boring and annoying work, while those who don't care a bit can 
continue to do so?!


Carsten


pgp5SDO90yfHE.pgp
Description: PGP signature

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Carsten Lohrke]

On Sunday 08 January 2006 01:38, Brian Harring wrote:
> Asking people to focus on cleaning the tree?  Sure.  Generate a list
> of candidates would help.  Blocking new packages?  No...

I can't say I did not expect negative replies and "generating a list of 
candidates" is at least a suggestion. But a very weak one if you think about 
it; It would presume that most devs are too dumb to use bugzilla or to grep 
the tree.


Carsten


pgpSXFvfSUmGI.pgp
Description: PGP signature

Re: [gentoo-dev] net-proxy/squid should be demoted to ~mips

[Carsten Lohrke]

You don't have to care, Alin. Mips is not among the security-wise supported¹ 
architectures.

Then only problem I see in general is, that every single subproject defines 
what is supported and the information is scattered on the different 
gentoo.org documentation pages (release, security, kernel,...). This is 
anything else but user friendly and can e.g. result in official releases for 
not security-wise supported architectures.


Carsten


[1] http://www.gentoo.org/security/en/vulnerability-policy.xml


pgp7IxEKtHFEF.pgp
Description: PGP signature

Re: [gentoo-dev] Split ebuilds for GCC

[Kumba]

Dirk Heinrichs wrote:

Hi,

there has been a lengthy discussion on bugzilla ([1]), about the best 
packaging method for the gnat Ada compiler. The outcome seems to be that 
gnat will still have its own ebuild in the future and not be part of the 
GCC ebuild. It also has a mention that gcj will eventually be split out 
from the GCC ebuild in the future.


So my question is: Would it be a good idea to generally turn GCC into split 
ebuilds (like KDE/X.org)? Pros/Cons?


The only case where we actually split anything is for the few C-only kernel 
compiler packages, gcc-mips64, gcc-sparc64, gcc-powerpc64, etc..  These disable 
everything else but C, as this compiler is explicitly only for kernel building.


Anything else...good luck.  Aim for manipulating USE flags properly, though, to 
disable features of gcc you don't want or need.  This works better than 
splitting everything.



--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Catalyst{,2} and 2006.0

[Kumba]

Kalin KOZHUHAROV wrote:

Yes, thes examples are quite good, however as I said before, real (=working) 
examples weere needed.
(note to /me => `emerge -s livecd && emerge -a livecd-specs livecd-kconfigs`)


Working specs can be found in our ViewCVS in gentoo/src/releng/specs.  Therein 
are contained the specs used to build prior releases for most archs.



--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Developer: Tobias Matzat (SirSeoman)

[Tobias Scherbaum]

On Fri, 2006-01-06 at 23:55 +0100, Wernfried Haas wrote:
> On Fri, Jan 06, 2006 at 11:25:57PM +0100, Tobias Scherbaum wrote:
> > Yo, Welcome Tobias!
> 
> Oh no, not another Tobias!

Isn't it a beautiful name? :P

  Tobias


signature.asc
Description: This is a digitally signed message part