Philipp Kern dixit:
>> Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is.
>
>Unfortunately it is not being run on the same host as dak either.
Hm, rmadison then. What does packages.d.o/sid/binpkgname use? (On the
other hand, that’s often quite behind…)
bye,
//mirabilos
On Fri, Oct 23, 2015 at 02:46:23PM +0200, Thorsten Glaser wrote:
> On Fri, 23 Oct 2015, Adam D. Barratt wrote:
> > and testing), so the only way to be certain what binNMU number to use is to
> > check manually. In practice what actually happens is that people forget
> > about
> Maybe wb could do a
On Fri, 23 Oct 2015, Adam D. Barratt wrote:
> and testing), so the only way to be certain what binNMU number to use is to
> check manually. In practice what actually happens is that people forget about
Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is.
I’ll have a look
On 2015-10-23 13:28, Thorsten Glaser wrote:
[...]
On Fri, 23 Oct 2015, Adam D. Barratt wrote:
[...]
It's also not quite that simple, even working things out by hand - see
#599128
for example.
Hm, I’m still under the impression that the +bN suffix to the Debian
version of the package in the a
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
> >> Ah, cool – so we have only to patch this tool to automatically
> >> use the highest number per batch on all affected architectures
> >> (or even to use the highest number if all architectures would
> >> be touched, but that’s probably an unre
On 23/10/15 13:21, Emilio Pozuelo Monfort wrote:
> On 23/10/15 13:02, Thorsten Glaser wrote:
>> On Fri, 23 Oct 2015, Adam D. Barratt wrote:
>>
>>> wanna-build does, yes, but at least the Release Team tend to use the "wb"
>>> wrapper tool which automatically works out the next free number on each
>>
On 23/10/15 13:02, Thorsten Glaser wrote:
> On Fri, 23 Oct 2015, Adam D. Barratt wrote:
>
>> wanna-build does, yes, but at least the Release Team tend to use the "wb"
>> wrapper tool which automatically works out the next free number on each
>> architecture.
>
> Ah, cool – so we have only to patc
On 2015-10-23 12:02, Thorsten Glaser wrote:
On Fri, 23 Oct 2015, Adam D. Barratt wrote:
wanna-build does, yes, but at least the Release Team tend to use the
"wb"
wrapper tool which automatically works out the next free number on
each
architecture.
Ah, cool – so we have only to patch this to
On Fri, 23 Oct 2015, Adam D. Barratt wrote:
> wanna-build does, yes, but at least the Release Team tend to use the "wb"
> wrapper tool which automatically works out the next free number on each
> architecture.
Ah, cool – so we have only to patch this tool to automatically
use the highest number p
On 2015-10-23 11:56, Thorsten Glaser wrote:
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
I didn't say once per arch. I said once per package, which is worse. I
normally
schedule binNMUs for several dozens packages. Multiply that by several
But you need to look the number up anyway? The
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
> I didn't say once per arch. I said once per package, which is worse. I
> normally
> schedule binNMUs for several dozens packages. Multiply that by several
But you need to look the number up anyway? The wanna-build
--binNMU parameter gets the n
On 23/10/15 12:23, Wookey wrote:
> +++ Emilio Pozuelo Monfort [2015-10-23 11:49 +0200]:
>> On 23/10/15 11:20, Thorsten Glaser wrote:
>
>>> How about, scheduling them all at once, but using the same version
>>> number across arches when doing it (i.e. the largest)?
>>
>> Again, that involves determ
+++ Emilio Pozuelo Monfort [2015-10-23 11:49 +0200]:
> On 23/10/15 11:20, Thorsten Glaser wrote:
> > How about, scheduling them all at once, but using the same version
> > number across arches when doing it (i.e. the largest)?
>
> Again, that involves determining what that number is for each pack
On 23/10/15 11:20, Thorsten Glaser wrote:
> On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
>
>> I can go back to scheduling binNMUs for release architectures only, or for
>> ANY
>> -x32. But I don't have the time to look at every architecture and determine
>> which one needs a binNMU and whic
[ Sorry for the cross-post, but I believe the people in -release and -wb-team
should see this ]
On 23/10/15 09:05, Thorsten Glaser wrote:
> Hi,
>
> whoever is scheduling binNMUs now should do so with a little
> bit more care, please.
>
> Case in point, frameworkintegration – x32 already was rebu
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
> I can go back to scheduling binNMUs for release architectures only, or for ANY
> -x32. But I don't have the time to look at every architecture and determine
> which one needs a binNMU and which one has already done it. Anyway if your
OK. In thi
Hi,
whoever is scheduling binNMUs now should do so with a little
bit more care, please.
Case in point, frameworkintegration – x32 already was rebuilt
against the new Qt API and did not need the additional binNMU.
Case in point, some OCaml binNMUs were done recently (within
the last month), to re
17 matches
Mail list logo
