Bug#921914: minissdpd: Lots of "Address already in use" syslog messages (again)

[Matijs van Zuijlen]

Package: minissdpd
Version: 1.5.20180223-5
Severity: normal

Dear maintainer,

With the most recent upgrade of minissdpd, the 'Address already in use'
messages from #903783 seem to have returned. They now appear every five
minutes or so:

Feb  9 17:02:58 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:02:58 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:02:58 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:03:01 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:03:01 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:03:01 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:03:09 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:03:09 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:03:09 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:11:18 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:11:18 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Feb  9 17:11:18 bean minissdpd[2321]: setsockopt(udp, 
IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use

I do not recall consciously having set the MiniSSDPd_INTERFACE_ADDRESS
option, which was modified on 2019-02-08, it seems when the latest
release was installed. Maybe this has something to do with it?

Regards,
Matijs

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

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

Versions of packages minissdpd depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  init-system-helpers1.56+nmu1
ii  libc6  2.28-6
ii  libnfnetlink0  1.0.1-3+b1
ii  lsb-base   10.2018112800

minissdpd recommends no packages.

minissdpd suggests no packages.

-- Configuration Files:
/etc/default/minissdpd changed:
MiniSSDPd_INTERFACE_ADDRESS="br-4022230c9d1b docker0 wlan0"
MiniSSDPd_OTHER_OPTIONS="-6"


-- debconf information:
* minissdpd/listen: br-4022230c9d1b docker0 wlan0
* minissdpd/why_I_am_here:
* minissdpd/start_daemon: true
  minissdpd/ip6: true

Bug#921886: python-cartopy-data: data files installed in one-level-too-deep subdirectories

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Matt,

On 2/9/19 10:24 PM, Matt Marjanovic wrote:
> I suspect this is simply a mistake in the debian/python-cartopy-data.install
> file.

Indeed it is, and now fixed in git. A new upload to unstable will follow
shortly.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#921913: locales: character map file `C' not found: No such file or directory

[Helge Kreutzmann]

Package: locales
Version: 2.28-6
Severity: minor

In todays upgrade in my sid chroot I see the following messages
locales (2.28-6) wird eingerichtet ...
Generating locales (this might take a while)...
  de_DE.ISO-8859-1... done
  de_DE.UTF-8... done
  en_GB.UTF-8... done
  en_US.UTF-8... done
  C.C...[error] character map file `C' not found: No such file or directory
 done
Generation complete.

I don't know if this is new or older or if this poses a problem. I can provide 
you with mor details if necessary.

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#921887: python3-cartopy: config['repo_data_dir'] is incorrect (e.g., breaking stock_image())

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Matt,

On 2/9/19 10:36 PM, Matt Marjanovic wrote:
> The 'repo_data_dir' element in the cartopy.config dictionary still has its
> upstream default value of "/usr/lib/python3/dist-packages/cartopy/data",
> however the "python-cartopy-data" package installs these files in a different
> location, "/usr/share/cartopy/data".

The symlinks to /usr/share/cartopy/data where missing from the
python{,3}-cartopy packages to due a typo in the filenames (.link
instead of .links). With the symlinks in place the repo_data_dir value
doesn't need to be changed.

The fix is in git and a new upload to unstable will follow shortly.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#736859: dput: Please set the default transport to use ssh-upload

[Ben Finney]

Control: tags -1 + moreinfo

On 27-Nov-2018, Daniel Kahn Gillmor wrote:

> We surely have ssh keys for most DMs these days, via gitlab,
> monkeysphere, or some other mechanism.  Maybe we could we grant those
> DMs access?

If I understand this suggestion, it seems out of scope for this bug
report. Would you re-post that suggestion for discussion where it
might result in action?

> > 2. It does not support the DELAYED queue.
> 
> If it doesn't support the DELAYED queue, that should be fixed. is
> there a reason that DELAYED isn't available via ssh-upload?

I don't know; Paride, is this problem already reported in some bug
report? Which one?

-- 
 \ “I must say that I find television very educational. The minute |
  `\   somebody turns it on, I go to the library and read a book.” |
_o__)—Groucho Marx |
Ben Finney 

signature.asc
Description: PGP signature

Bug#921874: gf-complete: fix runtime cpu detection and compilation on i386/armhf

[Yuriy M. Kaminskiy]

On 09.02.2019 20:48, Yuriy M. Kaminskiy wrote:
> 2) it can expose bugs on some cpus, that are not caught by testsuite
> (e.g. [previous version of] my _mm_extract_epi64 replacement was very
> buggy - but it was not detected by debian's qemu test [as it only runs
> only single unit test for gf64, but only gf128 was affected]);

Just in case, I (ab)used valgrind hook to run complete testsuite for all
combination of flags for i386 and amd64, incremental debdiff attached (on the 
top of above).

Known problems: takes a bit too long to run (2.5 hours for amd64, and even more 
for i386).
diff -Nru gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog
--- gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog   2019-02-09 
13:29:51.0 +0300
+++ gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog   2019-02-09 
13:29:51.0 +0300
@@ -1,9 +1,10 @@
-gf-complete (1.0.2+2017.04.10.git.ea75cdf-3~bpo9+1~local1) stretch-backports; 
urgency=medium
+gf-complete (1.0.2+2017.04.10.git.ea75cdf-3~bpo9+1~local2) stretch-backports; 
urgency=medium
 
   * Rebuild for stretch-backports.
   * Fix i386 simd compilation.
   * Fix runtime cpudetection.
   * Fix neon for armhf.
+  * Run complete test suite under qemu.
 
  -- Yuriy M. Kaminskiy   Sat, 09 Feb 2019 13:29:51 
+0300
 
diff -Nru gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/rules 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/rules
--- gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/rules   2019-02-09 
13:29:51.0 +0300
+++ gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/rules   2019-02-09 
13:29:51.0 +0300
@@ -6,44 +6,43 @@
 
 GIT_TAG ?= $(shell echo '$(DEB_VERSION_UPSTREAM)' | sed -e 's/~/_/')
 
-%:
-   dh $@  --with autoreconf
-
 ifeq ($(DEB_HOST_ARCH), amd64)
-ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-override_dh_auto_test:
-   dh_auto_test
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,-sse3,-ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,+sse3,-ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,+sse3,+ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,+sse3,+ssse3,+sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,+sse3,+ssse3,+sse4.1,+sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,+sse3,+ssse3,+sse4.1,+sse4.2,+pclmulqdq ./test/gf_unit 64 A -1 -
-endif
+QEMU_ARCH=x86_64
+# omitted: sse2 (always on amd64), sse3 (not used)
+QEMU_CPUS=qemu64,-ssse3,-sse4.1,-sse4.2,-pclmulqdq
 endif
 
 ifeq ($(DEB_HOST_ARCH), i386)
+QEMU_ARCH=i386
+# omitted: sse3 (not used)
+QEMU_CPUS=qemu32,-sse2,-ssse3,-sse4.1,-sse4.2,-pclmulqdq
+endif
+
+ifeq ($(DEB_HOST_ARCH), armhf)
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-override_dh_auto_test:
-   dh_auto_test
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,-ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,-ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,+ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,+ssse3,+sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2,+pclmulqdq ./test/gf_unit 64 A -1 -
+ifeq (neon,$(shell grep -o -w -h -m 1 neon /proc/cpuinfo 2>/dev/null))
+$(warning NEON detected on the build host, arm-without-neon configuration will 
not be tested)
+else
+QEMU_ARCH=arm
+QEMU_CPUS=cortex-a8
+endif
 endif
 endif
 
-ifeq ($(DEB_HOST_ARCH), armhf)
+%:
+   dh $@  --with autoreconf
+
+ifneq (,$(QEMU_ARCH))
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 override_dh_auto_test:
dh_auto_test
-# I have not found any way to disable NEON in emulated cpu
-#  ./libtool --mode=execute qemu-arm-static -cpu cortex-a8,-neon 
./test/gf_unit 64 A -1 -
-   set -ex; if grep -sw neon /proc/cpuinfo; then echo "WARNING: NEON 
detected on build host, arm-without-neon configuration is not tested"; fi
-   ./libtool --mode=execute qemu-arm-static -cpu cortex-a8 ./test/gf_unit 
64 A -1 -
+   set -ex; C=$(QEMU_ARCH); c=$(QEMU_CPUS); p=X; \
+   while test "$$p" != "$$c"; do \
+   export 

Bug#736859: dput: Please set the default transport to use ssh-upload

[Ben Finney]

Control: severity -1 wishlist
Control: outlook -1 0
Control: tags -1 + moreinfo

The Debian infrastructure support for SSH upload may not be good
enough to be the default transport for this tool.

On 27-Nov-2018, Paride Legovini wrote:
> While ssh-upload is clearly better than FTP and I would like to see
> it as the default upload method too, it still has two important
> shortcomings:
> 
> 1. Only Debian Developers can use it, as DM do not have an account;
> 
> 2. It does not support the DELAYED queue.

