Bug#948532: closed by Debian FTP Masters (reply to Ricardo Mones ) (Bug#948532: fixed in claws-mail 3.17.5-1)

[Ricardo Mones]

Hi Laurent,

On Tue, Feb 25, 2020 at 12:38:42AM +0100, Laurent Bigonville wrote:
> found 948532 3.17.5-1
> thanks
> 
> Hello,
> 
> Le 24/02/20 à 20:51, Debian Bug Tracking System a écrit :
> 
> > * Switch to libenchant-2-dev (Closes: #948532)
> 
> Looks like libclaws-mail-dev still depends against libenchant-dev, so
> it's not fully fixed

My bad, thanks for noticing! fixed on salsa now ;-)

best regards,
-- 
  Ricardo Mones 
  ~
  The world will end in 5 minutes. Please log out.Unknown



signature.asc
Description: PGP signature

Bug#952508: Cannot call external script in rule CMD option

[Brian Wengel]

Package: libpam-abl
Version: 0.6.0-5

Description:
I cannot run a simple shell script:
I have the following options in my "/etc/security/pam_abl.conf":
  user_rule=*:3/1h
  host_rule=*:5/5h
  host_purge=1d
  user_purge=1d
  limits=100-300
  user_db=/var/lib/abl/users.db
  host_db=/var/lib/abl/hosts.db
  user_clear_cmd=[logger] [clear] [user] [%u]
  host_clear_cmd=[/tmp/brute.sh]
  host_block_cmd=[/tmp/brute.sh]
  user_clear_cmd=[/tmp/brute.sh]
  user_block_cmd=[/tmp/brute.sh]
  host_whitelist=localhost
  user_whitelist=
  db_home=/var/lib/abl

The result of the command "pam_abl -d" is:
  host_block_cmd: "/tmp/brute.sh"
  host_clear_cmd: "/tmp/brute.sh"
  user_block_cmd: "/tmp/brute.sh"
  user_clear_cmd: "/tmp/brute.sh"

The content of "/tmp/brute.sh"
  #!/bin/bash
  echo START >> /tmp/PAM_abl_env.txt
  env >> /tmp/PAM_abl_env.txt

Is this a bug or am I missing something?

Bug#952469: i3-wm: Moving windows in a specific way causes i3 to crash

[Michael Stapelberg]

Thanks for your report. Please file this issue on GitHub. There are
Debian repositories you can use to get the latest version:
https://i3wm.org/docs/repositories.html

On Mon, Feb 24, 2020 at 10:27 PM nabijaczleweli
 wrote:
>
> Package: i3-wm
> Version: 4.17.1-1
> Severity: normal
> Tags: upstream
>
> Dear Maintainer,
>
>
> I was trying to get myself out of a pickle with a workspace layout when
> i3 crashed to DM. I've managed to reduce this issue down to the
> following keystrokes (all with Mod held down, based on the default
> config -- Enter for terminal, W for tabbed, V for vert-split,
> A for select parent):
>
>   Enter
>   W
>   Enter
>   Left
>   V
>   Right
>   Shift+Down
>   Shift+Up
>   Shift+Up
>   Shift+Up
>   Down
>   A
>   Shift+Right
>
> See the attached screenshot for the layout before the final S+Right.
>
>
> I've attached a log of a crashing session, but in all of the ones I've
> collected (that managed to flush to disk) the following assertion fired:
>
>   i3[-with-shmlog]: ../../i3-wm-4.17.1/src/x.c:103: state_for_frame:
>   Assertion `false' failed.
>
> But the logging wasn't always exceptional and i3 seemed to crash much
> harder with it than without. Crashing backtraces are attached as well.
>
>
> I'm reporting this here rather than upstream because none of
> [next branch, 4.18.1, 4.18] built for me, and the website says
> that only the latest stable is supported, but I'll be happy to move this
> to GitHub.
>
> Regards,
> nabijaczleweli
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)
>
> Kernel: Linux 5.4.0-4-686-pae (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages i3-wm depends on:
> ii  libc6 2.29-10
> ii  libcairo2 1.16.0-4
> ii  libev41:4.31-1
> ii  libglib2.0-0  2.62.4-2
> ii  libpango-1.0-01.42.4-8
> ii  libpangocairo-1.0-0   1.42.4-8
> ii  libpcre3  2:8.39-12+b1
> ii  libstartup-notification0  0.12-6
> ii  libxcb-cursor00.1.1-4
> ii  libxcb-icccm4 0.4.1-1.1
> ii  libxcb-keysyms1   0.4.0-1+b2
> ii  libxcb-randr0 1.13.1-5
> ii  libxcb-shape0 1.13.1-5
> ii  libxcb-util0  0.3.8-3+b2
> ii  libxcb-xinerama0  1.13.1-5
> ii  libxcb-xkb1   1.13.1-5
> ii  libxcb-xrm0   1.0-3
> ii  libxcb1   1.13.1-5
> ii  libxkbcommon-x11-00.10.0-1
> ii  libxkbcommon0 0.10.0-1
> ii  libyajl2  2.1.0-3
> ii  perl  5.30.0-9
>
> Versions of packages i3-wm recommends:
> ii  fonts-dejavu-core   2.37-1
> ii  libanyevent-i3-perl 0.17-1
> ii  libjson-xs-perl 4.020-1+b1
> ii  rxvt-unicode [x-terminal-emulator]  9.22-6+b1
> ii  xfonts-base 1:1.0.5
>
> i3-wm suggests no packages.
>
> -- no debconf information



-- 
Best regards,
Michael

Bug#952494: unable to reproduce

[Antonio Russo]

Hi!

I merged your two bug reports, because it seems that they're about the same 
issue. In the future, you can indicate that the problem still exists
in another version by using the "Control: found -1"  command (see [1] 
for details to manage the Debian BTS).

I too am running network manager, and using it to manage a wired connection. 
However, my upgrade went smoothly. Could you go into more detail
about your configuration? In which prior version of network manager was this 
working? Did anything else change?

What is the output of "nmcli connection"? Can you also please include your 
NetworkManager.conf file? (Make sure there are no secrets in it!)

Best,
Antonio Russo


[1] https://www.debian.org/Bugs/server-control#found

Bug#950336: fixed in python-pbcore 1.7.1+git20200129.c55621e+dfsg-1

[Gianfranco Costamagna]

control: unarchive -1
control: reopen -1
control: notfixed -1 1.7.1+git20200129.c55621e+dfsg-1
control: tags -1 patch


>* Remove python3-pyxb from Build-Depends
>  Closes: #950336

tests are still depending on it.

this might be sufficient

diff -Nru python-pbcore-1.7.1+git20200129.c55621e+dfsg/debian/changelog 
python-pbcore-1.7.1+git20200129.c55621e+dfsg/debian/changelog
--- python-pbcore-1.7.1+git20200129.c55621e+dfsg/debian/changelog   
2020-01-31 15:34:17.0 +
+++ python-pbcore-1.7.1+git20200129.c55621e+dfsg/debian/changelog   
2020-02-25 06:46:15.0 +
@@ -1,3 +1,9 @@
+python-pbcore (1.7.1+git20200129.c55621e+dfsg-2) unstable; urgency=medium
+
+  * Drop pyxb also from test depends (Closes: #950336)
+
+ -- Gianfranco Costamagna   Tue, 25 Feb 2020 
07:46:15 +0100
+
 python-pbcore (1.7.1+git20200129.c55621e+dfsg-1) unstable; urgency=medium
 
   * Remove python3-pyxb from Build-Depends
diff -Nru python-pbcore-1.7.1+git20200129.c55621e+dfsg/debian/tests/control 
python-pbcore-1.7.1+git20200129.c55621e+dfsg/debian/tests/control
--- python-pbcore-1.7.1+git20200129.c55621e+dfsg/debian/tests/control   
2020-01-31 15:34:17.0 +
+++ python-pbcore-1.7.1+git20200129.c55621e+dfsg/debian/tests/control   
2020-02-25 06:46:13.0 +
@@ -1,3 +1,3 @@
 Tests: run-unit-test
-Depends: @, python3-pytest, python3-pyxb, python3-pytest-runner, 
python3-pytest-xdist, python3-pytest-cov
+Depends: @, python3-pytest, python3-pytest-runner, python3-pytest-xdist, 
python3-pytest-cov
 Restrictions: allow-stderr

G.

Bug#952507: dunst cannot be disabled and steals notifications

[Norbert Preining]

Package: dunst
Version: 1.4.1-1
Severity: important

Hi,

I am running cinnamon, which uses its own notification daemon.
But when dunst is installed it suddenly takes over all notifications.

I tried to disable it, but it comes back again and again. 
systemctl even reports it as disabled but started:

$ systemctl --user status dunst
● dunst.service - Dunst notification daemon
 Loaded: loaded (/usr/lib/systemd/user/dunst.service; disabled; vendor 
preset: enabled)
 Active: active (running) since Tue 2020-02-25 15:27:18 JST; 16min ago
   Docs: man:dunst(1)
   Main PID: 155923 (dunst)
 CGroup: /user.slice/user-1000.slice/user@1000.service/dunst.service
 └─155923 /usr/bin/dunst

Feb 25 15:27:18 bulldog systemd[2360]: Starting Dunst notification daemon...
Feb 25 15:27:18 bulldog systemd[2360]: Started Dunst notification daemon.
$

How am I supposed to disable this program?
And no, I do *not* want to remove it, nor mask the service, because
other uses are using i3 and are using dunst here.

Thanks

Norbert


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

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

Versions of packages dunst depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  init-system-helpers   1.57
ii  libc6 2.29-10
ii  libcairo2 1.16.0-4
ii  libgdk-pixbuf2.0-02.40.0+dfsg-2
ii  libglib2.0-0  2.62.4-2
ii  libpango-1.0-01.42.4-8
ii  libpangocairo-1.0-0   1.42.4-8
ii  libx11-6  2:1.6.8-1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-2
ii  libxrandr22:1.5.1-1
ii  libxss1   1:1.2.3-1

Versions of packages dunst recommends:
ii  sensible-utils  0.0.12+nmu1

dunst suggests no packages.

-- no debconf information

Bug#952488: TAG: qemu-system-riscv -- QEMU is a fast processor emulator

[Alistair]

On Mon, Feb 24, 2020, at 10:28 PM, Christian Kastner wrote:
> On 25.02.20 00:00, Alistair wrote:
> > This package provides the full system emulation binaries to emulate the 
> > following RISC-V hardware: riscv32 riscv64.
> > 
> > https://git.qemu.org/?p=qemu.git
> 
> QEMU is already packaged [1], and it's qemu-system-misc package provides
> qemu-system-riscv32 and qemu-system-riscv64 binaries.
> 
> Is it possible that you overlooked those?

Ah sorry. I completely overlooked the misc package. I just assumed there had to 
be a qemu-system-riscv package.

Thanks for pointing that out and thanks for already having packaged it!

Alistair

> 
> [1] https://tracker.debian.org/pkg/qemu
> 

Bug#952375: [Pkg-javascript-devel] Bug#952375: node-jsonld: FTBFS: Module not found: Error: Can't resolve 'rdf-canonize' in '/<>/lib'

[Xavier]

Control: tags -1 - moreinfo

Le 25/02/2020 à 07:27, Xavier a écrit :
> Control: tags -1 moreinfo
> 
> Le 23/02/2020 à 15:06, Lucas Nussbaum a écrit :
>> Source: node-jsonld
>> Version: 1.6.2-2
>> Severity: serious
>> Justification: FTBFS on amd64
>> Tags: bullseye sid ftbfs
>> Usertags: ftbfs-20200222 ftbfs-bullseye
>>
>> Hi,
>>
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
> 
> Hi,
> 
> I'm unable to reproduce this failure. Could you share more information?

Sorry, I tried with version fixed by Nilesh, bug confirmed, waiting for
maintainer review

Bug#952488: TAG: qemu-system-riscv -- QEMU is a fast processor emulator

[Christian Kastner]

On 25.02.20 00:00, Alistair wrote:
> This package provides the full system emulation binaries to emulate the 
> following RISC-V hardware: riscv32 riscv64.
> 
> https://git.qemu.org/?p=qemu.git

QEMU is already packaged [1], and it's qemu-system-misc package provides
qemu-system-riscv32 and qemu-system-riscv64 binaries.

Is it possible that you overlooked those?

[1] https://tracker.debian.org/pkg/qemu

Bug#952375: [Pkg-javascript-devel] Bug#952375: node-jsonld: FTBFS: Module not found: Error: Can't resolve 'rdf-canonize' in '/<>/lib'

[Xavier]

Control: tags -1 moreinfo

Le 23/02/2020 à 15:06, Lucas Nussbaum a écrit :
> Source: node-jsonld
> Version: 1.6.2-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Hi,

I'm unable to reproduce this failure. Could you share more information?

> [...]
>> make[1]: *** [debian/rules:8: override_dh_auto_build] Error 2
> 
> The full build log is available from:
>http://qa-logs.debian.net/2020/02/22/node-jsonld_1.6.2-2_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.

Bug#952505: ocaml-qtest: autopkgtests regression

[Gianfranco Costamagna]

Source: ocaml-qtest
Version: 2.10.1-1
Severity: serious

Hello, looks like the last 2.10.1-1 version has autopkgtests failures.

Look e.g. to
https://ci.debian.net/data/autopkgtest/unstable/amd64/o/ocaml-qtest/4368021/log.gz


(Reading database ... 16955 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [10:26:31]: test testdirectives: [---
Target file: `directives.ml.result'. Extraction : `directives.ml' Done.
77c77
< exit (QCheck_ounit.run ("" >::: List.rev !___tests))
---
> exit (QCheck_runner.run ("" >::: List.rev !___tests))
testdirectives   FAIL non-zero exit status 1

not sure if a new ounit is needed.

G.

Bug#952504: RM: logservice -- ROM; unmaintained, low popcon, only 1 maintainer upload ever

[Stuart Prescott]

Package: ftp.debian.org
Severity: normal

The logservice package was only ever uploaded by the maintainer once (in
2011). The uploader's address bounces and the packaging Vcs does not
incorporate the NMU from 2015. This is a low popcon package without anyone
who wants to maintain it and can be safely removed from Debian.

(Found in triaging Python 2 removal bugs)

Bug#952497: Wired network interface can not be managed by Network-Manager

[wglxy]

Hi, I notice that the wired interface's name maybe be changed while rebooting. 
Sometimes the wired interface's name is "enp0s31f6", sometimes it is "eth0". 
The Network Manager can manage the wired interface if wired interface's name is 
"enp0s31f6". The Network Manager can not manage the wired interface if wired 
inteface's name is "eth0".






Best regards,
Gulfstream

Bug#950056: python-bleach FTBFS: test failures with Python 3.7.6 and 3.8.1

[Scott Kitterman]

On Tue, 28 Jan 2020 20:20:51 +0200 Adrian Bunk  wrote:
> Source: python-bleach
> Version: 3.1.0-2
> Severity: serious
> Tags: ftbfs
> Forwarded: https://github.com/mozilla/bleach/issues/503
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-bleach.html

Upstream has made the decision to revert the change that caused this problem 
for python3.7 and python3.8, so I'm going to lower the severity of this bug, 
since bleach doesn't need to change anything.

I'm not closing it because once we get python3.9, this will be a problem 
agian.

Scott K

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

Bug#949029: Processed: reassign 949029 to python3.8

[Scott Kitterman]

On Tue, 18 Feb 2020 16:24:50 -0500 Scott Kitterman  
wrote:
> Revert is being done upstream for python 3.8.2:
> 
> https://bugs.python.org/msg361815
> 
> Since it appears this is going to be solved in python3.8, I'm going to 
> reassign again.  Please don't reassign back, there's no point.  There's 
> another open bug against ptyhon-bleach for this.

The relevant change is reverted in 3.8.2 rc2 and will also in the upstream VCS 
for the next 3.7 update, so we should be good to go for 3.8.  It also needs 
fixing in python3.7.  Can you go ahead with a distro patch for that?

Scott K

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

Bug#952501: slapd: README.Debian does not note that databases are created

[Karl O. Pinc]

Package: slapd
Version: 2.4.47+dfsg-3+deb10u1
Severity: normal
Tags: patch

Hello,

The slapd package creates an ldap database, by default.  This can be
completely opaque, depending upon how debconf is configured.

The README.Debian should describe how the Debian installation differs
from upstream.  Automatically creating a database, and configuring
access, is an important difference.

Attached is a patch to the README.Debian describing the initial setup.

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

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

Versions of packages slapd depends on:
ii  adduser 3.118
ii  coreutils   8.30-3
ii  debconf [debconf-2.0]   1.5.71
ii  libc6   2.28-10
ii  libdb5.35.3.28+dfsg1-0.5
ii  libgnutls30 3.6.7-4+deb10u2
ii  libldap-2.4-2   2.4.47+dfsg-3+deb10u1
ii  libltdl72.4.6-9
ii  libodbc12.3.6-0.1
ii  libperl5.28 5.28.1-6
ii  libsasl2-2  2.1.27+dfsg-1+deb10u1
ii  libwrap07.6.q-28
ii  lsb-base10.2019051400
ii  perl [libmime-base64-perl]  5.28.1-6
ii  psmisc  23.2-1

Versions of packages slapd recommends:
ii  libsasl2-modules  2.1.27+dfsg-1+deb10u1

Versions of packages slapd suggests:
ii  ldap-utils2.4.47+dfsg-3+deb10u1
pn  libsasl2-modules-gssapi-mit | libsasl2-modules-gssap  

-- debconf information excluded
--- /tmp/README.Debian  2020-02-24 21:24:25.635042167 -0600
+++ /tmp/README.Debian.new  2020-02-24 22:54:03.401642325 -0600
@@ -11,7 +11,35 @@
   the OpenLDAP Admin Guide for more information, including configuration
   examples for common use cases. 
 
-The OpenLDAP configuration
+The initial databases
+
+  Upon installation the Debian package uses debconf to create a
+  regular OpenLDAP database for storage of directory information, by
+  default using the MDB backend.  An initial database root user and
+  password is created to administer this database.  And the OpenLDAP
+  configuration database is created.
+
+  Re-create the initial databases and their configuration, as the Unix
+  root user, with:
+
+  dpkg-reconfigure slapd
+
+  The installed configuration requires the Unix root user to use the
+  options "-Y EXTERNAL -H ldapi:///", when using the OpenLDAP client
+  command line tools, to obtain root-level access to the OpenLDAP
+  configuration database.  This database is rooted, as per the
+  pre-defined stock OpenLDAP DIT, at "cn=config".  The configuration
+  database contains the password and access permissions of the regular
+  database's root-user, as well as access permissions to the
+  configuration database itself, should changes be required.
+
+  The root user created to administer the regular database has a dn
+  starting with "cn=admin," followed by the base dn (olcSuffix) of the
+  database.  This root user's password, set when the initial database
+  is created, allows the root user to bind to the regular database
+  with password authentication and grants root-level access.
+
+Maintaining the OpenLDAP configuration
 
   Since version 2.4.23-3 the configuration of OpenLDAP has been changed to
   /etc/ldap/slapd.d by default.  The OpenLDAP packages in Debian provide an

Bug#951310: Delaying transition

[Graham Inggs]

Control: tags -1 + moreinfo

Hi Alastair

On Fri, 14 Feb 2020 at 16:27, Alastair McKinstry  wrote:
> The SOVERSION revision in 3.1.5rc1 was an error; its not bumping the
> soversion until the 4.x releas, expected Q2 this year.
>
> I am postponing any changes on pmix until then as reverting (renaming
> libpmix3->libpmix2) for a minor bugfix release in the interim
> seems  suboptimal.

I've tagged this bug 'moreinfo'.  Please remove the tag when you are ready.

Regards
Graham

Bug#952429: spamass-milter: doesn't work with the -s flag to spamc

[Don Armstrong]

On Tue, 25 Feb 2020, Russell Coker wrote:
> It seems that any command-line parameter that doesn't start with '-'
> will be passed as a parameter to spamc. I don't think this is
> something many people will expect or desire.

Yeah; that's basically how the code is currently written. 

> Maybe a good option would be to log what the spamc parameters will be
> at daemon start time so the user doesn't have to strace it to find out
> what it's doing.

If you use -d misc you should get that logged to syslog.

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

[M]en and nations do behave wisely once they have exhausted all other
alternatives.
 -- Abba Ebban

Bug#952500: RM: python-dns -- ROM; Obsolete, python2 only, python3 port is in py3dns package

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

This needs to go away.  It's already out of Testing.  The remaining
rdepends seem unmaintained and should probably be considered for removal
too.

Scott K

Bug#951497: I can't reproduce

[Matthew Fernandez]

You’re definitely testing v2020.01.27-1 right, Adam? I would think you probably 
are, but I ask because the version you uploaded for me last week 
(v2020.02.17-1) is not the problem one. v2020.02.17-1 should not reproduce this 
issue as I also made the fix there before uploading it. The problems Anatoly 
encountered were with v2020.01.27-1.

This is the first time I’ve had to make an updated release for a non-current 
version of a package, so it’s possible I did something unorthodox or confusing 
in my v2020.02.17-2 upload as well.

FWIW the situation Anatoly identified is a genuine problem for both the Debian 
package and the upstream native repo. The build system didn’t pass the test 
suite any parallelism constraints and the test suite tries to monopolise all 
cores in this scenario. Note that even after the fix you may see brief periods 
of multicore load because some of the test cases themselves do parallel work.

Bug#952499: python-csa: needs a source-only upload

[Peter Green]

Source: python-csa
Version: 0.1.10-1
Severity: serious

The release team have decreed that non-buildd binaries can no longer migrate to 
testing, please make a source-only upload so your package can migrate.

Bug#952498: mate-menus : icons menus is missing Mate 1.24

[Gleisson Jesuino Joaquim Cardoso]

Package: mate-menus
Version: 1.24.0-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
   
 When upgrading to version 1.24, the main menu icons do not appear.

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

I made a change to the locale file (/ etc / default / locale)
adding at the end of the file LANGUAGE = "C".
   
   * What was the outcome of this action?
   
   The icons return to normal !!!
   However the language changes to English, but I use pt_BR
   

   * What outcome did you expect instead?
   
   Let the icons return to normal after the update.
   



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

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

Versions of packages mate-menus depends on:
ii  gir1.2-matemenu-2.0  1.24.0-1

mate-menus recommends no packages.

mate-menus suggests no packages.

-- no debconf information

Bug#952497: Wired network interface can not be managed by Network-Manager

[gulfstream]

Package: network-manager
Version: 1.22.8-1
Severity: grave


Hi, I found that the network-manage can not manage the wired net interface now. 
Message "Wired Unmanaged" was showed, and I have set "managed=true" in 
NetworkManager.conf.

I have upgrade the network-manager to 1.22.8-1, but the problem did not be 
resolved.

How to resolve this problem?

Thank you!


Gulfstream


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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.16-2
ii  init-system-helpers1.57
ii  libaudit1  1:2.8.5-2+b1
ii  libbluetooth3  5.50-1+b1
ii  libc6  2.29-10
ii  libcurl3-gnutls7.67.0-2
ii  libglib2.0-0   2.62.4-2
ii  libgnutls303.6.12-2
ii  libjansson42.12-1
ii  libmm-glib01.10.4-0.1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.21-4
ii  libnm0 1.22.8-1
ii  libpam-systemd 244.3-1
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libpsl50.20.2-2
ii  libreadline8   8.0-3
ii  libselinux13.0-1+b1
ii  libsystemd0244.3-1
ii  libteamdctl0   1.30-1
ii  libudev1   244.3-1
ii  libuuid1   2.34-0.1
ii  policykit-10.105-26
ii  udev   244.3-1
ii  wpasupplicant  2:2.9+git20200213+877d9a0-1

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1.1
ii  iptables 1.8.4-3
ii  modemmanager 1.10.4-0.1
ii  ppp  2.4.7-2+4.1+b1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.1
pn  libteam-utils

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=true


-- no debconf information

Bug#949070: debci: information is out of date

[Drew Parsons]

Source: debci
Followup-For: Bug #949070

I second this bug report. This problem is very annoying, makes it hard
to keep track of the status of packages.

In the past ci.debian.org kept test logs up to date.  But for several
months now it's been lagging.  Are there too many test jobs, is the
webpage update daemon not keeping up?

Bug#950585: binutils-dev: included log files introduce reproducibility issues

[Chris Lamb]

Vagrant Cascadian wrote:

> > Or you could add a override database for files which are expected to differ.
> 
> This is considerably more complicated than running a checksum on the
> resulting .deb files and is another opportunity for bugs to lead to
> incorrect reproducibility results...

I would very much underline Vagrant's hesitation regarding a
centralised database. Such overrides would get out of date (or at
least out of sync) amongst many many other concerns including it,
albeit at a slight stretch, being a possible attack vector.

The ability to check reproducibility with no other knowledge or tools
other than cmp(1) or sha256sum(1) etc. does not seem to be that
important as it might initially appear but it extremely valuable as it
is so simple, engendering trust, lowering the barrier to entry,
reducing mistakes, etc. etc.

> which I think has actually happened when trying this kind of approach
> in the past, though I don't have a reference off the top of my head.

(Vagrant, are you perchance thinking of RPM? If I recall correctly, the
signatures in question there are embedded in the .rpm itself so you
need a special tool to even extract them.)


Best wishes,

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

Bug#952426: digikam: digkam experimental not correctly instalable

[Steven Robbins]

Eric,

Thank you for the bug report.  Per your question: I do indeed test before 
uploading -- I've been using Digikam 7 since I uploaded last week.

On Monday, February 24, 2020 4:38:40 A.M. CST Eric Valette wrote:

> valette@tri-yann4:~$ digikam --version
> digikam: error while loading shared libraries: libhdf5_serial_hl.so.100:
> cannot open shared object file: No such file or directory

Thanks.  Before today, I thought the issue was merely a missing dependency.  
On my system, digikam works with libhdf5 installed so I thought it would for 
you as well.

Here's what I see:

$ digikam --version
digikam 7.0.0-beta2
$ ldd /usr/bin/digikam |grep libhd
libhdf5_serial.so.103 => /lib/x86_64-linux-gnu/libhdf5_serial.so.103 
(0x7fb5136e5000)
libhdf5_serial_hl.so.100 => /lib/x86_64-linux-gnu/
libhdf5_serial_hl.so.100 (0x7fb510895000)


I think your issue may be due to attempting to use the experimental version of 
libhdf5.  I'm using hdf5 from unstable.  Note that the buildd pulls all its 
dependencies from unstable; e.g.

Get: 705 https://mirrors.wikimedia.org/debian unstable/main i386 libhdf4-0-alt 
i386 4.2.14-1 [285 kB]
Get: 706 https://mirrors.wikimedia.org/debian unstable/main i386 libsz2 i386 
1.0.4-1 [6820 B]
Get: 707 https://mirrors.wikimedia.org/debian unstable/main i386 libhdf5-103 
i386 1.10.4+repack-10 [1310 kB]

-- from i386 build log https://buildd.debian.org/status/fetch.php?
pkg=digikam=i386=4%3A7.0.0%7Ebeta2%2Bdfsg-1=1582008391=0

Can you try using deps from unstable and let us know how it goes?

Best,
-Steve



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

Bug#952496: python3-whiteboard, depends on package that is not in Debian.

[peter green]

Package: python3-whiteboard
Version: 1.0+git20170915-3
Severity: serious

