Bug#951686: education-workstation: add gvfs-fuse under Recommends: field

[Mike Gabriel]

Package: education-workstation
Severity: wishlist

To make gvfsd mounted shares usable in a terminal session, we need the  
share to be actually mounted on the local filesystem of a workstation.


This gets automatically handled via gvfs-fuse, if it is installed.  
Current Debian Edu workstations don't have this pkg installed.


It becomes even more urgent on Roaming Workstations, where the  
server-side HOMEs are mounted via gvfsd as SMB shares. If users shall  
be able to access their home from a terminal, then gvfs-fuse daemon  
needs to be running in the background.


Mike
--

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

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



pgpy7cFWyE13K.pgp
Description: Digitale PGP-Signatur

Bug#951675: z3 causing llvm linking issues

[Sylvestre Ledru]

Hello,

Le 20/02/2020 à 00:36, TheComputerGuy a écrit :

Package: llvm-9-dev
Version: 9.0.1-8

llvm or clang could be causing this issue but I have no idea which one. This 
issue occurs in the Debian Sid Docker. When linking the zig binary, a bunch of 
undefined references errors show up. I have been told by the maintainer that 
its an issue with Debian.

 > anyway that error looks like the debian llvm package was built to depend on 
Z3 support (which zig does not need), but then didn't correctly report -lz3 with 
llvm-config --system-libs. so your options are:
* build llvm/clang from source
* get debian/llvm to fix their bug
* use apt.llvm.org instead of the debian package
* use a binary from ziglang.org/download 
* maintain fork of zig that works around the issue

I'm not quite sure what the maintainer said from this quote but it sounds like this should be fixed as it could fix some packages that might currently be broken. I'm using the llvm and clang v9 stuff. I hope this issue is fixed soon, if anyone needs the specific errors you can find it on the build 
log from https://github.com/ExpidusOS/docker-zig/runs/454581154 .


Could you please provide some error messages and step to reproduce?

Thanks
Sylvestre

Bug#951684: juce FTCBFS: multiple reasons

[Helmut Grohne]

Source: juce
Version: 5.4.7~ds0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

juce fails to cross build from source, for multiple reasons.

1. debian/rules invokes the build architecture pkg-config. An easy
   solution is letting dpkg's buildtools.mk supply pkg-config.
2. An upstream Makefile hard codes the build architecture pkg-config.
   It should be substitutable such that dh_auto_build can replace it.
3. debian/rules has a bare make invocation that lacks cross tools. Using
   dh_auto_build can fix this.

Please consider applying the attached patch to make juce cross
buildable.

