Bug#902470: Status?

[Alexandre Viau]

On Sat, 25 Aug 2018 19:44:12 +0200 olivier sallou 
wrote:
> Hi,
> My packages have been removed from testing due to this bug.
> Can we remove failing test and lower bug severity waiting for upstream fix?

I have uploaded a fix.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#896171: MS DOS partition table recognized as Atari AHDI

[Emmanuel Kasper]

Ok i can reproduce the issue using the pc6.mbr posted by bouke:

cp pc6.mbr disk.img
# otherwise parted complains "Can't have a partition outside the disk"
truncate -s 600GB disk.img

# fdisk correctly detects the msdos partition table
fdisk -l disk.img
Disk disk.img: 600 GiB, 644245094400 bytes, 1258291200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x44a777ed

Device Boot Start   End   Sectors  Size Id Type
disk.img1  * 2048718847716800  350M 17 Hidd
disk.img2  718848 975747071 975028224  465G  7 HPFS
disk.img3   975747072 976771071   1024000  500M 27 Hidd

# parted fails

parted disk.img print

Disk /home/manu/Téléchargements/disk.img: 644GB
Sector size (logical/physical): 512B/512B
Partition Table: atari
Disk Flags:

Number  Start   End SizeType File system  Flags
 1  8323MB  14,8GB  6446MB  primary   boot


Also using the disktype utility (which knows both msdos and ahdi) the
msdos partition table is properly recognized.

CCing John as he is the original atari patch author

@john: I am heavily suspecting here the disk signature, but maybe you
have a better idea ?

Bug#907168: pytest-httpbin FTBFS with OpenSSL 1.1.1

[Kurt Roeckx]

On Tue, Aug 28, 2018 at 03:33:11PM +0200, Pierre-Elliott Bécue wrote:
> Le samedi 25 août 2018 à 20:34:35+0200, Kurt Roeckx a écrit :
> > This is caused by a Debian change to require a 2048 bit key by
> > default instead of a 1024 bit key. Since this is just for a test,
> > you can either just replace the certificates with larger keys,
> > or lower the security level for the test from 2 to 1. I suggest
> > you just create a new certificates.
> 
> Dear Kurt,
> 
> This would imply to do a Debian patch in upstream's source.
> 
> Do you think it's the best solution?

Upstream should fix this too. I suggest you talk to upstream and
then just apply the fix in Debian if they've fixed it.


Kurt

Bug#876759: daisy-player: Broken autopkgtest

[Samuel Thibault]

Hello,

Jos Lemmens, le mar. 28 août 2018 18:07:10 +0200, a ecrit:
> I do know nothing about autopkgtest. It is completely new to me.
> I will read the manual. Can you give me a hint?

One can easily run by hand with

autopkgtest -- null

Paul dropped the test in 857c879279ea69a7d5be8a05108386c28718b7ba (which
got in 11.2-1) because of the hang and mentions a way to reproduce it:

Fails: bash -ec 'LC_ALL=C daisy-player -h' > >(tee -a /tmp/command1-stdout)
Success: dash -ec 'LC_ALL=C daisy-player -h' > >(tee -a 
/tmp/command1-stdout)

Samuel

Bug#907399: Logs with systemd-coredump

[Francois Marier]

I installed systemd-coredump and this is what I see in my logs now:

  Aug 27 23:04:37 hostname systemd[1]: Listening on Process Core Dump Socket.
  Aug 27 23:05:34 hostname cups-browsed[29428]: munmap_chunk(): invalid pointer
  Aug 27 23:05:34 hostname systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
  Aug 27 23:05:34 hostname systemd[1]: Started Process Core Dump (PID 6012/UID 
0).
  Aug 27 23:05:35 hostname systemd[1]: cups-browsed.service: Main process 
exited, code=dumped, status=6/ABRT
  Aug 27 23:05:35 hostname systemd[1]: cups-browsed.service: Failed with result 
'core-dump'.
  Aug 27 23:05:35 hostname systemd-coredump[6013]: Process 29428 (cups-browsed) 
of user 0 dumped core.#012#012Stack trace of thread 29428:#012#0  
0x7fe5388c0f3b __GI_raise (libc.so.6)#012#1  0x7fe5388c22f1 __GI_abort 
(libc.so.6)#012#2  0x7fe538903867 __libc_message (libc.so.6)#012#3  
0x7fe538909e0a malloc_printerr (libc.so.6)#012#4  0x7fe53890a36c 
munmap_chunk (libc.so.6)#012#5  0x5618c0606c86 n/a (/usr/sbin/cups-browsed 
(deleted))#012#6  0x7fe5388adb17 __libc_start_main (libc.so.6)#012#7  
0x5618c060769a n/a (/usr/sbin/cups-browsed (deleted))#012#012Stack trace of 
thread 29487:#012#0  0x7fe538978739 __GI___poll (libc.so.6)#012#1  
0x7fe538d44439 n/a (libglib-2.0.so.0)#012#2  0x7fe538d4454c 
g_main_context_iteration (libglib-2.0.so.0)#012#3  0x7fe538d44591 n/a 
(libglib-2.0.so.0)#012#4  0x7fe538d6be05 n/a (libglib-2.0.so.0)#012#5  
0x7fe538a4ff2a start_thread (libpthread.so.0)#012#6  0x7fe538982edf 
__clone (libc.so.6)#012#012Stack trace of thread 29492:#012#0  
0x7fe538978739 __GI___poll (libc.so.6)#012#1  0x7fe538d44439 n/a 
(libglib-2.0.so.0)#012#2  0x7fe538d447d2 g_main_loop_run 
(libglib-2.0.so.0)#012#3  0x7fe539332e26 n/a (libgio-2.0.so.0)#012#4  
0x7fe538d6be05 n/a (libglib-2.0.so.0)#012#5  0x7fe538a4ff2a 
start_thread (libpthread.so.0)#012#6  0x7fe538982edf __clone (libc.so.6)
  Aug 27 23:07:19 hostname cups-browsed[6015]: munmap_chunk(): invalid pointer
  Aug 27 23:07:19 hostname systemd[1]: Started Process Core Dump (PID 16052/UID 
0).
  Aug 27 23:07:19 hostname systemd[1]: cups-browsed.service: Main process 
exited, code=dumped, status=6/ABRT
  Aug 27 23:07:19 hostname systemd[1]: cups-browsed.service: Failed with result 
'core-dump'.
  Aug 27 23:07:19 hostname systemd-coredump[16053]: Process 6015 (cups-browsed) 
of user 0 dumped core.#012#012Stack trace of thread 6015:#012#0  
0x7f28aa0dcf3b __GI_raise (libc.so.6)#012#1  0x7f28aa0de2f1 __GI_abort 
(libc.so.6)#012#2  0x7f28aa11f867 __libc_message (libc.so.6)#012#3  
0x7f28aa125e0a malloc_printerr (libc.so.6)#012#4  0x7f28aa12636c 
munmap_chunk (libc.so.6)#012#5  0x561f47bf3c86 n/a (cups-browsed)#012#6  
0x7f28aa0c9b17 __libc_start_main (libc.so.6)#012#7  0x561f47bf469a n/a 
(cups-browsed)#012#012Stack trace of thread 6017:#012#0  0x7f28aa194739 
__GI___poll (libc.so.6)#012#1  0x7f28aa560439 n/a (libglib-2.0.so.0)#012#2  
0x7f28aa56054c g_main_context_iteration (libglib-2.0.so.0)#012#3  
0x7f28aa560591 n/a (libglib-2.0.so.0)#012#4  0x7f28aa587e05 n/a 
(libglib-2.0.so.0)#012#5  0x7f28aa26bf2a start_thread 
(libpthread.so.0)#012#6  0x7f28aa19eedf __clone (libc.so.6)#012#012Stack 
trace of thread 6018:#012#0  0x7f28aa194739 __GI___poll (libc.so.6)#012#1  
0x7f28aa560439 n/a (libglib-2.0.so.0)#012#2  0x7f28aa5607d2 
g_main_loop_run (libglib-2.0.so.0)#012#3  0x7f28aab4ee26 n/a 
(libgio-2.0.so.0)#012#4  0x7f28aa587e05 n/a (libglib-2.0.so.0)#012#5  
0x7f28aa26bf2a start_thread (libpthread.so.0)#012#6  0x7f28aa19eedf 
__clone (libc.so.6)

One thing I noticed is that I don't actually have the cups-browsed package
installed:

  $ dpkg -l cups-browsed
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name  Version Architecture
Description
  
+++-=-===-===-===
  un  cups-browsed  (no 
description available)

though I do have cups-filters:

  $ dpkg -l cups-filters
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name  Version Architecture
Description
  
+++-=-===-===-===
  ii  cups-filters  1.21.1-1amd64   
OpenPrinting CUPS Filters - Main Package

Could this be the problem? It's a bit strange that I'd 

Bug#894548: pdf-presenter-console: Toggle pointer and drawing mode do not work

[debian]

I found what's going on.

The numerical shortcuts don't work because I used Shitf+key (azerty layout)!
If I use Capslock, the shortcuts work well.

But it is not very easy :

- When capslock is not activated, I can't use the numerical keys.
- When capslock is activated, I can't use the alphabetical keys.


Perhaps, it is useful to transmit this problem upstream?

Bug#876759: daisy-player: Broken autopkgtest

[Jos Lemmens]

Hello Jeremy,

I do know nothing about autopkgtest. It is completely new to me.
I will read the manual. Can you give me a hint?

   Regards,
   
  Jos.
  

On Mon, Sep 25, 2017 at 11:32:04AM -0400, Jeremy Bicha wrote:
> Source: daisy-player
> Version: 10.6.4.2-1
> 
> daisy-player's autopkgtest does not work:
> 
> https://ci.debian.net/packages/d/daisy-player/unstable/amd64/
> http://autopkgtest.ubuntu.com/packages/d/daisy-player/artful/amd64
> 
> It times out after over 2 hours so it's a bit of a drain on the
> autopkgtest infrastructure.
> 
> Thanks,
> Jeremy Bicha

-- 

   Sent from Debian GNU/Linux 9

   ---
   Jos Lemmens
   The Netherlands
   E-mail: j...@jlemmens.nl
   Homepage: www.jlemmens.nl

Bug#907216: ganeti: autopkgtest needs update for new version of openssl

[Apollon Oikonomopoulos]

On 12:38 Mon 27 Aug , Apollon Oikonomopoulos wrote:
> So, it turns out ganeti's internal CA is using SHA1 to sign all 
> generated certificates, which - by the looks of it - is not acceptable 
> by OpenSSL 1.1.
> 
> I'll need some time to investigate and see how we should handle this.

The good news is that it's pretty straightforward to get Ganeti to issue 
SHA256-signed certificates.

