Bug#890506: stretch-pu: package ntp/1:4.2.8p10+dfsg-3+deb9u2

[Bernhard Schmidt]

On 23.02.2018 18:44, Adam D. Barratt wrote:

Hi Adam,

> On Thu, 2018-02-15 at 12:55 +0100, Bernhard Schmidt wrote:
>> I'd like to update ntp in Stretch to fix Bug#887385. There have been
>> numerous
>> reports about ntpd segfaulting with the libc6 update from
>> stretch-proposed-updates or in sid. It does not happen on all
>> machines (I for
>> one did not see it once).
>>
>> There has been an upstream bug and an upstream patch to increase the
>> stack size. This patch has been part of sid/buster for some weeks now
>> and
>> one of the reporters on the bug confirmed it being fixed.
>>
> 
> Please go ahead.

Uploaded and ACCEPTed.

Bernhard

Bug#891346: RM: jirc/1.0-1

[Adrian Bunk]

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

I confirmed the information in #800450 that jirc
works with the version of libpoe-filter-xml-perl
in wheezy (sic).

With the version of libpoe-filter-xml-perl in jessie
and stretch it fails pretty early even on --help.

Bug#890935: transition: console-bridge

[Jose Luis Rivero]

uploaded to unstable.

On 23 Feb 2018 13:51, "Emilio Pozuelo Monfort"  wrote:

> Control: tags -1 confirmed
>
> On 23/02/18 12:14, Jose Luis Rivero wrote:
> > On 23/02/18 10:13, Emilio Pozuelo Monfort wrote:
> >>>
> >>> Please schedule binNMUs for the above mentioned packages on all
> >>> architectures.
> >>
> >> First you need to upload console-bridge to unstable. Before doing that,
> have you
> >> tested that those packages build fine with the new console-bridge?
> >>
> >
> > I ran ratt against the changes file and all the packages listed above
> > passed the build in experimental (same versions than unstable) without
> > any error. I assume that the next step is upload console-bridge to
> > unstable.
>
> Yes, go ahead.
>
> Emilio
>

Bug#884571: [Pkg-privacy-maintainers] Bug#884571: RM: torbrowser-launcher/0.1.9-1+deb8u3

[intrigeri]

Adam D. Barratt:
> # Broken Depends:
> onionshare/contrib: onionshare

So I guess Jessie should first get the fix we applied to onionshare in
testing/sid, i.e. move torbrowser-launcher to Recommends.

Re: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Wed, Feb 21, 2018 at 11:14:24AM -0800, Steve Langasek wrote:
> Hi again,
> 
> On Tue, Feb 20, 2018 at 06:16:34PM -0800, Steve Langasek wrote:
> > So, despite Julien's valid objection that core library conflicts cause
> > dist-upgrades to be more brittle, I think the right answer here is:
> 
> > - keep all sonames as-is.
> > - rename libcurl3 to libcurl4.
> > - leave the package names of the other variants as-is.
> > - *if* libcurl-gnutls.so.4 and libcurl-nss.so.4 sonames are known to exist
> >   elsewhere outside the Debian ecosystem, fix the symbol versions for
> >   libcurl3-gnutls and libcurl3-nss to use symbol aliases, so that CURL_FOO_4
> >   is used as the preferred name and CURL_FOO_3 is for compatibility only.
> >   (This is only worth doing if this increases binary compatibility;
> >   otherwise it's better to maintain bidirectional binary compatibility for
> >   Debian-built binaries.)
> > - change the symbol versions for libcurl4 to CURL_OPENSSL_4.
> 
> > I would be willing to prepare a patch that implements this.
> 
> I've done this now and raised an MP:
> 
>   https://salsa.debian.org/debian/curl/merge_requests/3
> 
> (I'm assuming there is no point in CURL_FOO_4 symbol version for
> libcurl-gnutls and libcurl-nss, because these sonames come from a
> Debian-specific patch and therefore there's no upstream binary compatibility
> to be concerned about.)
> 
> Thoughts on this?
> 
> In terms of ABI changes, this appears to be a strict subset of what
> Alessandro had proposed and would be binary-compatible for libcurl.so.4; so
> at minimum, we will probably adopt this change in Ubuntu and proceed with
> the transition ASAP there, even if Debian later decides to change the ABI
> for gnutls and nss variants also.

I'm fine with going ahead with just the libcurl3 -> libcurl4 transition for
now.

Julien: is this something that the Release Team would be ok with? As Steve
pinted out before, libcurl3 has significantly lower usage than lubcurl3-gnutls
so impact should be somewhat more limited.

I'd like to go ahead and upload Steve's patch to experimental (which means NEW
queue) soon, and then request the transition.

Cheers


signature.asc
Description: PGP signature

Bug#891285: stretch-pu: package inputlirc/23-2+b2

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hello release team,

with maintainer's permission (Cc'd, see #879458) I'd like to fix the
inputlirc package in the upcoming stretch point release, see debdiff
below.

Some background if I understood correctly: During build, inputlirc picks
some information from a kernel header file. However, that header file
was split in linux kernel commit v4.3-rc4-49-gf902dd893427, subsequently
some definitions were no longer found. Obviously, the binNMU leading to
23-2+b2 was already done after the kernel header package in Debian
was updated, resulting the the described behaviour.

Kind regards,

Christoph
diff -u inputlirc-23/debian/changelog inputlirc-23/debian/changelog
--- inputlirc-23/debian/changelog
+++ inputlirc-23/debian/changelog
@@ -1,3 +1,10 @@
+inputlirc (23-2+deb9u1) stretch; urgency=medium
+
+  * Include input-event-codes.h instead of input.h. Closes: #879458
+Thanks to Ingo Schneider for reporting the bug and providing the fix.
+
+ -- Christoph Biedl   Sat, 24 Feb 2018 
09:25:27 +0100
+
 inputlirc (23-2) unstable; urgency=medium
 
   * Set Architecture: linux-any, since inputlirc depends on the Linux input
only in patch2:
unchanged:
--- inputlirc-23.orig/Makefile
+++ inputlirc-23/Makefile
@@ -27,7 +27,7 @@
 
 all: $(SBIN)
 
-names.h: /usr/include/linux/input.h gennames
+names.h: /usr/include/linux/input-event-codes.h gennames
./gennames $< > $@
 
 inputlircd: inputlircd.c /usr/include/linux/input.h names.h


signature.asc
Description: PGP signature