Helmut
diff --minimal -Nru juce-5.4.7~ds0/debian/changelog 
juce-5.4.7~ds0/debian/changelog
--- juce-5.4.7~ds0/debian/changelog 2020-02-18 09:46:05.0 +0100
+++ juce-5.4.7~ds0/debian/changelog 2020-02-20 06:50:40.0 +0100
@@ -1,3 +1,13 @@
+juce (5.4.7~ds0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dpkg's buildtools.mk supply pkg-config for debian/rules.
++ cross.patch: Make pkg-config substitutable.
++ Let dh_auto_build pass cross tools to make.
+
+ -- Helmut Grohne   Thu, 20 Feb 2020 06:50:40 +0100
+
 juce (5.4.7~ds0-1) unstable; urgency=medium
 
   * New upstream version 5.4.7~ds0
diff --minimal -Nru juce-5.4.7~ds0/debian/patches/cross.patch 
juce-5.4.7~ds0/debian/patches/cross.patch
--- juce-5.4.7~ds0/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ juce-5.4.7~ds0/debian/patches/cross.patch   2020-02-20 06:50:38.0 
+0100
@@ -0,0 +1,56 @@
+--- juce-5.4.7~ds0.orig/extras/Projucer/Builds/LinuxMakefile/Makefile
 juce-5.4.7~ds0/extras/Projucer/Builds/LinuxMakefile/Makefile
+@@ -19,6 +19,10 @@
+   AR=ar
+ endif
+ 
++ifndef PKG_CONFIG
++  PKG_CONFIG=pkg-config
++endif
++
+ ifndef CONFIG
+   CONFIG=Debug
+ endif
+@@ -35,13 +39,13 @@
+ TARGET_ARCH := 
+   endif
+ 
+-  JUCE_CPPFLAGS := $(DEPFLAGS) -DLINUX=1 -DDEBUG=1 -D_DEBUG=1 
-DJUCER_LINUX_MAKE_6D53C8B4=1 -DJUCE_APP_VERSION=5.4.7 
-DJUCE_APP_VERSION_HEX=0x50407 $(shell pkg-config --cflags x11 xinerama xext 
freetype2 webkit2gtk-4.0 gtk+-x11-3.0) -pthread -I../../JuceLibraryCode 
-I../../../../modules $(CPPFLAGS)
++  JUCE_CPPFLAGS := $(DEPFLAGS) -DLINUX=1 -DDEBUG=1 -D_DEBUG=1 
-DJUCER_LINUX_MAKE_6D53C8B4=1 -DJUCE_APP_VERSION=5.4.7 
-DJUCE_APP_VERSION_HEX=0x50407 $(shell $(PKG_CONFIG) --cflags x11 xinerama xext 
freetype2 webkit2gtk-4.0 gtk+-x11-3.0) -pthread -I../../JuceLibraryCode 
-I../../../../modules $(CPPFLAGS)
+   JUCE_CPPFLAGS_APP := -DJucePlugin_Build_VST=0 -DJucePlugin_Build_VST3=0 
-DJucePlugin_Build_AU=0 -DJucePlugin_Build_AUv3=0 -DJucePlugin_Build_RTAS=0 
-DJucePlugin_Build_AAX=0 -DJucePlugin_Build_Standalone=0 
-DJucePlugin_Build_Unity=0
+   JUCE_TARGET_APP := Projucer
+ 
+   JUCE_CFLAGS += $(JUCE_CPPFLAGS) $(TARGET_ARCH) -g -ggdb -O0 $(CFLAGS)
+   JUCE_CXXFLAGS += $(JUCE_CFLAGS) -std=c++11 $(CXXFLAGS)
+-  JUCE_LDFLAGS += $(TARGET_ARCH) -L$(JUCE_BINDIR) -L$(JUCE_LIBDIR) $(shell 
pkg-config --libs x11 xinerama xext freetype2 webkit2gtk-4.0 gtk+-x11-3.0) -lrt 
-ldl -lpthread $(LDFLAGS)
++  JUCE_LDFLAGS += $(TARGET_ARCH) -L$(JUCE_BINDIR) -L$(JUCE_LIBDIR) $(shell 
$(PKG_CONFIG) --libs x11 xinerama xext freetype2 webkit2gtk-4.0 gtk+-x11-3.0) 
-lrt -ldl -lpthread $(LDFLAGS)
+ 
+   CLEANCMD = rm -rf $(JUCE_OUTDIR)/$(TARGET) $(JUCE_OBJDIR)
+ endif
+@@ -56,13 +60,13 @@
+ TARGET_ARCH := 
+   endif
+ 
+-  JUCE_CPPFLAGS := $(DEPFLAGS) -DLINUX=1 -DNDEBUG=1 
-DJUCER_LINUX_MAKE_6D53C8B4=1 -DJUCE_APP_VERSION=5.4.7 
-DJUCE_APP_VERSION_HEX=0x50407 $(shell pkg-config --cflags x11 xinerama xext 
freetype2 webkit2gtk-4.0 gtk+-x11-3.0) -pthread -I../../JuceLibraryCode 
-I../../../../modules $(CPPFLAGS)
++  JUCE_CPPFLAGS := $(DEPFLAGS) -DLINUX=1 -DNDEBUG=1 
-DJUCER_LINUX_MAKE_6D53C8B4=1 -DJUCE_APP_VERSION=5.4.7 
-DJUCE_APP_VERSION_HEX=0x50407 $(shell $(PKG_CONFIG) --cflags x11 xinerama xext 
freetype2 webkit2gtk-4.0 gtk+-x11-3.0) -pthread -I../../JuceLibraryCode 
-I../../../../modules $(CPPFLAGS)
+   JUCE_CPPFLAGS_APP := -DJucePlugin_Build_VST=0 -DJucePlugin_Build_VST3=0 
-DJucePlugin_Build_AU=0 -DJucePlugin_Build_AUv3=0 -DJucePlugin_Build_RTAS=0 
-DJucePlugin_Build_AAX=0 -DJucePlugin_Build_Standalone=0 
-DJucePlugin_Build_Unity=0
+   JUCE_TARGET_APP := Projucer
+ 
+   JUCE_CFLAGS += $(JUCE_CPPFLAGS) $(TARGET_ARCH) -O3 $(CFLAGS)
+   JUCE_CXXFLAGS += $(JUCE_CFLAGS) -std=c++11 $(CXXFLAGS)
+-  JUCE_LDFLAGS += $(TARGET_ARCH) -L$(JUCE_BINDIR) -L$(JUCE_LIBDIR) $(shell 
pkg-config --libs x11 xinerama xext freetype2 webkit2gtk-4.0 gtk+-x11-3.0) 
-fvisibility=hidden -lrt -ldl -lpthread $(LDFLAGS)
++  JUCE_LDFLAGS += $(TARGET_ARCH) -L$(JUCE_BINDIR) -L$(JUCE_LIBDIR) $(shell 
$(PKG_CONFIG) --libs x11 xinerama xext freetype2 webkit2gtk-4.0 gtk+-x11-3.0) 
-fvisibility=hidden -lrt -ldl -lpthread $(LDFLAGS)
+ 
+   CLEANCMD = rm -rf $(JUCE_OUTDIR)/$(TARGET) $(JUCE_OBJDIR)
+ endif
+@@ -136,8 +140,8 @@
+ all : $(JUCE_OUTDIR)/$(JUCE_TARGET_APP)
+ 
+ $(JUCE_OUTD

Bug#951685: abr2gbr FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: abr2gbr
Version: 1:1.0.2-2.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

abr2gbr fails to cross build from source, because it uses build
architecture build tools. For one thing, debian/rules does not pass
cross tools to make - which is commonly fixed by using dh_auto_build -
and for another, the Makefile hard codes the build architecture
pkg-config. Please consider applying the attached patch to make abr2gbr
cross buildable.

Helmut
diff --minimal -Nru abr2gbr-1.0.2/debian/changelog 
abr2gbr-1.0.2/debian/changelog
--- abr2gbr-1.0.2/debian/changelog  2020-02-17 22:29:46.0 +0100
+++ abr2gbr-1.0.2/debian/changelog  2020-02-20 08:08:44.0 +0100
@@ -1,3 +1,12 @@
+abr2gbr (1:1.0.2-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make pkg-config substitutable.
++ Let dh_auto_build pass cross tools to make.
+
+ -- Helmut Grohne   Thu, 20 Feb 2020 08:08:44 +0100
+
 abr2gbr (1:1.0.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru abr2gbr-1.0.2/debian/patches/cross.patch 
abr2gbr-1.0.2/debian/patches/cross.patch
--- abr2gbr-1.0.2/debian/patches/cross.patch1970-01-01 01:00:00.0 
+0100
+++ abr2gbr-1.0.2/debian/patches/cross.patch2020-02-20 08:08:43.0 
+0100
@@ -0,0 +1,14 @@
+--- abr2gbr-1.0.2.orig/Makefile
 abr2gbr-1.0.2/Makefile
+@@ -24,8 +24,9 @@
+ 
+ OBJDIR= .obj
+ BINDIR=   /usr/bin
+-CFLAGS  = $(CCFLAGS) $(shell $(BINDIR)/pkg-config --cflags glib-2.0)
+-LIBS= $(CLIBS) $(shell $(BINDIR)/pkg-config --libs 
glib-2.0)
++PKG_CONFIG ?= $(BINDIR)/pkg-config
++CFLAGS  = $(CCFLAGS) $(shell $(PKG_CONFIG) --cflags glib-2.0)
++LIBS= $(CLIBS) $(shell $(PKG_CONFIG) --libs glib-2.0)
+ DESTS = $(addprefix $(OBJDIR)/, $(SOURCES:.c=.o))
+ BIN   = abr2gbr
+ DEPEND= $(OBJDIR)/.depend
diff --minimal -Nru abr2gbr-1.0.2/debian/patches/series 
abr2gbr-1.0.2/debian/patches/series
--- abr2gbr-1.0.2/debian/patches/series 2020-02-17 22:28:03.0 +0100
+++ abr2gbr-1.0.2/debian/patches/series 2020-02-20 08:08:09.0 +0100
@@ -1,2 +1,3 @@
 fix_compile_flags-1:1.0.2-2
 gcc9.patch
+cross.patch
diff --minimal -Nru abr2gbr-1.0.2/debian/rules abr2gbr-1.0.2/debian/rules
--- abr2gbr-1.0.2/debian/rules  2010-08-27 21:13:41.0 +0200
+++ abr2gbr-1.0.2/debian/rules  2020-02-20 08:08:44.0 +0100
@@ -20,9 +20,7 @@
 
 build-stamp: configure-stamp  
dh_testdir
-
-   $(MAKE) CCFLAGS="$(CFLAGS)"
-
+   dh_auto_build -- CCFLAGS="$(CFLAGS)"
touch $@
 
 clean: 

Bug#951655: r-cran-sf

[Andreas Tille]

Control: tags -1 upstream

On Thu, Feb 20, 2020 at 05:51:25AM +0100, Sebastiaan Couwenberg wrote:
> On 2/19/20 10:05 PM, Edzer Pebesma wrote:
> > I just tested lwgeom ("r-cran-lwgeom") also against PROJ 7.0.0RC1, and
> > the github version also seems to pass checks. Hope we can get both on
> > CRAN soon.
> > 
> > On 2/19/20 9:57 PM, Roger Bivand wrote:
> >> Thanks for posting the 7.0.0RC1 listing on the proj list. The r-cran-sf
> >> issue is simply a configure test for 6 or not, so 7 sorts with <6. Fixed
> >> in the github sf repo.
> 
> Let's CC Andreas Tille, the maintainer of the R packages in Debian.

Thanks a lot.  So I just can "sit and wait" until you push a new verion 
of lwgeom (and tag the bug "upstream").

If there is a patch for sf in the githup repository as well it seems I
can also wait.  Bas, if you want to get things solved faster I can for
sure cherry pick the patches and upload.  Please ping the according
bug reports.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#951683: rust-selectors: build-depends on non-existing librust-cssparser-0.25+default-dev

[Ralf Treinen]

Source: rust-selectors
Version: 0.21.0-1
Severity: serious
User: trei...@debian.org
Usertags: edos-uninstallable

Hi, rust-selectors build-depends on librust-cssparser-0.25+default-dev
which does not exist in unstable.

-Ralf.

Bug#951682: rust-html5ever: build-depends on non-existing librust-markup5ever-0.9+default-dev

[Ralf Treinen]

Source: rust-html5ever
Version: 0.24.0-1
Severity: serious
User: trei...@debian.org
Usertags: edos-uninstallable

Hi, rust-html5ever build-depends on librust-markup5ever-0.9+default-dev
which does not exist in unstable.

-Ralf.

Bug#951549: zfs-mount-generator

[Antonio Russo]

Peter,

I specifically created the zfs-mount-generator to automate managing of zfs 
mount units through systemd (and, in particular, ordering of mounts
for bind mounts).  I'm guessing you're in a similar situation. If you're 
running unstable, you should be ready to go! Just follow the
tutorial in man zfs-mount-generator.

If this solves your problem I'd encourage you to close this bug report---you 
either want zfs doing automatic management, and you should use
zfs-mount-generator, or you don't and the user should take responsibility for 
these fine-grained controls. (Even then, there's actually a very
recent patch [1] on zfs master that allows for especially fine-grained 
controls, including a couple interfaces x-systemd.wanted-by and
x-systemd.required-by that we specifically coordinated with systemd upstream 
on). This feature out is coming along very nicely, take a look!

Antonio

[1] https://github.com/zfsonlinux/zfs/pull/9649

Bug#712176: could not read directory /proc/acpi/processor

[Ben Wong]

Package: acpitool
Version: 0.5.1-4+b4
Followup-For: Bug #712176

Dear Maintainer,

'acpitool -c' seems to work fine without /proc/acpi/processor, but it
still complains about it being missing. Could we simply remove the
spurious warning in Show_CPU_Info()?

Thanks!

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

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

Versions of packages acpitool depends on:
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6

Versions of packages acpitool recommends:
ii  acpid  1:2.0.31-1

acpitool suggests no packages.

-- no debconf information

Bug#951461: Acknowledgement (libgl1-mesa-dri: X crashes on startup when libgl1-mesa-dri ver is not same as libegl-mesa0/libgbm1)

[Brian Sammon]

On Wed, 19 Feb 2020 09:21:09 +0100
Julien Cristau  wrote:

> I think this might be essentially the same issue as #947813.  Since
> version 19.3.1-4, both libgl1-mesa-dri and libegl-mesa0 depend on
> same-version libglapi-mesa, meaning this mismatch can no longer happen.

Okay, If I read this correctly, this means that if I upgrade libegl-mesa0 to 
19.3.1-4 or newer, then apt will prevent this type of mismatch from happening 
again (by preventing me from installing, for example, libgl1-mesa-dri 19.8.65 
without upgrading libgbm1 to a matching version).

However, I don't think this will solve the problem (which may not occur very 
often, granted) of apt allowing you to install newer versions of 
libgl1-mesa-dri with libegl1-mesa < 19.3 and libgbm1 < 19.3.

Bug#951657: ffmpegfs: d/copyright issues

[Norbert Schlia]

I see. The file has been added to d/copyright. Change will be in 1.10-3.

Thanks for your assistance!


Am 20.02.20 um 03:28 schrieb Sean Whitton:

Hello,

On Wed 19 Feb 2020 at 08:48PM +01, Norbert Schlia wrote:


ffmpegfs.1 is a generated file, it is build from ffmpegfs.1.txt which is
listed, I guess this should be sufficient.

No, it's not, because the current d/copyright implies it has a license
other than it has -- it falls under the `Files: *` stanza.


--
*Oblivion Software Development and Internet Services*
Norbert Schlia
Hans-Thoma-Str. 24
76327 Pfinztal
Germany

Telefon:0721 47 05 1112
Fax:0721 47 05 1113
Mobile: 0178 5365230
Steuernr.:  3411/44460


/www: http://www.oblivion-software.eu//

/Pour le Respect de l'Environnement : merci d'éviter d'imprimer ce 
message./
/Rispetto per l'ambiente: Si prega di evitare di stampare questo 
messaggio./
/Пожалуйста, не печатайте это письмо - защита окружающей среды в наших 
руках./
/Por favor, ten en cuenta el medio ambiente antes de imprimir este 
mensaje./

/With regard to the environment: Please avoid printing this message./
/Aus Rücksicht auf die Umwelt drucken Sie bitte diese Nachricht nicht aus./

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

[Johannes Schauer]

Hi,

Quoting Francesco Poli (2020-02-19 23:21:55)
> On Tue, 18 Feb 2020 00:03:06 +0100 Johannes Schauer wrote:
> > Can you show me how you converted the tarball mmdebstrap
> > produced into your debian-unstable.qcow2 image?
> 
> Sure, the command was:
> 
>   $ mmdebstrap-autopkgtest-qemu
> 
> which is a small script I am trying to develop, based on your suggested
> command.
> It is still experimental, needs to be improved in many aspects, and has
> not yet produced any working QEMU image (!).
> I wanted to send it to you as a contribution to mmdebstrap, once it was
> mature enough.
> I am sending it to you now, as a preview (not to be included in the
> official package, yet!). Any suggestion for improvement is more than
> welcome...
> 
> Please note that I am running it on an amd64 box. Hence:
> 
>   $ dpkg --print-architecture
>   amd64
> 
> 
> I tried the image again, after adding my regular user to the 'kvm'
> group (I hadn't done so, out of ignorance about QEMU/KVM), but the
> result was the same:
> 
>   $ qemu-system-x86_64 -enable-kvm -m 512 -serial 
> unix:/tmp/ttyS0,server,nowait -drive  
> "file=./debian-unstable.qcow2,cache=unsafe,if=virtio,index=0"
> 
> or
> 
>   $ qemu-system-x86_64 -m 512 -serial unix:/tmp/ttyS0,server,nowait -drive 
> "file=./debian-unstable.qcow2,cache=unsafe,if=virtio,index=0"
> 
> or
> 
>   $ qemu-system-x86_64 -enable-kvm -m 512 -serial 
> unix:/tmp/ttyS0,server,nowait -drive 
> "file=./debian-unstable.img,format=raw,cache=unsafe,if=virtio,index=0"
> 
> always starts a virtual machine that hangs (seemingly) forever, at the
> "Booting from Hard Disk..." stage.
> 
> 
> I really cannot understand what's going on.

I have an idea. When I tried running guestfish on salsa CI it also would not
boot at all. The image that was created by guestfish just wasn't bootable for
some reason. After much tinkering, I added the following to the end of the
guestfish invocation:

: sync : umount / : shutdown

And that worked. Since there seem to be some machines where these additions to
guestfish are needed, I also now put these into all guestfish invocations and
examples in mmdebstrap but that version isn't released yet and you would have
had to look into the current git master.

Try it out and tell me if it helped!

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#951666: ITP: php-league-flysystem -- unified file system API for PHP

[David Prévot]

Hi Robin,

Le 19/02/2020 à 10:56, Robin Gustafsson a écrit :
> Package: wnpp
[…]
> * Package name: php-league-flysystem
>   Version : 1.0.64
[…]
> I plan to maintain this package within the Debian PHP PEAR Maintainers team.

CCed.

Please note this package was part of Debian some time ago and its VCS is
still archived on Alioth:

https://alioth-archive.debian.org/git/pkg-php/php-league-flysystem.git.tar.xz

Feel free to use it or not.

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#951671: pdfannotator not yet fixed

[Norbert Preining]

Hi Bastien,

> Could you please replace the previous patch with this one ?

Updated in git, thanks.

Norbert

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

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

Oh an one further thing... doing:
ffmpeg -i in.mp3 -acodec copy -y out.mp3

with both files (i.e. those that should playback gapless) also destroys
the gabless playback, that worked just perfectly fine with the files
straight from lame.


Cheers,
Chris.

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

Any further ideas on this?

I've just checked again with the current ffmpeg/bs1770gain versions
from sid... and still, the gapless playback of MP3s is broken when
files are processed with --overwrite.

It does seem to work when not using --overwrite mode (but -a -o
dir),... but that's no big surprise as files are decoded to flac (which
is per se gapless), but this is probably not what most people want.


Seems a bit as if something is going wrong when the mp3 stream is
remuxed or stored again.


With the unfortunate removal of python-rgain, bs1770gain seems to be
the only remaining replaygain tool in Debian... so it would be really
nice if ffmpeg could be made no breaking the output files :-)


Cheers,
Chris.

Bug#869617: Acknowledgement (libutempter0: Helper executable multiply broken: can't add, can't del)

[Dmitry V. Levin]

Hi,

On Mon, Jul 24, 2017 at 10:26:40PM +0100, Conrad Hughes wrote:
[...]
> Origin: , 
> Bug: 
> Bug-Debian: https://bugs.debian.org/
> Bug-Ubuntu: https://launchpad.net/bugs/
> Forwarded: 
> Reviewed-By: 
> Last-Update: 2017-07-24
> 
> --- libutempter-1.1.6.orig/utempter.c
> +++ libutempter-1.1.6/utempter.c
> @@ -241,7 +241,7 @@ main(int argc, const char *argv[])
>   exit(EXIT_FAILURE);
>   }
>  
> - device = ptsname(STDIN_FILENO);
> + device = ttyname(STDIN_FILENO);
>  
>   if (!device)
>   {

Replacing ptsname() with ttyname() would allow to use privileged utempter
helper for adding unauthorized records.  For example, regular clients
of slave pseudo-terminal devices would be able to add such records,
which would be a security vulnerability.

The ptsname() invocation is correct.  Please ensure that
- STDIN_FILENO is a valid file descriptor corresponding to a properly
configured pseudo-terminal master device;
- operating system is not mis-configured and ptsname() works properly.

I'd like to remind you the following part of documentation:
"utempter_add_record() function adds a login record to the database
for the TTY belonging to the pseudo-terminal master file descriptor fd."

Please forward this information to whom it may concern.


-- 
ldv

Bug#951681: python-jenkinsapi: FTBFS due to missing build deps and pylint command

[Logan Rosen]

Package: python-jenkinsapi
Version: 0.3.11-1
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi,

python-jenkinsapi currently fails to build from source after the Python
3 changes. There are a few tweaks that need to be made to get it
building again.

In Ubuntu, the attached patch was applied to achieve the following:

  * Fix FTBFS:
- Build-depend on dh-python and python3-pbr.
- Use pylint instead of pylint3.

Thanks for considering the patch.

Logan

-- System Information:
Debian Release: buster/sid
  APT prefers eoan-updates
  APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan'), 
(100, 'eoan-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-29-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-jenkinsapi-0.3.11/debian/control 
python-jenkinsapi-0.3.11/debian/control
--- python-jenkinsapi-0.3.11/debian/control 2020-02-16 18:39:59.0 
-0500
+++ python-jenkinsapi-0.3.11/debian/control 2020-02-19 22:01:41.0 
-0500
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Al Stone 
 Build-Depends: debhelper (>= 12), python3-all-dev, python3-lxml, 
- python3-setuptools, python3-pytest, pylint3
+ python3-setuptools, python3-pytest, pylint3, dh-python, python3-pbr
 Standards-Version: 4.5.0
 Homepage: http://pypi.python.org/pypi/jenkinsapi
 Vcs-Git: https://github.com/ahs3/python-jenkinsapi
diff -Nru python-jenkinsapi-0.3.11/debian/patches/codestyle.patch 
python-jenkinsapi-0.3.11/debian/patches/codestyle.patch
--- python-jenkinsapi-0.3.11/debian/patches/codestyle.patch 2020-02-16 
18:39:59.0 -0500
+++ python-jenkinsapi-0.3.11/debian/patches/codestyle.patch 2020-02-19 
22:01:41.0 -0500
@@ -1,11 +1,10 @@
-diff -Naur orig-jenkinsapi/Makefile fixed-jenkinsapi/Makefile
 orig-jenkinsapi/Makefile   2020-02-16 17:49:45.404336646 -0700
-+++ fixed-jenkinsapi/Makefile  2020-02-16 17:50:25.352625604 -0700
+--- a/Makefile
 b/Makefile
 @@ -1,7 +1,6 @@
  .PHONY: lint tox dist
  
  lint:
 -  pycodestyle
-   pylint3 jenkinsapi/*.py
+   pylint jenkinsapi/*.py
  
  tox:
diff -Nru python-jenkinsapi-0.3.11/debian/patches/install.patch 
python-jenkinsapi-0.3.11/debian/patches/install.patch
--- python-jenkinsapi-0.3.11/debian/patches/install.patch   2020-02-16 
18:39:59.0 -0500
+++ python-jenkinsapi-0.3.11/debian/patches/install.patch   2020-02-19 
22:01:41.0 -0500
@@ -1,12 +1,11 @@
-diff -Naur orig-jenkinsapi/Makefile fixed-jenkinsapi/Makefile
 orig-jenkinsapi/Makefile   2020-02-16 18:11:36.225956771 -0700
-+++ fixed-jenkinsapi/Makefile  2020-02-16 18:13:10.706654980 -0700
+--- a/Makefile
 b/Makefile
 @@ -1,4 +1,4 @@
 -.PHONY: lint tox dist
 +.PHONY: lint tox dist install
  
  lint:
-   pylint3 jenkinsapi/*.py
+   pylint jenkinsapi/*.py
 @@ -9,3 +9,5 @@
  dist:
python3 setup.py sdist bdist_wheel
diff -Nru python-jenkinsapi-0.3.11/debian/patches/python3.patch 
python-jenkinsapi-0.3.11/debian/patches/python3.patch
--- python-jenkinsapi-0.3.11/debian/patches/python3.patch   2020-02-16 
18:39:59.0 -0500
+++ python-jenkinsapi-0.3.11/debian/patches/python3.patch   2020-02-19 
22:01:41.0 -0500
@@ -1,7 +1,6 @@
-diff -Naur python-jenkinsapi.github/Makefile fixed-jenkinsapi/Makefile
 python-jenkinsapi.github/Makefile  2020-02-16 16:46:46.767307926 -0700
-+++ fixed-jenkinsapi/Makefile  2020-02-16 17:02:37.545891630 -0700
-@@ -1,17 +1,17 @@
+--- a/Makefile
 b/Makefile
+@@ -1,7 +1,7 @@
  .PHONY: test lint tox coverage dist
  
  test:
@@ -10,10 +9,7 @@
  
  lint:
pycodestyle
--  pylint jenkinsapi/*.py
-+  pylint3 jenkinsapi/*.py
- 
- tox:
+@@ -11,7 +11,7 @@
tox
  
  dist:

Bug#951680: inetutils-inetd

[Marcin Sacha]

Package: inetutils-inetd

Version: 2:1.9.4-7

 

Option -p do not work - pidfile is not created. Pidfile is created only,
when option -p is not present.

 

Environment:

Debian GNU/Linux 10 (buster)

Architecture: i386

libc6: 2.28-10

kernel: 4.19.98-1

 

MJS

 

Bug#951679: [gedit] sh syntax highlighting bug

[jnqnfe]

Package: gedit
Version: 3.34.0-1

There is a noticeable syntax highlighting bug handling shell code as
demonstrated in the attached image (problem.png).

I happened to noticed that the bug disappears if adding a space before
the terminating nested quote as shown in (problem_with_space.png).

Bug#951678: adequate reports obsolete-conffile while it is upgraded

[shirish शिरीष]

Package: mate-applets
Version: 1.24.0-1
Severity: normal

User: debian...@lists.debian.org
Usertags : obsolete-conffile@adequate

I got the following obsolete-conffile warning while upgrading mate-applets -

~$ adequate mate-applets
mate-applets: obsolete-conffile
/etc/dbus-1/system.d/org.mate.CPUFreqSelector.conf

Please fix it.

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

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

Versions of packages mate-applets depends on:
ii  gsettings-desktop-schemas  3.34.0-2
ii  gvfs   1.42.2-1
ii  libatk1.0-02.34.1-1
ii  libc6  2.29-10
ii  libcairo2  1.16.0-4
ii  libcpupower2   5.4.19-1
ii  libdbus-glib-1-2   0.110-5
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-2
ii  libglib2.0-0   2.62.4-2
ii  libgtk-3-0 3.24.13-1
ii  libgtksourceview-3.0-1 3.24.11-2
ii  libgtop-2.0-11 2.40.0-2
ii  libgucharmap-2-90-71:12.0.1-2
ii  libiw3030~pre9-13+b1
ii  libmate-panel-applet-4-1   1.24.0-1
ii  libmateweather11.24.0-1
ii  libnotify4 0.7.8-1
ii  libpango-1.0-0 1.42.4-7
ii  libpangocairo-1.0-01.42.4-7
ii  libpolkit-gobject-1-0  0.105-26
ii  libupower-glib30.99.11-1
ii  libwnck-3-03.32.0-1
ii  libx11-6   2:1.6.8-1
ii  libxml22.9.4+dfsg1-8
ii  mate-applets-common1.24.0-1
ii  mate-panel 1.24.0-1

Versions of packages mate-applets recommends:
ii  mate-media   1.24.0-1
ii  mate-polkit  1.24.0-1
ii  mate-system-monitor  1.24.0-1

mate-applets suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#951349: mecab: Fails to build against ruby2.7

[Hideki Yamane]

control: block -1 by 951623

Hi,

On Wed, 19 Feb 2020 17:41:37 -0300
Lucas Kanashiro  wrote:
> FYI ruby2.7 is already enabled in unstable (the ruby2.7 transition
> already started), so no need to use experimental. Here you can find the
> build logs with failures:
> https://buildd.debian.org/status/package.php?p=mecab

 It seems that 951623 is the issue.


-- 
Hideki Yamane 

Bug#951657: ffmpegfs: d/copyright issues

[Sean Whitton]

Hello,

On Wed 19 Feb 2020 at 08:48PM +01, Norbert Schlia wrote:

> ffmpegfs.1 is a generated file, it is build from ffmpegfs.1.txt which is
> listed, I guess this should be sufficient.

No, it's not, because the current d/copyright implies it has a license
other than it has -- it falls under the `Files: *` stanza.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#951677: shotcut: Should depend (or recommend) frei0r-plugins

[Celelibi]

Package: shotcut
Version: 20.02.17-1
Severity: important

Dear Maintainer,

When adding a video track in the timeline, a transition is automatically
added. It uses either the transition 'movit.overlay' or
'frei0r.cairoblend'.

This is pretty explicit in the code at:
src/models/multitrackmodel.cpp:2625
Mlt::Transition composite(MLT.profile(), Settings.playerGPU()? "movit.overlay" 
: "frei0r.cairoblend");

Without it, adding the first video track makes the application segfault.
Therefore, I think the easiest fix is to have the shotcut package
depend on frei0r-plugins.

Best regards,
Celelibi


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

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

Versions of packages shotcut depends on:
ii  libc6  2.29-10
ii  libgcc-s1  10-20200211-1
ii  libjs-three111+dfsg1-1
ii  libmlt++3  6.20.0-1
ii  libmlt66.20.0-1
ii  libqt5core5a   5.12.5+dfsg-8
ii  libqt5gui5 5.12.5+dfsg-8
ii  libqt5multimedia5  5.12.5-1+b1
ii  libqt5network5 5.12.5+dfsg-8
ii  libqt5opengl5  5.12.5+dfsg-8
ii  libqt5qml5 5.12.5-5
ii  libqt5quick5   5.12.5-5
ii  libqt5quickwidgets55.12.5-5
ii  libqt5sql5 5.12.5+dfsg-8
ii  libqt5webkit5  5.212.0~alpha3-6
ii  libqt5websockets5  5.12.5-2+b1
ii  libqt5widgets5 5.12.5+dfsg-8
ii  libqt5xml5 5.12.5+dfsg-8
ii  libstdc++6 10-20200211-1
ii  qml-module-qtgraphicaleffects  5.12.5-2+b1
ii  qml-module-qtqml-models2   5.12.5-5
ii  qml-module-qtquick-controls5.12.5-1+b1
ii  qml-module-qtquick-controls2   5.12.5+dfsg-2+b1
ii  qml-module-qtquick-dialogs 5.12.5-1+b1
ii  qml-module-qtquick-extras  5.12.5-1+b1
ii  qml-module-qtquick-layouts 5.12.5-5
ii  qml-module-qtquick-window2 5.12.5-5
ii  qml-module-qtquick25.12.5-5

shotcut recommends no packages.

shotcut suggests no packages.

-- no debconf information

Bug#949486: python-dmidecode: FTBFS with libxml2 not shipping xml2-config

[Logan Rosen]

Package: python-dmidecode
Version: 3.12.2-10
Followup-For: Bug #949486
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:


  * Use pkg-config to find libxml2 linker flags (fixes Debian #949486).


Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: buster/sid
  APT prefers eoan-updates
  APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan'), 
(100, 'eoan-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-29-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-dmidecode-3.12.2/debian/control 
python-dmidecode-3.12.2/debian/control
--- python-dmidecode-3.12.2/debian/control  2019-08-21 14:12:13.0 
-0400
+++ python-dmidecode-3.12.2/debian/control  2020-02-19 20:37:26.0 
-0500
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Sandro Tosi 
 Uploaders: Debian Python Modules Team 

-Build-Depends: debhelper-compat (= 10), dh-python, python3-all-dev, 
python3-all-dbg, libxml2-dev, python3-libxml2
+Build-Depends: debhelper-compat (= 10), dh-python, python3-all-dev, 
python3-all-dbg, libxml2-dev, python3-libxml2, pkg-config
 Standards-Version: 4.4.0
 Vcs-Git: https://salsa.debian.org/python-team/modules/python-dmidecode.git
 Vcs-Browser: https://salsa.debian.org/python-team/modules/python-dmidecode
diff -Nru python-dmidecode-3.12.2/debian/patches/0005-pkg-config.patch 
python-dmidecode-3.12.2/debian/patches/0005-pkg-config.patch
--- python-dmidecode-3.12.2/debian/patches/0005-pkg-config.patch
1969-12-31 19:00:00.0 -0500
+++ python-dmidecode-3.12.2/debian/patches/0005-pkg-config.patch
2020-02-19 20:37:26.0 -0500
@@ -0,0 +1,21 @@
+--- a/src/setup_common.py
 b/src/setup_common.py
+@@ -54,14 +54,14 @@
+ if os_path.exists("/etc/debian_version"): #. XXX: Debian Workaround...
+ libdir.append("/usr/lib/pymodules/python%d.%d"%sys.version_info[0:2])
+ 
+-(res, libxml2_libs) = subprocess.getstatusoutput("xml2-config --libs")
++(res, libxml2_libs) = subprocess.getstatusoutput("pkg-config --libs 
libxml-2.0")
+ if res != 0:
+ print("Could not build python-dmidecode.")
+-print("Could not run xml2-config, is libxml2 installed?")
+-print("Also the development libraries?")
++print("Could not run pkg-config, is it installed?")
++print("Also the development libraries for libxml2?")
+ sys.exit(1)
+ 
+-# Parse the xml2-config --libs response
++# Parse the pkg-config --libs libxml-2.0 response
+ for l in libxml2_libs.split(" "):
+ if l.find('-L') == 0:
+ libdir.append(l.replace("-L", "", 1))
diff -Nru python-dmidecode-3.12.2/debian/patches/series 
python-dmidecode-3.12.2/debian/patches/series
--- python-dmidecode-3.12.2/debian/patches/series   2019-08-21 
14:12:13.0 -0400
+++ python-dmidecode-3.12.2/debian/patches/series   2020-02-19 
20:34:48.0 -0500
@@ -2,3 +2,4 @@
 0002-Stop-linking-with-libxml2mod.patch
 0003-Fix-memory-Type-Detail-map-size.patch
 0004-makefile-dont-cp.patch
+0005-pkg-config.patch

Bug#951409: Confirmed fix to build required platform comphy as module

[Joel Johnson]

Thanks, I created an identical patch before seeing your update, tested 
and confirmed that building as a module is loaded during boot. I tried 
to submit a merge request to the repo, but don't have access to push 
branches, so I've also attached the resulting patch here.


Joel

From c866cc5b105d5bdec3edec500512e7a2ca42e79a Mon Sep 17 00:00:00 2001
From: Joel Johnson 
Date: Wed, 19 Feb 2020 18:25:55 -0700
Subject: [PATCH] Build PHY_MVEBU_A38X_COMPHY module

The Device Tree for ClearFog devices was updated to use comphy during
the 5.1 development cycle, merged in a4751093a26c. The new support
requires the presence of the platform specific comphy driver.
---
 debian/changelog   | 3 +++
 debian/config/armhf/config | 1 +
 2 files changed, 4 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 0f76df363348..f6afe0eb94d4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -26,6 +26,9 @@ linux (5.5.5-1~exp1) UNRELEASED; urgency=medium
   [ Aurelien Jarno ]
   * [riscv64] Enable SECCOMP.
 
+  [ Joel Johnson ]
+  * [armhf] Build PHY_MVEBU_A38X_COMPHY module (Closes: #951409, #948298)
+
   [ Romain Perier ]
   * [arm64] Enable BCMGENET
   * [arm64] Fix CONFIG_INFINIBAND_HNS_HIP06 and CONFIG_INFINIBAND_HNS_HIP08
diff --git a/debian/config/armhf/config b/debian/config/armhf/config
index 71a1828be643..9b83f014845d 100644
--- a/debian/config/armhf/config
+++ b/debian/config/armhf/config
@@ -994,6 +994,7 @@ CONFIG_PHY_SUN9I_USB=m
 ##
 ## file: drivers/phy/marvell/Kconfig
 ##
+CONFIG_PHY_MVEBU_A38X_COMPHY=m
 CONFIG_PHY_PXA_USB=m
 
 ##
-- 
2.20.1

Bug#951676: RFS: dia/0.97.3+git20160930-9 -- Diagram editor

[Rodrigo Carvalho]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: dia
   Version : 0.97.3+git20160930-9
   Upstream Author : several authors
 * URL : https://wiki.gnome.org/Apps/Dia/
 * License : GPL-2
 * Vcs : None
   Section : graphics

It builds those binary packages:

  dia-common - Diagram editor (common files)
  dia - Diagram editor

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dia/dia_0.97.3+git20160930-9.dsc

Changes since the last upload:

   * New maintainer.
   * Disable use of xml_config. Now we use pkg_config. (Closes: #949097).
   * debian/rules: remove unnecessary dh argument
   * debian/control:
 - remove obsolete VCS URLs (anonscm no longer exists,
   we should create a VCS on salsa).
 - Standards-Version: 4.5.0.

OBS: There is a maintainer swap. Rodrigo Siqueira have already agreed.
CC Siqueira who can
confirm, if necessary.

Regards,

--
  Rodrigo Carvalho

Bug#951351: dovecot-sieve: extracttext w/out :first causes sieve to segfault

[Bradley M. Kuhn]

Timo, thanks so much for your prompt response!

> On 15. Feb 2020, at 2.01, Bradley M. Kuhn  wrote:
>> Package: dovecot-sieve
>> Version: 1:2.3.4.1-5+deb10u1
>> Severity: important
>>$ sieve-test -t - -Tlevel=tests test.sieve multipart.eml  
>> that  reliably generates a segfault for me.

Timo Sirainen wrote at 02:26 (PST) on Monday:
> Fixed by 
> https://github.com/dovecot/pigeonhole/commit/daf4a721c5e8606ceded426d7b882718fb22b8a9

Seems the right thing to do would be to backport that patch to the versions
in Debian stretch and buster as a security update, no?

I see there is a role address for the team maintaining the dovecot package.
I'd offer to do the backport although I admittedly haven't done it before,
but I'm willing to figure out how if it'd be useful.  Would it be useful for
me to do that?

-- 

Bradley M. Kuhn - he/him

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/

Bug#951675: z3 causing llvm linking issues

[TheComputerGuy]

Package: llvm-9-dev
Version: 9.0.1-8

llvm or clang could be causing this issue but I have no idea which one. This 
issue occurs in the Debian Sid Docker. When linking the zig binary, a bunch of 
undefined references errors show up. I have been told by the maintainer that 
its an issue with Debian.

> anyway that error looks like the debian llvm package was built to depend on 
> Z3 support (which zig does not need), but then didn't correctly report -lz3 
> with llvm-config --system-libs. so your options are:
* build llvm/clang from source
* get debian/llvm to fix their bug
* use apt.llvm.org instead of the debian package
* use a binary from ziglang.org/download
* maintain fork of zig that works around the issue

I'm not quite sure what the maintainer said from this quote but it sounds like 
this should be fixed as it could fix some packages that might currently be 
broken. I'm using the llvm and clang v9 stuff. I hope this issue is fixed soon, 
if anyone needs the specific errors you can find it on the build log from 
https://github.com/ExpidusOS/docker-zig/runs/454581154.

Bug#951674: kalzium: molecular editor is not available

[John Scott]

Source: kalzium
Severity: normal
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=416856

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I haven't narrowed down in what version this changed, but in Kalzium the
Molecular Editor button appears to be greyed out on the toolbar. Invoking
Kalzium with --molecule and pointing to a file seems to have no effect
regardless of whether it exists.

Trying to build the current version yields
- -- Kalzium molecular editor disabled
and
- -- Checking for module 'openbabel-2.0>=2.2.0'
- --   No package 'openbabel-2.0' found
CMake Warning at CMakeLists.txt:30 (find_package):
  By not providing "FindAvogadroLibs.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "AvogadroLibs", but CMake did not find one.

  Could not find a package configuration file provided by "AvogadroLibs" with
  any of the following names:

AvogadroLibsConfig.cmake
avogadrolibs-config.cmake

  Add the installation prefix of "AvogadroLibs" to CMAKE_PREFIX_PATH or set
  "AvogadroLibs_DIR" to a directory containing one of the above files.  If
  "AvogadroLibs" provides a separate development package or SDK, be sure it
  has been installed.

screenshots.debian.net seems to suggest that it was working in previous
versions, however.

Avogadro, Eigen 3, and OpenBabel 2 are the dependencies needed to build it.
Since unstable has OpenBabel 3, upstream will need to port to that first,
which is the forwarded bug.

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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXk3GJwAKCRByvHFIwKst
p3PcAQCFhfrrJZZ3GU8+sMkGdmR4NiANk+NjDCS6qEsycdRr5AEA9iwl7oC5zTRW
Mu/BFpJGXJXUciY2CHv4qIrDZFT16g0=
=ND90
-END PGP SIGNATURE-

Bug#951673: RFS: aplus-fsf/4.22.1-10.1 [NMU, RC] -- A+ programming language run-time environment

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "aplus-fsf"

 * Package name: aplus-fsf
   Version : 4.22.1-10.1
   Upstream Author : Arthur Whitney, et. al.
 * URL : http://www.aplusdev.org/
 * License : GPL-2.0
 * Vcs : None
   Section : interpreters

It builds those binary packages:

  aplus-fsf-doc - A+ programming language documentation
  xfonts-kapl - APL fonts for A+ development
  aplus-fsf-el - XEmacs lisp for A+ development
  aplus-fsf - A+ programming language run-time environment
  aplus-fsf-dev - A+ programming language development environment

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

  https://mentors.debian.net/package/aplus-fsf

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/aplus-fsf/aplus-fsf_4.22.1-10.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix ftbfs. (Closes: #925633)


-- 
Regards
Sudip

Bug#729217: digikam: Digikam crashes when importing from mtpfs mounted Android device

[Rainer Dorsch]

Am Montag, 17. Februar 2020, 18:15:16 CET schrieb Agustin Martin:
> On Sun, Nov 10, 2013 at 12:28:59PM +0100, Rainer Dorsch wrote:
> > Package: digikam
> > Version: 4:3.5.0-3
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > I validated on your request that the bug described in
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714561
> > 
> > is still present in the current verion of digikam.
> > 
> > I can list and copy image files in the mtpfs mounted directory but if
> > I try to "Import Images" from digikam on that mtpfs mounted directory,
> > digikam still crashes.
> > 
> > If I do a copy (cp) to an ext4 dir first, then import with digikam
> > from there, I have no problems.
> 
> Hi,
> 
> This seems to have been reported upstream
> 
>   https://bugs.kde.org/show_bug.cgi?id=349280
> 
> and was apparently fixed in digikam 4.12.0.
> 
> Is this still a problem for you?
> 
> Thanks for the feedback.
> 
> Regards,


Hi Agustin,

thanks for following-up. I use in the meantime another method and I won't find 
time in the next two weeks to test.

I suggest to close the bug, in case I can still repro it later, I will reopen 
it.

Thanks again
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#948553: Tomcat9 startup script ignores CATALINA_PID

[root]

Package: tomcat9
Version: 9.0.16-4
Followup-For: Bug #948553

Dear Maintainer,

the bug is still in the last version of stable.

The error is that \&\& should be just \&

Would be nice if this could be fixed soon.


Sincerley,
DaB.


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

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

Versions of packages tomcat9 depends on:
ii  lsb-base10.2019051400
ii  systemd 241-7~deb10u3
ii  tomcat9-common  9.0.16-4
ii  ucf 3.0038+nmu1

Versions of packages tomcat9 recommends:
ii  libtcnative-1  1.2.21-1

Versions of packages tomcat9 suggests:
pn  tomcat9-admin 
pn  tomcat9-docs  
pn  tomcat9-examples  
pn  tomcat9-user  

-- no debconf information

Bug#921297: FTBFS also with doxygen 1.8.16-1~exp3 from experimental

[Norbert Preining]

tags 921297 + fixed-upstream pending
thanks

> I will discuss with upstream what to do.

Added dep in upstream.

Norbert

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

Bug#711007: audacity: plays back at high speed and then hangs

[Pierre Bernhardt]

On Thu, 22 Dec 2016 18:08:52 +0100 Dietrich Clauss  
wrote:> Steve Handley wrote:
> > If audacity is launched from a terminal, and the sound played, the line:
> > ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
> > occurs repeatedly until the program is killed.
I've been fixed the issue in buster release 2.2.2 by enlarge the Latency
Buffer length from 100 to 999 milliseconds (Edit -> Preferences ->
Devices -> Latency -> Buffer length.)

Maybe lower value is also good but for me with 999 it works without
clipping, noising, fast playing... and without give the underrun
error.

So it looks like it can be fixed by increasing the default stored value?

Cheers,
Pierre

Bug#949227: fixed in python-pysaml2 4.5.0-7

[Thomas Goirand]

On 2/19/20 2:02 PM, Santiago Vila wrote:
> On Wed, Feb 19, 2020 at 10:10:27AM +0100, Thomas Goirand wrote:
> 
>> Thanks, but I don't need you to micro-manage the bugs in the BTS for me.
> 
> I'm not really micro-managing anything for you. I'm just making sure
> that the information in the BTS is correct. Not necessarily for you,
> but for anybody working on QA issues (which may be anybody, not just you).
> 
>> FYI, the package has been uploaded to security-master, and will soon
>> reach the security repositories, which is why I didn't care much about
>> this bug being closed (and I prefer it to be closed, so it isn't "on my
>> way" when reviewing the team's bug list).
> 
> Glad to know a fixed version has been uploaded to security, but I'm
> sure there must be already some BTS tag for that (for example, "pending"
> or "fixed"), which will help you to put bugs "outside your way"
> without incorrectly closing them.
> 
> There is a reason why we use the changelog as the preferred method to
> close bugs: We do it to ensure that the bug is only closed when a
> fixed version is actually available in the archive, so that bugs are
> not closed in error.
> 
> This is valid for unstable, but also for stable and for security.
> 
> So, if you did a security upload and wrote a Closes statement in the
> changelog, then the thing you should not care much is really about it
> being open.
> 
> Thanks.

Santiago,

Your lecturing is kind of frustrating. What you wrote above, I know it,
and you are right and accurate. We simply have a difference in how we
see things. Let me attempt to explain.

You view the BTS as the state of things for packages. I view it as a
helper for my maintainer's job. This is the source of many of the
exchanges (and sometimes, disagreement) we had. I hope these words will
help you understand that both yours and my point of view are valid, but
very different. Though like it or not, in Debian, it is up to the
maintainer to decide how to manage his bugs.

I will not play BTS ping-pong (we both have better things to do), though
I still would have prefer this bug to not be "on my way" when I review
things I have to do on my packages, because at this point, I am
considering my work on this specific issue as "done". Adding a pending
tag could do, but that's more work, and precious time that I very much
prefer wasting arguing with you :) (just joking...)

Cheers,

Thomas Goirand (zigo)

P.S: Thanks for your work in Debian, and maintaining key packages for so
long...

Bug#948307: works with openafs 1.8.5-1 and kernel 5.4.0-4-amd64

[Kai-Martin Knaak]

Dear Ben, 

I can confirm that dkms module openafs 1.8.5-1 from unstable compiles
fine with kernel 5.4.0-4-amd64 .

Thank you for the heads up. 

All the best, 

---<)kaimartin(>---
-- 
Kai-Martin Knaak
kn...@iqo.uni-hannover.de Universität Hannover, Inst. f. Quantenoptik
 tel: +49-511-762-2895 Welfengarten 1, 30167 Hannover
  fax: +49-511-762-2211
https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xC13AA4CC7B0F9882


pgphXZR9yAmq5.pgp
Description: OpenPGP digital signature

Bug#951659: setup-storage should allow default tmpfs settings

[Antoine Beaupré]

On 2020-02-19 22:24:37, Thomas Lange wrote:
>> On Wed, 19 Feb 2020 14:42:22 -0500, Antoine Beaupre  
>> said:
>
> > should be to the kernel, which has its own defaults (50% of RAM at the
> > time of writing, I believe).
> Do you have more details on that?

It's a bit fuzzy, because the situation with the tmpfs(5) manpage is a
bit unclear right now (#951598 and #951596). However, the "upstream" (as
in "linux kernel") documentation is here:

http://man7.org/linux/man-pages/man5/tmpfs.5.html

and says:

The default, when neither size nor nr_blocks is specified, is size=50%.

> > It seems there's no way to do that delegation in setup-storage(8)
> > right now: if I use `-` as a , I get the following error:
> What exactly do you want to delegate?

The size= setting. I want to be able to just use the defaults without
overriding the configuration of the linux kernel module.

a.
-- 
If Christ were here there is one thing he would not be -- a Christian.
- Mark Twain

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

[Francesco Poli]

On Tue, 18 Feb 2020 00:03:06 +0100 Johannes Schauer wrote:

[...]
> Can you show me how you converted the tarball mmdebstrap
> produced into your debian-unstable.qcow2 image?

Sure, the command was:

  $ mmdebstrap-autopkgtest-qemu

which is a small script I am trying to develop, based on your suggested
command.
It is still experimental, needs to be improved in many aspects, and has
not yet produced any working QEMU image (!).
I wanted to send it to you as a contribution to mmdebstrap, once it was
mature enough.
I am sending it to you now, as a preview (not to be included in the
official package, yet!). Any suggestion for improvement is more than
welcome...

Please note that I am running it on an amd64 box. Hence:

  $ dpkg --print-architecture
  amd64


I tried the image again, after adding my regular user to the 'kvm'
group (I hadn't done so, out of ignorance about QEMU/KVM), but the
result was the same:

  $ qemu-system-x86_64 -enable-kvm -m 512 -serial unix:/tmp/ttyS0,server,nowait 
-drive  "file=./debian-unstable.qcow2,cache=unsafe,if=virtio,index=0"

or

  $ qemu-system-x86_64 -m 512 -serial unix:/tmp/ttyS0,server,nowait -drive 
"file=./debian-unstable.qcow2,cache=unsafe,if=virtio,index=0"

or

  $ qemu-system-x86_64 -enable-kvm -m 512 -serial unix:/tmp/ttyS0,server,nowait 
-drive "file=./debian-unstable.img,format=raw,cache=unsafe,if=virtio,index=0"

always starts a virtual machine that hangs (seemingly) forever, at the
"Booting from Hard Disk..." stage.


I really cannot understand what's going on.


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


mmdebstrap-autopkgtest-qemu
Description: Binary data


pgpQiQn35glig.pgp
Description: PGP signature

Bug#951672: jinja2: don't recommend python2 package from doc package

[Steve Langasek]

Package: jinja2
Version: 2.10.1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

The python-jinja2-doc package currently Recommends: python-jinja2, which is
the python2 version of this package.

Installing documentation should not nowadays pull in python2 packages.

In Ubuntu, we have dropped this Recommends in order to keep python-jinja2
out of Ubuntu main.  You might wish to switch the Recommends instead to
python3-jinja2 if you prefer to keep it.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru jinja2-2.10.1/debian/control jinja2-2.10.1/debian/control
--- jinja2-2.10.1/debian/control2019-07-10 13:34:15.0 -0700
+++ jinja2-2.10.1/debian/control2020-02-19 13:35:57.0 -0800
@@ -41,7 +41,6 @@
 Section: doc
 Architecture: all
 Depends: ${sphinxdoc:Depends}, ${misc:Depends}
-Recommends: python-jinja2
 Description: documentation for the Jinja2 Python library
  Jinja2 is a small but fast and easy to use stand-alone template engine
  .

Bug#951671: pdfannotator not yet fixed

[Bastien Roucariès]

Package: texlive-latex-extra
Version: 2019.202000218-1
Severity: important
Tags: patch

Dear Maintainer,

Could you please replace the previous patch with this one ?

pdfannator is not  yet fixed and fail to run

diff --git a/scripts/pax/pax.jar b/scripts/pax/pax.jar
deleted file mode 100644
index 36371e2..000
Binary files a/scripts/pax/pax.jar and /dev/null differ
diff --git a/scripts/pax/pdfannotextractor.pl b/scripts/pax/pdfannotextractor.pl
index 085dc43..c5d5cf2 100755
--- a/scripts/pax/pdfannotextractor.pl
+++ b/scripts/pax/pdfannotextractor.pl
@@ -39,18 +39,15 @@ ${title}Syntax:   $program [options] 
 Options:
   --help  print usage
   --version   print version number
-  --install   try installing PDFBox library
   --debug debug informations
 END_OF_USAGE
 
 my $help = 0;
 my $debug = 0;
-my $install = 0;
 my $opt_version = 0;
 use Getopt::Long;
 GetOptions(
   'debug!' => \$debug,
-  'install!' => \$install,
   'help!' => \$help,
   'version!' => \$opt_version,
 ) or die $usage;
@@ -59,24 +56,13 @@ if ($opt_version) {
   print "$name $date v$version\n";
   exit(0);
 }
-!$install and (@ARGV >= 1 or die $usage);
+(@ARGV >= 1 or die $usage);
 
 print $title;
 
 my $error = '!!! Error:';
-my $url_pdfbox = 'http://prdownloads.sourceforge.net/pdfbox/PDFBox-0.7.3.zip?download';
-my $size_pdfbox_zip = 22769102;
-my $size_pdfbox_jar = 3321771;
-my $name_pdfbox_jar = 'PDFBox-0.7.3.jar';
-my $entry_pdfbox= "PDFBox-0.7.3/lib/$name_pdfbox_jar";
 my $pdfbox = 'PDFBox';
-
 my $prg_kpsewhich = 'kpsewhich';
-my $prg_wget  = 'wget';
-my $prg_curl  = 'curl';
-my $prg_unzip = 'unzip';
-my $prg_texhash   = 'texhash';
-my $prg_mktexlsr  = 'mktexlsr';
 my $prg_java  = 'java';
 my %prg;
 
@@ -175,34 +161,13 @@ sub find_jar_pax () {
 }
 }
 
-sub find_jar_pdfbox () {
-return if $path_jar_pdfbox;
-foreach my $dir (@dir_jar) {
-foreach my $jar (@jar_pdfbox) {
-my $path = "$dir/$jar";
-if (-f $path) {
-$path_jar_pdfbox = $path;
-debug $jar_pdfbox, $path_jar_pdfbox;
-return;
-}
-}
-}
-foreach my $jar_pdfbox (@jar_pdfbox) {
-$path_jar_pdfbox = find_jar $jar_pdfbox;
-last if $path_jar_pdfbox;
-}
-}
 
 sub launch_pax () {
 check_prg $prg_java, 1;
 my @cmd = ($prg_java);
-my $sep = $is_win ? ';' : ':';
-my $cp = "$path_jar_pax";
-$cp .= "$sep$path_jar_pdfbox" if $path_jar_pdfbox;
-$cp .= "$sep$classpath" if $classpath;
 push @cmd, '-cp';
-push @cmd, $cp;
-push @cmd, $main_class;
+push @cmd, $path_jar_pax;
+push @cmd, 'pax.PDFAnnotExtractor';
 push @cmd, @ARGV;
 debug 'System', "@cmd";
 system @cmd;
@@ -222,212 +187,10 @@ sub launch_pax () {
 return $exit_code;
 }
 
-# install part
-
-sub expand_var ($) {
-my $var = shift;
-check_prg $prg_kpsewhich, 1;
-my $cmd = $prg_kpsewhich
-  . " --progname $program"
-  . ' --expand-var';
-$cmd .= $is_win ? " \$$var" : " \\\$$var";
-debug 'Backticks', $cmd;
-my $path = `$cmd`;
-if ($? == 0) {
-chomp $path;
-debug 'Exit code', '0/success';
-debug "\$$var", $path;
-return $path;
-}
-if ($? == -1) {
-die "!!! Error: Cannot execute `$prg_kpsewhich' ($!)!\n";
-}
-if ($? & 127) {
-die "!!! Error: `$prg_kpsewhich' died with signal " . ($? & 127)
-. (($? & 128) ? ' with coredump' : '') . "!\n";
-}
-debug 'Exit code', ($? >> 8);
-return '';
-}
-
-sub ensure_dir ($) {
-my $dir = shift;
-return if -d $dir;
-mkdir $dir or die "$error Cannot create directory `$dir'!\n";
-debug 'mkdir', $dir;
-}
-
-sub file_size ($) {
-my $file = shift;
-return -1 unless -f $file;
-return (stat $file)[7];
-}
-
-if ($install) {
-# Can PDFBox already be found?
-find_jar_pdfbox;
-if ($path_jar_pdfbox) {
-print "* Nothing to do, because $pdfbox is already found:\n"
-  . "  $path_jar_pdfbox\n";
-exit(0);
-}
-
-# Find TEXMFVAR
-my $tds_root;
-foreach my $var ('TEXMFVAR', 'VARTEXMF') {
-$tds_root = expand_var $var;
-last if $tds_root;
-}
-$tds_root or die "$error Cannot find settings for `TEXMFVAR' or `VARTEXMF'!\n";
-
-# Create directories
-ensure_dir $tds_root;
-my $tds_pax = $tds_root;
-$tds_pax =~ s/(\/*)$/\/scripts/;
-ensure_dir $tds_pax;
-$tds_pax .= '/pax';
-ensure_dir $tds_pax;
-my $tds_pax_lib = "$tds_pax/lib";
-ensure_dir $tds_pax_lib;
-
-# Download
-my $dest_file = "$tds_pax/PDFBox-0.7.3.zip";
-if (file_size $dest_file == $size_pdfbox_zip) {
-debug "$pdfbox archive found", $dest_file;
-}
-else {
-my @cmd;
-my $prg_download;
-check_prg $prg_wget, 0;
-if ($prg{$prg_wget}) {
-$prg_download = $prg_wget;
-push @cmd, $prg_wget;
- 

Bug#934004: ITP: golang-starlark -- Interpreter for the Starlark configuration language

[Emanuel Krivoy]

X-Debbugs-CC: by...@debian.org

Hi Boyuan,

There is a draft package in
https://salsa.debian.org/go-team/packages/golang-skylark. Progress was
stalled for a bit while waiting for a sponsor, but Martina Ferrari (
t...@tina.pm) has kindly volunteered to help.

I'll update this bug when I get closer to submission, let me know if I can
further help.

On Thu, Feb 13, 2020 at 7:34 PM Boyuan Yang  wrote:

> X-Debbugs-CC: ekri...@gmail.com
>
> Hi Emanuel,
>
> On Mon, 5 Aug 2019 23:49:33 +0200 Emanuel Krivoy 
> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Emanuel Krivoy 
> >
> > * Package name: golang-starlark
> >   Version : 0.0~git20190717.fc7a7f4-1
> >   Upstream Author : The Bazel Authors
> > * URL : https://github.com/google/starlark-go
>
> How is this packaging effort going? We have some other projects that is
> also
> waiting for this package thus the progress can be important to us.
>
> Please let me know if you have any difficulties in the packaging. If you
> have
> any parital work output, it would also be great if you could past a URL
> here.
>
> --
> Thanks,
> Boyuan Yang
>

Bug#951670: ITP: azure-uamqp-python -- AMQP 1.0 client library for Python

[Luca Boccassi]

Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi" 
X-Debbugs-CC: debian-de...@lists.debian.org
Control: block 949763 by -1

* Package name: azure-uamqp-python
  Version : 1.2.6
  Upstream Author : Microsoft Corporation
* URL : https://github.com/Azure/azure-uamqp-python
* License : MIT
* Programming Lang: Python
* Description : AMQP 1.0 client library for Python

A cython client library for the AMQP 1.0 protocol, implemented using
the Azure uAMQP library for C.

It is required as a new dependency of the new version of python-azure.

-- 
Kind regards,
Luca Boccassi


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

Bug#936604: getmail: Python2 removal in sid/bullseye

[Daniel Kahn Gillmor]

On Wed 2019-11-13 15:31:04 +0100, Iustin Pop wrote:
> On 2019-11-13 15:06:54, Thomas Goirand wrote:
>> On 11/12/19 4:37 PM, Osamu Aoki wrote:
>> > The related binary packages are available in 2 binary names (depending on 
>> > release)
>> >  getmail4 (version=4,5) popcon installed ~2000
>> >  getmail  (version=3,5) popcon installed ~1000
>> > 
>> > https://qa.debian.org/popcon-graph.php?packages=getmail%20getmail4&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1
>> > 
>> > I think this qualifies for "py2keep".
>> 
>> IMO, this qualifies for RM-RoM. getmail is an alternative to fetchmail,
>> which is still available in Debian (and with 4 times the number of
>> installed package in popcon...). So I see no reason to keep getmail
>> then. Maybe tell this to upstream, and they may think another time.
>
> Uh, no. Functionality-wise, they're quite different. getmail is (AFAIK)
> the only tool that works for gmail with ASPs disabled (i.e. with OAUTH).
>
> Heck, I'd be very willing to maintain Py3 patches myself, because I need
> this tool.

Thanks for the clarification about what you need from this tool.  I
stopped using getmail several months ago, and i'm in the process of
taking my name out of the uploaders list.  Sorry to bail on it, Osamu!
I just don't feel write being named as responsible for it when i no
longer even have python2 on many systems that i care about.

Upstream appears to indicate that getmail for python3 is likely to be a
nearly complete rewrite.

For myself, i've been using the very simple imap-dl (now in mailscripts
0.18, i'm the main author, and Sean Whitton is a very capable
maintainer).  But imap-dl doesn't have the OAUTH mechanism for gmail
built in.  If you wanted to port that mechanism into imap-dl, i'd be
happy to review it, though!

Regards,

  --dkg


signature.asc
Description: PGP signature

Bug#951659: setup-storage should allow default tmpfs settings

[Thomas Lange]

> On Wed, 19 Feb 2020 14:42:22 -0500, Antoine Beaupre  
> said:

> should be to the kernel, which has its own defaults (50% of RAM at the
> time of writing, I believe).
Do you have more details on that?

> It seems there's no way to do that delegation in setup-storage(8)
> right now: if I use `-` as a , I get the following error:
What exactly do you want to delegate?
-- 
regards Thomas

Bug#951669: xdeb: Lintian's new interface for file index operations

[Felix Lechner]

Package: xdeb
Severity: normal
Control: tags -1 + patch
X-Debbugs-CC: debian-lint-ma...@lists.debian.org

Hi,

Lintian has a new interface to access file indices. Please find
attached a patch that converts your package.

The patch was created while the patch from Bug#939171 was already
applied, but it should not make a difference.

Kind regards
Felix Lechner


xdeb-new-lintian-file-index.patch.xz
Description: application/xz

Bug#951668: src:kubectx: fails to migrate to testing for too long

[Paul Gevers]

Source: kubectx
Version: 0.6.2-1
Severity: serious
Control: fixed -1 0.6.3-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug. Your package src:kubectx in its current
version in unstable has been trying to migrate for 375 days. Hence, I am
filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html




signature.asc
Description: OpenPGP digital signature

Bug#951664: php-league-commonmark: new upstream version available

[Robin Gustafsson]

Package: php-league-commonmark
Version: 1.2.2-1
Severity: normal
Control: block 951159 by -1

Dear Maintainer,

Please consider updating to a newer upstream version (>= 1.3.0).

This is blocking one of my ITPs.

Regards,
Robin

Bug#951665: ITP: php-opis-closure -- serializable closures (anonymous functions) for PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 
Control: block 951159 by -1

* Package name: php-opis-closure
  Version : 3.5.1
  Upstream Author : Marius Sarca 
* URL : https://github.com/opis/closure
* License : MIT
  Programming Lang: PHP
  Description : serializable closures (anonymous functions) for PHP

PHP library that can be used to serialize closures (anonymous functions) and
arbitrary objects. It aims to overcome PHP's limitations regarding closure
serialization by providing a wrapper that will make all closures serializable.
.
Key features:
- Serializes any closure and arbitrary objects
- Doesn't use eval for closure serialization or unserialization
- Handles all variables referenced in use(), recursive closures, static
  closures and magic constants
- Automatically resolves all class names, function names and constant names
  used inside the closure
- Track closure's residing source by using the #trackme directive
- Simple and very fast parser
- Proper exception handling for unserialized closures
- Supports cryptographically signed closures
- Provides a reflector for serialized closures
- Automatically detects when the scope and/or the bound object of a closure
  needs to be serialized in order for the closure to work after deserialization


This package is a dependency of php-laravel-framework (ITP #951159).

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951666: ITP: php-league-flysystem -- unified file system API for PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 
Control: block 951159 by -1

* Package name: php-league-flysystem
  Version : 1.0.64
  Upstream Author : Frank de Jonge 
* URL : https://github.com/thephpleague/flysystem
* License : MIT
  Programming Lang: PHP
  Description : unified file system API for PHP

Flysystem is a PHP library providing a filesystem abstraction which allows you
to easily swap out a local filesystem for a remote one.
.
Goals:
- Have a generic API for handling common tasks across multiple file storage
  engines.
- Have consistent output which you can rely on.
- Integrate well with other packages/frameworks.
- Be cacheable.
- Emulate directories in systems that don't support them, like AWS S3.
- Support third party plugins.
- Make it easy to test your filesystem interactions.
- Support streams for big file handling.


This package is a dependency of php-laravel-framework (ITP #951159).

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951667: src:check: fails to migrate to testing for too long

[Paul Gevers]

Source: check
Version: 0.10.0-3
Severity: serious
Control: fixed -1 0.12.0-0.1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug. Your package src:check in its current
version in unstable has been trying to migrate for 435 days. Hence, I am
filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html




signature.asc
Description: OpenPGP digital signature

Bug#921297: FTBFS also with doxygen 1.8.16-1~exp3 from experimental

[Norbert Preining]

severity 921297 normal
retitle 921297 stackengine (tl-l-e) needs listofitems (tl-plain-generic)
thanks

On Wed, 19 Feb 2020, Adrian Bunk wrote:
> > The package texlive-plain-generic contains this file:
> > /usr/share/texlive/texmf-dist/tex/generic/listofitems/listofitems.sty 

There is and never has been a guarantee that all cross package (in TL
terms cross collection) dependencies are completely recorded. Users
are advised to install either texlive-full, or carefull check which
files are needed.

I will discuss with upstream what to do.

Norbert

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

Bug#951349: mecab: Fails to build against ruby2.7

[Lucas Kanashiro]

FYI ruby2.7 is already enabled in unstable (the ruby2.7 transition
already started), so no need to use experimental. Here you can find the
build logs with failures:
https://buildd.debian.org/status/package.php?p=mecab

-- 
Lucas Kanashiro

Bug#951663: src:rng-tools: fails to migrate to testing for too long

[Paul Gevers]

Source: rng-tools
Version: 2-unofficial-mt.14-1
Severity: serious
Control: fixed -1 5-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug. Your package src:rng-tools in its current
version in unstable has been trying to migrate for 444 days. Hence, I am
filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html




signature.asc
Description: OpenPGP digital signature

Bug#951662: src:stringencoders: fails to migrate to testing for too long

[Paul Gevers]

Source: stringencoders
Version: 3.10.3+git20160924-3
Severity: serious
Control: fixed -1 3.10.3+git20180306-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug. Your package src:stringencoders in its
current version in unstable has been trying to migrate for 456 days.
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html




signature.asc
Description: OpenPGP digital signature

Bug#951661: src:osmo-hlr: fails to migrate to testing for too long

[Paul Gevers]

Source: osmo-hlr
Version: 0.2.1-3
Severity: serious
Control: fixed -1 0.2.1-4
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug. Your package src:osmo-hlr in its current
version in unstable has been trying to migrate for 460 days. Hence, I am
filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html




signature.asc
Description: OpenPGP digital signature

Bug#951660: src:phast: fails to migrate to testing for too long

[Paul Gevers]

Source: phast
Version: 1.4+dfsg-1
Severity: serious
Control: fixed -1 1.5+dfsg-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug. Your package src:phast in its current
version in unstable has been trying to migrate for 488 days. Hence, I am
filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html




signature.asc
Description: OpenPGP digital signature

Bug#951281: FTBFS: /usr/bin/ld: cannot find -lpthreads

[Juhani Numminen]

Markus Koschany kirjoitti 19.2.2020 klo 20.32:
> Hello Juani,
> 
> Am 15.02.20 um 09:49 schrieb Juhani Numminen:
> [...]
>> Markus, you have made team uploads of widelands before. I wonder if you
>> could make an upload that adds the patch?
> 
> Could you adjust the patch to use the same mechanism to find SDL2 as in
> openjk?

I actually started to work on that after receiving Simon's message, and
have now pushed the revised patch to a branch for your consideration.

https://salsa.debian.org/games-team/widelands/commit/e470cba2029c459d3ab1bb6c385bfd4746a9dd05

--
Juhani

Bug#951657: ffmpegfs: d/copyright issues

[Norbert Schlia]

Hi,

thanks for the report.

I have updated d/copyright with the license, and the copyright years 
from src/ffmpegfs.h/cc (2008-2013).


ffmpegfs.1 is a generated file, it is build from ffmpegfs.1.txt which is 
listed, I guess this should be sufficient.


Will be fixed in 1.10-3.


Am 19.02.20 um 19:30 schrieb Sean Whitton:

Package: ffmpegfs
Version: 1.10-1

Hello,

Some things found during review in NEW:

I note that Henriksson has relicensed his docs under the GPL or the
GFDL, not just the GFDL.[1]  So d/copyright should be updated to
reflect that.

INSTALL.md needs to be listed in d/copyright as currently d/copyright
implies it is under only the GPL, and does not include all copyright
years.  I think ffmpegfs.1 needs listing too.

src/ffmpegfs.cc, src/ffmpegfs.h has additional copyright years for
Henriksson.

[1]  
https://github.com/khenriks/mp3fs/commit/cfda985adf4ab955bd6ea5830e077cce994816ef


--
*Oblivion Software Development and Internet Services*
Norbert Schlia
Hans-Thoma-Str. 24
76327 Pfinztal
Germany

Telefon:0721 47 05 1112
Fax:0721 47 05 1113
Mobile: 0178 5365230
Steuernr.:  3411/44460


/www: http://www.oblivion-software.eu//

/Pour le Respect de l'Environnement : merci d'éviter d'imprimer ce 
message./
/Rispetto per l'ambiente: Si prega di evitare di stampare questo 
messaggio./
/Пожалуйста, не печатайте это письмо - защита окружающей среды в наших 
руках./
/Por favor, ten en cuenta el medio ambiente antes de imprimir este 
mensaje./

/With regard to the environment: Please avoid printing this message./
/Aus Rücksicht auf die Umwelt drucken Sie bitte diese Nachricht nicht aus./

Bug#951659: setup-storage should allow default tmpfs settings

[Antoine Beaupre]

Package: fai-setup-storage
Version: 5.8.4
Severity: wishlist
File: /usr/sbin/setup-storage
Tags: upstream

The setup-storage(8) command has the following grammar for tmpfs
blocks:

volume ::= tmpfs   
tmpfs_size ::= 
sizespec ::= RAM:[[:digit:]]+%|[[:digit:]]+[kKMGTP%iB]*

This forces a line that looks like the examples in the manpage:

tmpfs   /tmpRAM:20% defaults
tmpfs   /scratch3GiBdefaults

... which is great if you want to control that. But in our
configuration, we're happy to delegate the decision of how big a tmpfs
should be to the kernel, which has its own defaults (50% of RAM at the
time of writing, I believe).

It seems there's no way to do that delegation in setup-storage(8)
right now: if I use `-` as a , I get the following error:

# setup-storage -f "disk-config/gnt-fsn" -X
Starting setup-storage 2.2
Using config file: disk-config/gnt-fsn

  ERROR (line 15):  invalid tmpfs size near " - defaults disk_config
   nvme0n1 disklabel:gpt-bios gpt_bios_part:1 bootable:2
  [...]

  ERROR (line 15): Invalid volume: Was expecting tmpfs size but found "-
   defaults" instead

  ERROR (line 15): Invalid line: Was expecting '\n' but found "tmpfs 
/tmp -
   defaults" instead
Syntax error

(I'll also note the duplicate errors, with the first strangely
containing the entire configuration after the tmpfs keyword, stripped
here for brievety.)

It seems to me "-" should be allowed here, like this:

disk_config tmpfs
tmpfs   /tmp-   defaults

It's allowed in fstab and just worked fine in our previous
configuration.

Thanks!

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

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

Versions of packages fai-setup-storage depends on:
ii  e2fsprogs 1.44.5-1+deb10u3
ii  liblinux-lvm-perl 0.17-2
ii  libparse-recdescent-perl  1.967015+dfsg-2
ii  parted3.2-25
ii  perl  5.28.1-6

Versions of packages fai-setup-storage recommends:
ii  lvm2   2.03.02-3
ii  mdadm  4.1-1

Versions of packages fai-setup-storage suggests:
ii  cryptsetup 2:2.1.0-5+deb10u2
ii  dmsetup2:1.02.155-3
ii  dosfstools 4.1-2
pn  jfsutils   
ii  ntfs-3g1:2017.3.23AR.3-3
ii  reiserfsprogs  1:3.6.27-3
ii  xfsprogs   4.20.0-1

-- no debconf information

Bug#908203: opam in buster

[Anil Madhavapeddy]

On 17 Feb 2020, at 23:25, Stéphane Glondu  wrote:
> 
> Hello,
> 
> It has been brought to my attention that opam doesn't work in stable
> (buster) out of the box. This has been tracked in [1] (fixed in testing
> (bullseye)) and [2]. See in particular comments starting at [3].
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908203
> [2] https://github.com/ocaml/opam/issues/3827
> [3] https://github.com/ocaml/opam/issues/3827#issuecomment-586265289
> 
> Martin Lucina (@mato on GitHub) proposed some changes to improve the
> situation.
> 
> I've tested the following: "opam init" does not work properly without
> the changes (I've killed it because it consumes too much memory). With
> the changes, it fails (in a chroot) because bwrap fails, but "opam init
> --disable-sandboxing" works.
> 
> I've attached the proposed changes. I am considering submitting them to
> buster. Can someone review them and confirm that they work as expected
> (or, at least, that they improve the situation)?
> 

I have reviewed it (but not yet tested it with a binary package build) and
can confirm that it would certainly improve the situation. For all useful
purposes, aspcud no longer scales to the live opam repository, and mccs
does.  This will significantly improve opam in buster if applied.

regards,
Anil

Bug#923032: php7.3-fpm: needs to set the SE Linux context after creating a directory

[Christian Göttsche]

Control: user selinux-de...@lists.alioth.debian.org
Control: usertags -1 selinux

Or one could directly create the directory with the correct SELinux context:

--- php-fpm.init.backup 2020-02-19 19:56:30.837758877 +0100
+++ php-fpm.init2020-02-19 19:56:47.137485779 +0100
@@ -103,7 +103,7 @@
 if [ -r "$TMPFILES" ]; then
while read type path mode user group age argument; do
if [ "$type" = "d" ]; then
-   mkdir $V -p "$path"
+   mkdir $V -pZ "$path"
chmod $V "$mode" "$path"
chown $V "$user:$group" "$path"
fi

Bug#951658: RFS: coinor-cgl/0.60.3+repack1-2 [QA] -- COIN-OR Cut Generation Library

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "coinor-cgl"

 * Package name: coinor-cgl
   Version : 0.60.3+repack1-2
   Upstream Author : [fill in name and email of upstream]
 * URL : https://projects.coin-or.org/Cgl
 * License : EPL-1
 * Vcs : https://salsa.debian.org/science-team/coinor-cgl
   Section : science

It builds those binary packages:

  coinor-libcgl1 - COIN-OR Cut Generation Library
  coinor-libcgl-dev - COIN-OR Cut Generation Library (developer files)
  coinor-libcgl-doc - COIN-OR Cut Generation Library (documentation)

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


  https://mentors.debian.net/package/coinor-cgl

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/coinor-cgl/coinor-cgl_0.60.3+repack1-2.dsc


Changes since the last upload:

   * QA upload.
   * Remove compression on Makefile

Regards,
Håvard

Bug#951549: systemd-fstab-generator: zfs entries in fstab should require zfs-import-scan or zfs-import-cache

[Michael Biebl]

Control: reassign -1 zfs-linux

Am 18.02.2020 um 14:35 schrieb Michael Biebl:
> Am 18.02.2020 um 12:33 schrieb Fabian Grünbichler:
>>
>> ZFS on Linux also ships an (opt-in) mount generator in recent versions, 
>> which should avoid the need to have any fstab entries at all for ZFS 
>> mount points when used together with zfs-zed.
>>
>> https://manpages.debian.org/buster-backports/zfsutils-linux/zfs-mount-generator.8.en.html
> 
> Thanks for your input, Fabian.
> If zfs mounts really need those additional orderings,
> zfs-mount-generator could also amend [1] the .mount units that are
> generated from /etc/fstab by systemd-fstab-generator.
> 
> Regards,
> Michael
> 
> [1] via drop-ins
> 

I'll reassign this issue to the zfs-linux package.
They can better evaluate the situation.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#951411: systemd: user service units not getting precedence

[Michael Biebl]

Am 16.02.2020 um 19:05 schrieb Michael Biebl:
> Control: tags -1 + unreproducible moreinfo
> 
> Am 16.02.20 um 09:08 schrieb westlake:
>> Package: systemd
>> Version: 244-3~bpo10+1
>> Severity: important
>>
>> Dear maintainer,
>>
>> please repair the precedence for the user's service units.
>>
>> having an example.service unit in ~/.config/systemd/user overrides it's
>> counterpart in /usr/lib/systemd/user.
>>
> 
> ~/.config/systemd/user does override /etc/systemd/user and
> /usr/lib/systemd/user. See

[..]

> Please elaborate!


Any followup feedback here or can this issue be closed?


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



signature.asc
Description: OpenPGP digital signature

Bug#950495: /usr/bin/xdg-settings: 735: Bad substitution

[luca.pedrielli]

Il 19/02/20 19:16, Emilio Pozuelo Monfort ha scritto:

On 19/02/2020 18:32, luca.pedrielli wrote:

Il 19/02/20 18:09, Emilio Pozuelo Monfort ha scritto:

Control: forwarded -1 https://gitlab.freedesktop.org/xdg/xdg-utils/issues/10

On 02/02/2020 16:32, luca wrote:

Package: xdg-utils
Version: 1.1.3-1
Severity: normal

/usr/bin/xdg-settings: 735: Bad substitution
-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=KDE

Looks like you're running into
https://gitlab.freedesktop.org/xdg/xdg-utils/issues/10

Cheers,
Emilio

Hi Emilio,

no in my case |read_kde_browser()|doesn't returns an empty string, but
"/usr/bin/firefox" as you can see in the attached log.

the problem is that bash works with x"${browser:0:1}" and dash doesn't. Debian
set /bin/sh as /bin/dash.

the shabang of**xdg-settings is #!/bin/sh

Ok, I see. Can you open an issue in the upstream tracker at [1]?

[1] https://gitlab.freedesktop.org/xdg/xdg-utils/issues/new

Thanks,
Emilio


Done.

https://gitlab.freedesktop.org/xdg/xdg-utils/issues/165

--
Saluti, Luca Pedrielli

Bug#901148: timidity: upgrading broke sound via pulseaudio (patch)

[Joachim Wiedorn]

After many tests I have found the solution about the
bugs around timidity-daemon and pulseaudio.

timidity-daemon installs an system-wide daemon. But
pulseaudio is a user-wide "daemon".

With my appended patch the system-wide daemon will be 
removed and a xdg/autostart script will be installed.

After that timidity together with pulseaudio runs
perfectly.

---
Have a nice day.
Joachim (Germany)


timidity-with-user-wide-daemon.patch.gz
Description: application/gzip


pgpMaLFFNmahw.pgp
Description: Digitale Signatur von OpenPGP

Bug#951281: FTBFS: /usr/bin/ld: cannot find -lpthreads

[Markus Koschany]

Hello Juani,

Am 15.02.20 um 09:49 schrieb Juhani Numminen:
[...]
> Markus, you have made team uploads of widelands before. I wonder if you
> could make an upload that adds the patch?

Could you adjust the patch to use the same mechanism to find SDL2 as in
openjk?

https://salsa.debian.org/games-team/openjk/commit/22fd18c4f2fb01bce65bc8737536c123c5f4bceb

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#951657: ffmpegfs: d/copyright issues

[Sean Whitton]

Package: ffmpegfs
Version: 1.10-1

Hello,

Some things found during review in NEW:

I note that Henriksson has relicensed his docs under the GPL or the
GFDL, not just the GFDL.[1]  So d/copyright should be updated to
reflect that.

INSTALL.md needs to be listed in d/copyright as currently d/copyright
implies it is under only the GPL, and does not include all copyright
years.  I think ffmpegfs.1 needs listing too.

src/ffmpegfs.cc, src/ffmpegfs.h has additional copyright years for
Henriksson.

[1]  
https://github.com/khenriks/mp3fs/commit/cfda985adf4ab955bd6ea5830e077cce994816ef

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#950495: /usr/bin/xdg-settings: 735: Bad substitution

[Emilio Pozuelo Monfort]

On 19/02/2020 18:32, luca.pedrielli wrote:
> Il 19/02/20 18:09, Emilio Pozuelo Monfort ha scritto:
>> Control: forwarded -1 https://gitlab.freedesktop.org/xdg/xdg-utils/issues/10
>>
>> On 02/02/2020 16:32, luca wrote:
>>> Package: xdg-utils
>>> Version: 1.1.3-1
>>> Severity: normal
>>>
>>> /usr/bin/xdg-settings: 735: Bad substitution
>>> -- Package-specific info:
>>> Desktop environment: XDG_CURRENT_DESKTOP=KDE
>> Looks like you're running into
>> https://gitlab.freedesktop.org/xdg/xdg-utils/issues/10
>>
>> Cheers,
>> Emilio
> 
> Hi Emilio,
> 
> no in my case |read_kde_browser()|doesn't returns an empty string, but
> "/usr/bin/firefox" as you can see in the attached log.
> 
> the problem is that bash works with x"${browser:0:1}" and dash doesn't. Debian
> set /bin/sh as /bin/dash.
> 
> the shabang of**xdg-settings is #!/bin/sh

Ok, I see. Can you open an issue in the upstream tracker at [1]?

[1] https://gitlab.freedesktop.org/xdg/xdg-utils/issues/new

Thanks,
Emilio

Bug#844049: Bug#951593: cups-filters: Cups filters has hard depends on imagemagick makes unnistallable

[PICCORO McKAY Lenz]

El mié., 19 de feb. de 2020 a la(s) 12:56, Didier 'OdyX' Raboud
(o...@debian.org) escribió:
>
>  Hello Lenz, and thanks for taking the time to report this bug.

only two persons can made it! but what happened if not? do you know
that the report bug seems a bit complicateed for mayority of persons?
i can understand that of course it's not a simle piece of a single
software.. but.. this problem has several mounts happened and nobody
takes the care!

>This was fixed in 1.14.0-2; and is therefore already fixed in stable, testing
> and unstable. It is arguably a bug (but not a grave one) in versions before
> stable, but I (as maintainer) will not get it fixed in these ancient versions,
> as that would clearly be a disruptive change, unacceptable for Debian
> (old)stable versions.

so stable has no import6ance? interesting.. we must use unstalbel due
unstable are the target stable to bugfixeds, puff
>
> Le mercredi, 19 février 2020, 16.52:05 h CET PICCORO McKAY Lenz a écrit :
> > please we must said hard words to make this some noise and take attention?
> Threats of any kind are _not welcome_ in Debian; please reconsider the use of
> this type of language. (Also, it doesn't _motivate_ me to help you, much the
> contrary)

seems in history of debian only noise cause changes.. see systemd
problems! see etch migration.. see DEvuan migration? where goes the
quality?

>
> --
> OdyX

Bug#951516: gvfs: gvfs-daemons fails to install on non-linux boxes

[Andreas Henriksson]

Hello,

On Mon, Feb 17, 2020 at 07:07:00PM +0100, Svante Signell wrote:
> Source: gvfs
> Severity: important
> Version: 1.42.2-1
> Tags: patch
> User: debian-h...@lists.debian.org
> Usertags: hurd
> X-Debbugs-CC: debian-h...@lists.debian.org
> 
> Hello,
> 
> The latest version of gvfs fails to install on non-linux boxes due to the
> dependency on lsof for gvfs-daemons, [...]
> Attached are two patches, one for control and one for control.in. 
[...]

Please send a merge-request on salsa.debian.org or this will easily get
lost in all the noise in the BTS.

Regards,
Andreas Henriksson

Bug#932373: proftpd error reading passphrase for SFTPHostKey

[Hilmar Preuße]

Control: tags -1 + pending

Am 18.07.2019 um 16:14 teilte Markus Raps mit:

Hi,

> I think there is something wrong with the sftp module in buster
> because proftpd cant read ssh Host keys
> 
> i also tried to recreate the keys with dpkg-reconfigure openssh-server
> or manually by ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key
> and i tried to create keys on a Debian 9 machine and copied them on the
> Debian 10 machine.
> so i think it isn't the key its the module.
> 
According to upstream this has been solved in 1.3.6c (soon to be
uploaded). Tag as pending.

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



signature.asc
Description: OpenPGP digital signature

Bug#921297: FTBFS also with doxygen 1.8.16-1~exp3 from experimental

[Adrian Bunk]

Control: reassign -1 texlive-latex-extra 2019.20191208-1
Control: retitle -1 texlive-latex-extra: stackengine needs listofitems in 
texlive-plain-generic
Control: reassign 921300 texlive-latex-extra 2019.20191208-1
Control: forcemerge -1 921300
Control: affects -1 src:qevercloud src:frobby

On Thu, Oct 24, 2019 at 06:30:08PM +0200, Paolo Greppi wrote:
> Same error as with doxygen 1.8.15.
> 
> The package texlive-plain-generic contains this file:
> /usr/share/texlive/texmf-dist/tex/generic/listofitems/listofitems.sty 

Looks like a bug in texlive-latex-extra to me:

$ cat test.tex 
\documentclass{article}
\usepackage{stackengine}
\begin{document}
.
\end{document}
$ latex test.tex 
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) 
(preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2020-02-02> patch level 2
L3 programming layer <2020-02-14>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2019/12/20 v1.4l Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/stackengine/stackengine.sty
(/usr/share/texlive/texmf-dist/tex/latex/etoolbox/etoolbox.sty)

! LaTeX Error: File `listofitems.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)

Enter file name: 


> Paolo 

cu
Adrian

Bug#951656: r-cran-lwgeom: FTBFS with PROJ 7.0.0 (ERROR: lazy loading failed for package 'lwgeom')

[Bas Couwenberg]

Source: r-cran-lwgeom
Version: 0.2-1-1
Severity: important
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: proj-7.0

Dear Maintainer,

Your package FTBFS with PROJ 7 from experimental:

 ** byte-compile and prepare package for lazy loading
 double free or corruption (!prev)
 Aborted
 ERROR: lazy loading failed for package 'lwgeom'

The full buildlog is attached.

Kind Regards,

Bas
dpkg-checkbuilddeps: error: Unmet build dependencies: r-cran-rcpp r-cran-units 
r-cran-sf
W: Unmet build-dependency in source
dh clean --buildsystem R
   dh_auto_clean -O--buildsystem=R
   dh_autoreconf_clean -O--buildsystem=R
   dh_clean -O--buildsystem=R
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building r-cran-lwgeom using existing 
./r-cran-lwgeom_0.2-1.orig.tar.gz
dpkg-source: info: building r-cran-lwgeom in r-cran-lwgeom_0.2-1-2.debian.tar.xz
dpkg-source: info: building r-cran-lwgeom in r-cran-lwgeom_0.2-1-2.dsc
I: Generating source changes file for original dsc
dpkg-genchanges: info: not including original source code in upload
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.24003
I: forking: cp -al /var/cache/pbuilder/base-sid+rebuild.cow 
/var/cache/pbuilder/build/cow.24003
I: removed stale ilistfile /var/cache/pbuilder/build/cow.24003/.ilist
I: forking: chroot /var/cache/pbuilder/build/cow.24003 
cowdancer-ilistcreate /.ilist 'find . -xdev -path ./home -prune -o \( \( -type 
l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ''
I: Invoking pbuilder
I: forking: pbuilder build --debbuildopts  --debbuildopts  --buildplace 
/var/cache/pbuilder/build/cow.24003 --buildresult /var/cache/pbuilder/result/ 
--mirror http://ftp.nl.debian.org/debian/ --distribution sid --no-targz 
--internal-chrootexec 'chroot /var/cache/pbuilder/build/cow.24003 cow-shell' 
/home/bas/tmp/debian/r-cran-lwgeom_0.2-1-2.dsc
I: Running in no-targz mode
I: pbuilder: network access will be disabled during build
I: Current time: Wed Feb 19 15:28:24 CET 2020
I: pbuilder-time-stamp: 1582122504
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage 
for details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [/home/bas/tmp/debian/r-cran-lwgeom_0.2-1-2.dsc]
I: copying [/home/bas/tmp/debian/r-cran-lwgeom_0.2-1.orig.tar.gz]
I: copying [/home/bas/tmp/debian/r-cran-lwgeom_0.2-1-2.debian.tar.xz]
I: Extracting source
dpkg-source: warning: extracting unsigned source package 
(r-cran-lwgeom_0.2-1-2.dsc)
dpkg-source: info: extracting r-cran-lwgeom in r-cran-lwgeom-0.2-1
dpkg-source: info: unpacking r-cran-lwgeom_0.2-1.orig.tar.gz
dpkg-source: info: unpacking r-cran-lwgeom_0.2-1-2.debian.tar.xz
I: using fakeroot in build.
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper-compat (= 12), dh-r, r-base-dev, r-cran-rcpp, r-cran-units, 
r-cran-sf, libproj-dev, libgeos-dev
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 14427 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on debhelper-compat (= 12); however:
  Package debhelper-compat is not installed.
 pbuilder-satisfydepends-dummy depends on dh-r; however:
  Package dh-r is not installed.
 pbuilder-satisfydepends-dummy depends on r-base-dev; however:
  Package r-base-dev is not installed.
 pbuilder-satisfydepends-dummy depends on r-cran-rcpp; however:
  Package r-cran-rcpp is not installed.
 pbuilder-satisfydepends-dummy depends on r-cran-units; however:
  Package r-cran-units is not installed.
 pbuilder-satisfydepends-dummy depends on r-cran-sf; however:
  Package r-cran-sf is not installed.
 pbuilder-satisfydepends-dummy depends on libproj-dev; however:
  Package libproj-dev is not installed.
 pbuilder-satis

Bug#951655: r-cran-sf: FTBFS with PROJ 7.0.0 (configure: error: proj_api.h not found in standard or given locations.)

[Bas Couwenberg]

Source: r-cran-sf
Version: 0.8-1+dfsg-1
Severity: important
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: proj-7.0

Dear Maintainer,

Your package FTBFS with PROJ 7 from experimental:

 configure: error: proj_api.h not found in standard or given locations.

The full buildlog is attached.

Kind Regards,

Bas
dpkg-checkbuilddeps: error: Unmet build dependencies: r-cran-classint (>= 
0.4-1) r-cran-dbi (>= 0.8) r-cran-magrittr r-cran-rcpp (>= 0.12.18) 
r-cran-units libgdal-dev
W: Unmet build-dependency in source
dh clean --buildsystem R
   dh_auto_clean -O--buildsystem=R
   dh_autoreconf_clean -O--buildsystem=R
   dh_clean -O--buildsystem=R
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building r-cran-sf using existing 
./r-cran-sf_0.8-1+dfsg.orig.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building r-cran-sf in r-cran-sf_0.8-1+dfsg-2.debian.tar.xz
dpkg-source: info: building r-cran-sf in r-cran-sf_0.8-1+dfsg-2.dsc
I: Generating source changes file for original dsc
dpkg-genchanges: info: not including original source code in upload
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.340
I: forking: cp -al /var/cache/pbuilder/base-sid+rebuild.cow 
/var/cache/pbuilder/build/cow.340
I: removed stale ilistfile /var/cache/pbuilder/build/cow.340/.ilist
I: forking: chroot /var/cache/pbuilder/build/cow.340 cowdancer-ilistcreate 
/.ilist 'find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a 
-links +1 -print0 \) | xargs -0 stat --format '%d %i ''
I: Invoking pbuilder
I: forking: pbuilder build --debbuildopts  --debbuildopts  --buildplace 
/var/cache/pbuilder/build/cow.340 --buildresult /var/cache/pbuilder/result/ 
--mirror http://ftp.nl.debian.org/debian/ --distribution sid --no-targz 
--internal-chrootexec 'chroot /var/cache/pbuilder/build/cow.340 cow-shell' 
/home/bas/tmp/debian/r-cran-sf_0.8-1+dfsg-2.dsc
I: Running in no-targz mode
I: pbuilder: network access will be disabled during build
I: Current time: Wed Feb 19 08:33:14 CET 2020
I: pbuilder-time-stamp: 1582097594
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage 
for details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [/home/bas/tmp/debian/r-cran-sf_0.8-1+dfsg-2.dsc]
I: copying [/home/bas/tmp/debian/r-cran-sf_0.8-1+dfsg.orig.tar.xz]
I: copying [/home/bas/tmp/debian/r-cran-sf_0.8-1+dfsg-2.debian.tar.xz]
I: Extracting source
dpkg-source: warning: extracting unsigned source package 
(r-cran-sf_0.8-1+dfsg-2.dsc)
dpkg-source: info: extracting r-cran-sf in r-cran-sf-0.8-1+dfsg
dpkg-source: info: unpacking r-cran-sf_0.8-1+dfsg.orig.tar.xz
dpkg-source: info: unpacking r-cran-sf_0.8-1+dfsg-2.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying exclude_test_requiring_rgeos.patch
dpkg-source: info: applying exclude_test_requiring_rgdal.patch
I: using fakeroot in build.
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper-compat (= 12), dh-r, r-base-dev, r-cran-classint (>= 0.4-1), 
r-cran-dbi (>= 0.8), r-cran-magrittr, r-cran-rcpp (>= 0.12.18), r-cran-units, 
libgdal-dev
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 14426 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on debhelper-compat (= 12); however:
  Package debhelper-compat is not installed.
 pbuilder-satisfydepends-dummy depends on dh-r; however:
  Package dh-r is not installed.
 pbuilder-satisfydepends-dummy depends on r-base-dev; however:
  Package r-base-dev is not installed.
 pbuilder-satisfydepends-dummy depends on r-cran-classint (>= 0.4-1); however:
  Package r-cran-classint is not installed.
 pbuilder-

Bug#950495: /usr/bin/xdg-settings: 735: Bad substitution

[luca.pedrielli]

Il 19/02/20 18:09, Emilio Pozuelo Monfort ha scritto:

Control: forwarded -1 https://gitlab.freedesktop.org/xdg/xdg-utils/issues/10

On 02/02/2020 16:32, luca wrote:

Package: xdg-utils
Version: 1.1.3-1
Severity: normal

/usr/bin/xdg-settings: 735: Bad substitution
-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=KDE

Looks like you're running into
https://gitlab.freedesktop.org/xdg/xdg-utils/issues/10

Cheers,
Emilio


Hi Emilio,

no in my case |read_kde_browser()|doesn't returns an empty string, but 
"/usr/bin/firefox" as you can see in the attached log.


the problem is that bash works with x"${browser:0:1}" and dash doesn't. Debian 
set /bin/sh as /bin/dash.

the shabang of**xdg-settings is #!/bin/sh

 


--
Saluti, Luca Pedrielli

Bug#951654: new upstream (5.0.2)

[Daniel Baumann]

Package: suricata
Severity: wishlist

Hi,

thank you very much for maintaining suricata in Debian.

It would be nice if you could upgrade to the current upstream version
(5.0.2) and upload it to unstable.

Regards,
Daniel

Bug#950495: /usr/bin/xdg-settings: 735: Bad substitution

[Emilio Pozuelo Monfort]

Control: forwarded -1 https://gitlab.freedesktop.org/xdg/xdg-utils/issues/10

On 02/02/2020 16:32, luca wrote:
> Package: xdg-utils
> Version: 1.1.3-1
> Severity: normal
> 
> /usr/bin/xdg-settings: 735: Bad substitution

> -- Package-specific info:
> Desktop environment: XDG_CURRENT_DESKTOP=KDE

Looks like you're running into
https://gitlab.freedesktop.org/xdg/xdg-utils/issues/10

Cheers,
Emilio

Bug#951653: lintian: provide way to track systemd services vs init.d services

[Lucas Nussbaum]

Package: lintian
Version: 2.52.0~bpo10+1
Severity: wishlist

Hi,

In the context of https://trends.debian.net/, it would be interesting to
track the status of packages shipping services, to know whether
maintainers are dropping init.d scripts.

This would ideally require:
- a tag to indicate whether a package ships a init.d script
- a tag to indicate whether a package ships a systemd service (excluding
  .service files for matching timer or path units, as already done
  elsewhere in the code).
- a tag to indicate whether there are init.d scripts without
  corresponding systemd services
  (omitted-systemd-service-for-init.d-script,
  missing-systemd-service-for-init.d-script, and
  missing-systemd-service-for-init.d-rcS-script would do)
- similarly, tags to indicate missing init.d scripts for systemd
  services

That way, I could put together a graph with packages shipping services,
classifying them into:
- packages with missing init.d scripts and missing systemd services (you
never know)
- packages with missing init.d scripts
- packages with missing service units
- packages with matching init.d scripts and service units

I might work on that when I have time, but I'm unlikely to find time.

Lucas



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

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

Versions of packages lintian depends on:
ii  binutils 2.31.1-16
ii  bzip21.0.6-9.2~deb10u1
ii  diffstat 1.62-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.35-4+deb10u1
ii  gettext  0.19.8.1-9
ii  gpg  2.2.12-1+deb10u1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.34+b1
ii  libarchive-zip-perl  1.64-1
ii  libberkeleydb-perl   0.55-2
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.40-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b2
ii  libclone-perl0.41-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.72-1
ii  libipc-run-perl  20180523.0-1
ii  libjson-perl 4.02000-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003004-2
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2+deb10u1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-libxml-perl   2.0134+dfsg-1
ii  libyaml-libyaml-perl 0.76+repack-1
ii  man-db   2.8.5-2
ii  patchutils   0.3.4-2
ii  perl [libdigest-sha-perl]5.28.1-6
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-16
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#951151: polymake: test failure on mips64el

[Benjamin Lorenz]

On 13/02/2020 16.53, Benjamin Lorenz wrote:
> On 13/02/2020 13.18, David Bremner wrote:
>> Benjamin Lorenz  writes:
 It looks like it's flint related?
>>>
>>> Yes, I think this is a bug in flint and for now I suggest disabling the
>>> flint-interface of polymake with the configure option --without-flint on
>>> mips64el. This has basically no functionality loss as polymake will use
>>> its own generic polynomial arithmetic instead (it will be somewhat slower).
>>> Currently rebuilding polymake to check the testsuite again but this will
>>> take some time and I will report back tomorrow.
>>>
>>
>> The easy thing would be to disable it everywhere. It is also possible to
>> do it on an architecture specific basis. Do you think the (small) added
>> complexity of the latter is worth it?
> 
> It seems we might need some extra stuff for mips64el anyway as I see
> some weird segfaults even without flint (at different testcases).

I finally got this running on mips64el:
1) update to polymake 4.0r1, this includes:
   - a (slightly adjusted) fix for gmp 6.2
   - a fix for the TERM issue in the reproducible builds (FTBFS)
   - disables a libnormaliz test when libnormaliz is not configured
   - and some other bugfixes
2) switch off both flint and libnormaliz on mips64el with:
   --without-flint --without-libnormaliz
   The normaliz package also runs into a similar flint crash as it also
uses flint for polynomial arithmetic.
   Switching off flint for all architectures would be ok but I really
want to keep libnormaliz active on all other architectures.
   I have reported the flint crash upstream:
   https://github.com/wbhart/flint2/issues/614
3) switch the linker on mips64el:
   add -fuse-ld=bfd to LDFLAGS
   by default polymake will use -fuse-ld=gold if it is available but
then exception handling doesn't seem to work on mips64el and I really
don't want to investigate this any further.

Benjamin

Bug#951652: upgrade-reports: tortoisehg fails, missing python-qscintilla2 and pyqt4-dev-tools

[ecm]

Package: upgrade-reports
Severity: important


Dear Maintainer,

On 2020-02-08 Saturday, upgrading Debian bullseye uninstalled the libqt4-*,
libqtcore4, python-qscintilla2, pyqt4-dev-tools, and python-qt4 packages. They
are no longer available from Debian's testing (bullseye) repos.

(The page at https://bitbucket.org/tortoisehg/thg/wiki/developers/Linux lists
that pyqt4-dev-tools and python-qscintilla2 should be installed in Debian to
run thg.)

A few days later I closed thg and then re-opened it. Since then, it gives an
error on startup. (See end of report for full error text.)

I tried installing the following packages without success:

* python-pyqt5
* libqscintilla2-qt5-15
* libqscintilla2-qt5-l10n
* python3-pyqt5
* python3-pyqt5.qsci
* pyqt5-dev
* pyqt5.qsci-dev
* libqscintilla2-qt5-dev


I also tried adding the buster repositories to synaptic and installing python-
qscintilla2 and pyqt4-dev-tools manually again. This kept reporting broken
dependencies in synaptic. Using apt-get install I was able to finish this, but
it removed many qt5 libraries and also vlc and virtualbox (from the virtualbox
repos).

I also looked into installing qscintilla manually, but the versions available
from https://pypi.org/project/QScintilla/ seem to be exclusive to Python3.

I did report this bug earlier to tortoisehg but have not yet received an answer
there: https://bitbucket.org/tortoisehg/thg/issues/5519/debian-bullseye-python-
qscintilla2-package


Full error text:

#!python
** Mercurial version (5.2.2).  TortoiseHg version (5.1+367-9e3bf37dd711)
** Command:
** CWD: /home/evln
** Encoding: UTF-8
** Extensions loaded: record, strip, mq, transplant, eol, fetch, graphlog,
children, churn, hgk, convert, purge, rebase, patchbomb, histedit,
tortoisehg.util.configitems
** Python version: 2.7.17 (default, Jan 19 2020, 19:54:54) [GCC 9.2.1
20200110]
** System: Linux arona 5.4.0-3-amd64 #1 SMP Debian 5.4.13-1 (2020-01-19)
x86_64
** Qt-5.12.5 PyQt-5.14.1 QScintilla-(unknown)
Traceback (most recent call last):
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/run.py", line
138, in dispatch
return _runcatch(u, args)
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/run.py", line
342, in _runcatch
return runcommand(ui, args)
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/run.py", line
436, in runcommand
return _runcommand(lui, options, cmd, d)
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/run.py", line
488, in _runcommand
return checkargs()
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/run.py", line
441, in checkargs
return cmdfunc()
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/run.py", line
435, in 
**pycompat.strkwargs(cmdoptions))
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/qtapp.py", line
465, in __call__
dlg, reporoot = self._createdialog(dlgfunc, args, opts)
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/qtapp.py", line
529, in _createdialog
return dlgfunc(self._ui, *args, **opts), reporoot
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1845, in
check
return func(*args, **kwargs)
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/run.py", line
1057, in log
w = _workbench(ui, *pats, **opts)
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/run.py", line
527, in _workbench
w = qtrun.createWorkbench()
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/qtapp.py", line
561, in createWorkbench
self._workbench = workbench.Workbench(
  File "/usr/lib/python2.7/dist-
packages/hgdemandimport/demandimportpy2.py", line 157, in __getattr__
self._load()
  File "/usr/lib/python2.7/dist-
packages/hgdemandimport/demandimportpy2.py", line 97, in _load
_origimport, head, globals, locals, None, level
  File "/usr/lib/python2.7/dist-
packages/hgdemandimport/demandimportpy2.py", line 44, in _hgextimport
return importfunc(name, globals, *args, **kwargs)
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/workbench.py",
line 56, in 
from .docklog import LogDockWidget
  File "/usr/lib/python2.7/dist-
packages/hgdemandimport/demandimportpy2.py", line 257, in _demandimport
_origimport, name, globals, locals, level=level
  File "/usr/lib/python2.7/dist-
packages/hgdemandimport/demandimportpy2.py", line 44, in _hgextimport
return importfunc(name, globals, *args, **kwargs)
  File "/media/ssd-data/coding/proj/thg/thg/tortoisehg/hgqt/docklog.py",
line 12, in 
from .qsci import (
  File "/usr/lib/python2.7/dist-
packages/hgdemandimport/demandimportpy2.py", line 181, in _demandimport
return _hgextimport(_origimport, name, globals, locals, fromlist,
level)
  File "/usr/lib/python2.7/dist-
packages/hgdemandimport/demandimpo

Bug#951216: poppler-utils: pdfinfo incorrectly reports date metadata under reprotest

[Jeff]

Strangely, the dummy package built fine (i.e. only reproducibility
problems, not build-chain problems) on a Mint 19.3-based machine,
which allowed me to try out Vagrant's suggestions[1]:

> This *should* vary only time:

>  reprotest --variations=-all,+time

> and and only timezome:

>  reprotest --variations=-all,+timezone

 reprotest --variations=-all,+time .

built fine. But

 reprotest --variations=-all,+timezone .

did not:

 -CreationDate:   Mon Dec 31 00:00:00 2018 GMT
 -ModDate:Mon Dec 31 00:00:00 2018 GMT
 +CreationDate:   Tue Jan  1 02:00:00 2019 GMT
 +ModDate:Tue Jan  1 02:00:00 2019 GMT

But given that Chris couldn't reproduce the problem outside reprotest,
my suggestion would be for someone with knowledge of the internals of
reprotest to take a look and understand what is going on.

[1]
https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20200203/012103.html




signature.asc
Description: OpenPGP digital signature

Bug#951629: RFS: timeshift/19.01+ds-2.1 [NMU] [RC] -- System restore utility

[Steve M]

On Wed, 19 Feb 2020 10:05:49 -0500 Boyuan Yang  wrote:

> Hi Steve, wrar,

> 

> On Wed, 19 Feb 2020 12:40:15 +0500 Andrey
Rahmatullin  wrote:

> > Control: tags -1 + moreinfo

> > 

> > Unfortunately you ignored 

> https://lists.debian.org/debian-mentors/2020/02/msg00124.html

> > lintian even tells you about the mangled
changelog.

> 

> I'm letting you know that I am keeping an eye on
package timeshift since I

> granted the original maintainer DM permission. I
know the original maintainer

> privately and it looks like he is extremely unlikely
to work on timeshift (and

> any other Debian work) in the foreseeable future.
For now, I will not work on

> fixing it or salvaging the package since it's a
perfectly valuable chance for

> you (Steve) to practice and participate in Debian's
work.

> 

> Steve: I took a look at the source package you
provided on mentors.debian.net.

> Actually wrar gave some valuable advice and there
are some bugs that *must* be

> fixed before anyone accept your work (namely the
duplicated changelog

> entries). If you are unsure about what changes you
made, please take advantage

> of the debdiff(1) tool and check the differences
between the existing version

> and your proposed version.

> 

> Please *DO* fix it and let us know when you are
ready. I will be glad to help

> you upload this NMU. Let me know if you have any
doubts.

> 

> -- 

> Thanks,

> Boyuan YangThank you both and kokoye2007for your feedback and for enduring my ignorance.wrar, for some reason I did not receive your very helpful reply on debian mentors that you linked me to. I will of course now follow your advise and clean things up.Boyua, I would be happy to assist or take over from the current maintainer in whatever capacity they desire.Thanks-Steve Meliza

Bug#915386: . libfdk-aac-dev: New upstream version 2.0.0 available

[GMiller]

Hello:

For your information, below is the posting that I made to the subject 
Debian Bug#915386:



    Completion of Dream Bug#907576 requires the newer codec of 
libfdk-aac-dev 2.2.0, which has also been requested by Bug#915386 
(latest at Github is 2.0.1). Dream cannot function properly with the 
current 1.6 codec in Debian.


    Is anyone working to complete 915386? I am willing to try to 
package it (ie, ITP), subject to my limited experience in Debian.


    Suggestions or help is welcome.



Thank You,

Garie Miller



 
--
Take back your privacy. Switch to www.StartMail.com

Bug#951631: Acknowledgement (lightning: UI elements show what looks like XML errors)

[Bob Ham]

I should also point out that the calendar is not accessible which is
kind of critical.

Bug#742705: remind: sunrise() and sunset() are significantly different from other sources

[Dianne Skoll]

Hi,

Please note that in Remind, longitudes are positive for the Western hemisphere
and negative for the Eastern hemisphere.  This is unfortunately non-standard.

I believe the original submitter should set $LongDeg to -8 and $LongMin to -50.

Regards,

Dianne.

Bug#936055: t/unthreaded.t test failing

[gregor herrmann]

Control: severity -1 serious

On Wed, 19 Feb 2020 14:16:52 +0100, Héctor Orón Martínez wrote:

>   This issue is now affecting GDB 9.1 autopkgtests and preventing it from 
> migrating to testing.
>   
> https://ci.debian.net/data/autopkgtest/testing/amd64/liba/libapp-stacktrace-perl/4328197/log.gz
>   
> https://ci.debian.net/data/autopkgtest/testing/arm64/liba/libapp-stacktrace-perl/4314744/log.gz

Oh, one of the bugs which "hide":
https://ci.debian.net/packages/liba/libapp-stacktrace-perl/testing/amd64/
is all green, and after clicking on britney it turns red:
https://ci.debian.net/user/britney/jobs?package=libapp-stacktrace-perl&suite[]=testing&arch[]=amd64

Anyway, in the meantime it also FTBFS in unstable:

# [Thread debugging using libthread_db enabled]
# Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
# 0x7f7b77cc1047 in select () from /lib/x86_64-linux-gnu/libc.so.6
# à|ÚU:101
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# [Inferior 1 (process 25884) detached]

#   Failed test at t/unthreaded.t line 55.
#   '[Thread debugging using libthread_db enabled]
# Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
# 0x7f7b77cc1047 in select () from /lib/x86_64-linux-gnu/libc.so.6
# à|ÚU:101
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# à|ÚU:106
# [Inferior 1 (process 25884) detached]
# '
# doesn't match '(?^mx:
# (?:
# ^t/unthreaded\.t:\d+\n
# ){10}
# )'
# Looks like you failed 1 test of 5.
t/unthreaded.t  
1..5
not ok 1
ok 2 - Reaped pstack
ok 3 - exit(0)
ok 4 - No signals
ok 5 - No core dump
# Alive top 1582127930: 1 middle: 1
# Alive top 1582127931: 1 middle: 0
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/5 subtests 

Test Summary Report
---
t/unthreaded.t  (Wstat: 256 Tests: 5 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=4, Tests=6,  2 wallclock secs ( 0.03 usr  0.01 sys +  0.96 cusr  0.09 
csys =  1.09 CPU)
Result: FAIL

(I _think_ that's yet another different error.)


In testing with gdb 8.3.1 the package still builds:

# [Thread debugging using libthread_db enabled]
# Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
# 0x7f1b9eb77047 in select () from /lib/x86_64-linux-gnu/libc.so.6
# t/unthreaded.t:101
# t/unthreaded.t:106
# t/unthreaded.t:106
# t/unthreaded.t:106
# t/unthreaded.t:106
# t/unthreaded.t:106
# t/unthreaded.t:106
# t/unthreaded.t:106
# t/unthreaded.t:106
# t/unthreaded.t:106
# t/unthreaded.t:106
# [Inferior 1 (process 3207) detached]
t/unthreaded.t  
1..5
ok 1
ok 2 - Reaped pstack
ok 3 - exit(0)
ok 4 - No signals
ok 5 - No core dump
# Alive top 1582128303: 1 middle: 1
# Alive top 1582128304: 1 middle: 0
ok



Cheers,
gregor


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Pink Floyd: Another Brick In The Wall (part 1)


signature.asc
Description: Digital Signature

Bug#948775: Re: Bug#948775: RFS: ukui-interface/1.0.0-1 [ITP] -- Provides the interface for system configuration

[handsome_feng]

Hi, Alexis,


Thanks for your advice! :)


> You should probably add a prefix to packages names to avoid cluttering
> the package namespace.
> For example:
> libprint0=> libukui-print0
> backgroundserver => ukui-backgroundserver
> Same for the underlying binaries if they don't have "ukui" in their name.
> The rationale is to avoid too generic names that could already exist or
> better suitted to more common tools.
> For example, "libsubversion0" would better be the name of a package for
> SVN implementation (actually, the subversion source package use the name
> of libsvn1 for its binary library package).
I have renamed those packages and binaries, and upload it to the mentors, :)


> Also, maybe add a meta package that depends on all these package with
> Depends, Recommends or Suggests as appropriate so someone that want ukui
> only have to select one package instead of all parts of it. (This
> package would be an equivalent to, say, kde-standard for KDE).Since it's 
> mainly used to be a library, the developer only needs add the 
> correspondinglibfoo-dev to the build-depends to use the corresponding 
> functions. So maybe it'sno need to add a meta package?

Thanks again!handsome_feng

Bug#931930: firmware-misc-nonfree: Please, include i915/icl_dmc_ver1_07.bin

[Romain Perier]

On Fri, Jan 31, 2020 at 06:10:01PM -0800, Todd Troxell wrote:
> Is there a reason why it's not included?  I can make a patch and try it...

Hi,

icl_dmc_ver1_07.bin and bxt_huc_ver01_8_2893.bin seems to be included already,
see 
https://salsa.debian.org/kernel-team/firmware-nonfree/blob/master/debian/config/misc-nonfree/defines

At least in 20190717-1.

Messages about "W: Possible missing firmware  for module " is
thrown by the hook functions of initramfs-tools, when a kmod requires
firmware images not found on your systemd in /lib/firmware. Are you sure
that your firmware packages are up-to-date ?

Regards,
Romain


signature.asc
Description: PGP signature

Bug#951262: Please set CGO_XFLAGS with dpkg-buildflags

[Shengjing Zhu]

On Wed, Feb 19, 2020 at 9:44 PM Tong Sun  wrote:
> If no objection to Shengjing's proposal, I'll take a look and try to fix it...
>

It has been fixed, thanks though.

-- 
Shengjing Zhu

Bug#844049: cups-filters: Cups filters has hard depends on imagemagick makes unnistallable

[PICCORO McKAY Lenz]

seems  844049 and 951593are also affected!

please we must said hard words to make this some noise and take attention?

cups-filters are the problem.. so then make something!


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#951651: lsb_release does not check for existence of "apt-cache"

[Daniel Bryant]

Package: lsb-release
Version: 11.1.0

There is a bug with lsb_release in that it does not check for the existence
of apt-cache before it tries to execute it. If apt-cache is not present on
the system this will result in the following error:

[  111s] Traceback (most recent call last):
[  111s]   File "/usr/bin/lsb_release", line 95, in 
[  111s] main()
[  111s]   File "/usr/bin/lsb_release", line 59, in main
[  111s] distinfo = lsb_release.get_distro_information()
[  111s]   File "/usr/lib/python3/dist-packages/lsb_release.py", line 356,
in get_distro_information
[  111s] distinfo = guess_debian_release()
[  111s]   File "/usr/lib/python3/dist-packages/lsb_release.py", line 290,
in guess_debian_release
[  111s] rinfo = guess_release_from_apt()
[  111s]   File "/usr/lib/python3/dist-packages/lsb_release.py", line 195,
in guess_release_from_apt
[  111s] releases = parse_apt_policy()
[  111s]   File "/usr/lib/python3/dist-packages/lsb_release.py", line 178,
in parse_apt_policy
[  111s] close_fds=True).communicate()[0].decode('utf-8')
[  111s]   File "/usr/lib/python3.7/subprocess.py", line 800, in __init__
[  111s] restore_signals, start_new_session)
[  111s]   File "/usr/lib/python3.7/subprocess.py", line 1551, in
_execute_child
[  111s] raise child_exception_type(errno_num, err_msg, err_filename)
[  111s] FileNotFoundError: [Errno 2] No such file or directory:
'apt-cache': 'apt-cache'
[  112s] Traceback (most recent call last):
[  112s]   File "/usr/bin/lsb_release", line 95, in 
[  112s] main()
[  112s]   File "/usr/bin/lsb_release", line 59, in main
[  112s] distinfo = lsb_release.get_distro_information()
[  112s]   File "/usr/lib/python3/dist-packages/lsb_release.py", line 356,
in get_distro_information
[  112s] distinfo = guess_debian_release()
[  112s]   File "/usr/lib/python3/dist-packages/lsb_release.py", line 290,
in guess_debian_release
[  112s] rinfo = guess_release_from_apt()
[  112s]   File "/usr/lib/python3/dist-packages/lsb_release.py", line 195,
in guess_release_from_apt
[  112s] releases = parse_apt_policy()
[  112s]   File "/usr/lib/python3/dist-packages/lsb_release.py", line 178,
in parse_apt_policy
[  112s] close_fds=True).communicate()[0].decode('utf-8')
[  112s]   File "/usr/lib/python3.7/subprocess.py", line 800, in __init__
[  112s] restore_signals, start_new_session)
[  112s]   File "/usr/lib/python3.7/subprocess.py", line 1551, in
_execute_child
[  112s] raise child_exception_type(errno_num, err_msg, err_filename)
[  112s] FileNotFoundError: [Errno 2] No such file or directory:
'apt-cache': 'apt-cache'

The line that attempts to run apt-cache is this one:
https://salsa.debian.org/debian/lsb/blob/debian/master/lsb_release.py#L174

I would suggest a check is added to see if apt-cache exists on the system,
and if not that check is bypassed. Possibly a check such as: if shutil.which
("apt-cache") != None:

This seems like a straightforward check, currently lsb_release does not
work at all on systems without apt-cache, such as those used by the Open
Build Service.

This appears to be present on all versions of lsb_release since at least
10.2019031300, I'm not sure if it is in older versions as well.

Bug#951607: peony: FTBFS on many architectures (mishandling of symbols)

[handsome_feng]

Hi, Boyuan,


I have uploaded the new version and I will keep track with this. :)


Thanks a lot,
handsome_feng














在2020年02月19 03时00分，"Boyuan Yang"写道：

Source: peony
Version: 2.0.0-1
Severity: grave
X-Debbugs-CC: jianfen...@ubuntukylin.com

Hi handsome_feng,

As you can see in https://buildd.debian.org/status/package.php?p=peony ,
there's some mishandling of symbols as indicated in the build log. Please
consider fixing them. Thanks!

-- 
Best,
Boyuan Yang

Bug#951650: lintian: should emit rules-requires-root-explicitly in more cases

[Lucas Nussbaum]

Package: lintian
Version: 2.52.0~bpo10+1
Severity: normal

Hi,

The code for rules-requires-root-explicitly is:


# Check Rules-Requires-Root
if (defined(my $r3 = $processable->source_field('rules-requires-root'))) {
if ($r3 eq 'no') {
$self->tag('rules-does-not-require-root');
} elsif ($r3 eq 'binary-targets') {
$self->tag('rules-requires-root-explicitly');
}
} else {
$self->tag('rules-requires-root-missing');
}

That does not match
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-rules-requires-root,
which allows Rules-Requires-Root to take other values than
binary-targets (see the discussion about keywords in Policy).

In that case, the tag should also be emitted.

An example of package for which that fails is libcap2_2.27-1, which
specifies:
Rules-Requires-Root: dpkg/target-subcommand

- Lucas

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

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

Versions of packages lintian depends on:
ii  binutils 2.31.1-16
ii  bzip21.0.6-9.2~deb10u1
ii  diffstat 1.62-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.35-4+deb10u1
ii  gettext  0.19.8.1-9
ii  gpg  2.2.12-1+deb10u1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.34+b1
ii  libarchive-zip-perl  1.64-1
ii  libberkeleydb-perl   0.55-2
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.40-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b2
ii  libclone-perl0.41-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.72-1
ii  libipc-run-perl  20180523.0-1
ii  libjson-perl 4.02000-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003004-2
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2+deb10u1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-libxml-perl   2.0134+dfsg-1
ii  libyaml-libyaml-perl 0.76+repack-1
ii  man-db   2.8.5-2
ii  patchutils   0.3.4-2
ii  perl [libdigest-sha-perl]5.28.1-6
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-16
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#951280: fixed in ncbi-blast+ 2.9.0-4

[Andreas Tille]

On Wed, Feb 19, 2020 at 10:01:57AM -0500, Aaron M. Ucko wrote:
> At the moment, a mipsel toolchain error is blocking
> migration; I'll see what I can do about that.

Cool.  Please ping me if its in testing.
 
> > PS: I'd be happy if you could answer Tony Travis on the Debian
> > Med list and explain the current status.
> 
> Done a little while ago.

Thanks a lot, Andreas. 

-- 
http://fam-tille.de

Bug#951532: libinput: Touchpad behavour changed

[Lukas Straub]

On Wed, 19 Feb 2020 16:10:26 +0200
Timo Aaltonen  wrote:

> On 17.2.2020 22.33, Lukas Straub wrote:
> > Source: libinput
> > Version: 1.15.1-1
> > Severity: normal
> >
> > Dear Maintainer,
> > Since Version 1.15.1-1 the behavour of the Touchpad changed. I have a 
> > "unified" Touchpad i.e. no physical seperate buttons, the whole touchpad is 
> > pressed down.
> > -It's now impossible to do a middle or right-click and drag (It will always 
> > send left-click)
> > -If I have my finger on the touch area first, I can do left-click and drag. 
> > If the mouse button is pressed first, it's impossible to drag (the pointer 
> > stays where it is).
> >
> > These problems go away if I downgrade to libinput-bin 1.14.3-1.
>
> Test 1.15.1-2 which was uploaded today.
>
>

Yep, It works now. Thanks.

Bug#951629: RFS: timeshift/19.01+ds-2.1 [NMU] [RC] -- System restore utility

[Boyuan Yang]

Hi Steve, wrar,

On Wed, 19 Feb 2020 12:40:15 +0500 Andrey Rahmatullin  wrote:
> Control: tags -1 + moreinfo
> 
> Unfortunately you ignored 
https://lists.debian.org/debian-mentors/2020/02/msg00124.html
> lintian even tells you about the mangled changelog.

I'm letting you know that I am keeping an eye on package timeshift since I
granted the original maintainer DM permission. I know the original maintainer
privately and it looks like he is extremely unlikely to work on timeshift (and
any other Debian work) in the foreseeable future. For now, I will not work on
fixing it or salvaging the package since it's a perfectly valuable chance for
you (Steve) to practice and participate in Debian's work.

Steve: I took a look at the source package you provided on mentors.debian.net.
Actually wrar gave some valuable advice and there are some bugs that *must* be
fixed before anyone accept your work (namely the duplicated changelog
entries). If you are unsure about what changes you made, please take advantage
of the debdiff(1) tool and check the differences between the existing version
and your proposed version.

Please *DO* fix it and let us know when you are ready. I will be glad to help
you upload this NMU. Let me know if you have any doubts.

-- 
Thanks,
Boyuan Yang


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

Bug#951280: fixed in ncbi-blast+ 2.9.0-4

[Aaron M. Ucko]

Andreas Tille  writes:

> Feel free to ping me once the package is in testing an a backport
> is possible.  I have permissions to do backports and I'd volunteer
> to upload if you have no such permissions.

That would be helpful, thanks; I'm not sure I ever obtained such
permissions.  At the moment, a mipsel toolchain error is blocking
migration; I'll see what I can do about that.

> Thank you for your work on this

No problem.

> PS: I'd be happy if you could answer Tony Travis on the Debian
> Med list and explain the current status.

Done a little while ago.

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

Bug#950063: influxdb-python FTBFS with pandas 0.25.3

[Alexandre Viau]

Feel free to move influxdb-python to DPMT.

However, if you do, please remove me from the maintainers and
delete/move the existing salsa project.

Cheers,


-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature