On Thu, Mar 26, 2020 at 4:51 PM Emilio Pozuelo Monfort wrote:
> On 25/03/2020 07:06, László Böszörményi (GCS) wrote:
> > Previously mentioned under-maintained packages ignition-msgs and
> > ignition-transport: these build correctly but their autopkgtests are
> > failing. What should be done with p
Control: tags -1 pending
On 25/03/2020 07:06, László Böszörményi (GCS) wrote:
> On Mon, Mar 23, 2020 at 10:16 AM Emilio Pozuelo Monfort
> wrote:
>> On 22/03/2020 12:34, Emilio Pozuelo Monfort wrote:
>>> On 22/03/2020 08:33, László Böszörményi (GCS) wrote:
Thanks, uploaded. Built on all prim
On 3/25/20 7:06 AM, László Böszörményi (GCS) wrote:
> An other question is opencv as in the transition tracker its marked
> unknown status (?) as '?!'. Manually checking its binNMU logs reveals
> it built correctly on all supported architectures.
That's due to cruft:
https://ftp-master.debian.or
On Mon, Mar 23, 2020 at 10:16 AM Emilio Pozuelo Monfort
wrote:
> On 22/03/2020 12:34, Emilio Pozuelo Monfort wrote:
> > On 22/03/2020 08:33, László Böszörményi (GCS) wrote:
> >> Thanks, uploaded. Built on all primary architectures and on secondary
> >> ones that have ruby2.7 - only sparc64 regres
On 23/03/2020 10:20, László Böszörményi (GCS) wrote:
> On Mon, Mar 23, 2020 at 10:16 AM Emilio Pozuelo Monfort
> wrote:
>> On 22/03/2020 12:34, Emilio Pozuelo Monfort wrote:
>>> I have scheduled binNMUs for level 2.
>>
>> And 3 as well.
> Any reason you skipped level1?
The two rdeps in level 1 a
On Mon, Mar 23, 2020 at 10:16 AM Emilio Pozuelo Monfort
wrote:
> On 22/03/2020 12:34, Emilio Pozuelo Monfort wrote:
> > I have scheduled binNMUs for level 2.
>
> And 3 as well.
Any reason you skipped level1?
> Things seem to be in a good shape, except for astroidmail which needs an
> upload
> f
On 22/03/2020 12:34, Emilio Pozuelo Monfort wrote:
> On 22/03/2020 08:33, László Böszörményi (GCS) wrote:
>> On Sat, Mar 21, 2020 at 2:31 PM Emilio Pozuelo Monfort
>> wrote:
>>> So let's go ahead, and let's get things in a good shape quickly if they turn
>>> badly so as not to delay the other tra
On 22/03/2020 08:33, László Böszörményi (GCS) wrote:
> On Sat, Mar 21, 2020 at 2:31 PM Emilio Pozuelo Monfort
> wrote:
>> So let's go ahead, and let's get things in a good shape quickly if they turn
>> badly so as not to delay the other transitions.
> Thanks, uploaded. Built on all primary archi
On Sat, Mar 21, 2020 at 2:31 PM Emilio Pozuelo Monfort wrote:
> So let's go ahead, and let's get things in a good shape quickly if they turn
> badly so as not to delay the other transitions.
Thanks, uploaded. Built on all primary architectures and on secondary
ones that have ruby2.7 - only sparc6
Control: tags -1 confirmed
On 21/03/2020 14:08, László Böszörményi (GCS) wrote:
> On Sat, Mar 21, 2020 at 12:20 PM Emilio Pozuelo Monfort
> wrote:
>> On 21/03/2020 06:33, László Böszörményi (GCS) wrote:
>>> Multilevel transition needed for a while including for the grpc
>>> package. Rebuilt rever
On Sat, Mar 21, 2020 at 12:20 PM Emilio Pozuelo Monfort
wrote:
> On 21/03/2020 06:33, László Böszörményi (GCS) wrote:
> > Multilevel transition needed for a while including for the grpc
> > package. Rebuilt reverse dependencies on amd64 and got the following
> > results.
>
> This conflicts with th
On 21/03/2020 06:33, László Böszörményi (GCS) wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Hi RMs,
>
> Multilevel transition needed for a while including for the grpc
> package. Rebuilt reverse dependencies on am
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Hi RMs,
Multilevel transition needed for a while including for the grpc
package. Rebuilt reverse dependencies on amd64 and got the following
results.
Level1 is OK
Level2 is mostly OK, e
13 matches
Mail list logo
