Re: [gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC

2005-09-16 Thread Diego 'Flameeyes' Pettenò
On Friday 16 September 2005 01:56, Nathan L. Adams wrote:
 I'm writing a tool, called esyntaxer, that finds certain common ebuild
 errors and automagically corrects them if possible. Yes, I'm aware of
 the overlaps with repoman, and no this isn't a duplication of work.
Actually, I already have prepared a ruby script that I use to find violators 
to the syntax (like enewuser with /bin/false and cp called with extra 
options). It's on http://dev.gentoo.org/~flameeyes/ruby-checker.tbz2 .
It's not complete, but it works when it comes to checking for these simple 
cases.

I don't trust automatic correction, false positives can always happen, 
currently my way to proceed with such problems is opening a big bug and 
poking maintainers to fix them :)

-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpHbARht5xPg.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC

2005-09-16 Thread Diego 'Flameeyes' Pettenò
On Friday 16 September 2005 01:30, Kito wrote:
 Items on the Agenda so far:
I would add that (that I forgot last night but is one of the main concerns):

* ${ARCH} usage, keywords and variables assignments.

 Flame-on.
This was my part :P

-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpc6xEqMyGDT.pgp
Description: PGP signature


Re: [gentoo-dev] Clarification of packages cd's for 2005.1

2005-09-16 Thread Chris Gianelloni
On Fri, 2005-09-16 at 14:51 +1200, Nick Rout wrote:
 According to the release announcement the package cd's don't seem to
 have an athlon version any more. 
 http://www.gentoo.org/news/20050808-annoncement-release-2005.1.xml
 (the choices seem to be alpha amd64 ppc (32 bit) ppc (64 bit) sparc64
 x86).

Only the base arches get distributed on the mirrors due to space
constraints.

 However on http://tracker.netdomination.org/ there are package cd's for
 a whole lot of other sub-arches -  i686, athlon-xp, P3, P4 and more. Are 
 these official gentoo - if not can anyone tell me about their origin and 
 reliability?

They were built by the Release Engineering team using the exact same
specifications as the rest of the media.  Currently, these are only
available from the Friends of Gentoo e.V. tracker.  We hope to have them
available from the store shortly.  Unfortunately, we just don't have the
resources on our community mirrors for hosting them.

 Also is athlon-xp compatible with athlon? Or should I go for i686?

No.  You need i686.  Athlon XP added SSE instructions to the Athlon.

 Actually using i686 could be a bonus as it would mean I could share
 binaries between my desktop and my p3 laptop, which is compiled for 686.

Sounds like a plan.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


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


[gentoo-dev] [RFC] Portability eclass

2005-09-16 Thread Diego 'Flameeyes' Pettenò
If nobody finds problem in the attached eclass, I'm going to commit this 
tonight or tomorrow.
The first function is a drop-in replacement for cp --parent (that doesn't work 
on BSD userland), the second one is a commodity function to symlink commands 
and manpages at once (as done by bsdtar and other packages).

If we'll find other functions needed for portability's sake, they'll probably 
going to be there, too.

Comments?
-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Author: Diego Pettenò [EMAIL PROTECTED]
#
# This eclass is created to avoid using non-portable GNUisms inside ebuilds
#
# NB:  If you add anything, please comment it!

# treecopy orig1 orig2 orig3  dest
#
# mimic cp --parents copy, but working on BSD userland as well
treecopy() {
dest=$(eval echo \${$#})
files_count=$#

for (( i=1; ${i}  ${files_count}; i=$((${i}+1)) )); do
dirstruct=$(dirname $1)
mkdir -p ${dest}/${dirstruct}
cp -pPR $1 ${dest}/${dirstruct}

shift
done
}

# symcmd oldcmd newcmd [mansection]
#
# Symlinks a given command to a new one, useful to shade a package that is
# the default provider of a command in a given userland.
# When mansection is specified, also the manpage with basename(oldcmd) is
# symlinked to basename(newcmd).
symcmd() {
dosym ${newcmd} ${oldcmd} || die symlink failed

if [[ -n $3 ]]; then
dosym ${oldcmd}.$3.gz /usr/share/man/man$3/${newcmd}.$3.gz
fi
}


pgp4iTKElrDby.pgp
Description: PGP signature


[gentoo-dev] Change md5 checksum in ebuils by sha-256, AES or others

2005-09-16 Thread Camilo Aguilar
Hello, i was reading in some pages that md5 is no longer secure anymore
to continue proving the integrity of the programs.

Is it possible to change md5 check in the ebuilds for another more
secure algorithm ?

links:
http://www.codeproject.com/useritems/HackingMd5.asp
http://www.eweek.com/article2/0,1759,1859751,00.asp

Cordialmente, 

Camilo Aguilar 
Director de Proyectos

Cel: +57 3007048038
Off: +574 3136345
   +574 3134870



La simplicidad es la máxima sofisticación --- Leonardo Da Vinci

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Change md5 checksum in ebuils by sha-256, AES or others

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 11:47 am, Camilo Aguilar wrote:
 Is it possible to change md5 check in the ebuilds for another more
 secure algorithm ?

search bugzilla please before asking about feature enhancments

this has been covered in bugzilla (among other places) a couple of times
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] Portability eclass

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 11:42 am, Diego 'Flameeyes' Pettenò wrote:
 the second one is a commodity function to symlink
 commands and manpages at once (as done by bsdtar and other packages).

i dont see this being really useful ... either way, assuming the manpage is 
compressed with gzip (or compressed at all) is wrong
-mike

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] Portability eclass

2005-09-16 Thread Martin Schlemmer
On Fri, 2005-09-16 at 17:42 +0200, Diego 'Flameeyes' Pettenò wrote:
 If nobody finds problem in the attached eclass, I'm going to commit this 
 tonight or tomorrow.
 The first function is a drop-in replacement for cp --parent (that doesn't 
 work 
 on BSD userland), the second one is a commodity function to symlink commands 
 and manpages at once (as done by bsdtar and other packages).
 
 If we'll find other functions needed for portability's sake, they'll probably 
 going to be there, too.
 

I do not think its so urgent?  Either way, we have elibs approved now,
so how about waiting a while so that we do not have yet another elib
candidate to port?

Also, treecopy() will break if I do:

treecopy ${S}/data ${D}/usr/share/foodata


-- 
Martin Schlemmer



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


[gentoo-dev] Re: Gentoo alt-projects meeting 9/26 1900 UTC

2005-09-16 Thread Kito
Thanks for the feedback kids. Anyone who has any items they want  
added, speak up!


Revised agenda list:

  * Rollcall/Active members

  * Elections/Nominations for project lead?

  * Sub-project organization

  * Project page content (tech notes, tasks data, etc)

  * Alt-project roadmap

  * Portage rewrite - alternate prefix installs(!), moving/adding  
platform dependent code to loadable modules


  * ${ARCH} usage, keywords and variables assignments

  * Naming and categorization of alt-arch system packages

  * Merging patches in the main tree

  * Additional Repoman checks (cp -[a,d], /bin/false, etc.)

  * Open Floor


--Kito
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

2005-09-16 Thread Lares Moreau
Does someone who is primarily working on (for arguents sake)
Translations does not nessessarily know what they are doing in terms
of overall gentoo dev.  My impression is that they have voting
privileges.  

My feeling is that people who know about TopicA will vote on things that
relate to that Topic and refrain from voting on things of which they
have little or no knowledge of.  SO why the big argument

Lares

On Tue, 2005-09-13 at 13:22 +0200, Simon Stelling wrote:
 Homer Parker wrote:
  On Tue, 2005-09-13 at 04:14 +0100, Ciaran McCreesh wrote:
  
 | voting previleges
 
 Again, why? They have not yet demonstrated their understanding of
 complex technical issues. Voting should be restricted to people who
 know what they're doing. Arch testers have not yet proven themselves.
  
  
  I don't remember that being asked for...
 
 As the GLEP asks to make the ATs staff, it'd imply giving them voting 
 privileges.
 
 -- 
 Simon Stelling
 Gentoo/AMD64 Operational Co-Lead
 [EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] Portability eclass

2005-09-16 Thread Diego 'Flameeyes' Pettenò
On Friday 16 September 2005 18:16, Martin Schlemmer wrote:
 I do not think its so urgent?  Either way, we have elibs approved now,
 so how about waiting a while so that we do not have yet another elib
 candidate to port?
There are at least two ebuilds in portage that uses cp --parente . It wasn't 
being a problem if it wasn't used.

elib can be approved, but we're working on Gentoo/*BSD (and Gentoo/OSX) now, 
not 4 years from now (ok that was an exageration, but simplify what the 
problem is: it doesn't seem probable that a newer portage goes out working 
and ebuilds start using the new features in a little time.

Remember that we had a bit of opposition also to have gcc using USE_EXPAND-ed 
variables, I can't figure what would happen also if tomorrow we find a 
portage with elib working :/

-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpIQB0FsUuqM.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Portability eclass

2005-09-16 Thread Chris Gianelloni
On Fri, 2005-09-16 at 18:33 +0200, Diego 'Flameeyes' Pettenò wrote:
 On Friday 16 September 2005 17:59, Mike Frysinger wrote:
  i dont see this being really useful ... either way, assuming the manpage is
  compressed with gzip (or compressed at all) is wrong
 Doesn't portage always gzip manpages?

No, it can bzip2 them, also.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux


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


Re: [gentoo-dev] [RFC] Portability eclass

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 12:33 pm, Diego 'Flameeyes' Pettenò wrote:
 On Friday 16 September 2005 17:59, Mike Frysinger wrote:
  i dont see this being really useful ... either way, assuming the manpage
  is compressed with gzip (or compressed at all) is wrong

 Doesn't portage always gzip manpages?

current stable does yes, but ive started adding customizable compression to 
trunk
-mike

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] Portability eclass

2005-09-16 Thread warnera6

Diego 'Flameeyes' Pettenò wrote:

On Friday 16 September 2005 19:28, Mike Frysinger wrote:


current stable does yes, but ive started adding customizable compression to
trunk


Okay, then *that* is a problem :P Suggestion how to fix it?



You are going to have to ask portage what it used via a PortageAPI call, 
I'd gather.

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Martin Schlemmer
On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote:
 On Friday 16 September 2005 00:20, Mike Frysinger wrote:
  actually this is came up in the meeting as something we would like to see
  spelled out explicitly ... either as a GLEP itself or as a policy update to
  current stabilization practices
 
  the GLEP was approved on the grounds that we need an x86 team and that it
  needs to be treated as any other arch ... arch team interaction with
  maintainers should be spelled out clearly rather than part of a single
  sentence '... or make individual arrangements with the x86 arch team.'
 
 Ok, I do think that we will need a way for the maintainer to indicate that 
 the 
 package is stable. I'd be happy to leave stabilizing out of my hands, but I 
 wouldn't want my packages to be stabilized before I deem it stable.
 

File a bug if the arches (or main ones at least) haven't picked it up
yet?  Will make the problem of missing some or other keyword minimal
(especially for some obscure package not often used).


-- 
Martin Schlemmer



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


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Brian Harring
On Fri, Sep 16, 2005 at 08:14:08PM +0200, Martin Schlemmer wrote:
 On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote:
  On Friday 16 September 2005 00:20, Mike Frysinger wrote:
   actually this is came up in the meeting as something we would like to see
   spelled out explicitly ... either as a GLEP itself or as a policy update 
   to
   current stabilization practices
  
   the GLEP was approved on the grounds that we need an x86 team and that it
   needs to be treated as any other arch ... arch team interaction with
   maintainers should be spelled out clearly rather than part of a single
   sentence '... or make individual arrangements with the x86 arch team.'
  
  Ok, I do think that we will need a way for the maintainer to indicate that 
  the 
  package is stable. I'd be happy to leave stabilizing out of my hands, but I 
  wouldn't want my packages to be stabilized before I deem it stable.
  
 
 File a bug if the arches (or main ones at least) haven't picked it up
 yet?  Will make the problem of missing some or other keyword minimal
 (especially for some obscure package not often used).
I would prefer this route, personally.

Jamming a maint keyword into the ebuild is kind of ugly from where I 
sit :)
~harring


pgp1E2oHKfzdH.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Simon Stelling

Paul de Vrieze wrote:
Ok, I do think that we will need a way for the maintainer to indicate that the 
package is stable. I'd be happy to leave stabilizing out of my hands, but I 
wouldn't want my packages to be stabilized before I deem it stable.


That's exactly what the maint keyword is for.


