Re: [gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
-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
