Bug#929729: Test package ships invalid md5sums
* 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
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!"
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
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
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
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
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
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
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 ?
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=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
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
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
> 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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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 ( 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Bug#953099: lintian: FPOS for pkg-config-references-unknown-shared-library
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
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
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
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
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
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
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
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ß
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
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
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)
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
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)
> 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
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
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:
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
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
> 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
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.
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
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:
Bug#953115: libsixel: Please package the latest upstream version (1.8.6)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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.