--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Ciaran McCreesh
On Fri, 16 Sep 2005 19:42:36 +0200 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| Ok, I do think that we will need a way for the maintainer to indicate
| that the package is stable. I'd be happy to leave stabilizing out of
| my hands, but I wouldn't want my packages to be stabilized before I
| deem it stable.

Take it out of package.mask and leave it for thirty (package-dependent)
days. If there is a pressing (eg security) reason for it to go to
stable sooner than would normally be expected, file a bug and Cc: the
relevant arch teams.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpi9rE5zIdCg.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Ciaran McCreesh
On Fri, 16 Sep 2005 20:48:45 +0200 Paul de Vrieze [EMAIL PROTECTED]
wrote:
|  Take it out of package.mask and leave it for thirty
|  (package-dependent) days. If there is a pressing (eg security)
|  reason for it to go to stable sooner than would normally be
|  expected, file a bug and Cc: the relevant arch teams.
| 
| I was thinking more like signalling that it shouldn't be stable yet,
| but shouldn't be masked either.

Well, if it's in ~arch it's a candidate to go to stable after further
testing. If a package maintainer isn't prepared to have a package moved
to stable, they shouldn't take it out of package.mask.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpPAZRMgyiSL.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Portability eclass

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 01:36 pm, Diego 'Flameeyes' Pettenò wrote:
 On Friday 16 September 2005 19:28, Mike Frysinger wrote:
  current stable does yes, but ive started adding customizable compression
  to trunk

 Okay, then *that* is a problem :P Suggestion how to fix it?

simple, dont add the function

but i guess if you insist on cruft, create the symlink w/out a compression 
extension and portage may fix it for you (or it may remove it, who knows)
-mike

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Simon Stelling

Ciaran McCreesh wrote:

Well, if it's in ~arch it's a candidate to go to stable after further
testing. If a package maintainer isn't prepared to have a package moved
to stable, they shouldn't take it out of package.mask.


The 30 days are just a rule, there are enough packages which surely need a 
longer testing period, even if they work flawlessly. Or would you mark gcc 4.0 
stable after 30 days? I think that's what Paul wanted to say.


--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 03:02 pm, Ciaran McCreesh wrote:
 On Fri, 16 Sep 2005 20:48:45 +0200 Paul de Vrieze [EMAIL PROTECTED]

 wrote:
 |  Take it out of package.mask and leave it for thirty
 |  (package-dependent) days. If there is a pressing (eg security)
 |  reason for it to go to stable sooner than would normally be
 |  expected, file a bug and Cc: the relevant arch teams.
 |
 | I was thinking more like signalling that it shouldn't be stable yet,
 | but shouldn't be masked either.

 Well, if it's in ~arch it's a candidate to go to stable after further
 testing. If a package maintainer isn't prepared to have a package moved
 to stable, they shouldn't take it out of package.mask.

not really ... sometimes you want to keep a package in unstable forever (like 
the cvs snapshots i make of e17), or until you work some quirks/features out 
for a new revbump which you would want stable
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Ciaran McCreesh
On Fri, 16 Sep 2005 21:12:56 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| Ciaran McCreesh wrote:
|  Well, if it's in ~arch it's a candidate to go to stable after
|  further testing. If a package maintainer isn't prepared to have a
|  package moved to stable, they shouldn't take it out of package.mask.
| 
| The 30 days are just a rule, there are enough packages which surely
| need a longer testing period, even if they work flawlessly. Or would
| you mark gcc 4.0 stable after 30 days? I think that's what Paul
| wanted to say.

For that, I'd point you at the devmanual version of keywording policy,
which is a hell of a lot better written and includes an explicit remark
about core system components needing a lot more than 30 days.

http://dev.gentoo.org/~plasmaroo/devmanual/keywording/

Plus for stuff like gcc, it's very much an arch decision, not a package
maintainer decision.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgp54tvvRBLYy.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Ciaran McCreesh
On Fri, 16 Sep 2005 15:15:26 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| not really ... sometimes you want to keep a package in unstable
| forever (like the cvs snapshots i make of e17), or until you work
| some quirks/features out for a new revbump which you would want stable

Those should be in package.mask. ~arch is for candidates for arch that
haven't yet proven themselves.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpO2kheLRBls.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Aron Griffis
Vapier wrote:[Fri Sep 16 2005, 03:15:26PM EDT]
 not really ... sometimes you want to keep a package in unstable
 forever (like the cvs snapshots i make of e17), or until you work
 some quirks/features out for a new revbump which you would want
 stable

Why wouldn't you put these in package.mask?

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer



pgp4V1gCmR7oy.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Aron Griffis
Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT]
  Those should be in package.mask. ~arch is for candidates for arch that
  haven't yet proven themselves.
 
 It's often the case that those ebuilds in principle work, but there
 are other reasons for not marking stable yet. Some packages for
 example can have upgrade problems for stable users while being
 stable for testing (by benefit of allready having passed such
 upgrade problems). Masking the ebuild is not really an option
 (causing testing users to go through unnecessary hoops again), while
 marking stable is also no option.

You're saying there's four states:

package.mask
~arch
~arch candidate for arch
arch

Putting packages in package.mask isn't a hardship for testers.  I'm
not sure that's a good reason for the additional state.  It's purely
a matter of

echo 'dev-util/mercurial'  /etc/portage/package.unmask

So far I find myself agreeing with Ciaran's idea in this thread.
I don't see the point (yet) in more than three states.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer



pgppgsKoBkwrJ.pgp
Description: PGP signature


Re: [gentoo-dev] Clarification of packages cd's for 2005.1

2005-09-16 Thread Nick Rout
Thanks for the clarification Chris.

On a semi-related matter I was looking for the catalyst .spec files, and
see a thread pointing at cvs, however I believe that as a non-dev mortal I
can't get access to gentoo cvs. Is that so? If it is then how does one get
the spec files? The old catalyst howto seems to have disappeared too.



-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Clarification of packages cd's for 2005.1

2005-09-16 Thread Brian Harring
On Sat, Sep 17, 2005 at 08:23:47AM +1200, Nick Rout wrote:
 Thanks for the clarification Chris.
 
 On a semi-related matter I was looking for the catalyst .spec files, and
 see a thread pointing at cvs, however I believe that as a non-dev mortal I
 can't get access to gentoo cvs. Is that so? If it is then how does one get
 the spec files? The old catalyst howto seems to have disappeared too.