The bad news is that this will need a cluster-wide crypto material 
renewal (CA cert + client certs) using `gnt-cluster upgrade', which must 
be performed *after* installing the updated package on *all* nodes and 
cannot be done as part of a maintainer script (and thus can't be 
properly sequenced using Breaks).

I still need to investigate the following bits:

 - Whether I can get ganeti-luxid to use SECLEVEL=1 so that it won't 
   refuse to load the existing client certificates and thus won't cause 
   breakage during the time after the package installation and before 
   gnt-cluster upgrade. A quick look here says that this is not 
   possible, since libcurl seems to set the cipher list (which is used 
   to piggy-back security level information) *after* loading the client 
   certificates[1]. Using curl(1) confirms this as well.

   [1] https://github.com/curl/curl/blob/curl-7_61_0/lib/vtls/openssl.c#L2396

 - Whether a cluster that doesn't work because of SECLEVEL=2 + SHA-1 
   certs can be restored simply by using `gnt-cluster renew-crypto 
   --new-cluster-cert`, which will greatly simplify things. IOW, whether 
   `gnt-cluster renew-crypto` works without using Ganeti's RPC.

Finally, to ensure a smooth upgrade, SHA256 support must be backported 
to Stretch to allow users to upgrade their crypto material and upgrade 
to Buster without problems.

Regards,
Apollon

Bug#907049: [Pkg-openssl-devel] Bug#907049: openssl: Update to 1.1.1~~pre9-1 makes certain programs unusable

[Günter Frenz]

Hi,

On Sun, 26 Aug 2018 16:08:59 +0200 Antonin Kral  wrote:
> * Antonin Kral  [2018-08-25 15:56] wrote:
> > According to https://community.openvpn.net/openvpn/wiki/Hardening , 
> > OpenVPN 2.3.3 and newer should support TLS version negotiation.
> > After some poking around, I have figured that server is running
> > 2.3.4. So one would expect, that TLSv1.2 will work, but it doesn't.
> > TLSv1 is confirmed in log
> > 
> > Sat Aug 25 15:33:33 2018 Control Channel: TLSv1, cipher SSLv3
> > DHE-RSA-AES256-SHA, 2048 bit RSA
> > 
> > I will try to get server upgraded to confirm, that newer version
> > will basically work out of the box.
> 
> I do confirm, that updating server side to a newer version 
> (2.4.0-6+deb9u1 in this case) fully solved the issue and clients are
> now able to negotiate at least TLSv2.

since I can't upgrade the server (running jessie) I downgraded the
client to openssl_1.1.0h-4 which also solved the problem.

Regards

Günter

-- 
---
Günter Frenz
Börschgasse 16a, D-51143 Köln
(h) gu...@guefz.de, gu...@freenet.de
(w) f...@gso-koeln.de
---




pgpZIZz4F05pb.pgp
Description: Digitale Signatur von OpenPGP

Bug#896171: parted wrongly identifies my msdos partition table as atari

[Emmanuel Kasper]

Le 28/08/2018 à 14:46, Franz Simader a écrit :
> Hello,
> 
> I have the same problem as described in the Bug #896171.
> 
> A valid *msdos *partition table with 3 partitions is shown with parted
> (3.2-17) as '*atari*' and only the first partition is visible.
> 
> Is there a solution for this known problem ?
> 
> 
> With best regards.
> 
> Franz Simader

Can you post the output of

parted /dev/my_device print

and attach the first 512 bytes of the the disk to this bug report ?

Did the partitioning of the disk was made on Windows ?

Bug#907485: makepasswd: By default, generated passwords are unsecure

[Emmanuel CHANTREAU]

Package: makepasswd
Version: 1.10-10
Severity: important

Dear Maintainer,

makepasswd, by default, generates passwords that can be cracked in one day or
one month by a single PC with a fast GPU.

Why it is true:
By default the generated password is from length 8 to 10.
Nowdays, a 8 length password is cracked in one day by a single pc with a fast
GPU. I saw this using a testing web site (http://password-checker.online-
domain-tools.com/) and also by my own calculations based on the number or
passwords tested by good crackers.

Why it's a big security problem:
-users relies on the default values to get security
-using this program, users are led to believe that a 8/9 length password is a
good security (this was my case).
For example I crypted my sensible data with a 9 length password.

Security is nothing with only good programs, we need also good practices, good
default parameters and good informations.

Suggestion: set the password to length 14 and give the information that this is
a good security level in 2012. We could set a lower length but the password
should resist not just now but also in a few years.

Regards



-- System Information:
Debian Release: 9.5
Architecture: amd64 (x86_64)

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

Versions of packages makepasswd depends on:
ii  libbytes-random-secure-perl  0.28-1
ii  libcrypt-passwdmd5-perl  1.3-10
ii  perl 5.24.1-3+deb9u4

makepasswd recommends no packages.

makepasswd suggests no packages.

-- no debconf information

Bug#791484: qgit: When a pre-commit hook prints something, QGit conciders that an error

[Filipe Rinaldi]

Hi,

Due to some limitations (see [1]) QGit user the STDERR to detect whether a
git command failed.
Note that the pre-commit hook sample from git sets all output to be done on
the stderr. In this case, I believe the user built his hook based on the
example and is printing out on the stderr even though it is not meant to
represent an error.

https://github.com/tibirna/qgit/blob/5a3c9299484947c8cbe818d1163b36b28c84252a/src/myprocess.cpp#L147

Cheers,
Filipe

Bug#903295: libpam-systemd: Depends: systemd-shim (>= 10-4~) but it is not going to be installed: A stopgap, probably incorrect solution

[Sabahattin Gucukoglu]

I went for an exceedingly dirty solution but one not requiring a build 
environment: unpack the systemd-shim 10-3 deb archive, the control archive 
inside, and then modify the control file.  Carefully pack it back up with tar 
and ar, then install it with dpkg -i.

I *do* hope this will get fixed. Only one package that I need depends on 
systemd via policykit, namely BRLTTY, and the polkit support is completely 
optional if you are not using brlapi.

The servers will never get systemd, of course. This is just a VM with a pure 
textmode environment. I have wondered whether I shouldn’t just bite the bullet, 
only I can’t justify it. This is not change-aversion but self-respect. Systemd 
offers nothing I can’t do better with daemontools/runit/monit. I hope this bug 
is just a bug and not a feature …



smime.p7s
Description: S/MIME cryptographic signature

Bug#899273: ITP: fonts-ibm-plex -- IBM's corporate typeface

[Paride Legovini]

The packaging is ready, but it remains to be decided which format to
ship in the Debian package (TTF, OTF, or both). Tracked upstream:

https://github.com/IBM/plex/issues/198

Paride

Bug#907484: monitoring-plugins-basic: check_file_age not mod_perl safe - please add -epn

[Florian Lohoff]

Package: monitoring-plugins-basic
Version: 2.2-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,
the check_file_age plugin uses perl FindBin which is not mod_perl/embperl
safe and fails.

Please add a 

#!/usr/bin/perl -w
# nagios: -epn

Nagios -epn line at the top to stop nagios executing it with
mod_perl/embperl

Flo


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

Versions of packages monitoring-plugins-basic depends on:
ii  iputils-ping   3:20161105-1
ii  libc6  2.24-11+deb9u3
ii  libssl1.1  1.1.0f-3+deb9u2
ii  monitoring-plugins-common  2.2-3
ii  procps 2:3.3.12-3+deb9u1
ii  ucf3.0036

Versions of packages monitoring-plugins-basic recommends:
ii  libcap2-bin  1:2.25-1

Versions of packages monitoring-plugins-basic suggests:
pn  icinga | icinga2  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdb9o7oebX2papQ/KkN1BIMsJ8i8FAluFYLcACgkQkN1BIMsJ
8i87Pw/8D0Ao2F/NtfeKpcxCHMZfzZSrllJxngXgYWLf0MfAsRt+tSnjynz52MKf
Ttr22pxEHPTYBSy6UJFJNhjP3cNN2mc5wOhVNb+CjJoBbqDWSqJzJaWEQf+3mTBW
1MyWhY+qKGY0ItxGueOnoiPIgkh7rCNU5cdOOeQvVezWUeehrzj7s1ZLqc07YRf7
gU4C52HUJIL7VaOhx3qMsKoqKDhgc1uWzZZWfCb6tqMGLKroiD/MXKc9Ia1K9T3M
XeNLjqB29Dbt6m+WJ49WsJQGXIggXFsYNuHfEL18vOeBPWCDqRCUgraeynsRfuXW
fatEGeWmeb4+9X3L1Ncjek5tM6zy06XdnrUbjjb9qup31SwTp8t0IBLZMdeHysYy
so8Cip8ZBISqeZgQP/MUuEUidBydcYWGXniXiGt9mOrUmcihsO6rFUgPuRVTQ/pD
+VxdQosKVlelgthw/4IhXMDRPB15fbDa5qgb3sFF0hZwefshefNP+GpubJrq/zWT
9bXiwnnQyCS8/q9ygCqvqEWDIOoYsRphiDkO2GBmrlOuW0jteBrKYNKGAtv/IGSX
Mby3gcTS+Xfq1pUl4B84UM7kANxTGMtogv5cRpOP9TcHwcEHsDDyN/D1/qxDbLA3
+LsBssfv3QgxofHwYawzpMnoY6LuMc3sZj0Jj56hw9PQcoWz7IM=
=Zc98
-END PGP SIGNATURE-

Bug#907483: grub-efi-*-signed-template: `Built-Using` must refer to source packages

[Ansgar Burchardt]

Package: grub-efi-amd64-signed-template
Version: 2.02+dfsg1-5
Severity: serious

The `Built-Using` field of the source template refers to binary
packages instead of source packages.  This makes dak reject the upload
of the signed packages:

+---
| grub-efi-amd64-signed_1+2.02+dfsg1+5_amd64.deb: Built-Using refers to 
non-existing source package grub-efi-amd64-bin (= 2.02+dfsg1-5)
+---[ grub-efi-amd64-signed_1+2.02+dfsg1+5_amd64.changes.reason ]

(same for ia32/i386 and arm64)

Ansgar

Bug#907437: debbugs creates wrong 'Resent-CC' field

[Martin Castillo]

On Tue, Aug 28, 2018 at 09:20:26AM +0200, Julien Cristau wrote:
> On Tue, Aug 28, 2018 at 02:26:43 +0200, Martin Castillo wrote:
> 
> > Package: debbugs
> > 
> > Hi,
> > 
> > I'm subscribed to the guix-patc...@lists.gnu.org mailing list and
> > saw that debbugs seems to add a 'Resent-CC:' field to the messages that
> > it bounces.
> > 
> > According to  the
> > second 'c' should be lowercase: Resent-Cc:
> > 
> > I checked the debbugs git repo and it seems to be created in
> > scripts/process:814.
> > 
> I believe this bug is invalid;  Per
> https://tools.ietf.org/html/rfc5322#section-1.2.2 "Resent-Cc" is a
> "case-insensitive literal value enclosed in quotation marks" and so
> "Resent-CC" is just fine.

I did not see that part. This bug is invalid.

Martin

Bug#905732: kernel-package: fails to create debian directory (/bin/sh: 1: [: -lt: unexpected operator)

[Claude Heiland-Allen]

On 11/08/18 18:43, Claude Heiland-Allen wrote:

Worked (albeit slowly) without  -j 32.  To be precise, this worked:


I think this is an issue with using an old .config and not updating it 
properly with new variables defined in the new kernel.


Seems if I go through the make oldconfig stuff (invoked by make-kpkg) 
once successfully, with the build failing after that with the can't 
crate debian directory, then subsequently trying make-kpkg again does 
work with -j 32

Bug#907482: emacs: FTBFS on powerpc

[Daniel Kahn Gillmor]

Package: emacs
Version: 1:25.2+1-11
Severity: normal

I know that powerpc is a port these days, and not an official 
architecture, but the emacs build-time test suite is failing on powerpc:

https://buildd.debian.org/status/fetch.php?pkg=emacs=powerpc=1%3A25.2%2B1-11=1535311183=0
 

shows:

Testing /<>/debian/build-src/test/automated/file-notify-tests.elc
Running 7 tests (2018-08-26 19:18:07+)
Library: `inotify'
   passed  1/7  file-notify-test00-availability
   passed  2/7  file-notify-test01-add-watch
   passed  3/7  file-notify-test02-events
Reverting buffer `file-notify-test55251Gzj'.
Reverting buffer `file-notify-test55251Gzj'.
   passed  4/7  file-notify-test03-autorevert
   passed  5/7  file-notify-test04-file-validity
   passed  6/7  file-notify-test05-dir-validity
