Bug#883921: transition: libical

[Andreas Beckmann]

Followup-For: Bug #883921

experimental NMU for libical3:

nmu libkolab_1.0.2-5 . ANY . experimental . -m "Rebuild against libical3."

libkolab1 will pick up a new dependency on libical3, fixing an
unresolved symbol it currently has (only in experimental).



Andreas

Re: [pkg-cryptsetup-devel] Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Guilhem Moulin]

Hi Cyril,

On Mon, 18 Dec 2017 at 01:39:35 +0100, Cyril Brulebois wrote:
> Guilhem Moulin  (2017-12-18):
>> On Sun, 17 Dec 2017 at 18:12:21 +0100, Cyril Brulebois wrote:
>>> I've added this as a todo item, along with looking into src:argon2
>>> and src:json-c. I'll try to look into that next week (ping welcome),
>>> but we'll need to get those packages past NEW; it would be
>>> appreciated to only start the cryptsetup transition once
>>> dependencies can be satisfied, to avoid breaking d-i daily builds
>>> purposefully.
>> 
>> Ack.  I see mejo has just requested the transition slot in #884618,
>> that means we should we block that bug by #88052[56], right?
> 
> That would look good yes.

Done.

>> Not sure what's upstream's intention regarding making `cryptsetup
>> luksFormat` create LUKS2 devices by default, but at this stage it seems
>> precipitated to switch to LUKS2 in d-i: I'd rather stick to upstream's
>> default, especially considering the following snippets of their v2.0.0
>> Release Notes:
>> 
>>“Please note that […] the LUKS2 on-disk format itself are new
>>features and can contain some bugs.”
>>— 
>> https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/v2.0.0-ReleaseNotes#L15
>> 
>> (And FWIW it's possible to later in-place convert a device from LUKS1 to
>> LUKS2 format using `cryptsetup convert`, although it of course won't
>> magically upgrade the crypto & PKDF algorithms.)
> 
> Alright; feel free to poke us again for partman-crypto when the new
> format looks mature enough so that we see about adding support for it.

Will do :-)

>>> Alternatively, instead of waiting for udebs to be available for the
>>> dependencies, maybe support for those two libraries could be patched
>>> out temporarily in the cryptsetup udebs?
>> 
>> For libargon2-0 it should be a matter of changing the default PBKDF
>> back to pbkdf2, but I don't see a way to drop the libjson-c3
>> dependency unless we compile cryptsetup without LUKS2 support (LUKS2
>> headers contain metadata stored in JSON format [1]), which is not
>> trivial AFAICT.
> 
> Alright, thanks for your input, that's going to guide my looking into
> these packages during the week; I'll investigate as soon as I'm done
> with urgent matters.

Awesome, thanks!

-- 
Guilhem.


signature.asc
Description: PGP signature

Processed: block 884618 with 880525 880526

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 884618 with 880525 880526
Bug #884618 [release.debian.org] transition: cryptsetup
884618 was not blocked by any bugs.
884618 was not blocking any bugs.
Added blocking bug(s) of 884618: 880526 and 880525
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
884618: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884618
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: [pkg-cryptsetup-devel] Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Cyril Brulebois]

Hi,

Guilhem Moulin  (2017-12-18):
> On Sun, 17 Dec 2017 at 18:12:21 +0100, Cyril Brulebois wrote:
> > FWIW, feel free to (x-debbugs-)cc debian-boot@ when requesting such
> > additions; you might get some feedback like a patch or two, or
> > alternative routes to consider.
> > 
> > I hadn't spotted libcryptsetup12-udeb isn't installable due to these
> > dependencies, as experimental isn't checked automatically:
> > https://d-i.debian.org/dose/
> 
> Makes sense, sorry for not doing so.

No worries, knowing about the transition in advance was nice already. :)

> > I've added this as a todo item, along with looking into src:argon2
> > and src:json-c. I'll try to look into that next week (ping welcome),
> > but we'll need to get those packages past NEW; it would be
> > appreciated to only start the cryptsetup transition once
> > dependencies can be satisfied, to avoid breaking d-i daily builds
> > purposefully.
> 
> Ack.  I see mejo has just requested the transition slot in #884618,
> that means we should we block that bug by #88052[56], right?

That would look good yes.