http://www.gentoo.org/cgi-bin/viewcvs.cgi 

Is a start ;)
~harring


pgp0iks5YMa4J.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 03:34 pm, Ciaran McCreesh wrote:
 On Fri, 16 Sep 2005 15:15:26 -0400 Mike Frysinger [EMAIL PROTECTED]

 wrote:
 | not really ... sometimes you want to keep a package in unstable
 | forever (like the cvs snapshots i make of e17), or until you work
 | some quirks/features out for a new revbump which you would want stable

 Those should be in package.mask. ~arch is for candidates for arch that
 haven't yet proven themselves.

ok, e17 packages dont count here.  however, your hardcore view i still dont 
buy.  how about the baselayout-1.9.x - baselayout-1.11.x stabilization 
process ?  are you telling me that arch teams should have had the power to 
move those into stable without talking to the maintainer ?  baselayout may be 
a core package, but if you continue with your hard rule here, then it doesnt 
matter.
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Olivier Crete
On Fri, 2005-16-09 at 16:21 -0400, Aron Griffis wrote:
 Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT]
   Those should be in package.mask. ~arch is for candidates for arch that
   haven't yet proven themselves.
  
  It's often the case that those ebuilds in principle work, but there
  are other reasons for not marking stable yet. Some packages for
  example can have upgrade problems for stable users while being
  stable for testing (by benefit of allready having passed such
  upgrade problems). Masking the ebuild is not really an option
  (causing testing users to go through unnecessary hoops again), while
  marking stable is also no option.
 
 You're saying there's four states:
 
 package.mask
 ~arch
 ~arch candidate for arch
 arch
[...]
 So far I find myself agreeing with Ciaran's idea in this thread.
 I don't see the point (yet) in more than three states.

Well having the ~arch candidate for arch makes the imlate script much
easier to use.. I would find it a PITA to have to go through the
changelog of every package to see if it has been in testing for 30
days.. Or we need to automate it, something like a
imlate-because-the-package-hasnt-changed-in-30-days.py 

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Ciaran McCreesh
On Fri, 16 Sep 2005 22:17:20 +0200 Carsten Lohrke [EMAIL PROTECTED]
wrote:
| On Friday 16 September 2005 21:34, Ciaran McCreesh wrote:
|  Those should be in package.mask. ~arch is for candidates for arch
|  that haven't yet proven themselves.
| 
| No. Your idea how it should work simply doesn't match reality.

That's not my idea. That's policy. I just happen to a) have actually
read what policy says and b) agree with it.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpanIaLjyO98.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 04:25 pm, Daniel Ostrow wrote:
 His point (and it's an unfortunately valid one) as I understand it is
 that our user base has been (mis)educated to avoid packages in p.mask
 for fear of breaking things too badly. As such it gets an inherently far
 smaller test base then packages in ~arch do.

i [rightly] fear package.mask packages most of the time.  we stick things in 
there that have security issues, or are known to be badly broken in some way, 
or wont work in subprofiles for archs (think glibc-specific packages masked 
in a uclibc profile).  at the sametime, we use package.mask for things that 
*should* work fine, but we dont know yet.  i wouldnt mind a restricted 4th 
level of masking here:

arch stable
~arch unstable
?arch should work fine, but not 100% sure yet
package.mask known to be broken in some way

it's also a pita to maintain package.mask since we're storing information 
about specific ebuilds outside of the ebuild itself, and it tends to suffer 
badly from bitrot
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote:
 On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger [EMAIL PROTECTED]

 wrote:
 | ok, e17 packages dont count here.  however, your hardcore view i
 | still dont buy.  how about the baselayout-1.9.x - baselayout-1.11.x
 | stabilization process ?  are you telling me that arch teams should
 | have had the power to move those into stable without talking to the
 | maintainer ?  baselayout may be a core package, but if you continue
 | with your hard rule here, then it doesnt matter.

 I'm saying that arch teams should be allowed to mark it stable if they
 think it's appropriate. Not that it must be moved to stable after $x
 days, but that it can be at the arch team's discretion. And any arch
 team which is silly enough to mark a broken baselayout stable has far
 bigger problems anyway...

baselayout is an example, any package can be used here (although not many are 
as critical)

i'm saying that the maintainer may have a certain idea of when the package is 
ready for stable (a target feature set, working out certain quirks, etc...).  
your current hard view does not allow for that.  for example, i had an arch 
maintainer one time mark bash-3 stable before base-system was ready for it 
(readline, baselayout, etc... were going to be stabilized together).  i 
smacked them hard for it, but if we went with this hard view, it would have 
been perfectly acceptable behavior.
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Ciaran McCreesh
On Fri, 16 Sep 2005 16:59:56 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| baselayout is an example, any package can be used here (although not
| many are as critical)
| 
| i'm saying that the maintainer may have a certain idea of when the
| package is ready for stable (a target feature set, working out
| certain quirks, etc...). your current hard view does not allow for
| that.  for example, i had an arch maintainer one time mark bash-3
| stable before base-system was ready for it (readline, baselayout,
| etc... were going to be stabilized together).  i smacked them hard
| for it, but if we went with this hard view, it would have been
| perfectly acceptable behavior. -mike

There is nothing in this view that says consulting the package
maintainer is not part of the stable decision-making process for arch
teams.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpZ2x7fCaSsi.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Simon Stelling

Ciaran McCreesh wrote:

There is nothing in this view that says consulting the package
maintainer is not part of the stable decision-making process for arch
teams.


So do I have to ask the maintainer first everytime I want mark a package stable? 
Is that what you are currently doing?


--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Carsten Lohrke
On Friday 16 September 2005 22:38, Ciaran McCreesh wrote:
 That's not my idea. That's policy. I just happen to a) have actually
 read what policy says and b) agree with it.

First: I know you're proposing this regularly, but please show me the policy - 
I'm sure your interpretation doesn't match mine.

Second: a) and b) doesn't match what's going on with large parts of the tree 
and I refuse to constantly add and remove ebuilds from the package.mask file, 
that are not really broken. It's only extra work for me and confusing for 
users.


Carsten


