* Jacob Godserv schrieb:
> On Tue, 17 Aug 2010 19:04:03 +0200
> Enrico Weigelt wrote:
>
> > Meanwhile I've reworked my Briegel buildsystem [1] to support
> > direct git checkouts (including a repo cache). Next step will be
> > a mechanism to check tag signatures.
>
> You have a footnote, but no
On Tue, 17 Aug 2010 19:04:03 +0200
Enrico Weigelt wrote:
> Meanwhile I've reworked my Briegel buildsystem [1] to support
> direct git checkouts (including a repo cache). Next step will be
> a mechanism to check tag signatures.
You have a footnote, but no link, and I'm curious. :)
--
Jacob
* Brian Harring schrieb:
> > hmm, I'm exclusively using bzip2 and never had these problems
> > yet. maybe it depends on the compressor type.
>
> http://www.gentoo.org/proj/en/glep/glep-0025.html#the-problem-in-detail
>
> Note also that bzip2 had another change in output after that
> release- m
* Ciaran McCreesh schrieb:
> PHP and mplayer both have 100 USE flags. There's not enough
> CPU power in the world.
We don't have to try *all* possible combinations, but only those
differing in interfaces (eg. if some libfoo changes its exported
interface on a userflag, the clients have to be bu
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 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 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
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, 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
* 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
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 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 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
* 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
* 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
* 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
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
* 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
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
On Sat, 26 Jun 2010 21:57:33 +0200
Enrico Weigelt 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 wi
On Sat, 2010-06-26 at 21:46 +0200, Enrico Weigelt wrote:
> BTW: if upstream has an proper VCS and an canonical tagging
> scheme, they don't actually have to create release tarballs,
> just hack up a little script which creates them on-the-fly
> from an canonical URL scheme (eg. oss-qm does exactl
On Sun, Jun 27, 2010 at 1:29 AM, Ciaran McCreesh
wrote:
> On Sat, 26 Jun 2010 21:46:39 +0200
> Enrico Weigelt wrote:
>> BTW: if upstream has an proper VCS and an canonical tagging
>> scheme, they don't actually have to create release tarballs,
>> just hack up a little script which creates them on
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
compression program will always produce the same
* Krzysztof Pawlik schrieb:
> > Down that path lies madness. There's no guarantee that you'll get the
> > same tarball if you request the same URL twice in a row, particularly
> > if you're using one of those new-fangled new compression schemes.
>
> I agree with Ciaran here, to add one more thin
* Ciaran McCreesh schrieb:
> On Sat, 26 Jun 2010 21:46:39 +0200
> Enrico Weigelt wrote:
> > BTW: if upstream has an proper VCS and an canonical tagging
> > scheme, they don't actually have to create release tarballs,
> > just hack up a little script which creates them on-the-fly
> > from an cano
On Sat, 26 Jun 2010 21:57:33 +0200
Enrico Weigelt wrote:
> > Uhm. No. Certain compilers will give you warnings for f(g(a), g(b))
> > if you -Wall.
>
> Warn on what exactly ?
That f's arguments are evaluated in an unspecified order.
> Which compilers do that ?
For all you know, gcc 4.7.
New gc
On 06/26/10 20:59, Ciaran McCreesh wrote:
> On Sat, 26 Jun 2010 21:46:39 +0200
> Enrico Weigelt wrote:
>> BTW: if upstream has an proper VCS and an canonical tagging
>> scheme, they don't actually have to create release tarballs,
>> just hack up a little script which creates them on-the-fly
>> fr
* Ciaran McCreesh schrieb:
> On Sat, 26 Jun 2010 21:39:15 +0200
> Enrico Weigelt 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.
On Sat, 26 Jun 2010 21:46:39 +0200
Enrico Weigelt wrote:
> BTW: if upstream has an proper VCS and an canonical tagging
> scheme, they don't actually have to create release tarballs,
> just hack up a little script which creates them on-the-fly
> from an canonical URL scheme (eg. oss-qm does exactl
* Krzysztof Pawlik schrieb:
> > Hmm, this document suggests something, I just forgot to prohibit:
> >
> > "Release the source archives along with whatever binary archives you may
> > have."
> > ^
>
> You intend to "prohibit" relea
On Sat, 26 Jun 2010 21:39:15 +0200
Enrico Weigelt 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 will give you warnings
* Petteri Räty schrieb:
> There should be useful stuff here:
> http://video.fosdem.org/2010/devrooms/distributions/How_to_be_a_good_upstream.ogv
#1 he says nothing about that - if upstream has a VCS (and properly
uses it ;-o) - the distros should use it, so eg. set their branches
ontop the ups
On 06/26/10 19:51, Enrico Weigelt wrote:
> * Krzysztof Pawlik schrieb:
>
>> Take a look at this page:
>> http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream - it is
>> Java
>> specific mostly, but some general points can be reused :)
>
> Hmm, this document suggests something, I
* Alistair Bush schrieb:
> Is this language specific?
I'll try to separate it into generic and language specific
rules step by step (same for various build systems, etc).
> would you be interested in comments about java, ruby, python,
> etc, etc, etc or are you only interested in good old C
* Krzysztof Pawlik schrieb:
> Take a look at this page:
> http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream - it is
> Java
> specific mostly, but some general points can be reused :)
Hmm, this document suggests something, I just forgot to prohibit:
"Release the source archive
On 06/25/2010 11:17 PM, Enrico Weigelt wrote:
>
> Hi folks,
>
>
> I'm currently collecting a set of rules which upstream developers
> should follow to make distro maintainer's life easier.
>
> Comments welcomed :)
>
There should be useful stuff here:
http://video.fosdem.org/2010/devrooms/dis
On 06/25/10 21:17, Enrico Weigelt wrote:
> I'm currently collecting a set of rules which upstream developers
> should follow to make distro maintainer's life easier.
>
> Comments welcomed :)
Take a look at this page:
http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream - it is Java
> Hi folks,
>
>
> I'm currently collecting a set of rules which upstream developers
> should follow to make distro maintainer's life easier.
>
> Comments welcomed :)
>
Is this language specific? would you be interested in comments about java,
ruby, python, etc, etc, etc or are you only inter
Hi folks,
I'm currently collecting a set of rules which upstream developers
should follow to make distro maintainer's life easier.
Comments welcomed :)
cu
--
-
Enrico Weigelt== metux IT service - http://www.metux.de/
40 matches
Mail list logo
