Re: Scheduling 9.5

[Adam D. Barratt]

Hi,

On Wed, 2018-07-11 at 06:11 +0200, Cyril Brulebois wrote:
> In the end I've been out longer than I thought I would, so I only
> managed to give it a go during the night. Being bugged by the
> perspective of only build-testing d-i before the upload, I've gone
> ahead with the whole “hack an archive” game, and it looks like test
> cases like plain disk, encrypted LVM, plain disk with XFS don't
> regress. Those usually let us (dis)cover kernel-related fun, so I
> guess green lights means we can merge this kernel
> ABI bump without too many second thoughts.

Great, thanks.

> If that upload gets accepted and built during the day, I can probably
> take care of dini this evening.

Thanks; flagged for acceptance.

Regards,

Adam

Re: Scheduling 9.5

[Cyril Brulebois]

Hi,

Adam D. Barratt  (2018-07-10):
> On Tue, 2018-07-10 at 02:36 +0200, Cyril Brulebois wrote:
> > I'm not sure I'll be able to run tests (with a hacked archive due to
> > the udebs being in s-p-u) before late evenings of Tuesday or
> > Wednesday.
> > Should I upload right away, so that we can build d-i and d-i-n-i
> > first, and eventually not include them for the point release if
> > subsequent tests show regressions?
> > 
> > That would get builds out of your way, while leaving us an
> > opportunity to abort their inclusion if regressions are detected?
> 
> Sure, that seems like a reasonable plan to me; thanks.

In the end I've been out longer than I thought I would, so I only managed
to give it a go during the night. Being bugged by the perspective of only
build-testing d-i before the upload, I've gone ahead with the whole “hack
an archive” game, and it looks like test cases like plain disk, encrypted
LVM, plain disk with XFS don't regress. Those usually let us (dis)cover
kernel-related fun, so I guess green lights means we can merge this kernel
ABI bump without too many second thoughts.

If that upload gets accepted and built during the day, I can probably take
care of dini this evening.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Uploading linux (4.17.6-1)

[Ben Hutchings]

I intend to upload linux to unstable once the 4.17.6 stable update is
available (probably on Thursday 12th).

Aside from the stable updates, the other committed changes are:

  * [armhf] DRM: Enable CONFIG_DRM_IMX_PARALLEL_DISPLAY
  * linux-tools: Fix cross-build of objtool
  * [powerpcspe] Fix build failures (thanks to James Clarke):
- powerpc/lib/sstep: Fix building for powerpcspe
- powerpc/lib/Makefile: Don't pull in quad.o for 32-bit kernels
- linux-perf: Disable building for powerpcspe
  * [powerpc,powerpcspe,ppc64] Fix cross-build (Closes: #903096):
- Introduce linux-bootwrapper- package containing boot wrapper
  tools for the host architecture
- linux-image: Install symlinks to boot wrapper tools instead of the
  native tools built by kbuild
   * fs: Fix up non-directory creation in SGID directories (CVE-2018-13405)
   * sound/pci/hda: Ignore ABI changes

This might require an ABI bump, but I think it's avoidable.  In any
case, it will require a trip through NEW to add the linux-bootwrapper
package.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.



signature.asc
Description: This is a digitally signed message part

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: rustc_1.24.1+dfsg1-1~deb9u2_amd64.changes
  ACCEPT

Bug#899189: nmu: unison_2.48.3-1

[Stéphane Glondu]

On 06/07/2018 03:15, Cyril Brulebois wrote:
>> For the sake of completeness, here's an extra data point. If someone
>> ends up with two peers with versions 2.48.3-1 vs. 2.48.3-1+b1 (hosts
>> with s-p-u enabled, but not dist-upgraded at the same time), one can
>> get this very issue:
>> | Uncaught exception Failure("input_value: bad bigarray kind")

This is expected.

>> with extra unfriendly debug messages (hey, look at those in the github
>> bug tracker, the ones we wanted to get rid of).
>>
>> I thought I'd mention the possibly surprising outcome for people not
>> following debian-release@ closely.
> 
> Also, that seems to completely invalidate the on-disk cache, which is
> likely the reason why the first run with an upgraded version (on either
> side, by the way) can take several (dozens of) minutes instead of a
> couple of seconds.

Indeed. Care must be taken at each upgrade of Unison, I think Unison
users are aware of that. This is not specific to Debian. What was
specific to Debian was the situation of Unison compiled with a version
of OCaml different from the one that is being distributed alongside,
which this binNMU is meant to fix.

> It might have been a good idea to mention that in the binNMU request. It
> might also be a good idea to document those consequences in some way.

Sorry. Where would be a good place to document this, now?


Cheers,

-- 
Stéphane

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_mips64el.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_armel.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_mips.changes
  ACCEPT
Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_mipsel.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_armhf.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_amd64.changes
  ACCEPT
Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_arm64.changes
  ACCEPT
Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_ppc64el.changes
  ACCEPT
Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_s390x.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_all.changes
  ACCEPT
Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_i386.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gridengine_8.1.9+dfsg-4+deb9u2_source.changes
  ACCEPT