Updating x86 microcode in stable

I notice that amd64-microcode and intel-microcode haven't been updated in stable this year. (Indeed, amd64-microcode hasn't been updated at all this year, but I know AMD has issued an update!) You have updated intel-microcode in backports suites instead. What's the reasoning behind this? I

Re: Scheduling 9.5

On Mon, 14, May, 2018 at 06:19:00PM +0100, Jonathan Wiltshire spoke thus.. > Hi, > > We're due a point release any day now. Please indicate your availablility > out of: > > - May 26th (meaning freeze this coming weekend, which might be a big ask) > - Jun 2nd (which may require an unusual SRM)

Re: Scheduling 9.5

On Mon, May 14, 2018 at 06:19:00PM +0100, Jonathan Wiltshire wrote: >Hi, > >We're due a point release any day now. Please indicate your availablility >out of: > > - May 26th (meaning freeze this coming weekend, which might be a big ask) Awkward, but doable. > - Jun 2nd (which may require an

Re: Scheduling final Jessie point release, 8.11

On Mon, May 14, 2018 at 06:26:08PM +0100, Jonathan Wiltshire wrote: >Hi, > >According to my records main security support for Jessie can end any time >after 17th June. > >So to the security team: do you have a date in mind? > >I also presume that LTS will take over the existing security suites as

Re: Scheduling 9.5

and now without the typo in KiBi's address *sigh* On Mon, 2018-05-14 at 20:55 +0100, Adam D. Barratt wrote: > [CC += KiBi] > > On Mon, 2018-05-14 at 18:19 +0100, Jonathan Wiltshire wrote: > > We're due a point release any day now. Please indicate your > > availablility > > out of: > > > >  -

Re: Scheduling 9.5

[CC += KiBi] On Mon, 2018-05-14 at 18:19 +0100, Jonathan Wiltshire wrote: > We're due a point release any day now. Please indicate your > availablility > out of: > >  - May 26th (meaning freeze this coming weekend, which might be a big > ask) >  - Jun 2nd (which may require an unusual SRM) >  -

Re: Scheduling final Jessie point release, 8.11

On Mon, May 14, 2018 at 06:26:08PM +0100, Jonathan Wiltshire wrote: > Hi, > > According to my records main security support for Jessie can end any time > after 17th June. > > So to the security team: do you have a date in mind? The 17th :-) Cheers, Moritz

Bug#894159: ICU transition: ICU version is part of the boost ABI

On Mon, May 14, 2018 at 07:13:57PM +0200, Emilio Pozuelo Monfort wrote: > On 13/05/18 16:08, Adrian Bunk wrote: > > Control: reassign 898465 src:icu 60.1-1 > > Control: retitle 898369 boost: ICU version used is part of the ABI > > Control: retitle 898465 ICU must not migrate to testing before the

Scheduling 9.5

Hi, We're due a point release any day now. Please indicate your availablility out of: - May 26th (meaning freeze this coming weekend, which might be a big ask) - Jun 2nd (which may require an unusual SRM) - Jun 9th (getting quite a way out of cadence, but maybe that can't be helped)

Scheduling final Jessie point release, 8.11

Hi, According to my records main security support for Jessie can end any time after 17th June. So to the security team: do you have a date in mind? I also presume that LTS will take over the existing security suites as before. [1] lists the current delta between security and o-p-u-new which

Bug#894159: ICU transition: ICU version is part of the boost ABI

On 13/05/18 16:08, Adrian Bunk wrote: > Control: reassign 898465 src:icu 60.1-1 > Control: retitle 898369 boost: ICU version used is part of the ABI > Control: retitle 898465 ICU must not migrate to testing before the boost ABI > breakage is resolved > Control: affects 898369 libmapnik3.0 viking

Bug#894159: transition: icu

On 13/05/18 22:52, László Böszörményi (GCS) wrote: > Last but not least I've a different understanding (again) of package > transitions with Adrian Bunk. He reassigned #898465 [2] to ICU, when both > related bugreports of ncmpcpp [3] and viking due to mapnik [4] are due to > partial upgrades

Processed: Incorrect bug number was used in 'block ... by ...'

Processing commands for cont...@bugs.debian.org: > unblock 897579 by 898644 Bug #897579 [release.debian.org] transition: mmdb 897579 was blocked by: 898644 897579 was blocking: 897673 Removed blocking bug(s) of 897579: 898644 > block 897673 by 898644 Bug #897673 [wnpp] ITP: coot -- model building

Processed: ITP: refmac-dictionary -- dictionary for macromolecular refinement and model building

Processing control commands: > block 897579 by -1 Bug #897579 [release.debian.org] transition: mmdb 897579 was not blocked by any bugs. 897579 was blocking: 897673 Added blocking bug(s) of 897579: 898644 -- 897579: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897579 898644:

Bug#878428: marked as done (transition: gjs/mutter/gnome-shell 3.26)

Your message dated Mon, 14 May 2018 16:06:57 +0100 with message-id <20180514150657.ga15...@espresso.pseudorandom.co.uk> and subject line Re: Bug#878428: transition: gjs/mutter/gnome-shell 3.26 has caused the Debian Bug report #878428, regarding transition: gjs/mutter/gnome-shell 3.26 to be marked

Re: Fixing Linux getrandom() in stable

> "Thorsten" == Thorsten Glaser writes: Thorsten> Adrian Bunk dixit: >> As an example, what happens if I debootstrap and deploy the >> resulting filesytem to a large number of identical embedded >> systems without entropy sources? Thorsten> Just get into

Bug#898341: marked as done (nmu: libtermkey_0.20-3)

Your message dated Mon, 14 May 2018 09:08:20 +0200 with message-id and subject line Re: Bug#898341: nmu: libtermkey_0.20-3 has caused the Debian Bug report #898341, regarding nmu: libtermkey_0.20-3 to be marked as done. This means that you claim