On Thu, 2022-09-01 at 08:45 -0500, Steven Robbins wrote:
> OK, so let's call it "bin nmu", then. And add the "+bN" version
> suffix.
As others said, binNMUs exist, but not for arch:all packages. Debian
doesn't yet have sourceful no-change rebuilds, so you have to manually
do a sourceful
On Thu, Sep 01, 2022 at 08:45:06AM -0500, Steven Robbins wrote:
> > > Specficially: in the case of a NEW binary upload, could a manual request
> > > be
> > > implemented (pick a different name if "give back" is not suitable) such
> > > that it is thrown away and replaced by a buildd build?
> >
>
Paul Said:
> On Sun, 2022-08-28 at 17:54 -0500, Steven Robbins wrote:
> > Specficially: in the case of a NEW binary upload, could a manual request
> > be
> > implemented (pick a different name if "give back" is not suitable) such
> > that it is thrown away and replaced by a buildd build?
>
> If
On Sun, Aug 28, 2022 at 05:54:36PM -0500, Steven Robbins wrote:
> I understand that the current state is that one can only "give back" a failed
> build. I'm asking whether this must necessarily be the case.
Yes, by definition.
> Specficially: in the case of a NEW binary upload, could a manual
On Sun, 2022-08-28 at 17:54 -0500, Steven Robbins wrote:
> Specficially: in the case of a NEW binary upload, could a manual request be
> implemented (pick a different name if "give back" is not suitable) such that
> it
> is thrown away and replaced by a buildd build?
The dak software already
On Tuesday, August 23, 2022 6:56:32 P.M. CDT Nilesh Patra wrote:
> On 24 August 2022 3:29:10 am IST, Steven Robbins wrote:
> >The binary upload cannot transition to testing -- a buildd binary build is
> >required. So far as I know -- assuming [1] is still up-to-date, this means
> >a nuisance
Hello,
On Wed 24 Aug 2022 at 12:09AM GMT, Holger Levsen wrote:
>
> On Tue, Aug 23, 2022 at 04:59:10PM -0500, Steven Robbins wrote:
>> Commonly, I update a package that provides a shared library. Due to the
>> package naming convention, a new SOVERSION necessitates a trip through NEW,
>> which
On Wed, Aug 24, 2022 at 10:06:55PM +0200, Paul Gevers wrote:
> > The patch for dropping NEW binaries has been in dak for two years but
> > its configuration options were never enabled by ftp-master so far.
> > Dinstall::ThrowAwayNewBinarySuites
> > Dinstall::ThrowAwayNewBinaryComponents
> I would
On Thu, Aug 25, 2022 at 07:13:52PM +0800, Paul Wise wrote:
> On Thu, 2022-08-25 at 11:04 +0200, Paul Gevers wrote:
> > In testing and on release architectures, I'm only aware [1] of one that
> > can't build arch:all+arch:any binaries on amd64 (cmucl), but even that
> > one builds its arch:all
On Thu, 2022-08-25 at 11:04 +0200, Paul Gevers wrote:
> In testing and on release architectures, I'm only aware [1] of one that
> can't build arch:all+arch:any binaries on amd64 (cmucl), but even that
> one builds its arch:all binaries on amd64. I'm wondering if there are
> packages where this
Hi all
On 25-08-2022 02:43, Paul Wise wrote:
I don't think Build-Architecture header is done yet?
Neither do I.
Although since we
build all arch:all packages on amd64 machines now I don't think this is
needed for throwing away NEW binaries?
In testing and on release architectures, I'm
On 2022-08-25 08:43:58 +0800, Paul Wise wrote:
> On Wed, 2022-08-24 at 23:19 +0200, Sebastian Ramacher wrote:
>
> > I run
> >
> > $ drt-tools process-excuses
> >
> > once a day (except during VAC or when I am not in front of a box with my
> > Debian keys). That schedules binNMUs for all
On Wed, 2022-08-24 at 23:19 +0200, Sebastian Ramacher wrote:
> I run
>
> $ drt-tools process-excuses
>
> once a day (except during VAC or when I am not in front of a box with my
> Debian keys). That schedules binNMUs for all packages that only require
> a rebuild and have no other issues
On 2022-08-24 22:06:55 +0200, Paul Gevers wrote:
> Hi,
>
> On 24-08-2022 02:05, Paul Wise wrote:
> > The release team automatically do binNMUs for packages that need a
> > rebuild to transition to testing and are able to be binNMUed
>
> Maybe my fellow Release Team members have automated this
Hi,
On 24-08-2022 02:05, Paul Wise wrote:
The release team automatically do binNMUs for packages that need a
rebuild to transition to testing and are able to be binNMUed
Maybe my fellow Release Team members have automated this locally, but
I'm not aware of shared tools (or even cron jobs)
Am Wed, Aug 24, 2022 at 12:09:20AM + schrieb Holger Levsen:
>
> it's rather easy to do too, though maybe there should be something in
> src:devscripts
> implementing something along these lines:
Sure its easy and may be everybody (including me) has written some local
scripts. The fact that
[My earlier mail went blank, not sure what's up with K-9]
On 24 August 2022 3:29:10 am IST, Steven Robbins wrote:
>The binary upload cannot transition to testing -- a buildd binary build is
>required. So far as I know -- assuming [1] is still up-to-date, this means a
>nuisance upload just
On 24 August 2022 3:29:10 am IST, Steven Robbins wrote:
>The binary upload cannot transition to testing -- a buildd binary build is
>required. So far as I know -- assuming [1] is still up-to-date, this means a
>nuisance upload just bumping the debian revision from -1 to -2. Is this still
On Tue, Aug 23, 2022 at 04:59:10PM -0500, Steven Robbins wrote:
> Commonly, I update a package that provides a shared library. Due to the
> package naming convention, a new SOVERSION necessitates a trip through NEW,
> which in turn means a binary upload.
>
> The binary upload cannot transition
On Tue, 2022-08-23 at 16:59 -0500, Steven Robbins wrote:
> The binary upload cannot transition to testing -- a buildd binary build is
> required. So far as I know -- assuming [1] is still up-to-date, this means a
> nuisance upload just bumping the debian revision from -1 to -2. Is this
>
Commonly, I update a package that provides a shared library. Due to the
package naming convention, a new SOVERSION necessitates a trip through NEW,
which in turn means a binary upload.
The binary upload cannot transition to testing -- a buildd binary build is
required. So far as I know --
21 matches
Mail list logo