Bug#929729: Test package ships invalid md5sums

2020-03-04 Thread Jakub Wilk

* Felix Lechner , 2020-03-04, 10:28:
The test package provided elsewhere in this bug may have an invalid 
md5sums file. As detailed in commit 822d4b70, the specifications 
explain that newlines are escaped with a backslash but are printed 
*verbatim*:


   
https://www.gnu.org/software/coreutils/manual/html_node/md5sum-invocation.html

That is also how the md5sum tool behaves. It can be tested on any file system.


Hmm, no? The documentation is not very clear about this, but md5sums 
escapes newlines as \n:


  $ x=$(printf 'foo\nbar')
  $ echo "$x"
  foo
  bar
  $ touch "$x"
  $ md5sum "$x"
  \d41d8cd98f00b204e9800998ecf8427e  foo\nbar

--
Jakub Wilk



Bug#953145: vrms: autopkgtest should not assert the testbed is free of non-free packages

2020-03-04 Thread Steve Langasek
Package: vrms
Version: 1.25
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

Since version 1.24, the autopkgtests for vrms have been failing in Ubuntu,
blocking the new version of the package from propagating to the release,
because the smoke-test test has been changed to not just run vrms but to
also require that vrms gives a clean bill of health to the testbed.

On Ubuntu, the output is:
[...]
running /tmp/autopkgtest.PDNfBd/build.9zS/src/debian/tests/smoke-test
Non-free packages installed on autopkgtest

amd64-microcode Processor microcode firmware for AMD CPUs
fonts-ubuntu-consoleconsole version of the Ubuntu Mono font
intel-microcode Processor microcode firmware for Intel CPUs

 Contrib packages installed on autopkgtest

iucode-tool Intel processor microcode tool

  3 non-free packages, 0.6% of 504 installed packages.
  1 contrib packages, 0.2% of 504 installed packages.
[...]


This is not testing a property of the vrms package, but of the environment
the test is run in, and therefore I don't think this is appropriate in an
autopkgtest.

I've uploaded the attached patch to Ubuntu, so vrms will not be held up by
this autopkgtest.  Would you consider applying this in Debian as well?

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru vrms-1.25/debian/tests/smoke-test 
vrms-1.25ubuntu1/debian/tests/smoke-test
--- vrms-1.25/debian/tests/smoke-test   2018-12-01 12:01:01.0 -0800
+++ vrms-1.25ubuntu1/debian/tests/smoke-test2020-03-04 23:46:14.0 
-0800
@@ -3,4 +3,3 @@
 echo running $0
 
 vrms
-vrms | grep "rms would be proud"


Bug#953144: origami install fails with "ERROR: WGET RETRIEVAL FAILED!"

2020-03-04 Thread Göran Weinholt
Package: origami
Version: 1.2.7+really0.7.4-1.1
Severity: grave

The origami program is unable to install the Folding @ Home client,
seems like something on a network server has changed:

# origami install
ERROR: WGET RETRIEVAL FAILED!



-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

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

Versions of packages origami depends on:
ii  bash  5.0-4
ii  curl  7.64.0-4+deb10u1
ii  wget  1.20.1-1.1

origami recommends no packages.

origami suggests no packages.

-- no debconf information



Bug#953098: xscreensaver: Crashes with XIO: fatal IO error

2020-03-04 Thread Omer Zak
xscreensaver crashes also in my system.

Debian version: 10.3 (Buster)
xscreensaver version: 5.42+dfsg1-1

My system (a laptop) has 3 screens:
- the original one
- connected via HDMI
- connected via DisplayLink

When using
xscreensaver -nosplash -log /tmp/x.log -verbose &
I did not see the XIO fatal IO error message.
However, the message
"xscreensaver-gl-helper did not report a GL visual!"
repeated once in a while. Whatever it is, it did not cause xscreensaver
to crash.

The crash was not accompanied by any useful information in the logfile.
If someone can advise how to get more information in the logfile, I'll
be happy to help investigate this bug.


On Wed, 04 Mar 2020 14:08:56 +0100 =?utf-8?q?Jens_Holzk=C3=A4mper?= <
jens.holzkaem...@zbmath.org> wrote:
> Package: xscreensaver
> Version: 5.42+dfsg1-1
> Severity: grave
> Tags: security
> Justification: user security hole



Bug#937491: pynn: Python2 removal in sid/bullseye

2020-03-04 Thread Andreas Tille
On Thu, Mar 05, 2020 at 12:47:30PM +1100, Stuart Prescott wrote:
> There's a new upstream version of pynn (0.9.5) that is python 3 compatible.
> 
> Is this another candidate for moving from neurodebian to debian-med as a 
> starting point for that?

I'm working on this[1].  However, lazyarray needs to be ported first.

Kind regards

  Andreas.

[1] https://salsa.debian.org/med-team/pynn 

-- 
http://fam-tille.de



Bug#951917: debhelper: [INTL:de] Updated German manpage translation

2020-03-04 Thread Niels Thykier
Chris Leick:
> Package: debhelper
> Version: 12.9
> Severity: wishlist
> Tags: l10n patch
> 
> 
> 
> Hi,
> 
> please find attached the newest German manpage translation.
> 
> Kind regards,
> Chris
> 

Hi Chris,

Thanks for the update. :)

Let me know if you would like commit access to update the translations
directly in git - i.e. https://salsa.debian.org/debian/debhelper (so you
do not have to wait for me in the future).

~Niels



Bug#953143: mbedtls: Please make autopkgtests cross-test-friendly

2020-03-04 Thread Steve Langasek
Package: mbedtls
Version: 2.16.4-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi James,

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 mbedtls tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner and also do
not use cross-capable test dependencies.  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.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru mbedtls-2.16.4/debian/tests/build mbedtls-2.16.4/debian/tests/build
--- mbedtls-2.16.4/debian/tests/build   2020-01-28 15:38:13.0 -0800
+++ mbedtls-2.16.4/debian/tests/build   2020-03-04 22:04:36.0 -0800
@@ -11,6 +11,13 @@
 fi
 
 cd "$AUTOPKGTEST_TMP"
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < mbedtls_sha1.c
 #include 
 #include 
@@ -37,9 +44,9 @@
 EOF
 
 # Build program shared + statically
-gcc -Wall -Werror -o mbedtls_sha1 mbedtls_sha1.c -lmbedcrypto
+${CROSS_COMPILE}gcc -Wall -Werror -o mbedtls_sha1 mbedtls_sha1.c -lmbedcrypto
 echo "build1: OK"
-gcc -Wall -Werror -static -o mbedtls_sha1_static mbedtls_sha1.c -lmbedcrypto
+${CROSS_COMPILE}gcc -Wall -Werror -static -o mbedtls_sha1_static 
mbedtls_sha1.c -lmbedcrypto
 echo "build2: OK"
 
 # Run it on a few strings
diff -Nru mbedtls-2.16.4/debian/tests/control 
mbedtls-2.16.4/debian/tests/control
--- mbedtls-2.16.4/debian/tests/control 2020-01-28 15:38:13.0 -0800
+++ mbedtls-2.16.4/debian/tests/control 2020-03-04 22:04:29.0 -0800
@@ -1,2 +1,2 @@
 Tests: build selftest
-Depends: gcc, libc-dev, libmbedtls-dev
+Depends: build-essential, libmbedtls-dev
diff -Nru mbedtls-2.16.4/debian/tests/selftest 
mbedtls-2.16.4/debian/tests/selftest
--- mbedtls-2.16.4/debian/tests/selftest2020-01-28 15:38:13.0 
-0800
+++ mbedtls-2.16.4/debian/tests/selftest2020-03-04 22:04:36.0 
-0800
@@ -10,10 +10,16 @@
exit 1
 fi
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 # Build mbedtls_selftest shared / statically
-cc -Wall -Werror programs/test/selftest.c -o 
"$AUTOPKGTEST_TMP/mbedtls_selftest" -lmbedtls -lmbedx509 -lmbedcrypto
+${CROSS_COMPILE}gcc -Wall -Werror programs/test/selftest.c -o 
"$AUTOPKGTEST_TMP/mbedtls_selftest" -lmbedtls -lmbedx509 -lmbedcrypto
 echo "build1: OK"
-cc -Wall -Werror -static programs/test/selftest.c -o 
"$AUTOPKGTEST_TMP/mbedtls_selftest_static" -lmbedtls -lmbedx509 -lmbedcrypto 
-pthread
+${CROSS_COMPILE}gcc -Wall -Werror -static programs/test/selftest.c -o 
"$AUTOPKGTEST_TMP/mbedtls_selftest_static" -lmbedtls -lmbedx509 -lmbedcrypto 
-pthread
 echo "build2: OK"
 
 # Run the testsuite twice


Bug#953142: archive.debian.org: Please do archive as well Changelogs for releases

2020-03-04 Thread Salvatore Bonaccorso
Package: ftp.debian.org
Severity: wishlist

Hi

It has occurend as question where one can find Changelogs for archived
releases. Whilst for current active releases one can find the
changelog in 

https://deb.debian.org/debian/dists/$release/ChangeLog

they are not for archived releases in

http://archive.debian.org/debian/dists/release/

So when archiving a release it would be nice to get an archived copy
as well for these extra files.

Regards,
Salvatore



Bug#953141: tmux: Please add Suggests: ncurses-term to allow us using TERM=tmux or tmux-256color

2020-03-04 Thread Ryo IGARASHI
Package: tmux
Version: 2.8-3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

ncurses-term package contains termcap entry of tmux and tmux-256color.
Using these entry, I can use e.g. italic which is not available using
TERM=screen.
However, this fact is not indicated anywhere on tmux package
description. It would be nice to add Suggest: ncurses-term.

Best regards,
- -- 
Ryo Igarashi, Ph.D.
rigar...@gmail.com

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

Kernel: Linux 4.4.0-18362-Microsoft
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages tmux depends on:
ii  libc6   2.28-10
ii  libevent-2.1-6  2.1.8-stable-4
ii  libtinfo6   6.1+20181013-2+deb10u2
ii  libutempter01.1.6-3

tmux recommends no packages.

tmux suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIkEARYKADEWIQSQVQWnJ6dEuIxNmESAtgFFC/hXNwUCXmCfChMccmlnYXJhc2hA
Z21haWwuY29tAAoJEIC2AUUL+Fc32j8BAI0E2Oa3qK03QFBjNlHJfNmv6LHoJasL
g/NrfLWBUXKRAP9yAstEp3Bh8T0y10lqqTr5oPmWkvI7vIyK7uCzEYXcAQ==
=N532
-END PGP SIGNATURE-



Bug#948553: - backport to buster ?

2020-03-04 Thread Landry Breuil

hello,

this bug is now fixed in sid, but could it be a candidate for a fix in 
stable/buster ? as of now, tomcat9 is a bit broken wrt systemd in 
stable, and i see two options to fix it:
- only backport the commit 
(https://svn.apache.org/viewvc?view=revision&revision=1853508) on top of 
catalina.sh to just fix the issue

- fix the systemd unit ?
- update to 9.0.17 in buster ?



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

2020-03-04 Thread Carsten Schoenert
Hello Bob,

Am 03.03.20 um 20:03 schrieb Bob Ham:
>> have you tried to follow these steps?
>>
>> https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues
> 
> I had tried most of them, yes.  I disabled the lightning plugin and
> checked that it was causing the problem (that's why I filed the bug
> against the lightning package.)

shows that Lightning is involved into the issue and maybe the root of
it. But not Thunderbird itself.

> I hadn't tried creating a fresh profile.  Having done that now, it does
> seem that lightning works OK with the fresh profile.

As I expected. As written on the wiki page, quite most of such issues,
like this report is about, are caused by outdated or somehow faulty
AddOns or some user modified configuration.

> There's still a problem though; my existing profile contains a lot of
> information I don't want to lose or have to manually recreate, like
> message filter rules and so on.
These are more or less easy to migrate as these are just files.

Message filter for example
https://www.systutorials.com/how-to-export-and-import-message-filters-of-thunderbird/

Address books are also easy, just copy all *.mab files into the new
profile, or export them within the UI

But there are also some AddOns which can help with such tasks.

https://addons.thunderbird.net/en-US/thunderbird/addon/importexporttools-ng/

-- 
Regards
Carsten Schoenert



Bug#953140: libarchive: Please make autopkgtests cross-test-friendly

2020-03-04 Thread Steve Langasek
Package: libarchive
Version: 3.4.0-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Peter,

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 libarchive tests currently fail in this environment, one because it is a
build test that does not invoke the toolchain in a cross-aware manner, the
other because it does not use cross-capable test dependencies.  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.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libarchive-3.4.0/debian/tests/control 
libarchive-3.4.0/debian/tests/control
--- libarchive-3.4.0/debian/tests/control   2019-09-20 15:36:12.0 
-0700
+++ libarchive-3.4.0/debian/tests/control   2020-03-04 21:47:59.0 
-0800
@@ -2,6 +2,6 @@
 Depends: build-essential, file, libarchive-dev, pkg-config
 
 Test-Command: adequate libarchive-dev libarchive13 libarchive-tools bsdtar 
bsdcpio
-Depends: @, adequate
+Depends: @, adequate:native
 Features: test-name=adequate
 Restrictions: superficial
diff -Nru libarchive-3.4.0/debian/tests/minitar 
libarchive-3.4.0/debian/tests/minitar
--- libarchive-3.4.0/debian/tests/minitar   2019-09-20 15:36:12.0 
-0700
+++ libarchive-3.4.0/debian/tests/minitar   2020-03-04 21:47:52.0 
-0800
@@ -6,7 +6,13 @@
 # correctly and minitar works as expected.
 # Author: Benjamin Drung 
 
-gcc -O2 -g -Wno-unused-result -o minitar examples/minitar/minitar.c 
$(pkg-config --cflags --libs libarchive)
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+${CROSS_COMPILE}gcc -O2 -g -Wno-unused-result -o minitar 
examples/minitar/minitar.c $(${CROSS_COMPILE}pkg-config --cflags --libs 
libarchive)
 
 # Create different tarballs
 echo "Deadbeaf" > foo
@@ -26,7 +32,7 @@
 test "$(file -b --mime-type foo.tar.bz2)" = "application/x-bzip2"
 
 # Test untar, too, for extracting.
-gcc -O2 -g -Wno-unused-result -o untar examples/untar.c $(pkg-config --cflags 
--libs libarchive)
+${CROSS_COMPILE}gcc -O2 -g -Wno-unused-result -o untar examples/untar.c 
$(${CROSS_COMPILE}pkg-config --cflags --libs libarchive)
 
 # Extract tarballs and compare content
 mv foo foo.orig


Bug#953139: BUG #953139 Correction

2020-03-04 Thread Ron Lovell
> Should I have python3 installed?

Meant: Should I have python3-all installed?
-- 
James Ronald Lovell 
Huntsville, AL, USA


Bug#953139: python3-jupyter-core: Sid python3-jupyter-core 4.6.3-2 Needs python3-distutils

2020-03-04 Thread Ron Lovell
Package: python3-jupyter-core
Version: 4.6.3-2
Severity: important

After recent updates to the jupyter packages and for the Python
3.8 tranision in Sid, I decided to give qtconsole a spin just to
see how it's working. It's not able to load:

$ jupyter qtconsole
Traceback (most recent call last):
  File "/usr/bin/jupyter", line 11, in 
load_entry_point('jupyter-core==4.6.3', 'console_scripts', 'jupyter')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 489, in 
load_entry_point

...

  File "/usr/lib/python3/dist-packages/jupyter_core/command.py", line 25, in 

from . import paths
  File "/usr/lib/python3/dist-packages/jupyter_core/paths.py", line 21, in 

from distutils.util import strtobool
ModuleNotFoundError: No module named 'distutils.util'

I was able to resolve this by installing python3-distutils, which
installs both Python 3.7 and 3.8 versions of distutils.util.

The latest /usr/lib/python3/dist-packages/jupyter_core/paths.py
module from Debian package python3-jupyter-core does import from
distutils.util. The python3-jupyter-core 4.4.0-2 installed on my
Buster host does not.

Should python3-jupyter-core now depend on package python3-distutils?

CAVEATS: The Python 3.8 transition is still a work-in-progress
on my Sid host, as I expect it is on other users'. Upgrades of
python3 libpython3-stdlib python3-minimal from 3.7.5-3 -> 3.8.2-1
are blocked because python3-talloc requires python3 (< 3.8), and
python3-talloc is (ultimately) required by gnome-control-center
via GVFS/Samba dependencies.

Also, I DO NOT have python3-all installed, which would bring in
python3-distutils. Should I have python3 installed?

My sincere apologies if I've jumped the gun and this issue would
have worked itself out as the 3.8 transition progresses. But this
could affect other qtconsole users, so I thought I should report it.

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 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 python3-jupyter-core depends on:
hi  python33.7.5-3
ii  python3-traitlets  4.3.3-2

python3-jupyter-core recommends no packages.

Versions of packages python3-jupyter-core suggests:
pn  python3-pip  

-- no debconf information



Bug#953138: mysql-workbench: Cannot install: missing libantlr4-runtime and python libraries

2020-03-04 Thread Brian Clinkenbeard
Source: mysql-workbench
Severity: serious
Justification: Policy 2.2.1

Dear Maintainer,

When attempting to install mysql-workbench there are a number of
dependencies that seem to no longer be in Debian:

The following packages have unmet dependencies:
 mysql-workbench : Depends: libantlr4-runtime4.7.2 (>= 4.7.2+dfsg) but it is 
not installable
   Depends: python-mysql.connector but it is not installable
   Depends: python-paramiko but it is not installable
   Depends: python-pyodbc (>= 2.1.8) but it is not installable
   Recommends: mysql-utilities but it is not going to be 
installed
   Recommends: default-mysql-client but it is not going to be 
installed or
   virtual-mysql-client


-- 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.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled



Bug#834724: curl: (35) gnutls_handshake() failed: Public key signature verification has failed.

2020-03-04 Thread None None
On Wed, 28 Sep 2016 12:57:49 +0100 Tim Small wrote: > Package: curl >
Followup-For: Bug #834724 > > I fixed this on a sid install by removing
libgnutls-deb0-28 which was > being kept around by an old librtmp1 package
version, left over from > Jessie debian-multimedia. Possibly libcurl should
conflict with this > package? > > -- System Information: > Debian Release:
stretch/sid > APT prefers unstable-debug > APT policy: (500,
'unstable-debug'), (500, 'unstable') > Architecture: amd64 (x86_64) >
Foreign Architectures: i386 > > Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU
core) > Locale: LANG


