* Jacob Godserv jacobgods...@gmail.com schrieb:
On Tue, 17 Aug 2010 19:04:03 +0200
Enrico Weigelt weig...@metux.de 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.
* Brian Harring ferri...@gmail.com 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
On Tue, 17 Aug 2010 19:04:03 +0200
Enrico Weigelt weig...@metux.de 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. :)
* Ciaran McCreesh ciaran.mccre...@googlemail.com 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
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,
* 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/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, 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, 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 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 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
* Krzysztof Pawlik nelch...@gentoo.org 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
* Alistair Bush ali_b...@gentoo.org 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
* Petteri Räty betelge...@gentoo.org 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
On Sat, 26 Jun 2010 21:39:15 +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 will give
* Krzysztof Pawlik nelch...@gentoo.org 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
On Sat, 26 Jun 2010 21:46:39 +0200
Enrico Weigelt weig...@metux.de 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.
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
On Sat, 26 Jun 2010 21:39:15 +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
On 06/26/10 20:59, Ciaran McCreesh wrote:
On Sat, 26 Jun 2010 21:46:39 +0200
Enrico Weigelt weig...@metux.de 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 Sat, 26 Jun 2010 21:57:33 +0200
Enrico Weigelt weig...@metux.de 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
* Krzysztof Pawlik nelch...@gentoo.org 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
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
On Sat, 26 Jun 2010 21:46:39 +0200
Enrico Weigelt weig...@metux.de 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
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 input and program options, a
compression program will always
On Sun, Jun 27, 2010 at 1:29 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Sat, 26 Jun 2010 21:46:39 +0200
Enrico Weigelt weig...@metux.de wrote:
BTW: if upstream has an proper VCS and an canonical tagging
scheme, they don't actually have to create release tarballs,
just hack
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 exactly
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/
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 interested
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
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:
37 matches
Mail list logo
