Bug#951387: Please accept https://salsa.debian.org/installer-team/console-setup/merge_requests/3

[Mantas Baltix]

I've added my patch to git and created merge request, see:
https://salsa.debian.org/installer-team/console-setup/merge_requests/3

Please accept :)

English US (intl with altGR) keyboard layout is chosen because this
layout is most useful for Lithuanians - contains Euro (€) and other
symbols, often used in Lithuania.

-- 
Prekyba kompiuteriais su Linux OS - http://tinklas.eu/prekyba
Naudokite laisvą Linux operacinę sistemą savo kompiuteryje -
http://baltix.akl.lt
Use Baltix GNU/Linux OS !

Bug#950737: ncbi-vdb - compiles, could a regular maintainer please double check?

[Andreas Tille]

Hi Steffen,

Ping?

On Wed, Feb 05, 2020 at 03:22:55PM +0100, Andreas Tille wrote:
> Hi Steffen,
> 
> On Sat, Jan 18, 2020 at 01:25:31AM +0100, Steffen Möller wrote:
> > I fiddled with it until it compiled again - the new version is needed to
> > compile the sra-sdk. The problem was with the crypto functions for which
> > the ncbi wrapper function was not existing for a few callbacks, so I
> > used the original function. But I cannot claim to truly have known what
> > I was doing.
> > 
> > git diff 7e29d064babc8fe48996b15bedde2348ea17670c debian/patches/
> > 
> > and there lines matching "vdb_mbedtls"
> 
> Could you please make sure you push
> 
>debian/patches/fix_path_mbedtls.patch
> 
> It was added to seried in commit e3a41421 but the actual file was
> not added to the repository.
> 
> Kind regards
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#951409: Marvell A38x ClearFog mvneta eth device regression

[Joel Johnson]

Package: src:linux
Version: 5.4.19-1
Severity: important

Recent armmp kernels fail to enable all available ethernet devices using 
the mvneta driver. On a ClearFog Base, booting the 4.19 Buster kernels 
works as expected, with eth0/eth1/eth2 all being present and available 
for use.


However, in booting more recent kernels, only the single eth0 device is 
available for use. The mvneta module is loaded and used in all cases, 
but doesn't seem to even acknowledge the existence of the other two 
devices.


The device tree for the ClearFog maps ethernet devices as 
f107.ethernet, f103.ethernet, and f1034000.ethernet. According 
to dmesg boot output, the f107 device is the only one which is 
available on newer kernels.


I've tested with 4.19.67-2+deb10u2 and confirmed it working, and tested 
with linux-image-5.2.0-2-armmp version 5.2.7-1 from snapshots and 
confirmed that it is not working as of that 5.2 build.


Thanks,
Joel

Bug#951408: RFS: pulseaudio/13.0-5~bpo10+1 -- PulseAudio sound server

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: pulseaudio
   Version : 13.0-5~bpo10+1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://www.pulseaudio.org
 * License : [fill in]
 * Vcs : https://salsa.debian.org/pulseaudio-team/pulseaudio
   Section : sound

It builds those binary packages:

  pulseaudio - PulseAudio sound server
  pulseaudio-utils - Command line tools for the PulseAudio sound server
  pulseaudio-module-zeroconf - Zeroconf module for PulseAudio sound
server
  pulseaudio-module-jack - jackd modules for PulseAudio sound server
  pulseaudio-module-lirc - lirc module for PulseAudio sound server
  pulseaudio-module-gsettings - GSettings module for PulseAudio sound
server
  pulseaudio-module-raop - RAOP module for PulseAudio sound server
  pulseaudio-module-bluetooth - Bluetooth module for PulseAudio sound
server
  pulseaudio-equalizer - Equalizer sink module for PulseAudio sound
server
  libpulse0 - PulseAudio client libraries
  libpulse-mainloop-glib0 - PulseAudio client libraries (glib support)
  libpulse-dev - PulseAudio client development headers and libraries
  libpulsedsp - PulseAudio OSS pre-load library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pulseaudio/pulseaudio_13.0-5~bpo10+1.dsc

Changes since the last bpo:

pulseaudio (13.0-5) unstable; urgency=medium

  * Fix removal of 00-disable-autospawn.conf.
The autoremoval script was wrongly put into the pulseaudio package,
while
it should have been in the libpulse0 package. Moreover, the version
specified
was wrong (set at 12.2 instead of 13.0) (Closes: #950413)

 -- Felipe Sateler   Wed, 05 Feb 2020 23:06:41
-0300

pulseaudio (13.0-4) unstable; urgency=medium

  [ Steve Langasek ]
  * Make autopkgtests cross-test-friendly.
In Ubuntu, we are in the process of moving the i386 architecture to
a
compatibility-only layer on amd64, and therefore we are also moving
our
autopkgtest infrastructure to test i386 binaries in a cross-
environment.
This requires changes to some tests so that they are cross-aware and
can do
the right thing.
The pulseaudio tests currently fail in this environment, because
they are
build tests that do not invoke the toolchain in a cross-aware
manner.  I've
verified that the attached patch lets the tests successfully build
(and run)
i386 tests on an amd64 host.
Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH
so this
is a complete no-op in Debian for the moment.  Support for cross-
testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and
once
landed, will still have no effect unless autopkgtest is invoked with
a '-a'
option.  So this change should be safe to land in your package
despite this
not being upstream in autopkgtest. (Closes: #946375)

  [ Felipe Sateler ]
  * Enable autospawn automatically on sysvinit systems.
Instead of having a default configuration, make pulseaudio default
to
disabled, and then have a sysvinit service to reenable the autospawn
setting
(Closes: #923203)
  * Allow installing pulseaudio with elogind.
Because we now autospawn with non-systemd, we can use the weaker
guarantees
provided by elogind
(Closes: #923201)
  * Drop postinst snippet dealing with old upgrades.
5.0 is already in oldoldstable so no need to carry it anymore
  * Set upstream metadata fields: Name (from ./configure), Repository,
Repository-Browse.
Fixes: lintian: upstream-metadata-file-is-missing
See-also: 
https://lintian.debian.org/tags/upstream-metadata-file-is-missing.html
  * Bump Standards-Version.
No changes needed
  * Enable the systemd user units dynamically, not statically.
Now that there is support for systemd --user in debhelper, lets use
that to
enable the user units instead of having a global link (Closes:
#943999)

 -- Felipe Sateler   Fri, 31 Jan 2020 09:24:15
-0300

Changes since the last upload:

   * Rebuild for buster-backports.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#950474: python-cogent FTBFS on armel and i386: test failures

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/cogent3/cogent3/issues/534

On Sun, Feb 02, 2020 at 01:12:27PM +0200, Adrian Bunk wrote:
> 
> The armel port has no FPU in the baseline,
> and the math emulation does not handle all corner cases correctly.
> 
> The i386 port uses the 387 FPU that has excess precision.
> 
> Since this package likely has no users on armel or i386,
> I'd suggest to file an RM bug for the old binaries and

ROM bug filed.

> then lower the severity of this bug.

Will do so once the packages are removed.  I reported the issue
upstream as well.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#951407: RM: python-cogent [i386 armel] -- ROM; Remove for architectures without working FPU

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

please remove python-cogent for i396 and armel as suggensted in
bug report #950474.  Meanwhile I will inform upstream about the
issue.

Kind regards

  Andreas.

Bug#951406: gnuplot: "-" and two 'using' doesn't work in plot/splot

[Veek]

Package: gnuplot
Version: 5.2.6+dfsg1-1+deb10u1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
cat data 
17993 7555 2114 22230 11946 9761 119 5938 
24263 5803 23116 26022 2100 13260 10751 16774 
12935 31166 11077 28420 30729 5930 28746 14660 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
works, with TWO points since there are two 'using': 
gnuplot -p -e 'splot "data" u 1:2:3, "" u 1:3:4';

fails only ONE point: 
cat data|gnuplot -p -e 'splot "-" u 1:2:3, "" u 1:3:4';

   * What outcome did you expect instead?
it should display both points - one for each 'using'


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

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

Versions of packages gnuplot depends on:
ii  gnuplot-qt [gnuplot-x11]  5.2.6+dfsg1-1+deb10u1

gnuplot recommends no packages.

Versions of packages gnuplot suggests:
pn  gnuplot-doc  

-- no debconf information

Bug#951405: ITP: golang-github-yuin-goldmark-highlighting -- syntax highlighting extension for the goldmark Markdown parser

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-yuin-goldmark-highlighting
  Version : 0.0~git20191202.78f32c8-1
  Upstream Author : Yusuke Inuzuka
* URL : https://github.com/yuin/goldmark-highlighting
* License : Expat
  Programming Lang: Go
  Description : syntax highlighting extension for the goldmark Markdown 
parser.

 goldmark-highlighting is an extension for the goldmark Markdown parser
 that adds syntax-highlighting to fenced code blocks.
 .
 goldmark-highlighting uses chroma as syntax highlighter.

Reason for packaging: Needed by Hugo 0.60.0 and up

Bug#951335: procps: top: window entry #1 corrupt, please delete '/home/tglase/.toprc'

[Thorsten Glaser]

Hi Craig,

>   I am pretty sure it's the fieldscur validation having a bad day. I've
> emailed the author and will let you know what happens.

thanks! Feel free to suggest the author use my /etc/skel/.toprc as
regression test upstream ☻

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

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#951404: zfs-dkms: requires Linux headers

[David Christensen]

Package: zfs-dkms
Version: 0.6.5.9-5
Severity: important

Dear Maintainer,

Instation of zfs-dkms fails if Linux headers are not installed:

2020-02-15 19:42:47 root@tinkywinky ~
# apt-get install --reinstall zfs-dkms
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 47 not 
upgraded.
Need to get 0 B/1080 kB of archives.
After this operation, 0 B of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 130450 files and directories currently installed.)
Preparing to unpack .../zfs-dkms_0.6.5.9-5_all.deb ...

 Uninstall Beginning 
Module:  zfs
Version: 0.6.5.9
Kernel:  4.9.0-12-amd64 (x86_64)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

zavl.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.9.0-12-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module 
version.


zcommon.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.9.0-12-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module 
version.


znvpair.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.9.0-12-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module 
version.


zpios.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.9.0-12-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module 
version.


zunicode.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.9.0-12-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module 
version.


zfs.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.9.0-12-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module 
version.

depmod...

DKMS: uninstall completed.

--
Deleting module version: 0.6.5.9
completely from the DKMS tree.
--
Done.
Unpacking zfs-dkms (0.6.5.9-5) over (0.6.5.9-5) ...
Setting up zfs-dkms (0.6.5.9-5) ...
Loading new zfs-0.6.5.9 DKMS files...
Building for 4.9.0-11-amd64
Module build for kernel 4.9.0-11-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.


The package should offer to install a suitable Linux headers package,
ask for user confirmation, install the headers, and continue installing
ZFS.

If zfs-dkms is being installed non-interactively, it should install
a suitable Linux headers package and continue.


David



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

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  dkms   2.3-2
ii  lsb-release9.20161125
ii  spl-dkms   0.6.5.9-1

Versions of packages zfs-dkms recommends:
ii  zfs-zed 0.6.5.9-5
ii  zfsutils-linux  0.6.5.9-5

zfs-dkms suggests no packages.

-- debconf information:
* zfs-dkms/note-incompatible-licenses:
  zfs-dkms/stop-build-for-unknown-kernel: true
  zfs-dkms/stop-build-for-32bit-kernel: true

Bug#951403: RFS: jcc/3.6-1 [ ITA] -- generator for a Python extension from Java classes (Python 3)

[eamanu]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: jcc
   Version : 3.6-1
   Upstream Author : Andi Vadja 
 * URL : http://lucene.apache.org/pylucene/jcc/
 * License : Apache
 * Vcs : https://salsa.debian.org/debian/jcc
   Section : oldlibs

It builds those binary packages:

  python3-jcc - generator for a Python extension from Java classes
(Python 3)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/j/jcc/jcc_3.6-1.dsc

Changes since the last upload:

   [ Emmanuel Arias ]
   * New upstream version 3.6
   * New maintainer (Closes: #922568):
 - Add myself to Maintainer field on d/control.
   * Bump debhelper to 12 (from 9.2):
 - Update debhelper to debhelper-compat on d/control Build-Depends.
   * Update Vcs-* repository to salsa repository.
   * Add myself on debian/* files copyright on d/copyright.
   * Bump Standard-Version to 4.4.1
   * d/control: add autopkgtest-pkg-python
   * Remove Python2 support.
   * d/control: Remove X-Python-Version for Python 2
   * d/salsa-ci.yml: enable salsa-ci.
   * d/gbp.conf: add gbp.conf file.
 .
   [Ludovico Cavedon]
   * Fix jdk path with Java 9 (Closes: #875579).
   * Fall-back to client-mode JVM is the server-mode one is not available
 (Closes: #885955).
   * Refresh patches.
   * Create python-jcc and python3-jcc packages, and make jcc a transitional
 one. Expand the "default-jdk" symlink at build time, so the run-time
 dependency is on the correct JDK version.
   * Make sure to depend on the JRE package we built against. Do not link
 against libjava as it is not necessary.
   * Change priority extra to optional.
   * No longer remove JCC.egg-info/SOURCES.txt during clean.
   * Add lintian-overrides for JRE rpath (needed because libjvm.so does not
 have an SONAME).
   * Build library with hardening=+all hardening flags.

Regards,

--
  Emmanuel Arias



0xFA9DEC5DE11C63F1.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#944922: postfix: Init script in 3.4.7-2 does not start all instances

[Scott Kitterman]

On Tue, 11 Feb 2020 20:34:33 +0100 jaros...@thinline.cz wrote:
...
> Hello,
> 
> thanks for putting your time into this.
> 
> If it helps, I made a quick and dirty fix to the new approach
> 
> running() {
> 
> INSTANCE="$1"
> if [ "X$INSTANCE" = X ]; then
> 
> POSTMULTI=""
> 
> else
> 
> POSTMULTI="postmulti -i $INSTANCE -x "
> 
> fi
> POSTCONF="${POSTMULTI} postconf"
> 
> daemon_directory=$($POSTCONF -hx daemon_directory 2>/dev/null ||
> 
> echo /usr/lib/postfix/sbin)
> 
> if ! ${POSTMULTI} $daemon_directory/master -t 2>/dev/null ; then
> 
> echo y
> 
> fi
> 
> }
> 
> This way postmulti calls master (or any program) with some environment
> variables set, namely [1]:
> 
> MAIL_LOGTAG=postfix
> MAIL_CONFIG=/etc/postfix-fwd
> daemon_directory=/usr/lib/postfix/sbin
> command_directory=/usr/sbin
> config_directory=/etc/postfix-fwd
> queue_directory=/var/spool/postfix-fwd
> data_directory=/var/lib/postfix-fwd
> multi_instance_name=postfix-fwd
> multi_instance_group=
> multi_instance_enable=yes
> 
> Apparently master process uses these and does the right thing, ie. looks
> for the pidfile in correct directory - see strace:
> 
> [pid  8180] chdir("/var/spool/postfix-fwd") = 0
> [pid  8180] access("pid/master.pid", F_OK) = 0
> 
> I admit I have no idea whatsoever if this approach is correct,
> documented or supported. Just occured to me it might work and it did.
> 
> [1] postmulti -i postfix-fwd -x cat /proc/self/environ | tr "\0" "\n"

I've verified this works for a single instance still (no reason it shouldn't) 
and researched it a bit.  I think this is actually quite reasonable.  Thanks.  
Unless someone can find a problem or has a better idea, I'll go with this on 
the next upload.

Scott K


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

Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling

[notafile]

Hi,

I've been running into this myself a lot lately and wonder if anything has 
happened regarding this since 2014, after all it's been six years.
I'm surprised so few people seem to be taking interest in this considering the 
amount of tools that rely on frame pointers for performant stack traces, which 
has further increased with the introduction of eBPF.

Bug#951149: more info

[Peter Eckersley]

I saw this on a sid system with dpkg 1.19.0.4 installed (piecemeal upgrades).
But people might hit it while upgrading from oldstable to the next release?
It's a fairly annoying bug because (at least for me) it broke apt and required
manual untangling once triggered.

May be a more general problem if this flag is widely used though?

-- 
Peter Eckersleyp...@eff.org
Distinguished Technology Fellow   Tel  +1 415 200 7907
Electronic Frontier Foundation

Bug#951402: FTBFS: override for vtkvmtkPolyBallLine does not override

[Drew Parsons]

Source: vmtk
Followup-For: Bug #951402
Control: forwarded -1 https://github.com/vmtk/vmtk/issues/346

Bug#951402: FTBFS: override for vtkvmtkPolyBallLine does not override

[Drew Parsons]

Source: vmtk
Version: 1.4.0+dfsg-1
Severity: normal

Trying to build vmtk 1.4.0 for Debian unstable,
vmtk 1.4.0+dfsg-1~
VTK 7.1.1+dfsg2-2
g++ 4:9.2.1-3.1
cmake 3.16.3-1

The build gives this error:

[  7%] Building CXX object 
vtkVmtk/IO/CMakeFiles/vtkvmtkIOPythonD.dir/vtkvmtkXdaWriterPython.cxx.o
cd /build/vmtk/obj-x86_64-linux-gnu/vtkVmtk/IO && /usr/bin/c++  
-DITK_IO_FACTORY_REGISTER_MANAGER -DvtkvmtkIOPythonD_EXPORTS 
-I/usr/include/vtk-7.1 
-I/build/vmtk/obj-x86_64-linux-gnu/ITKFactoryRegistration 
-I/usr/include/hdf5/serial -I/usr/include/nifti -I/usr/include/gdcm-3.0 
-I/usr/include/double-conversion -I/usr/include/ITK-4.13 -I/build/vmtk/vtkVmtk 
-I/build/vmtk/vtkVmtk/Common -I/build/vmtk/vtkVmtk/ComputationalGeometry 
-I/build/vmtk/vtkVmtk/DifferentialGeometry -I/build/vmtk/vtkVmtk/IO 
-I/build/vmtk/vtkVmtk/Misc -I/build/vmtk/vtkVmtk/Segmentation 
-I/build/vmtk/vtkVmtk/Contrib -I/build/vmtk/vtkVmtk/Utilities/vtkvmtkITK 
-I/build/vmtk/obj-x86_64-linux-gnu/vtkVmtk -I/usr/include/python3.7m 
-I/usr/include/python2.7  -g -O2 -fdebug-prefix-map=/build/vmtk=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2   -O2 -g -DNDEBUG -fPIC   -o 
CMakeFiles/vtkvmtkIOPythonD.dir/vtkvmtkXdaWriterPython.cxx.o -c 
/build/vmtk/obj-x86_64-linux-gnu/vtkVmtk/IO/vtkvmtkXdaWriterPython.cxx
In file included from 
/build/vmtk/vtkVmtk/ComputationalGeometry/vtkvmtkCenterlineBranchExtractor.cxx:24:
/build/vmtk/vtkVmtk/ComputationalGeometry/vtkvmtkPolyBallLine.h:45:10: error: 
‘double vtkvmtkPolyBallLine::EvaluateFunction(double, double, double)’ marked 
‘override’, but does not override
   45 |   double EvaluateFunction(double x, double y, double z) VTK_OVERRIDE
  |  ^~~~
make[3]: *** 
[vtkVmtk/ComputationalGeometry/CMakeFiles/vtkvmtkComputationalGeometry.dir/build.make:131:
 
vtkVmtk/ComputationalGeometry/CMakeFiles/vtkvmtkComputationalGeometry.dir/vtkvmtkCenterlineBranchExtractor.cxx.o]
 Error 1
make[3]: Leaving directory '/build/vmtk/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:710: 
vtkVmtk/ComputationalGeometry/CMakeFiles/vtkvmtkComputationalGeometry.dir/all] 
Error 2



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

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

Bug#951401: freecad: In the File menu, nothing is printed or shown using Print, Print Preview, or Export PDF

[Mike Haag]

Package: freecad
Version: 0.18~pre1+dfsg1-5
Severity: normal

Dear Maintainer,

Steps to reproduce:

1. Download and open a tutorial file from the freecad web site. For example,
"Basic_Part_Design_Tutorial_017.fcstd".

2. Starting from the View menu, use View > Standard Views > Fit all

3. In the file menu:
 1.The "Print" command prints only a blank page.
 2.The "Print preview" command opens the print preview window, but it is blank.
 3.The "Export PDF..." command produces a PDF file, but it is blank.

In all three cases, the same three error messages are produced in the Report
view pane as listed below:

QOpenGLFramebufferObject: Framebuffer incomplete attachment.
QOpenGLFramebufferObject: Unsupported framebuffer format.
QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.



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

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

Versions of packages freecad depends on:
ii  freecad-python3  0.18~pre1+dfsg1-5

Versions of packages freecad recommends:
ii  calculix-ccx  2.11-1+b3
ii  graphviz  2.40.1-6

Versions of packages freecad suggests:
pn  freecad-doc 
ii  povray  1:3.7.0.8-1
ii  python-collada  0.4-3

-- no debconf information

Bug#934200: gbp import-orig is broken with multiple source tarballs

[Sandro Tosi]

control: tags -1 - pending

On Thu, 08 Aug 2019 11:18:43 +0530 Pirate Praveen
 wrote:
> Package: git-buildpackage,devscripts
> severity: important
>
> You can try it with node-ajv (from 6.10.0-5 tag). It imported the
> component instead of the main tar ball.
>
> node-ajv$ gbp import-orig --pristine-tar --uscan
> gbp:info: Launching uscan...
> gbp:info: Using uscan downloaded tarball
> ../node-ajv_6.10.2.orig-fast-json-stable-stringify.tar.gz
> What is the upstream version? [6.10.2]
> gbp:info: ../node-ajv_6.10.2.orig.tar.gz already exists, moving to
> ../node-ajv_6.10.2.orig.tar.gz.1565242303
> gbp:info: Importing
> '../node-ajv_6.10.2.orig-fast-json-stable-stringify.tar.gz' to branch
> 'upstream'...
> gbp:info: Source package is node-ajv
> gbp:info: Upstream version is 6.10.2
> gbp:info: Replacing upstream source on 'master'
> gbp:info: Successfully imported version 6.10.2 of
> ../node-ajv_6.10.2.orig-fast-json-stable-stringify.tar.gz

this is still happening: i'm trying to upgrade dblatex to the latest
upstream release and the source package has 2 upstream tarballs.

`gbp import-orig --uscan` imports only the "main" tarball but not the
additional component (`examples`,
https://salsa.debian.org/debian/dblatex/tree/pristine-tar) and `gbp
import-orig ../../dblatex*orig*` complains multiple files are
specified on the command-line, and i did not find a combination of
commands to import 2 tarballs one after the other.

I'm not sure how frequent is the case of multiple tarballs, but it
would still be extra-useful if this bug could be addressed soon.

Regards,
Sandro

Bug#951398: FTBFS: pax.jar

[Norbert Preining]

severity 951398 normal
thanks

Hi Bastien,

On Sun, 16 Feb 2020, Bastien Roucariès wrote:
> I could not found the source of file texmf-dist/scripts/pax.jar

Mind looking into the .orig.tar.xz?

drwxr-xr-x norbert/norbert0 2020-02-10 10:40 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/
-rw-r--r-- norbert/norbert 1376 2008-09-21 08:48 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/build.xml
drwxr-xr-x norbert/norbert0 2020-02-10 10:40 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/license/
drwxr-xr-x norbert/norbert0 2020-02-10 10:40 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/license/LaTeX/
-rw-r--r-- norbert/norbert19110 2008-09-21 08:48 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/license/LaTeX/lppl.txt
drwxr-xr-x norbert/norbert0 2020-02-10 10:40 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/license/PDFAnnotExtractor/
-rw-r--r-- norbert/norbert17990 2008-09-21 08:48 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/license/PDFAnnotExtractor/gpl.txt
drwxr-xr-x norbert/norbert0 2020-02-10 10:40 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/
-rw-r--r-- norbert/norbert 4271 2012-04-20 01:53 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/Constants.java
-rw-r--r-- norbert/norbert 4583 2012-04-20 01:53 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/Entry.java
-rw-r--r-- norbert/norbert  963 2012-04-20 01:53 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/EntryWriteException.java
-rw-r--r-- norbert/norbert   83 2008-10-03 08:11 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/MANIFEST.MF
-rw-r--r-- norbert/norbert27677 2012-04-20 01:53 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/PDFAnnotExtractor.java
-rw-r--r-- norbert/norbert 3674 2012-04-20 01:53 
texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/StringVisitor.java

> I will in the next week do an audit of all file not rebuilded from source and 
> I think this package is unsuitable from main

Wrong. But please enjoy the checking which has already been done by the
RedHat lawyers.

Enjoy.

Norbert

--
PREINING Norbert   http://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#936772: jupyter-client: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:21:43 + Matthias Klose  wrote:
> Package: src:jupyter-client
> Version: 5.2.4-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

Hey Gordon,
jupyter-client (and python-jupyter-client) is the last reverse depends
on pyzmq. are you plans still to keep the python2 jupyter platform
around or is it now a good time to start removing part of it?

AFAIK, pyzmq is a core dependency of jupyter-client so this wont be as
easy as removing mpl from ipython :)

Regards,
Sandro

Bug#670040: Fixed

[Norbert Preining]

Hi Bastien,

>  https://github.com/bastien-roucaries/latex-pax

Would you like to take over PAX as upstream? Heiko has left all behind
and most packages are maintained by others now.

Best

Norbert

--
PREINING Norbert   http://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#951400: RM: matplotlib2 -- ROM; python2-only; superseeded by src:matplotlib; no r-deps in testing

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
i would like to remove src:matplotlib2 from Debian. this package contains an old
version of matplotlib, the 2.x series, which is the last one compatible with
python2. In the meantime upstream released the 3.x series, tracked in
src:matplotlib, which requires all new features and enhancements.

dak *does* report some dependencies issues:

```
Checking reverse dependencies...
# Broken Depends:
brian: python-brian
matplotlib2: python-matplotlib-dbg
nitime: python-nitime
psychopy: psychopy
pwrkap: pwrkap-gui
python-cogent: python-cogent
seekwatcher: seekwatcher

# Broken Build-Depends:
battery-stats: python-matplotlib
brian: python-matplotlib (>= 0.90.1)
dipy: python-matplotlib
mypaint: python-matplotlib
nipy: python-matplotlib (>= 0.98.3)
nipype: python-matplotlib
psychopy: python-matplotlib
pymvpa2: python-matplotlib
```

almost all of those are not in testing for months, some even for years; with a
few exceptions:

* src:nitime, doesnt build `python-nitime` anymore, not sure why it's there
* src:python-cogent, doesnt build `python-cogent` anymore, not sure why it's
  there


While i understand it's not as clean a situation as you usually like, i would
still like to remove src:matplotlib2 from the archive, and i'll deal with the
consequences if and when some appear. Many of the broken rdeps are RC because
they depend already on removed packages: removing python-matplotlib wont take
them to a worst situation and they will need to be ported to python3 anyway to
re-enter testing.

src:matplotlib2 is currently the package that, once removed, will unblock the
more dependencies for the py2removal effort.

Thanks,
Sandro

Bug#951398: Patch

[Bastien ROUCARIES]

control: tags -1 + patch

Patch file

Bug#951399: buster-pu: package softflowd/0.9.9-5

[Christoph Biedl]

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

Hello release team,

a nasty bug made it into the Debian 10 ("buster") version of softflowd,
and I'd like to fix that in a stable point release.

Due to a broken flow aggregation, the flow table might overflow,
resulting in forced flow expiration. Which, as I was told, can lead to
constant 100% CPU usage of the softflowd process. Another effect is the
resulting flow files captured by nfcapd(1) (from the nfdump package)
are way bigger then before the upgrade, and nfcapd creating a lot of
noise in the syslog as well.

This was fixed upstream although not quite in an obvious way - thanks
to bisecting this wasn't a big problem anyway. According to tests done
by the reporter the fix ended the massive CPU usage, for the other
effects I can confirm the desired behaviour as seen in the previous
Debian 9 ("stretch") version is restored as well.

For the next stable point release, version 0.9.9-5+deb10u1 was already
uploaded to the applicable queue.

Suggested one-line description: Fix broken netflow aggregation

Regards,

Christoph

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

Kernel: Linux 5.4.19 (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: unable to detect

diff -Nru softflowd-0.9.9/debian/changelog softflowd-0.9.9/debian/changelog
--- softflowd-0.9.9/debian/changelog2018-10-26 17:10:09.0 +0200
+++ softflowd-0.9.9/debian/changelog2019-12-05 00:21:02.0 +0100
@@ -1,3 +1,10 @@
+softflowd (0.9.9-5+deb10u1) buster; urgency=medium
+
+  * Fix roken flow aggregation which might result in flow table overflow
+and 100% CPU usage.
+
+ -- Christoph Biedl   Thu, 05 Dec 2019 
00:21:02 +0100
+
 softflowd (0.9.9-5) unstable; urgency=high
 
   * Don't migrate legacy config if it wasn't modified. Closes: #910214
diff -Nru 
softflowd-0.9.9/debian/patches/cherry-pick.softflowd-0.9.9-22-ge6d29a1.fix-some-bugs.patch
 
softflowd-0.9.9/debian/patches/cherry-pick.softflowd-0.9.9-22-ge6d29a1.fix-some-bugs.patch
--- 
softflowd-0.9.9/debian/patches/cherry-pick.softflowd-0.9.9-22-ge6d29a1.fix-some-bugs.patch
  1970-01-01 01:00:00.0 +0100
+++ 
softflowd-0.9.9/debian/patches/cherry-pick.softflowd-0.9.9-22-ge6d29a1.fix-some-bugs.patch
  2019-12-05 00:21:02.0 +0100
@@ -0,0 +1,68 @@
+Subject: [ Add option "-a" for reading pcap file and ] fix some bugs
+Origin: softflowd-0.9.9-22-ge6d29a1 

+Upstream-Author: Hitoshi Irino 
+Date: Sun May 26 23:00:41 2019 +0900
+Comment: Fixes a regression introduced in buster: The flow aggregation
+ is broken, causing a new flow to generated for virtually each packet.
+ If the daemon sees a lot of traffic, the flow table might overflow,
+ resulting in forced expiration and 100% CPU usage.
+ .
+ Thanks Johanna Jerzembeck for reporting and testing.
+
+- fix flow_compare for comparing vlan and ether
+[ - fix missing sequence in netflow v9 ]
+
+
+--- a/softflowd.c
 b/softflowd.c
+@@ -55,6 +55,8 @@
+ static int verbose_flag = 0;  /* Debugging flag */
+ static u_int16_t if_index = 0;/* "manual" interface index */
+ 
++static int track_level;
++
+ /* Signal handler flags */
+ static volatile sig_atomic_t graceful_shutdown_request = 0;   
+ 
+@@ -144,15 +146,21 @@
+ {
+   /* Be careful to avoid signed vs unsigned issues here */
+   int r;
++  if (track_level == TRACK_FULL_VLAN || track_level == 
TRACK_FULL_VLAN_ETHER) {
++  if (a->vlanid[0] != b->vlanid[0])
++  return (a->vlanid[0] > b->vlanid[0] ? 1 : -1);
++
++  if (a->vlanid[1] != b->vlanid[1])
++  return (a->vlanid[1] > b->vlanid[1] ? 1 : -1);
++}
+ 
+-  if (a->vlanid != b->vlanid)
+-  return (a->vlanid > b->vlanid ? 1 : -1);
+-
++  if (track_level == TRACK_FULL_VLAN_ETHER) {
+   if ((r = memcmp(&a->ethermac[0], &b->ethermac[0], 6)) != 0)
+   return (r > 0 ? 1 : -1);
+ 
+   if ((r = memcmp(&a->ethermac[1], &b->ethermac[1], 6)) != 0)
+   return (r > 0 ? 1 : -1);
++  }
+ 
+   if (a->af != b->af)
+   return (a->af > b->af ? 1 : -1);
+@@ -1526,7 +1534,7 @@
+ 
+   ft->param.max_flows = DEFAULT_MAX_FLOWS;
+ 
+-  ft->param.track_level = TRACK_FULL;
++  track_level = ft->param.track_level = TRACK_FULL;
+ 
+   ft->param.tcp_timeout = DEFAULT_TCP_TIMEOUT;
+   ft->param.tcp_rst_timeout = DEFAULT_TCP_RST_TIMEOUT;
+@@ -1882,6 +1890,7 @@
+   usage();
+   exit(1);
+   }
++  track_level = flowtrack.param.track_level

Bug#670040: Fixed

[Bastien ROUCARIES]

control: tags -1 + patch

Fixed here :
 https://github.com/bastien-roucaries/latex-pax

The javapath are not fixed but the pax could by using java -cp
/usr/share/texlive/texmf-dist/scripts/pax/pax.jar:/usr/share/java/pdfbox.jar:/usr/share/java/commons-logging.jar
pax.PDFAnnotExtractor file.pdf

Bug#951398: FTBFS: pax.jar

[Bastien Roucariès]

Source: texlive-extra
Version: 2019.202000210-1
Severity: serious
Justification: DFSG #2

Dear Maintainer,

I could not found the source of file texmf-dist/scripts/pax.jar

I have recreated a github solving also the problem of using an old pdfbox 
source https://github.com/bastien-roucaries/latex-pax

The javapath are not fixed but the pax could by using java -cp 
/usr/share/texlive/texmf-dist/scripts/pax/pax.jar:/usr/share/java/pdfbox.jar:/usr/share/java/commons-logging.jar
 pax.PDFAnnotExtractor file.pdf

I will in the next week do an audit of all file not rebuilded from source and I 
think this package is unsuitable from main

Bastien

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

Bug#951397: ITP: zita-dc1 - Dynamics Compressor

[Dennis Braun]

Here you go: https://mentors.debian.net/package/zita-dc1



signature.asc
Description: OpenPGP digital signature

Bug#951397: ITP: zita-dc1 - Dynamics Compressor

[Dennis Braun]

Package: wnpp
Severity: wishlist
Owner: d_br...@kabelmail.de


* Package name : zita-dc1
  Version : 0.3.3
  Upstream Author : Fons Adriaensen 
* URL : http://kokkinizita.linuxaudio.org/linuxaudio/downloads/
* License : GPL-3+
  Programming Lang: C++
  Description : Dynamics Compressor


Hello,

the package is already ready on my local disk.
i'll upload this package to mentors asap.

Best,
Dennis



signature.asc
Description: OpenPGP digital signature

Bug#930869: marked as done (Don't release with buster)

[Ian Jackson]

Debian Bug Tracking System writes ("Bug#930869: marked as done (Don't release 
with buster)"):
> The new maintainer, Ian Jackson, seems to be quite busy, and did not
> decide yet whether to drop the i386 parts.  But, even if untestable
> for most of us, they're unlikely to regress -- and thus, will still
> serve owners of hardware of that era.

Hi.  Sorry for being busy.  Thanks, Adam, for closing this bug.  I
approve.

I think we should keep the i386 parts unless and until some actual
problems appear.

Regards,
Ian.

Bug#951396: libpam-radius-auth: CVE-2015-9542

[Salvatore Bonaccorso]

Source: libpam-radius-auth
Version: 1.4.0-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for libpam-radius-auth.

CVE-2015-9542[0]:
|buffer overflow in password field

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2015-9542
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-9542
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1686980
[2] https://github.com/FreeRADIUS/pam_radius/commit/01173ec
https://github.com/FreeRADIUS/pam_radius/commit/6bae92d
https://github.com/FreeRADIUS/pam_radius/commit/ac2c1677

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#951381: pdftex ignores tl-paper setting

[Norbert Preining]

tags 951381 + unreproducible moreinfo
thanks

Hi Ted,

I just tried to reproduce this on my buster system, without success.

On Sat, 15 Feb 2020, Ted To wrote:
> $ tl-paper
...

Did you rebuild the formats after changing the default paper size?

Please do
sudo tl-paper set all letter
sudo fmtutil-sys --all

After that it should work.

Norbert

--
PREINING Norbert   http://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#945711: Python 3 fixes

[Antonio Russo]

Control: tag -1 patch

Please see my merge request on salsa [1]. The Python 2 dependency is completely 
vestigial, and can be trivially removed.

I've tested that patch locally.

Antonio

[1] 
https://salsa.debian.org/python-team/applications/speedtest-cli/merge_requests/2

Bug#944330: debian-policy: Hyphenation damage on plain text output

[Russ Allbery]

Dmitry Shachnev  writes:
> On Sun, Nov 17, 2019 at 11:11:37AM -0800, Russ Allbery wrote:
>> Sphinx uses Python's standard textwrap module to wrap text output.  That
>> class has an option, break_on_hyphens, which defaults to True but can be
>> set to False.  For Policy, we want to set it to False, but Sphinx doesn't
>> expose a configuration setting that allows this.
>>
>> I'm reassigning this bug to Sphinx, but it's really an upstream feature
>> request.

> Upstream said they are not interested in such an option, but they may change
> their opinion if they see any ugly examples:

> https://github.com/sphinx-doc/sphinx/issues/6867

Thanks, I replied to that issue.

-- 
Russ Allbery (r...@debian.org)  

Bug#651085: ITP: zita-dpl1 - look-ahead digital peak limiter

[Dennis Braun]

retitle 651085 ITP: zita-dpl1 - look-ahead digital peak limiter



signature.asc
Description: OpenPGP digital signature

Bug#651085: ITP: zita-dpl1 - look-ahead digital peak limiter

[Dennis Braun]

Here you go: https://mentors.debian.net/package/zita-dpl1



signature.asc
Description: OpenPGP digital signature

Bug#951395: missing source pstoedit.pro

[Ian Jackson]

Package: pstoedit
Version: 3.75-1
Severity: important

Hi.  I regret to report that our pstoedit package contains an output
file without the corresponding source code.  The top of
src/pstoedit.ph says:

  // DO NOT CHANGE THIS FILE. THIS FILE IS GENERATED FROM pstoedit.pro 
  // You can get pstoedit.pro from the author of pstoedit
  // pstoedit.pro contains a lot more comments and explanations than pstoedit.ph

I wasn't able to find the file pstoedit.pro in the package.  My
websearches suggested that at least some people other than the author
have had a copy.  So I suggest asking the author is probably a good
idea.  It looks like the .ph file is probably made in some fairly
simple way.

I suggest we ask the upstream author for a copy of pstoedit.pro and
see if we can construct pstoedit.ph from it.  How about we first ask
for just the .pro file first, rather than asking for the conversion
script(s) ?

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#935969: linux-image-5.2.0-2-amd64: Missing firmware for new driver rtwpci

[Iustin Pop]

On 2019-12-22 11:27:25, Salvatore Bonaccorso wrote:
> Control: tags -1 + pending
> 
> Hi Andrea,
> 
> On Sun, Dec 22, 2019 at 08:46:42AM +0100, Andrea Palazzi wrote:
> > Package: firmware-realtek
> > Version: 20190717-2
> > Followup-For: Bug #935969
> > 
> > Hi,
> > 
> > What's keeping this bug from being fixed, given that there's a patch 
> > available?
> > Is there something that I can do to help?
> > 
> > Also, shouldn't it be an important bug, since it makes unusable the wifi in
> > systems with boars using the rtw88 firmware?
> 
> It would need a slightly different approach, because the rules.gen is
> generated. Sjoerd Simons proposed the changes in
> https://salsa.debian.org/kernel-team/firmware-nonfree/merge_requests/10
> .
> 
> The packaging itself needs more changes to be finalized, but the
> support is now commited.

That's great to hear, but any chance of uploading a -3 version? This is
still broken for such devices (and thus prevents using a backported 
kernel, for example).

thanks,
iustin

Bug#651085: ITP: zita-dpl1 - look-ahead digital peak limiter

[Dennis Braun]

Package: wnpp
Severity: wishlist
Owner: d_br...@kabelmail.de


* Package name : zita-dpl1
  Version : 0.3.3
  Upstream Author : Fons Adriaensen 
* URL : http://kokkinizita.linuxaudio.org/linuxaudio/downloads/
* License : GPL-3+
  Programming Lang: C++
  Description : look-ahead digital peak limiter


Heya,

i would like to adopt this and will upload the package to mentor in a
few mins. :-)
its version 0.3.3 meanwhile and GPLv3+.

Best regards,
Dennis


signature.asc
Description: OpenPGP digital signature

Bug#951394: pstoedit fails with findfont error with gs 9.26

[Ian Jackson]

Package: ghostscript, pstoedit
Version: 9.26a~dfsg-0+deb9u6, 3.70-3+b2
Tags: upstream
Control: fixed -1 + 9.50~dfsg-5

Hi.  Dear maintainers of ghsotscript and pstoedit,

Debian buster is affected by this bug:
  https://sourceforge.net/p/pstoedit/support-requests/4/

I'm afraid I don't understand the details.  It appears that DELAYBIND
is now deprecated with upstream.  Everything works in bullseye.  It is
broken in stretch.  Perhaps surprisingly, the pstoedit -nb option does
not help.

I am filing this bug here mostly to help other users of pstoedit on
Debian.  #880650 seems related but not identical.

Maybe it would be worth considering a backport of ghostscript 9.50 to
buster ?

Steps to reproduce:

$ cat <<'END' >test.ps
%!
/NimbusMonoPS-Bold findfont
50 scalefont
setfont
100 100 moveto
(C) show
zealot:play> PS1='$ '
END
$ pstoedit -f dump test.ps dump.ou
pstoedit: version 3.70 / DLL interface 108 (built: Oct 11 2016 - release build 
- g++ 6.2.1 20161215 - 64-bit) : Copyright (C) 1993 - 2014 Wolfgang Glunz
Error: /undefined in /findfont
Operand stack:
   NimbusMonoPS-Bold
Execution stack:
   %interp_exit   .runexec2   --nostringval--   .findfontop   --nostringval--   
2   %stopped_push   --nostringval--   .findfontop   .findfontop   false   1   
%stopped_push   2044   1   3   %oparray_pop   2043   1   3   %oparray_pop   
2024   1   3   %oparray_pop   1884   1   3   %oparray_pop   --nostringval--   
%errorexec_pop   .runexec2   --nostringval--   .findfontop   --nostringval--   
2   %stopped_push   --nostringval--   2044   1   3   %oparray_pop   2043   1   
3   %oparray_pop   2024   1   3   %oparray_pop   1884   1   3   %oparray_pop   
--nostringval--   %errorexec_pop   .runexec2   --nostringval--   .findfontop   
--nostringval--   2   %stopped_push   --nostringval--   .findfontop   1975   1  
 3   %oparray_pop
Dictionary stack:
   --dict:970/1684(ro)(G)--   --dict:0/20(G)--   --dict:321/450(L)--
Current allocation mode is local
Current file position is 31
GPL Ghostscript 9.26: Unrecoverable error, exit code 1
PostScript/PDF Interpreter finished. Return status 256 executed command : 
/usr/bin/gs -q -dDELAYBIND -dWRITESYSTEMDICT -dNODISPLAY -dNOEPS 
"/tmp/psinZUL0CV"
The interpreter seems to have failed, cannot proceed !
$ 

-- 
Ian JacksonThese opinions are my own.

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

Bug#951393: octavia-health-manager: French debconf templates translation

[Jean-Philippe MENGUAL]

Package: octavia-health-manager
Version: N/A
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

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

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

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


Please find attached the french debconf templates translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Regards


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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: 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)
LSM: AppArmor: enabled
# French translation for octavia.
# Copyright (C) 2020, French l10n team 
# This file is distributed under the same license as the octavia package.
# Jean-Philippe MENGUAL , 2020.
#
msgid ""
msgstr ""
"Project-Id-Version: octavia\n"
"Report-Msgid-Bugs-To: octa...@packages.debian.org\n"
"POT-Creation-Date: 2019-12-31 16:09+0100\n"
"PO-Revision-Date: 2020-02-15 22:35+0100\n"
"Last-Translator: Jean-Philippe MENGUAL \n"
"Language-Team: French \n"
"Language:  fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../octavia-health-manager.templates:1001
msgid "Configure health-manager with debconf ?"
msgstr "Faut-il configurer health-manager avec debconf ?"

#. Type: boolean
#. Description
#: ../octavia-health-manager.templates:1001
msgid ""
"Octavia health-manager needs to have bind_ip, bind_port and heartbeat_key "
"configured. This can be configured via debconf."
msgstr ""
"octavia-health-manager a besoin que bind_ip, bind_port et heartbeat_key "
"soient configurés. Vous pouvez le faire avec debconf."

#. Type: string
#. Description
#: ../octavia-health-manager.templates:2001
msgid "Value for health_manager bind_ip:"
msgstr "Valeur de bind_ip de health_manager :"

#. Type: string
#. Description
#: ../octavia-health-manager.templates:2001
msgid ""
"IP address of Octavia health_manager on which will listen for heart beats. "
"This IP has to be in external octavia LB network to be able communicate with "
"amphora instances. This value will be set in config block health_manager "
"bind_ip."
msgstr ""
"Adresse IP d'octavia-health_manager sur laquelle seront écoutées les "
"pulsations cardiaques. Cette IP doit être dans un réseau LB externe "
"d'octavia pour pouvoir communiquer avec des instances amphora. Cette valeur "
"sera définie dans le bloc de configuration bind_ip de health_manager."

#. Type: string
#. Description
#: ../octavia-health-manager.templates:3001
msgid "Value for health_manager bind_port:"
msgstr "Valeur de bind_port de health_manager :"

#. Type: string
#. Description
#: ../octavia-health-manager.templates:3001
msgid ""
"IP port of Octavia health_manager on which will listen for heart beats. This "
"value will be set in config block health_manager bind_port."
msgstr ""
"Port IP d'octavia health_manager sur lequel seront écoutées les pulsations "
"cardiaques. Cette valeur sera définie dans le bloc de configuration "
"bind_port de health_manager."

#. Type: string
#. Description
#: ../octavia-health-manager.templates:4001
msgid "Octavia's hearthbeat_key:"
msgstr "hearthbeat_key d'Octavia :"

#. Type: string
#. Description
#: ../octavia-health-manager.templates:4001
msgid ""
"Key used to validate amphora sending the message. This value will be set in "
"config block health_manager, heartbeat_key."
msgstr ""
"Clé utilisée pour valider l'envoi d'un message amphora. Cette valeur sera "
"définie dans le bloc de configuration de health_manager, heartbeat_key."

Bug#951392: RFS: sosreport/3.9-1

[Eric Desrochers]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sosreport":

 * Package name: sosreport
   Version : 3.9-1
   Upstream Author : Bryn M. Reeves 
 * URL : https://sos.readthedocs.io/en/latest/
 * License : GPL-2+
 * Vcs : https://github.com/sosreport/sos/
   Section : admin

It builds those binary packages:

  sosreport - Collect and package diagnostic and support data

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sosreport/sosreport_3.9-1.dsc

Changes since the last upload:

* New 3.9 upstream release.
- Improved human-readable archive naming and support for archive labels
- Improved reporting of archive output and properties
- Support for automatic uploading of report archives via FTP and HTTPS
- Automatic PATH support on Ubuntu distributions
- Improved policy performance
- Improved service status collection API
- 9 new plugins: cloud_init, convert2rhel, ebpf, fwupd, login, nginx,
  nvidia, openstack_tripleo
- 6 obsolete plugins removed or merged into other plugins:
  katello, last, mrggrid, mrgmessg, satellite
- Significant updates to 14 plugins: dlm, dnf, ceph, foreman, gluster,
  gnocchi, juju, kubernetes, logs, maas, networking, openvswitch,
  python, plugins
- The openswan plugin was renamed to libreswan to reflect the active
  upstream project name
- Updated Red Hat presets and new Cloud Forms preset
- Updates to networking plugin namespace handling
- Updates to the OVN plugins (ovn_central, ovn_host)
- Kernel eBPF data consolidated in a single plugin

  Further release information and tarballs are available at:
https://github.com/sosreport/sos/releases/tag/3.9

  * Other specific modifications:
- d/p/0001-skip-py2-only-tests.patch: Omit Python2 only unittests

Regards,

Bug#951391: RM: reposurgeon [armel armhf i386] -- ANAIS; 32-bit machines no longer supported

[Anthony Fok]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear FTP Masters,

As of Reposurgeon 4.0, the Python-to-Go conversion has been completed
with major performance improvement.

However, as Debian buildd results for 4.2-1 show, reposurgeon
no longer builds on 32-bit architectures:
https://buildd.debian.org/status/logs.php?pkg=reposurgeon&ver=4.2-1

I inquired upstream at https://gitlab.com/esr/reposurgeon/issues/255,
and author Eric S. Raymond @esr replied:

I haven't bothered to keep the code 32-bit-compatible because
4GB isn't enough address space for medium to large large
repository conversions.  The manual page already says:

Because the code is designed for dealing with large data sets,
it has been optimized for 64-bit machines and no particular effort
has been made to keep it 32-bit clean.  Various counters may
overflow if you try using it to lift a large repository on a
32-bit machine.

When Julien Rivaud suggested replacing int by int64 throughout the code,
Eric further replied:

@frnchfrgg Unfortunately changing int to int64 would be
more of a pain than you've perhaps realized yet.
Range clauses and various system-library things are wired to int;
we'd have to add an annoying number of castS and var statements
to fix that.

I don't think it's worth the complexity increment.  After
fifteen years of adverse selection, repositories small enough
not to blow out a 4GB limit but not already converted are
increasingly rare, meaning that a true 32-bit build is not
much good for anything but passing its own regression tests.
I wrote about the adverse-selection effect in 2014:
http://esr.ibiblio.org/?p=6216

Soon after, Eric updated the INSTALL documentation
https://gitlab.com/esr/reposurgeon/-/blob/master/INSTALL.adoc:

You will need 64-bit hardware. This code is not intended to
run on 32-bit machines (which have an address space too small to be
useful for repository surgery) and won't build on them.


So, I went ahead to remove [armel armhf i386 mipsel] from Architecture
list in debian/control:
See https://salsa.debian.org/debian/reposurgeon/commit/5f8db4c

And proceeded to file this Bug report to you so as to allow
reposurgeon to be migrated to testing.

Many thanks!

Anthony Fok


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAl5IX9wACgkQ6iUAtBLF
ms+n/w/+IRwi/WS1Gc69DL0jmhG86WdmFJLmoxIcAiFAAf6LighG3Ix8lxi1oON5
poUEaCHsUF9ktzenUekLxVafJA4YxlducMdIyk9zlhKUQfdrVL1uDZwkE6FS0ZAT
QRUApk4BsABX1uDvERXc+4pBWcif1/SLLyY3J5SRtDXFjLbXLD9rNT9QuDanFiL2
nN0eDzhy61s0nlNUdGTjl5i9EPVY9m253FHV7U93oNQRPjJFhVWGphAGzdImjpk1
hxl1qiSIRbO/d9OHbNPporp4YoSdCOIlGsitQAyWn5JLQZlD1GIJSOw3FDsxi2DX
QMNEWG0t3hto6UhxjSsbodpHWD3YunOppwDYiJR34Bj760iPhTYvDIlKEuWcMFSK
OKlYthnd53XuewJRHZ/ADsvW5EJ7QYroIMCf6RcR4+MC738EK8ZkILxB8MDIbiRI
l3+F59yD3cm3rWZUIzFxycvTZakUzw72hAWlb7n5z5tB9+G29rk5wbl9Lvg/3C2e
dH/oDw0VkiQo6ATPHm8Kj0uvhqS+86D9QfczFynsVd0xyp0ZE7av7KQZHtk1G95m
ujx9lHpWSTZmHvcMpCIhCSaROVmV3RTgpFvsxCi/5oRgG170iTVGSMKBxNcBrETM
BZ/Tx/IIlM1gFwhCdEzNMaFYblU60g+yA8XgCW7kjct24t0UWgI=
=iBtj
-END PGP SIGNATURE-

Bug#949312: txsocksx: should this package be removed?

[Adrian Bunk]

On Sat, Feb 08, 2020 at 08:25:35PM -0500, Sandro Tosi wrote:
> On Fri, Feb 7, 2020 at 6:37 AM Adrian Bunk  wrote:
> > On Thu, Feb 06, 2020 at 09:20:31PM -0500, Sandro Tosi wrote:
> > > On Sun, Feb 2, 2020 at 6:51 AM Adrian Bunk  wrote:
> > > > On Tue, Jan 28, 2020 at 04:06:28PM -0500, Sandro Tosi wrote:
> > > > >...
> > > > > python-txsocksx -> foolscap -> tahoe-lafs
> > > > >
> > > > > both foolscap and tahoe-lafs were removed from testing, so to my
> > > > > script python-txsocksx appears as a leaf package (as its removal wont
> > > > > break already broken/RC packages not in testing). not sure what we
> > > > > want to do here, none of the 2 other packages will get fix anytime
> > > > > soon and may get removed from debian entirely at some point.
> > > > >...
> > > >
> > > > The latter statement is not true.
> > > >
> > > > Both tahoe-lafs and foolscap have substantial upstream activities
> > > > towards Python 3 porting,
> > >
> > > my statement says "none of the 2 other packages will get fix anytime
> > > soon and may get removed from debian entirely at some point" -- what
> > > do you find un-true about it?
> > >
> > > i did not say those projects python3 port is not being worked on, but
> > > i say that they are not close to finishing it, which includes both
> > > porting the code *and* testing it and finally release a version that
> > > has the python3 port.
> >
> > To me it looks likely to be finished in time for the bullseye freeze.
> 
> that'd be great, so they could be easily re-introduced in Debian once
> they are ready.

Even greater would be to no have all the package removal effects like
"sorry that your package has been removed from Debian" bug closure
emails to users.

>...
> > working hard on Python 3 porting which is already 89% completed.
> > (no blaming, just stating facts)
> 
> i'm afraid you got facts mixed up: i asked for the removal of
> txsocksx, while it's tahoe-lafs port that's at 89% completion.
>...

You asked the ftp team to recommend filing a removal bug for tahoe-lafs.

It is hard to see any other purpose behind your "Let me know how you 
want me to proceed" since the alternative would have been that you
just close your bug.

>...
> > What always strikes me as weird is the py2keep option, why are you
> > offering that some packages can use Python 2.7 for an additional
> > *Debian release*?
> 
> well, you need to ask that to who crafted the bug template.
> 
> There *are* cases where it makes sense, the one that comes to mind is
> moin: wiki.d.o uses that software and we're in no position to switch
> to a different wiki engine; moin hasnt been ported to python3 yet
> (likely it wont) so it is justifiable to mark it as py2keep.

And users who use tahoe-lafs might not be in a position to switch
to a different file storage - same situation, except that you are
not be among the users.

> > Much of the python2 removal only makes sense when the point is to not
> > have to ship and security support Python 2.7 in Debian 11.
> 
> the level of security support will be decided by the security team in
> concert with the release team, if i remember correctly how it was done
> in the part (f.e. with chromium and node?)

Did DSA agree to run wiki.d.o with an interpreter without security support?

Shipping the software running wiki.d.o in bullseye only makes sense 
after security support for the interpreter it uses has been secured.

>...
> If we end up with 2/300 python2 modules/apps in bullseye (for
> important packages) that's already a good win, and the security and
> infrastructural implications of having such a small subset of packages
> will be entirely different than (say) 1500 still pending.
>...

In many of the more scientific areas of the archive it is normal that 
important software for some specific field (and therefore with low 
popcon) was written as part of a scientific project or thesis and
is not maintained afterwards.

In many cases the only choice for the Debian maintainers to fix your 
bugs has been to upload whatever 2to3 produced, and hope that it works.

If the python2.7 interpreter cannot be shipped in bullseye because it is 
not supportable this is the best option available.

If the python2.7 interpreter is shipped and supported in bullseye this 
is bad, since it gives our users worse software for no good reason.

Plenty of bugs like #948706 pop up for buggy python3 conversions.

The security implication of many of the Python 3 conversions might be a 
disaster, people who do not know the code somehow trying to get it 
ported sounds like a perfect recipe for Debian-specific CVEs.

Please do not get me wrong, I do appreciate your overall work on moving 
Debian towards Python 3 and for a large part of the archive this move 
will not be a problem for bullseye. But if the python2.7 interpreter 
ends up being shipped in bullseye then reducing the number of python2 
using packages is not a value itself, and removals or buggy python3 
conversions will for many packages be 

Bug#944330: debian-policy: Hyphenation damage on plain text output

[Dmitry Shachnev]

On Sun, Nov 17, 2019 at 11:11:37AM -0800, Russ Allbery wrote:
> Sphinx uses Python's standard textwrap module to wrap text output.  That
> class has an option, break_on_hyphens, which defaults to True but can be
> set to False.  For Policy, we want to set it to False, but Sphinx doesn't
> expose a configuration setting that allows this.
>
> I'm reassigning this bug to Sphinx, but it's really an upstream feature
> request.

Upstream said they are not interested in such an option, but they may change
their opinion if they see any ugly examples:

https://github.com/sphinx-doc/sphinx/issues/6867

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#951109: wlroots: Testing migration blocked by autopkgtest

[Birger Schacht]

Hi,

On 2/11/20 10:20 AM, Birger Schacht wrote:
> Source: wlroots
> Version: 0.10.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> the testing migration of wlroots is blocked by a failing autopkgtest.
I've installed autopkgtest on my system and was able to reproduce the
failing test (though only when using --no-built-binaries switch of
autopkgtest).
The tests pass if I add libx11-xcb-dev and libxcb-xinput-dev to the
Depends: of the test
Or should those rather be Dependencies of libwlroots-dev?

cheers,
Birger



signature.asc
Description: OpenPGP digital signature

Bug#951390: sarg: CVE-2019-18932

[Salvatore Bonaccorso]

Source: sarg
Version: 2.3.11-1
Severity: important
Tags: security upstream
Control: found -1 2.3.10-2

Hi,

The following vulnerability was published for sarg.

CVE-2019-18932[0]:
| log.c in Squid Analysis Report Generator (sarg) through 2.3.11 allows
| local privilege escalation. By default, it uses a fixed temporary
| directory /tmp/sarg. As the root user, sarg creates this directory or
| reuses an existing one in an insecure manner. An attacker can pre-
| create the directory, and place symlinks in it (after winning a
| /tmp/sarg/denied.int_unsort race condition). The outcome will be
| corrupted or newly created files in privileged file system locations.

The issue was fixed upstream in [1].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-18932
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18932
[1] 
https://sourceforge.net/p/sarg/code/ci/8ec6d20be8c0da3c885aba78e63251f2e5080748

Regards,
Salvatore

Bug#951389: akonadi-backend-postgresql: Initialisation of database fail if locale en_US.UTF8 is not avalaible systemwide

[Bastien Roucariès]

Package: akonadi-backend-postgresql
Version: 4:19.08.3-1
Severity: grave
Justification: renders package unusable
Tags: l10n patch
forwarded: https://bugs.kde.org/show_bug.cgi?id=417721

Dear Maintainer,

The creation of database fail if locale en_US.UTF8 is not installed systemwise 
(by pulling
locale-all package for instance).

Indeed akonadi create database by using --locale en_US.UTF8
(see 
https://github.com/KDE/akonadi/blob/8aca730125ad247014868ba6e4cc530f4209619a/src/server/storage/dbconfigpostgresql.cpp#L297
and 
https://github.com/KDE/akonadi/blob/8aca730125ad247014868ba6e4cc530f4209619a/src/server/storage/dbconfigpostgresql.cpp#L484

correct flags will be: -E UTF8 --no-locale   
that does not need to install a locale systemwise and is safe

Thanks

Bastien



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

Bug#949591: gitlab: Gitlab not serving cached assets

[vv221]

On Wed, 22 Jan 2020 14:43:45 +0100 David L  wrote:
> Apparently, gitlab is not serving cached assets.
> 
> That's result on a very long loading time.
> 
> Example of most relevant file: 
> 
> Cached:
> 
> 304 Not Modified 
> https://salsa.debian.org/assets/webpack/main.b91d0a07.chunk.js <-- 2,55mb, 
> 849ms load time
> 304 Not Modified 
> https://assets.gitlab-static.net/assets/webpack/main.45f98342.chunk.js <-- 
> 0b, 42ms load time
> 
> My installation:
> 
> 200 OK https://git.myserver.net/assets/webpack/main.chunk.js <-- 20.87mb, 
> 12135ms load time

I think this is due to the environment variable NODE_ENV not being set
to "production" when the assets building command is called.

I’m currently experimenting a bit to find a way to reliably pass this
variable to any rake command, but in the meantime it would be nice to
know if the maintainers team has some advice on this front.



signature.asc
Description: OpenPGP digital signature

Bug#948859: coccinelle: Package is uninstallable

[Sebastian Andrzej Siewior]

On 2020-01-16 15:11:42 [+0100], Stéphane Glondu wrote:
> > The following packages have unmet dependencies:
> >  coccinelle : Depends: libpcre-ocaml-2h5n2 but it is not installable
> >   Depends: ocaml-base-nox-4.05.0 but it is not installable
> > E: Unable to correct problems, you have held broken packages.
> 
> This is known; the package currently FTBFS in unstable. I've fixed it in
> git, but wonder if it is worth an upload because of #885267, which I've
> not fixed. In its current state, the package will never migrate to
> testing because of #885267.

Could we please get something working into unstable? I can install
neither the package from unstable nor from experimental. I failed to
build package from the git repo.

Sebastian

Bug#951388: [akonadi-backend-postgresql] apparmor profile unsuitable

[Bastien Roucariès]

Package: akonadi-backend-postgresql
Version: 4:19.08.3-1
Severity: grave
Justification: renders package unusable
Tags: patch

Dear Maintainer,

Please find the following update for apparmor 

Please apply

Bastiendiff --git a/apparmor.d/postgresql_akonadi b/apparmor.d/postgresql_akonadi
index c25fa08..b650612 100644
--- a/apparmor.d/postgresql_akonadi
+++ b/apparmor.d/postgresql_akonadi
@@ -5,21 +5,27 @@
 
 profile postgresql_akonadi {
   #include 
+  #include 
   #include 
 
   capability setgid,
   capability setuid,
 
+  signal receive set=kill peer=/usr/bin/akonadiserver,
+  signal receive set=term peer=/usr/bin/akonadiserver,
+
   /etc/passwd r,
+
   /{usr/,}bin/dash mrix,
   /{usr/,}bin/locale mrix,
+  /{var/,}run/systemd/resolve/resolv.conf r,
   /usr/lib/postgresql/*/bin/initdb mrix,
   /usr/lib/postgresql/*/bin/pg_ctl mrix,
   /usr/lib/postgresql/*/bin/postgres mrix,
+  /usr/lib/postgresql/*/bin/pg_upgrade mrix,
   /usr/share/postgresql/** r,
   owner /dev/shm/PostgreSQL.* rw,
   owner @{xdg_data_home}/akonadi/** rwlk,
-  owner @{xdg_data_home}/akonadi/db_data/** l,
 
   # Site-specific additions and overrides. See local/README for details.
   #include 
diff --git a/apparmor.d/usr.bin.akonadiserver b/apparmor.d/usr.bin.akonadiserver
index 2055a49..8a8cc23 100644
--- a/apparmor.d/usr.bin.akonadiserver
+++ b/apparmor.d/usr.bin.akonadiserver
@@ -13,7 +13,8 @@
 
   signal send set=kill peer=mysqld_akonadi,
   signal send set=term peer=mysqld_akonadi,
-
+  signal send set=kill peer=postgresql_akonadi,
+  signal send set=term peer=postgresql_akonadi,
 
   /etc/xdg/** r,
   /usr/bin/akonadiserver mr,
@@ -32,7 +33,7 @@
   owner @{xdg_config_home}/akonadi* rw,
   owner @{xdg_config_home}/QtProject/qtlogging.ini r,
   owner @{xdg_config_home}/akonadi/ rw,
-  owner @{xdg_config_home}/akonadi/* rwl,
+  owner @{xdg_config_home}/akonadi/** rwl,
   owner @{xdg_config_home}/akonadi/akonadiconnectionrc wl,
   owner @{xdg_config_home}/akonadi/akonadiconnectionrc.lock rwk,
   owner @{xdg_config_home}/akonadi/akonadiserverrc.lock rwk,
@@ -44,6 +45,8 @@
   owner @{xdg_data_home}/akonadi/** rwk,
   owner @{PROC}/@{pid}/loginuid r,
   owner @{PROC}/@{pid}/mounts r,
+  owner /{,var/}run/user/[0-9]*/akonadi/ w,
+  owner /{,var/}run/user/[0-9]*/akonadi/** rw,
 
   # Site-specific additions and overrides. See local/README for details.
   #include 


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

Bug#949332: fwknop-apparmor-profile: consider adding ipset to apparmor profile

[Francois Marier]

In other words, the attached patch is what was needed to make this work on
your machine?

Francois

-- 
https://fmarier.org/
--- a/extras/apparmor/usr.sbin.fwknopd
+++ b/extras/apparmor/usr.sbin.fwknopd
@@ -20,16 +20,23 @@
   /bin/bash rix,
   /etc/fwknop/access.conf r,
   /etc/fwknop/fwknopd.conf r,
+  /etc/host.conf r,
   /etc/nsswitch.conf r,
   /etc/passwd r,
   /etc/protocols r,
+  /etc/services r,
+  @{PROC}/@{pid}/net/ip_tables_names r,
   /root/.gnupg/* rwkl,
   /run/fwknop/ rw,
   /run/fwknop/* rwk,
+  /run/resolvconf/resolv.conf r,
   /run/xtables.lock rwk,
+  /sbin/ipset rix,
   /sbin/xtables-multi rix,
   /usr/bin/gpg rix,
   /usr/sbin/fwknopd mr,
+  /usr/sbin/ipset rix,
+  /usr/sbin/xtables-nft-multi rix,
   /var/cache/nscd/passwd r,
 
 }

Bug#951387: [PATCH] Misleading XKBLAYOUT is set when choosing Lithuanian in dpkg-reconfigure keyboard-configuration

[Mantas Baltix]

Package: console-setup
Version: 1.194

Dear console-setup maintainer,

If user chooses Lithuanian keyboard layout during installation or
dpkg-reconfigure keyboard-configuration then misleading layout
configuration is set in /etc/default/keyboard :

XKBLAYOUT="lt,lt"
XKBVARIANT=",us"

This configuration is not intuitive, because people think, that
sometimes Lithuanian keyboard works (when lt1 is selected in GNOME
shell or other DE) and sometimes doesn't work (when LT2 is selected,
because LT2 is really English US layout where lithuanian letters can
be entered only when AltGr is pressed) - most of desktop users doesn't
even notice small number 1 or 2 after LT)

So, majority of Lithuanian users are force to removed second lt(us)
layout and add English (US) altgr-intl layout.

Correct, intuitive for all users, /etc/default/keyboard should be:

XKBMODEL="pc105"
XKBLAYOUT="lt,us"
XKBVARIANT=",altgr-intl"
XKBOPTIONS="grp_led:scroll"
BACKSPACE="guess"

I'm attaching a patch to debian/keyboard-configuration.config file
which fixes this issue - patch replaces not intuitive secondary lt(us)
layout with us(altgr-intl), which is used by the majority of
Lithuanian users as second layout.
this improvement works fine also with Ubuntu installer, I've tested my
patch with Ubuntu 19.10, look at this bugreport
https://launchpad.net/ubuntu/+source/console-setup/+bug/1863001

Btw, this issue is very old, exists even in console-setup 1.47
(released in 2009) and older, old Debian and Ubuntu users already got
used to this bug, they know, that first step after installation is to
remove lt(us) layout and add us(altgr-intl) or other us/en layout :)

Thanks for maintaining free software :)
Mantas Kriaučiūnas

-- 
Prekyba kompiuteriais su Linux OS - http://tinklas.eu/prekyba
Naudokite laisvą Linux operacinę sistemą savo kompiuteryje - http://baltix.eu
Use Ubuntu and Debian GNU/Linux OS !
--- /tmp/console-setup-1.194/debian/keyboard-configuration.config	2019-12-05 14:09:52.0 +
+++ keyboard-configuration.config	2020-02-13 15:17:18.0 +
@@ -1103,7 +1103,7 @@
 # on values of $XKBLAYOUT and $XKBVARIANT.
 if [ "$XKBLAYOUT" ]; then
 case "$XKBLAYOUT" in
-	lt,lt)
+	lt,us)
 	debconf_layout="${XKBLAYOUT%,*}"
 	debconf_variant="${XKBVARIANT%,*}"
 	unsupported_layout=no
@@ -1497,7 +1497,7 @@
 			esac
 			;;
 		lt)
-			XKBLAYOUT=lt,lt
+			XKBLAYOUT=lt,us
 			;;
 		me)
 			case "$debconf_variant" in
@@ -1527,12 +1527,12 @@
 XKBVARIANT="latin,$debconf_variant" ;;
 		esac
 ;;
-lt,lt)
+lt,us)
 		case "$debconf_variant" in
 		us)
 XKBVARIANT="us," ;;
 		*)
-XKBVARIANT="$debconf_variant,us" ;;
+XKBVARIANT="$debconf_variant,altgr-intl" ;;
 		esac
 ;;
 		*,*)

Bug#930869: Don't release with buster

[Jan Braun]

Package: pm-utils
Followup-For: Bug #930869

pm-utils is now marked for autoremoval due to this frivolous RC bug.
As another satisfied pm-utils user, this worries me.

Would someone with more authority please downgrade/close this as
invalid, or at least get Michael Biebl to to adress the questions Sam
Hartman raised more than 7 month ago in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930869#74 ?

Thank you for your work in Debian,
Jan


signature.asc
Description: PGP signature

Bug#951386: uscan: fails to downloads from a “dumb” HTTP git repository

[nicoo]

Package: devscripts
Version: 2.20.2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainers,

While updating debian/watch for package xe, I discovered that uscan fails
to download packages, in mode=git, when given a repository served over the
“dumb” HTTP(S) transport (in particular, without support for shallow clones):

> $ cat debian/watch
> version=4
> opts="mode=git, pgpmode=gittag" \
>   https://github.com/leahneukirchen/xe.git refs/tags/v(\d\S+)
> 
> $ uscan -v --force-download
> uscan info: uscan (version 2.20.2) See uscan(1) for help
> uscan info: Scan watch files in .
> uscan info: Check debian/watch and debian/changelog in .
> uscan info: package="xe" version="0.11-4" (as seen in debian/changelog)
> uscan info: package="xe" version="0.11" (no epoch/revision)
> uscan info: ./debian/changelog sets package="xe" version="0.11"
> uscan info: Found upstream signing keyring: debian/upstream/signing-key.asc
> uscan info: Process watch file at: debian/watch
> package = xe
> version = 0.11
> pkg_dir = .
> uscan info: opts: mode=git, pgpmode=gittag
> uscan info: line: https://git.vuxu.org/xe refs/tags/v(\d\S+)
> uscan info: Parsing mode=git
> uscan info: Parsing  pgpmode=gittag
> uscan info: line: https://git.vuxu.org/xe refs/tags/v(\d\S+)
> uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.11
> uscan info: Last orig.tar.* tarball version (dversionmangled): 0.11
> uscan info: Execute: git ls-remote https://git.vuxu.org/xe
> uscan info: Found the following matching refs:
>  refs/tags/v0.11 (0.11)
>  refs/tags/v0.10 (0.10)
>  refs/tags/v0.9 (0.9)
>  refs/tags/v0.8 (0.8)
>  refs/tags/v0.7.0 (0.7.0)
>  refs/tags/v0.6.1 (0.6.1)
>  refs/tags/v0.6 (0.6)
>  refs/tags/v0.5 (0.5)
>  refs/tags/v0.4 (0.4)
>  refs/tags/v0.3 (0.3)
>  refs/tags/v0.2 (0.2)
>  refs/tags/v0.1 (0.1)
>  HEAD ()
>  refs/heads/master ()
>  refs/heads/perc-regex ()
> uscan info: Looking at $base = https://git.vuxu.org/xe with
> $filepattern = refs/tags/v(\d\S+) found
> $newfile = refs/tags/v0.11
> $newversion  = 0.11
> $lastversion = 0.11
> uscan info: Upstream URL(+tag) to download is identified as
> https://git.vuxu.org/xe refs/tags/v0.11
> uscan info: Filename (filenamemangled) for downloaded file: xe-0.11.tar.xz
> uscan info: Newest version of xe on remote site is 0.11, local version is 0.11
> uscan info:=> Package is up to date for from
>   https://git.vuxu.org/xe refs/tags/v0.11
> uscan info:=> Forcing download as requested
> uscan info: Downloading upstream package: xe-0.11.tar.xz
> Cloning into bare repository '../xe-temporary.1117681.git'...
> fatal: dumb http transport does not support shallow capabilities
> uscan error: Command failed (git clone --bare --depth=1 -b v0.11 
> https://git.vuxu.org/xe ../xe-temporary.1117681.git)


I would expect uscan to fallback to a non-shallow clone in this setting.


Best,

  nicoo

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.24-1
ii  file  1:5.38-4
ii  gnupg 2.2.19-1
ii  gnupg22.2.19-1
ii  gpgv  2.2.19-1
ii  libc6 2.29-10
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-2
ii  libmoo-perl   2.003006-1
ii  libwww-perl   6.43-1
ii  patchutils0.3.4-2+b1
ii  perl  5.30.0-9
ii  python3   3.7.5-3
ii  sensible-utils0.0.12+nmu1
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.4
pn  at  
ii  curl7.67.0-2
pn  dctrl-tools 
ii  debian-keyring  2020.02.02
ii  dput-ng [dput]  1.29
pn  equivs  
ii  libdistro-info-perl 0.23
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.23-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck 

Bug#951385: keyboard-configuration: No accented letters in mk_MK

[Goran Delcev]

Package: keyboard-configuration
Version: 1.193~deb10u1
Severity: normal

Dear Maintainer,


   My /etc/default/keyboard file is:

   XKBMODEL="pc105"
   XKBLAYOUT="us,mk"
   XKBVARIANT=""
   
XKBOPTIONS="grp:sclk_toggle,compose:paus,grp_led:scroll,terminate:ctrl_alt_bksp"

   BACKSPACE="guess"
   
 As you can see I have edited my keyboard file, to suit my needs. After 
this I have rebooted the system.
   
   In console I cannot get accented е and и of Macedonian alphabet. Also I 
cannot set PrtScr to be compose key. Combination compose key followed by e and 
= is not giving the euro sign. In Xserver everything is working fine.
   



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

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

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.71
ii  liblocale-gettext-perl  1.07-3+b4

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

Versions of packages console-setup depends on:
ii  console-setup-linux  1.193~deb10u1
ii  debconf  1.5.71
ii  xkb-data 2.26-2

Versions of packages console-setup suggests:
ii  locales   2.28-10
ii  lsb-base  10.2019051400

Versions of packages console-setup-linux depends on:
ii  init-system-helpers  1.56+nmu1
ii  kbd  2.0.4-4

Versions of packages console-setup-linux suggests:
ii  console-setup  1.193~deb10u1

Versions of packages keyboard-configuration is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.4-4
ii  systemd   241-7~deb10u3

-- debconf information excluded

Bug#697716: [supertuxkart] Wrong number of points added to the total score in story mode

[Steve Cotton]

On Tue, Jan 08, 2013 at 09:05:08PM +0100, Bob wrote:
> Package: supertuxkart
> Version: 0.8-1
> Severity: normal
> 
> Sometimes the number of points added to the total score in story mode is
> incorrect. Happend a couple of times. For example after getting a silver
> award for a challenge with 9 points, the score goes from 160 to 161 points.

Hi Bob,

Sorry that no-one triaged this ancient bug report earlier, but as supertuxkart
has continued with active development I guess that this is already fixed.

However, I can think of one in-game situation that sounds similar, but isn't a
bug. If you already have bronze for a race then you already have 8 points for
bronze, and you only get 1 extra point for getting silver.

BR,
Steve

Bug#951384: ck: FTBFS against glibc 2.30

[Logan Rosen]

Package: ck
Version: 0.6.0-1.2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear Maintainer,

ck fails to build from source against glibc 2.30, which is currently in
experimental. In Ubuntu, glibc 2.30 has been used since the last stable
release.

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

  * d/p/glibc-2.30.patch: Apply patch from upstream to fix FTBFS against glibc
2.30.

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 ck-0.6.0/debian/patches/glibc-2.30.patch 
ck-0.6.0/debian/patches/glibc-2.30.patch
--- ck-0.6.0/debian/patches/glibc-2.30.patch1969-12-31 19:00:00.0 
-0500
+++ ck-0.6.0/debian/patches/glibc-2.30.patch2020-02-15 12:39:01.0 
-0500
@@ -0,0 +1,52 @@
+From b520d58d00b7ed6c5cc9bc97c62f07e09f4f49ad Mon Sep 17 00:00:00 2001
+From: Samy Al Bahra 
+Date: Tue, 29 Oct 2019 17:30:09 -0400
+Subject: [PATCH] regressions/common: rename gettid wrapper to common_gettid.
+
+glibc-2.30 added a wrapper to gettid (https://lwn.net/Articles/795127/).
+gettid will clash with the glibc-provided symbol. Remove the
+macro and instead move to a dedicated namespace.
+
+We go this route to avoid introducing unnecessary complexity to
+build.
+
+Fixes #147
+---
+ regressions/common.h | 8 +++-
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/regressions/common.h
 b/regressions/common.h
+@@ -267,13 +267,11 @@
+ #define AFFINITY_INITIALIZER {0, 0}
+ 
+ #ifdef __linux__
+-#ifndef gettid
+ static pid_t
+-gettid(void)
++common_gettid(void)
+ {
+   return syscall(__NR_gettid);
+ }
+-#endif /* gettid */
+ 
+ CK_CC_UNUSED static int
+ aff_iterate(struct affinity *acb)
+@@ -285,7 +283,7 @@
+   CPU_ZERO(&s);
+   CPU_SET(c % CORES, &s);
+ 
+-  return sched_setaffinity(gettid(), sizeof(s), &s);
++  return sched_setaffinity(common_gettid(), sizeof(s), &s);
+ }
+ 
+ CK_CC_UNUSED static int
+@@ -297,7 +295,7 @@
+   CPU_ZERO(&s);
+   CPU_SET((*core) % CORES, &s);
+ 
+-  return sched_setaffinity(gettid(), sizeof(s), &s);
++  return sched_setaffinity(common_gettid(), sizeof(s), &s);
+ }
+ #elif defined(__MACH__)
+ CK_CC_UNUSED static int
diff -Nru ck-0.6.0/debian/patches/series ck-0.6.0/debian/patches/series
--- ck-0.6.0/debian/patches/series  2019-11-21 03:36:35.0 -0500
+++ ck-0.6.0/debian/patches/series  2020-02-15 12:41:20.0 -0500
@@ -1 +1,2 @@
 allow-disable-sse.patch
+glibc-2.30.patch

Bug#951116: libmosquitto-dev package lacks header file mqtt_protocol.h

[Gianfranco Costamagna]

control: tags -1 patch pending

patch uploaded in deferred/2 and sent upstream

G.

On Tue, 11 Feb 2020 10:43:10 + "Ostkamp, Guido, MU" 
 wrote:
> Package: libmosquitto-dev
> Version: 1.6.8-1
> 
> The header file mqtt_protocol.h is missing in the libmosquitto-dev package.
> This file is required since it contains definitions required for MQTT v5 
> properties as mentioned in mosquitto.h
> 
> Excerpt from mosquitto.h
> 
> ...
> * Example:
> *  mosquitto_property *proplist = NULL;
> *  mosquitto_property_add_int32(&proplist, MQTT_PROP_MESSAGE_EXPIRY_INTERVAL, 
> 86400);
> */
> libmosq_EXPORT int mosquitto_property_add_int32(mosquitto_property 
> **proplist, int identifier, uint32_t value);
> ...
> 
> The definition MQTT_PROP_MESSAGE_EXPIRY_INTERVAL is not present in 
> msoquitto.h, but part of mqtt_protocol.h
> 
> Except from mqtt_protocol.h:
> 
> enum mqtt5_property {
> MQTT_PROP_PAYLOAD_FORMAT_INDICATOR = 1, /* Byte :   
> PUBLISH, Will Properties */
> MQTT_PROP_MESSAGE_EXPIRY_INTERVAL = 2,  /* 4 byte int : 
> PUBLISH, Will Properties */
> MQTT_PROP_CONTENT_TYPE = 3, /* UTF-8 string :   
> PUBLISH, Will Properties */
> MQTT_PROP_RESPONSE_TOPIC = 8,   /* UTF-8 string :   
> PUBLISH, Will Properties */
> MQTT_PROP_CORRELATION_DATA = 9, /* Binary Data :
> PUBLISH, Will Properties */
> MQTT_PROP_SUBSCRIPTION_IDENTIFIER = 11, /* Variable byte int :  
> PUBLISH, SUBSCRIBE */
> MQTT_PROP_SESSION_EXPIRY_INTERVAL = 17, /* 4 byte int : 
> CONNECT, CONNACK, DISCONNECT */
> MQTT_PROP_ASSIGNED_CLIENT_IDENTIFIER = 18,  /* UTF-8 string :   
> CONNACK */
> MQTT_PROP_SERVER_KEEP_ALIVE = 19,   /* 2 byte int : 
> CONNACK */
> MQTT_PROP_AUTHENTICATION_METHOD = 21,   /* UTF-8 string :   
> CONNECT, CONNACK, AUTH */
> MQTT_PROP_AUTHENTICATION_DATA = 22, /* Binary Data :
> CONNECT, CONNACK, AUTH */
> MQTT_PROP_REQUEST_PROBLEM_INFORMATION = 23, /* Byte :   
> CONNECT */
> MQTT_PROP_WILL_DELAY_INTERVAL = 24, /* 4 byte int : Will 
> properties */
> MQTT_PROP_REQUEST_RESPONSE_INFORMATION = 25,/* Byte :   
> CONNECT */
> MQTT_PROP_RESPONSE_INFORMATION = 26,/* UTF-8 string :   
> CONNACK */
> MQTT_PROP_SERVER_REFERENCE = 28,/* UTF-8 string :   
> CONNACK, DISCONNECT */
> MQTT_PROP_REASON_STRING = 31,   /* UTF-8 string :   All 
> except Will properties */
> MQTT_PROP_RECEIVE_MAXIMUM = 33, /* 2 byte int : 
> CONNECT, CONNACK */
> MQTT_PROP_TOPIC_ALIAS_MAXIMUM = 34, /* 2 byte int : 
> CONNECT, CONNACK */
> MQTT_PROP_TOPIC_ALIAS = 35, /* 2 byte int : 
> PUBLISH */
> MQTT_PROP_MAXIMUM_QOS = 36, /* Byte :   
> CONNACK */
> MQTT_PROP_RETAIN_AVAILABLE = 37,/* Byte :   
> CONNACK */
> MQTT_PROP_USER_PROPERTY = 38,   /* UTF-8 string pair :  All */
> MQTT_PROP_MAXIMUM_PACKET_SIZE = 39, /* 4 byte int : 
> CONNECT, CONNACK */
> MQTT_PROP_WILDCARD_SUB_AVAILABLE = 40,  /* Byte :   
> CONNACK */
> MQTT_PROP_SUBSCRIPTION_ID_AVAILABLE = 41,   /* Byte :   
> CONNACK */
> MQTT_PROP_SHARED_SUB_AVAILABLE = 42,/* Byte :   
> CONNACK */
> };
> 
> This file is also installed by the lib/Makefile in the Mosquitto distribution 
> on make install.
> 
> Please add the file to the package.
> 
diff -Nru mosquitto-1.6.8/debian/changelog mosquitto-1.6.8/debian/changelog
--- mosquitto-1.6.8/debian/changelog2020-02-08 09:35:50.0 +0100
+++ mosquitto-1.6.8/debian/changelog2020-02-15 19:51:49.0 +0100
@@ -1,3 +1,10 @@
+mosquitto (1.6.8-2) unstable; urgency=medium
+
+  * Also install mqtt_protocol.h in libmosquitto-dev package.
+(Closes: #951116)
+
+ -- Gianfranco Costamagna   Sat, 15 Feb 2020 
19:51:49 +0100
+
 mosquitto (1.6.8-1) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru mosquitto-1.6.8/debian/libmosquitto-dev.install 
mosquitto-1.6.8/debian/libmosquitto-dev.install
--- mosquitto-1.6.8/debian/libmosquitto-dev.install 2020-01-22 
12:05:17.0 +0100
+++ mosquitto-1.6.8/debian/libmosquitto-dev.install 2020-02-15 
19:47:32.0 +0100
@@ -1,3 +1,4 @@
 usr/include/mosquitto.h
+usr/include/mqtt_protocol.h
 usr/lib/*/libmosquitto.so
 usr/lib/*/pkgconfig/libmosquitto.pc
diff -Nru mosquitto-1.6.8/debian/patches/install-protocol.patch 
mosquitto-1.6.8/debian/patches/install-protocol.patch
--- mosquitto-1.6.8/debian/patches/install-protocol.patch   1970-01-01 
01:00:00.0 +0100
+++ mosquitto-1.6.8/debian/patches/install-protocol.patch   2020-02-15 
19:51:48.0 +0100
@@ -0,0 +1,14 @@
+Description: Also install mqtt_protocol.h, as is done in Makefile
+Author: Gianfranco Costamagna 

Bug#725484: A way to override blhc false-positives

[nicoo]

Hi Jari,

Sorry to comment on an old bug, but this is still an issue.

If there's no way for package maintainers to automatically ignore false
positives, this tremendously reduces the usefulness of blhc, by causing a
form of alarm fatigue:

People and processes (like CI) will ignore blhc failing, assuming it is a
known false positive, and will miss new issues being flagged.


On Fri, Oct 21, 2016 at 08:50:32AM +0300, Jari Aalto wrote:
> I think the request is for reading configuration file at startup:
> 
>   /.blhc-ignore   OR if not exists, search ...
>   $HOME/.blhc-ignore

I don't think expecting a local file works very well:

- ~/.blhc-ignore wouldn't allow using different rulesets for different
  packages, and doesn't work for collaborative packaging workflows (where
  we would want to keep the overrides for a package in its repository)

- ./debian/blhc-ignore works for (most?) collaborative packaging workflows,
  but doesn't work with the build logs checks done on [qa.d.o/bls] (also
  exposed on tracker.d.o)

[qa.d.o/bls]: https://qa.debian.org/bls/


Would it be possible to embed the overrides into the build log itself?


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#934478: RFS: sane-backends/1.0.27-3.2+deb10u1 -- API library for scanners -- utilities

[Jörg Frings-Fürst]

Closed. 

New upstream release work.

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#951376: ITP: scalene -- high-performance, high-precision CPU and memory profiler for Python

[Emmanuel Arias]

Hi
On 15/02/2020 15:02, Sandro Tosi wrote:
> did you see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951348 ?
Yes, and I ITP scalene. But, I made the mistake
of not retitle #951348.

I must close this issue and retitle that.

So sorry




signature.asc
Description: OpenPGP digital signature

Bug#951383: va-driver-all: missing i915_drv_video.so

[hjrkn]

Package: va-driver-all
Version: 2.4.0-1
Severity: important

Dear Maintainer,

After upgrading from Debian Rel. 9.8 to 10.3 my integrated graphics controller 
(Intel 945) is
supported by the kernel driver i915, but the corresponding va-driver does not 
exist so causing
depending modules (e.g. gnome-mpv) to crash.

Expected behaviour: the required file exists and works.

output of 'vainfo':
 libva info: VA-API version 1.4.0
 libva info: va_getDriverName() returns 0
 libva info: Trying to open /usr/lib/i386-linux-gnu/dri/i915_drv_video.so
 libva info: va_openDriver() returns -1
 vaInitialize failed with error code -1 (unknown libva error),exit

Current content of the referenced driver directory:
ls -l /usr/lib/i386-linux-gnu/dri/
 insgesamt 185268
 -rw-r--r-- 5 root root 11039216 Jan 15 20:28 i915_dri.so
 -rw-r--r-- 5 root root 11039216 Jan 15 20:28 i965_dri.so
 -rw-r--r-- 1 root root  1929992 Feb  2  2019 i965_drv_video.so
 -rw-r--r-- 1 root root  4086832 Apr  7  2019 iHD_drv_video.so
 -rw-r--r-- 8 root root 13545420 Jan 15 20:28 kms_swrast_dri.so
 -rw-r--r-- 8 root root 13545420 Jan 15 20:28 nouveau_dri.so
 -rw-r--r-- 3 root root  6704404 Jan 15 20:28 nouveau_drv_video.so
 -rw-r--r-- 5 root root 11039216 Jan 15 20:28 nouveau_vieux_dri.so
 -rw-r--r-- 5 root root 11039216 Jan 15 20:28 r200_dri.so
 -rw-r--r-- 8 root root 13545420 Jan 15 20:28 r300_dri.so
 -rw-r--r-- 8 root root 13545420 Jan 15 20:28 r600_dri.so
 -rw-r--r-- 3 root root  6704404 Jan 15 20:28 r600_drv_video.so
 -rw-r--r-- 5 root root 11039216 Jan 15 20:28 radeon_dri.so
 -rw-r--r-- 8 root root 13545420 Jan 15 20:28 radeonsi_dri.so
 -rw-r--r-- 3 root root  6704404 Jan 15 20:28 radeonsi_drv_video.so
 -rw-r--r-- 8 root root 13545420 Jan 15 20:28 swrast_dri.so
 -rw-r--r-- 8 root root 13545420 Jan 15 20:28 virtio_gpu_dri.so
 -rw-r--r-- 8 root root 13545420 Jan 15 20:28 vmwgfx_dri.so


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

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

Versions of packages va-driver-all depends on:
ii  i965-va-driver 2.3.0+dfsg1-1
ii  intel-media-va-driver  18.4.1+dfsg1-1
ii  mesa-va-drivers18.3.6-2+deb10u1

va-driver-all recommends no packages.

va-driver-all suggests no packages.

-- no debconf information

Bug#951381: Acknowledgement (pdftex ignores tl-paper setting)

[Ted To]

FYI, latex + dvipdf produces pdfs with the correct paper size.

On 2/15/20 12:36 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 951381: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951381.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian TeX Maintainers 

If you wish to submit further information on this problem, please
send it to 951...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#951382: Weasyprint does not work without ca-certificates package

[n_petr]

Package: weasyprint
Version: 51-1


When I invoke `weasyprint "https://www.google.com"; google.pdf' an error occurs, 
rather than the expected creation of *.pdf file.
Here is a transcript:


root@b4879d89318d:/home# weasyprint "https://www.google.com"; google.pdf
Traceback (most recent call last):
  File "/usr/lib/python3.7/urllib/request.py", line 1319, in do_open
encode_chunked=req.has_header('Transfer-encoding'))
  File "/usr/lib/python3.7/http/client.py", line 1252, in request
self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1298, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1247, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1026, in _send_output
self.send(msg)
  File "/usr/lib/python3.7/http/client.py", line 966, in send
self.connect()
  File "/usr/lib/python3.7/http/client.py", line 1422, in connect
server_hostname=server_hostname)
  File "/usr/lib/python3.7/ssl.py", line 423, in wrap_socket
session=session
  File "/usr/lib/python3.7/ssl.py", line 870, in _create
self.do_handshake()
  File "/usr/lib/python3.7/ssl.py", line 1139, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
verify failed: unable to get local issuer certificate (_ssl.c:1076)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/weasyprint/urls.py", line 284, in fetch
result = url_fetcher(url)
  File "/usr/lib/python3/dist-packages/weasyprint/urls.py", line 248, in 
default_url_fetcher
timeout=timeout, context=ssl_context)
  File "/usr/lib/python3.7/urllib/request.py", line 222, in urlopen
return opener.open(url, data, timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 525, in open
response = self._open(req, data)
  File "/usr/lib/python3.7/urllib/request.py", line 543, in _open
'_open', req)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 1362, in https_open
context=self._context, check_hostname=self._check_hostname)
  File "/usr/lib/python3.7/urllib/request.py", line 1321, in do_open
raise URLError(err)
urllib.error.URLError: 

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/weasyprint", line 11, in 
load_entry_point('WeasyPrint==51', 'console_scripts', 'weasyprint')()
  File "/usr/lib/python3/dist-packages/weasyprint/__main__.py", line 211, in 
main
media_type=args.media_type)
  File "/usr/lib/python3/dist-packages/weasyprint/__init__.py", line 112, in 
__init__
with result as (source_type, source, base_url, protocol_encoding):
  File "/usr/lib/python3.7/contextlib.py", line 112, in __enter__
return next(self.gen)
  File "/usr/lib/python3/dist-packages/weasyprint/__init__.py", line 396, in 
_select_source
with result as result:
  File "/usr/lib/python3.7/contextlib.py", line 112, in __enter__
return next(self.gen)
  File "/usr/lib/python3/dist-packages/weasyprint/__init__.py", line 406, in 
_select_source
with fetch(url_fetcher, url) as result:
  File "/usr/lib/python3.7/contextlib.py", line 112, in __enter__
return next(self.gen)
  File "/usr/lib/python3/dist-packages/weasyprint/urls.py", line 286, in fetch
raise URLFetchingError('%s: %s' % (type(exc).__name__, str(exc)))
weasyprint.urls.URLFetchingError: URLError: 


I suggest that the "ca-certificates" should be added into "Depends". When the 
package ca-certificates is installed, weasyprint works well.

I am using docker image "debian:bullseye":
  PRETTY_NAME="Debian GNU/Linux bullseye/sid"
  NAME="Debian GNU/Linux"
  ID=debian
  Linux b4879d89318d 4.19.76-linuxkit #1 SMP Thu Oct 17 19:31:58 UTC 2019 
x86_64 GNU/Linux.


Yours sincerely,
Petr Novak

Bug#951376: ITP: scalene -- high-performance, high-precision CPU and memory profiler for Python

[Sandro Tosi]

did you see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951348 ?

On Sat, Feb 15, 2020 at 10:39 AM Emmanuel Arias
 wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Emmanuel Arias 
>
>
> * Package name: scalene
>   Version : 0.7.5
>   Upstream Author : Emery Berger
> * URL : https://github.com/emeryberger/scalene
> * License : Apache
>   Programming Lang: Python
>   Description : high-performance, high-precision CPU and memory profiler 
> for Python
>
> Scalene is a high-performance CPU and memory profiler for Python that does a 
> few
> things that other Python profilers do not and cannot do. It runs orders of
> magnitude faster than other profilers while delivering far more detailed
> information.
> .
> This package can be maintained under DPMT umbrella.
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#949941: byobu build depends on the removed pep8 transitional package

[Dustin Kirkland]

Okay, just tried a new upload.  Disabling pep8 for now, until I figure out
a different solution.

@DustinKirkland
Ubuntu Core Dev


On Tue, Feb 11, 2020 at 5:42 PM Boyuan Yang  wrote:

> Control: reopen -1
> Control: notfixed -1 5.131-1
> Control: found -1 5.131-1
> X-Debbugs-CC: kirkl...@ubuntu.com anar...@koumbit.org
>
> Unfortunately the latest upload still FTBFS currently. It looks like
> the building process still invokes the "pep8" executable (in
> debian/rules), which is not provided in the system.
>
> --
> Thanks,
> Boyuan Yang
>
> On Sun, 9 Feb 2020 10:23:46 -0600 Dustin Kirkland 
> wrote:
> > Fixing this now.  Thanks.
> >
> > @DustinKirkland
> > Ubuntu Core Dev
> >
> >
> > On Mon, Jan 27, 2020 at 5:27 AM Adrian Bunk  wrote:
> >
> > > Source: byobu
> > > Version: 5.130-1.1
> > > Severity: serious
> > > Tags: ftbfs
> > >
> > > pep8 is no longer built by src:pep8.
> > >
>

Bug#951381: pdftex ignores tl-paper setting

[Ted To]

Package: texlive-base, texlive-binaries

Version: 2018.20190227-2, 2018.20181218.49446-1

Paper size to letter:

$ tl-paper
Current dvipdfmx paper size (from 
/var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): letter
Current dvips paper size (from 
/var/lib/texmf/dvips/config/config-paper.ps): letter
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/config/pdftexconfig.tex): letter

Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): letter

But produced pdf files still come out as a4:

$ pdflatex test
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 
2019/dev/Debian) (preloaded format=pdflatex)

 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2018-12-01>
(/usr/share/texlive/texmf-dist/tex/latex/base/letter.cls
Document Class: letter 2014/09/29 v1.2z Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size12.clo)) (./test.aux)
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2] [3] 
(./test.aux) )
(see the transcript file for additional 
information)
ist/fonts/type1/public/amsfonts/cm/cmbx12.pfb>
Output written on test.pdf (3 pages, 33961 bytes).
Transcript written on test.log.

$ pdfinfo test.pdf
Creator:    TeX
Producer:   pdfTeX-1.40.19
CreationDate:   Sat Feb 15 12:23:17 2020 EST
ModDate:    Sat Feb 15 12:23:17 2020 EST
Tagged: no
UserProperties: no
Suspects:   no
Form:   none
JavaScript: no
Pages:  3
Encrypted:  no
Page size:  595.276 x 841.89 pts (A4)
Page rot:   0
File size:  33961 bytes
Optimized:  no
PDF version:    1.5

This has apparently been fixed in unstable but not in stable or testing.

Bug#948786: apt-cacher-ng 3.2.1-1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 948786 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: apt-cacher-ng
Version: 3.2.1-1

Explanation: enforce secured call to the server in maint job triggering 
[CVE-2020-5202]; allow .zst compression for tarballs; incrase size of the 
decompression line buffer for config file reading

Bug#951380: vim-tiny: Incorrect size reported when invoked as vi on armhf/armv7l

[Tresi Arvizo]

Package: vim-tiny
Version: 2:8.1.0875-5
Severity: normal

Dear Maintainer,

When invoked as vi, vim.tiny incorrectly reports the file size being
edited, reporting "898964 characters" no matter now large or small the
file is (tried files from 0 bytes to 71 MB).  It works correctly when
invoked as vim.tiny.  This seems to be a problem on the armhf/armv7l
architecture; I did not see it on an i686 machine.

tresi@raspberrypi:~$ uname -a
Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l 
GNU/Linux
tresi@raspberrypi:~$ echo hi > foo
tresi@raspberrypi:~$ ls -al foo
-rw-r--r-- 1 tresi tresi 3 Feb 15 11:59 foo
tresi@raspberrypi:~$ vi foo
hi
~
"foo" 1 line, 898964 characters

tresi@raspberrypi:~$ which vi
/usr/bin/vi
tresi@raspberrypi:~$ readlink /usr/bin/vi
/etc/alternatives/vi
tresi@raspberrypi:~$ readlink /etc/alternatives/vi
/usr/bin/vim.tiny
tresi@raspberrypi:~$ readlink /usr/bin/vim.tiny

tresi@raspberrypi:~$ vim.tiny foo
hi
~
"foo" 1L, 3C

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.tiny

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 4.19.97-v7+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vim-tiny depends on:
ii  libacl1  2.2.53-4
ii  libc62.28-10+rpi1
ii  libselinux1  2.8-1+b1
ii  libtinfo66.1+20181013-2+deb10u2
ii  vim-common   2:8.1.0875-5

vim-tiny recommends no packages.

Versions of packages vim-tiny suggests:
pn  indent  

-- no debconf information

Bug#951313: openprinting-ppds: MemoryError

[Till Kamppeter]

The problem is discussed here:

https://github.com/vitorbaptista/pyppd/issues/2

(Upstream Issue #2 of pyppd)

   Till

Bug#948834: glib2.0: FTBFS: SIGABRT in gsocketclient-slow test

[Mattia Rizzolo]

On Sun, Feb 09, 2020 at 07:19:24PM +, Simon McVittie wrote:
> I personally think this is a pbuilder bug (see also
> ). The fact that
> "localhost" resolves to 127.0.0.1 and/or ::1 is part of the "OS API",
> and I think packages' tests should be entitled to assume that this will
> happen, without needing to take special steps to achieve it.

I fixed pbuilder quite some time ago, and "localhost" now resolves
properly.

> According to #897662 this used to work - has it regressed?

I don't think so…
that was part of pbuilder 0.230, which is in stretch-backports+.  And I
haven't done many changes since then.

Once thing I noticed last month though, is that the way /etc/hosts is
create is odd and causes a leading \t:

|mattia@warren ~/pbuilder/build/3684584/etc % cat hosts
|   127.0.0.1   localhost localhost.localdomain warren 
warren.mapreri.org
|
|   ::1 ip6-localhost ip6-loopback localhost6 localhost6.localdomain6
|   fe00::0 ip6-localnet
|   ff00::0 ip6-mcastprefix
|   ff02::1 ip6-allnodes
|   ff02::2 ip6-allrouters
|   ff02::3 ip6-allhosts

That's also fixed in git.
Could that be causing issues for glib?  But I don't think that's the
case, since I can build it here with that leading \t… :(

> We could probably work around this in glib2.0 with a Build-Depends on
> libnss-myhostname | netbase, or the other way round.

> Related to 
> (which is about whether the name in /etc/hostname resolves to a local
> IP address, whereas this one is about whether localhost resolves to a
> local IP adddress, but installing libnss-myhostname or netbase will
> usually fix both those anomalous situations).

that's indeed a slighly different problem.  I already fixed pbuilder
for that in git, where `hostname -f` resolves back to 127.0.1.1.
https://salsa.debian.org/pbuilder-team/pbuilder/commit/36860888738ca61295a50bcd6626363843a73f03

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#951379: pcmanfm: Subfolder not selected when navigating to parent folder

[August Karlstrom]

Package: pcmanfm
Version: 1.3.1-1
Severity: normal

Dear Maintainer,

When navigating to a parent folder the scroll position should be set so 
that the folder navigated from is visible and selected. This makes it 
much easier to go through adjacent folders.

Steps to reproduce the problem:

1. Navigate to a folder which contains many subfolders which cannot be 
displayed all at once (scrolling required)

2. Scroll down and enter the last folder

3. Go back to the parent folder

Outcome:

The scrollbar is at its top position and the folder we came from is not 
visible. In order to go to an adjacent folder we have to scroll down and 
find the folder we came from (if we even remember which folder it was).

Expected outcome:

The folder we came from is visible and selected. It is now easy to 
navigate to an adjacent folder.


When pressing the left arrow or up arrow button

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

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

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


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

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

Versions of packages pcmanfm depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfm-gtk4   1.3.1-1
ii  libfm4   1.3.1-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk2.0-0  2.24.32-3
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  libx11-6 2:1.6.7-1
ii  shared-mime-info 1.10-1

Versions of packages pcmanfm recommends:
ii  gnome-icon-theme   3.12.0-3
ii  gvfs-backends  1.38.1-5
ii  gvfs-fuse  1.38.1-5
ii  lxpolkit [polkit-1-auth-agent] 0.5.4-1
ii  mate-polkit [polkit-1-auth-agent]  1.20.2-1

pcmanfm suggests no packages.

-- no debconf information

Bug#951378: matrix-synapse: missing dep on python3-signedjson 1.1.0

[C. Dominik Bodi]

Package: matrix-synapse
Version: 1.10.0-1
Severity: normal

Dear Maintainer,

matrix-synapse 1.10.0 fails to start with the following error message:
Feb 15 17:21:21 odysseus python3[1411600]: ERROR:root:Needed signedjson>=1.1.0, 
got signedjson==1.0.0
Feb 15 17:21:21 odysseus python3[1411600]: Missing Requirements: 
'signedjson>=1.1.0'
Feb 15 17:21:21 odysseus python3[1411600]: To install run:
Feb 15 17:21:21 odysseus python3[1411600]: pip install --upgrade --force 
'signedjson>=1.1.0'
Feb 15 17:21:21 odysseus systemd[1]: matrix-synapse.service: Control process 
exited, code=exited, status=1/FAILURE

Apparently, it requires python3-signedjson 1.1.0
However, unstable currently has 1.0.0+git20151019-3

Regards,

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

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

Versions of packages matrix-synapse depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.73
ii  libjs-jquery   3.3.1~dfsg-3
ii  libpython3-stdlib  3.7.5-3
ii  lsb-base   11.1.0
ii  python33.7.5-3
ii  python3-attr   19.3.0-1
ii  python3-bcrypt 3.1.7-2
ii  python3-bleach 3.1.0-2
ii  python3-canonicaljson  1.1.4-3
ii  python3-daemonize  2.4.7-4
ii  python3-distutils  3.8.0-1
ii  python3-frozendict 1.2-2
ii  python3-idna   2.6-2
ii  python3-jinja2 2.10.1-1
ii  python3-jsonschema 3.0.2-4
ii  python3-lxml   4.4.2-1
ii  python3-msgpack0.5.6-3
ii  python3-nacl   1.3.0-4
ii  python3-netaddr0.7.19-3
ii  python3-openssl19.0.0-1
ii  python3-phonenumbers   8.9.10-2
ii  python3-pil7.0.0-4
ii  python3-prometheus-client  0.7.1-1.1
ii  python3-pyasn1 0.4.2-3
ii  python3-pyasn1-modules 0.2.1-0.2
ii  python3-pymacaroons0.13.0-3
ii  python3-service-identity   18.1.0-5
ii  python3-signedjson 1.0.0+git20151019-3
ii  python3-six1.14.0-2
ii  python3-sortedcontainers   2.1.0-2
ii  python3-systemd234-3+b1
ii  python3-treq   18.6.0-0.2
ii  python3-twisted18.9.0-6
ii  python3-typing-extensions  3.7.4.1-1
ii  python3-unpaddedbase64 1.1.0-5
ii  python3-yaml   5.3-1

Versions of packages matrix-synapse recommends:
ii  python3-psycopg2  2.8.4-1

Versions of packages matrix-synapse suggests:
pn  python3-txacme  

-- Configuration Files:
/etc/matrix-synapse/homeserver.yaml changed [not included]

-- debconf information excluded

Bug#951377: support updating changelog in separate commit

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.58
Severity: wishlist

lintian-brush currently supports updating the changelog along with the related
changes, or not updating the changelog at all. Some users prefer a separate
commit with the changelog updates, similar to e.g. the way 'gbp dch' works.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.2
ii  python3  3.7.5-3
ii  python3-breezy   3.0.2-4
ii  python3-debian   0.1.36
ii  python3-distro-info  0.23
ii  python3-dulwich  0.19.15-1
ii  python3-iniparse 0.4-3
ii  python3-levenshtein  0.12.0-5
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.19-1
ii  libdebhelper-perl  12.9
ii  lintian2.52.0
ii  python3-asyncpg0.20.0-1
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  211

-- no debconf information

Bug#951376: ITP: scalene -- high-performance, high-precision CPU and memory profiler for Python

[Emmanuel Arias]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias 


* Package name: scalene
  Version : 0.7.5
  Upstream Author : Emery Berger
* URL : https://github.com/emeryberger/scalene
* License : Apache
  Programming Lang: Python
  Description : high-performance, high-precision CPU and memory profiler 
for Python

Scalene is a high-performance CPU and memory profiler for Python that does a few
things that other Python profilers do not and cannot do. It runs orders of
magnitude faster than other profilers while delivering far more detailed
information.
.
This package can be maintained under DPMT umbrella.

Bug#951366: rkhunter: libkeyutils1/1.6.1-2 triggers a false positive

[Francesco Poli]

Control: severity -1 normal


On Sat, 15 Feb 2020 12:06:03 +0100 Francesco Poli (wintermute) wrote:

[...]
> As explained in [bug #951338], this looks like a false positive
> triggered by just the filename.
> 
> [bug #951338]: 

Hello again,
thanks from a suggestion from keyutils Debian package maintainer,
I managed to work around the issue, by adding the following two
lines to my rkhunter configuration file:

  $ grep keyutils /etc/rkhunter.conf 
  RTKT_FILE_WHITELIST=/lib/x86_64-linux-gnu/libkeyutils.so.1.9
  USER_FILEPROP_FILES_DIRS=/lib/x86_64-linux-gnu/libkeyutils.so.1.9

I hope this is the correct way to avoid the annoying daily alert.

Please let me know, thanks for your time.


-- 
 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


pgpAVrMmZlP3p.pgp
Description: PGP signature

Bug#951338: libkeyutils1: rkhunter warns that libkeyutils.so.1.9 may contain a possible rootkit

[Francesco Poli]

On Sat, 15 Feb 2020 13:16:10 +0100 Christian Kastner wrote:

> On 15.02.20 11:39, Francesco Poli wrote:
[...]
> > Is it wrong (or too late) to change that symbol into
> > keyctl_move@KEYUTILS_1.10 ?
> > Would that bump the SONAME again and generate libkeyutils.so.1.10 ?
> 
> The SONAME didn't change, actually -- that's the benefit of symbol
> versioning, instead of versioning the whole library.
> 
> It's too late to change the symbol itself, IMO. What could be done is to
> just change the library filename, but I feel it's a poor solution. We
> can't start renaming things just because malware chooses to abuse that name.

I can agree with you on this.
Thanks for the kind explanation!

> 
> > I had to downgrade libkeyutils1 and pin it to version 1.6-6, in order
> > to getting an annoying daily alert (via local mail) from rkhunter.
> > I would love to see this issue solved soon.
> 
> Researching this, I saw that Arch discovered this issue already last
> August [1]. The third comment contains a whitelisting workaround for
> rkhunter.
> 
> Could I ask you to try this workaround, and report back if it worked?
> 
> [1] https://bugs.archlinux.org/task/63369

That's interesting: I hadn't found the correct whitelist option to use.

I added the following two lines to my rkhunter configuration file:

  $ grep keyutils /etc/rkhunter.conf 
  RTKT_FILE_WHITELIST=/lib/x86_64-linux-gnu/libkeyutils.so.1.9
  USER_FILEPROP_FILES_DIRS=/lib/x86_64-linux-gnu/libkeyutils.so.1.9

and this seems to work around the issue.

Thanks a lot for your research effort, it is much appreciated!

This bug report may probably be closed.
In the meanwhile, I reported the corresponding [bug #951366] against
rkhunter: let's see what the Debian Security Tools maintainers think...

[bug #951366]: 


-- 
 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


pgpFr3dQ3CIZH.pgp
Description: PGP signature

Bug#951374: RFP: gh -- the GitHub CLI

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: gh
  Version : 0.5.5
  Upstream Author : GitHub Inc.
* URL : https://cli.github.com/
* License : MIT
  Programming Lang: Go
  Description : the GitHub CLI

`gh` is a command-line interface for the Github source-hosting service; it
brings pull requests, issues, and other GitHub functionality to the terminal,
next to git and other programming tooling.

It is an alternative to `hub`, which was Github's unofficial CLI client.

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl5IBjIRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MvYSg//WyxlmrlLhiPeQ4pmDcMgdgnBSob2wRqt
xVvbGJFAibGV8FSCTe2kpesyuJqBG4Jy5pprHX6lzvDT4qKh0LWIo7ETzKFnfMcr
HBIDtUbBcdypD0VoLnAP7lduybaDb6zDmYxiefVwVtNv01azGhD51on5Hm8qLkNJ
yQP43zXjhrb3gokpIOP/YypbOBU6ldaS5eBbI4nWqTWCpY6AOGgxIHkkgPlIbZvn
D18/PM/K0SYwuh1fLYDR7rFa4tzhlL4vwbFxGgk4s1hdHOU4xT6o7hTw4Xtp990Q
ab8j/Tx1qIcEY3Ahkx0C1K056PN7cYC3f7cUxcz418e8b1tFBQBDfOzNGaA/qVU3
dSHSprpp03EQrDDpkGcH5Tk8CbZB5vF0oHUP6sWAGsOGQ1tNg/uOF2g6GhDFsUrm
QIOAhur2yOdlMR3BPrMbqjDh/GATAOETX7Q7bGIoSZ3JUC9Wzf8RXGaaMWYCI8RS
8EQtmA5UFE4Io9VbNk/Wg5MA0p1QJ0rQZ3wf8lw+y8PVJxi0l4wcNF+3W4eWwINO
eQxfTPaSFzeOe8yNkHuXs35naNE0/wkHiaYbowG7oKGnzAjb7EU1kWX0WhSSN42S
7qp8OfdV28Kh+fczhztXvXwyYr8vXtmmohTB3pTsyzyZt+6AYbD+Uvi1/0ujA15w
IqaQg+nNGDY=
=Otf5
-END PGP SIGNATURE-

Bug#951313: openprinting-ppds: MemoryError

[Didier 'OdyX' Raboud]

Control: reassign -1 src:pyppd
Control: retitle -1 pyppd: unarchiving some ppds needs large available memory
Control: tags -1 +upstream
Control: affects -1 openprinting-ppds

Le vendredi, 14 février 2020, 11.45:31 h CET sergio a écrit :
> openprinting-ppds requires too much memory, and doesn't handle this case
> correctly:
> 
> % /usr/lib/cups/driver/openprinting-ppds cat
> openprinting-ppds:0/ppd/openprinting/Samsung/PXL/Samsung_M262x_282x_Series_
> PXL.ppd Traceback (most recent call last):
>   File "/usr/lib/cups/driver/openprinting-ppds", line 119, in 
> main()
>   File "/usr/lib/cups/driver/openprinting-ppds", line 95, in main
> ppd = cat(args[1])
>   File "/usr/lib/cups/driver/openprinting-ppds", line 67, in cat
> ppds['ARCHIVE'] =
> BytesIO(decompress(base64.b64decode(ppds['ARCHIVE'].encode('ASCII' File
> "/usr/lib/cups/driver/openprinting-ppds", line 17, in decompress return
> process.communicate(value)[0]
>   File "/usr/lib/python3.7/subprocess.py", line 939, in communicate
> stdout, stderr = self._communicate(input, endtime, timeout)
>   File "/usr/lib/python3.7/subprocess.py", line 1711, in _communicate
> stdout = b''.join(stdout)
> MemoryError

This code is generated from pyppd, in which all PPDs are compressed in a .xz 
archive, which is serialized in the /usr/lib/cups/driver/openprinting-ppds 
file. This file is in fact a python self-unarchiver.

Indeed, it seems that unarchiving this PPD takes quite some amount of memory:
$ /usr/bin/time -v /usr/lib/cups/driver/openprinting-ppds cat openprinting-
ppds:0/ppd/openprinting/Samsung/PXL/Samsung_M262x_282x_Series_PXL.ppd
  Command being timed: "/usr/lib/cups/driver/openprinting-ppds cat 
openprinting-ppds:0/ppd/openprinting/Samsung/PXL/
Samsung_M262x_282x_Series_PXL.ppd"
User time (seconds): 2.64
System time (seconds): 1.05
Percent of CPU this job got: 13%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:27.38
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1235052
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 311755
Voluntary context switches: 28633
Involuntary context switches: 299
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0


>   Maximum resident set size (kbytes): 1235052

That's almost a Gb of memory as far as I understand it.

Till; anything upstream we could do to avoid this?

Cheers,
OdyX

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[Udo Richter]

On 24.03.19 19:35, Udo Richter wrote:

I experience this behavior in most cases when light-locker kicks in as
screen saver. Closing the lid or suspending never triggers this. i965
driver on Sandybridge CPU. Ctrl-Alt-F6-F7 brings me to a
screen-is-locked display, and after some seconds, to the actual login
prompt. Bug appeared after upgrading from stretch a few months ago.




Some more infos after living with this bug for a year:

- The bug can be instantly triggered with xdg-screensaver lock

- One new workaround seems to be to use a backport kernel (atm thats
linux-image-5.4.0-0.bpo.2-amd64)

- The workaround with Ctrl-Alt-F7/F8 worked for me usually.
- You can also blindly type your password, and the screen will be back
after unlocking
- Be aware, if you're too fast after screen lock, the screen might
unlock without password prompt and without screen being back on. That
way I corrupted a password by typing it blindly into a messenger. ^^'
- If the screen is locked quite long (like >30min), screen may wake up
by mouse move again.


I'm now testing the backports kernel. First test looking good, I'll
report if I notice anything new.

Bug#888670: gnome-system-tools: has been unmaintained upstream for a long time

[Simon McVittie]

On Fri, 14 Feb 2020 at 20:39:54 +0100, Andreas Henriksson wrote:
> (Please also make sure to look into all the deprecated notices that is
> being spit out during build. Those will likely become an issue in the
> not too distant future. But first you might want to reconsider if you
> really have the resources for taking on the task of becoming your own
> upstream.)

All the same considerations apply to liboobs and system-tools-backends,
which are also former GNOME projects. Taking over as upstream developer
of gnome-system-tools doesn't really make sense unless you do the same
for those two packages.

Again, consider whether you have the resources to maintain these. At this
point they have at least a decade of technical debt since the last time
they were actively maintained. In particular, they depend on dbus-glib,
which has been obsolete since the addition of GDBus to GLib in 2010.

Nothing else seems to depend on any of this family of packages, so
if you do take them over, combining the former gnome-system-tools,
system-tools-backends and liboobs packages into one big source tree
is likely to be simpler than keeping them separate.

smcv

Bug#951373: ITP: ordered-map -- C++ insertion-order-preserving hash map and hash set

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: ordered-map
  Version : 0.8.1
  Upstream Author : Tessil
* URL or Web page : https://github.com/Tessil/ordered-map/releases
* License : MIT
  Description : C++ insertion-order-preserving hash map and hash set

This package is needed for pacakging Zeek 3.x (formerly known as Bro).

Bug#951372: golang-github-proglottis-gpgme: CVE-2020-8945

[Salvatore Bonaccorso]

Source: golang-github-proglottis-gpgme
Version: 0.1.0-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/proglottis/gpgme/pull/23

Hi,

The following vulnerability was published for golang-github-proglottis-gpgme.

CVE-2020-8945[0]:
| The proglottis Go wrapper before 0.1.1 for the GPGME library has a
| use-after-free, as demonstrated by use for container image pulls by
| Docker or CRI-O. This leads to a crash or potential code execution
| during GPG signature verification.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-8945
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8945
[1] https://github.com/proglottis/gpgme/pull/23

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#951337: lintian-brush: dh_clideps fails when debian/compat is removed

[Jelmer Vernooij]

On Fri, Feb 14, 2020 at 06:23:53PM +0100, Andreas Henriksson wrote:
> It seems running lintian-brush on a .NET package (like pdfmod) will
> cause it to FTBFS. AFAICT this is caused by the switching of
> debian/compat -> debhelper-compat (= ...) change, as the dh_clideps
> helper has not been updated to support the new syntax.
> 
> Please consider detecting .NET packages and skipping the
> debhelper-compat change for now (until someone volunteers to
> fix up dh_clideps).
Is there a bug in cli-common-dev to track this? It'd be useful to
known when e.g. such a check could be dropped.

I tried digging into this issue a little bit - it looks like
dh_clideps is no longer finding PdfMod.exec.config, but it's not clear
to me why (does it run with a different $CWD now?).

Cheers,

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#951371: O: styx -- combined parser/scanner generator for C/C++

[Tobias Frost]

Package: wnpp

The current maintainer of styx, Frederik Schüler ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: styx
Binary: styx, libstyx2, styx-dev, styx-doc
Version: 2.0.1-1
Maintainer: Frederik Schüler 
Build-Depends: cdbs, autotools-dev, debhelper (>= 7), docbook-to-man, gawk
Architecture: any all
Standards-Version: 3.9.1
Format: 3.0 (quilt)
Files:
 d9ef8f78f569afa7b2ac5fd2a946a4c3 1184 styx_2.0.1-1.dsc
 3d3a2b0a4a50df4f62b6c5e6cafbf72b 6957941 styx_2.0.1.orig.tar.gz
 d095b6da389d5bd63f42bca252473385 8661 styx_2.0.1-1.debian.tar.gz
Checksums-Sha256:
 60408ac0e1bcbb0b7ac1df80a5524776520122a80075cd39575c8ca637959318 1184 
styx_2.0.1-1.dsc
 f370319fe87ce5c61dfad2bb36ecd6574b3af13f314e1b580e1ec1bfabea0086 6957941 
styx_2.0.1.orig.tar.gz
 ca5e4d4315d082f1411730dd7ef323b3402a3224778773042d295b0dc3b0df00 8661 
styx_2.0.1-1.debian.tar.gz
Homepage: http://speculate.de/styx/
Package-List: 
 libstyx2 deb libs optional
 styx deb devel optional
 styx-dev deb devel optional
 styx-doc deb doc optional
Directory: pool/main/s/styx
Priority: source
Section: devel

Package: styx
Source: styx (2.0.1-1)
Version: 2.0.1-1+b1
Installed-Size: 183
Maintainer: Frederik Schüler 
Architecture: amd64
Depends: libc6 (>= 2.4), libstyx2 (>= 2.0.1)
Recommends: styx-dev (= 2.0.1-1+b1)
Suggests: styx-doc (= 2.0.1-1)
Description-en: combined parser/scanner generator for C/C++
 The package facilitates application development including
 user-defined context free languages.
 .
 Its development model deviates from the traditional lex/yacc pair
 (flex/bison in Debian) by automating tedious tasks which are
 commonly implemented in yacc's actions.
 .
 Styx automatically derives a depth grammar, generates reentrant
 parsers that support persistent derivation trees, preserve full
 source information, support Unicode and are thread safe.
Description-md5: b68f9a001ad29b268ab8d67c47507631
Homepage: http://speculate.de/styx/
Tag: devel::code-generator, interface::commandline, role::program,
 scope::utility, works-with::software:source
Section: devel
Priority: optional
Filename: pool/main/s/styx/styx_2.0.1-1+b1_amd64.deb
Size: 50918
MD5sum: 79ce621f5d1be062b186321913c3fa76
SHA256: 2d4f9b01f18c16243d3a5d4c3ce3a1eed211c9e343bbfce5d69f3741ec5897aa

Package: libstyx2
Source: styx (2.0.1-1)
Version: 2.0.1-1+b1
Installed-Size: 720
Maintainer: Frederik Schüler 
Architecture: amd64
Replaces: libdstyx, libxstyx
Provides: libdstyx, libxstyx
Depends: libc6 (>= 2.14)
Conflicts: libdstyx, libxstyx
Description-en: runtime libraries for styx
 Dynamically linked programs containing lexical scanners or parsers
 developed with styx depend on this library.
 .
 It implements abstract grammar, LALR(1) parser and lexical scanner
 interfaces, hashed symbol tables and supporting data types.
Description-md5: 8efc7c06045e1e2fc95046c30d87afdb
Homepage: http://speculate.de/styx/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/s/styx/libstyx2_2.0.1-1+b1_amd64.deb
Size: 227374
MD5sum: 8233101489bb2fc8a8283a838b666899
SHA256: 89e51aba4bb4fc81e5099b5009f20f1990f06583bf8b389a6a5a9251982db8d7

Package: styx-dev
Source: styx (2.0.1-1)
Version: 2.0.1-1+b1
Installed-Size: 1596
Maintainer: Frederik Schüler 
Architecture: amd64
Depends: styx (= 2.0.1-1+b1)
Suggests: styx-doc (= 2.0.1-1)
Description-en: combined parser/scanner generator development files
 Static libraries and headers needed for development with styx.
 .
 cf. styx for features.
Description-md5: f747059776d93ec49bf19e2d2b48f6e9
Homepage: http://speculate.de/styx/
Tag: devel::code-generator, devel::library, role::devel-lib
Section: devel
Priority: optional
Filename: pool/main/s/styx/styx-dev_2.0.1-1+b1_amd64.deb
Size: 285322
MD5sum: aabdbbfc1eb884321ac1ffebe14c7023
SHA256: 316d6e5159f095316331d7ed7e58b1ad74247e90c744654edf2beee4be4f83da

Package: styx-doc
Source: styx
Version: 2.0.1-1
Installed-Size: 1291
Maintainer: Frederik Schüler 
Architecture: all
Description-en: combined parser/scanner generator documentation
 "The Styx Handbook" describes application development with styx and
 contains HTML reference documentation for the styx API.
 .
 Contains a full blown example showing how to build an XML parser
 with styx.
 .
 cf. styx for features.
Description-md5: 2be9f2eeb3aacf89edde73d6871ebe2f
Homepage: http://speculate.de/styx/
Tag: devel::code-generator, devel::doc, devel::examples, made-of::html,
 role::documentation
Section: doc
Priority: optional
Filename: pool/main/s/styx/styx-doc_2.0.1-1_all.deb
Size: 244274
MD5sum: 38f6a64884baa78f5e416595b112b751
SHA256: 96779b5ea1115dae36290cbccd84b2257bb577d759967cd5af654a8aff94f017



signature.as

Bug#947298: ipython-py2: Python2 removal in sid/bullseye

[Gordon Ball]

On Thu, Feb 13, 2020 at 09:02:33PM -0500, Sandro Tosi wrote:
> > > (source:ipython-py2)Build-Depends->python-matplotlib
> > ...
> >
> > Do you think it would be possible to remove that build-depends (my
> 
> I've actually tried to rebuild ipython-py2 without mpl and it builds
> fine: are you ok with me making an upload with that b-d removed?

I've just uploaded 5.8.0-4 dropping the matplotlib dependency; it
was a vestigal test dependency which was no longer needed. Thanks for
spotting it (and all your work on py2removal).

Bug#888670: gnome-system-tools: has been unmaintained upstream for a long time

[Andriy Grytsenko]

Hello!

You have written on Friday, 14 February, at 20:39:

>The new repository[1] that was supposedly fixing this bug report
>doesn't even include the upstream sources (or their git history).
>It's a plain packaging repo with only the debian/ directory.
>I don't see how that's supposed to fulfil the need for you to
>become your own uptream. You most likely want to create a fork
>from the archived gnome repo[2].

Yes, I've created a fork and mentined it in in the debian/control file:

Homepage: https://github.com/LStranger/gnome-system-tools

I had a hope that it's enoungh. From your message it seems it's not.

>Also please pick a (new) name for your fork as it's *not* THE
>gnome-system-tools (anymore), unless you actually talk to the gnome
>project to officially pick up as the gnome maintainer (but I suspect
>at this point there's absolutely no interest from the gnome project to
>have gnome-system-tools revived).

>(Once a proper upstream fork exists, packaging that under the new name
>and providing a transitional gnome-system-tools meta-package will give
>current users a seemless upgrade experience.)

I understand that it's possible but it would need creating new package
and removing old one, thus involve some DD and some ftpmaster as well.
I'm still just a DM so did what is available for me to do. Thank you for
an advice, I'll decide how I can handle all this situation.

>(Please also make sure to look into all the deprecated notices that is
>being spit out during build. Those will likely become an issue in the
>not too distant future. But first you might want to reconsider if you
>really have the resources for taking on the task of becoming your own
>upstream.)

Yes, I understand all this said and, frankly speaking, I really have not
enough resources to handle this whole bunch (it also includes liboobs and
system-tools-backends) but unfortunately there is no another standalone
GTK tool to manage users and date/time around, it was a whole reason why
I've picked up this package in the first place. And as a LXDE maintainer,
I cannot leave LXDE users without means to manage users and date/time.
It's a pretty hard and problematic dilemma I have here, unless I start to
write appropriate tools from scratch by myself but that would take a lot
of time as well and this is also a problem. Well, as for LXDE I hope to
handle date/time management by the panel indicator later (and actually it
is almost never required as most of decent systems does not need manual
managing due to NTP in action) but users still cannot be handled without
this package. So in short, if I found some standalone tool to manage
users then I would be very glad to get rid of these three packages.

With best regards,
Andriy.

Bug#951370: Updating the gfs2-utils Uploaders list

[Tobias Frost]

Source: gfs2-utils
Version: 3.2.0-1 3.2.0-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Frederik Schüler  has not been working on
the gfs2-utils package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.


signature.asc
Description: PGP signature

Bug#951330: keyboard connected to an USB hub does not work in X11 but on console

[Michael Biebl]

Control: tags -1 + fixed-upstream

Am 15.02.2020 um 11:29 schrieb Marc Haber:
> On Fri, Feb 14, 2020 at 04:34:49PM +0100, Michael Biebl wrote:
>> You might try reverting that change as in
>> https://github.com/systemd/systemd-stable/commit/c4280c342bbf4fa8da833103482362236c18f835
> 
> That fixed the issue for me. I have also verified that transplanting
> 71-seat.rules from an older systemd version will also make systemd 244.2
> work.

Thanks for testing. Will upload a fixed package later today.

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#951338: libkeyutils1: rkhunter warns that libkeyutils.so.1.9 may contain a possible rootkit

[Christian Kastner]

On 15.02.20 11:39, Francesco Poli wrote:
> On Fri, 14 Feb 2020 23:15:08 +0100 Christian Kastner wrote:
> OK, I am about to say something very idiotic here, because I am not too
> familiar with versioned symbols in libraries. Hence, please bear with
> me...
> 
> Is it wrong (or too late) to change that symbol into
> keyctl_move@KEYUTILS_1.10 ?
> Would that bump the SONAME again and generate libkeyutils.so.1.10 ?

The SONAME didn't change, actually -- that's the benefit of symbol
versioning, instead of versioning the whole library.

It's too late to change the symbol itself, IMO. What could be done is to
just change the library filename, but I feel it's a poor solution. We
can't start renaming things just because malware chooses to abuse that name.

> I had to downgrade libkeyutils1 and pin it to version 1.6-6, in order
> to getting an annoying daily alert (via local mail) from rkhunter.
> I would love to see this issue solved soon.

Researching this, I saw that Arch discovered this issue already last
August [1]. The third comment contains a whitelisting workaround for
rkhunter.

Could I ask you to try this workaround, and report back if it worked?

[1] https://bugs.archlinux.org/task/63369

Bug#951369: RFS: sachesi/2.0.4+ds-1 [ITP] -- BlackBerry 10 device utility

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: sachesi
   Version : 2.0.4+ds-1
   Upstream Author : https://github.com/xsacha/Sachesi/issues
 * URL : https://github.com/xsacha/Sachesi
 * License : GPL-3
   Section : comm

It builds those binary packages:

  sachesi - BlackBerry 10 device utility

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/sachesi/sachesi_2.0.4+ds-1.dsc

Changes since the last upload:

   * Initial release (Closes: #787482)

Regards,
Bastian Germann

Bug#950986: uninstalling cgroupfs-mount wails about sys/fs/cgroup/elogind

[Harald Dunkel]

I am not quite sure what you mean, but in this case systemd is *not* init.
elogind conflicts with systemd.


Regards
Harri

Bug#951368: ITP: cargo-deny -- Cargo plugin to help you manage large dependency graphs

[Fabian Grünbichler]

Package: wnpp
Severity: wishlist
Owner: Fabian Grünbichler 

* Package name: cargo-deny
  Version : 0.6.4
  Upstream Author : Jake Shadle 
* URL : https://github.com/EmbarkStudios/cargo-deny
* License : MIT or Apache-2.0
  Programming Lang: Rust
  Description : Cargo plugin to help you manage large dependency graphs

Allows checking for desired/undesired licenses, duplicate dependencies
and unfixed CVEs in the graph of direct and transitive dependencies of a
crate.

Will be maintained via debcargo-conf / the Debian Rust team.

Bug#951367: debootstrap: Raspbian bootstrap: Failed getting release file

[Michael Büsch]

Package: debootstrap
Version: 1.0.117
Severity: important

Since debootstrap 1.0.117 Raspbian bootstrap fails with the following error
message:

$ debootstrap --arch=armhf --foreign --verbose --keyring=keyrings/raspbian-
archive-keyring.gpg buster /tmp/debootstrap-test
http://mirrordirector.raspbian.org/raspbian/
I: Retrieving InRelease
I: Retrieving Release
E: Failed getting release file
http://mirrordirector.raspbian.org/raspbian/dists/buster/Release



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

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

Versions of packages debootstrap depends on:
ii  wget  1.20.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.16-2
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.19-1

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

Bug#951364: tlp: Typo in package description

[Beatrice Torracca]

Package: tlp
Severity: minor

Hi,

with a recent upgrade (I think in 1.3.1-1) a typo has sneaked in into
the package description.

In particular Bluetooth has been changed in "luetooth".

Thanks,

beatrice

Bug#951366: rkhunter: libkeyutils1/1.6.1-2 triggers a false positive

[Francesco Poli (wintermute)]

Package: rkhunter
Version: 1.4.6-7
Severity: important

Hello and thanks for maintaining rkhunter in Debian!

After upgrading

  [UPGRADE] libkeyutils1:amd64 1.6-6 -> 1.6.1-2

I get the following warning with

  # rkhunter --sk -c

in /var/log/rkhunter.log:

  Info: Starting test name 'running_procs'
Checking running processes for suspicious files [ Warning ]
  Warning: The following processes are using suspicious files:
   Command: sshd
 UID: 0PID: 7331
 Pathname: /lib/x86_64-linux-gnu/libkeyutils.so.1.9
 Possible Rootkit: Spam tool component

As explained in [bug #951338], this looks like a false positive
triggered by just the filename.

[bug #951338]: 

Please fix this false positive, since getting a daily alert
from rkhunter for this is annoying.

Thanks for your time!
Bye.


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

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

Versions of packages rkhunter depends on:
ii  binutils   2.34-2
ii  debconf [debconf-2.0]  1.5.73
ii  file   1:5.38-4
ii  lsof   4.93.2+dfsg-1
ii  net-tools  1.60+git20180626.aebd88e-1
ii  perl   5.30.0-9
ii  ucf3.0038+nmu1

Versions of packages rkhunter recommends:
ii  curl   7.67.0-2
ii  e2fsprogs  1.45.5-2
ii  exim4-daemon-light [mail-transport-agent]  4.93-10
ii  iproute2   5.4.0-1
ii  mailutils [mailx]  1:3.7-2
ii  unhide 20130526-4
ii  unhide.rb  22-4
ii  wget   1.20.3-1+b2

Versions of packages rkhunter suggests:
ii  liburi-perl 1.76-2
ii  libwww-perl 6.43-1
pn  powermgmt-base  

-- Configuration Files:
/etc/rkhunter.conf changed [not included]

-- debconf information:
  rkhunter/apt_autogen: yes
  rkhunter/cron_db_update: yes
  rkhunter/cron_daily_run: yes

Bug#951356: virtual disk was allocated with -f qcow

[Chris Ward]

I have just noticed that the virtual disk for the system was allocated with

qemu-img create -f qcow Debian10.qcow 200G

where the intended allocation would be with

qemu-img create -f qcow2 Debian10.qcow2 200G

When I allocated the disk in the intended way, formatting proceeded much 
faster. This bug can be closed as 'user error'.

Bug#951365: autopkgtest: blocks TL due to warnings of unknown specials

[Norbert Preining]

Package: pyxplot
Version: 0.9.2-10
Severity: important

Dear all,

pyxplot defines autopkgtest and currently blocks new TeX Live packages,
the sole reason being that pyxplot is unable to interpret new dvi
specials:
file 'examples/ex_linestyles.ppl':103: Warning: ignoring unhandled DVI 
special string header=l3backend-dvips.pro
This is a new special introduced with recent LaTeX, see
https://tug.org/pipermail/tex-live/2020-February/044737.html
and the whole thread.

The whole point of this bug report is that the warning shipped out is
innocent, but blocks TeX Live packages, and thus are to be honest a
PITA.

Please either disable these broken autopkgtests, or fix the package to
not emit warnings on these specials.

Thanks

Norbert


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

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

Versions of packages pyxplot depends on:
ii  libc62.29-10
ii  libcfitsio8  3.470-3
ii  libfftw3-double3 3.3.8-2
ii  libgsl23 2.5+dfsg-6+b1
ii  libkpathsea6 2019.20190605.51237-3
ii  libpng16-16  1.6.37-2
ii  libreadline8 8.0-3
ii  libxml2  2.9.4+dfsg1-8
ii  texlive-latex-base   2019.20200210-1
ii  texlive-latex-extra  2019.202000210-1
ii  zlib1g   1:1.2.11.dfsg-1.2

Versions of packages pyxplot recommends:
ii  atril [postscript-viewer]   1.24.0-1
ii  evince [postscript-viewer]  3.34.1-1+b1
ii  ghostscript [postscript-viewer] 9.50~dfsg-5
ii  gv [postscript-viewer]  1:3.7.4-2+b1
ii  imagemagick 8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+b2
ii  okular [postscript-viewer]  4:17.12.2-2.2+b2
ii  pyxplot-doc 0.9.2-10
ii  qpdfview-ps-plugin [postscript-viewer]  0.4.18-1.3
ii  sensible-utils  0.0.12+nmu1

Versions of packages pyxplot suggests:
ii  unzip  6.0-25
ii  wget   1.20.3-1+b2

-- no debconf information

Bug#951331: merge HexChat AppArmor profile

[Mattia Rizzolo]

On Sat, Feb 15, 2020 at 10:46:31AM +, Patrick Schleizer wrote:
> Mattia Rizzolo:
> >> The profile is tested with HexChat.
> >>
> >> https://github.com/Whonix/apparmor-profile-xchat
> > 
> > What would you think of properly integreting it into the upstream
> > package at https://github.com/hexchat/hexchat ?
> 
> 
> That would be better indeed but I was sent here. :)
> 
> https://github.com/hexchat/hexchat/issues/1577

ahem :s

Alright, let me see if I can find somebody to have a look at those 2
files…

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#951331: merge HexChat AppArmor profile

[Patrick Schleizer]

Mattia Rizzolo:
>> The profile is tested with HexChat.
>>
>> https://github.com/Whonix/apparmor-profile-xchat
> 
> What would you think of properly integreting it into the upstream
> package at https://github.com/hexchat/hexchat ?


That would be better indeed but I was sent here. :)

https://github.com/hexchat/hexchat/issues/1577