Bug#953137: wine-development: wine fails to start, probably due to missing nls files

2020-03-04 Thread Jiri Palecek
Package: wine-development
Version: 5.2-2
Severity: normal

Dear Maintainer,

in this version, any attempt of running wine fails, with these error
messages:

0009:err:nls:load_unix_cptable failed to load 
"/usr/lib/wine-development/../../share/wine-development/wine/nls/c_28592.nls"
000b:err:nls:load_unix_cptable failed to load 
"/usr/lib/wine-development/../../share/wine-development/wine/nls/c_28592.nls"
000b:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, 
aborting
000b:err:module:LdrInitializeThunk Initializing dlls for 
L"C:\\windows\\system32\\wineboot.exe" failed, status c005
0009:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, 
aborting
0009:err:module:LdrInitializeThunk Initializing dlls for 
L"C:\\windows\\system32\\start.exe" failed, status c005

It seems the file c_28592.nls is indeed missing from the packaging (and
other .nls files as well), although they are built on the buildd. Please
include them (and, I suggest you at least review output fo dh_missing).

Regards
Jiri Palecek

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-development.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: i386 (i686)
Foreign Architectures: amd64

Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wine-development depends on:
ii  wine32-development  5.2-2

wine-development recommends no packages.

Versions of packages wine-development suggests:
pn  dosbox   
ii  kio-extras   4:19.08.1-1+b1
pn  playonlinux  
pn  q4wine   
ii  winbind  2:4.11.5+dfsg-1
pn  wine-binfmt  
ii  winetricks   0.0+20190912-1

Versions of packages libwine-development depends on:
ii  libasound2   1.2.2-2
ii  libc62.29-8
ii  libfaudio0   19.12-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libglib2.0-0 2.62.5-1
ii  libgphoto2-6 2.5.22-3
ii  libgphoto2-port122.5.22-3
ii  libgstreamer-plugins-base1.0-0   1.16.2-2
ii  libgstreamer1.0-01.16.2-2
ii  liblcms2-2   2.9-3+b1
ii  libldap-2.4-22.4.49+dfsg-1
ii  libmpg123-0  1.25.13-1
ii  libncurses6  6.1+20191019-1
ii  libopenal1   1:1.19.1-1+b1
ii  libpcap0.8   1.9.1-2
ii  libpulse013.0-3
ii  libtinfo66.1+20191019-1
ii  libudev1 244.3-1
ii  libvkd3d11.1-3
ii  libx11-6 2:1.6.9-2
ii  libxext6 2:1.3.3-1+b2
ii  libxml2  2.9.10+dfsg-3
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-2
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages libwine-development recommends:
pn  fonts-liberation   
ii  fonts-wine 5.0~rc4-1
ii  gstreamer1.0-plugins-good  1.16.2-2
pn  libasound2-plugins 
pn  libcapi20-3
ii  libcups2   2.3.1-7
ii  libdbus-1-31.12.16-2
ii  libgl1 1.3.1-1
ii  libgl1-mesa-dri19.3.3-1
ii  libglu1-mesa [libglu1] 9.0.1-1
ii  libgnutls303.6.12-2
ii  libgsm11.0.18-2
ii  libgssapi-krb5-2   1.17-5
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libkrb5-3  1.17-5
ii  libodbc1   2.3.6-0.1+b1
ii  libosmesa6 19.3.3-1
ii  libpng16-161.6.37-1
ii  libsane1.0.27-3.2+b1
ii  libsdl2-2.0-0  2.0.10+dfsg1-2
ii  libtiff5   4.1.0+git191117-2
ii  libv4l-0   1.16.3-3
ii  libvulkan1 1.1.126.0-2
ii  libxcomposite1 1:0.4.4-2
ii  libxcursor11:1.2.0-2
ii  libxfixes3 1:5.0.3-1
ii  libxi6 2:1.7.9-1
ii  libxinerama1   2:1.1.4-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  libxslt1.1 1.1.34-3
ii  libxxf86vm11:1.1.4-1+b2

Versions of packages libwine-development suggests:
ii  cups-bsd   2.3.1-7
ii  gstreamer1.0-libav 1.16.2-2
ii  gstreamer1.0-plugins-bad   1.16.2-2.1
ii  gstreamer1.0-plugins-ugly  1.16.2-2
pn  ttf-mscorefonts-installer  

Versions of packages wine32-development depends on:
ii  libc62.29-8
ii  libwine-development  

Bug#951302: timeshift: /mnt is used programmatically

2020-03-04 Thread Tony George
This is fixed in v20.03

https://github.com/teejee2008/timeshift/releases/tag/v20.03


Bug#952066: jag: FTBFS: SDL_mixer.h:25:10: fatal error: SDL_stdinc.h: No such file or directory

2020-03-04 Thread Carlos Donizete Froes
Hi,

A new version of jag/0.3.6-1 was released where the following fixes were
made[1]:

* Fixed  ->  in the source files.
* Added "pkg-config --cflags sdl2" and "pkg-config --libs sdl2 SDL2_mixer" in
the game.pro file.

[1] https://mentors.debian.net/package/jag

Bye!

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


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


Bug#950526: endlessh FTCBS: does not pass cross tools to make

2020-03-04 Thread nicoo
Control: tag -1 + confirmed pending
Control: notfound -1 1.1-1

Hi Helmut!

On Mon, Feb 03, 2020 at 05:55:34AM +0100, Helmut Grohne wrote:
> endlessh fails to cross build from source, because it does not pass
> cross tools to make. The easiest way of doing so - using dh_auto_build -
> makes endlessh cross buildable. Please consider applying the attached
> patch.

Thanks a lot for the catch, and sorry for introducing the bug in the latest
upload.


Best,

  nicoo


signature.asc
Description: PGP signature


Bug#953136: RFS: jag/0.3.6-1 [RC] -- arcade and puzzle 2D game

2020-03-04 Thread Carlos Donizete Froes
Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: jag
   Version : 0.3.6-1
   Upstream Author : XlabSoft & Industrial Infosystems
 * URL : https://gitlab.com/coringao/jag/wikis
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/games-team/jag
   Section : games

It builds those binary packages:

  jag - arcade and puzzle 2D game
  jag-data - arcade and puzzle 2D game (data file)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/j/jag/jag_0.3.6-1.dsc

Changes since the last upload:

   * New upstream release. FTBFS bug fixed. (Closes: #952066)
   * debian/control:
 + Bumped Standards-Version to 4.5.0.
 + Set Rules-Requires-Root to no.
 - Removed ${source:Version} from Depends.
   * debian/copyright:
 + Added copyright information for contact.
 + Copyright updated for current years (2020).
   * Update debian/upstream/metadata years (2020).
   * Removed d/jag.6 and d/jag.desktop.
   * debian/jag.install:
 + Binary file path changed.
 + Changed the path of the jag.desktop file.
   * debian/manpages: Changed the path of the jag.6 file.
   * debian/rules: Removed override_dh_auto_clean.

Regards,

--
  Carlos Donizete Froes [a.k.a coringao]



Bug#935706: lintian: Make tag certainty a programmatic assessment

2020-03-04 Thread Chris Lamb
Hi,

> lintian: Make tag certainty a programmatic assessment

Controversial opinion — the "certainty" of tags is of no actionable
benefit to either the users of Lintian or its developers and should
be removed.

If a tag is emitted by Lintian, this leads to one of four actions:

 a) fixing the problem
 b) postponing the fixing of the issue
 c) adding an override the issue 
 d) filing a false-positive bug report against lintian

Knowing the "certainty" is no meaningful benefit to working out what
to do from the above. Making the certainty programmatic is just
papering over this fundamental problem and implementation of this
feature could distract us from other, likely more valuable, tasks.

Even if there was some benefit or tortured situation where this might
affect what to do, the "certainty" is highly subjective and only appears
to result in annoying our users when there is a legitimate false-
positive and lintian is patronisingly and obstinately telling them it
is "certain". 


Regards,

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



Bug#937491: pynn: Python2 removal in sid/bullseye

2020-03-04 Thread Stuart Prescott
There's a new upstream version of pynn (0.9.5) that is python 3 compatible.

Is this another candidate for moving from neurodebian to debian-med as a 
starting point for that?
-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



Bug#953135: ITP: golang-github-letsencrypt-challtestsrv -- ACME challenge mock server

2020-03-04 Thread Harlan Lieberman-Berg
Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 

* Package name: golang-github-letsencrypt-challtestsrv
  Version : 1.2.0
  Upstream Author : Let's Encrypt (Internet Security Research Group)
* URL : https://github.com/letsencrypt/challtestsrv
* License : MPL-2.0
  Programming Lang: Go
  Description : ACME challenge mock server

challtestsrv is a library for testing code to respond to HTTP-01,
DNS-01, and TLS-ALPN-01 ACME challenges.  It can also be used as a
mock DNS server letting developers mock `A`, ``, `CNAME`, and
`CAA` DNS data for specific hostnames.
.
Important note: The `challtestsrv` library is for TEST USAGE ONLY.  It
is trivially insecure, offering no authentication whatsoever.  Only
use this library in a controlled test environment.

This library is being packaged as a dependency for pebble, which is
itself an ACME test server to be used by the Debian Let's Encrypt team
for end-to-end CI testing of ACME clients.



Bug#953134: sensible-utils: 0.0.12+nmu1 broke recursion protection

2020-03-04 Thread Matthew Gabeler-Lee
Package: sensible-utils
Version: 0.0.12+nmu1
Severity: normal

The diff applied for sensible-editor in 0.0.12+nmu1 broke the logic to
protect against recursive loops due to a copy paste error:

[ -n "$EDITOR" ] && [ "$(which $EDITOR || true)" = "$p" ] && EDITOR=
[ -n "$EDITOR" ] && [ "$(which $VISUAL || true)" = "$p" ] && VISUAL=
[ -n "$EDITOR" ] && [ "$(which $SELECTED_EDITOR || true)" = "$p" ] && 
SELECTED_EDITOR=

Should be:

[ -n "$EDITOR" ] && [ "$(which $EDITOR || true)" = "$p" ] && EDITOR=
[ -n "$VISUAL" ] && [ "$(which $VISUAL || true)" = "$p" ] && VISUAL=
[ -n "$SELECTED_EDITOR" ] && [ "$(which $SELECTED_EDITOR || true)" = "$p" ] && 
SELECTED_EDITOR=

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

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

-- no debconf information



Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Nicholas D Steeves
Hi Lisandro,

Lisandro Damián Nicanor Pérez Meyer  writes:

> Hi!
>
> On Wed, 4 Mar 2020 at 20:40, Nicholas D Steeves  wrote:
>>
>> Hi Lisandro,
>>
>> Out of curiosity, could this be solved for a Debian (and derivatives)
>> context by changing the Recommends on clang and clang-tidy to their
>> versioned package names (eg: clang-8 and clang-tidy-8)?
>
> No, this is not a versioning problem.
>

I agree, ideally it should be solved upstream, but a side-effect of
installing Recommends s/clang/clang-8/ is that it pulls in a dependency
on libclang-common-8-dev, and

Alexis Murzeau  writes:

> Install `qtcreator` but not the `libclang-common-8-dev` package
> Note: Installing `clang` package will install `clang-9` and not `clang-8`.
>
[snip]
>
> When installing the `libclang-common-8-dev` package, the clang code
> model error goes away and no error is reported anymore.
>
[snip]
>
> I expect the clang code model to work out of the box with all depends
> and recommends dependencies of `qtcreator`.
> As of now, `libclang-common-8-dev` seems required by the clang code
> model to work correctly, but that package is not a direct or indirect
> dependency of `qtcreator`.
>
> The simplest solution (if it is the right one) is to add
> `libclang-common-8-dev` as depends or recommends dependency to qtcreator.
> Or maybe it should be a dependency of `libclang1-8` instead (which
> qtcreator depends on).
>

My proposal would solve the Debian (and derivatives) case and is easy to
update/maintain with a sed regex.  Is our team categorically opposed to
working around upstream issues using Debian packaging facilities?

Thanks,
Nicholas


signature.asc
Description: PGP signature


Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Alexis Murzeau
Le 05/03/2020 à 00:03, Lisandro Damián Nicanor Pérez Meyer a écrit :
> Hi again.
> 
> On Wed, 4 Mar 2020 at 19:45, Alexis Murzeau  wrote:
>>
>> Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit :
>>> Hi!
>>>
>>> El mié., 4 mar. 2020 18:11, Alexis Murzeau  escribió:
>>>
 Hi,

 I've a question about whether libclang1-X should depend on
 libclang-common-X-dev to always have the clang's builtin headers
 available when libclang is installed.

>>>
>>> Definitely not. Headers should depend upon the library, not the other way
>>> around.
>>>

>>>
>>
>> Why do you think that ?
> 
> Because development files should depend upon the libraries they
> provide the headers for, not the other way around. It's the basics of
> library packaging.

libclang-common-X-dev contains clang's builtin headers which are not the
same as libclang API headers.

clang's builtin headers are not the ones providing the API of libclang
but compiler builtin functions like _mm_sqrt_ps using clang's specific
functions like __builtin_ia32_sqrtps.

The package that contains libclang's API headers is libclang-X-dev, not
libclang-common-X-dev.

So to sum up, clang has:
 - libclang-X-dev: libclang's API headers containing functions available
in libclang to manipulate AST, compile code, ... (for example
ASTMutationListener.h, CompilerInstance.h, CXCompilationDatabase.h, ...)

 - libc++-X-dev: clang's libc++ standard library headers (for example
vector, unordered_map, ...)

 - libc6-dev: GNU C standard library headers (for example stdlib.h,
stdio.h, ...)

 - libclang-common-X-dev: clang's builtin headers (for example,
immintrin.h, stddef.h, x86intrin.h, ...)

And there is also libllvm API headers:
 - libllvm-X-dev: llvm's API headers (for example IRReader.h,
LinkTimeOptimizer.h, ...)

> 
> [snip]
>> If libclang1-X should not depend on libclang-common-X-dev, then users of
>> libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile
>> code from source should depend themselves on libclang-common-X-dev as it
>> is required for them to work correctly.
> 
> And then again, wrong. Making an IDE show the header a compiler is
> **NOT** using it's plain **WRONG**. I already expressed that in the
> bug upstream and in Qt Creator's bug. Note that I did even stress the
> question in upstream's bug just to show that nobody could say
> otherwise. Neither Marko nor Thiago denied that.

This may be wrong, but having parse errors because of issues like "fatal
error: 'stddef.h' file not found" is not better. It makes qtcreator's
code model to fail to parse code, which is one of the key feature of an
IDE like this.

It's better have the IDE use clang's builtin headers than not being able
to parse code because of missing builtin headers.

> 
> So if you want a fix make clang understand other compiler's headers,
> or provide a better code parser.


Currently, whatever if this is right or wrong, the only way to fix
"fatal error: 'stddef.h' file not found" when using qtcreator or
kdevelop on Debian is to install the appropriate libclang-common-X-dev.



The toolchain used to parse the code model for qtcreator and the
toolchain used to actually compile the code can be different, but that
doesn't matter because clang already provide the appropriate *builtin*
headers to make other compilers specific functions also available with
clang.

