Bug#943744: caja: Cannot move file to Trash, do you want to delete immediately?

[mike . gabriel]

Hi,

Am Mittwoch, 30. Oktober 2019 schrieb scott092...@aol.com:
> Having done some investigating, I find that in 4 previous distros I have 
> installed (all Lubuntu),
> none has had root:root as owners of  ~/.local/share/Trash
> 
> Since the contents of the files directory in that folder in my current Debian 
> install are files
> that would originally have been in a sub-directory of a system directory, 
> they would have had to 
> be trashed from a sudo-invoked FM; it is at least possible that the trashing 
> caused ownership
> to change to root:root.
> 
> However...
> 
> Most of the files I trash are in my personal directories, in my data 
> partition, and would (should)
> end up in the /data/.Trash-1000  trash, which as you can see, is owned by me.
> 
> Unless Caja was trying to trash the files by copying them from the data 
> partition to the system
> partition trash folder, I cannot see how it had difficulty trashing them.
> 
> Can anyone enlighten me?

IMHO, the ~/.local/share/Trash folder needs to be owned by you, not root. Using 
sudo can play tricks on you, if set up like e.g. in Ubuntu: if applications are 
use first time and that with sudo, new config files and dirs are created in the 
user home, nut owned by root.

On my Ubuntu systems I run a 'sudo chown $user:$user -Rfv ~' in regular 
intervals...

Mike

-- 
Gesendet von meinem Fairphone2 (powered by Sailfish OS).

Bug#940595: transition: hypre

[Drew Parsons]

On 2019-10-18 15:56, Emilio Pozuelo Monfort wrote:

On 17/10/2019 17:05, Drew Parsons wrote:


Hi Emilio, this is rather awkward.  Hypre upstream has just released 
2.18.1, so

this would be the one to run the transition on.

...
"The hypre team currently does nothing to ensure application binary 
interface
(ABI) compatibility. As a result, all releases (major, minor, or 
patch) should

be treated as incompatible."

It means we have to run a new library package for each patch release, 
and
therefore have to jump back into the NEW queue with libhypre-2.18.1. 
 It's
either that, or provide only a generic libhypre package and apply 
rigidly strict

shlib files depending strictly on a given version.

...

Right, the strict dependency via shlibs and provides would make testing
migrations harder as everything would need to transition at the same 
time (hypre
and all rdeps). However there are three rdeps and you control two of 
them, so it

doesn't look like a terrible situation.



hypre 2.18.1 is now ready in experimental.

I've implemented the common libhypre option with shlibs patch-version 
dependency. If this approach proves problematic in practice then we can 
switch back to version-based library package names afterwards if we need 
to.


I've confirmed petsc and sundials build successfully.

Let's do this transition.

Drew

Bug#936164: auto-07p: Python2 removal in sid/bullseye

[Sergey B Kirpichev]

tags 937695 +pending +upstream +fixed-upstream
thanks

It seems, Python3-compatible release will be available
soon: https://github.com/auto-07p/auto-07p/issues/2

On Fri, 30 Aug 2019 07:10:54 + Matthias Klose  wrote:
> Package: src:auto-07p
> Version: 0.9.1+dfsg-7
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>   
>   This is the preferred option.
> 
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.  If the
>   package still has reverse dependencies, raise the severity to
>   "serious" and document the reverse dependencies with the BTS affects
>   command.  If the package has no reverse dependencies, confirm that
>   the package can be removed, reassign this issue to ftp.debian.org,
>   make sure that the bug priority is set to normal and retitle the
>   issue to "RM: PKG -- removal triggered by the Python2 removal".
> 
> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
> 
>   This is the least preferred option.
> 
> If the conversion or removal needs action on another package first,
> please document the blocking by using the BTS affects command, like
> 
>   affects  + src:auto-07p
> 
> If there is no py2removal bug for that reverse-dependency, please file
> a bug on this package (similar to this bug report).
> 
> If there are questions, please refer to the wiki page for the removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.
> 
> 

Bug#868164: systemd: fakeraid + cryptsetup (root) + lvm results in 90s time out waiting for device at boot

[Sergey Belyashov]

Hi,
I have found, that my problem is caused only in case of mdraid device
partitioning. To reproduce:
1. Take 2 HDD (at least by 50 GB)
2. Run from any LiveCD
3. Make two partitions on each HDD: for 256-1024MB and for remaining space,
make first partition bootable
4. Create mdraid1 around second partitions of both HDD
5. Repartition md device by 3 partitions: 10GB (md0p1), 20GB (md0p2) and
remaining space (md0p3)
6. Using cryptsetup configure luks encryption over md0p2.
7. Install debian 9 or 10, using: /dev/sda1 - /boot, /dev/md0p1 - /root,
/dev/md0p2 - /var, /dev/mapper/ - /home
After reboot system do not start if default boot options are specified. It
will wait for some devices to be ready, but no any password prompt. There
is only one way to boot system: run rescue mode and then exit from rescue
shell using Ctrl-D.

If you create on HDDs four partitions and use them to build four RAID1
devices, then encrypted device configured on /dev/md3 will start on boot
successfully (after prompting password).

So I think, some boot scripts/services does not know anything about md
device partitioning.

Bug#940595: transition: hypre

[Drew Parsons]

On 2019-10-30 15:21, Drew Parsons wrote:


hypre 2.18.1 is now ready in experimental.

I've implemented the common libhypre option with shlibs patch-version
dependency. If this approach proves problematic in practice then we
can switch back to version-based library package names afterwards if
we need to.

I've confirmed petsc and sundials build successfully.

Let's do this transition.


p.s. for bonus lols, I just checked and yes, 2.18.2 has just been 
released...


So yes, the unversioned libhypre package name is certainly the option 
that will preserve the greatest sanity (I'll proceed directly with 
2.18.2 once you give the thumbs up).


(they're releasing unusually rapidly lately. Previously there have been 
less than 2 releases each year).

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

[intrigeri]

Control: tag -1 + patch

Hi,

I believe I partly understood the bug. I did not dive into why it does
not happen in all cases; but I suspect this has to do with the recent
librole-tiny-perl updates. Regardless, my understanding is that the
affected Lintian code was not entirely correct, and used to work
merely by luck, while my proposed fix makes it more correct and
robust:

https://salsa.debian.org/lintian/lintian/merge_requests/266

Cheers!

Bug#943813: Version 1.0.49 available

[Sebastien Bacher]

Package: pure-ftpd
Version: 1.0.47-3

There is a new 1.0.48/49 available upstream including TLS 1.3/openssl
1.1.X proper support, it would be nice to get it updated in Debian
https://www.pureftpd.org/project/pure-ftpd/news/

Thanks,

Bug#943814: amanda-common: amcrypt-ossl-asym fails: deprecated options of openssl enc

[Heiko Schlittermann (HS12-RIPE)]

Package: amanda-common
Version: 3.5.1
Severity: important
Tags: upstream patch

Dear Maintainer,

using amcrypt-ossl-asym results in extra output about deprected "openssl
enc" options and does not encrypt: no backup is written!

root@marta:/# date | sudo -su backup amcrypt-ossl-asym >/dev/null
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.

For testing purpose I added (as recommended) the option -pbkdf2 to the encoding 
and the decoding
lines and now it works.

Please fix and report upstream.

Thank you.

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

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

Versions of packages amanda-common depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  libc6 2.28-10
pn  libcurl3  
ii  libcurl4  7.64.0-4
ii  libglib2.0-0  2.58.3-2+deb10u1
ii  libssl1.1 1.1.1d-0+deb10u2
ii  mailutils [mailx] 1:3.5-3
pn  openbsd-inetd | inet-superserver  
ii  perl  5.28.1-6
ii  perl-base [perlapi-5.28.0]5.28.1-6
pn  perlapi-5.24.1
ii  update-inetd  4.49

amanda-common recommends no packages.

Versions of packages amanda-common suggests:
pn  amanda-server | amanda-client  

Bug#758064: FTBFS with clang instead of gcc

[Michael Crusoe]

On Thu, 29 Dec 2016 06:59:50 +0100 Matthias Klose  wrote:
> Control: tags -1 + moreinfo
>
> please recheck with 0.168 available in experimental, and provide an
updated
> patch if necessary.

0.175-2 was tested on 2019-01-09 and now gets a configure time error of

checking for gcc with GNU99 support... no
configure: error: gcc with GNU99 support required

https://clang.debian.net/logs/2019-01-09-8svn/elfutils_0.175-2_unstable_clang.log

Bug#943623: Any idea how to fix this?

[Sylvestre Ledru]

I am working on a potential fix

S


Le 30/10/2019 à 03:13, Shmerl a écrit :

This issue currently breaks building Mesa master with llvm10 snapshot from
http://apt.llvm.org/unstable (in Debian testing).

___
Pkg-llvm-team mailing list
pkg-llvm-t...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team

Bug#943815: munin-plugins-core: ntp_states plugin doesn't work

[johannes.hamann]

Package: munin-plugins-coreVersion: 2.0.49-1Hello,As I pointed out here[1] the 
ntp_states plugins accidentally doesn't worke in this release.Upstream fixed it 
with this[2] commit.Could you please ensure to have this fix in the package as 
soon as possible?Thanks JohannesRefs:[1] 
https://github.com/munin-monitoring/munin/issues/1244[2] 
https://github.com/munin-monitoring/munin/commit/a1738b47356e7582ba96bf73a9e00b20f095611e

Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file

[intrigeri]

Hi,

intrigeri:
> Martin-Éric Racine:
>> At the very least, allowing anything inside /home/${USER} would
>> probably eliminate the vast majority of bug reports. Let's try it.

> Deal!

Here's a merge request implementing this proposal:
https://salsa.debian.org/printing-team/cups/merge_requests/4

Cheers,
-- 
intrigeri

Bug#943816: Please get rid of python2 dependencies

[Christoph Berg]

Package: src:llvm-toolchain-9
Version: 1:9.0.0-2
Severity: normal

I just upgraded my build chroots from llvm 7 to llvm 9 because that's
what the PostgreSQL packages are using, and I was surprised that this
pulled in python2.7:

11:21:17 + apt-get -y install llvm-9-dev clang-9 libllvm7-
11:21:17 Reading package lists...
11:21:17 Building dependency tree...
11:21:17 Reading state information...
11:21:17 The following package was automatically installed and is no longer 
required:
11:21:17   libobjc-9-dev
11:21:17 Use 'apt autoremove' to remove it.
11:21:17 The following additional packages will be installed:
11:21:17   libclang-common-9-dev libclang-cpp9 libllvm9 libobjc-8-dev libpfm4
11:21:17   libpython-stdlib libpython2-stdlib libpython2.7-minimal 
libpython2.7-stdlib
11:21:17   libz3-4 llvm-9 llvm-9-runtime llvm-9-tools python python-minimal
11:21:17   python-pygments python-yaml python2 python2-minimal python2.7
11:21:17   python2.7-minimal python3-pygments python3-yaml
11:21:17 Suggested packages:
11:21:17   clang-9-doc llvm-9-doc python-doc python-tk python-pygments-doc
11:21:17   ttf-bitstream-vera python2-doc python2.7-doc
11:21:17 Recommended packages:
11:21:17   libomp-9-dev python-chardet python-pkg-resources
11:21:17 The following packages will be REMOVED:
11:21:17   clang-7 libclang-common-7-dev libclang1-7 libllvm7 llvm-7 llvm-7-dev
11:21:17   llvm-7-runtime
11:21:17 The following NEW packages will be installed:
11:21:17   clang-9 libclang-common-9-dev libclang-cpp9 libllvm9 libobjc-8-dev 
libpfm4
11:21:17   libpython-stdlib libpython2-stdlib libpython2.7-minimal 
libpython2.7-stdlib
11:21:17   libz3-4 llvm-9 llvm-9-dev llvm-9-runtime llvm-9-tools python 
python-minimal
11:21:17   python-pygments python-yaml python2 python2-minimal python2.7
11:21:17   python2.7-minimal python3-pygments python3-yaml
11:21:17 0 upgraded, 25 newly installed, 7 to remove and 0 not upgraded.
11:21:17 Need to get 196 MB of archives.
11:21:17 After this operation, 309 MB of additional disk space will be used.

Is that really needed?

Christoph

Bug#943216: Bug#943753: RFS: simple-scan/3.34.1-2 -- Simple Scanning Utility

[Jeremy Bicha]

On Tue, Oct 29, 2019 at 1:48 PM Jörg Frings-Fürst  wrote:
> after the answer to my RFS - bug went directly to non-participants, I
> answer the same way.
>
> A note in advance: I am neither employed by Debian nor by Canonical. I
> have to do a job because of that.
> My employer supports my work for Debian, but at the moment I can only
> work for Debian in my spare time.
>
> Therefore, I don't allow myself to answer mails that contain sayings
> like "... It's frustrating that there has been no response to ...".

I also am neither employed by Debian nor by Canonical. My job does not
involve anything at all related to Debian or Ubuntu or Linux or open
source software. I have never received a salary to do Debian or Ubuntu
packaging.

I did not start with my "it's frustrating" email. I sent you patches
to https://bugs.debian.org/904168 over a year ago. I sent you a
followup via that bug. I pinged you on IRC.

I also have made several offers to sponsor your uploads which should
save you time and effort, but you ignore me there too. I feel like I
am left with no other reasonable alternative than to try to reach out
to your sponsors to get acknowledgment of my patches.

The Debian GNOME team would be happy to take over maintainership of
simple-scan if it is too much of a burden to accept patches and answer
emails. We have volunteered multiple times and the offer is still
open.


There are a total of 8 commits in my branch; it looks like you didn't
see the 3 oldest commits.

Thanks,
Jeremy Bicha

Bug#943817: ITP: ripser -- Fast computation of persistent homology of Vietoris-Rips complexes

[Gard Spreemann]

Package: wnpp
Severity: wishlist
Owner: Gard Spreemann 

* Package name: ripser
  Version : 1.1
  Upstream Author : Ulrich Bauer
* URL : http://ripser.org
* License : MIT
  Programming Lang: C++
  Description : Fast computation of persistent homology of flag complexes

Ripser computes persistent homology of flag complexes (such as
Vietoris-Rips complexes) only, allowing significant gains in
computation time and memory usage.

See https://arxiv.org/abs/1908.02518.

The package is widely used in the field of topological data
analysis. It is mature, slow-moving and has very few dependencies. I
will be maintaining the package for myself. I would currently need a
sponsor, but I am in the process of becoming a DD.

Bug#943819: RM: haskell-gi-gtk-hs [armhf] -- ROM; depends on missing libghc-gi-gtk-dev

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove haskell-gi-gtk-hs from armhf.
It depends on missing libghc-gi-gtk-dev.

Thanks,

-- 
Ilias

Bug#943820: RM: haskell-gi-vte [armhf] -- ROM; depends on missing libghc-gi-gtk-dev

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove haskell-gi-vte from armhf.
It depends on missing libghc-gi-gtk-dev.

Thanks,

-- 
Ilias

Bug#943818: RM: haskell-gi-dbusmenugtk3 [armhf] -- ROM; depends on missing libghc-gi-gtk-dev

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove haskell-gi-dbusmenugtk3 from armhf.
It depends on missing libghc-gi-gtk-dev.

Thanks,

-- 
Ilias

Bug#943821: RM: haskell-gtk-strut [armhf] -- ROM; depends on missing libghc-gi-gtk-dev

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove haskell-gtk-strut from armhf.
It depends on missing libghc-gi-gtk-dev.

Thanks,

-- 
Ilias