python3-whiteboard depends on python3-cwiid, however I can't find any evidence 
of this package existing, it's not in debian, it doesn't appear to be in new 
(at least searching new for cwiid doesn't show anything) and my google searches 
aren't turning anything up either.

Bug#952495: python-matplotlib-doc: Local search functionality for the documentation does not work

[Raj Kiran Grandhi]

Package: python-matplotlib-doc
Version: 3.0.2-2
Severity: important

Dear Maintainer,

After upgrading to buster, the search functionality of the html
documentation is not longer working. 

   * What led up to the situation?

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

Installed python-matplotlib-doc package, point web-browser at
file:///usr/share/doc/python-matplotlib-doc/html/index.html and typed in
a query in the search box.

   * What was the outcome of this action?

The search page opens but no search results are displayed.

   * What outcome did you expect instead?

The results of the search are displayed normally.

(Please note that this issue is also occuring with python-numpy-doc and
python-scipy-doc)

Thank you,
Raj Kiran

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

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

Versions of packages python-matplotlib-doc depends on:
ii  libjs-jquery  3.3.1~dfsg-3

python-matplotlib-doc recommends no packages.

python-matplotlib-doc suggests no packages.

-- no debconf information

Bug#952257: xemacs21-packages: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.

[Mark Brown]

On Sun, Feb 23, 2020 at 02:22:15PM +0100, Lucas Nussbaum wrote:

> Relevant part (hopefully):
> > make[3]: Entering directory '/<>/xemacs-packages/edit-utils'

Not sure how these are generated but there's over 1000 lines of
log here, most of it irrelevant.  This makes it hard to both find
the actual problem and reply to this mail.  The only relevant
part of the log is:

> > cd . && makeinfo  -o edit-utils.info edit-utils.texi
> > cd . && makeinfo  -o tempo.info tempo.texi
> > utf8 "\xE5" does not map to Unicode at 
> > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 1796,  line 22.
> > Malformed UTF-8 character: \xe5\x67\x65 (unexpected non-continuation byte 
> > 0x67, immediately after start byte 0xe5; need 3 bytes, got 1) in pattern 
> > match (m//) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.
> > Malformed UTF-8 character (fatal) at 
> > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.
> > make[3]: *** [../../XEmacs.rules:310: tempo.info] Error 25


signature.asc
Description: PGP signature

Bug#952494: Can not manage wired interface

[gulfstream]

Package: network-manager
Version: 1.22.6-1
Severity: grave


Hi, I found the network-manage can not manage the wired net interface now. 
Message "Wired Unmanaged" was showed, and I have set "managed=true" in 
NetworkManager.conf.

How to resolve this problem?


Thank you!

Gulfstream



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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.16-2
ii  init-system-helpers1.57
ii  libaudit1  1:2.8.5-2+b1
ii  libbluetooth3  5.50-1+b1
ii  libc6  2.29-10
ii  libcurl3-gnutls7.67.0-2
ii  libglib2.0-0   2.62.4-2
ii  libgnutls303.6.12-2
ii  libjansson42.12-1
ii  libmm-glib01.10.4-0.1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.21-4
ii  libnm0 1.22.6-1
ii  libpam-systemd 244.3-1
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libpsl50.20.2-2
ii  libreadline8   8.0-3
ii  libselinux13.0-1+b1
ii  libsystemd0244.3-1
ii  libteamdctl0   1.30-1
ii  libudev1   244.3-1
ii  libuuid1   2.34-0.1
ii  policykit-10.105-26
ii  udev   244.3-1
ii  wpasupplicant  2:2.9+git20200213+877d9a0-1

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1.1
ii  iptables 1.8.4-3
ii  modemmanager 1.10.4-0.1
ii  ppp  2.4.7-2+4.1+b1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.1
pn  libteam-utils

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=true


-- no debconf information

Bug#950886: Withdrawal of bug report

[Henrik Lundberg]

I'd like to withdraw this bug report.
It seems there were an old libcrypt library from libc which had not
been removed during an update.

KR
/Henrik

Bug#952429: spamass-milter: doesn't work with the -s flag to spamc

[Russell Coker]

On Tuesday, 25 February 2020 8:26:07 AM AEDT Don Armstrong wrote:
> Control: tag -1 moreinfo
> 
> On Mon, 24 Feb 2020, Russell Coker wrote:
> > spamc -u russ...@coker.com.au --max-size=10485760 127.0.0.1 < spam.mbox
> > 
> > The above command will correctly scan a file that's more than 500K in
> > size.
> > 
> > spamc -u russ...@coker.com.au 127.0.0.1 --max-size=10485760 < spam.mbox
> > 
> > The above command (differing only in the order of 2 parameters)
> > doesn't work, spamc logs "skipped message, greater than max message
> > size (512000 bytes)" to syslog. The man page for spamc doesn't
> > document this, it may be a bug in spamc.
> > 
> > execve("/usr/bin/spamc", ["/usr/bin/spamc", "-u", "russ...@coker.com.au",
> > "127.0.0.1", "-s", "10485760"], 0x7ffef748a960 /* 15 vars */) = 0
> > 
> > The above is from stracing spamass-milter, it does what spamc doesn't like
> > and there seems to be no way to stop it.
> 
> That's really strange; I would have expected the call to spamc to be:
> 
> /usr/bin/spamc -u rus...@cocker.com.au -d 127.0.0.1 -s 10485760
> 
> That's what the codebase does, and there's no (documented) way to
> specify the host without using -d.

OPTIONS="-u spamass-milter -e -i 127.0.0.1 -r 5 -- -s 10485760"

The above is what I had.  I just realised that -e expects a domain parameter, 
so then "-i" would be taken as a domain and 127.0.0.1 would be taken as 
something else.

/usr/sbin/spamass-milter -P /var/run/spamass/spamass.pid -f -p /var/spool/
postfix/spamass/spamass.sock -u spamass-milter -e -i 127.0.0.1 -r 5 -- -s 
10485760

The above is what was being run.

It seems that any command-line parameter that doesn't start with '-' will be 
passed as a parameter to spamc.  I don't think this is something many people 
will expect or desire.

Maybe a good option would be to log what the spamc parameters will be at 
daemon start time so the user doesn't have to strace it to find out what it's 
doing.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#952481: texlive: mktexpk fails to create tcrm1000

[Norbert Preining]

Hi Holger,

On Mon, 24 Feb 2020, Holger Wansing wrote:
> http://qa-logs.debian.net/2020/02/22/installation-guide_20191229_unstable.log

What is there is
Writing build.out.el.amd64/html/index.html for book
Info: creating .pdf file...

kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 
tcrm1000
mkdir: cannot create directory 
‘build.tmp.el.i386/dblatex/mt7684.tmp’: No such file or directory
kpathsea: Appending font creation commands to missfont.log.

which means that something in the build process is hosed .. either write
permissions or whatever, so this is strange.

Furthermore, by default these files are generated in /tmp, unless you
set TEMPDIR to something else, see /usr/share/texlive/texmf-dist/web2c/mktex.opt
if test -n "$TMPDIR"; then
  TEMPDIR="${TMPDIR}/mt$$.tmp"
else
  TEMPDIR="/tmp/mt$$.tmp"
fi
...
(umask 077 && mkdir "$TEMPDIR") || exit 1
So if $TMPDIR is not available, then there is something strange going
on.


Anyway, you **don't** want pk fonts (pixel fonts) in a PDF, so you
**should** depend on the
cm-super
fonts to get proper type1 fonts that are scalable (without pixelation).

My guess (wild guess) is the following:
- before tcrm fonts were not necessary because they were not used by the
  LaTeX kernel, and thus no extra build process (mktex*) was called
- the new LaTeX kernel requires tc fonts (because textcomp is loaded)
- your package *always* had some setup that prevented creating of
  directories or similar
- the recent changes made this obvious.

So as said, there are two things to be done:
- either make the directory writable, then the fonts will be generated
  and included into the pdf properly
- depend on cm-super
or both.

Best

Norbert

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

Bug#952493: xavs2: please make the build reproducible

[Chris Lamb]

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

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
xavs2 could not be built reproducibly.

Patch attached, although that xavs2 will still vary due to the
embedding the path in calls to assert(...).

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/1003_reproducible_build.patch  1969-12-31 
16:00:00.0 -0800
--- b/debian/patches/1003_reproducible_build.patch  2020-02-24 
15:38:11.940987381 -0800
@@ -0,0 +1,17 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2020-02-24
+
+--- xavs2-1.3.orig/version.sh
 xavs2-1.3/version.sh
+@@ -24,7 +24,9 @@ VER_MAJOR=`echo $(($api / 10))`
+ VER_MINOR=`echo $(($api % 10))`
+ 
+ # date and time information
+-BUILD_TIME=`date "+%Y-%m-%d %H:%M:%S"`
++DATE_FMT="+%Y-%m-%d %H:%M:%S"
++SOURCE_DATE_EPOCH="${SOURCE_DATE_EPOCH:-$(date +%s)}"
++BUILD_TIME=$(date -u -d "@$SOURCE_DATE_EPOCH" "$DATE_FMT" 2>/dev/null || date 
-u -r "$SOURCE_DATE_EPOCH" "$DATE_FMT" 2>/dev/null || date -u "$DATE_FMT")
+ 
+ # generate the file version.h
+ echo "// 
==="  > 
version.h
--- a/debian/patches/series 2020-02-24 15:30:28.338962779 -0800
--- b/debian/patches/series 2020-02-24 15:38:10.548980153 -0800
@@ -2,3 +2,4 @@
 020181225~ffa8095.patch
 1001_allow_preseeded_revision.patch
 1002_fix_arch_optimizations.patch
+1003_reproducible_build.patch

Bug#952492: net-tools: netstat address fields are truncated on IPv6

[Russell Coker]

Package: net-tools
Version: 1.60+git20180626.aebd88e-1
Severity: normal
Tags: upstream

tcp6   0  0 2a01:4f8:140:71f5::d:25 :::*LISTEN 

Above is part of the output of "netstat -tln" on one of my systems.  It
doesn't show the last 8 characters of the address so I can't determine
which of the addresses is being used.  Even worse the truncated address is a
valid IPv6 address.

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages net-tools depends on:
ii  libc62.28-10
ii  libselinux1  2.8-1+b1

net-tools recommends no packages.

net-tools suggests no packages.

-- no debconf information

Bug#948532: closed by Debian FTP Masters (reply to Ricardo Mones ) (Bug#948532: fixed in claws-mail 3.17.5-1)

[Laurent Bigonville]

found 948532 3.17.5-1
thanks

Hello,

Le 24/02/20 à 20:51, Debian Bug Tracking System a écrit :


* Switch to libenchant-2-dev (Closes: #948532)


Looks like libclaws-mail-dev still depends against libenchant-dev, so 
it's not fully fixed


Kind regards,

Laurent Bigonville

Bug#952490: ITP: golang-github-google-wire -- Compile-time Dependency Injection for Go

[Anthony Fok]

On Mon, Feb 24, 2020 at 4:27 PM Anthony Fok  wrote:
> Reason for packaging:
>  Required by hugo >= 0.56.0, and
>  Google's wire command may be helpful too.

I was not entirely accurate and should clarify:
hugo does not depend on github.com/google/wire directly.
Rather, hugo depends on gocloud.dev which requires github.com/google/wire.

Cheers,
Anthony

Bug#952490: ITP: golang-github-google-wire -- Compile-time Dependency Injection for Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-google-wire
  Version : 0.4.0-1
  Upstream Author : The Wire Authors, Google LLC
* URL : https://github.com/google/wire
* License : Apache-2.0
  Programming Lang: Go
  Description : Compile-time Dependency Injection for Go

 Wire: Automated Initialization in Go
 .
 Wire is a code generation tool that automates connecting components
 using dependency injection.  Dependencies between components are
 represented in Wire as function parameters, encouraging explicit
 initialization instead of global variables.  Because Wire operates
 without runtime state or reflection, code written to be used with
 Wire is useful even for hand-written initialization.
 .
 For an overview, see the introductory blog post
 https://blog.golang.org/wire

Reason for packaging:
 Required by hugo >= 0.56.0, and
 Google's wire command may be helpful too.

Note:
 An existing Debian go-wire package of the Tendermint project
 also provides /usr/bin/wire, but actually Tendermint upgraded
 and renamed the project from Go-Wire to Go-Amino back in April 2018.
 I will reach out to go-wire’s original packager Alessio Treglia
 to migrate Debian’s go-wire to go-amino too.
 So there should be no conflict or namespace clash with Google’s Wire.

Bug#952491: RM: mono-reference-assemblies -- ROM; superseeded by mono-devel

[Dimitri John Ledkov]

Package: ftp.debian.org
Version: 3.12.1+dfsg-2
Severity: normal

#debian-uk

22:22:30  i don't have a working MTA configured anywhere
 right now, plz file an RM: RoM for mono-reference-assemblies (its
 function is subsumed into mono-devel now)

The new mono-devel is uploaded to unstable already.

Regards,

Dimitri.

Bug#952489: SyntaxWarning: "is" with a literal. Did you mean "=="?

[Emmanuel Arias]

Package: python3-plotly
Version: 4.4.1+dfsg-1
Severity: normal

Dear Maintainer,

During the installation of python3-plotly on testing
I have the next Warning:

Setting up python3-plotly (4.4.1+dfsg-1) ...
/usr/lib/python3/dist-packages/_plotly_utils/utils.py:214: SyntaxWarning: "is" 
with a literal. Did you mean "=="?
  if (iso_string.split("-")[:3] is "00:00") or (iso_string.split("+")[0] is 
"00:00"):
/usr/lib/python3/dist-packages/_plotly_utils/utils.py:214: SyntaxWarning: "is" 
with a literal. Did you mean "=="?
  if (iso_string.split("-")[:3] is "00:00") or (iso_string.split("+")[0] is 
"00:00"):
/usr/lib/python3/dist-packages/plotly/figure_factory/_candlestick.py:194: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if direction is "increasing":
/usr/lib/python3/dist-packages/plotly/figure_factory/_candlestick.py:199: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif direction is "decreasing":
/usr/lib/python3/dist-packages/plotly/figure_factory/_ohlc.py:176: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if direction is "increasing":
/usr/lib/python3/dist-packages/plotly/figure_factory/_ohlc.py:179: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif direction is "decreasing":
/usr/lib/python3/dist-packages/plotly/matplotlylib/renderer.py:460: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if props["offset_coordinates"] is "data":
/usr/lib/python3/dist-packages/plotly/matplotlylib/renderer.py:572: 
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if props["coordinates"] is not "data":
-V is ignored in pypy3compile


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

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

Versions of packages python3-plotly depends on:
ii  python33.7.5-3
ii  python3-decorator  4.3.0-1.1
ii  python3-nbformat   5.0.4-1
ii  python3-requests   2.22.0-2
ii  python3-retrying   1.3.3-4
ii  python3-six1.14.0-2
ii  python3-tz 2019.3-1

python3-plotly recommends no packages.

Versions of packages python3-plotly suggests:
ii  ipython37.12.0-1
pn  python3-ipykernel   
ii  python3-matplotlib  3.1.2-2
pn  python3-pandas  
pn  python3-scipy   

-- no debconf information

Bug#952488: TAG: qemu-system-riscv -- QEMU is a fast processor emulator

[Alistair]

Package: wnpp
Severity: ITP

QEMU is a fast processor emulator: currently the package supports RISC-V 
emulation. By using dynamic translation it achieves reasonable speed while 
being easy to port on new host CPUs.

This package provides the full system emulation binaries to emulate the 
following RISC-V hardware: riscv32 riscv64.

In system emulation mode QEMU emulates a full system, including a processor and 
various peripherals. It enables easier testing and debugging of system code. It 
can also be used to provide virtual hosting of several virtual machines on a 
single server.

https://git.qemu.org/?p=qemu.git

Copyright: https://git.qemu.org/?p=qemu.git;a=blob_plain;f=LICENSE;hb=HEAD

The qemu-system-arm package has the same license and can be found here: 
https://metadata.ftp-master.debian.org/changelogs//main/q/qemu/qemu_3.1+dfsg-8+deb10u4_copyright

Bug#951539: ITP: bruteforce-wallet -- Try to find a password of a encrypted wallet file

[Samuel Henrique]

Hello Sam,

I'm gonna assume that the full description of the package addresses the
issue of describing which wallets does it works with and sponsor the upload
for Francisco.

Please feel free to suggest a change to the short description, if you think
that should be changed as well (we can always change it later).

Regards,

-- 
Samuel Henrique 

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli]

On Sat, 22 Feb 2020 19:03:48 +0100 Johannes Schauer wrote:

[...]
> for what it's worth I'm attaching the script I am using to re-generate my
> autopkgtest qemu image. I uploaded a few packages today and just successfully
> used that script so I can confirm it working.

I cannot spot any significant difference between your script and mine
(apart from the fact that I have recently added "sync : umount / :
shutdown" to the guestfish command-line, as you suggested)...

I really cannot understand what's going on! :-(

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpkXfzkZehUw.pgp
Description: PGP signature

Bug#949461: repo is an empty package in unstable/testing, failing it's autopkg tests

[Marcos Marado]

Hi,

An update to this package, based on salsa's repository, is available in
https://github.com/marado/repo . It bumps repo's version to the latest,
as well as fixes the empty package issue.

$ head debian/changelog
repo (2.4.1-1) unstable; urgency=medium

  [ Marcos Marado ]
  * New upstream version 2.4.1
  * updated set-python-shebang.patch
  * Pass autopkg tests, by reverting dh compatibility (Closes: #949461)

 -- Marcos Marado   Mon, 24 Feb 2020 14:00:00 -0700

Bug#947847: please install systemd-sysusers using update-alternatives

[Thomas Goirand]

On 2/21/20 9:10 PM, Niko Tyni wrote:
> Hi Thomas,
> 
> on IRC recently you said:
> 
>  23:24 < zigo> If you're just answering about update-alternatives, then you 
> haven't paid attention to what I 
>wrote in the bug report.
>  23:25 < zigo> And IMO, missing the point ...
> 
> As I read the above, the systemd maintainers declined your suggestion to
> add support for handling /usr/bin/systemd-sysusers with the alternatives
> system, and you then requested the Technical Committee to overrule them.
> 
> If this is not the case, could you please state clearly what you want
> us to decide.
> 
> Among other things, you later mention that a separate systemd-sysusers
> package would be acceptable to you, pointing to #946456 . This avenue
> doesn't seem to be exhausted yet?

Hi,

IMO, the question is a bit more hard than just "having packages that
conflicts" or "using update-alternatives". As I think the issue is
complicated, I would have like to have the tech ctte opinion on how to
handle this case, for the Debian project at large. This is a general
opinion that I'm asking for here, and guidance on how to set the policy
for programs using systemd-sysusers, and the ones willing to
(re-)implement the systemd interface to be used as an alternative
implementation. It is my opinion that it's not good enough for the
maintainer of systemd and systemd-sysusers to just decide, as every
program using sysuser may be affected. Also please keep in mind that
this is not only about sysusers, but a more broad scope (tmpfiles is
concerned too... more may come!).

Using update-alternatives for /bin/systemd-sysusers is what I thought
was the best option, because cheap and easy to implement, with the nice
advantage that we can have both packages installed at the same time, and
programs can decide if they want a specific implementation or just any
of them.

However, if everyone is in the opinion that it's a bad idea, then I'm
open to other solutions. Having systemd package systemd-sysusers (and
systemd-tmpfiles) as separate package is also an option that would work.
It's IMO annoying, because it takes a way longer to switch from one
implementation to another, when update-alternatives instantly changes
the configuration. We also loose the co-instability, and the fact that a
given program can actively decide to use a specific implementation. But
that still works too.

However, packaging systemd-sysusers as a separate package it isn't as
easy as one may think. See #946456 for the discussion. Using
update-alternatives should have been a way easier. At the present
moment, I'm not aware of any decision from the systemd maintainer, as
this looks like not as easy as one may think.

The only thing which I do *not* want to do, is using dpkg-divert. It is
my strong opinion that this is a disservice to our users to do that,
because dpkg-divert is rarely known, yet even understood by the average
Debian users, so they wouldn't be able to even understand what happened
to their system. We should be able to find a much nicer way to implement
things.

I'm also strongly against a /bin/sysusers which both programs would
update-alternatives to, because then, we have a different implementation
than on other platforms (this would be Debian specific).

Cheers,

Thomas Goirand (zigo)

Bug#950747: projectl: Projectl fails to run with current libgphobos76

[Matthias Klose]

Control: severity -1 important

this is a won't fix.  It will be addressed when GCC 10 becomes the default
compiler (and libgphobos changes the soname).  There is now a binNMU for 
projectl.

Bug#952487: ITP: analizo -- multi-language source code analysis toolkit

[Joenio Costa]

Package: wnpp
Severity: wishlist
Owner: Joenio Costa 

* Package name: analizo
  Version : 1.23.0
  Upstream Author : Joenio Costa 
* URL : http://www.analizo.org
* License : GPL-3+
  Programming Lang: Perl
  Description : multi-language source code analysis toolkit

Analizo is a suite of source code analysis tools, aimed at being
language-independent and extensible, analizo parses source code in multiple
languages and report useful information about it, such as module dependency,
source code metrics and more.
.
Analizo uses doxyparse to parse the source code, and is currently tested and
expected to work well with C, C++, Java and C# source code.

The plan is maintain it as part of the Debian Perl Group umbrella.

Bug#952486: node-typescript-types: Acorn supply now types

[Bastien Roucariès]

Package: node-typescript-types
Version: 20190926-2
Severity: serious
Justification: break unrelated package

Dear Maintainer,

acorn 6 supply on debian/unstable its type. So do not carry type here.

Thanks




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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.4.0-4-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

node-typescript-types depends on no packages.

node-typescript-types recommends no packages.

Versions of packages node-typescript-types suggests:
ii  node-typescript  3.7.5-1

-- no debconf information

Bug#417118: Gruß

[MUSTERMANN MAXIMLIAN HANNOVER]

Gruß

In einer kurzen Einführung bin ich Rechtsanwältin Mustermann Maximlia
Hannover aus Nordirland, aber jetzt lebe ich in London. Ich habe Ihnen
eine E-Mail über Ihre verstorbene Verwandte gesendet, aber ich habe
keine Antwort von Ihnen erhalten. Der Verstorbene ist ein Bürger von
Ihnen Land mit dem gleichen Nachnamen wie Sie, er ist ein Exporteur
von Gold hier in London.

'Er starb vor einigen Jahren mit seiner Familie, verließ sein
Unternehmen und hinterlegte riesige Geldbeträge bei der UBS Investment
Bank hier in London.

Ich bin sein persönlicher Anwalt und ich brauche Ihre Mitarbeit. Damit
wir das Geld von der Bank erhalten können, bevor die Regierung es
endgültig beschlagnahmt, beträgt der Gesamtbetrag in der Bank 7,7
Millionen Pfund Sterling, wird aber erklärt, weitere Einzelheiten,
wenn ich davon höre Sie.

Bug#952485: RM: node-acorn-object-spread -- ROM; Obsolete newer acorn include it (no need for plugin)

[Bastien Roucariès]

Package: ftp.debian.org
Severity: normal

Please remove

Bug#952484: RM: node-acorn-jsx -- ROM; included in acorn package

[Bastien Roucariès]

Package: ftp.debian.org
Severity: normal

Please remove

Bug#952483: RM: node-acorn-dynamic-import -- ROM; included in acorn package

[Bastien Roucariès]

Package: ftp.debian.org
Severity: normal

Please remove

Bug#952482: webkit2gtk: Please pass -mlra and -fno-move-loop-invariants on sh4

[John Paul Adrian Glaubitz]

Source: webkit2gtk
Version: 2.26.4-1
Severity: normal
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh4

Hi!

In order for webkit2gtk to build on sh4, it's necessary to enable the
new register allocator on sh4 (LRA), see [1, 2].

Also, there is a regression in gcc-9 and gcc-10 that needs one optimization
to be disabled as otherwise the compiler will crash with an internal
compiler error (ICE) [3].

Please apply the attached patch for the next upload.

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- webkit2gtk-2.26.4/debian/rules.orig 2020-02-14 14:55:40.0 +0100
+++ webkit2gtk-2.26.4/debian/rules  2020-02-24 23:06:26.482766937 +0100
@@ -37,6 +37,14 @@
EXTRA_CMAKE_ARGUMENTS += -DUSE_LD_GOLD=OFF
 endif
 
+# Enable the new register allocator on SH and
+# disable one particular optimization flag
+# See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
+# and: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
+ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4))
+CPPFLAGS += -mlra -fno-move-loop-invariants
+endif
+
 ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
EXTRA_CMAKE_ARGUMENTS += -DUSE_SYSTEM_MALLOC=ON
CPPFLAGS += -DRELEASE_WITHOUT_OPTIMIZATIONS

Bug#952481: texlive: mktexpk fails to create tcrm1000

[Holger Wansing]

Package: texlive-base
Version: 2019.20200218-1


Hi,

since some days the debian installation-guide fails to create the Greek PDF
variant due to a texlive breakage when creating tcrm font file.

I saw that the tcrm* files have been moved from the texlive-fonts-recommended
package into the texlive-base package.
However, adding texlive-base as a new build-depends does not fix the error.

Maybe something more is broken within texlive with this?
(sorry if it sounds arrogant, if I suspect the reason for the breakage in 
texlive, but I have no idea where to look otherwise.)

A log from the failed build can be found here:
http://qa-logs.debian.net/2020/02/22/installation-guide_20191229_unstable.log
(search for "Running mktexpk")


thanks for help

Holger


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

Bug#952480: RM: node-acorn -- NBS; node-acorn binary package is now a virtual package build from acorn and provide by node-debbundle-acorn

[Bastien Roucariès]

Package: ftp.debian.org
Severity: normal


Please remove

Bug#950585: binutils-dev: included log files introduce reproducibility issues

[Vagrant Cascadian]

On 2020-02-22, Matthias Klose wrote:
>> I'm not sure what the rationale for including these test logs in the
>> package is, but from a reproducible builds perspective, ideally these
>> would simply not be included at all.
>
> that's not an option.  this is all useful information for debugging purposes,
> and you'll find that in the GCC packages as well.  Having it turned off by
> default defeats the purpose.

So, my attempt at sanitizing them removed too much information; ok.

Why can't these test logs be output to the build log instead of being
embedded in the package? What's the use-case that needs them to be in
the package itself?

From what I recall, binutils was reproducible in debian testing for a
while before these logs were added. While GCC was not ever reproducible
thus far, it is another core part of the toolchain that I would hope
could one day be made reproducible.


> I think I filed a bug report that builds should be
> able to generate their own artifacts, as the autopkg tests are doing that,
> however that probably will take a while to implement.

I would be very interested in this bug report; against what package?


> Or you could add a override database for files which are expected to differ.

This is considerably more complicated than running a checksum on the
resulting .deb files and is another opportunity for bugs to lead to
incorrect reproducibility results... which I think has actually happened
when trying this kind of approach in the past, though I don't have a
reference off the top of my head.

Exploring avenues to put files like this into some separate artifact for
things that are not reproducible might be one avenue; I know that the
debian-installer packages ship some artifacts which are not
.deb/.dbgsym/.udeb... but this still makes it more difficult to compare
the resulting objects... worried about how to get that right, but maybe
we, as reproducible builds, need to explore that an an option?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#952479: urwid-satext: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: urwid-satext
Version: 0.8.0~hg143.144bdf877d21-1
Severity: serious
Justification: out-of-sync unstable-to-testing
X-Debbugs-CC: deba...@debian.org robo...@debian.org m...@lm7.fr

Dear packag urwid-satext maintainers,

The latest upload of your package was not a source-only upload. As a result,
it did not migrate to Testing.

According to
https://lists.debian.org/debian-devel-announce/2020/02/msg5.html ,
packages that are out-of-sync between testing and unstable for more than 60
days are considered as having a Release Critical bug. Your package has been
out-of-sync for 119 days.

Please consider making another source-only upload to allow testing migration
according to https://wiki.debian.org/SourceOnlyUpload . Let me know if you
need any help. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#951494: marked as pending in procps

[Mike Gabriel]

Hi Craig,

On  Mo 24 Feb 2020 22:14:32 CET, Craig Small wrote:


can you please upload the above fix? There are several packages that
FTBFS because of bug #951494. Or are there reasons for holding back the
upload?


Hi Mike,
  Should be available very soon. I've just uploaded the -2 package now.  It
was sitting there ready but was trying to work out why the CI tests failed
(came down to reprotest brokeness again).
Apologies for the inconvenience. One day I'll work out the deb-ci syntax
and put something in to check for a broken symlink.

 - Craig


thanks!
Mike
--

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

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



pgpLMNg8Ynr3J.pgp
Description: Digitale PGP-Signatur

Bug#952478: cloudpickle: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: cloudpickle
Version: 1.2.1-2
Severity: serious
Justification: out-of-sync unstable-to-testing
X-Debbugs-CC: di...@ghic.org

Dear cloudpickle maintainer,

The latest upload of your package was not a source-only upload. As a result,
it did not migrate to Testing.

According to
https://lists.debian.org/debian-devel-announce/2020/02/msg5.html ,
packages that are out-of-sync between testing and unstable for more than 60
days are considered as having a Release Critical bug. Your package has been
out-of-sync for 115 days.

Please consider making another source-only upload to allow testing migration
according to https://wiki.debian.org/SourceOnlyUpload . Let me know if you
need any help. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#952477: cloudpickle: Please package the latest upstream version (1.3.0)

[Boyuan Yang]

Source: cloudpickle
Version: 1.2.1-2
Severity: normal
X-Debbugs-CC: di...@ghic.org

Dear package cloudpickle maintainer,

The upstream of cloudpickle has release a new upstream version (1.3.0). Please
consider packaging it.

-- 
Thanks,
Boyuan Yang


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

Bug#952476: cupp: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: cupp
Version: 0.0+20190501.git986658-4
Severity: serious
Justification: out-of-sync unstable-to-testing

Dear cupp maintainer,

The latest upload of your package was not a source-only upload. As a result,
it did not migrate to Testing.

According to
https://lists.debian.org/debian-devel-announce/2020/02/msg5.html ,
packages that are out-of-sync between testing and unstable for more than 60
days are considered as having a Release Critical bug. Your package has been
out-of-sync for 80 days.

Please consider making another source-only upload to allow testing migration
according to https://wiki.debian.org/SourceOnlyUpload . If you need any help,
please let me know. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#952475: ats2-lang: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: ats2-lang
Severity: serious
Version: 0.3.13-1
Justification: out-of-sync unstable-to-testing

Dear ats2-lang maintainer,

The latest upload of your package was not a source-only upload. As a result,
it did not migrate to Testing.

According to 
https://lists.debian.org/debian-devel-announce/2020/02/msg5.html ,
packages that are out-of-sync between testing and unstable for more than 60
days are considered as having a Release Critical bug. Your package has been
out-of-sync for 67 days.

Please consider making another source-only upload to allow testing migration
according to https://wiki.debian.org/SourceOnlyUpload . Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#952474: ferm: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: ferm
Severity: important
Version: 2.5-1
X-Debbugs-CC: formo...@debian.org

Hi formorer,

The latest upload of package ferm in Debian was not a source-only upload. As a
result, it did not migrate to Testing.

Please make another source-only upload to allow its testing migration
according to https://wiki.debian.org/SourceOnlyUpload . Thanks!


-- 
Regards,
Boyuan Yang


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

Bug#952473: opensysusers: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: opensysusers
Version: 0.5.1-1
Severity: important
X-Debbugs-CC: z...@debian.org

Hi zigo,

Package opensysusers was uploaded onto Sid but no following source-only upload
was made. As a result, it did not migrate to Testing.

Please make another source-only upload to allow its testing migration
according to https://wiki.debian.org/SourceOnlyUpload .

-- 
Thanks,
Boyuan Yang


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

Bug#952472: RFP: hsd -- blockchain-based top-level domain DNS protocol implementation

[Chris Lamb]

Package: wnpp
Severity: wishlist
Owner: la...@debian.org

* Package name: hsd
* URL : https://github.com/handshake-org/hsd
* License : MIT
  Programming Lang: Javascript / NodeJS
  Description : blockchain-based top-level domain DNS protocol 
implementation
  
>From upstream's website:

  Handshake is a UTXO-based blockchain protocol which manages the
  registration, renewal and transfer of DNS top-level domains (TLDs).
  Our naming protocol differs from its predecessors in that it has no
  concept of namespacing or subdomains at the consensus layer. Its
  purpose is not to replace DNS, but to replace the root zone file and
  the root servers. HSD is an implementation of the Handshake
  Protocol. 
 
I've pushed some initial packaging here which would be more than happy
for someone to take over:

  https://salsa.debian.org/lamby/pkg-hsd

... but I think it will require a number of libraries to be packaged
too, for example bcrypto/lib/blake2b, etc.


Regards,

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

Bug#952471: pure-ftpd: CVE-2020-9365

[Salvatore Bonaccorso]

Source: pure-ftpd
Version: 1.0.49-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for pure-ftpd.

CVE-2020-9365[0]:
| An issue was discovered in Pure-FTPd 1.0.49. An out-of-bounds (OOB)
| read has been detected in the pure_strcmp function in utils.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-9365
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9365
[1] 
https://github.com/jedisct1/pure-ftpd/commit/36c6d268cb190282a2c17106acfd31863121b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#952429: spamass-milter: doesn't work with the -s flag to spamc

[Don Armstrong]

Control: tag -1 moreinfo

On Mon, 24 Feb 2020, Russell Coker wrote:
> spamc -u russ...@coker.com.au --max-size=10485760 127.0.0.1 < spam.mbox
> 
> The above command will correctly scan a file that's more than 500K in size.
> 
> spamc -u russ...@coker.com.au 127.0.0.1 --max-size=10485760 < spam.mbox
> 
> The above command (differing only in the order of 2 parameters)
> doesn't work, spamc logs "skipped message, greater than max message
> size (512000 bytes)" to syslog. The man page for spamc doesn't
> document this, it may be a bug in spamc.
> 
> execve("/usr/bin/spamc", ["/usr/bin/spamc", "-u", "russ...@coker.com.au", 
> "127.0.0.1", "-s", "10485760"], 0x7ffef748a960 /* 15 vars */) = 0
> 
> The above is from stracing spamass-milter, it does what spamc doesn't like and
> there seems to be no way to stop it.

That's really strange; I would have expected the call to spamc to be:

/usr/bin/spamc -u rus...@cocker.com.au -d 127.0.0.1 -s 10485760

That's what the codebase does, and there's no (documented) way to
specify the host without using -d.

Have you modified the init script? Or is there something else
interesting happening here?

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

Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
 -- Antoine de Saint-Exupe'ry, Terres des Hommes

Bug#940793: polkit-kde-1 package is not in unstable now

[Alexander Kernozhitsky]

Control: severity -1 serious

Hello,

it seems that polkit-kde-1 is removed from testing/unstable now, so I think 
the severity can be raised.

-- 
Alexander Kernozhitsky

Bug#952470: netdata: fails to send alarm mail

[Riri Soft]

Package: netdata
Version: 1.19.0-2~bpo10+1
Severity: important

Dear Maintainer,

I did my own backport of netdata 1.19.0-2 to buster without any change
from unstable sources and noticed that mail alarms do not work.

I see some "Failed to create spool file
/var/spool/exim4//input//1j5uL8-0001du-VH-D: Read-only file system"
errors from exim logs and "failed to send email notification" from netdata logs

I believe that the change introduced by
https://salsa.debian.org/debian/netdata/-/commit/421a6b0b905cd3cbb51a2cdf193f75a4166a6e5b
fallbacks the fix for this issue already reported in #851852 and fixed
in 
https://salsa.debian.org/debian/netdata/-/commit/ddac3bd0ae77f5a722df7ae2ae1938055c20012a

I believe that the systemd service file should be reconsidered as far as
filesystem permissions are concerned.

I would recommend the following as a compromise between security and
functionality, with the additional benefit of simplifying the service
file maintenance:

ProtectSystem=strict
ReadWriteDirectories=/var

What do you think ?
Cheers !

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

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

Versions of packages netdata depends on:
ii  netdata-core  1.19.0-2~bpo10+1
ii  netdata-plugins-bash  1.19.0-2~bpo10+1
ii  netdata-web   1.19.0-2~bpo10+1

Versions of packages netdata recommends:
pn  netdata-plugins-nodejs  
ii  netdata-plugins-python  1.19.0-2~bpo10+1

netdata suggests no packages.

-- no debconf information

Bug#952233: frobby: FTBFS: ! LaTeX Error: File `listofitems.sty' not found.

[Doug Torrance]

Control: reassign -1 texlive-latex-extra
Control: merge 921297 -1

On Sun, Feb 23, 2020 at 8:21 AM Lucas Nussbaum  wrote:
> > ! LaTeX Error: File `listofitems.sty' not found.

Thanks for the report!  This bug was previously reported in #921300,
which was merged with #921297.

Bug#952468: libtss2-dev: Don't ship libtss2-tcti-default.so

[Jonathan McDowell]

Package: libtss2-dev
Version: 2.3.2-1
Severity: normal

The existence of libtss2-tcti-default.so changes the default ordering of
how TSS2 tries to find the TPM2 device. Without the -dev package
installed everything is ok, but with it the symlink from default to
device causes /dev/tpm0 to be tried first resulting in errors being
output:

ERROR:tcti:src/tss2-tcti/tcti-device.c:439:Tss2_Tcti_Device_Init() Failed to 
open device file /dev/tpm0: Permission denied  
WARNING:tcti:src/tss2-tcti/tctildr.c:62:tcti_from_init() TCTI init for function 
0x7efc49ceee00 failed with a000a 
WARNING:tcti:src/tss2-tcti/tctildr.c:92:tcti_from_info() Could not initialize 
TCTI named: tcti-device 
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:150:tcti_from_file() Could not initialize 
TCTI file: libtss2-tcti-default.so 

It does fall back to /dev/tpmrm0 after this, but it would be better not
to output the errors/warnings at all.

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

Kernel: Linux 5.5.6 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtss2-dev depends on:
ii  libgcrypt20-dev  1.8.5-3
ii  libtss2-esys02.3.2-1

libtss2-dev recommends no packages.

libtss2-dev suggests no packages.

-- no debconf information

Bug#951494: marked as pending in procps

[Craig Small]

> can you please upload the above fix? There are several packages that
> FTBFS because of bug #951494. Or are there reasons for holding back the
> upload?
>
Hi Mike,
  Should be available very soon. I've just uploaded the -2 package now.  It
was sitting there ready but was trying to work out why the CI tests failed
(came down to reprotest brokeness again).
Apologies for the inconvenience. One day I'll work out the deb-ci syntax
and put something in to check for a broken symlink.

 - Craig

Bug#952269: nsis: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2

[Didier 'OdyX' Raboud]

Le dimanche, 23 février 2020, 14.24:13 h CET Lucas Nussbaum a écrit :
> Source: nsis
> Version: 3.05-1
> Severity: serious
> Justification: FTBFS on amd64
> (…)
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > scons -c  VERSION=3.05-1 VER_MAJOR=3 VER_MINOR=05 VER_REVISION=1
> > PREFIX=/usr PREFIX_CONF=/etc CHMDOCS=0 STRIP_CP=no  UNICODE=yes
> > SKIPUTILS=zip2exe 2>&1 scons: Reading SConscript files ...
> > Mkdir("build/urelease/config")
> > Delete("nsis-3.05-1")
> > Delete(".instdist")
> > Delete(".test")
> > Using GNU tools configuration
> > Checking for linker flag $MAP_FLAG... yes
> > Checking for linker flag $MAP_FLAG... yes
> > Checking for memcpy requirement... no
> > Checking for memset requirement... no
> > Checking for linker flag -pthread... yes
> > Checking for __BIG_ENDIAN__... no
> > i686-w64-mingw32-gcc --version
> > i686-w64-mingw32-gcc (GCC) 8.3-win32 20191201
> > Copyright (C) 2018 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > 
> > g++ --version
> > g++ (Debian 9.2.1-29) 9.2.1 20200220
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > 
> > Checking for C library gdi32... no
> > Checking for C library user32... no
> > Checking for C library pthread... yes
> > Checking for C library iconv... no
> > Checking for C library shlwapi... no
> > Checking for C library oleaut32... no
> > Checking for C library dl... yes
> > Checking for C library gdi32... no
> > Checking for C library iconv... no
> > Checking for C library pthread... yes
> > Checking for C library user32... no
> > Checking for C library oleaut32... no
> > Checking for C++ library cppunit... yes
> > scons: done reading SConscript files.
> > scons: Cleaning targets ...
> > scons: done cleaning targets.
> > Removing autogenerated file .sconsign.dblite
> > Removing autogenerated directory .sconf_temp
> > rm -rf .sconf_temp .sconsign.dblite SCons/Tools/crossmingw.pyc build
> > config.log .test /<>/build/test rm -f Source/exehead/sconf.h
> > Source/version.h Source/defines.h config.log make[1]: Leaving directory
> > '/<>'
> > 
> >dh_clean
> >  
> >  dpkg-source -b .
> > 
> > dpkg-source: info: using source format '3.0 (quilt)'
> > dpkg-source: info: building nsis using existing ./nsis_3.05.orig.tar.gz
> > dpkg-source: info: using patch list from debian/patches/series
> > dpkg-source: error: cannot represent change to
> > SCons/Tools/__pycache__/crossmingw.cpython-37.pyc: binary file contents
> > changed dpkg-source: error: add
> > SCons/Tools/__pycache__/crossmingw.cpython-37.pyc in
> > debian/source/include-binaries if you want to store the modified binary
> > in the debian tarball dpkg-source: error: unrepresentable changes to
> > source
> > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status
> > 2


Even after fixing this bug (pushed to the repo), I still can't manage to build 
NSIS:

scons: done reading SConscript files.
scons: Building targets ...
scons: *** Do not know how to make File target `install-utils' (/
<>/install-utils).  Stop.
scons: building terminated because of errors.
make[1]: *** [debian/rules:194: override_dh_auto_test-indep] Error 2

@Thomas: any idea?

OdyX

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

Bug#951991: bali-phy: FTBFS: detected.hpp:52:7: error: invalid use of incomplete type ‘struct nlohmann::detail::detector

[Benjamin Redelings]

I will take a look.

The cause is not completely obvious:  The compile failure goes away when 
using either (i) clang instead of gcc, or (ii) version 3.5 of 
nlohmann-json.  It also does not occur with the master branch of bali-phy.


-BenRI

On 2/24/20 6:09 AM, Andreas Tille wrote:

Control: tags -1 upstream
Control: forwarded -1 Benjamin Redelings 

Hi Benjamin,

can you please have a look?

Thanks a lot

  Andreas.

On Sun, Feb 23, 2020 at 08:31:45AM +0100, Lucas Nussbaum wrote:

Source: bali-phy
Version: 3.4.1+dfsg-2
Severity: serious
Justification: FTBFS on amd64
Tags: buster sid
Usertags: ftbfs-20200222 ftbfs-buster

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

Relevant part (hopefully):

c++ -Isrc/25a6634@@bali-phy@exe -Isrc -I../src -I. -I../ -I/usr/include/eigen3 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++14 -DHAVE_CONFIG_H -Wall 
-Wextra -Wno-sign-compare -Woverloaded-virtual -Wstrict-aliasing -Wno-unknown-pragmas 
-Wno-maybe-uninitialized -DNDEBUG -DNDEBUG_DP -O3 -funroll-loops -ffast-math -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -O3 -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ 
'src/25a6634@@bali-phy@exe/util_ptree.cc.o' -MF 
'src/25a6634@@bali-phy@exe/util_ptree.cc.o.d' -o 
'src/25a6634@@bali-phy@exe/util_ptree.cc.o' -c ../src/util/ptree.cc
In file included from /usr/include/nlohmann/detail/meta/type_traits.hpp:11,
  from 
/usr/include/nlohmann/detail/conversions/from_json.hpp:19,
  from /usr/include/nlohmann/adl_serializer.hpp:5,
  from /usr/include/nlohmann/json.hpp:51,
  from ../src/util/json.hh:3,
  from ../src/util/ptree.H:12,
  from ../src/util/ptree.cc:1:
/usr/include/nlohmann/detail/meta/detected.hpp: In substitution of ‘template class Op, class ... 
Args> using is_detected_exact = std::is_same::type> [with Expected = void; Op = nlohmann::detail::to_json_function; Args = 
{nlohmann::basic_json<>::json_serializer, nlohmann::basic_json, std::allocator >, bool, long int, long unsigned int, double, 
std::allocator, nlohmann::adl_serializer>&, ptree}]’:
/usr/include/nlohmann/detail/meta/type_traits.hpp:121:27:   required from ‘constexpr const 
bool nlohmann::detail::has_to_json, ptree, void>::value’
/usr/include/nlohmann/detail/meta/type_traits.hpp:353:27:   required from ‘constexpr const 
bool nlohmann::detail::is_compatible_type_impl, ptree, 
void>::value’
/usr/include/nlohmann/json.hpp:1299:55:   required by substitution of ‘template::value) && nlohmann::detail::is_compatible_type, U>::value), int>::type  > 
nlohmann::basic_json<>::basic_json(CompatibleType&&) [with CompatibleType = ptree; U = ptree; typename std::enable_if<((! 
nlohmann::detail::is_basic_json::value) && nlohmann::detail::is_compatible_type, U>::value), int>::type  = 
]’
/usr/include/c++/9/type_traits:883:12:   required from ‘struct 
std::is_constructible, ptree>’
/usr/include/nlohmann/detail/conversions/to_json.hpp:305:123:   required by substitution of ‘template::value && std::is_constructible::value), int>::type 
 > void nlohmann::detail::to_json(BasicJsonType&, const std::pair<_Tp1, _Tp2>&) [with BasicJsonType = nlohmann::basic_json<>; T1 = 
std::__cxx11::basic_string; T2 = ptree; typename std::enable_if<(std::is_constructible::value && 
std::is_constructible::value), int>::type  = ]’
/usr/include/nlohmann/detail/conversions/to_json.hpp:335:24:   [ skipping 12 
instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ]
/usr/include/nlohmann/adl_serializer.hpp:43:36:   required by substitution of ‘template static decltype ((nlohmann::{anonymous}::to_json(j, forward(val)), void())) 
nlohmann::adl_serializer::to_json(BasicJsonType&, 
ValueType&&) [with BasicJsonType = nlohmann::basic_json<>; ValueType = ptree]’
/usr/include/nlohmann/detail/meta/detected.hpp:52:7:   recursively required by substitution of ‘template class Op, class ... Args> struct nlohmann::detail::detector 
>::type, Op, Args ...> [with Default = nlohmann::detail::nonesuch; Op = nlohmann::detail::to_json_function; Args = 
{nlohmann::adl_serializer, nlohmann::basic_json, std::allocator >, bool, long int, long unsigned int, double, std::allocator, 
nlohmann::adl_serializer>&, ptree}]’
/usr/include/nlohmann/detail/meta/detected.hpp:52:7:   required by substitution of ‘template class 
Op, class ... Args> using is_detected_exact = std::is_same::type> [with Expected = void; Op = nlohmann::detail::to_json_function; Args = 
{nlohmann::basic_json<>::json_serializer, nlohmann::basic_json, std::allocator >, bool, long int, long unsigned int, double, 
std::allocator, nlohmann::adl_serializer>&, ptree}]’
/usr/include/nlohmann/detail/meta/type_traits.hpp:121:27:   required from ‘constexpr const 
bool nlohmann::detail::has_to_json, ptree, void>::value’
/usr/include/nlohmann/detail/meta/type_traits.hpp:353:27:   required from ‘constexpr const 
bool 