For example, gcc provides the non standard function _get_ssp available
from immintrin.h [0], clang also does provide it in cetintrin.h builtin
header which is included by its own immintrin.h builtin header.

MSVC provides _InterlockedCompareExchange_HLEAcquire function (which is
specific to MSVC as said in [1]), clang also provides it in the same
immintrin.h builtin header (even on linux, these builtin headers are in
libclang-common-X-dev package. Or maybe guarded with some #ifdef).


So while clang support other compilers specifics, it still needs to have
its matching *builtin* headers (which are mostly only intrinsics or
platform specific stuff) as builtin headers of each compilers are
probably highly specific to the compiler they are made for (which are
different from API headers or C and C++ standard library headers).



> 
> Regards, Lisandro.
> 
> 

[0]
https://gcc.gnu.org/onlinedocs/gcc/x86-control-flow-protection-intrinsics.html#x86-control-flow-protection-intrinsics
[1]
https://docs.microsoft.com/fr-fr/cpp/intrinsics/interlockedcompareexchange-intrinsic-functions?view=vs-2019


-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature


Bug#953132: kodi-pvr-vdr-vnsi: Please prepare for Kodi 18 transition

2020-03-04 Thread Bálint Réczey
Package: kodi-pvr-vdr-vnsi
Version: 2.6.12-1
Severity: normal

Hi Tobias,

I've prepared the other  kodi-related packages in the packaging
repositories to be ready for kodi 18 and I've already uploaded kodi 18
to experimental.

Please prepare this add-on, too, for switching to kodi 18.

Thanks,
Balint



Bug#953056: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used

2020-03-04 Thread Stuart Prescott
Control: tags -1 + patch

This is not a bug in the individual python module packages as claimed at [1]. 
It is a bug in py3compile.

$ touch foo.py 
$ py3compile foo.py  
/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering 
(buffering=1) isn't supported in binary mode, the default buffer size will be 
used 
 self.stdin = io.open(p2cwrite, 'wb', bufsize)

The origin is at the call to `Popen`, which provides fds in binary mode while 
`bufsize=1` implies line buffering which is only allowed with text mode [2, 3].

/usr/bin/py3compile:128
def py_compile(version, optimize, workers):
if not isinstance(version, str):
version = vrepr(version)
cmd = "/usr/bin/python%s%s -m py_compile -" \
% (version, ' -O' if optimize else '')
process = Popen(cmd, bufsize=1, shell=True,
stdin=PIPE, close_fds=True)

The bug can be fixed by changing Popen to use text mode (`text=True`) but that 
risks encoding errors. Presumably the real desire here is just to have a buffer 
that is shorter than the default 8k for a binary fd and so changing bufsize to 
0 to disable buffering or indeed any other small integer would be OK.

The attached patch sets buffsize=0.

regards
Stuart

[1] https://bugs.launchpad.net/ubuntu/+source/python3.8/+bug/1863414

[2] https://docs.python.org/3/library/subprocess.html#subprocess.Popen

[3] https://docs.python.org/3/library/functions.html#open

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7>From e05f2aa70feddca072c0315ee3ee3cd45f61e746 Mon Sep 17 00:00:00 2001
From: Stuart Prescott 
Date: Thu, 5 Mar 2020 10:45:39 +1100
Subject: [PATCH] Use unbuffered IO to pass filenames to py_compile

Closes: #953056
---
 py3compile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/py3compile b/py3compile
index 125e6d3..f8e0c32 100755
--- a/py3compile
+++ b/py3compile
@@ -129,7 +129,7 @@ def py_compile(version, optimize, workers):
 version = vrepr(version)
 cmd = "/usr/bin/python%s%s -m py_compile -" \
 % (version, ' -O' if optimize else '')
-process = Popen(cmd, bufsize=1, shell=True,
+process = Popen(cmd, bufsize=0, shell=True,
 stdin=PIPE, close_fds=True)
 workers[version] = process  # keep the reference for .communicate()
 stdin = process.stdin
-- 
2.20.1



Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Lisandro Damián Nicanor Pérez Meyer
Hi!

On Wed, 4 Mar 2020 at 20:40, Nicholas D Steeves  wrote:
>
> Hi Lisandro,
>
> Out of curiosity, could this be solved for a Debian (and derivatives)
> context by changing the Recommends on clang and clang-tidy to their
> versioned package names (eg: clang-8 and clang-tidy-8)?

No, this is not a versioning problem.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/



Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Nicholas D Steeves
Hi Lisandro,

Out of curiosity, could this be solved for a Debian (and derivatives)
context by changing the Recommends on clang and clang-tidy to their
versioned package names (eg: clang-8 and clang-tidy-8)?


Cheers,
Nicholas


signature.asc
Description: PGP signature


Bug#921328: auctex: please generate and install auto-loads.el (upstream Makefile target)

2020-03-04 Thread Nicholas D Steeves
Control: block -1 by 766441

Add blocking bug, because I'm unable to assess whether my solution for
auctex solves the smartparens self-tests failures, because they are
currently failing due to what is probably an obsolete scala-mode-el.
At the moment I am waiting for confirmation from smartparens' upstream
about which variant of scala-mode to use (probably the only one on
MELPA).

Regards,
Nicholas


signature.asc
Description: PGP signature


Bug#953131: RFP: veroroute -- Veroboard, Perfboard, and PCB layout and routing application

2020-03-04 Thread Alex Lawrow
Package: wnpp
Severity: wishlist

* Package name: veroroute
  Version : 1.83
  Upstream Author : Name 
* URL : https://sourceforge.net/projects/veroroute/
* License : GPL version 3
  Programming Lang: C++
  Description : Veroboard, Perfboard, and PCB layout and routing
application


I am the author of the program. I released it on Sourceforge almost 3 years ago
and have been continually improving it since then.

I orginally wrote the software to help me do simple veroboard (stripboard)
layouts for guitar effect pedals, and
realised I could expand it to design simple PCBs also.  It is unlike any other
stripboard or PCB design software
in the approach taken to design the circuit.

I know of one other piece of free software for producing veroboard and
perfboard layouts ("DIY Layout Creator" or DIYLC).
It is fairly easy to use but lacks key functionality which makes it little more
than a glorified drawing package.
In particular it has no abilty to specify a netlist, which means the user has
to manually check
the whole design for open circuits and short circuits, and this makes it hard
to reliably design complex circuits.

VeroRoute on the other hand was designed from the start with connectivity
checking in mind.
It is impossible to create a design with a short circuit (the program won't let
you) and it will warn you about any open circuits.
Not only that, it will auto-route the circuit for you.
I recently added Gerber export. This means with a click of a few buttons you
can take a
simple stripboard or perfboard design, and easily produce the files required to
get a 2-layer PCB manufactured.
I believe this program provides the simplest way for getting a circuit laid out
and manufactured as a PCB.

See this post for an example with screeenshots ...
https://www.diystompboxes.com/smfforum/index.php?topic=123842.msg1172616#msg1172616

I do not know what is required to get a package into Debian (other than making
this request).
Someone has already ported VeroRoute to FreeBSD, and another person has made it
available in the Arch Linux User Repository.
I am hoping someone on the Debian team could do something similar and producing
a Debian package based on what I release on sourceforge.


Thank you.


Alex Lawrow



Bug#861124: ITP: elpa-writeroom-mode -- distraction-free writing for Emacs

2020-03-04 Thread Nicholas D Steeves
Control: retitle -1 RFP: elpa-writeroom-mode -- distraction-free writing for 
Emacs
Control: noowner -1 

Upstream is not longer considering a rename, so I am no longer
interested in uploading my work, because I do not want to be responsible
for dealing with potential correspondences with a litigious corporation
who distributes similarly named software in their app store.

Regards,
Nicholas


signature.asc
Description: PGP signature


Bug#953130: ITP: pebble -- ACME (RFC 8555) compliance testing server

2020-03-04 Thread Harlan Lieberman-Berg
Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 

* Package name: pebble
  Version : 2.3.0
  Upstream Author : Let's Encrypt (Internet Security Research Group)
* URL : https://github.com/letsencrypt/pebble
* License : MPL-2.0
  Programming Lang: Go
  Description : ACME (RFC 8555) test-only server

Pebble is a miniature version of Boulder
(https://github.com/letsencrypt/boulder) that can assist in the
development and testing of ACME clients against the standard without
having to setup a full production-capable ACME server.
.
Pebble is NOT designed for production use and is for testing only.  By
design, it will drop all of its state between invocations and will
randomize keys and certificates used for issuance!
.
Pebble has several top level goals:
.
1. Provide a simplified ACME testing front end
2. Provide a test-bed for new and compatibility breaking ACME features
3. Encourage ACME client best-practices
4. Aggressively build in guardrails against non-testing usage

Pebble is being packaged for Debian in order to provide a test harness
for the certbot client, as well as other ACME clients in Debian, with
the goal to be able to provide evidence that as-installed clients are
fully functional through the Debian CI system.  It will be maintained
under the auspices of the Debian Let's Encrypt team.



Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Lisandro Damián Nicanor Pérez Meyer
Hi again.

On Wed, 4 Mar 2020 at 19:45, Alexis Murzeau  wrote:
>
> Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit :
> > Hi!
> >
> > El mié., 4 mar. 2020 18:11, Alexis Murzeau  escribió:
> >
> >> Hi,
> >>
> >> I've a question about whether libclang1-X should depend on
> >> libclang-common-X-dev to always have the clang's builtin headers
> >> available when libclang is installed.
> >>
> >
> > Definitely not. Headers should depend upon the library, not the other way
> > around.
> >
> >>
> >
>
> Why do you think that ?

Because development files should depend upon the libraries they
provide the headers for, not the other way around. It's the basics of
library packaging.

[snip]
> If libclang1-X should not depend on libclang-common-X-dev, then users of
> libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile
> code from source should depend themselves on libclang-common-X-dev as it
> is required for them to work correctly.

And then again, wrong. Making an IDE show the header a compiler is
**NOT** using it's plain **WRONG**. I already expressed that in the
bug upstream and in Qt Creator's bug. Note that I did even stress the
question in upstream's bug just to show that nobody could say
otherwise. Neither Marko nor Thiago denied that.

So if you want a fix make clang understand other compiler's headers,
or provide a better code parser.

Regards, Lisandro.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/



Bug#953033: bug#39901: Emacs needs to update window-width when the user updates the text size

2020-03-04 Thread Katsumi Yamaoka
Thanks Drew.  Jidanni, try the following two advices if interest.
Probably this would be what you want `text-scale-adjust' to do.
The first one tweaks the `window-width' function so to return
a value based on the text scaling, and the second one makes the
`text-scale-adjust' function redisplay an emacs-w3m page.  It's
only a quick hack, so I don't want to imprement it in emacs-w3m.

(defadvice w3m-redisplay-this-page (around adjust-window-width activate)
  "Adjust window-width value according to `face-remapping-alist'."
  (current-buffer)
  (let ((height (ignore-errors
  (cadr (assq :height
  (assq 'default face-remapping-alist))
(if height
(let ((ofn (symbol-function 'window-width)))
  (fset 'window-width (lambda (&rest args)
(floor (/ (funcall ofn) height
  (unwind-protect
  ad-do-it
(fset 'window-width ofn)))
  ad-do-it)))

(defadvice text-scale-adjust (after redisplay-w3m-page activate)
  "Redisplay w3m page after scaling text."
  (when (eq major-mode 'w3m-mode)
(let ((w3m-message-silent t))
  (w3m-redisplay-this-page



Bug#951570: fscrypt 2.5 unlock does work well with --user=$USER

2020-03-04 Thread Eric Valette




2. I just uploaded version 0.2.6-1 of the fscrypt package. Once the new
version becomes available in the archive could you check if the problem
is still present?


Yes and BTW even without --user= I also get the problem.

#!/bin/bash

fscrypt unlock /home//mySafe
Result=$?
exit $Result

If the first unlock fails, then I have to cancel the script and restart. 
Even after I entered the right passwd.


-- eric



Bug#953129: ITP: dpf-plugins - Audio plugin collection from DISTRHO

2020-03-04 Thread Dennis Braun
Here you go: https://mentors.debian.net/package/dpf-plugins
And here: https://salsa.debian.org/multimedia-team/dpf-plugins



signature.asc
Description: OpenPGP digital signature


Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Alexis Murzeau
Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit :
> Hi!
> 
> El mié., 4 mar. 2020 18:11, Alexis Murzeau  escribió:
> 
>> Hi,
>>
>> I've a question about whether libclang1-X should depend on
>> libclang-common-X-dev to always have the clang's builtin headers
>> available when libclang is installed.
>>
> 
> Definitely not. Headers should depend upon the library, not the other way
> around.
> 
>>
> 

Why do you think that ?



My view on this is that libclang contains the compiler and the compiler
needs the headers but the headers don't really need the compiler to be used.
I agree that if you install the headers, you probably have to install
clang to use them anyway.

But actually, clang binaries (like clang-tidy) depends on
libclang-common-X-dev which depends on libllvm (that one is different
than libclang. libllvm is the backend of the compiler while libclang and
clang are the frontend)

So as of now, headers do not depends on libclang or clang, and clang
depends on these headers but not libclang.

clang also depends on libclang, as do QtCreator and kdevelop and other
IDE using libclang.

That's why I'm wondering if the dependency of clang-X =>
libclang-common-X-dev should be lifted to libclang1-X =>
libclang-common-X-dev.
For clang, this would start from:
clang-8 =>
libclang1-8
libclang-common-8-dev
to:
clang-8 =>
libclang1-8 =>
libclang-common-8-dev

The description of libclang1-X is:
The C Interface to Clang provides a relatively small API that exposes
facilities for:
- parsing source code into an abstract syntax tree (AST),
- loading already-parsed ASTs,
- traversing the AST,
- associating physical source locations with elements within the AST,
- and other facilities that support Clang-based development tools.

Some of them (like the one using already parsed AST) might not need
builtin headers, so it might be understandable to avoid a dependency
from libclang1 to libclang-common-X-dev.

binary rdepends on libclang1-{6.0,7,8} are:
 - doxygen
 - clang-X which also depends already on libclang-common-X-dev
 - clang-tools-X which also depends on clang
 - libclang-X-dev which also depends already on libclang-common-X-dev
 - bpftrace (high-level tracing language for Linux eBPF)
 - codelite (IDE for C, C++ and others)
 - gnat-ps (IDE for C and Ada)
 - gnome-builder which also depends on clang (IDE for C, C++ and others)
 - irony-server (Emacs C/C++ minor mode)
 - kdevelop which recommends clang (C/C++ IDE)
 - libclang-perl (libclang perl bindings)
 - qdoc-qt5 (tool to generate doc from C/C++ source files)
 - qtcreator which recommends clang (C/C++ IDE)
 - rtags which recommends libclang-common-X-dev (C/C++ client/server
indexer with integration for Emacs)
 - shiboken2 (CPython bindings generator for C++ libraries)
 - ycmd which recommends libclang-common-X-dev (code-completion &
comprehension server)

So many of them uses libclang to parse C/C++ code, but only bpftrace do
not I think (it parses the BPFTrace language instead which is based on C).

If libclang1-X should not depend on libclang-common-X-dev, then users of
libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile
code from source should depend themselves on libclang-common-X-dev as it
is required for them to work correctly.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature


Bug#953129: ITP: dpf-plugins - Audio plugin collection from DISTRHO

2020-03-04 Thread Dennis Braun
Package: wnpp
Severity: wishlist
Owner: d_br...@kabelmail.de


* Package name : dpf-plugins
  Version : 1.1.13
  Upstream Author : Filipe Coeho 
* URL : https://github.com/falkTX/DPF-Plugins
* License : ISC, GPL-2+, GPL-3+, LGPL-2.1+, LGPL-3+, MIT, ZLIB
  Programming Lang: C++
  Description : Audio plugin collection from DISTRHO


Heya,

the package is already in ubuntu -> 
https://packages.ubuntu.com/focal/dpf-plugins
i'll upload this package to mentors asap.

Best,
Dennis




signature.asc
Description: OpenPGP digital signature


Bug#947017: ITP: org-drill -- emacs self-learning mode with spaced repetition

2020-03-04 Thread Nicholas D Steeves
Control: retitle -1 ITP: org-drill -- emacs self-learning mode with spaced 
repetition
Control: ownder -1 !

I had almost completed packaging this, then encountered a blocker to do
missing persists.el.  See newly added "block" bug.

Cheers,
Nicholas


signature.asc
Description: PGP signature


Bug#953128: ITP: persist-el -- persist variables across Emacs Sessions

2020-03-04 Thread Nicholas D Steeves
Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 
Control: block 947017 by -1

Package name: persist-el
Version : 0.4
Upstream Author : Phillip Lord 
URL : https://elpa.gnu.org/packages/persist.html
License : GPL-3+
Programming Lang: elisp
Description : persist variables across Emacs Sessions

This package allows variables to persist across Emacs sessions.

The main entry point is `persist-defvar' which behaves like
`defvar' but which persists the variables between session.  Variables
are automatically saved when Emacs exits.

Other useful functions are `persist-save' which saves the variable
immediately, `persist-load' which loads the saved value,
`persist-reset' which resets to the default value.

Values are stored in a directory in `user-emacs-directory', using
one file per value.  This makes it easy to delete or remove unused
variables.

I am packaging this as a dependency of org-drill and will maintain it
in the Debian Emacsen Team.  I will require a sponsor for the initial
upload.

Regards,
Nicholas



Bug#953127: RFS: fonts-jetbrains-mono/1.0.3-1 [ITP] -- free and open-source typeface for developers

2020-03-04 Thread Romain Porte
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fonts-jetbrains-mono"

* Package name : fonts-jetbrains-mono
Version : 1.0.3-1
Upstream Author : [fill in name and email of upstream]
* URL : https://www.jetbrains.com/lp/mono/
* License : Apache-2
* Vcs : None
Section : fonts

It builds those binary packages:

fonts-jetbrains-mono - free and open-source typeface for developers

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

https://mentors.debian.net/package/fonts-jetbrains-mono

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

dget -x
https://mentors.debian.net/debian/pool/main/f/fonts-jetbrains-mono/fonts-jetbrains-mono_1.0.3-1.dsc

Changes since the last upload:

* Initial release (closes: #952954).


Regards,



Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Lisandro Damián Nicanor Pérez Meyer
Hi!

El mié., 4 mar. 2020 18:11, Alexis Murzeau  escribió:

> Hi,
>
> I've a question about whether libclang1-X should depend on
> libclang-common-X-dev to always have the clang's builtin headers
> available when libclang is installed.
>

Definitely not. Headers should depend upon the library, not the other way
around.

>


Bug#952470: netdata: CapabilityBoundingSet is also an issue for exim4

2020-03-04 Thread Riri Soft
Package: netdata
Version: 1.19.0-2~bpo10+1
Followup-For: Bug #952470

Hello,

I investigated further the issue: After removing /var
from the ReadOnlyPaths mails are sent but i still get a strange behavior:
mails are not sent immediately, they are queued and processed only when the
exim4 queue is recycled (every 30m), then I get the following error:

2020-03-03 20:24:38 1j9D9i-0005L4-8Y Spool error for 
/var/spool/exim4//input//1j9D9i-0005L4-8Y-D: Permission denied
2020-03-03 20:24:38 1j9D9i-0005L4-8Y Cannot open main log file 
"/var/log/exim4/mainlog": Permission denied: euid=0 egid=116
exim: could not open panic log - aborting: see message(s) above

Commenting out the CapabilityBoundingSet from the service file solves
the issue.

I did not succeeded in finding the capability to be added for mails to
be sent immediately without error.

This is an important issue for netdata use cases where alerting is key
functionality.

Cheers,
Riri.



Bug#953126: RFS: nitpic/0.1-17 [QA] [RC] -- simulator for the Microchip PIC16C84 microcontroller

2020-03-04 Thread Sudip Mukherjee
Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: nitpic
   Version : 0.1-17
   Upstream Author : Dave Madden 
 * URL : http://huizen.dds.nl/~gnupic
 * License : NITPIC GPL
 * Vcs : None
   Section : electronics

It builds those binary packages:

  nitpic - simulator for the Microchip PIC16C84 microcontroller

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/n/nitpic/nitpic_0.1-17.dsc

Changes since the last upload:

   * QA upload.
   * Mark source format as 3.0
 - Import diff in quilt format.
   * Update Standards-Version to 4.5.0
 - Update priority to optional.
   * Fix FTBFS with binutils. (Closes: #951885)

Note:
d/copyright says its "NITPIC GENERAL PUBLIC LICENSE (which appears to be 
substantially the same as the GPL)",


-- 
Regards
Sudip



Bug#953125: libpython3.8-minimal: /usr/lib/python3.8/subprocess.py:838: RuntimeWarning

2020-03-04 Thread Boyuan Yang
Package: libpython3.8-minimal
Severity: minor
Version: 3.8.2-1
X-Debbugs-CC: d...@debian.org

Hi Doko,

There is an annoying warning when configuring libpython3.8:

[...]
Preparing to unpack .../7-libpython3-stdlib_3.8.2-1_amd64.deb ...
Unpacking libpython3-stdlib:amd64 (3.8.2-1) ...
Setting up python3-minimal (3.8.2-1) ...
/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering
(buffering=1) isn't supported in binary mode, the default buffer size will be
used
  self.stdin = io.open(p2cwrite, 'wb', bufsize)
Selecting previously unselected package python3.
[...]

I believe this will need some fixes by upstream to have the warning
suppressed.

-- 
Regards,
Boyuan Yang


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


Bug#953121: qabcs: d/copyright issue

2020-03-04 Thread Eriberto
Em qua., 4 de mar. de 2020 às 17:41, Eriberto Mota
 escreveu:
>
> Em qua., 4 de mar. de 2020 às 17:15, Sean Whitton
>  escreveu:
> >
> > Source: qabcs
> > Version: 1.0.2-1
> >
> > Hello,
> >
> > I believe that the only copyright holder actually mentioned in the
> > source is DanSoft, not the individual Alexander Danilov.
>
> Hi Sean,
>
> The copyright says 'DanSoft (d...@inbox.ru), 2019'. The RFS, converted
> to ITP (#944279), says Alexander Danilov .

Sorry: s/RFS/RFP/

The RFP was opened by the upstream.

Regards,

Eriberto



Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Alexis Murzeau
Hi,

I've a question about whether libclang1-X should depend on
libclang-common-X-dev to always have the clang's builtin headers
available when libclang is installed.

A bit of context:
QtCreator uses libclang for its code model. If clang's builtin headers
are not available in the system, libclang will fail to find its builtin
headers (like stddef.h) and might fail to parse code and flag "#include
" as an error because the header cannot be found (stddef.h is
one of the builtin headers).

This was reported to QtCreator's upstream in [2].


As seen in [0] and [1], libclang expect to have its builtin headers
available to work correctly.

While analyzing this bug, I found that kdevelop has the exact same issue
as QtCreator.
That is, if they are installed without the libclang's builtin headers,
they both fail to parse "#include " as libclang can't find it.

Codelite is probably in the same case as it uses libclang too but I've
not tested it.


So, I'm thinking that libclang1-X should have a dependency on
libclang-common-X-dev as it seems all users of libclang will likely need
the builtin headers too. (For example, libclang1-8 should depend on
libclang-common-8-dev).

@LLVM Packaging Tream, what do you think about adding this dependency ?

Thanks :)

[0] http://lists.llvm.org/pipermail/cfe-dev/2018-April/057688.html
[1] http://clang.llvm.org/docs/LibTooling.html#builtin-includes
[2] https://bugreports.qt.io/browse/QTCREATORBUG-23451

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature


Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt

2020-03-04 Thread Aurelien Jarno
On 2020-03-04 09:33, Matthias Klose wrote:
> Package: src:glibc
> Version: 2.30-0experimental2
> Severity: important
> Tags: sid bullseye patch
> 
> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At

I am fine reverting temporarily that commit. But it fixes a real issue,
so the problem has to be fixed on the gcc side before the bullseye release.

> least on s390x, you get a non-wrorking compiler, which at least cannot glibc
> anymore.  The macro is still referenced in the include-fixed directory.

Do you have more details in the issue? The include-fixed directory only
contains limits.h and syslimits.h and none of them have a reference to
__glibc_has_include.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#953122: puma: CVE-2020-5249

2020-03-04 Thread Salvatore Bonaccorso
Source: puma
Version: 3.12.0-4
Severity: important
Tags: security upstream
Control: found -1 3.12.0-2

Hi,

The following vulnerability was published for puma, it is fixed
upstream in 4.3.3 and 3.12.4.

CVE-2020-5249[0]:
| In Puma (RubyGem) before 4.3.3 and 3.12.4, if an application using
| Puma allows untrusted input in an early-hints header, an attacker can
| use a carriage return character to end the header and inject malicious
| content, such as additional headers or an entirely new response body.
| This vulnerability is known as HTTP Response Splitting. While not an
| attack in itself, response splitting is a vector for several other
| attacks, such as cross-site scripting (XSS). This is related to
| CVE-2020-5247, which fixed this vulnerability but only for regular
| responses. This has been fixed in 4.3.3 and 3.12.4.


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-5249
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5249
[1] https://github.com/puma/puma/security/advisories/GHSA-33vf-4xgg-9r58

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#953123: stretch-pu: package rake/10.5.0-2+deb9u1

2020-03-04 Thread Utkarsh Gupta
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
Severity: normal

Hiya,

rake seemed to be affected by CVE-2020-8130.
This has been fixed in Sid, Bullseye, and Jessie already.
I got an ack to upload from the Security Team.

Here's the debdiff:
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

diff -Nru rake-10.5.0/debian/changelog rake-10.5.0/debian/changelog
--- rake-10.5.0/debian/changelodiff -Nru rake-10.5.0/debian/changelog
rake-10.5.0/debian/changelog
--- rake-10.5.0/debian/changelog2016-03-01 23:45:05.0 +0530
+++ rake-10.5.0/debian/changelog2020-02-29 20:57:18.0 +0530
@@ -1,3 +1,10 @@
+rake (10.5.0-2+deb9u1) stretch; urgency=high
+
+  * Team upload
+  * Add patch to use File.open explicitly. (Fixes: CVE-2020-8130)
+
+ -- Utkarsh Gupta   Sat, 29 Feb 2020 20:57:18 +0530
+
 rake (10.5.0-2) unstable; urgency=medium

   * Team upload.
diff -Nru rake-10.5.0/debian/patches/CVE-2020-8130.patch
rake-10.5.0/debian/patches/CVE-2020-8130.patch
--- rake-10.5.0/debian/patches/CVE-2020-8130.patch1970-01-01
05:30:00.0 +0530
+++ rake-10.5.0/debian/patches/CVE-2020-8130.patch2020-02-29
20:54:24.0 +0530
@@ -0,0 +1,18 @@
+Description: Use File.open explicitly.
+Author: Hiroshi SHIBATA 
+Author: Utkarsh Gupta 
+Origin: 
https://github.com/ruby/rake/commit/5b8f8fc41a5d7d7d6a5d767e48464c60884d3aee
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2020-8130
+Last-Update: 2020-02-29
+
+--- a/lib/rake/file_list.rb
 b/lib/rake/file_list.rb
+@@ -290,7 +290,7 @@
+   matched = 0
+   each do |fn|
+ begin
+-  open(fn, "r", *options) do |inf|
++  File.open(fn, "r", *options) do |inf|
+ count = 0
+ inf.each do |line|
+   count += 1
diff -Nru rake-10.5.0/debian/patches/series rake-10.5.0/debian/patches/series
--- rake-10.5.0/debian/patches/series2016-03-01 23:45:05.0 +0530
+++ rake-10.5.0/debian/patches/series2020-02-29 20:54:08.0 +0530
@@ -2,3 +2,4 @@
 skip_permission_test.patch
 autopkgtest.patch
 skip-rake-libdir.patch
+CVE-2020-8130.patch
g2016-03-01 23:45:05.0 +0530
+++ rake-10.5.0/debian/changelog2020-02-29 20:57:18.0 +0530
@@ -1,3 +1,10 @@
+rake (10.5.0-2+deb9u1) stretch; urgency=high
+
+  * Team upload
+  * Add patch to use File.open explicitly. (Fixes: CVE-2020-8130)
+
+ -- Utkarsh Gupta   Sat, 29 Feb 2020 20:57:18 +0530
+
 rake (10.5.0-2) unstable; urgency=medium

   * Team upload.
diff -Nru rake-10.5.0/debian/patches/CVE-2020-8130.patch
rake-10.5.0/debian/patches/CVE-2020-8130.patch
--- rake-10.5.0/debian/patches/CVE-2020-8130.patch1970-01-01
05:30:00.0 +0530
+++ rake-10.5.0/debian/patches/CVE-2020-8130.patch2020-02-29
20:54:24.0 +0530
@@ -0,0 +1,18 @@
+Description: Use File.open explicitly.
+Author: Hiroshi SHIBATA 
+Author: Utkarsh Gupta 
+Origin: 
https://github.com/ruby/rake/commit/5b8f8fc41a5d7d7d6a5d767e48464c60884d3aee
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2020-8130
+Last-Update: 2020-02-29
+
+--- a/lib/rake/file_list.rb
 b/lib/rake/file_list.rb
+@@ -290,7 +290,7 @@
+   matched = 0
+   each do |fn|
+ begin
+-  open(fn, "r", *options) do |inf|
++  File.open(fn, "r", *options) do |inf|
+ count = 0
+ inf.each do |line|
+   count += 1
diff -Nru rake-10.5.0/debian/patches/series rake-10.5.0/debian/patches/series
--- rake-10.5.0/debian/patches/series2016-03-01 23:45:05.0 +0530
+++ rake-10.5.0/debian/patches/series2020-02-29 20:54:08.0 +0530
@@ -2,3 +2,4 @@
 skip_permission_test.patch
 autopkgtest.patch
 skip-rake-libdir.patch
+CVE-2020-8130.patch

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

Best,
Utkarsh
---

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 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



Bug#953124: buster-pu: package rake/12.3.1-3+deb10u1

2020-03-04 Thread Utkarsh Gupta
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
Severity: normal

Hiya,

rake seemed to be affected by CVE-2020-8130.
This has been fixed in Sid, Bullseye, and Jessie already.
I got an ack to upload from the Security Team.

Here's the debdiff:
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

diff -Nru rake-12.3.1/debian/changelog rake-12.3.1/debian/changelog
--- rake-12.3.1/debian/changelog2018-05-02 19:16:41.0 +0530
+++ rake-12.3.1/debian/changelog2020-02-29 20:40:36.0 +0530
@@ -1,3 +1,10 @@
+rake (12.3.1-3+deb10u1) buster; urgency=high
+
+  * Team upload
+  * Add patch to use File.open explicitly. (Fixes: CVE-2020-8130)
+
+ -- Utkarsh Gupta   Sat, 29 Feb 2020 20:40:36 +0530
+
 rake (12.3.1-3) unstable; urgency=medium

   * Revert the drop of the ruby dependency. See Debian bug #897279 for related
diff -Nru rake-12.3.1/debian/patches/CVE-2020-8130.patch
rake-12.3.1/debian/patches/CVE-2020-8130.patch
--- rake-12.3.1/debian/patches/CVE-2020-8130.patch1970-01-01
05:30:00.0 +0530
+++ rake-12.3.1/debian/patches/CVE-2020-8130.patch2020-02-29
20:34:19.0 +0530
@@ -0,0 +1,18 @@
+Description: Use File.open explicitly.
+Author: Hiroshi SHIBATA 
+Author: Utkarsh Gupta 
+Origin: 
https://github.com/ruby/rake/commit/5b8f8fc41a5d7d7d6a5d767e48464c60884d3aee
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2020-8130
+Last-Update: 2020-02-29
+
+--- a/lib/rake/file_list.rb
 b/lib/rake/file_list.rb
+@@ -294,7 +294,7 @@
+   matched = 0
+   each do |fn|
+ begin
+-  open(fn, "r", *options) do |inf|
++  File.open(fn, "r", *options) do |inf|
+ count = 0
+ inf.each do |line|
+   count += 1
diff -Nru rake-12.3.1/debian/patches/series rake-12.3.1/debian/patches/series
--- rake-12.3.1/debian/patches/series2018-05-02 19:16:41.0 +0530
+++ rake-12.3.1/debian/patches/series2020-02-29 20:31:31.0 +0530
@@ -1,3 +1,4 @@
 0001-test-helper-adapt-to-test-installed-package.patch
 0002-rake-testtask-never-include-I-usr-lib-ruby-vendor_ru.patch
 0003-gemspec-drop-git-usage.patch
+CVE-2020-8130.patch

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

Best,
Utkarsh
---

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 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



Bug#949980: libgl1-mesa-dri: SIGSEGV in rockchip_dri.so when running Gnome/GTK

2020-03-04 Thread Zack Weinberg
Package: libgl1-mesa-dri
Followup-For: Bug #949980

This bug is still present with the libgl1-mesa-dri in unstable
(currently 19.3.3-1), but upgrading the following set of packages
to the version in experimental (currently 20.0.0-1) fixes it for me:

libegl-mesa0
libgbm1
libgl1-mesa-dri
libglapi-mesa
libglx-mesa0
mesa-va-drivers
mesa-vdpau-drivers
mesa-vulkan-drivers


-- Package-specific info:
glxinfo:

glxinfo is not available (missing mesa-utils package).

/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

The lspci command was not found; not including PCI data.

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.5.0-1-pinebookpro-arm64 (abuild@obs-arm-9) (gcc version 9.2.1 
20200224 (Debian 9.2.1-30)) #1 SMP PREEMPT Sun Mar 1 05:19:55 UTC 2020

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 36000 Mar  4 15:44 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[12.158] 
X.Org X Server 1.20.7
X Protocol Version 11, Revision 0
[12.158] Build Operating System: Linux 4.19.0-6-arm64 aarch64 Debian
[12.158] Current Operating System: Linux torrey 5.5.0-1-pinebookpro-arm64 
#1 SMP PREEMPT Sun Mar 1 05:19:55 UTC 2020 aarch64
[12.158] Kernel command line: root=PARTLABEL=mmcblk0-RootFS 
console=ttyS2,150n8 console=tty0 ro quiet splash 
plymouth.ignore-serial-consoles maxcpus=4 coherent_pool=1M 
earlycon=uart8250,mmio32,0xff1a mem_sleep_default=s2idle
[12.158] Build Date: 05 February 2020  04:27:36PM
[12.158] xorg-server 2:1.20.7-3 (https://www.debian.org/support) 
[12.158] Current version of pixman: 0.36.0
[12.158]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[12.158] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[12.159] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar  4 14:02:25 
2020
[12.171] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[12.174] (==) No Layout section.  Using the first Screen section.
[12.175] (==) No screen section available. Using defaults.
[12.175] (**) |-->Screen "Default Screen Section" (0)
[12.175] (**) |   |-->Monitor ""
[12.176] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[12.176] (==) Automatically adding devices
[12.177] (==) Automatically enabling devices
[12.177] (==) Automatically adding GPU devices
[12.177] (==) Max clients allowed: 256, resource mask: 0x1f
[12.182] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[12.183]Entry deleted from font path.
[12.189] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[12.189] (==) ModulePath set to "/usr/lib/xorg/modules"
[12.189] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[12.189] (II) Loader magic: 0xbb81ce10
[12.189] (II) Module ABI versions:
[12.189]X.Org ANSI C Emulation: 0.4
[12.189]X.Org Video Driver: 24.1
[12.189]X.Org XInput driver : 24.1
[12.189]X.Org Server Extension : 10.0
[12.194] (++) using VT number 7

[12.194] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[12.199] (II) xfree86: Adding drm device (/dev/dri/card0)
[12.207] (II) xfree86: Adding drm device (/dev/dri/card1)
[12.207] (II) no primary bus or device found
[12.207]falling back to 
/sys/devices/platform/display-subsystem/drm/card0
[12.207] (II) LoadModule: "glx"
[12.211] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[12.257] (II) Module glx: vendor="X.Org Foundation"
[12.257]compiled for 1.20.7, module version = 1.0.0
[12.257]ABI class: X.Org Server Extension, version 10.0
[12.258] (==) Matched modesetting as autoconfigured driver 0
[12.258] (==) Matched fbdev as autoconfigured driver 1
[12.258] (==) Assigned the driver to the xf86ConfigLayout
[12.258] (II) LoadModule: "modesetting"
[12.259] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[12.264] (II) Module modesetting: vendor="X.Org Foundatio

Bug#953099: lintian: FPOS for pkg-config-references-unknown-shared-library

2020-03-04 Thread Mattia Rizzolo
On Wed, Mar 04, 2020 at 09:14:40AM -0800, Felix Lechner wrote:
> On Wed, Mar 4, 2020 at 5:33 AM Mattia Rizzolo  wrote:
> > xml2 is clearly a direct dependency of libxslt1-dev, and 'libxml2.so' is
> > shipped by libxml2-dev which is a direct dependency of libxslt1-dev
> 
> The way I understand pkg-config, the libraries listed do not have to
> be direct prerequisites (i.e. the extra math library of old, -lm).

I don't know what "direct prerequisites" means in your sentence above,
but I feel like I agree with you :)

> Lintian cannot test for all prerequisites without unpacking all build
> requirements and, in effect, attempting a build.
> 
> I would like to remove this tag from Lintian.

Indeed, https://bugs.debian.org/920699 doesn't show much thought for
this fact.
It feels to me that just removing this is kind of a waste…   But yes,
lintian has no access to anything external from the single package, and
it can't know the contents of the dependencies.  So indeed perhaps this
tag might just be impossible to implement correctly with lintian's
limitations.

-- 
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#953121: qabcs: d/copyright issue

2020-03-04 Thread Eriberto Mota
Em qua., 4 de mar. de 2020 às 17:15, Sean Whitton
 escreveu:
>
> Source: qabcs
> Version: 1.0.2-1
>
> Hello,
>
> I believe that the only copyright holder actually mentioned in the
> source is DanSoft, not the individual Alexander Danilov.

Hi Sean,

The copyright says 'DanSoft (d...@inbox.ru), 2019'. The RFS, converted
to ITP (#944279), says Alexander Danilov .

This package was approved by FTP-Master  team today. So, all is right.

Thanks!

Eriberto



Bug#843014: Apache2: ServerTokens Minimal

2020-03-04 Thread receive

Hi there,
just would like to add my opinion.

First of all,
thank you Stefan for tagging this as "wontfix".

To be honest, for myself these tokens are essential for debugging 
customer appliances without having access to their services. We're able 
to identify their server software easily through these headers and are 
able to provide proper support services to them.
Further they're enabling us to gather simple statistical information 
throughout our monitoring.


Further, normal users are able to gather simple information by a simple 
nmap scan of their server which services are running on it if they're 
unexperienced in usage.
Some tutorials rely on these headers and if we wouldn't have them 
anymore, we couldn't use them also properly anymore. Just google abit 
and you'll find one quite fast.


All in all, they're quite nice to have.
If anyone feels annoyed of them, they're able to turn it of.
I don't think we should remove it by default. As Stefan already 
mentioned they could be a security issue - but as a black hat you could 
gather the server information anyway quite fast if youre experienced 
enough.


Best wishes,
Anna Sdvoijspa



Bug#952557: proftpd-dfsg: Followup fix for CVE-2020-9273

2020-03-04 Thread Salvatore Bonaccorso
Hi Hilmar,

On Wed, Mar 04, 2020 at 09:09:30PM +0100, Hilmar Preuße wrote:
> found -1 1.3.5b-4+deb9u3
> found -1 1.3.6-4+deb10u3
> 
> On 2/25/20 8:39 PM, Salvatore Bonaccorso wrote:
> 
> > As per https://github.com/proftpd/proftpd/issues/903 there was a
> > follow-up fix for upstream issue #903, CVE-2020-9273.
> > 
> Found in stable and oldstable too.

Actually not, because we never released a fix for #903 which was
incomplete. The update issued contained both commits needed.

Regards,
Salvatore



Bug#952557: proftpd-dfsg: Followup fix for CVE-2020-9273

2020-03-04 Thread Hilmar Preuße
found -1 1.3.5b-4+deb9u3
found -1 1.3.6-4+deb10u3

On 2/25/20 8:39 PM, Salvatore Bonaccorso wrote:

> As per https://github.com/proftpd/proftpd/issues/903 there was a
> follow-up fix for upstream issue #903, CVE-2020-9273.
> 
Found in stable and oldstable too.

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



signature.asc
Description: OpenPGP digital signature


Bug#953121: qabcs: d/copyright issue

2020-03-04 Thread Sean Whitton
Source: qabcs
Version: 1.0.2-1

Hello,

I believe that the only copyright holder actually mentioned in the
source is DanSoft, not the individual Alexander Danilov.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#953120: "salsa.sh update_safe" with no extra arguments should error out

2020-03-04 Thread Christoph Berg
Package: devscripts
Version: 2.20.2
Severity: normal

$ cat config
#SALSA_GROUP=debian-hamradio-team
SALSA_GROUP=debian-hamradio-team/soapysdr
SALSA_TOKEN_FILE=~/.priv/pw/salsa-token
SALSA_IRKER=no
SALSA_KGB=yes
SALSA_IRC_CHANNEL='debian-hams;use_irc_notices=1;squash_threshold=3'
SALSA_CI_CONFIG_PATH=debian/gitlab-ci.yml
SALSA_EMAIL=yes
SALSA_EMAIL_RECIPIENTS=dispatch+%p_...@tracker.debian.org
SALSA_ENABLE_MR=yes
SALSA_ENABLE_ISSUES=yes
SALSA_TAGPENDING=yes

$ cat salsa.sh
#!/bin/sh

salsa --conffile config "$@"

Now run that without any extra arguments like --all:

$ ./salsa.sh update_safe
salsa warn: Repository name is missing
1 packages misconfigured, update them ? (Y/n) ^C

The misconfig warning appeared basically instantaneously so I don't
believe it was actually talking to salsa.

Christoph



Bug#924099: ITP

2020-03-04 Thread Ryan Pavlik
I now have a package for this tool up on mentors, seeking sponsorship.
(And yes, the package builds its own man pages with itself.)

https://mentors.debian.net/package/click-man

I have the source maintained on salsa at
https://salsa.debian.org/rpavlik-guest/click-man

Let me know if there are changes you'd recommend. (Besides mentioning
the ITP bug in the changelog) It is passing all the salsa-ci tests
except for the reprotest.

Thanks!

Ryan



signature.asc
Description: OpenPGP digital signature


Bug#908805: Gruß

2020-03-04 Thread MUSTERMANN MAXIMLIAN HANNOVER
Gruß

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

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

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



Bug#953062: FTBFS on arm64, armel, armhf, ppc64el, s390x

2020-03-04 Thread Moritz Mühlenhoff
On Tue, Mar 03, 2020 at 05:56:18PM -0600, Ryan Pavlik wrote:
> armel and armhf: these platforms only have OpenGL-ES, not desktop
> OpenGL, so the correct thing to do is to disable this package on those
> platforms. Is there a better way to do this than to list all other
> platforms in the control file?

No, I think listing the archs it's known to build on is the only
way.

Cheers,
Moritz



Bug#953119: mtj: Please make another source-only upload to allow testing migration

2020-03-04 Thread Boyuan Yang
Source: mtj
Version: 0.9.14+dfsg-6
Severity: serious
Justification: out-of-sync unstable-to-testing
X-Debbugs-CC: ti...@debian.org

Dear package mtj maintainers,

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

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

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

-- 
Regards,
Boyuan Yang


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


Bug#952947: peewee: Package latest upstream (3.13.1)

2020-03-04 Thread Mike Gabriel

Hi Adrian,

On  Mo 02 Mär 2020 22:16:35 CET, Adrian Vondendriesch wrote:


Hi Mike,

Am 02.03.20 um 08:42 schrieb Mike Gabriel:

Package: src:peewee
Severity: wishlist
X-Debbugs-Cc: adrian.vondendrie...@credativ.de

Hi Adrian,

for packaging GWE (GreenWithEnvy), a GPU (mostly NVidia) tweaking tool,
I need an updated version of peewee in Debian unstable.

Would you be available for updating the package the coming days?


I've prepared a new upload. However, I need to have a close look at the
build log. The testsuite prints some warnings and I would like to verify
it doesn't include serious errors.


Ok. Please ping me once you are ready for upload / have uploaded.


Otherwise, would you be ok with me doing a team upload?


I'm always ok with team uploads ;)


As you are currently my applicant in NM, I'd love to sponsor that  
upload and also give feedback (if there is anything to be said after  
reviewing).


Greets,
Mike

--

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

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



pgpou8Ihf35lc.pgp
Description: Digitale PGP-Signatur


Bug#953118: RM: projectm -- RoQA; Depends on Qt4

2020-03-04 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove projectm. It depends on Qt4, which is now being removed.
It can be reintroduced when/if ported to Qt5.

Cheers,
Moritz




Bug#953117: Acknowledgement (infernal: please make the build reproducible)

2020-03-04 Thread Chris Lamb


> Thank you for filing a new Bug report with Debian.

[…]

Ah, this might be actually #946315 that needs reopening..



Regards,

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



Bug#953117: infernal: please make the build reproducible

2020-03-04 Thread Chris Lamb
Source: infernal
Version: 1.1.3-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

│ │ │ ├── ./usr/share/doc/infernal/examples/testsuite/i49.tbl
│ │ │ │ @@ -5,10 +5,10 @@
│ │ │ │  #
│ │ │ │  # Program: cmsearch
│ │ │ │  # Version: 1.1.3 (Nov 2019)
│ │ │ │  # Pipeline mode:   SEARCH
│ │ │ │  # Query file:  ./../testsuite/bug-i49.cm
│ │ │ │  # Target file: ./../testsuite/bug-i49.fa
│ │ │ │  # Option settings: ../src/cmsearch --tblout i49.tbl --toponly --cpu 0 
./../testsuite/bug-i49.cm ./../testsuite/bug-i49.fa 
│ │ │ │ -# Current dir: /build/1st/infernal-1.1.3/testsuite
│ │ │ │ -# Date:Sun Mar  1 19:36:34 2020
│ │ │ │ +# Current dir: /build/2/infernal-1.1.3/2nd/testsuite
│ │ │ │ +# Date:Mon Apr  5 04:14:10 2021
│ │ │ │  # [ok]

Patch attached that excludes this nondetermistic file from the binary
package.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2020-03-04 10:10:02.000119663 -0800
--- b/debian/rules  2020-03-04 10:20:14.910600860 -0800
@@ -51,4 +51,5 @@
cd $(sampledir) && ln -s 
../../../../lib/$(DEB_TARGET_MULTIARCH)/$(DEB_SOURCE)/examples/easel ./easel \
&& ln -s 
../../../../lib/$(DEB_TARGET_MULTIARCH)/$(DEB_SOURCE)/examples/src ./src
cp -aR testsuite $(sampledir)/
+   rm $(sampledir)/testsuite/*.tbl
cp ./easel/devkit/sqc $(sampledir)/


Bug#945404: Information

2020-03-04 Thread khimaros
I don't believe this is a problem specific to NVMe, as my working machine has 
an NVMe drive.

The working installation is quite old as is the case with the reporter. The 
working machine was
upgraded in place from stretch. The original installation medium was:

```
# cat /var/log/installer/lsb-release 
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170112"
X_INSTALLATION_MEDIUM=cdrom
```

I am able to reproduce the breakage with two other machines which have HDD. 
These machines were
installed more recently (most recent was two days ago), using the same netinst 
image over USB:

```
# cat /var/log/installer/lsb-release
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190702+deb10u2"
X_INSTALLATION_MEDIUM=cdrom
```

All three machines are now on buster and have grub-common=2.04-5. All three 
machines are laptops.

Below are the lines from `grub-probe -vv -t abstraction` which are only present 
on the working
machine:

```
grub-probe: info: changing current directory to block.
grub-probe: info: changing current directory to by-partuuid.
grub-probe: info: changing current directory to by-uuid.
grub-probe: info: changing current directory to disk.
grub-probe: info: cheatmounted hostdisk//dev/nvme0n1,msdos5 (luks) at 
/dev/mapper/nvme0n1p5_crypt.
grub-probe: info: no LVM signature found.
grub-probe: info: opening the device hostdisk//dev/nvme0n1.
grub-probe: info: Partition 0 starts from 2048.
grub-probe: info: Partition 4 starts from 501760.
grub-probe: info: scanning crypto0 for LDM.
grub-probe: info: Scanning for dmraid_nv devices on disk crypto0.
grub-probe: info: Scanning for ldm devices on disk crypto0.
grub-probe: info: Scanning for ldm devices on disk hostdisk//dev/nvme0n1.
```

To summarize, it seems that grub-probe is scanning a few more /dev paths, 
"cheatmounted" one of the
devices, and did not find an LVM signature on one of the devices. There are 
also several references
to a crypto0 device.

I've reinstalled one of the machines with RC3 of the buster installation media 
and had the same
issue. Partitioned as "Guided full disk LVM encrypted volume" -- accepted all 
defaults.



Bug#952022: ruby-puppet-syntax: FTBFS: ERROR: Test "ruby2.7" failed: LoadError:

2020-03-04 Thread Daniel Leidert
Package: src:ruby-puppet-syntax
Followup-For: Bug #952022

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

facter has been binNMUed. The Ruby2.7 tests then failed because sync was
missing (has been soplit out of Ruby). So I added ruby-sync. But the build
still fails:

Failures:

  1) PuppetSyntax::Templates on Puppet >= 3.7 should return nothing from a 
valid file
 Failure/Error: expect(res).to match([])

   expected ["/usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb:80: 
warning: Using the last argument as keyword parameters is deprecated\n"] to 
match []
   Diff:
   @@ -1 +1,2 @@
   +/usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb:80: warning: 
Using the last argument as keyword parameters is deprecated\n
 # ./spec/puppet-syntax/templates_spec.rb:103:in `block (3 levels) in '

  2) PuppetSyntax::Templates on Puppet >= 3.7 should catch SyntaxError
 Failure/Error: expect(res.size).to eq(1)

   expected: 1
got: 2

   (compared using ==)
 # ./spec/puppet-syntax/templates_spec.rb:110:in `block (3 levels) in '

  3) PuppetSyntax::Templates on Puppet >= 3.7 should read more than one valid 
file
 Failure/Error: expect(res).to match([])

   expected ["/usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb:80: 
warning: Using the last argument as k...ile_system/file_impl.rb:80: warning: 
Using the last argument as keyword parameters is deprecated\n"] to match []
   Diff:
   @@ -1 +1,2 @@
   +/usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb:80: warning: 
Using the last argument as keyword parameters is 
deprecated\n/usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb:80: 
warning: Using the last argument as keyword parameters is deprecated\n
 # ./spec/puppet-syntax/templates_spec.rb:118:in `block (3 levels) in '

  4) PuppetSyntax::Templates on Puppet >= 3.7 should continue after finding an 
error in the first file
 Failure/Error: expect(res.size).to eq(2)

   expected: 2
got: 3

   (compared using ==)
 # ./spec/puppet-syntax/templates_spec.rb:125:in `block (3 levels) in '

  5) PuppetSyntax::Templates on Puppet >= 3.7 when the 'epp_only' options is 
set should process an ERB as EPP and find an error
 Failure/Error: expect(res.size).to eq(1)

   expected: 1
got: 2

   (compared using ==)
 # ./spec/puppet-syntax/templates_spec.rb:139:in `block (4 levels) in '

Finished in 0.09464 seconds (files took 0.70415 seconds to load)
43 examples, 5 failures

Failed examples:

rspec ./spec/puppet-syntax/templates_spec.rb:99 # PuppetSyntax::Templates on 
Puppet >= 3.7 should return nothing from a valid file
rspec ./spec/puppet-syntax/templates_spec.rb:106 # PuppetSyntax::Templates on 
Puppet >= 3.7 should catch SyntaxError
rspec ./spec/puppet-syntax/templates_spec.rb:114 # PuppetSyntax::Templates on 
Puppet >= 3.7 should read more than one valid file
rspec ./spec/puppet-syntax/templates_spec.rb:121 # PuppetSyntax::Templates on 
Puppet >= 3.7 should continue after finding an error in the first file
rspec ./spec/puppet-syntax/templates_spec.rb:135 # PuppetSyntax::Templates on 
Puppet >= 3.7 when the 'epp_only' options is set should process an ERB as EPP 
and find an error

/usr/bin/ruby2.7 
-I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.2/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib
 /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/exe/rspec --pattern 
./spec/\*\*/\*_spec.rb --format documentation failed
ERROR: Test "ruby2.7" failed. Exiting.

The issue probably is the new warning thrown by Ruby. I guess that's the reason
why all those tests fail. Upstream maybe already fixed it but did not yet
release a new version.

I pushed my work to the repository.

Regards, Daniel

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 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)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl5f87oACgkQS80FZ8KW
0F37/hAA2L6KoVI3ZnxYb0+XChM9xBUop07oHbYh+McgfwTwKXTpJJFPpa+jmnwQ
qUJVV7JJB0E//2oCOR2kN+NWLrdpSJHvpjYYy3nnfLR6rUjWxZ+vEJVIc/hfWOo+
Egg/o88uxzp8io8JXKRUrU3PHPIo1F+tL7SWhjDmlxzCTEtnpLQzYfLr3edVUFQb
zyfUZDcTLz7zIR0khe+EQEV6MTWanVD8XwrjhP1SBVrV6ZKmM+CkPbgcThk/JU0F
8rfVlS2DjQUPrzaAx+No1sEt1pr/NzXaRVUL07t9IQUGJ+L43owzrgviNsghW2Y+
Z/VnrZznXKxFGCYb9FiRAqxMr+bDnPn6FKeb+Hn34QBh6aW4GZ4vp/b5FWzT0hDS
lK+fK7ouLvD/jfHcAWsBc4C3KX88HW+hmlQR1Lke4L2qgvpljkUgYYmoBTXCe6CU
Y8iXeDe/tH4V3UVIlcKmCKBC+Jle30qrev+B5yBE/K2ap7SCyPXBLCRg7C4llWAz
RVmxccsx7k9NBgawWclUMl5AQYTCezmOZwNUR2g+MZlBrxkvOfhtYIVguSAvhYYM
l+qm9R/59Pm3A4xTuFYoox167r+1NhBksv/yEIXpm54HI14qJ0PFPTTCVoHFBW/a

Bug#929729: Test package ships invalid md5sums

2020-03-04 Thread Felix Lechner
Hi,

The test package provided elsewhere in this bug may have an invalid
md5sums file. As detailed in commit 822d4b70, the specifications
explain that newlines are escaped with a backslash but are printed
*verbatim*:


https://www.gnu.org/software/coreutils/manual/html_node/md5sum-invocation.html

That is also how the md5sum tool behaves. It can be tested on any file system.

The test package, however, ships an md5sums file in a different
format. That file, which is reproduced in full below, renders the
newline as 'n', a customary control character. That is incorrect and
defective. It should have an actual newline character with the value
0x0a:

e367e202f03b5f62800ece455a165565  usr/share/doc/newline/changelog.gz
\d41d8cd98f00b204e9800998ecf8427e  usr/share/newline/\n/etc/issue

This detail was probably not noticed when the bug was closed because
Lintian dequoted file names in various places. When all file indices
were made true, Lintian produced this output:

$ frontend/lintian ../bugs/newline/newline_1_all.deb
E: newline: extended-description-is-empty
E: newline: md5sums-lists-nonexistent-file usr/share/newline/n/etc/issue
E: newline: no-copyright-file
W: newline: file-missing-in-md5sums usr/share/newline/\n/etc/issue

As one can see, the files names did not match. Lintian replaces all
newlines with \n when printing tags. The fact that they look the same
is the give-away.

The package newline.deb is exotic, and current tools may refuse to
produce it. Unfortunately, it also contains an invalid list of
md5sums.

Kind regards
Felix Lechner



Bug#953033: bug#39901: Emacs needs to update window-width when the user updates the text size

2020-03-04 Thread Drew Adams
> Emacs needs to update window-width when
> the user updates the text size.

Apologies for not following this thread,
and if this reply is off-topic.  I stumbled
on this message by chance.

FWIW, letting users automatically resize
the window to accommodate a change in
text scale is the purpose of library
`face-remap+.el'.  This enhancement was
proposed to Emacs dev from the outset
(2009), but there was no interest.

`face-remap+.el' lets buffer font
resizing also zoom the window size
accordingly (horizontally, vertically,
or both).  That way, you can take
advantage of the space freed up by
resizing (text-scaling) to a smaller
font.

The code has just a small change to
`text-scale-increase'.

https://www.emacswiki.org/emacs/download/face-remap%2b.el

Option `text-scale-resize-window'
lets you control the behavior:

nil:Don't resize window
`horizontally': Resize window only horizontally
`vertically':   Resize window only vertically
t:  Resize window both directions

[If the window is alone in its frame, and if
you also use library `fit-frame.el', then the
frame is resized (horizontally & vertically).]



Bug#953105: gtk-update-icon-cache does not produce reproducible results on 32-bit architectures

2020-03-04 Thread Chris Lamb
Hi dkg,

> But it seems odd that the 32-bit architectures would produce
> unreproducible caches when the 64-bit version is reproducible.

I haven't checked the build history but assuming this is not in-of
itself a nondetermistic distinction (in which I would blame the hash
table usage) then this is likely due to filesystem ordering. Indeed if
you look at gtk/updateiconcache.c src:gtk+3.0 then, after a quick
skim, both of these things are apparent in this file.

Anyway, I've added this issue and bug to the Reproducible Builds
"notes" git repository:

  
https://salsa.debian.org/reproducible-builds/reproducible-notes/commit/0b871fa18b9accc95c960dacada22820a9a79969

… and tagged the src:balsa package with this issue:

  
https://salsa.debian.org/reproducible-builds/reproducible-notes/commit/2ea542dffb997d664a62b0485d6e02209da587ee

(Very rough and ready of course, but even this approximate tagging
is very helpful to us.)


Best wishes,

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



Bug#953116: libpetsc-complex3.10:amd64: The PETSc library has not been compiled with the --with-64-bit-indices option.

2020-03-04 Thread Henning
Package: libpetsc-complex3.10
Version: 3.10.3+dfsg1-5
Severity: normal
Tags: newcomer

Dear Maintainer,

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

   * What led up to the situation?
Applying the library using matrix dimensions higher than 46340.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Setting the dimension to 54455
   * What was the outcome of this action?
Got a report that the product of the dimension is exceeding the limit,
I should compile the PETSc libraries with the --with-64-bit-indices option.
I assume that singed 4 Byte integers are used to describe the indices
and the product of the indices.
   * What outcome did you expect instead?
Just a normal diagonalization. Compiling the library with this option
solved the situation.
*** End of the template - remove these template lines ***


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/32 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.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 libpetsc-complex3.10:amd64 depends on:
ii  libamd21:5.4.0+dfsg-1
ii  libatlas3-base [liblapack.so.3]3.10.3-8
ii  libblas3 [libblas.so.3]3.8.0-2
ii  libc6  2.28-10
ii  libcholmod31:5.4.0+dfsg-1
ii  libfftw3-double3   3.3.8-2
ii  libfftw3-mpi3  3.3.8-2
ii  libgcc11:8.3.0-6
ii  libgfortran5   8.3.0-6
ii  libhdf5-openmpi-1031.10.4+repack-10
ii  libklu11:5.4.0+dfsg-1
ii  liblapack3 [liblapack.so.3]3.8.0-2
ii  libmumps-5.1.2 5.1.2-4+b2
ii  libopenblas-base [liblapack.so.3]  0.3.5+ds-3
ii  libopenmpi33.1.3-11
ii  libptscotch-6.06.0.6-2
ii  libquadmath0   8.3.0-6
ii  libscalapack-openmpi2.02.0.2-7+b2
ii  libstdc++6 8.3.0-6
ii  libsuperlu-dist6   6.1.1+dfsg1-1
ii  libsuperlu55.2.1+dfsg1-4
ii  libumfpack51:5.4.0+dfsg-1

libpetsc-complex3.10:amd64 recommends no packages.

libpetsc-complex3.10:amd64 suggests no packages.

-- no debconf information



Bug#953114: linux-image-5.4.0-4-amd64: r8169 temporarely looses netwok connectivity

2020-03-04 Thread Lukas Straub
Package: src:linux
Version: 5.4.19-1
Severity: normal

Dear Maintainer,
Under network and/or cpu load, network connectivity is regularely lost for 
short amounts of time (~3 seconds).

This problems also happens with 
linux-image-5.5.0-rc5-amd64-unsigned_5.5~rc5-1~exp1_amd64.
This problem does not happen with linux-image-5.3.0-2-amd64.

Mar 04 15:51:39 tele-clu-03 kernel: [ cut here ]
Mar 04 15:51:39 tele-clu-03 kernel: NETDEV WATCHDOG: enp1s0 (r8169): transmit 
queue 0 timed out
Mar 04 15:51:39 tele-clu-03 kernel: WARNING: CPU: 0 PID: 1503 at 
net/sched/sch_generic.c:447 dev_watchdog+0x248/0x250
Mar 04 15:51:39 tele-clu-03 kernel: Modules linked in: tun sctp ppp_deflate 
bsd_comp ppp_async crc_ccitt ppp_generic slhc sch_htb cls_cgroup bridge stp llc 
ext4 crc16 mbcache jbd2 dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio 
radeon nls_ascii nls_cp437 vfat fat kvm_amd ccp rng_core kvm efi_pstore ttm 
snd_hda_codec_realtek evdev snd_hda_codec_generic drm_kms_helper 
snd_hda_codec_hdmi ledtrig_audio snd_hda_intel snd_intel_nhlt snd_hda_codec drm 
irqbypass serio_raw snd_hda_core efivars pcspkr k10temp sp5100_tco snd_hwdep 
watchdog snd_pcm sg snd_timer snd i2c_algo_bit soundcore button acpi_cpufreq 
efivarfs ip_tables x_tables autofs4 btrfs xor zstd_decompress zstd_compress 
raid6_pq libcrc32c crc32c_generic dm_mod sd_mod uas usb_storage ahci libahci 
ohci_pci libata ohci_hcd ehci_pci ehci_hcd usbcore scsi_mod psmouse r8169 
realtek libphy i2c_piix4 usb_common
Mar 04 15:51:39 tele-clu-03 kernel: CPU: 0 PID: 1503 Comm: pidof Not tainted 
5.4.0-4-amd64 #1 Debian 5.4.19-1
Mar 04 15:51:39 tele-clu-03 kernel: Hardware name: FUJITSU FUTRO S700/D3003-B1, 
BIOS V4.6.4.1 R1.19.0 for D3003-B1x 07/03/2013
Mar 04 15:51:39 tele-clu-03 kernel: RIP: 0010:dev_watchdog+0x248/0x250
Mar 04 15:51:39 tele-clu-03 kernel: Code: 85 c0 75 e5 eb 9f 4c 89 ef c6 05 58 
1d a8 00 01 e8 0d e4 fa ff 44 89 e1 4c 89 ee 48 c7 c7 f0 cc 52 85 48 89 c2 e8 
76 40 a0 ff <0f> 0b eb 80 0f 1f 40 00 0f 1f 44 00 00 41 57 41 56 49 89 d6 41 55
Mar 04 15:51:39 tele-clu-03 kernel: RSP: :a25280003e68 EFLAGS: 00010286
Mar 04 15:51:39 tele-clu-03 kernel: RAX:  RBX: 898fb6076e00 
RCX: 0006
Mar 04 15:51:39 tele-clu-03 kernel: RDX: 0007 RSI: 0082 
RDI: 898ff9817680
Mar 04 15:51:39 tele-clu-03 kernel: RBP: 898ff3f6245c R08: 0373 
R09: 0004
Mar 04 15:51:39 tele-clu-03 kernel: R10:  R11: 0001 
R12: 
Mar 04 15:51:39 tele-clu-03 kernel: R13: 898ff3f62000 R14: 898ff3f62480 
R15: 0001
Mar 04 15:51:39 tele-clu-03 kernel: FS:  7f50dcc40540() 
GS:898ff980() knlGS:
Mar 04 15:51:39 tele-clu-03 kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Mar 04 15:51:39 tele-clu-03 kernel: CR2: 558bfde65018 CR3: 7650c000 
CR4: 06f0
Mar 04 15:51:39 tele-clu-03 kernel: Call Trace:
Mar 04 15:51:39 tele-clu-03 kernel:  
Mar 04 15:51:39 tele-clu-03 kernel:  ? pfifo_fast_enqueue+0x150/0x150
Mar 04 15:51:39 tele-clu-03 kernel:  call_timer_fn+0x2d/0x130
Mar 04 15:51:39 tele-clu-03 kernel:  __run_timers.part.0+0x16f/0x260
Mar 04 15:51:39 tele-clu-03 kernel:  ? timerqueue_add+0x96/0xb0
Mar 04 15:51:39 tele-clu-03 kernel:  ? enqueue_hrtimer+0x36/0x90
Mar 04 15:51:39 tele-clu-03 kernel:  run_timer_softirq+0x26/0x50
Mar 04 15:51:39 tele-clu-03 kernel:  __do_softirq+0xe6/0x2e9
Mar 04 15:51:39 tele-clu-03 kernel:  irq_exit+0xa6/0xb0
Mar 04 15:51:39 tele-clu-03 kernel:  smp_apic_timer_interrupt+0x76/0x130
Mar 04 15:51:39 tele-clu-03 kernel:  apic_timer_interrupt+0xf/0x20
Mar 04 15:51:39 tele-clu-03 kernel:  
Mar 04 15:51:39 tele-clu-03 kernel: RIP: 0033:0x7f50dcabd77a
Mar 04 15:51:39 tele-clu-03 kernel: Code: ff 0f 1f 80 00 00 00 00 0f b6 74 24 
13 48 39 cd 0f 85 e2 fe ff ff eb db 0f 1f 84 00 00 00 00 00 48 b9 ff ff ff ff 
ff ff ff 7f <48> 63 54 24 14 48 01 ca 48 39 c2 0f 82 14 ff ff ff 8b 4c 24 14 48
Mar 04 15:51:39 tele-clu-03 kernel: RSP: 002b:7ffd49e5db10 EFLAGS: 0246 
ORIG_RAX: ff13
Mar 04 15:51:39 tele-clu-03 kernel: RAX: 017f RBX:  
RCX: 7fff
Mar 04 15:51:39 tele-clu-03 kernel: RDX: 000a RSI:  
RDI: 558bfde5b2b6
Mar 04 15:51:39 tele-clu-03 kernel: RBP:  R08: 1999 
R09: 
Mar 04 15:51:39 tele-clu-03 kernel: R10: 7f50dcbecac0 R11: 7f50dcbed3c0 
R12: 
Mar 04 15:51:39 tele-clu-03 kernel: R13: 558bfde5b2b3 R14:  
R15: 000a
Mar 04 15:51:39 tele-clu-03 kernel: ---[ end trace c38142171e4748bf ]---


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: FUJITSU
product_name: FUTRO S700
product_version:
chassis_vendor: FUJITSU
chassis_version:
bios_vendor: FUJITSU // American Megatrends Inc.
bios_version: V4.6.

Bug#953115: libsixel: Please package the latest upstream version (1.8.6)

2020-03-04 Thread Boyuan Yang
Source: libsixel
Version: 1.8.2-2.1
Severity: important
X-Debbugs-CC: k...@debian.org

Dear package libsixel maintainer in Debian,

The libsixel upstream has released new version (1.8.6). Please consider
packaging it in Debian.

-- 
Thanks,
Boyuan Yang


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


Bug#931347: ITP: lsp-plugins -- LSP (Linux Studio Plugins)

2020-03-04 Thread Dennis Braun
owner 931347 !

* Package name    : lsp-plugins
  Version : 1.1.13

Adapted the package for debian.

https://salsa.debian.org/multimedia-team/lsp-plugins



signature.asc
Description: OpenPGP digital signature


Bug#950385: lintian: Crash error on lintian

2020-03-04 Thread Felix Lechner
Hi,

On Fri, Jan 31, 2020 at 2:03 PM Niels Thykier  wrote:
>
> tar: nexuiz-data-2.5.2/misc: Cannot mkdir: No space left on device

The foregoing may be a better title for the bug. Also, the bug may
relate to lintian.d.o rather than Lintian proper.

> Filehandle STDOUT reopened as $_[...] only for input at (eval 143) line 149.
> print() on closed filehandle STDOUT at 
> /srv/lintian.debian.org/lintian/lib/Lintian/Output.pm line 354.

The file handle may have been closed automatically for lack of memory.
That would make the warning a consequence, and not a cause, of the
out-of space error.

Similar warnings sometimes occur due to an old Perl bug
(https://github.com/Perl/perl5/issues/3905) but I think the warnings
here are genuine.

Kind regards

Felix Lechner



Bug#953113: /sbin/sysctl: man page for sysctl is ambiguous

2020-03-04 Thread tkoeck
Package: procps
Version: 2:3.3.15-2
Severity: normal
File: /sbin/sysctl

Dear Maintainer,

you wrote in the 'man sysctl' for the -w option

  -w, --write
  Use this option when all arguments prescribe a key to be set.

but it's also possible to write the key without it

E.g.

sysctl kernel.domainname="example.com"

What is the function of the '-w' option? Is it optional?
The man page seems to be a little bit ambiguous.

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

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

Versions of packages procps depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libncurses6  6.1+20181013-2+deb10u2
ii  libncursesw6 6.1+20181013-2+deb10u2
ii  libprocps7   2:3.3.15-2
ii  libtinfo66.1+20181013-2+deb10u2
ii  lsb-base 10.2019051400

Versions of packages procps recommends:
ii  psmisc  23.2-1

procps suggests no packages.

-- no debconf information



Bug#940708: [Pkg-javascript-devel] Bug#940708: Bug#940708: acorn: please revisit your versioning strategy before making a sid upload

2020-03-04 Thread Mattia Rizzolo
On Wed, Mar 04, 2020 at 11:06:00PM +0530, Pirate Praveen wrote:
> That is not correct. Xavier (yadd) proposed 3 solutions already. Hope he will 
> share the relevant proposals.

Yes, the current one was proposed by him, as well as the one I linked
below…
I'm actually defending his work here :P

-- 
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#953112: xfwm4: Title bar text with Daloa theme vertically off center and partially invisible

2020-03-04 Thread marek
Package: xfwm4
Version: 4.14.0-2
Severity: normal

Title bar text with Daloa theme is vertically off center and partially
invisible.
When I open Settings / Window Manager / Style and change Theme to Default and
back to Daloa, title bar text becomes correctly aligned and fully visible. But
the problem re-appears after logout and login again.
The problem starts manifesting itself when I updated XFCE4 12.5 to 14.

Removed the following packages:
xfce4-goodies
xfce4-sensors-plugin

Upgraded the following packages:
libcolord2 (1.3.3-2) to 1.4.3-4
libgarcon-1-0 (0.4.0-2) to 0.6.4-1
libxfce4panel-2.0-4 (4.12.1-2) to 4.14.3-1
libxfce4ui-utils (4.12.1-2) to 4.14.1-1+b1
lightdm (1.26.0-3) to 1.26.0-7
lightdm-gtk-greeter (2.0.2-1) to 2.0.7-1
thunar (1.6.14-1) to 1.8.12-1
thunar-data (1.6.14-1) to 1.8.12-1
xfce4 (4.12.5) to 4.14
xfce4-appfinder (4.12.0-2) to 4.14.0-1+b1
xfce4-cpufreq-plugin (1.1.3-1) to 1.2.1-1
xfce4-cpugraph-plugin (1.0.5-1+b1) to 1.1.0-1
xfce4-dict (0.7.2-1) to 0.8.3-1
xfce4-diskperf-plugin (2.5.5-1+b1) to 2.6.2-1
xfce4-fsguard-plugin (1.0.2-1+b1) to 1.1.1-1
xfce4-genmon-plugin (3.4.0-2+b1) to 4.0.2-1
xfce4-mailwatch-plugin (1.2.0-2+b2) to 1.2.0-3+b1
xfce4-netload-plugin (1.2.4-2) to 1.3.2-1
xfce4-notes-plugin (1.8.1-1) to 1.8.1-3
xfce4-panel (4.12.1-2) to 4.14.3-1
xfce4-places-plugin (1.7.0-3) to 1.8.1-1
xfce4-session (4.12.1-5) to 4.14.1-1
xfce4-settings (4.12.1-1) to 4.14.2-1
xfce4-smartbookmark-plugin (0.4.6-2) to 0.5.1-1
xfce4-systemload-plugin (1.1.2-1+b1) to 1.2.3-1
xfce4-timer-plugin (1.6.0-1+b1) to 1.7.0-1
xfce4-verve-plugin (1.1.0-1) to 2.0.0-1
xfce4-weather-plugin (0.8.9-1) to 0.10.0-1
xfce4-whiskermenu-plugin (1.6.2-1) to 2.3.5-1
xfce4-xkb-plugin (1:0.7.1-2+b1) to 1:0.8.1-2+b1
xfconf (4.12.1-1) to 4.14.1-1
xfdesktop4 (4.12.3-4) to 4.14.2-1
xfdesktop4-data (4.12.3-4) to 4.14.2-1
xfwm4 (4.12.4-1) to 4.14.0-2
firmware-amd-graphics (20180825+dfsg-1) to 20190717-2
firmware-iwlwifi (20170823-1) to 20190717-2
firmware-linux (20180825+dfsg-1) to 20190717-2
firmware-linux-free (3.4) to 20200122-1
firmware-linux-nonfree (20180825+dfsg-1) to 20190717-2
firmware-misc-nonfree (20180825+dfsg-1) to 20190717-2
intel-microcode (3.20170707.1) to 3.20191115.2
libvte-2.91-0 (0.46.1-1) to 0.58.3-1
libvte-2.91-common (0.46.1-1) to 0.58.3-1
libxfce4util-bin (4.12.1-3) to 4.14.0-1
libxfce4util7 (4.12.1-3) to 4.14.0-1
orage (4.12.1-3) to 4.12.1-7
xfce4-battery-plugin (1.1.0-1) to 1.1.3-1
xfce4-clipman (2:1.4.1-1) to 2:1.4.3-2
xfce4-clipman-plugin (2:1.4.1-1) to 2:1.4.3-2
xfce4-datetime-plugin (0.7.0-1) to 0.8.0-1
xfce4-notes (1.8.1-1) to 1.8.1-3
xfce4-notifyd (0.3.6-1) to 0.4.4-1+b1
xfce4-pulseaudio-plugin (0.2.4-2) to 0.4.2-1
xfce4-screenshooter (1.8.2-2) to 1.9.7-1
xfce4-taskmanager (1.1.0-1) to 1.2.2-1
xfce4-terminal (0.8.4-1) to 0.8.9.1-1
xfce4-wavelan-plugin (0.6.0-1) to 0.6.1-1
compton (0.1~beta2+20150922-1) to 0.1~beta2+20150922-1+b1


Installed the following packages:
libexo-2-0 (0.12.11-1)
libgarcon-gtk3-1-0 (0.6.4-1)
libindicator3-7 (0.5.0-4)
libthunarx-3-0 (1.8.12-1)
libxnvctrl0 (440.59-1)
libxpresent1 (1.0.0-2+b10)
libical3 (3.0.7-2)
libqrencode4 (4.0.2-2)
orage-data (4.12.1-7)



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

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

Versions of packages xfwm4 depends on:
ii  libc6 2.29-2
ii  libcairo2 1.15.10-1
ii  libepoxy0 1.4.3-1
ii  libgdk-pixbuf2.0-02.36.11-1
ii  libglib2.0-0  2.62.2-3
ii  libgtk-3-03.24.4-1
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libstartup-notification0  0.12-5
ii  libwnck-3-0   3.20.1-3
ii  libx11-6  2:1.6.4-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfce4ui-2-04.14.1-1+b1
ii  libxfce4util7 4.14.0-1
ii  libxfconf-0-3 4.14.1-1
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxinerama1  2:1.1.3-1+b3
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1

Versions of packages xfwm4 recommends:
ii  librsvg2-common  2.40.20-2

Versions of packages xfwm4 suggests:
ii  xfce4  4.14

-- no debconf information


Bug#953048: [Pkg-sass-devel] Bug#953048: ruby-sass: sass --watch does not work

2020-03-04 Thread Jonas Smedegaard
Quoting Werner Joss (2020-03-04 18:35:46)
> may I propose to just remove the --watch option When it does not work 
> anyway ?

Excellent suggestion. Thanks!

> Would be better than a crash, IMHO ;)

Certainly (and silly that I didn't think of that when I did the patch).

It is however unlikely that such change find its way into stable Debian, 
and for testing/unstable debian it is quite likely that the package will 
get removed instead of improved due to the lack of upstream maintenance.


> And yes, I already thought about writing a script using sass or sassc 
> together with some filesystem-watch tool, as you proposed, but 
> fortunately there is also pyscss: 
> https://pythonhosted.org/scss/#python-scss Which has this watch 
> feature and gets the job done.

Good that you found a working alternative.  And now it is on record, for 
others finding themselves in similar situation.  Thanks for sharing!


 - Jonas

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

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

signature.asc
Description: signature


Bug#952718: Limitation in clang's code

2020-03-04 Thread Lisandro Damián Nicanor Pérez Meyer
tag 952718 wontfix
severity 952718 wishlist
thanks

Hi!

According to the upstream bug this is a limitaion of using clang for the code
model, as it can't parse gcc's headers.

Forcing a dependency on clang headers means that Creator would be showing a
different header than the one really used at compile time. This is problematic,
as they might differ. As an example I use Creator for microcontrollers which
might have very different definitions.

It's not up to the package maintainers to tape over upstream limitations/bugs,
and showing by default a wrong header is definitely not the right solution.

I am so lowering the severity to wishlist and marking it as wontfix, as upstream
does not seems to have plans to solve this issue, which is totally 
understandable.



Bug#953048: [Pkg-sass-devel] Bug#953048: ruby-sass: sass --watch does not work

2020-03-04 Thread Werner Joss
Am Mittwoch, 4. März 2020, 17:48:05 CET schrieb Jonas Smedegaard:
> I deliberately wrote "should" because it is outside Debian: I don't 
> really know if and how it might maybe perhaps work and if so then for 
> how long before it maybe perhaps crashes in weird ways.
> 
> I know about Debian, and I chose to avoid that feature because it became 
> difficult to package for Debian and I considered it a low-priority 
> feature (read: I found it more important to ship sass wihtout that 
> feature than to not ship sass at all with Debian).
> 
> Beware: Ruby-based sass is dead upstream.  I recommend to use sassc 
> instead.
> 
> For the --watch feature, I suggest you consider generic tools like 
> fswatch inotify-tools iwatch

Ok, Jonas,
That makes things a little more clear for me - may I propose to just remove the 
--watch option
When it does not work anyway ?
Would be better than a crash, IMHO ;)
And yes, I already thought about writing a script using sass or sassc together 
with some filesystem-watch tool,
as you proposed, but fortunately there is also pyscss: 
https://pythonhosted.org/scss/#python-scss
Which has this watch feature and gets the job done.

Kind regards
Werner



Bug#953111: pacemaker: post-start got lost

2020-03-04 Thread Lukas Straub
Package: pacemaker
Version: 2.0.3-3
Severity: normal

Dear Maintainer,
I have a master-slave resource which relies on the post-start notification to 
start replication
to the slave. This works well, but every now and then the post-start 
notification isn't sent.

Note the line
 Discarding attempt to perform action notify on colo_test in state S_INTEGRATION
below.

Mar 04 16:28:50 tele-clu-03 python[8351]: (colo_test) DEBUG: notify called: 
action: pre-start, master_uname: tele-clu-03, start_uname: tele-clu-02, 
stop_uname: tele-clu-01, shutdown_guest: False
Mar 04 16:28:50 tele-clu-03 pacemaker-controld[538]:  notice: Result of notify 
operation for colo_test on tele-clu-03: 0 (ok)
Mar 04 16:28:50 tele-clu-03 pacemaker-controld[538]:  notice: Initiating start 
operation colo_test_start_0 on tele-clu-02
Mar 04 16:28:54 tele-clu-03 corosync[481]:   [KNET  ] rx: host: 1 link: 0 is up
Mar 04 16:28:54 tele-clu-03 corosync[481]:   [KNET  ] host: host: 1 (passive) 
best link: 0 (pri: 0)
Mar 04 16:28:54 tele-clu-03 corosync[481]:   [TOTEM ] A new membership (1.1cc0) 
was formed. Members joined: 1
Mar 04 16:28:54 tele-clu-03 corosync[481]:   [CPG   ] downlist left_list: 0 
received
Mar 04 16:28:54 tele-clu-03 corosync[481]:   [CPG   ] downlist left_list: 0 
received
Mar 04 16:28:54 tele-clu-03 corosync[481]:   [CPG   ] downlist left_list: 0 
received
Mar 04 16:28:55 tele-clu-03 corosync[481]:   [QUORUM] Members[3]: 1 2 3
Mar 04 16:28:55 tele-clu-03 corosync[481]:   [MAIN  ] Completed service 
synchronization, ready to provide service.
Mar 04 16:28:55 tele-clu-03 pacemaker-controld[538]:  notice: Node tele-clu-01 
state is now member
Mar 04 16:28:55 tele-clu-03 pacemakerd[532]:  notice: Node tele-clu-01 state is 
now member
Mar 04 16:28:55 tele-clu-03 pacemaker-based[533]:  notice: Node tele-clu-01 
state is now member
Mar 04 16:28:55 tele-clu-03 pacemaker-attrd[536]:  notice: Node tele-clu-01 
state is now member
Mar 04 16:28:55 tele-clu-03 pacemaker-attrd[536]:  notice: Setting 
#attrd-protocol[tele-clu-01]: (unset) -> 2
Mar 04 16:28:55 tele-clu-03 pacemaker-fenced[534]:  notice: Node tele-clu-01 
state is now member
Mar 04 16:28:55 tele-clu-03 pacemaker-controld[538]:  notice: Transition 12 
aborted: Peer Halt
Mar 04 16:28:55 tele-clu-03 pacemaker-controld[538]:  notice: Initiating notify 
operation colo_test_post_notify_start_0 locally on tele-clu-03
Mar 04 16:28:55 tele-clu-03 pacemaker-controld[538]:  notice: Discarding 
attempt to perform action notify on colo_test in state S_INTEGRATION 
(shutdown=false)
Mar 04 16:28:55 tele-clu-03 pacemaker-controld[538]:  notice: Initiating notify 
operation colo_test_post_notify_start_0 on tele-clu-02
Mar 04 16:28:55 tele-clu-03 pacemaker-controld[538]:  notice: Transition 12 
(Complete=22, Pending=0, Fired=0, Skipped=1, Incomplete=1, 
Source=/var/lib/pacemaker/pengine/pe-warn-93.bz2): Stopped
Mar 04 16:28:57 tele-clu-03 pacemaker-schedulerd[537]:  notice: Watchdog will 
be used via SBD if fencing is required and stonith-watchdog-timeout is nonzero
Mar 04 16:28:57 tele-clu-03 pacemaker-schedulerd[537]:  notice: Calculated 
transition 13, saving inputs in /var/lib/pacemaker/pengine/pe-input-1569.bz2
Mar 04 16:28:57 tele-clu-03 pacemaker-controld[538]:  notice: Initiating 
monitor operation colo_test_monitor_0 on tele-clu-01
Mar 04 16:28:57 tele-clu-03 pacemaker-controld[538]:  notice: Initiating 
monitor operation colo_test_monitor_1 on tele-clu-02
Mar 04 16:28:58 tele-clu-03 pacemaker-controld[538]:  notice: Initiating 
monitor operation colo_small_test_monitor_0 on tele-clu-01
Mar 04 16:28:58 tele-clu-03 pacemaker-controld[538]:  notice: Transition 13 
(Complete=3, Pending=0, Fired=0, Skipped=0, Incomplete=0, 
Source=/var/lib/pacemaker/pengine/pe-input-1569.bz2): Complete
Mar 04 16:28:58 tele-clu-03 pacemaker-controld[538]:  notice: State transition 
S_TRANSITION_ENGINE -> S_IDLE
Mar 04 16:29:08 tele-clu-03 pacemaker-controld[538]:  notice: High CPU load 
detected: 2.75

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

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

Versions of packages pacemaker depends on:
ii  corosync   3.0.2-1+b1
ii  dbus   1.12.16-2
ii  init-system-helpers1.57
ii  libc6  2.29-10
ii  libcfg73.0.2-1+b1
ii  libcib27   2.0.3-3
ii  libcmap4   3.0.2-1+b1
ii  libcorosync-common43.0.2-1+b1
ii  libcrmcluster292.0.3-3
ii  libcrmcommon34 2.0.3-3
ii  libcrmservice282.0.3-3
ii  libglib2.0-0   2.62.5-1
ii  libgnutls303.6.12-2
ii  liblrmd28  2.0.3-3
ii  libpacemaker1

Bug#940708: [Pkg-javascript-devel] Bug#940708: Bug#940708: acorn: please revisit your versioning strategy before making a sid upload

2020-03-04 Thread Pirate Praveen



On 2020, മാർച്ച് 4 10:40:30 PM IST, Mattia Rizzolo  wrote:
>*Many* have complained about the version string, but nobody has come up
>with a saner way to
> * track what is bundled inside a source package
> * the versions of those things
>* automatically look up whether there are updates to any of those
>things

That is not correct. Xavier (yadd) proposed 3 solutions already. Hope he will 
share the relevant proposals.

>when the bundled bits come from different sources, with different
>release schedules, etc.
>Note that uscan's integration into much of the Debian infrastructure is
>relevant here.
>A new approach _could_ be this, that I have yet to evaluate though:
>https://salsa.debian.org/debian/devscripts/-/merge_requests/156
>
>The current version string is totally horrible and might be hard on
>humans, but otherwise accomplishes the above.
>
>
>
>If something you use is broken by it, please mention what it is.
>
>
>BTW, this bit of the OP:
>> It's not useful from a dependency point-of-view,
>> because a dependent package cannot specify a dependency on only the
>> component they care about, so they would have to include the versions
>of
>> the packages they don't care about too.
>
>it's not true: versioned provides are in place, and indeed nobody
>should
>depend on "node-debbundle-acorn".

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Bug#953110: libmpdclient2: broken request when size exceeds 4096 bytes

2020-03-04 Thread Damyan Ivanov
Package: libmpdclient2
Version: 2.16-1
Severity: normal
Tags: upstream

Control: found -1 2.18-1

Reproducer:

Uses mpc to send a 'find' request, containing an invalid search expression. The 
expected result is an error message about the invalid search expression.

working:

 $ strace -s 40 -e trace=sendto,recvfrom mpc find '('$(for i in $(seq 1 4086); 
do echo -n "+"; done)')'
 recvfrom(3, "OK MPD 0.21.4\n", 4096, MSG_DONTWAIT, NULL, NULL) = 14
 sendto(3, "find \"(+"..., 4096, MSG_DONTWAIT, 
NULL, 0) = 4096
 recvfrom(3, "ACK [2@0] {find} Word expected\n", 4096, MSG_DONTWAIT, NULL, 
NULL) = 31
 mpd error: Word expected
 +++ exited with 1 +++

Note the request size on line 3: 4096 bytes.

broken:

The only difference is one more '+' in the expression, which would result in a 
request of 4097 bytes.

 $ strace -s 40 -e trace=sendto,recvfrom mpc find '('$(for i in $(seq 1 4087); 
do echo -n "+"; done)')'
 recvfrom(3, "OK MPD 0.21.4\n", 4096, MSG_DONTWAIT, NULL, NULL) = 14
 mpd error: Timeout
 +++ exited with 1 +++

Instead of error about the invalid request, a timeout occurs after 30 seconds 
because the request is not really sent (note the missing sendto() call).

Ideally, libmpdclient should support requests of arbitrary size (eventually 
reaching the server limit), but if that is not feasible, at least a proper 
error reporting would be nice.

Thanks for taking care of mpd software in Debian.


Cheers,
dam

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

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

Versions of packages libmpdclient2 depends on:
ii  libc6  2.29-3

libmpdclient2 recommends no packages.

libmpdclient2 suggests no packages.

-- no debconf information



Bug#950655: #950655: buster-pu: package rubygems-integration/1.11+deb10u1

2020-03-04 Thread Antonio Terceiro
On Tue, Feb 04, 2020 at 02:44:28PM +0100, Antonio Terceiro wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hello,
> 
> This update is part of a collaboration with upstream on their handling
> of deprecations in the rubygems codebase. See
> https://github.com/rubygems/rubygems/issues/3068 and the thread starting
> at https://lists.debian.org/debian-ruby/2020/01/msg00015.html for
> context.
> 
> In short: going forward, they want to only deprecate code on rubygems on
> new releases of the ruby interpreter (~ once a year). But for this time,
> there was a release where these warnings reached end users.
> 
> This is fixed by this update (patch attached). As you can see the patch
> is pretty simple and harmless.

> diff --git a/debian/changelog b/debian/changelog
> index 272a6dc..b2d099a 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,9 @@
> +rubygems-integration (1.11+deb10u1) buster; urgency=medium
> +
> +  * Replace usage of Gem::ConfigMap with RbConfig::CONFIG
> +
> + -- Antonio Terceiro   Tue, 04 Feb 2020 14:11:57 +0100
> +
>  rubygems-integration (1.11) unstable; urgency=medium
>  
>[ Cédric Boutillier ]
> diff --git a/lib/rubygems/defaults/operating_system.rb 
> b/lib/rubygems/defaults/operating_system.rb
> index 461cfe4..f68f029 100644
> --- a/lib/rubygems/defaults/operating_system.rb
> +++ b/lib/rubygems/defaults/operating_system.rb
> @@ -7,7 +7,7 @@ class << Gem
>  
>alias :upstream_default_dir :default_dir
>def default_dir
> -File.join('/', 'var', 'lib', 'gems', Gem::ConfigMap[:ruby_version])
> +File.join('/', 'var', 'lib', 'gems', RbConfig::CONFIG["ruby_version"])
>end
>  
>alias :upstream_default_bindir :default_bindir
> @@ -26,8 +26,8 @@ class << Gem
>extra_path = File.join('/usr/share/rubygems-integration', '2.2')
>  end
>  
> -arch = Gem::ConfigMap[:arch]
> -api_version = Gem::ConfigMap[:ruby_version]
> +arch = RbConfig::CONFIG["arch"]
> +api_version = RbConfig::CONFIG["ruby_version"]
>  
>  upstream_default_path + [
>"/usr/lib/#{arch}/rubygems-integration/#{api_version}",

ping


signature.asc
Description: PGP signature


Bug#947685: linux-image-5.4.0-1-amd64: NETDEV WATCHDOG: enp5s0f1 (r8169): transmit queue 0 timed out

2020-03-04 Thread Vincas Dargis

Disabling offloading helps as workaround, see:
https://lore.kernel.org/netdev/81548409-2fd3-9645-eeaf-ab8f7789b...@gmail.com/



Bug#906259: ITP: smartparens -- auto insertion, wrapping, and navigation of ()s, delimiters, and tags for Emacs

2020-03-04 Thread Nicholas D Steeves
Update: I am pursuing an NMU for #951973 (RC) and plan to also unblock this
bug by solving #921328 in the same upload.

Other than this, I'm waiting for confirmation from upstream about which
scala-mode variant is needed
  https://github.com/Fuco1/smartparens/issues/1011

--N


Bug#932062: remmina: Raspberry Pi, Two Monitors, icons on LHS of Windows window to move right off in the RDP window

2020-03-04 Thread Matteo F. Vescovi
Hi!

On Sun, Jul 14, 2019 at 5:45 PM Duncan  wrote:
>
> Package: remmina
> Version: 1.3.3+dfsg-2
> Severity: important
>
> Dear Maintainer,
[...]

Can you please test the new release as explained in the following link:

https://gitlab.com/Remmina/Remmina/-/wikis/home#raspberry-pi

Then let me know if the issue has been resolved.

Thanks in advance.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A



Bug#953099: lintian: FPOS for pkg-config-references-unknown-shared-library

2020-03-04 Thread Felix Lechner
Hi,

On Wed, Mar 4, 2020 at 5:33 AM Mattia Rizzolo  wrote:
>
> xml2 is clearly a direct dependency of libxslt1-dev, and 'libxml2.so' is
> shipped by libxml2-dev which is a direct dependency of libxslt1-dev

The way I understand pkg-config, the libraries listed do not have to
be direct prerequisites (i.e. the extra math library of old, -lm).
Lintian cannot test for all prerequisites without unpacking all build
requirements and, in effect, attempting a build.

I would like to remove this tag from Lintian.

Kind regards
Felix Lechner



Bug#940708: [Pkg-javascript-devel] Bug#940708: acorn: please revisit your versioning strategy before making a sid upload

2020-03-04 Thread Mattia Rizzolo
On Wed, Mar 04, 2020 at 04:37:47PM +, Dimitri John Ledkov wrote:
> And if a saner/shorter version number is not possible, maybe Debian
> does not deserve to ship acorn at all.

*Many* have complained about the version string, but nobody has come up
with a saner way to
 * track what is bundled inside a source package
 * the versions of those things
 * automatically look up whether there are updates to any of those things

when the bundled bits come from different sources, with different
release schedules, etc.
Note that uscan's integration into much of the Debian infrastructure is
relevant here.
A new approach _could_ be this, that I have yet to evaluate though:
https://salsa.debian.org/debian/devscripts/-/merge_requests/156

The current version string is totally horrible and might be hard on
humans, but otherwise accomplishes the above.



If something you use is broken by it, please mention what it is.


BTW, this bit of the OP:
> It's not useful from a dependency point-of-view,
> because a dependent package cannot specify a dependency on only the
> component they care about, so they would have to include the versions of
> the packages they don't care about too.

it's not true: versioned provides are in place, and indeed nobody should
depend on "node-debbundle-acorn".

-- 
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#932345: profile-sync-daemon: Debian specific error "I require modinfo but it's not installed"

2020-03-04 Thread Shengjing Zhu
Package: profile-sync-daemon
Version: 6.34-1
Followup-For: Bug #932345
User: m...@linux.it
Usertags: usrmerge

Hi,

This happens in is usr-merged system.

in /usr/bin/profile-sync-daemon

```
# needed for debian 8.x
[[ -h /sbin ]] || PATH=$PATH:/sbin
```

The fisrt test is failed, since /sbin is a symlink to /usr/sbin.
Thus the PATH doesn't contain sbin.

I think just adding following line could fix the problem.

```
[[ -h /usr/sbin ]] || PATH=$PATH:/usr/sbin
```

Thanks



Bug#953109: Recommend [check-valid-until=no] by default

2020-03-04 Thread chrysn
Package: snapshot.debian.org
Severity: minor
Tags: patch

With the last unsupporting version being oldoldstable,
[check-valid-until=no] should be in the sources.list line everyone[1]
copies over.

I've pushed a version with a suggested fix to
https://salsa.debian.org/chrysn-guest/snapshot/-/tree/default-check-valid-until
for easy merging, or attached as a patch if that better suites your
workflow.

[1] Well, I do. Just spent yet another run of changing / etckeeper
committing / apt update where I should really have known but mindlessly
copy-pasted anyway.

-- 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.6.0-rc2 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
From 1264f8c9f59edb67bac0cd3d8dc237472b9e8b93 Mon Sep 17 00:00:00 2001
From: chrysn 
Date: Wed, 4 Mar 2020 17:47:30 +0100
Subject: [PATCH] Advertise [check-valid-until=no] by default

With all recent Debian versions supporting it, the recommendation can go
into what is most commonly copy-pasted, with just a note on older
versions.
---
 web/app/snapshot/templates/description.mako | 28 -
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/web/app/snapshot/templates/description.mako b/web/app/snapshot/templates/description.mako
index 294fb32..12513b0 100644
--- a/web/app/snapshot/templates/description.mako
+++ b/web/app/snapshot/templates/description.mako
@@ -54,10 +54,10 @@ If you want to add a specific date's archive to your apt sources.list
 
-deb https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
-deb-src https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
-deb https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
-deb-src https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
+deb [check-valid-until=no] https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
+deb-src [check-valid-until=no] https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
+deb [check-valid-until=no] https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
+deb-src [check-valid-until=no] https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
 
 
 To access snapshots using https, you need to install the ca-certificates
@@ -73,21 +73,13 @@ is no import at the exact time you specified you will get the latest
 available timestamp which is before the time you specified.
 
 
-To access snapshots of suites using Valid-Until that are older than a dozen days,
-it is necessary to ignore the Valid-Until header within Release files, in order
-to prevent apt from disregarding snapshot entries ("Release file expired").  Use
-aptitude -o Acquire::Check-Valid-Until=false update or
-apt-get -o Acquire::Check-Valid-Until=false update for this purpose.
-
-
-If you use at least apt version 1.1.exp9 (stretch and later), you can use this instead:
+The [check-valid-until=no] option is necessary to access suites
+older than a dozen days, as their Valid-Until header has expired.
+If you use apt versions before 1.1.exp9 (jessie and older), you have to elide
+the option and use aptitude -o Acquire::Check-Valid-Until=false
+update or apt-get -o Acquire::Check-Valid-Until=false
+update instead.
 
-
-deb [check-valid-until=no] https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
-deb-src [check-valid-until=no] https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
-deb [check-valid-until=no] https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
-deb-src [check-valid-until=no] https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
-
 
 
 If you want anything related to a specific package simply enter the
-- 
2.25.1



signature.asc
Description: PGP signature


Bug#953048: [Pkg-sass-devel] Bug#953048: ruby-sass: sass --watch does not work

2020-03-04 Thread Jonas Smedegaard
Quoting Werner Joss (2020-03-04 16:18:15)
> Am Dienstag, 3. März 2020, 21:38:00 CET schrieb Jonas Smedegaard:
> > Quoting Werner Joss (2020-03-03 20:46:47)
> > > sass --watcg does not work - I get the following errors:
> > 
> > You are right, that feature has been omitted from the Debian 
> > packaging of ruby-sass.  It should work if you install the Python 
> > module sass-watch locally.
> 
> But unfortunately, I can't find any package with this name (via 
> aptitude and pip/pip3) - installed pysass and python-libsass instead 
> but no change.

I deliberately wrote "should" because it is outside Debian: I don't 
really know if and how it might maybe perhaps work and if so then for 
how long before it maybe perhaps crashes in weird ways.

I know about Debian, and I chose to avoid that feature because it became 
difficult to package for Debian and I considered it a low-priority 
feature (read: I found it more important to ship sass wihtout that 
feature than to not ship sass at all with Debian).

Beware: Ruby-based sass is dead upstream.  I recommend to use sassc 
instead.

For the --watch feature, I suggest you consider generic tools like 
fswatch inotify-tools iwatch


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature


Bug#953108: glibc: CVE-2020-10029

2020-03-04 Thread Salvatore Bonaccorso
Source: glibc
Version: 2.29-10
Severity: important
Tags: security upstream
Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=25487

Hi,

The following vulnerability was published for glibc.

CVE-2020-10029[0]:
| The GNU C Library (aka glibc or libc6) before 2.32 could overflow an
| on-stack buffer during range reduction if an input to an 80-bit long
| double function contains a non-canonical bit pattern, a seen when
| passing a 0x5d41414141414141 value to sinl on x86 targets. This is
| related to sysdeps/ieee754/ldbl-96/e_rem_pio2l.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-10029
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10029
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=25487

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#940708: acorn: please revisit your versioning strategy before making a sid upload

2020-03-04 Thread Dimitri John Ledkov
On Thu, 19 Sep 2019 10:48:34 +0100 Jonathan Dowland  wrote:
>
> 
> 6.2.1+ds+~0.4.0+~4.0.0+really4.0.0+~1.0.0+~5.0.1+ds+~1.7.0+ds+~0.1.1+~0.3.1+~0.2.0+~0.1.0+~0.3.0+~0.3.0-5
>

And if a saner/shorter version number is not possible, maybe Debian
does not deserve to ship acorn at all.

Regards,

Dimitri.



  1   2   >