Bug#943822: RM: haskell-gtk-sni-tray [armhf] -- ROM; depends on missing libghc-gi-gtk-dev

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove haskell-gtk-sni-tray from armhf.
It depends on missing libghc-gi-gtk-dev.

Thanks,

-- 
Ilias

Bug#943823: RM: taffybar [armel armhf] -- ROM; depends on missing libghc-gi-gtk-dev

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove taffybar from both armel and armhf.
It depends on missing libghc-gi-gtk-dev.

Thanks,

-- 
Ilias

Bug#943824: [libeantic0] crashing because of buffer overflow

[Giovanni Mascellani]

Package: libeantic0
Version: 0.1.3+ds-3
Severity: normal
Tags: patch

The attached patch fixes a crash caused by a buffer overflow: a sprintf
call in the code uses a fixed size buffer without checking if the string
will actually fit inside it.

I discovered it because an application I am writing crashed over it.

The attached patch should fix the problem. I can NMU if you're ok with it.

Thanks, Giovanni.


--- System information. ---
Architecture: Kernel:   Linux 5.2.0-3-amd64

Debian Release: bullseye/sid
  500 xenial  updates.signal.org   500 unstable-debug
debug.mirrors.debian.org   500 unstabledeb.debian.org   500
testing deb.debian.org   500 stable  repo.skype.com
500 stable  dl.google.com 1 experimentaldeb.debian.org
--- Package information. ---
Depends(Version) | Installed
-+-==
libc6   (>= 2.4) | libflint-2.5.2   |
libflint-arb2  (>= 1:2.17.0) | libgcc1   (>= 1:3.0) |
libgmp10 | libgomp1  (>= 4.2.1) |
libstdc++6(>= 4.1.1) |

Package's Recommends field is empty.

Package's Suggests field is empty.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
diff -Nru e-antic-0.1.3+ds/debian/changelog e-antic-0.1.3+ds/debian/changelog
--- e-antic-0.1.3+ds/debian/changelog	2019-09-27 18:18:49.0 +0200
+++ e-antic-0.1.3+ds/debian/changelog	2019-10-30 12:37:40.0 +0100
@@ -1,3 +1,10 @@
+e-antic (0.1.3+ds-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to fix buffer overflow on sprintf call.
+
+ -- Giovanni Mascellani   Wed, 30 Oct 2019 12:37:40 +0100
+
 e-antic (0.1.3+ds-3) unstable; urgency=medium
 
   * FTBFS fix release (Closes: #941259), see below.
diff -Nru e-antic-0.1.3+ds/debian/patches/fix_sprintf_buffer_overflow.patch e-antic-0.1.3+ds/debian/patches/fix_sprintf_buffer_overflow.patch
--- e-antic-0.1.3+ds/debian/patches/fix_sprintf_buffer_overflow.patch	1970-01-01 01:00:00.0 +0100
+++ e-antic-0.1.3+ds/debian/patches/fix_sprintf_buffer_overflow.patch	2019-10-30 12:37:35.0 +0100
@@ -0,0 +1,24 @@
+From: Giovanni Mascellani 
+Subject: Fix buffer overflow caused by sprintf
+
+sprintf() is called on a fixed-size buffer, overflowing it
+on some inputs and triggering undefined behaviour. This patch
+ensure that the buffer is sufficiently large.
+
+Index: e-antic-0.1.3+ds/renf_elem/get_str_pretty.c
+===
+--- e-antic-0.1.3+ds.orig/renf_elem/get_str_pretty.c
 e-antic-0.1.3+ds/renf_elem/get_str_pretty.c
+@@ -42,8 +42,10 @@ char * renf_elem_get_str_pretty(renf_ele
+ if (flag & EANTIC_STR_D)
+ {
+ // output of get_d
+-s = flint_malloc(20 * sizeof(char));
+-sprintf(s, "%lf", renf_elem_get_d(a, nf, ARF_RND_NEAR));
++double d = renf_elem_get_d(a, nf, ARF_RND_NEAR);
++int len = snprintf(NULL, 0, "%lf", d);
++s = flint_malloc((len+1) * sizeof(char));
++snprintf(s, len+1, "%lf", d);
+ t = flint_realloc(t, strlen(t) + strlen(s) + 1);
+ strcat(t, s);
+ flint_free(s);
diff -Nru e-antic-0.1.3+ds/debian/patches/series e-antic-0.1.3+ds/debian/patches/series
--- e-antic-0.1.3+ds/debian/patches/series	2019-06-20 19:24:48.0 +0200
+++ e-antic-0.1.3+ds/debian/patches/series	2019-10-30 12:33:26.0 +0100
@@ -1,3 +1,4 @@
 upstream-libtool-versioning.patch
 upstream-libtool-version_script.patch
 debianization.patch
+fix_sprintf_buffer_overflow.patch


signature.asc
Description: OpenPGP digital signature

Bug#864079: Status of this bug?

[sixerjman]

I would like to know if anybody is working on this. There has been a recent
update of
perl-base from 5.28 to 5.30 which necessitated rebuilding the backuppc and
backuppc-xs
(now libbackuppc-xs-perl) packages. The most recent backuppc version is now
4.3.1
and each time a new release of any of packages comes out it necessitates
rebuilding
the packages per

https://github.com/backuppc/backuppc/wiki/Build-Your-Own-Packages.

Now today on testing yet another perl-base upgrade from 5.30.0-8 to
5.30.0-9 has come
along, and I just got done with the a somewhat stressful rebuild for
5.30.0-8.

For what it's worth, the rsync-bpc on my server is version 3.0.9.12 which
has worked
with v4.2, v4.3 and v4.3.1 of backuppc. This bug is listed as a packaging
blocker
for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873075 but it seems
like
it could be packaged up so progress can be made on packaging backuppc-v4
proper.

Bug#943825: RM: cp2k [mipsel] -- ROM; libint2 Build-Depends not being built

[Michael Banck]

Package: ftp.debian.org
Severity: normal

Hi,

libint2 is not available on mipsel due to autobuilder resources, so the
corresponding cp2k mipsel binary package needs to be removed as well for
it to migrate to testing.


Thanks

Michael

Bug#940116: [Debichem-devel] Bug#940116: cp2k: autopkgtest regression: missing versioned (test) depends?

[Michael Banck]

Hi Paul,

On Thu, Sep 12, 2019 at 03:59:53PM +0200, Paul Gevers wrote:
> Source: cp2k
> Version: 6.1-3
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainers,
> 
> With a recent upload of cp2k the autopkgtest of cp2k fails in testing
> when that autopkgtest is run with the binary packages of cp2k from
> unstable. It passes when run with only packages from testing. In tabular
> form:
>passfail
> cp2k   from testing6.1-3
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing

I tried to reproduce this, but unsuccessfully so far.

> https://ci.debian.net/data/autopkgtest/testing/amd64/c/cp2k/2934307/log.gz

>From the next one in line
(https://ci.debian.net/data/autopkgtest/testing/amd64/c/cp2k/2944184/log.gz)
the tests appears to be fine again.

> dh /usr/share/mpi-default-dev/debian_defaults
> make: dh: Command not found

This one is in
https://ci.debian.net/data/autopkgtest/testing/amd64/c/cp2k/2944184/log.gz
as well, so I don't think it's an issue.
 
> >>>
> /tmp/autopkgtest-lxc.yey4jvbr/downtmp/build.jim/src/tools/regtesting/../..//TEST-Linux-x86_64-gfortran-popt-2019-09-11_08-15-36/tests/QS/regtest-tddfpt
> H2O_tddfpt-s-1.inp
> RUNTIME FAIL

I guess the issue is:

|/tmp/autopkgtest-lxc.yey4jvbr/downtmp/build.jim/src/tools/regtesting/../..///exe/Linux-x86_64-gfortran/cp2k.popt:
|symbol lookup error:
|/tmp/autopkgtest-lxc.yey4jvbr/downtmp/build.jim/src/tools/regtesting/../..///exe/Linux-x86_64-gfortran/cp2k.popt:
|undefined symbol: libint2_build_eri1
|EXIT CODE:  127  MEANING:  RUNTIME FAIL

That has been fixed since in testing it seems, can we close this bug?


Michael

Bug#935994: [Debichem-devel] Bug#935994: nwchem: NWChem compiled with long int lapack/blas interface?

[Michael Banck]

Hi Giacomo,

sorry, I apparently missed your mail initially.

On Wed, Aug 28, 2019 at 08:42:21PM +0200, Giacomo Mulas wrote:
> I am a long time NWChem (ab)user.  I always have to compile NWChem myself,
> instead of using the binary version provided by debian, because for large
> enough molecules matrices become too big for the 32 bit int interface, and 
> only run if NWChem was compiled with a 64 bit int lapack/blas.
> I understand the need to provide a version of NWChem in debian that works
> with free libs available in debian as well, hence the need (so far) to 
> compile it using the 64 to 32 bit conversion of ints on 64 bit machines.
> However, lapack and blas libs with 64 bit integer interfaces just appeared
> on debian experimental, and have been available for some time in the 
> non-free (but packaged in non-free) Intel MKL libs.

I don't follow it closely, are you saying that both the refblas/lapack
packages now provide a 64bit int interface, and MKL? Or just MKL?

> Apparently, this would require limited changes in the debian/rules file.
> Would you consider building (also) such a version of nwchem, compiled with
> long int blas/lapack libs? 

Unless there are considerable downsides (are there?) I would not mind
switching the nwchem packaging to a 64bit int build using blas/lapack
libraries from main.

Regarding mkl, my current, initial opinion is that we would welcome
patches to make it possible to rebuild nwchem for MKL without source
changes (via some DEB_BUILD_OPTIONS or other external flags), but
building nwchem twice and once for MKL would (I believe) mean the source
package would have to move into contrib as it build-depended on a
non-free package.

Does anybody else want to chime in here and offer their opinion?


Michael

Bug#942397: [Debichem-devel] Bug#942397: ITP: avogadrolibs -- Molecular Graphics and Modelling System (libs)

[Michael Banck]

Hi Drew,

On Wed, Oct 16, 2019 at 01:02:28AM +0800, Drew Parsons wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Drew Parsons 
> 
> * Package name: avogadrolibs
>   Version : 1.91.0
>   Upstream Author : Kitware, Inc.
> * URL : https://github.com/OpenChemistry/avogadrolibs
> * License : BSD-3
>   Programming Lang: C++
>   Description : Molecular Graphics and Modelling System (libs)
> 
> The avoagadro package has been split upstream into avogadroapp
> and avogadrolibs.
> 
> We'll keep avogadroapp as the avogadro package, and therefore need to
> add the new package avogadrolibs, which will provide libavogadro.
> 
> To be team-maintained by the Debichem team, same as avogadro.

Great!


Michael

Bug#943826: gnome: Type 'A' when switching desktop

[Thomas Fischbach]

Package: gnome
Version: 1:3.30+2
Severity: normal

Dear Maintainer,

When I switch desktop a 'A' is typed.
Open terminal on 1st desktop and another application on 2nd desktop
Switch between desktops and sometimes a 'A' is typed to the terminal. Or if I'm
using tail I see '^[[1;7A'

Using gnome on xorg is not effected



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

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

Versions of packages gnome depends on:
ii  avahi-daemon 0.7-4+b1
ii  cheese   3.34.0-1+b1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 10.0.3
ii  evolution3.34.1-2+b1
ii  evolution-plugins3.34.1-2+b1
ii  file-roller  3.32.2-1
ii  gedit-plugins3.34.0-3
ii  gnome-calendar   3.34.2-1+b1
ii  gnome-clocks 3.34.0-1+b2
ii  gnome-color-manager  3.32.0-2
ii  gnome-core   1:3.30+2
ii  gnome-documents  3.34.0-1
ii  gnome-getting-started-docs   3.34.0-2
ii  gnome-maps   3.34.1-1
ii  gnome-music  3.32.2-1
ii  gnome-photos 3.34.0-2
ii  gnome-screenshot 3.34.0-1
ii  gnome-sound-recorder 3.34.0-1
ii  gnome-todo   3.28.1-5
ii  gnome-tweaks 3.34.0-2
ii  gnome-weather3.34.0-1
ii  gstreamer1.0-libav   1.16.1-1
ii  gstreamer1.0-plugins-ugly1.16.1-1
ii  libgsf-bin   1.14.46-1
ii  libproxy1-plugin-networkmanager  0.4.15-7
ii  libreoffice-calc 1:6.3.3~rc1-1
ii  libreoffice-gnome1:6.3.3~rc1-1
ii  libreoffice-impress  1:6.3.3~rc1-1
ii  libreoffice-writer   1:6.3.3~rc1-1
ii  nautilus-sendto  3.8.6-3
ii  network-manager-gnome1.8.24-1
ii  orca 3.34.0-2
ii  rhythmbox3.4.3-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.3-2+b1
ii  rhythmbox-plugins3.4.3-2+b1
ii  rygel-playbin0.36.2-4
ii  rygel-tracker0.36.2-4
ii  seahorse 3.34-1
ii  simple-scan  3.34.1-1
ii  totem-plugins3.34.1-2
ii  vinagre  3.22.0-6
ii  vino 3.22.0-5
ii  xdg-user-dirs-gtk0.10-3

Versions of packages gnome recommends:
ii  gnome-games 1:3.30+2
ii  nautilus-extension-brasero  3.12.2-6
ii  transmission-gtk2.94-2+b1

Versions of packages gnome suggests:
ii  alacarte 3.11.91-5
pn  empathy  
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  gnome-remote-desktop 
pn  goobox | sound-juicer
ii  polari   3.34.0-1
pn  webext-ublock-origin 

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.34.0-2
ii  at-spi2-core  2.34.0-3
ii  baobab3.34.0-1
ii  caribou   0.4.21-7
ii  chromium  76.0.3809.100-1
ii  dconf-cli 0.34.0-1
ii  dconf-gsettings-backend   0.34.0-1
ii  eog   3.34.1-1
ii  epiphany-browser  3.34.1-1+b1
ii  evince3.34.1-1
ii  evolution-data-server 3.34.1-1+b1
ii  firefox   70.0-1
ii  fonts-cantarell   0.111-2
ii  gdm3  3.34.1-1
ii  gedit 3.34.0-1
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.62.1-1
ii  gnome-backgrounds 3.34.0-1
ii  gnome-bluetooth   3.34.0-1
ii  gnome-calculator  3.34.1-1
ii  gnome-characters  3.32.1-2
ii  gnome-contacts3.34-2
ii  gnome-control-center  1:3.34.1-1
ii  gnome-disk-utility3.34.0-2
ii  gnome-font-viewer 3.34.0-1+b1
ii  gnome-keyring 3.34.0-1
ii  gnome-logs3.34.0-1
ii  gnome-menus   3.32.0-1
ii  gnome-online-accounts 3.34.1-1
ii  gnome-online-miners   3.34.0-1
ii  gnome-session 3.34.1-1
ii  gnome-settings-daemon 3.34.1-1+b1
ii  gnome-shell   3.34.1+git20191024-1
ii  gnome-shell-extensions3.34.1-2
ii  gnome-software

Bug#943827: please B-D on libblas-dev instead of libatlas-base-dev

[Mo Zhou]

Package: meep
Version: 1.7.0-3+b1
Severity: important
Control: blocks 943712 by -1

Hi,

Please set B-D on libblas-dev instead of atlas, as per the MBF mail
and $943712.

I understand that electromagnetic field simulation is computational
intensive. It's recommended to add e.g.
  Recommend: libopenblas-base | libatlas3-base | libmkl-rt | libblas.so.3 ...
to the meep binary package.

Bug#926066: Back to the roots?

[Lisandro Damián Nicanor Pérez Meyer]

forwarded 926066 https://bugs.kde.org/show_bug.cgi?id=405496
thanks

Hi Karsten!

On Sun, 20 Oct 2019 at 06:21, Karsten  wrote:
>
> Hello Debian maintainer,
>
> i don't want to criticize you, but there is no progress in this and other 
> bugs like this any more.
> The problem is that i am still working with Debian 8 (Jessie) on my desktop, 
> because there are fundamental problems in
> Debian 9 & 10 desktop systems that will prevent to use ist, like a missing 
> sound.

After looking at the bug I can not see whether it's a Plasma issue or
a video card issue. Which video card are you using? Are you sharing
your home between the various installations you have?

Cheers, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#943828: please don't build against atlas

[Mo Zhou]

Package: altree
Version: 1.3.1-7+b2
Severity: important
Tags: patch

See the recent MBF announcement and #943712

If you think the reference BLAS sucks in terms of performance, it's
recommended to add this for the binary package:

  Recommends: libopenblas-base | libatlas3-base | libmkl-rt | libblas.so.3 ...

--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: bash-completion,
texlive-fonts-recommended,
libmath-tamuanova-perl,
libgsl-dev,
-   libatlas-base-dev,
+   libblas-dev,
libtest-deep-perl,
fig2dev
 Standards-Version: 4.1.4
diff --git a/debian/patches/blas.patch b/debian/patches/blas.patch
new file mode 100644
index 000..a770b3d
--- /dev/null
+++ b/debian/patches/blas.patch
@@ -0,0 +1,13 @@
+diff --git a/CUtils/Makefile.PL b/CUtils/Makefile.PL
+index 69a6c5b..795242c 100644
+--- a/CUtils/Makefile.PL
 b/CUtils/Makefile.PL
+@@ -9,7 +9,7 @@ WriteMakefile(
+ ($] >= 5.005 ? ## Add these new keywords supported since 5.005
+   (ABSTRACT_FROM  => 'lib/ALTree/CUtils.pm', # retrieve abstract from 
module
+AUTHOR => 'Claire Bardel ') : ()),
+-LIBS  => ['-lm -lpthread -lgsl -lcblas'], # e.g., '-lm'
++LIBS  => ['-lm -lpthread -lgsl -lblas'], # e.g., '-lm'
+ DEFINE=> '', # e.g., '-DHAVE_SOMETHING'
+ INC   => '-ggdb3 -I. -Ic_sources', # e.g., '-I. 
-I/usr/include/other'
+   # Un-comment this if you add C files to link with later:
diff --git a/debian/patches/series b/debian/patches/series
index ddb8d43..6ee37fe 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 from-upstream-no-nested-functions.patch
 no-quicksort.patch
+blas.patch

Bug#943664: xserver-xorg-video-radeon: Same behaviour on Thinkpad T41

[Petra R.-P.]

Package: xserver-xorg-video-radeon
Version: 1:19.1.0-1
Followup-For: Bug #943664

Dear Maintainer,

I can confirm every detail of the original report,
except that this happens here on an old IBM Thinkpad T 41.


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 May 22  2009 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Mar  5  2019 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] RV200/M7 [Mobility Radeon 7500] [1002:4c57]

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1183 May 25  2009 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc105"
Option  "XkbLayout" "de"
# Option"XkbVariant""nodeadkeys"
  Option"XkbOptions" "compose:caps" # P. R.-P., Mo., 25. Mai 2009
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
EndSection

Section "Device"
Identifier  "Configured Video Device"
EndSection

Section "Monitor"
Identifier  "Configured Monitor"
EndSection

Section "Screen"
Identifier  "Default Screen"
Monitor "Configured Monitor"
EndSection

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 5.2.0-3-686 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-22)) #1 SMP Debian 5.2.17-1 (2019-09-26)

Xorg X server log files on system:
--
-rw-r--r-- 1 root  root  36267 Aug  8  2015 /var/log/Xorg.1.log
-rw-r--r-- 1 root  root  37471 Oct 25  2015 /var/log/Xorg.0.log
-rw-r--r-- 1 petra petra 46383 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.2.log
-rw-r--r-- 1 petra petra 46383 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.3.log
-rw-r--r-- 1 petra petra 46383 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.4.log
-rw-r--r-- 1 petra petra 46383 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.5.log
-rw-r--r-- 1 petra petra 46383 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.6.log
-rw-r--r-- 1 petra petra 46383 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.7.log
-rw-r--r-- 1 petra petra 46383 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.8.log
-rw-r--r-- 1 petra petra 51769 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.9.log
-rw-r--r-- 1 petra petra 53220 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.10.log
-rw-r--r-- 1 petra petra 52334 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.11.log
-rw-r--r-- 1 petra petra 54232 Mar 10  2018 
/home/petra/.local/share/xorg/Xorg.12.log
-rw-r--r-- 1 petra petra 37588 Oct 30 13:52 
/home/petra/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 petra petra 24233 Oct 30 14:05 
/home/petra/.local/share/xorg/Xorg.0.log

Contents of most recent Xorg X server log file 
(/home/petra/.local/share/xorg/Xorg.0.log):
--
[   122.848] 
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[   122.849] Build Operating System: Linux 4.9.0-8-amd64 i686 Debian
[   122.849] Current Operating System: Linux netty 5.2.0-3-686 #1 SMP Debian 
5.2.17-1 (2019-09-26) i686
[   122.850] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.2.0-3-686 
root=UUID=496e0e0a-6e7c-46c2-9132-315243394a2d ro framebuffer=false quiet 
fb=false systemd.show_status=true
[   122.850] Build Date: 05 March 2019  08:11:12PM
[   122.851] xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
[   122.851] Current version of pixman: 0.36.0
[   122.851]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   122.851] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented

Bug#943830: apt Also Removes Fixed Packages After Failed Install

[Adam Danischewski]

Package: apt
Version: 1.9.4
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
 I installed Linux Headers yet the install failed, I forgot I had
 done that and rebooted. Later I went to install a new package,
 xmms2, it told me that I needed to run apt --fix-broken install 
 So I ran that and the install went through. Thereafter, I decided I 
 didn't want xmms2 and removed the package with sudo apt-get
 autoremove --purge xmms2. Yet apt not only removed xmms2 it also 
 unnecessarily removed the unrelated Linux Headers. 

 There is no way to avoid uninstalling what was fixed. 

   * What outcome did you expect instead? Only what I installed to be
   * removed. 

   $ get xmms2

Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 linux-headers-5.4.0-994-lowlatency : Depends: linux-headers-5.4.0-994 but it 
is not installable
 xmms2 : Depends: xmms2-client-cli but it is not going to be installed
 Depends: xmms2-core but it is not going to be installed
 Depends: xmms2-icon but it is not going to be installed
 Depends: xmms2-plugin-alsa but it is not going to be installed or
  xmms2-plugin-output
 Depends: xmms2-plugin-id3v2 but it is not going to be installed
 Depends: xmms2-plugin-mad but it is not going to be installed
 Depends: xmms2-plugin-vorbis but it is not going to be installed
 Depends: xmms2-plugin-pulse but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).
