Bug#921031: Dpkg::Source::Package missing use of ::Format

[Adam Conrad]

Package: dpkg
Version: 1.19.4
Followup-For: Bug #921031
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch



In Ubuntu, the attached patch was applied to achieve the following:

  * scripts/Dpkg/Source/Package.pm: use Dpkg::Source:Format (closes: #921031)

Simple enough patch, this seems to resolve the dgit autopkgtest
regressions for us.

... Adam

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

Kernel: Linux 4.19.0-13-lowlatency (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru dpkg-1.19.4ubuntu2/debian/control dpkg-1.19.4ubuntu3/debian/control
--- dpkg-1.19.4ubuntu2/debian/control   2019-02-18 07:21:59.0 -0700
+++ dpkg-1.19.4ubuntu3/debian/control   2019-02-19 07:37:22.0 -0700
@@ -1,8 +1,7 @@
 Source: dpkg
 Section: admin
 Priority: required
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Dpkg Developers 
+Maintainer: Dpkg Developers 
 Uploaders: Guillem Jover 
 Origin: debian
 Bugs: debbugs://bugs.debian.org
diff -Nru dpkg-1.19.4ubuntu2/scripts/Dpkg/Source/Package.pm 
dpkg-1.19.4ubuntu3/scripts/Dpkg/Source/Package.pm
--- dpkg-1.19.4ubuntu2/scripts/Dpkg/Source/Package.pm   2019-01-23 
05:04:28.0 -0700
+++ dpkg-1.19.4ubuntu3/scripts/Dpkg/Source/Package.pm   2019-02-19 
07:37:16.0 -0700
@@ -56,6 +56,7 @@
 use Dpkg::Path qw(check_files_are_the_same find_command);
 use Dpkg::IPC;
 use Dpkg::Vendor qw(run_vendor_hook);
+use Dpkg::Source::Format;
 
 my $diff_ignore_default_regex = '
 # Ignore general backup files

Bug#859553: pidentd: Please migrate to openssl1.1 in buster

[Moritz Muehlenhoff]

On Wed, Feb 20, 2019 at 12:28:48AM +0100, Sebastian Andrzej Siewior wrote:
> On 2017-10-12 23:44:37 [+0200], To 859...@bugs.debian.org wrote:
> > this is a remainder about the openssl transition [0]. We really want to
> > remove libssl1.0-dev from unstable for Buster. I will raise the severity
> > of this bug to serious in a month. Please react before that happens.
> 
> There has been no action on pidentd and it is out of testing during
> soft-freeze. Should there be a RM bug filled? We do have alternative
> ident daemons in the archive. This package is holding back the removal
> of openssl 1.0.2 in the archive.

Or alternatively we can simply drop the idecrypt binary package, and remove
--with-des* from the configure (and the build dep). I doubt anyone really
uses the DES feature of ident...

Cheers,
Moritz

Bug#922667: beep: Error: could not open any device

[jim_p]

Package: beep
Version: 1.4.3-1
Followup-For: Bug #922667

Dear Maintainer,

I tried adding my user to the beep group, but nothing changed. Then I read
everything in /usr/share/doc/beep/INSTALL.md and here are my thoughts,

Before adding my user to the beep group, I had to create that group. I did
that, but still no beep. Why?

Because before making the group, I had to make the relevant udev rule. I
created it too, I rebooted, bust still no beep. Why?

Because I also had to change the device permissions, but I have no idea how to
to that. I tried whatever is suggested in the instructions but all I get is
this bit

# ls -lH /dev/input/by-path/platform-pcspkr-event-spkr
crw-rw 1 root input 13, 67 Feb 20 09:00 /dev/input/by-path/platform-pcspkr-
event-spkr

# getfacl /dev/input/by-path/platform-pcspkr-event-spkr
getfacl: Removing leading '/' from absolute path names
# file: dev/input/by-path/platform-pcspkr-event-spkr
# owner: root
# group: input
user::rw-
group::rw-
other::---

Maybe I am doing something wrong. But I think most, if not all, of this stuff
can be ommited if you provide the udev rule, make the group and change the
device permissions upon the install of the package.
On top of that, I think all that setup is a tedius job for something that, for
me at least, is used for a few milliseconds each time (I use beep to make an
audible notification for when transmission-daemon completes a download). The
1.3.x version was literally plug-n-play, because, after installing it, I could
use pcspkr with it instantly, with no extra setup at all.



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

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages beep depends on:
ii  libc6  2.28-7

beep recommends no packages.

beep suggests no packages.

-- no debconf information

Bug#922692: galax: FTBFS on ppc64el - ERROR: unable to find camomileLibrary.cmi in /usr/lib/ocaml/camomile

[Ralf Treinen]

On Tue, Feb 19, 2019 at 03:31:21PM +0100, Thierry fa...@linux.ibm.com wrote:
> Package: galax
> Version: 1.1-15
> Severity: important
> 
> Compilation on ppc64el fails with the message
> 
> ERROR: unable to find camomileLibrary.cmi in /usr/lib/ocaml/camomile

Thanks for your bug report. This is in fact the case on all
architectures, not only ppc64el.

-Ralf.

Bug#922731: llvm-toolchain-7: Unjustified API breakage introduced by Debian patch

[Sylvestre Ledru]

Hello,

Le 20/02/2019 à 00:07, A.C. a écrit :

Source: llvm-toolchain-7
Severity: important

Dear Maintainer,
A recently merged patch that introduced support for KFreeBSD broke the API
compatibility by introducing pointless renamings of enumeration values (KFreeBSD
to kFreeBSD) and classes/structures.

This change is not purely cosmetic and actively breaks any software that's
making use of the aforementioned enums/struct/classes.

My suggestion is to either amend the patches and be more careful in future in
order to avoid this kind of silly breakage.


Would you have a testcase which shows the issue? This to make sure we 
don't regress again

in the future.

Svante, should I just revert the patches?

Thanks

S

Bug#921914: minissdpd: Lots of "Address already in use" syslog messages (again)

[Yangfl]

On Sun, 10 Feb 2019 08:54:19 +0100 Matijs van Zuijlen  wrote:
> Package: minissdpd
> Version: 1.5.20180223-5
> Severity: normal
>
> Dear maintainer,
>
> With the most recent upgrade of minissdpd, the 'Address already in use'
> messages from #903783 seem to have returned. They now appear every five
> minutes or so:
>
> Feb  9 17:02:58 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:02:58 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:02:58 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:03:01 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:03:01 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:03:01 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:03:09 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:03:09 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:03:09 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:11:18 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:11:18 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
> Feb  9 17:11:18 bean minissdpd[2321]: setsockopt(udp, 
> IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
>
> I do not recall consciously having set the MiniSSDPd_INTERFACE_ADDRESS
> option, which was modified on 2019-02-08, it seems when the latest
> release was installed. Maybe this has something to do with it?
>
> Regards,
> Matijs
>

No idea. Could you please attach an example of log, 'ip a' 'ip r'
'sudo netstat -anup' output, and its corresponding wireshark capture?

Bug#686442: initscripts: This failed update completely breaks dpkg

[Roger Leigh]

On 20/02/2019 01:56, Pierre Ynard wrote:

This isn't an issue in initscripts, and I think it wouldn't even be
possible to add Breaks statements against offending unpurged packages;
so not much can be done here. The offending initscripts are either from
the local administrator or from obsolete package versions, so I don't
see any point in reassigning the bug either.


Given the number of warnings about the lack of LSB headers,h the init 
scripts themselves.  It's solely due to update-rc.d/insserv erroring out 
when *configuring* the initscripts.  It would have broken for any 
package configuration step which invoked update-rc.d.


It's clear this system was using nonconforming scripts, be they custom 
ones, customised Debian scripts, or out of date Debian scripts from 
older versions of the packages.  In this timeframe (2012), we had made 
LSB headers essentially mandatory.  The cause is a dependency loop from 
the xfree86-common package, which hasn't existed for a long time now 
with the switch to xorg.


The solution here would have been to purge the system (dpkg --purge) of 
all *obsolete* packages, thereby removing all the LSB dependency 
warnings from stale init scripts hanging around.  And if there are any 
custom packages, to add an LSB header to them.


As far as I can tell, this bug never had anything to do with initscript 
itself, and the correct action was for the admin to tidy the system, so 
I think this can be safely closed at this point.



Kind regards,
Roger

Bug#588070: urandom: Syntax error on line 76 in /etc/init.d/urandom .(:) After remove that urandom scropt works fine.

[Pierre Ynard]

> I fail to see any typos in my copy of the script. Can you provide more
> details? Is this the same as #587665 fied in -11?

This was most likely a duplicate of #587665, and without other
information there is nothing we can do. I think we should merge and/or
close this.

-- 
Pierre Ynard

Bug#922740: odb-api: ODB-API fails to compile with Flang Fortran compiler

[Alastair McKinstry]

Source: odb-api
Severity: wishlist

Dear Maintainer,

Please make it possible to compile with Flang.

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_IE.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#922739: r-cran-vegan: autopkgtest regression

[Graham Inggs]

Source: r-cran-vegan
Version: 2.5-4+dfsg-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of 2.5-4+dfsg-1, r-cran-vegan has been failing its
own autopkgtests [1] with the following error:

autopkgtest [15:46:18]: test run-unit-test: [---
gzip: *.gz: No such file or directory
autopkgtest [15:46:18]: test run-unit-test: ---]
autopkgtest [15:46:18]: test run-unit-test:  - - - - - - - - - -
results - - - - - - - - - -
run-unit-testFAIL non-zero exit status 1

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-vegan/unstable/amd64/

Bug#922715: debbugs: b.d.o/release-critical/britney/testing-nr wrongly reports RC bugs when reported against two packages

[Don Armstrong]

On Tue, 19 Feb 2019, Paul Gevers wrote:
> Britney is using RC bugs to determine if package may migrate from
> unstable to testing. If an RC bug is only in unstable and not in
> testing, the package is not allowed to migrate. However, in the above
> case simplejson is listed in both
> https://bugs.debian.org/release-critical/britney/testing-nr
> and
> https://bugs.debian.org/release-critical/britney/unstable-nr
> 
> Can you please have a look at it? I wanted to mark the failure as
> skiptest, because I expect the bug to be assigned to
> json-schema-validator in 10 days from now, and was counting on the RC
> bug to block simplejson from migrating.

So this is a case where we're using the status of the bug (present in
testing) and then reversing it to apply to all of the packages to which
the bug is assigned.

We don't really have a good way to state that a bug assigned to multiple
packages should apply to the intersection of all of the
versions/packages listed (which is what you're looking for) rather than
the OR of all the versions/packages listed (which is what the BTS does
by default).

Hopefully that clears things up; I don't expect that I'll get around to
adding the AND/OR feature to versions any time soon, so in the meantime
I'd just file a separate bug if you want to be sure that a package
doesn't transition if one of the set already has.

-- 
Don Armstrong  https://www.donarmstrong.com

Do not handicap your children by making their lives easy.
 -- Robert Heinlein _Time Enough For Love_ p251

Bug#922430: only

[Gürkan Myczko]

only if the interface starts with a digit, otherwise you get a nice 
error msg :)

Bug#922723: RM: conserver -- RoQA; RC-buggy, depends on openssl 1.0

[Salvatore Bonaccorso]

Hi Sebastian

On Wed, Feb 20, 2019 at 12:28:39AM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-02-19 22:32:59 [+0100], Moritz M??hlenhoff wrote:
> > Someone should NMU it soon, then. We're down to four remaining packages
> > using OpenSSL 1.0 and this will not drag for more than a few weeks, the
> > openssl1.0 is already going on for ages.
> 
> Someone just did.

Thank you!

(Closing the RM bug then, too bad we missed the window when the fix
was released and the soft-freeze, so it would have been eliglible to
re-enter testing for buster).

Regards,
Salvatore

Bug#922736: texlive-pictures: TikZ libraries spath3, knots, and calligraphy produce errors

[Norbert Preining]

On Wed, 20 Feb 2019, Dylan Thurston wrote:
> I opened this bug because I thought this might be a candidate for
> "small targeted fixes", per the soft freeze policy. It would be an
> update to one TeXlive package, that is currently broken.

Updates to texlive packages cannot (easily) be done only for one single
package like the one you mentioned. One would need to either patch the
sources, or include the changed files in the .debian.tar.gz
I usually do full updates of all of TL from the current tlnet.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#922738: ITP: pmdk-convert -- convert pmdk/pmemobj pools to a given on-memory format

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: pmdk-convert
  Version : 1.5.1
  Upstream Author : Intel
* URL : https://github.com/pmem/pmdk-convert
* License : BSD-3
  Programming Lang: C, C++
  Description : convert pmdk/pmemobj pools to a newer on-memory format
 The on-memory format of data pools used by libpmemobj is not compatible
 between major releases, and the library doesn't currently support automatic
 conversion.  Such upgrades need to be done manually, by this tool.

Bug#697003: initscripts: postinst fails: mv /dev/shm/* misses dot (hidden) files

[Pierre Ynard]

Hello,

While I think there were certainly good points raised about issues with
it, that mv code to migrate /{dev,run}/shm and contents in postinst was
long removed, and nowadays is only left code to set up directories and
symlinks at bootup, when they're still empty. All this `mv /run/shm/*
/dev/shm` stuff was removed 5 years ago in:

https://salsa.debian.org/debian/sysvinit/commit/e58f3742cc303fd1563e6cf046661e892b97181a

> debian: Clean up legacy migration logic in maintainer and init scripts

So I think this issue is mostly long resolved.

However there is one point that I can confirm can still be seen
today: it was pointed out that /dev/shm/.tmpfs shouldn't exist
after boot, yet it still does. It is indeed still created by
mount_shm() in /lib/init/mount-functions.sh, but not cleaned up by
/etc/init.d/bootmisc.sh

Anybody can clear up what to think of this today?

> > # Remove bootclean's flag files.
> > # Don't run bootclean again after this!
> > rm -f /tmp/.clean /lib/init/rw/.clean /run/.clean /run/lock/.clean
> > rm -f /tmp/.tmpfs /lib/init/rw/.tmpfs /run/.tmpfs /run/lock/.tmpfs
> >
> > While here - could neaten this up a little:
> >
> > for dir in /lib/init/rw /tmp /run /run/lock /run/shm; do
> > rm -f "$dir/.clean" "$dir/.tmpfs"
> > done
>
> That's much better, thanks.

This proposed snippet could still be relevant (apart from the part about
/lib/init/rw which doesn't exist anymore).

-- 
Pierre Ynard

Bug#922737: lintian rarely hangs

[Felix Lechner]

Hi Helmut,

I have also had this problem since December and hoped no one would
notice. Personally, I think it is related to Perl 5.28.1-3, but I am
not sure.

We also recently added a parallel collection that may have a race
condition. I will look at it in the coming days. Thank you for your
diligence in reporting this.

Kind regards,
Felix Lechner


On Tue, Feb 19, 2019 at 9:15 PM Helmut Grohne  wrote:
>
> Package: lintian
> Version: 2.6.0
> Severity: important
> User: helm...@debian.org
> Usertags: rebootstrap
>
> I use lintian to detect wrongly cross built packages. In this setup,
> lintian is run by sbuild inside the (unstable) schroot after the build.
> I pass "-T
> binary-from-other-architecture,triplet-dir-and-architecture-mismatch" to
> lintian and it all works fine ... most of the time.
>
> In roughly 1/2000 builds, lintian hangs. Now the bad part is that I have
> little details on what is going on here.
>
>  * A process list shows just "lintian" without any command line flags.
>  * lintian has a zombie chiled called "[rm]".
>  * lintian has the following file descriptors:
>+ 0 is /dev/null inherited from the sbuild invocation
>+ 1 and 2 are the same writable pipe (presumably to sbuild)
>+ 3 is /dev/null (inside the schroot) for writing
>+ 4 and 5 are the read and write ends of a pipe
>+ 6 is /usr/share/perl5/Net/DNS/Resolver/Base.pm inside the schroot
>  * It already happend with 2.6.0 and continues to happen with 2.7.0.
>  * Attaching the hanging lintian with strace only yields
>restart_syscall.
>
> Given the 1/2000 builds nature, it takes a while (days) to reproduce.
> I'll leave one such hanging process around for a while in case you have
> ideas on how to debug this.
>
> Helmut
>

Bug#922736: texlive-pictures: TikZ libraries spath3, knots, and calligraphy produce errors

[Dylan Thurston]

On Wed, Feb 20, 2019 at 01:32:54PM +0900, Norbert Preining wrote:
> Hi
> 
> > The spath3 library has recently (2019-02-12) been updated to fix this.
> 
> Thanks, unfortunately I cannot upload new packages to Debian, and Buster
> is already in freeze. If it is important for you, please see
> intermediate packages as described here:
>   https://www.preining.info/blog/2019/01/debian-updates/
> The latest build is from 2019-02-19

I opened this bug because I thought this might be a candidate for
"small targeted fixes", per the soft freeze policy. It would be an
update to one TeXlive package, that is currently broken.

Bug#921156: etcd: CVE-2018-1098 CVE-2018-1099

[Stephen Gelman]

On Tue, 12 Feb 2019 09:32:48 +0700 Arnaud Rebillout
 wrote:
> I looked into this a bit yesterday.
>
> As mentioned in the issue upstream at
> https://github.com/etcd-io/etcd/issues/9353, the fix has been merged in
> the master branch of etcd in March 2018, almost a year ago. The
> conversation also mentions that this will be part of the next release
> v3.4. However v3.4 has not been released yet.
>
> And I don't think we want to package a random commit from the master
> branch of etcd. So if we want to solve this bug simply by updating the
> package, we'll have to wait for v3.4 to be released.
>
> The other alternative is to cherry-pick the patch.
>
> If I'm not mistaken, the fix can be found in this MR:
> https://github.com/etcd-io/etcd/pull/9372/files. It's not a trivial
> patch. It's unlikely that we can apply it without modification on the
> etcd currently packaged in debian.
>
> I personally can't do that, as I know nothing about etcd anyway. I don't
> know if someone feels up to the task, or have a better idea about how to
> solve that.
>
> Cheers,
>
>   Arnaud

Since upstream still hasn't released a version that fixes the CVE is
this still considered a RC bug?  Obviously it's better to fix it asap
but if upstream doesn't consider it critical I'm not sure this should
be RC.

Stephen

Bug#900671: progress still FTCBFS

[Helmut Grohne]

Control: reopen 900671

progress still fails to cross build, because the patch was incorrectly
applied. The patch asked to include "buildtools.mk", but what ended up
being included is "buildflags.mk". Thus PKG_CONFIG is literally
"pkg-config" rather than set up by buildtools.mk.

Helmut

Bug#909229: closed by Christopher Schramm (Bug#909229: fixed in blueman 2.0.8-1)

[Christopher Schramm]

Recent changes in upstream master make blueman compatible with 
adwaita-icon-theme and papirus-icon-theme. blueman 2.0 is not.


tango-icon-theme is not compatible at all.

Bug#922737: lintian rarely hangs

[Helmut Grohne]

Package: lintian
Version: 2.6.0
Severity: important
User: helm...@debian.org
Usertags: rebootstrap

I use lintian to detect wrongly cross built packages. In this setup,
lintian is run by sbuild inside the (unstable) schroot after the build.
I pass "-T
binary-from-other-architecture,triplet-dir-and-architecture-mismatch" to
lintian and it all works fine ... most of the time.

In roughly 1/2000 builds, lintian hangs. Now the bad part is that I have
little details on what is going on here.

 * A process list shows just "lintian" without any command line flags.
 * lintian has a zombie chiled called "[rm]".
 * lintian has the following file descriptors:
   + 0 is /dev/null inherited from the sbuild invocation
   + 1 and 2 are the same writable pipe (presumably to sbuild)
   + 3 is /dev/null (inside the schroot) for writing
   + 4 and 5 are the read and write ends of a pipe
   + 6 is /usr/share/perl5/Net/DNS/Resolver/Base.pm inside the schroot
 * It already happend with 2.6.0 and continues to happen with 2.7.0.
 * Attaching the hanging lintian with strace only yields
   restart_syscall.

Given the 1/2000 builds nature, it takes a while (days) to reproduce.
I'll leave one such hanging process around for a while in case you have
ideas on how to debug this.

Helmut

Bug#734717: tasksel not installing task--desktop - confirmed

[Holger Wansing]

Control: tags -1 + confirmed

Using the correct syntax for tagging



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#922736: texlive-pictures: TikZ libraries spath3, knots, and calligraphy produce errors

[Norbert Preining]

Hi

> The spath3 library has recently (2019-02-12) been updated to fix this.

Thanks, unfortunately I cannot upload new packages to Debian, and Buster
is already in freeze. If it is important for you, please see
intermediate packages as described here:
https://www.preining.info/blog/2019/01/debian-updates/
The latest build is from 2019-02-19

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#922177: ubuntu-keyring: invalid symlink if select two or more (postinst script loop loops only once (SC2066))

[Hiroyuki YAMAMORI]

Dear Maintainer,

Taking bug #922176 into account, it works well with the following code.

debian/ubuntu-keyring.postinst: line 5
```
case "$1" in
install|configure)

  TRUSTEDPARTS="/etc/apt/tusted.gpg.d/"
  eval "$(apt-config shell TRUSTEDPARTS Dir::Etc::trustedparts/d)"

  # purge old setting before package renaming
  # from ubuntu-archive-keyring to ubuntu-keyring
  if [ -d /usr/share/doc/ubuntu-archive-keyring ]; then
rm -f "${TRUSTEDPARTS}ubuntu-archive-keyring.gpg" \
  "${TRUSTEDPARTS}ubuntu-archive-removed-keys.gpg"
  fi

  . /usr/share/debconf/confmodule
  db_version 2.0
  db_get ubuntu-keyring/keyring

  rm -f "${TRUSTEDPARTS}ubuntu-keyring-2018-archive.gpg" \
"${TRUSTEDPARTS}ubuntu-keyring-2012-archive.gpg" \
"${TRUSTEDPARTS}ubuntu-archive-removed-keys.gpg"

  if [ -n "$RET" ]; then
selected=$(echo "$RET" | sed -e 's/, /\n/g')
echo "$selected" | while read keyring
do
  ln -sf "/usr/share/keyrings/${keyring}.gpg" "$TRUSTEDPARTS"
done
  fi
```

Thank you,
Hiroyuki YAMAMORI

Bug#750011: re

[Johann Reimann]

My Name is Johann Reimann and i have something important to discuss with you 
but only with your permission i will proceed.

Regards
J. Reimann

Bug#921598: fixed in simgear 1:2018.3.2+dfsg-5

[Gabriel F. T. Gomes]

On Sun, 17 Feb 2019 20:54:34 + to...@debian.org (Dr. Tobias Quathamer) 
wrote:
> Source: simgear
> Source-Version: 1:2018.3.2+dfsg-5
> 
> We believe that the bug you reported is fixed in the latest version of
> simgear, which is due to be installed in the Debian FTP archive.

Thanks for this simgear fix.

I tested that rebuilding flightgear with this dependency updated solves
the METAR problem.  Do you plan to upload a new binary version of
flightgear, too?  (I'm asking because the flightgear package currently
on the archives still has the problem (probably because it needs to be
rebuilt - should a rebuild happen automatically?)).

Bug#922019: cdimage.debian.org: Non-free live builds missing contrib and non-free components

[Steve McIntyre]

On Sat, Feb 16, 2019 at 10:25:01PM -0600, Daniel Lewart wrote:
>Steve,
>
>> Right, that's as expected. The only non-free bit about those images is
>> that they include some non-free firmware packages too. Otherwise
>> they're just the same as the normal free images. Is there a problem
>> with that?
>
>Yes, a minor one.  Especially for Buster, I expect "apt update; apt upgrade"
>to install available upgrades for all packages, including firmware.

ACK, fair point. I'll take a look...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#650501: slapd headers status

[Ryan Tandy]

Control: forwarded -1 http://www.openldap.org/its/?findid=8982

Update since this came up again in IRC:

slapd.h, portable.h, and other generated headers such as config.h are 
"private and subject to change without notice" [ITS#7283]. IMO that 
makes them unsuitable for shipping in a Debian package unless we somehow 
arrange for external builds to have strict dependencies the exact build 
of openldap that provided the header.


The requests for a more public interface for slapd plugins have been 
noted in the past, and raised again now as [ITS#8982].


[ITS#7283] http://www.openldap.org/its/?findid=7283
[ITS#8982] http://www.openldap.org/its/?findid=8982

Bug#798104: #798104 Segmentation fault when running selection example

[Thomas Dickey]

On Wed, Feb 20, 2019 at 12:07:17AM +0100, Javier Barroso wrote:
> Hello,
> 
> On Tue, Feb 19, 2019 at 11:33 PM Thomas Dickey  wrote:
> 
> > I was not able to reproduce this when it was reported, nor can I reproduce
> > it using the same source now (and same applies to the current packages).
> >
> Now it works on my laptop too, maybe a temporal problem by the time. So I'm
> closing this bug report
> 
> Now, the example should be fixed, removing defined keyword, as advised:
> $ perl /usr/share/doc/libcdk-perl/examples/examples/selection
> Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at
> /usr/share/doc/libcdk-perl/examples/examples/selection line 37.

yes - I did that a couple of days ago (there were 2-3 of those)
 
> Thank you for your Debian work !

no problem (report bugs)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#686442: initscripts: This failed update completely breaks dpkg

[Pierre Ynard]

This isn't an issue in initscripts, and I think it wouldn't even be
possible to add Breaks statements against offending unpurged packages;
so not much can be done here. The offending initscripts are either from
the local administrator or from obsolete package versions, so I don't
see any point in reassigning the bug either.

Can we close this?

-- 
Pierre Ynard

Bug#919383: supercollider: unbuildable on several architectures due to qtwebengine5-dev

[Горбешко Богдан]

Hi. Why did the package start depending on QtWebEngine at all? I had to 
hold it because of that. If I got the upstream README correctly, 
QtWebEngine is needed only for IDE, which is in another package.

Bug#922736: texlive-pictures: TikZ libraries spath3, knots, and calligraphy produce errors

[Dylan Thurston]

Package: texlive-pictures
Version: 2018.20190131-1
Severity: normal

Dear Maintainer,

The TikZ library 'spath3' uses illicit variant forms, and stops with a
warning. As a result, the 'knots' and 'calligraphy' libraries are also
broken, and should not be released as-is. Details here:
https://tex.stackexchange.com/questions/408378/warning-with-tikzlibrary-calligraphy

The spath3 library has recently (2019-02-12) been updated to fix this.

##
minimal input file

\documentclass{article}

\usepackage{tikz}
\usetikzlibrary{knots}

\begin{document}
Testing.
\end{document}

##
 List of ls-R files

-rw-r--r-- 1 root root 1289 Feb  2 19:29 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Sep  2 08:32 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jan 30 22:53 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jan 30 22:53 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Sep  4 14:08 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Jan 30 22:53 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Jan 30 22:53 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3032 Feb  2 19:29 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 16  2017 mktex.cnf
-rw-r--r-- 1 root root 475 Sep  4 14:08 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.utf8 (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)
LSM: AppArmor: enabled

Versions of packages texlive-pictures depends on:
ii  python 2.7.15-4
ii  tex-common 6.10
ii  texlive-base   2018.20190131-1
ii  texlive-binaries   2018.20181218.49446-1
ii  texlive-latex-recommended  2018.20190131-1

Versions of packages texlive-pictures recommends:
ii  ruby  1:2.5.1
ii  tk8.6.0+9

Versions of packages texlive-pictures suggests:
pn  dot2tex 
pn  prerex  
pn  ruby-tcltk | libtcltk-ruby  
ii  texlive-latex-extra 2018.20190131-1
ii  texlive-pictures-doc2018.20190131-1
pn  vprerex 

Versions of packages tex-common depends on:
ii  dpkg  1.19.4
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
ii  debhelper  12.1

Versions of packages texlive-pictures is related to:
ii  tex-common6.10
ii  texlive-binaries  2018.20181218.49446-1

-- no debconf information

Bug#922735: aptitude truncates the version number in the visual interface

[Vincent Lefevre]

Package: aptitude
Version: 0.8.11-7
Severity: normal

aptitude truncates the version number of packages, even when the
window width is large:

i A --\ wpasupplicant   

 
2:2.7+git20190128+0c1e29 2:2.7+git20190128+0c1e29

They should be respectively:
  2:2.7+git20190128+0c1e29f-1
  2:2.7+git20190128+0c1e29f-2

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.11
Compiler: g++ 8.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20181013
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7ffcb51dc000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7f0e7ca93000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f0e7c8bd000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f0e7c883000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f0e7c855000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f0e7c84c000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f0e7c746000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f0e7c622000)
libboost_iostreams.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f0e7c604000)
libboost_system.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f0e7c5fd000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f0e7c3d2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f0e7c3b1000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f0e7c22d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f0e7c0a8000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f0e7c08e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0e7becd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0e7bec8000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f0e7beae000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f0e7bc9)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f0e7bc7b000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f0e7bc53000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f0e7bc34000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7f0e7bb94000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f0e7bb6e000)
/lib64/ld-linux-x86-64.so.2 (0x7f0e7d0f6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f0e7bb62000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f0e7bb59000)

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.11-7
ii  libapt-pkg5.0 1.8.0~rc3
ii  libboost-iostreams1.67.0  1.67.0-13
ii  libboost-system1.67.0 1.67.0-13
ii  libc6 2.28-7
ii  libcwidget3v5 0.5.17-11
ii  libgcc1   1:8.2.0-21
ii  libncursesw6  6.1+20181013-2
ii  libsigc++-2.0-0v5 2.10.1-2
ii  libsqlite3-0  3.27.1-1
ii  libstdc++68.2.0-21
ii  libtinfo6 6.1+20181013-2
ii  libxapian30   1.4.10-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-13
ii  sensible-utils 0.0.12

Versions of packages aptitude suggests:
ii  apt-xapian-index0.49
ii  aptitude-doc-en [aptitude-doc]  0.8.11-7
pn  debtags 
ii  tasksel 3.50

-- no debconf information

Bug#922711: lxqt-branding-debian: lxqt-config-appearance unable to set lxqt-panel icons

[Alf Gaida]

Ok - thanks for the clarification - so it is not a bug, it's a feature 
:D - really.


It is damn hard to combine a dark panel and menu with the rest of the 
system in lighter colors, so the panel can have it's own icon set 
activated.


So - for the dark panel i set the panel override as shown in the 
picture: https://i.imgur.com/LjYw7oL.png


Without the override it would look like this:
https://i.imgur.com/LjYw7oL.png or
https://i.imgur.com/9Xeyrmb.png some icons will look really bad. Call it 
compromize.


Panel is right and applications not or vice versa - it depends on the 
icon theme, a theme that work nearly right is oxygen - downside is:


https://i.imgur.com/9Xeyrmb.png

One see the themes age and i don't think it fits well for a modern 
Desktop environment, to be honest, i can't stand it anymore - the Plasma 
guys likely see this this way too, they developed Breeze as replacement. 
Another theme that works fine nearly without glitches is the faenza 
theme, right now the modern themes like breeze or papirus icons need 
this this trick.


Thanks again for your report, i hope it clarify the situation a bit.

Cheers Alf

Bug#902658: Antworten Sie auf meine E-Mail-Adresse jian...@wang-wandagroup.com

[Le-griguer Fatima]

Ich beabsichtige, Ihnen einen Teil meines Vermögens als freiwillige finanzielle 
Spende zukommen zu lassen. Antworten Sie auf meine E-Mail-Adresse 
jian...@wang-wandagroup.com

Bug#637300: Antworten Sie auf meine E-Mail-Adresse jian...@wang-wandagroup.com

[Le-griguer Fatima]

Ich beabsichtige, Ihnen einen Teil meines Vermögens als freiwillige finanzielle 
Spende zukommen zu lassen. Antworten Sie auf meine E-Mail-Adresse 
jian...@wang-wandagroup.com

Bug#823286: xserver-xorg-input-libinput: -libinput doesn't really 'essentially replace' -synaptics

[Celejar]

Package: xserver-xorg-input-libinput
Version: 0.28.2-1
Followup-For: Bug #823286

I tried removing xserver-xorg-input-synaptics, as suggested by the
language in the xserver-xorg-input-libinput package description, and my
trackpad behavior changed drastically, including losing vertical
scrolling. I tried to get back the old behavior via the Xfce
configuration tool,, but discovered that in my Xfce 'mouse and touchpad'
settings, the whole touchpad section was missing (and, for some reason,
the 'restore to defaults' button in the still existing 'buttons and
feedback' section was grayed out and non-working). Reinstalling
-synaptics (even while leaving -libinput) got me back the missing
configuration section and the desired behavior.

I don't think the -libinput package description should claim:

It can handle keyboards, mice and touchpads, and essentially replaces
the separate -evdev and -synaptics drivers.

Or at the very least, it should clarify that some configuration tools
may not work well with libinput, and major functionality may be lost by
removing -synaptics.

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.7.0 

Bug#922734: mate-utils: Unable to upgrade to mate-utils 1.20.2-2 on !i386 archs

[Pascal Giard]

Package: mate-utils
Version: 1.20.2-1
Severity: important

Dear Maintainer,

It's currently not possible to upgrade mate-utils to 1.20.2-2 on a number
of archs, e.g., amd64, because mate-utils-common 1.20.2-2 is not available
for archs other than i386.

This issue is also visible in the PTS [1], see excuses preventing the
migration from unstable to testing.

Nonetheless, thanks for your work on packaging MATE for Debian.

Best regards,

-Pascal
[1] https://tracker.debian.org/pkg/mate-utils

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=fr:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mate-utils depends on:
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-7
ii  libcairo-gobject2 1.16.0-2
ii  libcairo2 1.16.0-2
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.38.0+dfsg-7
ii  libglib2.0-0  2.58.3-1
ii  libgtk-3-03.24.5-1
ii  libgtop-2.0-112.38.0-4
ii  libice6   2:1.0.9-2
ii  libmate-panel-applet-4-1  1.20.5-1
ii  libmatedict6  1.20.2-1
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  mate-desktop-common   1.20.4-2
ii  mate-utils-common 1.20.2-1
ii  zlib1g1:1.2.11.dfsg-1

mate-utils recommends no packages.

mate-utils suggests no packages.

-- no debconf information

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

 
Package: src:linux
Version: 4.19.12-1~bpo9+1
Severity: important
 
 
Feb 19 19:01:04 vhost182 kernel: INFO: task btrfs-transacti:613 blocked for 
more than 120 seconds.
Feb 19 19:01:04 vhost182 kernel:   Tainted: GE 
4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1
Feb 19 19:01:04 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 19 19:01:04 vhost182 kernel: btrfs-transacti D0   613  2 0x8000
Feb 19 19:01:04 vhost182 kernel: Call Trace:
Feb 19 19:01:04 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 19 19:01:04 vhost182 kernel:  schedule+0x32/0x80
Feb 19 19:01:04 vhost182 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  ? remove_wait_queue+0x60/0x60
Feb 19 19:01:04 vhost182 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  btrfs_write_dirty_block_groups+0x109/0x3d0 
[btrfs]
Feb 19 19:01:04 vhost182 kernel:  ? btrfs_run_delayed_refs+0x88/0x1b0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  commit_cowonly_roots+0x245/0x2f0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  btrfs_commit_transaction+0x36f/0x8a0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  kthread+0xf8/0x130
Feb 19 19:01:04 vhost182 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Feb 19 19:01:04 vhost182 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 19 19:01:04 vhost182 kernel:  ret_from_fork+0x35/0x40
Feb 19 19:01:04 vhost182 kernel: INFO: task kworker/u24:4:5280 blocked for more 
than 120 seconds.
Feb 19 19:01:04 vhost182 kernel:   Tainted: GE 
4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1
Feb 19 19:01:04 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 19 19:01:04 vhost182 kernel: kworker/u24:4   D0  5280  2 0x8000
Feb 19 19:01:04 vhost182 kernel: Workqueue: btrfs-endio-write 
btrfs_endio_write_helper [btrfs]
Feb 19 19:01:04 vhost182 kernel: Call Trace:
Feb 19 19:01:04 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 19 19:01:04 vhost182 kernel:  schedule+0x32/0x80
Feb 19 19:01:04 vhost182 kernel:  wait_current_trans+0xb9/0xf0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  ? remove_wait_queue+0x60/0x60
Feb 19 19:01:04 vhost182 kernel:  start_transaction+0x201/0x3e0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  btrfs_finish_ordered_io+0x48d/0x7e0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  ? wb_workfn+0x3ac/0x450
Feb 19 19:01:04 vhost182 kernel:  normal_work_helper+0xd0/0x320 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  process_one_work+0x191/0x370
Feb 19 19:01:04 vhost182 kernel:  worker_thread+0x4f/0x3b0
Feb 19 19:01:04 vhost182 kernel:  kthread+0xf8/0x130
Feb 19 19:01:04 vhost182 kernel:  ? rescuer_thread+0x340/0x340
Feb 19 19:01:04 vhost182 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 19 19:01:04 vhost182 kernel:  ret_from_fork+0x35/0x40
Feb 19 19:01:04 vhost182 kernel: INFO: task kworker/u24:0:7477 blocked for more 
than 120 seconds.
Feb 19 19:01:04 vhost182 kernel:   Tainted: GE 
4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1
Feb 19 19:01:04 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 19 19:01:04 vhost182 kernel: kworker/u24:0   D0  7477  2 0x8000
Feb 19 19:01:04 vhost182 kernel: Workqueue: btrfs-endio-write 
btrfs_endio_write_helper [btrfs]
Feb 19 19:01:04 vhost182 kernel: Call Trace:
Feb 19 19:01:04 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 19 19:01:04 vhost182 kernel:  schedule+0x32/0x80
Feb 19 19:01:04 vhost182 kernel:  wait_current_trans+0xb9/0xf0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  ? remove_wait_queue+0x60/0x60
Feb 19 19:01:04 vhost182 kernel:  start_transaction+0x201/0x3e0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  btrfs_finish_ordered_io+0x48d/0x7e0 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  normal_work_helper+0xd0/0x320 [btrfs]
Feb 19 19:01:04 vhost182 kernel:  ? move_linked_works+0x6e/0xa0
Feb 19 19:01:04 vhost182 kernel:  process_one_work+0x191/0x370
Feb 19 19:01:04 vhost182 kernel:  worker_thread+0x4f/0x3b0
Feb 19 19:01:04 vhost182 kernel:  kthread+0xf8/0x130
Feb 19 19:01:04 vhost182 kernel:  ? rescuer_thread+0x340/0x340
Feb 19 19:01:04 vhost182 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 19 19:01:04 vhost182 kernel:  ret_from_fork+0x35/0x40
Feb 19 19:01:04 vhost182 kernel: INFO: task kworker/u24:5:7480 blocked for more 
than 120 seconds.
Feb 19 19:01:04 vhost182 kernel:   Tainted: GE 
4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1
Feb 19 19:01:04 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 19 19:01:04 vhost182 kernel: kworker/u24:5   D0  7480  2 0x8000
Feb 19 19:01:04 vhost182 kernel: 

Bug#912575: Additional information neccessary?

[Felix]

Please let me know if you need additional information regarding this issue.

Bug#918378: fixed in qemu 1:3.1+dfsg-3

[Steven Young]

Just updated my test machines to the newly released qemu/1:3.1+dfsg-4 
and can confirm it's fixed. Thanks!

Bug#921031: Processed: severity of 921031 is grave

[Guillem Jover]

Hi!

On Tue, 2019-02-12 at 17:33:03 +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > # Breaks autopkgtests and is therefore a migration blocker
> > severity 921031 grave
> Bug #921031 [libdpkg-perl] Dpkg::Source::Package missing use of ::Format
> Severity set to 'grave' from 'normal'

Sorry about the delay, as I mentioned on IRC I wanted to let exim
migrate first to not regress on the s-s-d issue. I'm planning on doing
the upload tomorrow evening.

Thanks,
Guillem

Bug#921653: texlive-latex-extra: docindex.sty relies on unavailable xhj.sty, galley2.sty

[Norbert Preining]

On Mon, 18 Feb 2019, Hilmar Preuße wrote:
> So, how to got from here? My suggestion: we put the package on the black
> list and close the bug.

I am against this. There is also xdoc2.sty in the same tlpdb, and who
knows who is using that, it might work while the docindex doesn't.

What is the problem with having the docindex.sty in there?

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#922733: python3-milter: Milter.utils.parseaddr() fails: AttributeError: module 'email' has no attribute 'utils'

[Daniel Kahn Gillmor]

Package: python3-milter
Version: 1.0.3-2
Severity: normal
Tags: patch, upstream

0 dkg@alice:~$ ipython3
Python 3.7.2+ (default, Feb  2 2019, 14:31:48) 
Type "copyright", "credits" or "license" for more information.

IPython 5.8.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help  -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import Milter.utils

In [2]: Milter.utils.parseaddr('Daniel Kahn Gillmor ')
---
AttributeErrorTraceback (most recent call last)
 in ()
> 1 Milter.utils.parseaddr('Daniel Kahn Gillmor ')

/usr/lib/python3/dist-packages/Milter/utils.py in parseaddr(t)
137   """
138   #return email.utils.parseaddr(t)
--> 139   res = email.utils.parseaddr(t)
140   # dirty fix for some broken cases
141   if not res[0]:

AttributeError: module 'email' has no attribute 'utils'

In [3]: 



--

weirdly, it doesn't have the same problem in python2:


0 dkg@alice:~$ ipython
Python 2.7.15+ (default, Feb  3 2019, 13:13:16) 
Type "copyright", "credits" or "license" for more information.

IPython 5.8.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help  -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import Milter.utils

In [2]: Milter.utils.parseaddr('Daniel Kahn Gillmor '
   ...: )
Out[2]: ('Daniel Kahn Gillmor', 'd...@fifthhorseman.net')

In [3]:

I don't know how to account for this difference, but i'd say that
pymilter probably needs more testing.

A simple patch is attached.

 --dkg

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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)

Versions of packages python3-milter depends on:
ii  libc6   2.28-6
ii  libmilter1.0.1  8.15.2-12
ii  python3 3.7.2-1
ii  python3-dns 3.2.0-2

python3-milter recommends no packages.

Versions of packages python3-milter suggests:
ii  postfix3.3.2-1+b1
pn  python-milter-doc  

-- no debconf information
From: Daniel Kahn Gillmor 
Date: Tue, 19 Feb 2019 18:20:18 -0500
Subject: utils: import email.utils

Without this patch, Milter.utils.parseaddr() fails with:

  File "/usr/lib/python3/dist-packages/Milter/utils.py", line 139, in parseaddr
res = email.utils.parseaddr(t)
AttributeError: module 'email' has no attribute 'utils'
---
 Milter/utils.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Milter/utils.py b/Milter/utils.py
index 2ed5db8..85fd635 100644
--- a/Milter/utils.py
+++ b/Milter/utils.py
@@ -8,6 +8,7 @@ import socket
 import email.errors
 from email.header import decode_header
 import email.base64mime
+import email.utils
 from fnmatch import fnmatchcase
 from binascii import a2b_base64
 

Bug#922723: RM: conserver -- RoQA; RC-buggy, depends on openssl 1.0

[Sebastian Andrzej Siewior]

On 2019-02-19 22:32:59 [+0100], Moritz Mühlenhoff wrote:
> Someone should NMU it soon, then. We're down to four remaining packages
> using OpenSSL 1.0 and this will not drag for more than a few weeks, the
> openssl1.0 is already going on for ages.

Someone just did.

> Cheers,
> Moritz

Sebastian

Bug#637822: calibre-bin: traceback on shutdown, 100% of the time

[Nicholas D Steeves]

Hi Michael,

On Sun, Aug 14, 2011 at 05:22:12PM -0400, Michael P. Soulier wrote:
> Package: calibre-bin
> Version: 0.7.7+dfsg-1squeeze1
> Severity: minor
> 
> Every time I shut down calibre I see this in the terminal.
> 
> Exception in thread Thread-4 (most likely raised during interpreter shutdown):
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
...
> 
> -- System Information:
> Debian Release: 6.0.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: i386 (i686)

Debian 6/squeeze has been end-of-life since early 2016, so I am
closing this bug.  If you know how to trigger this shutdown bug in
Debian 9/stretch (calibre 2.75.1+dfsg-1), buster (3.35.0+dfsg-1), or
sid (3.39.1+dfsg-2) please go ahead and either reopen this bug or file
a new one.

Thank you!
Nicholas


signature.asc
Description: PGP signature

Bug#859553: pidentd: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

On 2017-10-12 23:44:37 [+0200], To 859...@bugs.debian.org wrote:
> this is a remainder about the openssl transition [0]. We really want to
> remove libssl1.0-dev from unstable for Buster. I will raise the severity
> of this bug to serious in a month. Please react before that happens.

There has been no action on pidentd and it is out of testing during
soft-freeze. Should there be a RM bug filled? We do have alternative
ident daemons in the archive. This package is holding back the removal
of openssl 1.0.2 in the archive.
 
Sebastian

Bug#922729: debootstrap: unable to override arch-test

[Vagrant Cascadian]

On 2019-02-20, John Paul Adrian Glaubitz wrote:
> On 2/19/19 11:56 PM, Vagrant Cascadian wrote:
>> I tried installing an armel chroot on an arm64 machine:
>> 
>>   $ sudo debootstrap --variant=minbase --arch=armel --no-merged-usr 
>> --verbose sid /srv/chroots/armeltest http://deb.debian.org/debian/
>>   E: Unable to execute target architecture
>
> I just pass --foreign in these case and then chroot into the target to
> run ./debootstrap/deboostrap --second-stage.
>
> Alternatively, use qemu-deboostrap.

Ok, I guess those are also workarounds, but --second-stage seems like a
lot of extra hoops to jump through, and qemu-debootstrap +
qemu-user-static seems resource inefficient on a system that should
otherwise be able to support it "natively".


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#922732: openssl: ~/.rnd (RANDFILE) ignored

[Thorsten Glaser]

Package: openssl
Version: 1.1.1a-1
Severity: minor

When I do “openssl rand 4 | hd”, the file ~/.rnd is ignored
(judging from its tiestamp and md5sum, it’s not rewritten,
and probably not read either) despite me adding the line

RANDFILE= $ENV::HOME/.rnd

to openssl.cnf as described in config(5).


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages openssl depends on:
ii  libc6  2.28-6
ii  libssl1.1  1.1.1a-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-bundle [ca-certificates]  20181220

-- Configuration Files:
/etc/ssl/openssl.cnf changed:
HOME= .
RANDFILE= $ENV::HOME/.rnd
oid_section = new_oids
openssl_conf = default_conf
[ new_oids ]
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7
[ ca ]
default_ca  = CA_default# The default ca section
[ CA_default ]
dir = ./demoCA  # Where everything is kept
certs   = $dir/certs# Where the issued certs are kept
crl_dir = $dir/crl  # Where the issued crl are kept
database= $dir/index.txt# database index file.
# several certs with same subject.
new_certs_dir   = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem   # The CA certificate
serial  = $dir/serial   # The current serial number
crlnumber   = $dir/crlnumber# the current crl number
# must be commented out to leave a V1 
CRL
crl = $dir/crl.pem  # The current CRL
private_key = $dir/private/cakey.pem# The private key
x509_extensions = usr_cert  # The extensions to add to the cert
name_opt= ca_default# Subject Name options
cert_opt= ca_default# Certificate field options
default_days= 365   # how long to certify for
default_crl_days= 30# how long before next CRL
default_md  = default   # use public key default MD
preserve= no# keep passed DN ordering
policy  = policy_match
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName= match
organizationalUnitName  = optional
commonName  = supplied
emailAddress= optional
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName= optional
organizationName= optional
organizationalUnitName  = optional
commonName  = supplied
emailAddress= optional
[ req ]
default_bits= 2048
default_keyfile = privkey.pem
distinguished_name  = req_distinguished_name
attributes  = req_attributes
x509_extensions = v3_ca # The extensions to add to the self signed cert
string_mask = utf8only
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = AU
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Some-State
localityName= Locality Name (eg, city)
0.organizationName  = Organization Name (eg, company)
0.organizationName_default  = Internet Widgits Pty Ltd
organizationalUnitName  = Organizational Unit Name (eg, section)
commonName  = Common Name (e.g. server FQDN or YOUR name)
commonName_max  = 64
emailAddress= Email Address
emailAddress_max= 64
[ req_attributes ]
challengePassword   = A challenge password
challengePassword_min   = 4
challengePassword_max   = 20
unstructuredName= An optional company name
[ usr_cert ]
basicConstraints=CA:FALSE
nsComment   = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = critical,CA:true
[ crl_ext ]
authorityKeyIdentifier=keyid:always
[ proxy_cert_ext ]
basicConstraints=CA:FALSE
nsComment   = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo
[ tsa ]
default_tsa = tsa_config1   # the default TSA section
[ 

Bug#851085: conserver: diff for NMU version 8.2.1-1.1

[Sebastian Andrzej Siewior]

Control: tags 851085 + patch
Control: tags 851085 + pending

Dear maintainer,

I've prepared an NMU for conserver (versioned as 8.2.1-1.1) and I am
about to upload (RC bug with no feedback, RM bug filled).

Regards.
Sebastian
diff -u conserver-8.2.1/configure conserver-8.2.1/configure
--- conserver-8.2.1/configure
+++ conserver-8.2.1/configure
@@ -5249,7 +5249,7 @@
 int
 main ()
 {
-SSL_library_init()
+SSL_CTX_new(NULL)
   ;
   return 0;
 }
diff -u conserver-8.2.1/debian/changelog conserver-8.2.1/debian/changelog
--- conserver-8.2.1/debian/changelog
+++ conserver-8.2.1/debian/changelog
@@ -1,3 +1,11 @@
+conserver (8.2.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * cherry-pick a handfull patches from upstream for OpenSSL 1.1 compatibility
+(Closes: #851085).
+
+ -- Sebastian Andrzej Siewior   Tue, 19 Feb 2019 23:50:54 +0100
+
 conserver (8.2.1-1) unstable; urgency=medium
 
   * new upstream version 
diff -u conserver-8.2.1/debian/control conserver-8.2.1/debian/control
--- conserver-8.2.1/debian/control
+++ conserver-8.2.1/debian/control
@@ -2,7 +2,7 @@
 Section: non-free/comm
 Priority: optional
 Maintainer: Jörgen Hägg 
-Build-Depends: debhelper (>= 7.0.50), po-debconf, libpam0g-dev, libwrap0-dev, libssl1.0-dev
+Build-Depends: debhelper (>= 7.0.50), po-debconf, libpam0g-dev, libwrap0-dev, libssl-dev
 Standards-Version: 3.9.8
 XS-Autobuild: yes
 Homepage: http://www.conserver.com/
only in patch2:
unchanged:
--- conserver-8.2.1.orig/configure.in
+++ conserver-8.2.1/configure.in
@@ -535,7 +535,7 @@
 	[LIBS="$LIBS -lssl -lcrypto"
 	AC_MSG_CHECKING(for openssl libraries -lssl and -lcrypto)
 	AC_TRY_LINK([#include 
-		],[SSL_library_init()],
+		],[SSL_CTX_new(NULL)],
 		[AC_MSG_RESULT(yes)
 		cons_with_openssl="YES"
 		AC_DEFINE(HAVE_OPENSSL)
only in patch2:
unchanged:
--- conserver-8.2.1.orig/conserver/cutil.c
+++ conserver-8.2.1/conserver/cutil.c
@@ -59,7 +59,9 @@
 {
 DestroyDataStructures();
 #if HAVE_OPENSSL
+# if OPENSSL_VERSION_NUMBER < 0x1010L
 ERR_free_strings();
+# endif
 #endif
 exit(status);
 }
only in patch2:
unchanged:
--- conserver-8.2.1.orig/conserver/cutil.h
+++ conserver-8.2.1/conserver/cutil.h
@@ -9,7 +9,15 @@
 #include 
 #if HAVE_OPENSSL
 # include 
+# include 
+# include 
 # include 
+# if OPENSSL_VERSION_NUMBER < 0x1010L
+#  define TLS_method SSLv23_method
+#  define CIPHER_SEC0
+# else
+#  define CIPHER_SEC0 ":@SECLEVEL=0"
+# endif /* OPENSSL_VERSION_NUMBER < 0x1010L */
 #endif
 #if HAVE_GSSAPI
 # include 
only in patch2:
unchanged:
--- conserver-8.2.1.orig/conserver/main.c
+++ conserver-8.2.1/conserver/main.c
@@ -86,12 +86,74 @@
 #endif
 
 #if HAVE_OPENSSL
+#if OPENSSL_VERSION_NUMBER < 0x1010L
+int DH_set0_pqg(DH *dh, BIGNUM *p, BIGNUM *q, BIGNUM *g)
+{
+/* If the fields p and g in d are NULL, the corresponding input
+ * parameters MUST be non-NULL.  q may remain NULL.
+ */
+if ((dh->p == NULL && p == NULL)
+|| (dh->g == NULL && g == NULL))
+return 0;
+
+if (p != NULL) {
+BN_free(dh->p);
+dh->p = p;
+}
+if (q != NULL) {
+BN_free(dh->q);
+dh->q = q;
+}
+if (g != NULL) {
+BN_free(dh->g);
+dh->g = g;
+}
+
+if (q != NULL) {
+dh->length = BN_num_bits(q);
+}
+
+return 1;
+}
+#endif /* OPENSSL_VERSION_NUMBER < 0x1010L */
+
 SSL_CTX *ctx = (SSL_CTX *)0;
 DH *dh512 = (DH *)0;
 DH *dh1024 = (DH *)0;
 DH *dh2048 = (DH *)0;
 DH *dh4096 = (DH *)0;
 
+DH *
+DHFromArray(unsigned char *dh_p, size_t dh_p_size, unsigned char *dh_g, size_t dh_g_size) {
+DH *dh;
+BIGNUM *p, *g;
+
+p = BN_bin2bn(dh_p, dh_p_size, NULL);
+if (p == NULL) {
+	return (NULL);
+}
+
+g = BN_bin2bn(dh_g, dh_g_size, NULL);
+if (g == NULL) {
+	BN_free(g);
+	return (NULL);
+}
+
+if ((dh = DH_new()) == NULL) {
+	BN_free(p);
+	BN_free(g);
+	return (NULL);
+}
+
+if (!DH_set0_pqg(dh, p, NULL, g)) {
+	BN_free(p);
+	BN_free(g);
+	DH_free(dh);
+	return (NULL);
+}
+
+return (dh);
+}
 
 DH *
 GetDH512(void)
@@ -108,17 +170,8 @@
 static unsigned char dh512_g[] = {
 	0x02,
 };
-DH *dh;
 
-if ((dh = DH_new()) == NULL)
-	return (NULL);
-dh->p = BN_bin2bn(dh512_p, sizeof(dh512_p), NULL);
-dh->g = BN_bin2bn(dh512_g, sizeof(dh512_g), NULL);
-if ((dh->p == NULL) || (dh->g == NULL)) {
-	DH_free(dh);
-	return (NULL);
-}
-return (dh);
+return DHFromArray(dh512_p, sizeof(dh512_p), dh512_g, sizeof(dh512_g));
 }
 
 DH *
@@ -142,17 +195,8 @@
 static unsigned char dh1024_g[] = {
 	0x02,
 };
-DH *dh;
 
-if ((dh = DH_new()) == NULL)
-	return (NULL);
-dh->p = BN_bin2bn(dh1024_p, sizeof(dh1024_p), NULL);
-dh->g = BN_bin2bn(dh1024_g, sizeof(dh1024_g), NULL);
-if ((dh->p == NULL) || (dh->g == NULL)) {
-	DH_free(dh);
-	return (NULL);
-}
-return (dh);
+return DHFromArray(dh1024_p, sizeof(dh1024_p), dh1024_g, sizeof(dh1024_g));
 }
 
 DH *
@@ -189,17 

Bug#922729: debootstrap: unable to override arch-test

[John Paul Adrian Glaubitz]

On 2/19/19 11:56 PM, Vagrant Cascadian wrote:
> I tried installing an armel chroot on an arm64 machine:
> 
>   $ sudo debootstrap --variant=minbase --arch=armel --no-merged-usr --verbose 
> sid /srv/chroots/armeltest http://deb.debian.org/debian/
>   E: Unable to execute target architecture

I just pass --foreign in these case and then chroot into the target to
run ./debootstrap/deboostrap --second-stage.

Alternatively, use qemu-deboostrap.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#922731: llvm-toolchain-7: Unjustified API breakage introduced by Debian patch

[A.C.]

Source: llvm-toolchain-7
Severity: important

Dear Maintainer,
A recently merged patch that introduced support for KFreeBSD broke the API
compatibility by introducing pointless renamings of enumeration values (KFreeBSD
to kFreeBSD) and classes/structures.

This change is not purely cosmetic and actively breaks any software that's
making use of the aforementioned enums/struct/classes.

My suggestion is to either amend the patches and be more careful in future in
order to avoid this kind of silly breakage.

Regards,
DH

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#798104: #798104 Segmentation fault when running selection example

[Javier Barroso]

Hello,

On Tue, Feb 19, 2019 at 11:33 PM Thomas Dickey  wrote:

> I was not able to reproduce this when it was reported, nor can I reproduce
> it using the same source now (and same applies to the current packages).
>
Now it works on my laptop too, maybe a temporal problem by the time. So I'm
closing this bug report

Now, the example should be fixed, removing defined keyword, as advised:
$ perl /usr/share/doc/libcdk-perl/examples/examples/selection
Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at
/usr/share/doc/libcdk-perl/examples/examples/selection line 37.

Thank you for your Debian work !

Bug#922730: cannot browse anything

[積丹尼 Dan Jacobson]

Package: epiphany-browser
Version: 3.31.91-2
Severity: grave

$ mkdir /tmp/p
$ HOME=/tmp/p epiphany /etc/motd

** (epiphany:11842): WARNING **: 06:53:40.412: Web process crashed

(WebKitWebProcess:12106): GLib-GObject-WARNING **: 06:53:41.133: 
../../../gobject/gtype.c:4265: type id '0' is invalid

(WebKitWebProcess:12106): GLib-GObject-WARNING **: 06:53:41.139: can't peek 
value table for type '' which is not currently referenced

No, /usr/lib/*-linux-gnu/webkit2gtk-4.0/MiniBrowser works fine.

Versions of packages epiphany-browser depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.13.8-1
ii  dbus-x11 [dbus-session-bus]   1.13.8-1
ii  epiphany-browser-data 3.31.91-2
ii  gsettings-desktop-schemas 3.31.0.2-2
ii  iso-codes 4.2-1
ii  libc6 2.28-7
ii  libcairo2 1.16.0-2
ii  libdazzle-1.0-0   3.31.90-1
ii  libgcr-base-3-1   3.28.1-2
ii  libgcr-ui-3-1 3.28.1-2
ii  libgdk-pixbuf2.0-02.38.0+dfsg-7
ii  libglib2.0-0  2.59.2-2
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgtk-3-03.24.5-1
ii  libhogweed4   3.4.1-1
ii  libicu63  63.1-6
ii  libjavascriptcoregtk-4.0-18   2.23.90-1
ii  libjson-glib-1.0-01.4.4-2
ii  libnettle63.4.1-1
ii  libnotify40.7.7-4
ii  libpango-1.0-01.42.4-6
ii  libsecret-1-0 0.18.7-1
ii  libsoup2.4-1  2.64.2-2
ii  libsqlite3-0  3.27.1-1
ii  libwebkit2gtk-4.0-37  2.23.90-1
ii  libxml2   2.9.8+dfsg-1+b1

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20190110
pn  evince   
ii  yelp 3.31.90-1

epiphany-browser suggests no packages.

-- no debconf information

Bug#922531: lintian: Please make package-uses-vendor-specific-patch-series Debian-archive specific

[Chris Lamb]

Hi Guillem,

> > Or perhaps not emit this tag for "local" packages (via the
> > versioning scheme?)
> 
> I'm not sure there's any reliable way to distinguish those? I think
> most people even tend to use the defaul target distribution from dch,
> and use normal looking versions for local packages.

dch(1) has:

   --local, -lsuffix

 
   Add a suffix to the Debian version number for a local build.

... which might be legitimate to ask people to use so that Lintian
ignores it.

But before we spend more energy here instead of on other things;
are there many concrete people actually complaining about this? If
so, where? 

> Creating the profiles is rather easy, the above would be a simple
> example of that, and can be placed either system-wide or on each
> user's home. The problem is that this needs to be deployed on each
> user/CI/build system

Nod, indeed. Including, for example, GitLab instances, etc. etc.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#894962: Links between bugs

[Xavier]

#894962 was probably partially due to #909151.

Thanks to Mauricio Oliveira to have fixed #909151.

https://bugs.debian.org/894962
  FTBFS and Debci failure with node-process-nextick-args 2.0.0-1

https://bugs.debian.org/909151
  'Uncaught TypeError: nextTick is not a function' with
node-process-nextick-args 2.0.0

Bug#922729: debootstrap: unable to override arch-test

[Vagrant Cascadian]

Package: debootstrap
Version: 1.0.114
Severity: normal

I tried installing an armel chroot on an arm64 machine:

  $ sudo debootstrap --variant=minbase --arch=armel --no-merged-usr --verbose 
sid /srv/chroots/armeltest http://deb.debian.org/debian/
  E: Unable to execute target architecture

This appears to be due to:

  #922728: arch-test: reports armel invalid on arm64 system
  https://bugs.debian.org/922728

If I remove arch-test, debootstrap works fine, installs the chroot, and
I'm able to chroot into the armel environment just fine.

Other than uninstalling arch-test, there appears to be no way to tell
debootstrap to ignore, or at least downgrade arch-test results to a
warning. I'm not sure if a commandlinne option and/or environment
variable would be the preferred workaround.

Obviously, the best thing to do is fix arch-test in this particular
case, but if it's not possible, or it takes a long time, or some future
bug in arch-test comes around, it'd be nice to be able to override it
without uninstalling arch-test.

live well,
  vagrant


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (120, 'unstable'), (1, 
'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 4.20.0-trunk-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_SOFTLOCKUP
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debootstrap depends on:
ii  wget  1.20.1-1

Versions of packages debootstrap recommends:
ii  arch-test   0.15-1
ii  debian-archive-keyring  2018.1
ii  gnupg   2.2.12-1

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information


signature.asc
Description: PGP signature

Bug#894962: Links between bugs

[Xavier]

#894962 was probably partially due to #909151.

Thanks to Mauricio Oliveira to have fixed #909151.

https://bugs.debian.org/894962
  FTBFS and Debci failure with node-process-nextick-args 2.0.0-1

https://bugs.debian.org/909151
  'Uncaught TypeError: nextTick is not a function' with
node-process-nextick-args 2.0.0

Bug#922711: lxqt-branding-debian: lxqt-config-appearance unable to set lxqt-panel icons

[Amy Kos]

Sorry for not being understandable enough. I'll try it again.

In your screenshot you have papirus selected, if you select oxygen
it will change all icons except the panel icons.

It should change all icons including the panel icons.

And it does as soon lxqt-branding-debian is removed.
Thanks for relaxing dependencies as far as possible.

Bug#879935: closed by Chris Lamb (Bug#879935: fixed in lintian 2.5.56)

[Guillem Jover]

Control: retitle -1 Please warn on packages using getconf(1), except to get 
PATH, _NPROCESSORS_{CONF,ONLN}

On Mon, 2017-10-30 at 09:05:46 +, Chris Lamb wrote:
> retitle 879935 Please warn on packages using getconf(1) to get PATH, 
> _NPROCESSORS_{CONF,ONLN} etc.
> thanks

> > Well this only got the patch I supplied to be applied, it didn't implement
> > the requested new tag for getconf(1) usage. :)
> 
> Okay, let's give this bug a nicer title .. and I await your patch for
> the tag ;-)

Actually the new title had a logic inversion bug. :) Will try to come
up with one when I get some time.

Thanks,
Guillem

Bug#922531: lintian: Please make package-uses-vendor-specific-patch-series Debian-archive specific

[Guillem Jover]

On Mon, 2019-02-18 at 14:16:56 +0100, Chris Lamb wrote:
> > The problem with emitting this tag unconditionally, even within the
> > Debian-vendor realm, is that people create local packages for their
> > own, or for $work, etc.
> 
> Hmm. Emitting such a tag here still seems right to me, or at least
> when balanced with the downsides. The local package will never
> reach "dak prime" by definition, after all, and the maintainer can
> simply override the warning if they so wish (and do not use a
> vendor).

The problem with this is that a warning (now) or a non-overridable
error (in the future) are rather scary looking, and even harder to
override as the latter does require a custom vendor profile. :(
Something like the following untested one:

  ,---
  Profile: vendor/main
  Extends: debian/main
  Disable-Tags:
package-uses-vendor-specific-patch-series,
  `---

Which would of course still trigger on other systems w/o that vendor
profile.

This is compounded with the fact that there's still no clear
distinction between what is the core specification of the packaging
system and what's (possibly arbitrary) Debian-specific policy (which
I'm trying to fix slowly from the dpkg side by documenting the first
part within dpkg itself, but still), and that the tag description does
not help either as it seems misleading to me. :/

