Bug#899165: fixed in git
tag 900331 + pending tag 899165 + pending tag 899178 + pending thanks These bugs are fixed in git, tagging them as pending. Regards, Daniel
Bug#900298: needrestart: Needrestart false positive detect need to reboot due to microcode update
tags 900298 upstream thanks Hi, this might be related to issue #112[1]. While scanning for ucode updates using the iucode_tool for the running system it does report updates which are *not* applicable. This might be a bug or a inaccuracy description of the --scan--system option of iucode_tool. Needrestart 3.2 (not released, yet) contains a fix to workaround this issue. [1] https://github.com/liske/needrestart/issues/112 Could you give upstream's most recent iucode-scan-versions[2] scripts a try? It should report a single ucode revision. You might just run it as root (optionally add '1' as parameter to make it more verbose) and compare it with the output of your local /usr/lib/needrestart/iucode-scan-versions. [2] https://github.com/liske/needrestart/blob/master/lib/iucode-scan-versions Regards, Thomas Paul Wise writes: > Control: retitle -1 needrestart: microcode: false positives, select expected > version based on sig/pf/pf_mask > > On Mon, 28 May 2018 19:09:54 +0200 Francois Mescam wrote: > >> The currently running processor microcode revision is 0x712 which is >> not the expected microcode revision 0xe09. > ... >> /usr/sbin/iucode_tool: system has processor(s) with signature 0x00050663 > ... >> 001/001: sig 0x00050662, pf_mask 0x10, 2018-01-22, rev 0x0015, size 31744 >> 001/002: sig 0x00050663, pf_mask 0x10, 2018-01-22, rev 0x712, size >> 22528 >> 001/003: sig 0x00050664, pf_mask 0x10, 2018-01-22, rev 0xf11, size >> 22528 >> 001/004: sig 0x00050665, pf_mask 0x10, 2018-01-22, rev 0xe09, size >> 18432 > > The issue here appears to be that needrestart isn't matching the list > of available microcode versions against the CPU's sig value. > > In addition, on the #debian-next IRC channel, a Debian user discovered > a system where there were multiple microcode revisions available for > the processor sig and the one that was loaded was the one where the > processor flags (pf) value (from dmesg and sysfs) bitwise ANDed with > the microcode pf_mask value resulted in a non-zero value. > > $ sudo sort -u /sys/devices/system/cpu/cpu*/microcode/processor_flags > 0x2 > > $ sudo dmesg | grep pf= > [1.103617] microcode: sig=0x106e5, pf=0x2, revision=0x8 > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise -- :: WWW:https://fiasko-nw.net/~thomas/ :: ::: Jabber: xmpp:tho...@jabber.fiasko-nw.net ::: :: flickr: https://www.flickr.com/photos/laugufe/ ::
Bug#866440: NMU for mcomix RC bug
Hi Krzysztof and Emfox,
#866440 has been an RC bug on mcomix for some months, and it is no longer
installable in unstable; I've uploaded a NMU to DELAYED/5 with the attached
patch. Please let me know if you'd like me to cancel that upload.
--
Nicholas Breen
nbr...@debian.org
diff -Nru mcomix-1.2.1/debian/changelog mcomix-1.2.1/debian/changelog
--- mcomix-1.2.1/debian/changelog 2016-02-20 23:35:20.0 -0800
+++ mcomix-1.2.1/debian/changelog 2018-05-29 21:35:28.0 -0700
@@ -1,3 +1,10 @@
+mcomix (1.2.1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Replace Depends: python-imaging with python-pil. (Closes: #866440)
+
+ -- Nicholas Breen Tue, 29 May 2018 21:35:28 -0700
+
mcomix (1.2.1-1) unstable; urgency=low
* New upstream release (Closes: #813730, #810743)
diff -Nru mcomix-1.2.1/debian/control mcomix-1.2.1/debian/control
--- mcomix-1.2.1/debian/control 2016-02-20 23:29:23.0 -0800
+++ mcomix-1.2.1/debian/control 2018-05-29 21:35:28.0 -0700
@@ -10,7 +10,7 @@
Package: mcomix
Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, python-gtk2, python-imaging
+Depends: ${misc:Depends}, ${python:Depends}, python-gtk2, python-pil
Suggests: unrar
Description: GTK+ image viewer for comic books
MComix is an user-friendly, customizable image viewer. It is specifically
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Package: nvidia-driver Version: 390.59-1 Followup-For: Bug #900248 Hi, I can confirm that the above workaround works correctly for me. Marc
Bug#781283: libvirt: workaround with clear_emulator_capabilities = 0
Source: libvirt Followup-For: Bug #781283 I have managed to workaround this issue with the following settings in /etc/libvirt/qemu.conf: clear_emulator_capabilities = 0 user = "root" group = "root" This is tested using a KVM virtual machine (Debian Stretch) with the following definintion: and the following /etc/fstab entry share /mnt/share/ 9p rw,nodev,relatime,sync,dirsync,access=client,trans=virtio0 0 I tried a number of different permission settings before disabling clear_emulator_capabilities. However, this was the only way to permit permission changes to files or normal users (apart from root) to own files. I am concerned by the potential security implications of this change as it may expose higher privileges for the guest KVM machines. It would be great if there were a way to support 9pfs passthrough without escalating privilegs using this setting. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (450, 'stable'), (10, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/40 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#890278: scotch: Please add documentation
On Mon, 28 May 2018 20:05:32 +0800 Drew Parsons wrote: > > It fails to build libscotch, I logged a bug upstream at > https://gforge.inria.fr/tracker/index.php?func=detail=21671 > Upstream has fixed it in the new repo at https://gitlab.inria.fr/scotch/scotch Patches pulled to salsa.
Bug#900329: [pkg-apparmor] Bug#900329: apparmor: denials for apt-cacher-ng
On Tue, 2018-05-29 at 17:38 -0700, Seth Arnold wrote: > On Tue, May 29, 2018 at 03:30:06PM +0545, Ritesh Raj Sarraf wrote: > > It is the audit subsystem logging those messages. I remember > > playing > > with it a couple of months ago. Haven't been able to recollect how > > to > > disable it. > > The rules are typically stored in /etc/audit/audit.rules or > /etc/audit/rules.d/ files -- best to edit the rules to match your > desires > and then restart the auditd service. > Hello Seth, THank you for your suggestion. But neither do I have the audit folder nor the auditd.service rrs@priyasi:~$ ls /etc/audit* ls: cannot access '/etc/audit*': No such file or directory 10:30 ♒♒♒☹ => 2 rrs@priyasi:~$ systemctl status auditd.service Unit auditd.service could not be found. 10:31 ♒♒♒☹ => 4 -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#900389: RFS: deepin-screen-recorder/2.7.4-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "deepin-screen-recorder" * Package name: deepin-screen-recorder Version : 2.7.4-1 Upstream Author : Deepin Technology Co., Ttd. * URL : https://github.com/manateelazycat/deepin-screen-recorder * License : GPL-3+ Section : utils It builds those binary packages: deepin-screen-recorder - Simple recorder tools for deepin To access further information about this package, please visit the following URL: https://mentors.debian.net/package/deepin-screen-recorder Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/deepin-screen-recorder/deepin-screen-recorder_2.7.4-1.dsc More information about hello can be obtained from https://salsa.debian.org/pkg-deepin-team/deepin-screen-recorder Changes since the last upload: deepin-screen-recorder (2.7.4-1) unstable; urgency=medium * New upstream release. * d/control: Add new uploader Yanhao Mo . * d/control: Add Build-Depends libprocps6 to work around bug #900239. * d/control: Bump Standards-Version to 4.1.4. (no changes needed) -- Yanhao Mo Wed, 30 May 2018 10:19:10 +0800 -- Yanhao Mo signature.asc Description: PGP signature
Bug#900388: parcimonie: systemd user journal bloat: parcimonie.desktop[]: gpg: key "" not found: Not found
Package: parcimonie Version: 0.10.3-2 Severity: normal File: parcimonie.desktop Usertags: verbose I noticed that parcimonie bloats the systemd user journal with lots of fingerprints of keys that could not be found. On spinning rust with a large keyring this is a significant amount of I/O bandwidth, extra disk space usage and a noticeable amount of journald and rsyslog CPU usage. There is no reason for parcimonie to be logging not found keys, since having keys in one's keyring that are not on the public keyservers is a legitimate use-case that parcimonie users are likely to be doing. The string being output is from GnuPG, so the fix is probably to tell gpg or dirmngr to not output not found keys, or to filter the output. $ journalctl --user --follow May 30 11:55:27 hostname parcimonie.desktop[1234]: gpg: key "0123456789ABCDEF0123456789ABCDEF01234567" not found: Not found May 30 11:55:27 hostname parcimonie.desktop[1234]: gpg: key "0123456789ABCDEF0123456789ABCDEF01234567" not found: Not found May 30 11:55:27 hostname parcimonie.desktop[1234]: gpg: key "0123456789ABCDEF0123456789ABCDEF01234567" not found: Not found May 30 11:55:27 hostname parcimonie.desktop[1234]: gpg: key "0123456789ABCDEF0123456789ABCDEF01234567" not found: Not found May 30 11:55:27 hostname parcimonie.desktop[1234]: gpg: key "0123456789ABCDEF0123456789ABCDEF01234567" not found: Not found May 30 11:55:27 hostname parcimonie.desktop[1234]: gpg: key "FEDCBA9876543210FEDCBA9876543210FEDCBA98" not found: Not found May 30 11:55:27 hostname parcimonie.desktop[1234]: gpg: key "FEDCBA9876543210FEDCBA9876543210FEDCBA98" not found: Not found May 30 11:55:27 hostname parcimonie.desktop[1234]: gpg: key "FEDCBA9876543210FEDCBA9876543210FEDCBA98" not found: Not found May 30 11:55:27 hostname parcimonie.desktop[1234]: gpg: key "FEDCBA9876543210FEDCBA9876543210FEDCBA98" not found: Not found $ strings /usr/bin/gpg | grep -i '^key ".*" not found:' key "%s" not found: %s -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages parcimonie depends on: ii dirmngr 2.2.5-1 ii gnupg2.2.5-1 ii gnupg2 2.2.5-1 ii libclone-perl0.39-1 ii libconfig-general-perl 2.63-1 ii libfile-homedir-perl 1.004-1 ii libfile-which-perl 1.21-1 ii libgnupg-interface-perl 0.52-9 ii libipc-system-simple-perl1.25-4 ii liblist-moreutils-perl 0.416-1+b3 ii libmoo-perl 2.003004-1 ii libmoox-late-perl0.015-3 ii libmoox-options-perl 4.023-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl0.104-2 ii libtime-duration-parse-perl 0.13-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl1.002001-1 ii libtypes-path-tiny-perl 0.005-1 ii perl 5.26.2-5 ii torsocks 2.2.0-2 Versions of packages parcimonie recommends: ii libglib-perl3:1.327-1 ii libgtk3-perl0.034-1 ii liblocale-gettext-perl 1.07-3+b3 ii libnet-dbus-glib-perl 0.33.0-2+b2 ii libnet-dbus-perl1.1.0-4+b3 ii libpango-perl 1.227-2+b1 ii libtime-duration-perl 1.20-1 ii tor 0.3.3.6-1 parcimonie suggests no packages. -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#900277: Enable csv (like json1 is already)
László Böszörményi (GCS) wrote:
> On Mon, May 28, 2018 at 1:33 PM Trent W. Buck wrote:
>> Per /usr/share/doc/sqlite3-doc/csv.html & https://sqlite.org/csv.html
>>
>> sqlite> CREATE VIRTUAL TABLE temp.t1 USING csv(filename='thefile.csv');
>> Error: no such module: csv
>>
>> ⋮
>>
>> If it's easy to do, can you please build the CSV module
>> (and any other similar first-party extensions)?
>
>Again, don't need to load any module. What's wrong with the following?
>
> $ cat test.csv
> a,b
> 1,2
> 3,4
> 5,6
> 7,8
>
> $ sqlite3
> SQLite version 3.23.1
> sqlite> .mode csv
> sqlite> .import test.csv test_table
> sqlite> .schema test_table
> CREATE TABLE test_table(
> "a" TEXT,
> "b" TEXT
> );
> sqlite> select * from test_table;
> 1,2
> 3,4
> 5,6
> 7,8
That reads the test.csv into a native sqlite table.
The csv module leaves it as an external table.
Reading into a native table (as you suggest) is definitely safer, and probably
queries are much faster, so
I agree it's USUALLY the right answer.
My actual use case is to migrate a mess of bash and CSV to python and sqlite,
but
I want to do it slowly, which means keeping the old CSV files working.
The workload is read-mostly and a small percentage of appends, so
using CSV as an external table looks/looked like a good bet.
A quick proof-of-concept test using the .import method you suggested
shows about 1m to round-trip the database from CSV to sqlite3 (45s)
and back to CSV (22s). That's the main thing I'm hoping to avoid.
Anyway, I did say "if it's easy to do", and it looks like the upstream
configure.ac does *not* make this easy.
For some reason upstream provides --enable options for only SOME
modules, e.g. json1 and rtree, but not interesting-looking things like
csv # read-only CSV virtual tables
zip # read-write ZIP virtual tables (each row is one file in the .zip)
icu # Unicode-aware LIKE, lower(), upper(),
lsm1# key/value storage backend (a la BDB)
eval# SQL function eval()
percentile # SQL aggregate function for
https://en.wikipedia.org/wiki/Percentile
regexp # SQL function regexp(re, str), for e.g. SELECT WHERE
scrub # Like VACUUM but stop-and-copy(?); optionally zeroes unused
blocks, like ext4's zerofree.
series # SQL function equivalent of GNU coreutils's seq(1)
shathree# SQL function for SHA-3 Keccak
spellfix# http://www.sqlite.org/spellfix1.html
totype # Coercion a la postgres ::INT and ::FLOAT
unionvtab # virtual table merging e.g. students.db and teachers.db tables
vfsstat # monitoring for questions like "why is my database so slow?"
For someone just using regular Debian /usr/bin/sqlite3 (or libsqlite3 via
python3),
it's not at all obvious how to actually get any of these features.
Following http://sqlite.org/loadext.html, this doesn't error, but does seem to
hang:
(BUILDROOT:BUSTER)root@zygon:/tmp/sqlite3# gcc -g -fPIC -shared
ext/misc/csv.c -o ext/misc/csv.so
(BUILDROOT:BUSTER)root@zygon:/tmp/sqlite3# seq 100 >test.csv
(BUILDROOT:BUSTER)root@zygon:/tmp/sqlite3# sqlite3
SQLite version 3.23.1 2018-04-10 17:39:29
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE VIRTUAL TABLE temp.t1 USING csv(filename='test.csv');
Error: no such module: csv
sqlite> .load ext/misc/csv.so
sqlite> CREATE VIRTUAL TABLE temp.t1 USING csv(filename='test.csv');
sqlite> .schema
CREATE VIRTUAL TABLE temp.t1 USING csv(filename='test.csv')
/* temp.t1(c0) */;
sqlite> select count(*) from temp.t1;
[hangs]
Probably because RFC-compliant CSV files need CRLF not LF, so…
(BUILDROOT:BUSTER)root@zygon:/tmp/sqlite3# unix2dos test.csv
unix2dos: converting file test.csv to DOS format...
[same behaviour from sqlite3]
The sha1 module *DOES* work when tested in this way:
(BUILDROOT:BUSTER)root@zygon:/tmp/sqlite3# gcc -g -fPIC -shared
ext/misc/sha1.c -o ext/misc/sha1.so
(BUILDROOT:BUSTER)root@zygon:/tmp/sqlite3# sqlite3 <<< $'.load
ext/misc/sha1.so\n select sha1("hello world");'
2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
(BUILDROOT:BUSTER)root@zygon:/tmp/sqlite3# printf 'hello world' | sha1sum
2aae6c35c94fcfb415dbe95f408b9ce91ee846ed -
Of course, I don't want to have to carry a csv.so around with me — I
want Debian to provide it in a standard place, so that when I change
architectures, or there's a security update to the sqlite3 package, I
get the newer csv.so automatically.
Oh, also, that way I get debhelper's standard hardening flags ☺
Bug#900387: RFP: abduco -- lightweight session manager with {de,at}tach support
Package: wnpp
Severity: wishlist
* Package name: abduco
Version : 0.6
Upstream Author : Marc André Tanner
* URL : http://www.brain-dump.org/projects/abduco/
* License : ISC
Programming Lang: C
Description : lightweight session manager with {de,at}tach support
abduco provides session management i.e. it allows programs to be run
independently from its controlling terminal. That is programs can be detached -
run in the background - and then later reattached. Together with dvtm it
provides a simpler and cleaner alternative to tmux or screen.
This package was included in Debian for a short while but was removed
due to the Debian package maintainer being inactive. abduco has a number
of advantagers over dtach that are described in the homepage and is
significantly more maintained. dvtm, a package by the same developer, is
intended to be paired with abduco for many use cases and already exists
within Debian.
Bug#900203: guile-2.2 FTCBFS for mipsel: In procedure load-thunk-from-memory: No such file or directory
On Tue, May 29, 2018 at 08:33:12PM -0500, Rob Browning wrote: > Also, I've rarely cross-builded via dpkg-buildpackage. For this to > work, will I need armhf or whatever as a dpkg architecture, and then to > perhaps apt install gcc:armhf, libreadline-dev:armhf, etc.? Yes, you do. It's not gcc:armhf, but gcc-arm-linux-gnueabihf. dpkg-buildpackage will run dpkg-checkbuilddeps and complain if anything is missing except for crossbuild-essential-armhf which is assumed present and libc-dev:armhf and libstdc++-dev:armhf as crossbuild-essential-armhf presently lacks the dependencies (#815172). I recommend using sbuild or pbuilder as bothe of these handle most of the complexity themselves. If there is any other build wrapper, that doesn't support cross compilation, please tell. Helmut
Bug#900298: needrestart: Needrestart false positive detect need to reboot due to microcode update
Control: retitle -1 needrestart: microcode: false positives, select expected version based on sig/pf/pf_mask On Mon, 28 May 2018 19:09:54 +0200 Francois Mescam wrote: > The currently running processor microcode revision is 0x712 which is > not the expected microcode revision 0xe09. ... > /usr/sbin/iucode_tool: system has processor(s) with signature 0x00050663 ... > 001/001: sig 0x00050662, pf_mask 0x10, 2018-01-22, rev 0x0015, size 31744 > 001/002: sig 0x00050663, pf_mask 0x10, 2018-01-22, rev 0x712, size 22528 > 001/003: sig 0x00050664, pf_mask 0x10, 2018-01-22, rev 0xf11, size 22528 > 001/004: sig 0x00050665, pf_mask 0x10, 2018-01-22, rev 0xe09, size 18432 The issue here appears to be that needrestart isn't matching the list of available microcode versions against the CPU's sig value. In addition, on the #debian-next IRC channel, a Debian user discovered a system where there were multiple microcode revisions available for the processor sig and the one that was loaded was the one where the processor flags (pf) value (from dmesg and sysfs) bitwise ANDed with the microcode pf_mask value resulted in a non-zero value. $ sudo sort -u /sys/devices/system/cpu/cpu*/microcode/processor_flags 0x2 $ sudo dmesg | grep pf= [1.103617] microcode: sig=0x106e5, pf=0x2, revision=0x8 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#900386: ITP: r-cran-rio -- GNU R package with Swiss-army knife for data i/o
Package: wnpp Owner: Dirk Eddelbuettel Severity: wishlist * Package name: r-cran-rio Version : 0.5.10 Upstream Author : Thomas Leeper * URL or Web page : https://cran.r-project.org/package=rio * License : GPL-2 Description : GNU R package with Swiss-army knife for data i/o This is another new Build-Depends of package r-cran-car (which has been in Debian since 2003); this package had been waiting on its own Build-Depends r-cran-openxlsx for a few weeks. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#895787: RFA: pcapy -- Python interface to the libpcap packet capture library
Control: retitle -1 ITA: pcapy -- Python interface to the libpcap packet capture library Control: owner -1 emmanuelaria...@gmail.com I would like to adopt this package Regards! -- Arias Emmanuel https://www.linkedin.com/in/emmanuel-arias-437a6a8a http://eamanu.com
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Hi Luca, > I don't think so - I still can't reproduce the problem despite that. It > should all go through the glvnd blobs. > > Do you have all of the following installed: Here I have again upgraded and have the same packages installed as you: ii libegl-nvidia0:amd64 390.59-1amd64 NVIDIA binary EGL library ii libegl1:amd64 1.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library -- EGL support ii libgl1:amd64 1.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library -- legacy GL support ii libgl1-nvidia-glvnd-glx:amd64 390.59-1amd64 NVIDIA binary OpenGL/GLX library (GLVND variant) ii libgles-nvidia2:amd64 390.59-1amd64 NVIDIA binary OpenGL|ES 2.x library ii libgles2:amd641.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library -- GLES support ii libglvnd0:amd64 1.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library ii libglx-nvidia0:amd64 390.59-1amd64 NVIDIA binary GLX library ii libglx0:amd64 1.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library -- GLX support ii libnvidia-cfg1:amd64 390.59-1amd64 NVIDIA binary OpenGL/GLX configuration library ii libnvidia-egl-wayland1:amd64 390.59-1amd64 NVIDIA binary Wayland EGL external platform library ii libnvidia-eglcore:amd64 390.59-1amd64 NVIDIA binary EGL core libraries ii libnvidia-glcore:amd64390.59-1amd64 NVIDIA binary OpenGL/GLX core libraries ii libnvidia-ml1:amd64 390.59-1amd64 NVIDIA Management Library (NVML) runtime library ii libopengl0:amd64 1.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library -- OpenGL support ii nvidia-alternative390.59-1amd64 allows the selection of NVIDIA as GLX provider ii nvidia-driver 390.59-1amd64 NVIDIA metapackage ii nvidia-driver-bin 390.59-1amd64 NVIDIA driver support binaries ii nvidia-driver-libs:amd64 390.59-1amd64 NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) ii nvidia-egl-common 390.59-1amd64 NVIDIA binary EGL driver - common files ii nvidia-egl-icd:amd64 390.59-1amd64 NVIDIA EGL installable client driver (ICD) ii nvidia-egl-wayland-common 390.59-1amd64 NVIDIA binary Wayland EGL external platform - common files ii nvidia-egl-wayland-icd:amd64 390.59-1amd64 NVIDIA Wayland EGL external platform library (ICD) ii nvidia-kernel-dkms390.59-1amd64 NVIDIA binary kernel module DKMS source ii nvidia-kernel-support 390.59-1amd64 NVIDIA binary kernel module support files ii nvidia-legacy-check 390.59-1amd64 check for NVIDIA GPUs requiring a legacy driver ii nvidia-vdpau-driver:amd64 390.59-1amd64 Video Decode and Presentation API for Unix - NVIDIA driver ii xserver-xorg-video-nvidia 390.59-1amd64 NVIDIA binary Xorg driver but I am still running on software rendering: $ glxinfo | grep OpenGL OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 6.0, 256 bits) ... Doing the same copy game of glx.so from linux to extensions dir I get it working: $ glxinfo | grep OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 1050 Ti/PCIe/SSE2 ... Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#900203: guile-2.2 FTCBFS for mipsel: In procedure load-thunk-from-memory: No such file or directory
Helmut Grohne writes: > I'm sorry, I don't usually build with dpkg-buildpackage directly and > thus I messed up the instructions. dpkg-buildpackage has its own > --host-arch switch. Please try: > > DEB_BUILD_PROFILES="cross nocheck" \ > DEB_BUILD_OPTIONS="parallel=2 nocheck" \ > nice fakeroot dpkg-buildpackage -B --host-arch=mipsel Also, I've rarely cross-builded via dpkg-buildpackage. For this to work, will I need armhf or whatever as a dpkg architecture, and then to perhaps apt install gcc:armhf, libreadline-dev:armhf, etc.? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#900248: Direct Rendering problem
I must add that the upgrade to Xserver 1.20 was at the same time as the Nvidia upgrade & the problem occurred right afterward (the xserver upgrade was blocked until there was a xserver-xorg-video-nvidia package available). Looking at the commit in question, I see that the Xserver is no longer looking for /linux--the location that Nvidia installs its version of libgxl.so. After creating a link from /linux to /extensions to make the nvidia driver work correctly "tends" to make me think that the root cause has been found. I am very open to exploring other options & will help in anything asked. -- Cheers!!! Dean Loros Performance by Design Ltd. autocrosser at http://forums.linuxmint.com
Bug#900385: ITP: golang-github-google-uuid -- generates and inspects UUIDs based on RFC 4122
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package name: golang-github-google-uuid Version: 0.2 Upstream Author: Google License: BSD-3-Clause URL: https://github.com/google/uuid Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-github-google-uuid Description: generates and inspects UUIDs based on RFC 4122 This package generates and inspects UUIDs based on RFC 4122 (http://tools.ietf.org/html/rfc4122) and DCE 1.1: Authentication and Security Services. . This package is based on the "github.com/pborman/uuid" package. It differs from these earlier packages in that a UUID is a 16 byte array rather than a byte slice. One loss due to this change is the ability to represent an invalid UUID (vs a NIL UUID). signature.asc Description: This is a digitally signed message part.
Bug#823037: ITP: flatbuffers -- efficient cross platform serialization library
Hi!
2018-05-29 17:44 GMT+09:00 Maximiliano Curia :
> ¡Hola!
>
> El 2018-05-29 a las 09:56 +0200, Maximiliano Curia escribió:
>>
>> I created a packaging salsa project here:
>> https://salsa.debian.org/debian/flatbuffers
>
>
> Ups, that was a lie, the project was created by Nobuhiro Iwamatsu. I was
> checking the flatbuffers, sink and kube code base last week and I today,
> when I found that an empty project was already present, I tought I created
> the repository and forgot about it.
>
> Nobushiro, sorry to meddle with this package. Please let me know if you are
> willing to group maintain this package, if not, please take the ownership of
> this bug.
No problem.
I am planning to packaging apache/arrow.
This package depends flatbuffers, if I can, I want to maintain this package.
Coulld you add me to flatbuffers team ?
Best regards,
Nobuhiro
>
> Happy hacking,
> --
> "By definition, when you are investigating the unknown, you do not know what
> you will find"
> -- The Ultimate Principle
> Saludos /\/\ /\ >< `/
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
Bug#900384: mirror submission for mirror.as29550.net
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.as29550.net Type: leaf Archive-architecture: amd64 i386 kfreebsd-amd64 kfreebsd-i386 Archive-http: /debian/ Maintainer: Hostmaster Country: GB United Kingdom Location: Reading Sponsor: AS29550 http://www.simplytransit.net/ Comment: Path is actually /ftp.debian.org/debian but your form wont accept that. Trace Url: http://mirror.as29550.net/debian/project/trace/ Trace Url: http://mirror.as29550.net/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.as29550.net/debian/project/trace/mirror.as29550.net
Bug#900203: guile-2.2 FTCBFS for mipsel: In procedure load-thunk-from-memory: No such file or directory
Helmut Grohne writes: > I'm sorry, I don't usually build with dpkg-buildpackage directly and > thus I messed up the instructions. dpkg-buildpackage has its own > --host-arch switch. Please try: > > DEB_BUILD_PROFILES="cross nocheck" \ > DEB_BUILD_OPTIONS="parallel=2 nocheck" \ > nice fakeroot dpkg-buildpackage -B --host-arch=mipsel Will do. > I ran each ftcbfs build twice to rule out the possibility of a random > ftcbfs. So we have a non-random ftcbfs for some architectures. I'm a bit > surprised about s390x here as it is the only failing 64bit architecture. Hmm. No idea if it's relevant, but wonder if it's of different endianness than the other 64-bit architectures (don't recall). For what it's worth, I believe guile's compiled .go files are currently only sensitive to endianness and pointer-width (and assume longs and pointers are the same width). (See prebuilt/Makefile.am -- though now that I look at it, irrespective of the comments earlier in the file, it doesn't appear to build 64-bit-big-endian... Maybe it handles that as a special case.) Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#900329: [pkg-apparmor] Bug#900329: apparmor: denials for apt-cacher-ng
On Tue, May 29, 2018 at 03:30:06PM +0545, Ritesh Raj Sarraf wrote: > It is the audit subsystem logging those messages. I remember playing > with it a couple of months ago. Haven't been able to recollect how to > disable it. The rules are typically stored in /etc/audit/audit.rules or /etc/audit/rules.d/ files -- best to edit the rules to match your desires and then restart the auditd service. Thanks signature.asc Description: PGP signature
Bug#900282: webkitgtk FTBFS with new ICU
On Mon, May 28, 2018 at 02:21:26PM +0100, peter green wrote: > Webkitgtk seems to be failing to build, failures have been seen > with binnmus in Debian and Raspbian and also on the reproducible > builds service. I had a look at the insanely large build log from > reproducible builds and found the following error, there are likely > many others. Although this is a very old and unsupported version of WebKitGTK+, I think this upstream patch still applies: https://bugs.webkit.org/show_bug.cgi?id=171612 I'll give it a try and see if it works. Berto
Bug#899274: KMail does not always remember the desired message list columns
On woensdag 30 mei 2018 01:11:50 CEST Sandro Knauß wrote: > But I do not understand the bugtracker for Qt within which version > what is fixed. I don't understand it either (apparently) as to me the bug you mentioned/ linked indicated to me it should've been fixed 'long' (in Sid terms) ago ;) > And I know from a friend that this bug is fixed within Qt > 5.11, as it was on the reason for him to switch to Qt 5.11 very early. Excellent. As mentioned on debian-kde it is indeed a minor annoyance. > According to arch there are (maybe) more bugs with patches needed Main reason for my message was to point to Arch's patches. Good that upstream is aware :) Thanks signature.asc Description: This is a digitally signed message part.
Bug#899274: KMail does not always remember the desired message list columns
Hey, > Are you sure? Because the qt bug is marked as fixed, but I still have this > issue as well (fully updated Sid system). Well also Arch mention this bug and hopefully they are all patched already in master :D But I do not understand the bugtracker for Qt within which version what is fixed. And I know from a friend that this bug is fixed within Qt 5.11, as it was on the reason for him to switch to Qt 5.11 very early. According to arch there are (maybe) more bugs with patches needed: qheaderview-restore.patch "https://code.qt.io/cgit/qt/qtbase.git/patch/?id=4a04eea4; qtbug-66444.patch "https://code.qt.io/cgit/qt/qtbase.git/patch/?id=9395f35c; qtbug-66420.patch "https://code.qt.io/cgit/qt/qtbase.git/patch/?id=fa091640; qtbug-66816.patch "https://code.qt.io/cgit/qt/qtbase.git/patch/?id=e4e87a2e; hefee signature.asc Description: This is a digitally signed message part.
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Hello Luca, [Cc'ing bugs this time] > I don't think so - I still can't reproduce the problem despite that. It > should all go through the glvnd blobs. OK. I don't know what I can do to help. This affected both of my computers with nvidia graphics, and for now I "fixed" it by copying the libglx.so to the other directory. > Do you have all of the following installed: I have most of them but not all. See the attached file. Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-===--== ii libegl-nvidia0:amd64 390.59-1amd64NVIDIA binary EGL library ii libegl-nvidia0:i386 390.59-1i386 NVIDIA binary EGL library ii libegl1:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- EGL support ii libegl1:i386 1.0.0+git20180308-2 i386 Vendor neutral GL dispatch library -- EGL support ii libgl1:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- legacy GL support ii libgl1:i386 1.0.0+git20180308-2 i386 Vendor neutral GL dispatch library -- legacy GL support ii libgl1-nvidia-glvnd-glx:amd64 390.59-1amd64NVIDIA binary OpenGL/GLX library (GLVND variant) ii libgl1-nvidia-glvnd-glx:i386 390.59-1i386 NVIDIA binary OpenGL/GLX library (GLVND variant) un libgles-nvidia2(no description available) ii libgles2:amd641.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- GLES support ii libglvnd0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library ii libglvnd0:i3861.0.0+git20180308-2 i386 Vendor neutral GL dispatch library ii libglx-nvidia0:amd64 390.59-1amd64NVIDIA binary GLX library ii libglx-nvidia0:i386 390.59-1i386 NVIDIA binary GLX library ii libglx0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- GLX support ii libglx0:i386 1.0.0+git20180308-2 i386 Vendor neutral GL dispatch library -- GLX support un libnvidia-cfg1 (no description available) ii libnvidia-eglcore:amd64 390.59-1amd64NVIDIA binary EGL core libraries ii libnvidia-eglcore:i386390.59-1i386 NVIDIA binary EGL core libraries ii libnvidia-glcore:amd64390.59-1amd64NVIDIA binary OpenGL/GLX core libraries ii libnvidia-glcore:i386 390.59-1i386 NVIDIA binary OpenGL/GLX core libraries ii libnvidia-ml1:amd64 390.59-1amd64NVIDIA Management Library (NVML) runtime library ii libopengl0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- OpenGL support ii nvidia-alternative390.59-1amd64allows the selection of NVIDIA as GLX provider ii nvidia-driver 390.59-1amd64NVIDIA metapackage ii nvidia-driver-bin 390.59-1amd64NVIDIA driver support binaries ii nvidia-driver-libs:amd64 390.59-1amd64NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) ii nvidia-driver-libs:i386 390.59-1i386 NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) ii nvidia-egl-common 390.59-1amd64NVIDIA binary EGL driver - common files ii nvidia-egl-icd:amd64 390.59-1amd64NVIDIA EGL installable client driver (ICD) ii nvidia-egl-icd:i386 390.59-1i386 NVIDIA EGL installable client driver (ICD) un nvidia-egl-wayland-icd (no description available) ii nvidia-kernel-dkms390.59-1amd64NVIDIA binary kernel module DKMS source ii nvidia-kernel-support 390.59-1amd64NVIDIA binary kernel module support files ii nvidia-legacy-check 390.59-1amd64check for NVIDIA GPUs requiring a legacy driver ii nvidia-vdpau-driver:amd64 390.59-1amd64Video Decode and Presentation API for Unix - NVIDIA driver ii xserver-xorg 1:7.7+19amd64X.Org X server ii xserver-xorg-core 2:1.20.0-2 amd64Xorg X server - core server ii xserver-xorg-video-nvidia 390.59-1amd64NVIDIA binary Xorg driver dpkg-query: no
Bug#900377: git: Debian git package can now include git-p4 Perforce proxy
On 29 May 2018 at 22:21, Jonathan Nieder wrote: > forcemerge 715534 900377 > quit > > Hi, > > Luke Diamand wrote: > >> Originally the Debian git package included this tool, but it was removed >> in 2014 because - at the time - the Perforce command-line tool was non-free: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715534#10 > > To be clear, what the Debian git package included before was a script > of a few lines that said that git was built without support for > Python. > > I don't believe the Debian git package ever included git-p4. > >> However, later that year, Perforce actually open-sourced a good deal of >> their software, including the p4 command-line client which git-p4 relies >> on: >> >> https://www.perforce.com/press-releases/perforce-open-sources-popular-version-control-tools >> >> The source can currently be found here: >> >> https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/ >> >> and the license (as of the 2018-1 branch) is here: >> >> https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/2018-1/LICENSE >> >> That appears to be a standard BSD license (2-part). > > Cool! Is there a bug open to package p4 in Debian? Not as far as I know. I could start the ball rolling with a bug report. I guess the question is how many people would actually use it. > >> I found that I could build the code on a recent Debian install with a >> few small hacks (I think it assumes an older version of openssl than >> that shipped with current Debian). >> >> Given this, I think git could once again include the git-p4 package. >> That would be very useful for people in organizations where Perforce is >> in use for version control, but who would prefer to use the standard git >> frontend (and for whatever reason can't use Perforce's own git-fusion >> tool). > > Thanks for the update. Given this context, it certainly seems worth > adding git-p4 to contrib for now, and to the main Debian repository > once the perforce client is in Debian. It's too bad the server isn't > also open source, but as long as the protocol spec is open and > implementable, that's not a reason not to include the client in > Debian. Thanks! I think the git-p4 client is the thing that's really useful (at least to people like me) but I've only very recently learned that the p4 client had been open-sourced. Luke
Bug#564112: [Reportbug-maint] Bug#564112: use python-apt to look up package short descriptions
> changing utils.available_package_description() to use the try..except > with python3-apt sounds like a good idea. I take that back. We should just drop utils.available_package_description() and its tests. If we'd put the try..except into that function, we'd also need to either (i) put the apt.Cache() call there or (ii) change the function interface to pass it the cache object. However, "i" is inefficient and we lose all the speed benefits of the patch, and "ii" is incompatible.
Bug#900316: Reassigning
reassign 900316 xorg-server forcemerge 900352 900316 thanks Merging with 900352, where the bug currently is.
Bug#884038: 884038: 2.15.x fails to fetch remote repository - introduced in d0c39a49ccb5dfe7feba4325c3374d99ab123c59?
I think this bug report may be about the same issue that I came across a while back here: https://www.spinics.net/lists/git/msg316628.html I found that the problem was "introduced" in d0c39a49ccb5dfe7feba4325c3374d99ab123c59, first released in 2.15.0 (as also noted in the bug). >revision.c: --all adds HEAD from all worktrees > >Unless single_worktree is set, --all now adds HEAD from all worktrees. The problem shows up if you have a git worktree where the HEAD revision ends up being expired (which happens automatically). My understanding is that the problem is that git prior to 2.15 could corrupt your repo by pruning a still-accessible worktree; this no longer happens. I haven't actually verified this myself, but since I sorted out my original broken tree, and moved to 2.15, I haven't seen the problem again. I think you could verify this theory by creating a worktree, expiring it and then doing fsck, with a 2.14 git and a 2.15+ git, but I haven't done that myself.
Bug#900089: [zfs-dkms]
Also, I already pushed a fix to git master that should make this work. Have you not tried a clean build with that patch?
Bug#899274: KMail does not always remember the desired message list columns
On dinsdag 22 mei 2018 14:20:38 CEST Sandro Knauß wrote: > Control: reassign -1 src:qtbase-opensource-src 5.10.1+dfsg-6 > Control: forward -1 https://bugreports.qt.io/browse/QTBUG-65478 > Control: affects -1 kmail > ... > I can confirm this bug. On kdepim-us...@kde.org it was mentioned that this > issue is a Qt one. Here the the mail: > > > > Its a QT bug apparently, related to this: > > https://bugreports.qt.io/browse/QTBUG-65478 > > Fixed in Fedora which probably doesn't help you. But FYI from the > > Changelog: > > - omit 0068-QHeaderView.patch, reports of regression'y behavior Are you sure? Because the qt bug is marked as fixed, but I still have this issue as well (fully updated Sid system). I reported it here: https://lists.debian.org/debian-kde/2018/04/msg00039.html and Lisandro mentioned that Arch had several patches related to it, here: https://lists.debian.org/debian-kde/2018/04/msg00047.html signature.asc Description: This is a digitally signed message part.
Bug#900089: [zfs-dkms]
Control: severity -1 wishlist I think everyone can agree this is at most a wishlist bug. I also agree that making Debian packaging easier for others in the greater Debian ecosystem would be nice. However, your point of contact for a build issue on another distribution should be that distribution's bugtracker. Not filing grave bugs without first confirming they affect that distribution.
Bug#900347: [DRE-maint] Bug#900347: Gitlab - wrong amount of pages
* Holger Wansing [180529 13:09]: > When watching the list of projects for a team, there is an issue > with the amount of pages for switching page-wise. > Means: go to the list of the installer team > https://salsa.debian.org/installer-team > and scroll down to the bottom, you see there are in summary > 5 pages listed, and pressing "Last" you get page 5, but there is > one more page. When being on page 5, there is page 6 > available. Please report bugs on salsa.d.o against the bugtracker for salsa.d.o; the gitlab package has nothing to do with salsa.d.o. Also, I cannot actually reproduce this on salsa.d.o :-) Cheers, Chris
Bug#900337: firejail: Users from user database should be able to run firejail regardless of UID_MIN on the system
On 05/29/2018 06:46 PM, Reiner Herrmann wrote: > Control: forwarded -1 https://github.com/netblue30/firejail/issues/1964 > > On Tue, May 29, 2018 at 11:35:24AM +0200, Alex Mestiashvili wrote: >> not able to use firejail after updating to 0.9.54-1 due to new check for >> UID_MIN. My user is a system user with UID 256. >> >> Firejail should not ignore users defined in the users database >> /etc/firejail/firejail.users even if they have uid lower that UID_MIN >> (defined in /etc/login.defs on a buildd!) > > Thanks for reporting this. I forwarded it upstream and suggested > to obtain the limit at runtime instead of hardcoding it. Thank you! I commented on the issue as I don't see a good reason for UID_MIN check if there is a user database check.. > >> @@ -83,6 +78,11 @@ int firejail_user_check(const char *name >> >> fclose(fp); >> return 0; >> + >> +// other system users will run the program as is >> +uid_t uid = getuid(); >> +if ((uid < UID_MIN && uid != 0) || strcmp(name, "nobody") == 0) >> +return 0; >> } >> >> // add a user to the database > > This will not work, as you moved the block behind a return statement. > The code can now never be reached. Ah, right, good that you spot that! but it seems to me that this check is redundant anyway. So I guess it is safe to remove it. Best regards, Alex
Bug#900383: virtualbox-guest-additions-iso: Please use git-lfs on salsa
Package: virtualbox-guest-additions-iso Severity: wishlist Hi, your repo on salsa wastes a lot of space for your iso, please consider using git-lfs on salsa. Thanks Alex - on behalf of the salsa admins -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled virtualbox-guest-additions-iso depends on no packages. Versions of packages virtualbox-guest-additions-iso recommends: ii virtualbox-5.2 [virtualbox] 5.2.8-121009~Debian~stretch virtualbox-guest-additions-iso suggests no packages.
Bug#900377: git: Debian git package can now include git-p4 Perforce proxy
forcemerge 715534 900377 quit Hi, Luke Diamand wrote: > Originally the Debian git package included this tool, but it was removed > in 2014 because - at the time - the Perforce command-line tool was non-free: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715534#10 To be clear, what the Debian git package included before was a script of a few lines that said that git was built without support for Python. I don't believe the Debian git package ever included git-p4. > However, later that year, Perforce actually open-sourced a good deal of > their software, including the p4 command-line client which git-p4 relies > on: > > https://www.perforce.com/press-releases/perforce-open-sources-popular-version-control-tools > > The source can currently be found here: > > https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/ > > and the license (as of the 2018-1 branch) is here: > > https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/2018-1/LICENSE > > That appears to be a standard BSD license (2-part). Cool! Is there a bug open to package p4 in Debian? > I found that I could build the code on a recent Debian install with a > few small hacks (I think it assumes an older version of openssl than > that shipped with current Debian). > > Given this, I think git could once again include the git-p4 package. > That would be very useful for people in organizations where Perforce is > in use for version control, but who would prefer to use the standard git > frontend (and for whatever reason can't use Perforce's own git-fusion > tool). Thanks for the update. Given this context, it certainly seems worth adding git-p4 to contrib for now, and to the main Debian repository once the perforce client is in Debian. It's too bad the server isn't also open source, but as long as the protocol spec is open and implementable, that's not a reason not to include the client in Debian. I'll look into it this week. Thanks for your kind and patient help, Jonathan
Bug#858992: [Pkg-cas-maintainers] Bug#858992: libapache2-mod-auth-cas: Please migrate to openssl1.1 in buster
On Sat, Oct 14, 2017 at 08:03:27AM +0200, Thijs Kinkhorst wrote: > Hi, > > On Thu, October 12, 2017 23:44, Sebastian Andrzej Siewior wrote: > > this is a remainder about the openssl transition [0]. We really want to > > remove libssl1.0-dev from unstable for Buster. I will raise the severity > > of this bug to serious in a month. Please react before that happens. > > Thanks, I'm aware but this is currently blocked by curl. FWIW, curl is now resolved. Cheers, Moritz
Bug#886940: libzypp-dev: ZyppCommon.cmake is installed in a wrong directory
Control: tags -1 wontfix Control: close -1 Hi, On Thu, 11 Jan 2018 15:41:41 +0100 =?utf-8?Q?=C5=81ukasz?= Stelmach wrote: > Package: libzypp-dev > Version: 14.29.1-2 > Severity: normal > > Dear Maintainer, > > It appears the ZyppCommon.cmake file is installed in a wrong directory. > When I try to build https://github.com/openSUSE/libzypp-bindings I get > an error messagage > > --8<---cut here---start->8--- > CMake Error at CMakeLists.txt:20 (INCLUDE): > include could not find load file: > > ZyppCommon > --8<---cut here---end--->8--- > > the workaround I've found is to copy the file to > /usr/share/cmake-3.6/Modules/. This does not feel right. For more details, please follow the thought line as posted at [1]. Closing and tagging as won't fix for now. Feel free to reopen if you have other technical input. Thanks! Mike [1] https://github.com/openSUSE/libzypp/issues/28
Bug#900382: decopy: please use https URL in Format
Package: decopy Version: 0.2.2-1 Severity: wishlist lintian started nagging about that some time ago, so could you please default the URL in Format: to the https variant? Thanks Cheers -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (650, 'unstable-debug'), (650, 'buildd-unstable'), (650, 'unstable'), (601, 'testing'), (600, 'experimental-debug'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-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 decopy depends on: ii bzip2 1.0.6-8.1 ii exiv2 0.25-3.1 ii python3 3.6.5-3 ii python3-debian 0.1.32 ii python3-xdg 0.25-4 ii xz-utils5.2.2-1.3 Versions of packages decopy recommends: ii python3-tqdm 4.19.5-1 decopy suggests no packages. -- no debconf information -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#856470: libzypp: FTBFS on mips*
Control: close -1
Control: fixed -1 17.3.1-1
Hi,
On Wed, 1 Mar 2017 12:14:33 + James Cowgill wrote:
> Source: libzypp
> Version: 16.4.3-1
> Severity: serious
> Tags: sid stretch
>
> Hi,
>
> libzypp FTBFS on mips* due to errors in Arch.cc:
> > /«PKGBUILDDIR»/zypp/Arch.cc:153:46: error: expected unqualified-id
before numeric constant
> > namespace { static inline const IdString & _##A () { static
IdString __str(#A); return __str; } } \
> > ^
> > /«PKGBUILDDIR»/zypp/Arch.cc:215:3: note: in expansion of macro
'DEF_BUILTIN'
> > DEF_BUILTIN( mips );
> > ^~~
> > /«PKGBUILDDIR»/zypp/Arch.cc:153:46: error: expected initializer
before numeric constant
> > namespace { static inline const IdString & _##A () { static
IdString __str(#A); return __str; } } \
> > ^
> > /«PKGBUILDDIR»/zypp/Arch.cc:215:3: note: in expansion of macro
'DEF_BUILTIN'
> > DEF_BUILTIN( mips );
> > ^~~
> > /«PKGBUILDDIR»/zypp/Arch.cc:154:29: error: expression cannot be
used as a function
> > const Arch Arch_##A( _##A() )
> > ^
> > /«PKGBUILDDIR»/zypp/Arch.cc:215:3: note: in expansion of macro
'DEF_BUILTIN'
> > DEF_BUILTIN( mips );
> > ^~~
> > /«PKGBUILDDIR»/zypp/Arch.cc: In constructor
'zypp::{anonymous}::ArchCompatSet::ArchCompatSet()':
> > /«PKGBUILDDIR»/zypp/Arch.cc:357:27: error: expression cannot be
used as a function
> > defCompatibleWith( _mips(), _noarch() );
> > ^
> > zypp/CMakeFiles/zypp.dir/build.make:4889: recipe for target
'zypp/CMakeFiles/zypp.dir/Arch.cc.o' failed
>
> This is because, for historical reasons, the mips toolchain defines
> "mips = 1" and "_mips = 1". Either "-Umips -U_mips" need to be added to
> the CFLAGS on MIPS or the code in Arch.cc needs to be changed to avoid
> the use of the "mips" and "_mips" identifiers.
>
> Thanks,
> James
>
It seems that this issue got resolved with the latest upload of libzypp
17.3.1-1. The buildd jobs successfully built the package on mips*.
Thus, closing...
Mike
Bug#900381: Fails to boot cirros QEMU image with tuned running
Package: tuned Version: 2.9.0-1 As soon as you install tuned (which auto-starts tuned.service), booting at least some QEMU images does not work any more: $ wget https://download.cirros-cloud.net/0.3.5/cirros-0.3.5-i386-disk.img $ qemu-system-x86_64 -enable-kvm -nographic cirros-0.3.5-i386-disk.img -snapshot qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.8001H:ECX.svm [bit 2] And then nothing happens at all any more, other than QEMU using 100% CPU. This also affects version 0.4.0 and x86_64, so it's not particularly sensitive to guest changes. I'm testing this with (nested) KVM inside a current Debian testing VM. After systemctl stop tuned", QEMU works again: $ qemu-system-x86_64 -enable-kvm -nographic cirros-0.3.5-i386-disk.img -snapshot qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.8001H:ECX.svm [bit 2] [ 0.00] Initializing cgroup subsys cpuset [ 0.00] Initializing cgroup subsys cpu [ 0.00] Linux version 3.2.0-80-virtual (buildd@komainu) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #116-Ubuntu SMP Mon Mar 23 17:48:17 UTC 2015 (Ubuntu 3.2.0-80.116-virtual 3.2.68) [...] This shows that the "ECX.svm" warning already happened before and seems to be unrelated. Further info: * This is with current Linux 4.16.5 and QEMU 2.12. * This also affects Ubuntu 18.04 LTS, which has the exact same tuned version, but a slightly older kernel (4.15.0), and an older QEMU (2.11). (https://launchpad.net/bugs/1774000) * This does *not* seem to affect Fedora 28, which also has the exact same tuned version, configuration files, systemd unit, tuned invocation, default profile, etc. That runs Linux 4.16.11 and QEMU 2.11.1. Thanks, Martin
Bug#797867: libzypp: ABI transition needed for libstdc++ v5
Control: close -1 Control: fixed -1 17.3.1-1 Hi, On Thu, 3 Sep 2015 08:30:01 +0100 Simon McVittie wrote: > Source: libzypp > Version: 15.3.0-1 > Severity: serious > Justification: breaks ABI without a package rename > Tags: sid stretch > User: debian-...@lists.debian.org > Usertags: libstdc++-cxx11 > > Background[1]: libstdc++6 introduces a new ABI to conform to the > C++11 standard, but keeps the old ABI to not break existing binaries. > Packages which are built with g++-5 from experimental (not the one > from testing/unstable) are using the new ABI. Libraries built from > this source package export some of the new __cxx11 or B5cxx11 symbols, > dropping other symbols. If these symbols are part of the API of > the library, then this rebuild with g++-5 will trigger a transition > for the library. > > In the case of libzypp, std::string appears in major classes such as > Pathname, so it seems very likely that a transition is needed. The > transition normally consists of renaming the affected library packages, > adding a v5 suffix. The SONAME should not be changed when doing this. > However, libzypp is not packaged according to Policy §8.1 and does > not generate correct dependencies (I'll file a separate bug), > so a versioned Breaks on zypper will probably be needed as well. > > If an upgrade to a new upstream SONAME is already planned, and that > SONAME has never been available in Debian compiled with g++-4, then an > alternative way to carry out the transition would be to bump the > SONAME. Please avoid doing this unless the new upstream version > is very low-risk. > > These follow-up transitions for libstdc++ are not going through exactly > the normal transition procedure, because many entangled transitions are > going on at the same time, and the usual ordered transition procedure > does not scale that far. When all the C++ libraries on which this library > depends have started their transitions in unstable if required, this > library should do the same, closing this bug; the release team will deal > with binNMUs as needed. > > Looking at the build-dependencies of libzypp, the C++ libraries > are Boost, which has had its rename already (while moving from 1.55 > to 1.58), and libproxy, which only has a C ABI so does not need a > rename; so this sub-transition is ready to start. > > The package might be NMU'd if there is no maintainer response. The > release team have declared a 2 day NMU delay[2] for packages involved > in the libstdc++ transition, in order to get unstable back to a usable > state in a finite time. > > Regards, > S > > [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition > [2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html This bug should be resolved with latest upload of libzypp 17.3.1-1 to Debian unstable. Unfortunately, I had the wrong bug closure in debian/changelog and this bug did not get closed with the upload. Thus closing manually... (with a post-upload fix in debian/changelog). Mike
Bug#898934: transition: libmygpo-qt
On 29/05/18 21:11, Thomas Pierson wrote: > Hi Emilio, > > This transition seems almost done but clementine can't be built for now > on armel and armhf. So could you please remove clementine armel and > armhf binaries in *testing* to ease the migration of clementine to testing? No, we don't do partial removals from testing. So either you fix clementine, or request its removal from unstable for those architectures. Cheers, Emilio
Bug#898934: transition: libmygpo-qt
On 29/05/18 22:38, Emilio Pozuelo Monfort wrote: > On 29/05/18 21:11, Thomas Pierson wrote: >> Hi Emilio, >> >> This transition seems almost done but clementine can't be built for now >> on armel and armhf. So could you please remove clementine armel and >> armhf binaries in *testing* to ease the migration of clementine to testing? > > No, we don't do partial removals from testing. So either you fix clementine, > or > request its removal from unstable for those architectures. Since you no longer allow building the package on those architectures, you should request the removal from unstable by filing a bug against ftp.debian.org with reportbug (then follow the instructions). Once that happens, the removal will propagate to testing and the transition will finish. Cheers, Emilio
Bug#900259: mate-tweak: Colors in marco-compton are weird
Alex ARNAUD wrote: > Hello Erik, > > Thank you for this report. What I can understand in your report is > related to Marco, right? > > Do we agree that Marco Compton is not enabled by default? marco-compton is not enabled by default. I had to install mate-tweak and then switch from marco to marco-compton. > Can you tell us what is your graphic card? What driver are you using > with It? THe video carda is : NVIDIA Corporation GP107 [GeForce GTX 1050] (rev a1) and I'm using xserver-xorg-video-nouveau. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/
Bug#900380: RM: ike -- RoQA; dead upstream, orphaned, RC-buggy
Package: ftp.debian.org Severity: normal Hi, please remove ike. It's dead upstream (last release from 2013), orphaned without an adopter since two years and is incompatible with OpenSSL 1.1 (so RC-buggy). Cheers, Moritz
Bug#900378: glx-alternative-nvidia: Fails to enable proprietary accelerated OpenGL and does not report the problem
Control: reassign -1 nvidia-driver Control: forcemerge 900248 -1 On Tue, 2018-05-29 at 21:08 +0100, Tony Houghton wrote: > Package: glx-alternative-nvidia > Version: 0.8.3 > Severity: normal > > Since a dist-upgrade I noticed a poor framerate and high CPU usage in > Minecraft. glxinfo seems to indicate it's using software rendering: > > name of display: :1 > display: :1 screen: 0 > direct rendering: Yes > server glx vendor string: SGI > server glx version string: 1.4 > ... > Extended renderer info (GLX_MESA_query_renderer): > Vendor: VMware, Inc. (0x) > Device: llvmpipe (LLVM 6.0, 128 bits) (0x) > Version: 18.0.4 > Accelerated: no > ... > > I think the source of the problem is that the available version of > most > of the binary packages of nvidia-graphics-drivers is 390.59-1 but for > libgl1-glvnd-nvidia-glx it's 390.48-3 (can there really be a lag of a > whole day for packages from the same source package to make it into > the > archive?) so it can't be installed. But seeing as > glx-alternative-nvidia's main job is to activate the proprietary > driver > it should report the problem if it's unable to do that and/or it > should > depend on all the packages it needs. Those binaries are gone and apt should prompt to autoremove them. The same has already been reported, so merging the bugs. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900073: clementine: fails to play anything: streaming stopped, reason not linked (-1)
Control: tags -1 =
Control: severity normal
Control: retitle -1 clementine: provide better error message if output device
is not available
Hi Thomas
On 2018-05-29 21:50:06, Thomas Pierson wrote:
> severity 900073 important
> tags 900073 + moreinfo unreproducible
> thanks
>
> Hi Sebastian,
>
> I can't reproduce your issue. I also try to reproduce it by installing
> clementine on a fresh sid system and I can play mp3 and flac files.
Steps to reproduce the issue:
* In clementine's preferences under "Playback - Audio output" select some
removable device.
* Quit clementine.
* Unplug/disconnect/remove the output device.
* Start clementine and try to play a file.
Then clementine is unable to play anything and only reports an internal error
and prints the GstEnginePipeline errors. After setting the output device to an
existing device everything works again. It would be really helpful if clementine
would report a sensible error message like "output device does not exist"
instead of an "internal stream error". Then one would be able to act on it.
Retitled the bug accordingly.
> Can you try to make a backup and remove all possible config directories
> located here `~/.config/Clementine{-new/-qt5}`, do an upgrade of your
> system and then retry after that?
Diffing the new and old config files revealed the above issue.
> Also could you give me more info about your system and your desktop
> environment as I can try to reproduce your issue.
It's a plain XFCE. But I suppose the issue is unrleated to the DE.
Cheers
--
Sebastian Ramacher
signature.asc
Description: PGP signature
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On Tue, 2018-05-29 at 01:20 +0200, Peter De Wachter wrote: > Package: nvidia-driver > Followup-For: Bug #900248 > > I think this bug is caused by a change in xserver 1.20. The nvidia > libglx.so gets installed in /usr/lib/xorg/modules/linux/, but this > directory has been removed from X's search path. As a result X only > finds the default libglx.so in /usr/lib/xorg/modules/extensions/. > See this commit: > https://cgit.freedesktop.org/xorg/xserver/commit/?id=97bd6e4536765168 > 91250389ec0fd695c110087c > > Best regards, > Peter I don't think so - I still can't reproduce the problem despite that. It should all go through the glvnd blobs. Do you have all of the following installed: ii libegl-nvidia0:amd64 390.59-1 amd64NVIDIA binary EGL library ii libgl1-nvidia-glvnd-glx:amd64 390.59-1 amd64NVIDIA binary OpenGL/GLX library (GLVND variant) ii libgles-nvidia2:amd64 390.59-1 amd64NVIDIA binary OpenGL|ES 2.x library ii libglx-nvidia0:amd64 390.59-1 amd64NVIDIA binary GLX library ii libnvidia-cfg1:amd64 390.59-1 amd64NVIDIA binary OpenGL/GLX configuration library ii libnvidia-egl-wayland1:amd64 390.59-1 amd64NVIDIA binary Wayland EGL external platform library ii libnvidia-eglcore:amd64 390.59-1 amd64NVIDIA binary EGL core libraries ii libnvidia-glcore:amd64390.59-1 amd64NVIDIA binary OpenGL/GLX core libraries ii libnvidia-ml1:amd64 390.59-1 amd64NVIDIA Management Library (NVML) runtime library ii nvidia-alternative390.59-1 amd64allows the selection of NVIDIA as GLX provider ii nvidia-driver 390.59-1 amd64NVIDIA metapackage ii nvidia-driver-bin 390.59-1 amd64NVIDIA driver support binaries ii nvidia-driver-libs:amd64 390.59-1 amd64NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) ii nvidia-egl-common 390.59-1 amd64NVIDIA binary EGL driver - common files ii nvidia-egl-icd:amd64 390.59-1 amd64NVIDIA EGL installable client driver (ICD) ii nvidia-egl-wayland-common 390.59-1 amd64NVIDIA binary Wayland EGL external platform - common files ii nvidia-egl-wayland-icd:amd64 390.59-1 amd64NVIDIA Wayland EGL external platform library (ICD) ii nvidia-kernel-dkms390.59-1 amd64NVIDIA binary kernel module DKMS source ii nvidia-kernel-support 390.59-1 amd64NVIDIA binary kernel module support files ii nvidia-legacy-check 390.59-1 amd64check for NVIDIA GPUs requiring a legacy driver ii nvidia-vdpau-driver:amd64 390.59-1 amd64Video Decode and Presentation API for Unix - NVIDIA driver ii xserver-xorg-video-nvidia 390.59-1 amd64NVIDIA binary Xorg driver ii libegl1:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- EGL support ii libgl1:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- legacy GL support ii libgles2:amd641.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- GLES support ii libglvnd0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library ii libglx0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- GLX support ii libopengl0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- OpenGL support -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900379: php-common, php-apcu-bc: sessionclean spams errors if apcu_bc is enabled
Package: php-common Version: 1:61 Severity: minor With apcu_bc enabled, sessionclean looks for the apc.so file in /usr/lib/php/20151012/ even though it only exists in /usr/lib/php/20170718/: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/apc.so' - /usr/lib/php/20151012/apc.so: cannot open shared object file: No such file or directory in Unknown on line 0 A trivial workaround is to phpdismod apcu_bc $ apt-cache policy php-apcu-bc php-apcu-bc: Installed: 1.0.3-2+b1 Candidate: 1.0.3-2+b1 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.13-x86_64-linode106 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages php-common depends on: ii psmisc 23.1-1+b1 ii sed 4.4-2 php-common recommends no packages. php-common suggests no packages. -- no debconf information
Bug#900275: xsd: backport smart_ptr PR #47: disable .set mips2 for mips release r6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello YunQiang Su, thank you for spending your time helping to make Debian better with this bug report. Please can you explain the meaning of your bug for xsd? CU Jörg - -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst IRC: j_...@freenode.net j_...@oftc.net My wish list: - Please send me a picture from the nature at your home. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlsNtHAACgkQCfifPIyh 0l0NghAAk0v9JRLlNWI1gLL8Kh/nYxQNxaQA8uDFjc9fHXvjR6jxODac3p/Nz67M SoTEUBZyll6yTE8vCQ7p58Ibl2ZcragxJ4dhyQZOoQ0dwKdqVFXmFW2dYoxc/qj7 luVW6it1BtCd+Mu9PF3nULpox+pqc1h0LVtGggN2gJMDnmju65eFoA9J8uD1sfLl XCYVWDf1yvaDRV3VW/UKZ+/Z0xJSK8P25B+caR5kk/Qdp9U2bjDGdcQStl/sIkMO rTcZ1LGq0m8uA6fBRJCq6moPAjMCICoM2bvqehpCylYXRW+jZGFkeforYqXXDnca /qMefMzDURIlcICg6aOk6GLwzPoUUgGOfYooSa+/zBv6AejtJNcp63sXMafHHC4h 9koY8uVSf0qqwTQMIJuwSKt0Rg5UPDKX2ktKfQJnI0zlPiKdN+KGiqYTAWUCXwFa DUVTfhM1MHUF3tp3F3hJLkzljEmuEV5JN+AvLwfCj/NC/Z+d7YMtjovncFIMn76k lVf6g10GppKcWwQlT2jRUza+QeRrm5rHN4z8X+h15zjkzyHihFr5aY3bw4XkKkHb RO2TLaV9MoADZF4YSHsFbHULSoc/z32aeIcT1Vs+bV/sJmEOpdofgbGxcND0ped3 kRaHz+3xJ54ylJTCbsLBZjMG6CD1d/lUYPqUJlCJnRo6HMGYsyY= =xS/i -END PGP SIGNATURE-
Bug#900378: glx-alternative-nvidia: Fails to enable proprietary accelerated OpenGL and does not report the problem
Package: glx-alternative-nvidia Version: 0.8.3 Severity: normal Since a dist-upgrade I noticed a poor framerate and high CPU usage in Minecraft. glxinfo seems to indicate it's using software rendering: name of display: :1 display: :1 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 ... Extended renderer info (GLX_MESA_query_renderer): Vendor: VMware, Inc. (0x) Device: llvmpipe (LLVM 6.0, 128 bits) (0x) Version: 18.0.4 Accelerated: no ... I think the source of the problem is that the available version of most of the binary packages of nvidia-graphics-drivers is 390.59-1 but for libgl1-glvnd-nvidia-glx it's 390.48-3 (can there really be a lag of a whole day for packages from the same source package to make it into the archive?) so it can't be installed. But seeing as glx-alternative-nvidia's main job is to activate the proprietary driver it should report the problem if it's unable to do that and/or it should depend on all the packages it needs. -- Package-specific info: Diversions: diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.0.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.7.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.7.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.0.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.0.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.7.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.7.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.2.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions
Bug#607802: fontconfig-config: Additional information for suggested fix
Package: fontconfig-config Version: 2.13.0-5 Followup-For: Bug #607802 Dear Maintainer, I have encountered the same problem, and am able to provide sufficient information for a quick fix. Han character fonts in Linux generally fall in three styles; an woodblock style, a sans-serif style, and a brush style. The woodblock style is typically considered the serif analogue, while the brush style should be considered handwriting, or cursive. In addition to the first reporter, there exist fonts categorized as serif that should not be categorized as such. Here are the offending lines that should be deleted, which should suffice for a fix: Under serif, WenQuanYi Zen Hei AR PL Zenkai Uni Under sans-serif, WenQuanYi Bitmap Song AR PL ShanHeiSun Uni AR PL New Sung AR PL KaitiM GB AR PL KaitiM Big5 AR PL ShanHeiSun Uni AR PL SungtiL GB AR PL Mingti2L Big5 ZYSong18030 Thanks! -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fontconfig-config depends on: ii debconf [debconf-2.0] 1.5.66 ii fonts-dejavu-core 2.37-1 ii fonts-liberation 1:1.07.4-6 ii ucf3.0038 fontconfig-config recommends no packages. fontconfig-config suggests no packages. -- debconf information: fontconfig/subpixel_rendering: Automatic fontconfig/enable_bitmaps: false fontconfig/hinting_style: hintslight fontconfig/hinting_type: Native
Bug#900377: git: Debian git package can now include git-p4 Perforce proxy
Source: git Severity: wishlist Dear Maintainer, There is a standard git tool, git-p4, which proxies between git and Perforce (c.f. git-svn for example). Originally the Debian git package included this tool, but it was removed in 2014 because - at the time - the Perforce command-line tool was non-free: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715534#10 However, later that year, Perforce actually open-sourced a good deal of their software, including the p4 command-line client which git-p4 relies on: https://www.perforce.com/press-releases/perforce-open-sources-popular-version-control-tools The source can currently be found here: https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/ and the license (as of the 2018-1 branch) is here: https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/2018-1/LICENSE That appears to be a standard BSD license (2-part). I found that I could build the code on a recent Debian install with a few small hacks (I think it assumes an older version of openssl than that shipped with current Debian). Given this, I think git could once again include the git-p4 package. That would be very useful for people in organizations where Perforce is in use for version control, but who would prefer to use the standard git frontend (and for whatever reason can't use Perforce's own git-fusion tool). Thanks Luke -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/12 CPU cores) 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)
Bug#900025: /usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header
control: reassign -1 hplip On 2018-05-26 09:13, Cristian Ionescu-Idbohrn wrote: > On Fri, 25 May 2018, Aurelien Jarno wrote: > > On 2018-05-24 21:12, Cristian Ionescu-Idbohrn wrote: > > > Package: libc6-dev > > > Version: 2.27-3 > > > Severity: normal > > > > > > Not sure if this should be filed against simple-scan. In that case > > > feel free to reassign. > > > > > > simple-scan: common/utils.c 188: unable to load library libm.so: > > > /usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header > > > > > > Adn these are the contents of /usr/lib/x86_64-linux-gnu/libm.so: > > > > > > /* GNU ld script > > > */ > > > OUTPUT_FORMAT(elf64-x86-64) > > > GROUP ( /lib/x86_64-linux-gnu/libm.so.6 AS_NEEDED ( > > > /usr/lib/x86_64-linux-gnu/libmvec_nonshared.a > > > /lib/x86_64-linux-gnu/libmvec.so.1 ) ) > > > > .so files are not designed to be loaded, but to be used at link time. > > Therefore it's perfectly fine for them to be a linker file. simple-scan > > should use libm.so.6 instead, or rather LIBM_SO from the > > include. > > Then this should be reassigned to package simple-scan? As Florian pointed out it's actually an issue in the hplip package, used by simple-scan. I am therefore reassigning the bug there. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#900349: linux-image-4.9.0-6-amd64 does not support RAID controller (530-4i Flex) of Lenovo ThinkSystem SN550 servers
Control: tag -1 upstream fixed-upstream patch
On Tue, 29 May 2018 13:41:13 +0200 Michael Prokop wrote:
> Package: linux
> Version: 4.9.88-1+deb9u1
> Severity: important
>
> The current kernel version of Debian/stretch (4.9.0-6-amd64) doesn't
> support the RAID controller as present in Lenovo ThinkSystem SN550
> blade servers (https://lenovopress.com/lp0637-thinksystem-sn550-server).
>
> It's known to be supported with Ubuntu 18.10 using kernel 4.15, I
> gathered hardware information from a Grml live system which uses
> kernel 4.15 though, being based on Debian's debian/4.15.17-1 (git
> commit 0b520de976c19).
[...]
> AFAICT the relevant support has been introduced as of git commit
> 45f4f2eb3da3 ("scsi: megaraid_sas: Add new pci device Ids for SAS3.5
> Generic Megaraid Controllers") in upstream kernel repository, present
> in kernel versions 4.11 and newer.
[...]
Is it sufficient to apply that single commit? I'm attaching a
slightly modified version that applies to stretch.
Ben.
--
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.
From: Sasikumar Chandrasekaran
Date: Tue, 10 Jan 2017 18:20:43 -0500
Subject: scsi: megaraid_sas: Add new pci device Ids for SAS3.5 Generic
Megaraid Controllers
Origin: https://git.kernel.org/linus/45f4f2eb3da3cbff02c3d77c784c81320c733056
Bug-Debian: https://bugs.debian.org/900349
This patch contains new pci device ids for SAS3.5 Generic Megaraid Controllers
Signed-off-by: Sasikumar Chandrasekaran
Reviewed-by: Tomas Henzl
Signed-off-by: Martin K. Petersen
[bwh: Backported to 4.9: adjust context]
---
drivers/scsi/megaraid/megaraid_sas.h| 12 ++---
drivers/scsi/megaraid/megaraid_sas_base.c | 14 +-
drivers/scsi/megaraid/megaraid_sas_fusion.c | 30 -
3 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h
index fdd519c1dd57..cb82195a8be1 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -56,6 +56,11 @@
#define PCI_DEVICE_ID_LSI_INTRUDER_24 0x00cf
#define PCI_DEVICE_ID_LSI_CUTLASS_52 0x0052
#define PCI_DEVICE_ID_LSI_CUTLASS_53 0x0053
+#define PCI_DEVICE_ID_LSI_VENTURA 0x0014
+#define PCI_DEVICE_ID_LSI_HARPOON 0x0016
+#define PCI_DEVICE_ID_LSI_TOMCAT 0x0017
+#define PCI_DEVICE_ID_LSI_VENTURA_4PORT 0x001B
+#define PCI_DEVICE_ID_LSI_CRUSADER_4PORT 0x001C
/*
* Intel HBA SSDIDs
@@ -100,7 +105,7 @@
*/
/*
- * MFI stands for MegaRAID SAS FW Interface. This is just a moniker for
+ * MFI stands for MegaRAID SAS FW Interface. This is just a moniker for
* protocol between the software and firmware. Commands are issued using
* "message frames"
*/
@@ -1435,7 +1440,7 @@ enum FW_BOOT_CONTEXT {
* register set for both 1068 and 1078 controllers
* structure extended for 1078 registers
*/
-
+
struct megasas_register_set {
u32 doorbell; /*h*/
u32 fusion_seq_offset; /*0004h*/
@@ -1478,7 +1483,7 @@ struct megasas_register_set {
u32 inbound_high_queue_port ; /*00C4h*/
- u32 reserved_5; /*00C8h*/
+ u32 inbound_single_queue_port; /*00C8h*/
u32 res_6[11]; /*CCh*/
u32 host_diag;
u32 seq_offset;
@@ -2142,6 +2147,7 @@ struct megasas_instance {
u8 is_imr;
u8 is_rdpq;
bool dev_handle;
+ bool is_ventura;
};
struct MR_LD_VF_MAP {
u32 size;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
index d5cf15eb8c5e..e00b3dece088 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -155,6 +155,12 @@ static struct pci_device_id megasas_pci_table[] = {
/* Intruder 24 port*/
{PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_CUTLASS_52)},
{PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_CUTLASS_53)},
+ /* VENTURA */
+ {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_VENTURA)},
+ {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_HARPOON)},
+ {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_TOMCAT)},
+ {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_VENTURA_4PORT)},
+ {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_CRUSADER_4PORT)},
{}
};
@@ -5714,6 +5720,12 @@ static int megasas_probe_one(struct pci_dev *pdev,
instance->pdev = pdev;
switch (instance->pdev->device) {
+ case PCI_DEVICE_ID_LSI_VENTURA:
+ case PCI_DEVICE_ID_LSI_HARPOON:
+ case PCI_DEVICE_ID_LSI_TOMCAT:
+ case PCI_DEVICE_ID_LSI_VENTURA_4PORT:
+ case PCI_DEVICE_ID_LSI_CRUSADER_4PORT:
+ instance->is_ventura = true;
case PCI_DEVICE_ID_LSI_FUSION:
case PCI_DEVICE_ID_LSI_PLASMA:
case PCI_DEVICE_ID_LSI_INVADER:
@@ -5738,7 +5750,7 @@ static int megasas_probe_one(struct pci_dev *pdev,
if ((instance->pdev->device == PCI_DEVICE_ID_LSI_FUSION) ||
(instance->pdev->device == PCI_DEVICE_ID_LSI_PLASMA))
fusion->adapter_type = THUNDERBOLT_SERIES;
- else
+ else if (!instance->is_ventura)
Bug#900073: clementine: fails to play anything: streaming stopped, reason not linked (-1)
severity 900073 important
tags 900073 + moreinfo unreproducible
thanks
Hi Sebastian,
I can't reproduce your issue. I also try to reproduce it by installing
clementine on a fresh sid system and I can play mp3 and flac files.
Can you try to make a backup and remove all possible config directories
located here `~/.config/Clementine{-new/-qt5}`, do an upgrade of your
system and then retry after that?
Also could you give me more info about your system and your desktop
environment as I can try to reproduce your issue.
Thanks,
Thomas
On 25/05/2018 19:07, Sebastian Ramacher wrote:
> Package: clementine
> Version: 1.3.1+git542-gf00d9727c+dfsg-1
> Severity: grave
>
> Since the last update clementine [1] refuses to play any files. clementine
> was able
> to play these files in previously. I see the following error messages:
>
> 18:50:13.677 ERROR GstEnginePipeline:65212 "gstbaseparse.c(3611):
> gst_base_parse_loop ():
> /GstPipeline:pipeline/GstURIDecodeBin:uridecodebin-198/GstDecodeBin:decodebin13/GstFlacParse:flacparse13:\nstreaming
> stopped, reason not-linked (-1)"
>
> (for flac files)
>
> 18:58:48.333 ERROR GstEnginePipeline:6521 "gstbaseparse.c(3611):
> gst_base_parse_loop ():
> /GstPipeline:pipeline/GstURIDecodeBin:uridecodebin-0/GstDecodeBin:decodebin1/GstMpegAudioParse:mpegaudioparse1:\nstreaming
> stopped, reason not-linked (-1)"
>
> (for mp3 files)
>
> Please let me know if you need any more information.
>
> Cheers
>
> [1] … not necessarily since the last clementine update. This could also be
> releated to gstreamer 1.14.1.
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers unstable-debug
> APT policy: (650, 'unstable-debug'), (650, 'unstable'), (601, 'testing'),
> (600, 'experimental-debug'), (600, 'experimental'), (500, 'testing-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.16.0-1-amd64 (SMP w/4 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 clementine depends on:
> ii gstreamer1.0-plugins-base 1.14.1-1
> ii gstreamer1.0-plugins-good 1.14.1-1
> ii gstreamer1.0-plugins-ugly 1.14.1-1
> ii libc6 2.27-3
> ii libcdio17 1.0.0-2+b1
> ii libchromaprint1 1.4.3-2
> ii libcrypto++65.6.4-8
> ii libfftw3-double33.3.7-1+b1
> ii libgcc1 1:8.1.0-3
> ii libgdk-pixbuf2.0-0 2.36.11-2
> ii libglib2.0-02.56.1-2
> ii libgpod40.8.3-11
> ii libgstreamer-plugins-base1.0-0 1.14.1-1
> ii libgstreamer1.0-0 1.14.1-1
> ii libimobiledevice6 1.2.1~git20180302.3a37a4e-1
> ii libmtp9 1.1.13-1
> ii libmygpo-qt5-1 1.1.0-2
> ii libplist3 2.0.0-3
> ii libprojectm2v5 2.1.0+dfsg-4+b3
> ii libprotobuf10 3.0.0-9.1
> ii libpulse0 11.1-5
> ii libqt4-sql-sqlite 4:4.8.7+dfsg-17
> ii libqt5concurrent5 5.10.1+dfsg-7
> ii libqt5core5a5.10.1+dfsg-7
> ii libqt5dbus5 5.10.1+dfsg-7
> ii libqt5gui5 5.10.1+dfsg-7
> ii libqt5network5 5.10.1+dfsg-7
> ii libqt5opengl5 5.10.1+dfsg-7
> ii libqt5sql5 5.10.1+dfsg-7
> ii libqt5widgets5 5.10.1+dfsg-7
> ii libqt5x11extras55.10.1-2
> ii libqt5xml5 5.10.1+dfsg-7
> ii libsqlite3-03.23.1-1
> ii libstdc++6 8.1.0-3
> ii libtag1v5 1.11.1+dfsg.1-0.2+b1
> ii libx11-62:1.6.5-1
> ii projectm-data 2.1.0+dfsg-4
> ii zlib1g 1:1.2.11.dfsg-1
>
> Versions of packages clementine recommends:
> ii gstreamer1.0-pulseaudio 1.14.1-1
>
> Versions of packages clementine suggests:
> ii gstreamer1.0-plugins-bad 1.14.1-1
>
> -- no debconf information
>
Bug#900376: jnr-posix: Package 3.0.45 release
Package: src:jnr-posix Version: 3.0.42 Severity: wishlist As title says. 3.0.45 is required for JRuby 9.2.0.0. I already prepared the upload and I will complete it very soon. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche signature.asc Description: PGP signature
Bug#900375: hg-fast-export: Incompatible with mercurial 4.6
Package: hg-fast-export Version: 20140308-1 Severity: important The (old) version of hg-fast-export currently packaged is incompatible with mercurial 4.6. Support for this looks to be available upstream (https://github.com/frej/fast-export) on the hg-4.6-compat branch. There are also many other fixes & enhancements available upstream on the master branch. -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hg-fast-export depends on: ii git1:2.11.0-3+deb9u2 ii mercurial 4.6-2 ii python 2.7.13-2 hg-fast-export recommends no packages. hg-fast-export suggests no packages. -- no debconf information
Bug#898934: transition: libmygpo-qt
Hi Emilio, This transition seems almost done but clementine can't be built for now on armel and armhf. So could you please remove clementine armel and armhf binaries in *testing* to ease the migration of clementine to testing? Thanks, Thomas
Bug#900374: knot: running as a non-privileged user has problems, needs overhaul.
Package: knot Version: 1.3.0~rc3-1 In 509ad7fe247fea6f5a60f231b3496fb4d8bc778b, the knot package introduced the knot user and make certain files owned by it by default. /etc/knot/knot.conf also has a (commented-out) line: # user: knot:knot If the local administrator has launched knot without commenting out this line (which happens by default upon initial installation), then /var/lib/knot/timers/ (and its children lock.mdb and data.mdb) will be created owned by root:root. As a result, when the local administrator uncomments that line and tries to restart knot, knot raises errors in its logs with: warning: cannot open persistent timer DB '/var/lib/knot/timers' (operation not permitted) as a workaround, it's possible to change ownership over these timers, or to move them out of the way. But this shouldn't be necessary. The non-privileged user should be used by default, without needing any changes. Furthermore, it's not clear why /etc/knot or /etc/knot/knot.conf need to have the ownership/permissions restricted the way that they are (they are currently managed as knot:knot and unreadable by the world). If the daemon is running as the non-privileged user, presumably it should not be allowed to rewrite its own configuration file. I propose that these configuration files and directories should be owned by the superuser, not by the knot user. If they need to be made group "knot" for readability, that's a separate concern. I also doubt whether it makes sense for knot.conf avoid world-readablity by the package itself. As far as i can tell, there are three potentially secret things in knot.conf: * pin-value in keystore:config (for a pkcs11 keystore whose security is contingent on a PIN) * key:secret (for TSIG use) * acl information (for security-through-obscurity IP-filtered master/slave relationships) for installations that don't use these chocies, a world-readable knot.conf is probably fine. It's also simpler to maintain if they're root:root, and world-readable. So perhaps if the administrator of a knot server has secrets in this file, they can adjust the ownership and permissions accordingly, and the package doesn't need to do it manually. I think transitioning the package to always running the server as a non-privileged user, and leaving the files alone is right way to fix this bug. A clean transition should of course support existing installations without breaking them. for systems using systemd, the [Service] section of knot.service should probably contain: User=knot AmbientCapabilities=CAP_NET_BIND_SERVICE I'll probably try to make these changes (including backward-compatibility for prior installs) in knot before the release of buster, so that after the release of buster we can drop the backward compatibility steps. Please comment on this ticket if you have an objection to this privilege-limiting approach. --dkg signature.asc Description: PGP signature
Bug#870200: linking to mariadb bug report tool
Hi Harald, thank you for your help! Linking this bug to MariaDB bug report tool: https://jira.mariadb.org/browse/MDEV-13672 Faustin
Bug#865534: confirmed / steps / clarification
I can confirm the problem and I am able to reproduce it. Steps: 1/ on jessie, install mariadb-server and apparmor 2/ enable apparmor (on fresh jessie, it is not enabled by default for mysqld): https://wiki.debian.org/AppArmor/HowToUse?action=show=AppArmor%2FHowTo#Enable_AppArmor 3/ replace commented profile '/etc/apparmor.d/usr.sbin.mysqld' with https://salsa.debian.org/mariadb-team/mariadb-10.1/blob/stretch/support-files/policy/apparmor/usr.sbin.mysqld 4/ create empty file '/etc/apparmor.d/local/usr.sbin.mysqld' 5/ activate profile: $ sudo aa-enforce mysqld Setting /usr/sbin/mysqld to enforce mode. 6/ upgrade to stretch > So this needs to be fixed: > 1) Make sure the old AppArmor profile isn't loaded anymore. Disabling arbitrarily mysqld apparmor profile when it as been enabled may be considered as a security issue and it is clearly a lack of transparency to the user. So I think this is something that we can not do automatically during postinstall. > 3) Reload the AppArmor profile afterwards. By default, apparmor is now disabled for newer version of MariaDB (https://salsa.debian.org/mariadb-team/mariadb-10.1/blob/stretch/debian/apparmor-profile) But again for old installation, this decision belongs to the user. Regarding the workaround, I am not an apparmor expert but I think this is a cleaner way: $ sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/ $ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld Verify: $ sudo aa-status Finalize mariadb-server upgrade: $ sudo dpkg --configure mariadb-server For people who want to keep apparmor mysqld profile running, I would suggest editing the local profile '/etc/apparmor.d/local/usr.sbin.mysqld' to their needs: - https://blogs.oracle.com/jsmyth/apparmor-and-mysql - https://bugs.launchpad.net/ourdelta/+bug/491349 > 2) A message should be printed that this mighht take a while and to be > patient. This is a good suggestion and I will check if it is not already on our todo list for the next release. > I suspect this is AppArmor-related. However, the resolution > instructions are also wrong, referencing /usr/scripts/scripts. Message resolution suggestion and detection is really not an easy thing, and in that case, I see another problem, path is wrong. I have opened an issue on our bug tracking system (https://jira.mariadb.org/browse/MDEV-16321).
Bug#900373: libkscreenlocker5: kscreenlocker_greet may be frozen on resume from suspend to Ram
Package: libkscreenlocker5 Version: 5.12.2-1 Severity: important Dear Maintainer, After resume from suspend, kscreenlocker_greet is most often frozen and cannot be interacted with. This is a dual display setup, and, when this bug happens, the left display („primary” in systemsettings) is black, the frozen kscreenlocker is only shown on the right display. Killing kscreenlocker_greet from a root terminal will spawn a new kscreenlocker that behaves normaly. This is somewhat similiar to #852162, which is worse but no longer happens to me. Alex -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkscreenlocker5 depends on: ii kpackagetool5 5.46.0-1 ii libc6 2.27-3 ii libkf5configcore5 5.46.0-1 ii libkf5configgui5 5.46.0-1 ii libkf5coreaddons5 5.46.0-1 ii libkf5crash5 5.46.0-1 ii libkf5declarative55.46.0-1 ii libkf5globalaccel55.46.0-1 ii libkf5i18n5 5.46.0-1 ii libkf5idletime5 5.46.0-1 ii libkf5notifications5 5.46.0-1 ii libkf5package55.46.0-1 ii libkf5quickaddons55.46.0-1 ii libkf5waylandclient5 4:5.46.0-1 ii libkf5waylandserver5 4:5.46.0-1 ii libkf5windowsystem5 5.46.0-1 ii libpam0g 1.1.8-3.7 ii libqt5core5a 5.10.1+dfsg-7 ii libqt5dbus5 5.10.1+dfsg-7 ii libqt5gui55.10.1+dfsg-7 ii libqt5network55.10.1+dfsg-7 ii libqt5qml55.10.1-4 ii libqt5quick5 5.10.1-4 ii libqt5widgets55.10.1+dfsg-7 ii libqt5x11extras5 5.10.1-2 ii libseccomp2 2.3.3-2 ii libstdc++68-20171108-1 ii libwayland-client01.15.0-2 ii libwayland-server01.15.0-2 ii libx11-6 2:1.6.5-1 ii libxcb-keysyms1 0.4.0-1+b2 ii libxcb1 1.13-1 ii libxi62:1.7.9-1 Versions of packages libkscreenlocker5 recommends: ii kde-config-screenlocker 5.12.2-1 libkscreenlocker5 suggests no packages. -- no debconf information
Bug#900372: qemu-system-arm aarch64 / qemu-user-static (arm64): python3 seg faults
Package: qemu-system-arm Version: 2.12+dfsg-1+b1 Both qemu-system-aarch64 and qemu-user-static can't run python3.6 binaries in virtual machines (or bin-fmt's chroots), causing the binaries to segfault. This is particularly painful because lots of build-deps depend on python3-minimal which has been bumped to 3.6-minimal in sid. I tested same python3.6 packages in real arm64 hardware (ThunderX) and they worked fine. I backported latest qemu into debian sid and latest commit (e609fa71e8) works ok, python3 binaries don't segfault neither in fully emulated guests nor in containers running qemu-user-static. I'm using latest sid updated to the date. -Rafael
Bug#900371: ITP: libhttp-tiny-multipart-perl -- module to add post_multipart method to HTTP::Tiny
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libhttp-tiny-multipart-perl Version : 0.08 Upstream Author : Renee Baecker * URL : https://metacpan.org/release/HTTP-Tiny-Multipart * License : Artistic-2.0 Programming Lang: Perl Description : module to add post_multipart method to HTTP::Tiny HTTP::Tiny::Multipart adds a post_multipart method to HTTP::Tiny. HTTP::Tiny is a very simple HTTP/1.1 client, designed for doing simple requests without the overhead of a large framework like LWP::UserAgent, and is part of perl core since 5.13.9 The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#900286: ITP: spm -- simple password manager
On Tue, 2018-05-29 at 13:11 -0400, Nicholas D Steeves wrote: > On Mon, May 28, 2018 at 07:46:59PM +0200, Jakub Wilk wrote: > > * Paride Legovini , 2018-05-28, 17:33: > > > spm is a single fully POSIX shell compliant script > > [...] > > > In Debian the script will be installed as 'spm.sh' > > > > That would be against Policy §10.4. > > Please talk to upstream about choosing a different name. > > Are there any reasons why a debian/spm.install like this one wouldn't > be an appropriate solution to §10.4? > > #!/usr/bin/dh-exec > spm.sh => /usr/bin/spm /usr/bin/spm is already shipped by another package as noted in the initial report. Renaming the binary to simple-password-manager or so would probably work. Ansgar
Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404
On Tue, May 29, 2018 at 12:35:59PM -0400, Joey Hess wrote: > Any chance you can build git-annex from source, so we can try a few > modifications to try to narrow this down? > > sudo apt-get build-dep git-annex > apt-get source git-annex > cd git-annex-6.20180509 > make > PATH=`pwd`:$PATH > export PATH > > Then see if you can reproduce the problem, ... and it turns out my build does not reproduce the problem. I ran "git annex assistant" ten times with the Debian package, and 10 times with the source built as above. When it started up, I followed up with "git annex assistant --stop". Results are: Debian package: try 1–4 fail, 5 ok, 6–10 fail My build: try 1–10 ok So just to be sure, I rm -Rf'd that source tree, extracted it again (dpkg-source -x) and did a dch --bin-nmu to up the version. Followed by debuild -b -uc to make a new package, and installed it. My package: try 1–10 ok I'm running diffoscope on the two packages, but it's been thinking long and hard on git-annex's .text segment, so I'm guessing it won't be useful. I'm not sure where to go for here — I'm not sure if forcing a rebuild would fix it in Debian. Or how much work it'd be for me to reproduce Debian's build environment from https://buildd.debian.org/status/fetch.php?pkg=git-annex=amd64=6.20180509-1=1525912069=0 in a VM and see if then I can reproduce a broken build, and if that'd really help us learn anything. -- Democracy is a process by which the people are free to choose the man who will get the blame. -- Laurence J. Peter
Bug#900370: iptraf-ng: Iptraf-ng crashes when using logging option.
Package: iptraf-ng Version: 1:1.1.4-6+b1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** This may have been something re-introduced as a patch was provided 4 years ago (https://github.com/pld-linux/iptraf-ng) for a floating point exception error from an interval being 0 and used in tcplog_flowrate_msg(). * What led up to the situation? When configured to write logs to a file, iptraf-ng will crash with a floating point exception. The log file is created and data is logged to it prior to crashing. GDB basic info. Program received signal SIGFPE, Arithmetic exception. 0x55566bfd in ?? () (gdb) bt #0 0x55566bfd in ?? () #1 0x55567d60 in ?? () #2 0x555646a1 in ?? () #3 0x7e34 in ?? () #4 0x773ef2e1 in __libc_start_main (main=0x7490, argc=1, argv=0x7fffe668, init=, fini=, rtld_fini=, stack_end=0x7fffe658) at ../csu/libc-start.c:291 #5 0x7eda in ?? () (gdb) f 4 #4 0x773ef2e1 in __libc_start_main (main=0x7490, argc=1, argv=0x7fffe668, init=, fini=, rtld_fini=, stack_end=0x7fffe658) at ../csu/libc-start.c:291 291 ../csu/libc-start.c: No such file or directory. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages iptraf-ng depends on: ii libc6 2.24-11+deb9u3 ii libncursesw6 6.1+20180210-4 ii libtinfo6 6.1+20180210-4 iptraf-ng recommends no packages. iptraf-ng suggests no packages. -- no debconf information
Bug#875790: fixed in scilab 6.0.1-2
Control: reopen -1 Control: retitle -1 scilab: depends on openjdk-8 On Mon, 14 May 2018 21:21:44 +0200 Emilio Pozuelo Monfort wrote: > On Fri, 04 May 2018 05:05:48 + Julien Puydt wrote: > > . > >[ Emmanuel Bourg ] > >* Fixed the build failure with Java 9 (Closes: #875790) > > . > >[ Julien Puydt ] > >* Depend on unversioned tcl/tk (Closes: #803526) > >* Force use of java 8 since later versions aren't supported (Closes: > > #875790) > > So is the build really fixed with Java 9 now? If so, why force Java 8? The > build > is failing on i386 with Java 8, so it may be good to go back to default Java > (9 > at the moment) to attempt to fix the build. Besides the FTBFS on i386 with openjdk-8: we are also moving to OpenJDK 11 for buster, and openjdk-8 will be removed from testing in due time. Thus please switch to openjdk 10 or 11 (or preferably to default-jdk). This is blocking the curl transition due to the FTBFS on i386, so I'd appreciate some quick action if possible. Thanks, Emilio
Bug#842815: Help needed for HDF5 1.10 transition of libsis-jhdf5-java
Hi, Andreas Tille a écrit le 28/05/2018 à 11:29 : > Hi folks from Debian Science, > > is there anybody out there who can help with some HDF5 1.10 transition? > > I admit I have no experience with HDF5 neither with Java - but the > migration would help a lot. > > Kind regards > >Andreas. As already stated in this thread [1] I think patching libsis-jhdf5-java is a huge task beyond my available time. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842815#55 > On Mon, May 28, 2018 at 09:18:28AM +0200, Bernd Rinn wrote: >> Hello Andreas, >> >> On 05/27/2018 07:12 AM, Andreas Tille wrote: >>> Hello Bernd, >>> >>> sorry for nagging again but we now have another Dependency from >>> sis-jhdf5 which makes a fix for this issue even more interesting. As I Have you considered using libhdf5-java or libjhdf5-java instead? _g. >>> said before I would also try a patch if you might hesitate to issue a >>> completely new release. >> >> It is embarrassing to admit that I still haven't found the time to port >> JHDF5 to HDF5 1.10. >> >> If you can come up with a patch to bridge to time that would be greatly >> appreciated! >> >> Kind regards, >> Bernd >> Andreas. >>> >>> On Wed, Sep 06, 2017 at 12:50:56PM +0200, Andreas Tille wrote: Hello Bernd, On Wed, 23 Nov 2016 06:54:21 +0100, you wrote > the migration of JHDF5 to HDF5 1.10 is ongoing and mostly depend on me > having a block of time I can spend on it. Your analysis of the work that > needs to be done is right from what I can see. The plan is to switch to > using the JNI library from the HDF group wherever possible (it may still > be necessary to have a small JNI library though as some calls appear to > be missing). > > I will keep you updated. Is there any news, may be only a patch for the existing version we could try to fix the Debian package? Kind regards Andreas. -- http://fam-tille.de ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging >>> >> >> -- >> Dr. Bernd Rinn >> Head Scientific IT Services >> ETH Zurich IT Services >> SIB Swiss Institute of Bioinformatics >> Weinbergstr. 11 (WEC D 19), 8092 Zürich, Switzerland, +41 44 632 0608 >> Mattenstr. 26 (BSB 1.01), 4058 Basel, Switzerland, +41 61 387 3130 >> > > > signature.asc Description: OpenPGP digital signature
Bug#900366: postinst creation of /etc/machine-id breaks CustomFirstBoot unit parameter
I spotted this when trying to use the ConditionFirstBoot option writing out and enabling a new systemd service in the installer, and wondering why it was never firing on the first 'real' boot. While I appreciate that removing machine-id or playing around with it are options, they aren't general ones - you wouldn't want to put 'rm /etc/machine-id' in a package for general distribution! The man page for systemd-machine-id-setup says: Use systemd-firstboot(1) to initialize the machine ID on mounted (but not booted) system images. which was what made me think that calling systemd-mahcine-id-setup in postinst might not be the correct thing to do, and perhaps enabling a systemd-firstboot.service might be another approach. (However I'm not that knowledgeable on the intricacies of systemd, so am happy to be wrong here). The 'inverse bug' as it were is then: if the postinst remains unchanged, what can be done to make it clear that ConditionFirstBoot is always False to those following the systemd docs and writing units? Thanks, Matthew On 29/05/18 17:17, Michael Biebl wrote: > Am 29.05.2018 um 16:53 schrieb Matthew Richardson: >> Package: systemd >> Version: 238-5 >> >> The postinst for the systemd deb pkg contains the following: >> >> # Create /etc/machine-id >> systemd-machine-id-setup >> >> This generates /etc/machine-id as the package is installed. >> >> However the systemd unit option ConditionFirstBoot uses the presence or >> absence of this file to detect whether or not this is the first boot. >> From 'man systemd.unit' >> >> "ConditionFirstBoot= takes a boolean argument. This condition may be >> used to conditionalize units on whether the system is booting up with an >> unpopulated /etc directory (specifically: an /etc with no >> /etc/machine-id). This may be used to populate /etc on the first boot >> after factory reset, or when a new system instance boots up for the >> first time." >> >> Since no unit can start until after systemd is installed, and the >> install always creates this file, this test will always be False which >> renders this option useless. > > Well, if you remove /etc/machine-id as part of your debootstrap process, > then /etc/machine-id will not be present during boot. > > Or if you use a stateless system, then /etc might be empty as well. > > So the Condition still makes sense. > > Can you elaborate, what this bug report is supposed to achieve? > > signature.asc Description: OpenPGP digital signature The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Bug#899406: requests.Session doesn't properly handle closed keep-alive sessions
Thank you for putting it in the right place Daniele. I added more detail on github, as requested. On Mon, May 28, 2018 at 9:16 PM, Daniele Tricoli wrote: > forwarded 899406 https://github.com/requests/requests/issues/4664 > thanks > > Hello Jonathan, > thanks for your report! > > On Wednesday, May 23, 2018 10:16:57 PM CEST Jonathan Lynch wrote: > > Package: python-requests > > Version: 2.18.4 > [CUT detailed description] > > I forwarded the issue upstream since it's not Debian specific. Do you have > a > test that is able to reproduce systematically the issue? If yes can you > attach > on upstream bug tracker? > > Kind regards, > > -- > Daniele Tricoli 'eriol' > https://mornie.org
Bug#900286: ITP: spm -- simple password manager
On Mon, May 28, 2018 at 07:46:59PM +0200, Jakub Wilk wrote: > * Paride Legovini , 2018-05-28, 17:33: > > spm is a single fully POSIX shell compliant script [...] > > In Debian the script will be installed as 'spm.sh' > > That would be against Policy §10.4. > Please talk to upstream about choosing a different name. Are there any reasons why a debian/spm.install like this one wouldn't be an appropriate solution to §10.4? #!/usr/bin/dh-exec spm.sh => /usr/bin/spm I guess it might be annoying to carry a patch for a manpage that would effectively s/spm.sh/spm/... Cheers, Nicholas signature.asc Description: PGP signature
Bug#899019: Test Fix
tags 899019 + patch thanks The attached patch addresses the failure. diff --git a/debian/tests/demoLaplacian.py b/debian/tests/demoLaplacian.py index 230f3e9..168d009 100755 --- a/debian/tests/demoLaplacian.py +++ b/debian/tests/demoLaplacian.py @@ -56,7 +56,7 @@ tleft = abs(fnor[1,:]+1) < 1e-14 ttop = abs(fnor[0,:]-1) < 1e-14 fleft = np.compress(tleft, flst, axis=1) ftop = np.compress(ttop, flst, axis=1) -fneum = np.compress(True - ttop - tleft, flst, axis=1) +fneum = np.compress(True ^ ttop ^ tleft, flst, axis=1) # mark it as boundary DIRICHLET_BOUNDARY_NUM1 = 1
Bug#900337: firejail: Users from user database should be able to run firejail regardless of UID_MIN on the system
Control: forwarded -1 https://github.com/netblue30/firejail/issues/1964 On Tue, May 29, 2018 at 11:35:24AM +0200, Alex Mestiashvili wrote: > not able to use firejail after updating to 0.9.54-1 due to new check for > UID_MIN. My user is a system user with UID 256. > > Firejail should not ignore users defined in the users database > /etc/firejail/firejail.users even if they have uid lower that UID_MIN > (defined in /etc/login.defs on a buildd!) Thanks for reporting this. I forwarded it upstream and suggested to obtain the limit at runtime instead of hardcoding it. > @@ -83,6 +78,11 @@ int firejail_user_check(const char *name > > fclose(fp); > return 0; > + > + // other system users will run the program as is > + uid_t uid = getuid(); > + if ((uid < UID_MIN && uid != 0) || strcmp(name, "nobody") == 0) > + return 0; > } > > // add a user to the database This will not work, as you moved the block behind a return statement. The code can now never be reached. Kind regards, Reiner signature.asc Description: PGP signature
Bug#899073: [uscan][RFC] please support something like uscan components for multiple tar.gz
On Sat, May 19, 2018 at 10:49 PM, Bastien ROUCARIES wrote: > On Fri, May 18, 2018 at 10:50 PM, Chris Lamb wrote: >> severity 899073 wishlist >> tags 899073 + moreinfo >> thanks >> >> [Tagging +moreinfo due to RFC status & "wishlist" as it's a feature request] >> >> Hi Bastien, >> >>> For packaging a lot of too small node package we will like that uscan >>> support >>> to download from multiple source with different version ala uscan component. >> >> If I understand this correctly, you plan to ship similar/related node >> packages as separate components of a single source package. > > Yes like node-tap that ship (using manual uscan) one line source code > package own-or and own-or-env, or node-function bind that ship one > liner node-has > >> >>> It will decrease the load of small pacakge for us and decrease the load of >>> ftpmasters >> >> If so, could you clarify exactly how this would help ftpmaster? The >> amount of code to be reviewed remains constant, merely that the number >> of source packages is far fewer from a statistics point of view. > > The number of line of code to review will increase but the number of > package under 1ko will decrease. And i think it is easier for you to > review > a tar.gz decompressed, than to reviewing copyright of patches (usually > small package are added with the help of patch). That why I said, it > will simplify your work. > >> Indeed, it might even be additional work for all as, for example, >> problem with (eg.) component 14 out of 27 might would delay the entire >> thing and cause confusion about exactly which package one is referring >> to at any point in time. > > I understand, but it will reserved to only really small package like > the node-is-odd that sit in the NEWS queue (that could be I think > rejected) . This kind of package could be merge with the rdepend with > no loss of generality. > > We could not get upstream to be (censured), but we could try something > on your side. Ping ? > > Bastien > >> >> Best wishes, >> >> -- >> ,''`. >> : :' : Chris Lamb >> `. `'` la...@debian.org / chris-lamb.co.uk >>`-
Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404
Any chance you can build git-annex from source, so we can try a few modifications to try to narrow this down? sudo apt-get build-dep git-annex apt-get source git-annex cd git-annex-6.20180509 make PATH=`pwd`:$PATH export PATH Then see if you can reproduce the problem, and then try applying the attached patch, and re-making and see if it avoids the problem. The patch tries to avoid doing anything before forking when starting the assistant, so it should do only the same pre-fork operations as git-annex watch. (Other than some differences due to argument parsing I suppose.) -- see shy jo diff --git a/Command/Assistant.hs b/Command/Assistant.hs index 70088674d..b148b2566 100644 --- a/Command/Assistant.hs +++ b/Command/Assistant.hs @@ -60,8 +60,8 @@ start o liftIO autoStop stop | otherwise = do - liftIO ensureInstalled - ensureInitialized + --liftIO ensureInstalled + --ensureInitialized Command.Watch.start True (daemonOptions o) (startDelayOption o) startNoRepo :: AssistantOptions -> IO () signature.asc Description: PGP signature
Bug#900210: thunderbird: Thunderbird AppArmor config disables ability to send entirely
On 5/28/18 11:01 PM, Carsten Schoenert wrote: Hello intri, hello Vincas, this looks like something you guys should have a look at please. Thanks! I'll take a look into this.
Bug#900366: postinst creation of /etc/machine-id breaks CustomFirstBoot unit parameter
Am 29.05.2018 um 16:53 schrieb Matthew Richardson: > Package: systemd > Version: 238-5 > > The postinst for the systemd deb pkg contains the following: > > # Create /etc/machine-id > systemd-machine-id-setup > > This generates /etc/machine-id as the package is installed. > > However the systemd unit option ConditionFirstBoot uses the presence or > absence of this file to detect whether or not this is the first boot. > From 'man systemd.unit' > > "ConditionFirstBoot= takes a boolean argument. This condition may be > used to conditionalize units on whether the system is booting up with an > unpopulated /etc directory (specifically: an /etc with no > /etc/machine-id). This may be used to populate /etc on the first boot > after factory reset, or when a new system instance boots up for the > first time." > > Since no unit can start until after systemd is installed, and the > install always creates this file, this test will always be False which > renders this option useless. Well, if you remove /etc/machine-id as part of your debootstrap process, then /etc/machine-id will not be present during boot. Or if you use a stateless system, then /etc might be empty as well. So the Condition still makes sense. Can you elaborate, what this bug report is supposed to achieve? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#900369: mps-youtube: defaults to checking for updates in exit
Package: mps-youtube
Version: 0.2.7.1-2
Severity: minor
Tags: patch
Dear Maintainer,
the checkupdate config option is initialized with True, leading mpsyt to check
for updates on each quit.
Stefan
-- System Information:
Debian Release: 9.4
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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: sysvinit (via /sbin/init)
Versions of packages mps-youtube depends on:
ii ffmpeg 7:3.2.10-1~deb9u1
ii mpv0.23.0-2+deb9u2
ii python33.5.3-1
ii python3-pafy 0.5.2-2
ii python3-pkg-resources 33.1.1-1
Versions of packages mps-youtube recommends:
ii libnotify40.7.7-2
pn python3-dbus
ii python3-gi3.22.0-2
ii xclip 0.12+svn84-4+b1
mps-youtube suggests no packages.
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/mps_youtube/config.py
(from mps-youtube package)
--- /tmp/config.py 2018-05-29 17:53:09.014921914 +0200
+++ config.py 2018-05-29 17:53:30.503195977 +0200
@@ -288,7 +288,7 @@
ConfigItem("playerargs", ""),
ConfigItem("encoder", 0, minval=0, check_fn=check_encoder),
ConfigItem("notifier", ""),
-ConfigItem("checkupdate", True),
+ConfigItem("checkupdate", False),
ConfigItem("show_mplayer_keys", True, require_known_player=True),
ConfigItem("fullscreen", False, require_known_player=True),
ConfigItem("show_status", True),
Bug#804077: parallel-ssh manpage: typo: paralllel -> parallel
Package: pssh Version: 2.3.1-1 Followup-For: Bug #804077 Other manpages are funky, too: parallel-rsync -- parallel process kill program
Bug#900368: RFS: pygithub/1.40a3-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pygithub" * Package name: pygithub Version : 1.40a3-1 Upstream Author : Author : Adam Dangoor Vincent Jacques < vinc...@vincent-jacques.net> Jeremy Phelps < jphe...@linuxfoundation.org> * URL : https://pypi.python.org/pypi/PyGithub * License : LGPL-3+ Section : python It builds those binary packages: python-github - Access to full Github API v3 from Python2 python3-github - Access the full Github API v3 from Python3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pygithub or https://salsa.debian.org/python-team/modules/pygithub Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pygithub/pygithub_1.40a3-1.dsc or git clone g...@salsa.debian.org:python-team/modules/pygithub.git More information about pygithub can be obtained from http://pygithub.readthedocs.io/ Changes since the last upload: * New upstream release * Update Standards-Version from 4.1.3 to 4.1.4 version * Add Uploaders field from debian/control to intent to adopt the package (Closes: #851187) Regards, Emmanuel Arias -- Arias Emmanuel https://www.linkedin.com/in/emmanuel-arias-437a6a8a http://eamanu.com
Bug#804077: parallel-ssh manpage: typo: paralllel -> parallel
Package: pssh Version: 2.3.1-1 Followup-For: Bug #804077 Regardless of the years going by this report is still valid. Mind you, I realize that the package wasn't touched since 2014 and that its upstream changed and moved. NMU time? :-)
Bug#900367: xtensor-python: autopkgtests fail when including Python.h
Source: xtensor-python Version: 0.12.4-1 Severity: normal Dear Maintainer, The autopkgtests for xtensor-python fail to link to Python.h when building, which causes them to fail. See, for example, [0]. Some brief investigation suggests that cmake isn't being correctly configured to perform the linking, even though the headers are available in the testbed. Thanks, Dan [0] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/x/xtensor-python/20180529_025953_a27b6@/log.gz
Bug#900366: postinst creation of /etc/machine-id breaks CustomFirstBoot unit parameter
Package: systemd Version: 238-5 The postinst for the systemd deb pkg contains the following: # Create /etc/machine-id systemd-machine-id-setup This generates /etc/machine-id as the package is installed. However the systemd unit option ConditionFirstBoot uses the presence or absence of this file to detect whether or not this is the first boot. From 'man systemd.unit' "ConditionFirstBoot= takes a boolean argument. This condition may be used to conditionalize units on whether the system is booting up with an unpopulated /etc directory (specifically: an /etc with no /etc/machine-id). This may be used to populate /etc on the first boot after factory reset, or when a new system instance boots up for the first time." Since no unit can start until after systemd is installed, and the install always creates this file, this test will always be False which renders this option useless. signature.asc Description: OpenPGP digital signature The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Bug#895033: New upstream release
Hi Daniel On 29/05/2018 15:38, Daniel Watkins wrote: 1.4.0 has just been released upstream[0]; this includes a fix to be compatible with the new version of python-ase. [0] https://pypi.org/project/gpaw/1.4.0/ Excellent! I have been waiting for that, thanks for letting me know. Regards Graham
Bug#900365: libqt5opengl5: Sometimes crash (not core dumped) after "XIO: fatal IO error 0 (Success) on X server"
Package: libqt5opengl5
Version: 5.10.1+dfsg-7
Severity: important
Dear Maintainer,
After update to this version,
When running some programs, i.e. FCITX-TOOLBER-QT, programs suddenly crashs.
This is *not* SEGV.
Regards,
Ohta.
I got log with xtrace, programs crashed after below messages:
---
000:>:01cb: Event PropertyNotify(28) window=0x0445
atom=0x161("_NET_WM_NAME") time=0x04a61cf2 state=NewValue(0x00)
000:>:01cb: Event PropertyNotify(28) window=0x0445 atom=0x27("WM_NAME")
time=0x04a61cf8 state=NewValue(0x00)
000:>:01cb:32: Reply to GetInputFocus: revert-to=Parent(0x02) focus=0x018b
000:<:01cc: 16: Request(78): CreateColormap alloc=None(0x00) mid=0x0441
window=0x05c5 visual=0x040c
000:<:01cd: 48: Request(1): CreateWindow depth=0x18 window=0x0449
parent=0x05c5 x=0 y=0 width=100 height=100 border-width=0
class=InputOutput(0x0001) visual=0x040c
value-list={background-pixel=0x00ff border-pixel=0x
override-redirect=true(0x01) colormap=0x0441}
000:<:01ce: 8: Request(79): FreeColormap cmap=0x0441
000:<:01cf: 8: DRI2-Request(155,3): CreateDrawable drawable=0x0449
000:<:01d0: 12: Request(98): QueryExtension name='DRI2'
000:>:01d0:32: Reply to QueryExtension: present=true(0x01) major-opcode=155
first-event=119 first-error=0
000:<:01d1: 12: DRI2-Request(155,12): SwapInterval drawable=0x0449
interval=1
000:<:01d2: 20: DRI2-Request(155,7): GetBuffersWithFormat drawable=0x0449
attachments={attachment=BackLeft(0x0001) format=0x0018};
000:>:01d2:52: Reply to GetBuffersWithFormat: width=100 height=100
buffers={attachment=BackLeft(0x0001) name=0x0005 pitch=512
cpp=4 flags=0x};
000:<:01d3: 8: Request(4): DestroyWindow window=0x0449
000:<:01d4: 52: GLX-Request(152,34): glXCreateContextAttribsARB opcode=0x98
opcode2=0x22
unparsed-data=0x0b,0x00,0x40,0x04,0x25,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x08,0x00,0x40,0x04,0x01,0x00,0x00,0x00,0x03,0x00,0x00,0x00,0x91,0x20,0x00,0x00,0x02,0x00,0x00,0x00,0x92,0x20,0x00,0x00,0x00,0x00,0x00,0x00,0x26,0x91,0x00,0x00,0x04,0x00,0x00,0x00;
000:<:01d5: 4: Request(43): GetInputFocus
000:>:01d5:32: Reply to GetInputFocus: revert-to=Parent(0x02)
focus=0x018b
000:<:01d6: 16: Request(78): CreateColormap alloc=None(0x00)
mid=0x044a window=0x05c5 visual=0x040c
000:<:01d7: 48: Request(1): CreateWindow depth=0x18 window=0x044c
parent=0x05c5 x=0 y=0 width=100 height=100 border-width=0
class=InputOutput(0x0001) visual=0x040c
value-list={background-pixel=0x00ff border-pixel=0x
override-redirect=true(0x01) colormap=0x044a}
000:<:01d8: 8: Request(79): FreeColormap cmap=0x044a
000:<:01d9: 8: DRI2-Request(155,3): CreateDrawable drawable=0x044c
000:<:01da: 12: DRI2-Request(155,12): SwapInterval drawable=0x044c
interval=1
000:<:01db: 20: DRI2-Request(155,7): GetBuffersWithFormat drawable=0x044c
attachments={attachment=BackLeft(0x0001) format=0x0018};
000:>:01db:52: Reply to GetBuffersWithFormat: width=100 height=100
buffers={attachment=BackLeft(0x0001) name=0x0007 pitch=512 cpp=4
flags=0x};
000:<:01dc: 8: Request(4): DestroyWindow window=0x044c
000:<:01dd: 52: GLX-Request(152,27): glXCreatePbuffer opcode=0x98 opcode2=0x1b
unparsed-data=0x00,0x00,0x00,0x00,0x25,0x01,0x00,0x00,0x0d,0x00,0x40,0x04,0x04,0x00,0x00,0x00,0x41,0x80,0x00,0x00,0x01,0x00,0x00,0x00,0x40,0x80,0x00,0x00,0x01,0x00,0x00,0x00,0x1c,0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x1b,0x80,0x00,0x00,0x00,0x00,0x00,0x00;
000:<:01de: 16: Request(53): CreatePixmap depth=0x18 pid=0x044e
drawable=0x05c5 width=1 height=1
000:<:01df: 8: DRI2-Request(155,3): CreateDrawable drawable=0x044e
000:<:01e0: 12: DRI2-Request(155,12): SwapInterval drawable=0x044e
interval=1
000:<:01e1: 20: DRI2-Request(155,7): GetBuffersWithFormat drawable=0x044e
attachments={attachment=BackLeft(0x0001)format=0x0018};
XIO: fatal IO error 0 (Success) on X server ":9"
after 481 requests (481 known processed) with 0 events remaining.
-
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'oldstable'),
(1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to ja_JP.UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to ja_JP.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libqt5opengl5 depends on:
ii libc6 2.27-3
ii libqt5core5a [qtbase-abi-5-10-0] 5.10.1+dfsg-7
ii libqt5gui55.10.1+dfsg-7
ii libqt5widgets55.10.1+dfsg-7
ii libstdc++68.1.0-3
libqt5opengl5 recommends no packages.
libqt5opengl5 suggests no
Bug#858930: potential patch available
https://github.com/openwrt/packages/pull/6141 was recently submitted to OpenWRT, and also apparently upstream. It makes use of openssl-compat.[ch] from https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes, which is unfortunate, but may be the best we're going to get. I haven't yet tested this change. noah signature.asc Description: PGP signature
Bug#900145: Bug#900352: new xorg-server version causes a random freezes in plasmashell
Hi. Maximiliano Curia - 29.05.18, 14:18: > Package: src:xorg-server > Version: 2:1.20.0-2 > Severity: critical > Tags: upstream […] > The severity is set as it breaks "unrelated programs" although I'm not > sure a desktop environment can be called "unrelated" to x, but in any > case, it would be better if this version of xorg does not migrate to > testing till this is fixed. Probably related: xserver-xorg-core: flickering, black screen and modeset driver error: flip queue failed: Cannot allocate memory https://bugs.debian.org/900333 But depends on whether you use modesettings driver and have your Xorg log spammed with: [ 1201.939] (WW) modeset(0): flip queue failed: Cannot allocate memory [ 1201.939] (WW) modeset(0): Page flip failed: Cannot allocate memory [ 1201.939] (EE) modeset(0): present flip failed Thanks, -- Martin
Bug#891727: NMU
Because of: 1. fix for this bug is in git from 1st March (almost ~3 mons) 2. I asked Sandro Tosi at 10th May for upload, he told me "no, please hold" 3. this is release-critical bug older than 7 days 4. there is no reply from maintainer for more than 7 days in this bug I done NMU to DELAYED/0. Debdiff attached. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B pyopenssl_17.5.0-1.1.patch Description: Binary data
Bug#900356: jabref: JabRef does no longer start with Java8
On Tue, 29 May 2018 14:41:14 +0200, Andreas Gocht wrote: > I recently tried to start JabRef using my default Java8 version. I got the > following error: > > Unrecognized option: --add-modules=java.se.ee > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > I realised, that --add-modules=java.se.ee might be needed for Java9, so I > installed openjdk-9-jre which solved the problem. Thanks for your bug report! Indeed, the interaction between JabRef and various openjdk-* versions is a bit messy. Looking at the recent evolution of debian/control, I note that there's no default-jre or openjdk-* in Depends any more. The recent changes were: "default-jre (>= 2:1.8) | java8-runtime" → "openjdk-8-jre" → "" I guess, adding something like "default-jre (>= 2:1.9) | java9-runtime" should help (java9-runtime is provided by default-jre (2:1.10-65), default-jre (2:1.10-66), openjdk-10-jre (10.0.1+10-4), openjdk-11-jre (11~13-2), openjdk-11-jre (11~15-1), openjdk-9-jre (9.0.4+12-4)). Tony, what do you think? PS and JFTR: `JABREF_JAVA_OPTS="" jabref' might have worked with openjdk-8 as well. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Bruce Springsteen: The Fuse signature.asc Description: Digital Signature
Bug#900354: lintian: warn against guarding adduser/addgroup calls
On 05/29/2018 04:28 PM, Chris Lamb wrote: > tags 900354 + moreinfo > thanks > > Hi Julien, > > Thanks for the report. > >> <@weasel> "guarding adduser calls considered harmful" > > … regardless of --system or? oh, some concrete examples of "good" and > "bad" would be really helpful here in ensuring we implement exactly > what you after if you could spend a couple of seconds on that? > I would think adduser/addgroup without --system in maintainer scripts should be verboten altogether. I'll try to poke through codesearch to find other examples later. Cheers, Julien
Bug#900354: lintian: warn against guarding adduser/addgroup calls
tags 900354 + moreinfo thanks Hi Julien, Thanks for the report. > <@weasel> "guarding adduser calls considered harmful" … regardless of --system or? oh, some concrete examples of "good" and "bad" would be really helpful here in ensuring we implement exactly what you after if you could spend a couple of seconds on that? Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#899240: debian-installer: blank screen on boot (6th Gen. ThinkPad X1)
On 21/05 03:47, Matti Pöllä wrote: > booting to Debian Installer fails on a 6th Generation Lenovo ThinkPad > X1 (type 20KH-006MMX) with the following symptoms: > > * Boot from a Debian installation media (mini.iso 2018-05-18 on a USB > drive). Also tested with Wheezy, Jessie, Stretch and Testing amd64 > ISOs. > > * GRUB menu (version 2.02-2) shows options "Install", "Advanced > options" and "Install with speech synthesis". > > * On entering "Install", the screen goes blank. The machine is still > powered on and the keyboard leds respond to, e.g., the "mute" > button. Switching to virtual terminals does not help as the screen > appears dead. This issue is reproducible if the installer is starting in UEFI mode (grub says "Debian GNU/Linux UEFI Installer menu") but CSM Support is disabled in the Thinkpad Setup screen, which is the one you access by pressing F1 at boot. Set CSM Support to "Yes" under Startup -> UEFI/Legacy Boot to get past this. Alternatively, set "UEFI/Legacy Boot" to "Legacy Only", in which case the installer will start in BIOS mode. > Booting to a live environment using debian-live-9.3.0-amd64-gnome.iso > is not affected by the bug. The live system uses a full 2560x1440 > resolution on a 4.9.0-4-amd64 kernel. However, the "Install" option on > the same ISO results in a blank screen. This might be due to the live image including i915.ko in its initrd? It seems to get loaded pretty early on, much earlier than X. To doublecheck, remove boot=live from the kernel parameters. You'll be dropped into a initramfs shell and by running lsmod you'll see that i915 is loaded already. Also I've tried booting the live image with modprobe.blacklist=i915 and it behaves exactly like the installer with CSM Support disabled (immediate blank screen).
Bug#900165: calibre: segfault
> $ calibre-debug --test-build Uhh aahh, never tried this - I actually not even know what this should do ;-) Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#900352: new xorg-server version causes a random freezes in plasmashell
On 2018-05-29 02:18 PM, Maximiliano Curia wrote: > Package: src:xorg-server > Version: 2:1.20.0-2 > Severity: critical > Tags: upstream > > Hi, > > The severity is set as it breaks "unrelated programs" although I'm not > sure a desktop environment can be called "unrelated" to x, but in any > case, it would be better if this version of xorg does not migrate to > testing till this is fixed. > > The new xorg-server version seems to be causing plasmashell to freeze. > This was first reported in #900145, and it's also seen in other distros: > https://bugs.archlinux.org/task/58549 > > Upstream seems to have a patch for this (actually two patches that fix > this with two different aproaches), that I havent tested: > https://lists.x.org/archives/xorg-devel/2018-May/056829.html The upstream fix (in Mesa, where the bug was) is https://cgit.freedesktop.org/mesa/mesa/commit/?id=fe2edb25dd5628c395a65b60998f11e839d2b458 . -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature
Bug#900364: paraview: Paraview viewer mishandles fractional Qt screen scaling
Package: paraview Version: 5.4.1+dfsg4-3 Severity: normal I use a KDE desktop with fractional screen scaling enabled, more specifically, on my system ~> echo $QT_SCREEN_SCALE_FACTORS eDP-1=1.5;DP-1=1.5;HDMI-1=1.5;HDMI-2=1.5; As a result, only parts of the Paraview rendering window are actually used for rendering---the rest remains black. I'll attach a screenshot. The problem disappears when I set export QT_SCREEN_SCALE_FACTORS=eDP-1=1 The problem also disappears when I switch the Paraview window to full-screen mode. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages paraview depends on: ii libavcodec57 7:3.4.2-2+b1 ii libavformat57 7:3.4.2-2+b1 ii libavutil557:3.4.2-2+b1 ii libc6 2.27-3 ii libcgns3.3 3.3.0-6 ii libexpat1 2.2.5-3 ii libfreetype6 2.8.1-2 ii libgcc11:8.1.0-3 ii libgl1 1.0.0+git20180308-2 ii libgl2ps1.41.4.0+dfsg1-2 ii libglew2.0 2.0.0-5 ii libhdf5-1001.10.0-patch1+docs-4+b1 ii libjpeg62-turbo1:1.5.2-2+b1 ii libjsoncpp11.7.4-3 ii libnetcdf131:4.6.1-1 ii libogg01.3.2-1+b1 ii libopenmpi33.0.1.real-3 ii libpng16-161.6.34-1 ii libprotobuf10 3.0.0-9.1 ii libpython2.7 2.7.15-1 ii libqt5core5a 5.10.1+dfsg-6+b1 ii libqt5gui5 5.10.1+dfsg-6+b1 ii libqt5help55.10.1-2 ii libqt5network5 5.10.1+dfsg-6+b1 ii libqt5widgets5 5.10.1+dfsg-6+b1 ii libqt5x11extras5 5.10.1-2 ii libstdc++6 8.1.0-3 ii libswscale47:3.4.2-2+b1 ii libtheora0 1.1.1+dfsg.1-14+b1 ii libtiff5 4.0.9-5 ii libx11-6 2:1.6.5-1 ii libxml22.9.4+dfsg1-6.1 ii libxt6 1:1.1.5-1 ii python-autobahn17.10.1+dfsg1-2 ii python-matplotlib 2.1.1-2 ii python-mpi4py 2.0.0-3+b1 ii python-six 1.11.0-2 ii python-twisted 17.9.0-2 ii tcl [tclsh]8.6.0+9 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages paraview recommends: ii mpi-default-bin 1.13 ii paraview-doc 5.4.1+dfsg4-3 pn paraview-python Versions of packages paraview suggests: pn h5utils pn hdf5-tools -- no debconf information