$ sudo apt --fix-broken install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  linux-headers-5.0.0-31 linux-headers-5.0.0-31-generic 
linux-modules-5.0.0-31-generic
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  linux-headers-5.4.0-994-lowlatency
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
2 not fully installed or removed.
Need to get 0 B/390 kB of archives.
After this operation, 14.1 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 613245 files and directories currently installed.)
Removing linux-headers-5.4.0-994-lowlatency (5.4.0-994.201910292204) ...
$ get xmms2

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  linux-headers-5.0.0-31 linux-headers-5.0.0-31-generic 
linux-modules-5.0.0-31-generic
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  xmms2-client-cli xmms2-core xmms2-icon xmms2-plugin-alsa xmms2-plugin-id3v2 
xmms2-plugin-mad xmms2-plugin-pulse xmms2-plugin-vorbis
The following NEW packages will be installed:
  xmms2 xmms2-client-cli xmms2-core xmms2-icon xmms2-plugin-alsa 
xmms2-plugin-id3v2 xmms2-plugin-mad xmms2-plugin-pulse xmms2-plugin-vorbis
0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 699 kB/1,089 kB of archives.
After this operation, 1,597 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://us.archive.ubuntu.com/ubuntu eoan/universe amd64 xmms2-client-cli 
amd64 0.8+dfsg-18.2 [55.6 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu eoan/universe amd64 xmms2-core amd64 
0.8+dfsg-18.2 [536 kB]
Get:3 http://us.archive.ubuntu.com/ubuntu eoan/universe amd64 xmms2-icon all 
0.8+dfsg-18.2 [32.2 kB]
Get:4 http://us.archive.ubuntu.com/ubuntu eoan/universe amd64 xmms2-plugin-alsa 
amd64 0.8+dfsg-18.2 [13.7 kB]
Get:5 http://us.archive.ubuntu.com/ubuntu eoan/universe amd64 
xmms2-plugin-pulse amd64 0.8+dfsg-18.2 [13.7 kB]
Get:6 http://us.archive.ubuntu.com/ubuntu eoan/universe amd64 
xmms2-plugin-id3v2 amd64 0.8+dfsg-18.2 [14.6 kB]
Get:7 http://us.archive.ubuntu.com/ubuntu eoan/universe amd64 xmms2-plugin-mad 
amd64 0.8+dfsg-18.2 [14.7 kB]
Get:8 http://us.archive.ubuntu.com/ubuntu eoan/universe amd64 
xmms2-plugin-vorbis amd64 0.8+dfsg-18.2 [12.0 kB]
Get:9 http://us.archive.ubuntu.com/ubuntu eoan/universe amd64 xmms2 amd64 
0.8+dfsg-18.2 [7,388 B]
Fetched 699 kB in 0s (1,618 kB/s)
Selecting previously unselected package xmms2-client-cli.
(Reading database ... 601036 files and directories currently installed.)
Preparing to unpack .../0-xmms2-client-cli_0.8+dfsg-18.2_amd64.deb ...
Unpacking xmms2-client-cli (0.8+dfsg-18.2) ...
Selecting previously unselected package xmms2-core.
Preparing to unpack .../1-xmms2-core_0.8+dfsg-18.2_amd64.deb ...
Unpacking xmms2-core (0.8+dfsg-18.2) ...
Selecting previously unselec

Bug#939788: drbd-utils: Invalid argument with kernel 5.2

[Russell Mosemann]

As far as I can tell, the updated version of drbd-utils is not in unstable or 
even testing. What is the process for getting the latest version of drbd-utils 
into stable?
 
As mentioned previously, kernel 5.2 is useless on systems that use drbd.
 
--
Russell Mosemann

Bug#943829: pmemkv: please make the build reproducible

[Chris Lamb]

Source: pmemkv
Version: 1.0.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
pmemkv could not be built reproducibly. This is because it uses the
current build date when generating the manpages.

Patch attached that will use SOURCE_DATE_EPOCH [1] where set.

 [0] https://reproducible-builds.org/
 [1] https://reproducible-builds.org/specs/source-date-epoch/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/utils/md2man/md2man.sh2019-10-30 12:49:00.408574610 +
--- b/utils/md2man/md2man.sh2019-10-30 13:00:49.612409095 +
@@ -54,7 +54,7 @@
 section=`sed -n 's/^title:.*\([0-9]\))$/\1/p' $filename`
 version=`sed -n 's/^date:\ *\(.*\)$/\1/p' $filename`
 
-dt=$(date +"%F")
+dt="$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" +%F)"
 # since genereted docs are not kept in the repo the output dir may not exist
 out_dir=`echo $outfile | sed 's/\(.*\)\/.*/\1/'`
 mkdir -p $out_dir

Bug#722496: debdiff v2

[Callum Guy]

I believe the issue relates to if-pre-up.d/vlan - a comparison is performed
to evaluate the actual device MTU against that of the interface being
provisioned however when actioning the change the raw device name is used
in the ip link command:

if [ -n "$IF_MTU" -a -n "$IF_VLAN_RAW_DEVICE" ]; then
CUR_DEV_MTU=$(cat /sys/class/net/$IF_VLAN_RAW_DEVICE/mtu)
# increase the vlan raw device mtu if needed
if [ -n "$CUR_DEV_MTU" ] && [ $CUR_DEV_MTU -lt $IF_MTU ]; then
*ip link set dev $IF_VLAN_RAW_DEVICE mtu $IF_MTU*
fi
fi

Shouldn't this be:

if [ -n "$IF_MTU" -a -n "$IF_VLAN_RAW_DEVICE" ]; then
CUR_DEV_MTU=$(cat /sys/class/net/$IF_VLAN_RAW_DEVICE/mtu)
# increase the vlan raw device mtu if needed
if [ -n "$CUR_DEV_MTU" ] && [ $CUR_DEV_MTU -lt $IF_MTU ]; then
*ip link set dev $IFACE mtu $IF_MTU*
fi
fi

I would be happy to submit a patch if i knew where

On Mon, 12 Sep 2016 18:35:29 -0400 Dan Streetman <
dan.street...@canonical.com> wrote:
> sorry, there was a problem with the last patch; it didn't work if the
> vlan interface already existed, even if the raw device mtu was too
> low.  this updated debdiff checks and increases the dev mtu even if
> the vlan interface already exists.

-- 





*0333 332   |  www.x-on.co.uk   |   ** 
    
   *


X-on
is a trading name of Storacall 
Technology Ltd a limited company registered in
England and Wales.


Registered Office : Avaland House, 110 London Road, Apsley, Hemel 
Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.

The 
information in this e-mail is confidential and for use by the addressee(s)

only. If you are not the intended recipient, please notify X-on immediately 
on +44(0)333 332  and delete the
message from your computer. If you are 
not a named addressee you must not use,
disclose, disseminate, distribute, 
copy, print or reply to this email. Views
or opinions expressed by an 
individual
within this email may not necessarily
reflect the views of X-on 
or its associated companies. Although X-on routinely
screens for viruses, 
addressees should scan this email and any attachments
for
viruses. X-on 
makes no representation or warranty as to the absence of viruses
in this 
email or any attachments.

Bug#943831: should recommend xz-utils

[Tomas Pospisek]

Package: python3-apt
Version: 1.8.4
Severity: normal
Tags: patch

Please add `Recommends: xz-utils`. I happended to stumble into the same
problem as reported here: 
https://github.com/geerlingguy/docker-ubuntu1804-ansible/issues/7

The solution recommended there is to install `xz-utils`. After
installing `xz-utils` I can report that the `ansible` playbook run
succeeded.

I am thus assuming that `ansible-playbook` depends on `python3-apt` on the 
remote machine,
which apparently depends on `xz-utils` to manipulate or manage `*.deb`
packages.

Is my analysis correct? If so then please add the `Recommends: xz-utils`
dependency.
*t

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

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

Versions of packages python3-apt depends on:
ii  libapt-inst2.0 1.8.2
ii  libapt-pkg5.0  1.8.2
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libstdc++6 8.3.0-6
ii  python-apt-common  1.8.4
ii  python33.7.3-1

Versions of packages python3-apt recommends:
ii  iso-codes4.2-1
ii  lsb-release  10.2019051400

Versions of packages python3-apt suggests:
ii  apt  1.8.2
pn  python-apt-doc   
pn  python3-apt-dbg  

-- no debconf information

Bug#943832: asyncpg fails tests with python3.8

[Matthias Klose]

