On Wed, 22 Jul 2009, Cyril Brulebois wrote:
> Raphael Hertzog (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
Raphael Hertzog (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 help spotting
brea
On Tue, Jul 21, 2009 at 07:38:54AM +, Philipp Kern wrote:
> On 2009-07-21, Goswin von Brederlow 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 buildds a
On 2009-07-21, Goswin von Brederlow wrote:
> Philipp Kern writes:
>
>> On 2009-07-20, Stéphane Glondu 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 tra
Philipp Kern writes:
> On 2009-07-20, Stéphane Glondu 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
On 2009-07-20, Stéphane Glondu 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 uploaded, it mean
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 tak
On Sat, Jul 18, 2009 at 03:45:13PM +, Philipp Kern wrote:
> On 2009-07-18, Wouter Verhelst 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 2009-07-18, Wouter Verhelst 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 the whole thing
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
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 automate
Luk Claes 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 talking about err
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
> >
On Fri, 17 Jul 2009, Cyril Brulebois wrote:
> Steffen Moeller (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.
At least dpkg-de
Steffen Moeller (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 signature
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 fa
On 2009-07-17, Wouter Verhelst 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 do note tha
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,
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 th
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
Mike Hommey wrote:
> On Fri, Jul 17, 2009 at 10:57:25AM +0200, Steffen Moeller
> 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 build
On Fri, Jul 17, 2009 at 10:57:25AM +0200, Steffen Moeller
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. E.g.
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 th
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.
>
>
[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 buil
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
26 matches
Mail list logo