pgpzWVdprzyGa.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Ciaran McCreesh
On Fri, 16 Sep 2005 23:20:58 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| Ciaran McCreesh wrote:
|  There is nothing in this view that says consulting the package
|  maintainer is not part of the stable decision-making process for
|  arch teams.
| 
| So do I have to ask the maintainer first everytime I want mark a
| package stable? Is that what you are currently doing?

No. You *can* ask the package maintainer, if you feel that such a move
would be useful and productive.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpO5yI6AE5KF.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Ciaran McCreesh
On Fri, 16 Sep 2005 23:23:35 +0200 Carsten Lohrke [EMAIL PROTECTED]
wrote:
| On Friday 16 September 2005 22:38, Ciaran McCreesh wrote:
|  That's not my idea. That's policy. I just happen to a) have actually
|  read what policy says and b) agree with it.
| 
| First: I know you're proposing this regularly, but please show me the
| policy - I'm sure your interpretation doesn't match mine.

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1

 There is a difference between using package.mask and ~arch for
 ebuilds. The use of ~arch denotes an ebuild requires testing. The use
 of package.mask denotes that the application or library itself is
 deemed unstable.

| Second: a) and b) doesn't match what's going on with large parts of
| the tree 

Good time for package maintainers to start following policy properly,
eh?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpWkh8wb13nI.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Patrick Lauer
On Fri, 2005-09-16 at 22:34 +0100, Ciaran McCreesh wrote:
  There is a difference between using package.mask and ~arch for
  ebuilds. The use of ~arch denotes an ebuild requires testing. The use
  of package.mask denotes that the application or library itself is
  deemed unstable.
 | Second: a) and b) doesn't match what's going on with large parts of
 | the tree 
 
 Good time for package maintainers to start following policy properly,
 eh?
Good time for policy to be adapted to match reality ;-)

-- 
Stand still, and let the rest of the universe move


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


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Ciaran McCreesh
On Fri, 16 Sep 2005 23:41:21 +0200 Patrick Lauer [EMAIL PROTECTED]
wrote:
|  Good time for package maintainers to start following policy
|  properly, eh?
| Good time for policy to be adapted to match reality ;-)

Reality is that most people do exactly what policy says. Most bumps
don't warrant a package.mask entry anyway -- most upstreams for
non-trivial apps know about change control.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpSQvLgb0bFc.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 04:43 pm, Mike Frysinger wrote:
 On Friday 16 September 2005 04:25 pm, Daniel Ostrow wrote:
  His point (and it's an unfortunately valid one) as I understand it is
  that our user base has been (mis)educated to avoid packages in p.mask
  for fear of breaking things too badly. As such it gets an inherently far
  smaller test base then packages in ~arch do.

 arch stable
 ~arch unstable
 ?arch should work fine, but not 100% sure yet
 package.mask known to be broken in some way

actually, going with say 'testing.mask' instead of '?arch' may be better ... 
reinforce the fact that this is a package-level issue rather than 
arch-specific
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 05:26 pm, Ciaran McCreesh wrote:
 On Fri, 16 Sep 2005 23:20:58 +0200 Simon Stelling [EMAIL PROTECTED]

 wrote:
 | Ciaran McCreesh wrote:
 |  There is nothing in this view that says consulting the package
 |  maintainer is not part of the stable decision-making process for
 |  arch teams.
 |
 | So do I have to ask the maintainer first everytime I want mark a
 | package stable? Is that what you are currently doing?

 No. You *can* ask the package maintainer, if you feel that such a move
 would be useful and productive.

that's the problem, there's no way to flag which packages should be consulted 
and which ones are a non-issue
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Martin Schlemmer
On Fri, 2005-09-16 at 16:59 -0400, Mike Frysinger wrote:
 On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote:
  On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger [EMAIL PROTECTED]
 
  wrote:
  | ok, e17 packages dont count here.  however, your hardcore view i
  | still dont buy.  how about the baselayout-1.9.x - baselayout-1.11.x
  | stabilization process ?  are you telling me that arch teams should
  | have had the power to move those into stable without talking to the
  | maintainer ?  baselayout may be a core package, but if you continue
  | with your hard rule here, then it doesnt matter.
 
  I'm saying that arch teams should be allowed to mark it stable if they
  think it's appropriate. Not that it must be moved to stable after $x
  days, but that it can be at the arch team's discretion. And any arch
  team which is silly enough to mark a broken baselayout stable has far
  bigger problems anyway...
 
 baselayout is an example, any package can be used here (although not many are 
 as critical)
 
 i'm saying that the maintainer may have a certain idea of when the package is 
 ready for stable (a target feature set, working out certain quirks, etc...).  
 your current hard view does not allow for that.  for example, i had an arch 
 maintainer one time mark bash-3 stable before base-system was ready for it 
 (readline, baselayout, etc... were going to be stabilized together).  i 
 smacked them hard for it, but if we went with this hard view, it would have 
 been perfectly acceptable behavior.

We still have KEYWORDS=-*.  Sure, I know many do not like it, and if
something was decided in regards to it, I missed it, but it is generally
seen as 'less severe' than a package.mask'd mask, and its local to the
package, so should not get stale.



-- 
Martin Schlemmer



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


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Kito


On Sep 16, 2005, at 4:50 PM, Mike Frysinger wrote:


actually, going with say 'testing.mask' instead of '?arch' may be  
better ...

reinforce the fact that this is a package-level issue rather than
arch-specific


I like that concept. A lot less communication overhead, and addresses  
most of the current problems AFAICT.


--Kito

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 05:57 pm, Martin Schlemmer wrote:
 On Fri, 2005-09-16 at 16:59 -0400, Mike Frysinger wrote:
  On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote:
   On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger [EMAIL PROTECTED]
  
   wrote:
   | ok, e17 packages dont count here.  however, your hardcore view i
   | still dont buy.  how about the baselayout-1.9.x - baselayout-1.11.x
   | stabilization process ?  are you telling me that arch teams should
   | have had the power to move those into stable without talking to the
   | maintainer ?  baselayout may be a core package, but if you continue
   | with your hard rule here, then it doesnt matter.
  
   I'm saying that arch teams should be allowed to mark it stable if they
   think it's appropriate. Not that it must be moved to stable after $x
   days, but that it can be at the arch team's discretion. And any arch
   team which is silly enough to mark a broken baselayout stable has far
   bigger problems anyway...
 
  baselayout is an example, any package can be used here (although not many
  are as critical)
 
  i'm saying that the maintainer may have a certain idea of when the
  package is ready for stable (a target feature set, working out certain
  quirks, etc...). your current hard view does not allow for that.  for
  example, i had an arch maintainer one time mark bash-3 stable before
  base-system was ready for it (readline, baselayout, etc... were going to
  be stabilized together).  i smacked them hard for it, but if we went with
  this hard view, it would have been perfectly acceptable behavior.

 We still have KEYWORDS=-*.  Sure, I know many do not like it, and if
 something was decided in regards to it, I missed it, but it is generally
 seen as 'less severe' than a package.mask'd mask, and its local to the
 package, so should not get stale.

that would address the 'arch teams marking ahead of maintainer' issue, but in 
general, i think we need a testing mask of some sort separate from 
package.mask where we can put things like modular X, new KDE betas, new GNOME 
betas, e17 packages, etc...
-mike
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] [RFC] C++ herd proposal

