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
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 -
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
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
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
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
--
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
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
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
*
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
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
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?
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
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
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
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
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, 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
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
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
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 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
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
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
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?
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
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
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
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
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
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 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
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
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,
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 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 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
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, 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)
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
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
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
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
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
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
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
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
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?
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: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: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 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
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
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
-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
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
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
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
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
-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
60 matches
Mail list logo
