On Tue, 2009-11-24 at 10:25:59 +, Neil Williams wrote:
On Sat, 21 Nov 2009 03:01:06 +0100
Guillem Jover guil...@debian.org wrote:
Well, IMO any program implementing .deb extraction w/o using something
like --fsys-tarfile, --extract or --control from dpkg-deb (until we
have the upcoming
On Sat, 28 Nov 2009 22:25:31 +0100
Guillem Jover guil...@debian.org wrote:
On Tue, 2009-11-24 at 10:25:59 +, Neil Williams wrote:
On Sat, 21 Nov 2009 03:01:06 +0100
Guillem Jover guil...@debian.org wrote:
Well, IMO any program implementing .deb extraction w/o using something
like
On Sat, 2009-11-28 at 22:31:29 +, Neil Williams wrote:
On Sat, 28 Nov 2009 22:25:31 +0100 Guillem Jover wrote:
On Tue, 2009-11-24 at 10:25:59 +, Neil Williams wrote:
I'll update deb-gview for its next release, although I'll need some
real packages using data.tar.bz2 before I can
On Sun, 29 Nov 2009 00:13:14 +0100
Guillem Jover guil...@debian.org wrote:
On Sat, 2009-11-28 at 22:31:29 +, Neil Williams wrote:
On Sat, 28 Nov 2009 22:25:31 +0100 Guillem Jover wrote:
On Tue, 2009-11-24 at 10:25:59 +, Neil Williams wrote:
I'll update deb-gview for its next
On Sat, 21 Nov 2009 03:01:06 +0100
Guillem Jover guil...@debian.org wrote:
On Sun, 2009-11-15 at 22:22:52 +, Neil Williams wrote:
On Sun, 15, Nov, 2009 at 02:37:56PM -0500, Joey Hess spoke thus..
Note that debootstrap does not support data.tar.bz2.
ar -p ./$pkg data.tar.gz
On Wed, Nov 18, 2009 at 11:14:29PM +0900, Charles Plessy wrote:
You are member of the technical comittee, which means that I should trust
your experience. I want you and this list to understand that I take your
advice to orphan my packages very seriously.
Well, that's unfortunate, because
On Sun, Nov 22 2009, Steve Langasek wrote:
On Wed, Nov 18, 2009 at 11:14:29PM +0900, Charles Plessy wrote:
You are member of the technical comittee, which means that I should trust
your experience. I want you and this list to understand that I take your
advice to orphan my packages very
Am 15.11.2009 16:15, schrieb Joerg Jaspert:
multiple outstanding and intrusive patches got merged. We also discussed
various outstanding topics, a few of which we can report about already,
a few others where we still have to gather more information. This
process, either asking our lawyers or
Hi!
On Sun, 2009-11-15 at 22:22:52 +, Neil Williams wrote:
On Sun, 15, Nov, 2009 at 02:37:56PM -0500, Joey Hess spoke thus..
Note that debootstrap does not support data.tar.bz2.
debootstrap-1.0.20/functions: extract
progress $p $# EXTRACTPKGS Extracting packages
On 2009-11-19, Luk Claes l...@debian.org wrote:
This could only work if the built package is needed on the same buildd
it was built.
That depends on the assumptions. If the assumption is that the buildds are
trusted (the same as for autosigning) it would also be easy to argue that
setting up
On Thu, Nov 19, 2009 at 05:52:21AM +0100, Goswin von Brederlow wrote:
And then someone comes along and builds a Supercomputer cluster out of
game consoles.
Well, it *might be* that *someone* does this or that. But didn't we say
we give priority to our user_s_ (mind the plural). So for the
On 2009-11-19, Mike Hommey m...@glandium.org wrote:
On Wed, Nov 18, 2009 at 11:16:41PM +, Sune Vuorela wrote:
On 2009-11-18, Gerfried Fuchs rho...@deb.at wrote:
I am a bit confused with respect to how buildd autosigning is required
for this. It makes it sound somehow like it would
* Felipe Sateler fsate...@gmail.com [091118 23:39]:
You apparently fail to see that building the packages on mips uncovers
bugs that would otherwise be there, but take a longer time to uncover on
the 'mainstream' platforms.
This is not generally true. There are are classes of bugs that appear
Andreas Tille andr...@an3as.eu writes:
On Thu, Nov 19, 2009 at 05:52:21AM +0100, Goswin von Brederlow wrote:
And then someone comes along and builds a Supercomputer cluster out of
game consoles.
Well, it *might be* that *someone* does this or that. But didn't we say
we give priority to our
Luk Claes l...@debian.org writes:
Goswin von Brederlow wrote:
Sune Vuorela nos...@vuorela.dk writes:
On 2009-11-18, Gerfried Fuchs rho...@deb.at wrote:
I am a bit confused with respect to how buildd autosigning is required
for this. It makes it sound somehow like it would affect porter
Philipp Kern tr...@philkern.de writes:
On 2009-11-19, Luk Claes l...@debian.org wrote:
This could only work if the built package is needed on the same buildd
it was built.
That depends on the assumptions. If the assumption is that the buildds are
trusted (the same as for autosigning) it
On 2009-11-19, Goswin von Brederlow goswin-...@web.de wrote:
This could only work if the built package is needed on the same buildd
it was built.
What part of require some coordination with wanna-build did you not read?
Well, maybe because wanna-build wouldn't be involved except for an updated
Goswin von Brederlow wrote:
Philipp Kern tr...@philkern.de writes:
On 2009-11-19, Luk Claes l...@debian.org wrote:
This could only work if the built package is needed on the same buildd
it was built.
That depends on the assumptions. If the assumption is that the buildds are
trusted (the
Luk Claes l...@debian.org writes:
Goswin von Brederlow wrote:
Philipp Kern tr...@philkern.de writes:
On 2009-11-19, Luk Claes l...@debian.org wrote:
This could only work if the built package is needed on the same buildd
it was built.
That depends on the assumptions. If the assumption is
Luk Claes a écrit :
Charles Plessy wrote:
Le Tue, Nov 17, 2009 at 08:27:22AM +0100, Yves-Alexis Perez a écrit :
Unless your proposal is just for unstable but doesn't want to change the
policy for testing migration?
Hi,
Testing migration works the way it should: if a package is never built
On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
I don't think it's good to waste buildd time on failing to build packages.
I also don't think anyone is stopped from setting up a service that
allows source-only uploads as a go-between.
Do you mean set up an unofficial upload queue
On Wed, Nov 18, 2009 at 08:47:33AM +0100, Jean-Christophe Dubacq wrote:
If your package FTBFS on some architecture, then that is a bug. A bug
that was already there, it just was not noticed yet. In most cases the
bug is rather easy to fix, even for non porters as most of the
architecture
On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
I think one would be surprised how many packages get used on 'exotic'
architectures. Most users don't specifically search for a piece of
software, they want to have some specific task done by using a specific
package. Not providing
On 2009-11-18, Andreas Tille andr...@an3as.eu wrote:
Well, I do not think that you can do gene sequencing or number crunching
on current mobile phones. So there are really programs which are not
needed on all architectures and even if you find a binary package which
claims to do the job it is
Hi!
First of all, thanks for this great roundup. There are just some few
questions that popped up in my mind that I hope haven't asked yet
(wasn't able to check all the responses completely ...). Sorry if there
are duplications, a reference to the answer for easier tracking would be
Le Wed, Nov 18, 2009 at 12:42:47AM -0600, Manoj Srivastava a écrit :
I beg to differ. This sounds like a maintainer that is not
providing the support for their package, and needs to orphan that
package; not building on some architecture is often a symptom of
problems elsewhere as
Le Wed, Nov 18, 2009 at 10:54:18AM +, Philipp Kern a écrit :
there might not be clusters of arm yet but I saw offers for clusters of mips.
Hi Philipp
I also saw this cluster and got quite curious until I realised that most
programs I package are not parallelised…
The day we are contacted
On Wed, Nov 18 2009, Charles Plessy wrote:
Le Wed, Nov 18, 2009 at 12:42:47AM -0600, Manoj Srivastava a écrit :
I beg to differ. This sounds like a maintainer that is not
providing the support for their package, and needs to orphan that
package; not building on some architecture
On Wed, Nov 18 2009, Clint Adams wrote:
On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
I don't think it's good to waste buildd time on failing to build packages.
I also don't think anyone is stopped from setting up a service that
allows source-only uploads as a go-between.
Do
On Wed, Nov 18, 2009 at 11:40:52PM +0900, Charles Plessy wrote:
If we mean to attract such users, I do not think that the best strategy would
necessarly be having a pre-existing MIPS support of bioinformatics, which I
think is completely beyond our reach and expertise. I think that what would
Andreas Tille wrote:
On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
I think one would be surprised how many packages get used on 'exotic'
architectures. Most users don't specifically search for a piece of
software, they want to have some specific task done by using a specific
Clint Adams wrote:
On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
I don't think it's good to waste buildd time on failing to build packages.
I also don't think anyone is stopped from setting up a service that
allows source-only uploads as a go-between.
Do you mean set up an
Gerfried Fuchs wrote:
Hi!
First of all, thanks for this great roundup. There are just some few
questions that popped up in my mind that I hope haven't asked yet
(wasn't able to check all the responses completely ...). Sorry if there
are duplications, a reference to the answer for
Charles Plessy wrote:
Le Wed, Nov 18, 2009 at 10:54:18AM +, Philipp Kern a écrit :
there might not be clusters of arm yet but I saw offers for clusters of mips.
Hi Philipp
I also saw this cluster and got quite curious until I realised that most
programs I package are not
On Wed, Nov 18, 2009 at 08:18:57PM +0100, Luk Claes wrote:
There are architectures for different issues. There are issues which
allways need the fastest available architecture and there are other
needs which are targeting at low power consumption etc. We should
probably not put a large
Luk Claes wrote:
You apparently fail to see that building the packages on mips uncovers
bugs that would otherwise be there, but take a longer time to uncover on
the 'mainstream' platforms.
This is not generally true. There are are classes of bugs that appear on
different platforms _due to
On 2009-11-18, Felipe Sateler fsate...@gmail.com wrote:
This is not generally true. There are are classes of bugs that appear on
different platforms _due to being different platforms_, not just because
they were latent bugs waiting to be discovered. I presume that packages
that require as much
On 2009-11-18, Gerfried Fuchs rho...@deb.at wrote:
I am a bit confused with respect to how buildd autosigning is required
for this. It makes it sound somehow like it would affect porter binary
Basicalyl, the turnaround time is too long if we have to wait for manual
buildd signings.
For
Le Wed, Nov 18, 2009 at 02:49:46PM +, Mark Brown a écrit :
The flip side of this is that it's just inviting maintainers to decide
they can't be bothered with porting effort and leaving ports as second
class citizens.
It seems that the trend this year is to not trust the maintainers for
On Wed, Nov 18 2009, Charles Plessy wrote:
Le Wed, Nov 18, 2009 at 02:49:46PM +, Mark Brown a écrit :
The flip side of this is that it's just inviting maintainers to
decide they can't be bothered with porting effort and leaving ports
as second class citizens.
It seems that the trend
(Note: I am not a porter, so please correct anything wrong I say
below)
On Thu, Nov 19, 2009 at 08:29:53AM +0900, Charles Plessy wrote:
How about the porters responsability towards the project ? For instance, hppa
is blocking the testing migration of a couple of my packages, and probably the
Andreas Tille andr...@an3as.eu writes:
On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
I think one would be surprised how many packages get used on 'exotic'
architectures. Most users don't specifically search for a piece of
software, they want to have some specific task done by
Felipe Sateler fsate...@gmail.com writes:
Luk Claes wrote:
You apparently fail to see that building the packages on mips uncovers
bugs that would otherwise be there, but take a longer time to uncover on
the 'mainstream' platforms.
This is not generally true. There are are classes of bugs
Sune Vuorela nos...@vuorela.dk writes:
On 2009-11-18, Gerfried Fuchs rho...@deb.at wrote:
I am a bit confused with respect to how buildd autosigning is required
for this. It makes it sound somehow like it would affect porter binary
Basicalyl, the turnaround time is too long if we have to
On Mon, 16 Nov 2009, Steffen Joeris wrote:
On Mon, 16 Nov 2009 02:04:28 pm Carlo Segre wrote:
On Sun, 15 Nov 2009, Joerg Jaspert wrote:
The current winning opinion is to go with the source+throw away
binaries route. We are close to being able to achieve this, it is
simply that it has not yet
Goswin von Brederlow wrote:
Sune Vuorela nos...@vuorela.dk writes:
On 2009-11-18, Gerfried Fuchs rho...@deb.at wrote:
I am a bit confused with respect to how buildd autosigning is required
for this. It makes it sound somehow like it would affect porter binary
Basicalyl, the turnaround time
On Wed, Nov 18, 2009 at 11:16:41PM +, Sune Vuorela wrote:
On 2009-11-18, Gerfried Fuchs rho...@deb.at wrote:
I am a bit confused with respect to how buildd autosigning is required
for this. It makes it sound somehow like it would affect porter binary
Basicalyl, the turnaround time is
On Tue, 17 Nov 2009, Charles Plessy wrote:
To save everybody's time, I proposed earlier in this month's discussion to not
report the build failures in our bug tracking system unless there is an
interest
from the porters or from the package maintainers to make the package available
in the
Le Tue, Nov 17, 2009 at 08:27:22AM +0100, Yves-Alexis Perez a écrit :
Unless your proposal is just for unstable but doesn't want to change the
policy for testing migration?
Hi,
Testing migration works the way it should: if a package is never built on an
architecture, testing migration is not
Charles Plessy ple...@debian.org writes:
Le Tue, Nov 17, 2009 at 08:27:22AM +0100, Yves-Alexis Perez a écrit :
Unless your proposal is just for unstable but doesn't want to change the
policy for testing migration?
Hi,
Testing migration works the way it should: if a package is never
Charles Plessy wrote:
Le Tue, Nov 17, 2009 at 08:27:22AM +0100, Yves-Alexis Perez a écrit :
Unless your proposal is just for unstable but doesn't want to change the
policy for testing migration?
Hi,
Testing migration works the way it should: if a package is never built on an
On Tue, Nov 17 2009, Charles Plessy wrote:
Le Tue, Nov 17, 2009 at 08:27:22AM +0100, Yves-Alexis Perez a écrit :
Unless your proposal is just for unstable but doesn't want to change the
policy for testing migration?
Hi,
Testing migration works the way it should: if a package is never
On Sun, Nov 15, 2009 at 04:15:35PM +0100, Joerg Jaspert wrote:
source-only uploads
---
After some discussion about this, there are two opinions within the
ftp-team about this matter. Given that other distros experience has
shown that allowing source only uploads results in a
On 2009-11-16, Simon Huggins hug...@earth.li wrote:
If you throw away the binaries, a DD can upload a binary package with a
sole binary that prints out banana and a source package that builds the
right thing presumably. Are there any checks to prevent that?
I'm trying to work out if you get
Philipp Kern tr...@philkern.de writes:
On 2009-11-16, Simon Huggins hug...@earth.li wrote:
If you throw away the binaries, a DD can upload a binary package with a
sole binary that prints out banana and a source package that builds the
right thing presumably. Are there any checks to prevent
On Mon, Nov 16, 2009 at 08:38:15AM +0100, Goswin von Brederlow wrote:
I'm not asserting that this problem is *not* significant, I simply don't
know - and am interested in knowing if anyone has more data on this beyond
some four-year-old anecdotes. Certainly, Debian with its wider range of
Hi,
On Mon, Nov 16, 2009 at 09:38:38AM -0600, Steve Langasek wrote:
requiring binary uploads ensures that the package has been build-tested
*somewhere* prior to upload, and avoids clogging up the buildds with
preventable failures (some of which will happen only at the end of the
build, which
Simon Richter wrote:
Hi,
On Mon, Nov 16, 2009 at 09:38:38AM -0600, Steve Langasek wrote:
requiring binary uploads ensures that the package has been build-tested
*somewhere* prior to upload, and avoids clogging up the buildds with
preventable failures (some of which will happen only at the
Goswin von Brederlow wrote:
Philipp Kern tr...@philkern.de writes:
On 2009-11-16, Simon Huggins hug...@earth.li wrote:
If you throw away the binaries, a DD can upload a binary package with a
sole binary that prints out banana and a source package that builds the
right thing presumably. Are
On Sun, Nov 15, 2009 at 07:44:18PM +0100, Sandro Tosi wrote:
snip
While I like the source + trow away solution, I'd also like to ask
you to please consider some methods to allow the throw away step on
the developer machine, for example having dput/dupload not upload the
.debs (so .changes
On Tue, Nov 17, 2009 at 00:36, Kevin Mark kevin.m...@verizon.net wrote:
On Sun, Nov 15, 2009 at 07:44:18PM +0100, Sandro Tosi wrote:
snip
While I like the source + trow away solution, I'd also like to ask
you to please consider some methods to allow the throw away step on
the developer
On Mon, 2009-11-16 at 09:38 -0600, Steve Langasek wrote:
I thought the nature of the problem was clear, but to be explicit:
requiring binary uploads ensures that the package has been build-tested
*somewhere* prior to upload, and avoids clogging up the buildds with
preventable failures (some
Steve Langasek vor...@debian.org writes:
On Mon, Nov 16, 2009 at 08:38:15AM +0100, Goswin von Brederlow wrote:
I'm not asserting that this problem is *not* significant, I simply don't
know - and am interested in knowing if anyone has more data on this beyond
some four-year-old anecdotes.
Le Mon, Nov 16, 2009 at 09:38:38AM -0600, Steve Langasek a écrit :
Debian only advances as fast as the slowest supported port
That is the key observation.
To save everybody's time, I proposed earlier in this month's discussion to not
report the build failures in our bug tracking system unless
On mar., 2009-11-17 at 14:07 +0900, Charles Plessy wrote:
Although it sounds a bit sillogical, if for some architectures we do not build
the packages that have no users, no user will complain. So why not ?
Well, I'm not really sure we can expect our user to follow unstable and
each and every
On Sunday 15 November 2009, Joerg Jaspert wrote:
dpkg v3 source format, compression
--
As many already noticed, our archive now additionally supports 3.0
(quilt) and 3.0 (native) source package formats. You can use either
gzip as usual or bzip2 for the
Frans Pop elen...@planet.nl wrote:
On Sunday 15 November 2009, Joerg Jaspert wrote:
dpkg v3 source format, compression
[...]
Is there a policy for the use of bzip2?
As discussed earlier bzip2 is *much* slower that gzip and really hurts on
slower arches and systems, so I'd suggest that -
Hello Joerg,
thanks for the updates.
On Sun, Nov 15, 2009 at 16:15, Joerg Jaspert jo...@ganneff.de wrote:
...
source-only uploads
---
After some discussion about this, there are two opinions within the
ftp-team about this matter. Given that other distros experience has
shown
Andreas Metzler wrote:
FWIW dpkg does the smart thing by default. It uses gzip (both
for the debian packages and and debian.tar) but searches for both
foo_42.orig.tar.bz2 and .gz. Explicitely passing an option is required
to get bz2 compression for binary packages and/or debian.tar.
Note that
Sandro Tosi mo...@debian.org writes:
Hello Joerg,
thanks for the updates.
On Sun, Nov 15, 2009 at 16:15, Joerg Jaspert jo...@ganneff.de wrote:
...
source-only uploads
---
After some discussion about this, there are two opinions within the
ftp-team about this matter.
On 2009-11-15, Goswin von Brederlow goswin-...@web.de wrote:
If Architecture: all is kept then maybe allow source+all uploads?
Those are already possible. If they're allowed is another question, though.
Kind regards,
Philipp Kern
--
To UNSUBSCRIBE, email to
On Sun, 15, Nov, 2009 at 02:37:56PM -0500, Joey Hess spoke thus..
Andreas Metzler wrote:
FWIW dpkg does the smart thing by default. It uses gzip (both
for the debian packages and and debian.tar) but searches for both
foo_42.orig.tar.bz2 and .gz. Explicitely passing an option is required
Joey Hess wrote:
cu and- happliy using v3 for gnutls -reas
Please avoid doing so for libtasn1-3.
Please ignore above; misread.
--
see shy jo
signature.asc
Description: Digital signature
Mark Hymers wrote:
I think there's some confusion here between source and binary formats.
The announcement was referring to bzip2 when used as part of a source
upload. As far as I can tell from looking in the git logs, dak has
supported data.tar.bz2 since 2005, so I'm surprised that this has
This one time, at band camp, Frans Pop said:
Mark Hymers wrote:
I think there's some confusion here between source and binary formats.
The announcement was referring to bzip2 when used as part of a source
upload. As far as I can tell from looking in the git logs, dak has
supported
Then can you (or someone else) please explain what exactly is meant by the
reference to bzip2 for binary packages in the following quote from the
original mail:
! You can use either gzip as usual or bzip2 for the compression within
! the binary packages - and now also for the source files.
On Sun, Nov 15, 2009 at 04:15:35PM +0100, Joerg Jaspert wrote:
Tracking arch all packages
--
#246992 asked us to not delete arch all packages before the
corresponding (if any) arch any packages are available for all
architectures. Example: whenever a new source
On Sun, 15 Nov 2009 19:53:02 +
Mark Hymers m...@debian.org wrote:
On Sun, 15, Nov, 2009 at 02:37:56PM -0500, Joey Hess spoke thus..
Andreas Metzler wrote:
FWIW dpkg does the smart thing by default. It uses gzip (both
for the debian packages and and debian.tar) but searches for both
On 11935 March 1977, Joerg Jaspert wrote:
NEW/Byhand
--
Due to the massive changes in the archive, NEW (and also Byhand) had to
be disabled. Certain assumptions made by the processing tools no longer
applied. The last week was used to work on this issue and we think this
will be
Le Sun, Nov 15, 2009 at 04:15:35PM +0100, Joerg Jaspert a écrit :
source-only uploads
Hi Jörg and all the FTP team,
fist of all, I want to say a big thank you for all this work. I have given
harsh comments for part of it, but I am really grateful for most.
I am curious on how the rebuild of
On 11936 March 1977, Charles Plessy wrote:
source-only uploads
I am curious on how the rebuild of the architecture-independant packages
happens.
That depends on what we get out with in the end.
Probably all buildds can build arch:all (so the buildd maintainer wants it),
and there will be a
On Sun, 15 Nov 2009, Joerg Jaspert wrote:
The current winning opinion is to go with the source+throw away
binaries route. We are close to being able to achieve this, it is
simply that it has not yet been enabled. Before any version of this
can be enabled, buildd autosigning needs to be
On Mon, 16 Nov 2009 02:04:28 pm Carlo Segre wrote:
On Sun, 15 Nov 2009, Joerg Jaspert wrote:
The current winning opinion is to go with the source+throw away
binaries route. We are close to being able to achieve this, it is
simply that it has not yet been enabled. Before any version of
Hello,
On Sun, Nov 15, 2009 at 04:15:35PM +0100, Joerg Jaspert wrote:
source-only uploads
---
After some discussion about this, there are two opinions within the
ftp-team about this matter. Given that other distros experience has
shown that allowing source only uploads
On Mon, Nov 16, 2009 at 12:48:53AM +0100, Joerg Jaspert wrote:
On 11936 March 1977, Charles Plessy wrote:
source-only uploads
I am curious on how the rebuild of the architecture-independant packages
happens.
That depends on what we get out with in the end.
Probably all buildds can
On Sun, 2009-11-15 at 19:29 -0600, Steve Langasek wrote:
I'm not asserting that this problem is *not* significant, I simply don't
know - and am interested in knowing if anyone has more data on this beyond
some four-year-old anecdotes. Certainly, Debian with its wider range of
ports is more
Steve Langasek vor...@debian.org writes:
Hello,
On Sun, Nov 15, 2009 at 04:15:35PM +0100, Joerg Jaspert wrote:
source-only uploads
---
After some discussion about this, there are two opinions within the
ftp-team about this matter. Given that other distros experience has
87 matches
Mail list logo