-- 
 \ “I was trying to daydream, but my mind kept wandering.” —Steven |
  `\Wright |
_o__)  |
Ben Finney 

signature.asc
Description: PGP signature

Bug#920982: deal.ii: FTFBFS with doxygen 1.8.15 draft package

[Graham Inggs]

Control: severity -1 important

Hi Paolo

On Thu, 31 Jan 2019 at 11:09, Paolo Greppi  wrote:
> I tested your package against a draft package for doxygen 1.8.15:
> https://bugs.debian.org/919413
> https://salsa.debian.org/paolog-guest/doxygen/-/jobs/107680/artifacts/browse/debian/output/
>
> and it FTBFS with this error:

I'm lowering the severity of this bug for now.  Please raise it again
once doxygen 1.8.15 has been uploaded to unstable.

Regards
Graham

Bug#863899: amule: [amule] Closing last search tab crashes amule

[Ralf-Peter Rohbeck]

I can reproduce this behavior in buster with amule-utils-gui 
1:2.3.2-4+b1. Same on Armbian, fully updated.


(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Temporary breakpoint 1 (main) pending.
Starting program: /usr/bin/amulegui
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 5447]
 2019-02-09 21:35:40 (remote-GUI): Initialising aMuleGUI 2.3.2 compiled 
with wxGTK2 v3.0.4 and Boost 1.67
 2019-02-09 21:35:40 (remote-GUI): Checking if there is an instance 
already running...

 2019-02-09 21:35:40 (remote-GUI): No other instances are running.
[New Thread 0x724e5700 (LWP 5449)]
[New Thread 0x71ce4700 (LWP 5450)]
[New Thread 0x714e3700 (LWP 5451)]
[New Thread 0x70ce2700 (LWP 5452)]
[Detaching after fork from child process 5453]
[Detaching after fork from child process 5455]
[Detaching after fork from child process 5457]
[Detaching after fork from child process 5459]
[Detaching after fork from child process 5461]
[Detaching after fork from child process 5470]
[Detaching after fork from child process 5478]
[Detaching after fork from child process 5486]
 2019-02-09 21:35:42 (remote-GUI): Asio thread 1 started
 2019-02-09 21:35:42 (remote-GUI): Asio thread 2 started
 2019-02-09 21:35:42 (remote-GUI): Asio thread 3 started
 2019-02-09 21:35:42 (remote-GUI): Asio thread 4 started
 2019-02-09 21:35:44 (remote-GUI): Connecting...
 2019-02-09 21:35:44 (remote-GUI): Going to event loop...
 2019-02-09 21:35:44 (remote-GUI): Remote GUI EC event handler
[Detaching after fork from child process 5502]

Thread 1 "amulegui" received signal SIGSEGV, Segmentation fault.
0x76061db4 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0


(gdb) thread apply all bt
Thread 5 (Thread 0x70ce2700 (LWP 5452)):
#0  0x7645db2f in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x557e1887 in ?? ()
#2  0x557e5bc3 in ?? ()
#3  0x557ec17c in ?? ()
#4  0x76c3ad72 in wxThread::CallEntry() () from 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#5  0x76c44374 in ?? () from 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#6  0x77d81fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#7  0x7645d80f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 4 (Thread 0x714e3700 (LWP 5451)):
#0  0x77d87fbc in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#1  0x557e5d0c in ?? ()
#2  0x557ec17c in ?? ()
#3  0x76c3ad72 in wxThread::CallEntry() () from 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#4  0x76c44374 in ?? () from 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#5  0x77d81fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#6  0x7645d80f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 3 (Thread 0x71ce4700 (LWP 5450)):
#0  0x77d87fbc in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#1  0x557e5d0c in ?? ()
#2  0x557ec17c in ?? ()
#3  0x76c3ad72 in wxThread::CallEntry() () from 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#4  0x76c44374 in ?? () from 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#5  0x77d81fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#6  0x7645d80f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x724e5700 (LWP 5449)):
#0  0x77d87fbc in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#1  0x557e5d0c in ?? ()
#2  0x557ec17c in ?? ()
#3  0x76c3ad72 in wxThread::CallEntry() () from 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#4  0x76c44374 in ?? () from 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#5  0x77d81fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#6  0x7645d80f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x72dd7a40 (LWP 5439)):
#0  0x76061db4 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#1  0x760411eb in ?? () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#2  0x75d9ec7d in g_closure_invoke () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3  0x75db1b64 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x75dba983 in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x75dbb90f in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x76157cac in ?? () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#7  0x7603f48c in gtk_propagate_event () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#8  0x7603f87b in gtk_main_do_event () from 

Bug#787560: calibre: Calibre can't communicate with file managers

[Luis Mochan]

I'm currently running debian/buster, not stretch, with calibre 3.35.0+dfsg-1. I
believe the issue has been solved. The files when I found the problem
were local files and I was using  xpdf. Currently I'm using zathura as
a default pdf viewer. In my system epub and mobi files open in adobe digital
editions and in kindle when I click them in thunnar, as I installed
them under wine, not in calibre. When I open them in calibre they open
in calibre. When I drag a pdf into the middle panel it is added as a
new book and from then on I can open it in calibre by clicking it.

Thanks and regards,
Luis


On Sat, Feb 09, 2019 at 06:48:03PM -0700, Nicholas D Steeves wrote:
> Control: tag -1 + moreinfo
> 
> Hi Luis,
> 
> Is this issue also present in stretch's released
> calibre_2.75.1+dfsg-1, and if so, is it also present in the Calibre
> version in stretch-backports?
> 
>   https://backports.debian.org/
> 
> Reply follows inline:
> 
> On Tue, Jun 02, 2015 at 12:45:12PM -0500, Luis Mochan wrote:
> > Package: calibre
> > Version: 2.24.0+dfsg-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > After upgrading to Debian/stretch I found that Calibre was unable to open 
> > pdf
> > books, with errors such as
> >   Unable to find the requested file. Please check the spelling and try 
> > again.
> >   Unhandled error message: Error when getting information for file '...': No
> > such file or directory
> > (when my prefered file manager is Nautilus) and a nautilus window is opened.
> > Later I found the same message when trying to open a Path.
> >   Changing my prefered file manager to thunar through exo-preferred-
> > applications the message changes to
> >   Failed to open "..."
> >   Error when getting information for file '..': No such file or directory.
> > I noticed that the message seems to come from the file manager, not from
> > Calibre.
> > I also noticed that the file name passed to the file manager has spaces
> > replaced by '%20'.
> 
> Are the files local or is this a remote share (SSH/SFTP/SAMBA/etc)?
> 
> > The files do exist and I can open them from both file managers by clicking 
> > on
> > them.
> 
> Presumably the files open successfully in the default PDF viewer?
> Which PDF viewer?
> 
> > Furthermore, I can open the same book in other formats from the same
> > directory using Calibre. I could also open the pdf's after installing the 
> > 'Open
> > With' plugin and configuring it for opening pdf files. So I guess the 
> > problem
> > is related to the protocol used to communicate with the file managers.
> 
> So this issue is specific to PDFs?  Do ebooks in epub, mobi, etc. open
> successfully in Calibre (or calibre-viewer) when clicking on them in
> Nautilus or Thunar?
> 
> What happens when you drag and drop a PDF into the middle library pane
> of the Calibre window?
> 
> 
> Thanks for the bug report,
> Nicholas



-- 

  o
W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
Apdo. Postal 48-3, 62251 |   (*)/\/  \
Cuernavaca, Morelos, México  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

Bug#916696: initramfs-tools: search for nonexistent resume device

[Trek]

On Wed, 06 Feb 2019 21:21:57 +
Ben Hutchings  wrote:

> The RESUME variable doesn't have to be set in any particular file.
> Please check with:
> 
> grep -rw RESUME /etc/initramfs-tools/initramfs.conf \
> /etc/initramfs-tools/conf.d \
> /usr/share/initramfs-tools/conf.d/

it's empty


> If it's definitely not set, then please:
> 
> 1. Upgrade to initramfs-tools version 0.133 (I just uploaded this so
>you will have to wait a few hours for it to be available)
> 2. Run "update-initramfs -u -v >initramfs.log 2>&1"
> 3. Look in initramfs.log for "Calling hook resume" and send the
>messages after that

thanks for your help, now I've managed to debug and fix the resume hook:
when all the swaps are ephemeral, it finishes the for-loop, but the
last if-construct doesn't check the ephemeral variable

I include a patch, tested with and without an ephemeral swap:
- the second block (-79,9 +83,10) is the actual fix
- the first one (-63,9 +63,13) is only to be safer, as it
  checks /dev/random too and it stops searching /etc/crypttab when the
  device is found

ciao!--- a/usr/share/initramfs-tools/hooks/resume	2019-02-06 05:40:30.0 +0100
+++ b/usr/share/initramfs-tools/hooks/resume	2019-02-10 05:50:51.270496152 +0100
@@ -63,9 +63,13 @@
 			# shellcheck disable=SC2034
 			while read -r cryptdev srcdev keyfile junk; do
 report_verbose "Found cryptdev=$cryptdev keyfile=$keyfile"
-if [ "$cryptdev" = "$dm_name" ] && [ "$keyfile" = /dev/urandom ]; then
-	report_verbose "Rejecting $resume_auto since it has no permanent key"
-	ephemeral=true
+if [ "$cryptdev" = "$dm_name" ]; then
+	if [ "$keyfile" = /dev/urandom ] || [ "$keyfile" = /dev/random ]; then
+		report_verbose "Rejecting $resume_auto since it has no permanent key"
+		ephemeral=true
+	fi
+
+	break
 fi
 			done < /etc/crypttab
 		fi
@@ -79,9 +83,10 @@
 		esac
 
 		$ephemeral || break
+		resume_auto=
 	done
 
-	if [ -n "$resume_auto" ] && ! $ephemeral; then
+	if [ -n "$resume_auto" ]; then
 		if [ -n "$dm_name" ]; then
 			resume_auto_canon="/dev/mapper/$dm_name"
 		elif UUID=$(blkid -s UUID -o value "$resume_auto"); then

Bug#921820: fwupd: provide a network service file

[Ritesh Raj Sarraf]

Control: severity -1 wishlist

On Sat, 2019-02-09 at 13:14 +, mario.limoncie...@dell.com wrote:
> Per design this functionality exists in the frontend that runs as
> reduced privilege user. For example gnome-software which runs in a
> users session and regularly checks for apt metadata also will
> automatically check for firmware updates too.

apt has the option to set timers that can be invoked periodically to
update the database.

rrs@priyasi:~$ systemctl status apt-daily.timer apt-daily-upgrade.timer
● apt-daily.timer - Daily apt download activities
   Loaded: loaded (/lib/systemd/system/apt-daily.timer; disabled; vendor 
preset: enabled)
   Active: inactive (dead)
  Trigger: n/a

● apt-daily-upgrade.timer - Daily apt upgrade and clean activities
   Loaded: loaded (/lib/systemd/system/apt-daily-upgrade.timer; disabled; 
vendor preset: enabled)
   Active: inactive (dead)
  Trigger: n/a
10:59 ♒♒♒☹ => 3  


A similar timer could be introduced for fwupd. THis bug report should
instead be a wishlist, so I'm changing the severity accordingly.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#921912: libwxbase3.0-0v5-dbg: No buster libwxbase3.0-0v5-dbg

[Ralf-Peter]

Package: libwxbase3.0-0v5-dbg
Version: 3.0.2+dfsg-4
Severity: normal

Dear maintainer,
I tried to debug a Wxwindows application but when I installed the debug 
symbols, libwxbase3.0-0v5 was downgraded to the stretch version:

root@tp:~# apt-cache policy libwxbase3.0-0v5 libwxbase3.0-0v5-dbg
libwxbase3.0-0v5:
  Installed: 3.0.2+dfsg-4
  Candidate: 3.0.4+dfsg-8
  Version table:
 3.0.4+dfsg-8 900
900 http://httpredir.debian.org/debian buster/main amd64 Packages
900 http://httpredir.debian.org/debian testing/main amd64 Packages
 47 http://httpredir.debian.org/debian sid/main amd64 Packages
 47 http://httpredir.debian.org/debian unstable/main amd64 Packages
 *** 3.0.2+dfsg-4 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
libwxbase3.0-0v5-dbg:
  Installed: 3.0.2+dfsg-4
  Candidate: 3.0.2+dfsg-4
  Version table:
 *** 3.0.2+dfsg-4 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable'), (500, 'oldstable'), (47, 
'unstable'), (5, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libwxbase3.0-0v5-dbg depends on:
ii  libwxbase3.0-0v5  3.0.2+dfsg-4

libwxbase3.0-0v5-dbg recommends no packages.

libwxbase3.0-0v5-dbg suggests no packages.

-- no debconf information

Bug#921911: stretch-pu: package yosys/0.7-2+deb9u1

[Andreas Beckmann]

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

yosys-smtbmc cannot find its private modules. #904752
This is a cherry-pick of the change in sid that updated the searchpath.


Andreas
diff -Nru yosys-0.7/debian/changelog yosys-0.7/debian/changelog
--- yosys-0.7/debian/changelog  2016-11-06 15:40:47.0 +0100
+++ yosys-0.7/debian/changelog  2019-02-10 03:33:31.0 +0100
@@ -1,3 +1,18 @@
+yosys (0.7-2+deb9u1) stretch; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+  * Backport the patch fixing the search path from 0.7-5.
+
+  [ Ruben Undheim ]
+  * debian/patches/0010-Fix-adding-of-sys.path-in-yosys-smtbmc.patch
+- Fix "ModuleNotFoundError: No module named 'smtio'" (Closes: #904752)
+  * debian/tests/smtbc:
+- Added CI test to check that 'yosys-smtbmc' can be started with no
+  import errors
+
+ -- Andreas Beckmann   Sun, 10 Feb 2019 03:33:31 +0100
+
 yosys (0.7-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru 
yosys-0.7/debian/patches/0010-Fix-adding-of-sys.path-in-yosys-smtbmc.patch 
yosys-0.7/debian/patches/0010-Fix-adding-of-sys.path-in-yosys-smtbmc.patch
--- yosys-0.7/debian/patches/0010-Fix-adding-of-sys.path-in-yosys-smtbmc.patch  
1970-01-01 01:00:00.0 +0100
+++ yosys-0.7/debian/patches/0010-Fix-adding-of-sys.path-in-yosys-smtbmc.patch  
2019-02-10 03:07:38.0 +0100
@@ -0,0 +1,21 @@
+From: Ruben Undheim 
+Date: Fri, 27 Jul 2018 18:46:13 +
+Subject: Fix adding of sys.path in yosys-smtbmc
+
+---
+ backends/smt2/Makefile.inc | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/backends/smt2/Makefile.inc b/backends/smt2/Makefile.inc
+index eacda27..f98e610 100644
+--- a/backends/smt2/Makefile.inc
 b/backends/smt2/Makefile.inc
+@@ -6,7 +6,7 @@ ifneq ($(CONFIG),emcc)
+ TARGETS += yosys-smtbmc
+ 
+ yosys-smtbmc: backends/smt2/smtbmc.py
+-  $(P) sed 's|##yosys-sys-path##|sys.path += [os.path.dirname(__file__) + 
p for p in ["/share/python3", "/../share/yosys/python3"]]|;' < $< > $@.new
++  $(P) sed 's|##yosys-sys-path##|sys.path += ["/usr/share/yosys"]|;' < $< 
> $@.new
+   $(Q) chmod +x $@.new
+   $(Q) mv $@.new $@
+ 
diff -Nru yosys-0.7/debian/patches/series yosys-0.7/debian/patches/series
--- yosys-0.7/debian/patches/series 2016-11-06 11:19:59.0 +0100
+++ yosys-0.7/debian/patches/series 2019-02-10 03:08:33.0 +0100
@@ -4,3 +4,4 @@
 switch-to-free-font.patch
 manual-build.patch
 kfreebsd-support.patch
+0010-Fix-adding-of-sys.path-in-yosys-smtbmc.patch
diff -Nru yosys-0.7/debian/tests/control yosys-0.7/debian/tests/control
--- yosys-0.7/debian/tests/control  2016-11-06 10:12:54.0 +0100
+++ yosys-0.7/debian/tests/control  2019-02-10 03:07:38.0 +0100
@@ -1,2 +1,2 @@
-Tests: ice
+Tests: ice, smtbc
 Depends: @
diff -Nru yosys-0.7/debian/tests/smtbc yosys-0.7/debian/tests/smtbc
--- yosys-0.7/debian/tests/smtbc1970-01-01 01:00:00.0 +0100
+++ yosys-0.7/debian/tests/smtbc2019-02-10 03:07:38.0 +0100
@@ -0,0 +1,12 @@
+#!/bin/bash
+
+# Just verify that there are no Python import errors when starting yosys-smtbmc
+
+yosys-smtbmc 2>&1 | grep --quiet  ImportError
+RET=$?
+
+if [ "$RET" = "0" ]; then
+  exit 1
+else
+  exit 0
+fi

Bug#873795: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#677110: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#704552: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#865879: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#673216: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#826971: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#646128: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#855499: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#610328: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#689676: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#731842: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#657730: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#845380: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#719984: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#727147: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#747316: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#611242: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#589126: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#602053: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi,

This bug refers to an old (or ancient!) version of Calibre.  If you're
running Debian 10 (Stretch), please update this bug by confirming if
it exists in calibre-2.75.1+dfsg-1 (version in Debian 9/Stretch).  If
that version is bad, please enable stretch-backports and confirm
whether 3.31.0+dfsg-1~bpo9+1 is affected.

Alternatively, if you're running buster/sid, please confirm if 
3.39.1+dfsg-1 is affected.


Thanks!
Nicholas

Bug#867949: ebook-viewer crashes with "Illegal instruction"

[Nicholas D Steeves]

Control: tags + moreinfo

Hi Hartmut,

On Mon, Jul 10, 2017 at 06:18:31PM +0200, Hartmut Buhrmester wrote:
> Package: calibre
> Version: 2.75.1+dfsg-1
> 
> Other relevant packages:
> 
> calibre-bin2.75.1+dfsg-1
> python2.7  2.7.13-2
> libqt5webkit5  5.7.1+dfsg-1
> python-pyqt5.qtwebkit  5.7+dfsg-5
> 
> For debugging I also installed (for i386):
> 
> calibre-bin-dbgsym 2.75.1+dfsg-1
> python2.7-dbg  2.7.13-2
> libqt5webkit5-dbg  5.7.1+dfsg-1
> python-pyqt5.qtwebkit-dbg  5.7+dfsg-5
> 
> Kernel: Linux debian 4.9.0-3-686-pae #1 SMP Debian 4.9.30-2+deb9u2
> (2017-06-26) i686 GNU/Linux
> 
> 
> The ebook-viewer from the package calibre crashes with an "illegal
> instruction", while reading ebooks of type *.epub. This happens, for
> example, with the ebooks from Project Gutenberg at
> https://www.gutenberg.org/wiki/Main_Page .
> 
> The crash does not happen immediately; the application starts normally and I
> can open an ebook of type *.epub. I can also browse through the pages. But
> when I start reading and stay at two subsequent page for some time, then the
> ebook-viewer may suddenly quit with an illegal instruction.
> 
> It seems, that the ebook-viewer regularly recalculates the current reading
> position and safes it to a file. The next time it will reopen the file at
> the same position. But sometimes it seems to crash at this point.
> 
> The ebook-viewer may also crash, when the application window is closed. This
> crash may get unnoticed during normal usage. But in the debugger, I still
> get the message: "Program terminated with signal SIGILL, Illegal
> instruction."
> 
> I suspect, that the cause is again the recalculation of the reading
> position, to save it to a file.
>

Would you please confirm if this issue also affects calibre from
stretch-backports (3.31.0+dfsg-1~bpo9+1) or alternatively from sid
(3.39.1+dfsg-1).

> 
> When the ebook-viewer is started in a terminal, I get the error "Illegal
> instruction".
> 
> hb1@debian:~$ ebook-viewer
> Illegal instruction
> hb1@debian:~$
> 
> 
> The logfiles /var/log/messages, /var/log/syslog und /var/log/kern.log
> contain these messages:
> 
> > Jun 29 22:52:30 debian kernel: [ 1529.008213] traps: ebook-viewer[1350] 
> > trap invalid opcode ip:a84cae95 sp:bfa65160 error:0
> > Jun 29 23:08:31 debian kernel: [ 2490.015276] traps: ebook-viewer[1407] 
> > trap invalid opcode ip:abf0e9a9 sp:bfaa6890 error:0
> > Jun 29 23:09:58 debian kernel: [ 2577.010756] traps: ebook-viewer[1440] 
> > trap invalid opcode ip:a8e34989 sp:bfeac550 error:0
> > Jun 29 23:28:20 debian kernel: [ 3679.067235] traps: ebook-viewer[1454] 
> > trap invalid opcode ip:aac0e9a9 sp:bf9d16d0 error:0
>

I was not able to reproduce this ebook-viewer failure with 3.39.1+dfsg-1.

> 
> I created two backtraces with gdb, using the packages calibre-bin-dbgsym,
> python2.7-dbg, libqt5webkit5-dbg, and python-pyqt5.qtwebkit-dbg.
> 
> Since /usr/bin/ebook-viewer is not a binary file, but a Python script, I
> used the approach:
> 
> - start ebook-viewer in a terminal
> - get the process id of /usr/bin/python2.7 /usr/bin/ebook-viewer
> - start gdb
> - attach gdb to the process id
> - let the application continue
> - load an ebook in the ebook-viewer
> - read the ebook, until it crashes
> - get a backtrace
>

Thank you for the backtraces and high-quality bug report! :-D Based on
a quick scan of the backtrace I wonder if this might have been a
libqt5webkit5 or a jquery bug (from the ancient unmaintained bundled
copy of jquery 1.x).  If it's the latter, it's an upstream issue.  I
thought about unbundling it, and switching to Debian's libjs-jquery
3.x, but someone would have had to check if Calibre used obsolete
methods no longer supported in jquery 3.x...  Sadly I didn't have the
time/knowledge necessary to check this in time for Buster/Debian 10.


Cheers,
Nicholas



signature.asc
Description: PGP signature

Bug#915524: Acknowledgement (RFS: filemanager-actions/3.4-1 [ITP])

[Carlos Maddela]

On 9/2/19 1:14 am, Jeremy Bicha wrote:

> 4. I think your debian/source/options is unnecessary.
> 
> 5. I don't think your backup.tar stuff is necessary at all. I
> recommend removing all of it.

Hi,

I have removed these two things in the changes I have pushed, but I
wasn't able to preserve idempotent builds. For other projects I've
worked on, it's possible to just delete the modified files and achieve
idempotent builds, but since this project also tries to patch the files
that get deleted, it doesn't work.

Anyway, I couldn't find in the Debian Policy anything about idempotent
builds, just idempotent maintainer scripts. I've only been told about
idempotent builds, I think, by other developers and I've also come
across some bug reports about it. I've also found the --git-export-dir
option to gbp-buildpackage, which allows you to not worry about modified
files.

Cheers,

Carlos

Bug#916898: linux-image-4.18.0-3-amd64: kernel oops and gdm fails to start

[Wendy J. Elmer]

yes, 4.19 solved the problem.

Thanks,

On Sun, 2019-02-10 at 01:34 +, Ben Hutchings wrote:
> Control: forcemerge 914495 -1
> On Wed, 19 Dec 2018 20:35:14 -0600 "Brent S. Elmer" 
> wrote:
> > Package: src:linuxVersion: 4.18.20-2Severity:
> > criticalJustification: breaks the whole system
> > I upgraded to linux-image-4.18.0-3-amd64 and gdm fails to start.  I
> > can getinto the system remotely and get to the journal.  There is a
> > kernel oops in thejournal.
> [...]
> This looks like a bug that was fixed in 4.19.  Let us know if
> you'restill seeing the problem.
> Ben.
> 

Bug#919507: Reboot required patch for Debian policy

[Karl O. Pinc]

On Sat, 09 Feb 2019 17:59:18 -0700
Sean Whitton  wrote:

> >> The ``/run/reboot-required`` mechanism is used when a reboot is
> >> needed to fully apply the changes introduced by a package
> >> installation or upgrade.  Typically it is the ``postinst``
> >> maintainer script that touches ``/run/reboot-required``, at the
> >> end of a successful configuration of the package.  
> >
> > I used your text, removing an "a".  
> 
> Hmm, may I ask whether you are a native speaker of English?  I am, and
> it reads better with the 'a', to me.  But don't worry, you do not need
> to prepare a new diff, as I can fix that when committing.

Yup.  I'm a native English speaker.

You made me curious.  I guess it depends on whether the
noun-ification (gerund -- https://en.wikipedia.org/wiki/Gerund)
of the verb "reboot" is "reboot" or "rebooting".

Without an "a" in the above: ...used when rebooting is
needed...

Since reboot is only recently a word, and English is whack,
who knows what's right.  I suppose I think "reboot" is both a
noun and a verb because "boot" is both a noun and a verb.
(Boot him out.  I gave him the boot.  In the latter both
senses work.)

Anyway, do whatever you think best.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#904762: vulture: missing dependency on python3-pkg-resources

[Andreas Beckmann]

Followup-For: Bug #904762
Control: tag -1 pending

Hi,

I just backported the fix from sid, built the package for stretch, opened
a stretch-pu request and uploaded the fix:
https://bugs.debian.org/921910

Andreas

Bug#921910: stretch-pu: package vulture/0.11-1+deb9u1

[Andreas Beckmann]

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

Hi,

vulture lacks a dependency on python3-pkg-resources (#904762).
This change has been backported from the fixing upload to sid and is
already uploaded.


Andreas
diff -Nru vulture-0.11/debian/changelog vulture-0.11/debian/changelog
--- vulture-0.11/debian/changelog   2016-12-01 21:15:48.0 +0100
+++ vulture-0.11/debian/changelog   2019-02-10 02:42:08.0 +0100
@@ -1,3 +1,16 @@
+vulture (0.11-1+deb9u1) stretch; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+  * Backport the dependency fix from 0.21-1.1.
+
+  [ Adrian Bunk ]
+  * Add the missing dependency on python3-pkg-resources.
+(Closes: #904762)
+  * Fix the test dependencies.
+
+ -- Andreas Beckmann   Sun, 10 Feb 2019 02:42:08 +0100
+
 vulture (0.11-1) unstable; urgency=medium
 
   * New upstream release:
diff -Nru vulture-0.11/debian/control vulture-0.11/debian/control
--- vulture-0.11/debian/control 2016-12-01 21:15:48.0 +0100
+++ vulture-0.11/debian/control 2019-02-10 02:42:02.0 +0100
@@ -19,7 +19,8 @@
 Architecture: all
 Depends:
  ${misc:Depends},
- ${python3:Depends}
+ ${python3:Depends},
+ python3-pkg-resources
 Enhances:
  prospector
 Description: scans for unused ("dead") code in a Python program
diff -Nru vulture-0.11/debian/tests/control vulture-0.11/debian/tests/control
--- vulture-0.11/debian/tests/control   2016-03-21 21:02:04.0 +0100
+++ vulture-0.11/debian/tests/control   2019-02-10 02:41:10.0 +0100
@@ -1,2 +1,2 @@
 Tests: vulture
-Depends: python3, python3-pytest
+Depends: @, python3-pytest

Bug#826020: graphite-api.service: RequireMountsFor needs to be RequiresMountsFor

[Andreas Beckmann]

Followup-For: Bug #826020
Control: tag -1 pending

Hi,

I just extracted the fix from sid, rebuilt the package for stretch,
opened a stretch-pu request and uploaded the fix:
https://bugs.debian.org/921908


Andreas

Bug#921836: ipywidgets: FTBFS (error TS2688: Cannot find type definition file for 'sizzle')

[Ximin Luo]

Control: reassign -1 src:typescript-types

This is a problem with the typescript-types package, I will upload a fix 
shortly.

X

Santiago Vila:
> Package: src:ipywidgets
> Version: 6.0.0-3
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:
> 
> 
> [...]
>  debian/rules build-indep
> dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
>dh_update_autotools_config -i -O--buildsystem=pybuild
>dh_autoreconf -i -O--buildsystem=pybuild
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/<>'
> dh_auto_configure
> I: pybuild base:217: python2.7 setup.py config 
> running config
> I: pybuild base:217: python3.7 setup.py config 
> running config
> dh_auto_configure -- -d ./widgetsnbextension
> I: pybuild base:217: python2.7 setup.py config 
> INFO:root:setup.py entered
> INFO:root:$PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> running config
> I: pybuild base:217: python3.7 setup.py config 
> INFO:root:setup.py entered
> INFO:root:$PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> running config
> make[1]: Leaving directory '/<>'
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/<>'
> /usr/bin/make -C debian -f fakewebpack.mk all
> make[2]: Entering directory '/<>/debian'
> /usr/bin/make -f "fakewebpack-prep-unpacked.mk" all
> make[3]: Entering directory '/<>/debian'
> cd "fakewebpack-unpacked/phosphor/" && tsc --moduleResolution Classic 
> --project src
> mkdir -p "fakewebpack-unpacked/phosphor/styles/" && NODE_PATH=../.. 
> fakewebpack-helpers/css-loader-pack.py < 
> "fakewebpack-unpacked/phosphor/styles/base.css.real" > 
> "fakewebpack-unpacked/phosphor/styles/base.css"
> mkdir -p "fakewebpack-unpacked/phosphor/styles/" && m4 -DNODE_PATH=../.. 
> -DCSS_INPUT=./base.css "fakewebpack-helpers/style-loader.js.m4" > 
> "fakewebpack-unpacked/phosphor/styles/base.css?f74d"
> printf "module.exports = $(cat 
> "fakewebpack-unpacked/jupyter-js-widgets/package.json.real");" > 
> "fakewebpack-unpacked/jupyter-js-widgets/package.json"
> cd "fakewebpack-unpacked/jupyter-js-widgets/" && tsc --moduleResolution 
> Classic --project src
> ../../../../../../usr/lib/nodejs/@types/jquery/index.d.ts(28,23): error 
> TS2688: Cannot find type definition file for 'sizzle'.
> ../../../../../../usr/lib/nodejs/@types/jquery/misc.d.ts(27,33): error 
> TS2503: Cannot find namespace 'Sizzle'.
> ../../../../../../usr/lib/nodejs/@types/jquery/misc.d.ts(35,14): error 
> TS2503: Cannot find namespace 'Sizzle'.
> ../../../../../../usr/lib/nodejs/@types/jquery/misc.d.ts(43,17): error 
> TS2503: Cannot find namespace 'Sizzle'.
> make[3]: *** [fakewebpack-prep-unpacked.mk:33: 
> fakewebpack-unpacked/jupyter-js-widgets/lib.stamp] Error 1
> make[3]: Leaving directory '/<>/debian'
> make[2]: *** [fakewebpack.mk:73: 
> fakewebpack/widgetsnbextension-unpacked.stamp] Error 2
> make[2]: Leaving directory '/<>/debian'
> make[1]: *** [debian/rules:15: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:7: build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> status 2
> 
> 
> (The above is just how the build ends and not necessarily the most relevant 
> part)
> 
> The build was made in my autobuilder with "dpkg-buildpackage -A"
> and it also fails here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ipywidgets.html
> 
> where you can get a full build log if you need it.
> 
> If this is really a bug in one of the build-depends, please use reassign and 
> affects,
> so that this is still visible in the BTS web page for this package.
> 
> Thanks.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#787560: calibre: Calibre can't communicate with file managers

[Nicholas D Steeves]

Control: tag -1 + moreinfo

Hi Luis,

Is this issue also present in stretch's released
calibre_2.75.1+dfsg-1, and if so, is it also present in the Calibre
version in stretch-backports?

  https://backports.debian.org/

Reply follows inline:

On Tue, Jun 02, 2015 at 12:45:12PM -0500, Luis Mochan wrote:
> Package: calibre
> Version: 2.24.0+dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> After upgrading to Debian/stretch I found that Calibre was unable to open pdf
> books, with errors such as
>   Unable to find the requested file. Please check the spelling and try again.
>   Unhandled error message: Error when getting information for file '...': No
> such file or directory
> (when my prefered file manager is Nautilus) and a nautilus window is opened.
> Later I found the same message when trying to open a Path.
>   Changing my prefered file manager to thunar through exo-preferred-
> applications the message changes to
>   Failed to open "..."
>   Error when getting information for file '..': No such file or directory.
> I noticed that the message seems to come from the file manager, not from
> Calibre.
> I also noticed that the file name passed to the file manager has spaces
> replaced by '%20'.

Are the files local or is this a remote share (SSH/SFTP/SAMBA/etc)?

> The files do exist and I can open them from both file managers by clicking on
> them.

Presumably the files open successfully in the default PDF viewer?
Which PDF viewer?

> Furthermore, I can open the same book in other formats from the same
> directory using Calibre. I could also open the pdf's after installing the 
> 'Open
> With' plugin and configuring it for opening pdf files. So I guess the problem
> is related to the protocol used to communicate with the file managers.

So this issue is specific to PDFs?  Do ebooks in epub, mobi, etc. open
successfully in Calibre (or calibre-viewer) when clicking on them in
Nautilus or Thunar?

What happens when you drag and drop a PDF into the middle library pane
of the Calibre window?


Thanks for the bug report,
Nicholas


signature.asc
Description: PGP signature

Bug#921538: Fails to start since upgrade to 1.9.0-1

[Robert Edmonds]

Simon Deziel wrote:
> On 2019-02-06 11:12 a.m., Ryan Kavanagh wrote:
> > Since the upgrade to 1.9.0-1, unbound fails to start. Purging the
> > package and reinstalling does not fix the issue. The errors seem to be
> > due to being unable to read various configuration files.
> > 
> > Feb 06 11:01:12 zeta unbound[28647]: [28647:0] error: unable to open 
> > /var/lib/unbound/root.key for reading: No such file or directory
> > Feb 06 11:01:12 zeta package-helper[28648]: [1549468872] 
> > unbound-checkconf[28651:0] error: Could not open 
> > /etc/unbound//etc/unbound/unbound.conf: No such file or director
> 
> It seems like chroot'ing to /etc/unbound is attempted. To workaround you
> can try this:
> 
> cat << EOF > /etc/unbound/unbound.conf.d/chroot.conf
> server:
>   chroot: ""
> EOF
> service unbound restart

Automatic chroot'ing has been disabled in the unbound Debian package for
a while, by this commit:

https://salsa.debian.org/dns-team/unbound/commit/66bb04a0869e315f76c4b4efe8632914d860686c

It looks like that change was lost in the 1.9.0-1 upload, compare these
two revisions:

https://salsa.debian.org/dns-team/unbound/blob/debian/1.8.1-1/util/config_file.c#L163-165

https://salsa.debian.org/dns-team/unbound/blob/debian/1.9.0-1/util/config_file.c#L169-171

Probably it's better to use the --with-chroot-dir= argument to configure
rather than directly patching the source to change the default.

-- 
Robert Edmonds
edmo...@debian.org

Bug#921538: Fails to start since upgrade to 1.9.0-1

[Simon Deziel]

On 2019-02-09 8:28 p.m., Robert Edmonds wrote:
> Probably it's better to use the --with-chroot-dir= argument to configure
> rather than directly patching the source to change the default.

Indeed and that's what's being proposed in the merge request.

Regards,
Simon

Bug#921909: QCachegrind is not being packaged in KCachegrind 17

[nandhp]

Package: qcachegrind
Version: 4:17.08.3-2
Severity: important

Dear Maintainer,

QCachegrind is KCachegrind built without a KDE dependency. It is
compiled as part of the KCachegrind build process, but not installed
by default. It was packaged in Debian as part of KCachegrind 16 and
present in stretch:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836937

However, it seems to have gotten lost when KCachegrind 17 was
packaged. This means that QCachegrind is currently missing from buster
and sid. Please resume building the QCachegrind binary package.

https://tracker.debian.org/news/817634/accepted-kcachegrind-416083-1-source-into-unstable/
https://tracker.debian.org/news/872010/accepted-kcachegrind-417081-1-source-all-amd64-into-experimental/

Thank you.
-nandhp

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

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

Bug#666258: calibre: please, don't depend on fonts-liberation exclusively

[Nicholas D Steeves]

Hi Rogério!

On Fri, Mar 30, 2012 at 12:07:15AM -0300, Rogério Brito wrote:
> Package: calibre
> Version: 0.8.41+dfsg-1
> Severity: minor
> 
> Dear Maintainer,
> 
> In the interest of keeping systems with fewer dependencies, it would be nice
> if calibre's dependency of fonts-liberation were downgraded to a Recommends:
> or perhaps, have a Depends: like `ttf-freefont | fonts-liberation | 
> ttf-dejavu`
> (as cups-filters do).
> 
> Thanks in advance,
> 
> Rogério Brito.
> 

Thanks for filing this bug; I agree, dependency bloat/creep should be
resisted :-)

Calibre upstream bundles a copy of fonts-liberation, which would
usually be installed to /usr/share/calibre/fonts/liberation/.  Thus,
upstream intends a strong dependency on it.  [1] See
/usr/share/doc/calibre/README.Debian about how to change the font.

"Depends: ttf-freefont | fonts-liberation | ttf-dejavu" will not work
without those steps.

It may be possible to use the Debian alternatives mechanism (see
/etc/alternatives, and 'man update-alternatives') to configure this
[2], but I will have to ask more experienced developers if it is
permitted to use this mechanism as a way to configure fonts for a
single application...my gut feeling is that this is not permitted.

Unfortunately it's too late in the buster release cycle to experiment,
test, and move forward with this bug.  Please feel free to send a
reminder to revisit it in August :-)


Kind regards,
Nicholas

[1] But of course a hard upstream dependency is often a "Recommends"
in Debian.  In this case if there are rendering or layout issues
when using other fonts, then the existing "Depends" is necessary.
[2] Symlinks mentioned in README.Debian point to
/etc/alternatives/calibre_font_names


signature.asc
Description: PGP signature

Bug#921908: stretch-pu: package graphite-api/1.1.3-2+deb9u1

[Andreas Beckmann]

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

Let's fix the typo in the service file, #826020
Cherry-picked from sid and already uploaded.


Andreas
diff -Nru graphite-api-1.1.3/debian/changelog 
graphite-api-1.1.3/debian/changelog
--- graphite-api-1.1.3/debian/changelog 2016-09-03 22:49:50.0 +0200
+++ graphite-api-1.1.3/debian/changelog 2019-02-10 02:29:37.0 +0100
@@ -1,3 +1,14 @@
+graphite-api (1.1.3-2+deb9u1) stretch; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+  * Backport spelling fix from 1.1.3-3.  (Closes: #826020)
+
+  [ Vincent Bernat ]
+  * d/service: fix RequiresMountsFor spelling.
+
+ -- Andreas Beckmann   Sun, 10 Feb 2019 02:29:37 +0100
+
 graphite-api (1.1.3-2) unstable; urgency=medium
 
   * d/control: Build-Depends on python3-sphinx-rtd-theme. Closes: #828715.
diff -Nru graphite-api-1.1.3/debian/graphite-api.service 
graphite-api-1.1.3/debian/graphite-api.service
--- graphite-api-1.1.3/debian/graphite-api.service  2016-09-03 
22:49:50.0 +0200
+++ graphite-api-1.1.3/debian/graphite-api.service  2019-02-10 
02:18:50.0 +0100
@@ -1,7 +1,7 @@
 [Unit]
 Description=Graphite-API service
 Requires=graphite-api.socket
-RequireMountsFor=/var/log/graphite-api /var/lib/graphite/whisper 
/var/lib/graphite-api
+RequiresMountsFor=/var/log/graphite-api /var/lib/graphite/whisper 
/var/lib/graphite-api
 ConditionFileIsExecutable=/usr/bin/gunicorn3
 ConditionPathExists=/etc/graphite-api.yaml
 ConditionPathExists=/usr/lib/python3/dist-packages/graphite_api/app.py

Bug#916898: linux-image-4.18.0-3-amd64: kernel oops and gdm fails to start

[Ben Hutchings]

Control: forcemerge 914495 -1

On Wed, 19 Dec 2018 20:35:14 -0600 "Brent S. Elmer"  wrote:
> Package: src:linux
> Version: 4.18.20-2
> Severity: critical
> Justification: breaks the whole system
> 
> I upgraded to linux-image-4.18.0-3-amd64 and gdm fails to start.  I can get
> into the system remotely and get to the journal.  There is a kernel oops in 
> the
> journal.
[...]

This looks like a bug that was fixed in 4.19.  Let us know if you're
still seeing the problem.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.



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

Bug#921838: ppl: FTBFS (LaTeX error)

[James Clarke]

Looks like this common issue is in fact #921272.
(i.e. the currently-packaged tabu broke with recent TeX Live)

James

Bug#916858: supercollider-emacs: fails to install with xemacs21

[Andreas Beckmann]

Followup-For: Bug #916858
Control: tag -1 pending

Hi,

I cherry-picked that commit from sid, rebuilt the package for stretch
and files a stretch-pu request: https://bugs.debian.org/921893


Andreas

Bug#888847: grokmirror: missing dependency on python-pkg-resources

[Andreas Beckmann]

Followup-For: Bug #47
Control: tag -1 pending

Hi, I just rebuilt the package for stretch and filed a
stretch-pu-request: https://bugs.debian.org/921907


Andreas

Bug#919442: python-dmidecode-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

On 2019-02-10 00:04, Sandro Tosi wrote:
>> your .maintscript files are wrong. Obviously you wanted symlink_to_dir,
>> but you used dir_to_symlink.
> 
> mh not really, i want /usr/share/doc/python-dmidecode-dbg/ to be a
> symlink to /usr/share/doc/python-dmidecode/ (and the same for the py3k
> packages) - isnt symlink_to_dir the right helper to use in that case?

Well, as long as the package ships a directory full of files in
/usr/share/doc:

/usr/share/doc/python-dmidecode-dbg
/usr/share/doc/python-dmidecode-dbg/AUTHORS
/usr/share/doc/python-dmidecode-dbg/AUTHORS.upstream
/usr/share/doc/python-dmidecode-dbg/README
/usr/share/doc/python-dmidecode-dbg/README.types
/usr/share/doc/python-dmidecode-dbg/README.upstream.gz
/usr/share/doc/python-dmidecode-dbg/changelog.Debian.gz
/usr/share/doc/python-dmidecode-dbg/changelog.gz
/usr/share/doc/python-dmidecode-dbg/copyright

trying to use d-m-h to change that into a symlink will only cause a
great mess.

Andreas

Bug#872299: gnome-orca: Orca segfaults on startup

[Tim Smith]

I think my audio problem above may have been related to bug #801670,
"speech-dispatcher: Hangs and does no longer take speech from Orca until
killed".  When I killed speech-dispatcher and ran Orca again, it worked.
At any rate, I am now running newer versions of both Orca and
speech-dispatcher, and the problem no longer seems to occur.

Thanks,

Tim

On Fri, Sep 1, 2017 at 5:11 PM Tim Smith  wrote:

> I don't have braille that I know of.
>
> Output of "make check -k" is below.
>
> Regards,
>
> Tim
>
> -
>
> ./check gtk2
> got :1.0 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.2 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.3 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.4 at /org/a11y/atspi/accessible/root
>   got :1.4 at /org/a11y/atspi/accessible/1
> Got name 'Top Expanded Edge Panel'
>   got :1.4 at /org/a11y/atspi/accessible/2
> Got name 'Bottom Expanded Edge Panel'
>   end of list
> got :1.5 at /org/a11y/atspi/accessible/root
>   got :1.5 at /org/a11y/atspi/accessible/1
> Got name 'Desktop'
>   got :1.5 at /org/a11y/atspi/accessible/2
> Got name 'check-a11y'
> Success
> ./check gtk3
> got :1.0 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.2 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.3 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.4 at /org/a11y/atspi/accessible/root
>   got :1.4 at /org/a11y/atspi/accessible/1
> Got name 'Top Expanded Edge Panel'
>   got :1.4 at /org/a11y/atspi/accessible/2
> Got name 'Bottom Expanded Edge Panel'
>   end of list
> got :1.5 at /org/a11y/atspi/accessible/root
>   got :1.5 at /org/a11y/atspi/accessible/1
> Got name 'Desktop'
>   got :1.5 at /org/a11y/atspi/accessible/2
> Got name 'check-a11y'
> Success
> ./check qt4
> got :1.0 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.2 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.3 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.4 at /org/a11y/atspi/accessible/root
>   got :1.4 at /org/a11y/atspi/accessible/1
> Got name 'Top Expanded Edge Panel'
>   got :1.4 at /org/a11y/atspi/accessible/2
> Got name 'Bottom Expanded Edge Panel'
>   end of list
> got :1.5 at /org/a11y/atspi/accessible/root
>   got :1.5 at /org/a11y/atspi/accessible/1
> Got name 'Desktop'
>   got :1.5 at /org/a11y/atspi/accessible/2
> Got name 'check-a11y'
> Success
> ./check qt5
> got :1.0 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.2 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.3 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.4 at /org/a11y/atspi/accessible/root
>   got :1.4 at /org/a11y/atspi/accessible/1
> Got name 'Top Expanded Edge Panel'
>   got :1.4 at /org/a11y/atspi/accessible/2
> Got name 'Bottom Expanded Edge Panel'
>   end of list
> got :1.5 at /org/a11y/atspi/accessible/root
>   got :1.5 at /org/a11y/atspi/accessible/1
> Got name 'Desktop'
>   got :1.5 at /org/a11y/atspi/accessible/2
> Got name 'check-a11y'
> Success
> ./check java
> got :1.0 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.2 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.3 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.4 at /org/a11y/atspi/accessible/root
>   got :1.4 at /org/a11y/atspi/accessible/1
> Got name 'Top Expanded Edge Panel'
>   got :1.4 at /org/a11y/atspi/accessible/2
> Got name 'Bottom Expanded Edge Panel'
>   end of list
> got :1.5 at /org/a11y/atspi/accessible/root
>   got :1.5 at /org/a11y/atspi/accessible/1
> Got name 'Desktop'
>   got :1.5 at /org/a11y/atspi/accessible/2
> Got name 'check-a11y'
> Success
> ./check java7
> ./check: 34: ./check: /usr/lib/jvm/java-7-openjdk-amd64/bin/java: not found
> got :1.0 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.2 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.3 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.4 at /org/a11y/atspi/accessible/root
>   got :1.4 at /org/a11y/atspi/accessible/1
> Got name 'Top Expanded Edge Panel'
>   got :1.4 at /org/a11y/atspi/accessible/2
> Got name 'Bottom Expanded Edge Panel'
>   end of list
> got :1.5 at /org/a11y/atspi/accessible/root
>   got :1.5 at /org/a11y/atspi/accessible/1
> Got name 'Desktop'
>   got :1.5 at /org/a11y/atspi/accessible/2
> Got name 'check-a11y'
> Success
> ./check: 42: kill: No such process
>
> ./check java8
> got :1.0 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.2 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.3 at /org/a11y/atspi/accessible/root
>   end of list
> got :1.4 at /org/a11y/atspi/accessible/root
>   got :1.4 at /org/a11y/atspi/accessible/1
> Got name 'Top Expanded Edge Panel'
>   got :1.4 at /org/a11y/atspi/accessible/2
> Got name 'Bottom Expanded Edge Panel'
>   end of list
> got :1.5 at /org/a11y/atspi/accessible/root
>   got :1.5 at /org/a11y/atspi/accessible/1
> Got name 

Bug#883413: src:linux: Still reproducible with linux-image-4.15.0-rc8-amd64

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 moreinfo

On Mon, 29 Jan 2018 15:05:00 + Chris Boot  wrote:
> Package: src:linux
> Followup-For: Bug #883413
> 
> Hi Ben,
> 
> Unfortunately I can still reproduce this problem on 4.15-rc8 from
> experimental.
> 
> The cmdline for this boot was:
> 
> BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc8-amd64
> root=/dev/mapper/vg_tarquin-rootfs ro intel_iommu=on vsyscall=emulate
> scsi_mod.use_blk_mq=Y dm_mod.use_blk_mq=Y intel_pstate=passive
> i915.disable_display=Y i915.enable_gvt=Y apparmor=0
> systemd.unified_cgroup_hierarchy=1 console=ttyS1,115200n8 console=tty0
> 
> This triggers with DefaultMemoryAccounting=yes enabled in
> /etc/systemd/system.conf, and NUT seems to regularly be involved in the
> crash on my system. Sadly the systemd unit is very simple indeed, and
> because my UPS is network-connected I'm not even doing dodgy things like
> USB from within NUT.
> 
> Quite how the kernel thinks that nut-server.service is using 16 ZiB of
> memory is beyond me; presumably this is a slightly negative 64-bit int
> bring cast unsigned. The following also feels like a smoking gun:
>
> [ 2982.158622] percpu ref (css_release) <= 0 (-197) after switching to atomic
[...]

Sorry for leaving this unanswered so long.  Are you still seeing this? 
I found some apparently related reports on the Red Hat Bugzilla but not
on anything newer than 4.17.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.




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

Bug#919507: Reboot required patch for Debian policy

[Sean Whitton]

control: tag 1 +patch

Hello Karl,

Thank you for the new patch.

On Sun 20 Jan 2019 at 05:09PM -06, Karl O. Pinc wrote:

> I'm 99% confident that _a_ purpose of reboot-required.pkgs
> is to provide a list of the packages requiring a reboot
> to a human.  And notification did not seem to be via logs.
> I can't say if the file has any other purpose.
>
> Regardless of the above, I've made your change as suggested.
> The important thing I want to convey is that reboot-required.pkgs
> does not affect the reboot signal.  It does something supplementary.
> Better not to over-specify.

Indeed.

> It is also worth nothing at this point that kubernetes appears
> to be touching reboot-required and adding to reboot-required.pkgs, but
> doing so in non-package-installation related code.  AFAICT.  At least
> that's what I recall now after a short glance through the code
> some time ago.  This is why I added the bit about regular
> programs being able to signal for reboot.

Okay.

>> The ``/run/reboot-required`` mechanism is used when a reboot is
>> needed to fully apply the changes introduced by a package
>> installation or upgrade.  Typically it is the ``postinst``
>> maintainer script that touches ``/run/reboot-required``, at the
>> end of a successful configuration of the package.
>
> I used your text, removing an "a".

Hmm, may I ask whether you are a native speaker of English?  I am, and
it reads better with the 'a', to me.  But don't worry, you do not need
to prepare a new diff, as I can fix that when committing.

> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index 59c92ec..8276bfe 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -1040,3 +1040,33 @@ Debian, so this section has been removed.
> activate the trigger. In that case, it can be done by calling
> ``dpkg-trigger --no-await /usr/lib/mime/packages`` from the
> maintainer script after creating, modifying, or removing the file.
> +
> +.. index::
> +   pair: signaling; reboot
> +
> +.. _s-signalingreboot
> +
> +Signaling that a reboot is required
> +---
> +
> +.. index::
> +   single: reboot-required
> +   single: reboot-required.pkgs
> +
> +Programs can signal that a reboot is required by ``touch``\ing
> +``/run/reboot-required``.  It is conventional to add the name of the
> +package(s) requiring the reboot to
> +``/run/reboot-required.pkgs``. Programs should not add a package name
> +to ``/run/reboot-required.pkgs`` if it is already present there.
> +
> +.. index:
> +   single: postinst
> +
> +The ``/run/reboot-required`` mechanism is used when a reboot is
> +needed to fully apply the changes introduced by package
> +installation or upgrade.  Typically it is the ``postinst``
> +maintainer script that touches ``/run/reboot-required``, at the end
> +of a successful configuration of the package.
> +
> +There are no guarantees provided by the ``/var/reboot-required``
> +convention as to when or whether the requested reboot will occur.

Seconded.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#898743: breaks when #included after

[Ben Hutchings]

Control: reassign -1 libc6-dev
Control: severity -1 normal

On Tue, 15 May 2018 16:57:57 +0200 Helmut Grohne  wrote:
> Package: linux-libc-dev,libc6-dev
> Severity: serious
> Justification: makes systemd ftbfs
> User: helm...@debian.org
> Usertags: rebootstrap
> Control: affects -1 + src:systemd libmount-dev
>
> systemd FTBFS here, because compiling load-fragment.c fails. I spent a while
> minimizing that file and it boils down to:
> 
> $ cat test.c
> #include 
> #include 
> $ gcc -c test.c
> In file included from test.c:1:0:
> /usr/include/x86_64-linux-gnu/sys/mount.h:35:3: error: expected identifier 
> before numeric constant
>MS_RDONLY = 1,  /* Mount read-only.  */
>^
> $
> 
> linux/fs.h #defines MS_RDONLY and then sys/mount.h tries to create an
> enum containing MS_RDONLY. That's a problem.
[...]

 has defined MS_RDONLY as a macro since before version 1.0,
so this is a wontfix on the kernel side.   was already
defining MS_RDONLY as both enumerator and macro in jessie, so this
doesn't seem to be a regression.

Downgrading and reassigning to just libc6-dev, but I fully expect this
to be wontfix on that side as well.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.



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

Bug#921907: stretch-pu: package grokmirror/1.0.0-1.1~deb9u1

[Andreas Beckmann]

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

Hi,

grokmirror misses a dependency on python-pkg-resources (#47).
This is just a rebuild of the package from sid and already uploaded.

Andreas
diff -Nru grokmirror-1.0.0/debian/changelog grokmirror-1.0.0/debian/changelog
--- grokmirror-1.0.0/debian/changelog   2016-05-23 00:36:06.0 +0200
+++ grokmirror-1.0.0/debian/changelog   2019-02-10 01:39:00.0 +0100
@@ -1,3 +1,18 @@
+grokmirror (1.0.0-1.1~deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for stretch.
+
+ -- Andreas Beckmann   Sun, 10 Feb 2019 01:39:00 +0100
+
+grokmirror (1.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the missing dependency on python-pkg-resources.
+(Closes: #47)
+
+ -- Adrian Bunk   Thu, 27 Sep 2018 20:19:18 +0300
+
 grokmirror (1.0.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru grokmirror-1.0.0/debian/control grokmirror-1.0.0/debian/control
--- grokmirror-1.0.0/debian/control 2016-05-23 00:36:06.0 +0200
+++ grokmirror-1.0.0/debian/control 2018-09-27 19:19:18.0 +0200
@@ -12,7 +12,7 @@
 
 Package: grokmirror
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, python, python-anyjson, python-git
+Depends: ${misc:Depends}, ${python:Depends}, python, python-anyjson, 
python-git, python-pkg-resources
 Enhances: git
 Description: framework to smartly mirror git repositories
  grokmirror mirrors large git repository collections efficiently. It

Bug#921906: cryptsetup-run: askpass running in initramfs locks up if user types Ctrl+D at the password prompt

[Ken Milmore]

Package: cryptsetup-run
Version: 2:2.0.6-1
Severity: normal
Tags: patch

When using an encrypted root file system, user is prompted to enter
password to unlock the disk from initramfs. Typing Ctrl+D immediately at
the password prompt results in the boot locking up, requiring a hard reset.

Steps to reproduce:
- Install Debian, choosing to set up encrypted LVM, e.g. with guided
partitioning.
- When booting the installed system, a prompt of the form "Please unlock
disk sda3_crypt" is displayed.
- Press Ctrl+D instead of entering the passphrase.
- Nothing further is printed on screen. Attempts to enter the
passphrase, or anything else, result in no response.

The problem is in the console backend of the askpass binary, which goes
into an infinite loop calling getline() if an EOF should occur on stdin
at the beginning of a line. The behaviour of getline() with end-of-file
conditions seems to be rather odd in some cases, but if it is entered
with the eof status already set on the input stream it correctly returns
immediately with a -1 result. As askpass repeatedly calls getline until
a passphrase is successfully entered, once an eof happens the first time
it gets stuck in a busy loop.

I circumvented this in the attached patch by clearing the stream flags
on failure, causing the Ctrl+D to be ignored. I'm not sure if this is
quite the ideal behaviour but I suspect it is probably the best that can
be achieved when using cooked input and getline(). Note I have also
fixed the incorrect (but harmless) return of NULL from a bool function.

Another possible workaround is to install plymouth, which causes a
different askpass backend to be used.

-- Package-specific info:

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

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

Versions of packages cryptsetup-run depends on:
ii  cryptsetup-bin 2:2.0.6-1
ii  debconf [debconf-2.0]  1.5.70
ii  dmsetup2:1.02.155-1
ii  libc6  2.28-5

cryptsetup-run recommends no packages.

Versions of packages cryptsetup-run suggests:
ii  dosfstools  4.1-2
pn  keyutils
ii  liblocale-gettext-perl  1.07-3+b4

-- debconf information excluded
diff -Nru cryptsetup-2.0.6/debian/askpass.c cryptsetup-2.0.6/debian/askpass.c
--- cryptsetup-2.0.6/debian/askpass.c   2018-12-03 19:16:07.0 +
+++ cryptsetup-2.0.6/debian/askpass.c   2019-02-09 17:38:19.0 +
@@ -359,8 +359,10 @@
/* Console is in ICANON mode so we'll get entire lines */
nread = getline(, , stdin);
 
-   if (nread < 0)
-   return NULL;
+   if (nread < 0) {
+   clearerr(stdin);
+   return false;
+   };
 
/* Strip trailing newline, if any */
if (nread > 0 && consolebuf[nread - 1] == '\n') {

Bug#921842: (no subject)

[Ul]

I did: https://github.com/mate-desktop/eom/issues/206

just to document it here for the next one...

Bug#921905: RM: libvte-doc -- ROM; RoQA; arch:all NBS package

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-CC: v...@packages.debian.org

source:vte no longer builds libvte-doc. Please remove it from Debian.
It is arch:all so isn't picked up by auto-cruft.

Thanks,
Jeremy Bicha

Bug#921662: dput: Fails to install Bash completion scripts

[Ben Finney]

Control: severity -1 minor
Control: tags -1 + confirmed
Control: retitle -1 dput: Fails to install Bash completion scripts
Control: summary -1 0

The ‘dput’ binary package as of version 1.0.3 does not include the
Bash completion scripts for commands.

On 07-Feb-2019, Antoine Beaupre wrote:
> Some time ago, dput could autocomplete remote endpoints. […] Now
> that stopped working, I'm not sure why.

My attempt to reproduce shows that there is *no* Bash completion
script installed for ‘dput’ (nor ‘dcut’).

This means there is also no Bash completion for the specific command
options. What do you get when you try this:

$ dput --s[TAB]

That should, if Bash completion is working correctly, complete the
‘--simulate’ option.

-- 
 \  “Truth: Something somehow discreditable to someone.” —Henry L. |
  `\   Mencken |