2005-09-16 Thread Mark Loeser
Since we currently have language herds for other languages such as Ada,
Perl, and Java, I don't think C++ should be any different.  There are
currently many packages in the tree that are C++ libraries or utilities
that are no-herd and are actively maintained, and there are probably
some that have just been sitting around rotting.  With the creation of a
C++ herd, there would be a team that could support these packages,
instead of a single maintainer, if the package has one.  Below is a list
of all of the packages that I believe would qualify as falling under
this herd.  If you see your name in the following list, I'd especially
like to hear from you.  Names with a '?' next to them are packages that
had no metadata and I guessed from the changelog who the maintainer is.
 I would also like to see many of them, if not all, moved to the dev-cpp
category:

dev-cpp/commoncpp2  (no-herd, arj)
dev-cpp/gccxml  (no-herd, g2boojum)
dev-cpp/libibinio   (no-herd, spock)
dev-cpp/poslib  (no-herd, matsuu)
dev-cpp/rudiments   (no-herd, matsuu)
dev-db/libodbc++(no-herd, robbat2)
dev-libs/STLport(no-herd, vapier?)
dev-libs/asyncresolv(no-herd, jhhudso?)
dev-libs/blitz  (no-herd, dragonheart)
dev-libs/boost  (no-herd, morfic)
dev-libs/cgicc  (no-herd, ka0ttic)
dev-libs/commonc++  (duplicate of dev-cpp/commoncpp2 as far as I
can tell, unmaintained?)
dev-libs/darts  (no-herd, unmaintained?)
dev-libs/dvacm4 (no-herd, pvdabeel?)
dev-libs/dvcgi  (no-herd, ka0ttic)
dev-libs/dvutil (no-herd, ka0ttic)
dev-libs/fampp2 (no-herd, vapier)
dev-libs/ferrisloki (no-herd, vapier)
dev-libs/ibpp   (no-herd, sekretarz)
dev-libs/korelib(no-herd, george?)
dev-libs/libcoyotl  (no-herd, aliz)
dev-libs/libevocosm (no-herd, aliz)
dev-libs/libferrisstreams   (no-herd, vapier)
dev-libs/log4cpp(no-herd, george?)
dev-libs/log4cxx(no-herd, ka0ttic)
dev-libs/luabind(no-herd, rphillips)
dev-libs/ntl(no-herd, george?)
dev-libs/pcre++ (no-herd, eradicator)
dev-libs/ptypes (no-herd, dragonheart? george?)
dev-libs/quantlib   (no-herd, vanquirius)
dev-libs/rlog   (no-herd, vanquirius)
dev-libs/socketstream   (no-herd, george? dragonheart?)
dev-libs/sucs   (no-herd, ka0ttic)
dev-libs/swl(no-herd, trapni upstream dead? The site
appears to be dead)
dev-libs/wefts  (no-herd, flameeyes)
dev-libs/xerces-c   (no-herd, halcy0n)
dev-libs/xmlwrapp   (no-herd, ka0ttic)
dev-libs/yaz++  (no-herd, robbat2)
dev-util/leaktracer (no-herd, svyatogor?)
net-libs/socket++   (no-herd, ka0ttic)

Possible candidates (most of these are for C and C++):
dev-libs/nana   (no-herd, pyrania?)
dev-libs/xmlrpc-c   (no-herd, jhhudso)
dev-libs/xxl(no-herd, ka0ttic)
dev-util/astyle (no-herd, karltk)
dev-util/bcpp   (no-herd, chriswhite?)
dev-util/   (no-herd, dragonheart?)
dev-util/ccmalloc   (no-herd, dholm)
dev-util/cdecl  (no-herd, phosphan)
dev-util/cweb   (no-herd, no one)
dev-util/flawfinder (no-herd, aliz?)
dev-util/rats   (no-herd, robbat2)

Currently under another herd, but seems to make more sense here:

dev-cpp/libxmlpp(gnome-mm, ka0ttic)
dev-cpp/sptk(desktop-misc, iluxa?)
dev-libs/libsigc++  (gnome-mm, ka0ttic)
dev-libs/libsigcx   (gnome-mm, ka0ttic)
dev-libs/mxmlplus   (text-markup, usata)
dev-libs/xplc   (net-dialup, mrness)
dev-util/cppunit(lang-misc, george?)
dev-util/qtunit (kde, centic?)
net-libs/wvstreams  (net-dialup, mrness?)


I would like all of the current maintainers of these packages to keep
maintaining them, and they wouldn't be required to join the cpp team,
but there are a few people that seem to maintain quite a few C++
libraries that might be interested in joining.

If there is not a very good reason against the creation of this herd, I
would like to do so in the coming week.  As for the name, cpp may be a
little misleading, any better suggestions?  In the list above, I have
libraries for C++, as well as utilities.

Thanks,

Mark


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Maurice van der Pot
On Fri, Sep 16, 2005 at 05:50:39PM -0400, Mike Frysinger wrote:
 actually, going with say 'testing.mask' instead of '?arch' may be better ... 
 reinforce the fact that this is a package-level issue rather than 
 arch-specific

Let me get things straight. We would want this because it's the least of 
two evils?

On one hand ?arch isn't nice because it's package-level instead of 
arch-specific, so it doesn't belong among keywords. 
On the other hand testing.mask (if it's like package.mask) takes this 
(package-level) stuff and moves it out of the ebuilds it belongs to and 
dumps it all in one file.

So we'd want this because we don't want to introduce something new in
the ebuilds?

Just getting things straight before expressing my opinion explicitly =]

