On Sat, 26 Jun 2010 21:57:33 +0200
Enrico Weigelt weig...@metux.de wrote:
#2 One point i don't agree is the dont add -Werror rule. actually,
i'm thinking of making -Wall and -Werror mandatory. if some
package doenst build fine, it's simply broken. period.
Uhm. No. Certain compilers
Le 26/06/2010 21:39, Enrico Weigelt a écrit :
#2 One point i don't agree is the dont add -Werror rule. actually,
i'm thinking of making -Wall and -Werror mandatory. if some
package doenst build fine, it's simply broken. period.
You're obviously new here...
Just take a stroll through bugzilla
* Nirbheek Chauhan nirbh...@gentoo.org schrieb:
Or if they generate the tarball on-the-fly with no caching, which
results in differing timestamps each time. Hence, each time you fetch
it, you get a tarball with a different hash.
Does portage check the timestamps ?
cu
--
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
On Sat, 26 Jun 2010 22:09:09 +0200
Enrico Weigelt weig...@metux.de wrote:
Well, with git this works. (I'll yet have to run some automatic
stress tests, but at all my manual tests worked really fine).
You assume that, given the same
On Sun, 27 Jun 2010 12:34:44 +0200
Enrico Weigelt weig...@metux.de wrote:
You assume that, given the same input and program options, a
compression program will always produce the same output. This is not
the case.
Well, at least for tar, I've experienced no problem here yet.
But: true,
* Nikos Chantziaras rea...@arcor.de schrieb:
Did it actually occur to anyone that warnings are not errors? You can
have them for correct code. A warning means you might want to look at
the code to check whether there's some real error there. It doesn't
mean the code is broken.
In my
* Sergei Trofimovich sly...@gentoo.org schrieb:
I suggest you to try latest available dev-lang/icc (11.1.072).
This thing is really paranoid:
remark #2259: non-pointer conversion from int to unsigned char may lose
significant bits
unsigned char BlinkerPhase = 0;
...
* Rémi Cardona r...@gentoo.org schrieb:
We currently offer 11 different slots of GCC, 3 of gcc-apple, each with
multiple versions, 3 versions of llvm-gcc, 2 versions of clang, 7
versions of icc, so in all 26 *major* versions. You do well know that
each compiler prints out different warnings
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
Well, at least for tar, I've experienced no problem here yet.
But: true, it might change between tar versions.
The main offender is the compression program, not tar.
hmm, I'm exclusively using bzip2 and never had these problems
On Sun, 27 Jun 2010 13:08:58 +0200
Enrico Weigelt weig...@metux.de wrote:
Well, at least for tar, I've experienced no problem here yet.
But: true, it might change between tar versions.
The main offender is the compression program, not tar.
hmm, I'm exclusively using bzip2 and never
On 06/27/2010 06:52 AM, Enrico Weigelt wrote:
remark #981: operands are evaluated in unspecified order (tons of them)
return strcmp( left.c_str(), right.c_str() ) 0;
I'm not sure if this really qualifies an warning, since - AFAIK -
C spec never said, that there is an evaluation order
On 06/27/2010 01:47 PM, Enrico Weigelt wrote:
* Nikos Chantziarasrea...@arcor.de schrieb:
Did it actually occur to anyone that warnings are not errors? You can
have them for correct code. A warning means you might want to look at
the code to check whether there's some real error there. It
On 06/27/10 13:02, Enrico Weigelt wrote:
[snip]
We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions
of klibc. Each version may have header bugs, so may trigger warnings for
perfectly good code.
Well, if there're header bugs, shouldn't they get fixed before these
libs
On Sun, Jun 27, 2010 at 02:56:33PM +0300, Nikos Chantziaras wrote:
On 06/27/2010 01:47 PM, Enrico Weigelt wrote:
* Nikos Chantziarasrea...@arcor.de schrieb:
Did it actually occur to anyone that warnings are not errors? You can
have them for correct code. A warning means you might want
* Harald van D??k true...@gentoo.org schrieb:
The compiler is not totally free to ignore the register keyword. Both
the C and the C++ standards require that the compiler complain when
taking the address of a register variable. Other compilers will issue a
hard error for it. Fixing the code to
On Sun, 27 Jun 2010 14:22:53 +0200
Enrico Weigelt weig...@metux.de wrote:
Maybe it's time for a distributed build project: a generic container
image, which gets distributed to dozens of machines and runs build
tests coordinated by some server ... a bit like s...@home ;-)
Enough CPU is
On Sun, 27 Jun 2010 14:25:39 +0200
Enrico Weigelt weig...@metux.de wrote:
hmm, is there a (portable) way to prevent a specific warning
in an specific place ? (some kind of #pragma ?)
No.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On 06/27/2010 03:23 PM, Harald van Dijk wrote:
On Sun, Jun 27, 2010 at 02:56:33PM +0300, Nikos Chantziaras wrote:
On 06/27/2010 01:47 PM, Enrico Weigelt wrote:
* Nikos Chantziarasrea...@arcor.de schrieb:
Did it actually occur to anyone that warnings are not errors?
You can have them for
Hi
As many of you have already noticed, there are some arches that are quite
slow on stabilizations. This leads to deprecated stabilizations e.g a
package is stabilized after 60 days which makes that version of
the specific package obsolete and not worth to stabilize anymore.
I would suggest to
On 06/27/10 17:04, Markos Chandras wrote:
[snip]
Whilst I do understand that these arches are understaffed and they can't keep
up with the increased stabilization load like x86/amd64 do, I still
think that slow stabilization leads to an obsolete stable tree which I
doesn't make sense to me
On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
Moreover, slow arches introduce another problem as well. If a package is
marked stabled for their arch, but this package is quite old, and they fail to
stabilize a new version, we ( as maintainers ) can't drop the very old
( and
On Sun, Jun 27, 2010 at 11:47:49AM -0400, Olivier Crête wrote:
On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
Moreover, slow arches introduce another problem as well. If a package is
marked stabled for their arch, but this package is quite old, and they fail
to
stabilize a new
On 06/27/2010 06:47 PM, Olivier Crête wrote:
On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
Moreover, slow arches introduce another problem as well. If a package is
marked stabled for their arch, but this package is quite old, and they fail
to
stabilize a new version, we ( as
On Sun, 27 Jun 2010 18:04:45 +0300
Markos Chandras hwoar...@gentoo.org wrote:
Whilst I do understand that these arches are understaffed and they
can't keep up with the increased stabilization load like x86/amd64
do, I still think that slow stabilization leads to an obsolete stable
tree which I
On Sun, Jun 27, 2010 at 5:04 PM, Markos Chandras hwoar...@gentoo.org wrote:
Thoughts?
If Gentoo doesn't seem to have time to maintain the stable tree, why
have it in the first place? What really is the advantage of having a
stable tree?
On Sun, Jun 27, 2010 at 05:46:28PM +0300, Nikos Chantziaras wrote:
On 06/27/2010 03:23 PM, Harald van Dijk wrote:
The compiler is not totally free to ignore the register keyword.
Both the C and the C++ standards require that the compiler complain
when taking the address of a register
On Sun, Jun 27, 2010 at 06:53:56PM +0200, Auke Booij wrote:
On Sun, Jun 27, 2010 at 5:04 PM, Markos Chandras hwoar...@gentoo.org wrote:
Thoughts?
If Gentoo doesn't seem to have time to maintain the stable tree, why
have it in the first place? What really is the advantage of having a
stable
On Sun, Jun 27, 2010 at 05:38:34PM +0100, Ciaran McCreesh wrote:
On Sun, 27 Jun 2010 18:04:45 +0300
Markos Chandras hwoar...@gentoo.org wrote:
Whilst I do understand that these arches are understaffed and they
can't keep up with the increased stabilization load like x86/amd64
do, I still
On Sun, 27 Jun 2010 20:22:33 +0300
Markos Chandras hwoar...@gentoo.org wrote:
Which does Gentoo care about more: slightly increased convenience
for most developers, or considerably increased inconvenience for
users of minority archs?
I don't follow you. Increased convenience just for the
On 06/27/2010 08:14 PM, Harald van Dijk wrote:
On Sun, Jun 27, 2010 at 05:46:28PM +0300, Nikos Chantziaras wrote:
On 06/27/2010 03:23 PM, Harald van Dijk wrote:
The compiler is not totally free to ignore the register keyword.
Both the C and the C++ standards require that the compiler complain
On Sun, Jun 27, 2010 at 06:43:30PM +0100, Ciaran McCreesh wrote:
Which is the decision to make: make things very difficult for minority
arch users, who get screwed over royally every time keywords are
dropped, or make things slightly more inconvenient for developers, who
have to keep some
2010-06-27 17:04:45 Markos Chandras napisał(a):
Hi
As many of you have already noticed, there are some arches that are quite
slow on stabilizations. This leads to deprecated stabilizations e.g a
package is stabilized after 60 days which makes that version of
the specific package obsolete
On Sun, Jun 27, 2010 at 08:48:25PM +0300, Nikos Chantziaras wrote:
...
It is allowed. Section 7.1.1, Paragraphs 2 and 3 of the C++ standard:
...
Not in C.
ISO/IEC 9899:1999 (aka C99), section 6.7.1, note 101:
The implementation may treat any register declaration simply as an auto
On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras hwoar...@gentoo.org wrote:
What? I am talking about exotic arches and I didn't say to drop to
entire stable tree. Just to shrink it in order to keep it up to date
more easily
But my question stands: what really is the advantage of having a
stable
On Sun, 27 Jun 2010 19:01:13 +0100
Markos Chandras hwoar...@gentoo.org wrote:
Please explain me why keeping foobar-1.0 ( Released in 10/12/2009 ) is
in favor of a ppc64 stable user when amd64/x86 has foobar-2.1.3 (
Released 60 days ago ) already stabled for them
Because it's known to work.
On Sun, 2010-06-27 at 18:54 +0300, Markos Chandras wrote:
On Sun, Jun 27, 2010 at 11:47:49AM -0400, Olivier Crête wrote:
On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
Moreover, slow arches introduce another problem as well. If a package is
marked stabled for their arch, but
On 06/27/2010 09:10 PM, dev-ran...@mail.ru wrote:
On Sun, Jun 27, 2010 at 08:48:25PM +0300, Nikos Chantziaras wrote:
...
It is allowed. Section 7.1.1, Paragraphs 2 and 3 of the C++ standard:
...
Not in C.
ISO/IEC 9899:1999 (aka C99), section 6.7.1, note 101:
The implementation may treat any
On Sun, Jun 27, 2010 at 01:08:58PM +0200, Enrico Weigelt wrote:
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
Well, at least for tar, I've experienced no problem here yet.
But: true, it might change between tar versions.
The main offender is the compression program, not
On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
As many of you have already noticed, there are some arches that are quite
slow on stabilizations. This leads to deprecated stabilizations e.g a
package is stabilized after 60 days which makes that version of
the specific package
On Sun, 2010-06-27 at 17:45 +0200, Patrick Lauer wrote:
If possible I think we should try to keep stable keywords. So how can we
help? I'm not sure how I could help e.g. PPC - I don't have any hardware
I can test on, and I'm not aware of remotely accessible dev boxen.
There are options, an
On 06/27/10 20:33, Brian Harring wrote:
On Sun, Jun 27, 2010 at 01:08:58PM +0200, Enrico Weigelt wrote:
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
Well, at least for tar, I've experienced no problem here yet.
But: true, it might change between tar versions.
The main offender
On Sun, Jun 27, 2010 at 07:37:39PM +0100, Tony Chainsaw Vroon wrote:
On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
As many of you have already noticed, there are some arches that are quite
slow on stabilizations. This leads to deprecated stabilizations e.g a
package is
On Sun, Jun 27, 2010 at 08:15:32PM +0200, Auke Booij wrote:
On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras hwoar...@gentoo.org wrote:
What? I am talking about exotic arches and I didn't say to drop to
entire stable tree. Just to shrink it in order to keep it up to date
more easily
But my
On Sun, Jun 27, 2010 at 02:21:13PM -0400, Olivier Crête wrote:
That's ok. That way those users will know that no one from the arch team
maintains that packages and they will know it has a lower level of QA.
And the users will be able to make a choice. Instead of pretending that
it is
On Sun, 27 Jun 2010 22:55:42 +0300
Markos Chandras hwoar...@gentoo.org wrote:
Oh come on. I never said to stop supporting those arches. I just said
to shrink their stable tree. What do you suggest? Pretend to have
active exotic arches just to look shiny and pretty?
Claiming to support an
On Sun, Jun 27, 2010 at 09:01:55PM +0100, Ciaran McCreesh wrote:
On Sun, 27 Jun 2010 22:55:42 +0300
Markos Chandras hwoar...@gentoo.org wrote:
Oh come on. I never said to stop supporting those arches. I just said
to shrink their stable tree. What do you suggest? Pretend to have
active
On Sun, Jun 27, 2010 at 8:34 PM, Markos Chandras hwoar...@gentoo.org wrote:
As many of you have already noticed, there are some arches that are quite
slow on stabilizations. This leads to deprecated stabilizations e.g a
package is stabilized after 60 days which makes that version of
the
On Sun, Jun 27, 2010 at 4:05 PM, Enrico Weigelt weig...@metux.de wrote:
* Nirbheek Chauhan nirbh...@gentoo.org schrieb:
Or if they generate the tarball on-the-fly with no caching, which
results in differing timestamps each time. Hence, each time you fetch
it, you get a tarball with a
On Mon, Jun 28, 2010 at 01:59:42AM +0530, Nirbheek Chauhan wrote:
I'm saying that a 30 days rule is too strict for most packages and
herds. I don't think such a rule will fly very far. Even a 90 day rule
or a 6 month rule is too strict for GNOME packages. I personally
empathize with the
On Mon, Jun 28, 2010 at 3:08 AM, Markos Chandras hwoar...@gentoo.org wrote:
On Mon, Jun 28, 2010 at 01:59:42AM +0530, Nirbheek Chauhan wrote:
Now *this* is a problem. We have some bugs, some security bugs that
have been completely ignored by some arches. Mips as usual is one, but
recently hppa
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2010-06-27 23h59 UTC.
Removals:
dev-util/tkcvs 2010-06-21 09:59:20 jlec
dev-util/subversion 2010-06-22 18:18:38 arfrever
net-misc/neon
Hello everyone,
I'm sure at least half of you are thinking Oh no, not this again...,
and I agree. However, I'm /also/ thinking Why the heck haven't we
done this yet?
We've been discussing this since 2008, and probably waaay before that
too. The entire discussion about whether we should do this
On Sun, 27 Jun 2010 11:47:49 -0400
Olivier Crête tes...@gentoo.org wrote:
I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and
then just drop the old ebuild. These arches will slowly lose stable
keywords until their stable tree gets to a size that they can manage.
And everyone
53 matches
Mail list logo