Package: src:asyncpg
Version: 0.18.3-2
Severity: important
Tags: sid bullseye patch
User: debian-pyt...@lists.debian.org
Usertags: python3.8

asyncpg fails tests with python3.8

= test session starts ==
platform linux -- Python 3.8.0, pytest-4.6.5, py-1.8.0, pluggy-0.13.0
rootdir: /<>
collected 249 items / 1 deselected / 248 selected

tests/test__environment.py ss[  0%]
tests/test_adversity.py .F.  [  2%]
tests/test_cache_invalidation.py .   [  5%]
tests/test_cancellation.py F.FF  [  7%]
tests/test_codecs.py [ 20%]
tests/test_connect.py ...[ 32%]
tests/test_copy.py .FF.FF..F [ 41%]
tests/test_cursor.py ..  [ 45%]
tests/test_exceptions.py ... [ 46%]
tests/test_execute.py ...F.  [ 50%]
tests/test_introspection.py ...F..   [ 52%]
tests/test_listeners.py  [ 55%]
tests/test_pool.py ..FF...FFE[ 72%]
tests/test_prepare.py .FF..  [ 85%]
tests/test_record.py ...F... [ 93%]
tests/test_test.py ..[ 93%]
tests/test_timeout.py .FFF.  [ 97%]
tests/test_transaction.py    [ 99%]
tests/test_utils.py ..   [100%]

note, these are results from a build in Ubuntu:
https://launchpad.net/ubuntu/+source/asyncpg/0.18.3-2

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Ian Jackson]

Control: close -1

Hi.  I have been asked to take a look at this bug.  I've reviewed the
bug log and tried to identify what the issues are that this bug is
about.

The title is an objection to the Conflicts/Replaces/Provides.

I confess I found the bug log rather diffuse.  Many different people
have contributed a variety of material and it is sometimes difficult
to pin down particular problems.


In terms of actual malfunctions caused by this set of package
relationships, digging through the bugs I found references to
these:

 #934132   Unblock request related to buster, no longer relevant
but I looked through it to try to understand the
underlying issues.

 #935910   "apt: Should be less tolerant of dpkg errors..."
   This is now fixed in apt, in bullseye.

 #934491   The corresponding blocking bug in elogind.  This
   represents the fact that elogind should not migrate
   to bullseye until #935910 had been fixed or avoided.

#934491 is itself RC.  It seems most convenient to deal with that
separately, in its own bug; so I don't think that is an issue that
should be seen as part of this bug.

#935304 is mentioned, but it is related to the libpam-systemd
dependency and seems not really related to this bug.


The bulk of the bug is a discussion about the general approach to
allowing Debian users to choose between systemd and elogind (and,
therefore, allowing them to run desktoppy kind of software without
systemd).  As discussed it seems that this C/R/P is needed to
implement the approach which was agreed between the elogind and
systemd maintainers.

I think that it is appropriate that, if possible, the approach taken
should be one that is agreeable to both sets of maintainers.  That
makes for the least interpersonal friction (and of course the
respective sets of maintainers are best placed to foresee issues and
judge the merits and (in)elegance of possible approaches).

So my starting point is that it doesn't seem to me to have been
particularly fruitful to reopen this decision via this bug in this
way.  But in any case, the decision has been discussed at some length
here.  It doesn't appear that other options are better.


The submitter was asked to state any specific concerns.  In response:

| So one thing I think we should ensure is we don't end up
| uninstalling systemd without an explicit user choice.

But, the maintainer reports results of experiments, in message #236,
which show that that is already the case.

| So I am not sure any changes are required in order to enforce explicit
| instruction before attempting removal of systemd.
|
| Is this sufficient?

There hasn't been a reply to that.


So I think all of the concrete issues or concerns raised here in this
bug have been either recorded more conveniently in other bugs, or
resolved - whether that resolution was by fixing bugs, or by verifying
that the posited misbehaviour does not occur.

It seems to me therefore that this bug ought to be closed.  Everything
in it has been dealt with, one way or another.

If there are any remaining particular, specific, issues or problems,
it would probably be most convenient if they were filed as individual
bugs.  That would let us get to grips with them properly.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

[Felix Lechner]

Hi,

I also committed another fix, which I found more appropriate after
discussing the issue with Moo's author. The commit message has more
details and is replicated below.

Also, please let us know if your chroot or cowbuilder environment had
libclass-xsaccessor-perl installed. (Note the XS in the name; there
are other similar packages in the archive.)


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

Kind regards,
Felix Lechner

* * *

Clarify boolean return value in Collect::Binary->is_pkg_class. (Closes: #943724)

According to Moo's author haarg, Moo optionally looks for
Class::XSAccessor,  which in turn requires a argument to be passed to a
writer.

The undef return value is interpreted as providing the wrong number of
arguments. Moo's behavior is documented here:

https://metacpan.org/pod/Moo#MOO-AND-CLASS::XSACCESSOR

The availability of Class::XSAccessor determines who sees the bug. The
module was probably installed automatically in the chroot and
cowbuilder environments that gave gise to the bug report.

This can be tested: The error also occurs in logrotate/3.15.1-1 in
Debian stable when libclass-xsaccessor-perl is installed.

Thank you to intrigeri for shedding light on the issue and for
putting forward this merge request:

https://salsa.debian.org/lintian/lintian/merge_requests/266

Contrary to the fix proposed there, which forces the value returned to
a scalar in the consuming package, this commit causes ->is_pkg_class
to return 0 instead of undef (which evaluates to an empty list in list
context).

The undef return value is interpreted as providing the wrong number of
arguments in the mechanics behind the accessor _set_is_dummy.

Thanks to ilmari on #perl-help for identifing the proper fix and for
explaining the issue.

As an aside, installing libclass-xsaccessor-perl has another effect in
Lintian. It causes the style tests for POD coverage to fail:

===(   15295;22  33/?  34/?  159/?  97/?  67/?   4/19  0/?  0/?
... )===#   Failed test 'Lintian::Lab is covered'
#   at t/scripts/pod-coverage.t line 52.
# Coverage for Lintian::Lab is 50.0%, with 2 naked subroutines:
#   basedir
#   keep
#   Failed test 'Lintian::Processable::Group is covered'
#   at t/scripts/pod-coverage.t line 52.
# Coverage for Lintian::Processable::Group is 66.7%, with 7 naked
subroutines:
#   binary
#   buildinfo
#   changes
#   lab
#   name
#   source
#   udeb
#   Failed test 'Lintian::Processable::Pool is covered'
#   at t/scripts/pod-coverage.t line 52.
# Coverage for Lintian::Processable::Pool is 66.7%, with 3 naked
subroutines:
#   groups
#   lab
#   unpacker
# Looks like you failed 3 tests of 19.
t/scripts/pod-coverage.t ... Dubious, test
returned 3 (wstat 768, 0x300)
Failed 3/19 subtests

The error that gave rise to the original bug report was:

Usage: Lintian::files::empty_package::_set_is_dummy(self,
newvalue) at /usr/share/lintian/checks/files/empty-package.pm line 42.
internal error: cannot run files check on package
binary:logrotate/3.15.1-1/amd64
warning: skipping check of binary:logrotate/3.15.1-1/amd64

Clarifies the boolean return type to avoid problems with Moo attribute
accessors.

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Ian Jackson]

Control: close -1

Hi.  I was asked to take a look at #940034 and ended up reading this
bug too.  According to message #191 here, from the maintainer,

 | I can no longer reproduce the breakage that you reported.

That this now works is a consequence of #935910 having been fixed by
apt in bullseye.

Mark wrote:
 | Are you satisfied that this bug can be closed?

So, I think this bug should be closed now, unless there is something
that remains to be done to improve things here.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#864079: Status of this bug?

[Axel Beckert]

Hi,

sixerjman wrote:
> I would like to know if anybody is working on this.

Yes, Jonathan Wiltshire (Cc'ed) pushed a packaging of it to
https://salsa.debian.org/debian/backuppc-rsync

We also had a small Debian-BackupPC-Team meeting at MiniDebConf
Vaumarcus last weekend.

Jonathan wrote, that he's also working on the BackupPC 4 packaging.
But he doesn't seem to have pushed it to Salsa yet.

I though couldn't reach him by mail or IRC recently. (Tried to reach
him twice in the past two weeks, also because of our small team
meeting.) I assume, he's currently on vacation or so.

At the small team meeting we decided to wait a little bit more for his
work on BackupPC.

But I assume that we probably won't do much double work if we check
now what's left for getting backuppc-rsync through the NEW queue.
Especially if it helps wrt. to automatic BinNMUs. Thanks for this
hint. It didn't come to me that this might be an issue.

Will work on this later on this week. Probably won't find time for it
today.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#931332: xserver-xorg-core: X crash on keyboard remapping

[Samuel Thibault]

Just for the record: the patch is commited in master for 1.21, and in
server-1.20-branch for 1.20.6.

Samuel

Bug#931488: Fixed upstream in jack2 1.9.13

[Joseph Yasi]

This was fixed upstream in jack2 1.9.13. Pushing a new release will
take care of this.

Bug#941018: ibus 1.5.21-1 does not work with qt5 applications

[Gunnar Hjalmarsson]

Thanks for your work with this, Simon!

Seeing that you included quite a few patches in this update, I have a 
question as regards the stable releases. Are the commits included in 
 a standalone 
set of commits which would be sufficient for patching the stable 
releases in order to fix the IBus/Qt issue? I'm asking with my Ubuntu 
glasses on at first hand (in Ubuntu 16.04 we have glib2.0 2.48...), but 
the question does reasonably apply to Debian too.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#943833: [src:x11vnc] Drop bundled libvncserver/libvncclient

[Mike Gabriel]

Package: src:x11vnc
Version: 0.9.13-6
Severity: wishlist

Dear maintainer(s) of x11vnc,

I am currently working on a security audit of all VNC related packages  
in Debian and identified packages that partially or completely bundle  
libvncserver and/or libvncclient. Esp. with VNC code, people have  
copy+pasted code fragments into various projects and now ship  
custom-patched and non-security-patched versions of those code files.


For x11vnc, I discovered that the libvncserver and libvncclient shared  
libraries are bundled in upstream's orig tarball, but not used at  
build time. If that is the case, could you please drop those two  
folders from x11vnc with one of the next uploads?


While this is not a functionality improvement, it helps with security  
audits. Please consider removing the libvncclient/ and libvncserver/  
folders from the x11vnc orig tarball. Thanks!


light+love
Mike Gabriel


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp7z0aeAB5kY.pgp
Description: Digitale PGP-Signatur

Bug#941738: buster-pu: package network-manager/1.14.6-2+deb10u1

[Michael Biebl]

retitle 941738 buster-pu: package network-manager/1.14.6-2+deb10u1
thanks

Am 04.10.19 um 15:20 schrieb Michael Biebl:
> Am 04.10.19 um 15:09 schrieb Michael Biebl:
>> +network-manager (1.14.6-3) stable; urgency=medium
> 
> 1.14.6-3 is unused so far, but I guess it would be better us use
> 1.14.6-2+deb10u1 instead?

I guess the latter is more in line with current practice, so retitling
the bug report accordingly. Updated debdiff attached.