Bug#949955: RM: aboot -- RoQA; Multiple RC bugs, can no longer be built due to missing alpha buildds

[John Paul Adrian Glaubitz]

On 2/24/20 9:37 PM, Moritz Mühlenhoff wrote:
> On Sun, Feb 02, 2020 at 02:06:12PM +0100, John Paul Adrian Glaubitz wrote:
>> Hello!
>>
>> On 1/29/20 11:49 PM, John Paul Adrian Glaubitz wrote:
>>> One of the Gentoo developers has forked aboot and is maintaing it on
>>> Github [1]. I have filed an issue regarding the manpage issue and will
>>> coordinate a new release of the bootloader with the aforementioned
>>> issues addressed.
>>
>> I have created a pull request now upstream [1] to fix this issue.
>>
>> Also, I would like to take over the aboot package and plan to modernize
>> it the same way as the palo package which is the bootloader for hppa.
> 
> I'm not part of the original maintainers, but given that the last
> active maintainer acked the removal, please by all means adopt it!

Will upload an updated package within the next days.

I had to push some patches upstream first.

Adrian

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

Bug#952467: xtrans: Please package the latest version (1.4.0)

[Boyuan Yang]

Source: xtrans
Version: 1.3.5-1
Severity: normal
X-Debbugs-CC: k...@debian.org