Maurice.

-- 
Maurice van der Pot

Gentoo Linux Developer   [EMAIL PROTECTED] http://www.gentoo.org
Creator of BiteMe!   [EMAIL PROTECTED]   http://www.kfk4ever.com



pgpdCM9aKrnq7.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Carsten Lohrke
On Friday 16 September 2005 23:34, Ciaran McCreesh wrote:
 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1

As I said - your interpretation doesn't match mine - or the policy is not good 
enough.

 Good time for package maintainers to start following policy properly,
 eh?

I'm sorry, not your idea of this policy.


Carsten


pgpqzvyZIqfGJ.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Carsten Lohrke
On Friday 16 September 2005 23:50, Mike Frysinger wrote:
 actually, going with say 'testing.mask' instead of '?arch' may be better
 ... reinforce the fact that this is a package-level issue rather than
 arch-specific
 -mike

That's nearly as bad as having to deal with package.mask all the time. Keeping 
the maintainer's opinion on an ebuild outside of it doesn't make any sense.


Carsten


pgpSbVWzSfada.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Carsten Lohrke
On Friday 16 September 2005 23:26, Ciaran McCreesh wrote:
 No. You *can* ask the package maintainer, if you feel that such a move
 would be useful and productive.

No. There're lot of issues an arch maintainer not necessarily knows about. 
Without a way to indicate which ebuild is good, the whole position of a 
package maintainer is void.


Carsten


pgp1d23pqkLkk.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Carsten Lohrke
On Friday 16 September 2005 23:57, Martin Schlemmer wrote:
 We still have KEYWORDS=-*.

I'd appreciate, if we disallow that and all use package.mask.


Carsten


pgpanBD00AO4P.pgp
Description: PGP signature


Re: [gentoo-dev] first council meeting

2005-09-16 Thread Ciaran McCreesh
On Sat, 17 Sep 2005 00:43:02 +0200 Carsten Lohrke [EMAIL PROTECTED]
wrote:
|  Good time for package maintainers to start following policy
|  properly, eh?
| 
| I'm sorry, not your idea of this policy.

Policy is rather specific about it. It's not a matter of interpretation
at all.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpWzMjPyBw6j.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] C++ herd proposal

2005-09-16 Thread Mike Frysinger
On Friday 16 September 2005 06:20 pm, Mark Loeser wrote:
 Since we currently have language herds for other languages such as Ada,
 Perl, and Java, I don't think C++ should be any different.

it is different, but i dont mind the idea of having a bunch of C++ experts 
looking over a bunch of packages which otherwise may be neglected

 dev-libs/STLport(no-herd, vapier?)

vapier/toolchain

 dev-libs/fampp2 (no-herd, vapier)
 dev-libs/ferrisloki (no-herd, vapier)
 dev-libs/libferrisstreams   (no-herd, vapier)
 dev-db/stldb4

generally i dont need help with these as the upstream author is a pretty cool 
guy and gets back to me :)
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Carsten Lohrke
On Saturday 17 September 2005 01:00, Ciaran McCreesh wrote:
 Policy is rather specific about it. It's not a matter of interpretation
 at all.

That I disagree should prove that this is not a case. It's one thing to 
consider an application to just work for the user and another having e.g. 
the history of bug fix releases for previous versions in mind or knowing 
about minor but annoying bugs, which should be fixed before some version of 
it goes stable.


Carsten


pgpV8TNkyg3Vn.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC

2005-09-16 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Diego 'Flameeyes' Pettenò wrote:
 I don't trust automatic correction, false positives can always happen, 
 currently my way to proceed with such problems is opening a big bug and 
 poking maintainers to fix them :)


The esyntaxer tool will warn and/OR autocorrect; user's choice. The
warnings are intended to teach (by pointing to documentation) rather
than just moaning and groaning. And while I'll agree that there are
always edge cases and autocorrection will never be 100%, I must say that
the kinds of errors I'm correcting aren't that hard. Besides, esyntaxer
isn't something your run and forget; it is *not* a replacement for peer
review by good ole' humans. :)

Nathan



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDK1b12QTTR4CNEQARAmMkAJ0QSZ+p1SoImPQEIRzM3iq5BwaxtACgghKH
ReLKbUMlgPNGIch77olSWvQ=
=2OgF
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] compiler-config-2.0_alpha1

2005-09-16 Thread Jeremy Huddleston
Ok, I've put together an alpha release of compiler-config-2.0.  This is
a replacement for gcc-config which is alot more configurable

Some notable improvements over gcc-config-1.3.x:
GCC_SPECS and PATH are nolonger set in /etc/env.d/05gcc.  Instead, that
info is in the config files and extracted by the wrapper.
Users can have their own settings rather than use the system compiler.
Multilib archs will be able to have more control over the compilers used
for each ABI.  For example, you can install x86_64-*-gcc-3.4.4 and
i686-*-gcc-3.3.6 and choose to use either 3.4.4 or 3.3.6 when compiling
code with i686-*-gcc

Also, many thanks to sekretarz for writing the config file parser.

Requirements:
Emerge eselect before you install this.

Notes:
This is alpha.  It might break; the eselect module still needs cleaning
up and functionality added; yada yada yada.  There's no migration script
yet from the 1.3.x config files, and also toolchain.eclass doesn't make
config files for it either which means you need to make the config files
yourself.  You can find sample config files for gcc-3.4.4 on amd64 in
the conf directory of the tarball.  Just copy them
to /etc/eselect/compiler and edit them appropriately.  If anyone wants
to help with the migration script or anything else for that matter,
please let me know.

I'm not making an ebuild for it because there's no migration script for
it, and I'd like to get it cleaned up and finished more before it
reaches cvs (even in a package.mask state).

http://dev.gentoo.org/~eradicator/gcc/compiler-config-2.0_alpha1.tar.gz

--Jeremy


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


Re: [gentoo-dev] [RFC] C++ herd proposal

2005-09-16 Thread Aaron Walker

Mark Loeser wrote:

