On Wed, 22 Jul 2009, Cyril Brulebois wrote:
Raphael Hertzog hert...@debian.org (17/07/2009):
At least dpkg-dev has one and it's run at build-time.
I thought the goal of dpkg-dev was to actually build other packages. I
don't know how dpkg-dev developers see this, but maybe having a few
Raphael Hertzog hert...@debian.org (17/07/2009):
At least dpkg-dev has one and it's run at build-time.
I thought the goal of dpkg-dev was to actually build other packages. I
don't know how dpkg-dev developers see this, but maybe having a few
packages rebuilt using the new dpkg-dev package would
On 2009-07-21, Goswin von Brederlow goswin-...@web.de wrote:
Philipp Kern tr...@philkern.de writes:
On 2009-07-20, Stéphane Glondu st...@glondu.net wrote:
For example, each OCaml transition involve rebuilding a lot of packages
(about 139), with 6 levels of dependencies. So if some build
On Tue, Jul 21, 2009 at 07:38:54AM +, Philipp Kern wrote:
On 2009-07-21, Goswin von Brederlow goswin-...@web.de wrote:
The long wait is the signing, not the dinstall run. Even without
accepted dinstall runs 4 times a day now.
But I have to say I'm totaly against unsigned uploads. The
Wouter Verhelst a écrit :
Ah, so this is about not interfering with testing migration, I guess?
It's not only testing migration. As an example: If you have a large chain
of binNMUs which all need some dep-wait on a package upper in the chain
you get the effect that the whole thing takes
On 2009-07-20, Stéphane Glondu st...@glondu.net wrote:
For example, each OCaml transition involve rebuilding a lot of packages
(about 139), with 6 levels of dependencies. So if some build takes 2
days or more (for the current transition, on some builds, it was even
more than a week) to be
Philipp Kern tr...@philkern.de writes:
On 2009-07-20, Stéphane Glondu st...@glondu.net wrote:
For example, each OCaml transition involve rebuilding a lot of packages
(about 139), with 6 levels of dependencies. So if some build takes 2
days or more (for the current transition, on some builds,
On Sat, Jul 18, 2009 at 03:45:13PM +, Philipp Kern wrote:
On 2009-07-18, Wouter Verhelst wou...@debian.org wrote:
Ah, so this is about not interfering with testing migration, I guess?
It's not only testing migration. As an example: If you have a large chain
of binNMUs which all need
On 2009-07-18, Wouter Verhelst wou...@debian.org wrote:
Ah, so this is about not interfering with testing migration, I guess?
It's not only testing migration. As an example: If you have a large chain
of binNMUs which all need some dep-wait on a package upper in the chain
you get the effect that
On Thu, Jul 16, 2009 at 10:57:25PM -0500, Peter Samuelson wrote:
[Michael Biebl]
Would it make sense to avoid the upload of obviously broken
packages from buildds in the future. E.g. if lintian detects an
error it would need some special inspection from the buildd uploader.
Don't all
Wouter Verhelst wrote:
On Thu, Jul 16, 2009 at 10:57:25PM -0500, Peter Samuelson wrote:
[Michael Biebl]
Would it make sense to avoid the upload of obviously broken
packages from buildds in the future. E.g. if lintian detects an
error it would need some special inspection from the buildd
On Fri, Jul 17, 2009 at 10:57:25AM +0200, Steffen Moeller
steffen_moel...@gmx.de wrote:
Wouter Verhelst wrote:
On Thu, Jul 16, 2009 at 10:57:25PM -0500, Peter Samuelson wrote:
[Michael Biebl]
Would it make sense to avoid the upload of obviously broken
packages from buildds in the future.
Mike Hommey wrote:
On Fri, Jul 17, 2009 at 10:57:25AM +0200, Steffen Moeller
steffen_moel...@gmx.de wrote:
Wouter Verhelst wrote:
On Thu, Jul 16, 2009 at 10:57:25PM -0500, Peter Samuelson wrote:
[Michael Biebl]
Would it make sense to avoid the upload of obviously broken
packages from
On Fri, Jul 17, 2009 at 11:19:50AM +0200, Steffen Moeller wrote:
Not? Was the originally uploaded package correct? Amazing. Hm. Then,
it should be lintian errors that denote a build as a failure, indeed,
and these should somehow be detected by the mechanism that uploads the
packages ... not by
Wouter Verhelst wrote:
On Fri, Jul 17, 2009 at 11:19:50AM +0200, Steffen Moeller wrote:
Not? Was the originally uploaded package correct? Amazing. Hm. Then,
it should be lintian errors that denote a build as a failure, indeed,
and these should somehow be detected by the mechanism that uploads
On Fri, Jul 17, 2009 at 11:44:54AM +0200, Luk Claes wrote:
Wouter Verhelst wrote:
On Fri, Jul 17, 2009 at 11:19:50AM +0200, Steffen Moeller wrote:
Not? Was the originally uploaded package correct? Amazing. Hm. Then,
it should be lintian errors that denote a build as a failure, indeed,
and
On 2009-07-17, Wouter Verhelst wou...@debian.org wrote:
AFAIK the FTP Team is working on a system to prevent uploads which
have lintian errors. The whole category of lintian errors has
already been assessed and possible overrides are planned to arrive
in the NEW queue at least once... Please
Wouter Verhelst wrote:
On Fri, Jul 17, 2009 at 11:44:54AM +0200, Luk Claes wrote:
Wouter Verhelst wrote:
On Fri, Jul 17, 2009 at 11:19:50AM +0200, Steffen Moeller wrote:
Not? Was the originally uploaded package correct? Amazing. Hm. Then,
it should be lintian errors that denote a build as a
Steffen Moeller steffen_moel...@gmx.de (17/07/2009):
Wouter's comment aside, checks at buildd level would be too late.
Yes, sure. It'd rather be time for critical packages (say: dpkg-dev,
debhelper, cdbs) to have proper non-regression testsuites.
Mraw,
KiBi.
signature.asc
Description: Digital
On Fri, 17 Jul 2009, Cyril Brulebois wrote:
Steffen Moeller steffen_moel...@gmx.de (17/07/2009):
Wouter's comment aside, checks at buildd level would be too late.
Yes, sure. It'd rather be time for critical packages (say: dpkg-dev,
debhelper, cdbs) to have proper non-regression testsuites.
On Fri, Jul 17, 2009 at 12:10:56PM +0200, Luk Claes wrote:
Wouter Verhelst wrote:
Right. However, having sbuild run lintian would allow a buildd
maintainer to assess issues with packages by looking at *warnings*,
rather than 'just' errors. This isn't something an automated system can
do.
Luk Claes l...@debian.org writes:
AFAIK the FTP Team is working on a system to prevent uploads which have
lintian errors. The whole category of lintian errors has already been
assessed and possible overrides are planned to arrive in the NEW queue
at least once... Please do note that I'm
Wouter Verhelst wrote:
On Fri, Jul 17, 2009 at 12:10:56PM +0200, Luk Claes wrote:
Wouter Verhelst wrote:
Right. However, having sbuild run lintian would allow a buildd
maintainer to assess issues with packages by looking at *warnings*,
rather than 'just' errors. This isn't something an
On Fri, Jul 17, 2009 at 09:05:29PM +0200, Luk Claes wrote:
Wouter Verhelst wrote:
On Fri, Jul 17, 2009 at 12:10:56PM +0200, Luk Claes wrote:
Wouter Verhelst wrote:
Right. However, having sbuild run lintian would allow a buildd
maintainer to assess issues with packages by looking at
Roger Leigh schrieb:
Some people may have recently been bitten by #537125.
This mail isn't about that bug in particular, though it did
certainly expose the fragility of systems depending upon dbus.
Blaming this on D-Bus is not fair. It could have happened to any other
package.
Heaven forbid
[Michael Biebl]
Would it make sense to avoid the upload of obviously broken
packages from buildds in the future. E.g. if lintian detects an
error it would need some special inspection from the buildd uploader.
Don't all buildd binary packages already need special inspection from
a buildd
26 matches
Mail list logo