Dear kibi and Debian X team,

Upstream has released xtrans v1.4.0 on 2019-03. Please consider packaging it
in Debian. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#938838: xappy: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:58:55AM +, Matthias Klose wrote:
> Package: src:xappy
> Version: 0.5-5.2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

Hi Jonas,
xappy is dead upstream (last release from 2008) and there are no reverse
deps except a Recommends: by python-moinmoin. Are you planning to port it
to Python 3 yourself or should it rather be removed?

Cheers,
Moritz

Bug#869237: I would have loved to see it in debian as well

[Yaroslav Halchenko]

oh, apparently it survived in ubuntu land:
https://launchpad.net/ubuntu/+source/oprofile/1.3.0-0ubuntu9

On Mon, 24 Feb 2020, Yaroslav Halchenko wrote:

> Just +1 on having this package in Debian ;)
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#935337: RM: pillow -- NVIU; duplicated source packages in unstable

[Moritz Mühlenhoff]

tags 935337 -moreinfo
thanks

On Sat, Jan 04, 2020 at 01:44:22PM +0200, Juhani Numminen wrote:
> Control: block -1 by 866455
> Control: block -1 by 866429
> Control: block -1 by 948062
> 
> Hi,
> 
> Those listed above should be the blocking bugs.

All blockers have been removed or fixed.

Cheers,
Moritz

Bug#952466: RM: circus -- RoQA; unmaintained, depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove circus, it's unmaintained and depends on Python 2; there was just 
a single
upload four years ago and no bug was followed up to since.

Cheers,
Moritz

Bug#952465: please set debian-project@lists.d.o as moderated

[Stefano Zacchiroli]

Package: lists.debian.org
Severity: normal

Dear listmasters,
  in light of repeated trolling and abuse targeting individual Debian
contributors distributed via debian-project@lists.d.o, I'd like to ask for that
mailing list to be set to moderated for the time being.

A group of more than 30 Debian project members have volunteered to share the
burden of moderating the list.  Once this bug report is accepted by the BTS,
I'll followup to the listmaster contact address with the list of moderators
email addresses and account names.

Thanks a lot for your work on Debian mailing lists,
(which has certainly being unduly tiresome in recent times,)

Cheers

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

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

Bug#949955: RM: aboot -- RoQA; Multiple RC bugs, can no longer be built due to missing alpha buildds

[Moritz Mühlenhoff]

On Sun, Feb 02, 2020 at 02:06:12PM +0100, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> On 1/29/20 11:49 PM, John Paul Adrian Glaubitz wrote:
> > One of the Gentoo developers has forked aboot and is maintaing it on
> > Github [1]. I have filed an issue regarding the manpage issue and will
> > coordinate a new release of the bootloader with the aforementioned
> > issues addressed.
> 
> I have created a pull request now upstream [1] to fix this issue.
> 
> Also, I would like to take over the aboot package and plan to modernize
> it the same way as the palo package which is the bootloader for hppa.

I'm not part of the original maintainers, but given that the last
active maintainer acked the removal, please by all means adopt it!

Cheers,
Moritz

Bug#935203: tomcat9: systemd configuration fails to allow tomcat to write to it's own directory

[Emmanuel Bourg]

Hi Kit,

Thank you for the report. Does it work better if you install systemd
241-5~bpo9+1 from stretch-backports?

Emmanuel Bourg

Bug#869237: I would have loved to see it in debian as well

[Yaroslav Halchenko]

Just +1 on having this package in Debian ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#952460: colletion-latexbase hyperref.sty depends on collection-latexextra letltxmacro.sty

[Norbert Preining]

Hi Karl,

another of those oberdiek bundle split fallouts ;-)

hyperref.sty unconditionally requires letltxmacro.sty which is now in
collection-latexextra, shouldn't we move that to base, or at least
recommended?

Best

Norbert

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

Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Paul Gevers]

Source: clazy
Version: 1.6-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

With a recent upload of gcc-10 to unstable, the autopkgtest of clazy
failed on arm64 in testing when that autopkgtest was run with the binary
packages of gcc-10 from unstable. I looked into the history of your
autopkgtest and it fails very often.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests. Please either fix the test to be more robust, or or use the
"flaky" restriction for the offending test until a solution has been found.

I copied the output at the bottom of this report. All the failing tests
that I inspected look like it, albeit the test that fails differs
between runs.

I'll have the migration software ignore the results of your autopkgtest
on arm64 until this bug is fixed.

Paul

https://ci.debian.net/data/autopkgtest/testing/arm64/c/clazy/4369731/log.gz

Qt version: 51205
Qt headers: /usr/include/aarch64-linux-gnu/qt5
clang -Xclang -load -Xclang ClazyPlugin.so -Xclang -add-plugin -Xclang
clazy  -Wno-unused-value -Qunused-arguments -std=c++14 -isystem
/usr/include/aarch64-linux-gnu/qt5 -fPIC -L /usr/lib/aarch64-linux-gnu
-Xclang -plugin-arg-clazy -Xclang qt4-compat  -c  -Xclang
-plugin-arg-clazy -Xclang old-style-connect clazy/qt4compat2.cpp
Qt version: 51205
Qt headers: /usr/include/aarch64-linux-gnu/qt5
clang -Xclang -load -Xclang ClazyPlugin.so -Xclang -add-plugin -Xclang
clazy  -Wno-unused-value -Qunused-arguments -std=c++14 -isystem
/usr/include/aarch64-linux-gnu/qt5 -fPIC -L /usr/lib/aarch64-linux-gnu
-c  -Xclang -plugin-arg-clazy -Xclang old-style-connect -Xclang
-plugin-arg-clazy -Xclang export-fixes clazy/onlyQt1.cpp
Qt version: 51205
Qt headers: /usr/include/aarch64-linux-gnu/qt5
clang -Xclang -load -Xclang ClazyPlugin.so -Xclang -add-plugin -Xclang
clazy  -Wno-unused-value -Qunused-arguments -std=c++14 -isystem
/usr/include/aarch64-linux-gnu/qt5 -fPIC -L /usr/lib/aarch64-linux-gnu
-Xclang -plugin-arg-clazy -Xclang only-qt  -c  -Xclang -plugin-arg-clazy
-Xclang old-style-connect clazy/onlyQt2.cpp
Qt version: 51205
Qt headers: /usr/include/aarch64-linux-gnu/qt5
clang -Xclang -load -Xclang ClazyPlugin.so -Xclang -add-plugin -Xclang
clazy  -Wno-unused-value -Qunused-arguments -std=c++14 -isystem
/usr/include/aarch64-linux-gnu/qt5 -fPIC -L /usr/lib/aarch64-linux-gnu
-c -Wno-deprecated-declarations -Xclang -plugin-arg-clazy -Xclang
raw-environment-function raw-environment-function/main.cpp
Qt version: 51205
Qt headers: /usr/include/aarch64-linux-gnu/qt5
clang -Xclang -load -Xclang ClazyPlugin.so -Xclang -add-plugin -Xclang
clazy  -Wno-unused-value -Qunused-arguments -std=c++14 -isystem
/usr/include/aarch64-linux-gnu/qt5 -fPIC -L /usr/lib/aarch64-linux-gnu
-c  -Xclang -plugin-arg-clazy -Xclang inefficient-qlist
inefficient-qlist/main.cpp
Qt version: 51205
Qt headers: /usr/include/aarch64-linux-gnu/qt5
clang -Xclang -load -Xclang ClazyPlugin.so -Xclang -add-plugin -Xclang
clazy  -Wno-unused-value -Qunused-arguments -std=c++14 -isystem
/usr/include/aarch64-linux-gnu/qt5 -fPIC -L /usr/lib/aarch64-linux-gnu
-c  -Xclang -plugin-arg-clazy -Xclang qenums qenums/main.cpp
Running: clang -Xclang -load -Xclang ClazyPlugin.so -Xclang -add-plugin
-Xclang clazy  -Wno-unused-value -Qunused-arguments -std=c++14 -isystem
/usr/include/aarch64-linux-gnu/qt5 -fPIC -L /usr/lib/aarch64-linux-gnu
-c  -Xclang -plugin-arg-clazy -Xclang rule-of-three
rule-of-three/bug403193.cpp
output_file=rule-of-three/bug403193.cpp.out
[FAIL] rule-of-three (Failed to build test. Check
rule-of-three/bug403193.cpp.out for details)
---
Contents of rule-of-three/bug403193.cpp.out:
Stack dump:
0.  Program arguments: /usr/lib/llvm-8/bin/clang -cc1 -triple
aarch64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name
bug403193.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-fuse-init-array -target-cpu generic -target-feature +neon -target-abi
aapcs -fallow-half-arguments-and-returns -dwarf-column-info
-debugger-tuning=gdb -coverage-notes-file
/tmp/autopkgtest-lxc.ji5ue40b/downtmp/build.xGK/src/tests/bug403193.gcno
-resource-dir /usr/lib/llvm-8/lib/clang/8.0.1 -isystem
/usr/include/aarch64-linux-gnu/qt5 -internal-isystem
/usr/bin/../lib/gcc/aarch64-linux-gnu/8/../../../../include/c++/8
-internal-isystem
/usr/bin/../lib/gcc/aarch64-linux-gnu/8/../../../../include/aarch64-linux-gnu/c++/8
-internal-isystem
/usr/bin/../lib/gcc/aarch64-linux-gnu/8/../../../../include/aarch64-linux-gnu/c++/8
-internal-isystem
/usr/bin/../lib/gcc/aarch64-linux-gnu/8/../../../../include/c++/8/backward

Bug#952460: texlive-latex-base hyperref.sty depends on texlive-latex-extra letltxmacro.sty

[Norbert Preining]

Hi Agustin,

> $ grep letltxmacro 
> /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
> \RequirePackage{letltxmacro}[2008/06/13]

Ummm.

> texlive-latex-base should probably not depend on styles in
> texlive-latex-extra.
> 
> Am I missing something?

No.

In 2019-12 the former "oberdiek" bundle, which contained about a hundred
different packages, was split into separate ones, and put into
collections, but obviously some of those are misplaced.

I will discuss with Karl Berry what we do, this is obviously not optimal
a solution.

For now I guess you need to fix your build deps, but this will become
(hopefully) unnecessary with the next upload of TeX Live.

Thanks for the clear and detailed report

Norbert

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

Bug#952463: bagel: flaky arm64 autopkgtest: terminate called without an active exception

[Paul Gevers]

Source: bagel
Version: 1.2.2-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

With a recent upload of gcc-10 to unstable, the autopkgtest of bagel
failed on arm64 in testing when that autopkgtest was run with the binary
packages of gcc-10 from unstable. I looked into the history of your
autopkgtest and it fails very often.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests. Please either fix the test to be more robust, or or use the
"flaky" restriction for the offending test until a solution has been found.

I copied the output at the bottom of this report. All the failing tests
that I inspected look like it, albeit the test that fails differs
between runs.

I'll have the migration software ignore the results of your autopkgtest
on arm64 until this bug is fixed.

Paul

https://ci.debian.net/data/autopkgtest/testing/arm64/b/bagel/4258642/log.gz

running test case 'hf_sto3g_relfci_gaunt'... terminate called without an
active exception
/tmp/autopkgtest-lxc.q3t4znog/downtmp/build.F1y/src/debian/tests/testsuite.sh:
line 85: 15487 Aborted BAGEL test/${testname}.json >
${testname}.out
/tmp/autopkgtest-lxc.q3t4znog/downtmp/build.F1y/src/debian/tests/testsuite.sh:
fork: retry: Resource temporarily unavailable
FAILED.



signature.asc
Description: OpenPGP digital signature

Bug#952462: golang-go.crypto: CVE-2020-9283

[Salvatore Bonaccorso]

Source: golang-go.crypto
Version: 1:0.0~git20190701.4def268-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for golang-go.crypto.

CVE-2020-9283[0]:
| golang.org/x/crypto before v0.0.0-20200220183623-bac4c82f6975 for Go
| allows a panic during signature verification in the
| golang.org/x/crypto/ssh package. A client can attack an SSH server
| that accepts public keys. Also, a server can attack any SSH client.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-9283
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9283
[1] 
https://github.com/golang/crypto/commit/bac4c82f69751a6dd76e702d54b3ceb88adab236

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#949248: nftables: nft parsing from stdin fails but works from file

[jaroslav]

Package: nftables
Version: 0.9.0-2
Severity: normal

I want to parse rules from a script but parsing them from a pipe files 
while parsing from file works


nft -f nft.txt works
cat nft.txt | nft -f - fails with a handful of syntax errors

I also noticed a difference when doing full debug output
Reading Cfrom file shows the filename, the line number and the postion 
as well as the actual line and the used part of line
Reading from stdin just shows /dev/stdin, the line number and the 
position.

So there seams to be different handling oft reading the input



I encountered this too some time ago - according to strace, nft is 
reading rules in 8kB long blocks (so everything works fine until your 
rules grow) but after the block is read, nft attempts to seek few bytes 
back in the file. I guess it wants to do the next read from some kind of 
boundary. Anyway, seeking in stream obviously fails with ESPIPE - 
Illegal seek (I guess nft doesn't check return value here), another 8kB 
block is read but not from the file position nft wanted, resulting in 
syntax error.


Nft man page says that reading from stdin is supported, but it also says 
that "nft export json" is a thing, so I just written this off as yet 
another error in the docs and worked around it by dumping my rules into 
a temporary file a reading them via -f . You may want to do the same 
thing.

Bug#952173: golang-gopkg-gorethink-gorethink.v3: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 returned exit code 1

[Anthony Fok]

Hi again!

On Mon, Feb 24, 2020 at 10:47 AM Shengjing Zhu  wrote:
>
> On Tue, Feb 25, 2020 at 1:35 AM Anthony Fok  wrote:
> >
> > Hi Shengjing,
> >
> > Thanks for looking into this too.  I'm sorry for not recording my findings 
> > here before going to bed, causing duplication of work...
> >
>
> Nevermind, I have learned some (surprising) Perl knowledge...

Sorry, I forgot to subscribe to this bug report, and didn't realize
that you had already fixed the bug until I revisited the bug web page
and checked Salsa.  I apologize for my oversight!  You and 依云
@lilydjwg deserve the credit to have created and submitted such a
beautiful and concise fix.  Thus, I have merged your closed merge
request by doing a manual

git merge --ff-only b4acd2b

and added my own fix after.

Thanks again for all your awesome work!

Cheers,
Anthony

Bug#952126: emacs-bind-map: FTBFS caused by elpa-undo-tree 0.7.1

[Nicholas D Steeves]

Hi Lev and David,

Lev Lamberov  writes:

> Hmmm, looks like the bug is caused by undo-tree, since when
> elpa-undo-tree 0.6.4-3 is installed tests are passed correctly.
> Moreover, when new upstream version of undo-tree is used (0.7.4, not
> currently in Debian) tests also are passed correctly.

Lev, thank you for working to find, and finding the cause!  Sorry, I
share the blame for this regression because I sponsored the upload of
0.7.1.  How urgently would you like a fix?  I'd like to give David some
time to prepare the new undo-tree release, but can prepare it myself if
too much time passes.  BTW, are undo-trees tests flaky or could you
enable autopkgtests for it at this time?

David, this a type of bug that autopkgtests are useful to help detect
(eg: regressions that involve multiple packages).  I'd like to try
enabling them at this time, so please either include a commit that
enables them, or remind me to do so--whichever you prefer!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#950896: screen: out of bounds access when setting w_xtermosc after OSC 49

[Salvatore Bonaccorso]

Control: retitle -1 screen: CVE-2020-9366: out of bounds access when setting 
w_xtermosc after OSC 49

Hi

On Fri, Feb 07, 2020 at 10:28:55PM +0100, Salvatore Bonaccorso wrote:
> Source: screen
> Version: 4.7.0-1
> Severity: important
> Tags: security upstream fixed-upstream
> 
> Hi
> 
> There is a new upstream release 4.8.0 which fixes as well an out of
> bounds access issue:
> 
> https://www.openwall.com/lists/oss-security/2020/02/06/3

This in meanwhile has been assigned CVE-2020-9366.

Regards,
Salvatore

Bug#952360: [xml/sgml-pkgs] Bug#952360: linuxdoc-tools: FTBFS: fmt_latex2e::postASP: LaTeX first run problem. Aborting ...

[Agustin Martin]

Control: affects 952460 -1
Control: tags -1 +pending

On Sun, Feb 23, 2020 at 02:47:12PM +0100, Lucas Nussbaum wrote:
> Source: linuxdoc-tools
> Version: 0.9.73-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > make[2]: Entering directory '/<>/doc'
> > - Building txt docs
> > /tmp/ldt.p976T7wYPZ/linuxdoc --backend=txt --filter --blanks=1 guide.sgml
> > Processing file guide.sgml
> > troff: :2261: warning [p 1, 226.0i]: can't break line
> > - Building pdf docs
> > /tmp/ldt.p976T7wYPZ/linuxdoc --backend=latex \
> > --output=pdf \
> > --pass="\usepackage{times}" guide.sgml
> > Processing file guide.sgml
> > fmt_latex2e::postASP: LaTeX first run problem. Aborting ...
> > make[2]: *** [Makefile:9: guide.pdf] Error 1

Hi, Lucas,

Thanks for pointing out this problem.

This is caused by a rearrangement in contents of texlive packages. This
results in missing "letltxmacro.sty", which triggers the error. Missing
style now lives in "texlive-latex-extra", but is required by "hyperref.sty",
a style in "texlive-latex-base" which should not, IMHO, require styles
outside "texlive-latex-base".

I have filed #952460 against texlive-latex-base to make this known to
texlive maintainers. Depending on their reply this will be fixed either in
texlive with a new relocation or in linuxdoc-tools (by means of an additional
Build-Depends on texlive-latex-extra, now has only texlive-latex-recommended).

In the meantime I am marking this bug as pending.

Regards,

-- 
Agustin

Bug#952461: coccinelle: build-depend on python instead of python2

[Gianfranco Costamagna]

Source: coccinelle
Version: 1.0.4.deb-5
Severity: serious
tags: patch

Hello, your package depends on python instead of python2. Please update the 
dependency accordingly.
(or port to python3 if possible)

trivial patch:

diff -Nru coccinelle-1.0.4.deb/debian/changelog 
coccinelle-1.0.4.deb/debian/changelog
--- coccinelle-1.0.4.deb/debian/changelog   2020-02-16 16:13:10.0 
+
+++ coccinelle-1.0.4.deb/debian/changelog   2020-02-24 18:44:58.0 
+
@@ -1,3 +1,9 @@
+coccinelle (1.0.4.deb-5.1) unstable; urgency=medium
+
+  * Depend on python2 (Closes: #-1)
+
+ -- Gianfranco Costamagna   Mon, 24 Feb 2020 
19:44:58 +0100
+
 coccinelle (1.0.4.deb-5) unstable; urgency=medium
 
   * Team upload
diff -Nru coccinelle-1.0.4.deb/debian/control 
coccinelle-1.0.4.deb/debian/control
--- coccinelle-1.0.4.deb/debian/control 2020-02-16 16:13:10.0 +
+++ coccinelle-1.0.4.deb/debian/control 2020-02-24 18:43:36.0 +
@@ -8,7 +8,7 @@
  dh-ocaml (>= 1.0.3~),
  ocaml-nox (>= 3.11.1-3~),
  libpycaml-ocaml-dev (>= 0.82-13~),
- python (>= 2.6.6-3~),
+ python2 (>= 2.6.6-3~),
  menhir (>= 20090204.dfsg),
  libmenhir-ocaml-dev (>= 20090204.dfsg),
  ocaml-findlib,

Bug#755434: Echoing desire for exfat support

[Jennifer Morrow]

I also would prefer to stay on the maintained branch and have support for 
exFAT.  Is there any way to see when the patch might get merged?  It doesn’t 
look like support has been added since October 2019.

On Mon, 7 Oct 2019 16:47:49 + "Inman, Dana"  
wrote:
> Currently using pmount 0.9.23 and wishing this little patch was forthcoming 
> in a new release.
> 
> Sure, can apply the patch and build from source, but... would prefer to stay 
> on the maintained branch.
> 
> 
> [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is 
> proprietary to Medtronic and is intended for use only by the individual or 
> entity to which it is addressed, and may contain information that is private, 
> privileged, confidential or exempt from disclosure under applicable law. If 
> you are not the intended recipient or it appears that this mail has been 
> forwarded to you without proper authority, you are notified that any use or 
> dissemination of this information in any manner is strictly prohibited. In 
> such cases, please delete this mail from your records. To view this notice in 
> other languages you can either select the following link or manually copy and 
> paste the link into the address bar of a web browser: 
> http://emaildisclaimer.medtronic.com

Bug#952460: texlive-latex-base hyperref.sty depends on texlive-latex-extra letltxmacro.sty

[Agustin Martin]

Package: texlive-latex-base
Version: 2019.20200218-1
Severity: normal

Dear Maintainer,

I have been hit by a FTBFS in linuxdoc-tools (#952360) and when debugging it
I noticed that it was caused by missing letltxmacro.sty, required by
hyperref.sty, included in texlive-latex-base.

$ dpkg -S hyperref.sty letltxmacro.sty
...
texlive-latex-base: 
/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
texlive-latex-extra: 
/usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty

$ grep letltxmacro /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
\RequirePackage{letltxmacro}[2008/06/13]

linuxdoc-tools build depends only on texlive-latex-recommended and this
worked previously, but now causes a build failure. I can add a Build-Depends
on texlive-latex-extra, but I do not think it should be needed, as styles in
texlive-latex-base should probably not depend on styles in
texlive-latex-extra.

Am I missing something?

Thanks in advance, and thanks also for maintaining texlive.

Regards,

-- 
Agustin

Bug#952453: arbitrary command execution vulnerability

[Ryan Kavanagh]

Control: found -1 5.7.3p2-1

This affects Debian versions since 5.7.3p2 (released upstream
2016-02-02). Quoting from the advisory:

This vulnerability, an out-of-bounds read introduced in December
2015 (commit 80c6a60c, "when peer outputs a multi-line response
..."), is exploitable remotely and leads to the execution of
arbitrary shell commands: either as root, after May 2018 (commit
a8e22235, "switch smtpd to new grammar"); or as any non-root user,
before May 2018.

https://www.openwall.com/lists/oss-security/2020/02/24/5

The other advisory fixed by the patches does not appear to affect
Debian because /proc/sys/fs/protected_hardlinks is 1 by default:

https://www.openwall.com/lists/oss-security/2020/02/24/4

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#952283: Bug#951874: debian-security-support: Miscellaneous sh fixes

[Holger Levsen]

control: tags 952283 -pending
control: tags 952383 +pending
thanks

On Mon, Feb 24, 2020 at 05:21:22PM +, Daniel Shahaf wrote:
> Correction: #952383.
 
oh! sorry for the noise, Pirate!

Daniel, 952383 is fixed in git with the following changelog entry:

  * check-support-status.in:
- Don't exit gracefully if the detected Debian version is not supported,
  instead issue a warning and continue, to both do the checks that can be
  done and to not fail the package installation. Closes: #952383.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


signature.asc
Description: PGP signature

Bug#952458: elpa-undo-tree: please, update undo-tree to the latest upstream version

[David Krauser]

Hi Lev,

Thanks for reporting this!

On Monday, February 24, 2020 5:49 PM, Lev Lamberov  wrote:
> please, update undo-tree to the latest upstream version (currently,
> 0.7.4).

Unfortunately, upstream hasn't tagged an official release in the upstream git 
repository for 0.7.4, although that version _has_ been uploaded to elpa.

I sent a note to upstream last week asking if more changes are expected before 
an official tag is made. I'll poke them again. If I don't hear back soon, I'll 
look into pulling in the version that's listed in elpa.

Thanks again,

David Krauser