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 bugzi
* Nirbheek Chauhan 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 schrieb:
> On Sat, 26 Jun 2010 22:09:09 +0200
> Enrico Weigelt 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 input and program options, a
> compres
On Sun, 27 Jun 2010 12:34:44 +0200
Enrico Weigelt 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, it might
* Nikos Chantziaras 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 personal exper
* Sergei Trofimovich 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;
> ...
> BlinkerP
* Rémi Cardona 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 for the *same
* Ciaran McCreesh 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
yet. maybe it depends on the
On Sun, 27 Jun 2010 13:08:58 +0200
Enrico Weigelt 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 had th
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 f
On 06/27/2010 01:47 PM, Enrico Weigelt wrote:
* Nikos Chantziaras 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
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
>
On Sun, Jun 27, 2010 at 02:56:33PM +0300, Nikos Chantziaras wrote:
> On 06/27/2010 01:47 PM, Enrico Weigelt wrote:
> > * Nikos Chantziaras 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 lo
* Patrick Lauer schrieb:
> > Well, if there're header bugs, shouldn't they get fixed before these
> > libs are stabelized ? ;-O
>
> And there we have the thin line between actual bug and fuzzy
> specification. Sometimes things fail just because two people assumed
> something and thus the code di
* Harald van D??k 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 not declare th
On Sun, 27 Jun 2010 14:22:53 +0200
Enrico Weigelt 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 available all arou
On Sun, 27 Jun 2010 14:25:39 +0200
Enrico Weigelt 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 Chantziaras schrieb:
Did it actually occur to anyone that warnings are not errors?
You can have them for correct code. A wa
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 i
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 obso
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
> > stabili
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 (
On Sun, 27 Jun 2010 18:04:45 +0300
Markos Chandras 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 doesn't make se
On Sun, Jun 27, 2010 at 5:04 PM, Markos Chandras 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?
Le 27/06/2010 14:33, Ciaran McCreesh a écrit :
> On Sun, 27 Jun 2010 14:22:53 +0200
> Enrico Weigelt 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 li
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 v
On Sun, Jun 27, 2010 at 06:53:56PM +0200, Auke Booij wrote:
> On Sun, Jun 27, 2010 at 5:04 PM, Markos Chandras 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?
>
Wha
On Sun, Jun 27, 2010 at 05:38:34PM +0100, Ciaran McCreesh wrote:
> On Sun, 27 Jun 2010 18:04:45 +0300
> Markos Chandras 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 sl
On Sun, 27 Jun 2010 20:22:33 +0300
Markos Chandras 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 devs? How?
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
whe
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 som
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 obsole
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
> declar
On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras 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 tree, when you c
On Sun, 27 Jun 2010 19:01:13 +0100
Markos Chandras 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. That's the point of
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
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 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 e
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 obso
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 o
On 06/27/10 20:33, Brian Harring wrote:
> On Sun, Jun 27, 2010 at 01:08:58PM +0200, Enrico Weigelt wrote:
>> * Ciaran McCreesh 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 compr
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 sta
On Sun, Jun 27, 2010 at 08:15:32PM +0200, Auke Booij wrote:
> On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras 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 st
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 mai
On Sun, 27 Jun 2010 22:55:42 +0300
Markos Chandras 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 exotic arch but forcin
On Sun, Jun 27, 2010 at 09:01:55PM +0100, Ciaran McCreesh wrote:
> On Sun, 27 Jun 2010 22:55:42 +0300
> Markos Chandras 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 ju
On Sun, Jun 27, 2010 at 8:34 PM, 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 obsol
On Sun, Jun 27, 2010 at 4:05 PM, Enrico Weigelt wrote:
> * Nirbheek Chauhan 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 che
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 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 (and to a mu
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 thi
On Sun, 27 Jun 2010 11:47:49 -0400
Olivier Crête 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 will be winners
54 matches
Mail list logo