Since we currently have language herds for other languages such as Ada,
Perl, and Java, I don't think C++ should be any different.  There are
currently many packages in the tree that are C++ libraries or utilities
that are no-herd and are actively maintained, and there are probably
some that have just been sitting around rotting.  With the creation of a
C++ herd, there would be a team that could support these packages,
instead of a single maintainer, if the package has one.  Below is a list
of all of the packages that I believe would qualify as falling under
this herd.  If you see your name in the following list, I'd especially
like to hear from you.  Names with a '?' next to them are packages that
had no metadata and I guessed from the changelog who the maintainer is.
 I would also like to see many of them, if not all, moved to the dev-cpp
category:


snip

I'm game.

--
Who's scruffy-looking?
-- Han Solo

Aaron Walker [EMAIL PROTECTED]
[ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ]
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] The tree is now utf-8 clean

2005-09-16 Thread Ciaran McCreesh
The tree is now utf-8 clean. Or it is to the extent that a computer can
reasonably determine... If the relevant people are prepared to smack
anyone who refuses to play nice then now would be a good time to
unwithdraw GLEP 31, make compliance mandatory and add glep31check [1] to
repoman or server-side.

There are still a few instances of munged character sequences that
happen to also be valid UTF-8. If you come across one, feel free to fix
it.

If you have weird characters in your name, please make especially sure
that you're getting your ChangeLog name right. These are far more common
than occasional user credit ChangeLog entries. Also, if your name on the
devlist [2] isn't accented, pester someone to update it.

Something strange I noticed... Some people are using funny quotes and
non breaking spaces in ebuilds. Some people are using weird characters
as substitution delimiters for sed. Don't! It will break on many
systems. I'm going to go and purge all of those, UTF-8 or not, whenever
my brain recovers.

As far as editor support... On those really rare occasions when you need
to enter UTF-8 text in ebuilds, vim, emacs and nano should all more or
less work. For ChangeLogs, echangelog is utf-8 transparent, meaning if
you run it from a UTF-8 terminal it should be ok. We have a guide [3] if
you want to know more...

[1]: http://dev.gentoo.org/~ciaranm/toys/glep31check-0.3.3.tar.bz2
[2]: http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml
[3]: http://www.gentoo.org/doc/en/utf-8.xml

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpR2WIhHmmXx.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] C++ herd proposal

2005-09-16 Thread Ciaran McCreesh
On Fri, 16 Sep 2005 18:20:57 -0400 Mark Loeser [EMAIL PROTECTED]
wrote:
| Since we currently have language herds for other languages such as
| Ada, Perl, and Java, I don't think C++ should be any different.
| There are currently many packages in the tree that are C++ libraries
| or utilities that are no-herd and are actively maintained, and there
| are probably some that have just been sitting around rotting.  With
| the creation of a C++ herd, there would be a team that could support
| these packages, instead of a single maintainer, if the package has
| one.  Below is a list of all of the packages that I believe would
| qualify as falling under this herd.  If you see your name in the
| following list, I'd especially like to hear from you.  Names with a
| '?' next to them are packages that had no metadata and I guessed from
| the changelog who the maintainer is. I would also like to see many of
| them, if not all, moved to the dev-cpp
| category:

I use some of those. Count me in, so long as I don't ever have to touch
the hideous monstrosity that is boost...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgp1ISw7SmNLF.pgp
Description: PGP signature


Re: [gentoo-portage-dev] PATCH: gentoolkit: Make portage.config object a global object

2005-09-16 Thread Alec Warner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jason Stubbs wrote:
 On Saturday 17 September 2005 01:59, Paul Varner wrote:
 
http://bugs.gentoo.org/show_bug.cgi?id=90680

Author: Paul Varner

The current implementation of gentoolkit creates a portage.config object
for every package object that it creates. While this is the correct
thing to do from an object-oriented programming point of view, this
implementation consumes an excessive amount of memory and CPU.  The
proposed patch changes the portage.config object for each package object
to point to a single global object.

If no one sees any serious issues with the patch, I will be placing it
into gentoolkit.
 
 
 I tried doing this once before locally, but found some issue with it. 
 Unfortunately, I can't remember what that issue was. If you are calling 
 setcpv() for every call to the package object that utilizes the config 
 object and no utilizing packages (in gentoolkit or otherwise) are utilizing 
 threading, it should theoretically be okay. Actually, I think it was the 
 threading issue that delayed the fix.
 

I can't remember the model for this, but there is some logic along the
lines of intercepting config object writes with setattr and then cloning
the config object.  That way if the config is read-only only 1 is
instantiated, but if you attempt to modify it, the config would clone
itself, then proceed with the modification and return the cloned copy.
Not sure how easy that would be to implement, perhaps some sort of
wrapper class?

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

iQIVAwUBQytkOmzglR5RwbyYAQKDvw//Wz/TpPF35sf+yhz5dyQ09qN5Ug9qiTec
qDnf364k+lzUSXzzNEjhpgSpyyKcEv30CjZWTn+g3IoH7aQ2v2mIIF+5V0C/9kxP
JH0a+ibh+Mvzv28tteEE+VX4yTykNz8L5b6twwQO/53GfY8Dj/l19AqOrjgHOfGf
/nvslpqEiFmAzc0RdxMuOAiFHdcfZgZyQpHsHboTZ7kQQpFTX4h1nShNAkGiceBI
ucfIs/Fp0RunDUYK2pfIedbLKsfRKyySaUOXXPUrTiwufO7zbyvRZI/+mBLJlL6v
Ud49wak10G8dFNZA9J3LgWRoy2Dqxrp6Eu7gTp5U4ONKLSJo3CSVa+1P2eACmerl
RqlAaVxtz+lpaXoiTSNoFKzjrIgidT00d7kG0v/gbI0vsqVy31nEuaSqWgAwjBit
GeDV8A9Tnxe+UNyUkd4BpBX3p8bX4EyDUNqfv0OChuCXbozbc1yizksSps8+Y3iQ
uG29o90/ExvsRQVAFKhWBjc9aYgghMhTO8yrKGkp4eI+ewa82QhLnlhgdQRMLSqY
ox+IRPxClIVRLzUZ4m3BsITy3QdSqvVhrB7ITofIFjXSY0OPQivA0HSebnPDptlU
mPreE6NzWs7KGhjhBvatqKnM7CuzW9JogolXkk+vT/pvSWlAoPc48mAW77CmKO5G
q3754DSKb3A=
=uzjq
-END PGP SIGNATURE-
-- 
gentoo-portage-dev@gentoo.org mailing list