Bug#882640: Fwd: dm-zoned-tools uploaded to mentors.debian.net

[Andrew Worsley]

Deleted the previous upload and uploaded the package again to get a
clean the upload and fix the revision numbers.
The original revision number implied it was built from upstream
release 1.0.1 which was not correct.

Fixed the various issues mentioned in previous package comments.

-- Forwarded message -
From: mentors.debian.net 
Date: Fri, 4 Jan 2019 at 18:41
Subject: dm-zoned-tools uploaded to mentors.debian.net
To: 


Hi.

Your upload of the package 'dm-zoned-tools' to mentors.debian.net was
successful. Others can now see it. The URL of your package is:
https://mentors.debian.net/package/dm-zoned-tools

The respective dsc file can be found at:
https://mentors.debian.net/debian/pool/main/d/dm-zoned-tools/dm-zoned-tools_0.0~git20180830.9188cc0-1.dsc

If you do not yet have a sponsor for your package you may want to go to
https://mentors.debian.net/sponsors/rfs-howto/dm-zoned-tools
and set the "Seeking a sponsor" option to highlight your package on the
welcome page.

You can also send an RFS (request for sponsorship) to the debian-mentors
mailing list. Your package page will give your suggestions on how to
send that mail.

Good luck in finding a sponsor!

Thanks,

--
mentors.debian.net

Bug#918192: No email notification of autopkgtest failure

[Rebecca N. Palmer]

Package: tracker.debian.org,debci

https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation 
says autopkgtest failures trigger an automatic email.


When theano recently started failing [0] (#918090), no such email was 
received, either to its maintainer list [1] or to me (subscribed to 
theano on tracker.d.o).


Is this mechanism broken, or was it deliberately disabled?

[0] https://ci.debian.net/packages/t/theano/unstable/amd64/
[1] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2018-December/date.html

Bug#854324: lis debian package

[Gürkan Myczko]

Hi, meanwhile a newer version was released, and it moved here:

http://phd-sid.ethz.ch/debian/lis/

Best,

Bug#911832: polyfill should be dropped

[David Prévot]

Hi Kunal,

Le 04/01/2019 à 16:12, Kunal Mehta a écrit :
> On 1/3/19 6:57 PM, David Prévot wrote:
>> Le 04/01/2019 à 12:50, Kunal Mehta a écrit :
>>> This patch adds overrides for all symfony/polyfill-* packages to
>>> pkg-php-tools itself, so all packages will automatically use it and no
>>> longer automatically depend upon php-symfony-polyfill-* (and will cover
>>> all current dependencies).
>>
>> Overrides can be added “locally” (for the build, in
>> debian/pkg-php-tools-overrides, see e.g. twig). Anyway, this is not the
>> only needed step, see below.
> 
> Right. Are you saying you'd rather have the overrides in the individual
> packages instead of in pkg-php-tools?

Since packages need to be rebuilt from source as binNMU are still (even
for arch-all only source packages) not allowed for binary-all, we don’t
need an archive-wide workaround (and you already pointed that there are
only a handful of packages involved).

> I'm happy to prepare patches (and
> NMUs if necessary) either way

Great. Feel free to team-upload stuff under the PHP PEAR (and Composer)
umbrella too.

> but I think we still need a pkg-php-tools
> patch to support dropping the version constraint, which is included in
> my current merge request.

No opinion about pkg-php-tools, I’ll let Mathieu follow up.

>>> And this one drops php-symfony-polyfill-*

Just for the record (since I failed to point why those polyfill were
packaged in first place), those packages may be useful in backport-style
environments where the PHP version or extension constraints are
different than the usual Debian environments.

Also, I don’t mind if php-symfony-polyfill is gracefully removed from
testing (and thus the next Buster release) unless someone feels that it
may be useful.

[…]
>> You also (rightfully) changed the autoload files. It’s not “just” a
>> matter of removing the (build-)dependencies.
> 
> Ack, I just wrote the commit message before I realized those also needed
> to be removed.

Fine by me (I just had to look at the actual MR to find out if you took
everything into account).

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#899595: Invalid maintainer address pkg-xfce-de...@lists.alioth.debian.org

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2019-01-04 at 08:39 +0900, Hideki Yamane wrote:
> Hi,
> 
>  With Bugs search "Cleaner view", I've found those bugs are not closed
>  in unstable but are done in experimental. 

Hi, I am well aware of these, thanks.

> Do you have a plan to put them
>  into unstable, or just apply only those fixes to current unstable packages?

Not right now.
> 
>  I know xfce4.13 series are development release, but some projects like
> Fedora
>  and Xubuntu have released 4.13 series as discussed at
>  https://mail.xfce.org/pipermail/xfce4-dev/2018-July/032143.html
>  
We already shipped Xfce development release in stable previously, and I don't
want to do that again, so no, I'm waiting for stable releases. If it happens
before freeze, fine, if not then it'll be for Bullseye.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwvGVkACgkQ3rYcyPpX
RFux+Af+LhC020PuKdWr6uwIl4uJtR6WintK2RXrL0xTMXaU/hjFjRP0MpxJlkmR
DfDlA0tYCsUueNaJl5WkGUbsAepyIW77mr6yLOgikL2mveIRAMI4XGMHjj0nzu03
QEDGlk7BeAMn7DIuHg4W/pwnlSCb//CoTNoJmb4CqdU7JNolMuoBgBRk4vk6Z73i
JZi53w1corx5Bq3juv+ETkb4UoJBKCoRSdq87l2bX5klqyOFxn0Rz8K+Vo1lqmry
/gGdplBGFDh1EP3fyD98Bb8pjkemmm+VN9taBnEvXCAnVSQfEI48ltK6GHXVATMp
bOJu2ZnzOCCiYIOdeIELCFq2q1REmg==
=793v
-END PGP SIGNATURE-

Bug#911285: Current version is incompatible with Thunderbird 60

[Bastian Venthur]

On 03.01.19 23:35, Moritz Mühlenhoff wrote:


The package wasn't updated for a year, shall we remove it?


Probably, people can easily use the extension from Mozillas Addon Store.


Cheers,

Bastian

--
Dr. Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org

Bug#918157: openmpi seems broken on 32 bits architectures

[Graham Inggs]

Control: user debian...@lists.debian.org
Control: usertag -1 regression

Hi

In Ubuntu, the upload of openmpi 3.1.3-7 has caused numerous
autopkgtest failures on i386 and armhf [1].  Some affected packages
are: combblas; dune-grid, lammps, liggghts, petsc, ray and
superlu-dist.

I re-tried these tests after the upload of pmix 3.1.0~rc2-2 but the
failures persisted, e.g. combblas [2],

Regards
Graham


[1] 
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openmpi
[2] http://autopkgtest.ubuntu.com/packages/c/combblas/disco/i386

Bug#917060: [Pkg-rust-maintainers] Bug#917060: rust-nix: Please update to latest upstream version for sparc64 fixes

[John Paul Adrian Glaubitz]

Hi Paride!

On 1/3/19 4:14 PM, Paride Legovini wrote:
> The packaging is ready, but nix 0.12 build-depends on rust-libc >=
> 0.2.44, so that package needs to be updated first.

Thanks for the feedback. I have also updated rust-libc upstream to
release 0.2.46. It would be useful to package the latest libc version
as it contains small fixes for mips and s390x.

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#918190: systemd: timesyncd stopped updating clock file after package update

[Patrick Häcker]

Hi,

the problem seems to be mixing two approaches in an incompatible way:

1) /var/lib/systemd/timesync can either be a directory (a) or a symlink to
/var/lib/private/systemd/timesync (b)

2) systemd-timesyncd.service may either contain DynamicUser=yes (a) or not 
(b).

1a together with 2b should work as should 1b together with 2a.

With systemd 240-2 the combination 1b-2b seems to be used, which cannot work.

I just tested both combinations 1a-2b and 1b-2a and they work both.

But which package created the symlink (i.e. the transition from 1a to ab)? 
According to the symlink's timestamp (do not confuse with the clock's 
timestamp) and dpkg's log this was due to the upgrade from systemd version 
232-25+deb9u6 to 239-15.

So I guess the least intrusive change is to have systemd change /var/lib/
systemd/timesync back to being a directory. This only breaks if a user 
manually switched to DynamicUser, so it might be worth mentioning in the 
changelog.

Kind regards
Patrick

On Fri, 04 Jan 2019 07:27:05 +0100 =?utf-8?q?Patrick_H=C3=A4cker?= 
 wrote:
