On Fri, Sep 16, 2005 at 04:16:22PM -0400, Aron Griffis wrote:
> 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 whi
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
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-si
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 prob
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
-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 an
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
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 packag
On Friday 16 September 2005 06:45 pm, Carsten Lohrke wrote:
> 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
>
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 M
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
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
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.
On Friday 16 September 2005 23:34, Ciaran McCreesh wrote:
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=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
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
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 j
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 pa
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 th
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 bu
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
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 thing
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
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.
> | Secon
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
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 fir
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
On Sat, 2005-09-17 at 08:23 +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
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
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, wo
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
> | stabiliza
* Nick Rout <[EMAIL PROTECTED]> [05/09/17 08:23 +1200]:
> 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 fil
Ciaran McCreesh wrote:
Plus for stuff like gcc, it's very much an arch decision, not a package
maintainer decision.
gcc was just the first example which came to my mind -- you can replace it with
every other big piece of software that needs more testing than just 30 days. Or
the other way aro
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
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 t
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
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 th
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/f
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? I
On Fri, 2005-09-16 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 th
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
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
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. When you e.g.
have upstream devs following the maxim "release early an
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
On Friday 16 September 2005 21:34, 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/feat
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 b
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 pa
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
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
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 a
On Fri, 2005-09-16 at 20:48 +0200, Paul de Vrieze wrote:
> On Friday 16 September 2005 20:38, Ciaran McCreesh wrote:
> > 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 pa
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: th
On Friday 16 September 2005 20:38, Ciaran McCreesh wrote:
> 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 hand
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
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.
-
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 ...
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
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 Po
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
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?
--
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/Free
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
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 manpa
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'
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 T
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
* Po
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?
--
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org
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 commodi
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 c
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
--
g
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
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 ot
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
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
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 p
73 matches
Mail list logo