> > Also, from one the those two bugs: “cryptsetup ≥2.0.0 introduces a
> > new on-disk “LUKS2” format, which support Argon2i and Argon2id as
> > PBKDF.”
> > 
> > Is that a new default format? Does it need any special handling from
> > d-i components, like options or files to create, or is that just a
> > transparent change for cryptsetup callers?
> 
> The format isn't the new default in the sense that `cryptsetup
> luksFormat` still creates “legacy” LUKS (version 1) devices, and one
> needs to append `--type luks2` to create LUKS2 devices.  Opening a LUKS2
> block device does require a locking directory[0] (/run/lock/cryptsetup),
> but partman-crypto can stay as is as long as it keeps creating LUKS1
> devices.
> 
> Not sure what's upstream's intention regarding making `cryptsetup
> luksFormat` create LUKS2 devices by default, but at this stage it seems
> precipitated to switch to LUKS2 in d-i: I'd rather stick to upstream's
> default, especially considering the following snippets of their v2.0.0
> Release Notes:
> 
> “Please note that […] the LUKS2 on-disk format itself are new
> features and can contain some bugs.”
> — 
> https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/v2.0.0-ReleaseNotes#L15
> 
> (And FWIW it's possible to later in-place convert a device from LUKS1 to
> LUKS2 format using `cryptsetup convert`, although it of course won't
> magically upgrade the crypto & PKDF algorithms.)

Alright; feel free to poke us again for partman-crypto when the new
format looks mature enough so that we see about adding support for it.

> > Alternatively, instead of waiting for udebs to be available for the
> > dependencies, maybe support for those two libraries could be patched
> > out temporarily in the cryptsetup udebs?
> 
> For libargon2-0 it should be a matter of changing the default PBKDF
> back to pbkdf2, but I don't see a way to drop the libjson-c3
> dependency unless we compile cryptsetup without LUKS2 support (LUKS2
> headers contain metadata stored in JSON format [1]), which is not
> trivial AFAICT.

Alright, thanks for your input, that's going to guide my looking into
these packages during the week; I'll investigate as soon as I'm done
with urgent matters.


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


signature.asc
Description: PGP signature

Re: [pkg-cryptsetup-devel] Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Guilhem Moulin]

On Sun, 17 Dec 2017 at 18:12:21 +0100, Cyril Brulebois wrote:
> Guilhem Moulin  (2017-12-17):
>> On Sun, 17 Dec 2017 at 13:32:55 +0100, Cyril Brulebois wrote:
>>> Jonas Meurer  (2017-12-17):
 Debian-boot is Cc'ed as cryptsetup provides udebs, so
 debian-installer is affected as well.
>>> 
>>> Thanks for letting us (debian-boot@) know. AFAICT, on the udeb side
>>> we only have crypsetup-udeb that depends on its library udeb, and no
>>> other udebs are in the loop.
>> 
>> FWIW 2:2.0.0~rc1-1 (and soon 2:2.0.0-1) adds new dependencies on
>> libargon2-0 and libjson-c3, that don't have udebs yet.  We filed
>> #880525 and #880526 on Nov. 1 but didn't hear back from the respective
>> maintainers yet, and so far didn't have time to write the patches
>> ourselves.
> 
> FWIW, feel free to (x-debbugs-)cc debian-boot@ when requesting such
> additions; you might get some feedback like a patch or two, or
> alternative routes to consider.
> 
> I hadn't spotted libcryptsetup12-udeb isn't installable due to these
> dependencies, as experimental isn't checked automatically:
> https://d-i.debian.org/dose/

Makes sense, sorry for not doing so.
 
> I've added this as a todo item, along with looking into src:argon2 and
> src:json-c. I'll try to look into that next week (ping welcome), but
> we'll need to get those packages past NEW; it would be appreciated to
> only start the cryptsetup transition once dependencies can be satisfied,
> to avoid breaking d-i daily builds purposefully.

Ack.  I see mejo has just requested the transition slot in #884618, that
means we should we block that bug by #88052[56], right?

> Also, from one the those two bugs: “cryptsetup ≥2.0.0 introduces a new
> on-disk “LUKS2” format, which support Argon2i and Argon2id as PBKDF.”
> 
> Is that a new default format? Does it need any special handling from
> d-i components, like options or files to create, or is that just a
> transparent change for cryptsetup callers?

The format isn't the new default in the sense that `cryptsetup
luksFormat` still creates “legacy” LUKS (version 1) devices, and one
needs to append `--type luks2` to create LUKS2 devices.  Opening a LUKS2
block device does require a locking directory[0] (/run/lock/cryptsetup),
but partman-crypto can stay as is as long as it keeps creating LUKS1
devices.

Not sure what's upstream's intention regarding making `cryptsetup
luksFormat` create LUKS2 devices by default, but at this stage it seems
precipitated to switch to LUKS2 in d-i: I'd rather stick to upstream's
default, especially considering the following snippets of their v2.0.0
Release Notes:

“Please note that […] the LUKS2 on-disk format itself are new
features and can contain some bugs.”
— 
https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/v2.0.0-ReleaseNotes#L15

(And FWIW it's possible to later in-place convert a device from LUKS1 to
LUKS2 format using `cryptsetup convert`, although it of course won't
magically upgrade the crypto & PKDF algorithms.)

> Alternatively, instead of waiting for udebs to be available for the
> dependencies, maybe support for those two libraries could be patched
> out temporarily in the cryptsetup udebs?

For libargon2-0 it should be a matter of changing the default PBKDF back
to pbkdf2, but I don't see a way to drop the libjson-c3 dependency
unless we compile cryptsetup without LUKS2 support (LUKS2 headers
contain metadata stored in JSON format [1]), which is not trivial
AFAICT.

Cheers,
-- 
Guilhem.

[0] https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/man/cryptsetup.8#L1346
[1] 
https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/LUKS2-format.txt#L33


signature.asc
Description: PGP signature

Bug#884637: RM: wmaloader/0.1-5.1+b2

[Adam D. Barratt]

Control: reassign -1 ftp.debian.org

Removals from unstable are handled by the FTP team; reassigning.

On Sun, 2017-12-17 at 22:23 +0100, Uwe Kleine-König wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> Hello,
> 
> asking Steve McIntyre (= maintainer of src:wmaloader) in irc about
> some
> problem[1] with wmaloader he responded:
> 
> 1513543992 < Sledge> ukleinek: oh $deity, I thought I'd offloaded it
> ages ago
> 1513544068 < Sledge> ukleinek: please file an RM bug
> 1513544084 < Sledge> I've not used the hwardware involved for ~5
> years
> 
> The package got an NMU to fix a link failure in 2011 and the last
> change
> before that was in 2009. It seems the relevant hardware isn't
> produced
> any more, so I agree with Steve that it's sensible to drop this
> package.
> 
> Best regards
> Uwe
> 
> [1] The problem in my case is that wmaloader is hard to port to
> libupnp10 because it uses some internal stuff of libupnp6 and so
> is
> in the way for the libupnp transition (#884635)
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (700, 'testing'), (600, 'unstable'), (500, 'unstable-
> debug'), (500, 'stable'), (499, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> 

Processed: Re: Bug#884637: RM: wmaloader/0.1-5.1+b2

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 ftp.debian.org
Bug #884637 [release.debian.org] RM: wmaloader/0.1-5.1+b2
Bug reassigned from package 'release.debian.org' to 'ftp.debian.org'.
Ignoring request to alter found versions of bug #884637 to the same values 
previously set
Ignoring request to alter fixed versions of bug #884637 to the same values 
previously set

-- 
884637: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884637
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#884504: give-back gdal (2.2.3+dfsg-1) on powerpc

[Sebastiaan Couwenberg]

Please give back gdal on powerpc, it failed to build due to a g++:
internal compiler error. [0]

 gb gdal_2.2.3+dfsg-1 . powerpc . -m "Retry build"

[0]
https://buildd.debian.org/status/fetch.php?pkg=gdal=powerpcspe=2.2.3%2Bdfsg-1=1513545349=0

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#884635: transition: libupnp

[Uwe Kleine-König]

Hello James,

On Sun, Dec 17, 2017 at 09:34:34PM +, James Cowgill wrote:
> Control: block -1 by 882377 884252 884243 884245 884246 884247 884248
> Control: block -1 by 884249 884250 884251

Thanks for the blocks. Even though Sebastian told me in irc that he
reported these I didn't consider these blocks when reporting the
transition bug.

> > title = "libupnp";
> > is_affected = .depends ~ "libupnp6" | .depends ~ "libupnp10";
> > is_good = .depends ~ "libupnp10";
> > is_bad = .depends ~ "libupnp6";
> 
> One slight issue is #882377. In pupnp 1.8.3 upstream broke the ABI which
> I pointed out to them. As a result they have bumped the SONAME in
> upstream git (not yet released). To avoid having to do two transitions,
> we should wait to use the new SONAME. Since the damage is already done,
> I guess we could use the new SONAME right now, although I am always a
> little cautious in doing that in case upstream changes something else :)
> In any case, the ben file will need to be changed at some point.

I don't know if the transition is only added to the tracker when all
blocking bugs are resolved. If not, ben could use

is_good = .depends ~ /libupnp1[01]/

(or even .depends ~ /libupnp1[0-9]/ if upstream is expected to misbehave
:-)

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#884504: transition: gdal

[Sebastiaan Couwenberg]

On 12/17/2017 02:27 PM, Sebastiaan Couwenberg wrote:
> On 12/17/2017 10:38 AM, Emilio Pozuelo Monfort wrote:
>> On 15/12/17 23:11, Bas Couwenberg wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>>
>>> For the Debian GIS team I'd like to transition to GDAL 2.2.3.
>>>
>>> Like the previous transition to GDAL 2.2.2 (#876561), there is no SONAME
>>> bump, only the virtual ABI package changed to account for the C++ symbol
>>> changes.
>>>
>>> All reverse dependencies rebuilt successfully with GDAL 2.2.3 from
>>> experimental as summarized below.
>>>
>>> libgdal-grass doesn't need a binNMU as the 2.2.3 version will be
>>> uploaded to unstable instead. liblas likewise doesn't need a binNMU,
>>> the version is experimental will be moved to unstable instead.
>>
>> Go ahead.
> 
> Thanks, gdal (2.2.3+dfsg-1), liblas (1.8.1-6) & libgdal-grass (2.2.3-1)
> have been uploaded to unstable.

gdal (2.2.3+dfsg-1) has been built & installed on all release
architectures, we should be ready for the binNMUs now.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Processed: Re: Bug#884635: transition: libupnp

[Debian Bug Tracking System]

Processing control commands:

> block -1 by 882377 884252 884243 884245 884246 884247 884248
Bug #884635 [release.debian.org] transition: libupnp
884635 was not blocked by any bugs.
884635 was not blocking any bugs.
Added blocking bug(s) of 884635: 882377, 884246, 884248, 884247, 884252, 
884245, and 884243
> block -1 by 884249 884250 884251
Bug #884635 [release.debian.org] transition: libupnp
884635 was blocked by: 882377 884248 884246 884247 884252 884245 884243
884635 was not blocking any bugs.
Added blocking bug(s) of 884635: 884251, 884249, and 884250

-- 
884635: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884635
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#884635: transition: libupnp

[James Cowgill]

Control: block -1 by 882377 884252 884243 884245 884246 884247 884248
Control: block -1 by 884249 884250 884251

Hi,

On 17/12/17 21:07, Uwe Kleine-König wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> Currently there are two versions of libupnp in the archive:
> 
>  - src:libupnp providing the 1.6.x branch of libupnp which is considered
>legacy by upstream
>  - src:pupnp-1.8 providing the 1.8.x branch of libupnp
> 
> I want to get rid of libupnp6 converting all rdeps to the newer libupnp
> package.
> 
> There are not that many reverse dependencies for libupnp6:
[...]
> I know about mpd upstream already supporting both versions. The Debian
> maintainer of vlc already invested some work in making vlc support both
> versions. I'm about to send a bug about silverjuke with a patch
> implementing a simple conversion which makes it support both versions.
> The Debian maintainer of wmaloader asked me to report an RM bug.

I've added blocks for the bugs I think need to be fixed before starting
the transition. Most were filed by Sebastian Ramacher who (very kindly)
did a rebuild of all the rdeps against pupnp 1.8. mpd, silverjuke and
wmaloader all have bugs already filed against them.

> James Cowgill (= maintainer of src:pupnp-1.8) already uploaded a version
> of src:pupnp-1.8 providing libupnp-dev to experimental.
> https://release.debian.org/transitions/ doesn't have an automatic
> transition though (probably because there are two packages involved).
> 
> Ben file:
> 
> title = "libupnp";
> is_affected = .depends ~ "libupnp6" | .depends ~ "libupnp10";
> is_good = .depends ~ "libupnp10";
> is_bad = .depends ~ "libupnp6";

One slight issue is #882377. In pupnp 1.8.3 upstream broke the ABI which
I pointed out to them. As a result they have bumped the SONAME in
upstream git (not yet released). To avoid having to do two transitions,
we should wait to use the new SONAME. Since the damage is already done,
I guess we could use the new SONAME right now, although I am always a
little cautious in doing that in case upstream changes something else :)
In any case, the ben file will need to be changed at some point.

Also thanks to the people working on this. I know I haven't done as much
as I probably should be doing.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#884637: RM: wmaloader/0.1-5.1+b2

[Uwe Kleine-König]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Hello,

asking Steve McIntyre (= maintainer of src:wmaloader) in irc about some
problem[1] with wmaloader he responded:

1513543992 < Sledge> ukleinek: oh $deity, I thought I'd offloaded it ages ago
1513544068 < Sledge> ukleinek: please file an RM bug
1513544084 < Sledge> I've not used the hwardware involved for ~5 years

The package got an NMU to fix a link failure in 2011 and the last change
before that was in 2009. It seems the relevant hardware isn't produced
any more, so I agree with Steve that it's sensible to drop this package.

Best regards
Uwe

[1] The problem in my case is that wmaloader is hard to port to
libupnp10 because it uses some internal stuff of libupnp6 and so is
in the way for the libupnp transition (#884635)

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), 
(500, 'stable'), (499, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#884635: transition: libupnp

[Uwe Kleine-König]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

Currently there are two versions of libupnp in the archive:

 - src:libupnp providing the 1.6.x branch of libupnp which is considered
   legacy by upstream
 - src:pupnp-1.8 providing the 1.8.x branch of libupnp

I want to get rid of libupnp6 converting all rdeps to the newer libupnp
package.

There are not that many reverse dependencies for libupnp6:

amule
amule-daemon
djmount
gmediarender
gmediaserver
libmediastreamer-base3
linphone
linphone-nogtk
linux-igd
mpd
openclonk
ring-daemon
silverjuke
vlc-plugin-base
wmaloader

I know about mpd upstream already supporting both versions. The Debian
maintainer of vlc already invested some work in making vlc support both
versions. I'm about to send a bug about silverjuke with a patch
implementing a simple conversion which makes it support both versions.
The Debian maintainer of wmaloader asked me to report an RM bug.

James Cowgill (= maintainer of src:pupnp-1.8) already uploaded a version
of src:pupnp-1.8 providing libupnp-dev to experimental.
https://release.debian.org/transitions/ doesn't have an automatic
transition though (probably because there are two packages involved).

Ben file:

title = "libupnp";
is_affected = .depends ~ "libupnp6" | .depends ~ "libupnp10";
is_good = .depends ~ "libupnp10";
is_bad = .depends ~ "libupnp6";

Re: Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Jonas Meurer]

Am 17.12.2017 um 13:32 schrieb Cyril Brulebois:
>> How shall we proceed? The package is ready to be uploaded. Shall we go
>> ahead? Will you (the Release Managers) trigger the binary rebuilds
>> afterwards? Or can/shall we do this ourselves?
> 
> You would usually request a transition slot through a bug report against
> release.debian.org (pick 'transition'), and coordinate uploads & binNMUs
> with the release team.

This is done now: #884618

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#884618: transition: cryptsetup

[Jonas Meurer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hey there,

the upcoming upload of cryptsetup 2.0.0-1 will bump the libcryptsetup
soname from 4 to 12. According to (the very thoughtful) upstream, the
API (old functions) is backwards-compatible, so simple rebuilds of the
reverse depenencies should be enough.

Here's a list of reverse depends:

bruteforce-luks
cryptmount
libpam-mount
luksmeta
systemd
volume-key
libblockdev
zulucrypt

How shall we proceed? The package is ready to be uploaded. Shall we go
ahead? Will you (the Release Managers) trigger the binary rebuilds
afterwards? Or can/shall we do this ourselves?

Cheers
 jonas

Ben file:

title = "cryptsetup";
is_affected = .depends ~ "libcryptsetup4" | .depends ~ "libcryptsetup12";
is_good = .depends ~ "libcryptsetup12";
is_bad = .depends ~ "libcryptsetup4";


-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Re: [pkg-cryptsetup-devel] Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Cyril Brulebois]

Hi,

Guilhem Moulin  (2017-12-17):
> On Sun, 17 Dec 2017 at 13:32:55 +0100, Cyril Brulebois wrote:
> > Jonas Meurer  (2017-12-17):
> >> Debian-boot is Cc'ed as cryptsetup provides udebs, so
> >> debian-installer is affected as well.
> > 
> > Thanks for letting us (debian-boot@) know. AFAICT, on the udeb side
> > we only have crypsetup-udeb that depends on its library udeb, and no
> > other udebs are in the loop.
> 
> FWIW 2:2.0.0~rc1-1 (and soon 2:2.0.0-1) adds new dependencies on
> libargon2-0 and libjson-c3, that don't have udebs yet.  We filed
> #880525 and #880526 on Nov. 1 but didn't hear back from the respective
> maintainers yet, and so far didn't have time to write the patches
> ourselves.

FWIW, feel free to (x-debbugs-)cc debian-boot@ when requesting such
additions; you might get some feedback like a patch or two, or
alternative routes to consider.

I hadn't spotted libcryptsetup12-udeb isn't installable due to these
dependencies, as experimental isn't checked automatically:
  https://d-i.debian.org/dose/

I've added this as a todo item, along with looking into src:argon2 and
src:json-c. I'll try to look into that next week (ping welcome), but
we'll need to get those packages past NEW; it would be appreciated to
only start the cryptsetup transition once dependencies can be satisfied,
to avoid breaking d-i daily builds purposefully.


Also, from one the those two bugs: “cryptsetup ≥2.0.0 introduces a new
on-disk “LUKS2” format, which support Argon2i and Argon2id as PBKDF.”

Is that a new default format? Does it need any special handling from
d-i components, like options or files to create, or is that just a
transparent change for cryptsetup callers?


Alternatively, instead of waiting for udebs to be available for the
dependencies, maybe support for those two libraries could be patched
out temporarily in the cryptsetup udebs?


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


signature.asc
Description: PGP signature

Re: [pkg-cryptsetup-devel] Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Guilhem Moulin]

Hi all,

On Sun, 17 Dec 2017 at 13:32:55 +0100, Cyril Brulebois wrote:
> Jonas Meurer  (2017-12-17):
>> Debian-boot is Cc'ed as cryptsetup provides udebs, so debian-installer
>> is affected as well.
> 
> Thanks for letting us (debian-boot@) know. AFAICT, on the udeb side we
> only have crypsetup-udeb that depends on its library udeb, and no other
> udebs are in the loop.

FWIW 2:2.0.0~rc1-1 (and soon 2:2.0.0-1) adds new dependencies on
libargon2-0 and libjson-c3, that don't have udebs yet.  We filed #880525
and #880526 on Nov. 1 but didn't hear back from the respective
maintainers yet, and so far didn't have time to write the patches
ourselves.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#884606: stretch-pu: package espeakup/1:0.80-5+b2

[Samuel Thibault]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: k...@debian.org

Hello,

Several blind users have reported that the Debian Installer speech
synthesis was not working on their computer, thus making it unusable
for them. It happens that this is due to odd numbering of sound cards
by ALSA on those computers. We have fixed this in buster, it has been
successfully tested on the reported systems, so I propose to include the
fix in Stretch too, I have attached the diff. I'm also Cc-ing Kibi for
his opinion on this.

Samuel

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index a908870..7a19a8d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+espeakup (1:0.80-5+deb9u1) stretch; urgency=medium
+
+  * debian/espeakup-udeb.start: Fix case where card 0 does not have an id or
+where cards have non-contiguous indexes.
+  * debian/espeakup-udeb.finish-install: Use card id in installed system
+to avoid issues with card detection ordering.
+
+ -- Samuel Thibault   Sun, 17 Dec 2017 16:35:19 +0100
+
 espeakup (1:0.80-5) unstable; urgency=medium
 
   * Use canonical anonscm vcs URL.
diff --git a/debian/espeakup-udeb.finish-install 
b/debian/espeakup-udeb.finish-install
index 00e7e84..17c9182 100644
--- a/debian/espeakup-udeb.finish-install
+++ b/debian/espeakup-udeb.finish-install
@@ -12,4 +12,4 @@ apt-install espeakup alsa-utils || true
 
 cp /usr/share/espeakup-udeb/espeakup.default /target/etc/default/espeakup
 sed -i -e "s/^VOICE=.*/VOICE=$VOICE/" /target/etc/default/espeakup
-[ -z "$ALSA_CARD" ] || sed -i -e "s/^# ALSA_CARD=.*/ALSA_CARD=\"$ALSA_CARD\"/" 
/target/etc/default/espeakup
+[ -z "$ALSA_CARD" ] || sed -i -e "s/^# ALSA_CARD=.*/ALSA_CARD=\"`cat 
/sys/class/sound/card$ALSA_CARD/id`\"/" /target/etc/default/espeakup
diff --git a/debian/espeakup-udeb.start b/debian/espeakup-udeb.start
index d187d77..2f5db6a 100644
--- a/debian/espeakup-udeb.start
+++ b/debian/espeakup-udeb.start
@@ -1,7 +1,15 @@
+BASE=/sys/class/sound
+
+strip () {
+   cardid=${1#$BASE/card}
+   echo ${cardid%/id}
+}
+
 if lsmod | grep -q speakup_soft; then
# Give drivers some time to detect boards :/
sleep 2
-   N=$(ls /sys/class/sound/card*/id | wc -l)
+   IDS=$(echo $BASE/card*/id)
+   N=$(echo $IDS | wc -w)
case $N in
0)
echo No sound card detected, can not do software speech 
synthesis... Press enter to continue anyway.
@@ -9,17 +17,18 @@ if lsmod | grep -q speakup_soft; then
;;
1)
# Just one card, can not be wrong
-   echo 0 > /var/run/espeakup.card
-   /usr/bin/espeakup > /var/log/espeakup.log 2>&1
+   echo $(strip $IDS) > /var/run/espeakup.card
+   /usr/bin/espeakup -V en > /var/log/espeakup.log 2>&1
;;
*)
# Several cards, make the user choose
CARD=none
while [ "$CARD" = none ]
do
-   for i in $( seq 0 $(($N-1)) )
+   for ID in $IDS
do
-   ALSA_CARD=$(cat 
/sys/class/sound/card$i/id) /usr/bin/espeakup >> /var/log/espeakup.log 2>&1
+   i=$(strip $ID)
+   ALSA_CARD=$(cat 
/sys/class/sound/card$i/id) /usr/bin/espeakup -V en >> /var/log/espeakup.log 
2>&1
while ! [ -r /var/run/espeakup.pid ]
do
sleep 0.1
@@ -41,6 +50,6 @@ if lsmod | grep -q speakup_soft; then
done
done
echo "$CARD" > /var/run/espeakup.card
-   ALSA_CARD=$(cat /sys/class/sound/card$CARD/id) 
/usr/bin/espeakup >> /var/log/espeakup.log 2>&1
+   ALSA_CARD=$(cat /sys/class/sound/card$CARD/id) 
/usr/bin/espeakup -V en >> /var/log/espeakup.log 2>&1
esac
 fi

Bug#884605: transition: mumps

[Drew Parsons]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

mumps 5.1.2 is a minor update with bug fixes and performance
improvements, no API change and no particular upgrade dramas expected.


Ben file:

title = "mumps";
is_affected = .depends ~ "libmumps-5.1.1" | .depends ~ "libmumps-5.1.2";
is_good = .depends ~ "libmumps-5.1.2";
is_bad = .depends ~ "libmumps-5.1.1";


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Processed: bug 884504 is forwarded to https://release.debian.org/transitions/html/gdal-2.2.3.html

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 884504 https://release.debian.org/transitions/html/gdal-2.2.3.html
Bug #884504 [release.debian.org] transition: gdal
Set Bug forwarded-to-address to 
'https://release.debian.org/transitions/html/gdal-2.2.3.html'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
884504: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884504
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#884504: transition: gdal

[Sebastiaan Couwenberg]

On 12/17/2017 10:38 AM, Emilio Pozuelo Monfort wrote:
> On 15/12/17 23:11, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> For the Debian GIS team I'd like to transition to GDAL 2.2.3.
>>
>> Like the previous transition to GDAL 2.2.2 (#876561), there is no SONAME
>> bump, only the virtual ABI package changed to account for the C++ symbol
>> changes.
>>
>> All reverse dependencies rebuilt successfully with GDAL 2.2.3 from
>> experimental as summarized below.
>>
>> libgdal-grass doesn't need a binNMU as the 2.2.3 version will be
>> uploaded to unstable instead. liblas likewise doesn't need a binNMU,
>> the version is experimental will be moved to unstable instead.
> 
> Go ahead.

Thanks, gdal (2.2.3+dfsg-1), liblas (1.8.1-6) & libgdal-grass (2.2.3-1)
have been uploaded to unstable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Cyril Brulebois]

Hi Jonas,

Jonas Meurer  (2017-12-17):
> the upcoming upload of cryptsetup 2.0.0-1 will bump the libcryptsetup
> soname from 4 to 12. According to (the very thoughtful) upstream, the
> API (old functions) is backwards-compatible, so simple rebuilds of the
> reverse depenencies should be enough.
> 
> Here's a list of reverse depends:
> 
> bruteforce-luks
> cryptmount
> libpam-mount
> luksmeta
> systemd
> volume-key
> libblockdev
> zulucrypt
> 
> Debian-boot is Cc'ed as cryptsetup provides udebs, so debian-installer
> is affected as well.

Thanks for letting us (debian-boot@) know. AFAICT, on the udeb side we
only have crypsetup-udeb that depends on its library udeb, and no other
udebs are in the loop. Since a version with the bumped soname is
available in experimental, someone from the d-i team could build d-i
against it and see if cryptsetup still works as expected. And even if
that doesn't happen, we have no immediate plans for a release yet, so
there's no disruption risk: feel free to proceed whenever you see fit
(but see below).

> How shall we proceed? The package is ready to be uploaded. Shall we go
> ahead? Will you (the Release Managers) trigger the binary rebuilds
> afterwards? Or can/shall we do this ourselves?

You would usually request a transition slot through a bug report against
release.debian.org (pick 'transition'), and coordinate uploads & binNMUs
with the release team.


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


signature.asc
Description: PGP signature

Продам базу данных клиентов

[Darina]

Уникальный проект для заработка денег на автопилоте!

Атакуем и достигаем новых высот!

Уникальный проект для заработка денег на автопилоте!

Атакуем и достигаем новых высот!.

Узнать подробнее

Отписаться от рассылки: List-Unsubscribe

Processed: Re: Bug#884573: RM: torbrowser-launcher/0.2.6-2~bpo8+1

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 ftp.debian.org
Bug #884573 [release.debian.org] RM: torbrowser-launcher/0.2.6-2~bpo8+1
Bug reassigned from package 'release.debian.org' to 'ftp.debian.org'.
Ignoring request to alter found versions of bug #884573 to the same values 
previously set
Ignoring request to alter fixed versions of bug #884573 to the same values 
previously set

-- 
884573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884573
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#884573: RM: torbrowser-launcher/0.2.6-2~bpo8+1

[Adam D. Barratt]

Control: reassign -1 ftp.debian.org

On Sun, 2017-12-17 at 14:15 +0900, Roger Shimizu wrote:
> The old version of torbrowser-launcher cannot work properly anymore,
> because it uses the embedded old key.
> That's also the reason why it also missed the stretch release [0].
> 
> People want to use it in stable(jessie) should consider sloppy
> backports [1].
> 
> So please kindly help to remove torbrowser-launcher/0.2.6-2~bpo8+1.
> Thank you!
> 
> [0] https://bugs.debian.org/861744
> [1] https://wiki.debian.org/TorBrowser#Debian_8_.22Jessie.22

The Release Team don't manage backports suites.

I'm not sure if removals from backports are handled by the FTP team or
the backports team directly, so reassigning to the former for now.

Regards,

Adam

Bug#880080: marked as done (stretch-pu: package pyqt5/5.7+dfsg-5+deb9u1)

[Debian Bug Tracking System]

Your message dated Sun, 17 Dec 2017 13:39:59 +0300
with message-id <20171217103959.gc3...@mitya57.me>
and subject line Re: Bug#880080: stretch-pu: package pyqt5/5.7+dfsg-5+deb9u1
has caused the Debian Bug report #880080,
regarding stretch-pu: package pyqt5/5.7+dfsg-5+deb9u1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
880080: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880080
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear stable release managers,

I would like to make a pyqt5 upload with one change: enable Qt WebEngine
support on two new architectures: armhf and mipsel.

Qt WebEngine became available on these architectures just 9 days before
Stretch release (in 5.7.1+dfsg-6.1 upload). Support for it in PyQt5 on ARM
is a demanded feature: there was bug #867733 about it (fixed in unstable in
August), and there is bug #879958 now, requesting a fix in stable.

A fix is very simple: s/amd64 i386/amd64 armhf i386 mipsel/ in a few places.
The debdiff is attached.

--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+pyqt5 (5.7+dfsg-5+deb9u1) stretch; urgency=medium
+
+  * Enable Qt WebEngine support for armhf and mipsel (closes: #879958).
+
+ -- Dmitry Shachnev   Sun, 29 Oct 2017 13:35:57 +0300
+
 pyqt5 (5.7+dfsg-5) unstable; urgency=medium
 
   * Make WebEngine packages depend on WebChannel, to avoid import errors.
--- a/debian/control
+++ b/debian/control
@@ -42,7 +42,7 @@ Build-Depends: debhelper (>= 9),
qtmultimedia5-dev (>= 5.7.0),
qtpositioning5-dev (>= 5.7.0),
qttools5-dev (>= 5.7.0),
-   qtwebengine5-dev (>= 5.7.1+dfsg-3~) [amd64 i386]
+   qtwebengine5-dev (>= 5.7.1+dfsg-3~) [amd64 armhf i386 mipsel]
 Build-Depends-Indep: fdupes, python3-sphinx (>= 1.3)
 X-Python-Version: >= 2.7
 X-Python3-Version: >= 3.3
@@ -246,7 +246,7 @@ Description: Python 3 bindings for Qt5's Webchannel module (debug extension)
  This package contains the extension built for the Python 3 debug interpreter.
 
 Package: python3-pyqt5.qtwebengine
-Architecture: amd64 i386
+Architecture: amd64 armhf i386 mipsel
 Depends: python3-pyqt5.qtwebchannel (= ${binary:Version}),
  ${misc:Depends},
  ${python3:Depends},
@@ -260,7 +260,7 @@ Description: Python 3 bindings for Qt5's WebEngine module
 Package: python3-pyqt5.qtwebengine-dbg
 Priority: extra
 Section: debug
-Architecture: amd64 i386
+Architecture: amd64 armhf i386 mipsel
 Depends: python3-dbg,
  python3-pyqt5.qtwebchannel-dbg (= ${binary:Version}),
  python3-pyqt5.qtwebengine (= ${binary:Version}),
@@ -688,7 +688,7 @@ Description: Python 2 bindings for Qt5's Webchannel module (debug extension)
  This package contains the extension built for the Python 2 debug interpreter.
 
 Package: python-pyqt5.qtwebengine
-Architecture: amd64 i386
+Architecture: amd64 armhf i386 mipsel
 Depends: python-pyqt5.qtwebchannel (= ${binary:Version}),
  ${misc:Depends},
  ${python:Depends},
@@ -702,7 +702,7 @@ Description: Python 2 bindings for Qt5's WebEngine module
 Package: python-pyqt5.qtwebengine-dbg
 Priority: extra
 Section: debug
-Architecture: amd64 i386
+Architecture: amd64 armhf i386 mipsel
 Depends: python-dbg,
  python-pyqt5.qtwebchannel-dbg (= ${binary:Version}),
  python-pyqt5.qtwebengine (= ${binary:Version}),
--- a/debian/rules
+++ b/debian/rules
@@ -35,7 +35,7 @@ PYTHON := 2.7
 ALLPYTHONS := $(PYTHON3S) $(PYTHON)
 
 DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
-QTWEBENGINE_ARCHS := amd64 i386
+QTWEBENGINE_ARCHS := amd64 armhf i386 mipsel
 
 PYQT_MODULES := opengl sql webchannel webkit websockets xmlpatterns svg \
 	multimedia quick serialport sensors x11extras positioning


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On Sat, Dec 02, 2017 at 01:33:59PM +0100, Julien Cristau wrote:
> Bug #879958 seems to actually request a fix in raspbian, not in debian
> stable.
>
> I'm not convinced this is suitable for stable.  OTOH I guess the worst
> that could happen is this doesn't work.  Has there been any testing
> (manual or automated) of the proposed packages on those architectures in
> stretch?

Sorry for the delayed response.

Indeed you are right, and it looks like Raspbian does not have Qt WebEngine
itself, so my upload in Debian won’t help them. So closing this bug.

--
Dmitry Shachnev


signature.asc

Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Jonas Meurer]

Hi there,

the upcoming upload of cryptsetup 2.0.0-1 will bump the libcryptsetup
soname from 4 to 12. According to (the very thoughtful) upstream, the
API (old functions) is backwards-compatible, so simple rebuilds of the
reverse depenencies should be enough.

Here's a list of reverse depends:

bruteforce-luks
cryptmount
libpam-mount
luksmeta
systemd
volume-key
libblockdev
zulucrypt

Debian-boot is Cc'ed as cryptsetup provides udebs, so debian-installer
is affected as well.

How shall we proceed? The package is ready to be uploaded. Shall we go
ahead? Will you (the Release Managers) trigger the binary rebuilds
afterwards? Or can/shall we do this ourselves?

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#884504: transition: gdal

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 15/12/17 23:11, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> For the Debian GIS team I'd like to transition to GDAL 2.2.3.
> 
> Like the previous transition to GDAL 2.2.2 (#876561), there is no SONAME
> bump, only the virtual ABI package changed to account for the C++ symbol
> changes.
> 
> All reverse dependencies rebuilt successfully with GDAL 2.2.3 from
> experimental as summarized below.
> 
> libgdal-grass doesn't need a binNMU as the 2.2.3 version will be
> uploaded to unstable instead. liblas likewise doesn't need a binNMU,
> the version is experimental will be moved to unstable instead.

Go ahead.

Emilio

Processed: Re: Bug#884504: transition: gdal

[Debian Bug Tracking System]

Processing control commands:

> tags -1 confirmed
Bug #884504 [release.debian.org] transition: gdal
Added tag(s) confirmed.

-- 
884504: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884504
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems