Bug#933701: mandos FTCBFS: hard codes build architecture pkg-config

[Helmut Grohne]

Source: mandos
Version: 1.8.5-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mandos fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. The attached patch makes
it substitutable so mandos becomes cross buildable. Please consider
applying it.

Helmut
--- mandos-1.8.5.orig/Makefile
+++ mandos-1.8.5/Makefile
@@ -44,6 +44,7 @@
 htmldir:=man
 version:=1.8.5
 SED:=sed
+PKG_CONFIG?=pkg-config
 
 USER:=$(firstword $(subst :, ,$(shell getent passwd _mandos \
 	|| getent passwd nobody || echo 65534)))
@@ -80,20 +81,20 @@
 	done)
 ##
 
-SYSTEMD:=$(DESTDIR)$(shell pkg-config systemd --variable=systemdsystemunitdir)
-TMPFILES:=$(DESTDIR)$(shell pkg-config systemd --variable=tmpfilesdir)
+SYSTEMD:=$(DESTDIR)$(shell $(PKG_CONFIG) systemd --variable=systemdsystemunitdir)
+TMPFILES:=$(DESTDIR)$(shell $(PKG_CONFIG) systemd --variable=tmpfilesdir)
 
-GNUTLS_CFLAGS:=$(shell pkg-config --cflags-only-I gnutls)
-GNUTLS_LIBS:=$(shell pkg-config --libs gnutls)
-AVAHI_CFLAGS:=$(shell pkg-config --cflags-only-I avahi-core)
-AVAHI_LIBS:=$(shell pkg-config --libs avahi-core)
+GNUTLS_CFLAGS:=$(shell $(PKG_CONFIG) --cflags-only-I gnutls)
+GNUTLS_LIBS:=$(shell $(PKG_CONFIG) --libs gnutls)
+AVAHI_CFLAGS:=$(shell $(PKG_CONFIG) --cflags-only-I avahi-core)
+AVAHI_LIBS:=$(shell $(PKG_CONFIG) --libs avahi-core)
 GPGME_CFLAGS:=$(shell gpgme-config --cflags; getconf LFS_CFLAGS)
 GPGME_LIBS:=$(shell gpgme-config --libs; getconf LFS_LIBS; \
 	getconf LFS_LDFLAGS)
-LIBNL3_CFLAGS:=$(shell pkg-config --cflags-only-I libnl-route-3.0)
-LIBNL3_LIBS:=$(shell pkg-config --libs libnl-route-3.0)
-GLIB_CFLAGS:=$(shell pkg-config --cflags glib-2.0)
-GLIB_LIBS:=$(shell pkg-config --libs glib-2.0)
+LIBNL3_CFLAGS:=$(shell $(PKG_CONFIG) --cflags-only-I libnl-route-3.0)
+LIBNL3_LIBS:=$(shell $(PKG_CONFIG) --libs libnl-route-3.0)
+GLIB_CFLAGS:=$(shell $(PKG_CONFIG) --cflags glib-2.0)
+GLIB_LIBS:=$(shell $(PKG_CONFIG) --libs glib-2.0)
 
 # Do not change these two
 CFLAGS+=$(WARN) $(DEBUG) $(FORTIFY) $(COVERAGE) \

Bug#933700: debootstrap fails and the log gets deleted

[Marc Haber]

Package: mini-buildd
Version: 1.0.41
Severity: important

Hi,

I had to rebuild my mini-buildd builder on armhf, a Banana Pi. After installing
mini-buildd and installing sources and gnupg keys, I proceeded to build
the file chroots, which fails:

Aug  2 06:52:01 banana [CP Server Thread-6 ] WARNING : # 
/usr/sbin/debootstrap.. (stdout): W: Failure trying to run: chroot 
"/var/lib/mini-buildd/var/chroots/stretch/amd64/tmp" /bin/true 
[mini_buildd.call:116]
Aug  2 06:52:01 banana [CP Server Thread-6 ] WARNING : # 
/usr/sbin/debootstrap.. (stdout): W: See 
/var/lib/mini-buildd/var/chroots/stretch/amd64/tmp/debootstrap/debootstrap.log 
for details [mini_buildd.call:116]
Aug  2 06:52:01 banana [CP Server Thread-6 ] ERROR   : Sequence failed at: 1 
(rolling back) [mini_buildd.call:153]
Aug  2 06:52:01 banana [CP Server Thread-6 ] INFO: Called with retval 64: 
sudo -n /bin/umount -v /var/lib/mini-buildd/var/chroots/stretch/amd64/tmp/proc 
/var/lib/mini-buildd/var/chroots/stretch/amd64/tmp/sys  [mini_buildd.call:72]
Aug  2 06:52:01 banana [CP Server Thread-6 ] WARNING : # /bin/umount.. 
(stderr): umount: /var/lib/mini-buildd/var/chroots/stretch/amd64/tmp/proc: not 
mounted. [mini_buildd.call:116]
Aug  2 06:52:01 banana [CP Server Thread-6 ] WARNING : # /bin/umount.. 
(stderr): umount: /var/lib/mini-buildd/var/chroots/stretch/amd64/tmp/sys: not 
mounted. [mini_buildd.call:116]
Aug  2 06:52:03 banana [CP Server Thread-6 ] INFO: Called with retval 0: 
sudo -n /bin/rm --recursive --one-file-system --force 
/var/lib/mini-buildd/var/chroots/stretch/amd64/tmp  [mini_buildd.call:72]
Aug  2 06:52:03 banana [CP Server Thread-6 ] ERROR   : prepare failed: Debian 
'stretch:amd64' (tar): Call failed with retval 1: 'sudo -n 
/usr/sbin/debootstrap --variant buildd --keyring 
/var/lib/mini-buildd/var/chroots/stretch/amd64/keyring.gpg --arch amd64 stretch 
/var/lib/mini-buildd/var/chroots/stretch/amd64/tmp 
http://debian.debian.zugschlus.de/debian/ ' [base:368] 
[mini_buildd.models.base:78]

I would be able to debug this if the log mentioned by debootstrap was
here. It is not, it gets deleted by mini-buildd after the failure.

Too bad, so I need upstream's help again.

Greetings
Marc

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

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

Versions of packages mini-buildd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.72
ii  debootstrap1.0.115
ii  devscripts 2.19.6
ii  dirmngr2.2.17-3
ii  dpkg-dev   1.19.7
ii  gnupg  2.2.17-3
ii  libjs-jquery   3.3.1~dfsg-3
ii  libjs-sphinxdoc1.8.5-2
ii  lintian2.16.0
ii  lsb-base   10.2019051400
ii  mini-buildd-common 1.0.41
ii  python 2.7.16-1
ii  python-cherrypy3   8.9.1-2
ii  python-daemon  2.2.3-1
ii  python-mini-buildd 1.0.41
ii  python-pyftpdlib   1.5.4-1
ii  reprepro   5.3.0-1
ii  sbuild 0.78.1-2
ii  schroot1.6.10-6+b1
ii  sudo   1.8.27-1

Versions of packages mini-buildd recommends:
ii  python-apt  1.8.4

Versions of packages mini-buildd suggests:
pn  binfmt-support  
pn  btrfs-progs 
ii  debian-archive-keyring  2019.1
ii  haveged 1.9.1-8
ii  lvm22.03.02-3
pn  qemu-user-static
pn  ubuntu-keyring  

-- Configuration Files:
/etc/default/mini-buildd changed:
MINI_BUILDD_OPTIONS='--verbose -W :::8066'

/etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied: 
'/etc/sudoers.d/mini-buildd-sudoers'

-- debconf information:
  mini-buildd/purge_warning:
* mini-buildd/home: /var/lib/mini-buildd
* mini-buildd/options: --verbose --httpd-bind=:::8066
* mini-buildd/note:

Bug#932245: Build system updated

[Norbert Schlia]

After a few attempts I upgraded the build system to the latest Debian 10 
and now I got rid of all errors and many warnings. There are still a few 
glitches, but I don't think they are too important. There's a newer 
version of ffmpegfs, but I don't want to switch to it yet to avoid newer 
bugs. Also I'll have to figure out how to get the gpg signature check up.


Anyone out there willing to sponsor me? If you love music and have it 
available as video and audio files on disk you gotta try it out. It's a 
nice and convenient tool to get the stuff avialable anywhere, on your 
mobile phone, iPad or whatever. It bundles the full power of FFmpeg to 
do so. I am using it myself to provide my files to my Android phone.

Bug#933592: [Pkg-javascript-devel] Bug#933592: Webpack 4 transition: node-node-forge fail to build with webpack 4

[Pirate Praveen]

On Thu, 01 Aug 2019 18:45:17 -0300 Jonas Smedegaard  wrote:
> Thanks.  That was exactly the kind of details I was missing.

node-node-forge is fixed in webpack4 branch.

https://salsa.debian.org/js-team/node-node-forge/commit/d3196547e0e4afa13d961a09d70d1ccc4dc5a1c7
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores

[Phillip Lougher]

On Thu, Aug 1, 2019 at 11:41 PM László Böszörményi (GCS)  
wrote:

>  Let me add Chris Lamb then the previous Debian Project Leader (also
> British just like you [as I know] and you may sit down and talk about
> this in person) who asked for the reproducibility patch / build in the
> first place.
>

If Chris Lamb or anyone else wants a face-to-face meeting I'm more
than happy to do so.

I coincidentally have a week's holiday (vacation) next week, and I'm
happy to spend a day of it travelling and meeting to discuss the
situation.

I do want to de-escalate this situation if possible.

Phillip

> > What else do I have to do to make you stop bad-mouthing Squashfs?  Sue?
>  If you feel yourself better with that, be my guest. I don't know who
> is the lawyer of Debian, but I'm sure s/he can show you that it's only
> you who dance this storm.
>
> Regards,
> Laszlo/GCS
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919207#5
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919207#83
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919207#88
> [4] 
> https://sourceforge.net/p/squashfs/code/ci/e38956b92f738518c29734399629e7cdb33072d3/log/?path=
> [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921146#75
> [6] https://github.com/AgentD/squashfs-tools-ng
> [7] https://lwn.net/Articles/651775/
> [8] 
> https://github.com/plougher/squashfs-tools/commit/f95864afe8833fe3ad782d714b41378e860977b1
> [9] 
> https://github.com/plougher/squashfs-tools/commit/ba215d73e153a6f237088b4ecb88c702bb4d4183

Bug#933697: libuuid1 declared to replace e2fsprogs

[Ralph Ronnquist]

Well,

when I then "agt-get install libuuid1:i386" (on this multiarch)
I get advice about a page full of packages to be removed, and the
following (plus a bit more):
---
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  e2fsprogs libblkid1 (due to e2fsprogs) libuuid1 (due to e2fsprogs) fdisk
  libfdisk1 (due to fdisk) libmount1 (due to fdisk) init
  sysvinit-core (due to init) mount util-linux (due to mount) sysvinit-utils


Then, as I go ahead and install anyhow, I end up with a rather broken
installation :(

So "harmless" is probably not the right word.

Ralph.

Theodore Y. Ts'o wrote on 2/8/19 1:41 pm:
> On Fri, Aug 02, 2019 at 11:25:10AM +1000, Ralph Ronnquist wrote:
>> Package: libuuid1
>> Version: 2.34-0.1
>>
>> The package is declared to replace e2fsprogs, which it doesn't do.
>> Rather, installing it has a fair few ramifications on the installed system.
>>
>> The package belongs to the util-linux source, and it seems to be the
>> same issue with uuid-runtime and uuid-dev.
> 
> The replaces line in question is:
> 
> Replaces: e2fsprogs (<< 1.34-1)
> 
> This was because libuuid1 used to shipped as part of e2fsprogs, and it
> was split out in 1.34-1:
> 
> e2fsprogs (1.34-1) unstable; urgency=low
> 
>   * Split shared libraries out of the e2fsprogs package into separate
> packages: libss2, libcomerr2, libuuid1, and e2fslibs.  (Closes: #201155,
> #201164)
> 
> This happened in 2003, so this split landed in Debian 3.1 (Sarge).
> Later on, the uuid and blkid libraries got moved to util-linux, and
> the Replaces line carried over.
> 
> Given that Debian 10 (Buster) is now stable, that Replaces line is
> O-B-S-O-L-E-T-E.   That being said, it's harmless.
> 
> Cheers,
> 
>   - Ted
> 

Bug#933697: libuuid1 declared to replace e2fsprogs

[Theodore Y. Ts'o]

On Fri, Aug 02, 2019 at 11:25:10AM +1000, Ralph Ronnquist wrote:
> Package: libuuid1
> Version: 2.34-0.1
> 
> The package is declared to replace e2fsprogs, which it doesn't do.
> Rather, installing it has a fair few ramifications on the installed system.
> 
> The package belongs to the util-linux source, and it seems to be the
> same issue with uuid-runtime and uuid-dev.

The replaces line in question is:

Replaces: e2fsprogs (<< 1.34-1)

This was because libuuid1 used to shipped as part of e2fsprogs, and it
was split out in 1.34-1:

e2fsprogs (1.34-1) unstable; urgency=low

  * Split shared libraries out of the e2fsprogs package into separate
packages: libss2, libcomerr2, libuuid1, and e2fslibs.  (Closes: #201155,
#201164)

This happened in 2003, so this split landed in Debian 3.1 (Sarge).
Later on, the uuid and blkid libraries got moved to util-linux, and
the Replaces line carried over.

Given that Debian 10 (Buster) is now stable, that Replaces line is
O-B-S-O-L-E-T-E.   That being said, it's harmless.

Cheers,

- Ted

Bug#933699: RM: python-clamav -- ROM; Obsolete libs - python2 only, dead upstream

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

This one died upstream a long time ago.

Scott K

Bug#933698: network-manager-gnome: nm-applet fails to detect NetworkManager, possible race condition?

[James Tocknell]

Package: network-manager-gnome
Version: 1.8.22-2
Severity: important

It appears that sometimes nm-applet doesn't find the NetworkManager daemon (or
dbus interface or something), and states "NetworkManager not running". Given I
can see that NetworkManager is running (via nmcli), and I'm connected to the
network, and that if I kill nm-applet and start it up again and it find
NetworkManager running, I'm guessing there's some sort of race condition between
when nm-applet checks for NetworkManager availability and NetworkManager
actually running (or starting the dbus interface or which ever). This is a new
problem (1.8.20 didn't have this problem or at least I never triggered it), I'm
not confident enough yet to call it a regression. Would it be possible to get
nm-applet to poll for NetworkManager's existence if it appear to be not running?

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
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_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_AU.UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager-gnome depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.16-1
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libatk1.0-0  2.32.0-2
ii  libayatana-appindicator3-1   0.5.3-4
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.6-1
ii  libgtk-3-0   3.24.10-1
ii  libjansson4  2.12-1
ii  libmm-glib0  1.10.0-1
ii  libnm0   1.19.90-2
ii  libnma0  1.8.22-2
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libsecret-1-00.18.7-1
ii  libselinux1  2.9-2
ii  network-manager  1.19.90-2
ii  policykit-1-gnome [polkit-1-auth-agent]  0.105-7

Versions of packages network-manager-gnome recommends:
ii  awesome [notification-daemon]   4.3-4
ii  dunst [notification-daemon] 1.4.1-1
ii  gnome-keyring   3.28.2-5
ii  iso-codes   4.3-1
ii  mobile-broadband-provider-info  20170903-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#933697: libuuid1 declared to replace e2fsprogs

[Ralph Ronnquist]

Package: libuuid1
Version: 2.34-0.1

The package is declared to replace e2fsprogs, which it doesn't do.
Rather, installing it has a fair few ramifications on the installed system.

The package belongs to the util-linux source, and it seems to be the
same issue with uuid-runtime and uuid-dev.

Ralph.

Bug#933696: RM: p4est [armel armhf i386 mips mips64el mipsel hppa hurd-i386 ia64 kfreebsd-i386 powerpc sparc64 x32] -- ROM; binary architecture not supported; testfailures

[tamiko+DEBIAN]

Package: ftp.debian.org
Severity: normal

Ftp master,

Please remove the binary packages for the selected architectures.

Bug#933695: RM: deal.ii [mipsel ppc64el alpha hppa riscv64 sh4 x32] -- ROM; binary architectures not supported, build dependencies unavailable

[tamiko+DEBIAN]

Package: ftp.debian.org
Severity: normal

Ftp masters,

Please remove the above binary packages for deal.ii.

Bug#933693: rust-cargo: FTBFS due to missing/uninstallable build dependencies

[Ximin Luo]

We are blocked on FTP masters accepting rust-bstr and the new build 
dependencies of the new version of cargo.

Please check the debcargo-conf.git repo first, before filing bug reports for 
these types of FTBFS bugs. If there is a new version of the crate that is 
FTBFS, it means we the Rust team already know about it, and the bug report 
simply creates extra work to close it.

X

> Hi,
> 
> rust-cargo fails to rebuild from source (in a clean sbuild environment).
> 
> I ran into this while rebuilding all reverse dependencies of rust-openssl-sys
> prior to uploading an updated version.
> 
> Best,
> 
>   nicoo
> 
> ---
> 
> $ sbuild -d sid rust-cargo
> sbuild (Debian sbuild) 0.78.1 (09 February 2019) on localhost
> 
> +==+
> | rust-cargo (amd64)   Thu, 01 Aug 2019 23:34:16 
> + |
> +==+
> 
> Package: rust-cargo
> Distribution: sid
> Machine Architecture: amd64
> Host Architecture: amd64
> Build Architecture: amd64
> Build Type: full
> 
> [...]
> 
> +--+
> | Update chroot   
>  |
> +--+
> 
> [...]
> 
> +--+
> | Fetch source files  
>  |
> +--+
> 
> 
> Check APT
> -
> 
> Checking available source versions...
> 
> Download source files with APT
> --
> 
> Reading package lists...
> NOTICE: 'rust-cargo' packaging is maintained in the 'Git' version control 
> system at:
> https://salsa.debian.org/rust-team/debcargo-conf.git [src/cargo]
> Please use:
> git clone https://salsa.debian.org/rust-team/debcargo-conf.git [src/cargo]
> to retrieve the latest (possibly unreleased) updates to the package.
> Need to get 943 kB of source archives.
> Get:1 http://localhost:3142/debian sid/main rust-cargo 0.35.0-1 (dsc) [5100 B]
> Get:2 http://localhost:3142/debian sid/main rust-cargo 0.35.0-1 (tar) [934 kB]
> Get:3 http://localhost:3142/debian sid/main rust-cargo 0.35.0-1 (diff) [4304 
> B]
> Fetched 943 kB in 0s (11.2 MB/s)
> Download complete and in download only mode
> I: NOTICE: Log filtering will replace 
> 'build/rust-cargo-oCDNo8/rust-cargo-0.35.0' with '<>'
> I: NOTICE: Log filtering will replace 'build/rust-cargo-oCDNo8' with 
> '<>'
> 
> +--+
> | Install package build dependencies  
>  |
> +--+
> 
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: debhelper (>= 11), dh-cargo (>= 15), cargo, rustc, 
> libstd-rust-dev, librust-atty-0.2+default-dev, 
> librust-byteorder-1+default-dev (>= 1.2-~~), librust-bytesize-1+default-dev, 
> librust-clap-2+default-dev (>= 2.31.2-~~), 
> librust-core-foundation-0.6+default-dev, 
> librust-core-foundation-0.6+mac-os-10-7-support-dev, 
> librust-crates-io-0.23+default-dev, librust-crossbeam-utils-0.6+default-dev, 
> librust-crypto-hash-0.3+default-dev (>= 0.3.1-~~), 
> librust-curl-0.4+default-dev (>= 0.4.19-~~), librust-curl-0.4+http2-dev (>= 
> 0.4.19-~~), librust-curl-sys-0.4+default-dev (>= 0.4.15-~~), 
> librust-env-logger-0.6+default-dev, librust-failure-0.1+default-dev (>= 
> 0.1.5-~~), librust-filetime-0.2+default-dev, librust-flate2-1+default-dev (>= 
> 1.0.3-~~), librust-flate2-1+zlib-dev (>= 1.0.3-~~), 
> librust-fs2-0.4+default-dev, librust-fwdansi-1+default-dev, 
> librust-git2-0.8+default-dev, librust-git2-curl-0.9+default-dev, 
> librust-glob-0.2+default-dev (>= 0.2.11-~~), librust-hex-0.3+default-dev, 
> librust-home-0.3+default-dev, librust-ignore-0.4+default-dev, 
> librust-im-rc-12+default-dev (>= 12.1.0-~~), 
> librust-jobserver-0.1+default-dev (>= 0.1.11-~~), 
> librust-lazy-static-1+default-dev (>= 1.2.0-~~), 
> librust-lazycell-1+default-dev (>= 1.2.0-~~), librust-libc-0.2+default-dev, 
> librust-libgit2-sys-0.7+default-dev (>= 0.7.9-~~), 
> librust-log-0.4+default-dev (>= 0.4.6-~~), librust-miow-0.3+default-dev (>= 
> 0.3.1-~~), librust-num-cpus-1+default-dev, librust-opener-0.3+default-dev, 
> librust-rustc-workspace-hack-1+default-dev, librust-rustfix-0.4+default-dev 
> (>= 0.4.4-~~), librust-same-file-1+default-dev, 
> librust-semver-0.9+default-dev, librust-semver-0.9+serde-dev, 
> librust-serde-1+default-dev (>= 1.0.82-~~), librust-serde-1+derive-dev (>= 
> 1.0.82-~~), librust-serde-ignored-0.0.4+default-dev, 
> librust-serde-json-1+default-dev (>= 1.0.30-~~), 
> librust-serde-json-1+raw-value-dev (>= 1.0.30-~~), 
> 

Bug#931624: python3.8 ftbfs on the Hurd and KFreeBSD

[Samuel Thibault]

Control: forwarded -1 https://bugs.python.org/issue37744

Bug#824712: RFH: smokeping

[Nicholas D Steeves]

Hi Gabriel and Antoine!

When I read the wnpp report today I noticed that this bug is still
open.  Are you looking for more help with smokeping or can this bug be
closed?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores

[Theodore Y. Ts'o]

Phillip,

Peace.

You may not like the fact that David Oberhollenzer (GitHub username
AgentD) started an effort to implement a new set of tools to generate
squashfs images on April 30th, 2019, and called it squashfs-tools-ng.

However, it's really not fair to complain that there is a "violation
of copyright" given that all of squashfs-tools was released is under
the GPL.  Using some text from squashfs-tools in the package
description or documentation of squashfs-tools-ng is totally allowed
under the GPL.  You could complain that they didn't include an
acknowledgement that text was taken from your program.  But then give
them time to fix up the acknowledgements.  Assuming good faith is
always a good default.

The other thing that you've complained about is that some folks have
(inaccurately, in your view) described squashfs-tools as not being
maintained.  I'd encourage you to take a step back, and consider how
this might be quite understandable how they might have gotten that
impression.

First of all, let's look on the documentation in kernel source tree,
located at Documentation/filesystems/squashfs.txt.  It states that
squashfs-tools's web site is www.squashfs.org, and the git tree is at
git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git.

The web site www.squashfs.org is not currently responding, but
according to the Internet Archive, it was redirecting to
http://squashfs.sourceforge.net/.  This web site describes the latest
version of squashfs-tools is 4.2, released in February 2011, It
apparently wasn't updated when squashfs-tools 4.3 was released in May
2014.

The git.kernel.org tree is identical to the sourceforge.net's git
tree.  That tree's most recent commit is from August 2017, e38956b9
("squashfs-tools: Add zstd support").  Now, the fascinating thing is
that the github tree has a completely different commit-id for the same
commit is 61133613 ("squashfs-tools: Add zstd support").  The git
commit that the two trees have in common is 9c1db6d1 from September
2014.

Reconstructing the git history, you didn't make any commits between
September 2014 and March 2017.  At that time, you merged a number of
github pull requests between 2014 and 2017, but then exported them as
patches and applied them on the kernel.org/sourceforge git trees.
Why, I'm not sure.

In August 2017, you stopped updating the kernel.org and sourceforge
git trees, and abandoned them.  After that for the rest of 2017, you
merged one more pull request, and applied one commit to add the -nold
option.  In 2018, there were only two commits, in February and June.
And then nothing until April 2019 (about the time that squash-tools-ng
was started/announced), there has been a flurry of activity, including
merging github pull requests from 2017 and 2018, antd you've done a
lot of work since then.

I say this not to criticize the amount of attention you've paid to
squashfs-tools, but to point out that when David started work on
squashfs-tools-ng, it's not unreasonable that he might have gotten the
impression that development had ceased --- especially if he followed
the documentation in the kernel sources, and found an extremely
cobwebby website, and a git tree on git.kernel.org that hadn't been
updated since 2017, with substantive heavy development basically
ending in 2014 (which is also when the last release of squashfs-tools
was cut).  You don't need to ascribe malice to what might just simply
be an impression by looking in the official locations in the official
kernel documentation!

As a fellow kernel file system developer, let me make a few
suggestions.

* Don't worry about with "competing" software projects.  For a while,
  a multi-billion dollar company attempted to maintain a BSD-licensed
  "competition" to some of the programs in e2fsprogs.  This was
  because Andy Rubin was highly allergic to the GPL way back when.  I
  pointed the independent implementation was creating invalid file
  systems, and was buggy, and in general was making that billion
  dollar company's life harder, not easier.  They eventually gave up
  on it, and Android uses e2fsprogs these days.

  The whole point of open source is "may the best code win".  If
  you're convinced that you, as the upstream kernel developer, can do
  a better job maintaining the userspace tools, then instead of
  complaining and threatening to sue, just keep your head down, and
  keep improving your code, and in the end, the best code will win.

* I'd suggest that you make sure there is a single canonical git tree.
  It appears it's the github version of your git tree.  So... starting
  with your github tree, do a "git merge" of the master branch from
  git.kernel.org, and then push updates to github, git.kernel.org, and
  git.sf.code.net.  It's fine to have multiple mirrors of your git
  tree.  I maintain multiple copies of git e2fsprogs repo on
  git.kernel.org, github, and sourceforge.

* Please consider tagging your releases.  There are git tags for
  squashfs 3.1 and 3.2, 

Bug#931624: python3.8 ftbfs on the Hurd and KFreeBSD

[Samuel Thibault]

Hello,

Matthias Klose, le lun. 08 juil. 2019 13:37:00 +0200, a ecrit:
> The hurd-i386 and kfreebsd-* builds had some missing symbols, seen in
> 
> https://buildd.debian.org/status/fetch.php?pkg=python3.8=hurd-i386=3.8.0%7Eb2-1=1562346528=0
> https://buildd.debian.org/status/fetch.php?pkg=python3.8=kfreebsd-amd64=3.8.0%7Eb1-2=1560770610=0

Here is a mach implementation for the native thread ids, and the patch
to enable the symbol on hurd-any too.

Samuel
Index: python3.8-3.8.0~b2/Include/pythread.h
===
--- python3.8-3.8.0~b2.orig/Include/pythread.h
+++ python3.8-3.8.0~b2/Include/pythread.h
@@ -26,7 +26,7 @@ PyAPI_FUNC(unsigned long) PyThread_start
 PyAPI_FUNC(void) _Py_NO_RETURN PyThread_exit_thread(void);
 PyAPI_FUNC(unsigned long) PyThread_get_thread_ident(void);
 
-#if defined(__APPLE__) || defined(__linux__) || defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__) || defined(_WIN32) || defined(_AIX)
+#if defined(__APPLE__) || defined(__linux__) || defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__) || defined(_WIN32) || defined(_AIX) || defined(__GNU__)
 #define PY_HAVE_THREAD_NATIVE_ID
 PyAPI_FUNC(unsigned long) PyThread_get_thread_native_id(void);
 #endif
Index: python3.8-3.8.0~b2/Python/thread_pthread.h
===
--- python3.8-3.8.0~b2.orig/Python/thread_pthread.h
+++ python3.8-3.8.0~b2/Python/thread_pthread.h
@@ -22,6 +22,9 @@
 #   include   /* thread_self() */
 #elif defined(__NetBSD__)
 #   include  /* _lwp_self() */
+#elif defined(__GNU__)
+#   include /* mach_thread_self(), mach_task_self(),
+   mach_port_deallocate() */
 #endif
 
 /* The POSIX spec requires that use of pthread_attr_setstacksize
@@ -338,6 +341,10 @@ PyThread_get_thread_native_id(void)
 #elif defined(__NetBSD__)
 lwpid_t native_id;
 native_id = _lwp_self();
+#elif defined(__GNU__)
+mach_port_t native_id;
+native_id = mach_thread_self();
+mach_port_deallocate(mach_task_self(), mach_thread_self());
 #endif
 return (unsigned long) native_id;
 }
Index: python3.8-3.8.0~b2/debian/libpython.symbols.in
===
--- python3.8-3.8.0~b2.orig/debian/libpython.symbols.in
+++ python3.8-3.8.0~b2/debian/libpython.symbols.in
@@ -913,7 +913,7 @@
  PyThread_get_key_value@Base @SVER@
  PyThread_get_stacksize@Base @SVER@
  PyThread_get_thread_ident@Base @SVER@
- (arch=linux-any)PyThread_get_thread_native_id@Base @SVER@
+ (arch=linux-any hurd-any)PyThread_get_thread_native_id@Base @SVER@
  PyThread_init_thread@Base @SVER@
  PyThread_release_lock@Base @SVER@
  PyThread_set_key_value@Base @SVER@

Bug#933693: rust-cargo: FTBFS due to missing/uninstallable build dependencies

[Nicolas Braud-Santoni]

Source: rust-cargo
Version: 0.35.0-1
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

rust-cargo fails to rebuild from source (in a clean sbuild environment).

I ran into this while rebuilding all reverse dependencies of rust-openssl-sys
prior to uploading an updated version.

Best,

  nicoo

- ---

$ sbuild -d sid rust-cargo
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on localhost

+==+
| rust-cargo (amd64)   Thu, 01 Aug 2019 23:34:16 + |
+==+

Package: rust-cargo
Distribution: sid
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

[...]

+--+
| Update chroot|
+--+

[...]

+--+
| Fetch source files   |
+--+


Check APT
- -

Checking available source versions...

Download source files with APT
- --

Reading package lists...
NOTICE: 'rust-cargo' packaging is maintained in the 'Git' version control 
system at:
https://salsa.debian.org/rust-team/debcargo-conf.git [src/cargo]
Please use:
git clone https://salsa.debian.org/rust-team/debcargo-conf.git [src/cargo]
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 943 kB of source archives.
Get:1 http://localhost:3142/debian sid/main rust-cargo 0.35.0-1 (dsc) [5100 B]
Get:2 http://localhost:3142/debian sid/main rust-cargo 0.35.0-1 (tar) [934 kB]
Get:3 http://localhost:3142/debian sid/main rust-cargo 0.35.0-1 (diff) [4304 B]
Fetched 943 kB in 0s (11.2 MB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 
'build/rust-cargo-oCDNo8/rust-cargo-0.35.0' with '<>'
I: NOTICE: Log filtering will replace 'build/rust-cargo-oCDNo8' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
- -

Merged Build-Depends: debhelper (>= 11), dh-cargo (>= 15), cargo, rustc, 
libstd-rust-dev, librust-atty-0.2+default-dev, librust-byteorder-1+default-dev 
(>= 1.2-~~), librust-bytesize-1+default-dev, librust-clap-2+default-dev (>= 
2.31.2-~~), librust-core-foundation-0.6+default-dev, 
librust-core-foundation-0.6+mac-os-10-7-support-dev, 
librust-crates-io-0.23+default-dev, librust-crossbeam-utils-0.6+default-dev, 
librust-crypto-hash-0.3+default-dev (>= 0.3.1-~~), librust-curl-0.4+default-dev 
(>= 0.4.19-~~), librust-curl-0.4+http2-dev (>= 0.4.19-~~), 
librust-curl-sys-0.4+default-dev (>= 0.4.15-~~), 
librust-env-logger-0.6+default-dev, librust-failure-0.1+default-dev (>= 
0.1.5-~~), librust-filetime-0.2+default-dev, librust-flate2-1+default-dev (>= 
1.0.3-~~), librust-flate2-1+zlib-dev (>= 1.0.3-~~), 
librust-fs2-0.4+default-dev, librust-fwdansi-1+default-dev, 
librust-git2-0.8+default-dev, librust-git2-curl-0.9+default-dev, 
librust-glob-0.2+default-dev (>= 0.2.11-~~), librust-hex-0.3+default-dev, 
librust-home-0.3+default-dev, librust-ignore-0.4+default-dev, 
librust-im-rc-12+default-dev (>= 12.1.0-~~), librust-jobserver-0.1+default-dev 
(>= 0.1.11-~~), librust-lazy-static-1+default-dev (>= 1.2.0-~~), 
librust-lazycell-1+default-dev (>= 1.2.0-~~), librust-libc-0.2+default-dev, 
librust-libgit2-sys-0.7+default-dev (>= 0.7.9-~~), librust-log-0.4+default-dev 
(>= 0.4.6-~~), librust-miow-0.3+default-dev (>= 0.3.1-~~), 
librust-num-cpus-1+default-dev, librust-opener-0.3+default-dev, 
librust-rustc-workspace-hack-1+default-dev, librust-rustfix-0.4+default-dev (>= 
0.4.4-~~), librust-same-file-1+default-dev, librust-semver-0.9+default-dev, 
librust-semver-0.9+serde-dev, librust-serde-1+default-dev (>= 1.0.82-~~), 
librust-serde-1+derive-dev (>= 1.0.82-~~), 
librust-serde-ignored-0.0.4+default-dev, librust-serde-json-1+default-dev (>= 
1.0.30-~~), librust-serde-json-1+raw-value-dev (>= 1.0.30-~~), 
librust-shell-escape-0.1+default-dev (>= 0.1.4-~~), librust-tar-0.4-dev (>= 
0.4.18-~~), librust-tempfile-3+default-dev, librust-termcolor-1+default-dev, 
librust-toml-0.4+default-dev (>= 0.4.2-~~), 
librust-unicode-width-0.1+default-dev (>= 0.1.5-~~), librust-url-1+default-dev 
(>= 1.1-~~), librust-url-serde-0.2+default-dev, librust-winapi-0.3+basetsd-dev, 
librust-winapi-0.3+default-dev, librust-winapi-0.3+handleapi-dev, 
librust-winapi-0.3+jobapi-dev, 

Bug#928462: new upstream (4.0)

[Daniel Baumann]

retitle 928462 new upstream (4.1)
thanks

Hi,

in the meanwhile, version 4.1 has been released.

It fixes two CVEs, i didn't check though if they apply to the 3.x
shipped in unstable to stable. Nevertheless, it would be nice if you
could upgrade to the current version.

Regards,
Daniel

Bug#933692: new upstream (2.8.3)

[Daniel Baumann]

Package: knot
Severity: wishlist

Hi,

it would be nice if you could upgrade knot to the current upstream
version (2.8.3).

Regards,
Daniel

Bug#933691: solaar: New maintainer for project new repo at https://github.com/pwr-Solaar/Solaar

[Grant Diffey]

Package: solaar
Version: 0.9.2+dfsg-9
Severity: wishlist

Dear Maintainer,

Upstream has been forked and is now actively maintained and just made a release
of 1.0.1

The original project uri redirects to pwr-solaar/solaar on github.

Regards,

Grant



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

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

Versions of packages solaar depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.72
ii  gir1.2-gtk-3.0 3.24.10-1
ii  passwd 1:4.7-2
ii  python 2.7.16-1
ii  python-gi  3.30.4-1
ii  python-pyudev  0.21.0-1
ii  udev   241-7

Versions of packages solaar recommends:
ii  gir1.2-notify-0.7  0.7.7-4
ii  python-dbus1.2.8-3
ii  systemd241-7
ii  upower 0.99.10-1

Versions of packages solaar suggests:
pn  gir1.2-appindicator3-0.1  
pn  solaar-gnome3 

-- debconf information excluded

Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores

[GCS]

On Thu, Aug 1, 2019 at 5:27 PM Phillip Lougher
 wrote:
> On Wed, 31 Jul 2019 17:43:44 +0200 Alexander Couzens  wrote:
> > > On Wed, Jul 31, 2019 at 3:06 AM Steven Shiau 
> > > wrote: [...]
> > >  As mentioned in the past, it's the
> > > 0016-remove-frag_deflator_thread.patch that needs either reverted or
> > > fixed by it's original author, Alexander Couzens (added to this mail).
> >
> > Since I've full weeks ahead, I can not make any estimation when
> > I've time to look onto the performance issue.
>
> That patch is a laughable piece of rubbish.  I believe both you
> people (the Debian maintainer and author) are in total denial
> about your incompetence in this matter.  This is obviously just my
> opinion I've formed over the last couple of months, in case you want to
> claim that it is libellous.
 Good to know that you could form your opinion in the last couple of
months as on the other side I didn't know you until last week.

> It is, obvious, from the patch where the problem lies.  You *remove*
> the parallel fragment compressor threads, and move the work onto the
> main thread.
>
> Now what do you think that does?  It completely removes a significant
> amount of the parallelism of Mksquashfs and makes the main thread
> a bottleneck.
>
> This is your fault and your problem, and it lies in your lack of
> understanding.
 Who said we don't know where is the bottleneck? Alexander only stated
he can't work on fixing the bottleneck for some weeks.
While I don't know Alexander in person, according to my information he
contributes to 227 projects. Those programmed in C, C++, Python and
Rust; I wouldn't say he lacks any understanding in code.

> Yet you continually blame your inability to make Mksquashfs work
> correctly on *my* code being old and unmaintained and badly written.
 Never said that 1) mksquashfs doesn't work correctly, 2) it has a
problem which you don't fix and not possible to fix by others because
your code quality is bad. Please prove it where I have said such
things.

> This can be seen from the following excerpt from a post in this
> Debian bug thread made by the Debian maintainer.
>
> "> First of all, as squashfs-tools wasn't written in the last years, when
> > reproducible builds became more famous. So it's not written
> > with reproducible building in mind.
> > For me is reproducible builds more important than using all cpu cores.
> > But I don't use it with gigabytes images.
>  Yeah, it's quite an old software without real development in the recent 
> years."
 Just for the record, this is Debian bugreport #919207 [1] started by
a third person (not me or Alexander), Chris Lamb. Neither written by
me, but Alexander[2]. More importantly it only states that development
goals was not that the result image should always be the same (be
reproducible). It doesn't say anything about code quality.

> " This sounds more complex work than it can be achieved in this week.
> Maybe a complete rewrite would be better then on the long run."
 Written by me, talking _about the patch_ used for the
reproducibility[3] and _not_ about your code, see which part of the
previous email was referred above.

> Constantly pointing the blame at my tools and my code.
 Again, where is the blame on your code? You didn't code it with
reproducibility in mind, but it doesn't mean in any way that your code
would be bad.

> This is typical of the poor worker who chooses to blame everyone
> else but himself.
 Let me ask, who is the one who puff it up, cross post to unrelated
mailing lists (like LKML, which doesn't involved with Debian matters
or squashfs-tools application development)?

> None of that is the case.  50% of the code-base of Squashfs-tools
> was (re-)written in the last 9 years as part of on-going improvements.
> It has also been maintained across that period.
 Until recently the know VCS location was at SourceForge[4]. The last
commit there from 2017-08-15, adding zstd support by Sean Purcell. In
2017 there were eight commits, the one mentioned previously and thinks
like "Make all compressor functions static", "Fix pseudo format error
message", "add pseudo definition format to the help text" and "improve
the error message when filenames with spaces are used" etc. Doesn't
look like a rewrite.

> As for your specific claim that Mksquashfs can't be made to produce
> reproducible builds because it is old and written before reproducible
> builds became popular.  That is abject nonsense.
 Where do you see the statement it can't be made to produce
reproducible images? Again, it only said when you originally coded
squashfs-tools this was not in your goals.

> I added reproducible builds to Mksquashfs.  It took one weekend.
>
> https://github.com/plougher/squashfs-tools/commit/24da0c63c80be64e1adc3f24c27459ebe18a19af
 On June the 30th, 2019 just for the record. For some reason you
didn't notice anyone about this, that you have the correct solution
when talking about this matter[5].

> Squashfs-tools-ng, this is a rogue 

Bug#933671: RFS: multimail/0.52-1

[Adam Borowski]

On Thu, Aug 01, 2019 at 07:36:00PM -0300, Fernando Toledo wrote:
> El 1/8/19 a las 17:43, Adam Borowski escribió:
> > On Thu, Aug 01, 2019 at 01:57:51PM -0300, Fernando Toledo wrote:
> >>  * Package name: multimail
> >>Version : 0.52-1

> > At a brief glance, the package seems ok, but the changelog has a lot of
> > confusion wrt who's maintaining it: first there's a not-in-archive adoption
> > by Robert James Clay, then your NMU, then a seemingly regular entry.
> > Could you please describe that in a more obvious way?
> > 
> > I haven't yet reviewed the package well enough for 11 years of neglect.

> Yeah i think so too, Peter Karlsson was the mantainer up to 0.49
> Then, Robert try to update the package and build the 0.50 that i think
> that never was included on debian archive.
> 
> Due to lack of updates i want to try to keep the software. (and build
> 0.51 and now 0.52)

That's cool -- it's obvious that Robert isn't around.

> Should the lines of the versions (0.50 and 0.51) be eliminated? and let
> the 0.49 and 0.52?

I'd preserve at least Robert's entry separately.  It hasn't ever been in the
archive, but I feel it may be good to have an obvious line.

The other option is to use [ Someone ] notation.


What I asked to clarify, though, is that it's you who's adopting the package
now, as Robert's attempt wasn't completed.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#933671: RFS: multimail/0.52-1

[Fernando Toledo]

El 1/8/19 a las 17:43, Adam Borowski escribió:
> On Thu, Aug 01, 2019 at 01:57:51PM -0300, Fernando Toledo wrote:
>>  * Package name: multimail
>>Version : 0.52-1
> 
>>   Changes since the last upload:
>>
>>   adjust patch and build version 0.52
>>
>>   https://github.com/ftoledo/pkg-multimail/blob/master/debian/changelog
> 
> At a brief glance, the package seems ok, but the changelog has a lot of
> confusion wrt who's maintaining it: first there's a not-in-archive adoption
> by Robert James Clay, then your NMU, then a seemingly regular entry.
> Could you please describe that in a more obvious way?
> 
> I haven't yet reviewed the package well enough for 11 years of neglect.
> 
> 
> Meow!
> 
Yeah i think so too, Peter Karlsson was the mantainer up to 0.49
Then, Robert try to update the package and build the 0.50 that i think
that never was included on debian archive.

Due to lack of updates i want to try to keep the software. (and build
0.51 and now 0.52)

Should the lines of the versions (0.50 and 0.51) be eliminated? and let
the 0.49 and 0.52?

thanks for help!


-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

Bug#925550: signing cert EKU

[Chaskiel Grundman]

The problem openssl has is with the intermediate signing certificate's
extendedKeyUsage.
openssl wants codeSigning (1.3.6.1.5.5.7.3.3) or emailProtection
(1.3.6.1.5.5.7.3.4).

The certificate actually has msCTLSign ("Microsoft Trust List Signing",
1.3.6.1.4.1.311.10.3.1) for some reason. The only use for this EKU appears
to be certificate list updates.

Bug#933690: new upstream (2.9)

[Daniel Baumann]

Package: bash-completion
Severity: wishlist

Hi,

it would be nice if you could upgrade to the current upstream version
(2.9) of bash-completion.

Regards,
Daniel

Bug#932759: [Pkg-xen-devel] Bug#932759: After upgrade from stretch to buster, removal of obsolete xen 4.8 packages seems to trigger shutdown of xenconsoled

[Hans van Kranenburg]

On 7/23/19 4:07 PM, niek wrote:
> [...]
> 2019-07-21 07:38:40 status installed xen-utils-4.8:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:38:40 remove xen-utils-4.8:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11 
> 2019-07-21 07:38:40 status half-configured xen-utils-4.8:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:38:41 status half-installed xen-utils-4.8:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:38:41 status config-files xen-utils-4.8:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:38:41 status not-installed xen-utils-4.8:amd64 
> 2019-07-21 07:38:41 status installed libxen-4.8:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:38:41 remove libxen-4.8:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11 
> 2019-07-21 07:38:41 status half-configured libxen-4.8:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:38:41 status half-installed libxen-4.8:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:38:41 status config-files libxen-4.8:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:38:41 status not-installed libxen-4.8:amd64 
> [...]
> 2019-07-21 07:38:42 status installed xen-hypervisor-4.8-amd64:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:38:42 remove xen-hypervisor-4.8-amd64:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11 
> 2019-07-21 07:38:42 status half-configured
> xen-hypervisor-4.8-amd64:amd64 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:38:42 status half-installed xen-hypervisor-4.8-amd64:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11
> 2019-07-21 07:39:41 status config-files xen-hypervisor-4.8-amd64:amd64
> 4.8.5+shim4.10.2+xsa282-1+deb9u11

Ok, so, the most interesting question for me is...

On line 50 in the init script:

https://salsa.debian.org/xen-team/debian-xen/blob/master/debian/xen-utils-common.xen.init

case $DPKG_MAINTSCRIPT_PACKAGE in
xen-utils-$VERSION) ;;  # xen-utils-V maintscript, under Xen X=V
xen-utils-*)exit 0;; # xen-utils-V maintscript, but under Xen X!=V
*)  ;;  # maybe not under dpkg, etc.
esac

What is the value of this $DPKG_MAINTSCRIPT_PACKAGE when it happens?

Could it be something else than something beginning with xen-utils-?
I have a suspicion that the systemd[1]: Reloading. has something to do
with it. Or the triggers?

Anyway, if DPKG_MAINTSCRIPT_PACKAGE gets lost *anywhere* in whatever
happens, it might end up as empty, and then matching just *.

But, we really need find out how to reproduce it in a test environment. :|

Hans

Bug#933689: python3-singledispatch should be dropped from debian

[Daniel Kahn Gillmor]

Package: python3-singledispatch
Version: 3.4.0.3-2
Control: affects -1 python3-librtmp python3-pecan python3-livestreamer

python 3.4 ships with singledispatch in functools.

python3-singledispatch is a backport of this functionality to python 2.6
- 3.3.

Since debian doesn't ship any older version of python3 any longer, (and
hasn't since before the oldoldstable release), python3-singledispatch
should be dropped from debian.

If there are reverse dependencies that really want
python3-singledispatch, they should be patched to use singledispatch
from functools.

0 dkg@alice:~$ apt rdepends python3-singledispatch
python3-singledispatch
Reverse Depends:
  Depends: python3-librtmp
  Depends: python3-pecan
  Depends: python3-livestreamer
  Depends: python3-pecan
0 dkg@alice:~$ 

   --dkg


signature.asc
Description: PGP signature

Bug#933688: FTBFS when importing sources into git because of empty directories

[Daniel Baumann]

tag 933688 + patch
thanks

Here's a patch:

https://git.progress-linux.org/distributions/engywuck-backports/packages/inkscape/commit/?id=98c0a1546d57b88b96f1eadb769abbe4c51d0571

Regards,
Daniel

Bug#933592: [Pkg-javascript-devel] Bug#933592: Webpack 4 transition: node-node-forge fail to build with webpack 4

[Jonas Smedegaard]

Control: tags -1 +patch

Quoting Pirate Praveen (2019-08-01 16:52:27)
> On 2019-08-01 01:43, Jonas Smedegaard wrote:
> > Please actually provide a patch, or at least describe in human words 
> > what is the fix - not simply telling to go dig out a solution within 
> > other packages.
> 
> The exact commit was linked in transition wiki page which was also 
> shared in the original message. Sorry for not sharing it directly in 
> the bug report.
> 
> https://salsa.debian.org/js-team/node-axios/blob/5282cb7f2ab8cbec1e90dbce11cb63882377fda8/debian/patches/use-webpack4.patch
> 
> https://salsa.debian.org/js-team/node-source-map/commit/3d82f682ea09561a95d4413a04c8090d563bae99
> 
> "plugin" field should be replaced with "optimization" field. Or you 
> can also just use 'production' mode which minimizes by default.
> 
> See 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=933662;filename=node-matrix-js-sdk-0.9.2.debian.patch.txt;msg=5
>  
> (remove "plugin" field and add "mode": production).

Thanks.  That was exactly the kind of details I was missing.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#933688: FTBFS when importing sources into git because of empty directories

[Daniel Baumann]

Package: inkscape
Version: 1.0~alpha1-1
Severity: wishlist

Hi,

when importing inkscape into a git repository, checking it out on my
buildd fails because share/extensions is an empty directory that git
cannot track. I'll send a patch for this after having recieved the bug
number..

---snip---
-- Installing:
/build/inkscape-1.0_alpha-1_progress5+u1/debian/inkscape/usr/share/man/zh_TW/man1/inkscape.1
-- Installing:
/build/inkscape-1.0_alpha-1_progress5+u1/debian/inkscape/usr/share/man/man1/inkview.1
CMake Error at share/cmake_install.cmake:41 (file):
  file INSTALL cannot find
  "/build/inkscape-1.0_alpha-1_progress5+u1/share/extensions".
Call Stack (most recent call first):
  cmake_install.cmake:56 (include)


make[2]: *** [Makefile:132: install] Error 1
make[2]: Leaving directory
'/build/inkscape-1.0_alpha-1_progress5+u1/obj-x86_64-linux-gnu'
dh_auto_install: cd obj-x86_64-linux-gnu && make -j88 install
DESTDIR=/build/inkscape-1.0_alpha-1_progress5\+u1/debian/inkscape
AM_UPDATE_INF2
make[1]: *** [debian/rules:14: override_dh_auto_install-arch] Error 2
make[1]: Leaving directory '/build/inkscape-1.0_alpha-1_progress5+u1'
make: *** [debian/rules:6: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
exit status 2
---snap---

Regards,
Daniel

Bug#881177: xdvi does not draw all the symbols properly

[Leon Meier]

Hi Hilmar,

I cannot reproduce this problem using xdvi on ubuntu disco as of today 
(2019-08-01).  I'll double-check the current status on Debian later and 
report here.


Cheers,
Leon

Bug#320360: New URL's

[Jeremy Sowden]

The original links no longer work, but I have found the following:

  http://www.aiei.ch/linux/amiga/
  http://www.aiei.ch/linux/amiga/amiga.wmpbtheme

J.


signature.asc
Description: PGP signature

Bug#933687: ITP: golang-golang-x-arch -- Library with machine architecture information

[Emanuel Krivoy]

Package: wnpp
Severity: wishlist
Owner: Emanuel Krivoy 

* Package name: golang-golang-x-arch
  Version : 0.0~git20190312.788fe5f-1
  Upstream Author : The Go Authors
* URL : https://github.com/golang/arch
* License : BSD-3-clause
  Programming Lang: Go
  Description : Library with machine architecture information

This library holds machine architecture information used by the Go
toolchain. It supports the arm, arm64, ppc64 and x86 architectures. It mostly
includes functions for decoding assembly instructions.

This library is a dependency of delve (github.com/go-delve/delve, ITP in
#932835). If possible I'd like this package to be co-mantained/sponsored by the
Go Team.

Bug#877860: texlive-latex-recommended: Fontspec fails under LuaTeX if texlive-luatex (no dependency) is not installed

[Hilmar Preuße]

Control: tags 877860 + pending

Am 06.10.2017 um 12:28 teilte Timo Kalliomäki mit:

> When compiling with LuaTeX, the fontspec package requires the
> package luaotfload. However, there is no dependency to texlive-luatex
> in which luaotfload is contained and compilation will fail unless the
> missing dependency is manually installed.
> 
I've added texlive-luatex to the suggests, even a recommends would be to
strong. People have the chance to use apt-file to search for missing files.

Fix is on git, bug will be closed on next upload.

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



signature.asc
Description: OpenPGP digital signature

Bug#932688: Unable to update

[Vincent Prat]

Hi,

Unfortunately, I am unable to update astroplan, possibly because of
another change in astropy.
I reported the issue on Github
(https://github.com/astropy/astroplan/issues/416).

Cheers

Vincent

Bug#881177: xdvi does not draw all the symbols properly

[Hilmar Preuße]

Am 08.11.2017 um 16:15 teilte Leon Meier mit:

Hi Leon,

Sorry, we didn't see your bug report. The reason is that mails > 100KB
are not transferred to our mailing list. They are just visible in the
bug tracker.

> How to reproduce:
> 1. Get some dvi file; in my example it is
>   http://web.mat.bham.ac.uk/R.W.Kaye/latex/el2e.dvi
> 2. run `xdvi el2e.dvi &`
> 3. Observe that some symbols are not displayed or not fully displayed.
> The screenshot (screenshot1.jpg) is attached.
> 
> Which symbols are not displayed or not fully displayed seems random.
> Magnification glass shows the missing strikes.
> 
> The following actions do not alter anything on the fact that certain
> symbols are not fully displayed:
> - switching to some other window and back
> - switching to some other screen and back via Ctrl+Alt+Down, Ctrl+Alt+Up
> 
> The following actions change which symbols are not displayed or not
> fully displayed:
> - switching to a tty (Ctrl+Alt+Fn) and back
> - closing xdvi and starting it anew on the same file
> - scrolling to a different page of the file and back.
> See the second screenshort for another run on the same file.
> 
> My display manager is Gnome.
> 

I have here a quite different setup: xdvi / evince running on Debian
unstable. Display is (through X forwarding) an MobaXterm running on
Windows 10. I tried both viewers and I can't reproduce the problem.

1. Are you still able to reproduce the issue?
2. Did you try another application to display the file, e.g, evince?

I'd rather suspect that you look at a problem @the X server than the
application trying to display anything.

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



signature.asc
Description: OpenPGP digital signature

Bug#933370: chrony won't start

[Vincent Blut]

On Wed, Jul 31, 2019 at 01:18:02PM -0700, Ross Boylan wrote:

Here are some tests I wasn't able to get to earlier.

On Mon, Jul 29, 2019 at 5:39 PM Vincent Blut  wrote:
.


Nevertheless, I would like you to test some things.
To begin with, I have an updated chrony unit file in a private git
branch targeting a future revision (not the next one) containing:

Wants=time-sync.target
Before=time-sync.target

That would be great if you could override the unit file currently
provided by chrony to add these two lines. I have no high hopes, but I’m
sill curious to see the result in this case.


I tried it and it didn't help.  I was still able to start it
manually--I was a little  concerned that since Before=time-sync.target
would be unsatisfiable after startup it would never start.


Thanks, it was a bit expected though. Anyway, I’ll add these two lines 
to the unit file provided by chrony because according to the 
time-sync.target documentation:
   “Services responsible for synchronizing the system clock from a 
   remote source (such as NTP client implementations) should pull in 
   this target and order themselves before it.”



If that does not work, just removing systemd-timesyncd.service from the
“Conflicts=” line in the chrony unit file may fix the issue… well I
think.  ;-)


I did systemctl disable systemd-timesyncd and now chrony runs (and
stays running) on startup.


Disabling systemd-timesyncd was guaranteed enough to succeed. That shows 
that chrony is probably not at fault here. However, before merging this 
bug report with #883241 and reassigning them to systemd, I would really 
appreciate if you could check what’s happening by removing 
systemd-timesyncd.service from the “Conflicts=” line in the chrony unit 
file.


Note that I would totally understand that you refuse to run some tests 
again! I certainly do not want to burden you.


If you accept to run these tests, then:

# Reenable systemd-timesyncd
# systemctl enable systemd-timesyncd.service

# Edit chrony’s unit file
# systemctl edit --full chrony.service

That will invoke an editor. From there, remove 
“systemd-timesyncd.service” from the “Conflicts=” line. Save & exit!


# Restart the system and report chrony’s status here (ditto for 
systemd-timesyncd)


# If chrony is correctly running, you have the choice to leave things as 
# they are, but if you want to revert the chrony unit file to what it 
# was, run:

# systemctl revert chrony.service

# If you chose the revert option, disable systemd-timesyncd again
# systemctl disable systemd-timesyncd.service

Hope that helps!


Here are some logs and status info from what happened with the
override in place and
debug systemd.log_level=debug as kernel options (but none of the other
options I used before).
This also shows that status of systemd-timesyncd right after startup.
This is from before I disabled systemd-timesyncd.service.

root@barley:~# date; uptime
Wed 31 Jul 2019 12:51:18 PM PDT
12:51:18 up 2 min, 11 users,  load average: 6.08, 2.93, 1.12
root@barley:~# systemctl status chrony
[snip…]



root@barley:~# systemctl status systemd-timesyncd
[snip…]


Indeed, we can that pulling in time-sync.target and starting chrony 
before it is insufficient. As said previously, I did not have high hopes 
though.



Ross


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#933671: RFS: multimail/0.52-1

[Adam Borowski]

On Thu, Aug 01, 2019 at 01:57:51PM -0300, Fernando Toledo wrote:
>  * Package name: multimail
>Version : 0.52-1

>   Changes since the last upload:
> 
>   adjust patch and build version 0.52
> 
>   https://github.com/ftoledo/pkg-multimail/blob/master/debian/changelog

At a brief glance, the package seems ok, but the changelog has a lot of
confusion wrt who's maintaining it: first there's a not-in-archive adoption
by Robert James Clay, then your NMU, then a seemingly regular entry.
Could you please describe that in a more obvious way?

I haven't yet reviewed the package well enough for 11 years of neglect.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#933514: tmux: Screen garbling in ncurses apps

[Romain Francoise]

A patch for this is now available in the upstream bug tracker
(https://github.com/tmux/tmux/issues/1861) and I have tested it
successfully using the Mutt recipe from #933572.

Bug#933686: python-gnuplot: please add Python 3 support

[Andrej Shadura]

Package: src:python-gnuplot
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

With Python 2 scheduled to be removed mostly before the Bullseye
release, it is necessary for your package to provide Python 3 support to
be releasable.

Please have a look at the possibility of getting it, either upstream or
as a Debian patch.

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQJTBAEBCAA9FiEE47V74F4CWMP6ghzXtke0/0DsYwMFAl1DSOofHGFuZHJldy5z
aGFkdXJhQGNvbGxhYm9yYS5jby51awAKCRC2R7T/QOxjAxu5D/4hsCzmA55UCMlC
L9sl1MeRa9/bcHYnbx6aKu129ldGAAsuYi5wFKJnwWu1uA3QuQBzmz+T8/3L47PD
O0oanTuccVsBagB2Nbi2EZlTepEn2WBPehZQ0rbtwhagqvHYdxvdI1y4NNedU5u4
lRYtaHLtP14X5ByEPcdvX8c/pauhNiiv4XnbyqYTkcuKjFAkXCDwdCzto/acR+Z3
gOnzZtCBCwVWhNcd39EE5nDpoBR0Ywz2q4oUMJum3XnetF2ZGuSc8X5JtPJg5DpJ
jqkQ+Dg+XqC93WfCGId4ru54gh+l+ql5BNh9f/b+/BcDZNFVMPTSpGFi8SC9PzF+
L94gDKjtG/9TvLxYIzP1GyALVQzDOA+MnnfKGm1xPeu87G+gwmcmmZkzG4qjRqm8
vJMvGsL6fpKIQFX9FNxJtaZ+D2jDgiH5E42qS9pMSF1zZVTxP6ZrK4AzT9DTUpd+
+UiS+vkN0JEnVRpDy5/QlnMjWMAswKuIeAlwihh70r6dR/0dcmDbQ/x6KxCrimUO
aPkJmwuW9bq2VcI+4ouLsR6EzrIa5Ir4ILszsgtN44FFTVzCCYUzOhMyh0Qvdlkc
E1cIQ/mZeIsWCQzdlamSoCXZ6e3aaCqZoFlbyRwsxbibnBt/NdMB8Aq2lxUvGCcO
xJFES8qgGPBK0yLAJ+oDDHe52Adi7w==
=vuRB
-END PGP SIGNATURE-

Bug#933685: transition: http-parser

[Christoph Biedl]

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

Hello,

following the procedures as written in the Debian wiki, I am requesting
a transition slot for the http-parser library 2.9.2, accepted in
experimental earlier today.

A test rebuild of all the the packages listed at the transition page¹
result in one failure:

* python-httptools 0.0.11-1
  Bug report with upstream fix filed as #933684

All other packages passed:

* jabberd2 2.7.0-1
* libgit2 0.27.7+dfsg.1-0.2
* ocserv 0.12.2-3
* purple-matrix 0.0.0+git20180325-1
* ruby-http-parser.rb 0.6.0-4
* tang 7-1
* tcpflow 1.5.2+repack1-1

Kind regards,

Christoph

¹ https://release.debian.org/transitions/html/auto-http-parser.html


Ben file:

title = "http-parser";
is_affected = .depends ~ /\b(libhttp\-parser2\.8)\b/ | .depends ~ 
/\b(libhttp\-parser2\.9)\b/;
is_good = .depends ~ /\b(libhttp\-parser2\.9)\b/;
is_bad = .depends ~ /\b(libhttp\-parser2\.8)\b/;



signature.asc
Description: PGP signature

Bug#932717: RFS: blastem/0.6.3.2-2 -- Fast and accurate Genesis emulator

[Tobias Frost]

Control: tags -1 moreinfo

Hi Carlos,

there are not enough changes in the package that warrant an upload:
Changing compat level handling as only change is not enough…

However, there is bug #926498 … You probably want to fix that bug,
giving you the reason you need to justify an upload ;-)

--
tobi

Bug#933684: python-httptools: Please adjust for http-parser 2.9

[Christoph Biedl]

Source: python-httptools
Version: 0.0.11-1
Severity: important
Tags: patch

Dear Maintainer,

the http-parser library version 2.9 was accepted to experimental today,
and re-building all rdeps I noticed your package will fail to build in
the future due to a failure in the test suite.

This has already been fixed upstream. Please upgrade to at least 0.0.13,
or cherry-pick commit ebcc0fd, feel free to borrow from the patch
attached.

Regards,

Christoph
From d63280b950bfe0a875c45b4d73f4d18e8c91761f Mon Sep 17 00:00:00 2001
From: Christoph Biedl 
Date: Thu, 1 Aug 2019 21:46:24 +0200
Subject: [PATCH 1/2] Cherry-pick "Fix a unittest" to fix build error with
 http-parser 2.9

---
 debian/control|  2 +-
 ...-unittest-bump-the-version-to-0-0-13.patch | 19 +++
 debian/patches/series |  1 +
 3 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/cherry-pick.v0.0.11-6-gebcc0fd.fix-a-unittest-bump-the-version-to-0-0-13.patch

diff --git a/debian/control b/debian/control
index 4928709..0dcad52 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends:
  cython3,
  debhelper (>= 11),
  dh-python,
- libhttp-parser-dev,
+ libhttp-parser-dev (>= 2.9.2),
  python3-all-dev,
  python3-pytest,
  python3-setuptools,
diff --git a/debian/patches/cherry-pick.v0.0.11-6-gebcc0fd.fix-a-unittest-bump-the-version-to-0-0-13.patch b/debian/patches/cherry-pick.v0.0.11-6-gebcc0fd.fix-a-unittest-bump-the-version-to-0-0-13.patch
new file mode 100644
index 000..30bb954
--- /dev/null
+++ b/debian/patches/cherry-pick.v0.0.11-6-gebcc0fd.fix-a-unittest-bump-the-version-to-0-0-13.patch
@@ -0,0 +1,19 @@
+Subject: Fix a unittest; bump the version to 0.0.13
+Origin: v0.0.11-6-gebcc0fd 
+Upstream-Author: Yury Selivanov 
+Date: Mon Feb 25 14:55:35 2019 -0500
+
+--- a/tests/test_parser.py
 b/tests/test_parser.py
+@@ -582,9 +582,8 @@
+ (None, None, None, b'/a/b/c', b'b=1&', None, None))
+ 
+ def test_parser_url_2(self):
+-self.assertEqual(
+-self.parse(b''),
+-(None, None, None, None, None, None, None))
++with self.assertRaises(httptools.HttpParserInvalidURLError):
++self.parse(b'')
+ 
+ def test_parser_url_3(self):
+ with self.assertRaises(httptools.HttpParserInvalidURLError):
diff --git a/debian/patches/series b/debian/patches/series
index 4e746b7..d13e76a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 0002-Use-http_parser.h-from-distribution-installation.patch
 0003-Fix-unit-tests-on-invalid-data-after-connection-clos.patch
 0004-Do-not-install-package-data.patch
+cherry-pick.v0.0.11-6-gebcc0fd.fix-a-unittest-bump-the-version-to-0-0-13.patch
-- 
2.22.0

From 5581a99887dadf412d5a25280d5faa3fbb6846b2 Mon Sep 17 00:00:00 2001
From: Christoph Biedl 
Date: Thu, 1 Aug 2019 21:46:59 +0200
Subject: [PATCH 2/2] python-httptools 0.0.11-1.1

---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 26a11d9..a501a47 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+python-httptools (0.0.11-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Cherry-pick "Fix a unittest" to fix build error with
+http-parser 2.9
+
+ -- Christoph Biedl   Thu, 01 Aug 2019 21:46:59 +0200
+
 python-httptools (0.0.11-1) unstable; urgency=low
 
   * Initial release (Closes: #911498).
-- 
2.22.0



signature.asc
Description: PGP signature

Bug#933676: openjdk-11-jre-dcevm: openjdk-11-jre-dvecm doesn't include the hotswap agent

[Emmanuel Bourg]

Le 01/08/2019 à 20:21, Michael Meier a écrit :

> according to http://hotswapagent.org and 
> https://github.com/TravaOpenJDK/trava-
> jdk-11-dcevm/ the java 11 dvecm version is supposed to include the
> hotswapagent.
> This package here doesn't do so. Would be great if it also could include it. 
> So
> the tutorials/manuals on the web work directly.

Hi Michael,

Thank you for the suggestion. Technically the hotswap agent is a
separate project [1] so it can't really fit in the openjdk-11-jre-dcevm
package (it could depend on it though). I suggest turning this bug
report into a RFP.

Emmanuel Bourg

[1] https://github.com/HotswapProjects/HotswapAgent

Bug#933592: [Pkg-javascript-devel] Bug#933592: Processed: Webpack 4 transition: node-node-forge fail to build with webpack 4

[Pirate Praveen]

On 2019-08-01 01:43, Jonas Smedegaard wrote:

control: tags -1 =

Quoting Debian Bug Tracking System (2019-07-31 16:45:05)

Processing control commands:

> tags -1 patch


Please actually provide a patch, or at least describe in human words
what is the fix - not simply telling to go dig out a solution within
other packages.


The exact commit was linked in transition wiki page which was also 
shared in the original message. Sorry for not sharing it directly in the 
bug report.


https://salsa.debian.org/js-team/node-axios/blob/5282cb7f2ab8cbec1e90dbce11cb63882377fda8/debian/patches/use-webpack4.patch

https://salsa.debian.org/js-team/node-source-map/commit/3d82f682ea09561a95d4413a04c8090d563bae99

"plugin" field should be replaced with "optimization" field. Or you can 
also just use 'production' mode which minimizes by default.


See 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=933662;filename=node-matrix-js-sdk-0.9.2.debian.patch.txt;msg=5 
(remove "plugin" field and add "mode": production).

Bug#933683: cacti: Cacti needs fixes in order to work with newer MySQL versions to be merged

[Rafael David Tinoco]

Package: cacti
Severity: normal
Tags: patch upstream

Hello, I'm opening this bug to track the merge request made at:

https://salsa.debian.org/cacti-team/cacti/merge_requests/1

Where the changelog tells history about why it is needed:

  * dbc_authplugin parameter for dbconfig-common:
- debian/cacti.config changes default MySQL authentication
  plugin to a compatible (to PHP PDO and PHP mysqli) one.

  * Instructions have to contain workaround for NO_AUTO_CREATE_USER
- debian/README.Debian

  * General instructions have to contain workaround for NO_AUTO_CREATE_USER
- docs-source/General-Installing-Instructions.md

  * Fix MySQL keyword usage in table "aggregate_graph_templates"
- cacti.sql

It goes together with dbconfig fixes proposed at:

https://salsa.debian.org/debian/dbconfig-common/merge_requests/3

in order to make both packages to work with recent MySQL versions.

Thank you very much in advance for reviewing and considering this.

Best Regards

Rafael D. Tinoco
rafaeldtin...@ubuntu.com

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

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

Versions of packages cacti depends on:
pn  dbconfig-common  
pn  dbconfig-mysql | dbconfig-no-thanks  
ii  debconf [debconf-2.0]1.5.72
ii  fonts-dejavu-core2.37-1
pn  fonts-dejavu-extra   
pn  fonts-fork-awesome   
ii  javascript-common11
pn  libapache2-mod-php | php 
pn  libjs-c3 
pn  libjs-chart.js   
pn  libjs-d3 
ii  libjs-jquery 3.3.1~dfsg-3
ii  libjs-jquery-colorpicker 1.2.17-1
pn  libjs-jquery-cookie  
pn  libjs-jquery-hotkeys 
ii  libjs-jquery-jstree  3.3.7+dfsg1-1
pn  libjs-jquery-metadata
pn  libjs-jquery-tablesorter 
pn  libjs-jquery-timepicker  
ii  libjs-jquery-ui  1.12.1+dfsg-5
ii  libjs-jquery-ui-theme-smoothness 1.12.1+dfsg-1
ii  libjs-jquery-ui-theme-south-street   1.12.1+dfsg-1
ii  libjs-jquery-ui-theme-ui-darkness1.12.1+dfsg-1
pn  libjs-jquery-ui-touch-punch  
pn  libphp-phpmailer 
ii  perl 5.28.1-6
pn  php-cli  
pn  php-gd   
pn  php-gmp  
pn  php-json 
pn  php-ldap 
pn  php-mbstring 
pn  php-mysql
pn  php-phpseclib
pn  php-snmp 
pn  php-twig 
pn  php-xml  
pn  rrdtool  
pn  snmp 
ii  ucf  3.0038+nmu1

Versions of packages cacti recommends:
pn  apache2 | lighttpd | nginx | httpd   
pn  default-mysql-server | virtual-mysql-server  
ii  iputils-ping 3:20190515-2
ii  logrotate3.14.0-4

Versions of packages cacti suggests:
pn  cacti-spine  
pn  moreutils
pn  snmpd

Bug#932763: haproxy: `haproxy.cfg` contains an outdated URL and cipher choices

[Vincent Bernat]

 ❦ 22 juillet 2019 15:19 -05, April King :

> I would also strongly suggest bundling the RFC 7919 2048-bit
> Diffie-Hellman parameters file in the haproxy debian package as well.

For this part, I remember that in the past, it was better to have custom
DH parameters than widely used one. I don't quite understand what has
changed since. HAProxy did move away from DH params provided by RFC for
this reason. See:
 


I've update the cipher list for bind only:
 


It seems less important for servers to specify ciphers. We didn't do it
previously and I wouldn't want to break someone setup with such a change
(even if they are notified of it) as it is more likely to have apps
supporting only TLSv1.0 internally.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#859118: texlive-base: does not handle colon-delimited BROWSER environment variable

[Hilmar Preuße]

Control: forcemerge 570376 859118

Am 30.03.2017 um 15:43 teilte Julian Gilbey mit:

> My BROWSER environment variable is set to firefox:links:links2:lynx
> (as explained in the man(1) documentation).  I don't have any of the
> other environment variables listed on line 199 of
> /usr/share/texlive/texmf-dist/scripts/texdoc/config.tlu set.  I then
> get:
> 
Already reported. Merging.

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



signature.asc
Description: OpenPGP digital signature

Bug#933679: qpsmtpd: No Received header if received_hook configured

[Peter J. Holzer]

On 2019-08-01 20:58:39 +0200, Peter J. Holzer wrote:
> I will send a patch shortly.

Attached.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 
Description: Fix handling of received_line hook
 The received line(s) returned by the hook must be prepended to the
 header, not returned to the caller.
Author: Peter J. Holzer 
Bug-Debian: http://bugs.debian.org/933679
Index: qpsmtpd-0.94/lib/Qpsmtpd/SMTP.pm
===
--- qpsmtpd-0.94.orig/lib/Qpsmtpd/SMTP.pm
+++ qpsmtpd-0.94/lib/Qpsmtpd/SMTP.pm
@@ -870,7 +870,7 @@ sub received_line {
 die "YIELD not supported for received_line hook";
 }
 elsif ($rc == OK) {
-return join("\n", @received);
+$header_str = join("\n", @received);
 }
 else {# assume $rc == DECLINED
 $header_str = 


signature.asc
Description: PGP signature

Bug#933682: lintian-brush: Deals badly with homepage-field-uses-insecure-uri if upstream does not support https

[Andreas Tille]

Package: lintian-brush
Version: 0.17
Severity: normal

Hi,

I was running on paml[1].  It says:

paml(master) $ lintian-brush 
No changes made.


Some fixer scripts failed to run: {'homepage-field-uses-insecure-uri', 
'dep5-file-paragraph-references-header-paragraph', 
'upstream-metadata-file-is-missing', 'invalid-short-name-in-dep5-copyright', 
'global-files-wildcard-not-first-paragraph-in-dep5-copyright', 
'obsolete-field-in-dep5-copyright'}. Run with --verbose for details.

I tried in verbose mode and here are the problems issued:

Fixer 'dep5-file-paragraph-references-header-paragraph' failed to run.
Script 
/usr/share/lintian-brush/fixers/dep5-file-paragraph-references-header-paragraph.py
 failed with exit code: 1
Traceback (most recent call last):
  File 
"/usr/share/lintian-brush/fixers/dep5-file-paragraph-references-header-paragraph.py",
 line 36, in 
update_copyright(fix_header_license_references)
  File "/usr/lib/python3/dist-packages/lintian_brush/copyright.py", line 41, in 
update_copyright
'debian/copyright')
  File "/usr/lib/python3/dist-packages/lintian_brush/reformatting.py", line 45, 
in check_preserve_formatting
raise FormattingUnpreservable(path)
lintian_brush.reformatting.FormattingUnpreservable: debian/copyright

...

Script 
/usr/share/lintian-brush/fixers/global-files-wildcard-not-first-paragraph-in-dep5-copyright.py
 failed with exit code: 1
Traceback (most recent call last):
  File 
"/usr/share/lintian-brush/fixers/global-files-wildcard-not-first-paragraph-in-dep5-copyright.py",
 line 17, in 
update_copyright(swap_files_glob)
  File "/usr/lib/python3/dist-packages/lintian_brush/copyright.py", line 41, in 
update_copyright
'debian/copyright')
  File "/usr/lib/python3/dist-packages/lintian_brush/reformatting.py", line 45, 
in check_preserve_formatting
raise FormattingUnpreservable(path)
lintian_brush.reformatting.FormattingUnpreservable: debian/copyright

Fixer 'homepage-field-uses-insecure-uri' failed to run.
Script /usr/share/lintian-brush/fixers/homepage-field-uses-insecure-uri.py 
failed with exit code: 1
Traceback (most recent call last):
  File "/usr/lib/python3.7/urllib/request.py", line 1317, in do_open
encode_chunked=req.has_header('Transfer-encoding'))
  File "/usr/lib/python3.7/http/client.py", line 1229, in request
self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1275, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1224, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1016, in _send_output
self.send(msg)
  File "/usr/lib/python3.7/http/client.py", line 956, in send
self.connect()
  File "/usr/lib/python3.7/http/client.py", line 1392, in connect
server_hostname=server_hostname)
  File "/usr/lib/python3.7/ssl.py", line 412, in wrap_socket
session=session
  File "/usr/lib/python3.7/ssl.py", line 853, in _create
self.do_handshake()
  File "/usr/lib/python3.7/ssl.py", line 1117, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
verify failed: Hostname mismatch, certificate is not valid for 
'abacus.gene.ucl.ac.uk'. (_ssl.c:1056)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/lintian-brush/fixers/homepage-field-uses-insecure-uri.py", 
line 46, in 
update_control(source_package_cb=fix_homepage_header)
  File "/usr/lib/python3/dist-packages/lintian_brush/control.py", line 77, in 
update_control
update_control_file(BytesIO(original_contents), outf, **kwargs)
  File "/usr/lib/python3/dist-packages/lintian_brush/control.py", line 103, in 
update_control_file
source_package_cb(paragraph)
  File "/usr/share/lintian-brush/fixers/homepage-field-uses-insecure-uri.py", 
line 43, in fix_homepage_header
control["Homepage"] = fix_homepage(homepage)
  File "/usr/share/lintian-brush/fixers/homepage-field-uses-insecure-uri.py", 
line 32, in fix_homepage
https_contents = urllib.request.urlopen(https_url).read()
  File "/usr/lib/python3.7/urllib/request.py", line 222, in urlopen
return opener.open(url, data, timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 525, in open
response = self._open(req, data)
  File "/usr/lib/python3.7/urllib/request.py", line 543, in _open
'_open', req)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 1360, in https_open
context=self._context, check_hostname=self._check_hostname)
  File "/usr/lib/python3.7/urllib/request.py", line 1319, in 

Bug#932763: haproxy: `haproxy.cfg` contains an outdated URL and cipher choices

[Vincent Bernat]

 ❦ 22 juillet 2019 15:19 -05, April King :

> The existing `haproxy.cfg`, from `debian/haproxy.cfg` contains this URL:
> https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
> 
>
> However, it should point to this URL:
> https://ssl-config.mozilla.org/#server=haproxy 
> 
>
> Additionally, I would taking the list of ciphers from:
> ssl-default-bind-ciphers 
> ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
> ssl-default-bind-options no-sslv3
>
> And updating to the Mozilla Intermediate profile, as you can see here:
> https://ssl-config.mozilla.org/#server=haproxy=1.9.8=intermediate
> 
>
> I would also strongly suggest bundling the RFC 7919 2048-bit
> Diffie-Hellman parameters file in the haproxy debian package as well.

I'll do that in the branch for 2.0 (which at some point will be merged
in master). Thanks for the pointers!
-- 
What good is an obscenity trial except to popularize literature?
-- Nero Wolfe, "The League of Frightened Men"


signature.asc
Description: PGP signature

Bug#933681: ITP: python-pamqp -- RabbitMQ Focused AMQP low-level library

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-pamqp
  Version : 2.3.0
  Upstream Author : Gavin M. Roy 
* URL : https://github.com/gmr/pamqp/
* License : BSD-3-clause
  Programming Lang: Python
  Description : RabbitMQ Focused AMQP low-level library

 pamqp is a low level AMQP 0-9-1 frame encoding and decoding library for Python.
 It is not a end-user client library for talking to RabbitMQ but rather is used
 by client libraries for marshaling and unmarshaling AMQP frames.
 .
 AMQP class/method command class mappings can be found in the
 pamqp.specification module while actual frame encoding and encoding should be
 run through the pamqp.frame module.

This library is a new depencency for python-aioamqp. I do intend to maintain it
as part of the DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl1DPKkRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqobAgAvxj/0e7lXiqbZtcP+j6BQwuCI4fGZItw
pN08kydGgA3wWoct5j0zxKLfTLW5Skn0PajYLFWtTipAemEWXTCTFhJ1yDAkNFum
CER3EKlSr3UXHZzsF9wlCDPC179QgEnyFRjyeqUlBntIEqcXSGtu9fl4wa1/dVO3
XrWaAl4gB7chQYhDEskbW83iRgCLCmu7rKZJiPOoxSCkj0seMD4tY8PEqfrCe616
NO1P3vbvmFMK8im5bDQI6KrZd0PpRGqyYoT4vn16Ipm/f6pOpH5PNS6sdImzeYtK
tONa4WAf88GRL0o0QgW/nn7pBL88MVFNaRYaQlowSUzIzPLrMLPlLg==
=9GSE
-END PGP SIGNATURE-

Bug#933248: RFS: assaultcube/1.2.0.2-1 [ITA] -- realistic first-person-shooter

[Tobias Frost]

On Wed, Jul 31, 2019 at 11:42:23PM -0300, Carlos Donizete Froes wrote:
> Hi Tobias,
> 
> > I've took a look and I have to say assultcube's license is a nightmere;
> > for me it is far from clear from me what they mean… However, I cannot
> > see a change on the licensing, so I guess the situation is unchanged
> > and that would hint that we are still talking about non-free, at least
> > for the data.
> 
> I agree, there was no change in the license, so I left it as it was in the
> orphaned package. I just organized 'debian/copyright' by adding all licenses
> presented in the game directories.
> 
> > For example, what is source in their definition? I can only assume that
> > they mean the"sources.tar.gz" [1] on the release tab of their github
> > repo. If that is true, there quite a lots of difference when compared
> > to (what I guess is supposed to be in their terms) the game package
> > labeled "AssaultCube for Linux" [2]
> 
> The game is being mirrored in an 'experimental' branch [1], to be played on
> Windows and MacOSX with the updated SDL2 library.

/me confused. The dsc labels it as version 1.2.0.2, which is an
officially released version by upstream [a]. That somehow collided with 
"mirrored in an 'experimental' branch" as you wrote above.
Comparing the content of the dsc and the release from [a] shows 
differences (more files in the dsc). 
So it seems that this is not 1.2.0.2 you are packaging.

And here things become to become complicated againm, as this license is
really a f***up: They say:
- source code is licensed under zlib like license. Ok, but what is
  excatly the source? I can only guess that this is [1], but that guess
  needs a released version to work.
- Even the file marked as source ([1]) has non-free bits in it, so I
  guess it is not valid to say "this is the source". 
- the "packaged" file license says that you cannot modify the package,
  but says later that you might disect the package and ship the parts
  seperately, but only if it has a license attached to it explictily.
  Seems so that this is not in the case for every file…

So, I'm sorry, I think I am unable to help on this licensing monster.

I guess the fine people @ debian-legal might be more of an help here...
Or ask upstream for clarifcation. Or you use the same approach as the
old package did: split in engine and data. That has passed ftpmasters at
least, so I guess it is fine.

(What I probably would do is to stick to the released version.)

[a] https://github.com/assaultcube/AC/releases/tag/v1.2.0.2

> With that, I just removed the directory containing prebuilt Windows binary
> sources and some Makefile fixes to create the game binary.

What was the base of the removal? [1] or where?

> 
> > [2] has many MiB more files than [1], so I guess [1] is not sufficient
> > to play, is it?
> 
> No, this package is the complete game to play. ;) 

The dsc has more files in it than [1]…

> 
> > If I'm correct, the problem is that [2] is "no modification allowed", 
> > "non commerical" and they are clear that there are bits in it that may
> > only distributed "unmodified" (in their definition) [3]. So this still
> > looks non-free for me. 
> > 
> > [1] https://github.com/assaultcube/AC/archive/v1.2.0.2.tar.gz
> > [2] h
> > ttps://github.com/assaultcube/AC/releases/download/v1.2.0.2/AssaultCube_v1.2.0
> > .2.tar.bz2
> > 
> > [3] https://assault.cubers.net/docs/license.html
> > together with the README.md on https://github.com/assaultcube/AC
> > 
> > 
> > PS: On [3] they mention ./packages/audio/misc/pickup_armour.ogg --
> > as licensed under "Creative Commons Sampling Plus 1.0", which is
> > unfortunatly a non-free license [4]. This alone makes it non-free.
> > 
> > [4] 
> > https://wiki.debian.org/DFSGLicenses#Creative_Commons_Sampling_Plus_.28CC-sampling.2B-.29.2C_v1.0
> 
> Exactly, in this case would the game have to be 'non-free' rather than
> 'contrib'?

At least assaultcube-data needs to go to non-free. The engine could go
to contrib if everything required for it it is free software. 

I strongly suggest that you use keep old packaging scheme (two source
packages, assaultcube and assaultcube-data)

I'm not sure at all if putting the data on a git repository would
violate their license. (it is not unmodified distribution then)

Srry, I think I have to throw in towel for that package…
Please seek advice from debian-legal.

> [1] https://github.com/assaultcube/AC/tree/experimental
> 
> Thanks!
> 
> -- 
> ⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
> ⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
> ⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
> ⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

-- 
tobi

Bug#933680: DHCP 'option overload' must be supported

[ltspro2]

Package: pump
Version: 0.8.24-7.1
Severity: normal

Currently pump recognizes but ignores DHCP_OPTION_OVERLOAD. According to
RFC2131, clients MUST interpret the 'file' and 'sname' fields as DHCP
options if 'option overload' indicates so.

Bug#933679: qpsmtpd: No Received header if received_hook configured

[Peter J. Holzer]

Package: qpsmtpd
Version: 0.94-4
Severity: normal

Dear Maintainer,

the qpsmtpd included in Debian Buster doesn't handle the received hook
correctly. Instead of prepending the line to the headers it is returned
to the caller (which means that no Received header is added at all).

I will send a patch shortly.

(I think this was also present in Debian Stretch, and I will check
upstream next.)

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

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

Versions of packages qpsmtpd depends on:
ii  adduser  3.118
ii  debconf  1.5.71
ii  libclamav-client-perl0.11-2
ii  libdigest-hmac-perl  1.03+dfsg-2
ii  libio-socket-inet6-perl  2.72-2
ii  libipc-shareable-perl0.61-2
ii  libmail-spf-perl 2.9.0-4
ii  libmailtools-perl2.18-1
ii  libnet-dns-perl  1.19-1
ii  libsocket6-perl  0.29-1+b1
ii  lsb-base 10.2019051400
ii  perl 5.28.1-6
ii  perl-modules-5.24 [libnet-perl]  5.24.1-3+deb9u5

qpsmtpd recommends no packages.

Versions of packages qpsmtpd suggests:
pn  clamav-daemon 
pn  libnet-ldap-perl  
ii  spamassassin  3.4.2-1
pn  tinycdb   

-- Configuration Files:
/etc/qpsmtpd/badmailfrom changed [not included]
/etc/qpsmtpd/logging changed [not included]
/etc/qpsmtpd/plugins changed [not included]

-- debconf information excluded

Bug#933678: new upstream release (1.0~alpha2)

[Daniel Baumann]

Package: inkscape
Version: 1.0~alpha1-1
Severity: wishlist

Hi,

it would be nice if you could upgrade to 1.0~alpha2 in experimental.

Regards,
Daniel

Bug#933677: Non-conformant value of "Maximum DHCP Message Size" option

[ltspro2]

Control: retitle -1 Non-conformant value of "Maximum DHCP Message Size"
option

Bug#933677:

[ltspro2]

Control: retitle -1 Non-conformant value of "Maximum DHCP Message Size"
option

Bug#933609: How hard it is to find the Date of a package

[Boyuan Yang]

在 2019-08-02五的 02:24 +0800，積丹尼 Dan Jacobson写道：
> Let's look at a typical "Download" page,
> https://www.apkmirror.com/apk/couchsurfing-inc/couchsurfing-travel-app/couchsurfing-travel-app-4-26-0-release/#downloads
> as we see dates are of utmost importance.
> 
> Wherever we see a version number, we see a date.
> 
> In fact I'm sure you would be hard pressed to find any website that
> doesn't (except https://www.google.com/earth/versions/#download-pro ).
> 
> So I'm saying that the Debian website should "cough up the date",
> yes, "even if it is not the right date", just some date, any date, and
> put it more clearly on the trail of what the user sees after Googling a
> package.
> 
> I mean there are the MD5 sums, etc. down to the exact byte count, etc.
> but no indication of if the package was updated last year, or before the
> NASA moon voyages.
> 
> Those apt tools are great, but let's have the website cough up some
> dates better too.


Personally I'm not against adding dates at all. The fact is that the
development of packages.debian.org website (not tracker.debian.org) is long
stalled and it needs some more manpower. It would be great if any kind of
patches could emerge.


Thanks,
Boyuan Yang


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

Bug#933677: Buffer overflow during processing of large server replies in "pump"

[ltspro2]

Package: pump
Version: 0.8.24-7.1
Severity: normal

This daemon sends "Maximum DHCP Message Size" option with a value equal to
sizeof(struct bootpRequest) but "the minimum legal value is 576 octets"
according to RFC2132 (i.e., it should include not only sizeof(struct
bootpRequest) but also size of IP and UDP headers).

Bug#933609: How hard it is to find the Date of a package

[積丹尼 Dan Jacobson]

Let's look at a typical "Download" page,
https://www.apkmirror.com/apk/couchsurfing-inc/couchsurfing-travel-app/couchsurfing-travel-app-4-26-0-release/#downloads
as we see dates are of utmost importance.

Wherever we see a version number, we see a date.

In fact I'm sure you would be hard pressed to find any website that
doesn't (except https://www.google.com/earth/versions/#download-pro ).

So I'm saying that the Debian website should "cough up the date",
yes, "even if it is not the right date", just some date, any date, and
put it more clearly on the trail of what the user sees after Googling a
package.

I mean there are the MD5 sums, etc. down to the exact byte count, etc.
but no indication of if the package was updated last year, or before the
NASA moon voyages.

Those apt tools are great, but let's have the website cough up some
dates better too.

Bug#933676: openjdk-11-jre-dcevm: openjdk-11-jre-dvecm doesn't include the hotswap agent

[Michael Meier]

Package: openjdk-11-jre-dcevm
Version: 11.0.3+1-1
Severity: normal

according to http://hotswapagent.org and https://github.com/TravaOpenJDK/trava-
jdk-11-dcevm/ the java 11 dvecm version is supposed to include the
hotswapagent.
This package here doesn't do so. Would be great if it also could include it. So
the tutorials/manuals on the web work directly.



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (900, 'stable'), (700, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages openjdk-11-jre-dcevm depends on:
ii  libc62.28-10
ii  openjdk-11-jre-headless  11.0.4+11-1~deb10u1

openjdk-11-jre-dcevm recommends no packages.

openjdk-11-jre-dcevm suggests no packages.

-- no debconf information

Bug#931825: Dub executable does not run

[Matthias Klumpp]

clone 931825 -1
reassign -1 gdc-8 8.3.0-6
retitle -1 gdc-8: Unable to link D applications against runtime/stdlib
thankyou

This issue is actually bigger than I thought You currently can't
even rebuild dub with GDC, because the linking step fails when linking
against Phobos/DRuntime:
```
gdc -Wall -obin/dub -fversion=DubUseCurl -Isource
-Wl,--push-state,--no-as-needed -lcurl -lz -Wl,--pop-state
@build-files.txt

/usr/bin/ld: /tmp/ccoCvOX1.o: in function
`_D3dub11commandline17runDubCommandLineFAAyaZi':
app.d:(.text+0x797): undefined reference to
`_D3std5stdio23__T10makeGlobalS5stdinZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: /tmp/ccoCvOX1.o: in function
`_D3dub11commandline15DustmiteCommand7executeMFC3dub3dub3DubAAyaAAyaZi':
app.d:(.text+0x11098): undefined reference to
`_D3std5stdio23__T10makeGlobalS5stdinZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: app.d:(.text+0x110cf): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stdoutZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: app.d:(.text+0x11106): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stderrZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: /tmp/ccoCvOX1.o: in function
`_D3dub3dub3Dub13convertRecipeMFAyabZv':
app.d:(.text+0x2631e): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stdoutZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: /tmp/ccoCvOX1.o: in function
`_D3dub9compilers8compiler8Compiler10invokeToolMFAAyaDFiAyaZvZv':
app.d:(.text+0x6463f): undefined reference to
`_D3std5stdio23__T10makeGlobalS5stdinZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: app.d:(.text+0x64676): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stdoutZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: app.d:(.text+0x646ad): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stderrZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: /tmp/ccoCvOX1.o: in function
`_D3dub10generators5build14BuildGenerator16performRDMDBuildMFS3dub10generators9generator17GeneratorSettingsKS3dub9compilers13buildsettings13BuildSettingsxC3dub8package_7PackageAyaJS3dub8internal10vibecompat4inet4path10NativePathZv':
app.d:(.text+0x72999): undefined reference to
`_D3std5stdio23__T10makeGlobalS5stdinZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: app.d:(.text+0x729d0): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stdoutZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: app.d:(.text+0x72a07): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stderrZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: /tmp/ccoCvOX1.o: in function
`_D3dub10generators5build14BuildGenerator9runTargetMFS3dub8internal10vibecompat4inet4path10NativePathxS3dub9compilers13buildsettings13BuildSettingsAAyaS3dub10generators9generator17GeneratorSettingsZv':
app.d:(.text+0x7690b): undefined reference to
`_D3std5stdio23__T10makeGlobalS5stdinZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: app.d:(.text+0x76942): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stdoutZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: app.d:(.text+0x76979): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stderrZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: /tmp/ccoCvOX1.o: in function
`_D3dub8internal5utils11runCommandsFxAAyaHAyaAyaZv':
app.d:(.text+0x9ed61): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stdoutZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: app.d:(.text+0x9ed8c): undefined reference to
`_D3std5stdio24__T10makeGlobalS6stderrZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: app.d:(.text+0x9f026): undefined reference to
`_D3std5stdio23__T10makeGlobalS5stdinZ10makeGlobalFNbNcNdNiZS3std5stdio4File'
/usr/bin/ld: /tmp/ccoCvOX1.o: in function
`_D4core8internal4hash15__T6hashOfTAyaZ6hashOfFNaNbNiKAyamZm':
app.d:(.text._D4core8internal4hash15__T6hashOfTAyaZ6hashOfFNaNbNiKAyamZm[_D4core8internal4hash15__T6hashOfTAyaZ6hashOfFNaNbNiKAyamZm]+0x41):
undefined reference to `_D4core8internal4hash9bytesHashFNaNbNiPxvmmZm'
/usr/bin/ld: /tmp/ccoCvOX1.o: in function
`_D4core8internal4hash15__T6hashOfTAxaZ6hashOfFNaNbNiKAxamZm':
app.d:(.text._D4core8internal4hash15__T6hashOfTAxaZ6hashOfFNaNbNiKAxamZm[_D4core8internal4hash15__T6hashOfTAxaZ6hashOfFNaNbNiKAxamZm]+0x41):
undefined reference to `_D4core8internal4hash9bytesHashFNaNbNiPxvmmZm'
[]
collect2: error: ld returned 1 exit status
```

Something is wrong with either the compiler, or the standardlibrary
(gphobos) and runtime (druntime) don't export some expected symbols.

I cloned this issue because this first needs to be fixed in GCC, and
then dub will still likely need a rebuild anyway.

Cheers,
Matthias

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

Bug#932492: Fix description and upstream

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: commit-helper
  Version : 3.4.18
  Upstream Author : Andre Filho 
* URL : https://github.com/andre-filho/commit-helper
* License : GPL-3
  Programming Lang: Python
  Description : Helps you create and maintain your commit policy

The commit-helper do exactly what it's name suggest: helps you create
and maintain your git commit policy by tailoring your commit message
into a commit convention.

Bug#933674: Buffer overflow during processing of large server replies in "pump"

[ltspro2]

Package: pump
Version: 0.8.24-7.1
Severity: grave
Tags: security

There is a missing check in source file dhcp.c, function
handleTransaction(), line 958 when copying body of the server response to
struct bootpRequest bresp. Ethernet packet length can be greater than
sizeof(*bresp) == 548 but handleTransaction() only checks (line 914) that
j - sizeof (*ipHdr) - sizeof (*udpHdr) is non-negative. This allows
attacker to overwrite up to ETH_FRAME_LEN - sizeof(*ipHdr) -
sizeof(*udpHdr) - sizeof(*bresp) bytes of the stack memory. If compiler
hardening is disabled then this vulnerability can lead to execution of
arbitrary code. I am not sure whether this is practically exploitable when
"-fstack-protector" is enabled.

I suggest applying the attached patch, however it is not tested.--- dhcp.c	2019-03-01 00:00:00.0 +
+++ dhcp.c	2019-07-30 00:00:00.0 +
@@ -946,6 +946,13 @@ static char * handleTransaction(int s, s
 		continue;
 	if (udpHdr->dest != bootp_client_port) 
 		continue;
+
+	/* Relevant responses cannot exceed sizeof (*bresp) due to
+	   the value of DHCP_OPTION_MAXSIZE being set to it in our
+	   requests. */
+	if (j - sizeof (*ipHdr) - sizeof (*udpHdr) > sizeof (*bresp))
+		continue;
+
 	/* Go on with this packet; it looks sane */
 
 	  /* Originally copied sizeof (*bresp) - this is a security

Bug#933673: RM: muse-el [all] -- ROM; NBS; obsolete dummy transitional package to elpa-muse

[Nicholas D Steeves]

Package: ftp.debian.org
Severity: normal


Hi,

Please clean up the obsolete dummy transitional bin:muse-el arch:all
package (but not src:muse-el).

Thanks!
Nicholas

Bug#931825: Dub executable does not run

[Matthias Klumpp]

Am Do., 1. Aug. 2019 um 17:15 Uhr schrieb Andreas Ronnquist :
>
> severity 931825 grave
> thanks
>
> On Thu, 11 Jul 2019 00:12:56 +0300 Jussi Pakkanen 
> wrote:
> > Package: dub
> > Version: 1.12.1-1
> >
> > Installing dub on Debian unstable (tested on x86 and x64) and then
> > running "dub" errors out immediately with the following error message:
> >
> > dub: symbol lookup error: dub: undefined symbol: _Dstd5stdio_ > name of mangled symbol>.
> >
> >
>
> I run into similar problems when simply running dub:
>
> dub: symbol lookup error: dub: undefined symbol: 
> _D4core8internal4hash9bytesHashFNaNbNiPxvmmZm
>
> Also, the build system of the package lix is affected, see
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925769
>
> (That one is reported as it affect gcc-9 only, but I run into it on a
> standard unstable machine).

This happens if a programming language has no stable ABI...
I'm on it, a rebuild should be sufficient.

Cheers,
Matthias

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

Bug#933386: ncurses-term: Packaged alacritty terminfo file conflicts with official one

[Sven Joachim]

Control: severity -1 wishlist

On 2019-07-30 13:25 +0800, Ryan Lue wrote:

> Package: ncurses-term
> Version: 6.1+20190713-1
> Severity: important
>
> Dear Maintainer,
>
> The latest version of this package bundles a terminfo file for the
> alacritty terminal emulator (/usr/share/terminfo/a/alacritty).
> This terminfo file is also provided by the official alacritty repo,
> when built and installed with cargo-deb:
>
> $ cargo deb --install --manifest-path alacritty/Cargo.toml
> ...
> Preparing to unpack .../alacritty_0.3.3_amd64.deb ...
> Unpacking alacritty (0.3.3) ...
> dpkg: error processing archive 
> /home/rlue/tmp/alacritty/target/debian/alacritty_0.3.3_amd64.deb (--install):
>  trying to overwrite '/usr/share/terminfo/a/alacritty', which is also in 
> package ncurses-term 6.1+20190713-1
> Processing triggers for mime-support (3.62) ...
> Errors were encountered while processing:
>  /home/rlue/tmp/alacritty/target/debian/alacritty_0.3.3_amd64.deb
> cargo-deb: installation failed, because dpkg -i returned error
>
> I am not sure whether this constitutes an issue in the official
> ncurses-term debian package or in alacritty’s cargo-deb packaging
> configuration, but I am assuming it is the former. In any case, I have
> filed an issue on alacritty’s GitHub tracker for cross-referencing
> purposes:
>
> https://github.com/jwilm/alacritty/issues/2685

As mentioned by Christian Duerr in that bug report, this is not a bug in
ncurses-term, since we cannot possibly monitor random github
repositories.  In any case, it has been agreed that alacritty's .deb
needs to move its file out of the way.  Once that has been accomplished,
I will probably add a versioned Replaces on alacritty to ncurses-term so
that other users do not stumble upon this issue.

In the meantime, you can

- add a diversion for the conflicting file so that ncurses-term and
  alacritty can peacefully coexist:

# dpkg-divert --package ncurses-term --rename --add 
/usr/share/terminfo/a/alacritty

- test the patch which I pushed to github[1] and comment on the issue
  you opened.

Cheers,
   Sven


1. 
https://github.com/zwenna/alacritty/commit/95982960f61f160b05cbb49185dfc2788eb40a8a

Bug#926401: initramfs-tools: update-initramfs -k all -c does not create initrd images anymore

[Ben Hutchings]

On Thu, 2019-08-01 at 17:01 +0200, Marc Lehmann wrote:
[...]
> I always wondered why initramfs has its own system -
> although I guess that debian doesn't have a "canonical" way to enumerate
> kernels, so it's not clear what the right mehtod is.
> 
> BTW, my workaorund just iterates over /boot/vmlinuz-* to find kernel
> versions - that's probably not the best method :)

I introduced the "linux-version" command some years back for precisely
this purpose.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?




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

Bug#933665: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes

[Gerald Turner]

On Thu, Aug 01 2019, Colin Watson wrote:
> This is the scenario explained in the entry in
> /usr/share/doc/openssh-server/NEWS.Debian.gz for version 1:7.8p1-1,
> which was reproduced from upstream's release notes for OpenSSH 7.8:
>
>* sshd(8): The semantics of PubkeyAcceptedKeyTypes and the similar
>  HostbasedAcceptedKeyTypes options have changed.  These now
>  specify signature algorithms that are accepted for their
>  respective authentication mechanism, where previously they
>  specified accepted key types.  This distinction matters when
>  using the RSA/SHA2 signature algorithms "rsa-sha2-256",
>  "rsa-sha2-512" and their certificate counterparts.
>  Configurations that override these options but omit these
>  algorithm names may cause unexpected authentication failures (no
>  action is required for configurations that accept the default for
>  these options).

Oh shame on me - I thought I read the NEWS items (with apt-listchanges
helpfully emailing them to me), but not carefully enough.  Sorry for the
bogus bug report.

Long ago (during stretch) I adopted the OpenSSH certifcate/CA model:

  PubkeyAcceptedKeyTypes ssh-ed25519-cert-...@openssh.com

...which I believe is SHA-256, yet the configuration was unaffected by
the change in 7.8, otherwise I would've noticed a long while back on
personal workstations running Debian testing.

> I regret the inconvenience of the change, but given that it seems to
> have been a deliberate change upstream (mentioned in their release
> notes), I think it would be best to adapt to it.
>
> The debug output you quote is indeed a bit misleading (I think I'll
> take that up with upstream), but there's a clue hiding in the
> successful debug output:
>
>   sshd[20199]: debug1: userauth_pubkey: test pkalg rsa-sha2-512 pkblob RSA 
> SHA256:cN6+RJMBj25zximZ28B/CanFpjupWf/ABGrRGprS1LU [preauth]
>
> Note that the default for PubkeyAcceptedKeyTypes now ends with
> "rsa-sha2-512,rsa-sha2-256,ssh-rsa" rather than just "ssh-rsa".
> Therefore, things should work again if you set "PubkeyAcceptedKeyTypes
> rsa-sha2-512,rsa-sha2-256,ssh-rsa".  Let me know if that works?

Yep it makes sense.

BTW, if you take the debug output up with upstream, maybe also consider
that there's no "ssh -Q key" or similar command that'll reveal the
values that can be supplied to PubkeyAcceptedKeyTypes.

  $ ssh -Q key
  ssh-ed25519
  ssh-ed25519-cert-...@openssh.com
  ssh-rsa
  ssh-dss
  ecdsa-sha2-nistp256
  ecdsa-sha2-nistp384
  ecdsa-sha2-nistp521
  ssh-rsa-cert-...@openssh.com
  ssh-dss-cert-...@openssh.com
  ecdsa-sha2-nistp256-cert-...@openssh.com
  ecdsa-sha2-nistp384-cert-...@openssh.com
  ecdsa-sha2-nistp521-cert-...@openssh.com

...that's one of the first things I checked when dealing with the issue.

Thanks for the clarification!

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D


signature.asc
Description: PGP signature

Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd

[Gerald Turner]

On Thu, Aug 01 2019, Philipp Huebner wrote:
> your issue was fixed upstream, could you please try
> https://apt.debalance.de/pool/main/e/erlang-p1-pkix/erlang-p1-pkix_1.0.0-3+deb10u1_amd64.deb
>
> and report back if this solves your problem?

Awesome!  Problem solved.  My temporary OpenSSL-signed certificate has
now been thrown out, yay!

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D


signature.asc
Description: PGP signature

Bug#933672: transition: cfitsio

[Aurelien Jarno]

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

I would like to request a transition slot for cfitsio, changing the
library name from libcfitsio7 to libcfitsio8. The API has only been
extended, not changed, so I don't expect any big issue.

Due to a mistake on my side with sbuild, I wrongly uploaded the package
to sid instead of experimental. The distribution in the changelog is
experimental, but the one in the changes file is sid... Sorry about
that.

If it is not possible to proceed with the transition in the next days,
I'll just reupload the previous version with +really to sid.

Ben file:

title = "cfitsio";
is_affected = .depends ~ "libcfitsio7" | .depends ~ "libcfitsio8";
is_good = .depends ~ "libcfitsio8";
is_bad = .depends ~ "libcfitsio7";

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

Bug#932192: nano: More color, and Better default options

[Benno Schulenberg]

Op 31-07-19 om 10:58 schreef Bardot Jérôme:
> The first i have in mind are .ctp files from cakephp (which are php
> files)

So, basically you're asking that the PHP syntax should also be
activated when a filename has a .ctp extension?

> but also for twig files.

What are twig files?  ...  I'm guessing you are referring to:
  https://en.wikipedia.org/wiki/Twig_(template_engine)

You will have to enumerate exactly which filename extensions you
wish to be recognized as PHP files, because I have zero knowledge
of the PHP ecosystem.

> (if i remember well cuda/(opencl maybe) 
> is missing in c/c++ file )

Sorry, I don't understand what you mean here.

> Not include certain just broke others (sometimes).

I cannot parse this.

> I currently have to manage several server and it’s just a pain to have
> to add the -c option all the time.

Why not make an alias: alias nano="nano --line --soft"?

(By the way, the short option for line numbers is -l, not -c;
-c is for constantly showing the cursor position.)

Why not make or upload a .nanorc file for the relevant user?

Benno

Bug#772928: texlive-latex-base: pdflatex manpage misses docs about synctex option

[Hilmar Preuße]

Am 01.08.2019 um 00:16 teilte Hilmar Preuße mit:
> Am 12.12.2014 um 10:37 teilte Olivier Berger mit:

Hi Norbert,

>> FWIW, pdflatex manpage misses documentation about the -synctex option.
>>
> hille@debian-amd64-sid:~$ zless -X /usr/share/man/man1/pdflatex.1.gz
> .so man1/pdftex.1
> 
> ...points to the pdftex manual page, which is located in texlive-binaries.
> 
> Reassigning.
> 
I've created a small patch, which add the missing option. Should I
commit it to our repo and later submit to upstream?

Further: there is a little contradiction regarding formatting the
options between "pdftex --help" and the manual page.

pdftex(1):

   -fmt format
Use format as the name of the format to be used, instead of
the name by which pdfTeX was called or a %& line.

"pdftex --help":

-fmt=FMTNAMEuse FMTNAME instead of program name or a %& line

i.e. with or without = . Do you know which one is correct or are both
accepted?

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



signature.asc
Description: OpenPGP digital signature

Bug#933665: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes

[Colin Watson]

On Thu, Aug 01, 2019 at 08:32:54AM -0700, Gerald Turner wrote:
> I've been running several servers, upgraded across many Debian stable
> releases, with sshd_config that had been tightened down in various ways
> (example attached) including explicit PubkeyAcceptedKeyTypes (containing
> ssh-rsa).  After upgrading to buster a user reported that he could no
> longer login with his RSA key.
> 
>   sshd[17025]: userauth_pubkey: key type ssh-rsa not in 
> PubkeyAcceptedKeyTypes [preauth]
> 
> I tested and found that explicitly defining PubkeyAcceptedKeyTypes in
> sshd_config breaks RSA pubkey auth, even when the line merely states:
> 
>   PubkeyAcceptedKeyTypes ssh-rsa

This is the scenario explained in the entry in
/usr/share/doc/openssh-server/NEWS.Debian.gz for version 1:7.8p1-1,
which was reproduced from upstream's release notes for OpenSSH 7.8:

   * sshd(8): The semantics of PubkeyAcceptedKeyTypes and the similar
 HostbasedAcceptedKeyTypes options have changed.  These now specify
 signature algorithms that are accepted for their respective
 authentication mechanism, where previously they specified accepted key
 types.  This distinction matters when using the RSA/SHA2 signature
 algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate
 counterparts.  Configurations that override these options but omit
 these algorithm names may cause unexpected authentication failures (no
 action is required for configurations that accept the default for these
 options).

I regret the inconvenience of the change, but given that it seems to
have been a deliberate change upstream (mentioned in their release
notes), I think it would be best to adapt to it.

The debug output you quote is indeed a bit misleading (I think I'll take
that up with upstream), but there's a clue hiding in the successful
debug output:

  sshd[20199]: debug1: userauth_pubkey: test pkalg rsa-sha2-512 pkblob RSA 
SHA256:cN6+RJMBj25zximZ28B/CanFpjupWf/ABGrRGprS1LU [preauth]

Note that the default for PubkeyAcceptedKeyTypes now ends with
"rsa-sha2-512,rsa-sha2-256,ssh-rsa" rather than just "ssh-rsa".
Therefore, things should work again if you set "PubkeyAcceptedKeyTypes
rsa-sha2-512,rsa-sha2-256,ssh-rsa".  Let me know if that works?

-- 
Colin Watson   [cjwat...@debian.org]

Bug#693230: Bug#806572: RFS: multimail/0.50~20150922-1 [ITA]

[Fernando Toledo]

Hi people!

I'm working on version 0.52

https://github.com/ftoledo/pkg-multimail

I upload to mentors:
https://mentors.debian.net/package/multimail

I see that the package is orphaned, i can adopt it, but i'm not DD, how
to can i help and procced to upload to unstable?

Thanks!

-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar



signature.asc
Description: OpenPGP digital signature

Bug#933671: RFS: multimail/0.52-1

[Fernando Toledo]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: multimail
   Version : 0.52-1
   Upstream Author : MultiMail was originally developed under Linux by
Kolossvary Tamas and Toth Istvan. John Zero was the maintainer for
versions 0.2 through 0.6; since version 0.7, the maintainer is William
McBrine wmcbr...@gmail.com

 * URL : https://github.com/wmcbrine/MultiMail
 * License : GPL-3
   Section : mail

  It builds those binary packages:

multimail - Offline reader for Blue Wave, QWK, OMEN and SOUP

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/m/multimail/multimail_0.52-1.dsc

  More information about multimail can be obtained from

  http://wmcbrine.com/mmail/

  Changes since the last upload:

  adjust patch and build version 0.52

  https://github.com/ftoledo/pkg-multimail/blob/master/debian/changelog

  Muchas gracias!

-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

Bug#933670: ITP: python-alignlib -- edit and hamming distance computation

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-alignlib
  Version : 0.1.1
* URL : https://github.com/marcelm/alignlib
* License : MIT
  Programming Lang: C and Python
  Description : edit and hamming distance computation

Team maintained on https://salsa.debian.org/med-team/python-alignlib

Bug#933669: openjfx: Starting a java-jfx application with java --module-path=/usr/share/java/ --add-modules=javafx.controls -jar app.jar results in the error: Error occurred during initialization of b

[Lars Mucha]

Package: openjfx
Version: 11.0.2+1-1
Severity: normal

Dear Maintainer,

I upgraded from stretch to buster last week and now I am unable the start a 
java application which uses jfx-classes.

With openjdk-8 the application was starte with

java -jar app.jar

Now I need to add 2 parameters to tell java, where the jfx-files are to find:

java --module-path=/usr/share/java/ --add-modules=javafx.controls -jar app.jar

The result is the following error:

Error occurred during initialization of boot layer
java.lang.module.FindException: Two versions of module javafx.swing found in 
/usr/share/java (javafx-swing-11.jar and javafx-swing.jar)

My current workaround is, to copy only the jar-files, not the symbolic links, 
to another directory and give the new directory to the java command line. After 
every update of the jfx-classes the files has to copied again.

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

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

Versions of packages openjfx depends on:
ii  libopenjfx-java  11.0.2+1-1

Versions of packages openjfx recommends:
pn  openjfx-source  

openjfx suggests no packages.

-- no debconf information

Bug#926642: [dvipdfmx] dvipdfmx ignores "-m" option

[Hilmar Preuße]

Control: forwarded 926642 https://tug.org/pipermail/dvipdfmx/

Am 01.08.2019 um 05:57 teilte Akira Kakuto mit:

>> dvipdfmx in texlive-binaries_2018.20180907.48586 works well with>> "-m 
>> option". However, dvipdfmx in texlive-binaries_2018.20181104.49075
>> and
>> later ignores "-m option".
> 
> Thanks for the report. Confirmed.
> The author will fix it this weekend.
> 
Marking forwarded.

Yeah: below 50 unhandled Normal bugs for debian-tex-maint.

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



signature.asc
Description: OpenPGP digital signature

Bug#933499: libreoffice-base: database form with subform no longer works with "Data content could not be loaded" error

[Rene Engelhard]

Hi again,

On Thu, Aug 01, 2019 at 12:04:58AM +0200, Rene Engelhard wrote:
> On Wed, Jul 31, 2019 at 04:00:04PM -0500, william l-k wrote:
> >have linked sub-forms from two seperate tables for entering related data.
> >One of the databases started out as a libreoffice base then was converted
> >to a mariadb connection. The other started out as a connection to 
> > mariadb.

Maybe it's not related at all but connection to mariadb how? MySQL ODBC?
MySQL JDBC? (both of which are removed because being buggy), MariaDB
JDBC? Or libreoffice-mysql-connector?

If the latter, 5.2 removed the extension and need for libmysqlcppconn
but integrated it properly into the "main" packages
(libreoffice-sdbc-mysql), just using lib{mariadb,mysql}client/libmariadb
properly.

Maybe it's related to one of those?

Regards,
 
Rene

Bug#933668: Doesn't build against libecal-2.0

[Iain Lane]

Package: src:almanah
Version: 0.11.1-2
Severity: wishlist
Tags: patch upstream

Control: block 933577 by -1

Hi,

This is in experimental-NEW at the minute, but you can grab the packages
out of evolution-data-server Vcs-Git to test this. tl;dr is that ecal
broke API with this release. There are patches upstream which I grabbed
and applied to the Debian package (untested though). Diff attached for
you to review. If you wanted to upload to experimental now that would be
OK, or you can wait until we're ready to go to unstable - at which point
I'll raise the severity of this bug.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
diff -Nru almanah-0.11.1/debian/changelog almanah-0.11.1/debian/changelog
--- almanah-0.11.1/debian/changelog 2018-03-26 17:21:29.0 +0100
+++ almanah-0.11.1/debian/changelog 2019-08-01 17:21:20.0 +0100
@@ -1,3 +1,18 @@
+almanah (0.11.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * events-Removed-Evolution-runtime-dependency.patch,
+trivial-Fixed-indentation.patch,
+event-factories-Port-to-libecal-2.0.patch,
+data-Updated-the-AppData-format.patch,
+Update-the-AppData-file-to-version-0.7.patch,
+Add-a-missing-tag-to-the-AppData-file.patch,
+libecal-2.0:
+Backport a load of patches from upstream to enable building against
+libecal-2.0.
+
+ -- Iain Lane   Thu, 01 Aug 2019 17:21:20 +0100
+
 almanah (0.11.1-2) unstable; urgency=medium
 
   * Increase Priority to optional. Priority: extra is deprecated
diff -Nru almanah-0.11.1/debian/control almanah-0.11.1/debian/control
--- almanah-0.11.1/debian/control   2018-01-05 08:46:04.0 +
+++ almanah-0.11.1/debian/control   2019-08-01 16:56:47.0 +0100
@@ -2,15 +2,17 @@
 Section: gnome
 Priority: optional
 Maintainer: Angel Abad 
-Build-Depends: debhelper (>= 9),
- autotools-dev,
+Build-Depends: appstream-util,
+ debhelper (>= 9),
+ dh-autoreconf,
+ gnome-common,
  intltool (>= 0.35.0),
  libglib2.0-dev,
  libgtk-3-dev (>= 3.5.6),
  libsqlite3-dev,
  libcryptui-dev (>= 3.0.0),
  libgpgme11-dev,
- libecal1.2-dev (>= 3.6.0),
+ libecal2.0-dev,
  libedataserver1.2-dev (>= 3.6.0),
  libgtkspell3-3-dev
 Standards-Version: 3.9.6
diff -Nru 
almanah-0.11.1/debian/patches/Add-a-missing-tag-to-the-AppData-file.patch 
almanah-0.11.1/debian/patches/Add-a-missing-tag-to-the-AppData-file.patch
--- almanah-0.11.1/debian/patches/Add-a-missing-tag-to-the-AppData-file.patch   
1970-01-01 01:00:00.0 +0100
+++ almanah-0.11.1/debian/patches/Add-a-missing-tag-to-the-AppData-file.patch   
2019-08-01 17:11:39.0 +0100
@@ -0,0 +1,22 @@
+From 9c94abafe29415dbac1b6460af17c5af254e5859 Mon Sep 17 00:00:00 2001
+From: Richard Hughes 
+Date: Mon, 25 Jan 2016 15:12:21 +
+Subject: [PATCH] Add a missing tag to the AppData file
+
+---
+ data/almanah.appdata.xml.in | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/data/almanah.appdata.xml.in b/data/almanah.appdata.xml.in
+index df93a75..d50f20c 100644
+--- a/data/almanah.appdata.xml.in
 b/data/almanah.appdata.xml.in
+@@ -31,4 +31,5 @@
+ AppMenu
+ ModernToolkit
+   
++  almanah
+ 
+-- 
+2.20.1
+
diff -Nru almanah-0.11.1/debian/patches/data-Updated-the-AppData-format.patch 
almanah-0.11.1/debian/patches/data-Updated-the-AppData-format.patch
--- almanah-0.11.1/debian/patches/data-Updated-the-AppData-format.patch 
1970-01-01 01:00:00.0 +0100
+++ almanah-0.11.1/debian/patches/data-Updated-the-AppData-format.patch 
2019-08-01 17:13:02.0 +0100
@@ -0,0 +1,26 @@
+From 45971f9b492b366989ae0afd89243218be9b5fb1 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?=C3=81lvaro=20Pe=C3=B1a?= 
+Date: Sat, 7 Mar 2015 20:54:43 +0100
+Subject: [PATCH] data: Updated the AppData format
+
+Included the fields "name" and "summary".
+---
+ data/almanah.appdata.xml.in | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/data/almanah.appdata.xml.in b/data/almanah.appdata.xml.in
+index 17a0a7d..31db07d 100644
+--- a/data/almanah.appdata.xml.in
 b/data/almanah.appdata.xml.in
+@@ -4,6 +4,8 @@
+   almanah.desktop
+   CC0-1.0
+   GPL-3.0+
++  Almanah Diary
++  <_summary>Keep a diary of your life
+   
+ <_p>
+   Almanah Diary is an application to allow you to keep a diary of your 
life.
+-- 
+2.20.1
+
diff -Nru 
almanah-0.11.1/debian/patches/event-factories-Port-to-libecal-2.0.patch 
almanah-0.11.1/debian/patches/event-factories-Port-to-libecal-2.0.patch
--- almanah-0.11.1/debian/patches/event-factories-Port-to-libecal-2.0.patch 
1970-01-01 01:00:00.0 +0100
+++ almanah-0.11.1/debian/patches/event-factories-Port-to-libecal-2.0.patch 
2019-08-01 16:52:27.0 +0100
@@ -0,0 +1,821 @@
+From cb11d217448161562ae6eb4b94d01186e89b275f Mon Sep 17 00:00:00 2001
+From: Milan Crha 
+Date: Fri, 17 May 2019 12:22:09 +0200

Bug#933667: sagemath: FTBFS in sid

[Gianfranco Costamagna]

Source: sagemath
Version: 8.6-6
Severity: serious

Hello, looks like sagemath is now FTBFS, see e.g. logs at
http://debomatic-amd64.debian.net/distribution#unstable/sagemath/8.6-6build1/buildlog

and
https://launchpad.net/ubuntu/+source/sagemath/8.6-6build1/+build/17348800

not sure what regressed it.

thanks

Gianfranco

Bug#931135: German translation made me laugh during a meeting

[Holger Levsen]

Hi Helge,

On Thu, Aug 01, 2019 at 05:56:28PM +0200, Helge Kreutzmann wrote:
> I would suggest discussing this on debian-l10n-german so everybody
> interested from the German team notices and can join.

ack

> On Wed, Jul 31, 2019 at 09:05:35PM +, Holger Levsen wrote:
> > On Wed, Jul 31, 2019 at 10:23:21PM +0200, Helge Kreutzmann wrote:
> > > The translation only changed one word, namely canary. You can find it
> > > in the upstream git repository.
> > > 
> > > The remaining translation is only in the latest version in sid (and
> > > most of it in earlier version, e.g. in stable, as well).
> > 
> > 'die sich fortpflanzenden Bauschalter' were also quite absurd to me.
> > maybe better use 'vererb(t)en' instead of 'fortpflanzen'?
> 
> I'm switching to German as this is quite tough to describe in English.

indeed

> Signale pflanzen sich fort, Informationen pflanzen sich fort. 

well, ja, aber, irgendwann passt das nicht mehr. Fortpflanzungsrituale
von Signalen sind nicht nur sprachlich unsinnig :)

> In den deutschen Handbuchseiten verwenden wir »übertragen« (bei
> Systemd), ausbreiten, weiterreichen. 

passt

> Übertragen würde ich aber mit »transmit« zurückübersetzen, daher würde
> ich, falls wir es ändern, eher für »ausbreiten« plädieren.

'weiterreichen' find ich deutlich besser. 'ausbreiten' klingt so nach
Virus oder Krankheit... (und auch passiv, während 'weiterreichen' aktiv
ist.)

Thanks! :)

-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3

[Tobias Frost]

Package: src:wxwidgets3.0
Followup-For: Bug #933554

(Moving the subdiscussion from #933419)

> Is this same bug that you've written up recently as #933554?  I don't
> have a Debian system with a HiDPI display, but I should probably be
> able to test on another OS.

I could get Gnome to offer me the scaling issue on my Desktop PC with a
full HD monitor, so maybe that is a possiblity.

Some obervations on the bug:
Only the drawing seems to be botched. Mouse coordinates seem to be
matching with the window area, so e.g to select an object in slic3r you
would have put the mouse in the middle of the window area, not in the middle
where it is rendered. IOW, it seems that the coordinates to be rendered
are somewhere not using the scaling factor…

PS: https://github.com/prusa3d/PrusaSlicer/issues/864 seems related,
and it seems to be fixed^Wbetter in wxwidgets 3.1 …

--
tobi

Bug#933419: darkradiant: Please rebuild against wxWidgets GTK 3 package

[Tobias Frost]

On Wed, Jul 31, 2019 at 02:32:00PM -0400, Scott Talbert wrote:
> On Wed, 31 Jul 2019, Tobias Frost wrote:
> 
> > A quick Thought: Would there be a possiblity to have at least an message
> > printed out on wayland before crashing emitted from wxwidgets? like a
> > warning "you are using GLCanvas under wayland, this app will crash!"
> 
> Yes, in fact, I've upstreamed such a fix.  I thought I had included that
> patch in Debian, but it appears that I have not.  We can definitely do that.

Cool. That would definitly help the users, especially if we can give
them a pointer how to get it working.

> > BTW The other issue I mentioned is not related to wayland but to having
> > a QHD+ display… I need to pinpoint that further and will then file a bug
> > accordingly, however I'm not sure against which package.
> > 
> > This is a regression which makes darkradiant* unusable, so I will need to
> > postpone a fix for this bug, unfortunatly.
> > 
> > * one have to expect that someone using darkradiant using a QHD+ or 4K
> > display, because of the nature of darkadiant.
> 
> Is this same bug that you've written up recently as #933554?  I don't have a
> Debian system with a HiDPI display, but I should probably be able to test on
> another OS.

Yes, this is this bug. I just tried also on my desktop computer, it has
a Full HD monitor, which seems to be enough for gnome to offer the
scaling options, so possibly im might be enough to connect an externam
monitor. (But we should probably discuss that in the other bug)
;-)

> Scott

Bug#931135: German translation made me laugh during a meeting

[Helge Kreutzmann]

Hello Holger,
I would suggest discussing this on debian-l10n-german so everybody
interested from the German team notices and can join.

On Wed, Jul 31, 2019 at 09:05:35PM +, Holger Levsen wrote:
> On Wed, Jul 31, 2019 at 10:23:21PM +0200, Helge Kreutzmann wrote:
> > The translation only changed one word, namely canary. You can find it
> > in the upstream git repository.
> > 
> > The remaining translation is only in the latest version in sid (and
> > most of it in earlier version, e.g. in stable, as well).
> 
> 'die sich fortpflanzenden Bauschalter' were also quite absurd to me.
> maybe better use 'vererb(t)en' instead of 'fortpflanzen'?

I'm switching to German as this is quite tough to describe in English.

Signale pflanzen sich fort, Informationen pflanzen sich fort. 

In den deutschen Handbuchseiten verwenden wir »übertragen« (bei
Systemd), ausbreiten, weiterreichen. 

Übertragen würde ich aber mit »transmit« zurückübersetzen, daher würde
ich, falls wir es ändern, eher für »ausbreiten« plädieren.

Viele Grüße

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#920373: default soundfonts

[Thorsten Glaser]

Fabian Greffrath dixit:

>Done, feedback has been all positive so far.

I agree.

>Do you think the following commit does everything that's necessary for
>the timgm6mb-soundfont to properly support this new schema?
>
>https://salsa.debian.org/multimedia-team/timgm6mb-soundfont/commit/1a9d5a8718c95657df827e773fbba78493abbe44

After removing the musescore-compatible-soundfont from Provides,
this looks okay. “musescore-compatible-soundfont” is managed by
me only and has extra requirements, and only very few soundfonts
will provide it… basically MuseScore_General, which has a few
alternatives.

>Since the new packages are purely virtual, we will have to give a
>"real" alternative first in package dependencies. I suggest to use this
>one, timgm6mb-soundfont, by default, because it is small and sounds
>pretty well already - at least from a game background music playback
>point of view. What do you think?

Agreed, but individual packages can use a different one if they
have a reason for it, but I’d say timgm6mb should be the normal
case.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#933666: leaflet-image: fails to build with webpack 4 in experimental

[Pirate Praveen]

Package: leaflet-image
Version: 0.4.0~dfsg-1
Severity: important
Control: tags -1 patch

When building with webpack 4, this package fails with error,

mkdir --parents debian/js   uglifyjs --compress --mangle \  
--in-source-map leaflet-image.js.map \  
--source-map debian/js/leaflet-image.min.js.map \   
--output debian/js/leaflet-image.min.js -- leaflet-image.js 
fs.js:115   
throw err;  ^   
Error: ENOENT: no 
such file or directory, open 'leaflet-image.js.map'

Now webpack creates output files relative to dist directory.

This commit -> 
https://salsa.debian.org/js-team/leaflet-image/commit/c177c223f86facce929bab19f891675d4e511eb0
 in webpack4 branch of salsa fixes it.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#933665: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes

[Gerald Turner]

Package: openssh-server
Version: 1:7.9p1-10
Severity: normal

Dear Maintainer,

I've been running several servers, upgraded across many Debian stable
releases, with sshd_config that had been tightened down in various ways
(example attached) including explicit PubkeyAcceptedKeyTypes (containing
ssh-rsa).  After upgrading to buster a user reported that he could no
longer login with his RSA key.

  sshd[17025]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes 
[preauth]

I tested and found that explicitly defining PubkeyAcceptedKeyTypes in
sshd_config breaks RSA pubkey auth, even when the line merely states:

  PubkeyAcceptedKeyTypes ssh-rsa

However when PubkeyAcceptedKeyTypes is removed from the config, the
implicit defaults allow RSA to work.

I've attached sshd debug logs for the two scenarios.

My guess is there's some sort of config parsing glitch within ssh.

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

Kernel: Linux 4.19.0-5-cloud-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 openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libcom-err21.44.5-1
ii  libgssapi-krb5-2   1.17-3
ii  libkrb5-3  1.17-3
ii  libpam-modules 1.3.1-5
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux12.8-1+b1
ii  libssl1.1  1.1.1c-1
ii  libsystemd0241-5
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  openssh-client 1:7.9p1-10
ii  openssh-sftp-server1:7.9p1-10
ii  procps 2:3.3.15-2
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd  241-5
ii  ncurses-term6.1+20181013-2
ii  xauth   1:1.0.10-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- debconf information:
  openssh-server/permit-root-login: true
* ssh/use_old_init_script: true
  ssh/encrypted_host_key_but_no_keygen:
  ssh/disable_cr_auth: false
  ssh/vulnerable_host_keys:
  openssh-server/password-authentication: true

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D
AllowAgentForwarding no
AllowStreamLocalForwarding no
AllowTcpForwarding no
AllowUsers REDACTED
AuthenticationMethods publickey password
ChallengeResponseAuthentication no
Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com
ClientAliveCountMax 2
ClientAliveInterval 30
Compression no
DebianBanner no
DisableForwarding yes
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKeyAlgorithms ssh-ed25519-cert-...@openssh.com,ssh-ed25519,ssh-rsa
KexAlgorithms 
diffie-hellman-group18-sha512,ecdh-sha2-nistp521,curve25519-sha256,curve25519-sha...@libssh.org
LoginGraceTime 10
LogLevel VERBOSE
MACs hmac-sha2-512-...@openssh.com
MaxAuthTries 3
MaxStartups 2:50:10
PermitOpen none
PermitRootLogin no
PermitUserRC no
Port 50022
PrintMotd no
PubkeyAcceptedKeyTypes ssh-ed25519-cert-...@openssh.com,ssh-ed25519,ssh-rsa
RekeyLimit 1280M 53m59s
Subsystem sftp /usr/lib/openssh/sftp-server
TCPKeepAlive no
UseDNS yes
UsePAM yes
# Rejected RSA pubkey login.
# ssh running with explicit "PubkeyAcceptedKeyTypes ssh-rsa" in sshd_config

Aug  1 08:18:25 zoth-ommog sshd[20165]: debug1: Forked child 20167.
Aug  1 08:18:25 zoth-ommog sshd[20167]: debug1: Set /proc/self/oom_score_adj to 0
Aug  1 08:18:25 zoth-ommog sshd[20167]: debug1: rexec start in 5 out 5 newsock 
5 pipe 7 sock 8
Aug  1 08:18:25 zoth-ommog sshd[20167]: debug1: inetd sockets after dupping: 3, 
3
Aug  1 08:18:25 zoth-ommog sshd[20167]: Connection from REDACTED port 35260 on 
REDACTED port 50022
Aug  1 08:18:25 zoth-ommog sshd[20167]: debug1: Client protocol version 2.0; 
client software version OpenSSH_7.9p1 Debian-10
Aug  1 08:18:25 zoth-ommog sshd[20167]: debug1: match: OpenSSH_7.9p1 Debian-10 
pat OpenSSH* compat 0x0400
Aug  1 08:18:25 zoth-ommog sshd[20167]: debug1: Local version string 
SSH-2.0-OpenSSH_7.9p1
Aug  1 08:18:25 zoth-ommog sshd[20167]: debug1: permanently_set_uid: 103/65534 
[preauth]
Aug  1 08:18:25 zoth-ommog sshd[20167]: debug1: list_hostkey_types: 
ssh-ed25519,ssh-ed25519-cert-...@openssh.com,ssh-rsa [preauth]
Aug  1 08:18:25 zoth-ommog sshd[20167]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Aug  1 08:18:25 zoth-ommog sshd[20167]: debug1: SSH2_MSG_KEXINIT received 
[preauth]
Aug  1 08:18:25 

Bug#920373: default soundfonts

[Fabian Greffrath]

Am Samstag, den 27.07.2019, 15:26 + schrieb Thorsten Glaser:
> Meh I might be able to post that but I don’t read -devel due
> to traffic either except sometimes via the web archives so
> feel free to do that yourself ☻

Done, feedback has been all positive so far.

Do you think the following commit does everything that's necessary for
the timgm6mb-soundfont to properly support this new schema?

https://salsa.debian.org/multimedia-team/timgm6mb-soundfont/commit/1a9d5a8718c95657df827e773fbba78493abbe44

Since the new packages are purely virtual, we will have to give a
"real" alternative first in package dependencies. I suggest to use this
one, timgm6mb-soundfont, by default, because it is small and sounds
pretty well already - at least from a game background music playback
point of view. What do you think?

Cheers,

 - Fabian



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

Bug#932799: open-iscsi: Initiator doesn't login and connect on boot

[Ritesh Raj Sarraf]

On Thu, 2019-08-01 at 16:49 +0300, Dokuchaev Ivan wrote:
> There's also a ens19 interface, but it's management-only, and only
> has
> IP address assigned, no static routes/bonds/etc. Physically it's a VM
> on
> PVE hypervisor, all connected via virtual bridge to a router, and the
> target is located on a MS Windows Server by another admin, and iSCSI
> performs as expected on other initiators like the ones on Synology
> DSM
> and vmWare ESXi 6.x.
> 
> Journalctl shows that iscsid has been started (iscsi.service unit is
> not
> present):
> 
> jul 24 16:19:19 nfs-server iscsid[372]: iSCSI logger with pid=375
> started!
> jul 24 16:19:19 nfs-server iscsid[375]: iSCSI daemon with pid=376
> started!
> 
> But LUN is not mounted, requiring manual intervention with "iscsiadm
> -m
> node -L all && systemctl restart iscsid nfs-kernel-server" in order
> to
> drive to reappear.
> 

It is a stacked setup so it is hard to say where may lie the problem.
But the default Debian iSCSI setup works good.

root@debian-btrfs:~# systemctl status iscsi
● open-iscsi.service - Login to default iSCSI targets
   Loaded: loaded (/lib/systemd/system/open-iscsi.service; enabled; vendor 
preset: enabled)
   Active: active (exited) since Thu 2019-08-01 20:50:41 IST; 2min 19s ago
 Docs: man:iscsiadm(8)
   man:iscsid(8)
  Process: 407 ExecStartPre=/bin/systemctl --quiet is-active iscsid.service 
(code=exited, status=0/SUCCESS)
  Process: 408 ExecStart=/sbin/iscsiadm -m node --loginall=automatic 
(code=exited, status=0/SUCCESS)
  Process: 436 ExecStart=/lib/open-iscsi/activate-storage.sh (code=exited, 
status=0/SUCCESS)
 Main PID: 436 (code=exited, status=0/SUCCESS)

Aug 01 20:50:15 debian-btrfs systemd[1]: Starting Login to default iSCSI 
targets...
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Logging in to [iface: default, 
target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.40,
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Logging in to [iface: default, 
target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.41,
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Logging in to [iface: default, 
target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.42,
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Logging in to [iface: default, 
target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.43,
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Login to [iface: default, target: 
iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.40,3260]
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Login to [iface: default, target: 
iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.41,3260]
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Login to [iface: default, target: 
iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.42,3260]
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Login to [iface: default, target: 
iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.43,3260]
Aug 01 20:50:41 debian-btrfs systemd[1]: Started Login to default iSCSI targets.
root@debian-btrfs:~# systemctl status iscsid
● iscsid.service - iSCSI initiator daemon (iscsid)
   Loaded: loaded (/lib/systemd/system/iscsid.service; enabled; vendor preset: 
enabled)
   Active: active (running) since Thu 2019-08-01 20:50:15 IST; 2min 53s ago
 Docs: man:iscsid(8)
  Process: 400 ExecStartPre=/lib/open-iscsi/startup-checks.sh (code=exited, 
status=0/SUCCESS)
  Process: 403 ExecStart=/sbin/iscsid (code=exited, status=0/SUCCESS)
 Main PID: 405 (iscsid)
Tasks: 2 (limit: 2353)
   Memory: 4.9M
   CGroup: /system.slice/iscsid.service
   ├─404 /sbin/iscsid
   └─405 /sbin/iscsid

Aug 01 20:50:15 debian-btrfs systemd[1]: Starting iSCSI initiator daemon 
(iscsid)...
Aug 01 20:50:15 debian-btrfs iscsid[403]: iSCSI logger with pid=404 started!
Aug 01 20:50:15 debian-btrfs systemd[1]: Started iSCSI initiator daemon 
(iscsid).
Aug 01 20:50:16 debian-btrfs iscsid[404]: iSCSI daemon with pid=405 started!
Aug 01 20:50:41 debian-btrfs iscsid[404]: Connection2:0 to [target: 
iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.41,3260] through [
Aug 01 20:50:41 debian-btrfs iscsid[404]: Connection1:0 to [target: 
iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.40,3260] through [
Aug 01 20:50:41 debian-btrfs iscsid[404]: Connection4:0 to [target: 
iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.43,3260] through [
Aug 01 20:50:41 debian-btrfs iscsid[404]: Connection3:0 to [target: 
iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.42,3260] through [

> Configuration files haven't changed since initial bugreport, both
> iscsid.conf and default (inside /etc/iscsi/nodes/TARGETNAME/ADDRESS)
> have 'node.startup = automatic' and 'node.conn[0].startup =
> automatic'
> values in them.
> 
> I don't know it it's related, but I can't simply reboot the service
> with
> an active iSCSI portal login, with a strange error:
> 
> connection1:0: ping timeout of 5 secs expired, recv timeout 5, last
> 

Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores

[Phillip Lougher]

On Wed, 31 Jul 2019 17:43:44 +0200 Alexander Couzens  wrote:
> Hi László,
>
> > On Wed, Jul 31, 2019 at 3:06 AM Steven Shiau 
> > wrote: [...]
> >  As mentioned in the past, it's the
> > 0016-remove-frag_deflator_thread.patch that needs either reverted or
> > fixed by it's original author, Alexander Couzens (added to this mail).
>
> Since I've full weeks ahead, I can not make any estimation when
> I've time to look onto the performance issue.
>

That patch is a laughable piece of rubbish.  I believe both you
people (the Debian maintainer and author) are in total denial
about your incompetence in this matter.  This is obviously just my
opinion I've formed over the last couple of months, in case you want to
claim that it is libellous.

It is, obvious, from the patch where the problem lies.  You *remove*
the parallel fragment compressor threads, and move the work onto the
main thread.

Now what do you think that does?  It completely removes a significant
amount of the parallelism of Mksquashfs and makes the main thread
a bottleneck.

This is your fault and your problem, and it lies in your lack of
understanding.

Yet you continually blame your inability to make Mksquashfs work
correctly on *my* code being old and unmaintained and badly written.

This can be seen from the following excerpt from a post in this
Debian bug thread made by the Debian maintainer.

"> First of all, as squashfs-tools wasn't written in the last years, when
> reproducible builds became more famous. So it's not written
> with reproducible building in mind.
> For me is reproducible builds more important than using all cpu cores.
> But I don't use it with gigabytes images.
 Yeah, it's quite an old software without real development in the recent years."

and

" This sounds more complex work than it can be achieved in this week.
Maybe a complete rewrite would be better then on the long run."

Constantly pointing the blame at my tools and my code.

This is typical of the poor worker who chooses to blame everyone
else but himself.

None of that is the case.  50% of the code-base of Squashfs-tools
was (re-)written in the last 9 years as part of on-going improvements.
It has also been maintained across that period.

As for your specific claim that Mksquashfs can't be made to produce
reproducible builds because it is old and written before reproducible
builds became popular.  That is abject nonsense.

I added reproducible builds to Mksquashfs.  It took one weekend.

https://github.com/plougher/squashfs-tools/commit/24da0c63c80be64e1adc3f24c27459ebe18a19af

> > > Or shall we gradually switch to squashfs-tools-ng is the upstream
> > > is more active:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965
> >  It's under investigation. I'm traveling and will only arrive back
> > home on Sunday evening. Expect more details on this next week.
>
> I also seen the upcoming squashfs-tools-ng rising and quite interested
> to test it and reading the code.
> Depending on tests & the code, I could imagine I'll put my effort and
> time towards squashfs-tools-ng.
>
> @László It should be your call to revert or not. For sure there are
> also downstream users who need reproducible builds (e.g. tails) who
> may also change to squashfs-tools-ng if -ng is the only reproducible
> squashfs generator in debian.
>

Upstream Squashfs-tools now produces reproducible builds.

Squashfs-tools-ng, this is a rogue project masquerading as an
official new upstream .  It is neither official nor a new upstream.  As
Squashfs author and maintainer I completely disassociate that project
with the Squashfs project.

I also have publicly stated that this project is spreading falsehoods and
that it is defamatory to me as the Squashfs author and maintainer.

See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#29

and

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#34

I have lived for a couple of months with you two people bad-mouthing
Squashfs tools, it's code-base and my maintenance.

I have absolutely had enough.

I have CC'd this to the Debian project leader and the Debian technical
commitee, and also to linux-kernel, linux-fsdevel and linux-embedded
for wider attention.

What else do I have to do to make you stop bad-mouthing Squashfs?  Sue?

Yours

Dr. Phillip Lougher

> Hopefully I'll find time to look into it.
>
> Best Regards,
> lynxis
> --
> Alexander Couzens
>
> mail: lyn...@fe80.eu
> jabber: lyn...@fe80.eu
> gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604

Bug#933664: Acknowledgement (qemu-system-ppc: Initialization of device VGA failed: failed to find romfile "vgabios-stdvga.bin")

[Mathieu Malaterre]

Turns out this is simple as:

$ sudo apt-get install qemu-system-x86

I do not have recommends:

$ cat /etc/apt/apt.conf.d/99local
APT::Install-Recommends "false";
APT::Install-Suggests "false";

Sorry for the noise

Bug#931825: Dub executable does not run

[Andreas Ronnquist]

severity 931825 grave
thanks

On Thu, 11 Jul 2019 00:12:56 +0300 Jussi Pakkanen 
wrote:
> Package: dub
> Version: 1.12.1-1
> 
> Installing dub on Debian unstable (tested on x86 and x64) and then
> running "dub" errors out immediately with the following error message:
> 
> dub: symbol lookup error: dub: undefined symbol: _Dstd5stdio_ name of mangled symbol>.
> 
> 

I run into similar problems when simply running dub:

dub: symbol lookup error: dub: undefined symbol: 
_D4core8internal4hash9bytesHashFNaNbNiPxvmmZm

Also, the build system of the package lix is affected, see

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

(That one is reported as it affect gcc-9 only, but I run into it on a
standard unstable machine).

Bug#933664: qemu-system-ppc: Initialization of device VGA failed: failed to find romfile "vgabios-stdvga.bin"

[Mathieu Malaterre]

Package: qemu-system-ppc
Version: 1:3.1+dfsg-8~deb10u1
Severity: normal

Dear Maintainer,

I tried booting my shiny new kernel:

$ file g4/vmlinux
g4/vmlinux: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), 
statically linked, BuildID[sha1]=aec02dbaa89aea93d2cab980a6328b97de8d9820, with 
debug_info, not stripped

Using:

$ qemu-system-ppc -m 1024 -kernel g4/vmlinux -cdrom /tmp/mini.iso -boot d
qemu-system-ppc: Initialization of device VGA failed: failed to find romfile 
"vgabios-stdvga.bin"

It would be nice to fix the installation path.

Thanks,

The iso file is coming from the tarball:

http://ftp.ports.debian.org/debian-ports/pool-powerpc/main/d/debian-installer/debian-installer-images_20190702_powerpc.tar.gz

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

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

Versions of packages qemu-system-ppc depends on:
ii  libaio1 0.3.112-3
ii  libasound2  1.1.8-1
ii  libbluetooth3   5.50-1
ii  libbrlapi0.65.6-10
ii  libc6   2.28-10
ii  libcacard0  1:2.6.1-1
ii  libcapstone34.0.1+really+3.0.5-1
ii  libepoxy0   1.5.3-0.1
ii  libfdt1 1.4.7-3
ii  libgbm1 18.3.6-2
ii  libgcc1 1:8.3.0-6
ii  libglib2.0-02.58.3-2
ii  libgnutls30 3.6.7-4
ii  libibverbs1 22.1-1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libncursesw66.1+20181013-2
ii  libnettle6  3.4.1-1
ii  libnuma12.0.12-1
ii  libpixman-1-0   0.36.0-1
ii  libpng16-16 1.6.36-6
ii  librdmacm1  22.1-1
ii  libsasl2-2  2.1.27+dfsg-1
ii  libseccomp2 2.3.3-4
ii  libspice-server10.14.0-1.3
ii  libtinfo6   6.1+20181013-2
ii  libusb-1.0-02:1.0.22-2
ii  libusbredirparser1  0.8.0-1
ii  libvdeplug2 2.3.2+r586-2.2
ii  libvirglrenderer0   0.7.0-2
ii  openbios-ppc1.1.git20181001-1
ii  openhackware0.4.1+git-20140423.c559da7c-4.1
ii  qemu-slof   20180702+dfsg-1
ii  qemu-system-common  1:3.1+dfsg-8~deb10u1
ii  qemu-system-data1:3.1+dfsg-8~deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages qemu-system-ppc recommends:
pn  ipxe-qemu
pn  qemu-system-gui  
pn  qemu-utils   
pn  seabios  

Versions of packages qemu-system-ppc suggests:
pn  qemu-block-extra  
pn  samba 
pn  vde2  

-- no debconf information

Bug#932350: ITP: lutok -- lightweight C++ API library for Lua

[Nicolas Braud-Santoni]

Control: tag -1 + pending

Package has been in NEW for ~2 weeks


signature.asc
Description: PGP signature

Bug#933663: ITP: atf -- collection of libraries to write test programs in C, C++ and POSIX sh

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: atf
  Version : 0.21
  Upstream Author : Julio Merino 
* URL : https://github.com/jmmv/atf/
* License : BSD-3
  Programming Lang: C, C++, POSIX sh
  Description : collection of libraries to write test programs in C, C++ 
and POSIX sh

ATF is a collections of 3 libraries (resp. in C, C++, and POSIX sh) that
implement a common CLI-level interface for interacting with tests.

Such tests expect to be invoked by a runner, such as kyua (see ITP #932349).

ATF is a test dependency for pkgconf.

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl1C+UERHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MtPUhAArJDMdCnYkZ7R16XTTYLGNvECWv8NGEK5
Jdk6K+PLL/yCwvaL+sGnY651ZwIg2kj27pNJCHLKIBD9gdtdTpc95uXB1ncBiotT
+whrU84xIeVbG1MxQWRPC+upP1JhE/g8qIK0JPDYnzY9cUXgOo4W1STVgd3QwOiX
9OAmsk5EkRk8DtcBlUOsBBq1Pvljt7gNyRk6mHNl0mNiLHPUVN0psPmuhA9ljZuI
0Ritz917x9vvy10iP0uAtrSn+cKTiQc9RMyKbEqELBT2yHGWRbkT4Sg0k/au4do9
p6zbQ/Slt2VXF198bvIdo7BMMkXgPxkXC7k+Af7flouL8n6d0mPQ0sAk7LKCJ11h
dI6Cd1a/s7lkdXIru3OMQ+TFyNyooXkBVc+toX19Vyn8vXWT1fJVuo/3NR34esR9
+MLzhdu933KivlYOHKK6eje1dF9tvbXI1HQusZxAWa73m8PUXj0bHqEmc4WoZC2T
IPmZZLFQdAALbTFNqKU9kg03k5fDWMUphkJXODesGkBR0V7xee4jZQOYR3N87cOs
ZDHFvseMeVN6L+ZFABJpNMlHMKToPZqR1IIijHiHs7jj1osqejKwKfSTYBN5sDA8
Wj/eu/OsHISFUE4jPI7P6a5L2gN8wKxIg6iW9Mdtd+5nFBAR5I8Ukp/hiTyaLQEv
bCln/5NkPpc=
=qufR
-END PGP SIGNATURE-

Bug#933662: node-matrix-js-sdk: build with webpack 4 failing

[Pirate Praveen]

Package: node-matrix-js-sdk
Version: 0.9.2-1
Severity: important
Control: tags -1 patch

This package fail to build with webpack 4 from experimental. The attached patch 
makes the build pass with webpack 4.

More details about webpack 4 transition here 
https://wiki.debian.org/Javascript/Nodejs/Webpack4
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.diff -ur node-matrix-js-sdk-0.9.2.orig/debian/control 
node-matrix-js-sdk-0.9.2/debian/control
--- node-matrix-js-sdk-0.9.2.orig/debian/control2018-02-02 
18:00:55.0 +0100
+++ node-matrix-js-sdk-0.9.2/debian/control 2019-08-01 16:13:29.831517566 
+0200
@@ -26,7 +26,6 @@
 #"exorcist": "^0.4.0",
 #"sourceify": "^0.1.0",
 #"source-map-support": "^0.4.11",
- , node-uglify (>= 2.8.26)
 # (and install dependencies, to be bundled in browser package)
  , node-bluebird
  , node-browser-request
diff -ur node-matrix-js-sdk-0.9.2.orig/debian/rules 
node-matrix-js-sdk-0.9.2/debian/rules
--- node-matrix-js-sdk-0.9.2.orig/debian/rules  2017-12-29 19:17:13.0 
+0100
+++ node-matrix-js-sdk-0.9.2/debian/rules   2018-02-02 18:01:17.0 
+0100
@@ -18,7 +18,7 @@
dh $@
 
 override_dh_auto_clean:
-   rm -rf dist lib
+   rm -rf dist lib node_modules/.cache
 
 override_dh_auto_build:
# Node version
@@ -26,8 +26,10 @@
# Browser version -- does not work yet
mkdir -p dist
mkdir -p node_modules
-   webpack --config debian/webpack.config.js browser-index.js 
dist/browser-matrix.js
-   uglifyjs -c -m -o dist/browser-matrix.min.js --source-map 
dist/browser-matrix.min.js.map --in-source-map dist/browser-matrix.js.map 
dist/browser-matrix.js
+   webpack --config debian/webpack.config.js \
+--entry ./browser-index.js --output ./dist/browser-matrix.js --mode development
+   webpack --config debian/webpack.config.js \
+--entry ./browser-index.js --output ./dist/browser-matrix.min.js --mode 
production
 
 # dh_make generated override targets
 # This is example for Cmake (See https://bugs.debian.org/641051 )