Please let me know if I can proceed with the upload.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/debian/changelog b/debian/changelog
index 7cb171e5a..13658c1c3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+network-manager (1.14.6-2+deb10u1) stable; urgency=medium
+
+  * core: fix file permissions for "/var/lib/NetworkManager/secret_key"
+Patch cherry-picked from upstream.
+  * Fix permissions of /var/lib/NetworkManager/secret_key on upgrades.
+The file mode is supposed to be 0600. (Closes: #941609)
+  * Install directories as created by upstream build system.
+Drop network-manager.dirs and instead use the directories created by the
+upstream build system. Fix permissions of /var/lib/NetworkManager to be
+0700 as it contains possibly sensitive data and should not be
+world-readable.
+  * d/gbp.conf: Set debian-branch to buster
+
+ -- Michael Biebl   Fri, 04 Oct 2019 15:03:20 +0200
+
 network-manager (1.14.6-2) unstable; urgency=medium
 
   * supplicant: fix setting pmf when the supplicant doesn't advertise support
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 478d845ce..3c81df87a 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,4 @@
 [DEFAULT]
 pristine-tar = True
 patch-numbers = False
-debian-branch = master
+debian-branch = buster
diff --git a/debian/network-manager.dirs b/debian/network-manager.dirs
deleted file mode 100644
index e09403be4..0
--- a/debian/network-manager.dirs
+++ /dev/null
@@ -1,10 +0,0 @@
-etc/NetworkManager/conf.d/
-etc/NetworkManager/dispatcher.d/no-wait.d/
-etc/NetworkManager/dispatcher.d/pre-down.d/
-etc/NetworkManager/dispatcher.d/pre-up.d/
-etc/NetworkManager/dnsmasq.d/
-etc/NetworkManager/dnsmasq-shared.d/
-etc/NetworkManager/system-connections/
-usr/lib/NetworkManager/conf.d/
-usr/lib/NetworkManager/VPN/
-var/lib/NetworkManager/
diff --git a/debian/network-manager.install b/debian/network-manager.install
index 0f1e82ae5..3f94d7a46 100644
--- a/debian/network-manager.install
+++ b/debian/network-manager.install
@@ -2,10 +2,7 @@ usr/sbin/NetworkManager
 usr/bin/nm-online
 usr/bin/nmcli
 usr/bin/nmtui*
-usr/lib/NetworkManager/nm-dhcp-helper
-usr/lib/NetworkManager/nm-iface-helper
-usr/lib/NetworkManager/nm-dispatcher
-usr/lib/NetworkManager/nm-initrd-generator
+usr/lib/NetworkManager/
 usr/lib/*/NetworkManager/*/libnm-settings-plugin-ifupdown.so
 usr/lib/*/NetworkManager/*/libnm-device-plugin-*.so
 usr/lib/*/NetworkManager/*/libnm-ppp-plugin.so
@@ -18,7 +15,8 @@ usr/share/dbus-1/system.d/org.freedesktop.NetworkManager.conf
 usr/share/dbus-1/system.d/nm-dispatcher.conf
 usr/share/polkit-1/
 usr/share/bash-completion/
-etc/NetworkManager/dispatcher.d/
+etc/NetworkManager/
+var/lib/NetworkManager/
 lib/udev/rules.d/*.rules
 lib/systemd/system/NetworkManager.service
 lib/systemd/system/NetworkManager-dispatcher.service
diff --git a/debian/network-manager.postinst b/debian/network-manager.postinst
index 0f95087f8..7f0589da6 100644
--- a/debian/network-manager.postinst
+++ b/debian/network-manager.postinst
@@ -24,6 +24,9 @@ case "$1" in
 # org.freedesktop.NetworkManager.settings.modify.system without prior 
authentication
 addgroup --quiet --system netdev
 
+# This directory can contain sensitive data and should not be 
world-readable
+chmod 0700 /var/lib/NetworkManager
+
 NIF=/etc/network/interfaces
 if [ -z "$2" ] && [ -f $NIF ]; then
 ifaces=`grep -v '^#' $NIF | awk '/iface/ {print $2}' | sort -u | 
sed -e 's/lo//' -e '/^$/d' -e 's/^/- /'`
@@ -44,6 +47,12 @@ case "$1" in
 ln -sf  /run/NetworkManager/resolv.conf /etc/resolv.conf
 fi
 fi
+
+if dpkg --compare-versions "$2" lt-nl "1.14.6-3"; then
+if [ -f /var/lib/NetworkManager/secret_key ]; then
+chmod 0600 /var/lib/NetworkManager/secret_key
+fi
+fi
 ;;
 
 abort-upgrade|abort-deconfigure|abort-remove)
diff --git 
a/debian/patches/core-fix-file-permissions-for-var-lib-NetworkManager-secr.patch
 
b/debian/patches/core-fix-file-permissions-for-var-lib-NetworkManager-secr.patch
new file mode 100644
index 0..8e51fa6a4
--- /dev/null
+++ 
b/debian/patches/core-fix-file-permissions-for-var-lib-NetworkManager-secr.patch
@@ -0,0 +1,40 @@
+From: Thomas Haller 
+Date: Tue, 14 May 2019 13:55:41 +0200
+Subject: core: fix file permissions for "/var/lib/NetworkManager/sec

Bug#943834: 404 error on https://piuparts.d.o/doc/ files

[Santiago R.R.]

Package: piuparts.debian.org
Severity: normal

Different doc-related links seem to be broken:
https://piuparts.debian.org/doc/README.html
https://piuparts.debian.org/doc/piuparts.1.html
http://piuparts.debian.org/doc/README_server.html

Referer to those URLs are https://piuparts.debian.org/
and https://wiki.debian.org/piuparts/piuparts.debian.org

I cannot say if the solution would be to fix those links to point
somewhere else, or to provide piuparts.d.o/doc/

Cheers,

 -- Santiago

Bug#943836: dependency on python-all-dev?

[Matthias Klose]

Package: src:claws-mail
Version: 3.17.4-1

claws-mail-python-plugin depends on python-all-dev, why a dev package, why all? 
I think python2 would be the right dependency here.

Bug#943835: kwartz-client: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: kwartz-client
Version: 1.1-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for kwartz-client's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-

kwartz-client_1.1-1_pt.po.gz
Description: application/gzip

Bug#943837: viewnior: Version 1.7 available upstream

[Simon]

Package: viewnior
Version: 1.6-1+b1
Severity: normal

Dear Maintainer,

Version 1.7 is available upstream but Debian repositories still host version
1.6. Can you please update the package?
Thanks.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (450, 'testing'), (400, 'unstable'), (350, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages viewnior depends on:
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libexiv2-14  0.25-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgcc1  1:9.2.1-8
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libglib2.0-0 2.62.2-1
ii  libgtk2.0-0  2.24.32-4
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libstdc++6   9.2.1-8

viewnior recommends no packages.

viewnior suggests no packages.

-- no debconf information

Bug#940186: [texlive-latex-recommended] Newfloat conflicts wrapfig and rotating

[Hilmar Preuße]

Am 13.09.2019 um 18:13 teilte Спицын Андрей mit:

Hi,

> --- Please enter the report below this line. ---
> Newfloat conflicts with wrapfig and rotating packages. See upstream issues
> https://gitlab.com/axelsommerfeldt/caption/issues/60
> https://gitlab.com/axelsommerfeldt/caption/issues/61
> 
> Upstream patch is available.
> 
Is that solves in latest upload (made today)?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#864079: Thank you for the update

[sixerjman]

Thanks for continuing to stay on top of this. I realize it is kind of
complicated with the split out
of the BackupPC software into 3 clients with shifting dependencies, but
next to the operating
system and attendant major subsystems (i.e. networking), the backup
software is the most important subsystem
IMO. As upstream BackupPC continues to release bug fix / enhancement
updates, it is a priority to
continue to track it closely. Again, thank you for your work and attention
to this matter.

Bug#943839: cockpit: New version available (205)

[jim_p]

Package: cockpit
Severity: normal
Tags: upstream

Dear Maintainer,

There has been a new version available from upstream since mid October.
https://cockpit-project.org/blog/cockpit-205.html

Please update the package in the repo. Cockpit on debian usually gets updated
the day it is released from upstream.



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

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

Versions of packages cockpit depends on:
pn  cockpit-bridge  
pn  cockpit-system  
pn  cockpit-ws  

Versions of packages cockpit recommends:
pn  cockpit-dashboard   
pn  cockpit-networkmanager  
pn  cockpit-packagekit  
pn  cockpit-storaged

Versions of packages cockpit suggests:
pn  cockpit-doc   
pn  cockpit-docker
pn  cockpit-machines  
pn  cockpit-pcp   
ii  xdg-utils 1.1.3-1

Bug#923009: fixed 923009 seafile/7.0.2-1

[Salvatore Bonaccorso]

Hi Moritz,

On Wed, Oct 30, 2019 at 11:27:34AM +0100, Moritz Schlarb wrote:
> fixed 923009 seafile/7.0.2-1

I guess I have lost some context here. Can you clarify the following
before I proceed to mark the fixed version for the CVE as well in the
security-tracker?

The question is following: 923009, respective CVE-2013-7469 is
associated with upstream issue
https://github.com/haiwen/seafile/issues/350 . But there ws o closure
of this issue. In the previous BTS message you mentioned that the CVE
assignment was inaccurate, is the issue fixed with the new 0003 patch?

Were you able to reach out to MITRE (via the webform) to have the
references and description updated?

Regards,
Salvatore

Bug#943838: grml2usb: check_for_fat() always fails

[Sven Joachim]

Package: grml2usb
Version: 0.16.7
Severity: grave

The check_for_fat() function always fails, no matter what:

,
| # file -s /dev/sdc2
| /dev/sdc2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", 
sectors/cluster 64, reserved sectors 64, root entries 1024, Media descriptor 
0xf8, sectors/FAT 256, sectors/track 32, heads 64, hidden sectors 27265024, 
sectors 3512319 (volumes > 32 MB), serial number 0xadbb, unlabeled, FAT (16 
bit)
| # sudo grml2usb grml96-full_2018.12.iso /dev/sdc2
| Executing grml2usb version 0.16.7
| Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
(Use --fat16 or run mkfs.vfat /dev/sdc2)
| # grml2usb --fat16 grml96-full_2018.12.iso /dev/sdc2
| Executing grml2usb version 0.16.7
| Are you sure you want to format the specified partition with fat16? y/N y
| Note: you can skip this question using the option --force
| Formating partition with fat16 filesystem
| mkfs.fat 4.1 (2017-01-24)
| Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
(Use --fat16 or run mkfs.vfat /dev/sdc2)
`

I am not really a Python expert, but AFAICS the problem is that by
default Subprocess.open() opens file objects in binary mode, so the
"filesystem" variable is an array of bytes, and comparing it to a string
always yields false.


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

Kernel: Linux 5.3.8-nouveau (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 grml2usb depends on:
ii  grub-pc-bin 2.04-3
ii  grub2-common2.04-3
ii  kmod26-3
ii  mtools  4.0.23-1+b1
ii  python3 3.7.5-1
ii  python3-parted  3.11.2-11
ii  rsync   3.1.3-8
ii  syslinux3:6.04~git20190206.bf6db5b4+dfsg1-1

Versions of packages grml2usb recommends:
ii  genisoimage 9:1.1.11-3+b2
ii  syslinux3:6.04~git20190206.bf6db5b4+dfsg1-1
pn  syslinux-utils  

grml2usb suggests no packages.

-- no debconf information

Bug#936307: claws-mail: Python2 removal in sid/bullseye

[Matthias Klose]

Control: tags -1 + moreinfo

The python-gtk2 dependency has an RC issue now. https://bugs.debian.org/937452
It looks like nobody wants to step up to maintain that. What are you planning 
to do?

Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

[Matthias Klose]

On 27.10.19 17:59, Neil Williams wrote:

Package: python3
Version: 3.7.5-1
Severity: normal

As discussed on IRC and alongside the post to debian-devel-announce, please
review and include this amendment to the Debian Python Policy to cover
the removal of the Python 2 stack as outlined at 
https://wiki.debian.org/Python/2Removal


thanks for doing that.  I think we should make it more clear that there will no 
python binary package, and no python command in bullseye.  You adjusted the 
names, but are still talking about "should" in some place.  If we end up with 
some remaining python 2 packages, then these must depend on python2, 
python2-dbg, and must use the python2 command.

Bug#943841: desktopnova: Depends on gconf

[Yavor Doganov]

Source: desktopnova
Version: 0.8.1-1.2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid bullseye patch

This package build-depends on libgconf2-dev and src:gconf2 will be
removed from Debian soon.

Attached is a patch to move away from GConf, using the same approach
as done with the gnome-shell module.  It is probably a good idea to
update the package description and mention that MATE is also
supported.
Description: Move away from GConf.
Author: Yavor Doganov 
Forwarded: no
Last-Update: 2019-10-30
---

--- desktopnova-0.8.1.orig/src/modules/CMakeLists.txt
+++ desktopnova-0.8.1/src/modules/CMakeLists.txt
@@ -7,7 +7,7 @@
SET_TARGET_PROPERTIES(desktopnova-module-gnome
  PROPERTIES PREFIX ""
 OUTPUT_NAME module_gnome)
-   TARGET_LINK_LIBRARIES(desktopnova-module-gnome ${GCONF2_LIBRARIES})
+   TARGET_LINK_LIBRARIES(desktopnova-module-gnome ${DCONF_LIBRARIES})
SET(TARGETS ${TARGETS} desktopnova-module-gnome)
 ENDIF(ENABLE_MODULE_GNOME)
 
--- desktopnova-0.8.1.orig/src/modules/module_gnome.c
+++ desktopnova-0.8.1/src/modules/module_gnome.c
@@ -16,7 +16,7 @@
 */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -59,14 +59,14 @@
 
 void module_change_wallpaper(const gchar * filename)
 {
-   GConfClient * gconf_client = gconf_client_get_default();
-   if (gconf_client != NULL)
+   DConfClient * client = dconf_client_new();
+   if (dconf_client_is_writable(client, 
"/org/mate/desktop/background/picture-filename"))
{
-   gconf_client_set_string(gconf_client,
-   
"/desktop/gnome/background/picture_filename",
-   filename, NULL);
-   g_object_unref(gconf_client);
+   GVariant *value = g_variant_new("s", filename);
+   if (!dconf_client_write_sync(client, 
"/org/mate/desktop/background/picture-filename", value, NULL, NULL, NULL))
+   g_critical("gnome-module: Failed to set background to 
\"%s\"", filename);
}
+   g_object_unref(client);
 }
 
 #undef _
--- desktopnova-0.8.1.orig/CMakeLists.txt
+++ desktopnova-0.8.1/CMakeLists.txt
@@ -77,9 +77,6 @@
 IF(ENABLE_DBUS)
PKG_CHECK_MODULES(GTHREAD2 REQUIRED gthread-2.0)
 ENDIF(ENABLE_DBUS)
-IF(ENABLE_MODULE_GNOME)
-   PKG_CHECK_MODULES(GCONF2 REQUIRED gconf-2.0)
-ENDIF(ENABLE_MODULE_GNOME)
 IF(ENABLE_MODULE_XFCE_XFCONF)
PKG_CHECK_MODULES(XFCONF REQUIRED libxfconf-0)
 ENDIF(ENABLE_MODULE_XFCE_XFCONF)

Bug#937452: Bug#936307: claws-mail: Python2 removal in sid/bullseye

[Matthias Klose]

On 30.10.19 17:41, Matthias Klose wrote:

Control: tags -1 - moreinfo
Control: severity -1 serious

No need for more info. According to
https://lists.debian.org/debian-gtk-gnome/2019/10/msg1.html
pygtk will be removed in bullseye.


that last email went to the wrong bug report, but no harm done. Just wanted to 
add the link to https://lists.debian.org/debian-gtk-gnome/2019/10/msg1.html

Bug#943840: python3-rrdtool-dbg: missing Breaks+Replaces: rrdtool-dbg

[Andreas Beckmann]

Package: python3-rrdtool-dbg
Version: 1.7.2-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-rrdtool-dbg_1.7.2-2_amd64.deb ...
  Unpacking python3-rrdtool-dbg:amd64 (1.7.2-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-rrdtool-dbg_1.7.2-2_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/python3/dist-packages/rrdtool.cpython-37dm-x86_64-linux-gnu.so', 
which is also in package rrdtool-dbg:amd64 1.7.2-1+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-rrdtool-dbg_1.7.2-2_amd64.deb


cheers,

Andreas


rrdtool-dbg=1.7.2-1+b1_python3-rrdtool-dbg=1.7.2-2.log.gz
Description: application/gzip

Bug#936307: claws-mail: Python2 removal in sid/bullseye

[Matthias Klose]

Control: tags -1 - moreinfo
Control: severity -1 serious

No need for more info. According to
https://lists.debian.org/debian-gtk-gnome/2019/10/msg1.html
pygtk will be removed in bullseye.

Bug#943838: grml2usb: check_for_fat() always fails

[Sven Joachim]

Control: tags -1 + patch
Control: forwarded -1 https://github.com/grml/grml2usb/pull/24

On 2019-10-30 17:09 +0100, Sven Joachim wrote:

> Package: grml2usb
> Version: 0.16.7
> Severity: grave
>
> The check_for_fat() function always fails, no matter what:
>
> ,
> | # file -s /dev/sdc2
> | /dev/sdc2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID
> | "mkfs.fat", sectors/cluster 64, reserved sectors 64, root entries
> | 1024, Media descriptor 0xf8, sectors/FAT 256, sectors/track 32,
> | heads 64, hidden sectors 27265024, sectors 3512319 (volumes > 32
> | MB), serial number 0xadbb, unlabeled, FAT (16 bit)
> | # sudo grml2usb grml96-full_2018.12.iso /dev/sdc2
> | Executing grml2usb version 0.16.7
> | Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
> (Use --fat16 or run mkfs.vfat /dev/sdc2)
> | # grml2usb --fat16 grml96-full_2018.12.iso /dev/sdc2
> | Executing grml2usb version 0.16.7
> | Are you sure you want to format the specified partition with fat16? y/N y
> | Note: you can skip this question using the option --force
> | Formating partition with fat16 filesystem
> | mkfs.fat 4.1 (2017-01-24)
> | Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
> (Use --fat16 or run mkfs.vfat /dev/sdc2)
> `
>
> I am not really a Python expert, but AFAICS the problem is that by
> default Subprocess.open() opens file objects in binary mode, so the
> "filesystem" variable is an array of bytes, and comparing it to a string
> always yields false.

So that was indeed the case, but after fixing it I immediately ran into
another "strings vs bytes" problem in check_boot_flag().  Fortunately
that was the last issue, and now I have a USB stick with GRML on it. :-)
Have not tested whether it actually boots yet, though.

I have sent a pull request on GitHub.

Cheers,
   Sven

Bug#937452: Bug#936307: claws-mail: Python2 removal in sid/bullseye

[Matthias Klose]

Control: tags -1 - moreinfo
Control: severity -1 serious

No need for more info. According to
https://lists.debian.org/debian-gtk-gnome/2019/10/msg1.html
pygtk will be removed in bullseye.

Bug#943842: RFS: notepadqq/2.0.0~beta1-1 [ITP] -- Notepad++-like editor for Linux

[Alessandro Grassi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "notepadqq"

 * Package name: notepadqq
   Version : 2.0.0~beta1-1
   Upstream Author : Daniele Di Sarli 
 * URL : http://notepadqq.altervista.org
 * License : GPL-3+
 * Vcs : https://github.com/notepadqq/notepadqq
   Section : editors

It builds those binary packages:

  notepadqq - Notepad++-like editor for Linux

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/notepadqq

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/n/notepadqq/notepadqq_2.0.0~beta1-1.dsc

Changes since the last upload:

   [ Alessandro Grassi ]
   * Initial release. Closes: #740809

Regards,

--
  Alessandro Grassi

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Michael Biebl]

On Wed, 30 Oct 2019 13:22:14 + Ian Jackson
 wrote:

> The bulk of the bug is a discussion about the general approach to
> allowing Debian users to choose between systemd and elogind (and,
> therefore, allowing them to run desktoppy kind of software without
> systemd).  As discussed it seems that this C/R/P is needed to
> implement the approach which was agreed between the elogind and
> systemd maintainers.


I very much disagree with this summary.

In [1] I clearly expressed that I did not like this approach of having a
libelogind0 which replaces libsystemd0.

My feedback was ignored though, at which point I stopped engaging further.

And since the fallout from the decision to go with this approach
(despite my recommendation not to) was so tiresome and caused so much
friction, this will most likely be my only message regarding this topic.


> I think that it is appropriate that, if possible, the approach taken
> should be one that is agreeable to both sets of maintainers.  That
> makes for the least interpersonal friction (and of course the
> respective sets of maintainers are best placed to foresee issues and
> judge the merits and (in)elegance of possible approaches).
> 
> So my starting point is that it doesn't seem to me to have been
> particularly fruitful to reopen this decision via this bug in this
> way.  But in any case, the decision has been discussed at some length
> here.  It doesn't appear that other options are better.

I think the best option is still the one I outlined in [1], i.e. getting
rid of libelogind0 completely in Debian and simply ensure that elogind
works in combination with libsystemd0.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923244#10
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#926191: zlib1g-dbg: please mark zlib1g-dbg as Multi-Arch: same

[Witold Baryluk]

Package: zlib1g-dbg
Version: 1:1.2.11.dfsg-1+b1
Followup-For: Bug #926191

Any update on this?

It still is buggy:

$ sudo apt-get install -V zlib1g-dbg:amd64 zlib1g-dbg:i386
Reading package lists... Done
Building dependency tree   
Reading state information... Done
zlib1g-dbg is already the newest version (1:1.2.11.dfsg-1+b1).
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:
 zlib1g-dbg : Conflicts: zlib1g-dbg:i386 but 1:1.2.11.dfsg-1+b1 is to be 
installed
 zlib1g-dbg:i386 : Conflicts: zlib1g-dbg but 1:1.2.11.dfsg-1+b1 is to be 
installed
E: Unable to correct problems, you have held broken packages.
$


I wish zlib migrated to automatic debug packages with `-dbgsym` support
too.

I do need both 32-bit and 64-bit debug packages, as I am debugging some
Mesa issues.

Thanks.




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

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

Versions of packages zlib1g-dbg depends on:
ii  zlib1g  1:1.2.11.dfsg-1+b1

zlib1g-dbg recommends no packages.

zlib1g-dbg suggests no packages.

-- no debconf information

Bug#943843: mailutils-doc: missing Breaks+Replaces: mailutils (<< 1:3.7)

[Andreas Beckmann]

Package: mailutils-doc
Version: 1:3.7-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../mailutils-doc_1%3a3.7-1_all.deb ...
  Unpacking mailutils-doc (1:3.7-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/mailutils-doc_1%3a3.7-1_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/mailutils/AUTHORS', which is also in 
package mailutils 1:3.5-3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/mailutils-doc_1%3a3.7-1_all.deb


cheers,

Andreas


mailutils=1:3.5-3_mailutils-doc=1:3.7-1.log.gz
Description: application/gzip

Bug#943595: virtualbox-guest-additions-iso: New upstream version available: 6.0.14

[Holger Schröder]

I also wonder why the additions are no longer up to date. It's been that
way at 6.0.12, too.

...

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

> "Michael" == Michael Biebl  writes:

Michael> On Wed, 30 Oct 2019 13:22:14 + Ian Jackson
Michael>  wrote:

>> The bulk of the bug is a discussion about the general approach to
>> allowing Debian users to choose between systemd and elogind (and,
>> therefore, allowing them to run desktoppy kind of software
>> without systemd).  As discussed it seems that this C/R/P is
>> needed to implement the approach which was agreed between the
>> elogind and systemd maintainers.


Michael> I very much disagree with this summary.

Michael> In [1] I clearly expressed that I did not like this
Michael> approach of having a libelogind0 which replaces
Michael> libsystemd0.

That's actually not how I read that discussion.

I read you as grumblingly accepting the necessity of libelogind0 after
Mark explained that it was necessary because of the upstream design.

I suspect I'm not the only one who honestly read what you said as
accepting elogind0 even though it was not your preference.
Michael> I think the best option is still the one I outlined in [1],
Michael> i.e. getting rid of libelogind0 completely in Debian and
Michael> simply ensure that elogind works in combination with
Michael> libsystemd0.

That's inconsistent with the design of elogind.
Mark explored doing that in this bug and outlined why that doesn't work.

Summarizing for those less familiar with libsystemd0 than Michael:
libsystemd0 splits its interface to systemd across a number of things.
A lot of it is in a dbus API.
However, it also assumes a certain structure of how cgroups are layed
out.

Elogind does implement the dbus APIs in question.
However elogind lays out cgroups differently.
So key functionality does not actually work if you use libsystemd0 iwth
elogind.
Asking the Debian elogind maintainer to redesign elogind seems like kind
of a tall ask.

I agree that using libsystemd0 only would be a great option *if it
worked*

Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

[Daniel James]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1
Severity: important
File: nouveau

Dear Maintainer,

[Message prepared by reportbug 7.5.3-de10u1 but mailed from Thunderbird 
on a different system]


In Debian 10 "Buster" the Nouveau driver does not start correctly unless 
the "nomodeset" kernel parameter is supplied.


Without "nomodeset" the system boots to a full-screen graphical login 
screen. Login credentials can be entered, but the screen then flashes 
off (black) for a fraction of a second and returns to the login dialog.


With "nomodeset" Debian starts but the screen resolution is not optimal, 
and cannot be changed. The system boots to a graphical login screen with 
the edges black -- apparently a 1280x1024 displayed full-height but 
narrower than the screen. When login credentials are entered the system 
boots but still only shows a 1280x1024 desktop. Attempts to change the 
resolution (e.g. using xrandr to add a new mode and switch to it fail).


The system uses an Asus M2NPV-VM motherboard with NForce 430 chipset and 
GeForce 61500 onboard graphics. The monitor is a Dell U2410 which has a 
native resolution of 1920x1200 pixels.


On Debian 9 "Stretch" it was not necessary to specify "nomodeset", and 
the full screen resolution was used.


This bug report is being prepared from a text console after booting 
WITHOUT "nomodeset". The errors ("EE") at 45.875 seem to be crucial. I 
have compared /var/log/Xorg.0.log files from this system when booting 
Buster and when booting Stretch, and (apart from minor details like 
module version numbers and the time field) the logs are identical up to 
this point.



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

VGA-compatible devices on PCI bus:
--
00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51PV 
[GeForce 6150] [10de:0240] (rev a2)


/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc 
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)


Xorg X server log files on system:
--
-rw-r--r-- 1 daniel daniel 33547 Oct 13 15:34 
/home/daniel/.local/share/xorg/Xorg.0.log

-rw-r--r-- 1 root   root   26008 Oct 29 16:57 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[45.542]
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[45.542] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[45.542] Current Operating System: Linux welly-buster 4.19.0-6-amd64 
#1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64
[45.542] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-6-amd64 
root=UUID=4abd25ab-9425-42ee-8612-75c0164d13d5 ro noapic

[45.542] Build Date: 05 March 2019  08:11:12PM
[45.542] xorg-server 2:1.20.4-1 (https://www.debian.org/support)
[45.542] Current version of pixman: 0.36.0
[45.542]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[45.542] Markers: (--) probed, (**) from config file, (==) default 
setting,

(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[45.543] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Oct 29 
16:57:10 2019

[45.543] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[45.543] (==) No Layout section.  Using the first Screen section.
[45.543] (==) No screen section available. Using defaults.
[45.543] (**) |-->Screen "Default Screen Section" (0)
[45.543] (**) |   |-->Monitor ""
[45.544] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[45.544] (==) Automatically adding devices
[45.544] (==) Automatically enabling devices
[45.544] (==) Automatically adding GPU devices
[45.544] (==) Max clients allowed: 256, resource mask: 0x1f
[45.545] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
exist.

[45.545]Entry deleted from font path.
[45.545] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[45.545] (==) ModulePath set to "/usr/lib/xorg/modules"
[45.545] (II) The server relies on udev to provide the list of input 
devices.

If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[45.545] (II) Loader magic: 0x562deaa57e20
[45.545] (II) Module ABI vers

Bug#941018: ibus 1.5.21-1 does not work with qt5 applications

[Simon McVittie]

On Wed, 30 Oct 2019 at 15:45:19 +0100, Gunnar Hjalmarsson wrote:
> Seeing that you included quite a few patches in this update, I have a
> question as regards the stable releases. Are the commits included in
>  a standalone set
> of commits which would be sufficient for patching the stable releases in
> order to fix the IBus/Qt issue? I'm asking with my Ubuntu glasses on at
> first hand (in Ubuntu 16.04 we have glib2.0 2.48...), but the question does
> reasonably apply to Debian too.

I was hoping to let glib2.0 get some testing in unstable before
backporting anything. A build of GLib with amd64, i386, build-time tests,
autopkgtest and piuparts takes about an hour, and I have to do my actual
job as well, so I can't iterate on this particularly rapidly.

How do the security team want to handle this - as a stable update, or
as a DSA? It isn't a security fix in its own right, but it fixes what
is effectively a regression triggered by fixing CVE-2019-14822 in ibus
(#940267, DSA-4525-1).

The functionally important patches for this particular bug are:

* d/p/credentials-Invalid-Linux-struct-ucred-means-no-informati.patch
* d/p/GDBus-prefer-getsockopt-style-credentials-passing-APIs.patch

The first of those might need minor adjustment to apply in the absence
of d/p/gcredentialsprivate-Document-the-various-private-macros.patch, or
we could just apply that one too - it only adds documentation.

The test in d/p/Add-a-test-for-GDBusServer-authentication.patch would
be reassuring to have, but it is known to fail on non-Linux kernels
(a fix is pending review upstream and included in the 2.62.2-2 Debian
package), and might depend on other, less critical GDBus fixes. For what
it's worth, upstream didn't include it in the initial backport of !1176
to the 2.62.x branch.

smcv

Bug#895649: inkscape: Segfault closing dialog after importing PDF

[Omari Stephens]

I just ran into (and resolved) this.  It appears to be a packaging / 
dynamic-linking problem.  Fundamentally, it seems that inkscape is not 
compatible with having multiple versions of libpoppler present and 
usable.  This also explains why this issue is so consistent for the 
people who encounter it, but never occurs for the people who don't 
encounter it.


My first thought, on seeing the ldd output in this bug, was "isn't it 
weird that inkscape is picking up two different versions of the same 
library?"  This turned out to be the fundamental issue.


My ldd output looked like this when I was experiencing the crash:
$ldd /usr/bin/inkscape | grep poppler
    libpoppler.so.82 => /usr/lib/x86_64-linux-gnu/libpoppler.so.82 
(0x7f09b1c4b000)
    libpoppler-glib.so.8 => 
/usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 (0x7f09b19ef000)
    libpoppler.so.72 => /usr/lib/x86_64-linux-gnu/libpoppler.so.72 
(0x7f09a8e74000)


I then checked to see which versions of libpoppler were installed.  It 
was a whole bunch of them:

15:20:51> [xsdg{angular}@/usr/lib/x86_64-linux-gnu]
$dpkg -S libpoppler*
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0
libpoppler-cpp-dev:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.3.0
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.3.0
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.3.0
libpoppler-glib-dev: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8.9.0
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8.9.0
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8.9.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68.0.0
libpoppler-dev:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72.0.0
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82.0.0
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74.0.0
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64.0.0
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64.0.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68.0.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68.0.0
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72.0.0
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72.0.0
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74.0.0
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74.0.0
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80.0.0
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82.0.0

I uninstalled all of the deprecated versions and upgraded to the latest:
(excerpt from /var/log/aptitude):
[REMOVE (PURGE)] libpoppler64:amd64 0.48.0-2
[REMOVE (PURGE)] libpoppler68:amd64 0.57.0-2
[REMOVE (PURGE)] libpoppler72:amd64 0.61.1-2
[REMOVE (PURGE)] libpoppler73:amd64 0.62.0-2
[REMOVE (PURGE)] libpoppler74:amd64 0.63.0-2
[REMOVE (PURGE)] libpoppler80:amd64 0.69.0-2
[UPGRADE] gir1.2-poppler-0.18:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-cpp-dev:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-cpp0v5:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-dev:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-glib-dev:amd64 0.61.1-2 -> 0.71.0-6
[UPGRAD

Bug#943845: syslinux-common: error messages with grml boot stick

[Sven Joachim]

Package: syslinux-common
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-1
Severity: important

Today I built myself a USB stick with grml on it (see #943838 for the
problems I had with that).  When booting an old 32-bit laptop with this
stick syslinux threw some error messages before its prompt:

,
| Undef symbol FAIL: x86_init_fpu
| Failed to load libcom32.c32
| Failed to load COM32 file vesamenu.c32
| boot:
`

There was supposed to be a nice boot menu, but since vesamenu.c32 failed
to load it was not displayed.  TAB completion at the boot prompt and
actually booting worked, though.

This may be related to #918915, although that bug is already archived.


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

Kernel: Linux 5.3.8-nouveau (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)

-- no debconf information

Bug#942789: libbio-{db-{biofetch,gff,seqfeature},searchio-hmmer,tools-run-remoteblast}-perl: missing Breaks+Replaces: libbio-perl-perl (<< 1.7.3)

[Andreas Beckmann]

Followup-For: Bug #942789

There are some more related Breaks+Replaces needed:

  Unpacking libbio-db-gff-perl (1.7.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libbio-db-gff-perl_1.7.3-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/bp_bulk_load_gff', which is also in package 
bioperl 1.7.2-3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

  Preparing to unpack .../libbio-db-seqfeature-perl_1.7.3-1_all.deb ...
  Unpacking libbio-db-seqfeature-perl (1.7.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libbio-db-seqfeature-perl_1.7.3-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/bp_seqfeature_delete', which is also in 
package bioperl 1.7.2-3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

i.e. both libbio-db-gff-perl and libbio-db-seqfeature-perl need
an additional Breaks+Replaces: bioperl (<< 1.7.3)


Andreas

Bug#942803: No Sound HDMI with linux-image-5.3.0-1-amd64

[Gustavo Castro]

Dear Maintainer,

I have no sound on the HDMI output, and the speekers run out of sound when
entering the laptop in screen protection mode

lspci -k
00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series
SoC Transaction Register (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx
Series SoC Transaction Register
Kernel driver in use: iosf_mbi_pci
00:02.0 VGA compatible controller: Intel Corporation Atom Processor
Z36xxx/Z37xxx Series Graphics & Display (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx
Series Graphics & Display
Kernel driver in use: i915
Kernel modules: i915
00:13.0 SATA controller: Intel Corporation Atom Processor E3800 Series SATA
AHCI Controller (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor E3800 Series SATA
AHCI Controller
Kernel driver in use: ahci
Kernel modules: ahci
00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx,
Celeron N2000 Series USB xHCI (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx,
Celeron N2000 Series USB xHCI
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
00:1a.0 Encryption controller: Intel Corporation Atom Processor
Z36xxx/Z37xxx Series Trusted Execution Engine (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx
Series Trusted Execution Engine
00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx Series
High Definition Audio Controller (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx
Series High Definition Audio Controller
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI
Express Root Port 1 (rev 0e)
Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI
Express Root Port 2 (rev 0e)
Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI
Express Root Port 4 (rev 0e)
Kernel driver in use: pcieport
00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series
Power Control Unit (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx
Series Power Control Unit
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.3 SMBus: Intel Corporation Atom Processor E3800 Series SMBus
Controller (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor E3800 Series SMBus
Controller
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network
Adapter (rev 01)
Subsystem: AzureWave AW-NE186H
Kernel driver in use: ath9k
Kernel modules: ath9k
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5286
PCI Express Card Reader (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. RTS5286 PCI Express Card
Reader
Kernel driver in use: rtsx_pci
Kernel modules: rtsx_pci
03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI
Express Fast Ethernet controller (rev 06)
Subsystem: ASUSTeK Computer Inc. RTL810xE PCI Express Fast Ethernet
controller
Kernel driver in use: r8169
Kernel modules: r8169

aplay -l
 List of PLAYBACK Hardware Devices 
card 0: PCH [HDA Intel PCH], device 0: ALC270 Analog [ALC270 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: Generic Digital [Generic Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

lsmod | grep snd
snd_hda_codec_realtek   126976  1
snd_hda_codec_generic94208  2 snd_hda_codec_realtek
ledtrig_audio  16384  2 snd_hda_codec_generic,snd_hda_codec_realtek
snd_hda_intel  49152  2
snd_hda_codec 159744  3
snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_realtek
snd_hda_core  102400  4
snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_hwdep  16384  1 snd_hda_codec
snd_pcm   118784  3 snd_hda_intel,snd_hda_codec,snd_hda_core
snd_timer  40960  1 snd_pcm
snd98304  11
snd_hda_codec_generic,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
soundcore  16384  1 snd

add the file / etc / modprobe.d / snd-hda-intel.conf with the
following statement and the problem was not resolved

options snd-hda-intel model=asus-laptop

regards

Bug#943846: buster-pu: package python-cryptography/2.6.1-3+deb10u2

[Moritz Muehlenhoff]

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

(This is a followup update on top of the +deb10u1 already in s-p-u,
I've reached out to Tristan beforehand)

Attached debdiff fixes a memory leak in python-cryptography, which
was noticed in an ACME-related service 
(https://wikitech.wikimedia.org/wiki/Acme-chief)
running on Buster. It has been verified that the updated packages
fix the memory leak (and are otherwise working fine as well).

Debdiff below.

Cheers,
Moritz

diff -Nru python-cryptography-2.6.1/debian/changelog 
python-cryptography-2.6.1/debian/changelog
--- python-cryptography-2.6.1/debian/changelog  2019-09-30 20:55:00.0 
+0200
+++ python-cryptography-2.6.1/debian/changelog  2019-10-18 16:08:59.0 
+0200
@@ -1,3 +1,13 @@
+python-cryptography (2.6.1-3+deb10u2) buster; urgency=medium
+
+  * Cherrypick 92241410b5b0591d849443b3023992334a4be0a2 and
+9a22851fab924fd58482fdad3f8dd23dc3987f91 from upstream which
+addresses a memory leak triggerable when parsing x509
+certificate extensions like AIA, thanks to Valentin
+Gutierrez for the report (Closes: #941413)
+
+ -- Moritz Mühlenhoff   Fri, 18 Oct 2019 16:08:59 +0200
+
 python-cryptography (2.6.1-3+deb10u1) buster; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch 
python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch
--- python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch
1970-01-01 01:00:00.0 +0100
+++ python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch
2019-10-18 16:08:35.0 +0200
@@ -0,0 +1,94 @@
+From 92241410b5b0591d849443b3023992334a4be0a2 Mon Sep 17 00:00:00 2001
+From: Paul Kehrer 
+Date: Thu, 11 Apr 2019 20:57:13 +0800
+Subject: [PATCH] fix a memory leak in AIA parsing (#4836)
+
+* fix a memory leak in AIA parsing
+
+* oops can't remove that
+---
+ src/_cffi_src/openssl/x509v3.py   |  3 +++
+ .../hazmat/backends/openssl/decode_asn1.py|  9 +++-
+ tests/hazmat/backends/test_openssl_memleak.py | 21 ++-
+ 3 files changed, 31 insertions(+), 2 deletions(-)
+
+diff --git a/src/_cffi_src/openssl/x509v3.py b/src/_cffi_src/openssl/x509v3.py
+index 193d2e233b..5968120652 100644
+--- a/src/_cffi_src/openssl/x509v3.py
 b/src/_cffi_src/openssl/x509v3.py
+@@ -177,6 +177,7 @@
+ typedef void (*sk_GENERAL_NAME_freefunc)(GENERAL_NAME *);
+ typedef void (*sk_DIST_POINT_freefunc)(DIST_POINT *);
+ typedef void (*sk_POLICYINFO_freefunc)(POLICYINFO *);
++typedef void (*sk_ACCESS_DESCRIPTION_freefunc)(ACCESS_DESCRIPTION *);
+ """
+ 
+ 
+@@ -228,6 +229,8 @@
+ Cryptography_STACK_OF_ACCESS_DESCRIPTION *, int
+ );
+ void sk_ACCESS_DESCRIPTION_free(Cryptography_STACK_OF_ACCESS_DESCRIPTION *);
++void sk_ACCESS_DESCRIPTION_pop_free(Cryptography_STACK_OF_ACCESS_DESCRIPTION 
*,
++  sk_ACCESS_DESCRIPTION_freefunc);
+ int sk_ACCESS_DESCRIPTION_push(Cryptography_STACK_OF_ACCESS_DESCRIPTION *,
+ACCESS_DESCRIPTION *);
+ 
+diff --git a/src/cryptography/hazmat/backends/openssl/decode_asn1.py 
b/src/cryptography/hazmat/backends/openssl/decode_asn1.py
+index 773189d4f8..75d5844bc1 100644
+--- a/src/cryptography/hazmat/backends/openssl/decode_asn1.py
 b/src/cryptography/hazmat/backends/openssl/decode_asn1.py
+@@ -379,7 +379,14 @@ def _decode_authority_key_identifier(backend, akid):
+ 
+ def _decode_authority_information_access(backend, aia):
+ aia = backend._ffi.cast("Cryptography_STACK_OF_ACCESS_DESCRIPTION *", aia)
+-aia = backend._ffi.gc(aia, backend._lib.sk_ACCESS_DESCRIPTION_free)
++aia = backend._ffi.gc(
++aia,
++lambda x: backend._lib.sk_ACCESS_DESCRIPTION_pop_free(
++x, backend._ffi.addressof(
++backend._lib._original_lib, "ACCESS_DESCRIPTION_free"
++)
++)
++)
+ num = backend._lib.sk_ACCESS_DESCRIPTION_num(aia)
+ access_descriptions = []
+ for i in range(num):
+diff --git a/tests/hazmat/backends/test_openssl_memleak.py 
b/tests/hazmat/backends/test_openssl_memleak.py
+index ed22b5db9e..f9ae1c46b9 100644
+--- a/tests/hazmat/backends/test_openssl_memleak.py
 b/tests/hazmat/backends/test_openssl_memleak.py
+@@ -210,7 +210,7 @@ class TestOpenSSLMemoryLeaks(object):
+ @pytest.mark.parametrize("path", [
+ "x509/PKITS_data/certs/ValidcRLIssuerTest28EE.crt",
+ ])
+-def test_x509_certificate_extensions(self, path):
++def test_der_x509_certificate_extensions(self, path):
+ assert_no_memory_leaks(textwrap.dedent("""
+ def func(path):
+ from cryptography import x509
+@@ -226,6 +226,25 @@ def func(path):
+ cert.extensions
+ """), [path])
+ 
++@pytest.mark.parametrize("path", [
++"x509/cryptography.io.pem",
++])
++def test_pem_x509_certificate_extensions(self, path):
++

Bug#943744: caja: Cannot move file to Trash, do you want to delete immediately?

[scott092707]

Update:

Having given myself ownership and permissions to ~/.local/share/Trash[/*],
I am now able to trash items that are in my system / partition (including items 
that
are in /home/scott that are NOT in the bind-mounted personal data directories)
with no complaint from Caja.

scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha .local/share
drwxrwx---  4 scott scott 4.0K Mar 16  2019 Trash 

scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha .local/share/Trash  




   
total 16K   




   
drwxrwx---  4 scott scott 4.0K Mar 16  2019 .   




   
drwxr-xr-x 19 scott scott 4.0K Oct 29 23:50 ..  




   
drwxrwx---  2 scott scott 4.0K Mar 16  2019 files   




   
drwxrwx---  2 scott scott 4.0K Mar 16  2019 info

However, I am still not able to trash files in my bind-mounted directories.

In looking at the terminal output for the trash directory for /data (see above),
I noted that although I had ownership of the directory, only the owner had 
permissions for "Create and delete".

I fixed that...
scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha /data/.Trash-1000   




   
total 4.0M  




   
drwxrwx---   5 scott scott 4.0K Feb 28  2014 .  




   
drwxrwxr-x  10 scott scott 4.0K Oct 28 20:15 .. 




   
drwxrwx---   2 scott scott  16K Feb 28  2014 expunged   




   

Bug#942789: libbio-{db-{biofetch,gff,seqfeature},searchio-hmmer,tools-run-remoteblast}-perl: missing Breaks+Replaces: libbio-perl-perl (<< 1.7.3)

[Michael Crusoe]

All of those have been submitted, but were rejected due to my lack of
uploader privileges.

Any DD can allow me to upload the fixed packages via the following command


dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow ${srcpackage}


--
Michael R. Crusoe

On Wed, Oct 30, 2019, 19:09 Andreas Beckmann  wrote:

> Followup-For: Bug #942789
>
> There are some more related Breaks+Replaces needed:
>
>   Unpacking libbio-db-gff-perl (1.7.3-1) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/libbio-db-gff-perl_1.7.3-1_all.deb (--unpack):
>trying to overwrite '/usr/bin/bp_bulk_load_gff', which is also in
> package bioperl 1.7.2-3
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>
>   Preparing to unpack .../libbio-db-seqfeature-perl_1.7.3-1_all.deb ...
>   Unpacking libbio-db-seqfeature-perl (1.7.3-1) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/libbio-db-seqfeature-perl_1.7.3-1_all.deb
> (--unpack):
>trying to overwrite '/usr/bin/bp_seqfeature_delete', which is also in
> package bioperl 1.7.2-3
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>
> i.e. both libbio-db-gff-perl and libbio-db-seqfeature-perl need
> an additional Breaks+Replaces: bioperl (<< 1.7.3)
>
>
> Andreas
>

Bug#943847: python3-sardana: missing Breaks+Replaces: python-sardana

[Andreas Beckmann]

Package: python3-sardana
Version: 3.0.0a+3.f4f89e+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-sardana_3.0.0a+3.f4f89e+dfsg-1_all.deb ...
  Unpacking python3-sardana (3.0.0a+3.f4f89e+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-sardana_3.0.0a+3.f4f89e+dfsg-1_all.deb 
(--unpack):
   trying to overwrite '/usr/bin/MacroServer', which is also in package 
python-sardana 2.6.2+dfsg-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-sardana_3.0.0a+3.f4f89e+dfsg-1_all.deb


cheers,

Andreas


python-sardana=2.6.2+dfsg-1_python3-sardana=3.0.0a+3.f4f89e+dfsg-1.log.gz
Description: application/gzip

Bug#943395: runit: Minor fixes to invoke-run

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-35
Followup-For: Bug #943395

patch refreshed

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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.29-2
ii  sysuser-helper  1.3.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-35

runit suggests no packages.

-- Configuration Files:
/etc/default/runit changed [not included]
/etc/runit/3 changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/runit/invoke-run (from runit package)
debsums: changed file /sbin/update-service (from runit package)
>From 9d24842ffdb859894f47142925663d2aee748643 Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Wed, 30 Oct 2019 19:32:37 +0100
Subject: [PATCH] Minor improvements to invoke-run

* be verbose about uninstalled binary
* redirect output of {$initscripts} stop to /dev/null (it goes to
  service log otherwise); it is confusing to see a stop message during
  service startup

Closes: #943395
---
 debian/contrib/lib/invoke-run | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/contrib/lib/invoke-run b/debian/contrib/lib/invoke-run
index 2a11306..5a9b4c6 100755
--- a/debian/contrib/lib/invoke-run
+++ b/debian/contrib/lib/invoke-run
@@ -38,6 +38,7 @@ if [ -f "/etc/sv/${service}/.meta/installed" ] ; then
# uninstalled, but not purged. See #929693 and commit [4c485b]
# in dh-runit repository.
if ! [ -f "${installed}" ] ; then
+   echo "runsv: $NAME binary not installed"
sv down "${service}"
exit 0
fi
@@ -69,7 +70,7 @@ if [ -x "${initscript}" ] ; then
exit 0
fi
fi
-   "${initscript}" stop
+   "${initscript}" stop >/dev/null
 fi
 
 if [ -d "/etc/sv/${service}/conf" ] ; then
-- 
2.24.0.rc1

Bug#943848: Should depend on gir1.2-soup-2.4

[Sven Bartscher]

Package: lollypop
Version: 1.2.1-1
Severity: important

After installing lollypop and trying to start it through the
application menu, nothing happened. Lollypop didn't start as
expected. Trying to start it on the terminal revealed the following
error message:

$ lollypop
Traceback (most recent call last):
  File "/usr/bin/lollypop", line 45, in 
from lollypop.application import Application
  File "/usr/lib/python3/dist-packages/lollypop/application.py", line 40, in 

from lollypop.art import Art
  File "/usr/lib/python3/dist-packages/lollypop/art.py", line 18, in 
from lollypop.art_album import AlbumArt
  File "/usr/lib/python3/dist-packages/lollypop/art_album.py", line 26, in 

from lollypop.helper_task import TaskHelper
  File "/usr/lib/python3/dist-packages/lollypop/helper_task.py", line 14, in 

gi.require_version("Soup", "2.4")
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in 
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Soup not available

Installig fir1.2-soup-2.4 fixed the issue. Apparently lollypop needs a
dependency on that package.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lollypop depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  gir1.2-gst-plugins-base-1.0  1.16.1-1
ii  gir1.2-gstreamer-1.0 1.16.1-1
ii  gir1.2-secret-1  0.19.1-1
ii  gir1.2-totemplparser-1.0 3.26.3-1
ii  gstreamer1.0-libav   1.16.1-1
ii  python3  3.7.5-1
ii  python3-bs4  4.8.0-2
ii  python3-gi   3.34.0-1
ii  python3-pil  6.2.0-1
ii  python3-pylast   3.1.0-1

lollypop recommends no packages.

lollypop suggests no packages.

-- no debconf information

Bug#943849: geoipupdate does not create the database directory

[Etienne Dechamps]

Package: geoipupdate
Version: 4.0.6-1

After installing geoipupdate, the bundled cron job fails with:

# /usr/bin/geoipupdate
Error preparing to update: database directory is not available: stat
/var/lib/GeoIP: no such file or directory

Workaround:

# mkdir /var/lib/GeoIP

Seems like that command should be run as part of package installation.

Bug#943850: python3-python-qt-binding: missing Breaks+Replaces: python-qt-binding

[Andreas Beckmann]

Package: python3-python-qt-binding
Version: 0.3.6-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-python-qt-binding_0.3.6-2_all.deb ...
  Unpacking python3-python-qt-binding (0.3.6-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-python-qt-binding_0.3.6-2_all.deb (--unpack):
   trying to overwrite '/usr/share/pkgconfig/python_qt_binding.pc', which is 
also in package python-qt-binding 0.3.4-2
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-python-qt-binding_0.3.6-2_all.deb


cheers,

Andreas


python-qt-binding=0.3.4-2_python3-python-qt-binding=0.3.6-2.log.gz
Description: application/gzip

Bug#943851: inn2 FTCBFS: IOV_MAX check doesn't work for cross

[Helmut Grohne]

Source: inn2
Version: 2.6.3-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

inn2 fails to cross build from source, because its check for IOV_MAX
doesn't work during cross compilation. The check actually tries to do
two things in one check: 1. Figure out whether IOV_MAX is defined. 2.
Figure out a suitable value for IOV_MAX in case it isn't defined. The
second part cannot be easily ported to cross compilation, but luckily
our C library does provide IOV_MAX, so using AC_CHECK_DECL avoids the
need for our cause. The attached patch adapts the check. Please consider
applying it.

Helmut
--- inn2-2.6.3.orig/m4/iov-max.m4
+++ inn2-2.6.3/m4/iov-max.m4
@@ -38,9 +38,6 @@
   FILE *f = fopen ("conftestval", "w");
   if (f == NULL)
 return 1;
-#ifdef IOV_MAX
-  fprintf (f, "set in limits.h\n");
-#else
 # ifdef UIO_MAXIOV
   fprintf (f, "%d\n", UIO_MAXIOV);
 # else
@@ -61,14 +58,14 @@
 }
   fprintf (f, "1024\n");
 # endif /* UIO_MAXIOV */
-#endif /* IOV_MAX */
   return 0;
 }
 ]])])
 
 dnl Do the actual check.
 AC_DEFUN([INN_MACRO_IOV_MAX],
-[AC_CACHE_CHECK([value of IOV_MAX],
+[AC_CHECK_DECL([IOV_MAX],[],
+  [AC_CACHE_CHECK([value of IOV_MAX],
 [inn_cv_macro_iov_max],
 [AC_RUN_IFELSE([_INN_MACRO_IOV_MAX_SOURCE],
 inn_cv_macro_iov_max=`cat conftestval`,
@@ -78,7 +75,18 @@
  AC_MSG_WARN([probe failure, assuming 16])
  inn_cv_macro_iov_max=16
  fi])
- if test x"$inn_cv_macro_iov_max" != x"set in limits.h" ; then
 AC_DEFINE_UNQUOTED(IOV_MAX, $inn_cv_macro_iov_max,
[Define to the max vectors in an iovec.])
- fi])
+ ],[
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef HAVE_UNISTD_H
+# include 
+#endif
+#ifdef HAVE_LIMITS_H
+# include 
+#endif
+])])

Bug#943598: linux-source-4.9: Func irq_remove_generic_chip is undefined .

[Ben Hutchings]

Control: tag -1 moreinfo

On Sun, 2019-10-27 at 09:10 +0100, Corcodel Marian wrote:
> Package: linux-source-4.9
> Severity: normal
> 
> Func irq_remove_generic_chip is undefined but when compile file suppress
> errors.Search func here:
>   https://elixir.bootlin.com/linux/v5.0-rc6/ident/irq_remove_generic_chip

What errors are you talking about?

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
 - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'




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

Bug#940136: aqbanking-tools: Transaction fails with 9075::Starke Kundenauthentifizierung notwendig.

[Micha Lenk]

Hi Achim,

thank you very much for the positive feedback on the new AqBanking 
versions. This helps a lot to move on with more confidence in pushing 
this foward.


On 29.10.19 10:29, Achim Weber wrote:

One problem remains on my environment:
The assignment of online (bank) account to gnucash account isn't stored
correctly. In aqbanking management (via gnucash) the assignment can be done but
next time I fetch accounting info I have to select (gnucash) account again


This is probably a bug in Gnucash. Do you mind to raise this on a 
Gnucash related mailing list, or even file it as a separate bug in the 
upstream bug tracker at https://bugs.gnucash.org/enter_bug.cgi? The 
upstream bug tracker should be the best place to track such issues down 
and work on a fix.


Best regards,
Micha

Bug#943852: tstools FTCBFS: uses the build architecture ld

[Helmut Grohne]

Source: tstools
Version: 1.13~git20151030-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

tstools fails to cross build from source, because the upstream makefile
links with $(LD), which happens get default initialized to the build
architecture linker. Exporting it from dpkg's buildtools.mk makes
tstools cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru tstools-1.13~git20151030/debian/changelog 
tstools-1.13~git20151030/debian/changelog
--- tstools-1.13~git20151030/debian/changelog   2019-10-01 17:34:56.0 
+0200
+++ tstools-1.13~git20151030/debian/changelog   2019-10-30 20:06:41.0 
+0100
@@ -1,3 +1,9 @@
+tstools (1.13~git20151030-2) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Export a suitable LD. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 30 Oct 2019 20:06:41 +0100
+
 tstools (1.13~git20151030-1) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru tstools-1.13~git20151030/debian/rules 
tstools-1.13~git20151030/debian/rules
--- tstools-1.13~git20151030/debian/rules   2019-10-01 17:23:17.0 
+0200
+++ tstools-1.13~git20151030/debian/rules   2019-10-30 20:06:40.0 
+0100
@@ -10,6 +10,8 @@
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 include /usr/share/dpkg/default.mk
+-include /usr/share/dpkg/buildtools.mk
+export LD
 
 DEB_CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
 DEB_LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)

Bug#930736: solstices and equinoxes are wrongly reported in the Russian calendar

[sergio]

If you look attentively at the output you'll see quite all equinox and
solstice in the same output:

% faketime '20 Jun 2019' calendar
...
Jun 20* Весеннее равноденствие (Summer Equinox)
...
Jun 21* Зимнее солнцестояние (Winter Solstice)
Jun 21* Летнее солнцестояние (Summer Solstice)
...
Jun 21* Summer Solstice
...


It's not just a translation error that thought to fix easily.


-- 
sergio.

Bug#943790: www.debian.org: packages.debian.org partitions architectures into debports incorrectly

[Witold Baryluk]

Package: www.debian.org
Followup-For: Bug #943790

Yesterday it was showing:

sid (unstable) (libdevel): A library for atomic operations (development files)
7.6.10-1+b1: amd64
7.6.10-1 [ debports ]: alpha arm64 armel armhf hppa i386 m68k mips64el mipsel 
powerpcspe ppc64 ppc64el s390x sh4 sparc64 x32


Today it is showing:


sid (unstable) (libdevel): A library for atomic operations (development files)
7.6.10-1+b1: amd64
7.6.10-1: alpha arm64 armel armhf hppa i386 m68k mips64el mipsel powerpcspe 
ppc64 ppc64el s390x sh4 sparc64 x32



Still wrong, it should be:

sid (unstable) (libdevel): A library for atomic operations (development files)
7.6.10-1+b1: amd64
7.6.10-1: arm64 armel armhf i386 mips64el mipsel ppc64el s390x
7.6.10-1 [ debports ]: alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32


Best regards,
Witold

Bug#942676: mate-menu: Can't add MATE Advanced Menu to panel

[Alan McDonald]

Package: mate-menu
Version: 19.10.2-1
Severity: minor

Dear Maintainer,

I believe the problem is an unexpressed dependency in version 19.10.2-1.

This version of mate-menu requires package: python3-gi-cairo

Manual installation of that package resolved this issue for me on multiple 
physical and virtual machines.

Bug#940116: [Debichem-devel] Bug#940116: cp2k: autopkgtest regression: missing versioned (test) depends?

[Paul Gevers]

Hi Michael,

On 28-10-2019 20:56, Michael Banck wrote:
> That has been fixed since in testing it seems, can we close this bug?

As I already said on IRC, I fine with that, although technically the bug
is still there. I mean, the *versioned* (test) dependency is not
properly declared. But alas.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#943730: marked as done (RFS: cowsay/3.03+dfsg2-7 [ITA] -- configurable talking cow)

[Stephen Kitt]

On Wed, 30 Oct 2019 11:03:33 +0800, Paul Wise  wrote:
> On Wed, Oct 30, 2019 at 5:03 AM Stephen Kitt wrote:
> > I’ve pushed that to the games-team repository, and tagged the release.
> > Please register a guest account on Salsa if you don’t already have one:
> > https://signup.salsa.debian.org/
> > Then you’ll be able to request access to the cowsay repository and/or the
> > games team on https://salsa.debian.org/games-team  
> 
> Why not use the existing cowsay repository?
> 
> https://salsa.debian.org/debian/cowsay

Oops, sorry, yes, that’s the repo I used.

Regards,

Stephen


pgpIZdGGzfl7J.pgp
Description: OpenPGP digital signature

Bug#943588: libllvm9 version differs between amd64 and i386

[Bernhard Übelacker]

Hello,
this seems to be caused by a build failure in 1:9.0.0-1
for i386 while amd64 succeeded.
The build failure seems related to #942864.

Next upload 1:9.0.0-2 succeeded for both architectures.

Kind regards,
Bernhard


https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-9&arch=i386
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-9&arch=amd64
https://bugs.debian.org/942864

Bug#943854: neutron [INTL:de] Updated German debconf translation

[Chris Leick]

Package: neutron
Version: 15.0.0
Severity: wishlist
Tags: l10n patch



Hi,

please find attached the newest German debconf translation.

Kind regards,
Chris


de.po.gz
Description: application/gzip

Bug#941657: Needed too

[Peter Wienemann]

Hi Thomas,

On 27.10.19 09:10, Thomas Andrejak wrote:
> I'm also interested. I need it to bump version of Prewikka.

nice to hear.

> If you want, we can co-maintain the package

You are welcome as co-maintainer. I pushed what I have right now to
salsa such that you can get an idea what the present status is:

https://salsa.debian.org/python-team/modules/python-lark-parser

It seems that you are not yet a member of the Debian Python Modules
Team. Information on the team (including how to join) is available on

https://wiki.debian.org/Teams/PythonModulesTeam

Getting lark-parser into Debian requires more work than packaging
lark-parser itself. That is why this bug is blocked by #943783 which in
turn is blocked by #943785.

Progress on #943785 can be tracked here:

https://salsa.debian.org/python-team/modules/python-pyjsparser

My work on #943783 is presently slowed down by a problem with a js2py
unit test error [0]. After some necessary clean-up I will push my js2py
packaging work in progress to

https://salsa.debian.org/python-team/modules/python-js2py

Peter

[0] https://github.com/PiotrDabkowski/Js2Py/issues/185

Bug#943845: syslinux-common: error messages with grml boot stick

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Sven,

thanks for your report!

On Wed, 30 Oct 2019 18:58:12 +0100
Sven Joachim  wrote:

> Today I built myself a USB stick with grml on it (see #943838 for the
> problems I had with that).  When booting an old 32-bit laptop with
> this stick syslinux threw some error messages before its prompt:
> 
> ,
> | Undef symbol FAIL: x86_init_fpu
> | Failed to load libcom32.c32
> | Failed to load COM32 file vesamenu.c32
> | boot:
> `

I'm unable to reproduce this at the moment using the syslinux version
3:6.04~git20190206.bf6db5b4+dfsg1-1 .

I'm suspecting that there is somehow a mismatch between the version of
syslinux/extlinux used while installing (i.e. running `extlinux -i`)
and the c32 files installed on the medium.

Can you check whether the c32 files installed on the medium
(probably in /boot/syslinux or /boot/extlinux) match the one
from /usr/lib/syslinux/modules/bios on the host system? If they do
match, can you re-run the syslinux installation from the host system
and then try again? Is the image bootable when using `qemu-system-i386`?

If all of the above does not help narrow down the problem, can you
provide me with the necessary commands to build a similarly broken image
myself?

Thanks for your help
Lukas

Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2

[Wolfgang Silbermayr]

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

The rust-crossbeam-utils-0.5 package is no longer in use. All reverse
dependencies either migrated to a non-semver-suffixed version of rust-
crossbeam-utils or don't depend on it anymore at all.
The only remaining dependency as of now is rust-crossbeam-epoch-0.5 for which I
asked the maintainer to file a RM request as well.

Bug#943856: dumpasn1 misindentifies some inputs as ASCII

[Eric Seppanen]

Package: dumpasn1
Version: 20170309-1
Severity: normal

Dear Maintainer,

There is a bug in the dumpasn1 program that prevents it from handling certain
(valid) files.  This bug is fixed in the upstream source:
https://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c

I'll include the comment from the fixed code since it describes the problem
better than I could:
> Special-case handling for situations that would produce a 
> false positive, items containing nested SEQUENCE (0x30)/SET 
> (0x31) of an appropriate length will look like ASCII since
> the encoding is 0x30 0xXX 0x30 0xXX 0x30 0xXX, e.g. "0g0e0c",
> so we check for the pattern [0|1] alnum [0|1] alnum ...

An example of an input that demonstrates the problem:

MHcwdTBOMEwwSjAJBgUrDgMCGgUABBRCRjDCJxnb3nDwj/xz5aZfZjgXvAQUmNH4bhDrz5vsYJ8Y
kBug630J/SsCEQDtf4ChN5MCVggAGQ3NoiMwITAfBgkrBgEFBQcwAQIEEgQQX7GnwCPaKaV9
xhaMpzjwbA==

The problem looks like this:
$ base64 < (input file above) >ocsp_req.der
$ dumpasn1 ocsp_req.der 
Error: This file appears to be a base64-encoded text file, not binary data.
   In order to display it you first need to decode it into its
   binary form.

That error message is wrong; the file is in its proper binary form.  The
expected output looks like this (using the upstream code):

$ ./dumpasn1 ocsp_req.der 
  0 119: SEQUENCE {
  2 117:   SEQUENCE {
  4  78: SEQUENCE {
  6  76:   SEQUENCE {
  8  74: SEQUENCE {
 10   9:   SEQUENCE {
 12   5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
 19   0: NULL
   : }
 21  20:   OCTET STRING
   : 42 46 30 C2 27 19 DB DE 70 F0 8F FC 73 E5 A6 5F
   : 66 38 17 BC



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

Kernel: Linux 4.15.0-66-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dumpasn1 depends on:
ii  libc6  2.29-2

dumpasn1 recommends no packages.

dumpasn1 suggests no packages.

-- no debconf information

Bug#943811: perl:any is possible the following way and I suggest doing this

[Niko Tyni]

On Tue, Oct 29, 2019 at 11:05:27PM -0600, mdasoh kyaeppd wrote:
> Package: perl
> Version: 5.30.0-8
> Severity: important
> 
> Having seen perl:any wane in use, I suggest bringing it back with the 
> following measures:
> in perl's control stanza:
> Provides: perl:any (= 5.30.0-8)
> in perl-base's control stanza:
> Multi-Arch: foreign
> Provides: perl-base:any (= 5.30.0-8), perlapi-5.30.0:any
> in a package's control stanza which currently Depends: perl:any
> Multi-Arch: foreign
> Depends: perl:any (>= 5.30.0-8), perlapi-5.30.0:any
> 
> I have it working this way locally
> please respond with your thoughts or opinions.

I don't know what problem you are trying to solve and this doesn't make
much sense to me unfortunately.

In any case, depending on perlapi-5.30.0:any seems like a totally
wrong concept: perlapi-5.30.0 is about guaranteeing binary compatibility
between the perl interpreter and its plugins (compiled XS modules). Their
architectures must therefore always match.
-- 
Niko Tyni   nt...@debian.org