_o__)  |
Ben Finney 

Bug#921895: bitlbee: does not build all binary packages by default

[Sean Whitton]

Hello Wilmer,

On Sun 10 Feb 2019 at 12:10AM +00, Wilmer van der Gaast wrote:

> Yeah, this has always been a little bit iffy. Thankfully the
> Skype-related packages can go away altogether. I'm not tracking BitlBee
> development anymore but would expect that they go away in 3.6 (I'll have
> to do the upload for it within the next few days so I'll verify).

Thank you for your response.  Please be sure to my -1.2 NMU in your
upload, as it fixes another bug too.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#921869: libwebkit2gtk-4.0-37: Renders some Hebrew characters as square boxes

[Alberto Garcia]

On Sat, Feb 09, 2019 at 05:30:06PM +0100, Teus Benschop wrote:

> The webkit engine renders some Hebrew characters as square boxes.
> 
> I have created a minimal example that shows the problem.

Hello,

thanks for the example, I can reproduce the problem with WebKitGTK
2.22.6.

I did a quick test with other browsers:

  - Chromium 71.0.3578.80 also fails but in a different way:
- "he-goat" is right in Chromium, but wrong in WebKit
- "speak" is wrong in Chromium, but right in WebKit 
  - Chrome 71.0.3578.98 however displays everything correctly.
  - Firefox-ESR 60.5.0 also works fine.

Other apps (terminal, text editor, etc) can display the text
correctly.

I'll discuss the problem with the upstream developers.

> The link to the minimal example is here:

In case it's useful, the Debian WebKitGTK package also contains a mini
web browser:

   /usr/lib/*/webkit2gtk-4.0/MiniBrowser

Regards,

Berto

Bug#921895: bitlbee: does not build all binary packages by default

[Wilmer van der Gaast]

Yeah, this has always been a little bit iffy. Thankfully the
Skype-related packages can go away altogether. I'm not tracking BitlBee
development anymore but would expect that they go away in 3.6 (I'll have
to do the upload for it within the next few days so I'll verify).



signature.asc
Description: OpenPGP digital signature

Bug#821397: sway 1.0-rc1

[Sean Whitton]

Hello Berger, Mattia,

On Sat 09 Feb 2019 at 09:30PM +01, Mattia Rizzolo wrote:

> On Sat, Feb 09, 2019 at 01:21:36PM -0700, Sean Whitton wrote:
>> wlroots is only in experimental and is pre-1.0, however.  So we probably
>> shouldn't demand proper transitions from its maintainers.
>
> This is not about transitions though.  It's about being sure wlroots
> maintainer know what it means to track ABI and they understand their
> importance, and know about the tooling Debian has to properly deal with
> these metters.
>
>> Birger, could you add a comment in d/control, saying that the versioned
>> dependency is just a workaround to help users of Debian experimental
>> avoid a broken window manager, and in the future it will be removed in
>> favour of relying on dpkg-shlibdeps?
>
> May I instead suggest a new, proper, wlroots update?  If this is what
> I'm thinking, it means 0.3-1 broke over 0.2-1, and that is a bug that
> I'd be filing as serious if I found it myself.
> Happy to properly check, since this is a simple library I should find
> the time for this.

I don't think we should allow problems with wlroots in experimental to
block getting sway through NEW and into experimental, although we'd want
to hold off moving sway to unstable until the wlroots situation is
resolved.  So, I stand by my d/control commenting suggestion.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#921128: Info received (mailman3-web fails to initialize mysql: Specified key was too long)

[Pierre-Elliott Bécue]

Le vendredi 01 février 2019 à 21:05:38-0500, Antoine Beaupré a écrit :
> I just read the README.Debian file and it says the mariadb version in
> stretch might conflict with the mailman3-web version.
> 
> If that's really the case, might I suggest the backport be fixed to warn
> explicitely about this somehow? maybe conflict with that mariadb
> version?

Please review and comment
https://salsa.debian.org/mailman-team/mailman-suite/commit/1dc0dcf43e763b4b78e808877d65a8dbb6119170

I'll upload in a couple of days. :)

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#921663: Please add python-certbot update to jessie-backports

[Ola Lundqvist]

Hi

Here are the reverse dependencies for that.

(jessie_chroot)root@tigereye:~/build/certbot/python-certbot-0.28.0#
apt-rdepends -r python3-cryptography
Reading package lists... Done
Building dependency tree
Reading state information... Done
python3-cryptography
  Reverse Depends: python3-openssl (0.14-1)
python3-openssl
  Reverse Depends: python3-service-identity (1.0.0-3)
python3-service-identity

Does not look like much.

// Ola

On Sat, 9 Feb 2019 at 23:20, Brad Warren  wrote:

> Thanks for looking into that Ola.
>
> I think we could work around the python3-sphinx problem. It’s just used
> for building the docs and python3-sphinx (>= 1.6) is not in Stretch despite
> the Certbot package being updated there. It seems to me like something
> similar could be done here.
>
> python3-cryptography certainly might be a problem though.
>
> > On Feb 9, 2019, at 12:27 PM, Ola Lundqvist  wrote:
> >
> > Hi Holger and Brad
> >
> > Here is a little more extensive list of dependencies:
> >
> > python-certbot (of course as it is the one providing certbot)
> > python3-acme (>= 0.26.0~) - not in jessie, available in backports
> > python3-configargparse - not in jessie, available in backports
> > python3-cryptography (>= 1.2) - update needed (affecting something
> else?), available in backports
> > python3-josepy - not in jessie
> > python3-rfc3339 - not in jessie, available in backports
> > python3-sphinx (>= 1.6) - update needed (affecting something else?)
> > python-certbot-nginx
> > python-certbot-apache
> >
> > python-certbot-nginx and python-certbot-apache do not seem to add any
> additional dependencies that are not already in jessie.
> >
> > I have not checked if any of the above packages require further
> dependencies so the list may grow larger.
> >
> > Best regards
> >
> > // Ola
> >
> > On Sat, 9 Feb 2019 at 20:58, Brad Warren  wrote:
> >
> >
> > > On Feb 9, 2019, at 6:19 AM, Holger Levsen 
> wrote:
> > >
> > > On Sat, Feb 09, 2019 at 02:54:43PM +0100, Ola Lundqvist wrote:
> > >> I can also add that I have looked into this for myself and the number
> of
> > >> needed dependencies is rather large. So it is not just certbot that
> need an
> > >> update, we also need to include quite a few other packages too.
> > >
> > > how large exactly?
> > >
> > All of:
> >
> > - python-acme
> > - python-certbot
> > - python-certbot-apache
> > - python-certbot-nginx
> > - python-josepy
> >
> > would need to be added/updated like they were in Stretch. (The new
> python-josepy package comes from it being split out of python-acme.)
> >
> > We have spent a lot of time upstream keeping compatibility with older
> versions of our dependencies and not adding new dependencies with the goal
> of making situations like this easier.
> >
> > With that said, these Debian packages have switched from Python 2 to
> Python 3 since the last time they were updated in jessie-backports. The
> switch to Python 3 would either need to be undone (as we have kept
> compatibility with Python 2 upstream) or Python 3 versions of some of our
> dependencies would need to be added. I am not sure how many packages would
> be affected if the latter approach was taken.
> >
> > >
> > > --
> > > tschau,
> > >   Holger
> > >
> > >
> ---
> > >   holger@(debian|reproducible-builds|layer-acht).org
> > >   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A
> AA1C
> >
> >
> >
> > --
> >  --- Inguza Technology AB --- MSc in Information Technology 
> > /  o...@inguza.comFolkebogatan 26\
> > |  o...@debian.org   654 68 KARLSTAD|
> > |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> > \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
> >  ---
> >
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#881800: Please confirm bug affects 1.21.0-1

[Nicholas D Steeves]

Control: fixed -1 php-elisp/1.21.0-1

Hi Olivier,

Thanks for confirming!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#816200: bitlbee: diff for NMU version 3.5.1-1.2

[Sean Whitton]

Control: tags 816200 + pending
Control: tags 921895 + pending

Dear maintainer,

I've prepared an NMU for bitlbee (versioned as 3.5.1-1.2) and uploaded
it to DELAYED/5. Please feel free to tell me if I should delay it
longer.

Regards.

-- 
Sean Whitton
diff -u bitlbee-3.5.1/debian/bitlbee-common.postinst bitlbee-3.5.1/debian/bitlbee-common.postinst
--- bitlbee-3.5.1/debian/bitlbee-common.postinst
+++ bitlbee-3.5.1/debian/bitlbee-common.postinst
@@ -34,7 +34,9 @@
 	adduser --system --group --disabled-login --disabled-password --home /var/lib/bitlbee/ bitlbee
 fi
 
-chmod 700 /var/lib/bitlbee/
+if [ -d /var/lib/bitlbee ]; then
+chmod 700 /var/lib/bitlbee/
+fi
 
 ## Can't do this in packaging phase: Don't know the UID yet. Access to
 ## the file should be limited, now that it stores passwords. Added
diff -u bitlbee-3.5.1/debian/changelog bitlbee-3.5.1/debian/changelog
--- bitlbee-3.5.1/debian/changelog
+++ bitlbee-3.5.1/debian/changelog
@@ -1,3 +1,23 @@
+bitlbee (3.5.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Comment out bitlbee-plugin-skype and skyped in d/control (Closes: #921895).
+These binary packages are not built by d/rules by default, and as such
+they are not currently in the archive.  Commenting them out in order
+to avoid my NMU hitting binNEW; this caused the -1.1 source-only
+upload to fail.
+Thank you to Mattia Rizzolo for suggesting this fix.
+
+ -- Sean Whitton   Sat, 09 Feb 2019 17:03:38 -0700
+
+bitlbee (3.5.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add existence check to chmod call in bitlbee-common.postinst
+(Closes: #816200).
+
+ -- Sean Whitton   Fri, 25 Jan 2019 16:50:34 -0700
+
 bitlbee (3.5.1-1) unstable; urgency=medium
 
   * Crash bug fix. (Closes: #853282)
diff -u bitlbee-3.5.1/debian/control bitlbee-3.5.1/debian/control
--- bitlbee-3.5.1/debian/control
+++ bitlbee-3.5.1/debian/control
@@ -72,22 +72,22 @@
-Package: bitlbee-plugin-skype
-Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, bitlbee (= ${binary:Version}) | bitlbee-libpurple (= ${binary:Version}), bitlbee-common (= ${source:Version})
-Recommends: skyped
-Description: IRC to other chat networks gateway (Skype plugin)
- This program can be used as an IRC server which forwards everything you
- say to people on other chat networks: Jabber (which includes Google
- Talk), ICQ, AIM, MSN and Twitter.
- .
- This package contains a plugin that adds support for the Skype IM network.
- You need to download and install the Skype client for this to work.
+# Package: bitlbee-plugin-skype
+# Architecture: any
+# Depends: ${misc:Depends}, ${shlibs:Depends}, bitlbee (= ${binary:Version}) | bitlbee-libpurple (= ${binary:Version}), bitlbee-common (= ${source:Version})
+# Recommends: skyped
+# Description: IRC to other chat networks gateway (Skype plugin)
+#  This program can be used as an IRC server which forwards everything you
+#  say to people on other chat networks: Jabber (which includes Google
+#  Talk), ICQ, AIM, MSN and Twitter.
+#  .
+#  This package contains a plugin that adds support for the Skype IM network.
+#  You need to download and install the Skype client for this to work.
 
-Package: skyped
-Architecture: all
-Depends: ${misc:Depends}, ${shlibs:Depends}, python (>= 2.5), python-gnutls, python-skype (>=0.9.28.7)
-Recommends: skype
-Description: Daemon to control Skype remotely
- Daemon to control the GUI Skype client. Currently required to control Skype
- from the BitlBee IRC2IM gateway. Skyped and Skype can run on a different
- host than the BitlBee server, the communication is encrypted.
- .
- You need to download and install the Skype client for this to work.
+# Package: skyped
+# Architecture: all
+# Depends: ${misc:Depends}, ${shlibs:Depends}, python (>= 2.5), python-gnutls, python-skype (>=0.9.28.7)
+# Recommends: skype
+# Description: Daemon to control Skype remotely
+#  Daemon to control the GUI Skype client. Currently required to control Skype
+#  from the BitlBee IRC2IM gateway. Skyped and Skype can run on a different
+#  host than the BitlBee server, the communication is encrypted.
+#  .
+#  You need to download and install the Skype client for this to work.


signature.asc
Description: PGP signature

Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)

[Santiago Vila]

Package: src:win-iconv
Version: 0.0.8-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build-indep
make[1]: Entering directory '/<>'
for arch in x86_64-w64-mingw32 i686-w64-mingw32; do \
 mkdir -p build-$arch && \
 cd build-$arch && \
  ln -s ../*.h ../*.c ../*.def ../Makefile ./ && \
  /usr/bin/make CC=$arch-gcc AR=$arch-ar RANLIB=$arch-ranlib 
DLLTOOL=$arch-dlltool prefix=/usr/$arch \
  || exit 1 ; \
  cd .. ; \
done
make[2]: Entering directory '/<>/build-x86_64-w64-mingw32'
x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
-DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c -DMAKE_DLL
x86_64-w64-mingw32-gcc -shared -o iconv.dll -Wl,-s 
-Wl,--out-implib=libiconv.dll.a -Wl,--export-all-symbols win_iconv.o 
x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
-DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c
x86_64-w64-mingw32-ar rcs libiconv.a win_iconv.o
x86_64-w64-mingw32-ranlib libiconv.a
x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
-DDEFAULT_LIBICONV_DLL=\"\" -s -o win_iconv.exe win_iconv.c -DMAKE_EXE
make[2]: Leaving directory '/<>/build-x86_64-w64-mingw32'
make[2]: Entering directory '/<>/build-i686-w64-mingw32'
i686-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
-DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c -DMAKE_DLL
i686-w64-mingw32-gcc -shared -o iconv.dll -Wl,-s 
-Wl,--out-implib=libiconv.dll.a -Wl,--export-all-symbols win_iconv.o 
i686-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
-DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c
i686-w64-mingw32-ar rcs libiconv.a win_iconv.o
i686-w64-mingw32-ranlib libiconv.a
i686-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
-DDEFAULT_LIBICONV_DLL=\"\" -s -o win_iconv.exe win_iconv.c -DMAKE_EXE
make[2]: Leaving directory '/<>/build-i686-w64-mingw32'
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
cd build-x86_64-w64-mingw32 && 
WINEPREFIX=/<>/build-x86_64-w64-mingw32/.wine /usr/bin/make 
CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar 
RANLIB=x86_64-w64-mingw32-ranlib DLLTOOL=x86_64-w64-mingw32-dlltool test
make[2]: Entering directory '/<>/build-x86_64-w64-mingw32'
x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL 
-DDEFAULT_LIBICONV_DLL=\"\" -s -o win_iconv_test.exe win_iconv_test.c
wine ./win_iconv_test.exe
it looks like wine32 is missing, you should install it.
multiarch needs to be enabled first.  as root, please
execute "dpkg --add-architecture i386 && apt-get update &&
apt-get install wine32"
wine: created the configuration directory 
'/<>/build-x86_64-w64-mingw32/.wine'
wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory
make[2]: *** [Makefile:51: test] Error 1
make[2]: Leaving directory '/<>/build-x86_64-w64-mingw32'
make[1]: *** [debian/rules:40: override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:19: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2
E: Build killed with signal TERM after 60 minutes of inactivity


(Additionally, the autobuilder hangs and sbuild has to kill remaining processes)

The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/win-iconv.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#921902: sdb: FTBFS (error CS1617: Invalid -langversion option `future')

[Santiago Vila]

Package: src:sdb
Version: 1.2-1.1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh --with cli build-indep 
dh: Compatibility levels before 9 are deprecated (level 7 in use)
   dh_update_autotools_config -i
   dh_auto_configure -i
dh_auto_configure: Compatibility levels before 9 are deprecated (level 7 in use)
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
mkdir -p dep/
dh_auto_build
dh_auto_build: Compatibility levels before 9 are deprecated (level 7 in use)
make -j1
make[2]: Entering directory '/<>'
mkdir -p bin
cp LICENSE bin/LICENSE
mkdir -p bin
cp README.md bin/README
cp `pkg-config --variable=Sources mono-options` dep/Options.cs
cp `pkg-config --variable=Sources mono-lineeditor` dep/getline.cs
mkdir -p bin
cp `pkg-config --variable=Libraries mono-cecil` bin/
cp `pkg-config --variable=Libraries mono-debugger` bin/
mcs -debug -langversion:future -unsafe -warnaserror -keyfile:mono.snk -lib:bin 
-out:bin/sdb.exe -target:exe -r:Mono.Posix -r:Mono.Cecil.dll 
-r:Mono.Cecil.Mdb.dll -r:Mono.Debugger.Soft.dll -r:Mono.Debugging.dll 
-r:Mono.Debugging.Soft.dll -pkg:nrefactory dep/Options.cs dep/getline.cs 
src/Commands/AttachCommand.cs src/Commands/BacktraceCommand.cs 
src/Commands/BreakpointCommand.cs src/Commands/CatchpointCommand.cs 
src/Commands/ConfigCommand.cs src/Commands/ConnectCommand.cs 
src/Commands/ContinueCommand.cs src/Commands/DatabaseCommand.cs 
src/Commands/DecompileCommand.cs src/Commands/DirectoryCommand.cs 
src/Commands/DisassembleCommand.cs src/Commands/EnvironmentCommand.cs 
src/Commands/FrameCommand.cs src/Commands/HelpCommand.cs 
src/Commands/KillCommand.cs src/Commands/ListenCommand.cs 
src/Commands/PluginCommand.cs src/Commands/PrintCommand.cs 
src/Commands/QuitCommand.cs src/Commands/ResetCommand.cs 
src/Commands/RootCommand.cs src/Commands/RunCommand.cs 
src/Commands/SourceCommand.cs src/Com
 mands/StepCommand.cs src/Commands/ThreadCommand.cs 
src/Commands/WatchCommand.cs src/AssemblyInfo.cs src/Color.cs src/Command.cs 
src/CommandAttribute.cs src/CommandLine.cs src/Configuration.cs 
src/CustomLogger.cs src/Debugger.cs src/LibEdit.cs src/Log.cs 
src/MultiCommand.cs src/Plugins.cs src/Program.cs src/SessionKind.cs 
src/State.cs src/Utilities.cs
error CS1617: Invalid -langversion option `future'. It must be `ISO-1', 
`ISO-2', Default, Latest or value in range 1 to 7.2
make[2]: *** [Makefile:187: bin/sdb.exe] Error 1
make[2]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
make[1]: *** [debian/rules:9: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:16: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sdb.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#921898: pilkit: FTBFS (AssertionError: '.apng' != '.png')

[Santiago Vila]

Package: src:pilkit
Version: 2.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3 --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
cp debian/reference.png tests/assets/reference.png
dh_auto_build
I: pybuild base:217: /usr/bin/python setup.py build 
running build

[... snipped ...]

tests.test_processors.test_smartcrop ... ok
tests.test_processors.test_resizetofill ... ok
tests.test_processors.test_resizetofit ... ok
Regression test for matthewwithanm/pilkit#1 ... ok
tests.test_processors.test_resizetofit_mat ... ok
Test that the ColorOverlay processor ... ok
Test that the Resize processor antialiases. ... ok
Test that the upscale argument works as expected. ... ok
tests.test_processors.test_should_raise_exception_if_anchor_is_passed_and_crop_is_set_to_false
 ... ok
tests.test_processors.test_should_set_crop_to_true_if_anchor_is_passed_without_crop
 ... ok
tests.test_processors.test_should_raise_exception_when_crop_is_passed_without_height_and_width
 ... ok
tests.test_processors.test_make_gifs_opaque ... ok
tests.test_processors.test_should_call_resizetofill_when_crop_and_ancho_is_passed
 ... ok
tests.test_processors.test_should_call_resizetofit_when_crop_is_not_passed ... 
ok
tests.test_processors.test_should_call_smartresize_when_crop_not_passed ... ok
tests.test_processors.test_should_repass_upscale_option_false ... ok
tests.test_processors.test_should_repass_upscale_option_true ... ok
tests.test_utils.test_extension_to_format ... ok
tests.test_utils.test_format_to_extension_no_init ... FAIL
tests.test_utils.test_unknown_format ... ok
tests.test_utils.test_unknown_extension ... ok
Ensure default extensions are honored. ... ok
tests.test_utils.test_filewrapper ... ok
Test that ``save_image`` accepts filename strings (not just file objects). ... 
ok
Make sure formats are normalized by ``prepare_image()``. ... ok
Make sure the ``quiet`` util doesn't error if devnull is unwriteable. ... ok

==
FAIL: tests.test_utils.test_format_to_extension_no_init
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/<>/.pybuild/cpython2_2.7_pilkit/build/tests/test_utils.py", line 
19, in test_format_to_extension_no_init
eq_(format_to_extension('PNG'), '.png')
AssertionError: '.apng' != '.png'

--
Ran 26 tests in 0.205s

FAILED (failures=1)
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython2_2.7_pilkit/build; python2.7 -m nose -v tests
dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7 returned 
exit code 13
make: *** [debian/rules:9: build-indep] Error 25
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pilkit.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#921896: json-js: FTBFS (ERROR: `cycle.min.map` is not a supported option)

[Santiago Vila]

Package: src:json-js
Version: 0~20160510-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
test -x debian/rules
mkdir -p "."

Scanning upstream source for new/changed copyright notices...

set -e; LC_ALL=C.UTF-8 /usr/bin/licensecheck --check '.*' --recursive 
--copyright --deb-fmt --ignore 
'^(debian/(changelog|copyright(|_hints|_newhints)))$' --lines 0 * | 
/usr/lib/cdbs/licensecheck2dep5 > debian/copyright_newhints
2 combinations of copyright and licensing found.
WARNING:New or changed notices discovered:

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

To fix the situation please do the following:
  1) Examine debian/copyright_* and referenced files
  2) Update debian/copyright as needed
  3) Replace debian/copyright_hints with debian/copyright_newhints
touch debian/stamp-copyright-check
touch debian/stamp-upstream-cruft
uglifyjs --source-map cycle.min.map -o cycle.min.js cycle.js
Supported options:
  content null
  filenamenull
  includeSources  false
  rootnull
  url null
ERROR: `cycle.min.map` is not a supported option
at DefaultsError.get (eval at  
(/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :71:23)
at fatal (/usr/lib/nodejs/uglify-js/bin/uglifyjs:291:53)
at run (/usr/lib/nodejs/uglify-js/bin/uglifyjs:235:9)
at Object. (/usr/lib/nodejs/uglify-js/bin/uglifyjs:160:5)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Function.Module.runMain (module.js:693:10)
make: *** [debian/rules:36: cycle.min.js] Error 1
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/json-js.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#921903: sorl-thumbnail: FTBFS (failing tests)

[Santiago Vila]

Package: src:sorl-thumbnail
Version: 12.3+git20170708-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/sorl-thumbnail-12.3+git20170708'
dh_auto_build
I: pybuild base:217: /usr/bin/python setup.py build 
running build

[... snipped ...]

  Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
apifun(*marker.args, **marker.kwargs)
  /usr/lib/python2.7/dist-packages/pytest_django/plugin.py:630: 
RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged 
marks which are hard to deal with correctly.
  Please use node.get_closest_marker(name) or node.iter_markers(name).
  Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
apifun(*marker.args, **marker.kwargs)

tests/thumbnail_tests/test_templatetags.py::TemplateTestCaseB::test_portrait
  /usr/lib/python2.7/dist-packages/pytest_django/plugin.py:630: 
RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged 
marks which are hard to deal with correctly.
  Please use node.get_closest_marker(name) or node.iter_markers(name).
  Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
apifun(*marker.args, **marker.kwargs)
  /usr/lib/python2.7/dist-packages/pytest_django/plugin.py:630: 
RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged 
marks which are hard to deal with correctly.
  Please use node.get_closest_marker(name) or node.iter_markers(name).
  Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
apifun(*marker.args, **marker.kwargs)

tests/thumbnail_tests/test_templatetags.py::TemplateTestCaseB::test_url
  /usr/lib/python2.7/dist-packages/pytest_django/plugin.py:630: 
RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged 
marks which are hard to deal with correctly.
  Please use node.get_closest_marker(name) or node.iter_markers(name).
  Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
apifun(*marker.args, **marker.kwargs)
  /usr/lib/python2.7/dist-packages/pytest_django/plugin.py:630: 
RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged 
marks which are hard to deal with correctly.
  Please use node.get_closest_marker(name) or node.iter_markers(name).
  Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
apifun(*marker.args, **marker.kwargs)

tests/thumbnail_tests/test_templatetags.py::TemplateTestCaseClient::test_empty_error
  /usr/lib/python2.7/dist-packages/pytest_django/plugin.py:630: 
RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged 
marks which are hard to deal with correctly.
  Please use node.get_closest_marker(name) or node.iter_markers(name).
  Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
apifun(*marker.args, **marker.kwargs)
  /usr/lib/python2.7/dist-packages/pytest_django/plugin.py:630: 
RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged 
marks which are hard to deal with correctly.
  Please use node.get_closest_marker(name) or node.iter_markers(name).
  Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
apifun(*marker.args, **marker.kwargs)
  /usr/lib/python2.7/dist-packages/django/core/handlers/base.py:52: 
RemovedInDjango20Warning: Old-style middleware using 
settings.MIDDLEWARE_CLASSES is deprecated. Update your middleware and use 
settings.MIDDLEWARE instead.
"instead.", RemovedInDjango20Warning

-- Docs: https://docs.pytest.org/en/latest/warnings.html
= 1 failed, 59 passed, 8 skipped, 125 warnings in 9.80 seconds =
make[1]: *** [debian/rules:24: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>/sorl-thumbnail-12.3+git20170708'
make: *** [debian/rules:10: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sorl-thumbnail.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#921899: rt-extension-calendar: FTBFS (mv: cannot stat 'Makefile': No such file or directory)

[Santiago Vila]

Package: src:rt-extension-calendar
Version: 1.01-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
rm -rf inc/Module
for ver in 4; do \
 perl Makefile.PL RTHOME=/usr/share/request-tracker$ver INSTALLDIRS=vendor; \
 mv Makefile Makefile$ver; \
done
Cannot determine perl version info from lib/RTx/Calendar.pm
Can't locate Capture/Tiny.pm in @INC (you may need to install the Capture::Tiny 
module) (@INC contains: inc /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 
/usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at 
/usr/share/perl5/Module/Install/ReadmeFromPod.pm line 40.
include /<>/inc/Module/Install.pm
include inc/Module/Install/RTx.pm
include inc/Module/Install/Base.pm
include inc/Module/Install/Metadata.pm
include inc/Module/Install/Makefile.pm
include inc/Module/Install/ReadmeFromPod.pm
mv: cannot stat 'Makefile': No such file or directory
make[1]: *** [debian/rules:10: override_dh_auto_configure] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rt-extension-calendar.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#921897: morse-simulator: FTBFS (Could not import extension sphinx.ext.pngmath)

[Santiago Vila]

Package: src:morse-simulator
Version: 1.4-4
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python3
   dh_update_autotools_config -i
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DBUILD_DOC_SUPPORT=ON 
-DPYTHON_EXECUTABLE=/usr/bin/python3 \
 -DCPACK_DEBIAN_PACKAGE_DEPENDS=python3-all-dev -DPYMORSE_SUPPORT=ON
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DBUILD_DOC_SUPPORT=ON -DPYTHON_EXECUTABLE=/usr/bin/python3 
-DCPACK_DEBIAN_PACKAGE_DEPENDS=python3-all-dev -DPYMORSE_SUPPORT=ON ..
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done

[... snipped ...]

CMake Warning:
  Manually-specified variables were not used by the project:

CMAKE_EXPORT_NO_PACKAGE_REGISTRY
CMAKE_INSTALL_LIBDIR
CMAKE_INSTALL_LOCALSTATEDIR
CMAKE_INSTALL_SYSCONFDIR
CPACK_DEBIAN_PACKAGE_DEPENDS


-- Build files have been written to: /<>/obj-x86_64-linux-gnu
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
cp version.py obj-*/
dh_auto_build
cd obj-x86_64-linux-gnu && make -j1
make[2]: Entering directory '/<>/obj-x86_64-linux-gnu'
/usr/bin/cmake -S/<> -B/<>/obj-x86_64-linux-gnu 
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start 
/<>/obj-x86_64-linux-gnu/CMakeFiles 
/<>/obj-x86_64-linux-gnu/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
make -f CMakeFiles/man.dir/build.make CMakeFiles/man.dir/depend
make[4]: Entering directory '/<>/obj-x86_64-linux-gnu'
cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends 
"Unix Makefiles" /<> /<> 
/<>/obj-x86_64-linux-gnu /<>/obj-x86_64-linux-gnu 
/<>/obj-x86_64-linux-gnu/CMakeFiles/man.dir/DependInfo.cmake 
--color=
Scanning dependencies of target man
make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make -f CMakeFiles/man.dir/build.make CMakeFiles/man.dir/build
make[4]: Entering directory '/<>/obj-x86_64-linux-gnu'
env 
PYTHONPATH=/<>/obj-x86_64-linux-gnu:/<>/obj-x86_64-linux-gnu/src:/<>/obj-x86_64-linux-gnu/fakeenv:/<>/src:/<>/testing:/<>/bindings/pymorse/src/:$PYTHONPATH
 PYTHONDONTWRITEBYTECODE="morse" MORSESOURCE=/<> /usr/bin/python3 
/usr/bin/sphinx-build -b man -c /<>/obj-x86_64-linux-gnu/doc 
/<>/doc/man /<>/obj-x86_64-linux-gnu/doc/man && 
/bin/gzip -f /<>/obj-x86_64-linux-gnu/doc/man/*.1
Running Sphinx v1.8.3

Extension error:
Could not import extension sphinx.ext.pngmath (exception: No module named 
'sphinx.ext.pngmath')
make[4]: *** [CMakeFiles/man.dir/build.make:60: CMakeFiles/man] Error 2
make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[3]: *** [CMakeFiles/Makefile2:140: CMakeFiles/man.dir/all] Error 2
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [Makefile:144: all] Error 2
make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
dh_auto_build: cd obj-x86_64-linux-gnu && make -j1 returned exit code 2
make[1]: *** [debian/rules:27: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/morse-simulator.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#921900: rt-extension-smsnotify: FTBFS (dh_auto_configure fails)

[Santiago Vila]

Package: src:rt-extension-smsnotify
Version: 1.04-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   dh_auto_configure -i
perl -I. Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"LD=x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
Can't locate Capture/Tiny.pm in @INC (you may need to install the Capture::Tiny 
module) (@INC contains: inc . /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 
/usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at 
/usr/share/perl5/Module/Install/ReadmeFromPod.pm line 40.
include /<>/inc/Module/Install.pm
include inc/Module/Install/RTx.pm
include inc/Module/Install/Base.pm
include inc/Module/Install/Metadata.pm
include inc/Module/Install/Makefile.pm
include inc/Module/Install/ReadmeFromPod.pm
dh_auto_configure: perl -I. Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"LD=x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" 
returned exit code 2
make: *** [debian/rules:6: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rt-extension-smsnotify.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#921901: ruby-voight-kampff: FTBFS (expected: < 0.002, got: 0.002076509001199156)

[Santiago Vila]

Package: src:ruby-voight-kampff
Version: 1.1.3-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=ruby --with ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   dh_auto_build -i -O--buildsystem=ruby
dh_ruby --build
   dh_ruby --build
   dh_auto_test -i -O--buildsystem=ruby
dh_ruby --test
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=ruby --with ruby
   dh_testroot -i -O--buildsystem=ruby
   dh_prep -i -O--buildsystem=ruby

[... snipped ...]

│ Install Rubygems integration metadata   
 │
└──────────────────────────────────────────────────────────────────────────────┘

generating gemspec at 
/<>/debian/ruby-voight-kampff/usr/share/rubygems-integration/all/specifications/voight_kampff-1.1.3.gemspec
/usr/bin/ruby2.5 /usr/bin/gem2deb-test-runner

┌──────────────────────────────────────────────────────────────────────────────┐
│ Checking Rubygems dependency resolution on ruby2.5  
 │
└──────────────────────────────────────────────────────────────────────────────┘

GEM_PATH=debian/ruby-voight-kampff/usr/share/rubygems-integration/all:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all
 ruby2.5 -e gem\ \"voight_kampff\"

┌──────────────────────────────────────────────────────────────────────────────┐
│ Run tests for ruby2.5 from debian/ruby-tests.rake   
 │
└──────────────────────────────────────────────────────────────────────────────┘

RUBYLIB=/<>/debian/ruby-voight-kampff/usr/lib/ruby/vendor_ruby:. 
GEM_PATH=debian/ruby-voight-kampff/usr/share/rubygems-integration/all:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all
 ruby2.5 -S rake -f debian/ruby-tests.rake
rspec
.F..

Failures:

  1) VoightKampff::Test after the first run is fast
 Failure/Error: expect(Benchmark.realtime { 20.times { 
VoightKampff::Test.new('anything').bot? } }).to be < 0.002

   expected: < 0.002
got:   0.002076509001199156
 # ./spec/lib/voight_kampff/test_spec.rb:33:in `block (3 levels) in '

Finished in 0.27072 seconds (files took 3.02 seconds to load)
44 examples, 1 failure

Failed examples:

rspec ./spec/lib/voight_kampff/test_spec.rb:32 # VoightKampff::Test after the 
first run is fast

rake aborted!
Command failed with status (1): [rspec...]
/<>/debian/ruby-tests.rake:4:in `block in '
Tasks: TOP => default
(See full trace by running task with --trace)
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-voight-kampff 
returned exit code 1
make: *** [debian/rules:6: binary-indep] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-voight-kampff.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#921895: bitlbee: does not build all binary packages by default

[Sean Whitton]

Source: bitlbee
Version: 3.5.1-1
Severity: serious

Hello,

This source package's rules file does not build all the binary packages
listed in d/control unless special environment variable values are
present.  As a result, bin:skyped and bin:bitlbee-plugin-skype are not
in the archive.

This caused my source-only NMU of this package to be rejected, because
dak wanted to put it in binNEW because of skyped and
bitlbee-plugin-skype, but source-only uploads to binNEW are not allowed.

I think this is a bug of RC-severity because it is a highly irregular
use of the Debian source package format which is confusing to people
trying to do NMUs.  Perhaps the maintainer will disagree; a downgrade
of the severity of this bug would make sense if it turns out I'm not
aware of some workflow that not building all the binary packages by
default enables.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#919585: RM: node-groove/2.5.0-4 -- RoM; FTBFS; orphaned; abandoned upstream

[Jérémy Lal]

Le dim. 10 févr. 2019 à 00:14, Adam D. Barratt  a
écrit :

> Control: tags -1 + moreinfo
>
> On Thu, 2019-01-17 at 16:26 +0100, Jérémy Lal wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: rm
> >
> > Note that groovebasin is already removed from testing.
>
> So where are/were you requesting removal from?
>

The idea was to remove node-groove from testing and the only software
using it was groovebasin, which was already removed.
Maybe even from unstable since the situation for that software is not going
to improve.
And the message i wrote wasn't explicit enough, sorry about that.

Jérémy

Bug#916639: LXC AppArmor confinement breaks systemd v240

[Pierre-Elliott Bécue]

Le dimanche 27 janvier 2019 à 19:47:59+0100, intrigeri a écrit :
> Hi,
> 
> Pierre-Elliott Bécue:
> > We have to decide what solution I will implement.
> 
> Right, thanks for following up.
> 
> > I'm open to suggestions, although I'm considering the "disable
> > apparmor profiles for lxc" solution for now.
> 
> I think that disabling AppArmor by default for new LXC containers for
> Buster would be an OK-ish fallback option, if nothing else can
> realistically be made to work in time for the freeze; that would be
> sad, but it would not be a regression vs. Stretch. I assume we are on
> the same page regarding this: by all means, let's not ship a known
> broken LXC + AppArmor default configuration in Buster :)
> 
> Apart of this fallback, I can propose two options:
> 
> A) Add a blanket "mount," rule to the base AppArmor policy used by all
>profiles used for individual containers.
> 
>Pros: I guess that it's the cheapest possible way to have *some*
>working AppArmor policy enabled by default.
> 
>Cons:
> 
>  - This diverges from upstream quite a bit, and more importantly,
>in a non-obvious way, so users coming from other distros may be
>assuming a stricter default policy.
> 
>  - It's non-trivial for users to opt in for a stricter
>AppArmor policy.
> 
> B) Apply the patches I've backported and proposed,
>and make these settings the default:
> 
>  lxc.apparmor.profile = generated
>  lxc.apparmor.allow_nesting = 1
> 
>… which effectively adds the same blanket "mount," rule
>by default.
> 
>Pros:
> 
>  - The user has more flexibility wrt. how strictly they want this
>or that container to be confined by AppArmor.
> 
>  - Nicer UX: most users of LXC in Debian will be exposed to LXC
>being confined with AppArmor for the first time in Buster.
>It's nicer to give them means to configure it that are here to
>stay, i.e. that are the future of the LXC/LXD ecosystem,
>compared letting them learn the LXC 3.0.x way only to have to
>learn again once they upgrade to a newer LXC or to Bullseye.
> 
>  - Easier to document: it's easier to explain what the default
>value of these settings is on Debian, than to explain "we added
>a blanket 'mount' rule" to users who are not familiar
>with AppArmor.
> 
>Cons:
> 
>  - Bigger delta vs. upstream 3.0.x branch. I realize this has
>a maintenance cost and I guess that's why the maintainers have
>not applied the proposed patches yet.
> 
>  - This new code has been tested very minimally on LXC 3.0.x.
>It works well enough to make the systemd autopkgtests pass, it
>comes from LXD, it's has been in upstream's 3.1 branch for
>6 months, but still: there's a certain amount of
>uncertainty here.
> 
> Either way, we don't enable mount mediation at all by default, because
> as Wolfgang wrote, "the policy changes won't be enough for long".
> So the resulting AppArmor policy is quite weak, but as long as users'
> expectations are set adequately, it's definitely not worse than what
> we have in Stretch nor than the fallback option.
> 
> Personally, I'm leaning towards option (B), which is why I bothered
> backporting the patches mid-December, after upstream suggested this
> was the way to go. But time has flown since then, and I would
> understand if the maintainers don't feel comfortable with this option
> so close to the freeze. I can live with option (A) too, and worst
> case, well, with the fallback option if that's how it is.

Hey,

I feel comfortable with B, but as far as I understood, there was some
code needing to be backported not in your patches.

Do you think we could take care of it or should I just include your
patches as it?

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#919585: RM: node-groove/2.5.0-4 -- RoM; FTBFS; orphaned; abandoned upstream

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2019-01-17 at 16:26 +0100, Jérémy Lal wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> Note that groovebasin is already removed from testing.

So where are/were you requesting removal from?

Regards,

Adam

Bug#921667: [pkg-lxc-devel] Bug#921667: lxc, lava-dev: lxc fails to install along lava-dev --install-recommends

[Pierre-Elliott Bécue]

Le samedi 09 février 2019 à 22:19:13+0100, Andreas Beckmann a écrit :
> On 2019-02-09 21:51, Pierre-Elliott Bécue wrote:
> > I'm not sure that there is something we can do regarding lxc. Am I
> > wrong?
> 
> You could try to figure out why lxc explodes.
> Probably some package places some configuration file at some location
> 
> 
> Andreas
> 
> PS: I should be able to get a shell in the chroot after the failure
> occurred, in case you want me to collect some information.

That's a good idea. This error is not clear at all to me.

Could you please try to run the .postinst of lxc manually with a set -x?
The goal would be to check which part explodes.

Best,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#919442: python-dmidecode-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Sandro Tosi]

On Thu, Feb 7, 2019 at 11:24 AM Andreas Beckmann  wrote:
>
> Followup-For: Bug #919442
> Control: affects -1 + python3-dmidecode-dbg
> Control: found -1 3.12.2-7
>
> Hi,
>
> your .maintscript files are wrong. Obviously you wanted symlink_to_dir,
> but you used dir_to_symlink.

mh not really, i want /usr/share/doc/python-dmidecode-dbg/ to be a
symlink to /usr/share/doc/python-dmidecode/ (and the same for the py3k
packages) - isnt symlink_to_dir the right helper to use in that case?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#919442: python-dmidecode-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Sandro Tosi]

On Sat, Feb 9, 2019 at 6:04 PM Sandro Tosi  wrote:
>
> On Thu, Feb 7, 2019 at 11:24 AM Andreas Beckmann  wrote:
> >
> > Followup-For: Bug #919442
> > Control: affects -1 + python3-dmidecode-dbg
> > Control: found -1 3.12.2-7
> >
> > Hi,
> >
> > your .maintscript files are wrong. Obviously you wanted symlink_to_dir,
> > but you used dir_to_symlink.
>
> mh not really, i want /usr/share/doc/python-dmidecode-dbg/ to be a
> symlink to /usr/share/doc/python-dmidecode/ (and the same for the py3k
> packages) - isnt symlink_to_dir the right helper to use in that case?

what i meant to say is "isnt dir_to_symlink the right helper to use in
that case?" (so from dir to symlink)





-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#921893: stretch-pu: package supercollider/3.7.0~repack-4+deb9u1

[Andreas Beckmann]

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

supercollider fails to install with xemacs21, #916858
This is a backport (only changes to the changelog were needed)
of the commit from sid that disabled support for xemacs and other old
emacs <= 23. The diff looks a bit bigger due to the reindenting, but
diff -w showed that nothing actually changed in the reindented code.


Andreas
diff -Nru supercollider-3.7.0~repack/debian/changelog 
supercollider-3.7.0~repack/debian/changelog
--- supercollider-3.7.0~repack/debian/changelog 2016-11-17 00:27:41.0 
+0100
+++ supercollider-3.7.0~repack/debian/changelog 2019-02-09 22:39:14.0 
+0100
@@ -1,3 +1,16 @@
+supercollider (1:3.7.0~repack-4+deb9u1) stretch; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+  * Backport disabling support for XEmacs etc. from 1:3.10.0+repack-0.1.
+
+  [ Georges Khaznadar ]
+  * modified emacsen configuration files to fit the patterns found
+with ELPA. This prevents the installation with xemacs and emacs <= 23.
+Closes: #916858
+
+ -- Andreas Beckmann   Sat, 09 Feb 2019 22:39:14 +0100
+
 supercollider (1:3.7.0~repack-4) unstable; urgency=medium
 
   [ Dan Stowell ]
diff -Nru supercollider-3.7.0~repack/debian/gbp.conf 
supercollider-3.7.0~repack/debian/gbp.conf
--- supercollider-3.7.0~repack/debian/gbp.conf  2016-11-17 00:27:41.0 
+0100
+++ supercollider-3.7.0~repack/debian/gbp.conf  2019-02-09 22:39:14.0 
+0100
@@ -1,3 +1,4 @@
 [DEFAULT]
 pristine-tar = True
 sign-tags = True
+debian-branch = stretch
diff -Nru supercollider-3.7.0~repack/debian/supercollider-emacs.emacsen-install 
supercollider-3.7.0~repack/debian/supercollider-emacs.emacsen-install
--- supercollider-3.7.0~repack/debian/supercollider-emacs.emacsen-install   
2016-11-17 00:27:41.0 +0100
+++ supercollider-3.7.0~repack/debian/supercollider-emacs.emacsen-install   
2019-02-09 22:39:14.0 +0100
@@ -8,38 +8,51 @@
 FLAVOR=$1
 PACKAGE=SuperCollider
 
-if [ ${FLAVOR} = emacs ]; then exit 0; fi
+case $FLAVOR in
+emacs)
+exit 0
+;;
+emacs2[0123]*)
+echo install/${PACKAGE}: Skipping obsolete emacs ${FLAVOR}
+exit 0
+;;
+xemacs*)
+echo install/${PACKAGE}: Skipping unsupported emacs ${FLAVOR}
+exit 0
+;;
+*)
+echo install/${PACKAGE}: Handling install of emacsen flavor ${FLAVOR}
+   
+   #FLAVORTEST=`echo $FLAVOR | cut -c-6`
+   #if [ ${FLAVORTEST} = xemacs ] ; then
+   #SITEFLAG="-no-site-file"
+   #else
+   #SITEFLAG="--no-site-file"
+   #fi
+   FLAGS="${SITEFLAG} -q -batch -l path.el -f batch-byte-compile"
+
+   ELDIR=/usr/share/emacs/site-lisp/${PACKAGE}
+   ELCDIR=/usr/share/${FLAVOR}/site-lisp/${PACKAGE}
+
+   # Install-info-altdir does not actually exist. 
+   # Maybe somebody will write it.
+   if test -x /usr/sbin/install-info-altdir; then
+   echo install/${PACKAGE}: install Info links for ${FLAVOR}
+   install-info-altdir --quiet --section "" "" --dirname=${FLAVOR} 
/usr/share/info/${PACKAGE}.info.gz
+   fi
+
+   install -m 755 -d ${ELCDIR}
+   cd ${ELDIR}
+   FILES=`echo *.el`
+   cp ${FILES} ${ELCDIR}
+   cd ${ELCDIR}
 
-echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
-
-#FLAVORTEST=`echo $FLAVOR | cut -c-6`
-#if [ ${FLAVORTEST} = xemacs ] ; then
-#SITEFLAG="-no-site-file"
-#else
-#SITEFLAG="--no-site-file"
-#fi
-FLAGS="${SITEFLAG} -q -batch -l path.el -f batch-byte-compile"
-
-ELDIR=/usr/share/emacs/site-lisp/${PACKAGE}
-ELCDIR=/usr/share/${FLAVOR}/site-lisp/${PACKAGE}
-
-# Install-info-altdir does not actually exist. 
-# Maybe somebody will write it.
-if test -x /usr/sbin/install-info-altdir; then
-echo install/${PACKAGE}: install Info links for ${FLAVOR}
-install-info-altdir --quiet --section "" "" --dirname=${FLAVOR} 
/usr/share/info/${PACKAGE}.info.gz
-fi
-
-install -m 755 -d ${ELCDIR}
-cd ${ELDIR}
-FILES=`echo *.el`
-cp ${FILES} ${ELCDIR}
-cd ${ELCDIR}
-
-cat << EOF > path.el
+   cat << EOF > path.el
 (setq load-path (cons "." load-path) byte-compile-warnings nil)
 EOF
-${FLAVOR} ${FLAGS} ${FILES}
-rm -f *.el path.el
+   ${FLAVOR} ${FLAGS} ${FILES}
+   rm -f *.el path.el
+
+   exit 0
+esac
 
-exit 0
diff -Nru supercollider-3.7.0~repack/debian/supercollider-emacs.emacsen-remove 
supercollider-3.7.0~repack/debian/supercollider-emacs.emacsen-remove
--- supercollider-3.7.0~repack/debian/supercollider-emacs.emacsen-remove
2016-11-17 00:27:41.0 +0100
+++ supercollider-3.7.0~repack/debian/supercollider-emacs.emacsen-remove
2019-02-09 22:39:14.0 +0100
@@ -4,12 +4,25 @@
 FLAVOR=$1
 PACKAGE=SuperCollider
 
-if [ ${FLAVOR} != emacs ]; then
-if test -x /usr/sbin/install-info-altdir; then
-echo remove/${PACKAGE}: removing Info links for ${FLAVOR}
-   

Bug#749019: Bug#881811:

[Teemu Toivola]

On Sat, 9 Feb 2019 20:40:56 +
nodiscc  wrote:

> We had a discussion on IRC on how to best fix this. At first there was an
> attempt to use DaemonUser "vnstat" DaemonGroup "vnstat" and removing
> User=vnstat from the systemd unit file. But even then you have to systemctl
> restart vnstat for it to fix the db file permissions. So also manual.

For the 1.x versions, the intent was that using DaemonUser "vnstat" +
DaemonGroup "vnstat" and letting vnstatd start as root would fix the issue
as the daemon would correct possible file and directory permissions issues
by itself before switching to run as the configured user and group. There
would anyway need to be another command executed after "vnstat -u -i foo"
as the daemon doesn't automatically scan for new databases. The only thing
that it does is that it tracks those files that were present during startup
and if any gets removed then tracking of that interface is stopped.

However, things change a little bit once the Debian package gets updated to
include some 2.x version. As a result, there will be only one database file
no matter how many interfaces are being tracked. That way, adding new
interfaces for tracking even with the wrong user will not result in file
permission issues with the database file. The '-u' parameter has been
replaced with '--add' in order to remove the previous double role of '-u' /
'--update'. This obviously also has the side effect of making some really
old instructions for using vnstat partially invalid.

> I think a good and simple fix is to install the /var/lib/vnstat/ directory
> with sgid bit set. That way any file created there would have correct
> permissions.

See above. An upgrade to a 2.x version should solve the issue without
requiring sgid bit being set among other corrections and improvements as
documented in the CHANGES [1] file.

[1] https://humdi.net/vnstat/CHANGES

-- 
- Teemu Toivola

Bug#881424: RFP: ausweisapp2 -- online authentication using German identity document

[Hilmar Preuße]

On 11.11.17 16:41, W. Martin Borgert wrote:

> Package: wnpp
> Severity: wishlist
> Owner: "W. Martin Borgert" 
> 
> * Package name: ausweisapp2
>   Version : 1.12.4
>   Upstream Author : Governikus GmbH & Co. KG
> * URL : https://github.com/Governikus/AusweisApp2
> * License : EUPL-1.2
>   Programming Lang: C++
>   Description : online authentication using German identity document
> 
> This application is needed to authenticate e.g. at online services using
> a German identity document.
> 
https://www.glasen-hardt.de/2019/01/01/ausweisapp2-als-snap/

Seems to have been successful in compiling an running the App. Does this
help you?

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



signature.asc
Description: OpenPGP digital signature

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Francesco Poli]

On Sat, 9 Feb 2019 22:31:14 +0100 Michael Biebl wrote:

> Hi
> 
> Am 09.02.19 um 10:39 schrieb Francesco Poli:
> 
> > Could you please do me a favor?
> > I would like you to read bug [#916753] log and then tell me what you
> > think. Your insight might be useful to find a better solution.
> 
> What kind of input do you need?

I would like some insight especially on [message #30], regarding the
fact that runuser does something basically equivalent to what su does,
and thus seems to be unfit to irreversibly drop root privileges, and
regarding my search for a command that works like s6-setuidgid, but
runs the given command inside the user's login shell (with all the
environment that the user would get on a normal login).

[message #30]: 

> I guess I already mentioned the two alternatives (runuser/setpriv).
[...]

Maybe setpriv is equivalent to s6-setuidgid.
If this is the case, it can be used as an alternative to s6-setuidgid.

But I would like to have a command that runs a given command inside the
regular user's login environment, as I said above.
Do you know one such command?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpZOMog3Kfx0.pgp
Description: PGP signature

Bug#921892: libtommath: fails to clean after build

[Andreas Beckmann]

Source: libtommath
Version: 1.1.0-3~exp1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

libtommath/experimental fails to build twice in a row. Cleaning after
the first build fails with

 fakeroot debian/rules clean
dh clean
   dh_auto_clean
make -j3 clean
make[1]: Entering directory '/build/libtommath-1.1.0'
rm -f *.gcda *.gcno *.gcov *.bat *.o *.a *.obj *.lib *.exe *.dll etclib/*.o 
demo/demo.o test timing mpitest mtest/mtest mtest/mtest.exe \
*.idx *.toc *.log *.aux *.dvi *.lof *.ind *.ilg *.ps *.log *.s mpi.c 
*.da *.dyn *.dpi tommath.tex `find . -type f | grep [~] | xargs` *.lo *.la
rm -rf .libs/
make -C etc/ clean MAKE=make
make[2]: Entering directory '/build/libtommath-1.1.0/etc'
rm -f *.log *.o *.obj *.exe pprime tune mersenne drprime tune86 tune86l mont 
2kprime pprime.dat \
 *.da *.dyn *.dpi *~
make[2]: Leaving directory '/build/libtommath-1.1.0/etc'
make -C doc/ clean MAKE=make
make[2]: Entering directory '/build/libtommath-1.1.0/doc'
make -C pics/ clean MAKE=make
make[3]: Entering directory '/build/libtommath-1.1.0/doc/pics'
rm -rf *.ps *.pdf .xvpics
make[3]: Leaving directory '/build/libtommath-1.1.0/doc/pics'
rm -f *.idx *.toc *.log *.aux *.dvi *.lof *.ind *.ilg *.ps *.log tommath.tex
make[2]: Leaving directory '/build/libtommath-1.1.0/doc'
make[1]: Leaving directory '/build/libtommath-1.1.0'
   debian/rules override_dh_clean
make[1]: Entering directory '/build/libtommath-1.1.0'
dh_clean tommath.out debian/libtool
rm: cannot remove 'debian/libtool': Is a directory
dh_clean: rm -f -- debian/libtommath-docs.substvars 
debian/libtommath-dev.substvars debian/libtommath1.substvars tommath.out 
debian/libtool debian/files returned exit code 1
make[1]: *** [debian/rules:51: override_dh_clean] Error 2
make[1]: Leaving directory '/build/libtommath-1.1.0'
make: *** [debian/rules:21: clean] Error 2


Andreas


libtommath_1.1.0-3~exp1_twice.log.gz
Description: application/gzip

Bug#789119: Proposal,

[Mr Scalesse Girolamo]

HELLO,

FIRSTLY I APOLOGISE BECAUSE YOU DO NOT KNOW ME PERSONALLY I GOT YOUR EMAIL
FOR A WEB JOURNAL AND I WAS WONDERING IF WE CAN WORK TOGETHER BECAUSE I
HAVE A TRANSACTION FOR YOU CAN WE WORK TOGETHER ?

Bug#921663: Please add python-certbot update to jessie-backports

[Brad Warren]

Thanks for looking into that Ola.

I think we could work around the python3-sphinx problem. It’s just used for 
building the docs and python3-sphinx (>= 1.6) is not in Stretch despite the 
Certbot package being updated there. It seems to me like something similar 
could be done here.

python3-cryptography certainly might be a problem though.

> On Feb 9, 2019, at 12:27 PM, Ola Lundqvist  wrote:
> 
> Hi Holger and Brad
> 
> Here is a little more extensive list of dependencies:
> 
> python-certbot (of course as it is the one providing certbot)
> python3-acme (>= 0.26.0~) - not in jessie, available in backports
> python3-configargparse - not in jessie, available in backports
> python3-cryptography (>= 1.2) - update needed (affecting something else?), 
> available in backports
> python3-josepy - not in jessie
> python3-rfc3339 - not in jessie, available in backports
> python3-sphinx (>= 1.6) - update needed (affecting something else?)
> python-certbot-nginx
> python-certbot-apache
> 
> python-certbot-nginx and python-certbot-apache do not seem to add any 
> additional dependencies that are not already in jessie.
> 
> I have not checked if any of the above packages require further dependencies 
> so the list may grow larger.
> 
> Best regards
> 
> // Ola
> 
> On Sat, 9 Feb 2019 at 20:58, Brad Warren  wrote:
> 
> 
> > On Feb 9, 2019, at 6:19 AM, Holger Levsen  wrote:
> > 
> > On Sat, Feb 09, 2019 at 02:54:43PM +0100, Ola Lundqvist wrote:
> >> I can also add that I have looked into this for myself and the number of
> >> needed dependencies is rather large. So it is not just certbot that need an
> >> update, we also need to include quite a few other packages too.
> > 
> > how large exactly?
> > 
> All of:
> 
> - python-acme
> - python-certbot
> - python-certbot-apache
> - python-certbot-nginx
> - python-josepy
> 
> would need to be added/updated like they were in Stretch. (The new 
> python-josepy package comes from it being split out of python-acme.)
> 
> We have spent a lot of time upstream keeping compatibility with older 
> versions of our dependencies and not adding new dependencies with the goal of 
> making situations like this easier.
> 
> With that said, these Debian packages have switched from Python 2 to Python 3 
> since the last time they were updated in jessie-backports. The switch to 
> Python 3 would either need to be undone (as we have kept compatibility with 
> Python 2 upstream) or Python 3 versions of some of our dependencies would 
> need to be added. I am not sure how many packages would be affected if the 
> latter approach was taken.
> 
> > 
> > -- 
> > tschau,
> >   Holger
> > 
> > ---
> >   holger@(debian|reproducible-builds|layer-acht).org
> >   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
> 
> 
> 
> -- 
>  --- Inguza Technology AB --- MSc in Information Technology 
> /  o...@inguza.comFolkebogatan 26\
> |  o...@debian.org   654 68 KARLSTAD|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>  ---
> 

Bug#921884: wlroots: ABI break between 0.2 and 0.3

[Mattia Rizzolo]

On Sat, Feb 09, 2019 at 10:35:22PM +0100, Guido Günther wrote:
> This is well known to the users of wlroots and the reason why we did not
> upload to unstable yet but it's good to have a bug tracking that.

ahem… but that's not common knowledge outside that circle...

Can I ask you at least try to minimize the disruption until a stable ABI
comes around (hopefully soon…) by:
* mentioning this fact in the package description
* still adding a .symbols file so a diff of the gone symbols is available
* bumping shlibs every time the ABI changes (you should do this regardless)
* adding Breaks against everything in the archive that any random upload
  breaks

Instead of the last two items, you could add a virtual package (e.g.
libwlroots-abi-XXX) and have that XXX change any time the ABI change,
and have shlibs issue that instead of the current "libwlroots0"; I would
go as far as saying that doint this would also allow you to upload this
package to unstable even with the ABI regularly breaking, as you'd
de-facto enforce a transition every time you bump that virtual package.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#921891: mblaze: new upstream version available

[Linda Lapinlampi]

Package: mblaze
Version: 0.4-1
Severity: wishlist

Dear Maintainer,

a new version of mblaze (0.5) has been released today. I request this
updated version to be packaged to Debian.

Changelog:
https://github.com/chneukirchen/mblaze/blob/2c14e800cd532c5b2deea9d658551900700b1e69/NEWS.md


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

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

Versions of packages mblaze depends on:
ii  libc6  2.28-6

mblaze recommends no packages.

mblaze suggests no packages.

-- no debconf information

Bug#921890: clblas: error: variables in the local address space can only be declared in the outermost scope of a kernel function

[Rebecca N. Palmer]

Package: clblas
Version: 2.12-1
Control: tags -1 patch upstream
(upstream tag based on checking the source, not testing)

Some clblas operations fail on beignet-opencl-icd with

stringInput.cl:179:24: error: variables in the local address space can 
only be declared in the outermost scope of a kernel function


Checking the source confirms that they are declaring __local variables 
in an inner scope, which is not allowed by the OpenCL standard: 
https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/local.html


This affects example_chpmv, example_snrm2, example_sspmv, example_stpmv, 
example_stpsv, example_strmv, example_strsv.


The attached patch makes the examples run, but has *not* been tested 
beyond them (which I suspect don't check correctness): the test suite 
fails to build with what looks like 
https://github.com/clMathLibraries/clBLAS/issues/338.
Description: Move __local declarations to kernel function scope

The OpenCL spec does not allow declaring local variables in scopes
below kernel function scope, and such declarations fail to build
on at least beignet-opencl-icd.

https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/local.html

Author: Rebecca N. Palmer 
Bug-Debian: https://bugs.debian.org/
Forwarded: no

--- clblas-2.12.orig/src/library/blas/gens/clTemplates/trmv.cl
+++ clblas-2.12/src/library/blas/gens/clTemplates/trmv.cl
@@ -75,6 +75,8 @@ __kernel void %PREFIXtrmv_CU_kernel( __g
 
 
 	__local %TYPE  sXData[ TARGET_WIDTH ]; // Each column is multiplied with a common x_vector element
+volatile __local %TYPE%V sDataTemp[TARGET_ROWS_BY_VEC * TARGET_WIDTH];
+volatile __local %TYPE* sData = sDataTemp;
 
 	const int gIdx = get_global_id(0);
 	const int bIdx = get_group_id(0);
@@ -197,8 +199,6 @@ __kernel void %PREFIXtrmv_CU_kernel( __g
 		}
 
 
-		volatile __local %TYPE%V sDataTemp[TARGET_ROWS_BY_VEC * TARGET_WIDTH];
-		volatile __local %TYPE* sData = sDataTemp;
 		//sDataTemp[(threadIdx & ( TARGET_ROWS_BY_VEC -1 )) + (colShift * TARGET_ROWS_BY_VEC)] = sum;
 		sDataTemp[(threadIdx % ( TARGET_ROWS_BY_VEC )) + (colShift * TARGET_ROWS_BY_VEC)] = sum;
 		barrier(CLK_LOCAL_MEM_FENCE);
@@ -325,6 +325,8 @@ __kernel void %PREFIXtrmv_CL_kernel( __g
 #endif
 
 	__local %TYPE sXData[ TARGET_WIDTH ]; // Each column is multiplied with a common x_vector element
+__local %TYPE%V sDataTemp[TARGET_ROWS_BY_VEC * TARGET_WIDTH];
+__local %TYPE* sData = sDataTemp;
 
 	size_t gIdx = get_global_id(0);
 	size_t bIdx = get_group_id(0);
@@ -448,8 +450,6 @@ __kernel void %PREFIXtrmv_CL_kernel( __g
 		}
 
 
-		__local %TYPE%V sDataTemp[TARGET_ROWS_BY_VEC * TARGET_WIDTH];
-		__local %TYPE* sData = sDataTemp;
 		//sDataTemp[(threadIdx & ( TARGET_ROWS_BY_VEC -1 )) + (colShift * TARGET_ROWS_BY_VEC)] = sum;
 		sDataTemp[(threadIdx % ( TARGET_ROWS_BY_VEC  )) + (colShift * TARGET_ROWS_BY_VEC)] = sum;
 		barrier(CLK_LOCAL_MEM_FENCE);
@@ -584,6 +584,7 @@ __kernel void %PREFIXtrmv_CLT_kernel( __
 	int threadIdx 	= get_local_id(0);
 
 	__local %TYPE xShared[TARGET_WIDTH];
+__local %TYPE%V* xSharedTemp;
 
 	int startCol  	= blockIdx * %TARGET_ROWS;
 
@@ -608,7 +609,7 @@ __kernel void %PREFIXtrmv_CLT_kernel( __
 
 		//float4 xData = (float4)(xShared[ rowShift ], xShared[ rowShift + 1], xShared[ rowShift + 2], xShared[ rowShift + 3]);
 		%TYPE%V xData;
-		__local %TYPE%V* xSharedTemp = (xShared + rowShift);
+		xSharedTemp = (xShared + rowShift);
 		xData = *(xSharedTemp);
 
 		int row	= startRow + rowShift;
@@ -761,6 +762,9 @@ __kernel void %PREFIXtrmv_CUT_kernel( __
 	int threadIdx 	= get_local_id(0);
 
 	__local %TYPE xShared[TARGET_WIDTH];
+__local %TYPE%V* xSharedTemp;
+__local %TYPE%V sDataTemp[TARGET_WIDTH_BY_VEC * %TARGET_ROWS];
+__local %TYPE* sData = sDataTemp;
 
 	int startRow  	= 0;
 	int startCol  	= N - (blockIdx + 1)* %TARGET_ROWS;
@@ -842,7 +846,7 @@ __kernel void %PREFIXtrmv_CUT_kernel( __
 
 			//float4 xData = (float4)(xShared[ rowShift ], xShared[ rowShift + 1], xShared[ rowShift + 2], xShared[ rowShift + 3]);
 			%TYPE%V xData;
-			__local %TYPE%V* xSharedTemp = (xShared + rowShift);
+			xSharedTemp = (xShared + rowShift);
 			xData = *(xSharedTemp);
 
 			int row	= startRow + rowShift;
@@ -861,8 +865,6 @@ __kernel void %PREFIXtrmv_CUT_kernel( __
 		//__local float4 sData[16][4];
 		//sData[(threadIdx & 15)][colShift] = acc;
 		//barrier(CLK_LOCAL_MEM_FENCE);
-		__local %TYPE%V sDataTemp[TARGET_WIDTH_BY_VEC * %TARGET_ROWS];
-		__local %TYPE* sData = sDataTemp;
 
 		//sDataTemp[ ( threadIdx & ( TARGET_WIDTH_BY_VEC -1 ) ) + (colShift * TARGET_WIDTH_BY_VEC) ] = acc;
 		sDataTemp[ ( threadIdx % ( TARGET_WIDTH_BY_VEC  ) ) + (colShift * TARGET_WIDTH_BY_VEC) ] = acc;
--- clblas-2.12.orig/src/library/blas/gens/clTemplates/trsv_gemv.cl
+++ clblas-2.12/src/library/blas/gens/clTemplates/trsv_gemv.cl
@@ -35,6 +35,11 @@ __kernel void %PREFIXtrsv_CU_ComputeRect
 {
 	__global %TYPE* xnew;
 	__global %TYPE* A = _A + offa;
+	__local %TYPE%V sDataTemp[TARGET_ROWS_BY_VEC * 

Bug#921889: debian-policy: recommends an old version of libjs-sphinxdoc

[Gabriele Stilli]

Package: debian-policy
Version: 4.3.0.1

Hello,

debian-policy recommends libjs-sphinxdoc (<< 1.7.9.0~) while version
1.8.3-2 has just entered buster. Upgrading libjs-sphinxdoc would
therefore break the Recommends.

Regards,
Gabriele Stilli

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Michael Biebl]

Hi

Am 09.02.19 um 10:39 schrieb Francesco Poli:

> Could you please do me a favor?
> I would like you to read bug [#916753] log and then tell me what you
> think. Your insight might be useful to find a better solution.

What kind of input do you need?
I guess I already mentioned the two alternatives (runuser/setpriv).
Depending on your needs (w or w/o PAM session), they both should do fine
and would avoid needing this dependency on s6-setuidgid.

Michael




signature.asc
Description: OpenPGP digital signature

Bug#921888: apparmor: allow access to ~/.local/share/mime/**

[Anthony DeRobertis]

Package: thunderbird
Version: 1:60.4.0-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Whenever a calendar reminder is displaying, Thunderbird is flooding my
logs with apparmor denials:

Feb  9 16:20:34 Watt kernel: [518027.774746] audit: type=1400 
audit(1549747234.261:2371): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/mime.cache" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774759] audit: type=1400 
audit(1549747234.261:2372): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/globs2" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774761] audit: type=1400 
audit(1549747234.261:2373): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/magic" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774764] audit: type=1400 
audit(1549747234.261:2374): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/aliases" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774765] audit: type=1400 
audit(1549747234.261:2375): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/subclasses" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774768] audit: type=1400 
audit(1549747234.261:2376): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/icons" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774770] audit: type=1400 
audit(1549747234.261:2377): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/generic-icons" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905303] audit: type=1400 
audit(1549747248.393:2378): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/mime.cache" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905317] audit: type=1400 
audit(1549747248.393:2379): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/globs2" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905319] audit: type=1400 
audit(1549747248.393:2380): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/magic" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905321] audit: type=1400 
audit(1549747248.393:2381): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/aliases" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905323] audit: type=1400 
audit(1549747248.393:2382): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/subclasses" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905325] audit: type=1400 
audit(1549747248.393:2383): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/icons" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905327] audit: type=1400 
audit(1549747248.393:2384): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/generic-icons" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:21:07 Watt kernel: [518060.691464] audit: type=1400 
audit(1549747267.178:2385): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/mime.cache" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:21:07 Watt kernel: [518060.691471] audit: type=1400 
audit(1549747267.178:2386): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/globs2" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:21:07 Watt kernel: [518060.691474] audit: type=1400 
audit(1549747267.178:2387): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/magic" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 

Bug#921887: python3-cartopy: config['repo_data_dir'] is incorrect (e.g., breaking stock_image())

[Matt Marjanovic]

Package: python3-cartopy
Version: 0.17.0+dfsg-2
Severity: normal

Dear Maintainer,

The 'repo_data_dir' element in the cartopy.config dictionary still has its
upstream default value of "/usr/lib/python3/dist-packages/cartopy/data",
however the "python-cartopy-data" package installs these files in a different
location, "/usr/share/cartopy/data".

>From the docstring for 'repo_data_dir' in lib/cartopy/__init__.py:

  ``repo_data_dir``
The absolute path to the directory where the data delivered with the
cartopy repository is stored.  Typically this will only be set by OS
packagers and system administrators for site wide deployments.

A consequence of the mismatch is that methods like "stock_image()", which
expect to find files in certain places relative to 'repo_data_dir', fail
to work.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3-cartopy depends on:
ii  libc6   2.28-2
ii  libgcc1 1:8.2.0-12
ii  libgeos-c1v53.7.1-1
ii  libproj13   5.2.0-1
ii  libstdc++6  8.2.0-12
ii  python-cartopy-data 0.17.0+dfsg-2
ii  python3 3.7.1-3
ii  python3-numpy [python3-numpy-abi9]  1:1.16.1-1
ii  python3-pkg-resources   40.6.2-1
ii  python3-pyshp   2.0.1+ds-1
ii  python3-shapely 1.6.4-2
ii  python3-six 1.12.0-1

python3-cartopy recommends no packages.

Versions of packages python3-cartopy suggests:
pn  python3-fiona   
pn  python3-gdal
ii  python3-matplotlib  3.0.2-2
pn  python3-owslib  
ii  python3-pil 5.3.0-1
pn  python3-pyepsg  
pn  python3-pykdtree
ii  python3-scipy   1.1.0-2

-- no debconf information

Bug#921825: photocollage 1.4.3-2.1~deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

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

Thanks for your contribution!

Upload details
==

Package: photocollage
Version: 1.4.3-2.1~deb9u1

Explanation: add missing dependency on gir1.2-gtk-3.0