Test file-notify-test07-backup backtrace:
  #[0 "\306\307\310C\307C\3111(\312\313\314\315\316$\317\"\32
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  ert-run-test([cl-struct-ert-test file-notify-test07-backup "Check th
  ert-run-or-rerun-test([cl-struct-ert--stats (not (tag :expensive-tes
  ert-run-tests((not (tag :expensive-test)) #[385 "\30\307\"\203G\2
  ert-run-tests-batch((not (tag :expensive-test)))
  ert-run-tests-batch-and-exit((not (tag :expensive-test)))
  eval((ert-run-tests-batch-and-exit (quote (not (tag :expensive-test)
  command-line-1(("-L" ":/<>/debian/build
  command-line()
  normal-top-level()
Test file-notify-test07-backup condition:
(ert-test-failed
 ((should
   (file-notify--test-with-events-check events))
  :form
  (file-notify--test-with-events-check
   ((renamed created changed)))
  :value nil :explanation "Received events `(changed)' do not match 
expected events `(renamed created changed)'"))
   FAILED  7/7  file-notify-test07-backup

Ran 7 tests, 6 results as expected, 1 unexpected (2018-08-26 19:18:47+)

1 unexpected results:
   FAILED  file-notify-test07-backup

ERROR: file-notify-tests.log

Thanks for your work on emacs in debian!

--dkg


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

Kernel: Linux 4.14.0-3-powerpc-smp (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs depends on:
pn  emacs-gtk | emacs-lucid | emacs-nox  

emacs recommends no packages.

emacs suggests no packages.

Bug#907481: [fr] Do not translate the apt-ftparchive commands

[Laurent Bigonville]

Package: apt
Version: 1.6.4
Severity: normal
Tags: l10n patch

Hi,

It seems that the "package" command of apt-ftparchive has been
translated to "paquets" in the french usage message.

This is obviously not correct

Please find a patch attached that fixes this.

Kind regards,

Laurent Bigonville

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (/etc/apt/preferences.d/apt-listbugs present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/eid.list present, but not submitted) --


-- (/etc/apt/sources.list.d/skype-stable.list present, but not submitted) --


-- (/etc/apt/sources.list.d/spotify.list present, but not submitted) --


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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages apt depends on:
ii  adduser 3.117
ii  debian-archive-keyring  2017.7
ii  gpgv2.2.9-2
ii  libapt-pkg5.0   1.6.4
ii  libc6   2.27-5
ii  libgcc1 1:8.2.0-4
ii  libgnutls30 3.5.19-1
ii  libseccomp2 2.3.3-3
ii  libstdc++6  8.2.0-4

Versions of packages apt recommends:
ii  ca-certificates  20180409

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.10-9
ii  dpkg-dev1.19.0.5
ii  gnupg   2.2.9-2
ii  powermgmt-base  1.33

-- no debconf information
diff -Nru apt-1.7.0~alpha3/po/fr.po apt-1.7.0~alpha3bigon1/po/fr.po
--- apt-1.7.0~alpha3/po/fr.po   2018-08-20 17:44:19.0 +0200
+++ apt-1.7.0~alpha3bigon1/po/fr.po 2018-08-28 16:16:26.0 +0200
@@ -3410,7 +3410,7 @@
 "  -o=?  Set an arbitrary configuration option"
 msgstr ""
 "Usage : apt-ftparchive [options] commande\n"
-"Commandes :  paquets binarypath [fichier d'« override » [chemin du "
+"Commandes :  packages binarypath [fichier d'« override » [chemin du "
 "préfixe]]\n"
 " sources srcpath [fichier d'« override » [chemin du préfixe]]\n"
 " contents path\n"

Bug#906284: Too many false positives?

[Jonathan Dowland]

I think checking line length for the license text block would be much
more discriminative: approx 9% of the 317 currently matching packages
would trigger the test (some more than once). I attempted to simulate
this change in Lintian with a totally separate hacky script, manually
checking over the matches from *my* script produced the following bad
packages (including the 1/9 I found by-hand in my random-sampling)

   audacity
   bibletime
   gnome-devel-docs
   kbounce
   ksirk
   ktuberling
   marble
   mrpt
   ogre
   opensesame
   openscad-mcad (including: "it is licensed under the Creative Commons - GNU LGPL 
2.1 license.")
   phabricator
   pioneers
   plm
   python-odf
   recommonmark
   starfighter ("CC-BY-SA-3.0+ Identical to CC-BY-SA-3.0, except you may also chose 
to use any later version of this license.")
   supercollider
   ublock-origin
   xia

My hacky script had 3-4 false positives too, but manual inspection of
them show that to be due to problems in my hacky script, and not in the
notion of line-length checking the license.

Special handling of CC0 is indeed necessary for the line length check.
I've seen it referred to as "CC-Zero" (haskell-network-multicast) as
well as the more common CC0.

So I support adjusting the regex to avoid CC0/Zero and doing a simpler
line length check, 20 seems reasonable.

What I haven't done is look at the other 297 packages currently matching
and determine whether they are also incorrect. But let's assume not.

--
Jonathan Dowland

Bug#907480: altos FTBFS with gcc-arm-none-eabi 15:7-2018-q2

[Adrian Bunk]

Source: altos
Version: 1.8.6-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/altos.html

...
  CC  fox1ihu-altos-flash-1.8.6.elf
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: 
fox1ihu-altos-flash-1.8.6.elf section `.textram' will not fit in region `rom'
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: region `rom' 
overflowed by 18 bytes
collect2: error: ld returned 1 exit status
make[4]: *** [../../stm/Makefile-flash.defs:74: fox1ihu-altos-flash-1.8.6.elf] 
Error 1

Bug#869987: document (and enable?) the automatic purge of downloaded packages (APT::Periodic::AutocleanInterval)

[Balint Reczey]

Control: notfound -1 0.93.1+nmu1
Control: tags -1 - patch

On Fri, 28 Jul 2017 09:28:39 -0400 Antoine Beaupre
 wrote:> Package: unattended-upgrades
> Version: 0.93.1+nmu1
> Severity: normal
> Tags: patch
>
> Hi,
>
> In the past week, my filesystem finally filled up due to 6GB of
> archives in /var/cache/apt/archives. I identified unattended-upgrades
> as the cause of this problem, as it didn't purge old packages (hello
> texlive!) that it downloaded previously, even when there were
> many versions of the same packages.
>
> unattended-upgrades doesn't document how to work around this problem
> at all, in itself. There is, however, sparse documentation here and
> there that indicate there are ways of doing this with:
>
> // Do "apt-get autoclean" every n-days (0=disable)
> APT::Periodic::AutocleanInterval "7";
>
> This is documented in:
>
> https://wiki.debian.org/UnattendedUpgrades
> https://debian-handbook.info/browse/stable/sect.regular-upgrades.html
>
> It seem important that the default configuration also documents this
> feature, if not just enable it by default.
>
> I filed a pull request upstream for this:
>
> https://github.com/mvo5/unattended-upgrades/pull/68

As discussed in the GitHub issue the default seems to be working and
it may have been a local issue.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#831764: I am on V3.14.0-3 and experiencing this

[sixerjman]

The rsyslog configuration I have has messages, kern and ssh log. I see the
active file(s) as messages | kern | ssh log.1 and all have 'delaycompress'
in the /etc/logrotate.d/ snippet:

/var/log/ssh.log /var/log/messages /var/log/kern.log {
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog rotate > /dev/null
endscript
}

Bug#906749: python3-geopy: too old, does not include geopy.extra.rate_limiter.RateLimiter

[Thorsten Glaser]

Hi eriol,

> Sorry for the delay, I already started updating it, and I have ready also a 
> patch to fix an UnicodeDecodeError. I'm not sure I will be able to complete 
> the packaging today, is it a problem if it will be completed on Thursday?

thanks for the feedback. In the meantime I managed to do it
by running my script in the top-level directory of a clone
of upstream’s repository, so the immediate need is gone,
although we might need it occasionally still.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**Besuchen Sie uns auf der dmexco 2018!**

12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031**

Digital Business, Marketing und Innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*

**Visit us at dmexco 2018!**

12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031**

Digital business, marketing and innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*

Bug#907479: python3-grib: code improperly ported to python 3: 'dict_keys' object has no attribute 'sort'

[Goulou]

Package: python3-grib
Version: 2.0.2-4
Severity: minor
Tags: patch

Dear Maintainer,

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

   * What led up to the situation?
call repr() on a grib message object

   * What was the outcome of this action?
  File "/usr/lib/python3/dist-packages/ncepgrib2.py", line 623, in __repr__
keys.sort()
AttributeError: 'dict_keys' object has no attribute 'sort'
The line (/usr/lib/python3/dist-packages/ncepgrib2.py:623) should be changed
to:
keys = sorted(keys)


-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (950, 'stable'), (900, 'testing'), (130, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages python3-grib depends on:
ii  libc6   2.27-3
ii  libeccodes-data 2.0.2-5
ii  libeccodes-dev  2.0.2-5
ii  libeccodes0 2.0.2-5
ii  libgrib2c-dev   1.6.0-9
ii  python3 3.6.5-3
ii  python3-numpy [python3-numpy-abi9]  1:1.14.5-1+b1
ii  python3-pyproj  1.9.5.1-4

Versions of packages python3-grib recommends:
ii  python-grib-doc  2.0.2-4

python3-grib suggests no packages.

Bug#907476: libreoffice: file permissions are changed to 0600 when re-saving

[Rene Engelhard]

tag 907476 + upstream
tag 907476 + fixed-upstream
forwarded 907476 https://bugs.documentfoundation.org/show_bug.cgi?id=119050
thanks

Hi,

On Tue, Aug 28, 2018 at 02:25:03PM +0200, Brice Goglin wrote:
> When I create a document (tried with localc and lowriter), the output
> file is created with mode 0644 (as expected from my umask 022). However,
> whenever I open such a file and save it again, it is changed to 0600.
> 
> Same issue with 6.1.1~rc1-1 from unstable and 6.1.0-1 from testing.
> I think this issue didn't exist a couple months ago, hence I'd say
> it appeared with the upgrading to LO 6, but I can't easily verify.

Sounds like https://bugs.documentfoundation.org/show_bug.cgi?id=119050;
confirmed by upstream on IRC.

Regards,

Rene

Bug#906012: libxcursor: CVE-2015-9262

[Bjoern]

On 27/08/18 18:22, Moritz Muehlenhoff wrote:

On Mon, Aug 27, 2018 at 05:40:01PM +0800, Bjoern wrote:

-- Begin Quote: --
From: Chris Lamb 
To: 906...@bugs.debian.org
Cc: t...@security.debian.org
Subject: Re: libxcursor: CVE-2015-9262
Date: Mon, 13 Aug 2018 08:18:27 +0100

[Message part 1 (text/plain, inline)]

Hi security team,


libxcursor: CVE-2015-9262


I have prepared an update for stretch:

   libxcursor (1:1.1.14-1+deb9u2) stretch-security; urgency=high

* Non-maintainer upload by the Security Team.
* Fix a denial of service or potentially code execution via
  a one-byte heap overflow. (CVE-2015-9262) Closes: #906012)

   -- Chris Lamb   Mon, 13 Aug 2018 09:09:13 +0200


Full debdiff attached. Permission to upload to stretch-security?
-- End Quote: 

Hi Chris & Security Team:

Has Chris' patch for "Stretch" gone to /dev/null ?

"Stretch"/stable remains exposed whilst old-stable, testing, and unstable
have been patched.

May I seek your enlightenment on this matter?


This turned out to be non-exploitable. A fix will be provided via the
stretch 9.6 point release.

Cheers,
 Moritz


Thanks for the reply Moritz.

Given the above, please would it be possible for someone to point me to 
the references I missed regarding the non-exploitable finding?


I welcome your advice.

Kindest regards,
Bjoern.

Bug#907478: hugo: FTBFS if asciidoc is installed but not asciidoctor

[Vincent Danjean]

Package: hugo
Version: 0.47.1-1
Severity: important
Tags: patch

  Hi,

  I was trying to rebuild hugo from the Debian source package.
  I got failures at test time (with error messages from asciidoc) and, on the 
net, I saw that asciidoctor is, in fact, required.

  I fixed the build failure just by installing the asciidoctor package (not 
removing the asciidoc one that was initially already installed)

  So, please, add 'asciidoctor' as a build-dependency to force this package to 
be installed.
I do not track the dependencies, but I suspect that one package depends on 
"asciidoctor | asciidoc", but asciidoc do not work with hugo tests.

  Regards,
Vincent

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

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

Versions of packages hugo depends on:
ii  libc6   2.27-5
ii  libgcc1 1:8.1.0-12
ii  libsass13.5.4+20180621~c0a6cf3-1
ii  libstdc++6  8.1.0-12

hugo recommends no packages.

hugo suggests no packages.

-- no debconf information

Bug#740981: elinks: Does not support SSL rehandshakes

[أحمد المحمودي]

On Tue, Aug 28, 2018 at 03:34:42PM +0200, أحمد المحمودي wrote:
> SSL auth. using client cert. finally worked for me using your patch on 
> Witold's felinks fork[1]. I just had to concatenate crt & key files to a 
> pem file and use that in elinks
> 
> [1] https://github.com/rkd77/felinks
---end quoted text---

Actually your patch is already in that fork

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#907451: libbiod FTBFS: Error: cannot implicitly convert expression

[Matthias Klumpp]

Am Di., 28. Aug. 2018 um 10:40 Uhr schrieb Andreas Tille :
>
> On Tue, Aug 28, 2018 at 10:12:32AM +0300, Adrian Bunk wrote:
> > Source: libbiod
> > Version: 0.1.0-5
> > Severity: serious
> > Tags: ftbfs
> >
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libbiod.html
> >
> > ...
> > [30/149] ldc2 -Ibiod@sha -I. -I.. -I -I../ -I/usr/include/d -enable-color 
> > -O -g -release -wi -relocation-model=pic   -of 
> > 'biod@sha/bio_maf_reader.d.o' -c ../bio/maf/reader.d
> > FAILED: biod@sha/bio_maf_reader.d.o
> > ldc2 -Ibiod@sha -I. -I.. -I -I../ -I/usr/include/d -enable-color -O -g 
> > -release -wi -relocation-model=pic   -of 'biod@sha/bio_maf_reader.d.o' -c 
> > ../bio/maf/reader.d
> > ../bio/maf/reader.d(40): Deprecation: struct `std.stdio.File.ByLine!(char, 
> > char).ByLine` is deprecated - Use .byLine
> > ../bio/maf/reader.d(53): Error: cannot implicitly convert expression 
> > `this._f.byLine(cast(Flag)true, '\x0a')` of type `ByLineImpl!(char, char)` 
> > to `ByLine!(char, char)`
> > ../bio/maf/reader.d(53):`this._lines = 
> > this._f.byLine(cast(Flag)true, '\x0a')` is the first assignment of 
> > `this._lines` therefore it represents its initialization
> > ../bio/maf/reader.d(53):`opAssign` methods are not used for 
> > initialization, but for subsequent assignments
> > [

Looks like an upstream issue - have you filed a bug there already?

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#797931: elinks: Does not support SSL rehandshakes

[أحمد المحمودي]

On Sat, Nov 18, 2017 at 02:39:14AM +0100, أحمد المحمودي wrote:
> This commit https://github.com/rkd77/felinks/commit/4c4717b82ae5eae 
> fixed GnuTLS rehandshake issue for me.
> Anyways I applied your GnuTLS client cert patch over it, and I still 
> can't get it to work.
---end quoted text---

SSL auth. using client cert. finally worked for me using your patch on 
Witold's felinks fork[1]. I just had to concatenate crt & key files to a 
pem file and use that in elinks

[1] https://github.com/rkd77/felinks


-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#907168: pytest-httpbin FTBFS with OpenSSL 1.1.1

[Pierre-Elliott Bécue]

Le samedi 25 août 2018 à 20:34:35+0200, Kurt Roeckx a écrit :
> This is caused by a Debian change to require a 2048 bit key by
> default instead of a 1024 bit key. Since this is just for a test,
> you can either just replace the certificates with larger keys,
> or lower the security level for the test from 2 to 1. I suggest
> you just create a new certificates.

Dear Kurt,

This would imply to do a Debian patch in upstream's source.

Do you think it's the best solution?

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#907477: maven-debian-helper: does not substitute values of plugins with maven.rules

[Markus Koschany]

Package: maven-debian-helper
Version: 2.3
Severity: normal


Currently mina2 version 2.0.16-2 fails to build from source because

Plugin org.apache.xbean:maven-xbean-plugin:4.1 or one of its
dependencies could not be resolved: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the
artifact org.apache.xbean:maven-xbean-plugin:jar:4.1 has not been
downloaded from it before.

I added a new rule to debian/maven.rules

org.apache.xbean maven-xbean-plugin * s/.*/4\.5/ * *

Expected behavior:

The version in src/pom.xml will be tranformed from 4.1 to 4.5.

Result:

Version is still 4.1

Ideally libxbean-java would provide a debian version of
maven-xbean-plugin but that's another story.

Markus

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages maven-debian-helper depends on:
ii  default-jdk 2:1.10-68
ii  default-jdk-headless2:1.10-68
ii  libmaven-clean-plugin-java  3.1.0-1
ii  libmaven-compiler-plugin-java   3.8.0-1
ii  libmaven-jar-plugin-java3.1.0-1
ii  libmaven-resources-plugin-java  3.1.0-1
ii  libmaven-site-plugin-java   3.6-3
ii  libplexus-velocity-java 1.2-3
ii  libsurefire-java2.21.0-1
ii  libxml2-utils   2.9.4+dfsg1-7+b1
ii  maven   3.5.3-1
ii  maven-repo-helper   1.9.3
ii  unzip   6.0-21
ii  velocity1.7-5

maven-debian-helper recommends no packages.

Versions of packages maven-debian-helper suggests:
ii  apt-file  3.1.6
pn  libmaven-javadoc-plugin-java  
pn  licensecheck  
ii  subversion1.10.2-1

-- no debconf information

Bug#906284: lintian: check for incomplete-creative-commons-license gives false positives: the "not a law firm" is a preamble, not a license

[Jonathan Dowland]

Interestingly, 307 is roughly half of all CC-license using packages,
based on the numbers I counted in #795402

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#906284: Too many false positives?

[Jonathan Dowland]

Hi folks, sorry for the delay in getting involved.

On Tue, Aug 28, 2018 at 07:43:46AM +0100, Chris Lamb wrote:

Perhaps just looking at the size of the license text (say < 20 lines)
would work better? I don't know perl at all, so I can't help write it,
but I would be quite surprised if that wasn't easy to do for someone
with a minimal knowledge of the language and the codebase.


Let's await Jonathan's input; it's obviously not ideal to have such a
false-positive prone tag.


It certainly looks like the current ratio is problematic, if Julien's
4/20 is representative. I started counting on a random pattern, and got
1/9 so far (slowed down by Salsa being down right now).

I like Julien's suggestion of just checking the total license length <20
or similar; but, I guess the best way to evaluate that change would be
to see how it would classify the 317 copyright files that are currently
flagged.

I'll see whether I can easily check that.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#907475: false-positive "source-is-missing" error

[Chris Lamb]

tags 907475 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/75a5b2d4ef35346200588ceaa8a4d26143f42195

  data/cruft/warn-file-type | 2 +-
  debian/changelog  | 4 
  2 files changed, 5 insertions(+), 1 deletion(-)


Regards,

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

Bug#907118: error:141a318a:ssl routines:tls_process_ske_dhe:dh key too small

[Antonio Terceiro]

On Thu, Aug 23, 2018 at 03:24:52PM -0600, dann frazier wrote:
> Package: bip
> Version: 0.8.9-1.1
> Severity: normal
> Tags: patch
> 
> I run bip on a stretch system, and connect to it from a hexchat client on
> sid. After a recent upgrade of the client, which pulled in openssl 1.1,
> hexchat began failing to connect to my server with the message:
> 
> error:141a318a:ssl routines:tls_process_ske_dhe:dh key too small
> 
> I found that backporting bip 0.9.0~rc3-1 to jessie worked. I further found
> that just cherry-picking the following commit back to bip 0.8.9 seems to be
> sufficient:
> 
>   39414f8 Handle OpenSSL version 1.1

I just tried backporting commit 39414f8 to the bip version in stretch,
and it doesn't really fix the issue. There is probably some other commit
that is needed.


signature.asc
Description: PGP signature

Bug#896171: parted wrongly identifies my msdos partition table as atari

[Franz Simader]

Hello,

I have the same problem as described in the Bug #896171.

A valid msdos partition table with 3 partitions is shown with parted 
(3.2-17) as 'atari' and only the first partition is visible.

Is there a solution for this known problem ?


With best regards.

Franz Simader

Bug#859234:

[Pablo Sánchez [gmail]]

Hi !
Bug seems to be present on armhf (raspberry pi model 3+) .

In /var/log/syslog I get :
...
Aug 28 00:04:34 raspberrypi systemd[1]: Started User Manager for UID 1001.
Aug 28 00:04:43 raspberrypi fbguard[449]: Time out waiting for fbserver
process start
Aug 28 00:04:43 raspberrypi systemd[1]: firebird3.0.service: Control
process exited, code=exited status=252
Aug 28 00:04:43 raspberrypi systemd[1]: firebird3.0.service: Failed with
result 'exit-code'.
Aug 28 00:04:43 raspberrypi systemd[1]: Failed to start Firebird Database
Server ( SuperServer ).
Aug 28 00:04:43 raspberrypi systemd[1]: Reached target Multi-User System.
Aug 28 00:04:43 raspberrypi systemd[1]: Reached target Graphical Interface.
...

Version is 3.0.3

ii  firebird3.0-common  3.0.3.32900.ds4-4
ii  firebird3.0-common-doc  3.0.3.32900.ds4-4
ii  firebird3.0-doc 3.0.3.32900.ds4-4
ii  firebird3.0-examples3.0.3.32900.ds4-4
ii  firebird3.0-server  3.0.3.32900.ds4-4
ii  firebird3.0-server-core:armhf   3.0.3.32900.ds4-4
ii  firebird3.0-utils   3.0.3.32900.ds4-4

I have to start the server manually.

Regards

Pablo Sánchez

Bug#907293: stops: Please consider making another upload and refreshing package

[Daniel James]

Hi Boyuan,

> I am not proposing to remove this package; instead I was proposing of having 
> MIA team involved and (orphan this package) / (have other maintainers taken 
> this package care of)

That should not be necessary since it is maintained by
debian-multimedia. I agree it needs a rebuild now, even if the version
stays at 0.3.0.

> I thought stops might be eligible to such
> arrangement since it received no upload in the past 11 years, which is No.3 
> oldest (!) package in the Debian archive.

Let's aim for No. 1 by the year 2028 :-)

Cheers!

Daniel

Bug#907293: stops: Please consider making another upload and refreshing package

[Boyuan Yang]

在 2018年8月28日星期二 EDT 上午6:56:13，Sebastian Ramacher 写道：
> Hi Boyuan
> 
> On 2018-08-28 10:49:48, Daniel James wrote:
> > Hi Boyuan,
> > 
> > > Dear stops maintainer (Hi Free Ekanayaka)
> > 
> > Maintainer for this package is Debian Multimedia Team, it's just that
> > Free was the last uploader.
> > 
> > > I was cleaning up packages that hasn't receive any upload in Debian for
> > > a long time and noticed that your package, stops, received no upload
> > > since 2007, which is quite a long period of time.
> > 
> > As I recall, this package is static data, and may not ever need to be
> > updated upstream. Debian's version 0.3.0 is still the current release:
> > http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html
> > 
> > stops is a dependency of the active package
> > https://packages.debian.org/sid/aeolus which has a new upstream release
> > available (0.9.7).
> > 
> > > Making uploads to stops might be necessary according to [1] since we
> > > want to make Debian 100% reproducible in the future [2] and all
> > > packages built before December 2016 will need a rebuild.
> > 
> > Sounds good! Also #888669 might need looking at. I am not a Debian
> > Developer but happy to help if I can find a sponsor.
> > 
> > > I am also considering initiating the MIA procedure[3] (targeting
> > > package only, not to the person because I know you look still active) if
> > > there's no reply after certain period of time
> > 
> > Hopefully that will not be necessary, aeolus is a unique software
> > instrument and it would be a shame to lose it from Debian.
> 
> The MIA procedure is for maintainers and not for packages. So I am not sure
> what the intended goal is. Do you want to get get stops removed from the
> archive? I would find asking for removal of packages maintainer by other
> people that do not have an RC bug and have not been superseded rather
> inappropriate.

I am not proposing to remove this package; instead I was proposing of having 
MIA team involved and (orphan this package) / (have other maintainers taken 
this package care of) since monitoring packages that receive little care is 
also part of QA/MIA Team's job. I thought stops might be eligible to such 
arrangement since it received no upload in the past 11 years, which is No.3 
oldest (!) package in the Debian archive. The reproducible-builds project as 
mentioned above is also another reason of having the package rebuilt.

My personal idea is that packages in Debian should ideally be rebuilt every 
few years (or at least definitely every 10 years) since the packaging 
technology and .deb package formats are all evolving. I'm happy to provide 
with any kind of help that you might find necessary (including NMUs) but a 
concent from previous maintainers / uploaders will make the procedure more 
smoothly.

--
Regards,
Boyuan Yang

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

Bug#907476: libreoffice: file permissions are changed to 0600 when re-saving

[Brice Goglin]

Package: libreoffice
Version: 1:6.1.1~rc1-1
Severity: normal

Dear Maintainer,

When I create a document (tried with localc and lowriter), the output
file is created with mode 0644 (as expected from my umask 022). However,
whenever I open such a file and save it again, it is changed to 0600.

Same issue with 6.1.1~rc1-1 from unstable and 6.1.0-1 from testing.
I think this issue didn't exist a couple months ago, hence I'd say
it appeared with the upgrading to LO 6, but I can't easily verify.

Thanks
Brice

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

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

Versions of packages libreoffice depends on:
ii  libreoffice-avmedia-backend-gstreamer  1:6.1.1~rc1-1
ii  libreoffice-base   1:6.1.1~rc1-1
ii  libreoffice-calc   1:6.1.1~rc1-1
ii  libreoffice-core   1:6.1.1~rc1-1
ii  libreoffice-draw   1:6.1.1~rc1-1
ii  libreoffice-impress1:6.1.1~rc1-1
ii  libreoffice-math   1:6.1.1~rc1-1
ii  libreoffice-report-builder-bin 1:6.1.1~rc1-1
ii  libreoffice-writer 1:6.1.1~rc1-1
ii  python3-uno1:6.1.1~rc1-1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-7
ii  fonts-liberation2   2.00.1-7
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-hinted   20171026-2
ii  fonts-noto-mono 20171026-2
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.1.1~rc1-1
ii  libreoffice-librelogo   1:6.1.0-1
ii  libreoffice-nlpsolver   0.9+LibO6.1.0-1
ii  libreoffice-ogltrans1:6.1.1~rc1-1
ii  libreoffice-report-builder  1:6.1.1~rc1-1
ii  libreoffice-script-provider-bsh 1:6.1.1~rc1-1
ii  libreoffice-script-provider-js  1:6.1.1~rc1-1
ii  libreoffice-script-provider-python  1:6.1.1~rc1-1
ii  libreoffice-sdbc-postgresql 1:6.1.1~rc1-1
ii  libreoffice-wiki-publisher  1.2.0+LibO6.1.0-1

Versions of packages libreoffice suggests:
ii  cups-bsd2.2.8-5
ii  default-jre [java6-runtime] 2:1.10-68
ii  firefox 61.0.1-1
ii  firefox-esr 52.9.0esr-1
ii  ghostscript 9.22~dfsg-2.1
ii  gnupg   2.2.9-1
pn  gpa 
ii  gstreamer1.0-libav  1.15.0.1+git20180723+db823502-1
ii  gstreamer1.0-plugins-bad1.14.2-1
ii  gstreamer1.0-plugins-base   1.14.2-1
ii  gstreamer1.0-plugins-good   1.14.2-1
ii  gstreamer1.0-plugins-ugly   1.14.2-1
ii  hunspell-en-us [hunspell-dictionary]1:2018.04.16-1
ii  hunspell-fr-classical [hunspell-dictionary  1:6.2-1
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-5
ii  imagemagick 8:6.9.10.8+dfsg-1
ii  imagemagick-6.q16 [imagemagick] 8:6.9.10.8+dfsg-1
ii  libgl1  1.1.0-1
pn  libreoffice-gnome | libreoffice-kde5
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
pn  libreoffice-officebean  
pn  libsane1
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
ii  mythes-en-us [mythes-thesaurus] 1:6.1.0~rc2-2
pn  openclipart2-libreoffice | openclipart-lib  
ii  openjdk-10-jre [java6-runtime]  10.0.2+13-1
ii  openjdk-8-jre [java6-runtime]   8u171-b11-2
ii  openjdk-9-jre [java6-runtime]   9.0.4+12-4
pn  pstoedit
ii  thunderbird 1:52.9.1-1
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.0-5
ii  fonts-opensymbol  2:102.10+LibO6.1.0-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-8
ii  libboost-locale1.62.0 1.62.0+dfsg-8
ii  libc6 2.27-5
ii  libcairo2 1.15.12-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v5

Bug#907475: false-positive "source-is-missing" error

[Mo Zhou]

Package: lintian
Version: 2.5.98
Severity: normal
Justification: lintian requests a bug report

I got the following lintian E while building the source package
for tensorflow. The false-positive is requested by the lintian message.

This lintian report can be reproduced from this git repo:
g...@salsa.debian.org:science-team/tensorflow.git
 - ca0222be25424bc939da9281b747851bcc0f2591

E: tensorflow source: source-is-missing 
tensorflow/compiler/aot/codegen_test_o.golden
N: 
N:The source of the following file is missing. Lintian checked a few
N:possible paths to find the source, and did not find it.
N:
N:Please repack your package to include the source or add it to
N:"debian/missing-sources" directory.
N:
N:If this is a false-positive, please report a bug against Lintian.
N:
N:Please note, that insane-line-length-in-source-file tagged files are
N:likely tagged source-is-missing. It is a feature not a bug.
N:
N:Severity: serious, Certainty: possible
N:
N:Check: cruft, Type: source

Bug#860534: drm/radeon: Change the default to PCI on PowerPC

[Mathieu Malaterre]

Control: tags -1 fixed-upstream patch upstream

The symptoms should disappear now that default has been set to PCI
(instead of AGP) on PowerPC system.

https://github.com/torvalds/linux/commit/037d1a66ae64

Target is 4.18-rc1

https://lkml.org/lkml/2018/6/5/1158

Bug#907358: ncbi-vdb: fix broken library on i386

[Adrian Bunk]

On Sun, Aug 26, 2018 at 03:04:40PM -0700, Steve Langasek wrote:
>...
> It would also be perfectly reasonable to drop i386 as a supported
> architecture for ncbi-vdb if you prefer; but I suggest you then make sure to
> actually do this, rather than shipping a broken library package on i386.
>...

Additionally, there is a baseline violation on i386:
https://sources.debian.org/src/ncbi-vdb/2.9.1-1+dfsg-1/debian/patches/add_-msse2.patch/

The userbase of this package on i386 is likely zero, so setting 
  Architecture: amd64
would IMHO be the best way forward.

> Cheers,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#893817: salt-common: fails to install with Python 3.7

[Nicolas Braud-Santoni]

tag 904654 + upstream fixed-upstream
forward 904654 https://github.com/saltstack/salt/issues/48556

tag 893817 - fixed-upstream
forward 893817 https://github.com/saltstack/salt-jenkins/issues/995
thanks


Hi,

Just updating the bugs metadata  ;)

#904654 is fixed in upstream's 2018.3.3, to be released soon,
but #893817 still isn't fixed under Python 3  :(


Best,

  nicoo

On Fri, Aug 24, 2018 at 03:08:24PM +0200, Daniel Dehennin wrote:
> Hello.
> 
> I think the best thing to do is to update to the latest version
> 
> https://github.com/saltstack/salt/issues/48556
> 
> Regards.
> -- 
> Daniel Dehennin
> Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
> Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF




signature.asc
Description: PGP signature

Bug#907474: Insufficient Build-Depends libglib2.0-dev (>= 2.50.0), should be (>= 2.56.0)

[Mattias Ellert]

Source: libglibmm2.4
Version: 2.56.0-2
Severity: important

The builds of glibmm2.4 2.56.0-2 on kfreebsd-amd64 and kfreebsd-i386
failed with:

error: 'g_application_set_option_context_parameter_string' was not
declared in this scope

According to
https://developer.gnome.org/gio/stable/GApplication.html#g-application-set-option-context-parameter-string
g_application_set_option_context_parameter_string is available since
glib2.0 vesrion 2.56.

However, the glibmm2.4 2.56.0-2 on kfreebsd-amd64 and kfreebsd-i386
were attempted using glib2.0 version 2.54:

Selecting previously unselected package libglib2.0-dev:kfreebsd-amd64.
Preparing to unpack .../90-libglib2.0-dev_2.54.2-1_kfreebsd-amd64.deb ...
Unpacking libglib2.0-dev:kfreebsd-amd64 (2.54.2-1) ...

The Build-Depends in the glibmm2.4 source package states
libglib2.0-dev (>= 2.50.0), which is insufficient and should be changed
to libglib2.0-dev (>= 2.56.0) to make sure that
g_application_set_option_context_parameter_string is available.

Mattias



smime.p7s
Description: S/MIME cryptographic signature

Bug#907120: nm.debian.org: somehow it's possible to link a key already linked to another user

[Pierre-Elliott Bécue]

Le vendredi 24 août 2018 à 00:05:35+0200, Mattia Rizzolo a écrit :
> Package: nm.debian.org
> Severity: important
> 
> I don't quite understand how it happened, nor I tried to reproduce, but
> HAYASHI Kentaro managed to create a new account on nm.d.o and link to it
> a gpg key (D92025640886D27D14A9EE02D22C1A883455D448) that was already
> linked to another account with different uid (kenhys) and email.
> 
> This caused a lot of grief in the housekeeping job:
> |2018-08-23 21:47:28,907 ERROR dsa.NewGuestAccountsFromDSA: run_main failed
> |Traceback (most recent call last):
> |  File "/srv/nm.debian.org/nm2/django_housekeeping/run.py", line 206, in 
> run_task
> |method(self)
> |  File "/usr/lib/python3.5/contextlib.py", line 30, in inner
> |return func(*args, **kwds)
> |  File "/srv/nm.debian.org/nm2/dsa/housekeeping.py", line 43, in run_main
> |format_person=self.hk.link,
> |  File "/srv/nm.debian.org/nm2/backend/models.py", line 212, in 
> get_from_other_db
> |format_person(person), match_type, match_value))
> |backend.models.MultipleObjectsReturned: LDAP has fingerprint 
> D92025640886D27D14A9EE02D22C1A883455D448, which corresponds to two different 
> users in our db: https://nm.debian.org/person/kenhys (by uid kenhys) and 
> https://nm.debian.org/person/ken...@gmail.com (by fingerprint 
> D92025640886D27D14A9EE02D22C1A883455D448)
> 
> Plus it seemed to have caused some oddities around the website as well,
> e.g. the keycheck for https://nm.debian.org/process/531 looked
> inconsistent as he didn't report some signatures apparently.
> 
> Note that I've now mangled the users around, so the links in the
> traceback aren't really valid anymore, plus the situation is solved in
> the production website.  But still it shouldn't have allowed this
> situation to happen at all, so I'm reporting this bug.

I gave a look at this, and I think I have an explaination. Please mind that
I had no access to any DB, so I'm trying to deduce from what Mattia told me,
from this bug, and from nm.d.o's code.

It's plausible that kenhys created a NM user with his email address
@clear-code.com but didn't add the GPG fpr.

In a parallel shot, he got a guest account and added his FPR in the LDAP
database.

Then, he decided to become DM, and forgot about his old account. He decided
to create a new one, and got the uid/email problem, but the FPR being not
reserved, he succeeded at requesting it in nm.d.o.

Then the hk job extracted data from LDAP, and as it searches in the nm.d.o
db with a "or" clause (get_from_other_db searches against each and every
field one after another), it found two accounts, the old one, via the uid,
and the new one, via the fingerprint.

I don't think there's a way to prevent such things to happen, as it's a
dual-db inconsistency, except if you consider the (rather brutal) solution
where the HK job adds the missing data to a nm.d.o account from LDAP
entries.

---

Mattia, it seems there is no way for two accounts to share a fingerprint.
The FPR value is set to unique since the beginning of the django project,
and there's a ForeignKey for the person linked to the Fingerprint object.
Hence, I'm pretty sure there was no fpr on the uid=kenhys account on nm.d.o.

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#907473: bash: problems with relative bin in PATH

[fc]

Package: bash
Version: 4.4.18-3.1
Severity: normal
Tags: upstream

It should be summarized in the following excerpt:
0% bash
[fc@fulvio ~]$ echo $PATH
.:bin:/home/fc/bin:/home/fc/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin
[fc@fulvio ~]$ cd /
[fc@fulvio /]$ ls
backup  bin  boot  dev  etc  home  initrd.img  initrd.img.old  lib  lib32  
lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  store  sys  tmp 
 usr  var  vmlinuz  vmlinuz.old
[fc@fulvio /]$ cd /usr/bin/
[fc@fulvio bin]$ ls
bash: bin/ls: No such file or directory
[fc@fulvio bin]$ 

After visiting / and calling ls, bash thinks that ls is in bin/ls, the same 
with any other command.
This does not happen with . or any other relative directory, only with bin.

Fulvio

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

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 bash depends on:
ii  base-files   10.1
ii  debianutils  4.8.6
ii  libc62.27-5
ii  libtinfo66.1+20180714-1

Versions of packages bash recommends:
ii  bash-completion  1:2.8-1

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#357363: libcrypt-cbc-perl: Crypt::CBC uses 8 bits salt for 16 bits ciphers

[Xavier]

According to upstream response, this issue is not considered as a bug.
At least we should decrease severity, shouldn't we ?

Bug#907293: stops: Please consider making another upload and refreshing package

[Sebastian Ramacher]

Hi Boyuan

On 2018-08-28 10:49:48, Daniel James wrote:
> Hi Boyuan,
> > Dear stops maintainer (Hi Free Ekanayaka)
> 
> Maintainer for this package is Debian Multimedia Team, it's just that
> Free was the last uploader.
> 
> > I was cleaning up packages that hasn't receive any upload in Debian for a 
> > long 
> > time and noticed that your package, stops, received no upload since 2007, 
> > which is quite a long period of time.
> 
> As I recall, this package is static data, and may not ever need to be
> updated upstream. Debian's version 0.3.0 is still the current release:
> http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html
> 
> stops is a dependency of the active package
> https://packages.debian.org/sid/aeolus which has a new upstream release
> available (0.9.7).
> 
> > Making uploads to stops might be necessary according to [1] since we want 
> > to 
> > make Debian 100% reproducible in the future [2] and all packages built 
> > before 
> > December 2016 will need a rebuild.
> 
> Sounds good! Also #888669 might need looking at. I am not a Debian
> Developer but happy to help if I can find a sponsor.
> 
> > I am also considering initiating the MIA procedure[3] (targeting 
> > package only, not to the person because I know you look still active) if 
> > there's no reply after certain period of time
> 
> Hopefully that will not be necessary, aeolus is a unique software
> instrument and it would be a shame to lose it from Debian.

The MIA procedure is for maintainers and not for packages. So I am not sure what
the intended goal is. Do you want to get get stops removed from the archive? I
would find asking for removal of packages maintainer by other people that do not
have an RC bug and have not been superseded rather inappropriate.

Best
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#907472: ITP: golang-github-google-go-github -- Go library for accessing the GitHub API

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-google-go-github
  Version : 18.0.0+git20180828.0780c36-1
  Upstream Author : Google
* URL : https://github.com/google/go-github
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go library for accessing the GitHub API

 go-github is a Go client library for accessing the GitHub API v3
 (https://developer.github.com/v3/).


This package is required for the new upstream version of dh-make-golang.

Regards,
Tobias




signature.asc
Description: OpenPGP digital signature

Bug#907471: sysstat: segfault when reading very long entries in /etc/mtab

[dr4Ke]

Package: sysstat
Version: 11.4.3-2
Severity: important

Dear Maintainer,

* What led up to the situation?
Running some docker containers inserts very long entries in /etc/mtab.
The program sadc is crashing with a segmentation fault with these.

* Upstream bug
This bug was reported upstream [1] and corrected in v11.4.7.
Please consider updating the package in the stable dist.

[1] https://github.com/sysstat/sysstat/issues/162



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

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

Versions of packages sysstat depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3
ii  libsensors41:3.4.0-4
ii  lsb-base   9.20161125
ii  ucf3.0036
ii  xz-utils   5.2.2-1.2+b1

Versions of packages sysstat recommends:
ii  cron [cron-daemon]  3.0pl1-128+deb9u1

Versions of packages sysstat suggests:
pn  isag  

-- debconf information:
  sysstat/enable: false
  sysstat/remove_files: true

Bug#907380: tex-common: setting up of tex-common fails

[fulvio ciriaco]

Dear Norbert,
it turned out that dpkg-reconfigure has a problem with my PATH, i.e.
my path is prepended with:
PATH=.:bin:{{other dirs}}
when I modified it into PATH=.:{{other dirs}} dpkg had no more
problems.
My guess is that all this came out with the last version of bash,
upgraded just a few days ago.
In fact, if I try to run update-updmap from directory / as probably
dpkg is doing, with bin inside my path I obtain:

root@fulvio:/# echo $PATH
bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin
root@fulvio:/# update-updmap 
Regenerating '/var/lib/texmf/updmap.cfg-DEBIAN'... done.
/usr/sbin/update-updmap: line 235: bin/mkdir: No such file or directory

wow, lots of problems with bin in the path:
root@fulvio:/# cd /usr/sbin
root@fulvio:/usr/sbin# ls
bash: bin/ls: No such file or directory

ok, nothing to do with tex-common anyhow, sorry.

Fulvio

On Tue, 28 Aug 2018 12:16:07 +0200,
Norbert Preining wrote:
> 
> Hi,
> 
> > root@fulvio:/home/fc# dpkg --configure tex-common
> 
> That doesn't work for me at all:
> $ dpkg --configure tex-common
> dpkg: error processing package tex-common (--configure):
>  package tex-common is already installed and configured
> Errors were encountered while processing:
>  tex-common
> $ 
> 
> But I tried dpkg-reconfigure which should do the same:
> $ dpkg-reconfigure tex-common
> Running mktexlsr. This may take some time... done.
> Running mtxrun --generate. This may take some time... done.
> Running updmap-sys. This may take some time... done.
> Running mktexlsr /var/lib/texmf ... done.
> Building format(s) --all.
>   This may take some time... done.
> $
> 
> Can you please edit
>   /var/lib/dpkg/info/tex-common.postinst
> and add a
>   set -x
> near the top, then call dpkg --configure again and send the output,
> probably capturing it with tee or similar method.
> 
> Thanks.
> 
> Norbert
> 
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. +JAIST +TeX Live +Debian Developer
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#907470: fprint-demo FTBFS: error: dereferencing pointer to incomplete type 'struct fp_minutia'

[Adrian Bunk]

Source: fprint-demo
Version: 20080303git-6
Severity: serious
Tags: buster sid ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fprint-demo.html

...
verify.c: In function 'plot_minutiae':
verify.c:239:29: error: dereferencing pointer to incomplete type 'struct 
fp_minutia'
   size_t pixel_offset = (min->y * width) + min->x;
 ^~

Bug#907465: [Pkg-telepathy-maintainers] Bug#907465: telepathy-idle: Please update Uploaders, Vcs-*, etc. or remove

[Sjoerd Simons]

On Tue, 2018-08-28 at 10:51 +0100, Simon McVittie wrote:
> Source: telepathy-idle
> Version: 0.2.0-2
> Severity: normal
> 
> telepathy-idle still lists me and Jonny Lamb in its Uploaders; we
> removed
> ourselves from Uploaders in the VCS in 2014 and 2016 respectively.
> The
> package's metadata also still refers to Alioth, and its Standards-
> Version
> says it has not been checked for compliance with post-2013 Policy.
> Please
> update this package.
> 
> Alternatively, since Telepathy appears to be essentially dead
> upstream,
> perhaps this package should be removed? (This would have to be
> coordinated
> with the maintainer of polari.)

And this is how i do IRC; so nope please don't removed. 

Bug#907463: [Pkg-telepathy-maintainers] Bug#907463: telepathy-rakia: Please update Uploaders, Vcs-*, etc. or remove

[Sjoerd Simons]

On Tue, 2018-08-28 at 10:48 +0100, Simon McVittie wrote:
> Source: telepathy-rakia
> Version: 0.8.0-3
> Severity: normal
> 
> telepathy-spec still lists me and Jonny Lamb in its Uploaders; we
> removed
> ourselves from Uploaders in the VCS in 2014 and 2016 respectively.
> The
> package's metadata also still refers to Alioth, and its Standards-
> Version
> says it has not been checked for compliance with post-2013 Policy.
> Please
> update this package.
> 
> Alternatively, since Telepathy appears to be essentially dead
> upstream,
> perhaps this package should be removed?

Rakia is how i make daily SIP calls; so no really shouldn't be removed
;)

Bug#830076: Tests fail when testing installed package

[Bálint Réczey]

Control: fixed -1 1.0.5-1

Christian Hofstaedtler  ezt írta (időpont: 2016. júl.
5., K, 23:57):
>
> Package: ruby-concurrent
> Version: 1.0.0-1
> Severity: important
> X-Debbugs-CC: debian-r...@lists.debian.org
>
> Dear Maintainer,
>
> your package tests fail when testing the installed package:
>
> adt-run [02:47:32]: test command1: gem2deb-test-runner --autopkgtest 
> --check-dependencies 2>&1
> adt-run [02:47:32]: test command1: [---
>
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby2.3  
>  │
> └──┘
>
> /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:120:in `load_gemspec': More 
> than one .gemspec file in this directory: concurrent-ruby-edge.gemspec, 
> concurrent-ruby-ext.gemspec, concurrent-ruby.gemspec (RuntimeError)
> from /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:33:in `block in 
> initialize'
> from /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:32:in `chdir'
> from /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:32:in `initialize'
> from /usr/lib/ruby/vendor_ruby/gem2deb/test_runner.rb:77:in `new'
> from /usr/lib/ruby/vendor_ruby/gem2deb/test_runner.rb:77:in 
> `do_check_dependencies'
> from /usr/lib/ruby/vendor_ruby/gem2deb/test_runner.rb:67:in 
> `run_tests'
> from /usr/bin/gem2deb-test-runner:61:in `'
> adt-run [02:47:33]: test command1: ---]
> adt-run [02:47:33]: test command1:  - - - - - - - - - - results - - - - - - - 
> - - -

This looks like to be fixed, CI is passing.

Cheers,
Balint

Bug#907469: plasma-workspace: When many windows are merged on a list on the task manager, you can't scroll that list

[nikomartn]

Package: plasma-workspace
Version: 4:5.8.6-2.1+deb9u1
Severity: normal

Dear Maintainer,

It's my first bug report, I hope I'm doing it all right, my apologies
otherwise.

At least with a monitor of 1366x768 (with bigger screens, probably more items
of the list will be visible), when more than 10 windows of the same program are
open and the task manager merge them on a list, it's impossible to scroll down
that list to select a window that cannot be seen.
Tried with multiple instances of libreoffice and dolphin.

I've tried to scroll down with the mouse:
The list either collapses or the non desired window under the mouse
opens

when using the arrow keys:
The name of the window selected cannot be seen, therefore it's
impossible to open the desired window.

This problem has been seen on two of my computers with the same packages.




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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x11 1.10.26-0+deb9u1
ii  frameworkintegration 5.28.0-1
ii  gdb  7.12-6
ii  iso-codes3.75-1
ii  kactivitymanagerd5.8.4-1
ii  kde-cli-tools4:5.8.4-2
ii  kded55.28.0-1
ii  kinit5.28.0-1
ii  kio  5.28.0-2
ii  kpackagetool55.28.1-1
ii  libc62.24-11+deb9u3
ii  libcln6  1.3.4-2+b1
ii  libdbusmenu-qt5-20.9.3+16.04.20160218-1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgps22 3.16-4
ii  libice6  2:1.0.9-2
ii  libkf5activities55.28.0-1
ii  libkf5auth5  5.28.0-2
ii  libkf5baloo5 5.28.0-2
ii  libkf5bookmarks5 5.28.0-1
ii  libkf5calendarevents55.28.0-1
ii  libkf5completion55.28.0-1
ii  libkf5configcore55.28.0-2
ii  libkf5configgui5 5.28.0-2
ii  libkf5configwidgets5 5.28.0-2
ii  libkf5coreaddons55.28.0-2
ii  libkf5crash5 5.28.0-1
ii  libkf5dbusaddons55.28.0-1
ii  libkf5declarative5   5.28.0-1
ii  libkf5globalaccel-bin5.28.0-1
ii  libkf5globalaccel5   5.28.0-1
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5holidays5  16.04.2-1
ii  libkf5i18n5  5.28.0-2
ii  libkf5iconthemes55.28.0-2
ii  libkf5idletime5  5.28.0-1
ii  libkf5itemviews5 5.28.0-1
ii  libkf5jobwidgets55.28.0-2
ii  libkf5js55.28.0-1
ii  libkf5jsembed5   5.28.0-1
ii  libkf5kdelibs4support5   5.28.0-1
ii  libkf5kiocore5   5.28.0-2
ii  libkf5kiofilewidgets55.28.0-2
ii  libkf5kiowidgets55.28.0-2
ii  libkf5networkmanagerqt6  5.28.0-2
ii  libkf5newstuff5  5.28.0-1
ii  libkf5notifications5 5.28.0-1
ii  libkf5notifyconfig5  5.28.0-1
ii  libkf5package5   5.28.1-1
ii  libkf5plasma55.28.0-2
ii  libkf5plasmaquick5   5.28.0-2
ii  libkf5quickaddons5   5.28.0-1
ii  libkf5runner55.28.0-1
ii  libkf5service-bin5.28.0-1
ii  libkf5service5   5.28.0-1
ii  libkf5solid5 5.28.0-3
ii  libkf5texteditor55.28.0-2
ii  libkf5textwidgets5   5.28.0-1
ii  libkf5wallet-bin 5.28.0-3
ii  libkf5wallet55.28.0-3
ii  libkf5waylandclient5 4:5.28.0-1
ii  libkf5widgetsaddons5 5.28.0-3
ii  libkf5windowsystem5  5.28.0-2
ii  libkf5xmlgui55.28.0-1
ii  libkf5xmlrpcclient5  5.28.0-1
ii  libkscreenlocker55.8.6-2
ii  libksgrd74:5.8.4-1
ii  libkworkspace5-5   

Bug#907468: mention what filesystem type was created

[積丹尼 Dan Jacobson]

Package: e2fsprogs
Version: 1.44.4-2
Severity: wishlist

I would mention what type (ext2) was created too here:

# mke2fs /dev/sdd1
Creating filesystem with 14976 1k blocks and 3744 inodes
Filesystem UUID: 28ceb29f-4ab4-439a-bbe3-5d986422d7da
Superblock backups stored on blocks:
8193

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

Certainly mentioning "ext2" is just as important as those other items.

Bug#907467: ufraw-batch: NULL dereference in ufraw_batch_messenger

[Jaeseung Choi]

Package: ufraw-batch
Version: 0.22-1.1
Severity: normal

Dear Maintainer,

Running ufraw-batch with the attached poc file raises a NULL dereference
crash in ufraw_batch_messenger() function.

Following gdb log shows the program crashing with segfault.

jason@debian-amd64-stretch:~/report/source-latest/ufraw$ gdb
./ufraw-llvm/ufraw-batch -q
Reading symbols from ./ufraw-llvm/ufraw-batch...done.
(gdb) run --overwrite poc-null
Starting program:
/home/jason/report/source-latest/ufraw/ufraw-llvm/ufraw-batch --overwrite
poc-null
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) where
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x0041eee9 in ufraw_batch_messenger (message=0x0) at
ufraw_message.c:126
#2  0x0041f0b3 in ufraw_message (code=1, format=) at
ufraw_message.c:190
#3  0x00409f93 in ufraw_load_raw (uf=0x80ec60) at ufraw_ufraw.c:668
#4  0x004090d4 in main (argc=, argv=)
at ufraw-batch.c:85
(gdb) x/i $rip
=> 0x75683676 :  movdqu (%rax),%xmm4
(gdb) info reg rax
rax0x0  0


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
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 ufraw-batch depends on:
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-11+deb9u3
ii  libexiv2-14  0.25-3.1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libgomp1 6.3.0-18+deb9u1
ii  libjpeg62-turbo  1:1.5.1-2
ii  liblcms2-2   2.8-4
ii  liblensfun1  0.3.2-3
ii  libpng16-16  1.6.28-1
ii  libstdc++6   6.3.0-18+deb9u1
ii  libtiff5 4.0.8-2+deb9u2
ii  zlib1g   1:1.2.8.dfsg-5

ufraw-batch recommends no packages.

Versions of packages ufraw-batch suggests:
pn  ufraw  

-- no debconf information


poc_null
Description: Binary data

Bug#907293: stops: Please consider making another upload and refreshing package

[Daniel James]

Hi Boyuan,
> Dear stops maintainer (Hi Free Ekanayaka)

Maintainer for this package is Debian Multimedia Team, it's just that
Free was the last uploader.

> I was cleaning up packages that hasn't receive any upload in Debian for a 
> long 
> time and noticed that your package, stops, received no upload since 2007, 
> which is quite a long period of time.

As I recall, this package is static data, and may not ever need to be
updated upstream. Debian's version 0.3.0 is still the current release:
http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html

stops is a dependency of the active package
https://packages.debian.org/sid/aeolus which has a new upstream release
available (0.9.7).

> Making uploads to stops might be necessary according to [1] since we want to 
> make Debian 100% reproducible in the future [2] and all packages built before 
> December 2016 will need a rebuild.

Sounds good! Also #888669 might need looking at. I am not a Debian
Developer but happy to help if I can find a sponsor.

> I am also considering initiating the MIA procedure[3] (targeting 
> package only, not to the person because I know you look still active) if 
> there's no reply after certain period of time

Hopefully that will not be necessary, aeolus is a unique software
instrument and it would be a shame to lose it from Debian.

Cheers!

Daniel

Bug#907380: tex-common: setting up of tex-common fails

[Norbert Preining]

Hi,

> root@fulvio:/home/fc# dpkg --configure tex-common

That doesn't work for me at all:
$ dpkg --configure tex-common
dpkg: error processing package tex-common (--configure):
 package tex-common is already installed and configured
Errors were encountered while processing:
 tex-common
$ 

But I tried dpkg-reconfigure which should do the same:
$ dpkg-reconfigure tex-common
Running mktexlsr. This may take some time... done.
Running mtxrun --generate. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... done.
$

Can you please edit
/var/lib/dpkg/info/tex-common.postinst
and add a
set -x
near the top, then call dpkg --configure again and send the output,
probably capturing it with tee or similar method.

Thanks.

Norbert

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

Bug#907345: After upgrading from 5.10.1+dfsg-6 to 5.10.1+dfsg-7 akonadi imap stops working - possibly OpenSSL 1.1.1

[Wolfgang Walter]

Am Montag, 27. August 2018, 23:02:35 schrieben Sie:
> Hey,
> 
> > I think this bug-report can be closed.
> 
> you can do this by your own if you send a mail at
> 907345-d...@bugs.debian.org.
> > The problems disappears if openssl is also upgraded to version
> > 1.1.1~~pre9-1 (from 1.1.0h-4). So this problem only exists with openssl <
> > 1.1.1~~pre9-1.
> Wait - this is all very strange you say you have Qt 5.10.1+dfsg-6 installed
> and OpenSSL 1.1.1~~pre9-1.

Hmm, I'm afraid I wanted to write 5.11.1+dfsg-6 to 5.11.1+dfsg-7

Don't know why I typed 5.10, sorry for that.

So the problem was:

I upgraded libqt5core5a etc. from 5.11.1+dfsg-6 to 5.11.1+dfsg-7 but I did not 
upgrade openssl from 1.1.0h-4 to 1.1.1~~pre9-1, then. Under these conditions 
akonadi failed to access the imap server via TLS.

After also upgrading openssl from 1.1.0h-4 to 1.1.1~~pre9-1 akonadi worked 
again.

Regards and sorry for the wrong version numbers.
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Bug#907466: Package doesn't ship xml files anymore

[Laurent Bigonville]

Package: iso-codes
Version: 4.0-1
Severity: serious

Hi,

Since 4.0-1, iso-codes package is not shipping the xml files anymore:

   * New upstream version 4.0
 - This new release does no longer include the XML data files.
   Please use the JSON data files from now on.

This causes at least one other package to break (gnome-software)

Could you please check the package that are actually using the xml files
and help them to transition to the JSON ones?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

iso-codes depends on no packages.

iso-codes recommends no packages.

Versions of packages iso-codes suggests:
pn  isoquery  

-- no debconf information

Bug#907465: telepathy-idle: Please update Uploaders, Vcs-*, etc. or remove

[Simon McVittie]

Source: telepathy-idle
Version: 0.2.0-2
Severity: normal

telepathy-idle still lists me and Jonny Lamb in its Uploaders; we removed
ourselves from Uploaders in the VCS in 2014 and 2016 respectively. The
package's metadata also still refers to Alioth, and its Standards-Version
says it has not been checked for compliance with post-2013 Policy. Please
update this package.

Alternatively, since Telepathy appears to be essentially dead upstream,
perhaps this package should be removed? (This would have to be coordinated
with the maintainer of polari.)

Thanks,
smcv

Bug#907464: x264: NULL dereference crash

[Jaeseung Choi]

Package: x264
Version: 2:0.148.2748+git97eaef2-1
Severity: normal

Dear Maintainer,

Running x264 with the attached poc file raises a NULL dereference crash.

Following gdb log shows the program resulting in segfault.

jason@debian-amd64-stretch:~/report/debian-latest/x264$ gdb x264 -q
Reading symbols from x264...(no debugging symbols found)...done.
(gdb) run -o output.264 poc_null
Starting program: /usr/bin/x264 -o output.264 poc_null
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x76abad0b in ?? () from /usr/lib/x86_64-linux-gnu/libavformat.so.57
(gdb) x/i $rip
=> 0x76abad0b:  mov(%rdx,%rax,8),%rdx
(gdb) info reg rax rdx
rax0x0  0
rdx0x0  0
(gdb) where
#0  0x76abad0b in ?? () from
/usr/lib/x86_64-linux-gnu/libavformat.so.57
#1  0x76b3e2fd in ?? () from
/usr/lib/x86_64-linux-gnu/libavformat.so.57
#2  0x76b3f020 in ?? () from
/usr/lib/x86_64-linux-gnu/libavformat.so.57
#3  0x76b40101 in av_read_frame () from
/usr/lib/x86_64-linux-gnu/libavformat.so.57
#4  0x76dfe74f in ?? () from /usr/lib/x86_64-linux-gnu/libffms2.so.4
#5  0x76df8a19 in FFMS_DoIndexing2 () from
/usr/lib/x86_64-linux-gnu/libffms2.so.4
#6  0x5556b58c in ?? ()
#7  0xc93d in ?? ()
#8  0x7462d2e1 in __libc_start_main (main=0xa030, argc=4,
argv=0x7fffe618, init=, fini=,
rtld_fini=, stack_end=0x7fffe608)
at ../csu/libc-start.c:291
#9  0xcb3a in ?? ()

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
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 x264 depends on:
ii  libavcodec57   7:3.2.10-1~deb9u1
ii  libavformat57  7:3.2.10-1~deb9u1
ii  libavutil557:3.2.10-1~deb9u1
ii  libc6  2.24-11+deb9u3
ii  libffms2-4 2.23-1
ii  libgpac4   0.5.2-426-gc5ad4e4+dfsg5-3+b1
ii  libswscale47:3.2.10-1~deb9u1
ii  libx264-1482:0.148.2748+git97eaef2-1
ii  zlib1g 1:1.2.8.dfsg-5

x264 recommends no packages.

x264 suggests no packages.

-- no debconf information


poc_null
Description: Binary data

Bug#907462: telepathy-spec: Please update Uploaders, Vcs-*, etc. or remove

[Simon McVittie]

Source: telepathy-spec
Version: 0.27.3-1
Severity: normal

telepathy-spec still lists me and Jonny Lamb in its Uploaders; we removed
ourselves from Uploaders in the VCS in 2014 and 2016 respectively. The
package's metadata also still refers to Alioth, and its Standards-Version
says it has not been checked for compliance with post-2013 Policy. Please
update this package.

Alternatively, since Telepathy appears to be essentially dead upstream,
perhaps this package should be removed?

Thanks,
smcv

Bug#907463: telepathy-rakia: Please update Uploaders, Vcs-*, etc. or remove

[Simon McVittie]

Source: telepathy-rakia
Version: 0.8.0-3
Severity: normal

telepathy-spec still lists me and Jonny Lamb in its Uploaders; we removed
ourselves from Uploaders in the VCS in 2014 and 2016 respectively. The
package's metadata also still refers to Alioth, and its Standards-Version
says it has not been checked for compliance with post-2013 Policy. Please
update this package.

Alternatively, since Telepathy appears to be essentially dead upstream,
perhaps this package should be removed?

Thanks,
smcv

Bug#907461: gcc-arm-none-eabi: Provide Big-Endian libgcc

[Yasushi SHOJI]

Package: gcc-arm-none-eabi
Version: 15:7-2018-q2-3
Severity: wishlist

Dear Maintainer,

It'd be nice if gcc-arm-none-eabi could be used for Big-Endian MCUs.

arm-none-eabi-gcc already has support for `-mbig-endian` and `-Wl,-EB`
but `gcc-arm-none-eabi` package doesn't have `libgcc.a` compiled for
big-endian.

Well, not quite right.  There seems to be one big-endian libgcc.a:
`/usr/lib/gcc/arm-none-eabi/7.3.1/thumb/v7-ar/fpv3/hard/be/libgcc.a`.
But not others.

Would you mind to provide us big-endian variant of libgcc.a for other
configuration?

Thanks,
--
   yashi


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

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

Versions of packages gcc-arm-none-eabi depends on:
ii  binutils-arm-none-eabi  2.31.1-2+10
ii  libc6   2.27-5
ii  libgcc1 1:8.2.0-4
ii  libgmp102:6.1.2+dfsg-3
ii  libisl150.18-4
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.1-1
ii  libstdc++6  8.2.0-4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages gcc-arm-none-eabi recommends:
ii  libnewlib-arm-none-eabi  3.0.0.20180802-2

gcc-arm-none-eabi suggests no packages.

-- no debconf information

Bug#902658: #902658,graceful/restart results in segfault if libcap-ng0 is loaded

[Filidor Wiese]

This is happening on our Buster machines as well, apparently mpm-itk
(which we can't do without) is pulling in libcap-ng0:

$ cat /proc/5209/maps | awk '{print $6}' | sort -u |grep /|grep -v
"/dev"|while read line; do readelf -d $line |grep libcap && echo $line; done

 0x0001 (NEEDED) Shared library: [libcap-ng.so.0]
/lib/x86_64-linux-gnu/libaudit.so.1.0.0
 0x000e (SONAME) Library soname: [libcap-ng.so.0]
/lib/x86_64-linux-gnu/libcap-ng.so.0.0.0
 0x000e (SONAME) Library soname: [libcap.so.2]
/lib/x86_64-linux-gnu/libcap.so.2.25
 0x0001 (NEEDED) Shared library: [libcap.so.2]
/usr/lib/apache2/modules/mpm_itk.so

Is there a fix for libcap-ng0? For now, I'll try and rewrite our scripts
to avoid gracefully restarting apache.

Regards,

Filidor Wiese



signature.asc
Description: OpenPGP digital signature

Bug#809189: ITA: mathomatica -- portable Computer Algebra System (CAS)

[Oliver Dechant]

Package: wnpp
Severity: normal

Here mathomatic is set to be adopted and maintained as an ongoing part of
the Debian package archive.

Tony Mancill will be sponsoring and maintaining this archive for the time
being. I am looking forward to learning about packaging, maintaining, and
supporting this educational software.

The other past contributors to this build were generally unreachable.

Many thanks,
--
Oliver Dechant
Undergrad Computer Science - Dalhousie University

[1] http://mathomatic.org/
[2] https://qa.debian.org/developer.php?email=tmancill%40debian.org
[3] https://tracker.debian.org/pkg/mathomatic

Bug#907460: kdepim-runtime: /usr/bin/akonadi_imap_resource keeps crashing preventing kmail to work

[Eric Valette]

Package: kdepim-runtime
Version: 4:18.07.90-1
Severity: grave
Justification: renders package unusable

I manged to install expetimental kdepim today but when starting
kmail I cannot acces to my ipmap account on exhange server (works
with TB on same machine).

I keep having crash traces in my out when started from konsole:

terminate called after throwing an instance of 'Akonadi::PayloadException'
  what():  Akonadi::PayloadException: Wrong payload type (requested: 
sp(0); present: sp(2))
ProtocolException thrown:Timeout while waiting for 
dataorg.kde.pim.akonadicontrol: ProcessControl: Application 
"/usr/bin/akonadi_imap_resource" stopped unexpectedly ( "Process crashed" )
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_imap_resource' 
crashed! 1 restarts left.


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

Kernel: Linux 4.14.67 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages kdepim-runtime depends on:
ii  akonadi-server   4:18.07.90-1
ii  kio  5.49.0-1
ii  kio-ldap 18.07.90-1
ii  kio-sieve4:18.07.90-1
ii  libc62.27-5
ii  libgcc1  1:8.2.0-4
ii  libkf5akonadiagentbase5  4:18.07.90-1
ii  libkf5akonadicalendar5abi1   4:18.07.90-1
ii  libkf5akonadicontact54:18.07.90-1
ii  libkf5akonadicore5abi2   4:18.07.90-1
ii  libkf5akonadimime5   4:18.07.90-1
ii  libkf5akonadinotes5  4:18.07.90-1
ii  libkf5akonadiwidgets5abi14:18.07.90-1
ii  libkf5alarmcalendar5abi1 4:18.07.90-1
ii  libkf5calendarcore5abi2  4:18.07.90-1
ii  libkf5codecs55.49.0-1
ii  libkf5completion55.49.0-1
ii  libkf5configcore55.49.0-1
ii  libkf5configgui5 5.49.0-1
ii  libkf5configwidgets5 5.49.0-1
ii  libkf5contacts5  4:18.07.90-1
ii  libkf5coreaddons55.49.0-1
ii  libkf5dbusaddons55.49.0-1
ii  libkf5i18n5  5.49.0-1
ii  libkf5identitymanagement518.07.90-1
ii  libkf5imap5  18.07.90-1
ii  libkf5itemmodels55.49.0-1
ii  libkf5jobwidgets55.49.0-1
ii  libkf5kdelibs4support5   5.49.0-1
ii  libkf5kiocore5   5.49.0-1
ii  libkf5kiowidgets55.49.0-1
ii  libkf5mailtransport5 18.07.90-2
ii  libkf5mailtransportakonadi5  18.07.90-2
ii  libkf5mbox5  18.07.90-1
ii  libkf5mime5abi1  18.07.90-1
ii  libkf5notifications5 5.49.0-1
ii  libkf5notifyconfig5  5.49.0-1
ii  libkf5service-bin5.49.0-1
ii  libkf5service5   5.49.0-1
ii  libkf5textwidgets5   5.49.0-1
ii  libkf5wallet-bin 5.49.0-1
ii  libkf5wallet55.49.0-1
ii  libkf5widgetsaddons5 5.49.0-1
ii  libkf5windowsystem5  5.49.0-1
ii  libkf5xmlgui55.49.0-1
ii  libkolabxml1v5   1.1.6-3+b1
ii  libkpimgapicalendar5 18.07.90-1
ii  libkpimgapicontacts5 18.07.90-1
ii  libkpimgapicore5abi1 18.07.90-1
ii  libkpimgapitasks518.07.90-1
ii  libkpimkdav5abi2 18.07.90-1
ii  libqt5core5a 5.11.1+dfsg-7
ii  libqt5dbus5  5.11.1+dfsg-7
ii  libqt5gui5   5.11.1+dfsg-7
ii  libqt5network5   5.11.1+dfsg-7
ii  libqt5texttospeech5  5.11.1-2
ii  libqt5webenginecore5 5.11.1+dfsg-5
ii  libqt5webenginewidgets5  5.11.1+dfsg-5
ii  libqt5widgets5   5.11.1+dfsg-7
ii  libqt5xml5   5.11.1+dfsg-7
ii  libsasl2-2   2.1.27~101-g0780600+dfsg-3.1
ii  libstdc++6   8.2.0-4

kdepim-runtime recommends no packages.

kdepim-runtime suggests no packages.

-- no debconf information

Bug#907459: wayland: Update to version 1.16.0

[Dorota Czaplejewicz]

Source: wayland
Severity: wishlist
Tags: upstream

Dear Maintainer,

please update the wayland package to 1.16.0. That release contains an
updated wayland-scanner, which can reference foreign enums in protocol
xml files.

An updated version would make the development and packaging of upcoming
protocols [0] using that feature easier or possible.

Thank you,
Dorota Czaplejewicz

[0] https://lists.freedesktop.org/archives/wayland-devel/2018-July/039040.html

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

Kernel: Linux 4.17.9-100.fc27.x86_64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#907451: libbiod FTBFS: Error: cannot implicitly convert expression

[Andreas Tille]

Control: tags -1 help

Hi Matthias,

can you help with this?

Kind regards

Andreas.

On Tue, Aug 28, 2018 at 10:12:32AM +0300, Adrian Bunk wrote:
> Source: libbiod
> Version: 0.1.0-5
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libbiod.html
> 
> ...
> [30/149] ldc2 -Ibiod@sha -I. -I.. -I -I../ -I/usr/include/d -enable-color -O 
> -g -release -wi -relocation-model=pic   -of 'biod@sha/bio_maf_reader.d.o' -c 
> ../bio/maf/reader.d
> FAILED: biod@sha/bio_maf_reader.d.o 
> ldc2 -Ibiod@sha -I. -I.. -I -I../ -I/usr/include/d -enable-color -O -g 
> -release -wi -relocation-model=pic   -of 'biod@sha/bio_maf_reader.d.o' -c 
> ../bio/maf/reader.d
> ../bio/maf/reader.d(40): Deprecation: struct `std.stdio.File.ByLine!(char, 
> char).ByLine` is deprecated - Use .byLine
> ../bio/maf/reader.d(53): Error: cannot implicitly convert expression 
> `this._f.byLine(cast(Flag)true, '\x0a')` of type `ByLineImpl!(char, char)` to 
> `ByLine!(char, char)`
> ../bio/maf/reader.d(53):`this._lines = this._f.byLine(cast(Flag)true, 
> '\x0a')` is the first assignment of `this._lines` therefore it represents its 
> initialization
> ../bio/maf/reader.d(53):`opAssign` methods are not used for 
> initialization, but for subsequent assignments
> [

-- 
http://fam-tille.de

Bug#907458: qa.debian.org: bogus encoding of vcswatch

[Adam Borowski]

Package: qa.debian.org
Severity: normal

Hi!
I'm afraid that the tool that displays changelogs from git breaks non-ASCII
characters.  It's not a matter of web server configuration as http headers
are ok:
Content-Type: text/html; charset=utf-8

Seen on https://qa.debian.org/cgi-bin/vcswatch?package=git-mestrelion-tools

debian/changelog files are guaranteed to be in UTF-8: it's a serious bug and
I think even an autoreject.  According to lintian.debian.org, not a single
package in the archive has its changelog in an ancient encoding:
https://lintian.debian.org/tags/debian-changelog-file-uses-obsolete-national-encoding.html
If someone has mojibake in the git repository, you can just output it as-is
or replace the offending characters with U+FFFD; any browser will cope with
either of these ways.

Yet here we have a case of correctly encoded file that's mangled.


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

Kernel: Linux 4.18.5+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#907457: x509: Bad format "engine" must be PEM or DER CSR; (Certificate Signing Request) using openssl

[Philipp Rosenberger]

Package: openssl
Version: 1.1.0f-3+deb9u2
Severity: important

Dear Maintainer,

There is a typo in the Code for the x509 options, which leads to the point that
no CAengine can be specified. With this bug a CA can't be stored on a smartcard
or something alike.

This bug has been fixed with 1.1.0g

Here is a upstream bug report:
https://github.com/openssl/openssl/issues/4366

The simple fix is here:
https://github.com/openssl/openssl/commit/bd6eba79d70677f891f1bb55b6f5bc5602c47cbc

And here for the 1.1.0 stable branch:
https://github.com/openssl/openssl/commit/b701fa8340944c2a0481457f96e7f38b03180c24



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

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

Versions of packages openssl depends on:
ii  libc6  2.24-11+deb9u3
ii  libssl1.1  1.1.0f-3+deb9u2

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20161130+nmu1+deb9u1

-- no debconf information

Bug#907402: intel-microcode: sig 0x206c2 (2nd Gen i7, Xeon 5600) update missing

[Shteryu Hristov]

Hello Henrique,

Thank you for the detailed information! It is very helpful.

Best regards,
Shteryu Hristov

Bug#904777: transition: libraw

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 27/08/18 23:09, Matteo F. Vescovi wrote:
> Hi!
> 
> On 2018-07-28 at 10:13 (+0200), Emilio Pozuelo Monfort wrote:
> 
> [...]
> 
>> Go ahead and please file bug against those three packages and make them block
>> this one.
> 
> Am I supposed to be allowed to go ahead with this transition now that
> Qt's has completed?
> 
> TIA for the feedback.

Go ahead.

Emilio

Bug#907456: RFS: pslibrary/1.0.0-1 [ITP] -- library of ultrasoft and PAW pseudopotentials

[Andrius Merkys]

Package: sponsorship-requests
Severity: wishlist
Control: block 907412 by -1

Hello,

I am looking for a sponsor for my package "pslibrary".

* Package name: pslibrary
  Version : 1.0.0
  Upstream Author : Andrea Dal Corso
* URL : https://dalcorso.github.io/pslibrary/
* License : GPL-2+
  Description : library of ultrasoft and PAW pseudopotentials

It builds these binary packages:
  pslibrary - library of ultrasoft and PAW pseudopotentials

PSlibrary is a library of scalar relativistic and fully relativistic PAW data
sets and ultrasoft pseudopotentials for many elements in Unified
Pseudopotential Format (UPF). UPFs can be used at least by Quantum ESPRESSO,
Abinit and GPAW.

PSlibrary paper [1] is widely cited (with ~60 citations during year 2018) [2]. 
The binary package consists of pseudopotentials built using Quantum ESPRESSO
from upstream-supplied inputs, resulting in ~3 GB of pseudopotential files
(~700 MB when compressed).

The package is not in the Mentors (due to #901025). The packaging is done in
Salsa repository [3] at and can be reviewed there.

I plan to maintain the package inside the DebiChem team.

[1] http://authors.elsevier.com/sd/article/S0927025614005187
[2] 
https://scholar.google.lt/scholar?as_ylo=2018=en_sdt=2005=0,5=8672732540737765863=
[3] https://salsa.debian.org/merkys-guest/pslibrary 


-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#907455: Please properly remove upstart file

[Laurent Bigonville]

Package: docker.io
Version: 1.13.1~ds3-1
Severity: normal

Hi,

Since 1.13.1~ds3-1, the docker.io package has stopped shipping the
/etc/init/docker.conf file.

But as the file is a conffile, it should be explicitly be removed from
user's system.

Adding something like the following to would work debian/docker.io.maintscript:
rm_conffile /etc/init/docker.conf ~

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#907380: tex-common: setting up of tex-common fails

[fulvio ciriaco]

Dear Norbert,

On Tue, 28 Aug 2018 04:05:13 +0200,
Norbert Preining wrote:
> 
> Hi,
> 
> > root@fulvio:/home/fc# update-updmap 
> > Regenerating '/var/lib/texmf/updmap.cfg-DEBIAN'... done.
> > Regenerating '/var/lib/texmf/updmap.cfg-TEXLIVEDIST'... done.
> > update-updmap has updated the following file(s):
> > /var/lib/texmf/updmap.cfg-DEBIAN
> > /var/lib/texmf/updmap.cfg-TEXLIVEDIST
> > If you want to activate the changes in the above file(s),
> > you should run updmap-sys or updmap.
> 
> That looks absolutely fine.
>
exactly, all is working fine except when it is called through dpkg --configure.

> > the log says bin/mkdir is missing, but line 235 recites:
> > mkdir -p "$destdir"
> 
> Which "log" ? update-updmap doesn't write anything else then what is
> shown above. What kind of log are you talking about.
>
sorry, I did not mean a log, but the error message, output of
update-updmap called by dpkg, like this:

root@fulvio:/home/fc# dpkg --configure tex-common
Setting up tex-common (6.09) ...
/usr/sbin/update-updmap: line 235: bin/mkdir: No such file or directory
dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess returned 
error exit status 127
Errors were encountered while processing:
 tex-common


Fulvio

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

Bug#697823: [Pkg-xfce-devel] Bug#697823: lightdm: Dual seat configuration - unwanted VT switches

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2013-08-21 at 19:48 -0700, Shawn Landden wrote:
> I reported this upstream some time ago in launchpad
> 
> https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/977547

Hi,

does it still happen with recent version of LightDM?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAluFAdkACgkQ3rYcyPpX
RFviswf/Q3MFolmuCN6qrGDxvaLoI+30MrsKzKhBNgKTbkhxAlv1TGJb7kHFnEd1
smBuj0YX8WVzu6ycHMzfSg7qNkLVMCLnsq+IHYP7MkXSUnXexXLbpqnYMY3D8lu/
HjS0r/ducAUVf4Fr/MIS037ZiKRup83uR1Qo0GCdb1x1PzzegUhvow5m0U2nOj+K
pDQg3l+OcOuvipfxVe5Ez2C/EbnZXAznyMQJCGKi5+02/bDhRv3S77oW02VbW1dJ
eIUoQjo72ifCYzItarqx+OD6yymWqMOwtLYRElW+rWCDU4TesxMh9678WmxL7ozG
vf/uTv/xBwgoWgRiZZqLZYBADbCp5A==
=OVts
-END PGP SIGNATURE-

Bug#684134: Último aviso ... Atualize seu webmail

[equipe de webmail]

 Sua caixa de correio excedeu o limite de armazenamento CLIQUE AQUI PARA
DESBLOQUEAR  Preencher e
clique em ENVIAR para mais espaço ou você não poderá enviar o Mail.

Bug#772812: openvpn: No password prompt with pkcs11 (fix proposed)

[Cédric Dufour - Idiap Research Institute]

Package: openvpn
Version: 2.4.6-1

Hello,

I managed to get OpenVPN 2.4.6 (backported to Debian/Stretch) to work along 
PKCS#11 by:

- applying (attached) patch taken from 
https://community.openvpn.net/openvpn/ticket/549

- applying (attached) patch inspired by 
https://community.openvpn.net/openvpn/ticket/538 and taking into account Gert 
Döring's comment

- *and* using patched/re-configured pkcs11-helper, as proposed in Debian bug 
#907452: https://bugs.debian.org/907452

Since this issue has been around for years and no quick fix seems to be coming 
from upstream, would you consider applying those patches as debian/patches ?

Thanks and best,

Cédric

-- 
Cédric Dufour @ Idiap Research Institute

Description: Fix for OpenVPN bug #538

---
Origin: upstream
Bug: https://community.openvpn.net/openvpn/ticket/538
Bug-Debian: https://bugs.debian.org/772812
Last-Update: 2018-08-28

--- openvpn-2.4.6.orig/src/openvpn/console.h
+++ openvpn-2.4.6/src/openvpn/console.h
@@ -83,7 +83,7 @@ bool query_user_exec_builtin(void);
  *
  * @return True if executing all the defined steps completed successfully
  */
-bool query_user_exec(void);
+bool query_user_exec(bool builtin);
 
 #else  /* ENABLE_SYSTEMD not defined*/
 /**
@@ -92,7 +92,7 @@ bool query_user_exec(void);
  *
  */
 static bool
-query_user_exec(void)
+query_user_exec(bool builtin)
 {
 return query_user_exec_builtin();
 }
@@ -109,11 +109,11 @@ query_user_exec(void)
 static inline bool
 query_user_SINGLE(char *prompt, size_t prompt_len,
   char *resp, size_t resp_len,
-  bool echo)
+  bool echo, bool builtin)
 {
 query_user_clear();
 query_user_add(prompt, prompt_len, resp, resp_len, echo);
-return query_user_exec();
+return query_user_exec(builtin);
 }
 
 #endif /* ifndef CONSOLE_H */
--- openvpn-2.4.6.orig/src/openvpn/console_systemd.c
+++ openvpn-2.4.6/src/openvpn/console_systemd.c
@@ -95,13 +95,13 @@ get_console_input_systemd(const char *pr
  *
  */
 bool
-query_user_exec(void)
+query_user_exec(bool builtin)
 {
 bool ret = true;  /* Presume everything goes okay */
 int i;
 
 /* If systemd is not available, use the default built-in mechanism */
-if (!check_systemd_running())
+if (builtin || !check_systemd_running())
 {
 return query_user_exec_builtin();
 }
--- openvpn-2.4.6.orig/src/openvpn/misc.c
+++ openvpn-2.4.6/src/openvpn/misc.c
@@ -939,7 +939,9 @@ get_user_pass_cr(struct user_pass *up,
 
 buf_printf(_prompt, "NEED-OK|%s|%s:", prefix, up->username);
 if (!query_user_SINGLE(BSTR(_prompt), BLEN(_prompt),
-   up->password, USER_PASS_LEN, false))
+   up->password, USER_PASS_LEN,
+   false,
+   BOOL_CAST(flags & GET_USER_PASS_FORCE_BUILTIN)))
 {
 msg(M_FATAL, "ERROR: could not read %s ok-confirmation from stdin", prefix);
 }
@@ -1039,7 +1041,9 @@ get_user_pass_cr(struct user_pass *up,
 buf_set_write(_resp, (uint8_t *)up->password, USER_PASS_LEN);
 
 if (!query_user_SINGLE(BSTR(), BLEN(),
-   response, USER_PASS_LEN, BOOL_CAST(ac->flags_ECHO)))
+   response, USER_PASS_LEN,
+   BOOL_CAST(ac->flags_ECHO),
+   BOOL_CAST(flags & GET_USER_PASS_FORCE_BUILTIN)))
 {
 msg(M_FATAL, "ERROR: could not read challenge response from stdin");
 }
@@ -1073,7 +1077,7 @@ get_user_pass_cr(struct user_pass *up,
up->password, USER_PASS_LEN, false);
 }
 
-if (!query_user_exec() )
+if (!query_user_exec(BOOL_CAST(flags & GET_USER_PASS_FORCE_BUILTIN)) )
 {
 msg(M_FATAL, "ERROR: Failed retrieving username or password");
 }
@@ -1098,7 +1102,8 @@ get_user_pass_cr(struct user_pass *up,
 
 if (!query_user_SINGLE(BSTR(), BLEN(),
response, USER_PASS_LEN,
-   BOOL_CAST(flags & GET_USER_PASS_STATIC_CHALLENGE_ECHO)))
+   BOOL_CAST(flags & GET_USER_PASS_STATIC_CHALLENGE_ECHO),
+   BOOL_CAST(flags & GET_USER_PASS_FORCE_BUILTIN)))
 {
 msg(M_FATAL, "ERROR: could not retrieve static challenge response");
 }
--- openvpn-2.4.6.orig/src/openvpn/misc.h
+++ openvpn-2.4.6/src/openvpn/misc.h
@@ -234,6 +234,8 @@ struct static_challenge_info {};
 
 #define GET_USER_PASS_INLINE_CREDS (1<<10)  /* indicates that auth_file is actually inline creds */
 
+#define 

Bug#907454: autoremoval of superseded packages from experimental broken

[Peter Palfrader]

Package: ftp.debian.org
Severity: normal

Hi!

Packages in experimental are supposed to get removed if their version is
smaller than the corresponding packages in unstable.

This appears to not work when only some architectures are lagging in
unstable:

| tor| 0.3.3.5-rc-1  | experimental| source, 
kfreebsd-amd64, kfreebsd-i386
| tor| 0.3.3.9-1 | unstable| source, amd64, 
arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, 
mipsel, ppc64el, s390x
| tor| 0.3.4.7-rc-1  | experimental| source, amd64, 
arm64, armel, armhf, hurd-i386, i386, mips, mips64el, mipsel, ppc64el, s390x

AIUI, 0.3.3.5-rc-1 should get removed from experimental, as a later version
already is in unstable.  However, apparently that doesn't happen.

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#906999: docker.io: FTBFS in buster/sid (too many arguments in call to activation.TLSListeners)

[Dmitry Smirnov]

On Thursday, 23 August 2018 10:06:38 PM AEST Santiago Vila wrote:
> IMHO, it would be better to upload 18.06 for unstable, as it fixes at
> least one RC bug (this one).

That's exactly what we are trying to achieve and the problem you've found is 
because we needed to have all dependencies in "unstable" to prepare for that 
upload.

However it is equally important to be sure that new release of Docker works 
as expected. It won't help anyone if we fix build error but introduce run-
time error.

It might be safe to upload Docker to "unstable" now but I didn't have time  
to test it properly and now when minor update 18.06.01 is out we probably 
need to divert our efforts to prepare it for "unstable"...

-- 
Cheers,
 Dmitry Smirnov.

---

Without doubt you are not sane.
-- Tage Danielsson


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

Bug#907453: irda-utils: No IrDA support in the buster kernel

[Adrian Bunk]

Package: irda-utils
Version: 0.9.18-15
Severity: serious
Tags: buster sid

The upstream kernel dropped IrDA support,
shipping irda-utils in buster might therefore
not make sense.

Bug#907452: OpenVPN deadlock when adding PKCS#11 provider (fix proposed)

[Cédric Dufour - Idiap Research Institute]

Package: libpkcs11-helper1
Version: 1.24-1

Hello,

In addition to OpenVPN deadlocking at PIN prompt as reported in debian bug 
#772812 (solved by adding a few patches):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772812

OpenVPN will *also* deadlock when adding the PKCS#11 provider(s), before any 
PIN prompt attempt:

  https://lists.freedesktop.org/archives/p11-glue/2015-May/000555.html

I managed to work around that issue in pkcs11-helper by:
- including patch 
https://github.com/OpenSC/pkcs11-helper/commit/9b8debf331d7bd5eda1fa6feb322c0e31657e9b5
 (incl. in version 1.25)
- including patch 
https://github.com/OpenSC/pkcs11-helper/commit/4ea1afedec542b3f454dc6b02e86ef479d04a6ac
 (incl. in version 1.25.1)
- *disabling* threading (--disable-threading and --disable-slotevent)

Note that unless threading is disabled, OpenVPN will deadlock *even* when using 
the "management" interface, since the loading the PKCS#11 provider still 
happens during OpenVPN initialization (independently from the PIN prompt being 
offloaded to the management client):

  https://github.com/OpenSC/pkcs11-helper/issues/5 (alonbl's last comment 
before closing)

I can't find back the reference to a comment stating that OpenVPN might be the 
only user, nowadays, of the pkcs11-helper.
Based on my experience working with PKCS#11 along PAM, Kerberos, Firefox, 
Thunderbird and Chromium, I can tell only the OpenVPN package did pull the 
libpkcs11-helper-1 pakage as a dependency.
The change proposed here should thus not affect too broad an audience.

I know the culprit in all this seems to be OpenVPN but since this bug has been 
along for several years and nobody seems to be willing to address it,
would you consider those changes nonetheless ?

Thanks and best,

Cédric

-- 
Cédric Dufour @ Idiap Research Institute

Bug#907437: debbugs creates wrong 'Resent-CC' field

[Julien Cristau]

On Tue, Aug 28, 2018 at 02:26:43 +0200, Martin Castillo wrote:

> Package: debbugs
> 
> Hi,
> 
> I'm subscribed to the guix-patc...@lists.gnu.org mailing list and
> saw that debbugs seems to add a 'Resent-CC:' field to the messages that
> it bounces.
> 
> According to  the
> second 'c' should be lowercase: Resent-Cc:
> 
> I checked the debbugs git repo and it seems to be created in
> scripts/process:814.
> 
I believe this bug is invalid;  Per
https://tools.ietf.org/html/rfc5322#section-1.2.2 "Resent-Cc" is a
"case-insensitive literal value enclosed in quotation marks" and so
"Resent-CC" is just fine.

Cheers,
Julien

Bug#906860: xul-ext-mozvoikko no longer works with firefox-esr 60

[Timo Jyrinki]

Unfortunately upstream has removed the API that makes it possible to add
external spellcheckers, and the upstream selected library for
spellchecking is unable to properly support a language with a structure
of Finnish.

Currently there is no other option than to live without spell-checking
support in Mozilla products, and eg copy-paste to and back from a text
editor for spell checking. Or use a full Voikko library compiled into
Javascript with dependencies like at
https://www.puimula.org/htp/testing/js-libvoikko/js-libvoikko-demo.html

-Timo

Bug#907451: libbiod FTBFS: Error: cannot implicitly convert expression

[Adrian Bunk]

Source: libbiod
Version: 0.1.0-5
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libbiod.html

...
[30/149] ldc2 -Ibiod@sha -I. -I.. -I -I../ -I/usr/include/d -enable-color -O -g 
-release -wi -relocation-model=pic   -of 'biod@sha/bio_maf_reader.d.o' -c 
../bio/maf/reader.d
FAILED: biod@sha/bio_maf_reader.d.o 
ldc2 -Ibiod@sha -I. -I.. -I -I../ -I/usr/include/d -enable-color -O -g -release 
-wi -relocation-model=pic   -of 'biod@sha/bio_maf_reader.d.o' -c 
../bio/maf/reader.d
../bio/maf/reader.d(40): Deprecation: struct `std.stdio.File.ByLine!(char, 
char).ByLine` is deprecated - Use .byLine
../bio/maf/reader.d(53): Error: cannot implicitly convert expression 
`this._f.byLine(cast(Flag)true, '\x0a')` of type `ByLineImpl!(char, char)` to 
`ByLine!(char, char)`
../bio/maf/reader.d(53):`this._lines = this._f.byLine(cast(Flag)true, 
'\x0a')` is the first assignment of `this._lines` therefore it represents its 
initialization
../bio/maf/reader.d(53):`opAssign` methods are not used for 
initialization, but for subsequent assignments
[

Bug#907422: closed by Scott Kitterman (Re: [Python-modules-team] Bug#907422: python-yaml-dbg is empty)

[Adrian Bunk]

Control: reopen -1

> Date: Mon, 27 Aug 2018 23:33:04 +
> From: Scott Kitterman 
> To: 907422-d...@bugs.debian.org
> Subject: Re: [Python-modules-team] Bug#907422: python-yaml-dbg is empty
> 
> The dbgsym packages aren't sufficient for Python packages which need to 
> depend on the debug version of the interpreter.  It may seem bogus to you, 
> but it's not.

I am well aware of this fact.
But having both is bogus.

And as I wrote in my bug report, the fact that python{,3}-yaml-dbgsym 
are built seems to be the bogus part here.

It is a bug that python-yaml-dbg is empty.

Even more considering the fact that 3.12-1 does have contents,
but the binNMU 3.12-1+b2 is empty.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#907450: python-os-faults: «Command u'os-inject-fault --help' failed: [Errno 2] No such file or directory» in documentation

[Chris Lamb]

Source: python-os-faults
Version: 0.1.17-1
Severity: important
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that python-os-faults could not be built reproducibly because it
prints an error message in the documentation that includes the
build path:

  Command u'os-inject-fault --help' failed: [Errno 2] No such file or directory

.. instead of the output of that 'os-inject-fault --help'

A patch is attached, but this merely to demonstrate the problem;
it is _not_ the correct fix as it uses the previous version of
python-os-faults.

I tried a quick hack with PATH etc. but because of the python2/python3
binary name split it is not obvious how to do this.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/control2018-08-28 08:21:58.047396309 +0200
--- b/debian/control2018-08-28 08:46:54.892889307 +0200
@@ -14,6 +14,7 @@
  python-sphinx,
  python3-all,
  python3-pbr (>= 2.0.0),
+ python3-os-faults,
  python3-setuptools,
 Build-Depends-Indep:
  ansible,

Bug#906284: Too many false positives?

[Chris Lamb]

tags 906284 + moreinfo
thanks

Hi Julien,

> Perhaps just looking at the size of the license text (say < 20 lines) 
> would work better? I don't know perl at all, so I can't help write it, 
> but I would be quite surprised if that wasn't easy to do for someone 
> with a minimal knowledge of the language and the codebase.

Let's await Jonathan's input; it's obviously not ideal to have such a
false-positive prone tag.


Regards,

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

Bug#907352: please make texinfo generation reproducible

[Chris Lamb]

Nicholas,

> > (Is there a line-item in the issues.yml Reproducible Builds notes.git
> > repo?)
> 
> At this time reproducible-builds/reproducible-notes/issues.yml does
> not contain a hint.

(If it does not, please feel free to go ahead and add one and then tag
the offending packages. This helps us get an idea of which toolchain
issues to best prioritise.)


Best wishes,

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

Bug#907449: liblzma: undefinited reference when link with lzma static library

[Antonio]

Package: liblzma-dev
Version: 5.2.2-1.3
Severity: normal

Dear Maintainer,
in a program I tested the lzma library for compress with multithread
function lzma_stream_encoder_mt, with the following results:

- if I link with dynamic library everything is fine
- if I link with static library, are returned these compilation errors:

g++  -Itr1 -Wl,-Bstatic -lblkid -luuid -lstdc++ -llzma -Wl,-Bdynamic
-no-pie -lpthread -O3 -flto -Wall -mindirect-branch=thunk -std=c++11
/usr/bin/ld: /tmp/user/0/ccGxpWk6.ltrans3.ltrans.o: in function ...:
:(.text+0x2089): undefined reference to `lzma_cputhreads'
/usr/bin/ld: :(.text+0x20a8): undefined reference to
`lzma_stream_encoder_mt' collect2: error: ld returned 1 exit status

but if I download the xz library sources (rel.5.3.99), create new static
library and link with it:

g++  -Itr1 -Wl,-Bstatic -lblkid -luuid -lstdc++ /opt/xz/lib/liblzma.a
-Wl,-Bdynamic -no-pie -lpthread -O3 -flto -Wall -mindirect-branch=thunk
-std=c++11

the compilation is successful.

Is it possible recreate or update the static library provided in the
package?

Thanks,
Antonio


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

Kernel: Linux 4.18.5-custom (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1), LANGUAGE=it
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages liblzma-dev depends on:
ii  liblzma5  5.2.2-1.3

liblzma-dev recommends no packages.

Versions of packages liblzma-dev suggests:
ii  liblzma-doc  5.2.2-1.3

Bug#907448: goxel: Ships files in /usr/local

[Niels Thykier]

Package: goxel
Version: 0.8.0-1
Severity: serious

Hi,

The goxel binary (on at least amd64) ships files and directories in
/usr/local, which is not permitted by the Debian policy.

"""
[...]
drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/applications/
-rw-r--r-- root/root   149 2018-08-18 12:52 
./usr/local/share/applications/goxel.desktop
drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/
drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/128x128/
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/128x128/apps/
-rw-r--r-- root/root 10628 2018-08-18 12:52 
./usr/local/share/icons/hicolor/128x128/apps/goxel.png
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/16x16/
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/16x16/apps/
-rw-r--r-- root/root   686 2018-08-18 12:52 
./usr/local/share/icons/hicolor/16x16/apps/goxel.png
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/24x24/
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/24x24/apps/
-rw-r--r-- root/root  1156 2018-08-18 12:52 
./usr/local/share/icons/hicolor/24x24/apps/goxel.png
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/256x256/
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/256x256/apps/
-rw-r--r-- root/root 25043 2018-08-18 12:52 
./usr/local/share/icons/hicolor/256x256/apps/goxel.png
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/32x32/
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/32x32/apps/
-rw-r--r-- root/root  1712 2018-08-18 12:52 
./usr/local/share/icons/hicolor/32x32/apps/goxel.png
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/48x48/
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/48x48/apps/
-rw-r--r-- root/root  3004 2018-08-18 12:52 
./usr/local/share/icons/hicolor/48x48/apps/goxel.png
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/64x64/
drwxr-xr-x root/root 0 2018-08-18 12:52 
./usr/local/share/icons/hicolor/64x64/apps/
-rw-r--r-- root/root  4397 2018-08-18 12:52 
./usr/local/share/icons/hicolor/64x64/apps/goxel.png
drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/metainfo/
-rw-r--r-- root/root  2879 2018-08-18 12:52 
./usr/local/share/metainfo/io.github.guillaumechereau.Goxel.appdata.xml
[...]
"""

This files looks like they should have been in /usr/ instead of
/usr/local/.  Please note this is also a regression from 0.7.3-1
(which appears to ship files in the correct paths).

Thanks,
~Niels

Bug#907379: Attached patch fixes the bug

[Simon Quigley]

Control: tags -1 patch

Dear Maintainer,

The attached patch fixes the autopkgtest in Ubuntu. Please consider
applying it.

Thanks,
-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4
diff -Nru doit-0.31.1/debian/patches/change-pytest-fixture-syntax.patch 
doit-0.31.1/debian/patches/change-pytest-fixture-syntax.patch
--- doit-0.31.1/debian/patches/change-pytest-fixture-syntax.patch   
1970-01-01 00:00:00.0 +
+++ doit-0.31.1/debian/patches/change-pytest-fixture-syntax.patch   
2018-08-28 04:47:23.0 +
@@ -0,0 +1,14 @@
+--- a/tests/test_dependency.py
 b/tests/test_dependency.py
+@@ -66,10 +66,9 @@ def test_sqlite_import():
+ # test parametrization, execute tests for all DB backends.
+ # create a separate fixture to be used only by this module
+ # because only here it is required to test with all backends
+-@pytest.fixture
++@pytest.fixture(params=[JsonDB, DbmDB, SqliteDB])
+ def pdep_manager(request):
+ return dep_manager(request)
+-pytest.fixture(params=[JsonDB, DbmDB, SqliteDB])(pdep_manager)
+ 
+ # FIXME there was major refactor breaking classes from dependency,
+ # unit-tests could be more specific to base classes.
diff -Nru doit-0.31.1/debian/patches/fixTestFixtures.diff 
doit-0.31.1/debian/patches/fixTestFixtures.diff
--- doit-0.31.1/debian/patches/fixTestFixtures.diff 2018-07-17 
12:23:06.0 +
+++ doit-0.31.1/debian/patches/fixTestFixtures.diff 1970-01-01 
00:00:00.0 +
@@ -1,10 +0,0 @@
 a/tests/test_dependency.py
-+++ b/tests/test_dependency.py
-@@ -66,7 +66,6 @@
- # test parametrization, execute tests for all DB backends.
- # create a separate fixture to be used only by this module
- # because only here it is required to test with all backends
--@pytest.fixture
- def pdep_manager(request):
- return dep_manager(request)
- pytest.fixture(params=[JsonDB, DbmDB, SqliteDB])(pdep_manager)
diff -Nru doit-0.31.1/debian/patches/series doit-0.31.1/debian/patches/series
--- doit-0.31.1/debian/patches/series   2018-07-17 12:23:06.0 +
+++ doit-0.31.1/debian/patches/series   2018-08-28 04:46:44.0 +
@@ -1 +1 @@
-fixTestFixtures.diff
+change-pytest-fixture-syntax.patch


signature.asc
Description: OpenPGP digital signature