> Package: systemd
> Version: 240-2
> Severity: normal
> 
> Dear Maintainer,
> 
> after updating systemd from 239-15 to 240-2 timesyncd stopped touching
> /var/lib/private/systemd/timesync/clock any more and its time stamps
> stay at the time of the package upgrade.
> Additionally the file is no longer used to update the system time after
> reboot, using the compile time instead until an NTP server is available
> (if no RTC is available).
> 
> This is reproducable for the two systems I tested (the other is on amd64).
> On both systems the last timestamp is the time of the package upgrade
> according to the dpkg log.
> Downgrading to 239-15 solves the issue and the file is updated again.
> 
> Using
> > systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M 
printk.devkmsg=on
> as linux command line boot parameter, the following error appears in the 
log:
> > systemd-timesyncd[309]: Failed to create state directory, ignoring: 
Permission denied
> 
> So the open of /var/lib/systemd/timesync in timesyncd.c, line 37, fails. The
> reason is probably
> > ls -ld /var/lib/private
> > drwx-- 3 root root 4096 Dez 20 16:03 /var/lib/private/
> as timesyncd runs with UID/GUI systemd-timesync:systemd-timesync.
> 
> The following article might be related (modulo all the noise):
> https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimesyncdFailure
> 
> Kind regards
> Patrick
> 
> 
> -- Package-specific info:
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (800, 'testing'), (700, 'stable'), (500, 'stable-updates')
> Architecture: armhf (armv7l)
> 
> Kernel: Linux 4.19.8-v7+ (SMP w/4 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 systemd depends on:
> ii  adduser  3.118
> ii  libacl1  2.2.52-3+b1
> ii  libapparmor1 2.13.1-3+b1
> ii  libaudit11:2.8.4-2
> ii  libblkid12.33-0.2
> ii  libc62.28-2
> ii  libcap2  1:2.25-1.2
> ii  libcryptsetup12  2:2.0.6-1
> ii  libgcrypt20  1.8.4-4
> ii  libgnutls30  3.6.5-2


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

Bug#917303: Request for help with MariaDB 10.3 / libdbd-mysql-perl packaging

[pali]

Hello!

The main problem is that DBD::mysql touches internal libmariadb.so
structures which for obvious reasons do not have stable nor documented
API.

In DBD::MariaDB I replaced this code by usage of public Connector/C API.
But for buggy Perl application this may cause incompatibility.

Changes are in this pull request:
https://github.com/gooddata/DBD-MariaDB/pull/63

To prevent breakage of other Perl modules which uses DBD::mysql I
strongly suggest to stick with MySQL Connector/C or use MariaDB 10.0 or
10.1 which is known to work.

One of the reason why I forked and created DBD::MariaDB instead of
touching DBD::mysql is support for MariaDB 10.2+, 10.3+.

Basically touching these parts of DBD::mysql code may cause problems for
applications which misuse bugs in DBD::mysql. There was long discussion
about it 2 years ago and people decided that it rather should not be
changed. (Reason for fork and move to DBD::MariaDB). If you want to
prevent any possible breakage, then you have no other option and should
stick with either MySQL 5.5-5.7 or with MariaDB 10.0/10.1.

And if you really want to update MariaDB to 10.3, I strongly suggest to
also update packages from DBD::mysql to DBD::MariaDB.

For DBD::MariaDB we have large test coverage with different MySQL and
MariaDB versions, including MariaDB 10.3 and 10.4 series, see:

https://travis-ci.org/gooddata/DBD-MariaDB

Seems that in DBD::mysql upstream rather decided to drop MariaDB 10.3
support as trying to fix it, see:

https://github.com/perl5-dbi/DBD-mysql/commit/0c4fee5d928efdf937fdf5fdba5f4873b01848ef

And rather started fixing support for MySQL 8.0 series:

https://github.com/perl5-dbi/DBD-mysql/commit/08df02eabf08de62a5e363fbf852ca51f685a8ce

Maybe another option can be inclusion of MySQL 8.0 for DBD::mysql?

Bug#917060: [Pkg-rust-maintainers] Bug#917060: rust-nix: Please update to latest upstream version for sparc64 fixes

[Paride Legovini]

X-Debbugs-CC: wolfg...@silbermayr.at

John Paul Adrian Glaubitz wrote on 04/01/2019:
> On 1/3/19 4:14 PM, Paride Legovini wrote:
>> The packaging is ready, but nix 0.12 build-depends on rust-libc >=
>> 0.2.44, so that package needs to be updated first.
> 
> Thanks for the feedback. I have also updated rust-libc upstream to
> release 0.2.46. It would be useful to package the latest libc version
> as it contains small fixes for mips and s390x.

I see that rust-libc 0.2.45-1 is in NEW (I guess it introduces a new
binary package), so it is now a matter of patience...

Cheers,

Paride

Bug#918142: linux-image-4.19.0-1-amd64: Can no longer disable the touchscreen module

[fakefur]

makes no difference
i cannot disable the touchscreen


On Thu, 2019-01-03 at 20:15 +, Ben Hutchings wrote:
> Control: tag -1 moreinfo
> 
> On Thu, 2019-01-03 at 20:19 +0100, lauren wrote:
> > Package: src:linux
> > Version: 4.19.12-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > *** Reporter, please consider answering these questions, where
> > appropriate ***
> > 
> >* What led up to the situation?
> > upgraded to kernel 4.19 as part of regular debian apt update
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > i added "blacklist hid_multitouch" to
> > /etc/modprobe.d/blacklist.conf
> > 
> >* What was the outcome of this action?
> > no effect - the touchscreen is still active
> > 
> >* What outcome did you expect instead?
> > that the touchscreen was not active
> [...]
> 
> The kernel doesn't load modules itself; that's controlled by systemd,
> initramfs-tools, etc.
> 
> If you only recently updated the modprobe configuration, try running
> "update-initramfs -u" and then rebooting.  Does that fix the problem?
> 
> Ben.
> 

Bug#918193: flash-kernel: add Seagate Blackarmor NAS220 to machine db

[Hajo Noerenberg]

Package: flash-kernel
Version: 3.96
Severity: wishlist
Tags: patch

Add database entry for the Seagate Blackarmor NAS220.

More details and installation instructions may be found at
https://github.com/hn/seagate-blackarmor-nas


diff --git a/db/all.db b/db/all.db
index 5b227a4..6197d08 100644
--- a/db/all.db
+++ b/db/all.db
@@ -1509,6 +1509,16 @@ Boot-Script-Path: /boot/boot.scr
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools

+Machine: Seagate Blackarmor NAS220
+Kernel-Flavors: kirkwood marvell
+DTB-Id: kirkwood-blackarmor-nas220.dtb
+DTB-Append: yes
+Mtd-Kernel: uimage
+Mtd-Initrd: rootfs
+U-Boot-Kernel-Address: 0x0004
+U-Boot-Initrd-Address: 0x0080
+Required-Packages: u-boot-tools
+
 Machine: Seagate FreeAgent Dockstar
 Machine: Seagate FreeAgent DockStar
 Kernel-Flavors: kirkwood marvell

Bug#918190: systemd: timesyncd stopped updating clock file after package update

[Michael Biebl]

Hello,

systemd-timesyncd.service in previous releases used DynamicUser=true.
This will create a symlink /var/lib/systemd/timesync pointing at
../private/systemd/timesync and make sure it is properly owned by
systemd-timesync:systemd-timesync

This was reverted upstream in
https://github.com/systemd/systemd/commit/162e0b75f9c9f698f94c228c2f9148120f03e9a2

Am 04.01.19 um 07:27 schrieb Patrick Häcker:

> So the open of /var/lib/systemd/timesync in timesyncd.c, line 37, fails. The
> reason is probably
>> ls -ld /var/lib/private
>> drwx-- 3 root root 4096 Dez 20 16:03 /var/lib/private/
> as timesyncd runs with UID/GUI systemd-timesync:systemd-timesync.


Can you post the output of
ls -ld /var/lib/systemd/timesync
ls -la /var/lib/private/systemd/

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#918194: Updating the syslog-ng-incubator Uploaders list

[Mattia Rizzolo]

Source: syslog-ng-incubator
Version: 0.6.2-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Gergely Nagy  has retired, so can't work on
the syslog-ng-incubator package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#918195: Updating the edbrowse Uploaders list

[Mattia Rizzolo]

Source: edbrowse
Version: 3.7.4-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

 Gergely Nagy  has retired, so can't work on
the edbrowse package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#878121: Updates about BLAS64

[Sébastien Villemot]

Le mardi 18 décembre 2018 à 15:12 +, Mo Zhou a écrit :
> On Tue, Dec 18, 2018 at 12:42:22PM +0100, Sébastien Villemot wrote:
> > > BTW, what is the "-base" (in libopenblas-base) supposed to mean?
> > 
> > I don't even remember what it means, but it is clearly a legacy from
> > the past. Ideally the package should be named "libopenblas0". But I did
> > not bother with transitioning from one to the other, since it is rather
> > tedious, with strictly zero benefit for users.
> 
> Then it's a good chance for us to get rid of it, when modifying the
> package layout. We can avoid a transition if we turn the old pacakges
> into meta packages. I still prefer my proposed package layout, i.e.
> 
>   libopenblas0 (meta):
> deps: libopenblas0-openmp | libopenblas0-pthread | ...
>   libopenblas-base (meta, because it cannot be safely removed):
> deps: libopenblas0
>   libopenblas0-openmp:
> conflicts: libopenblas0-pthread, ...
> 
>   libopenblas-dev (meta):
> deps: libopenblas0,
>   libopenblas-openmp-dev | libopenblas-pthread-dev | ...
>   libopenblas-openmp-dev:
> conflicts: libopenblas-pthread-dev, ...
> 
> Such layout has several advantages:
> 
>   1. compared to (libopenblas0 i.e. pthread version, libopenblas0-openmp),
>  the (libopenblas0-openmp, libopenblas0-pthread) layout is more
>explicit and tidy.
> 
>   2. we can control the default openblas implementation by adjusting
>  the dependency of libopenblas0 (meta) and libopenblas-dev (meta).
>And maintainers of reverse dependencies won't have the headache to
>choose one from (openmp, pthread, ...)
> 
>   3. won't break packages that depend on libopenblas-base

Ok, I think you convinced me.

Note that we also want a libopenblas0-serial.

(I'm CC'ing #878121 so that we don't forget this layout proposal for OpenBLAS).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


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

Bug#918103: ipv6: Consider sk_bound_dev_if when binding a socket to an address

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream pending patch

Hi Ralf,

On Thu, Jan 03, 2019 at 12:14:05PM +0100, Ralf Jung wrote:
> Package: linux-image-4.18.0-0.bpo.3-amd64
> Version: 4.18.20-2~bpo9+1
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> I reported an upstream bug at 
>  that got a patch 
> submitted with .
> It would be great to have this patch applied to the next Debian kernel update.

Queued it up for our next sid upload, as per
https://salsa.debian.org/kernel-team/linux/commit/c91e16558f8fe6f1fa4df2faa27ad69afa397d03
.

Regards,
Salvatore

Bug#917323: transition: gdal

[Emilio Pozuelo Monfort]

On 03/01/2019 17:44, Sebastiaan Couwenberg wrote:
> On 1/3/19 4:39 PM, Sebastiaan Couwenberg wrote:
>> On 1/3/19 4:23 PM, Emilio Pozuelo Monfort wrote:
>>> On 02/01/2019 21:10, Sebastiaan Couwenberg wrote:
 On 1/2/19 12:55 PM, Emilio Pozuelo Monfort wrote:
> On 26/12/2018 08:46, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> For the Debian GIS team I'd like to transition to GDAL 2.4.0.
>>
>> Like the previous transition to GDAL 2.3.0 (#898566), there is no SONAME
>> bump, only the virtual ABI package changed to account for the C++ symbol
>> changes.
>>
>> All reverse dependencies rebuilt successfully with GDAL 2.4.0 from
>> experimental as summarized below, except mysql-workbench due to an
>> unrelated issue (#914761).
>>
>> libgdal-grass doesn't need a binNMU as the 2.4.0 version will be
>> uploaded to unstable instead. liblas likewise doesn't need a binNMU,
>> the version is experimental will be moved to unstable instead.
>
> Go ahead.

 Thanks.

 gdal (2.4.0+dfsg-1), liblas (1.8.1-9) & libgdal-grass (2.4.0-1) have
 been uploaded to unstable, and gdal (2.4.0+dfsg-1) is now installed on
 all release architectures.
>>>
>>> Looks like the rebuilt gazebo fails its autopkgtest due to a broken 
>>> gazebo.pc,
>>> see #918121. That causes migration delays for gdal. No idea where the broken
>>> flag is coming from, I haven't investigated that deep.
>>
>> That looks like @Boost_PKGCONFIG_LIBS@ which is constructed in
>> CMakeLists.txt with:
>>
>>   foreach (b ${Boost_LIBRARIES})
>> get_filename_component(bname ${b} NAME_WE)
>> # Prefix always -l
>> set (bname "-l${bname}")
>> # Remove the prefix lib (not always present, like in pthread)
>> string (REPLACE "lib" "" bname "${bname}")
>> set (Boost_PKGCONFIG_LIBS "${Boost_PKGCONFIG_LIBS} ${bname}")
>>   endforeach(b)
>>
>> get_filename_component() seems to return an empty string for one of the
>> boost libraries.
> 
> Patch submitted in #918128.
> 
> That just leaves python-numpy breaking many autopkgtests, which I'm not
> in a position to fix.

Can you file a bug report?

Emilio

Bug#918196: vboxdrv: module verification failed: signature and/or required key missing - tainting kernel

[Maria]

Package: virtualbox-dkms
Version: 5.2.22-dfsg-2
Severity: normal

Dear Maintainer,

dmesg shows these error messages:

vboxdrv: loading out-of-tree module taints kernel.
vboxdrv: module verification failed: signature and/or required key missing -
tainting kernel

as I experience a whole lot of problems at startup and while starting and
running Plasma I need to eliminate errors. If you need more info I'll be glad
to provide.

Thanks for your help!




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

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

Versions of packages virtualbox-dkms depends on:
ii  dkms  2.6.1-1

Versions of packages virtualbox-dkms recommends:
ii  virtualbox  5.2.22-dfsg-2

virtualbox-dkms suggests no packages.

-- no debconf information

Bug#918190: systemd: timesyncd stopped updating clock file after package update

[Michael Biebl]

Am 04.01.19 um 10:23 schrieb Michael Biebl:
> Hello,
> 
> systemd-timesyncd.service in previous releases used DynamicUser=true.
> This will create a symlink /var/lib/systemd/timesync pointing at
> ../private/systemd/timesync and make sure it is properly owned by
> systemd-timesync:systemd-timesync

Actually, it's the combination of
StateDirectory=systemd/timesync
+
DynamicUser=true

which creates /var/lib/systemd/timesync as symlink to ../private/systemd.

This will only be a problem for users of unstable/testing, not for users
who upgrade from stretch → buster directly, as timesyncd in stretch does
not use DynamicUser=true.

That said, we should probably add some cleanup routines to remove
/var/lib/systemd/timesync and
/var/lib/private/systemd/timesync
and let the directories be recreated

Checking the other services, for which DynamicUser=true was dropped,
like systemd-resolved, they don't appear to be affected afaics as they
don't use StateDirectory.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#824495: debian-policy: Source packages "can" declare relationships

[Sean Whitton]

Hello Ian,

On Tue 20 Nov 2018 at 03:24pm GMT, Ian Jackson wrote:

> Sean Whitton writes ("Bug#824495: debian-policy: Source packages "can" 
> declare relationships"):
>> I still don't see how we can implement such new rules, though, because
>> of the problem of how to determine whether we're making masses of
>> packages RC-buggy.
>
> I'm going to go back to my table:

Thank you again for your table.  I hope that we can improve the
guidelines in Policy that are designed to ensure that packages remain
buildable outside of chroots, in reasonable circumstances.  I don't
doubt we have a project consensus that that is worth doing.

> |   Package builds MAY be affected, sometimes adversely, by the
> |   installation of additional packages beyond the Build-Depends
> |   and build-essential, subject to the following rules:
> |
> | Nature of package  EffectPermitted
> |on build output
> |
> | Installed by default   Any effectMUST NOT
> | with any Build-Depends
>
> (I take your point about deferring to apt, but bear with me for now as
> this wording is clearer for discussion.)
>
> I think almost everyone would already agree that a situation where a
> package build is affected by the presence or otherwise of packages
> Recommended by the Build-Depends, is an RC bug.  This should be fixed
> by adding the affecting package(s) to Build-Depends or Build-Conflicts
> as applicable.

Indeed.

> | Part of any reasonble  AdditionalSHOULD NOT
> | default install for features
> | development workstation
> |Build fails   SHOULD NOT,
>
> I think this is uncontroversial.  NB violations are not RC.

Agreed.

> |  MUST Build-Conflict
>
> This is newly an RC bug in my proposal.  But it is pretty close to
> existing practice.  In practice people, including maintainers, do lots
> of ad-hoc builds other than in clean chroots.  That's how one does
> much of one's development.  So must such bugs will be detected
> already.
>
> And the RC bug is very easy to fix: add a Build-Conflicts.

This is the kind of case that prompted Santiago to file this bug, so I
am not so confident about how maintainers will feel about bugs requiring
a Build-Conflicts change being filed against their packages.

> |Builds broken MUST NOT
> |packages
>
> I think everyone agrees that this is an RC bug.
>
> | Other packages AdditionalMAY
> | features
>
> This `MAY' seems a bit controversial but I am not adding a new rule.
> I'm just documenting the existing rule.

Right.

> |Build fails   SHOULD NOT,
> |  MUST Build-Conflict
>
> This latter part is newly an RC bug in my proposal.  I think that this
> is questionable and warrants further discussion.  Personally I think
> most people would agree that any missing Build-Conflicts is a serious
> bug, even if all that happens is that the build fails.  But I could be
> wrong.
>
> If this is controversial then I suggest:
>
> | Other packages Build fails   MAY,
> |  SHOULD Build-Conflict

I am much less confident than you that there is such a difference, in
terms of RC-bugginess, between the case of a package that is part of a
standard development workstation install, and the case of other
packages.

> And finally:
>
> |Builds broken MUST NOT
> |packages
>
> This again is surely not controversial.  Admittedly it is not clear
> how many packages we are making rc-buggy here, but the fix is easy,
> again: add a Build-Conflicts.

People would already consider packages RC-buggy in this case.  So the
Policy change does not /make/ them RC-buggy, so we're fine.

=

Most of your table is uncontroversial.  There are two cases where your
proposal would make packages RC-buggy where we are not completely
confident that they would already be considered RC-buggy:

(1) the package FTBFSs when a package that is part of a reasonable
standard development workstation install is present, and the package
does not declare a Build-Conflicts

(2) the package FTBFSs when a package that is not part of a reasonable
standard development workstation install is present, and the package
does not declare a Build-Conflicts

In both cases, as you've noted, the fix is highly non-disruptive: adding
a Build-Conflicts.  Doing that cannot break any maintainer workflows
because the package doesn't build with the item in the Build-Conflicts
installed.  Nevertheless, even if maintainers are quite willing to add
the Build-Conflicts entries, they might not consider the RC-severity of
the bugs to be justified.

It is okay fo

Bug#918197: Please, drop me from Uploaders

[David Prévot]

Source: twitter-bootstrap
Severity: wishlist

Please, drop me from d/control and d/copyright. I don’t even seem to
have write access to the repository in order to do it myself.

Regards

David


signature.asc
Description: PGP signature

Bug#918029: transition: corosync

[Emilio Pozuelo Monfort]

On 02/01/2019 15:21, Ferenc Wágner wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> First of all, I'm sorry for inadvertently starting the Corosync
> transition.  It isn't a problematic one, though: please schedule a
> rebuild of sheepdog and dlm on all relevant architectures, that should
> finish it.

Done.

Cheers,
Emilio

Bug#917255: transition: yaml-cpp

[Emilio Pozuelo Monfort]

On 27/12/2018 05:00, Simon Quigley wrote:
> On 12/26/18 3:39 AM, Emilio Pozuelo Monfort wrote:
>> On 24/12/2018 20:30, Simon Quigley wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>>
>>> Hello Release Team,
>>>
>>> I would like to do a yaml-cpp transition to 0.6.2 before the
>>> Transition Freeze. It has been in Experimental since December 3rd and
>>> it involves a transition from libyaml-cpp0.5d1 -> libyaml-cpp0.6. I
>>> recently took over maintenance of the package, and this is my first
>>> yaml-cpp transition.
>>
>> Do the rdeps build against the new version?
> 
> Yes, test builds all succeed.
> 
> However, since some packages conflict with the Qt transition (that I am
> also helping with), it might need to wait until those rdeps are rebuild
> as well.

The new yaml-cpp failed to build on armel. Otherwise I might have acked this.

Cheers,
Emilio

Bug#915811: nmu: pocl_1.1-7

[Emilio Pozuelo Monfort]

Hi Andreas,

On 07/12/2018 01:21, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu pocl_1.1-7 . ANY . unstable . -m "Rebuild with latest gcc to collect 
> symbol updates."
> 
> These rebuilds will fail due to changed symbols ... which is a bit
> strange since the package was already built with gcc-8.
> Such symbol changes could affect other packages as well.

If the rebuilds will fail, how's a binNMU going to help? If you meant something
else by 'these rebuilds will fail', then now there is #916024 so I suppose a
binNMU is no longer appropriate in any case.

Cheers,
Emilio

> 
> e.g. on amd64
> 
> - _ZTISt19_Sp_make_shared_tag@Base 0.10
> 
> + _ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag@Base 1.1-7
> 
> 
> Andreas
> 
> 

Bug#918157: pmix (was: openmpi) seems broken on 32 bits architectures

[Gilles Filippini]

Control: reassign -1 libpmix2 3.1.0~rc2-1
Control: retitle -1 libpmix2 seems broken on 32 bits architectures

On 2019-01-04 09:41, Graham Inggs wrote:

Control: user debian...@lists.debian.org
Control: usertag -1 regression

Hi

In Ubuntu, the upload of openmpi 3.1.3-7 has caused numerous
autopkgtest failures on i386 and armhf [1].  Some affected packages
are: combblas; dune-grid, lammps, liggghts, petsc, ray and
superlu-dist.

I re-tried these tests after the upload of pmix 3.1.0~rc2-2 but the
failures persisted, e.g. combblas [2],


I tried a build against openmpi 3.1.3-6 and experienced the very same 
FTBFS. Then I downgraded libpmix2 to 3.0.2-2 and it worked. It worked 
against openmpi 3.1.3-7 as well.

The culprit is then pmix 3.1.0~rc2.

Thanks,

_g.

Bug#917323: transition: gdal

[Sebastiaan Couwenberg]

On 1/4/19 10:36 AM, Emilio Pozuelo Monfort wrote:
> On 03/01/2019 17:44, Sebastiaan Couwenberg wrote:
>> On 1/3/19 4:39 PM, Sebastiaan Couwenberg wrote:
>>> On 1/3/19 4:23 PM, Emilio Pozuelo Monfort wrote:
 On 02/01/2019 21:10, Sebastiaan Couwenberg wrote:
> On 1/2/19 12:55 PM, Emilio Pozuelo Monfort wrote:
>> On 26/12/2018 08:46, Bas Couwenberg wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>>
>>> For the Debian GIS team I'd like to transition to GDAL 2.4.0.
>>>
>>> Like the previous transition to GDAL 2.3.0 (#898566), there is no SONAME
>>> bump, only the virtual ABI package changed to account for the C++ symbol
>>> changes.
>>>
>>> All reverse dependencies rebuilt successfully with GDAL 2.4.0 from
>>> experimental as summarized below, except mysql-workbench due to an
>>> unrelated issue (#914761).
>>>
>>> libgdal-grass doesn't need a binNMU as the 2.4.0 version will be
>>> uploaded to unstable instead. liblas likewise doesn't need a binNMU,
>>> the version is experimental will be moved to unstable instead.
>>
>> Go ahead.
>
> Thanks.
>
> gdal (2.4.0+dfsg-1), liblas (1.8.1-9) & libgdal-grass (2.4.0-1) have
> been uploaded to unstable, and gdal (2.4.0+dfsg-1) is now installed on
> all release architectures.

 Looks like the rebuilt gazebo fails its autopkgtest due to a broken 
 gazebo.pc,
 see #918121. That causes migration delays for gdal. No idea where the 
 broken
 flag is coming from, I haven't investigated that deep.
>>>
>>> That looks like @Boost_PKGCONFIG_LIBS@ which is constructed in
>>> CMakeLists.txt with:
>>>
>>>   foreach (b ${Boost_LIBRARIES})
>>> get_filename_component(bname ${b} NAME_WE)
>>> # Prefix always -l
>>> set (bname "-l${bname}")
>>> # Remove the prefix lib (not always present, like in pthread)
>>> string (REPLACE "lib" "" bname "${bname}")
>>> set (Boost_PKGCONFIG_LIBS "${Boost_PKGCONFIG_LIBS} ${bname}")
>>>   endforeach(b)
>>>
>>> get_filename_component() seems to return an empty string for one of the
>>> boost libraries.
>>
>> Patch submitted in #918128.
>>
>> That just leaves python-numpy breaking many autopkgtests, which I'm not
>> in a position to fix.
> 
> Can you file a bug report?

You mean for all packages that fail their autopkgtest with the new
numpy? Or one for python-numpy about breaking autopkgtest of its rdeps
which block the gdal transition?

Kind Regards,

Bas

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

Bug#917323: transition: gdal

[Emilio Pozuelo Monfort]

On 04/01/2019 10:57, Sebastiaan Couwenberg wrote:
> On 1/4/19 10:36 AM, Emilio Pozuelo Monfort wrote:
>> On 03/01/2019 17:44, Sebastiaan Couwenberg wrote:
>>> On 1/3/19 4:39 PM, Sebastiaan Couwenberg wrote:
 On 1/3/19 4:23 PM, Emilio Pozuelo Monfort wrote:
> On 02/01/2019 21:10, Sebastiaan Couwenberg wrote:
>> On 1/2/19 12:55 PM, Emilio Pozuelo Monfort wrote:
>>> On 26/12/2018 08:46, Bas Couwenberg wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition

 For the Debian GIS team I'd like to transition to GDAL 2.4.0.

 Like the previous transition to GDAL 2.3.0 (#898566), there is no 
 SONAME
 bump, only the virtual ABI package changed to account for the C++ 
 symbol
 changes.

 All reverse dependencies rebuilt successfully with GDAL 2.4.0 from
 experimental as summarized below, except mysql-workbench due to an
 unrelated issue (#914761).

 libgdal-grass doesn't need a binNMU as the 2.4.0 version will be
 uploaded to unstable instead. liblas likewise doesn't need a binNMU,
 the version is experimental will be moved to unstable instead.
>>>
>>> Go ahead.
>>
>> Thanks.
>>
>> gdal (2.4.0+dfsg-1), liblas (1.8.1-9) & libgdal-grass (2.4.0-1) have
>> been uploaded to unstable, and gdal (2.4.0+dfsg-1) is now installed on
>> all release architectures.
>
> Looks like the rebuilt gazebo fails its autopkgtest due to a broken 
> gazebo.pc,
> see #918121. That causes migration delays for gdal. No idea where the 
> broken
> flag is coming from, I haven't investigated that deep.

 That looks like @Boost_PKGCONFIG_LIBS@ which is constructed in
 CMakeLists.txt with:

   foreach (b ${Boost_LIBRARIES})
 get_filename_component(bname ${b} NAME_WE)
 # Prefix always -l
 set (bname "-l${bname}")
 # Remove the prefix lib (not always present, like in pthread)
 string (REPLACE "lib" "" bname "${bname}")
 set (Boost_PKGCONFIG_LIBS "${Boost_PKGCONFIG_LIBS} ${bname}")
   endforeach(b)

 get_filename_component() seems to return an empty string for one of the
 boost libraries.
>>>
>>> Patch submitted in #918128.
>>>
>>> That just leaves python-numpy breaking many autopkgtests, which I'm not
>>> in a position to fix.
>>
>> Can you file a bug report?
> 
> You mean for all packages that fail their autopkgtest with the new
> numpy? Or one for python-numpy about breaking autopkgtest of its rdeps
> which block the gdal transition?

I had assumed (without investigating) that the problem would be in numpy, but
looking at the bug report that you added to this one's blocker list, I see that
the problem is with the new deprecated functions in numpy, so it's a problem in
the rdeps (that fail because of that). So yeah I suppose all rdeps with failing
autopkgtests need bugs filed (if they don't have a bug yet) so the maintainers
can determine if it is due to those deprecation warnings or something else and
act accordingly.

Cheers,
Emilio

Bug#918199: RM: libxfcegui4 -- ROM; deprecated upstream, no reverse dependencies

[Yves-Alexis Perez]

Package: ftp.debian.org
Severity: normal

Hi,

with the orage package out of the NEW queue, we don't have any package
using libxfcegui4 in unstable anymore. Could you remove it? It's
deprecated upstream and superseeded by libxfce4ui.

Thansk in advance,
-- 
Yves-Alexis

Bug#918198: qbittorrent-nox: Please add the relevant systemd .service file for us that want to run it as a daemon

[jim_p]

Package: qbittorrent-nox
Version: 4.1.5-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

Please add support for running qbittorrent-nox as a daemon, by adding a systemd
serivice file as described here

https://github.com/qbittorrent/qBittorrent/wiki/Setting-up-qBittorrent-on-
Ubuntu-server-as-daemon-with-Web-interface-(15.04-and-newer)

or as arch implements it here
https://git.archlinux.org/svntogit/community.git/tree/trunk/qbittorrent@.service?h=packages/qbittorrent

The service does not have to be enabled by default, just make it available and
if a user wants, he can enable it himself.

Tnank you



-- 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-1-amd64 (SMP w/2 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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qbittorrent-nox depends on:
ii  libboost-system1.67.0  1.67.0-11
ii  libc6  2.28-2
ii  libgcc11:8.2.0-13
ii  libqt5core5a   5.11.3+dfsg-2
ii  libqt5network5 5.11.3+dfsg-2
ii  libqt5xml5 5.11.3+dfsg-2
ii  libstdc++6 8.2.0-13
ii  libtorrent-rasterbar9  1.1.11-2
ii  zlib1g 1:1.2.11.dfsg-1

qbittorrent-nox recommends no packages.

Versions of packages qbittorrent-nox suggests:
pn  qbittorrent-dbg  

-- no debconf information

Bug#836236: prosody: doesn't try IPv4 when IPv6 fails

[Victor Seva]

Hi Cyril,

Can you please confirm that this error does not exist in the current
version of prosody 0.11.1-1?

Thanks,
Victor Seva

Bug#836236: prosody: doesn't try IPv4 when IPv6 fails

[Cyril Brulebois]

Hi Victor,

Victor Seva  (2019-01-04):
> Can you please confirm that this error does not exist in the current
> version of prosody 0.11.1-1?

I'm running stretch so I can't really confirm. I could try the
0.11.1-1~bpo9+1 backport but before that I would need to check what
specific modules were deployed (if any); ISTR having some of them before
stretch, not entirely sure about the current setup.

If you're confident it's fixed in this version, feel free to close this
bug report; it can always be reopened later if needed.


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


signature.asc
Description: PGP signature

Bug#918200: astropy: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: astropy
Version: 3.0.5-1
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
block the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918201: astropy-healpix: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: astropy-healpix
Version: 0.4-1
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918203: ccdproc: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: ccdproc
Version: 1.3.0-5
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#898696: Similar problem with version 4:18.08.1

[Pedro Celestino dos Reis Rodrigues]

For me this behavior starts after upgrading to 4:18.08.1

Thanks for any help

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

Bug#918202: caffe: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: caffe
Version: 1.0.0+git20180821.99bd997-21.0.0+git20180821.99bd997-2
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918207: pyregion: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: pyregion
Version: 2.0-6
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918204: dask: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: dask
Version: 1.0.0+dfsg-1
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918205: hipspy: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: hipspy
Version: 0.2-2
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918206: pandas: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: pandas
Version: 0.23.3-1
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918209: pytables: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: pytables
Version: 3.4.4-1
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918208: pyscanfcs: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: pyscanfcs
Version: 0.3.2+ds-2
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918211: ovito: depends on obsolete libnetcdf11

[Nick Manini]

Package: ovito
Version: 2.8.1+dfsg2-5
Severity: normal

Hello,
in the current testing suite, ovito 2.8.1+dfsg2-5 depends on
libnetcdf11, which is an old library, and conflicts with other software,
e.g. the dependences of the grace package.

The unstable version of ovito, 2.9.0+dfsg1-5, depends on the up-to-date
libnetcdf13 so it should fix this issue.  Hovever it seems impossible to
install 2.9.0+dfsg1-5, due to 6 library dependences being currently
unavailable.

Thanks!
Nick

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

Kernel: Linux 4.18.0-3-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ovito depends on:
ii  libavcodec57   7:3.2.12-1~deb9u1
ii  libavfilter6   7:3.2.12-1~deb9u1
ii  libavformat57  7:3.2.12-1~deb9u1
ii  libavresample3 7:3.2.12-1~deb9u1
ii  libavutil557:3.2.12-1~deb9u1
ii  libbotan-1.10-11.10.16-1
ii  libc6  2.28-2
ii  libgcc11:8.2.0-13
ii  libgl1 1.1.0-1
ii  libgl1-mesa-glx18.2.8-2
ii  libmuparser2v5 2.2.3-6
ii  libnetcdf111:4.4.1.1-2
ii  libpython3.5   3.5.3-1+deb9u1
ii  libqt5concurrent5  5.11.3+dfsg-2
ii  libqt5core5a   5.11.3+dfsg-2
ii  libqt5gui5 5.11.3+dfsg-2
ii  libqt5network5 5.11.3+dfsg-2
ii  libqt5scintilla2-12v5  2.9.3+dfsg-4
ii  libqt5widgets5 5.11.3+dfsg-2
ii  libqwt-qt5-6   6.1.3-1
ii  libstdc++6 8.2.0-13
ii  libswscale47:3.2.12-1~deb9u1
ii  python 2.7.15-3
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages ovito recommends:
ii  ovito-doc  2.8.1+dfsg2-5

Versions of packages ovito suggests:
pn  povray  

-- no debconf information

Bug#918212: python-pbcore: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: python-pbcore
Version: 1.5.0+git20180606.43fcd9d+dfsg-2
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918213: python-skbio: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: python-skbio
Version: 0.5.5-1
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918210: python-astropy: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: python-astropy
Version: 2.0.9-1
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918214: python-xarray: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: python-xarray
Version: 0.11.0-3
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918216: sunpy: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: sunpy
Version: 0.9.5-1
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918217: theano: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: theano
Version: 1.0.2+dfsg-1
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918215: skimage: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)

[Bas Couwenberg]

Source: skimage
Version: 0.14.1-2
Severity: normal
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for your package fail with python-numpy
(1:1.16.0~rc1-3), this increased the required age of python-numpy which
blocks the gdal transition.

Please fix the autopkgtest of your package.

Kind Regards,

Bas

Bug#918190: systemd: timesyncd stopped updating clock file after package update

[Patrick Häcker]

Hello,
 
> Can you post the output of
> ls -ld /var/lib/systemd/timesync
> ls -la /var/lib/private/systemd/

root@mmm /h/pat# ls -ld /var/lib/systemd/timesync
lrwxrwxrwx 1 root root 27 Jan  3  2018 /var/lib/systemd/timesync -> ../
private/systemd/timesync/

root@mmm /h/pat# ls -la /var/lib/private/systemd/
insgesamt 12
drwxr-xr-x 3 root root 4096 Jan  3  2018 ./
drwx-- 3 root root 4096 Jan  3  2018 ../
drwxr-xr-x 2 systemd-timesync systemd-timesync 4096 Okt 19  2017 timesync/

> This will only be a problem for users of unstable/testing, not for users
> who upgrade from stretch → buster directly, as timesyncd in stretch does
> not use DynamicUser=true.
> 
> That said, we should probably add some cleanup routines to remove
> /var/lib/systemd/timesync and
> /var/lib/private/systemd/timesync
> and let the directories be recreated
> 
> Checking the other services, for which DynamicUser=true was dropped,
> like systemd-resolved, they don't appear to be affected afaics as they
> don't use StateDirectory.
This sounds all very plausible and is in line with my understanding, i.e. an 
rm is all which is needed. I just tested it and /var/lib/systemd/timesync is 
really recreated with the correct permissions after deletion when starting 
timesyncd.

Kind regards and thanks
Patrick

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

Bug#913550: shared-mime-info: Don't assume every *.key file is an Apple Keynote file

[Chris Lamb]

[Adding pkg-freedesktop-maintain...@lists.alioth.debian.org & po...@debian.org 
to CC]

> Chris Lamb wrote:
> 
> > A Tails user's OpenPGP armored public key (e.g. exported with "gpg --
> > armor --export $KEY_ID" is incorrectly recognised as "application/x-
> > iwork-keynote-sffkey":
> […]
> > Therefore I am requesting you apply this to the local Debian
> > packaging in time for buster. Many thanks in advance.
> 
> Gentle ping on this?

I'd love to get this cherry-picked into buster for Tails. I have a
few moments to prepare an upload; would it be okay for me to go
ahead with that?

(I believe, the next steps would be to ACK that and then grant me
access to the freedesktop Salsa group.)


Best wishes,

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

Bug#918218: Bug: symlinks does not work in a container with overlayFS

[Mayer, Dirk]

Package: symlinks
Version: 1.4-3+b1

Hello Debian community,
the symlinks command does not work as expected, if executed from a docker 
container containing overlay2 filesystem.
No absolute symlinks are converted to relative ones, when executing symlinks -o 
-r -c -v dir1

How to reproduce:
1) Install docker and configure usage of overlay2 filesystem storage driver in 
container (which should be the default in Debian stretch, docker info | grep 
"Storage Driver" )
2) Pull latest Debian container image
3) Execute in container:
a. $ sudo -E apt install -y symlinks
b. $ mkdir -p $HOME/dir1/dir2
c. $ touch dir1/file
d. $ ln -s $HOME/dir1/file $HOME/dir1/dir2/symlink
e. $ symlinks -o -r -c -v dir1

Expected result:
symlink converted from absolute path to relative path:
absolute: /home/bob/dir1/dir2/symlink -> /home/bob/dir1/file
changed:  /home/bob/dir1/dir2/symlink -> ../file
$ ls -alh dir1/dir2
lrwxrwxrwx 1 bob bob   19 Jan  4 09:37 symlink -> ../file

Actual result: 
no conversion, no output fom symlink command at all
$ ls -alh dir1/dir2
lrwxrwxrwx 1 bob bob   19 Jan  4 09:37 symlink -> /home/bob/dir1/file

Impact:
As more and more build environments for source packages use the container 
technology to build binaries in clean environments, it should be possible to 
use this nice and handy tool also inside of container with overlayFS.
One example here is the package tzdata, which uses the symlinks command in the 
Makefile to convert absolute symlinks in a tmp directory to relative ones for 
all the available timezones before packaging.

If I take a look in the source code of version 1.4-3, it seems that an else 
case is missing in line 289 of the function dirwalk. The else should handle the 
case if the device numbers are not identical. In my opinion this is the root 
cause of the error, because in an overlayFS these device numbers are not 
identical.

Thanks and regards,
Dirk Mayer

Bug#918103: ipv6: Consider sk_bound_dev_if when binding a socket to an address

[Ralf Jung]

Hi,

> On Thu, Jan 03, 2019 at 12:14:05PM +0100, Ralf Jung wrote:
>> Package: linux-image-4.18.0-0.bpo.3-amd64
>> Version: 4.18.20-2~bpo9+1
>> Severity: normal
>> Tags: upstream
>>
>> Dear Maintainer,
>>
>> I reported an upstream bug at 
>>  that got a patch 
>> submitted with .
>> It would be great to have this patch applied to the next Debian kernel 
>> update.
> 
> Queued it up for our next sid upload, as per
> https://salsa.debian.org/kernel-team/linux/commit/c91e16558f8fe6f1fa4df2faa27ad69afa397d03

Thanks a lot!

How are updates to the stable-backports kernel usually handled?

Kind regards,
Ralf

Bug#918103: ipv6: Consider sk_bound_dev_if when binding a socket to an address

[Salvatore Bonaccorso]

Hi Ralf,

On Fri, Jan 04, 2019 at 11:42:26AM +0100, Ralf Jung wrote:
> Hi,
> 
> > On Thu, Jan 03, 2019 at 12:14:05PM +0100, Ralf Jung wrote:
> >> Package: linux-image-4.18.0-0.bpo.3-amd64
> >> Version: 4.18.20-2~bpo9+1
> >> Severity: normal
> >> Tags: upstream
> >>
> >> Dear Maintainer,
> >>
> >> I reported an upstream bug at 
> >>  that got a patch 
> >> submitted with .
> >> It would be great to have this patch applied to the next Debian kernel 
> >> update.
> > 
> > Queued it up for our next sid upload, as per
> > https://salsa.debian.org/kernel-team/linux/commit/c91e16558f8fe6f1fa4df2faa27ad69afa397d03
> 
> Thanks a lot!
> 
> How are updates to the stable-backports kernel usually handled?

Once a version uploaded to sid, migrates to testing, it can be
prepared for stable-backports based on that.

So what will need to happen here: upload of 4.19.13-2 to unstable
(actually possibly only >= 4.19.14-1 if we do not have pressure to
upload 4.19.13-2), then wait it migrates to testing, then the
stretch-backports upload can be done.

Hope this helps,

Regards,
Salvatore

Bug#918103: ipv6: Consider sk_bound_dev_if when binding a socket to an address

[Ralf Jung]

Hi,

> Once a version uploaded to sid, migrates to testing, it can be
> prepared for stable-backports based on that.
> 
> So what will need to happen here: upload of 4.19.13-2 to unstable
> (actually possibly only >= 4.19.14-1 if we do not have pressure to
> upload 4.19.13-2), then wait it migrates to testing, then the
> stretch-backports upload can be done.
> 
> Hope this helps,

It does, thanks. :)

Kind regards,
Ralf

Bug#918218: additional information

[Mayer, Dirk]

Severity: important

Hi,
sorry forgot to mention some additional information.

Inside docker container:
$ uname -a
Linux 27046b6215ae 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) x86_64 
GNU/Linux

$ cat /etc/debian_version
9.5

Bug#911977: how do we correctly guess the VM name in autopkgtest?

[Johannes Schauer]

Control: tag -1 + moreinfo

Hi,

On Fri, 26 Oct 2018 15:23:01 -0400 Antoine Beaupre  wrote:
> One of the nice things with the schroot backend is that it automatically
> guesses which schroot to use based on internal sbuild logic. If I build a
> stretch-security update, it will find my stretch chroot, for example.
> 
> This doesn't seem to work with the autopkgtest backend:
> 
> $ sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=qemu
> [...]
> dpkg-source: info: building gnupg2 in gnupg2_2.1.18-8~deb9u3.debian.tar.bz2
> dpkg-source: info: building gnupg2 in gnupg2_2.1.18-8~deb9u3.dsc
> dpkg-source: info: using options from gnupg2-2.1.18/debian/source/options: 
> --compression=bzip2 --compression-level=9
> sbuild (Debian sbuild) 0.77.1 (10 September 2018) on curie.anarc.at
> 
> +==+
> | gnupg2 2.1.18-8~deb9u3 (amd64)   Fri, 26 Oct 2018 19:13:13 
> + |
> +==+
> 
> Package: gnupg2
> Version: 2.1.18-8~deb9u3
> Source Version: 2.1.18-8~deb9u3
> Distribution: stretch
> Machine Architecture: amd64
> Host Architecture: amd64
> Build Architecture: amd64
> Build Type: full
> 
> usage: autopkgtest-virt-qemu [-h] [-q QEMU_COMMAND] [-o OVERLAY_DIR] [-u USER]
>  [-p PASSWORD] [-c CPUS] [--ram-size RAM_SIZE]
>  [--timeout-reboot SECONDS] [--show-boot] [-d]
>  [--qemu-options QEMU_OPTIONS] [--baseimage]
>  [--efi]
>  image [image ...]
> autopkgtest-virt-qemu: error: the following arguments are required: image
> Undefined chroot status
> E: Error creating chroot session: skipping gnupg2
> 
> Now of course I can fix this by passing the image in an argument, but
> then I am hardcoding that image path which is release dependent.
> 
> Shouldn't it be better for sbuild to correctly figure that out?

Did you try using percent escapes?

For example I have in my ~/.sbuildrc:

$autopkgtest_opts = [ '--', 'schroot', '%r-%a-sbuild' ];

The %r and %a escapes expand to the current distribution and architecture. For
qemu I use:

$autopkgtest_opts = [ '--', 'qemu', '/srv/qemu/%r-%a-autopkgtest.qcow2' ];

You can read up about the percent escapes in the sbuild man page. As far as I
can see, the documentation for the --autopkgtest-opt command line argument
currently already lists that percent escapes are supported.

Do you have a different solution in mind?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#918190: systemd: timesyncd stopped updating clock file after package update

[Michael Biebl]

Am 04.01.19 um 11:48 schrieb Patrick Häcker:
> Hello,
>  
>> Can you post the output of
>> ls -ld /var/lib/systemd/timesync
>> ls -la /var/lib/private/systemd/
> 
> root@mmm /h/pat# ls -ld /var/lib/systemd/timesync
> lrwxrwxrwx 1 root root 27 Jan  3  2018 /var/lib/systemd/timesync -> ../
> private/systemd/timesync/
> 
> root@mmm /h/pat# ls -la /var/lib/private/systemd/
> insgesamt 12
> drwxr-xr-x 3 root root 4096 Jan  3  2018 ./
> drwx-- 3 root root 4096 Jan  3  2018 ../
> drwxr-xr-x 2 systemd-timesync systemd-timesync 4096 Okt 19  2017 timesync/

Hm, but this directory is writable by systemd-timesync, so
systemd-timesyncd should have no problem with updating the timestamp.

For completeness sake, can you also post the output of
stat /var/lib/systemd/timesync/clock



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#876060: vit's error messages makes its output blow up.

[Marco Solieri]

Package: vit
Version: 1.2-4
Followup-For: Bug #876060

Dear all,

The bug is rooted in the upstream version, where it has been reported [1] and
solved [since 2] from the pre-release v1.3.beta1 [3].

Best regards.

~~
1. https://github.com/scottkosty/vit/issues/153
2. 
https://github.com/scottkosty/vit/commit/27f4dfa9caf3b14279c6e7cf18920bddf051a536
3. https://github.com/scottkosty/vit/releases/tag/v1.3.beta1

--
Marco Solieri

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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)
LSM: AppArmor: enabled

Versions of packages vit depends on:
ii  libcurses-perl  1.36-1+b5
ii  perl5.28.1-3
ii  taskwarrior 2.5.1+dfsg-6

vit recommends no packages.

vit suggests no packages.

-- debconf-show failed

Bug#918190: systemd: timesyncd stopped updating clock file after package update

[Michael Biebl]

Am 04.01.19 um 12:22 schrieb Michael Biebl:

> For completeness sake, can you also post the output of
> stat /var/lib/systemd/timesync/clock

Make that
stat /var/lib/private/systemd/timesync/clock

(I missed that you already deleted /var/lib/systemd/timesync/)


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#917859: vim FTBFS building for armel,armhf on arm64

[Steve McIntyre]

On Thu, Jan 03, 2019 at 07:43:03AM -0500, James McCoy wrote:
>On Wed, Jan 02, 2019 at 06:53:29PM +, Steve McIntyre wrote:
>> 
>> amdahl is the arm64 porterbox, and I've just checked - it has armel
>> and armhf schroots configured too. That should hopefully cover what
>> you need - shout if you need anything more!
>
>Unfortunately, I wasn't able to reproduce either of the issues on
>amdahl.  I built in both armel and armhf chroots.
>
>Still looking into the screen dump issue.  In the mean time, I'll be
>pulling in a new upstream patch level soon, so I guess we can see if
>that helps at all.

OK, this is really weird. I've just built by hand locally using
debuild, and things work. But the exact same version is failing using
sbuild *on the same machine*. I'm pondering if there *might* be some
build dependency difference or something! I'm going to try again in a
totally clean chroot now.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss

Bug#909378: Re: Bug#909378: sbuild: sbuild-createchroot must not consider “lost+found” for non empty directory

[Johannes Schauer]

Hi Daniel,

On Sun, 23 Sep 2018 13:21:38 +0200 Johannes Schauer  wrote:
> Quoting Daniel Dehennin (2018-09-22 19:52:55)
> > I'm trying to setup an LVM schroot but I got the following error:
> > 
> > #+begin_src
> > /srv/chroot/sid-amd64-sbuild is not empty at /usr/bin/sbuild-createchroot 
> > line 279,  line 13.
> > #+end_src
> > 
> > The problem is that sbuild-createchroot check for 3 directory entries 
> > without
> > taking “lost+found” as an exception.
> 
> the reason why sbuild requires an empty target directory, are debootstrap bugs
> like these that make you loose everything in case a wrong code path is taken:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833525
> 
> Now imagine that you actually had some previously recovered files in
> lost+found. If you are unlucky, those would then be deleted by a faulty
> debootstrap.
> 
> Why don't you just rmdir the directory? Then you also made sure that there is
> indeed nothing inside that you still need. fsck will re-create it in case it
> needs it.

as I thought more about this problem I now found a better solution that makes
both of us happy. Consider this diff:

-opendir(my $dh, $target) or die "Can't opendir($target): $!\n";
-# Attempt reading the directory thrice. If the third time succeeds, then it
-# has more entries than just "." and ".." and must thus not be empty.
-readdir $dh;
-readdir $dh;
-die "$target is not empty" if (readdir $dh);
+# check if the directory is empty or contains nothing more than an
+# empty lost+found directory. The latter exists on freshly created
+# ext3 and ext4 partitions.
+# rationale for requiring an empty directory: 
https://bugs.debian.org/833525
+opendir(my $dh, $target) or die "Can't opendir($target): $!";
+while (my $entry = readdir $dh) {
+   # skip the "." and ".." entries
+   next if $entry eq ".";
+   next if $entry eq "..";
+   # if the entry is a directory named "lost+found" then skip it
+   # if it's empty
+   if ($entry eq "lost+found" and -d "$target/$entry") {
+   opendir(my $dh2, "$target/$entry");
+   # Attempt reading the directory thrice. If the third time
+   # succeeds, then it has more entries than just "." and ".."
+   # and must thus not be empty.
+   readdir $dh2;
+   readdir $dh2;
+   # rationale for requiring an empty directory:
+   # https://bugs.debian.org/833525
+   if (readdir $dh2) {
+   die "$target contains a non-empty lost+found directory";
+   }
+   closedir($dh2);
+   } else {
+   die "$target is not empty";
+   }
+}
+closedir($dh);

The new version now check if either the target directory is empty, or it has
only an empty lost+found directory in it. It will abort in any other case. This
means that:

 - we still get all the safety and make sure nothing of value will accidentally
   get deleted

 - you don't need to manually rmdir a fresh lost+found directory on a new
   partition

What do you think?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#918219: nagios3-cgi: postinst script fails if supplied apache config has been deleted previously

[Alex Sheppard]

Package: nagios3-cgi
Version: 3.5.1.dfsg-2+deb8u1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

  Simply updating the system


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

  apt-get update && apt-get upgrade


   * What was the outcome of this action?

This packages  and the depending nagios3 package were left unconfigured / 
incompletely installed


   * What outcome did you expect instead?

The packages to install cleanly




   * More Detail

We use our own custom apache vhost to server nagios and so deleted the packaged 
/etc/nagios3/apache2.conf

The postinst script calls  'ucf --debconf-ok 
/usr/share/nagios3-cgi/apache2.conf /etc/nagios3/apache2.conf' which responds 
with
"Not replacing deleted config file /etc/nagios3/apache2.conf"

Then a few lines later 'apache2_invoke enconf nagios3' fails and results in an 
exit code of '1' from the postinst script.

I think this ought to be a warning, rather than an error.




*** End of the template - remove these template lines ***


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

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

Versions of packages nagios3-cgi depends on:
ii  adduser3.113+nmu3
ii  apache2-utils  2.4.10-10+deb8u12
ii  coreutils  8.23-4
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  libapache2-mod-php55.6.39+dfsg-0+deb8u1
ii  libc6  2.19-18+deb8u10
ii  libgd3 2.1.0-5+deb8u11
ii  libjpeg62-turbo1:1.3.1-12
ii  libjs-jquery   1.7.2+dfsg-3.2
ii  libpng12-0 1.2.50-2+deb8u3
ii  nagios3-common 3.5.1.dfsg-2+deb8u1
ii  ucf3.0030
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages nagios3-cgi recommends:
ii  apache2 [httpd]  2.4.10-10+deb8u12
pn  nagios-images

nagios3-cgi suggests no packages.

-- Configuration Files:
/etc/nagios3/cgi.cfg changed [not included]

-- debconf information:
  nagios3/httpd: apache2
  nagios3/adminpassword-mismatch:
  nagios3/nagios1-in-apacheconf: false

Bug#918220: securefs: Typo in debian/watch file

[Boyuan Yang]

Source: securefs
Version: 0.8.2+ds-3
Severity: minor

Dear securefs maintainer,

uscan reports error due to unrecognized option "repackasuffix=+ds". It is
obviously a typo.

Please consider fixing it in the next upload. Thanks!

--
Regards,
Boyuan Yang


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

Bug#911979: fails on chown in autopkgtest-qemu backend

[Johannes Schauer]

Hi,

On Fri, 26 Oct 2018 15:33:32 -0400 Antoine Beaupre  wrote:
> I have tried to use the autopkgtest backend with the qemu server but it
> completely failed to launch the build:
>
> [...]
>
> chown: invalid user: 'sbuild:sbuild'
> E: Failed to set sbuild:sbuild ownership on /build
> Failed to set up chroot
>
> [...]
>
> I can test that package with autopkgtest fine, for what that's worth, with:
>
> autopkgtest . -- qemu
>
> So this seems to be a problem specific to sbuild.

could you try adding the sbuild user and group to your qemu guest?

sbuild-createchroot is doing some customizations after running debootstrap. One
of them is to copy the sbuild user and group from the host into the chroot so
that the user and group work with schoor. Obviously this is not necessary when
using qemu so maybe sbuild should add a new sbuild user and group itself when
it doesn't find them in the chroot already.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#918221: ftp.debian.org: Please add aceept-with-bug to DAK process-new

[Lisandro Damián Nicanor Pérez Meyer]

Package: ftp.debian.org
Severity: wishlist

Hi! I was just discussing a REJECT with a FTP team member and he told me that 
currently
DAK-process-new does not has the option to ACCEPT a package and file a bug 
against it.

There are certain cases in which accepting a package with a bug makes sense, 
and this
feature would make it easier for team members to do it.

Thanks, Lisandro.

Bug#845223: 0ad: Crashes on startup with cache.cpp(43): Assertion failed: "cache.Validate()"

[Ludovic Rousseau]

Hello Cacatoes,

I just uploaded 0ad version 0.0.23.1 to unstable.
Can you check your problem is still present in this version?

if the problem is still present I suggest you to add a comment on your 
upstream bug http://trac.wildfiregames.com/ticket/4360 to let them know 
the problem is not yet fixed.


Bye


Le 01/12/2016 à 16:58, cacat...@tuxfamily.org a écrit :

Posted there (a week ago):
http://trac.wildfiregames.com/ticket/4360

Waiting for their feedback.

Le lundi 21 novembre 2016 à 10:34:14, Vincent Cheng a écrit :

Control: tag -1 + moreinfo unreproducible

Hi,

On Mon, Nov 21, 2016 at 8:35 AM,   wrote:

Package: 0ad
Version: 0.0.21-2

Hiya,

I just installed 0ad on my system.
It crashes as soon as I start the game.
See attachment for crash log. If I say "go on", it manages to play the
music.

note: I thought there was a -dbg package, but not in my repos.

0ad has now migrated to using auto-generated dbgsym packages (like
many other packages in Debian sid). You'll have to add an additional
line to your sources.list to pick up the dbgsym repository [1].

Please file a bug report upstream after obtaining a backtrace at [2].

Regards,
Vincent

[1] https://lists.debian.org/debian-devel/2015/12/msg00262.html
[2] http://trac.wildfiregames.com/newticket



--
Dr. Ludovic Rousseau

Bug#916889: [Pkg-privacy-maintainers] Bug#916889: onionshare: recommends torbrowser-launcher in contrib

[Ulrike Uhlig]

Hi John!

thank you for this report.

John Scott:
> Package: onionshare
> Severity: minor
> 
> The Policy Manual suggests that OnionShare shouldn't depend or
> recommend torbrowser-launcher unless as an alternative to tor
> because it's in main (assuming OnionShare 1.3+ works with that).

Onionshare 1.3 now comes with a bundled tor, that is the default option
for connecting to Tor.

So indeed, we can and should drop the recommends.

However, using TBB as onionshare's tor is an option using the GUI, so I
believe we could have it as a "suggests".

And tor itself should possibly be moved to "Recommends", if I follow my
own reasoning here. Because not necessarily needed by Onionshare to work.

What do you think?

Cheers,
Ulrike

Bug#918222: calamares-settings-debian: Typo in package description

[Thomas Vincent]

Package: calamares-settings-debian
Severity: minor

Dear Maintainer,

I noticed a typo in the calamares-settings-debian package description. Indeed, 
"genereic" should be spelled "generic".

Thanks a lot for your work on calamares-setting-debian!
Thomas


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

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

Bug#913003: already fixed

[Pirate Praveen]

Control: fixed -1 2.0.6-1

Really add fixed version.




signature.asc
Description: OpenPGP digital signature

Bug#918138: qtox: Add AppArmor profile

[Yangfl]

Vincas Dargis  于2019年1月4日周五 上午2:36写道：
>
> Dear Maintainer,
>
> I'm happy to see that we now have qTox in Debian! Thanks to Maintainer!
>
> It would be even cooler to have it confined with AppArmor. qTox
> maintains connections to various untrusted peers over the world, and so
> it is important do reduce attack vector in case of RCE happens, brought
> by some untrusted packet, etc.
>
> We have some GUI packages on Debian that ship with AppArmor profile
> (like Thunderbird, or LibreOffice, Totem, etc), and I agree that
> experience with them might not be the best yet, as AppArmor really lacks
> some features to make GUI applications "better confinable" without
> making user struggle with denies... So due to that I will *suggest to
> ship this profile disabled by default*, so power users should enable it
> consciously with knowing the risks of having some inconveniences.
>
> I am interested to prepare AppArmor porfile for qTox by myself, as I use
> this application daily. The idea is to maintain profile, same as with
> Thunderbird, in external apparmor-profiles [0] repository, and sync it
> to Debian package once it is accepted in apparmor-profiles, after it's
> reviewed by AppArmor maintainers and/or contributors.
>
> [0] https://gitlab.com/apparmor/apparmor-profiles
>

Hi,

I'd love to see any improvement in program quality. As you're willing
to create the AppArmor profile, I'd like to suggest you to directly
submit your changes to upstream; just open a pr in their github repo
https://github.com/qTox/qTox .

Directly shipping AppArmor profile within application package is
possible; see the example from another package
https://salsa.debian.org/yangfl-guest/i2pd/blob/master/debian/i2pd.install
. Once the upstream provides a (usable) AppArmor profile, I would be
very happy to include that in the next release.

Bug#918223: ioctl[SIOCSIWENCODEEXT]: Invalid argument

[積丹尼 Dan Jacobson]

Package: wpasupplicant
Version: 2:2.7-2
Severity: minor

wpa_supplicant connects fine, however I always get these two warnings,
with various hardware, always the same.
# wpa_supplicant -D wext,nl80211 -dd -i $i -c $co -B

wpa_driver_wext_set_key: alg=0 key_idx=4 set_tx=0 seq_len=0 key_len=0
ioctl[SIOCSIWENCODEEXT]: Invalid argument
Driver did not support SIOCSIWENCODEEXT
wpa_driver_wext_set_key: alg=0 key_idx=5 set_tx=0 seq_len=0 key_len=0
ioctl[SIOCSIWENCODEEXT]: Invalid argument
Driver did not support SIOCSIWENCODEEXT
wpa_driver_wext_set_countermeasures

Just thought you would like to know.

Bug#873341: SBT is uninstallable; depends on nonexistent packages

[Antonio Ospite]

On Thu, 3 Jan 2019 13:03:42 +0100
Antonio Ospite  wrote:

> On Thu, 3 Jan 2019 11:45:29 +0100
> Emmanuel Bourg  wrote:
> 
[...]
> > If someone wants to pick the ball the next steps are to:
> > 1. build SBT 1.0 without the embedded libraries
> > 2. build Scala 2.12
> >
> 
> I was wondering if downgrading scala to 2.10 might be somewhat useful
> and less work. Fedora is also still shipping scala 2.10.
> 

I tried installing scala 2.10.5 from debian snapshot:
https://snapshot.debian.org/archive/debian/20150606T044147Z/pool/main/s/scala/

However the sbt from debian was built with scala 2.11 and it will
still look for that version at runtime.

So if sbt should also be re-compiled to make the combination
scala_2.10+sbt_0.13 work it might as well be worth using newer versions
as Emmanuel suggested.

I think I'll stop my investigations for now.

Thank you,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#917174: davmail: FTBFS with libjackrabbit-java 2.18.0

[Alexandre Rossi]

> > unfortunately davmail fails to build from source with
> > libjackrabbit-java 2.18.0. Long deprecated methods have been removed.
> > Your package build-depends on a very old version of jackrabbit (2.4.3).

This is too much work and I'm afraid if I do not get help I'll miss
the 2019-02-12 - Soft-freeze deadline for davmail to be part of the
Debian buster release. I'll continue working on this anyhow. My work
will be regularly published at
https://salsa.debian.org/debian/davmail/tree/httpclient4-api

For davmail in buster, the options are :
1) let davmail being removed from buster (because it does not work
with the newer libjackrabbit, because low popcon, because a backport
can be made available later)
2) upload a libjackrabbit-old-java compatible with davmail and build
against this (I can prepare this).
3) holding libjackrabbit-java 2.18 from reaching buster because it
breaks its only rdep.
4) fixing the 1300+ compile errors before the soft freeze and ensure
few regressions (unlikely I can do this by February as I'm learning
libhttpclient-java and the davmail codebase at the same time)

Please advice,

Alex

Bug#918224: ITP: ruby-mini-mime: A lightweight mime type implementation

[Lucas Kanashiro]

Package: wnpp
Owner: Lucas Kanashiro 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : ruby-mini-mime
  Version : 1.0.1
  Upstream Author : Discourse Construction Kit, Inc.
* URL : https://github.com/discourse/mini_mime
* License : Expat
  Programming Lang: Ruby
  Description : A lightweight mime type implementation

Minimal mime type implementation for use with the mail and rest-client gem.
MiniMime is optimised to minimize memory usage. It keeps a cache of 100 mime
type lookups (and 100 misses).

This package will be maintained under the umbrella of the Debian Ruby team.

-- 
Lucas Kanashiro

Bug#864082: Next steps for a reproducible Fontconfig?

[Chris Lamb]

[Adding 864...@bugs.debian.org to CC]

Dear fontconfig maintainers,

I've just spent a coffee-or-two unpicking this to get the latest status
and to load the history back into my brain.

As a bit of background, I'm working on the Reproducible Builds
effort and fontconfig — in its usual usage, or at least in Debian
at the time — generated unreproducible cache files.

This was due to it using the timestamps of each directory in the
`checksum` member of the `_FcCache` struct. This is so that it can
identify which cache files remain valid and/or require regeneration
(or similar logic).

So therefore in June 2017 I sent an initial patch:

  https://lists.freedesktop.org/archives/fontconfig/2017-June/005948.html

… which, after some (private?) discussion regarding the implementation, 
resulted in:

  https://lists.freedesktop.org/archives/fontconfig/2018-May/006285.html

… and that was merged after some further round-trips in f098adac54:

   https://lists.freedesktop.org/archives/fontconfig/2018-May/006289.html

… which was released as part of:

   $ git tag --contains f098adac54 | head -n1
   2.13.1

So far, so good. However, Johannes Schauer then reported that
fontconfig "still" installs unreproduciby:

  https://bugs.debian.org/864082#101

… so I prepared a new patch:

  https://lists.freedesktop.org/archives/fontconfig/2018-October/006374.html

… and that was "soft NACK'd" in the sense that Keith mentions:

> I've dug into this a bit more and I think an architectural change in the
> cache files made last year is probably not what we want.

   — 
https://lists.freedesktop.org/archives/fontconfig/2018-October/006376.html

(I am now inferring that it was this "architectural change"
resulted in the regression Johannes reported, rather than the bug
being incomplete from the beginning.)

Anyway, the upshot from my proposal was that some larger/different
changes are/were "requested" instead.

Behdad Esfahbod also chimed in with:

> I don't like the new mechanism either, but I think it was added to resolve
> bind-mounted font dirs

   — 
https://lists.freedesktop.org/archives/fontconfig/2018-October/006381.html

… in the context of Flatpak apps. Keith then addressed all this
with a branch which he published here:

  https://gitlab.freedesktop.org/keithp/fontconfig

… the most salient commit being (I think?):

  
https://gitlab.freedesktop.org/keithp/fontconfig/commit/a04751b2e624d034becec7588159ef2f9a8dfc1b

Since then, I don't believe there has been any review of this
branch both in the sense of the code itself but also in terms of
the architectural changes that it implies. I might be able to help
on the former front but without knowing the "lore" of Fontconfig I
simply cannot comment on the latter parts.

Anyway, I'd love to get this resolved once and for all ideally get
it into Debian buster which is about to start "freezing" very
soon.

What would be the best way for me to help here? Can I entreat Keith
to merge his branch? I can put some cycles onto this issue if that is
of some assistance.


Best wishes,

-- 
Chris Lamb
chris-lamb.co.uk / @lolamby

Bug#917687: [3dprinter-general] Bug#917687: cura-engine: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: undefined reference to `pth

[Gregor Riepl]

> Looks OK to me.

Ok... So it turns out I made a stupid versioning mistake when preparing a
fixed version of libpolyclipping.
After fixing that and reinstalling the correct pkg-config file, I can build
cura-engine again.

I'll ask Petter to upload libpolyclipping-6.4.2-6 ASAP.

Bug#918225: pasystray: prefer GtkStatusIcon over Appindicator

[Valentin Blot]

Package: pasystray
Version: 0.7.0-1
Severity: normal
Tags: patch

Current implementation of AppIndicator does not handle click events or
modifiers. A middle click on the icon of pasystray is supposed to
toggle mute, but this is not possible with the AppIndicator
implementation. I filed a bug to AppIndicator but in the meantime it
would be better to fallback to the GtkStatusIcon implementation, which
is done with the attached patch.
--- a/debian/rules	2018-10-29 13:29:50.0 +0100
+++ b/debian/rules	2019-01-04 13:22:58.932093829 +0100
@@ -2,5 +2,8 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+override_dh_auto_configure:
+	dh_auto_configure -- --disable-appindicator
+
 %:
 	dh $@ --with autoreconf

Bug#918223: ioctl[SIOCSIWENCODEEXT]: Invalid argument

[Andrej Shadura]

On Fri, 4 Jan 2019 at 13:12, 積丹尼 Dan Jacobson  wrote:
>
> Package: wpasupplicant
> Version: 2:2.7-2
> Severity: minor
>
> wpa_supplicant connects fine, however I always get these two warnings,
> with various hardware, always the same.
> # wpa_supplicant -D wext,nl80211 -dd -i $i -c $co -B
>
> wpa_driver_wext_set_key: alg=0 key_idx=4 set_tx=0 seq_len=0 key_len=0
> ioctl[SIOCSIWENCODEEXT]: Invalid argument
> Driver did not support SIOCSIWENCODEEXT
> wpa_driver_wext_set_key: alg=0 key_idx=5 set_tx=0 seq_len=0 key_len=0
> ioctl[SIOCSIWENCODEEXT]: Invalid argument
> Driver did not support SIOCSIWENCODEEXT
> wpa_driver_wext_set_countermeasures
>
> Just thought you would like to know.

Thanks! I think this needs to be reported to the driver maintainers.

-- 
Cheers,
  Andrej

Bug#917850: Fwd: Server Error (500) on nm.d.o

[eamanu15]

Hi,

El lun., 31 de dic. de 2018 a la(s) 05:02, Jonathan McDowell (
nood...@earth.li) escribió:

> On Sun, Dec 30, 2018 at 11:29:33PM -0300, eamanu15 wrote:
> > I joined to NM and in my personal web I have on *pending *the next line:
> > "This is a new entry that requires confirmation before Jan. 2, 2019.
> Click
> > here to send the email challenge again."
> >
> > I don't receive the email. And when I click on "here" link this give me a
> > Server Error (500).
> >
> > What would be the problem?
>
> Your GPG key has expired, so the system can't encrypt the challenge to
> you. You need to update your key (and we need to fix the system so it
> prints a proper error message in that case).
>

I am trying to update my keyring using: *gpg --keyserver keyring.debian.org
 --send-keys ...*
But I don't see the change. On Debian wiki say that this could take some
time, because
the keyring push is monthly. Do you know approx when it occur? Or, there
are other way to update
the key?

Thanks!
Emmanuel

>
> J.
>
> --
> Web [  Just 'cause I remembered one thing doesn't make me smart!   ]
> site: https:// [  ]  Made by
> www.earth.li/~noodles/  [  ] HuggieTag 0.0.24
>


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#845223: 0ad: Crashes on startup with cache.cpp(43): Assertion failed: "cache.Validate()"

[cacatoes]

Hi Ludovic,

This problem doesn't occur after a few tests (I think it has been fixed
ages ago already). I posted back on their Trac.

During my tests I experienced another similar issue but not the same
error message. I believe it's a separate issue so I'll create another
one if I can pinpoint it a bit more.

This debian bug can also be closed, thanks!

Le vendredi 04 janvier 2019 à 12:45:37, Ludovic Rousseau a écrit :
> Hello Cacatoes,
> 
> I just uploaded 0ad version 0.0.23.1 to unstable.
> Can you check your problem is still present in this version?
> 
> if the problem is still present I suggest you to add a comment on your
> upstream bug http://trac.wildfiregames.com/ticket/4360 to let them know the
> problem is not yet fixed.
> 
> Bye
> 
> 
> Dr. Ludovic Rousseau
> 

Bug#918026: ruby-sinatra-contrib: uninstallable; depends on versions not present in the archive

[Antonio Terceiro]

On Wed, Jan 02, 2019 at 10:58:15AM -0300, Antonio Terceiro wrote:
> Package: ruby-sinatra-contrib
> Version: 2.0.5-1
> Severity: serious
> Justification: unsatisfiable dependencies
> 
> # apt install ruby-sinatra-contrib
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  ruby-sinatra-contrib : Depends: ruby but it is not going to be installed
> Depends: ruby-mustermann (>= 1.0~) but it is not 
> going to be installed
> Depends: ruby-sinatra (>= 2.0.5~) but it is not going 
> to be installed
> Depends: ruby-backports (>= 2.8.2) but it is not 
> going to be installed
> Depends: ruby-tilt (>= 1.3~) but it is not going to 
> be installed
> Depends: ruby-rack-protection (>= 2.0.5~) but it is 
> not going to be installed
> Depends: ruby-multi-json but it is not going to be 
> installed
> E: Unable to correct problems, you have held broken packages.

I just noticed that sinatra-contrib was moved into the sinatra
repository upstream.

Are you working on updating sinatra? I started working on a new sinatra
upstream release to unbreak debci after a new rack was uploaded, and
could build binaries for ruby-sinatra-contrib (and ruby-rack-protection,
which was also moved into sinatra) from the ruby-sinatra source in one
go.


signature.asc
Description: PGP signature

Bug#918080: breeze-gtk: symlink /usr/share/themes/Breeze/{gtk-3.20,gtk-3.0}/

[Maximiliano Curia]

¡Hola Simon!

El 2019-01-02 a las 21:25 -0600, Simon Quigley escribió:

Package: breeze-gtk
Severity: normal
Version: 5.14.3-1



It was raised to my attention from LXQt users that the Breeze GTK theme
cannot be used under LXQt as packaged. This is because the theme exists
in /usr/share/themes/Breeze/gtk-3.18/ and
/usr/share/themes/Breeze/gtk-3.20/ but doesn't exist in
/usr/share/themes/Breeze/gtk-3.0/ which is inconsistent to other GTK
themes in the archive. For example, the arc-theme package just installs
in gtk-3.0.



This raises a few questions for me. Is this just a hidden use of the
standard, or something Plasma-specific? Are the themes meant to only be
used on those minor versions of GTK?



Simply symlinking gtk-3.20 to gtk-3.0 solves the problem under LXQt. Is
it rational to ship this as default?


The theme was adapted to gtk 3.20 (which includes some incompatible changes 
with themes designed for previous gtk versions) and the adapted version is 
shipped in the gtk-3.20 folder, sadly the older version was moved to the 
gtk-3.18 folder. The folder name implies $GTK_VERSION >= 3.20, 
thus it would be wrong to rename it to gtk-3.0 . The gtk-3.18 folder, on the 
other hand, could be renamed, but we don't have a gtk-3 versions older than 
3.18, or even older than 3.20, so that's not really necessary.


I would suspect that lxqt is filtering the themes that that have a gtk-3.0 
folder in them, while a filter for themes that have a gtk-3.* folder would 
yield better results.


Happy hacking,
--
"Politicians and diapers have one thing in common. They should both be changed 
regularly, and for the same reason."

-- José Maria de Eça de Queiroz
Saludos /\/\ /\ >< `/



signature.asc
Description: PGP signature

Bug#917174: davmail: FTBFS with libjackrabbit-java 2.18.0

[Markus Koschany]

Hello Alex,

Am 04.01.19 um 13:16 schrieb Alexandre Rossi:
>>> unfortunately davmail fails to build from source with
>>> libjackrabbit-java 2.18.0. Long deprecated methods have been removed.
>>> Your package build-depends on a very old version of jackrabbit (2.4.3).
> 
> This is too much work and I'm afraid if I do not get help I'll miss
> the 2019-02-12 - Soft-freeze deadline for davmail to be part of the
> Debian buster release. I'll continue working on this anyhow. My work
> will be regularly published at
> https://salsa.debian.org/debian/davmail/tree/httpclient4-api
> 
> For davmail in buster, the options are :
> 1) let davmail being removed from buster (because it does not work
> with the newer libjackrabbit, because low popcon, because a backport
> can be made available later)
> 2) upload a libjackrabbit-old-java compatible with davmail and build
> against this (I can prepare this).
> 3) holding libjackrabbit-java 2.18 from reaching buster because it
> breaks its only rdep.
> 4) fixing the 1300+ compile errors before the soft freeze and ensure
> few regressions (unlikely I can do this by February as I'm learning
> libhttpclient-java and the davmail codebase at the same time)

Admittedly the upload happened on short notice and it was not my
intention to force you into porting davmail to a newer version of
jackrabbit-webdav. I think we can just prevent libjackrabbit-java 2.18
from moving to Buster which should solve this issue in the near-term.
However then we don't ship the current stable version of jackrabbit but
only an oldstable one that is maintained (at the moment) but will be EOL
during the Buster release cycle which is not so great either in my opinion.

I think the general problem is that upstream depends on an obsolete
version of jackrabbit-webdav, version 2.4.3, that has known security
vulnerabilities [1], CVE-2016-6801 and CVE-2015-1833. I only took care
of jackrabbit to make backports of security patches easier for all of
us. Ideally you should take care of jackrabbit too and maintain both
packages under the Java team umbrella. In any case I recommend to not
ship davmail in Bullseye if it can't be upgraded to supported versions
of jackrabbit and httpclient in the future.

Regards,

Markus

[1] https://security-tracker.debian.org/tracker/source-package/jackrabbit




signature.asc
Description: OpenPGP digital signature

Bug#918226: gcc-snapshot.prerm yields error messages - incorrect paths?

[Vincent Lefevre]

Package: gcc-snapshot
Version: 1:20190102-1
Severity: normal

I can see the following error messages on upgrade or removal:

find: ‘/usr/lib/gcc-snapshot/share/python’: No such file or directory
find: ‘/usr/lib/gcc-snapshot/share/python’: No such file or directory

They come from /var/lib/dpkg/info/gcc-snapshot.prerm, which contains:

find /usr/lib/gcc-snapshot/share/python -name '*.py[co]' | xargs -r rm -f
find /usr/lib/gcc-snapshot/share/python -name __pycache__ -type d | xargs -r rm 
-rf

However, the python directory in the package contents is:

  /usr/lib/gcc-snapshot/share/gcc-9/python

This appears to be an inconsistency.

-- 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)
Foreign Architectures: i386

Kernel: Linux 4.18.0-3-amd64 (SMP w/12 CPU cores)
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 gcc-snapshot depends on:
ii  binutils2.31.1-11
ii  libc6   2.28-4
ii  libc6-dev   2.28-4
ii  libc6-dev-i386  2.28-4
ii  libc6-dev-x32   2.28-4
ii  libc6-i386  2.28-4
ii  libc6-x32   2.28-4
ii  libgc1c21:7.6.4-0.4
ii  libgmp102:6.1.2+dfsg-4
ii  libisl190.20-2
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.1-2
ii  python3 3.7.1-3
ii  zlib1g  1:1.2.11.dfsg-1

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.31.1-11

-- no debconf information

Bug#916839: imagemagick: Silent ABI break in 6.9.10-11 on i386

[Balint Reczey]

Hi,

On Thu, Dec 20, 2018 at 6:46 AM Bastien ROUCARIES
 wrote:
>
> On Wed, Dec 19, 2018 at 12:09 PM Balint Reczey
>  wrote:
> >
> > Package: imagemagick
> > Version: 8:6.9.10.14+dfsg-1
> > Severity: grave
> > Control: forwareded -1 https://github.com/ImageMagick/ImageMagick6/issues/31
> > Control: tags -1 upstream fixed-upstream
> > Control: affects -1 ruby-rmagick
> >
> > Hi,
> >
> > The ABI broke in 6.9.10-11 due to changing MagickDoubleType to double
> > from long double.
> > This breaks ruby-rmagick and possibly other reverse dependencies, thus
> > after fixing imagemagick please check if some reverse dependencies
> > need to be rebuilt. The fix will be available in the .18 upstream
> > release.
>
> Exact, this will need a so bump I suppose...

Since the ABI broke only in unstable and testing and only affected
i386 and possibly a few rare arches not in Ubuntu I'd say a few
rebuilds would suffice. Upstream did not do a major ABI bump either
and released the fix.

Cheers,
Balint

>
> Bastien
>
>
>
> >
> > Cheers,
> > Balint
> >
> > --
> > Balint Reczey
> > Ubuntu & Debian Developer
> >



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#917859: vim FTBFS building for armel,armhf on arm64

[Steve McIntyre]

On Fri, Jan 04, 2019 at 11:34:04AM +, Steve McIntyre wrote:
>On Thu, Jan 03, 2019 at 07:43:03AM -0500, James McCoy wrote:
>>On Wed, Jan 02, 2019 at 06:53:29PM +, Steve McIntyre wrote:
>>> 
>>> amdahl is the arm64 porterbox, and I've just checked - it has armel
>>> and armhf schroots configured too. That should hopefully cover what
>>> you need - shout if you need anything more!
>>
>>Unfortunately, I wasn't able to reproduce either of the issues on
>>amdahl.  I built in both armel and armhf chroots.
>>
>>Still looking into the screen dump issue.  In the mean time, I'll be
>>pulling in a new upstream patch level soon, so I guess we can see if
>>that helps at all.
>
>OK, this is really weird. I've just built by hand locally using
>debuild, and things work. But the exact same version is failing using
>sbuild *on the same machine*. I'm pondering if there *might* be some
>build dependency difference or something! I'm going to try again in a
>totally clean chroot now.

And that builds just fine. I'm confused now, there must be something
causing this build failure but I can't see exactly what. :-(

Apologies for taking your time here, and thanks for being so
responsive already! I'll keep looking into this and see if I can find
any more clues.

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

Bug#918227: xtables-addons-common: GeoIPCountryCSV.zip ERROR 404: Not Found

[Tito Ragusa]

Package: xtables-addons-common
Version: 2.12-0.1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 Running periodically a script that calls 
/usr/lib/xtables-addons/xt_geoip_dl
 to update GeoIPv6.csv.gz and GeoIPCountryCSV.zip
   * What exactly did you do (or not do) that was effective (or
 ineffective)
 Call  /usr/lib/xtables-addons/xt_geoip_dl
   * What was the outcome of this action?
 --2019-01-04 14:26:53--  
http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
 Reusing existing connection to geolite.maxmind.com:80.
 HTTP request sent, awaiting response... 404 Not Found
   * What outcome did you expect instead?
 Download GeoIPCountryCSV.zip, but starting January 2, 2019 it was removed
 from the website and a switch to GeoLite2 format databases is needed
 which could be downloaded at 
https://geolite.maxmind.com/download/geoip/database/GeoLite2-Country-CSV.zip.
 Sadly it seems to me that the xtables packages in the stable repositories
 are unable to handle the GeoLite2 format databases. 
 

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

Kernel: Linux 4.9.0-8-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 /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xtables-addons-common depends on:
ii  libc6 2.24-11+deb9u3
ii  libxtables12  1.6.0+snapshot20161117-6

Versions of packages xtables-addons-common recommends:
ii  unzip6.0-21
ii  wget 1.18-5+deb9u2
ii  xtables-addons-dkms  2.12-0.1

Versions of packages xtables-addons-common suggests:
ii  libtext-csv-xs-perl  1.26-1

-- no debconf information

Bug#918026: ruby-sinatra-contrib: uninstallable; depends on versions not present in the archive

[Antonio Terceiro]

On Fri, Jan 04, 2019 at 10:22:08AM -0300, Antonio Terceiro wrote:
> On Wed, Jan 02, 2019 at 10:58:15AM -0300, Antonio Terceiro wrote:
> > Package: ruby-sinatra-contrib
> > Version: 2.0.5-1
> > Severity: serious
> > Justification: unsatisfiable dependencies
> > 
> > # apt install ruby-sinatra-contrib
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> > 
> > The following packages have unmet dependencies:
> >  ruby-sinatra-contrib : Depends: ruby but it is not going to be installed
> > Depends: ruby-mustermann (>= 1.0~) but it is not 
> > going to be installed
> > Depends: ruby-sinatra (>= 2.0.5~) but it is not 
> > going to be installed
> > Depends: ruby-backports (>= 2.8.2) but it is not 
> > going to be installed
> > Depends: ruby-tilt (>= 1.3~) but it is not going to 
> > be installed
> > Depends: ruby-rack-protection (>= 2.0.5~) but it is 
> > not going to be installed
> > Depends: ruby-multi-json but it is not going to be 
> > installed
> > E: Unable to correct problems, you have held broken packages.
> 
> I just noticed that sinatra-contrib was moved into the sinatra
> repository upstream.
> 
> Are you working on updating sinatra? I started working on a new sinatra
> upstream release to unbreak debci after a new rack was uploaded, and
> could build binaries for ruby-sinatra-contrib (and ruby-rack-protection,
> which was also moved into sinatra) from the ruby-sinatra source in one
> go.

FWIW I just pushed a more or less working source package to git in the
expected place (ruby-team/gemwatch), building binaries for
ruby-sinatra-contrib and ruby-rack-protection.

the main TODO is making the automated tests run properly during the
build. I installed the binaries locally and did the following tests:

- the debci tests now pass again
- gemwatch seems to work fine.
- also tested a couple of simple apps I have around, and they seem to
  work as well.


signature.asc
Description: PGP signature

Bug#918228: thunderbird: GNOME keyring integration causes malfunction of fetching messages from server

[Gottfried Bruckmann]

Package: thunderbird
Version: 1:60.4.0-1~deb9u1
Severity: normal

Dear Maintainer,

   * After having installed Debian 9 and thunderbird on a "virgin" system and
taking over the old user profile, I was unable to fetch mails from the server
on the accounts both from me and my wife. Also, the processor usage was quite
high.
   * After starting thunderbird from the command line via "thunderbird --safe-
mode", I could fetch mails.
   * Re-activating the add-ins one by one showed that GNOME keyring integration
was the "bad guy".
I don't have enigmail or something similar installed yet.
   * I would have expected that thunderbird is capable of fetching e-mails also
with this add on activated.

Thanks!



-- System Information:
Debian Release: 9.6
  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 thunderbird depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-11+deb9u3
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libgtk2.0-0   2.24.31-2
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-18+deb9u1
ii  libvpx4   1.6.1-3+deb9u1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libx11-xcb1   2:1.6.4-3+deb9u1
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b2
ii  x11-utils 7.7+3+b1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages thunderbird recommends:
ii  hunspell-de-at [hunspell-dictionary]  20161207-1
ii  hunspell-de-ch [hunspell-dictionary]  20161207-1
ii  hunspell-de-de [hunspell-dictionary]  20161207-1
ii  hunspell-en-us [hunspell-dictionary]  20070829-7
ii  lightning 1:60.4.0-1~deb9u1

Versions of packages thunderbird suggests:
ii  apparmor  2.11.0-3+deb9u2
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.15-1+deb9u1

-- no debconf information

Bug#902821: qa.debian.org: Asian (JP, CH) input impossible, when locale is not Asian (LANG=en_US, etc)

[Lucas Nussbaum]

reassign 902821 installation-reports
thanks

Hi,

Reassigning to installation-reports.

Lucas

Bug#887681: python-tornado: FTBFS on hurd-i386: multiple test suite failures

[Aaron M. Ucko]

Julien Puydt  writes:

> sorry it took so long to answer.

Likewise. :-)

> (2) is python-twisted test suite run during the build stage? If it
> isn't, the build might be happy while in fact everything is broken.

Yeah, that appears to be the issue; a closer look at
https://buildd.debian.org/status/fetch.php?pkg=twisted&arch=hurd-i386&ver=18.9.0-3&stamp=1544181757&raw=0
shows no indication of build-time testing.  (The package supplies
*runtime* autotests, but those don't catch platform-specific breakage.)

Please feel free to reassign this bug accordingly, though you might
still want to mark it as affecting python-tornado.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#904083: Regression run_lintian calls lintian with a non existing filename

[Johannes Schauer]

Control: tag -1 + moreinfo
Control: severity -1 normal

Hi,

On Thu, 19 Jul 2018 13:08:02 +0200 Maximiliano Curia  wrote:
> With the new release of sbuild 0.77 (which moves the run_lintian call outside 
> of the build function), lintian receives the name of a no longer existing 
> changes file (as the unlink is part of the copy_changes) and as such it fails 
> with, for example:
>  I: schroot -d /<> -c 
> unstable-amd64-sbuild-a8e6ff65-a882-41b6-9ce3-b5e764b4ca8c --run-session -q 
> -u maxy -p -- lintian -I --pedantic --show-overrides 
> sddm_0.18.0-1_amd64.changes
>  D: Running command: schroot -d /<> -c 
> unstable-amd64-sbuild-a8e6ff65-a882-41b6-9ce3-b5e764b4ca8c --run-session -q 
> -u maxy -p -- lintian -I --pedantic --show-overrides 
> sddm_0.18.0-1_amd64.changes
>  warning: "sddm_0.18.0-1_amd64.changes" cannot be processed.
>  warning: It is not a valid lab query and it is not an existing file.
> 
>  E: Lintian run failed (runtime error)
> 
> The issue is not present using the 0.76 version, and can be workaround 
> commenting the unlink call from the copy_changes function (as shown in the 
> attached file).
> 
> Thanks for working in sbuild. :)

I really fail to reproduce your problem. Can you give me your exact sbuild
invocation so that I may be able to see the same error that you see? I see it
neither in the version currently in unstable nor in git master.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#870344: [Pkg-mozext-maintainers] Bug#870344: New upstream release supporting Firefox 57+

[Sean Whitton]

Hello Moritz,

On Thu 03 Jan 2019 at 11:06pm +0100, Moritz Mühlenhoff wrote:

> On Tue, Aug 01, 2017 at 10:02:39AM -0400, Sean Whitton wrote:
>> Hello Damyan,
>>
>> On Tue, Aug 01, 2017 at 08:58:38AM +, Damyan Ivanov wrote:
>> > When firefox hits unstable (probably towards the end of this year) this
>> > bug will become grave.
>>
>> I think that it will only become grave once firefox-esr reaches a
>> version newer than 57.
>
> This is still broken in Stretch. Are you planning to also update
> stable or shall I file a removal bug to drop the broken package
> from stable?

I won't be, since I've never worked on this package, but perhaps Damyan
will.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#918185: fai - fcopy mode handling broken precedence

[Thomas Lange]

I guess my idea was that you set the default using the file-modes
file and then can override it in a script using the cmdline option if
you need different modes for the same file in different scripts.
But it seems also reasonable to change this.

So you like to change the precedence so that the cmdline sets the
default and the file-modes can override this?

The precedence will then become from low to high:

- modes of source file
- specified on the command line with -m/-M
- file-modes files in the files tree

That seems to be obvious better.
This is a normal bug. But surely I will fix it in the next release.

-- 
regards Thomas

Bug#829119: radicale does not commit to git

[Jens Reyer]

Package: radicale
Followup-For: Bug #829119

Hi

committing to git works here (radicale 2.1.11-2 and previous versions
from experimental).
python-dulwich / python3-dulwich is not needed anymore for this.

$ grep hook /etc/radicale/config
hook = ([ -d .git ] || git init) && ([ -e .gitignore ] || printf
'.Radicale.cache\n.Radicale.lock\n.Radicale.tmp-*\n' > .gitignore) &&
git add -A && (git diff --cached --quiet || git commit -m "Changes by
"%(user)s)

Whenever it didn't work here, it was because of messed up permissions
(although this is probably not the case for the submitter, I'd still
suggest a "chown -R radicale:radicale /var/lib/radicale").

Greets
jre

Bug#918229: criu: FTBFS building for armhf on arm64

[Steve McIntyre]

Package: src:criu
Version: 3.8.1-1
Severity: important

Hi!

I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so this rebuild is to identify packages that
might have problems with this configuration.

I've tried to build criu for armhf on top of arm64, and it's failing
to build:

...
  PBCC images/pipe-data.pb-c.c
  PBCC images/sk-packet.pb-c.c
  PBCC images/pstree.pb-c.c
  PBCC images/fs.pb-c.c
In file included from include/common/lock.h:9,
 from compel/plugins/std/infect.c:5:
include/common/asm/atomic.h:61:2: error: #error ARM architecture version 
(CONFIG_ARMV*) not set or unsupported.
 #error ARM architecture version (CONFIG_ARMV*) not set or unsupported.
  ^
include/common/asm/atomic.h: In function 'atomic_add_return':
include/common/asm/atomic.h:82:2: error: implicit declaration of function 
'smp_mb' [-Werror=implicit-function-declaration]
  smp_mb();
  ^~
  PBCC images/eventpoll.pb-c.c
  AR   soccr/libsoccr.a
  PBCC images/eventfd.pb-c.c
cc1: all warnings being treated as errors
make[2]: *** 
[/home/steve/debian/build/criu/criu-3.8.1/scripts/nmk/scripts/build.mk:208: 
compel/plugins/std/infect.o] Error 1
make[1]: *** [Makefile.compel:52: compel/plugins/std.lib.a] Error 2
make[1]: *** Waiting for unfinished jobs
...

It's blindly using the output of uname and assuming that's the right
answer for the target system. I *might* be building on a system that's
showing as "armv8l", but I'm building *for* armhf which is ARMv7 not
ARMv7. This package could do with a way to specify what the target is
via configuration, rather than the simple parsing of uname that's
currently hard-coded in the Makefile.

Full build log online at

  
https://www.einval.com/debian/arm/rebuild-logs/armhf/FAIL/criu_3.8.1-1_armhf.log

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

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