> > in most cases will not go to the trouble of creating a new vendor for this.
> 
> I wonder if part of the solution might be to make this bit easier?

Creating the profiles is rather easy, the above would be a simple
example of that, and can be placed either system-wide or on each
user's home. The problem is that this needs to be deployed on each
user/CI/build system that is going to have to deal with those. That's
why I think the "presence" of the tag is inverted here, for something
that really feels should only be emitted within the confines of the
Debian (and Ubuntu) archives.

> Or perhaps not emit this tag for "local" packages (via the
> versioning scheme?)

I'm not sure there's any reliable way to distinguish those? I think
most people even tend to use the defaul target distribution from dch,
and use normal looking versions for local packages. But maybe you had
something else in mind?

Thanks,
Guillem

Bug#922533: please document location of accounting file

[Marcos Fouces]

Hi Marc

In Debian, the pacct file is located in /var/log/account/pacct while in
Fedora it is in /var/account/pacct.

I don't see the reason to be less parsable in that location.

What is your suggestion?

Greetings,

Marcos

On 17/2/19 20:50, Marc Haber wrote:
> Package: acct
> Version: 6.6.4-2
> Severity: wishlist
>
> Hi,
>
> my package atop needs to adapt itself to acct being installed or not. If
> acct is installed, atop reads from acct's log files, while establishing
> its own accounting interface it acct is not installed.
>
> Historically, the pacct file is found in various different places,
> varying across distribution, so atop's upstream code does through
> various contortions to find the correct file. It for example acts on
> /etc/logrotate.d/psacct to find the file being rotated, which fails on
> Debian since Debian's acct package uses savelog in /etc/cron.d/acct.
>
> atop on Debian is currently growing code to parse for the savelog line
> in /etc/cron.d/acct to find out the acct file being used.
>
> Would it be possible ot have the acct file's location in a more easily
> parsable location? Thanks for helping!
>
> Greetings
> Marc
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.20.8-zgws1 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages acct depends on:
> ii  dpkg  1.19.4
> ii  install-info  6.5.0.dfsg.1-4+b1
> ii  libc6 2.28-7
> ii  lsb-base  10.2018112800
>
> acct recommends no packages.
>
> acct suggests no packages.
>

Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Handle transition from MAT to MAT2

[jvoisin]

> On 19-02-12 14:39:32, Georg Faerber wrote:
>> That is: option one of the second proposal ("quickly patch together a
>> Python 2 Nautilus extension that wraps mat2's CLI").
> 
> Unfortunately, and sorry again for my delay working on this, there was
> no feedback. I've poked Jonas today on IRC privately, asking if he had a
> comment, he said "sounds good, go ahead", and so I did.
Ouch, this is unexpected and sounds like a hack, but I guess this is the
only way to get a useable Mat2 into Buster before the hard freeze.

I took a look at your patch, and improved it a bit. Improved as in tried
to reduce the number of modifications, and made it more Pythonic.

I'm not super-duper-confident that this approach won't result in some
weird issues, but again, I guess it's better than nothing.

Thank you for taking the time to write this patch and taking care of
mat2 in Debian ♥
--- a/nautilus/mat2.py
+++ b/nautilus/mat2.py
@@ -1,5 +1,5 @@
-#!/usr/bin/env python3
-
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
 """
 Because writing GUI is non-trivial (cf. https://0xacab.org/jvoisin/mat2/issues/3),
 we decided to write a Nautilus extensions instead
@@ -12,34 +12,39 @@

 # pylint: disable=no-name-in-module,unused-argument,no-self-use,import-error

-import queue
+import Queue as queue
 import threading
-from typing import Tuple, Optional, List
-from urllib.parse import unquote
+from urlparse import unquote

 import gi
 gi.require_version('Nautilus', '3.0')
 gi.require_version('Gtk', '3.0')
 gi.require_version('GdkPixbuf', '2.0')
 from gi.repository import Nautilus, GObject, Gtk, Gio, GLib, GdkPixbuf
+import subprocess
+import mimetypes

-from libmat2 import parser_factory

+def _remove_metadata(fpath):
+""" This is a simple wrapper around the mat2 cli. """
+try:
+return subprocess.check_output(['mat2', fpath])
+except subprocess.CalledProcessError, e:
+return e.output
+
+
+def _guess_mtype(fpath):
+""" Function to guess the mtype of a given file. """
+mtype, _ = mimetypes.guess_type(fpath)
+return mtype

-def _remove_metadata(fpath) -> Tuple[bool, Optional[str]]:
-""" This is a simple wrapper around libmat2, because it's
-easier and cleaner this way.
-"""
-parser, mtype = parser_factory.get_parser(fpath)
-if parser is None:
-return False, mtype
-return parser.remove_all(), mtype

 class Mat2Extension(GObject.GObject, Nautilus.MenuProvider, Nautilus.LocationWidgetProvider):
 """ This class adds an item to the right-clic menu in Nautilus. """

 def __init__(self):
-super().__init__()
+super(Mat2Extension, self).__init__()
 self.infobar_hbox = None
 self.infobar = None
 self.failed_items = list()
@@ -61,7 +66,7 @@
 self.infobar.get_content_area().pack_start(self.infobar_hbox, True, True, 0)
 self.infobar.show_all()

-def get_widget(self, uri, window) -> Gtk.Widget:
+def get_widget(self, uri, window):
 """ This is the method that we have to implement (because we're
 a LocationWidgetProvider) in order to show our infobar.
 """
@@ -103,7 +108,7 @@
 window.show_all()

 @staticmethod
-def __validate(fileinfo) -> Tuple[bool, str]:
+def __validate(fileinfo):
 """ Validate if a given file FileInfo `fileinfo` can be processed.
 Returns a boolean, and a textreason why"""
 if fileinfo.get_uri_scheme() != "file" or fileinfo.is_directory():
@@ -112,7 +117,7 @@
 return False, "Not writeable"
 return True, ""

-def __create_treeview(self) -> Gtk.TreeView:
+def __create_treeview(self):
 liststore = Gtk.ListStore(GdkPixbuf.Pixbuf, str, str)
 treeview = Gtk.TreeView(model=liststore)

@@ -144,7 +149,7 @@
 treeview.show_all()
 return treeview

-def __create_progressbar(self) -> Gtk.ProgressBar:
+def __create_progressbar(self):
 """ Create the progressbar used to notify that files are currently
 being processed.
 """
@@ -161,11 +166,11 @@

 return progressbar

-def __update_progressbar(self, processing_queue, progressbar) -> bool:
+def __update_progressbar(self, processing_queue, progressbar):
 """ This method is run via `Glib.add_idle` to update the progressbar."""
 try:
 fname = processing_queue.get(block=False)
 except queue.Empty:
 return True

 # `None` is the marker put in the queue to signal that every selected
@@ -186,7 +191,7 @@
 self.infobar.show_all()
 return True

-def __clean_files(self, files: list, processing_queue: queue.Queue) -> bool:
+def __clean_files(self, files, processing_queue):
 """ This method is threaded in order to avoid blocking the GUI
 while cleaning up the files.
 """
@@ -200,8 +205,9 @@
 continue

 fpath = unquote(fileinfo.get_uri()[7:])  # `len('file://') = 7`
-

Bug#920571: Should this package be removed?

[Sebastian Andrzej Siewior]

On 2019-01-27 06:06:08 [+0100], Moritz Muehlenhoff wrote:
> Should zorp be removed? It's incompatible with OpenSSL 1.1 and the bug has
> been unacknowledged since 15 months (859840). It's one of the few remaining
> packages blocking the removal at this point, so this doesn't get ported
> to OpenSSL 1.1, zorp should be removed along with src:openssl1.0.

There is new zorp in NEW and its libzorp [0] depends on libssl1.1. It
does not close any bugs but should close #859840.

[0] 
https://ftp-master.debian.org/new/zorp_7.0.1~alpha1-1.html#binary-libzorp-7.0-control

> Cheers,
> Moritz

Sebastian

Bug#922557: lintian: Make orig-tarball-missing-upstream-signature a "dsc" check (was: "Re: Bug#922557: lintian: Please check whether there's an expected orig tarball signature")

[Chris Lamb]

Hi Guillem,

> > Assuming that is why Guillem did not see it I am renaming this bug
> > to match. There is no reason why it cannot be a .changes check;
[…]
> As Mattia mentions, that's the other way around.

(I don't have that message, and nor does the BTS...?)

> The .dsc always get all files listed, but the .changes only list what
> they will end up uploading

Indeed, I got them muddled in my previous mail; I changed it correctly
in the code itself (I hope!):

  
https://salsa.debian.org/lintian/lintian/commit/e05ddc3dab4105af905baee3366aa7711ce0fbb4


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#798104: #798104 Segmentation fault when running selection example

[Thomas Dickey]

I was not able to reproduce this when it was reported, nor can I reproduce
it using the same source now (and same applies to the current packages).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#922557: lintian: Make orig-tarball-missing-upstream-signature a "dsc" check (was: "Re: Bug#922557: lintian: Please check whether there's an expected orig tarball signature")

[Guillem Jover]

Hi!

On Mon, 2019-02-18 at 14:51:42 +0100, Chris Lamb wrote:
> > There is already such a tag, orig-tarball-missing-upstream-signature.
> > That's a .changes checks, not a .dsc one, so it would be emitted only
> > for -1.

Right, had seen it but from a very quick skim got the impression it
was for missing .asc when multiple tarballs were involved! :) But it
does really look like that was the tag indeed.

> Assuming that is why Guillem did not see it I am renaming this bug
> to match. There is no reason why it cannot be a .changes check;
> perhaps I originally thought that .dsc files did not mention such
> files in their manifests?

As Mattia mentiones, that's the other way around. The .dsc always get
all files listed, but the .changes only list what they will end up
uploading which for non -1 releases it means only the .dsc itself
and the diff.gz/debian.tar. files, even if the .dsc contained
orig.tar..asc (and orig.tar.) references.

> Anyway, fix incoming...

Thanks!
Guillem

Bug#922544: lintian: Mass tag rename to unify naming convention

[Chris Lamb]

Hi Guillem,

> > Do others have thoughts before I apply this patch?
> 
> As I mentioned initially, I don't think the patch is ready as is, it
> even has syntax errors

Apologies; I meant to communicate some idea of applying this patch
in *spirit* :)

I would certainly agree that we need a re-review all existing
patches and, of course, the tests etc. etc.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#922728: arch-test: reports armel invalid on arm64 system

[Vagrant Cascadian]

Package: arch-test
Version: 0.15-1
Severity: normal
Control: affects -1 debootstrap

On my pinebook, arch-test displays:

  $ arch-test
  arm64
  armhf

Which prevents running debootstrap --arch=armel.

With arch-test removed, debootstrap is able to run fine, and I'm able
to use the chroot without difficulty.

There definitely are arm64 systems which cannot run armel binaries,
but this one at least appears to support running armel binaries.


live well,
  vagrant

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (120, 'unstable'), (1, 
'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 4.20.0-trunk-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_SOFTLOCKUP
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information


signature.asc
Description: PGP signature

Bug#922544: lintian: Mass tag rename to unify naming convention

[Guillem Jover]

On Sun, 2019-02-17 at 23:45:37 +0100, Chris Lamb wrote:
> Do others have thoughts before I apply this patch?

As I mentioned initially, I don't think the patch is ready as is, it
even has syntax errors (at least one ‘?‘ :). It would probably need
a new pass over the newly created tags, a review of the proposed ones,
and fixing up the description and tag emissions to use the new names.

Also the new (and old) tags do not seem that uniform after all, because
I also noticed inconsistencies in their form, I'd say most use a form
such as subject-verb-object/adjective, but then others use forms such
as adjective-object-adverb-subject, so it might make sense to try to
unify that too, perhaps, if we are going to do a mass cleanup? :)

Thanks,
Guillem

Bug#922726: conserver: Update debian/watch file to watch github page for new released versions

[Salvatore Bonaccorso]

And here the proposed patch refercing the Bug.

Regards,
Salvatore
>From 7bbadff11ddb6e87e263ebd3b6541515beb88e71 Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Tue, 19 Feb 2019 23:10:06 +0100
Subject: [PATCH] debian/watch: watch github page for released versions

Closes: #922726
---
 debian/watch | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/debian/watch b/debian/watch
index 5f2c087b263a..124c220b7ee0 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
-version=3
-#
-#
-http://www.conserver.com/conserver-([\d\.]+)\.tar\.gz
+version=4
+opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%conserver-$1.tar.gz%" \
+https://github.com/conserver/conserver/tags \
+(?:.*?/)?v?(\d[\d.]*)\.tar\.gz
-- 
2.20.1

Bug#922727: CVE-2019-7443

[Moritz Muehlenhoff]

Source: kde4libs
Severity: important
Tags: security

The security bug filed against kauth in #921995 also seems to affect kde4libs, 
the
code is in kdecore/auth/backends/dbus/DBusHelperProxy.cpp?

Cheers,
Moritz

Bug#922726: conserver: Update debian/watch file to watch github page for new released versions

[Salvatore Bonaccorso]

Source: conserver
Version: 8.2.1-1
Severity: minor
Tags: patch

Hi,

conserver releases can be found on https://github/conserver/conserver
so the debian/watch file can monitor new upstream releases on the
GitHub page for conserver.

Regards,
Salvatore

Bug#922725: needrestart: networking.service should not be restarted since it can cause depending services to fail

[Timo Sigurdsson]

Package: needrestart
Version: 2.11-3+deb9u1
Severity: normal

Dear Maintainer,

please consider blacklisting networking.service in needrestart.conf similar to 
NetworkManager or other networking related services.

After the upgrade to the stable point release 9.8 which included updates to 
libc, I noticed a lot of services failed on my network gateway which runs 
Debian.

After the package upgrades needrestart issued a restart of the following 
services:
  Restarting services...
   /etc/needrestart/restart.d/systemd-manager
   systemctl restart arpwatch.service chrony.service cron.service 
haveged.service networking.service rsyslog.service serial-getty@ttyS0.service 
smartd.service ssh.service systemd-udevd.service unbound.service

Quite a few of these services failed to restart however, since they rely on 
network interfaces which were down due to the restart of networking.service. 
SSHD, for example, logged this:
  sshd: error: Bind to port 22 on 172.16.2.1 failed: Cannot assign requested 
address.
  sshd: fatal: Cannot bind any address.

Other networking related services such as unbound, dhcpcd and arpwatch failed 
at the same time.

Therefore, I suggest to blacklist networking.service.


Thanks!


-- Package-specific info:
needrestart output:



-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages needrestart depends on:
ii  dpkg   1.18.25
ii  gettext-base   0.19.8.1-2
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.23-1
ii  libproc-processtable-perl  0.53-2
ii  libsort-naturally-perl 1.03-1
ii  libterm-readkey-perl   2.37-1
ii  perl   5.24.1-3+deb9u5
ii  xz-utils   5.2.2-1.2+b1

Versions of packages needrestart recommends:
ii  libpam-systemd  232-25+deb9u9

Versions of packages needrestart suggests:
pn  needrestart-session | libnotify-bin  

Bug#922242: lucene-solr: CVE-2017-3164

[Markus Koschany]

Am 19.02.19 um 17:40 schrieb Moritz Mühlenhoff:
> On Fri, Feb 15, 2019 at 11:21:13AM +0100, Markus Koschany wrote:
[...]
>>
>> Upstream solved this problem by adding a new whitelist option for nodes
>> and shards and what they can request. In the latest version Zookeeper
>> would keep track of all the distributed nodes (SolrCloud), so this new
>> option is meant for legacy releases like the one shipped by Debian or
>> simply for a more fine grained control. I think this is a new security
>> feature but not a fatal flaw that we have to patch. In my opinion it
>> could be ignored.
> 
> Agreed, I think we can simply mark it as unimportant in the Security
> Tracker and close this bug.
> 
> Cheers,
> Moritz

Ok, let's do that.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#917030: python-pykmip: CVE-2018-1000872

[Moritz Mühlenhoff]

On Fri, Dec 21, 2018 at 07:13:52PM +0100, Salvatore Bonaccorso wrote:
> Source: python-pykmip
> Version: 0.7.0-2
> Severity: important
> Tags: patch security upstream
> Forwarded: https://github.com/OpenKMIP/PyKMIP/issues/430
> 
> Hi,
> 
> The following vulnerability was published for python-pykmip.
> 
> CVE-2018-1000872[0]:
> | OpenKMIP PyKMIP version All versions before 0.8.0 contains a CWE 399:
> | Resource Management Errors (similar issue to CVE-2015-5262)
> | vulnerability in PyKMIP server that can result in DOS: the server can
> | be made unavailable by one or more clients opening all of the
> | available sockets. This attack appear to be exploitable via A client
> | or clients open sockets with the server and then never close them.
> | This vulnerability appears to have been fixed in 0.8.0.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2018-1000872
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000872
> [1] https://github.com/OpenKMIP/PyKMIP/issues/430

This is fixed in 
https://github.com/OpenKMIP/PyKMIP/commit/3a7b880bdf70d295ed8af3a5880bab65fa6b3932
can we please get the patch in buster?

Cheers,
Moritz

Bug#881901: #971: "management tunnel " ignores port

[OpenVPN Trac instance]

#971: "management tunnel " ignores port
-+-
 Reporter:  berni|   Owner:  (none)
 Type:  Bug / Defect |  Status:  new
 Priority:  minor|   Milestone:
Component:  Management   | Version:  OpenVPN 2.4.4
 Severity:  Not set (select this |  (Community Ed)
  one, unless your'e a OpenVPN   |  Resolution:
  developer) |
 Keywords:   |
-+-

Comment (by Philip Hands):

 Replying to [comment:2 plaisthos]:
 > I think it might haven broken this back when I did the dual stack
 patches that went into 2.4.0. Consider that this has now been broken the
 whole time in 2.4.0 and we have only one report that noticed that this
 feature is completely broken, I wonder if it might be better to just
 remove the feature in 2.5.x rather to then try to fix a feature that seems
 not to be used very much. To be honest I m not sure what the real use case
 for this feature is anyway.

 It's always possible (although perhaps unlikely) that others experiencing
 this bug could have seen the open report, and decided that they had
 nothing to add.

 Anyway, in case it makes any difference, my use case for this is that I'm
 running OpenVPN on two servers, to provide redundancy, with the clients
 configured almost at random to prefer one or the other.

 In order to be able to route from any client to any other client,
 regardless of which server they are connecting to, I run a script (cube-
 routed) that looks at the state of logged in clients on the other server,
 and adds routes (going via another OpenVPN link, between the servers) to
 ensure that one can get to the clients that are attached to the other
 server.

 It works well enough, but if there's now a better way of achieving the
 same aim, I'm fine with switching to another approach.

 I am also happy to test either that alternative, or attempts to fix this
 bug, so feel free to ask either way.

-- 
Ticket URL: 
OpenVPN Community 
OpenVPN is a layer 2/3 SSL VPN

Bug#922723: RM: conserver -- RoQA; RC-buggy, depends on openssl 1.0

[Moritz Mühlenhoff]

On Tue, Feb 19, 2019 at 10:30:37PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Tue, Feb 19, 2019 at 10:09:15PM +0100, Moritz Muehlenhoff wrote:
> > Package: ftp.debian.org
> > Severity: normal
> >
> > Please remove conserver. It hasn't seen an upload since 2016 and
> > was removed from testing since Nov 2017. It's one of the last
> > remaining packages blocking the removal of OpenSSL 1.0.
> 
> There is actually a new upstream version 8.2.2 which includes fixes
> for OpenSSL 1.1+. But buster obvioulsy will not contain conserver.
> 
> There are recent commits from january on
> https://github.com/conserver/conserver so it might be possible to
> either cherry-pick those or import 8.2.2 + followup fixes to move to
> OpenSSL 1.1.
> 
> Please thus consider to not yet remove src:conserver.

Someone should NMU it soon, then. We're down to four remaining packages
using OpenSSL 1.0 and this will not drag for more than a few weeks, the
openssl1.0 is already going on for ages.

Cheers,
Moritz

Bug#922723: RM: conserver -- RoQA; RC-buggy, depends on openssl 1.0

[Salvatore Bonaccorso]

Hi,

On Tue, Feb 19, 2019 at 10:09:15PM +0100, Moritz Muehlenhoff wrote:
> Package: ftp.debian.org
> Severity: normal
>
> Please remove conserver. It hasn't seen an upload since 2016 and
> was removed from testing since Nov 2017. It's one of the last
> remaining packages blocking the removal of OpenSSL 1.0.

There is actually a new upstream version 8.2.2 which includes fixes
for OpenSSL 1.1+. But buster obvioulsy will not contain conserver.

There are recent commits from january on
https://github.com/conserver/conserver so it might be possible to
either cherry-pick those or import 8.2.2 + followup fixes to move to
OpenSSL 1.1.

Please thus consider to not yet remove src:conserver.

Regards,
Salvatore

Bug#922724: Lots of security issues

[Moritz Muehlenhoff]

Source: zoneminder
Severity: grave
Tags: security

Please see:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8429
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8428
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8427
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8426
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8425
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8424
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8423
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7352
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7351
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7350
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7349
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7348
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7347
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7346
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7345
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7344
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7343
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7342
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7341
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7340
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7339
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7338
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7337
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7336
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7335
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7334
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7333
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7332
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7331
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7330
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7329
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7328
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7327
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7326
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7325

We should generally restrict the level of security support to something
sensible. A video surveillance systems is obviously something
that only should be exposed to trusted parties anyway, so I'd suggest
we treat zoneminder similar to e.g. ganglia (#702775), i.e.
- add a note to debian-security-support so that it flags the status
  of it
- Add a short README.Debian.security (or similar to document it also
  within the package)

Cheers,
Moritz

Bug#776246: Processed: severity of 776246 is grave

[Moritz Mühlenhoff]

On Wed, Feb 20, 2019 at 02:12:55AM +0500, Andrey Rahmatullin wrote:
> On Tue, Feb 19, 2019 at 10:00:34PM +0100, Moritz Mühlenhoff wrote:
> > If a transition (even though it's marginal in size) isn't an option at this
> > point 
> That's not for me to decide. Should we ask the RT?

Sounds like a plan, can you please ping them?

Cheers,
   Moritz

Bug#859784: Bug #859784: validns: Please migrate to openssl1.1 in Buster

[Moritz Mühlenhoff]

On Thu, Jan 10, 2019 at 08:39:36PM +0100, Joost van Baal-Ilić wrote:
> Hi Moritz,
> 
> On Thu, Jan 10, 2019 at 08:33:05PM +0100, Moritz Mühlenhoff wrote:
> > On Mon, Nov 05, 2018 at 03:13:08PM +0100, Joost van Baal-Ilić wrote:
> > > 
> > > FWIW, this work:
> > > 
> > > > validns (0.8+git20170804-1) unstable; urgency=medium
> > 
> > [..]
> > 
> > > is available from
> > > https://non-gnu.uvt.nl/debian/stretch/validns/validns_0.8+git20170804-1.dsc
> > >  .
> > > I _*might*_ have time to merge this back with what's in the Debian 
> > > archive,
> > > before the freeze.
> > 
> > What's the status?
> 
> Thanks for your interest.  Haven't done any work on it yet.
> 
> I'll visit https://wiki.debian.org/BSP/2019/01/nl/Venlo and might get to doing
> some work on it, this weekend.  However, if _you're_ interested in working on
> it: don't wait for me; go for it.

JFTR, there's now only four packages left which depend on OpenSSL 1.0 (and
thus block it's removal, I'll file an RM bug against validns next week),
so there's still time to safe it (or simply reintroduce it later).

Cheers,
Moritz

Bug#776246: Processed: severity of 776246 is grave

[Andrey Rahmatullin]

On Tue, Feb 19, 2019 at 10:00:34PM +0100, Moritz Mühlenhoff wrote:
> If a transition (even though it's marginal in size) isn't an option at this
> point 
That's not for me to decide. Should we ask the RT?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#851085: conserver: FTBFS with openssl 1.1.0

[Moritz Mühlenhoff]

On Thu, Dec 13, 2018 at 08:55:05PM +0100, Moritz Mühlenhoff wrote:
> On Tue, Jun 05, 2018 at 11:12:34PM +0200, Moritz Muehlenhoff wrote:
> > On Sun, Jun 26, 2016 at 12:21:20PM +0200, Kurt Roeckx wrote:
> > > OpenSSL 1.1.0 is about to released.  During a rebuild of all packages 
> > > using
> > > OpenSSL this package fail to build. 
> > 
> > This has now been fixed in version 8.2.2:
> > https://github.com/conserver/conserver/commit/258c2e124135257dcc6128b629b4ad157841c81c
> 
> Hi Jörgen,
> there's now only a handful of packages blocking the removal of openssl 1.0,
> are you still interested in maintaining conserver or shall we remove it from
> the archive?

I've now filed a removal bug.
 
Cheers,
Moritz

Bug#922723: RM: conserver -- RoQA; RC-buggy, depends on openssl 1.0

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove conserver. It hasn't seen an upload since 2016 and
was removed from testing since Nov 2017. It's one of the last
remaining packages blocking the removal of OpenSSL 1.0.

Cheers,
Moritz

Bug#922721: RM: reconserver -- RoQA; unmaintained, RC_buggy, unused

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove reconserver. It's dropped from testing for 1.5 years,
RC-buggy and it's blocking the removal of resiprocate (and in turn
OpenSSL 1.0).

Cheers,
Moritz

Bug#922722: RM: registration-agent -- RoQA; NPOAR, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove registration-agent. It has only seen two upload,
was never even in testing and it blocks the removal of resiprocate
from the archive.

Cheers,
Moritz

Bug#922720: ca-certificates-java: update-ca-certificates fails with bashism in jks-keystore

[Steven Ihde]

Package: ca-certificates-java
Version: 20170929~deb9u1
Severity: important

Dear Maintainer,

After upgrading to Debian 9.8 today, the following error results
whenever I run update-ca-certificates:

--
$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

/etc/ca-certificates/update.d/jks-keystore: 56: [: amd64: unexpected operator
done.
done.
--

This appears to be due to a bashism introduced by the fix for 874276:

---
$ checkbashisms /etc/ca-certificates/update.d/jks-keystore
possible bashism in /etc/ca-certificates/update.d/jks-keystore line 56 (should 
be 'b = a'):
if [ "$arch" == "armhf" ]; then
---

Thanks,

Steve

-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 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)

Versions of packages ca-certificates-java depends on:
ii  ca-certificates  20161130+nmu1+deb9u1
ii  libnss3  2:3.26.2-1.1+deb9u1
ii  oracle-java8-installer [openjdk-7-jre-headless]  8u201-1~webupd8~1

ca-certificates-java recommends no packages.

ca-certificates-java suggests no packages.

-- Configuration Files:
/etc/default/cacerts [Errno 13] Permission denied: '/etc/default/cacerts'

-- no debconf information

Bug#776246: Processed: severity of 776246 is grave

[Moritz Mühlenhoff]

On Sat, Feb 16, 2019 at 10:35:05PM +0500, Andrey Rahmatullin wrote:
> On Sat, Feb 16, 2019 at 12:33:08PM +, Debian Bug Tracking System wrote:
> > Processing commands for cont...@bugs.debian.org:
> > 
> > > severity 776246 grave
> > Bug #776246 [librsync1] MD4 collision/preimage attacks (CVE-2014-8242)
> > Severity set to 'grave' from 'important'
> > > thanks
> > Stopping processing here.
> > 
> > Please contact me if you need assistance.
> Fixing this requires a transition and removing or patching rdiff-backup so 
> 
> Checking reverse dependencies...
> # Broken Depends:
> burp: burp [amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips 
> mips64el mipsel ppc64el s390x]
> csync2: csync2
> duplicity: duplicity
> rdiff-backup: rdiff-backup
> 
> # Broken Build-Depends:
> burp: librsync-dev
> csync2: librsync-dev
> duplicity: librsync-dev (>= 0.9.6)
>rdiff
> rdiff-backup: librsync-dev
> 
> 
> Unfortunately I was too demotivated by the initial state of new librsync
> (1.0+) and the API breakage affecting rdiff-backup to proceed with this
> during the release cycle.

If a transition (even though it's marginal in size) isn't an option at this
point I'm fine with ignoring this for buster again, but this by all means
fixed soon after.

Cheers,
Moritz

Bug#922718: /usr/bin/xflock4: please support xfce4-screensaver

[Dominik George]

Control: retitle -1 screen locking does not work without lightdm
Control: severity -1 important

> In xflock4, please support xfce4-screensaver, which is a mate-screensaver
> fork targeted at Xfce4 integration.
> 
> If installed, it should get the same priority as mate-screensaver (probably
> one higher).

If possible, please also recommend xfce4-screensaver in xfce4-session.
This ensures screen locking works out of the box in environments without
lightdm running, e.g. under X2go or RDP, in an LTSP environment using
LDM, and probably quite a few others.

A patch is attached.

I would very much suggest to upload this as a Debian patch before buster
full freeze, even though it should of course be fixed upstream. I
personally know about some hundred desktops that do not (aand cannot)
use lightdm (see above), so this breaks quite an important use case if
not fixed.

-nik
diff -Nru xfce4-session-4.12.1/debian/changelog 
xfce4-session-4.12.1/debian/changelog
--- xfce4-session-4.12.1/debian/changelog   2017-10-21 14:39:23.0 
+0200
+++ xfce4-session-4.12.1/debian/changelog   2019-02-19 21:50:35.0 
+0100
@@ -1,3 +1,11 @@
+xfce4-session (4.12.1-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support and recommend xfce4-screensaver for environments without
+lightdm (like remote desktop or LTSP; closes: #922718).
+
+ -- Dominik George   Tue, 19 Feb 2019 21:50:35 +0100
+
 xfce4-session (4.12.1-6) unstable; urgency=medium
 
   * debian/control:
diff -Nru xfce4-session-4.12.1/debian/control 
xfce4-session-4.12.1/debian/control
--- xfce4-session-4.12.1/debian/control 2017-10-21 14:20:13.0 +0200
+++ xfce4-session-4.12.1/debian/control 2019-02-19 21:50:28.0 +0100
@@ -39,6 +39,7 @@
 systemd-sysv [linux-any] | systemd-shim,
 upower,
 x11-xserver-utils,
+xfce4-screensaver,
 xfdesktop4,
 xfwm4
 Suggests: fortunes-mod, sudo
diff -Nru 
xfce4-session-4.12.1/debian/patches/03_xflock4-update-lockers-list.patch 
xfce4-session-4.12.1/debian/patches/03_xflock4-update-lockers-list.patch
--- xfce4-session-4.12.1/debian/patches/03_xflock4-update-lockers-list.patch
2017-10-21 14:15:19.0 +0200
+++ xfce4-session-4.12.1/debian/patches/03_xflock4-update-lockers-list.patch
2019-02-19 21:49:42.0 +0100
@@ -1,11 +1,12 @@
 --- a/scripts/xflock4
 +++ b/scripts/xflock4
-@@ -27,7 +27,9 @@ export PATH
+@@ -27,7 +27,10 @@ export PATH
  # Lock by xscreensaver or gnome-screensaver, if a respective daemon is running
  for lock_cmd in \
  "xscreensaver-command -lock" \
 -"gnome-screensaver-command --lock"
 +"light-locker-command --lock" \
++"xfce4-screensaver-command --lock" \
 +"gnome-screensaver-command --lock" \
 +"mate-screensaver-command --lock"
  do


signature.asc
Description: PGP signature

Bug#875358: Fails with Java 9, >2.0.0 required to work

[Markus Koschany]

On Sun, 10 Sep 2017 21:41:52 +0100 Chris West  wrote:
> Source: powermock
> Version: 1.6.6
> Severity: normal
> User: debian-j...@lists.debian.org
> Usertags: default-java9
> 
> Powermock fails to work properly on Java 9.


Powermock still fails to build but has not been removed from testing yet
because it has several reverse-build-dependencies:

reverse-depends -b libpowermock-java

Reverse-Build-Depends-Indep
===
* jline2

Reverse-Build-Depends
=
* commons-email
* dnssecjava
* libcommons-compress-java
* shiro


I don't really believe that we can still upgrade powermock to 2.x. So
the question is what to do. Worst case is to disable the tests in the
above packages and to remove libpowermock-java from B-D.





signature.asc
Description: OpenPGP digital signature

Bug#922719: src:libpdfbox-java: FTBFS in buster and sid after recent update to lcdf-typetools

[tony mancill]

Package: src:libpdfbox-java
Version: 1:1.8.16-1
Severity: serious
Justification: Policy 4.15

The package FTBFS with the following error after a recent update to
lcdf-typetools:

[...]
make[1]: Leaving directory '/build/libpdfbox-java-1.8.16'
   jh_linkjars -O--buildsystem=maven
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/libpdfbox-java-1.8.16'
# work around downloading adobe file
mkdir -p pdfbox/target/classes/org/apache/pdfbox/resources/cmap
cp pdfbox/src/main/resources/org/apache/pdfbox/resources/cmap/* 
pdfbox/target/classes/org/apache/pdfbox/resources/cmap/
mkdir -p pdfbox/target/classes/org/apache/pdfbox/resources/afm
cp /usr/share/htmldoc/fonts/*.afm  
pdfbox/target/classes/org/apache/pdfbox/resources/afm/
cp /usr/share/lcdf-typetools/glyphlist.txt 
pdfbox/target/classes/org/apache/pdfbox/resources
cp: cannot stat '/usr/share/lcdf-typetools/glyphlist.txt': No such file or 
directory
make[1]: *** [debian/rules:22: override_dh_auto_build] Error 1
make[1]: Leaving directory '/build/libpdfbox-java-1.8.16'
make: *** [debian/rules:8: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Bug#859224: netkit-ftp-ssl: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

On 2019-01-10 23:59:09 [+0100], Christoph Biedl wrote:
> Sebastian Andrzej Siewior wrote...
> 
> > On 2019-01-10 20:31:10 [+0100], Moritz Mühlenhoff wrote:
> >
> > > Or should we rather remove netkit-ftp-ssl? There are TLS-capable ftp 
> > > client
> > > alternatives in the archive still, e.g. lftp.
> > 
> > I provided a patch after Mats described how bad the new openssl is. I
> > never got and reply and I will not cry if it gets RMed.
> > 
> > There is also #912126 [0] was set pending by Christoph on Fri, 30 Nov
> > 2018 14:39:06 GMT. It would be good to know if Christoph plans to
> > address both issues or just the one in #912126. Eitherway, both need to
> > be fixed in order to get this to testing. And it would a waste if it
> > gets RMed after adressing #912126.
> 
> Indeed my plan was (and is) to address both. My attention got drawn away
> a bit, but I understand this should be addressed soon. I'll try to get
> this done by Monday.

Do you still plan to address this or should a RM be filled? The window
for Buster has been closed imho.

> Christoph

Sebastian

Bug#903125: exec-maven-plugin: FTBFS in stretch (expected:<[mvn] --version> but was:<['mvn'] --version>)

[Markus Koschany]

Control: severity -1 important

On Fri, 06 Jul 2018 13:25:28 + Santiago Vila  wrote:
> Package: src:exec-maven-plugin
> Version: 1.1.1+dfsg-3
> Severity: serious
> Tags: ftbfs

Buster/Sid is not affected. Since there is also a simple workaround for
stable and oldstable (disabling the tests), I am going to lower the
severity to important.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#919977: security-tracker: https://security-tracker.debian.org/tracker/data/json returns stale data

[Salvatore Bonaccorso]

Hi Julien,

On Tue, Feb 12, 2019 at 10:28:54AM +0100, Julien Cristau wrote:
> On 2/12/19 7:18 AM, Salvatore Bonaccorso wrote:
> > Agreed on leaving the bug open until clearer what is going on?
> 
> Ack.

Right now this seem to be again stalled, at least from some locations.

Regards,
Salvatore

Bug#922718: /usr/bin/xflock4: please support xfce4-screensaver

[Dominik George]

Package: xfce4-session
Version: 4.12.1-6
Severity: wishlist
File: /usr/bin/xflock4

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In xflock4, please support xfce4-screensaver, which is a mate-screensaver
fork targeted at Xfce4 integration.

If installed, it should get the same priority as mate-screensaver (probably
one higher).

Thanks!

- -- 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.19.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-session depends on:
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-7
ii  libcairo2  1.16.0-2
ii  libdbus-1-31.12.12-1
ii  libdbus-glib-1-2   0.110-4
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3
ii  libgdk-pixbuf2.0-0 2.38.0+dfsg-7
ii  libglib2.0-0   2.58.3-1
ii  libgtk2.0-02.24.32-3
ii  libice62:1.0.9-2
ii  libpango-1.0-0 1.42.4-6
ii  libpangocairo-1.0-01.42.4-6
ii  libpangoft2-1.0-0  1.42.4-6
ii  libpolkit-gobject-1-0  0.105-25
ii  libsm6 2:1.2.3-1
ii  libwnck22  2.30.7-6
ii  libx11-6   2:1.6.7-1
ii  libxfce4ui-1-0 4.12.1-3
ii  libxfce4util7  4.12.1-3
ii  libxfconf-0-2  4.12.1-1
ii  xfce4-settings 4.12.4-1
ii  xfconf 4.12.1-1

Versions of packages xfce4-session recommends:
ii  dbus-x11   1.12.12-1
ii  libpam-systemd 240-6
ii  light-locker   1.8.0-3
ii  systemd-sysv   240-6
ii  upower 0.99.9-3
ii  x11-xserver-utils  7.7+8
ii  xfdesktop4 4.12.4-2
ii  xfwm4  4.12.5-1

Versions of packages xfce4-session suggests:
pn  fortunes-mod  
ii  sudo  1.8.27-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKJBAEBCgBzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlxsZdQxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p
ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylp6YEADDCTHw
4WJoRhOnuyQKwYlUHyxSJoV17XUska5V2/3luG+7vEwJ0si3CZbuu67iVqmDV6aq
roklKW8OPqBSLkbARcL8sF1KZ78UGvGHneHr9Dku+3ceG/ry0bsm0FCYmV5/2Lwv
QsBAGExzlG8i4mzrGRGvnm9Ql48LpTGy4RxmpBdWcfk9ArseZ2haiTkuJrvcWvXe
SrwqDOS5UpxdahXsVBcEn1DJidWrn4BbFiaWDbJb+v1KgViNDld9hoK2JLVbotxB
BPeb2PGvYdO93pE0tK1JsMgUvUGm5D+dSIyks1mVAtZl/YT1jrR56z0NTJhm1sMi
4HoJTG6dMnw5DiJrfSVCE8Qo9vcqQqie4xWtYHoyACGp5xtfZRLNXRhMQBgbymUV
28uSIhiK+JW/5ZjivezoPC2POSYhS8Q/YuBTMnP5DN6VsE90beJD9usWdCgyiXl5
aYl7grBMAWxVl2Qs+XKq7dzA2HS4IJkotrzBf/gOc8zh5XOR64rTNtjvexlpWPAQ
dhbA42CFdjjkrGlu3F8Yqt9wvWTEA3zuszLwL4AeFKf5oMGI5tXztvhU4oPbi+eZ
t31fAyyeVDyevmqlQMCvpn4fqpyfEA25yr1iGLl+vG9lHk8K9WHCmAH8GynnA2s2
4lKfttFNWButL8oDd/YwqjsRNFIqZuYlYkGExg==
=ijW6
-END PGP SIGNATURE-

Bug#922247: security-tracker: please use new urlpath for DLAs on www.d.o

[Salvatore Bonaccorso]

Hi HOlger,

On Thu, Feb 14, 2019 at 07:08:23AM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + pending
> 
> Hi Holger,
> 
> On Wed, Feb 13, 2019 at 06:08:31PM +, Holger Levsen wrote:
> > package: security-tracker
> > x-debbugs-cc: debian-...@lists.debian.org
> > 
> > Hi,
> > 
> > this is a bug to track fixing this small glitch in the new
> > www.debian.org/lts/security/ area:
> > 
> > On Mon, Feb 11, 2019 at 04:26:38PM -0500, Antoine Beaupr?? wrote:
> > > >> * Adaptation in the security tracker so the new URL paths are used from
> > > >> now on is also needed.
> > > > right. shall we file a bug to not forget this?
> > > Sure, please do.
> > 
> > done. Salvatore also prepared a patch for this.
> 
> https://salsa.debian.org/security-tracker-team/security-tracker/commit/cfccb4bb04d4bc5129645fa48d17914d3fbf8936
> for reference. Bug can be closed once deployed.

Done.

Regards,
Salvatore

Bug#922662: xboxdrv: does not create a systemd service

[南]

> FYI you don't need xboxdrv to use the controller.

Yes I know, but the xpad kernel driver messes up the inputs of my controller in 
games. The only workaround I found was to blacklist xpad, install and configure 
xboxdrv with the systemd service and then the controller would work perfectly.

Bug#922717: uap-core: CVE-2018-20164

[Salvatore Bonaccorso]

Source: uap-core
Version: 20181019-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for uap-core.

CVE-2018-20164[0]:
| An issue was discovered in regex.yaml (aka regexes.yaml) in UA-Parser
| UAP-Core before 0.6.0. A Regular Expression Denial of Service (ReDoS)
| issue allows remote attackers to overload a server by setting the
| User-Agent header in an HTTP(S) request to a value containing a long
| digit string. (The UAP-Core project contains the vulnerability,
| propagating to all implementations.)

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20164
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20164
[1] https://www.x41-dsec.de/lab/advisories/x41-2018-009-uaparser/

Regards,
Salvatore