Bug#860291: unblock: cacti/0.8.8h+ds1-9
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Please unblock package cacti
In cacti 0.8.8h+ds1-9 I fixed a regression since PHP 7 became the default. In
the non-default (but relative common) situation where one wants to monitor some
variable with a higher frequency than once per minute, the poller would die on
calling split() which was deprecated in PHP 7, filed in bug 860271.
Debdiff attached.
unblock cacti/0.8.8h+ds1-9
- -- System Information:
Debian Release: 9.0
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'experimental'),
(200, 'testing'), (50, 'experimental'), (50, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAljwc5wACgkQnFyZ6wW9
dQo1Jgf+M62bB29LdleyDurk4svA18T2Cuw0ur+Br338xNvg0XplrrqE95Fz/J58
L1BOavJHXN9szM3KUo+0FB3DTi5kvqu2A7bZslbA26J418e1hafq6YDX6TyufpT9
0zZsG4lugaZayspKdDYToTpnVTloHk1/IfEp7p4DUE8uIyDgdRsPK5/H1NKscFsz
oGCUrSLrYknrmz4hwcV58xynaB6/47ZYpdCzmx1RFzP1F19rN/nK8oLxTrNjK33l
O+2ZF1XVbi79cxAN5QCk/BrTD7mzO4kiQOOs2Lmjk3KUjSMl0UusOvgk9oJhrnyf
K9dL0gcJ7Q2x87dX2XmtzMX3g/LLUA==
=eaEQ
-END PGP SIGNATURE-
diff -Nru cacti-0.8.8h+ds1/debian/changelog cacti-0.8.8h+ds1/debian/changelog
--- cacti-0.8.8h+ds1/debian/changelog 2016-12-14 21:20:24.0 +0100
+++ cacti-0.8.8h+ds1/debian/changelog 2017-04-13 22:05:30.0 +0200
@@ -1,3 +1,10 @@
+cacti (0.8.8h+ds1-9) unstable; urgency=medium
+
+ * Add enable_faster_polling_than_cron.patch to replace the use of the
+deprecated split() function (Closes: #860271)
+
+ -- Paul Gevers Thu, 13 Apr 2017 22:05:30 +0200
+
cacti (0.8.8h+ds1-8) unstable; urgency=medium
* Depend on libjs-jquery-jstree instead of using embedded version
diff -Nru cacti-0.8.8h+ds1/debian/patches/enable_faster_polling_than_cron.patch
cacti-0.8.8h+ds1/debian/patches/enable_faster_polling_than_cron.patch
--- cacti-0.8.8h+ds1/debian/patches/enable_faster_polling_than_cron.patch
1970-01-01 01:00:00.0 +0100
+++ cacti-0.8.8h+ds1/debian/patches/enable_faster_polling_than_cron.patch
2017-04-13 22:04:42.0 +0200
@@ -0,0 +1,23 @@
+Description: split() is deprecated in PHP 7, causing the code to fail
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/cacti/+bug/1662027
+Bug-Debian: https://bugs.debian.org/860271
+Source:
https://github.com/Cacti/cacti/commit/6b5931130770cdfa5baa68c43a913dcabf1c3970
+
+Index: cacti/poller.php
+===
+--- cacti.orig/poller.php
cacti/poller.php
+@@ -451,11 +451,9 @@ while ($poller_runs_completed < $poller_
+
+ /* sleep the appripriate amount of time */
+ if ($poller_runs_completed < $poller_runs) {
+- list($micro, $seconds) = split(' ', microtime());
+- $plugin_start = $seconds + $micro;
++ $plugin_start = microtime(true);
+ api_plugin_hook('poller_bottom');
+- list($micro, $seconds) = split(' ', microtime());
+- $plugin_end = $seconds + $micro;
++ $plugin_end = microtime(true);
+ if (($sleep_time - ($plugin_end - $plugin_start)) > 0) {
+ usleep(($sleep_time - ($plugin_end -
$plugin_start)) * 100);
+ }
diff -Nru cacti-0.8.8h+ds1/debian/patches/series
cacti-0.8.8h+ds1/debian/patches/series
--- cacti-0.8.8h+ds1/debian/patches/series 2016-12-14 21:16:53.0
+0100
+++ cacti-0.8.8h+ds1/debian/patches/series 2017-04-13 21:37:14.0
+0200
@@ -12,3 +12,4 @@
make_cacti_sql_mode-strict_compatible.patch
CVE-2016-2313-guest-auth.patch
fix_export_for_debian_packages.patch
+enable_faster_polling_than_cron.patch
Bug#860236: xen pv domU crash with 3.16 kernel and xen 4.8
On Thu, Apr 13, 2017 at 11:41:37PM +0100, Ben Hutchings wrote : > Control: tag -1 moreinfo > > On Thu, 2017-04-13 at 11:18 +0200, Vincent Legout wrote: > > Package: src:linux > > Version: 3.16.39-1+deb8u2 > > Severity: normal > > > > Hi, > > > > A xen jessie domU crashes around 5 minutes after the boot with the > > attached backtrace (at every boot). dom0 is also a Debian jessie running > > Xen 4.8. > > > > It only happens when the guest is in pv mode, it works fine with pvhvm. > > > > It also crashes with older 3.16 kernels and 4.0.2-1, but not with > > 4.2.1-1 (last 2 kernels from snapshot.debian.org). > > > > # uname -a > > 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux > > From the crash log: > > > [ 300.632389] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW > > 3.16.0-4-amd64 #1 Debian 3.16.39-1+deb8u2 > > This indicates there was an earlier WARNING message; what was that? Thanks for the answer. I got this WARNING after I increased verbosity in the command line: [ 300.636063] [ cut here ] [ 300.636102] WARNING: CPU: 0 PID: 0 at /build/linux-GSgHvp/linux-3.16.39/arch/x86/kernel/cpu/mcheck/mce.c:1307 mce_timer_fn+0x132/0x140() [ 300.636116] Modules linked in: x86_pkg_temp_thermal thermal_sys intel_rapl coretemp crc32_pclmul evdev aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper pcspkr cryptd autofs4 ext4 crc16 mbcache jbd2 xen_netfront xen_blkfront crct10dif_pclmul crct10dif_common crc32c_intel [ 300.636167] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-4-amd64 #1 Debian 3.16.39-1+deb8u2 [ 300.636178] 81514c81 0009 [ 300.636188] 81068867 88003f80ca00 88003f9eca00 0100 [ 300.636199] 81038a30 000f 81038b62 81a66e00 [ 300.636211] Call Trace: [ 300.636216][] ? dump_stack+0x5d/0x78 [ 300.636242] [] ? warn_slowpath_common+0x77/0x90 [ 300.636250] [] ? mce_cpu_restart+0x40/0x40 [ 300.636257] [] ? mce_timer_fn+0x132/0x140 [ 300.636267] [] ? call_timer_fn+0x31/0x140 [ 300.636274] [] ? mce_cpu_restart+0x40/0x40 [ 300.636284] [] ? run_timer_softirq+0x1e9/0x2f0 [ 300.636292] [] ? __do_softirq+0xf1/0x2d0 [ 300.636299] [] ? irq_exit+0x95/0xa0 [ 300.636309] [] ? xen_evtchn_do_upcall+0x35/0x50 [ 300.636319] [] ? xen_do_hypervisor_callback+0x1e/0x30 [ 300.636324][] ? xen_hypercall_sched_op+0xc/0x20 [ 300.636339] [] ? xen_hypercall_sched_op+0xc/0x20 [ 300.636349] [] ? xen_safe_halt+0xc/0x20 [ 300.636360] [] ? default_idle+0x19/0xd0 [ 300.636370] [] ? cpu_startup_entry+0x374/0x470 [ 300.636384] [] ? start_kernel+0x497/0x4a2 [ 300.636392] [] ? set_init_arg+0x4e/0x4e [ 300.636400] [] ? xen_start_kernel+0x569/0x573 [ 300.636413] ---[ end trace 7131ef713ca84161 ]--- Then, the same BUG as before. It always happens after 300 seconds. Vincent signature.asc Description: PGP signature
Bug#860293: reportbug: No CPU frequency scaling
Package: reportbug Version: 7.1.5 Severity: important Dear Maintainer, I use Debian Installer Stretch RC 3 to install Debian on my computer. I use "cat /proc/cpuinfo" to check the CPU frequency. there is no CPU frequency scaling. I got a fixed 3.20 GHz frequency. My CPU is Intel i7 6900k. the frequency is from 1.2 GHz to 4.0 GHz motherboard is ASUS x99-E WS USB3.1 I tested Debian 8.7 and ubuntu 16.04.2, the CPU frequency scaling is working properly. I also use the CD image download from debian.org. to boot my computer. then I enter root shell and run "cat /proc/cpuinfo". When I use CD image for Debian 8.7, I can see frequency scaling. But when I use CD image for Debian Installer Stretch RC 3， I got a fixd 3.20 GHz. -- Package-specific info: ** Environment settings: INTERFACE="gtk2" ** /home/alvin/.reportbugrc: reportbug_version "7.1.5" mode novice ui gtk2 email "alvin.zh...@gmail.com" no-cc header "X-Debbugs-CC: alvin.zh...@gmail.com" smtphost reportbug.debian.org -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages reportbug depends on: ii apt1.4 ii python3-reportbug 7.1.5 pn python3:any reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn dlocate pn emacs23-bin-common | emacs24-bin-common ii file 1:5.29-3 ii gir1.2-gtk-3.0 3.22.11-1 ii gir1.2-vte-2.91 0.46.1-1 ii gnupg2.1.18-6 pn postfix | exim4 | mail-transport-agent ii python3-gi 3.22.0-2 ii python3-gi-cairo 3.22.0-2 pn python3-gtkspellcheck pn python3-urwid ii xdg-utils1.1.1-1 Versions of packages python3-reportbug depends on: ii apt1.4 ii file 1:5.29-3 ii python3-debian 0.1.30 ii python3-debianbts 2.6.1 ii python3-requests 2.12.4-1 pn python3:any python3-reportbug suggests no packages. -- no debconf information
Bug#860294: Internal error and segmentation fault after enabling horizontal or vertical graph
Package: saods9 Version: 7.5+repack1-1 Severity: important Forwarded: https://github.com/SAOImageDS9/SAOImageDS9/issues/30 When I enable one of the graphs in the "View" menu, I get an error box "An internal error has been detected [OK]" as soon as the mouse is in the image area, but outside of the borders of the FITS image. This window immediately re-appears as long as I don't move it to a place where the cursor is not left over such an area after the error box disappears. On the Debian build, I also get a segmentation fault when I am in within the borders of a FITS image, when calling Base::bltCut(char*, char*, Coord::Orientation, Vector const&) () in frame/frblt.C line 947. This does not appear in the original built. The first issue is solved with patch [1], the Debian specific problem however remains and needs some more investigation. [1] https://github.com/SAOImageDS9/SAOImageDS9/commit/edea206.patch
Bug#860146: python-formencode: Ships /usr/lib/py2.7/dist-p/docs/index.txt
tags 860146 + patch thanks Patch attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff --git a/debian/python-formencode.docs b/debian/python-formencode.docs new file mode 100644 index 000..bf4cbd5 --- /dev/null +++ b/debian/python-formencode.docs @@ -0,0 +1 @@ +docs/*.txt diff --git a/debian/python3-formencode.docs b/debian/python3-formencode.docs new file mode 100644 index 000..bf4cbd5 --- /dev/null +++ b/debian/python3-formencode.docs @@ -0,0 +1 @@ +docs/*.txt diff --git a/debian/rules b/debian/rules index 59fa9b9..7fd8f5c 100755 --- a/debian/rules +++ b/debian/rules @@ -7,7 +7,7 @@ export PYBUILD_NAME=formencode override_dh_auto_install: dh_auto_install --buildsystem=pybuild find debian/python-formencode/ -type d -name i18n -print0 | xargs --null --no-run-if-empty rm -rf - dh_install -X.po -X.py formencode/i18n/* /usr/share/locale/ + find debian/python-formencode/ -type d \( -name i18n -or -name docs \) -print0 | xargs --null --no-run-if-empty rm -rf override_dh_auto_test: # network is required for the http://this.domain.does.not.exist.example.org/test.html test
Bug#860295: gnuradio: QT Time Sink segfaults with trigger mode "tag"
Package: gnuradio
Version: 3.7.10.1-2
Severity: important
Tags: patch
Dear Maintainer,
When setting trigger mode to "tags", the QT Time Sink crashes.
This is reported upstream here:
https://github.com/gnuradio/gnuradio/pull/1275
The fix is to check that the variable "d_start" is larger or equal to 0.
Best regards,
Ruben
From: Ruben Undheim
Date: Fri Apr 14 10:03:58 CEST 2017
Subject: Prevents a segfault when using QT time sink
with trigger mode "tag"
Bug-Upstream: https://github.com/gnuradio/gnuradio/pull/1275
Forwarded: yes
Index: gnuradio-3.7.10.1/gr-qtgui/lib/time_sink_c_impl.cc
===
--- gnuradio-3.7.10.1.orig/gr-qtgui/lib/time_sink_c_impl.cc
+++ gnuradio-3.7.10.1/gr-qtgui/lib/time_sink_c_impl.cc
@@ -567,12 +567,15 @@ namespace gr {
nr, nr + nitems + 1,
d_trigger_tag_key);
if(tags.size() > 0) {
-d_triggered = true;
trigger_index = tags[0].offset - nr;
-d_start = d_index + trigger_index - d_trigger_delay - 1;
-d_end = d_start + d_size;
-d_trigger_count = 0;
-_adjust_tags(-d_start);
+int start = d_index + trigger_index - d_trigger_delay - 1;
+if (start >= 0) {
+d_triggered = true;
+d_start = start;
+d_end = d_start + d_size;
+d_trigger_count = 0;
+_adjust_tags(-d_start);
+}
}
}
Index: gnuradio-3.7.10.1/gr-qtgui/lib/time_sink_f_impl.cc
===
--- gnuradio-3.7.10.1.orig/gr-qtgui/lib/time_sink_f_impl.cc
+++ gnuradio-3.7.10.1/gr-qtgui/lib/time_sink_f_impl.cc
@@ -562,12 +562,15 @@ namespace gr {
nr, nr + nitems + 1,
d_trigger_tag_key);
if(tags.size() > 0) {
-d_triggered = true;
trigger_index = tags[0].offset - nr;
-d_start = d_index + trigger_index - d_trigger_delay - 1;
-d_end = d_start + d_size;
-d_trigger_count = 0;
-_adjust_tags(-d_start);
+int start = d_index + trigger_index - d_trigger_delay - 1;
+if (start >= 0) {
+d_triggered = true;
+d_start = start;
+d_end = d_start + d_size;
+d_trigger_count = 0;
+_adjust_tags(-d_start);
+}
}
}
signature.asc
Description: Digital signature
Bug#860296: lirc is spamming syslog with messages
Source: lirc Severity: important Dear Maintainer, System is an EEEPC 1005HAG, debian/testing, i386 Sadly I have to tell, the latest version of lirc is spamming syslog with mwessages. To make sure, it is not a problem of an earlier configuration, I deinstalled it completely and reinstalled it new. The message, which is spamming is the following: Apr 11 20:28:22 localhost lircd-0.9.4c[8159]: Error: Cannot glob /sys/class/ rc/rc0/input[0-9]*/event[0-9]* Apr 11 20:28:23 localhost lircd[8159]: lircd-0.9.4c[8159]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]* Apr 11 20:28:23 localhost lircd-0.9.4c[8159]: Error: Cannot glob /sys/class/ rc/rc0/input[0-9]*/event[0-9]* Apr 11 20:28:24 localhost lircd[8159]: lircd-0.9.4c[8159]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]* and so on. Note: Although I have no infrared hardware installed, this issue did not happen with earlier versions. As a workaround, I had to deinstall the package for now. It would be nice, if you could take an eye on it. Thank you very much! Best Hans -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#860297: torbrowser-launcher: it is not possible to launch 2 torbrowsers on the same host from 2 different users
Package: torbrowser-launcher Version: 0.2.6-3.1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? 2 people on the same system, from 2 different monitors both started torbrowser-launcher. * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? Only 1 person can start a torbrowser. The other person gets a graphical window with the message: Tor unexpectedly exited. This might be due to a bug in Tor itself, . * What outcome did you expect instead? Both people should be able to start torbrowser in parallel. Some more information about my system: bs@majestix:~$ dpkg -l | grep "\ ii wmctrl 1.07-7+b1 Versions of packages torbrowser-launcher recommends: ii tor 0.2.9.10-1 Versions of packages torbrowser-launcher suggests: pn apparmor ii python-pygame 1.9.1release+dfsg-10+b2 -- no debconf information
Bug#860298: undertaker requires whatthepatch
Package: undertaker Version: 1.6.1-4+b1 Severity: important Dear Maintainer, undertaker-checkpatch requires python module whatthepatch [1], but this is not packaged for Debian. Could you please package it? Workaround to install whatthepatch with pip isn't really a solution. $ /usr/bin/undertaker-checkpatch Traceback (most recent call last): File "/usr/bin/undertaker-checkpatch", line 28, in import vamos.defect_analysis as defect_analysis File "/usr/lib/python2.7/dist-packages/vamos/defect_analysis.py", line 23, in from vamos.block import Block File "/usr/lib/python2.7/dist-packages/vamos/block.py", line 20, in import whatthepatch ImportError: No module named whatthepatch [1] https://github.com/cscorley/whatthepatch Kind regards, Petr -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages undertaker depends on: ii git1:2.11.0-2 ii libboost-filesystem1.62.0 1.62.0+dfsg-4 ii libboost-regex1.62.0 1.62.0+dfsg-4 ii libboost-system1.62.0 1.62.0+dfsg-4 ii libboost-thread1.62.0 1.62.0+dfsg-4 ii libboost-wave1.62.01.62.0+dfsg-4 ii libc6 2.24-9 ii libgcc11:6.3.0-11 ii libstdc++6 6.3.0-11 ii python 2.7.13-2 pn python:any undertaker recommends no packages. undertaker suggests no packages. -- no debconf information
Bug#842534: libmodbus : package update
Dear Maintainer Is it planned to upgrade this package or is there any issue with it? The package version is quite old and stops in the compilation of other programs or libraries. Bests Cedric
Bug#860299: unblock: osm2pgsql/0.92.0+ds-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package osm2pgsql
It fixes two important issues reported to me by one of the developers
one was also reported in #860273.
unblock osm2pgsql/0.92.0+ds-2
Kind Regards,
Bas
diff -Nru osm2pgsql-0.92.0+ds/debian/changelog
osm2pgsql-0.92.0+ds/debian/changelog
--- osm2pgsql-0.92.0+ds/debian/changelog2016-12-16 11:34:24.0
+0100
+++ osm2pgsql-0.92.0+ds/debian/changelog2017-04-13 23:00:11.0
+0200
@@ -1,3 +1,18 @@
+osm2pgsql (0.92.0+ds-2) unstable; urgency=medium
+
+ * Add upstream patches from 0.92.x branch to fix two important issues:
+- Ignore relations with more than 32k members.
+ There is a hard restriction in the pgsql middle tables, where
+ relation members are indexed using a smallint. To remain
+ consistent, drop all relations which exceed this size.
+ https://github.com/openstreetmap/osm2pgsql/issues/713
+- Use the same logic for queuing pending ways with multi and pgsql.
+ Fixes ways disappearing from the output table.
+ https://github.com/openstreetmap/osm2pgsql/issues/735
+(closes: #860273)
+
+ -- Bas Couwenberg Thu, 13 Apr 2017 23:00:11 +0200
+
osm2pgsql (0.92.0+ds-1) unstable; urgency=medium
* New upstream release.
diff -Nru
osm2pgsql-0.92.0+ds/debian/patches/0001-ignore-relations-with-more-than-32k-members.patch
osm2pgsql-0.92.0+ds/debian/patches/0001-ignore-relations-with-more-than-32k-members.patch
---
osm2pgsql-0.92.0+ds/debian/patches/0001-ignore-relations-with-more-than-32k-members.patch
1970-01-01 01:00:00.0 +0100
+++
osm2pgsql-0.92.0+ds/debian/patches/0001-ignore-relations-with-more-than-32k-members.patch
2017-04-13 22:55:58.0 +0200
@@ -0,0 +1,20 @@
+Description: ignore relations with more than 32k members
+ There is a hard restriction in the pgsql middle tables, where
+ relation members are indexed using a smallint. To remain
+ consistent, drop all relations which exceed this size.
+Author: Sarah Hoffmann
+Origin:
https://github.com/openstreetmap/osm2pgsql/commit/ec9c84edbcbd0dafab6d6c30290083e75c023890
+Bug: https://github.com/openstreetmap/osm2pgsql/issues/713
+
+--- a/parse-osmium.cpp
b/parse-osmium.cpp
+@@ -176,6 +176,9 @@ void parse_osmium_t::relation(osmium::Re
+ if (rel.deleted()) {
+ m_data->relation_delete(rel.id());
+ } else {
++if (rel.members().size() > 32767) {
++return;
++}
+ convert_tags(rel);
+ convert_members(rel.members());
+ if (m_append) {
diff -Nru
osm2pgsql-0.92.0+ds/debian/patches/0001-Use-the-same-logic-for-queuing-pending-ways-with-mul.patch
osm2pgsql-0.92.0+ds/debian/patches/0001-Use-the-same-logic-for-queuing-pending-ways-with-mul.patch
---
osm2pgsql-0.92.0+ds/debian/patches/0001-Use-the-same-logic-for-queuing-pending-ways-with-mul.patch
1970-01-01 01:00:00.0 +0100
+++
osm2pgsql-0.92.0+ds/debian/patches/0001-Use-the-same-logic-for-queuing-pending-ways-with-mul.patch
2017-04-13 23:00:11.0 +0200
@@ -0,0 +1,27 @@
+Description: Use the same logic for queuing pending ways with multi and pgsql
+ Fixes ways disappearing from the output table.
+Author: Paul Norman
+Origin:
https://github.com/openstreetmap/osm2pgsql/commit/8ffe16e67da43fd531a5e73b10d31465324f4a91
+Bug: https://github.com/openstreetmap/osm2pgsql/issues/735
+Bug-Debian: https://bugs.debian.org/860273
+
+--- a/output-multi.cpp
b/output-multi.cpp
+@@ -92,7 +92,7 @@ void output_multi_t::enqueue_ways(pendin
+ }
+
+ //make sure to get this one as well and move to the next
+-if(popped == id) {
++if (popped > id) {
+ if (!ways_done_tracker->is_marked(popped) &&
id_tracker::is_valid(popped)) {
+ job_queue.push(pending_job_t(popped, output_id));
+ added++;
+@@ -143,7 +143,7 @@ void output_multi_t::enqueue_relations(p
+ }
+
+ //make sure to get this one as well and move to the next
+-if(popped == id) {
++if (popped > id) {
+ if(id_tracker::is_valid(popped)) {
+ job_queue.push(pending_job_t(popped, output_id));
+ added++;
diff -Nru osm2pgsql-0.92.0+ds/debian/patches/series
osm2pgsql-0.92.0+ds/debian/patches/series
--- osm2pgsql-0.92.0+ds/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ osm2pgsql-0.92.0+ds/debian/patches/series 2017-04-13 22:55:55.0
+0200
@@ -0,0 +1,2 @@
+0001-ignore-relations-with-more-than-32k-members.patch
+0001-Use-the-same-logic-for-queuing-pending-ways-with-mul.patch
Bug#850629: Easy fix
Control: tags -1 + patch
thanks
The below patch fixes this (highly annoying) behaviour for me.
Description: Don't spawn the 2048-qt window at the center of the screen
2048-qt tries to spawn its main window at the center of the current
screen, and does so by setting a few variables in QML. Unfortunately,
this has the side effect of forcing the window to remain on the primary
screen in a multiscreen setup, overriding whatever the user chooses.
This is annoying behaviour for a window that isn't a modal dialog.
.
As such, remove it.
Author: Wouter Verhelst
Bug-Debian: https://bugs.debian.org/850629
Last-Update: 2017-04-14
---
--- 2048-qt-0.1.6.orig/qml/main.qml
+++ 2048-qt-0.1.6/qml/main.qml
@@ -13,9 +13,6 @@ ApplicationWindow {
title: qsTr("2048 Game");
//flags: Qt.Window | Qt.WindowTitleHint | Qt.WindowMinimizeButtonHint |
Qt.WindowCloseButtonHint | Qt.CustomizeWindowHint
-x: (Screen.width - width) / 2
-y: (Screen.height - height) / 2
-
ExclusiveGroup { id: labelSettingsGroup }
ExclusiveGroup { id: languageSettingsGroup }
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Bug#859708: unblock: kodi/2:17.1+dfsg1-2
Hi Niels, 2017-04-12 19:37 GMT+02:00 Niels Thykier : > Control: tags -1 confirmed moreinfo > > On Thu, 6 Apr 2017 11:20:25 +0200 Balint Reczey > wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> Dear Release Team, >> >> Current kodi version in Stretch is 2:17.0+dfsg1-3 but upstream >> already released Kodi 17.1 which is available from experimental >> as 2:17.1+dfsg1-1. >> >> Among many other bugfixes it fixes #847701 which made kodi unusable on >> many slower i386 machines. >> >> I believe 17.1 would be a better fit for Stretch, while the diff >> between 17.0 and 17.1 contains quite a lot bug fixes: >> >> https://github.com/xbmc/xbmc/compare/a10c5048f2487bd9b2dc1f35d2fee48a2594...fc1619b118f6d503f920a49cf4ac4afcd0dd6b41 >> >> At the moment 2:17.1+dfsg1-1 is uploaded to experimental only and I >> would like to upload 2:17.0+dfsg1-2 with no new changes to >> unstable if it would be allowed to migrate to testing. >> >> Otherwise I will just triage and add the fix for #847701 to >> 2:17.0+dfsg1-3 and upload that minimal change to unstable as >> 2:17.0+dfsg1-4, but would prefer going th 17.1 way. >> >> Please share your opinion about the options. >> >> The attached patch contains the packaging changes only because the full >> debdiff is ~400k. >> >> Cheers, >> Balint >> >> unblock kodi/2:17.1+dfsg1-2 >> > > Ack, please go ahead and let us know once it has been uploaded and > compiled on all relevant architectures. Thanks! Done and built. Cheers, Balint
Bug#860300: lircmd does not work
Package: lirc Version: 0.9.4c-9 Severity: important Dear Maintainer, I want to use lircmd After making sure that lirc works to control vdr and kodi, I configured lircmd in /etc/lirc/lirc_options.conf [lircmd] uinput = True nodaemon= False After starting "systemctl start lircmd", lircmd started without option "--uinput". Because I was not able to control my X11 mouse pointer, I tried to add this option. No matter if I tried on commandline by calling "/usr/sbin/lircmd --uinput", or by changing /lib/systemd/system/lircmd.service the following error was shown: Apr 14 11:03:38 majestix lircd-0.9.4c[23887]: "lircmd.cpp":394: Bad file descriptor Apr 14 11:03:38 majestix lircd-0.9.4c[23887]: "lircmd.cpp":394: Bad file descriptor ... *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lirc depends on: ii init-system-helpers 1.47 ii libasound2 1.1.3-5 ii libc62.24-9 ii libftdi1-2 1.3-2+b2 ii libgcc1 1:6.3.0-12 ii liblirc-client0 0.9.4c-9 ii liblirc0 0.9.4c-9 ii libportaudio219.6.0-1 ii libstdc++6 6.3.0-12 ii libsystemd0 232-22 ii libudev1 232-22 ii libusb-0.1-4 2:0.1.12-30 ii libusb-1.0-0 2:1.0.21-1 ii lsb-base 9.20161125 ii python3 3.5.3-1 Versions of packages lirc recommends: pn gir1.2-vte ii python3-gi3.22.0-2 ii python3-yaml 3.12-1 Versions of packages lirc suggests: ii ir-keytable 1.12.3-1 ii lirc-compat-remotes 0.9.0-1 pn lirc-doc pn lirc-drv-irman pn lirc-x ii setserial2.17-50 -- Configuration Files: /etc/lirc/lircd.conf.d/devinput.lircd.conf [Errno 2] Datei oder Verzeichnis nicht gefunden: '/etc/lirc/lircd.conf.d/devinput.lircd.conf' -- no debconf information
Bug#860236: xen pv domU crash with 3.16 kernel and xen 4.8
On Fri, Apr 14, 2017 at 09:15:58AM +0200, Vincent Legout wrote :
> On Thu, Apr 13, 2017 at 11:41:37PM +0100, Ben Hutchings wrote :
> > Control: tag -1 moreinfo
> >
> > On Thu, 2017-04-13 at 11:18 +0200, Vincent Legout wrote:
> > > Package: src:linux
> > > Version: 3.16.39-1+deb8u2
> > > Severity: normal
> > >
> > > Hi,
> > >
> > > A xen jessie domU crashes around 5 minutes after the boot with the
> > > attached backtrace (at every boot). dom0 is also a Debian jessie running
> > > Xen 4.8.
> > >
> > > It only happens when the guest is in pv mode, it works fine with pvhvm.
> > >
> > > It also crashes with older 3.16 kernels and 4.0.2-1, but not with
> > > 4.2.1-1 (last 2 kernels from snapshot.debian.org).
> > >
> > > # uname -a
> > > 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64
> > > GNU/Linux
> >
> > From the crash log:
> >
> > > [ 300.632389] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW
> > > 3.16.0-4-amd64 #1 Debian 3.16.39-1+deb8u2
> >
> > This indicates there was an earlier WARNING message; what was that?
>
> Thanks for the answer.
>
> I got this WARNING after I increased verbosity in the command line:
The WARNING and BUG disappear if "maxvcpus" is disabled in the guest
configuration (which prevents adding or removing vcpus).
Could cpu hotplug be buggy in 3.16? And Xen triggers this bug after 5
minutes even without doing any 'xl vcpu-set'?
With "maxvcpus" set larger "vcpus", xl vcpu-set seems to work most of
the time (between 1 and 16 vcpus), but after several tries, I got the
attached trace.
Vincent
[ 62.000210] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 62.000229] IP: [] migrate_timer_list+0x3b/0xc0
[ 62.000246] PGD 0
[ 62.000251] Oops: 0002 [#1] SMP
[ 62.000261] Modules linked in: x86_pkg_temp_thermal thermal_sys intel_rapl
coretemp crc32_pclmul evdev aesni_intel aes_x86_64 lrw gf128mul glue_helper
ablk_helper pcspkr cryptd autofs4 ext4 crc16 mbcache jbd2 xen_netfront
xen_blkfront crct10dif_pclmul crct10dif_common crc32c_intel
[ 62.000306] CPU: 9 PID: 89 Comm: xenwatch Not tainted 3.16.0-4-amd64 #1
Debian 3.16.39-1+deb8u2
[ 62.000318] task: 88003d597370 ti: 88003d598000 task.ti:
88003d598000
[ 62.000326] RIP: e030:[] []
migrate_timer_list+0x3b/0xc0
[ 62.000338] RSP: e02b:88003d59bd70 EFLAGS: 00010087
[ 62.000344] RAX: dead0200 RBX: RCX: 223a
[ 62.000351] RDX: RSI: 88003f96ca00 RDI: 88003daac000
[ 62.000357] RBP: 88003f96ca00 R08: 4000 R09: fff8
[ 62.000364] R10: R11: R12: 88003e3a5430
[ 62.000375] R13: 88003daac000 R14: 818e2fa0 R15: 88003e3a5030
[ 62.000387] FS: () GS:88003f92()
knlGS:
[ 62.000395] CS: e033 DS: ES: CR0: 80050033
[ 62.000401] CR2: 0008 CR3: 01813000 CR4: 00042660
[ 62.000408] Stack:
[ 62.000411] 88003daac000 88003e3a5c30
88003e3a5830
[ 62.000422] 88003e3a5430 81075188 88003e3a4000
fff2
[ 62.000432] 8184c1a0 0007
0001
[ 62.000443] Call Trace:
[ 62.000455] [] ? timer_cpu_notify+0xf8/0x2e0
[ 62.000465] [] ? notifier_call_chain+0x4e/0x70
[ 62.000478] [] ? cpu_notify+0x1f/0x40
[ 62.000486] [] ? cpu_notify_nofail+0xa/0x20
[ 62.000499] [] ? _cpu_down+0x17b/0x290
[ 62.000512] [] ? unregister_xenbus_watch+0x210/0x210
[ 62.000520] [] ? cpu_down+0x2d/0x40
[ 62.000530] [] ? handle_vcpu_hotplug_event+0xa7/0xd0
[ 62.000538] [] ? xenwatch_thread+0x92/0x130
[ 62.000550] [] ? prepare_to_wait_event+0xf0/0xf0
[ 62.000565] [] ? kthread+0xbd/0xe0
[ 62.000572] [] ? kthread_create_on_node+0x180/0x180
[ 62.000586] [] ? ret_from_fork+0x58/0x90
[ 62.000594] [] ? kthread_create_on_node+0x180/0x180
[ 62.000600] Code: 49 89 fd 41 54 49 89 f4 55 53 48 8b 2e 48 39 ee 74 4a 66
0f 1f 44 00 00 0f 1f 44 00 00 48 8b 45 08 48 8b 55 00 48 89 ee 4c 89 ef <48> 89
42 08 48 89 10 48 b8 00 02 00 00 00 00 ad de 48 89 45 08
[ 62.000680] RIP [] migrate_timer_list+0x3b/0xc0
[ 62.000692] RSP
[ 62.000696] CR2: 0008
[ 62.000703] ---[ end trace b62387850d17f99e ]---
[ 84.492006] INFO: rcu_sched detected stalls on CPUs/tasks: { 2 8 9}
(detected by 4, t=5255 jiffies, g=614, c=613, q=59)
[ 84.492039] sending NMI to all CPUs:
[ 63.481417] NMI backtrace for cpu 0
[ 63.481417] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D
3.16.0-4-amd64 #1 Debian 3.16.39-1+deb8u2
[ 63.481417] task: 8181a460 ti: 8180 task.ti:
8180
[ 63.481417] RIP: e030:[] []
_raw_spin_lock+0x28/0x30
[ 63.481417] RSP: e02b:88003f803b58 EFLAGS: 0093
[ 63.481417] RAX: 0198 RBX: 88003af9d3d8 RCX: 019b
[ 63.481417]
Bug#856872: jessie-pu: package gnutls28/3.3.8-6+deb8u5
Hi On Sun, Mar 05, 2017 at 07:08:08PM +0100, Andreas Metzler wrote: > Package: release.debian.org > Severity: normal > Tags: jessie > User: release.debian@packages.debian.org > Usertags: pu > > Hello, > > I would like fix a number of minor issues in GnuTLS. Would still be great to see that in the next point release. Note there is one more CVE in meanwhile assigned: > Most of these (notably CVE-2017-533[4567]) are related to the PGP > support, security does not intend to issue a DSA: > + 55_13_cdk_pkt_read-enforce-packet-limits.patch Addressed integer > overflow resulting to invalid memory write in OpenPGP certificate > parsing. Issue found using oss-fuzz project: > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=420 > [GNUTLS-SA-2017-3A] This one got CVE-2017-7869 assigned, cf. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7869 Regards, Salvatore
Bug#860301: libev-dev: failed to static link libev.a
Package: libev-dev Version: 1:4.22-1 Severity: important Dear Maintainer, When come to static link libev, the ld shows: gcc test.c -Wl,-Bstatic -lev -Wl,-Bdynamic -lm /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libev.a(ev.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status the test.c is taken from someone's gist, https://gist.github.com/amghost/0d8422c5c63ec3fe I checked the debian/rules, but I don't know why the -fPIC is missed. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libev-dev depends on: ii libev4 1:4.22-1 libev-dev recommends no packages. libev-dev suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#860304: flash-kernel: Incorrect installation path for dtbs
Package: flash-kernel Version: 3.78 Severity: normal Dear Maintainer, flash-kernel 3.77 and 3.78 install the dtb for the Odroid C2 in /boot/dtbs/4.10.0-rc5-next-20170125-r000-arm64/meson-gxbb-odroidc2.dtb In U-Boot 2017.05-rc1 the environment variable vendor is set to "amlogic". U-Boot loads and runs boot.scr. The script tries to load the dtb from /boot/dtbs/4.10.0-rc5-next-20170125-r000-arm64/amlogic/meson-gxbb-odroidc2.dtb and obviously fails. My understanding is that on arm64 platforms the dtbs should be installed in vendor specific folders. Best regards Heinrich Schuchardt -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 4.10.0-rc5-next-20170125-r000-arm64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.60 ii devio 1.2-1.2+b1 ii initramfs-tools0.128 ii linux-base 4.5 ii mtd-utils 1:2.0.0-1 ii ucf3.0036 Versions of packages flash-kernel recommends: ii u-boot-tools 2016.11+dfsg1-4 flash-kernel suggests no packages. -- debconf information: flash-kernel/linux_cmdline: quiet
Bug#860302: libmbedtls-dev: please provide static lib in dev package
Package: libmbedtls-dev Version: 2.4.2-1 Severity: important Dear Maintainer, In debian/rules, you set -DUSE_STATIC_MBEDTLS_LIBRARY=OFF, but static library is useful in development, and .a file should be put in -dev package according to debian policy 8.3 -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libmbedtls-dev depends on: ii libmbedcrypto0 2.4.2-1 ii libmbedtls102.4.2-1 ii libmbedx509-0 2.4.2-1 libmbedtls-dev recommends no packages. Versions of packages libmbedtls-dev suggests: pn libmbedtls-doc -- no debconf information signature.asc Description: PGP signature
Bug#860303: freetype: CVE-2016-10328: heap-buffer-overflow in cff_parser_run()
Source: freetype Version: 2.6.3-3.1 Severity: important Tags: security patch upstream Forwarded: https://savannah.nongnu.org/bugs/?func=detailitem&item_id=49858 Control: fixed -1 2.7.1-0.1 Hi, the following vulnerability was published for freetype. CVE-2016-10328[0]: | FreeType 2 before 2016-12-16 has an out-of-bounds write caused by a | heap-based buffer overflow related to the cff_parser_run function in | cff/cffparse.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2016-10328 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10328 [1] https://savannah.nongnu.org/bugs/?func=detailitem&item_id=49858 [2] http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=beecf80a6deecbaf5d264d4f864451bde4fe98b8 [3] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=289 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#860305: staticsite: Dependency on python3-tz missing
Package: staticsite Version: 0.4-1 Severity: normal Hi Enrico, on my system, ssite failed complaining it couldn't find pytz. apt-get install python3-tz fixed it. Cheers Daniel -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'proposed-updates'), (990, 'stable'), (500, 'testing-proposed-updates'), (99, 'testing'), (98, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages staticsite depends on: ii python3-jinja2 2.7.3-1 ii python3-livereload 2.2.2-1 ii python3-markdown2.5.1-2 ii python3-toml0.9.1-1 ii python3-unidecode 0.04.16-1 pn python3:any Versions of packages staticsite recommends: ii libjs-bootstrap 3.2.0+dfsg-1 ii libjs-jquery 1.7.2+dfsg-3.2 staticsite suggests no packages. -- no debconf information
Bug#860306: isc-dhcp-client: Repeatedly received DHCPNAK or no DHCPOFFERS; other computers work OK
Package: isc-dhcp-client Version: 4.3.5-3 Severity: normal Dear Maintainer, This following bug report was created on the computer that experienced problems with isc-dhcp-client, but has not external mail connectivity. I completed the report, saved it, and included it below as the actual report. I hope this is a workable work-around. - - - - - - - - - - - - - - begin of original bug-report - - - - - Package: isc-dhcp-client Version: 4.3.5-3 Severity: normal Dear Maintainer, About a week ago isc-dhcp-client tried to connect to a network. It was the first time I attempted to connect to that network, and while DHCP connections usually work OK, this one resulted in repeated logs of DHCPNAK entries. Here is an example: Mar 30 13:00:20 localhost dhclient[4265]: Listening on LPF/wlp5s0/d8:fc:93:80:61:e1 Mar 30 13:00:20 localhost dhclient[4265]: Sending on LPF/wlp5s0/d8:fc:93:80:61:e1 Mar 30 13:00:20 localhost dhclient[4265]: Sending on Socket/fallback Mar 30 13:00:20 localhost dhclient[4265]: DHCPDISCOVER on wlp5s0 to 255.255.255.255 port 67 interval 4 Mar 30 13:00:21 localhost dhclient[4265]: DHCPREQUEST of 192.168.61.234 on wlp5s0 to 255.255.255.255 port 67 Mar 30 13:00:21 localhost dhclient[4265]: DHCPOFFER of 192.168.61.234 from 192.168.60.1 Mar 30 13:00:21 localhost dhclient[4265]: DHCPNAK from 192.168.60.1 Remarkably, two (android-based) cell-phones and a windows computer trying to access that network at the same time successfully completed their DHCP connections. This morning I attempted to connect to a different network, also using DHCP. This time it failed and the following entries were logged: Apr 14 09:51:13 localhost dhclient[1570]: DHCPDISCOVER on wlp5s0 to 255.255.255.255 port 67 interval 12 Apr 14 09:51:25 localhost dhclient[1570]: DHCPDISCOVER on wlp5s0 to 255.255.255.255 port 67 interval 6 Apr 14 09:51:31 localhost dhclient[1570]: No DHCPOFFERS received. Apr 14 09:51:31 localhost dhclient[1570]: No working leases in persistent database - sleeping. Apr 14 09:51:31 localhost avahi-autoipd(wlp5s0)[4056]: Found user 'avahi-autoipd' (UID 106) and group 'avahi-autoipd' (GID 111). Apr 14 09:51:31 localhost avahi-autoipd(wlp5s0)[4056]: Successfully called chroot(). Apr 14 09:51:31 localhost avahi-autoipd(wlp5s0)[4056]: Successfully dropped root privileges. Apr 14 09:51:31 localhost avahi-autoipd(wlp5s0)[4056]: Starting with address 169.254.10.140 Apr 14 09:51:38 localhost avahi-autoipd(wlp5s0)[4056]: Callout BIND, address 169.254.10.140 on interface wlp5s0 Apr 14 09:51:38 localhost avahi-daemon[479]: Joining mDNS multicast group on interface wlp5s0.IPv4 with address 169.254.10.140. Apr 14 09:51:38 localhost avahi-daemon[479]: New relevant interface wlp5s0.IPv4 for mDNS. Apr 14 09:51:38 localhost avahi-daemon[479]: Registering new address record for 169.254.10.140 on wlp5s0.IPv4. Again, in the recent past connections to this network were successfully established, and my cell-phone had no problems connecting to this network. Last week I also tried to connect to this particular network, and then the connection also wasn't established. In the past (say, a month or more ago) I had no problems connecting to this network. Different from the previously mentioned DHCPNAK-producing network this latter one is within reach, so I could perform specific tests on the latter network, if that could provide additional information. So the main question is: isc-dhcp-client *usually* works OK, but I've now encountered at least two networks where other computers successfully esthablished their DHCP connections, but mine doesn't. The available documentation is sketchy: one suggestion I found in the dhcpclient.conf man-page was to use an empty dhcpclient.conf file. So I did, but to no avail. Am I missing something? What can I do to solve the problem? As a side note: I'm also puzzled by the workings of the avahi daemon. It's not clear what it's doing except for faking the above 169.254.10.140 address and network. Should I deinstall avahi-daemon, since it appears to consume resources but doesn't seem to do anything useful?... That's about it. If there's anything I can do to help solving this issue, please advise. Kind regards, Frank B. Brokken. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages isc-dhcp-client depends on: ii debianutils 4.8.1 ii iproute2 4.9.0-1 ii libc6 2.24-9 ii libdns-export162 1:9.10.3.dfsg.P4-12.1 ii libisc-export160 1:9.10.3.dfsg.P4-12.1 Versions of packages isc-dhcp-client recommends: ii isc-dhcp-common 4.3.5-3 Versions of packages isc-dhcp-client suggests: ii avahi-autoipd 0.6.32-2 pn isc-dhcp
Bug#860307: freetype: CVE-2017-7857 CVE-2017-7858
Source: freetype Version: 2.7.1-0.1 Severity: grave Tags: security upstream experimental Hi, the following vulnerabilities were published for freetype. AFAICS these affect only the version in experimental, so before it will migrate at some point to unstable, fixes for those two CVEs should be included. CVE-2017-7857[0]: | FreeType 2 before 2017-03-08 has an out-of-bounds write caused by a | heap-based buffer overflow related to the TT_Get_MM_Var function in | truetype/ttgxvar.c and the sfnt_init_face function in sfnt/sfobjs.c. CVE-2017-7858[1]: | FreeType 2 before 2017-03-07 has an out-of-bounds write related to the | TT_Get_MM_Var function in truetype/ttgxvar.c and the sfnt_init_face | function in sfnt/sfobjs.c. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-7857 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7857 [1] https://security-tracker.debian.org/tracker/CVE-2017-7858 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7858 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#860308: xserver-xorg-video-intel: why is this discouraged and what do you encourage instead?
Package: xserver-xorg-video-intel Version: 2:2.99.917+git20161206-1 Severity: normal I am running a i7-2600 which according to Intel was released in 2011 and meets the "your hw is new enough (ca. 2007 and newer)" criteria for discouraging the use of this package according to the long description. Why is it discouraged? Is anything else encouraged in it's place? Does libdrm-intel1 cover everything that is needed? My initial problem is that when using the xserver-xorg-video-fbdev driver (which happens because xorg decides not to use the Intel driver) I get 1920*1080 resolution on my 2560*1440 HDMI monitor. -- Package-specific info: X server symlink status: lrwxrwxrwx. 1 root root 13 Sep 5 2011 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x. 1 root root 274 Mar 4 01:41 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 4.9.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170221 (Debian 6.3.0-8) ) #1 SMP Debian 4.9.13-1 (2017-02-27) Xorg X server log files on system: -- -rw-r--r--. 1 root root 6038 Apr 14 18:50 /var/log/Xorg.1.log -rw-r--r--. 1 root root 28414 Apr 14 19:13 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [2052577.313] (--) Log file renamed from "/var/log/Xorg.pid-19216.log" to "/var/log/Xorg.0.log" [2052577.313] X.Org X Server 1.19.2 Release Date: 2017-03-02 [2052577.313] X Protocol Version 11, Revision 0 [2052577.313] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [2052577.313] Current Operating System: Linux xev 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64 [2052577.314] Kernel command line: BOOT_IMAGE=/vmlinuz-4.9.0-2-amd64 root=UUID=a2d7cbbc-23be-4d97-b2bb-de99b0c58c7d ro security=selinux rootflags=skip_balance security=selinux init=/bin/systemd [2052577.314] Build Date: 03 March 2017 03:14:41PM [2052577.314] xorg-server 2:1.19.2-1 (https://www.debian.org/support) [2052577.314] Current version of pixman: 0.34.0 [2052577.314] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [2052577.314] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [2052577.314] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Apr 14 18:50:43 2017 [2052577.314] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [2052577.314] (==) No Layout section. Using the first Screen section. [2052577.314] (==) No screen section available. Using defaults. [2052577.314] (**) |-->Screen "Default Screen Section" (0) [2052577.314] (**) | |-->Monitor "" [2052577.314] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [2052577.314] (==) Automatically adding devices [2052577.314] (==) Automatically enabling devices [2052577.314] (==) Automatically adding GPU devices [2052577.314] (==) Max clients allowed: 256, resource mask: 0x1f [2052577.314] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [2052577.314] Entry deleted from font path. [2052577.314] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [2052577.314] (==) ModulePath set to "/usr/lib/xorg/modules" [2052577.314] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [2052577.314] (II) Loader magic: 0x55feaeadce00 [2052577.314] (II) Module ABI versions: [2052577.314] X.Org ANSI C Emulation: 0.4 [2052577.314] X.Org Video Driver: 23.0 [2052577.314] X.Org XInput driver : 24.1 [2052577.314] X.Org Server Extension : 10.0 [2052577.317] (++) using VT number 7 [2052577.317] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [2052577.318] (II) xfree86: Adding drm device (/dev/dri/card0) [2052577.331] (--) PCI:*(0:0:2:0) 8086:0102:1043:844d rev 9, Mem @ 0xfe00/4194304, 0xc000/268435456, I/O @ 0xf000/64, BIOS @ 0x/131072 [2052577.331] (II) LoadModule: "glx" [205
Bug#860304: Acknowledgement (flash-kernel: Incorrect installation path for dtbs)
The environment for U-Boot 2017.05-rc1 has: fdtfile=amlogic/meson-gxbb-odroidc2.dtb The relevant setting in U-Boot is in file include/configs/odroid-c2.h #define MESON_FDTFILE_SETTING \ "fdtfile=amlogic/meson-gxbb-odroidc2.dtb\0"
Bug#810735: fatresize: fails to open /dev/loop0p1 too
Package: fatresize Version: 1.0.2-9 Followup-For: Bug #810735 Are there any chances of seeing that patch applied? -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (998, 'testing'), (994, 'unstable'), (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fatresize depends on: ii libc6 2.24-9 ii libparted-fs-resize0 3.2-17 ii libparted23.2-17 fatresize recommends no packages. Versions of packages fatresize suggests: ii dosfstools 4.1-1 -- no debconf information
Bug#860026: [Parl-devel] Bug#860026: debian-parl: please update dependencies
Quoting Andreas Beckmann (2017-04-10 14:46:41) > The following packages have unmet dependencies: > parl-desktop-world : Depends: myspell-cs but it is not going to be installed > E: Unable to correct problems, you have held broken packages. > > > The relevant bits of the dependency chain seem to be: > > Package: parl-desktop-world, parl-desktop-eu > Depends: icedove-l10n-cs, myspell-cs > > Package: icedove-l10n-cs > Depends: thunderbird-l10n-cs > > Package: thunderbird-l10n-cs > Recommends: hunspell-cs | myspell-cs-cz > > Package: hunspell-cs > Conflicts: myspell-cs > > Package: myspell-cs > Replaces: myspell-cs-cz > Provides: myspell-cs-cz > Conflicts: myspell-cs-cz > > > Please update the dependencies to not use the transitional packages: > icedove => thunderbird > iceowl => lightning > iceweasel => firefox-esr > (without guarantee on completeness :-)) Finalizing that change now, but... > For myspell-cs I recommend to either switch to > hunspell-cs > or (matching thunderbird) > hunspell-cs | myspell-cs-cz I believe the myspell-cs versus hunspell-cs issue specifically, although triggered by parl-desktop-world, is caused by firefox-* (and task-czech-desktop not used by debian-parl) recommending only myspell-*, whereas libreoffice-*, thunderbird-* and lightning-* favor hunspell-* over mypsell-*. I believe the latter - recommending either, and (generally¹) favoring hunspell over myspell - is correct. debian-parl avoids hunspell-cs to be able to install locale packages not only for libreoffice/thundebird/lightning but also for firefox, but it is no surprise to me that APT may have trouble resolving a solution involving a selection discouraged by the majority of a package set. > Please also check the other *spell dependencies. firefox-esr-l10n-* for these locales recommend only myspell-* where hunspell-* also exist, so should _additionally_ recommend hunspell-*: * da (myspell favored¹) * bg * cs * de (hunspell-de-de | hunspell-dictionary-de | myspell-dictionary-de)² * el * es-ar * es-es * fr (hunspell-fr | myspell-fr | myspell-fr-gut) * he * hu * nb-no (no) * nl * nn-no (no) * pl * pt-br * pt-pt * ru * sk * uk firefox-esr-l10n-* for these locales recommend dictionary only via transitional package, so should replace with _only_ hunspell-*: * ca (both real 0.20111230b-9 and transitional 3.0.1+repack1-3 exist) * en-gb * en-za (also wrongly transitions to en-gb) * it * lt * sl * sv-se (also should include and maybe¹ favor hunspell-sv) firefox-esr-l10n-* for these locales recommend no dictionary and both hunspell and myspell exist, so should recommend _both_: * es-cl (es) * es-mx (es) * gd * hr firefox-esr-l10n-* for these locales recommend no dictionary and only hunspell exist, so should recommend _only_ hunspell-*: * af * an * ar * be * bn-bd (bn) * bn-in (bn) * br * bs * eu * gl (hunspell-gl | hunspell-gl-es)³ * gn * gu-in (gu) * hi-in (hi) * is * kk * km (kmr) * ko * ml * ro * si * sr * te * th * uz * vi firefox-esr-l10n-* for these locales recommend no dictionary and only myspell exist, so should recommend _only_ myspell-*: * fa * ga-ie (ga) * hy-am (hy) ¹ myspell-da is arguably technically superior to hunspell-da: The former is built from a much larger wordlist - the latter is promoted by Mozilla and LibreOffice due to a more liberal license. Similar licensing issue for -se dictionaries - uncertain which of those is technical superior. ² german myspell packages do not provide virtual hunspell-dictionary-de ³ uncertain which should be favored Yes, above issues should ideally be reported separately - I thought I did so about a year ago, but apparently got axhausted before finishing reports for icedove and iceowl. Help passing on the info to firefox much appreciated. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#860302: libmbedtls-dev: please provide static lib in dev package
Control: severity -1 wishlist Hi, On 14/04/17 10:45, Shengjing Zhu wrote: > Package: libmbedtls-dev > Version: 2.4.2-1 > Severity: important > > Dear Maintainer, > > In debian/rules, you set -DUSE_STATIC_MBEDTLS_LIBRARY=OFF, but static > library is useful in development, and .a file should be put in -dev > package according to debian policy 8.3 I'll think about it, but I see a lot of disadvantages with statically linking a security library with few advantages. Why would static / dynamic linking matter during development? James signature.asc Description: OpenPGP digital signature
Bug#860309: libceres1: Requires rebuild for Eigen 3.3.2
Package: libceres1 Version: 1.12.0+dfsg0-1 Severity: important libceres currently is not useable, at least not if the project in question uses CMake. The reason is to be found in cmake/CeresConfig.cmake.in: CMake Error at /usr/lib/cmake/ceres/CeresConfig.cmake:88 (message): Failed to find Ceres - Found Eigen dependency, but the version of Eigen found (3.3.2) does not exactly match the version of Eigen Ceres was compiled with (3.3.0). This can cause subtle bugs by triggering violations of the One Definition Rule. See the Wikipedia article http://en.wikipedia.org/wiki/One_Definition_Rule for more details => Please add the exact version of Eigen found when building Ceres to debian/control, or fix Ceres to relax this dependency. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (700, 'testing'), (650, 'unstable'), (600, 'stable'), (550, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-rc5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libceres1 depends on: ii libamd2 1:4.5.4-1 ii libatlas3-base [liblapack.so.3] 3.10.3-1+b1 ii libc62.24-9 ii libcamd2 1:4.5.4-1 ii libccolamd2 1:4.5.4-1 ii libcholmod3 1:4.5.4-1 ii libcolamd2 1:4.5.4-1 ii libcxsparse3 1:4.5.4-1 ii libgcc1 1:6.3.0-12 ii libgflags2v5 2.1.2-3 ii libgomp1 6.3.0-12 ii libgoogle-glog0v50.3.4-2 ii liblapack3 [liblapack.so.3] 3.7.0-1 ii libspqr2 1:4.5.4-1 ii libstdc++6 6.3.0-12 ii libsuitesparseconfig41:4.5.4-1 libceres1 recommends no packages. libceres1 suggests no packages. -- no debconf information
Bug#852360: Cross compiling and Bug#852360
Hello Helmut, On Thu, 13 Apr 2017 22:05:02 +0200 Helmut Grohne wrote: > > Does that mean that the snippet > > > include /usr/share/dpkg/architecture.mk > > > ifeq ($(origin CC),default) > > > export CC := $(DEB_HOST_GNU_TYPE)-gcc > > > endif > > can be removed again from debian/rules? I tried to cross compile for > > armhf without that snipped using pbuilder (following the > > instructions from https://wiki.debian.org/CrossCompiling) which > > worked: The correct compiler was called and the binaries had the > > same sha512sum thanks to reproducible builds. > > I think you perfectly answered your own question. Performing a test > build under sbuild or pbuilder and looking at which compiler is being > used is a good approach to answer it. There isn't anything more to it. > Your own analysis clearly says that exporting CC is no longer > necessary. Thanks for clarifying. I was unsure because the version the bug was filed against had already switched to debhelper 10 (so this shouldn't have been a problem in the first place). > I'm also happy that apparently cross building using pbuilder is no > longer too hard for the uninitiated. Good work, Mattia! :) I agree. This was my first time cross compiling anything, and the process was very smooth. Thanks for that! Regards Lukas pgpgfBiVDxv_5.pgp Description: OpenPGP digital signature
Bug#735909: testing more architectures with piuparts
reassign 762308 piuparts.debian.org merge 735909 762308 retitle 735909 piuparts.$ARCH.debian.org thanks > On Sun, Mar 19, 2017 at 09:30:05AM +0800, Paul Wise wrote: > > > However, I realized today, that there is a cheap way out: > > > - rename piuparts.d.o to amd64.piuparts.d.o > > > - point piuparts.d.o at somewhere sensible (on amd64.piu….d.o) > > We would need to make sure that this part doesn't break all the > > services that use it or link to it. > of course. > that's actually the beauty of this solution: amd64 stays the same. to be clear, for a start it's enough to - add two new vhosts, piuparts.amd64.d.o and piuparts.i386.d.o and point piuparts.d.o to piuparts.adm64.d.o - run two masters on pejacevic, one for amd64 and one for i386, which create two websites and are served by different slaves… Then, we will want to add some inter-architecture links, though maybe this will stay rather minimal, as I believe the long term solution should rather be to store the piuparts results in postgresql and use a dynamic frontend… but this is really longterm and independent of the above "hack" to support several archs with minimal code changes now. > >That appears to be at minimum, > > release.d.o, UDD, PTS/tracker, DDPO and jenkins. Yes, indeed. This is currently awaiting feedback from DSA about the new i386 slave. -- cheers, Holger signature.asc Description: Digital signature
Bug#860310: unblock pre-apptoval request for yade/2017.01a-8
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package yade
Yade upstream have found a critical bug in so-called periodic
boundaries contact detection [1]. It would be good to have this
fix in Debian as well. I cherry-picked the upstream's patch,
which is attached to this mail.
unblock yade/2017.01a-8
[1] http://www.mail-archive.com/yade-dev@lists.launchpad.net/msg12355.html
Thanks,
Anton
diff -Nru yade-2017.01a/debian/changelog yade-2017.01a/debian/changelog
--- yade-2017.01a/debian/changelog 2017-02-28 22:03:24.0 +0100
+++ yade-2017.01a/debian/changelog 2017-04-14 12:43:59.0 +0200
@@ -1,3 +1,10 @@
+yade (2017.01a-8) unstable; urgency=medium
+
+ [ Bruno Chareyre ]
+ * [be08409] Critical bugfix for periodic boundaries.
+
+ -- Anton Gladky Fri, 14 Apr 2017 12:43:59 +0200
+
yade (2017.01a-7) unstable; urgency=medium
* [31387da] Add missing dependency on python-pyqt5.qtsvg in python-yade.
diff -Nru yade-2017.01a/debian/patches/09_fix_periodic_boundaries.patch
yade-2017.01a/debian/patches/09_fix_periodic_boundaries.patch
--- yade-2017.01a/debian/patches/09_fix_periodic_boundaries.patch
1970-01-01 01:00:00.0 +0100
+++ yade-2017.01a/debian/patches/09_fix_periodic_boundaries.patch
2017-04-14 12:42:33.0 +0200
@@ -0,0 +1,28 @@
+From c7c8e6f62d452c81a31415f05a12587a6cc8c452 Mon Sep 17 00:00:00 2001
+From: bchareyre
+Date: Fri, 14 Apr 2017 12:04:32 +0200
+Subject: [PATCH] Critical bugfix for collision detection in periodic boundary
+ conditions. Bounds lists were left partially unordered, then some
+ interactions were never detected (my toughest yade debugging until now).
+
+---
+ pkg/common/InsertionSortCollider.cpp | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/pkg/common/InsertionSortCollider.cpp
b/pkg/common/InsertionSortCollider.cpp
+index dc5d7ac..163a4f4 100644
+--- a/pkg/common/InsertionSortCollider.cpp
b/pkg/common/InsertionSortCollider.cpp
+@@ -410,8 +410,10 @@ Real InsertionSortCollider::cellWrapRel(const Real x,
const Real x0, const Real
+ void InsertionSortCollider::insertionSortPeri(VecBounds& v,
InteractionContainer* interactions, Scene*, bool doCollide){
+ assert(periodic);
+ long &loIdx=v.loIdx; const long &size=v.size;
+- for(long _i=0; _i
Bug#860311: simple-scan produces a log file with no size limit
Package: simple-scan Version: 3.23.2-1 Severity: normal Dear Maintainer, simple-scan produces detailed logs in ~/.cache/simple-scan/simple-scan.log. While this can be useful when debugging issues, it also means that simple-scan uses up more and more disk space (10GiB on my system) in a location which isn’t particularly discoverable... There’s probably a better way to fix this than just in simple-scan, but I thought it worth filing a bug anyway. (I skipped attaching the debug log, for obvious reasons.) Regards, Stephen -- Package-specific info: -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages simple-scan depends on: ii dbus-user-session [default-dbus-session-bus] 1.10.16-1 ii dbus-x11 [dbus-session-bus] 1.10.16-1 ii dconf-gsettings-backend [gsettings-backend] 0.26.0-2+b1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libcolord21.3.3-2 ii libgdk-pixbuf2.0-02.36.5-2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libgusb2 0.2.9-1+b1 ii libpackagekit-glib2-181.1.5-2 ii libpango-1.0-01.40.4-1 ii libpangocairo-1.0-0 1.40.4-1 ii libsane 1.0.25-3 ii libsqlite3-0 3.16.2-3 ii libusb-1.0-0 2:1.0.21-1 ii xdg-utils 1.1.1-1 ii zlib1g1:1.2.8.dfsg-5 simple-scan recommends no packages. simple-scan suggests no packages. -- no debconf information
Bug#860312: lmms: please lower the indirect dependency on wine
Source: lmms Version: 1.1.3-7 Severity: wishlist Hi maintainer Package lmms recommends lmms-vst-server:i386 which in turn depends on wine32 and wine. This means a typical installation (without --no-install-recommends) of lmms will install lmms-vst-server, libwine and all of libwine's dependencies. Would you please consider lowering the Recommends: lmms-vst-server:i386 to Suggests: lmms-vst-server:i386 ? Regards Graham
Bug#860313: freetype: CVE-2017-7864
Source: freetype Version: 2.6.3-3 Severity: important Tags: patch upstream security Hi, the following vulnerability was published for freetype. CVE-2017-7864[0]: | FreeType 2 before 2017-02-02 has an out-of-bounds write caused by a | heap-based buffer overflow related to the tt_size_reset function in | truetype/ttobjs.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-7864 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7864 [1] http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=e6699596af5c5d6f0ae0ea06e19df87dce088df8 [2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=509 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#860296: lirc is spamming syslog with messages
Version: 0.9.4c-9 Dear Debian folks, Am Freitag, den 14.04.2017, 10:15 +0200 schrieb Hans-J. Ullrich: > System is an EEEPC 1005HAG, debian/testing, i386 I am using Debian Sid/unstable. > Sadly I have to tell, the latest version of lirc is spamming syslog > with mwessages. To make sure, it is not a problem of an earlier > configuration, I deinstalled it completely and reinstalled it new. > > The message, which is spamming is the following: > > Apr 11 20:28:22 localhost lircd-0.9.4c[8159]: Error: Cannot glob > /sys/class/rc/rc0/input[0-9]*/event[0-9]* > Apr 11 20:28:23 localhost lircd[8159]: lircd-0.9.4c[8159]: Error: Cannot glob > /sys/class/rc/rc0/input[0-9]*/event[0-9]* > Apr 11 20:28:23 localhost lircd-0.9.4c[8159]: Error: Cannot glob > /sys/class/rc/rc0/input[0-9]*/event[0-9]* > Apr 11 20:28:24 localhost lircd[8159]: lircd-0.9.4c[8159]: Error: Cannot glob > /sys/class/rc/rc0/input[0-9]*/event[0-9]* > > and so on. `journalctl -a -f` also shows the constant message flow. There is no such directory `/sys/class/rc` here, when no remote control receiver is installed. ``` $ LANG=C ls -l /sys/class/ | grep rc drwxr-xr-x 2 root root 0 Apr 14 11:56 powercap ``` > Note: Although I have no infrared hardware installed, this issue did > not happen with earlier versions. > As a workaround, I had to deinstall the package for now. > > It would be nice, if you could take an eye on it. That’d would be awesome indeed. Kind regards, Paul signature.asc Description: This is a digitally signed message part
Bug#857394: Debian Policy violation -- libgegl-dev contains duplicate copy of openCL library files
On Thu, 13 Apr 2017 01:25:29 -0700 wrote: >> I'm not going to try a 'merge-on-the-fly' on headers to save a bunch >> of kilobytes. Sorry. > > Saving a bunch of kilobytes is really not the issue, as I suggested > when I said "isn't that a Policy violation?". I was right -- it IS a Debian Policy violation: * 4.13 Convenience copies of code * Some software packages include in their distribution convenience copies of code from other software packages, generally so that users compiling from source don't have to download multiple packages. Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible. https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles That seems to describe this situation EXACTLY. -- Ian Bruce
Bug#844237: Incorrect handling of device major/minor
Hello,
upstream applied Nicolas George's patch and released version 31
some days ago.
I hope it is not too late for stretch?
As I own an affected device I would like to supply some more
informations and workarounds to people with similar devices.
Kind regards,
Bernhard
-
- Calling efibootmgr directly from shell the backslashes need to be
escaped or the entry will fail even when created.
- Adding --verbose twice to efibootmgr, it outputs also the errors
stored by calls to efi_error function.
- As a workaround I could still boot to grub by:
- boot into UEFI shell
- enter: fs0:\EFI\debian\grubia32.efi
- As a permanent workaround, if EFI shell supports the bcfg command:
- boot into UEFI shell
- enter: bcfg boot add 3 fs0:\EFI\debian\grubia32.efi "debian"
- boot order can now possibly rearranged in UEFI menus.
If EFI shell does not support bcfg one could also supply a external EFI shell
e.g. from [1].
[1]
https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Obtaining_UEFI_Shell
- After I installed a version of libefivar1 with the mentioned patch
applied I got "Could not prepare Boot variable: No space left on device"
After moving some of the files /sys/firmware/efi/efivars/dump-type0* to
another disk the efibootmgr could successfully create the entry.
(These dump-type0* files seem to contain previous linux crashes when
examining them through /sys/firmware/efi/vars/dump-type0*/data ...)
-
# LANG=C grub-install --verbose --target=i386-efi
...
grub-install: info: executing efibootmgr -c -d /dev/mmcblk1 -p 1 -w -L debian
-l \EFI\debian\grubia32.efi.
Could not prepare Boot variable: No such file or directory
grub-install: error: efibootmgr failed to register the boot entry: Input/output
error.
# LANG=C efibootmgr --verbose --verbose -c -d /dev/mmcblk1 -p 1 -w -L debian -l
\\EFI\\debian\\grubia32.efi
Could not prepare Boot variable: No such file or directory
error trace:
creator.c:243 efi_va_generate_file_device_path_from_esp(): could not set disk
and partition name: No such file or directory
creator.c:320 efi_generate_file_device_path_from_esp(): could not generate
File DP from ESP: No such file or directory
efibootmgr.c:286 make_var(): make_linux_load_option() failed: No such file or
directory
efibootmgr.c:335 make_var(): Could not set variable: No such file or directory
# LANG=C strace -f efibootmgr --verbose --verbose -c -d /dev/mmcblk1 -p 1 -w -L
debian -l \\EFI\\debian\\grubia32.efi
...
fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(179, 256), ...}) = 0
readlink("/sys/dev/block/4275:0", 0x7fff3873b830, 4096) = -1 ENOENT (No such
file or directory)
...
# ls -lisah /dev/mmcblk1 /sys/dev/block/179\:256
1293 0 brw-rw 1 root disk 179, 256 Apr 13 21:17 /dev/mmcblk1
12373 0 lrwxrwxrwx 1 root root0 Apr 13 23:17 /sys/dev/block/179:256 ->
../../devices/platform/80860F14:00/mmc_host/mmc1/mmc1:0001/block/mmcblk1
Bug#860314: icu: CVE-2017-7867: Heap-buffer-overflow in utf8TextAccess
Source: icu Version: 52.1-8 Severity: grave Tags: patch security upstream Justification: user security hole Forwarded: https://ssl.icu-project.org/trac/ticket/12888 *** /tmp/icu.reportbug Package: icu X-Debbugs-CC: t...@security.debian.org secure-testing-t...@lists.alioth.debian.org Severity: grave Tags: security Hi, the following vulnerability was published for icu. CVE-2017-7867[0]: | International Components for Unicode (ICU) for C/C++ before 2017-02-13 | has an out-of-bounds write caused by a heap-based buffer overflow | related to the utf8TextAccess function in common/utext.cpp and the | utext_setNativeIndex* function. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-7867 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7867 [1] https://ssl.icu-project.org/trac/ticket/12888 (closed unfortunately) [2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=213 [3] https://ssl.icu-project.org/trac/changeset/39671 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#859462: Fix from upstream
Hi,
here is attached part of the patch applied upstream (
https://github.com/TelepathyIM/telepathy-qt/commit/15374115fa910ffa41ac2acce71b7f4fc0937674
)
That fixed the problem here.
F.
--- a/tests/dbus/contacts-capabilities.cpp
+++ b/tests/dbus/contacts-capabilities.cpp
@@ -111,7 +111,7 @@
QStringList ids = QStringList() << QLatin1String("alice")
<< QLatin1String("bob") << QLatin1String("chris");
-gboolean supportTextChat[] = { TRUE, FALSE, FALSE };
+bool supportTextChat[] = { true, false, false };
TpHandleRepoIface *serviceRepo =
tp_base_connection_get_handles(TP_BASE_CONNECTION(mConn->service()),
pgpJbaNMhDw2p.pgp
Description: PGP signature
Bug#849517: The valgrind diagnostic is a false positive
* Reuben Thomas: > A workaround is to build bash with --without-bash-malloc (but I presume > there's a good reason not to do that?). FWIW, Fedora and Red Hat Enterprise Linux compile bash this way, so it can't be *that* bad.
Bug#860314: icu: CVE-2017-7867 CVE-2017-7868: Heap-buffer-overflow in utf8TextAccess
Control: retitle -1 icu: CVE-2017-7867 CVE-2017-7868: Heap-buffer-overflow in utf8TextAccess Adding as well CVE-2017-7868: | International Components for Unicode (ICU) for C/C++ before 2017-02-13 | has an out-of-bounds write caused by a heap-based buffer overflow | related to the utf8TextAccess function in common/utext.cpp and the | utext_moveIndex32* function. which has the same upstream ticket (closed) and same changeset to fix, but are for issues via two different functions. Still think both affect icu back to 52.1, but please double check if I'm wrong possibly. Regards, Salvatore
Bug#860315: ITP: usbwall -- centralized USB devices filtering tool to associate locally allowed devices to LDAP user accounts
Package: wnpp Severity: wishlist Owner: Philippe Thierry * Package name: usbwall Version : 0.4-1 Upstream Author : Sylvain Leroy * URL : https://github.com/Oline/usbwall * License : MIT Programming Lang: C Section : utils Description : centralized USB devices filtering tool to associate locally allowed devices to LDAP user accounts standard It builds those binary packages: usbwalld: the daemon that effectively manage the USB device access list devid-schema: the LDAP schema associating users and hardware serial ID libpam-usbwall: the PAM module that retreives the association between locally connected user(s) and the associated device lists from the LDAP directory To access further information about this package, please visit the following URL: https://mentors.debian.net/package/usbwall Alternatively, one can download the package with dget using this command: dget -xhttps://mentors.debian.net/debian/pool/main/u/usbwall/usbwall_0.4-1.dsc The goal of the usbwall project is to support dynamic USB device filtering depending on a per-user centralized authorized device list. When a user log in, a custom PAM module will alert a daemon, that will get back the list of the authorized devices from LDAP. Regards, -- Philippe THIERRY
Bug#860316: CVE-2017-7861
Source: grpc Severity: grave Tags: security Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7861 for details. Cheers, Moritz
Bug#860316: CVE-2017-7861
Moritz Muehlenhoff wrote: > Source: grpc > Severity: grave > Tags: security > > Please see > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7861 for details. Also http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7860 Cheers, Moritz
Bug#859793: fluidsynth: Package has infringed GPL
El dl 10 de 04 de 2017 a les 23:06 +0200, Peter Hanappe va escriure: > However, it seems that chorus.c is now under the LGPL license. From > https://sourceforge.net/p/sox/code/ci/master/tree/COPYING: As I understand, fluidsynth_chorus.c was imported from SoX rather than the original project by Juergen Mueller. Thus, Chris Bagwell is the one who can shed light on the origin. > However, since fluidsynth was under LGPL > with "Copyright (C) 2003 Peter Hanappe and others" from the > beginning, I don't believe any contributors to > fluidsynth_chorus.c would object to putting their changes to that > file under the LGPL. I'll happily make my changes available under > that license. That makes sense. However, the main problem is the permission from Juergen Mueller and related contributors. > So, because SoX/chorus.c is now under the LGPL and all the > changes that have been made between chorus.c and > fluidsynth_chorus.c fall under the LGPL, I believe that > fluidsynth_chorus.c can be put under the LGPL, too. I see no evidence to support such relicensing. Original copyright should be to dropped if there is no trace from the original file, but this does not seem to be the case. smime.p7s Description: S/MIME cryptographic signature
Bug#860304: [PATCH 1/1] flash-kernel: support relative pathes for DTB-Id
Closes: #860304
In U-Boot some boards expect the dtb file to be installed in a vendor
specific subdirectory.
With this patch relative paths specified in the DTB-Id are used for
this purpose.
The data base entry for the Hardkernel Odroid C2 is adjusted.
Signed-off-by: Heinrich Schuchardt
---
README| 17 ++---
db/all.db | 2 +-
functions | 35 +--
3 files changed, 24 insertions(+), 30 deletions(-)
diff --git a/README b/README
index 555adaf..0f3b88f 100644
--- a/README
+++ b/README
@@ -115,13 +115,16 @@ The supported fields are:
This option is ignored if a DTB is to be appended, via either DTB-Append or
DTB-Append-From.
-* DTB-Id: (optional) specifies the name of the DTB file for this device
- relative to the kernel package DTB dir or /etc/flash-kernel/dtbs.
- It's not necessary to specify the directory if the DTB is in a vendor
- subdirectory as flash-kernel will search for the filename in
- subdirectories. If the value begins with a `!' then the field is a script
- which should be run. The script must produce the DTB filename (just the
- filename, without a vendor subdirectory) on stdout (and nothing else).
+* DTB-Id: (optional) specifies the name of the DTB file for this device.
+ If DTB-Id specifies an absolute path the directory specifies the path from
+ where the DTB is copied.
+ If DTB-Id specifies a relative path the directory specifies the subdirectory
+ of the kernel version directory where the DTB will be installed.
+ The filename is used to search for the filename in subdirectories of
+ /usr/lib/linux-image-* or /etc/flash-kernel/dtbs.
+ If the value begins with a `!' then the field is a script which should be
+ run. The script must produce the DTB filename (possibly including a
+ directory) on stdout.
* DTB-Append: (optional) when yes the DTB specified by DTB-Id will be appended
to the kernel image.
diff --git a/db/all.db b/db/all.db
index a696950..a40a312 100644
--- a/db/all.db
+++ b/db/all.db
@@ -443,7 +443,7 @@ Required-Packages: u-boot-tools
Machine: Hardkernel ODROID-C2
Kernel-Flavors: arm64
-DTB-Id: meson-gxbb-odroidc2.dtb
+DTB-Id: amlogic/meson-gxbb-odroidc2.dtb
Boot-Script-Path: /boot/boot.scr
U-Boot-Script-Name: bootscr.uboot-generic
Required-Packages: u-boot-tools
diff --git a/functions b/functions
index 76f57f0..d6f4b2d 100644
--- a/functions
+++ b/functions
@@ -244,21 +244,15 @@ get_dtb_name() {
error "dtb-probe $dtb_script failed"
fi
;;
- /*)
- dtb_name="$field"
- ;;
*)
- # DTBs on arm64 are stored in subdirs for each vendor; strip
- # the dir away (in case someone specified it, although it's
- # not needed).
- # The DTB will be stored in /boot/dtbs/$kvers/ without
- # additional subdirs.
- dtb_name=$(basename "$field")
+ dtb_name="$field"
;;
esac
if [ -n "$dtb_name" ] ; then
echo "Using DTB: $dtb_name" >&2
fi
+ dtb_dir = $(dirname "$dtb_name")
+ dtb_name = $(dirname "$dtb_name")
}
machine_uses_flash() {
@@ -570,9 +564,9 @@ android_flash() {
find_dtb_file() {
local dtb
- case "$dtb_name" in
+ case "$dtb_dir" in
/*)
- dtb="$dtb_name"
+ dtb="$dtb_dir/$dtb_name"
if [ ! -f "$dtb" ]; then
error "Couldn't find $dtb"
fi
@@ -596,10 +590,8 @@ handle_dtb() {
fi
local dtb
- local dtb_name
if [ "x$FK_KERNEL_HOOK_SCRIPT" = "xpostrm.d" ] ; then
- dtb_name=$(basename $dtb_name)
- rm -f "/boot/dtbs/$kvers/$dtb_name"
+ rm -f "/boot/dtbs/$kvers/$dtb_dir/$dtb_name"
# This was the old name we installed under. We
# currently include it as an alternative symlink.
@@ -623,23 +615,22 @@ handle_dtb() {
fi
else
dtb=$(find_dtb_file)
- dtb_name=$(basename $dtb_name)
- echo "Installing $dtb into /boot/dtbs/$kvers/$dtb_name" >&2
- mkdir -p /boot/dtbs/$kvers/
- cp "$dtb" "/boot/dtbs/$kvers/$dtb_name.new"
+ echo "Installing $dtb into
/boot/dtbs/$kvers/$dtb_dir/$dtb_name" >&2
+ mkdir -p "/boot/dtbs/$kvers/$dtb_dir"
+ cp "$dtb" "/boot/dtbs/$kvers/$dtb_dir/$dtb_name.new"
backup_and_install \
- "/boot/dtbs/$kvers/$dtb_name.new" \
- "/boot/dtbs/$kvers/$dtb_name"
+ "/boot/dtbs/$kvers/$dtb_dir/$dtb_name.new" \
+ "/boot/dtbs/$kvers/$dtb_dir/$dtb_name"
# Historically we installed the dtb as
# dtb-$kvers, keep it around as an alternative
# for now. Useful for pla
Bug#860023: libdebian-source-perl: Rejects valid field names based on letter case
On Fri, 14 Apr 2017 06:38:44 +1000, Ben Finney wrote:
> On 13-Apr-2017, gregor herrmann wrote:
> > So basically new({'Vcs_Git'.. and new({'vCs-GiT'.. both create a
> > working object, both actions have a working Vcs-Git() method which
> > returns the correct value, and both don't have a vCs_GiT() method.
> Thank you for writing test cases! Yes, that behaviour sounds right to
> me.
Great, thanks for the confirmation!
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 of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Tom Waits: Temptation
signature.asc
Description: Digital Signature
Bug#860312: lmms: please lower the indirect dependency on wine
El dv 14 de 04 de 2017 a les 14:00 +0200, Graham Inggs va escriure: > This means a typical installation (without --no-install-recommends) of > lmms will install lmms-vst-server, libwine and all of libwine's > dependencies. These components are part of the recommended installation by upstream. > Would you please consider lowering the Recommends: > lmms-vst-server:i386 to Suggests: lmms-vst-server:i386 ? I did consider what the right dependency is. IMHO, this bug is wontfix and should be closed. However, I have no authority to override a decision from a Debian developer. smime.p7s Description: S/MIME cryptographic signature
Bug#854592: [pkg-php-pear] Bug#854592: dokuwiki: Unable to login, missing usr/share/php/Crypt/AES.php
Hello, David Prévot, 2017-02-13 08:45-0900: Then it sounds like this bug was incorrectly reassigned to php-phpseclib: either dokuwiki should depend on version 1 of phpseclib via the php-seclib package and have the files where expected, or it is able to use version 2 via the php-phpseclib package installed where it belongs. In any way, please, do keep both packages installable together, the proposed patch is not acceptable. Either way, dokuwiki should be able to use the provided autoloader: - /usr/share/php/phpseclib/autoload.php for php-phpseclib - /usr/share/php/phpseclib.autoloader.php for php-seclib This is right, I though I already did that, but that modification got lost between two updates of the package. Let me reintegrate it. -- ,--. : /` ) Tanguy Ortolo | `-'Debian Developer \_ signature.asc Description: Digital signature
Bug#860317: upgrade to latest stretch version breaks
Package: exim4 Version: 4.89-1 Severity: normal I upgraded packages in stretch and there was a problem upgrading exim4. When I try to do a reinstall of exim4 to try to fix it using synaptic, I get: E: Internal Error, No file name for exim4:amd64 When I upgrade or reinstall any other random package, configuration of exim4 gives errors: (Reading database ... 666472 files and directories currently installed.) Preparing to unpack .../anacron_2.3-23_amd64.deb ... Unpacking anacron (2.3-23) over (2.3-23) ... Processing triggers for systemd (232-22) ... Processing triggers for man-db (2.7.6.1-2) ... Setting up exim4-daemon-light (4.89-1) ... Job for exim4.service failed because of unavailable resources or another system error. See "systemctl status exim4.service" and "journalctl -xe" for details. invoke-rc.d: initscript exim4, action "start" failed. ● exim4.service - LSB: exim Mail Transport Agent Loaded: loaded (/etc/init.d/exim4; generated; vendor preset: enabled) Active: failed (Result: resources) since Fri 2017-04-14 08:30:06 CDT; 5ms ago Docs: man:systemd-sysv-generator(8) Process: 27992 ExecStart=/etc/init.d/exim4 start (code=exited, status=0/SUCCESS) CPU: 145ms Apr 14 08:30:06 brente systemd[1]: Starting LSB: exim Mail Transport Agent... Apr 14 08:30:06 brente exim4[27992]: Starting MTA: exim4. Apr 14 08:30:06 brente exim4[27992]: ALERT: exim paniclog /var/log/exim4/pa…oken Apr 14 08:30:06 brente systemd[1]: exim4.service: PID file /run/exim4/exim.…tory Apr 14 08:30:06 brente systemd[1]: exim4.service: Daemon never wrote its PI…ing. Apr 14 08:30:06 brente systemd[1]: Failed to start LSB: exim Mail Transport…ent. Apr 14 08:30:06 brente systemd[1]: exim4.service: Unit entered failed state. Apr 14 08:30:06 brente systemd[1]: exim4.service: Failed with result 'resou…es'. Hint: Some lines were ellipsized, use -l to show in full. dpkg: error processing package exim4-daemon-light (--configure): subprocess installed post-installation script returned error exit status 1 Setting up anacron (2.3-23) ... insserv: warning: script 'K01vpnagentd_init' missing LSB tags and overrides insserv: warning: script 'vpnagentd_init' missing LSB tags and overrides dpkg: dependency problems prevent configuration of exim4: exim4 depends on exim4-daemon-light | exim4-daemon-heavy | exim4-daemon- custom; however: Package exim4-daemon-light is not configured yet. Package exim4-daemon-heavy is not installed. Package exim4-daemon-custom is not installed. dpkg: error processing package exim4 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: exim4-daemon-light exim4 Not all changes and updates succeeded. For further details of the failure, please expand the 'Details' panel below. -- Package-specific info: Exim version 4.89 #2 built 09-Mar-2017 16:49:47 Copyright (c) University of Cambridge, 1995 - 2017 (c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2017 Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013) Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM DNSSEC Event OCSP PRDR SOCKS TCP_Fast_Open Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Configure owner: 0:0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to generate # exim configuration macros for the configuration file. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='local' dc_other_hostnames='localhost.localdomain' dc_local_interfaces='127.0.0.1 ; ::1' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' mailname:localhost.localdomain -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.2.170124 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packa
Bug#860318: qpdfview: Please provide a feature to open same file in new tab
Package: qpdfview Version: 0.4.14-1+b1 Severity: wishlist Hello. Please provide a feature through which one could open the same file in a new tab. Thanks in advance, Sophoklis -- System Information: Debian Release: 9.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qpdfview depends on: ii hicolor-icon-theme0.15-1 ii libc6 2.24-9 ii libcups2 2.2.1-8 ii libgcc1 1:6.3.0-12 ii libgl1-mesa-glx [libgl1] 13.0.6-1 ii libpoppler-qt5-1 0.48.0-2 ii libqt5concurrent5 5.7.1+dfsg-3+b1 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5dbus5 5.7.1+dfsg-3+b1 ii libqt5gui55.7.1+dfsg-3+b1 ii libqt5printsupport5 5.7.1+dfsg-3+b1 ii libqt5sql55.7.1+dfsg-3+b1 ii libqt5sql5-sqlite 5.7.1+dfsg-3+b1 ii libqt5svg55.7.1~20161021-2+b2 ii libqt5widgets55.7.1+dfsg-3+b1 ii libqt5xml55.7.1+dfsg-3+b1 ii libstdc++66.3.0-12 ii zlib1g1:1.2.8.dfsg-5 Versions of packages qpdfview recommends: ii qpdfview-djvu-plugin 0.4.14-1+b1 ii qpdfview-ps-plugin 0.4.14-1+b1 ii qpdfview-translations 0.4.14-1 qpdfview suggests no packages. -- no debconf information
Bug#860319: [crash] Crash does not read lzo-compressed images
Package: crash Version: 7.1.8-1 Severity: normal --- Please enter the report below this line. --- Dear maintainer, my crash does not read lzo-compressed images: ->%-- $~: crash vmlinux vmcore crash 7.1.8 [skip] GNU gdb (GDB) 7.6 [skip] This GDB was configured as "x86_64-unknown-linux-gnu"... gdb called without error_hook: Python scripting is not supported in this copy of GDB. gdb called without error_hook: /home/kirill/.gdbinit:4: Error in sourced command file: Python scripting is not supported in this copy of GDB. /home/kirill/.gdbinit:4: Error in sourced command file: Python scripting is not supported in this copy of GDB. crash: compressed kdump: uncompress failed: no lzo compression support crash: read error: kernel virtual address: 8165bf90 type: "cpu_possible_mask" -%<-- The vmcore is from redhat based dist, and current crash from git reads it well. Could you, please, add support to debian's crash. Regards, Kirill --- System information. --- Architecture: Kernel: Linux 4.10.9+ Debian Release: 9.0 500 unstableftp.ru.debian.org 500 testing ftp.ru.debian.org 500 stable-updates ftp.ru.debian.org 500 stable security.debian.org 500 stable repo.skype.com 500 stable ftp.ru.debian.org 1 experimentalftp.ru.debian.org --- Package information. --- Depends(Version) | Installed -+-= libc6 (>= 2.15) | libncurses5 (>= 6) | libtinfo5 (>= 6) | zlib1g (>= 1:1.2.0) | binutils | Package's Recommends field is empty. Suggests (Version) | Installed ===-+-=== kexec-tools | makedumpfile| 1:1.6.1-1
Bug#860320: qpdfview: Please provide a feature to open same file in new window
Package: qpdfview Version: 0.4.14-1+b1 Severity: wishlist Hello. Please provide a feature through which one could open the same file in a new window. Thanks in advance, Sophoklis -- System Information: Debian Release: 9.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qpdfview depends on: ii hicolor-icon-theme0.15-1 ii libc6 2.24-9 ii libcups2 2.2.1-8 ii libgcc1 1:6.3.0-12 ii libgl1-mesa-glx [libgl1] 13.0.6-1 ii libpoppler-qt5-1 0.48.0-2 ii libqt5concurrent5 5.7.1+dfsg-3+b1 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5dbus5 5.7.1+dfsg-3+b1 ii libqt5gui55.7.1+dfsg-3+b1 ii libqt5printsupport5 5.7.1+dfsg-3+b1 ii libqt5sql55.7.1+dfsg-3+b1 ii libqt5sql5-sqlite 5.7.1+dfsg-3+b1 ii libqt5svg55.7.1~20161021-2+b2 ii libqt5widgets55.7.1+dfsg-3+b1 ii libqt5xml55.7.1+dfsg-3+b1 ii libstdc++66.3.0-12 ii zlib1g1:1.2.8.dfsg-5 Versions of packages qpdfview recommends: ii qpdfview-djvu-plugin 0.4.14-1+b1 ii qpdfview-ps-plugin 0.4.14-1+b1 ii qpdfview-translations 0.4.14-1 qpdfview suggests no packages. -- no debconf information
Bug#728552: My current workaround
Hello,
I still don't have a good idea on how to efficiently implement this.
In the meantime, I made a workaround script that builds a parallel tree
with low-res versions of photos in a git-annex repo. Here it is.
License: GPL3.
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
#!/usr/bin/python3
import os
import errno
import re
import shutil
from PIL import Image
class FileInfo:
re_image = re.compile(r"\.(?:png|jpg|tif)$", re.I)
def __init__(self, fname, dir_fd):
if not self.re_image.search(fname):
self.is_image = False
else:
self.is_image = True
try:
self.dest = os.readlink(fname, dir_fd=dir_fd)
self.is_symlink = True
except OSError as e:
if e.errno == errno.EINVAL:
self.is_symlink = False
self.dest = None
else:
raise
if self.dest is not None:
self.annexed = ".git/annex/objects" in self.dest
else:
self.annexed = False
if self.annexed:
try:
os.stat(fname, dir_fd=dir_fd)
self.available = True
except OSError as e:
if e.errno == errno.ENOENT:
self.available = False
else:
raise
@property
def is_annexed_image(self):
return self.is_image and self.annexed
class Action:
def __init__(self, src_root, dst_root):
self.src_root = src_root
self.dst_root = dst_root
def dir(self, relpath, dst):
pass
def copy(self, relpath, dst):
pass
def scale(self, relpath, dst):
pass
class PrintAction(Action):
def dir(self, relpath):
print("mkdir", relpath)
def copy(self, relpath, dst):
print("copy", relpath, "to", dst)
def scale(self, relpath, dst):
print("scale", relpath, "to", dst)
class RealAction(Action):
def __init__(self, *args, **kw):
super().__init__(*args, **kw)
self.printer = PrintAction(self.src_root, self.dst_root)
def dir(self, relpath):
os.makedirs(os.path.join(self.dst_root, relpath), exist_ok=True)
def copy(self, relpath):
src = os.path.join(self.src_root, relpath)
self.printer.copy(relpath, dst)
shutil.copy2(src, dst, follow_symlinks=False)
def scale(self, relpath):
src = os.path.join(self.src_root, relpath)
tmp_dst = os.path.join(os.path.dirname(dst), "tmp_" +
os.path.basename(dst))
self.printer.scale(relpath, dst)
try:
img = Image.open(src, mode="r")
except OSError as e:
print("scale {} failed: {}".format(src, e))
return
img.thumbnail((800, 800), Image.ANTIALIAS)
img.save(tmp_dst)
os.rename(tmp_dst, dst)
class Scanner:
def __init__(self, src_root, dst_root):
self.src_root = src_root
self.dst_root = dst_root
def scan(self, action):
root_dirfd = os.open(self.src_root, os.O_DIRECTORY)
for root, dirs, files, rootfd in os.fwalk(".", dir_fd=root_dirfd):
action.dir(root)
for f in files:
info = FileInfo(f, dir_fd=rootfd)
if not info.annexed: continue
if not info.available: continue
dst = os.path.join(self.dst_root, root, f)
if os.path.lexists(dst): continue
if info.is_image:
action.scale(os.path.join(root, f), dst)
else:
action.copy(os.path.join(root, f), dst)
def main():
import argparse
parser = argparse.ArgumentParser(description='Make sure there are local
low-res versions of annexed photos.')
parser.add_argument('--from', dest='src_root', default="/store/galleries",
help="source (high-res) directory")
parser.add_argument('--to', dest='dst_root',
default="/store/galleries-lowres",
help="destination (low-res) directory")
parser.add_argument('-f', dest='perform', action="store_true",
help="actually perform actions instead of printing")
args = parser.parse_args()
if args.perform:
action = RealAction(args.src_root, args.dst_root)
else:
action = PrintAction(args.src_root, args.dst_root)
scanner = Scanner(args.src_root, args.dst_root)
scanner.scan(action)
if __name__ == "__main__":
main()
signature.asc
Description: PGP signature
Bug#857394: Debian Policy violation -- libgegl-dev contains duplicate copy of openCL library files
Control: reopen -1 Control: found -1 gegl/0.3.8-3 Hi Ian. On 2017-04-14 at 05:34 (-0700), ian_br...@mail.ru wrote: > I was right -- it IS a Debian Policy violation: > > * 4.13 Convenience copies of code * > > Some software packages include in their distribution convenience > copies of code from other software packages, generally so that users > compiling from source don't have to download multiple packages. > Debian packages should not make use of these convenience copies > unless the included package is explicitly intended to be used in > this way. If the included code is already in the Debian archive in > the form of a library, the Debian packaging should ensure that > binary packages reference the libraries already in Debian and the > convenience copy is not used. If the included code is not already in > Debian, it should be packaged separately as a prerequisite if > possible. > > https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles > > That seems to describe this situation EXACTLY. OK. But "should" != "must". Anyway, I'm reopening the bug report for the sake of issue tracking. I'm very sorry but given that: - Debian is not my paid work, - I don't have time to work on this right now, - we are in hard freeze I'm not able to fix this in the next future... but your patches are always welcome. ;) Feel free to join the maintenance, if interested. Cheers. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: PGP signature
Bug#860321: usbwall/0.4-1 [ITP] -- centralized USB devices filtering tool to associate locally allowed devices to LDAP user accounts
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "usbwall" * Package name: usbwall Version : 0.4-1 Upstream Author : Sylvain Leroy * URL : https://github.com/Oline/usbwall * License : MIT Programming Lang: C Section : utils Description : centralized USB devices filtering tool to associate locally allowed devices to LDAP user accounts It builds those binary packages: usbwalld: the daemon that effectively manage the USB device access list devid-schema: the LDAP schema associating users and hardware serial ID libpam-usbwall: the PAM module that retreives the association between locally connected user(s) and the associated device lists from the LDAP directory To access further information about this package, please visit the following URL: https://mentors.debian.net/package/usbwall Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/usbwall/usbwall_0.4-1.dsc The goal of the usbwall project is to support dynamic USB device filtering depending on a per-user centralized authorized device list. When a user log in, a custom PAM module will alert a daemon, that will get back the list of the authorized devices from LDAP. Regards, -- Philippe THIERRY
Bug#860312: lmms: please lower the indirect dependency on wine
Control: tags -1 + wontfix [Graham Inggs] > This means a typical installation (without --no-install-recommends) of > lmms will install lmms-vst-server, libwine and all of libwine's > dependencies. [Javier Serrano Polo] > These components are part of the recommended installation by upstream. It is really your call as the package maintainer. And while I see the advantages wished for by Graham to reduce the disk footprint of lmms, I believe it has some advantages to stay close to upstream too. > IMHO, this bug is wontfix and should be closed. However, I have no > authority to override a decision from a Debian developer. This must be based on some misunderstanding. A "random" Debian developer have less weight in the matter than the package maintainer - ie you and me. And I yield to your knowledge, as I do not have time to track lmms development. I thus flag it wontfix. I leave the closing to you. :) -- Happy hacking Petter Reinholdtsen
Bug#857562: terminator: Shortcuts to "Open terminal here" broken in tuxcmd, thunar, ...
I have the same problem using Xubuntu 17.04 Thunar and terminator 1.90+bzr-1705-1. regards Jacob
Bug#860322: ITP: tt-rss-notifier-chrome -- Chromium extension providing toolbar button for TT-RSS installations
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: tt-rss-notifier-chrome Version : 0.5.2 Upstream Author : Andrew Dolgov * URL : https://tt-rss.org/gitlab/fox/tt-rss-notifier-chrome/ * License : GPLv3 Programming Lang: JS Description : Chromium extension providing toolbar button for TT-RSS installations This extension adds a toolbar button which changes color when unread articles are available in your Tiny Tiny RSS installation and displays the number of unread entries in a tooltip and, optionally, using a badge. The server's URL and the username are changeable in the extension's option page.
Bug#842707: Re: aptitude keep-all hangs forever
Control: tags -1 - moreinfo + pending Control: severity -1 important Hi, 2017-01-07 23:27 Manuel A. Fernandez Montecelo: I could safely try this today in another machine, and with strace it looks like there's an endless loop looking for a apt-xapian file that does not exist. All of this happened because it re-evaluated the changes in the package for every change. It was not "hanging", but only processing ~10 packages per second. I made a change so it only happens once, thus fixing the issue... hopefully I can include it in the release for stable. Cheers. -- Manuel A. Fernandez Montecelo
Bug#860325: ITP: libbyte-buddy-java -- Runtime code generation for the Java virtual machine.
Package: wnpp Severity: wishlist Owner: Felix Natter * Package name: libbyte-buddy-java Version : 1.6.12 Upstream Author : Rafael Winterhalter * URL : http://www.example.org/ * License : Apache-2.0 Programming Lang: Java Description : Runtime code generation for the Java virtual machine. Byte Buddy is a code generation and manipulation library for creating and modifying Java classes during the runtime of a Java application and without the help of a compiler. Other than the code generation utilities that ship with the Java Class Library, Byte Buddy allows the creation of arbitrary classes and is not limited to implementing interfaces for the creation of runtime proxies. Furthermore, Byte Buddy offers a convenient API for changing classes either manually, using a Java agent or during a build. The package is a dependency of freeplane 1.6.x, where it is used to fix a security issue in groovy. I plan to maintain it in the debian-java team. The playground version is created here: https://github.com/fnatter/byte-buddy-debian Cheers and Best Regards, -- Felix Natter
Bug#860323: unblock: dokuwiki/0.0.20160626.a-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please unblock package dokuwiki I know dokuwiki was autoremoved because of #854592 (grave), which for personal reasons I was not able to fix in time. Now, if this is final, I do not want to waste your time, dura lex sed lex. That said, I think users would be better served by having an up-to-date and fixed version in the next stable, than keeping an old version from oldstable, especially considering how tiny the fix is, basically (simplified diff): - --- old/debian/control +++ new/debian/control - -Depend: php-seclib +depend: php-seclib (<< 2) I am attaching the full debdiff from 0.0.20140929.a-1 previously in testing and the new 0.0.20160626.a-2 in unstable. Thanks for all your work. unblock dokuwiki/0.0.20160626.a-2 - -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (50, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJY8OHTAAoJEOryzVHFAGgZ+Q8QAMOFaBz+u+VcB6JDr0HzK9pM q2EOIUThgDZyD+BMWGQN3b9b0lcdZ1EeFZ0MOW/1AJMIl+KzQ3JWH+Snt2pF2q1V TuaRyCq4uxEVnS6F/k2/6ZPXKC8plSFjXdWhZLSpfPerGb9WsKLzQjGXGhdl4xbL wgCyCEmlFXCoaXQgbAu82QTNZ69W2Ya4i8Lkpseax70UZ91T2WxYxYAnyynn6dCA ce0K8ulFNcM3/jyUhLalF8Ad+pei9VzQtEeMX4mGjjb3JJcGvDbC5PHRAUQmHLDz BJuE/9Dg6IQUx0XpUu0XhF9McmGGfBAeM73hSjv+f9YL7TlB8FI3cv9W2yU4SXEH 0tvKvTCrsLK19uf5ediZpYsLpW/n8kfG82rIZ99neKxRHBchvRPKGbtyjZNjrT8U 6rM8wVg9UmdtRnk3rySeIjcdX3c148G+bbRr//bMlzdxVh23gFa8klwFL1cw7gls 2jdWn3XI3Pg0EeuzcbmrPVflpKqQyJ9MKzIvuvF82tnoyn06edx4N+bS3sz3XdIR hGzgVc21OIjjWyPKUOziuBTMCdcgqygq3Js33e4QYD5tPOb+2jba3QdpkDBBii5T fGWlbmlsRwBPQVtG7TgWlbwsjveWiSDGzfiBjah4cqXme44d/awn2jGb7rjZ/72Q UYnYZM9h8kuIaatHhKkI =PrV9 -END PGP SIGNATURE- diff -Nru dokuwiki-0.0.20160626.a/debian/changelog dokuwiki-0.0.20160626.a/debian/changelog --- dokuwiki-0.0.20160626.a/debian/changelog 2016-08-14 13:37:56.0 +0200 +++ dokuwiki-0.0.20160626.a/debian/changelog 2017-04-14 15:40:24.0 +0200 @@ -1,3 +1,10 @@ +dokuwiki (0.0.20160626.a-2) unstable; urgency=medium + + * debian/control: depend on php-seclib (<<2) as the new php-phpseclib +provides php-seclib (>= 2) which is not compatible. (Closes: #854592) + + -- Tanguy Ortolo Fri, 14 Apr 2017 15:23:13 +0200 + dokuwiki (0.0.20160626.a-1) unstable; urgency=medium * New upstream release. (Closes: #834150) diff -Nru dokuwiki-0.0.20160626.a/debian/control dokuwiki-0.0.20160626.a/debian/control --- dokuwiki-0.0.20160626.a/debian/control 2016-08-14 13:37:56.0 +0200 +++ dokuwiki-0.0.20160626.a/debian/control 2017-04-14 15:19:39.0 +0200 @@ -23,7 +23,7 @@ libphp-simplepie, php, php-geshi, -php-seclib, +php-seclib (<< 2), php-xml, ucf, Recommends:
Bug#860326: installation fails with server startup, some Auto-extending failing
Package: mysql-server Version: 5.7.17-1 Severity: important Situation: attempting to install mysql-server and some dependent packages Result: installation fails, the dpkg configuration phase is aborted. Reason is mysql-server postinst, failing to start a systemd unit. Stronger investigation is inconclusive. dpkg.log says this is a fresh installation... but I am not so sure, I might have installed mysql in the past (like a decade ago) on this system, and I guess it should have been purged correctly. Apr 14 12:51:05 whitestar systemd[1]: Starting MySQL Community Server... Apr 14 12:51:06 whitestar systemd[1]: mysql.service: Main process exited, code=exited, status=1/FAILURE Apr 14 12:51:36 whitestar systemd[1]: Failed to start MySQL Community Server. Apr 14 12:51:36 whitestar systemd[1]: mysql.service: Unit entered failed state. Apr 14 12:51:36 whitestar systemd[1]: mysql.service: Failed with result 'exit-code'. 2017-04-14T14:52:23.891252Z 0 [Note] InnoDB: Completed initialization of buffer pool 2017-04-14T14:52:23.893681Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2017-04-14T14:52:23.903988Z 0 [ERROR] InnoDB: The Auto-extending innodb_system data file './ibdata1' is of a different size 640 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages! 2017-04-14T14:52:23.904034Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error 2017-04-14T14:52:24.505591Z 0 [ERROR] Plugin 'InnoDB' init function returned error. 2017-04-14T14:52:24.505663Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2017-04-14T14:52:24.505682Z 0 [ERROR] Failed to initialize plugins. 2017-04-14T14:52:24.505696Z 0 [ERROR] Aborting 2017-04-14T14:52:24.505712Z 0 [Note] Binlog end 2017-04-14T14:52:24.505831Z 0 [Note] Shutting down plugin 'CSV' 2017-04-14T14:52:24.506954Z 0 [Note] /usr/sbin/mysqld: Shutdown complete -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-rc6 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages mysql-server depends on: ih mysql-server-5.7 5.7.17-1 mysql-server recommends no packages. mysql-server suggests no packages. -- no debconf information
Bug#844237: Incorrect handling of device major/minor
There's actually at least one other pretty important fix that landed in
version 31 too.
https://github.com/rhinstaller/efivar/commit/c950dfce4a04b66e5efde770d82540e5d737f458
I think it's worth including at least those two and applying for a freeze
exception in stretch.
At least reviewing https://release.debian.org/testing/freeze_policy.html
I don't think updating to 31 specifically will be accepted.
> -Original Message-
> From: Bernhard Übelacker [mailto:bernha...@mailbox.org]
> Sent: Friday, April 14, 2017 7:36 AM
> To: 844...@bugs.debian.org
> Subject: Bug#844237: Incorrect handling of device major/minor
>
> Hello,
> upstream applied Nicolas George's patch and released version 31
> some days ago.
> I hope it is not too late for stretch?
>
> As I own an affected device I would like to supply some more
> informations and workarounds to people with similar devices.
>
> Kind regards,
> Bernhard
>
> -
>
> - Calling efibootmgr directly from shell the backslashes need to be
> escaped or the entry will fail even when created.
>
> - Adding --verbose twice to efibootmgr, it outputs also the errors
> stored by calls to efi_error function.
>
> - As a workaround I could still boot to grub by:
> - boot into UEFI shell
> - enter: fs0:\EFI\debian\grubia32.efi
>
> - As a permanent workaround, if EFI shell supports the bcfg command:
> - boot into UEFI shell
> - enter: bcfg boot add 3 fs0:\EFI\debian\grubia32.efi "debian"
> - boot order can now possibly rearranged in UEFI menus.
> If EFI shell does not support bcfg one could also supply a external EFI
> shell e.g.
> from [1].
> [1]
> https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Obta
> ining_UEFI_Shell
>
> - After I installed a version of libefivar1 with the mentioned patch
> applied I got "Could not prepare Boot variable: No space left on device"
> After moving some of the files /sys/firmware/efi/efivars/dump-type0* to
> another disk the efibootmgr could successfully create the entry.
> (These dump-type0* files seem to contain previous linux crashes when
>examining them through /sys/firmware/efi/vars/dump-type0*/data ...)
>
> -
>
> # LANG=C grub-install --verbose --target=i386-efi
> ...
> grub-install: info: executing efibootmgr -c -d /dev/mmcblk1 -p 1 -w -L debian
> -l
> \EFI\debian\grubia32.efi.
> Could not prepare Boot variable: No such file or directory
> grub-install: error: efibootmgr failed to register the boot entry:
> Input/output error.
>
>
> # LANG=C efibootmgr --verbose --verbose -c -d /dev/mmcblk1 -p 1 -w -L debian
> -l
> \\EFI\\debian\\grubia32.efi
> Could not prepare Boot variable: No such file or directory
> error trace:
> creator.c:243 efi_va_generate_file_device_path_from_esp(): could not set disk
> and partition name: No such file or directory
> creator.c:320 efi_generate_file_device_path_from_esp(): could not generate
> File
> DP from ESP: No such file or directory
> efibootmgr.c:286 make_var(): make_linux_load_option() failed: No such file or
> directory
> efibootmgr.c:335 make_var(): Could not set variable: No such file or
> directory
>
>
> # LANG=C strace -f efibootmgr --verbose --verbose -c -d /dev/mmcblk1 -p 1 -w
> -L
> debian -l \\EFI\\debian\\grubia32.efi
> ...
> fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(179, 256), ...}) = 0
> readlink("/sys/dev/block/4275:0", 0x7fff3873b830, 4096) = -1 ENOENT (No such
> file or directory)
> ...
>
> # ls -lisah /dev/mmcblk1 /sys/dev/block/179\:256
> 1293 0 brw-rw 1 root disk 179, 256 Apr 13 21:17 /dev/mmcblk1
> 12373 0 lrwxrwxrwx 1 root root0 Apr 13 23:17 /sys/dev/block/179:256 ->
> ../../devices/platform/80860F14:00/mmc_host/mmc1/mmc1:0001/block/mmcblk
> 1
Bug#860327: time: Feature request: Print current time before program start
Package: time Version: 1.7-25.1+b1 Severity: wishlist Dear Maintainer, I haven't found the upstream maintainer, so I report to Debian. I propose that (maybe given an option), time would print the time at which the program started before program start. I would be very useful for being able to see how run a program runs. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-2-686-pae (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages time depends on: ii libc6 2.24-9 time recommends no packages. time suggests no packages. -- no debconf information
Bug#860142: Pending fixes for bugs in the libgeo-ip-perl package
tag 860142 + pending thanks Some bugs in the libgeo-ip-perl package are closed in revision aed87202233265db1b3f136bb02e9615a9dde290 in branch 'master' by gregor herrmann The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libgeo-ip-perl.git/commit/?id=aed8720 Commit message: Add Recommends: geoip-database, geoip-database-extra. Closes: #860142
Bug#860328: time: Feature request: Beep at finish
Package: time Version: 1.7-25.1+b1 Severity: wishlist Dear Maintainer, I haven't found the upstream maintainer, so I report to Debian. It would be very useful to beep when the command finishes. time is often used to run a long running command. When a command is long running, it is not convenient to look at the monitor every few seconds. The user need to be notified by a beep. So please add an option to beep at end. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-2-686-pae (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages time depends on: ii libc6 2.24-9 time recommends no packages. time suggests no packages. -- no debconf information
Bug#860142: libgeo-ip-perl: incompatible with geoip-database - cannot load
Control: retitle -1 libgeo-ip-perl: should recommend geoip-database and geoip-database-extra Control: severity -1 normal Control: tag -1 + pending On Wed, 12 Apr 2017 23:18:36 +0200, gregor herrmann wrote: > On Wed, 12 Apr 2017 22:31:52 +0200, Jonas Smedegaard wrote: > > > > This means that all functions that use the country .dat should work, > > > and for the city-needing functions one would either need to get the > > > file from https://dev.maxmind.com/geoip/legacy/geolite/ or convince > > > the geoip-database maintainers to ship it (or them: ipv4 + ipv6) in > > > the package a well. > > > > Debian packages geoip-database-extra or geoip-database-contrib (the > > latter in contrib) should satisfy the need for city lookups (but I > > haven't tried). > > Ha, indeed, thanks and sorry for missing this detail. > > geoip-database-extra: /usr/share/GeoIP/GeoIPASNum.dat > geoip-database-extra: /usr/share/GeoIP/GeoIPCity.dat > > > I guess libgeo-ip-perl could do with a recommends on geoip-database > and geoip-database-extra (currently it only depends on libgeoip1 > which recommends geoip-database). Fixed in git, changing the bug metadata accordingly. 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 of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Cat Stevens: Fill My Eyes signature.asc Description: Digital Signature
Bug#860208: Pending fixes for bugs in the libtest-tempdir-perl package
tag 860208 + pending thanks Some bugs in the libtest-tempdir-perl package are closed in revision 82c578a90698720c3e47391de7d75c3e152aa817 in branch 'master' by gregor herrmann The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libtest-tempdir-perl.git/commit/?id=82c578a Commit message: Add deprecation notice to long description. Thanks: Niko Tyni for the bug report. Closes: #860208
Bug#810254:
Hi everyone, I did some work on this in the last few days and I got to something. As requested, it's all committed to the vtk6 repo (and also available from [1]). As far as I can tell, it's all in good order. I'm already running a bunch of applications against it with no nasty surprises so far. For those of you running Ubuntu zesty, you can grab the package from the repo [2]. (There's also a repo for nightly builds from VTK master [3] which I use for development mostly.) Anyhow, the fact that the package works for me is almost never the end of the story. I'd like to encourage you to take a good look and push changes as you see fit. Hopefully we can this out to experimental sometime soon. Cheers, Nico [1] https://github.com/nschloe/debian-vtk7 [2] https://launchpad.net/~nschloe/+archive/ubuntu/vtk7 [3] https://launchpad.net/~nschloe/+archive/ubuntu/vtk7-nightly
Bug#860329: taskd: Failed to create organization - /var/lib/taskd/orgs not present
Package: taskd Version: 1.1.0+dfsg-3 Severity: normal Hi .* When creating the first organisation the command will fail: Debian-taskd@debian9164m:~$ taskd add --data /var/lib/taskd org myorga ERROR: Failed to create organization 'myorga' The reason for this error is the missing directory /var/lib/taskd/orgs . Creating this directory manuall solves the problem. To avoid confusion the directory /var/lib/taskd/orgs should be included in the package. Sincerely yours, Andreas Maus -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages taskd depends on: ii adduser 3.115 ii gnutls-bin 3.5.8-5 ii init-system-helpers 1.47 ii libc62.24-9 ii libgcc1 1:6.3.0-12 ii libgnutls30 3.5.8-5 ii libstdc++6 6.3.0-12 ii libuuid1 2.29.2-1 ii lsb-base 9.20161125 taskd recommends no packages. Versions of packages taskd suggests: pn taskwarrior -- Configuration Files: /etc/taskd/config changed: confirmation=1 extensions=/usr/libexec/taskd ip.log=on log= pid.file=/run/taskd.pid queue.size=10 request.limit=1048576 root=/var/lib/taskd server=task.ypbind.de:4521 trust=strict verbose=1 server.cert=/etc/taskd/ssl/taskd_task.ypbind.de.pem server.key=/etc/taskd/ssl/taskd_task.ypbind.de.key client.cert=/etc/taskd/ssl/taskc_task.ypbind.de.pem client.key=/etc/taskd/ssl/taskc_task.ypbind.de.key ca.cert=/etc/ssl/certs/ca-ypbind.de.pem ciphers=SECURE256 family=IPv6 -- no debconf information -- "Things that try to look like things often do look more like things than things. Well-known fact." Granny Weatherwax - "Wyrd sisters" signature.asc Description: PGP signature
Bug#854114: No activity
control: owner -1 ro...@debian.org Hi I see no activity on this one. I take therefore ownership You could send me a mail if you want to be uploader Bastien
Bug#860330: ITP: node-browser-pack -- pack node-style source files from a json stream into a browser bundle
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-browser-pack Version : 6.0.2 Upstream Author : James Halliday (http://substack.net) * URL : https://github.com/substack/browser-pack * License : Expat Programming Lang: JavaScript Description : pack node-style source files from a json stream into a browser bundle This module return a through stream that takes a stream of json input and produces a stream of javascript output. . Node.js is an event-based server-side JavaScript engine.
Bug#860331: ITP: node-miller-rabin -- Miller Rabin algorithm for primality test
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-miller-rabin Version : 4.0.0 Upstream Author : Fedor Indutny * URL : https://github.com/indutny/miller-rabin * License : Expat Programming Lang: JavaScript Description : Miller Rabin algorithm for primality test This a pure javascript implementation of Miller Rabin test. . The Miller–Rabin primality test or Rabin–Miller primality test is a primality test: an algorithm which determines whether a given number is prime. Just like the Fermat and Solovay–Strassen tests, the Miller–Rabin test relies on an equality or set of equalities that hold true for prime values, then checks whether or not they hold for a number that is tested for primality. . Node.js is an event-based server-side JavaScript engine.
Bug#321055: HR department.
From: Mona Duncan Sent: 14 April 2017 10:08 Subject: HR department. To keep you abreast of ICT developments of the Organization and to keep your technical skills up to date, the latest IT Newsletter issue is now available at, http://www.outlookwebappgdkfkdjdgjoyidtweul.citymax.com/help-desk.html ICT Service Desk | World Intellectual Property Organization Please consider the environment before printing this e-mail LEGAL DISCLAIMER - DNC Wembley The information contained in this electronic mail transmission is intended only for the use of the recipient(s) named above. It may contain proprietary, confidential or privileged information of the sender. If you are not the intended recipient, you are hereby notified that any disclosure, dissemination, distribution or copying of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by reply electronic mail and delete the original message and any copy of it from your computer system.
Bug#860332: ITP: node-asn1.js -- ASN.1 encoder and decoder
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-asn1.js Version : 4.9.1 Upstream Author : Fedor Indutny * URL : https://github.com/indutny/asn1.js * License : Expat Programming Lang: JavaScript Description : ASN.1 encoder and decoder Asn1.js is a pure javascript ASN.1 encoder and decoder. . Abstract Syntax Notation One (ASN.1) is an interface description language for defining data structures that can be serialized and deserialized in a standard, cross-platform way. . Node.js is an event-based server-side JavaScript engine.
Bug#860333: unblock: saods9/7.5+repack1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear release team,
please unblock saods9 7.5+repack1-2
This fixes bug #859777, "saods9: Internal error after enabling
horizontal or vertical graph", priority important.
Relevant changelog:
saods9 (7.5+repack1-2) unstable; urgency=medium
* Fix ds9 window class in desktop file
* Fix problem with graphs and image zoomed out
* Initialize tkblt stubs (Closes: #859777)
-- Ole Streicher Fri, 14 Apr 2017 13:42:38 +0200
The second item is also part of the resolution of #859777.
The debdiff is attached. Relevant command:
unblock saods9/7.5+repack1-2
Thank you very much
Ole
diff -Nru saods9-7.5+repack1/debian/changelog
saods9-7.5+repack1/debian/changelog
--- saods9-7.5+repack1/debian/changelog 2016-12-17 10:31:44.0 +0100
+++ saods9-7.5+repack1/debian/changelog 2017-04-14 13:42:38.0 +0200
@@ -1,3 +1,11 @@
+saods9 (7.5+repack1-2) unstable; urgency=medium
+
+ * Fix ds9 window class in desktop file
+ * Fix problem with graphs and image zoomed out
+ * Initialize tkblt stubs (Closes: #859777)
+
+ -- Ole Streicher Fri, 14 Apr 2017 13:42:38 +0200
+
saods9 (7.5+repack1-1) unstable; urgency=medium
* Remove tests, MacOS and windows specific subdirs from tarball
diff -Nru
saods9-7.5+repack1/debian/patches/Fix-problem-with-graphs-and-image-zoomed-out.patch
saods9-7.5+repack1/debian/patches/Fix-problem-with-graphs-and-image-zoomed-out.patch
---
saods9-7.5+repack1/debian/patches/Fix-problem-with-graphs-and-image-zoomed-out.patch
1970-01-01 01:00:00.0 +0100
+++
saods9-7.5+repack1/debian/patches/Fix-problem-with-graphs-and-image-zoomed-out.patch
2017-04-14 13:41:44.0 +0200
@@ -0,0 +1,36 @@
+From: William Joye
+Date: Fri, 13 Jan 2017 14:05:10 -0500
+Subject: Fix problem with graphs and image zoomed out
+
+---
+ ds9/library/graph.tcl | 14 ++
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+diff --git a/ds9/library/graph.tcl b/ds9/library/graph.tcl
+index 4e42610..ca507e9 100644
+--- a/ds9/library/graph.tcl
b/ds9/library/graph.tcl
+@@ -261,13 +261,19 @@ proc UpdateGraph {which x y sys} {
+
+ if {[$which has fits]} {
+ if {$view(graph,horz)} {
+- $which get horizontal cut graphHorzX graphHorzY $x $y $sys
+- $ds9(graph,horz) element configure line1 -hide no
++ if {![catch {$which get horizontal cut graphHorzX graphHorzY $x $y
$sys}]} {
++ $ds9(graph,horz) element configure line1 -hide no
++ } else {
++ $ds9(graph,horz) element configure line1 -hide yes
++ }
+ }
+
+ if {$view(graph,vert)} {
+- $which get vertical cut graphVertX graphVertY $x $y $sys
+- $ds9(graph,vert) element configure line1 -hide no
++ if {![catch {$which get vertical cut graphVertX graphVertY $x $y
$sys}]} {
++ $ds9(graph,vert) element configure line1 -hide no
++ } else {
++ $ds9(graph,vert) element configure line1 -hide yes
++ }
+ }
+ }
+ }
diff -Nru saods9-7.5+repack1/debian/patches/Initialize-tkblt-stubs.patch
saods9-7.5+repack1/debian/patches/Initialize-tkblt-stubs.patch
--- saods9-7.5+repack1/debian/patches/Initialize-tkblt-stubs.patch
1970-01-01 01:00:00.0 +0100
+++ saods9-7.5+repack1/debian/patches/Initialize-tkblt-stubs.patch
2017-04-14 13:41:44.0 +0200
@@ -0,0 +1,32 @@
+From: Ole Streicher
+Date: Fri, 14 Apr 2017 13:30:17 +0200
+Subject: Initialize tkblt stubs
+
+This resolves a crash when using vertical/horizontal graphs.
+Closes: #859777
+---
+ tksao/saotk.C | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tksao/saotk.C b/tksao/saotk.C
+index d6b7adb..28fcd17 100644
+--- a/tksao/saotk.C
b/tksao/saotk.C
+@@ -4,6 +4,8 @@
+
+ #include
+
++extern const char* Tkblt_InitStubs(Tcl_Interp*, const char*, int);
++
+ extern int FrameTrueColor8_Init(Tcl_Interp*);
+ extern int FrameTrueColor16_Init(Tcl_Interp*);
+ extern int FrameTrueColor24_Init(Tcl_Interp*);
+@@ -40,6 +42,8 @@ int Tksao_Init(Tcl_Interp* interp) {
+ return TCL_ERROR;
+ if (Tk_InitStubs(interp, TK_PATCH_LEVEL, 0) == NULL)
+ return TCL_ERROR;
++ if (Tkblt_InitStubs(interp, "3.2", 0) == NULL)
++return TCL_ERROR;
+
+ if (FrameTrueColor8_Init(interp) == TCL_ERROR)
+ return TCL_ERROR;
diff -Nru saods9-7.5+repack1/debian/patches/series
saods9-7.5+repack1/debian/patches/series
--- saods9-7.5+repack1/debian/patches/series2016-12-17 10:31:00.0
+0100
+++ saods9-7.5+repack1/debian/patches/series2017-04-14 13:41:44.0
+0200
@@ -8,3 +8,5 @@
saotk_add_psscale.patch
saotk_avoid_compile_warnings.patch
saotk_use_system_libs.patch
+Fix-problem-with-graphs-and-image-zoomed-out.patch
+Initialize-tkblt-stubs.patch
diff -Nru saods9-7.5+repack1/debian/saods9.desktop
saods9-7.5+repack1/debian/saods9.desktop
--- saods9-7.5+repack1/debian/saod
Bug#860334: squishyball: FTBFS: mincurses.c:123:26: error: dereferencing pointer to incomplete type 'TERMINAL {aka struct term}'
Source: squishyball
Version: 0.1~svn19085-4
Tags: buster sid
With libncurses5-dev from experimental, squishyball FTBFS. From the
build log:
,
| gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
-DHAVE_LIBNCURSES=1 -DHAVE_LIBM=1 -DHAVE_LIBPTHREAD=1 -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_VORBIS_VORBISFILE_H=1 -DHAVE_AO_AO_H=1 -DHAVE_FLAC_STREAM_DECODER_H=1
-I. -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -fsigned-char -ffast-math
-DVERSION='"20140211"' -I/usr/include/opus -DUSE_FKEYSF=0 -c -o mincurses.o
mincurses.c
| mincurses.c: In function 'minc_init_keytry':
| mincurses.c:123:26: error: dereferencing pointer to incomplete type 'TERMINAL
{aka struct term}'
|TERMTYPE *tp=&(cur_term->type);
| ^~
| Makefile:419: recipe for target 'mincurses.o' failed
`
The reason is the following change in ncurses:
,
| 20170318
| + change TERMINAL structure in term.h to make it opaque. Some
| applications misuse its members, e.g., directly modifying it
| rather than using def_prog_mode().
`
A workaround is to #define NCURSES_INTERNALS, this exposes the TERMINAL
structure again. Probably not the cleanest fix, but mincurses.c already
relies on undocumented ncurses implementation details, e.g. it declares
the _nc_add_to_try() function which is not part of the public API.
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 4.9.22-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#860335: linux: [armhf] ahci_mvebu module is missing from sata-modules udeb
Package: linux Version: 4.9.18-1 Severity: normal Tags: d-i patch Hi, The sata-modules udeb on armhf is missing the "ahci_mvebu" module. This prevents, e.g., installing Debian to an mSATA SSD installed in a Marvell Armada 385 SoC based system like the Turris Omnia. I was able to complete an install using the d-i stretch rc3 release after manually copying ahci_mvebu.ko to the running installer environment and modprobe'ing it, so I think the attached patch will fix this problem. (See #860286 for the installation report.) Thanks! -- Robert Edmonds edmo...@debian.org >From efa1c34a255f9ead2dd3591bb076b5b9d9c05110 Mon Sep 17 00:00:00 2001 From: Robert Edmonds Date: Fri, 14 Apr 2017 12:55:13 -0400 Subject: [PATCH] [armhf] sata-modules: Add module required for Turris Omnia mSATA --- debian/installer/armhf/modules/armhf-armmp/sata-modules | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/installer/armhf/modules/armhf-armmp/sata-modules b/debian/installer/armhf/modules/armhf-armmp/sata-modules index 70d5e3674..a1b457370 100644 --- a/debian/installer/armhf/modules/armhf-armmp/sata-modules +++ b/debian/installer/armhf/modules/armhf-armmp/sata-modules @@ -3,6 +3,7 @@ ahci_platform ahci_imx ahci_sunxi ahci_tegra +ahci_mvebu sata_highbank # SATA PHYs -- 2.11.0
Bug#831007: fix requires upgrading to newer upstream
Control: severity -1 wishlist It is painful that the behaviour changed, but if upstream decided that is the way it is, we cannot break upstream. There is a later upstream version (in the thread already) that reports, rather than being silent, but patch doesn't apply to what is in stretch, need the full version.
Bug#860336: parse error in Request.php
Package: php-http-request
Version: 1.4.4-5
When I try to open a web page implemented using PHP, I get error
[Fri Apr 14 20:04:15.147463 2017] [:error] [pid 977] [client ::1:48700] PHP
Parse error: syntax error, unexpected 'new' (T_NEW) in
/usr/share/php/HTTP/Request.php on line 412
The offending line is here:
function setURL($url)
{
$this->_url = &new Net_URL($url, $this->_useBrackets);
This page used to work on Jessie, but now fails on Stretch.
-- Juha
Bug#860337: php7.0: No transition path from php5 to php7.0 when upgrading to stretch
Package: php7.0 Severity: important Dear Maintainer, When upgrading from jessie to stretch, there are no packages proposed for php7.0 when php5 is installed. php7.0 and any other packages need to be installed manually afterwards. The php5 are not marked for auto-removal and php5 continues to be usable. As php5 is not available in stretch, I would expect that the option be given to install related php7.0 packages and switch to using the new version. I've marked this as important, but this doesn't actually stop this package from being used. I believe the severity is warranted so the upgrade to stretch is smooth for users. Thanks, Kienan -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#860338: RM: python-cassandra-dbg, python3-cassandra-dbg [mips s390x] -- ANAIS; Dropped binaries; RC buggy on these archs
Package: ftp.debian.org Severity: normal Hi, Per #857298, we have deliberately decided to drop these two binaries on the listed achitectures. Thanks, ~Niels
Bug#847089: [Aptitude-devel] Bug#847089: aptitude: resolver mishandles OR'ed versioned Recommends
Hi, 2016-12-05 15:08 Axel Beckert: Control: tag -1 + confirmed Hi Vincent, thanks for this bug report. Vincent Lefevre wrote: To satisfy an OR'ed versioned Recommends, the resolver should prefer a package upgrade over a new package installation (which may yield a conflict with the other choice), even though this is not the first choice. [...] But if I type '+' over "main", I get: --\ utils Various system utilities (5) --\ main The main Debian archive (5) iuA stardict-common -165 kB 3.0.1-9.23.0.1-9.3 iB stardict-gtk +31.7 kB 3.0.1-9.2+b2 3.0.1-9.3 iuA stardict-plugin +17.4 kB 3.0.1-9.2+b2 3.0.1-9.3 iuA stardict-plugin- +3072 B 3.0.1-9.2+b2 3.0.1-9.3 iuA stardict-plugin- -68.6 kB 3.0.1-9.2+b2 3.0.1-9.3 Here the package stardict-gtk is marked as broken, while it could be upgraded as shown above. In the details, I get: I can reproduce this on Sid with even less effort: Search for stardict-common, show its dependencies with "d", inside the Recommends, explicitly mark stardict-gtk for installation. Then go to the parent Recommends branch and mark the "Recommends" for installation with "+", and voila: Two alternative and conflicting packages are selected for installation despite one of them was already selected. This is IMO due to unrelated reasons. When pressing "+" in the Recommends subtree (or any other: Conflicts, whatever), all packages within the subtree will try to be installed, and they conflict among themselves -- there's no special intelligence to handle subtrees when they are recommends. It just tries to apply the action to all children. Cheers. -- Manuel A. Fernandez Montecelo
Bug#860339: unblock: mimetic/0.9.8-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
unblock mimetic/0.9.8-5
I've uploaded a new version of mimetic which fixes #859963.
The -5 upload only contains a small patch to mark a variable as
signed in order to avoid the build failures on architectures where
char is unsigned.
0.9.8-5 successfully built on all architectures (except armel, which
is still Needs-Build …).
Full debdiff attached.
Thanks in advance,
gregor
-BEGIN PGP SIGNATURE-
iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAljxEJ5fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgawGRAAps1xhJkdoGvemGAFel+/GT5n0GJtrDMJ5vzkhfoWDYvRCYmxyrMf7A2X
q9e1Y1UTnn0oJq8474xteerivn8WWesJ6vlflc9kjVU4pz6IAYfKdXeMxm2YbRA5
HEY1saCSew5Pv75CX2yOEnT9rctYoOFrR7Qw9T9mQQeHe7+/5gy7cfdMyzLlH1uW
3pn5V8Mo+bhsPLL21+yTTP+nS9bvl+cQ76BZSEzB7Saslrnoq47t63wDOyokPTiD
PiaW6FwQNmqVSKMxX7AR7PPmwqs+PxzpJ/rL0eHmUM0Me9g+vr20EZu2knTxtVss
Ah5b6ylvTUxAQD+BVD+8qFWN//QNoVkb2MBcMAfYu4wfAQmJq1oOOiuxTEczLznD
oEgo4iwnPZ3agAEacXLxdnFoSW1/4M27aGxw3bm6n0Jt8QH4ScRyJjZ1UVmEasGG
qVrqFrTsAPVD0BZcXBDASs9J9jZ10QL0YX8Fxq4l47B4RgdX7WwmEGRwK0Lh5vrI
UjJTBX6hTH8DE0VWOCyI4YB1Q7uUMfXdKTqJDcUtioz3qBEw2OimoaIgYImkmb6M
/Dn3AwkOHQhPSrHsrbgbhwBFuYHFPeV6tp0IPjrSzUK6fuAawFHUeK2eDnGgRQFY
H4Ma+6jiW5bpcH7joOGVszs0Ot7WlHNmpLcTADggm/mj0jEjy/c=
=IIGh
-END PGP SIGNATURE-
diff -Nru mimetic-0.9.8/debian/changelog mimetic-0.9.8/debian/changelog
--- mimetic-0.9.8/debian/changelog 2016-01-15 15:29:38.0 +0100
+++ mimetic-0.9.8/debian/changelog 2017-04-14 17:38:11.0 +0200
@@ -1,3 +1,11 @@
+mimetic (0.9.8-5) unstable; urgency=medium
+
+ * Add patch signed-char.patch to fix build failure on architectures
+where char is unsigned.
+Thanks to Adrian Bunk for the bug report. (Closes: #859963)
+
+ -- gregor herrmann Fri, 14 Apr 2017 17:38:11 +0200
+
mimetic (0.9.8-4) unstable; urgency=medium
* debian/rules: change dh_strip argument from --ddeb-migration to
diff -Nru mimetic-0.9.8/debian/patches/series
mimetic-0.9.8/debian/patches/series
--- mimetic-0.9.8/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ mimetic-0.9.8/debian/patches/series 2017-04-14 17:38:11.0 +0200
@@ -0,0 +1 @@
+signed-char.patch
diff -Nru mimetic-0.9.8/debian/patches/signed-char.patch
mimetic-0.9.8/debian/patches/signed-char.patch
--- mimetic-0.9.8/debian/patches/signed-char.patch 1970-01-01
01:00:00.0 +0100
+++ mimetic-0.9.8/debian/patches/signed-char.patch 2017-04-14
17:38:11.0 +0200
@@ -0,0 +1,31 @@
+Description: fix FTBFS on architectures where char is unsigned
+ Fix error
+ base64.cxx:30:1: error: narrowing conversion of '-1' from 'int' to 'char'
inside { } [-Wnarrowing]
+ by making Base64::sDecTable a signed char.
+Bug-Debian: https://bugs.debian.org/859963
+Forwarded: via email
+Author: gregor herrmann
+Last-Update: 2017-04-10
+
+--- a/mimetic/codec/base64.cxx
b/mimetic/codec/base64.cxx
+@@ -13,7 +13,7 @@
+ "abcdefghijklmnopqrstuvwxyz"
+ "0123456789+/=";
+
+-const char Base64::sDecTable[] = {
++const signed char Base64::sDecTable[] = {
+ -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
+ -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
+ -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
+--- a/mimetic/codec/base64.h
b/mimetic/codec/base64.h
+@@ -20,7 +20,7 @@
+ enum { default_maxlen = 76 };
+ enum { eq_sign = 100 };
+ static const char sEncTable[];
+-static const char sDecTable[];
++static const signed char sDecTable[];
+ static const int sDecTableSz;
+ public:
+ class Encoder; class Decoder;
Bug#860306: [pkg-dhcp-devel] Bug#860306: isc-dhcp-client: Repeatedly received DHCPNAK or no DHCPOFFERS; other computers work OK
control: tag -1 moreinfo On Fri, Apr 14, 2017 at 5:54 AM, Frank Brokken wrote: > As a side note: I'm also puzzled by the workings of the avahi daemon. It's > not clear what it's doing except for faking the above 169.254.10.140 address > and network. Should I deinstall avahi-daemon, since it appears to consume > resources but doesn't seem to do anything useful?... Avahi does complicate things, so yes you should try to reproduce the problem without avahi installed. If you can't reproduce it after that, then this should be reassigned to avahi. Best wishes, Mike
Bug#860306: [pkg-dhcp-devel] Bug#860306: isc-dhcp-client: Repeatedly received DHCPNAK or no DHCPOFFERS; other computers work OK
Also, consider googling for why you might receive a DHCP NAK and see if any of those reasons explain your problem. Best wishes, Mike
Bug#847089: aptitude: resolver mishandles OR'ed versioned Recommends
Control: tags -1 + moreinfo (tagging moreinfo to set it aside from untriaged reports and indicating that it needs further consideration, but not --necessarily-- more info from the submitter) Hi, 2016-12-05 14:26 Vincent Lefevre: Package: aptitude Version: 0.8.3-1+b2 Severity: normal TD;LR To satisfy an OR'ed versioned Recommends, the resolver should prefer a package upgrade over a new package installation (which may yield a conflict with the other choice), even though this is not the first choice. I have: --\ utils Various system utilities (5) --\ main The main Debian archive (5) i A stardict-common3.0.1-9.23.0.1-9.3 i stardict-gtk 3.0.1-9.2+b2 3.0.1-9.3 i A stardict-plugin3.0.1-9.2+b2 3.0.1-9.3 i A stardict-plugin- 3.0.1-9.2+b2 3.0.1-9.3 i A stardict-plugin- 3.0.1-9.2+b2 3.0.1-9.3 If I type '+' over "stardict-gtk", I get: --\ utils Various system utilities (5) --\ main The main Debian archive (5) iuA stardict-common -165 kB 3.0.1-9.23.0.1-9.3 iu stardict-gtk +31.7 kB 3.0.1-9.2+b2 3.0.1-9.3 iuA stardict-plugin +17.4 kB 3.0.1-9.2+b2 3.0.1-9.3 iuA stardict-plugin- +3072 B 3.0.1-9.2+b2 3.0.1-9.3 iuA stardict-plugin- -68.6 kB 3.0.1-9.2+b2 3.0.1-9.3 i.e. the packages will be upgraded as expected (only these 5 packages, nothing else). This is fine. This works fine because stardict-gtk Depends exactly on (stardict-common = 3.0.1-9.3), and the same with Recommends and the plugins, so it's easier for the resolution to arrive to the desired conclusion. But if I type '+' over "main", I get: --\ utils Various system utilities (5) --\ main The main Debian archive (5) iuA stardict-common -165 kB 3.0.1-9.23.0.1-9.3 iB stardict-gtk +31.7 kB 3.0.1-9.2+b2 3.0.1-9.3 iuA stardict-plugin +17.4 kB 3.0.1-9.2+b2 3.0.1-9.3 iuA stardict-plugin- +3072 B 3.0.1-9.2+b2 3.0.1-9.3 iuA stardict-plugin- -68.6 kB 3.0.1-9.2+b2 3.0.1-9.3 Here the package stardict-gtk is marked as broken, while it could be upgraded as shown above. In the details, I get: Some dependencies of stardict-gtk (broken, 3.0.1-9.2+b2) are not satisfied:▒ ▒ * stardict-gtk (upgrade, 3.0.1-9.2+b2 -> 3.0.1-9.3) conflicts with ▒ stardict-gnome ▒ ▒ The following packages conflict with stardict-gtk (broken, 3.0.1-9.2+b2): ▒ ▒ * stardict-gnome (install, 3.0.1-9.3) conflicts with stardict-gtk▒ However stardict-gnome is currently not installed! Note: the same thing occurs if I type '+' over "stardict-common". I suppose that the cause of the problem is due to an OR'ed versioned Recommends in stardict-common; before typing '+': --\ Recommends (1) --- stardict-gnome (>= 3.0.1-9.3) | stardict-gtk (>= 3.0.1-9.3) (UNSATISFIED) It seems that aptitude wants to satisfy the Recommends by taking the first choice stardict-gnome (>= 3.0.1-9.3) instead of upgrading the already installed package to satisfy the second choice. The problem does not occur if I ask to upgrade all the packages with "aptitude upgrade" or "aptitude upgrade --full-resolver", or type 'U' in the UI (but this is not practical when one wants to upgrade some packages only). Note that apt has the same problem with just apt install stardict-common (it wants to install stardict-gnome and remove stardict-gtk), but not with: apt install stardict-common stardict-gtk stardict-plugin \ stardict-plugin-espeak stardict-plugin-festival Ditto for "aptitude install ...". So, I wonder why typing '+' over "main" does not behave the same way. This may be a separate issue. I cannot confirm 100%, but I think that your analysis is correct. The reason why this happens when pressing '+' on "main" subtree is, I think, because aptitude relies on apt's dependency resolution initially (among other reasons, because it's faster), and it invokes its own resolver when it finds conflicts or some sort of broken dependencies or recommends. After that, it depends on the internal machinations of aptitude's resolver, and being guided by the different resolution strategies that can be configured. I've been tweaking the default parameters in the 0.8.x series so it suggests first upgrading, keeping or installing rather than removing dozens of packages; and also trying to minimise the number of actions; but fundamentally it is an open problem without clear-cut solutions, so it doesn't always work. (In the command line the aptitude resolver is used mor
Bug#859050: tried changing order
I changed the order in the Build-dep so that it was: libssl1.0-dev|libssl-dev instead of: libssl-dev|libssl1.0-dev It built fine, and used libssl1.0-dev instead. I think that this would solve lighttpd being in error state for this transition: https://release.debian.org/transitions/html/ssl1.0.html I'm happy to upload this, if you want. micah signature.asc Description: PGP signature
Bug#859927: Confirmed
I've confirmed this bug, as reported: I installed lighttpd: The following NEW packages will be installed: lighttpd spawn-fcgi 0 upgraded, 2 newly installed, 0 to remove and 326 not upgraded. Need to get 299 kB of archives. After this operation, 1,019 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://httpredir.debian.org/debian sid/main amd64 lighttpd amd64 1.4.45-1 [284 kB] Get:2 http://httpredir.debian.org/debian sid/main amd64 spawn-fcgi amd64 1.6.4-1+b1 [14.9 kB] Fetched 299 kB in 1s (194 kB/s) Selecting previously unselected package lighttpd. (Reading database ... 206019 files and directories currently installed.) Preparing to unpack .../lighttpd_1.4.45-1_amd64.deb ... Unpacking lighttpd (1.4.45-1) ... Selecting previously unselected package spawn-fcgi. Preparing to unpack .../spawn-fcgi_1.6.4-1+b1_amd64.deb ... Unpacking spawn-fcgi (1.6.4-1+b1) ... Setting up spawn-fcgi (1.6.4-1+b1) ... Setting up lighttpd (1.4.45-1) ... Created symlink /etc/systemd/system/multi-user.target.wants/lighttpd.service → /lib/systemd/system/lighttpd.service. Processing triggers for systemd (232-20) ... Processing triggers for man-db (2.7.6.1-2) ... and confirmed it is running: root@reeds:/home/micah/debian/lighttpd-1.4.45# ps auxw |grep lighttpd www-data 2129 0.0 0.0 58924 5452 ?Ss 15:03 0:00 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf root 4119 0.0 0.0 12788 956 pts/3S+ 15:03 0:00 grep lighttpd I enabled the module as described in the bug: root@reeds:/home/micah/debian/lighttpd-1.4.45# lighttpd-enable-mod fastcgi-php Met dependency: fastcgi Enabling fastcgi-php: ok Enabling fastcgi: ok Run "service lighttpd force-reload" to enable changes root@reeds:/home/micah/debian/lighttpd-1.4.45# service lighttpd force-reload and now lighttpd is not running: root@reeds:/home/micah/debian/lighttpd-1.4.45# ps auxw |grep lighttpd root 4223 0.0 0.0 12788 980 pts/3S+ 15:04 0:00 grep lighttpd I will attempt to apply the patch and see if it works. micah
Bug#857444: [debian-mysql] Bug#857444: Bug#857444: mysql-server-5.5: upgrade from jessie to stretch leaves mysql server uninstalled
Hi there, I've traced inter-package links (depends, conflicts et al) and I think I found the reason why the server gets removed. stretch still has a mysql-common package that has a "Replaces:" for mysql-server-5.5. during a dist-upgrade mysql-common will get upgraded to the stretch version, which in turn will remove the server package. to test this hypothesis, I ran "apt-mark hold mysql-common" right before doing a dist-upgrade from jessie to stretch and both mysql-server and mysql-server-5.5 then don't get removed by apt/dpkg. signature.asc Description: OpenPGP digital signature
Bug#859655: golang-go.crypto: CVE-2017-3204
Control: user -1 debian-rele...@lists.debian.org Control: usertags -1 bsp-2017-04-ca-montreal Control: tags -1 +patch I looked into this during the Montreal BSP, and it's unclear what we should do here, considering there has been multiple new uploads since the stretch freeze. The patch is pretty long: https://github.com/golang/crypto/commit/e4e2799dd7aab89f583e1d898300d96367750991 ... and there's no way to just backport it into stretch at this point (IIRC). So I'm wondering if the next step here would not just be to ask for an exception to unblock this for stretch, or just tell the release team to just ignore this and drop the package from stretch. Let me know, A. -- Celui qui ne connaît pas l'histoire est condamné à la revivre. - Karl Marx
Bug#860341: libmtp-common: libmtp does not work w/ recent Android phones
Package: libmtp-common Version: 1.1.12-1 Severity: grave Justification: renders package unusable Hi, libmtp should be upgraded to version 1.1.13 as it renders many recent smartphone unable to mount. Issue is reported there : https://sourceforge.net/p/libmtp/bugs/1625/ Many Android 6+ smartphones are actually affected, and users cannot mount them at all. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#860340: fancontrol: please add configuration file
Package: fancontrol Version: 1:3.4.0-4 Severity: wishlist Dear Maintainer, it would be nice, if you could add a default configuration file (/etc/fancontrol) to the package. This is useful, when used in livefile systems. In my case, I am regularly building a kali livefile dvd for my EEEPC, who needs fancontrol and eeepc-acpi-scripts (so fancontrol or eeepc-acpi-scripts should have the related dependency). After install, it is necessary to use pwmconfig, to create /etc/fancontrol. Without it, the fan will not run, and the cpu can be overheated. So, the solution is the following: 1. Build the livefile with the command "acpi_osi=Linux" at grub (my part) 2. Take care of installing fancontrol and eeepc-acpi-scripts (my part) 3. Create /etc/fancontrol at installation (your part) If you like, you can use mine for example, it is running fine on EEEPC. Here it is: - # Configuration file generated by pwmconfig, changes will be lost INTERVAL=5 DEVPATH=hwmon0= hwmon2=devices/platform/eeepc DEVNAME=hwmon0=acpitz hwmon2=eeepc FCTEMPS= hwmon2/pwm1=hwmon0/temp1_input FCFANS= hwmon2/pwm1= MINTEMP= hwmon2/pwm1=55 MAXTEMP= hwmon2/pwm1=65 MINSTART= hwmon2/pwm1=50 MINSTOP= hwmon2/pwm1=35 MINPWM= hwmon2/pwm1=0 MAXPWM= hwmon2/pwm1=255 --- Thank you for your help! Best regards Hans -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fancontrol depends on: ii init-system-helpers 1.47 ii lsb-base 9.20161125 fancontrol recommends no packages. fancontrol suggests no packages. -- no debconf information
Bug#860271: [cacti/debian-sid] Add enable_faster_polling_than_cron.patch
tag 860271 pending thanks Date: Thu Apr 13 21:43:46 2017 +0200 Author: Paul Gevers Commit ID: 934091e6738b1f2939b63119141776f683afa156 Commit URL: http://git.debian.org/?p=pkg-cacti/cacti.git;a=commitdiff;h=934091e6738b1f2939b63119141776f683afa156 Patch URL: http://git.debian.org/?p=pkg-cacti/cacti.git;a=commitdiff_plain;h=934091e6738b1f2939b63119141776f683afa156 Add enable_faster_polling_than_cron.patch Closes: #860271
Bug#756400: pytaglib: Please include a python2 package
Source: pytaglib Followup-For: Bug #756400 Dear Maintainer, Upstream is capable of both python2 and python3. I would really like to not have to make my code care, or install from pip. Thanks. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (600, 'unstable-debug'), (600, 'testing-debug'), (600, 'unstable'), (600, 'testing'), (200, 'experimental-debug'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#860337: Acknowledgement (php7.0: No transition path from php5 to php7.0 when upgrading to stretch)
Control: user debian-rele...@lists.debian.org Control: usertags -1 bsp-2017-04-ca-montreal signature.asc Description: PGP signature
Bug#860342: python3-taglib: Newer upstream releases available since Jan 21, 2014
Package: python3-taglib Severity: grave Justification: renders package unusable Dear Maintainer, Please update to a newer version of the package. This looks unmaintained and I would have filed an RM request save that there are packages that depend on this in the archive. Thanks. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (600, 'unstable-debug'), (600, 'testing-debug'), (600, 'unstable'), (600, 'testing'), (200, 'experimental-debug'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#860337: php7.0: No transition path from php5 to php7.0 when upgrading to stretch
Hello, for a little bit of additional information, the mysql to mariadb transition decided to use a meta-package called default-mysql-server to provide a path for the transition during the upgrade. Since php5 and php7 have a good number of differences, it might be desirable to have some kind of similar "opt-in" upgrade path so that one could install some package in jessie before performing the upgrade to stretch and have php packages get automatically upgraded to 7.0 one other detail that would be nice would be to add a note about this upgrade path in the release notes: https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html signature.asc Description: OpenPGP digital signature
