Bug#823755: pinpoint: Segfault reliably on example, even if I just start the example and do nothing

[Lynoure Braakman]

Package: pinpoint
Version: 1:0.1.8-3
Followup-For: Bug #823755

Dear Maintainer,

When I start the example presentation with pinpoint, and do nothing, it
segfaults in less than a minute.

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

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

Versions of packages pinpoint depends on:
ii  libc6 2.24-11+deb9u1
ii  libcairo2 1.14.8-1
ii  libclutter-1.0-0  1.26.0+dfsg-3
ii  libclutter-gst-3.0-0  3.0.24-1
ii  libclutter-gtk-1.0-0  1.8.2-2
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u1
ii  libglib2.0-0  2.50.3-2
ii  libgstreamer1.0-0 1.10.4-1
ii  libgtk-3-03.22.11-1
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1

pinpoint recommends no packages.

pinpoint suggests no packages.

-- no debconf information

Bug#879852: sourceforge redirector takes subfolder into account

[Paul Wise]

On Thu, 2017-10-26 at 18:38 +0200, Laurent Bigonville wrote:

> For a lot of project that OldFiles directory is definitely not showing 
> up in the default download page
> 
> https://www.google.be/search?q=sourceforge+%22oldfiles%22

I've done some experimentation and it looks like you are correct,
SourceForge is treating the OldFiles directory as hidden.

So I think the right thing to do here is to leave the files in the
OldFiles directory available in the redirector, but just make them
text without links and leave the the "path" or "direct" links in place:

https://qa.debian.org/watch/sf.php/rpcbind/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#879798: FTBFS: testsuite fails with dpkg 1.19, patch attached

[Adam Conrad]

On Thu, Oct 26, 2017 at 08:59:23PM +0200, Mattia Rizzolo wrote:
> On Wed, Oct 25, 2017 at 10:40:20PM -0600, Adam Conrad wrote:
> 
> We like to backport devscripts, and I'd rather not have backports deltas
> if possible...

I'd suggest that this commit already makes no-delta backports somewhat
problematic:

https://anonscm.debian.org/git/collab-maint/devscripts.git/commit/?id=921696fd6c92c4299accb1e2ef1ae48d13a47b0d

But ignoring that for a moment, how about this patch instead (tested
against dpkg 1.18.24ubuntu1 and 1.19.0.4ubuntu1):

diff -Nru devscripts-2.17.10/test/test_mk-origtargz 
devscripts-2.17.10ubuntu2/test/test_mk-origtargz
--- devscripts-2.17.10/test/test_mk-origtargz   2017-09-13 20:08:30.0 
-0600
+++ devscripts-2.17.10ubuntu2/test/test_mk-origtargz2017-10-26 
22:38:49.0 -0600
@@ -26,6 +26,12 @@
 PROGNAME="mk-origtargz.pl"
 fi
 
+if dpkg --compare-versions $(dpkg-query -W -f='${Version}' libdpkg-perl) lt 
1.19.0~; then
+SUBPROCESS_ERROR="gave error exit status 2"
+else
+SUBPROCESS_ERROR="subprocess returned exit status 2"
+fi
+
 cleanup(){
rm -rf $TMPDIR
unset LC_ALL
@@ -540,7 +546,7 @@
"tar: This does not look like a tar archive
 tar: Skipping to next header
 tar: Exiting with failure status due to previous errors
-$PROGNAME: error: tar --list --auto-compress --file ../foo_0.1.orig.tar.xz 
gave error exit status 2" \
+$PROGNAME: error: tar --list --auto-compress --file ../foo_0.1.orig.tar.xz 
$SUBPROCESS_ERROR" \
"" \
 ../foo-0.1.tar.gz --repack --compression xz
 }

... Adam

Bug#879900: Acknowledgement (apparmor-profiles-extra: Totem segfaults when apparmor profile is enforced)

[Jason Wittlin-Cohen]

I failed to mention earlier but I saw the same behavior on my Buster system
running version 1.14 and 1.15..  I am also seeing the same behavior on my
Stretch install:


jason@jason-desktop:/etc/apparmor.d$ /usr/bin/totem


(totem:14579): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL'
failed

Segmentation fault


Syslog:


Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-0: disconnected

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-0: Internal TMDS

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0):

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-1: disconnected

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-1: Internal TMDS

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-1: 330.0 MHz maximum pixel clock

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0):

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): Acer XB271HU (DFP-2): connected

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): Acer XB271HU (DFP-2): Internal DisplayPort

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): Acer XB271HU (DFP-2): 1440.0 MHz maximum pixel clock

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0):

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-3: disconnected

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-3: Internal TMDS

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-3: 330.0 MHz maximum pixel clock

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0):

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DELL U2713HM (DFP-4): connected

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DELL U2713HM (DFP-4): Internal DisplayPort

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DELL U2713HM (DFP-4): 1440.0 MHz maximum pixel clock

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0):

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-5: disconnected

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-5: Internal TMDS

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-5: 330.0 MHz maximum pixel clock

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0):

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-6: disconnected

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-6: Internal DisplayPort

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-6: 1440.0 MHz maximum pixel clock

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0):

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-7: disconnected

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-7: Internal TMDS

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0): DFP-7: 330.0 MHz maximum pixel clock

Oct 27 00:29:25 jason-desktop /usr/lib/gdm3/gdm-x-session[3332]: (--)
NVIDIA(GPU-0):

Oct 27 00:29:25 jason-desktop kernel: [ 96.503531] audit_printk_skb: 10
callbacks suppressed

Oct 27 00:29:25 jason-desktop kernel: [ 96.503533] audit: type=1400
audit(1509078565.921:86): apparmor="DENIED" operation="open"
profile="/usr/bin/totem" name="/proc/modules" pid=5467 comm="totem"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Oct 27 00:29:25 jason-desktop kernel: [ 96.504412] audit: type=1400
audit(1509078565.921:87): apparmor="DENIED" operation="exec"
profile="/usr/bin/totem" name="/usr/bin/nvidia-modprobe" pid=5470
comm="totem" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

Oct 27 00:29:25 jason-desktop kernel: [ 96.507159] audit: type=1400
audit(1509078565.925:88): apparmor="DENIED" operation="open"
profile="/usr/bin/totem" name="/proc/modules" pid=5467 comm="totem"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Oct 27 00:29:25 jason-desktop kernel: [ 96.507855] audit: type=1400
audit(1509078565.925:89): apparmor="DENIED" operation="exec"
profile="/usr/bin/totem" name="/usr/bin/nvidia-modprobe" pid=5471
comm="totem" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

Oct 27 00:29:25 jason-desktop 

Bug#879886: [Debian-med-packaging] Bug#879886: Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

Hi, Mattia and all,

على الخميس 26 تشرين الأول 2017 ‫15:44، كتب Mattia Rizzolo:
> On Thu, Oct 26, 2017 at 12:12:05PM -0700, Diane Trout wrote:
>> libhts2 introduced an ABI change which broke python-pysam, and a new
>> version of python-pysam needed to be released to update to the new ABI.
> 
> FTR, this is what changed between the symbols of the version 1.4.1-5 and
> 1.5-1:
> 
[...]
> 
>> libhts2 probably needs a proper symbols file to make it easier to see
>> when the ABI is changing. https://wiki.debian.org/UsingSymbolsFiles
>>
>> Mattia Rizzolo, also suggests other methods of dealing with managing ABI
>> changes.
> 
> In pysam's case, it is looking for hts_log, if you had properly checked
> the symbols of your package before uploading you should have at least
> tweaked the dh_shlibdeps invocation to force a version, or introduced a
> .symbols file (very recommended for a case like hstlib where the symbols
> seems to be simple).
> 
> But then, the ABI is broken, so just nicest symbols handling is not
> enough for your case, you need
>> Such as bumping soname, changing the package name and use Conflicts, or
>> adding versioned Breaks against broken packages
> 
> 

Please see #822701; specifically:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822701#26
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822701#41 (and
subsequent replies)
and
https://lists.alioth.debian.org/pipermail/debian-med-packaging/2016-January/038827.html
(which is linked from one of the replies to the above)

We've been doing this for every htslib suite release and can confirm
upstream's explanation. Other packages do not get broken. Upstream has
made a soname bump as appropriate for the 1.4 release if I remember
correctly. That's all I can say about this; I don't actually work on the
htslib packaging myself.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#879903: login: Add ttyMV0 to /etc/securetty

[Matthias Urlichs]

Package: login
Version: 1:4.4-4.1
Severity: normal

Please add to /etc/securetty:

# Marvell EspressoBin et al.
ttyMV0

Thank you.

Bug#879902: xosview FTCBFS: builds for the build architecture rather than host

[Helmut Grohne]

Source: xosview
Version: 1.19-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xosview fails to cross build from source, because it builds for the
build architecture:
 * The upstream build system defaults to the build architecture compiler
   and the packaging fails to pass cross compilers. dh_auto_build fixes
   that.
 * The packaging sets PLATFORM according to the build architecture,
   while it should be evaluating the host architecture.
 * The upstream build system determines its $(ARCH) from uname, which is
   a build architecture property and needs to be overriden by
   debian/rules.

After fixing all of the above, xosview cross builds successfully. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru xosview-1.19/debian/changelog xosview-1.19/debian/changelog
--- xosview-1.19/debian/changelog   2016-12-10 14:15:30.0 +0100
+++ xosview-1.19/debian/changelog   2017-10-27 06:31:37.0 +0200
@@ -1,3 +1,13 @@
+xosview (1.19-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross compilers to make.
++ Fix build/host confusion.
++ Also pass ARCH= to make.
+
+ -- Helmut Grohne   Fri, 27 Oct 2017 06:31:37 +0200
+
 xosview (1.19-1) unstable; urgency=low
 
   * New upstream release.
diff --minimal -Nru xosview-1.19/debian/rules xosview-1.19/debian/rules
--- xosview-1.19/debian/rules   2016-06-30 07:39:12.0 +0200
+++ xosview-1.19/debian/rules   2017-10-27 06:31:34.0 +0200
@@ -4,19 +4,19 @@
 #export DH_VERBOSE=1
 
 DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/buildflags.mk
 
 CXX=g++
 
-DEB_BUILD_ARCH_OS ?=$(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
-ifeq ($(DEB_BUILD_ARCH_OS),linux)
+ifeq ($(DEB_HOST_ARCH_OS),linux)
   PLATFORM=linux
-else ifeq ($(DEB_BUILD_ARCH_OS),kfreebsd)
+else ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
   PLATFORM=bsd
-else ifeq ($(DEB_BUILD_ARCH_OS),hurd)
+else ifeq ($(DEB_HOST_ARCH_OS),hurd)
   PLATFORM=gnu
 else
-  $(error Missing implementation for $(DEB_BUILD_ARCH_OS))
+  $(error Missing implementation for $(DEB_HOST_ARCH_OS))
 endif
 
 build: build-arch build-indep
@@ -24,7 +24,7 @@
 build-indep: build-stamp
 build-stamp:
dh_testdir
-   $(MAKE) PLATFORM=$(PLATFORM)
+   dh_auto_build -- PLATFORM=$(PLATFORM) ARCH=$(DEB_HOST_ARCH_CPU)
touch $@
 
 clean:

Bug#879901: kded5 memory leak consumes over 600MB of RAM

[Nicholas D Steeves]

Package: kded5
Version: 5.28.0-1
Severity: important

This is a normal KDE task netinstall of stretch on a Thinkpad X220
(clean install, not an upgrade).  I'm going to keep my laptop in
suspect until Monday, when I need to use it for work again.  Until
then I will only resume from S3 to help debug the dbus-daemon and kde5
memory leak bugs.  After Monday, I am afraid that the opportunity to
track this down again will be lost for a while.

I've attached relevant ps -aux and top output, and the gdb session.
The relevant -dbg.* packages have been installed to produce a
meaningful bt.  No package seems to provide pthread_cond_wait.S ...

  Using host libthread_db library
  "/lib/x86_64-linux-gnu/libthread_db.so.1".
  pthread_cond_wait@@GLIBC_2.3.2 ()
  at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  185 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No
  such file or directory.
  #0  pthread_cond_wait@@GLIBC_2.3.2 ()
  at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

Please let me know what else I can do to help track this down.

-- System Information:
Debian Release: 9.1
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kded5 depends on:
ii  libc6  2.24-11+deb9u1
ii  libkf5configcore5  5.28.0-2
ii  libkf5coreaddons5  5.28.0-2
ii  libkf5crash5   5.28.0-1
ii  libkf5dbusaddons5  5.28.0-1
ii  libkf5service-bin  5.28.0-1
ii  libkf5service5 5.28.0-1
ii  libqt5core5a   5.7.1+dfsg-3+b1
ii  libqt5dbus55.7.1+dfsg-3+b1
ii  libqt5gui5 5.7.1+dfsg-3+b1
ii  libqt5widgets5 5.7.1+dfsg-3+b1
ii  libstdc++6 6.3.0-18

kded5 recommends no packages.

kded5 suggests no packages.

-- no debconf information

Sincerely,
Nicholas
sten  1024  0.4  8.3 1568224 672080 ?  Sl   Oct19  56:51 kded5 
[kdeinit5]
 PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
 958 sten  20   0 6964832 5.364g720 S  31.1 69.8  30:49.31 dbus-daemon
1024 sten  20   0 1568224 676440  10160 S   0.0  8.4  56:51.09 kded5
...
   (and two minutes later)
1024 sten  20   0 1617724 751924   8108 S   0.0  9.3  58:10.11 
Quit
quit
Attaching to process 1024
[New LWP 1027]
[New LWP 1029]
[New LWP 1707]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
pthread_cond_wait@@GLIBC_2.3.2 ()
at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or 
directory.
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7fd4b5de1c6b in QWaitConditionPrivate::wait (
time=18446744073709551615, this=0x555e45f54690)
at thread/qwaitcondition_unix.cpp:143
#2  QWaitCondition::wait (this=this@entry=0x555e45f53540, 
mutex=mutex@entry=0x555e45f53538, 
time=time@entry=18446744073709551615)
at thread/qwaitcondition_unix.cpp:215
#3  0x7fd4ad2e754b in QDBusPendingCallPrivate::waitForFinished
(this=0x555e45f53500) at qdbuspendingcall.cpp:240
#4  0x7fd4ad2e8656 in QDBusPendingReplyData::argumentAt (
this=0x7ffc83943690, index=0) at qdbuspendingreply.cpp:283
#5  0x7fd49b28dd6c in Solid::PowerManagement::appShouldConserveResources() 
()
   from /usr/lib/x86_64-linux-gnu/libKF5KDELibs4Support.so.5
#6  0x7fd48b3e7e95 in ?? ()
   from /usr/lib/x86_64-linux-gnu/qt5/plugins/kded_apperd.so
#7  0x7fd48b3e9710 in ?? ()
   from /usr/lib/x86_64-linux-gnu/qt5/plugins/kded_apperd.so
#8  0x7fd4b5fdc5e9 in QMetaObject::activate (
sender=0x555e44897a10, signalOffset=, 
local_signal_index=, argv=)
at kernel/qobject.cpp:3740
#9  0x7fd48aabb655 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libpackagekitqt5.so.0
#10 0x7fd4b5fdc5e9 in QMetaObject::activate (
sender=0x555e449458e0, signalOffset=, 
local_signal_index=, argv=)
at kernel/qobject.cpp:3740
#11 0x7fd48aacfac3 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libpackagekitqt5.so.0
#12 0x7fd48aad1330 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libpackagekitqt5.so.0
#13 0x7fd4ad29ba10 in QDBusConnectionPrivate::deliverCall (
this=, object=, msg=..., 
metaTypes=..., slotIdx=)
at qdbusintegrator.cpp:995
#14 0x7fd4b5fdd499 in QObject::event (this=0x555e449458e0, 
e=) at kernel/qobject.cpp:1263
#15 0x7fd4b4864b8c in QApplicationPrivate::notify_helper (
this=, receiver=0x555e449458e0, 
e=0x7fd45fd3c710) at kernel/qapplication.cpp:3799
#16 0x7fd4b486c341 in QApplication::notify (
this=0x7ffc83944380, receiver=0x555e449458e0, e=0x7fd45fd3c710)
at 

Bug#879900: apparmor-profiles-extra: Totem segfaults when apparmor profile is enforced

[Jason Wittlin-Cohen]

Package: apparmor-profiles-extra
Version: 1.15
Severity: important

Dear Maintainer,

Totem suffers a segmentation fault upon startup when its respective apparmor
profile is set to enforce mode.  It starts fine when the apparmor profile is
set to complain mode. I have not modified the /etc/apparmor.d/usr.bin.totem
profile.

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

   * What led up to the situation?

I set /usr/bin/totem to "enforce" mode and then attempted to start
/usr/bin/totem from a terminal in order to display the error.  I see the
same
behavior if I open Totem from my GNOME menu.

jason@debian-testing:~$ /usr/bin/totem

(totem:29696): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL'
failed
Segmentation fault


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Placing /usr/bin/totem in "complain" mode resolves the issue.

   * What outcome did you expect instead?

I expected Totem to work properly with its apparmor profile in enforce mode.

Relevant Output from Syslog:

Oct 27 00:00:16 debian-testing kernel: [139095.152218] audit: type=1400
audit(1509076816.705:1330): apparmor="STATUS" operation="profile_replace"
info="same as current profile, skipping" profile="unconfined"
name="/usr/bin/totem" pid=29508 comm="apparmor_parser"
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-0: disconnected
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-0: Internal TMDS
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0):
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-1: disconnected
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-1: Internal TMDS
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-1: 330.0 MHz maximum pixel clock
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0):
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): Acer XB271HU (DFP-2): connected
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): Acer XB271HU (DFP-2): Internal DisplayPort
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): Acer XB271HU (DFP-2): 1440.0 MHz maximum pixel clock
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0):
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-3: disconnected
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-3: Internal TMDS
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-3: 330.0 MHz maximum pixel clock
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0):
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DELL U2713HM (DFP-4): connected
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DELL U2713HM (DFP-4): Internal DisplayPort
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DELL U2713HM (DFP-4): 1440.0 MHz maximum pixel clock
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0):
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-5: disconnected
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-5: Internal TMDS
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-5: 330.0 MHz maximum pixel clock
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0):
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-6: disconnected
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-6: Internal DisplayPort
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-6: 1440.0 MHz maximum pixel clock
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0):
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-7: disconnected
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-7: Internal TMDS
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0): DFP-7: 330.0 MHz maximum pixel clock
Oct 27 00:00:22 debian-testing /usr/lib/gdm3/gdm-x-session[20279]: (--)
NVIDIA(GPU-0):
Oct 27 00:00:22 debian-testing kernel: [139101.193078] audit: type=1400
audit(1509076822.746:1331): apparmor="DENIED" operation="open"

Bug#879899: ITP: node-coa -- Yet another parser for command line options

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-coa
  Version : 2.0.0
  Upstream Author : Sergey Berezhnoy  (http://github.com/veged)
* URL : http://github.com/veged/coa
* License : Expat
  Programming Lang: JavaScript
  Description : Yet another parser for command line options

 COA is a parser for command line options that aim to get maximum profit
from
 formalization of your program API. Once you write definition in terms of
 commands, options and arguments you automaticaly get:
  * Command line help text
  * Program API for use COA-based programs as modules
  * Shell completion
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature

Bug#879898: dbus: memory leak in dbus-daemon consumes over 5GB memory

[Nicholas D Steeves]

Package: dbus
Version: 1.10.22-0+deb9u1
Severity: important

I hope to hear back from you soon, because Monday I will need to use
my laptop and I will have to kill the misbehaving dbus-daemon to
reclaim memory at that time.  In the meantime I will keep my laptop in
S3 in order to prevent dbus-daemon from growing to such a size as the
kernel's OOM killer kills it.

I'm running Stretch on a Thinkpad X220.  It was a fresh installation
of the KDE task using the netinstaller.  Like most laptop users, I
suspend or hibernate rather than shutting down, but dbus-daemon has
only been running for 7 days.  After installing -dbg packages for
everything gdb said was missing I was able to capture the attached
backtrace...however nothing seems to provide
sysdeps/unix/syscall-template.S

Here is the only section that jumps out to me:
  0x7f87feb730d3 in __epoll_wait_nocancel () at 
../sysdeps/unix/syscall-template.S:84
  84../sysdeps/unix/syscall-template.S: No such file or directory.
  #0  0x7f87feb730d3 in __epoll_wait_nocancel () at 
../sysdeps/unix/syscall-template.S:84

I've also attached the relevant output from ps -aux and top.

-- System Information:
Debian Release: 9.1
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dbus depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libapparmor1 2.11.0-3
ii  libaudit11:2.6.7-2
ii  libc62.24-11+deb9u1
ii  libcap-ng0   0.7.7-3+b1
ii  libdbus-1-3  1.10.22-0+deb9u1
ii  libexpat12.2.0-2+deb9u1
ii  libselinux1  2.6-3+b3
ii  libsystemd0  232-25+deb9u1
ii  lsb-base 9.20161125

dbus recommends no packages.

Versions of packages dbus suggests:
ii  dbus-x11 [dbus-session-bus]  1.10.22-0+deb9u1

Versions of packages dbus is related to:
ii  dbus-x11  1.10.22-0+deb9u1
ii  systemd   232-25+deb9u1
ii  systemd-sysv  232-25+deb9u1

-- no debconf information

Sincerely,
Nicholas
sten   958  0.2 66.6 6682644 5371232 ? Ss   Oct19  28:20 
/usr/bin/dbus-daemon --fork --print-pid 5 --print-address 15 --session
PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
958 sten  20   0 6682644 5.123g692 t   0.0 66.7  28:20.00 dbus-daemon
Attaching to process 958
Reading symbols from /usr/bin/dbus-daemon...Reading symbols from 
/usr/lib/debug/.build-id/5e/b9d5dbcdf4a19994e5a9dd24e0c266f5e69b55.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libdbus-1.so.3...Reading symbols 
from 
/usr/lib/debug/.build-id/89/b4008c84caf853cd403f295d44d76f7c8402fe.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libsystemd.so.0...Reading symbols 
from 
/usr/lib/debug/.build-id/c5/5580513bc9dd1d436aa03d17f84b659b9a0301.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libexpat.so.1...Reading symbols from 
/usr/lib/debug/.build-id/3a/48cca749065ff40698794c2bde4990ae524a88.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libselinux.so.1...Reading symbols 
from 
/usr/lib/debug/.build-id/5a/f6fc2e006d3e50bc6b643d4bb6fafe7919c238.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libaudit.so.1...Reading symbols from 
/usr/lib/debug/.build-id/07/09efec334492fb455a6238d52f4f45041b97cb.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libcap-ng.so.0...Reading symbols 
from 
/usr/lib/debug/.build-id/88/c372f986252efa8e0def53516935f35d8010c4.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libapparmor.so.1...Reading symbols 
from 
/usr/lib/debug/.build-id/71/943532f6d2a4702f9bbbc24e9655cd0b519f6c.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading symbols 
from 
/usr/lib/debug/.build-id/96/8df33f83963b559243653d74d27d89605bed02.debug...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from 
/usr/lib/debug/.build-id/79/450f6e36287865d093ea209b85a09925ff.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...Reading symbols from 
/usr/lib/debug/.build-id/fe/41526a83999f2fe9d0f8aadcd61d03a92cbb70.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/liblzma.so.5...Reading symbols from 
/usr/lib/debug/.build-id/d9/4951f95e154271ae7cf843cc9d6d67ea502f5d.debug...done.
done.
Reading symbols from /usr/lib/x86_64-linux-gnu/liblz4.so.1...Reading symbols 
from /usr/lib/debug//usr/lib/x86_64-linux-gnu/liblz4.so.1.7.1...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libgcrypt.so.20...Reading symbols 
from 

Bug#879897: postgresql-multicorn: python{,3}-all-dev as test deps

[Steve Langasek]

Package: postgresql-multicorn
Version: 1.3.3-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear maintainers,

I noticed during the python3.6 migration in Ubuntu that postgresql-multicorn
failed its autopkgtests, because while there were multiple supported
versions of python3 (3.5, 3.6), 3.6 was not available at test time.

The attached patch addresses this by making the tests depend on the
corresponding python*-all-dev package.

Apologies for not submitting this patch in time to matter for the python3.6
transition in Debian, but it's still a correct change that will be
applicable for the next python3 transition.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru postgresql-multicorn-1.3.3/debian/tests/control 
postgresql-multicorn-1.3.3/debian/tests/control
--- postgresql-multicorn-1.3.3/debian/tests/control 2017-10-22 
06:22:35.0 -0700
+++ postgresql-multicorn-1.3.3/debian/tests/control 2017-10-26 
20:46:48.0 -0700
@@ -1,7 +1,7 @@
-Depends: newpid, postgresql-10-python-multicorn, python-psycopg2, 
python-sqlalchemy, postgresql-server-dev-all (>= 156~), postgresql-common (>= 
159~), postgresql-contrib-10, postgresql-plpython-10
+Depends: newpid, postgresql-9.6-python-multicorn, python-psycopg2, 
python-sqlalchemy, postgresql-server-dev-all (>= 156~), postgresql-common (>= 
159~), postgresql-contrib-9.6, postgresql-plpython-9.6, python-all-dev
 Test-Command: debian/tests/installcheck python2
 Restrictions: needs-root allow-stderr
 
-Depends: newpid, postgresql-10-python3-multicorn, python3-psycopg2, 
python3-sqlalchemy, postgresql-server-dev-all (>= 156~), postgresql-common (>= 
159~), postgresql-contrib-10, postgresql-plpython3-10
+Depends: newpid, postgresql-9.6-python3-multicorn, python3-psycopg2, 
python3-sqlalchemy, postgresql-server-dev-all (>= 156~), postgresql-common (>= 
159~), postgresql-contrib-9.6, postgresql-plpython3-9.6, python3-all-dev
 Test-Command: debian/tests/installcheck python3
 Restrictions: needs-root allow-stderr
diff -Nru postgresql-multicorn-1.3.3/debian/tests/control.in 
postgresql-multicorn-1.3.3/debian/tests/control.in
--- postgresql-multicorn-1.3.3/debian/tests/control.in  2017-10-21 
02:57:09.0 -0700
+++ postgresql-multicorn-1.3.3/debian/tests/control.in  2017-10-26 
20:46:48.0 -0700
@@ -1,7 +1,7 @@
-Depends: newpid, postgresql-PGVERSION-python-multicorn, python-psycopg2, 
python-sqlalchemy, postgresql-server-dev-all (>= 156~), postgresql-common (>= 
159~), postgresql-contrib-PGVERSION, postgresql-plpython-PGVERSION
+Depends: newpid, postgresql-PGVERSION-python-multicorn, python-psycopg2, 
python-sqlalchemy, postgresql-server-dev-all (>= 156~), postgresql-common (>= 
159~), postgresql-contrib-PGVERSION, postgresql-plpython-PGVERSION, 
python-all-dev
 Test-Command: debian/tests/installcheck python2
 Restrictions: needs-root allow-stderr
 
-Depends: newpid, postgresql-PGVERSION-python3-multicorn, python3-psycopg2, 
python3-sqlalchemy, postgresql-server-dev-all (>= 156~), postgresql-common (>= 
159~), postgresql-contrib-PGVERSION, postgresql-plpython3-PGVERSION
+Depends: newpid, postgresql-PGVERSION-python3-multicorn, python3-psycopg2, 
python3-sqlalchemy, postgresql-server-dev-all (>= 156~), postgresql-common (>= 
159~), postgresql-contrib-PGVERSION, postgresql-plpython3-PGVERSION, 
python3-all-dev
 Test-Command: debian/tests/installcheck python3
 Restrictions: needs-root allow-stderr

Bug#879171: cups: failed to recognize a driver of CP310dm

[Atsuhito Kohda]

Hi Brian,

On Thu, 26 Oct 2017 12:01:00 +0100, Brian Potkin wrote:

> Do you mean "CP310 dw"? This printer:
> 
>  http://news.fujixerox.com/image_library/detail/_imgid_000316/

Yes, sorry for my inaccuracy.

> What do you mean by "failed to recognize driver of CP310dm"?

I got printer driver (fxlinuxprint_1.1.2-1_amd64.deb)
from FujiXerox site; http://www.fujixerox.co.jp/download/eng/
(in fact, I accessed a Japanese page of it).
It installed /usr/share/ppd/FujiXerox/fxlinuxprint.ppd.gz

When I installed CP310 with cups (web interface), I selected
PPD and a file fxlinuxprint.ppd.gz. But after installation,
cups shows a printer driver of CP310 as "Local Raw Printer".
And, of course, I can't print with CP310.

> There is a PPD for your printer in /etc/cups/ppd. Please run the
> commands (as root)
> 
>  cupsfilter -p  -m printer/foo -e /etc/nsswitch  2>log.stretch
>  cupsfilter -p  -m printer/foo -e /etc/nsswitch  2>log.unstable
> 
> on stretch and an updated unstable.
> 
> Attach log.stretch and log.unstable to your next mail to the bug
> report.

I update cups 2.2.5-2 and set CP310 but it seems there is
no corresponding PPD in /etc/cups/ppd/

$ LANG=C ls -l /etc/cups/ppd/
total 80
-rw-r- 1 root lp 24814 Oct 17 08:59 CP310_dw.ppd
-rw-r- 1 root lp 24814 Oct 17 08:59 CP310_dw.ppd.O
-rw-r- 1 root lp 10713 Oct 13 06:52 ipsio.ppd
-rw-r- 1 root lp 10705 Jul 24 07:12 ipsio.ppd.O

I guess CP310_dw is a PPD when I installed cups 2.2.4-7.
So I can't generate log.unstable and attatch only log.stretch.
If I misunderstand anything, please let me know.

Thanks for your response.
2017-10-27(Fri)

-- 
 **
 Atsuhito Kohda
 Math. Meth. in Sci., Tokushima Univ.
 atsuhito_k AT tokushima-u.ac.jp

Bug#854691: xscreensaver user unit

[Daniel Kahn Gillmor]

On Thu 2017-08-31 12:07:10 +1000, Jeremy Visser wrote:
> I've attached a patch which fixes the issue.

Jeremy's patch (below) looks reasonable to me.  Even better would be to
have it include other useful metadata in the [Unit] section, like:

Documentation=man:xscreensaver(1)
Documentation=man:xscreensaver-command(1)
Documentation=man:xscreensaver-demo(1)
PartOf=graphical-session.target

xscreensaver(1) currently has a suggestion for this file.  It should
probably also be adjusted to remove the example, and explain
specifically that all the user needs to do is:

   systemctl --user enable xscreensaver

Arguably, this user unit should be enabled by default.  Is there any
reason to ship it disabled?

--dkg

> From 76072fa4cba00e6a6009324d6b9e0cf1d3fdc82f Mon Sep 17 00:00:00 2001
> From: Jeremy Visser 
> Date: Thu, 31 Aug 2017 11:53:00 +1000
> Subject: [PATCH] Fix broken systemd unit
>
> The ExecStart= line must be an absolute path as per systemd.service(5),
> but is currently a relative path. This change points it to
> /usr/bin/xscreensaver.
> ---
>  debian/xscreensaver.service | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/debian/xscreensaver.service b/debian/xscreensaver.service
> index 5e8f13d..c5298f2 100644
> --- a/debian/xscreensaver.service
> +++ b/debian/xscreensaver.service
> @@ -2,7 +2,7 @@
>  Description=XScreenSaver
>  
>  [Service]
> -ExecStart=xscreensaver
> +ExecStart=/usr/bin/xscreensaver
>  
>  [Install]
>  WantedBy=default.target
> -- 
> 2.14.1.581.gf28d330327-goog


signature.asc
Description: PGP signature

Bug#871698: upstream patch

[Benjamin Kaduk]

tags 871698 upstream pending
thanks

Upstream has committed a patch to use dynamic allocation to master at
https://github.com/krb5/krb5/pull/707 .
The backport is not entirely trivial, but we should be able to get
a version in (whether our own or upstream's) fairly soon.

-Ben

Bug#879839: ITP: xhtml2pdf -- A library for converting HTML into PDFs using ReportLab

[Drew Parsons]

Thanks Martin. Looking at the history on 
https://github.com/xhtml2pdf/xtml2pdfh, it got renamed from pisa to 
xhtml2pdf in 2010.

Anyway, we'll get it back into shape either way. Makes sense to keep it
in python-modules rather than debian-science.

Drew

On Thu, 2017-10-26 at 16:37 +0200, W. Martin Borgert wrote:
> Hi Drew,
> 
> many thanks for your ITP!
> 
> Note, that xhtml2pdf is known also as "pisa" - nobody so far could
> explain to me, why there is this upstream name confusion.
> 
> And pisa is in Debian: https://tracker.debian.org/pkg/pisa
> Unfortunately, pisa is not in a good state. It is not in testing,
> and did neither made it to stretch nor jessie. Python 3 support is
> needed, too.
> 
> Please feel free, to takeover the package or maintain it within the
> Python modules team. I'm also still interested in having the package
> in Debian, because of trac-wikiprint, but did not have the time nor
> energy to take care of the package.
> 
> I set Hugo in Cc, because he was also interested in helping.
> 
> Cheers
> 

Bug#879171: cups: failed to recognize a driver of CP310dm

[Atsuhito Kohda]

Hi Brian,

Sorry, I forgot to attach log.stretch.
Here it is.

Best regards,   2017-10-27(Fri)

-- 
 **
 Atsuhito Kohda
 Math. Meth. in Sci., Tokushima Univ.
 atsuhito_k AT tokushima-u.ac.jp
cupsfilter: File "/usr/lib/cups/filter/pdftopjlfx" permissions OK 
(040755/uid=0/gid=0).
cupsfilter: File "/usr/lib/cups/filter/pstopdffx" permissions OK 
(040755/uid=0/gid=0).
cupsfilter: File "/usr/lib/cups/filter/commandtops" permissions OK 
(040755/uid=0/gid=0).
cupsfilter: Unable to determine MIME type of "/etc/nsswitch".

Bug#862875: RFS: libzc/0.3.1-1 [ITP] -- fast zip cracking library

[Marc Ferland]

On Sun, Oct 15, 2017 at 9:12 PM, Adam Borowski  wrote:
>
> On Fri, Sep 15, 2017 at 10:47:29PM -0400, Marc Ferland wrote:
> > On Mon, Sep 11, 2017 at 4:09 PM, Andrey Rahmatullin  wrote:
> > > d/copyright says "License: GPL-3" instead of GPL-3+.
> > > lib/pthread_barrier.h and m4/ax_pthread.m4 should have separate entries in
> > > d/copyright.
> > > Otherwise the package looks good.
> >
> > Fixed d/copyright and other warnings reported by 'scan-copyright' with
> > latest version:
> >
> > https://mentors.debian.net/debian/pool/main/libz/libzc/libzc_0.3.5-1.dsc
>
> The package fails to build on most architectures, with a timeout in the
> testsuite:
>
...
> Running suite(s): reduce
> 66%: Checks: 3, Failures: 0, Errors: 1
> check_reduce.c:60:E:Core:test_can_generate_next_array_from_plaintext:0: 
> (after this point) Test timeout expired
> FAIL reduce (exit status: 1)

Some tests can take quite some time to finish. I've excluded those
from running when
doing an 'ordinary' make check. This fix and other small fixes are
available in the latest
version:

https://mentors.debian.net/debian/pool/main/libz/libzc/libzc_0.3.6-1.dsc

Regards,

Marc

Bug#879792: nvidia-detect: misses nvidia tesla p100 (GP100GL)

[Vincent McIntyre]

On Thu, Oct 26, 2017 at 11:47:00AM +0100, Luca Boccassi wrote:
>
> Hi,
>
> Is the Tesla series compatible with the Geforce series drivers that we
> package?
>
> They are sorted separately on Nvidia's website at least:
>
> http://www.nvidia.co.uk/download/driverResults.aspx/124885/en-uk
>
> But I've never used them so I'm not sure.
>

I'm a bit confused by this question. My understanding is that
nvidia-detect looks up the card PCI ID in the various
/usr/share/nvidia/*.ids files and reports a positive match.

Are you saying those files may contain IDs that aren't supported
by the drivers? How are those files maintained? I poked around
the repository briefly and it seems it's mostly manual edits,
which seems fine apart from the risk of the odd typo.

In this case the drivers you package (thank you!) do support the card,
so the *.ids files seem to have the correct information.

 $ dmesg|tail |sed -e 's/^[^ ]*//'
 nvidia: loading out-of-tree module taints kernel.
 nvidia: module license 'NVIDIA' taints kernel.
 Disabling lock debugging due to kernel taint
 nvidia-nvlink: Nvlink Core is being initialized, major device number 243
 NVRM: loading NVIDIA UNIX x86_64 Kernel Module  375.82  Wed Jul 19 21:16:49 
PDT 2017 (using threaded interrupts

 $ nvidia-smi
 Fri Oct 27 09:24:05 2017
 +-+
 | NVIDIA-SMI 375.82 Driver Version: 375.82|
 |---+--+--+
 | GPU  NamePersistence-M| Bus-IdDisp.A | Volatile Uncorr. ECC |
 | Fan  Temp  Perf  Pwr:Usage/Cap| Memory-Usage | GPU-Util  Compute M. |
 |===+==+==|
 |   0  Tesla P100-PCIE...  Off  | :04:00.0 Off |0 |
 | N/A   31CP026W / 250W |  0MiB / 16276MiB |  0%  Default |
 +---+--+--+
 |   1  Tesla P100-PCIE...  Off  | :82:00.0 Off |0 |
 | N/A   33CP027W / 250W |  0MiB / 16276MiB |  2%  Default |
 +---+--+--+

 +-+
 | Processes:   GPU Memory |
 |  GPU   PID  Type  Process name   Usage  |
 |=|
 |  No running processes found |
 +-+

Cheers
Vince

Bug#878013: reportbug: Gtk+ frontend doesn't start in MATE

[Bob Bib]

On Sun, 08 Oct 2017 11:54:22 -0300 "Doug S."  wrote:

Package: reportbug
Version: 7.1.7
...
Versions of packages reportbug suggests:
pn  claws-mail   
pn  debconf-utils
pn  debsums  
pn  dlocate  
pn  emacs24-bin-common | emacs25-bin-common  
ii  file 1:5.30-1+deb9u1
ii  gir1.2-gtk-3.0   3.22.11-1
pn  gir1.2-vte-2.91  
ii  gnupg2.1.18-8~deb9u1
pn  postfix | exim4 | mail-transport-agent   
ii  python3-gi   3.22.0-2
pn  python3-gi-cairo 
pn  python3-gtkspellcheck
pn  python3-urwid


Can you please try to install the following packages:
 gir1.2-vte-2.91 python3-gi-cairo
and recheck it?

(reportbug 7.* has started to use Python 3, so maybe it's just a missing 
dependencies problem).

--
Best wishes,
Bob

Bug#879727: debhelper: dh_systemd_start script fails to start new units when an existing unit is updated (LP#1707880)

[Felipe Sateler]

On Wed, Oct 25, 2017 at 3:19 AM, Niels Thykier  wrote:

> Imho, there should be an extra snippet in apt.postinst which does this:
>
> if [ -d /run/systemd/system ]; then
>  if dpkg --compare $2 with version that introduces apt-daily-upgrade.timer; 
> then
>  deb-systemd-invoke start apt-daily-upgrade.timer >/dev/null || true
>  fi
> fi
> """
>
> I am not entirely sure this can be solved in debhelper, so we may need
> some extra functionality from deb-systemd-invoke (as debhelper does
> not know when a service was introduced and when it wasn't).

Indeed, debhelper can't know. I see the following options:

1. Change the autoscripts to use restart instead of try-restart.
deb-systemd-invoke will still not start static/disabled units, but any
not running unit would start. This is basically how the
sysvinit/invoke-rc.d integration works.
2. Add an option to dh_systemd_start (and dh_installsystemd) to inject
the extra snippet, a la dpkg-maintscript-helper
3. Keep the installed units in a statefile somewhere so that
deb-systemd-invoke can do the right thing then told to try-restart a
new unit.

I think I prefer option 1, as it requires the least amount of work.
Tracking the versions a unit was shipped in sounds like over
engineering to me.

-- 

Saludos,
Felipe Sateler

Bug#706691: closed by Laurent Bigonville <bi...@debian.org> (Re: In rc0.d, sendsigs stops before rpcbind stops)

[Trent W. Buck]

FTR, the hosts where I had this problem now run Jessie & systemd.
nfs-utils 1.2.x under systemd is completely broken;
I had to write my own NFS units from scratch (inc. rpcbind, IIRC).

The end result is: my current bugs are new, and I don't care about this old one.
Your analysis that the real cause is probably #804670 sounds sensible.

(PS: FTR, nfs-utils 1.3 should Just Work under systemd, but
I haven't gotten around to testing it yet.)

> Date: Thu, 26 Oct 2017 19:01:38 +0200
> From: Laurent Bigonville 
> To: 706691-cl...@bugs.debian.org
> Subject: Re: In rc0.d, sendsigs stops before rpcbind stops
> Message-ID: <5eaf5b96-9f76-ca62-9951-a1bafa406...@debian.org>
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
>  Thunderbird/52.4.0
>
> On Fri, 3 May 2013 22:07:19 +1000 "Trent W. Buck" 
> wrote:
>
> > In a minimal live-boot image I built, I noticed that sendsigs was
> > running before all the NFS stuff was turned off.
>
> I know that this bug is really old, but there are something that I don't
> understand.
>
> The complete point of the "sendsigs.omit" is (was?) to avoid killing
> processes when the sendsigs is stopped.
>
> The fact that rpcbind is still running after sendsigs IS expected and
> rpcbind is stopped just after all the NFS file systems have been unmounted
> and the nfs-daemon are stopped.
>
> For me this is expected behavior. It's however possible that due to #804670,
> rpcbind is not killed when the **rpcbind** initscript returns, that will be
> fixed
>
> Feel free to reopen if the I misunderstood something.

Bug#877813: reprotest: regression between 0.7.1 and 0.7.2

[gregor herrmann]

On Thu, 26 Oct 2017 22:40:00 +, Ximin Luo wrote:

> gregor herrmann:
> > - reprotest called as 
> >   env -u TMPDIR -- reprotest --variations=+all,-build_path,-user_group 
> > --verbosity 1 . -- schroot default 2>&1 | [..]
> Thanks, this helped me reproduce the bug locally. I was having
> trouble before, because the bug only occurs when fileordering is
> switched on but user_group is not switched on.

Thanks, that's excellent news.
And sorry for not providing the command I used earlier.
 
> The bug is because disorderfs was being run as root inside the
> schroot, but the build was being run as the normal unprivileged
> user. This was because I was dropping privs in the wrong place,
> I've fixed in commit e367967, see if it works for you:
> https://anonscm.debian.org/git/reproducible/reprotest.git/commit/?id=e367967

I've now built a package from git HEAD (3efb86f), and .. hm .. I guess
this bug is fixed, it's just that I'm running into another issue
which seems related to another recent commit (the domain_host
feature):

#v+
INFO:root:build successful, copying artifacts
INFO:root:copying /tmp/reprotest.5Ab5ie/artifacts-control/ back from virtual 
server's /tmp/tmpo1_ukgqc/control
INFO:root:build "experiment-1": vary environment, FIX build_path, FIX 
user_group, vary fileordering, vary domain_host, vary home, vary kernel, vary 
locales, vary exec_path, vary time, vary timezone, vary umask
WARNING:root:Not using sudo for domain_host; it is recommended. Your build may 
fail.
WARNING:root:Be sure to `echo 1 > /proc/sys/kernel/unprivileged_userns_clone` 
if on a Debian system.
INFO:root:copying . over to virtual server's 
/tmp/reprotest.5Ab5ie/build-experiment-1/
INFO:root:starting build with source directory: 
/tmp/reprotest.5Ab5ie/build-experiment-1/, artifact pattern: ./../*.deb
Note, using directory './.' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
INFO:root:executing build in /tmp/reprotest.5Ab5ie/const_build_path/
unshare: unshare failed: ²»ÔÊÐíµIJÙ×÷
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 802, in run
return 0 if check_func(*check_args) else 1
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 351, in 
check
local_dists = [proc.send(nv) for nv in zip(bnames, build_variations)]
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 351, in 

local_dists = [proc.send(nv) for nv in zip(bnames, build_variations)]
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 317, in 
corun_builds
bctx.run_build(testbed, build, os.environ, artifact_pattern, 
testbed_build_pre, no_clean_on_error)
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 211, in 
run_build
kind='build')
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 63, in 
check_exec2
adtlog.AutopkgtestError)
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 69, in bomb
raise _type(m)
reprotest.lib.adtlog.AutopkgtestError: "su -s /bin/sh gregoa -c set -e; 
run_build() {
mkdir -p /tmp/reprotest.5Ab5ie/build-experiment-1-aux && \
mv /tmp/reprotest.5Ab5ie/build-experiment-1/ 
/tmp/reprotest.5Ab5ie/const_build_path && \
mv /tmp/reprotest.5Ab5ie/const_build_path/ 
/tmp/reprotest.5Ab5ie/const_build_path-before-disorderfs/ && \
mkdir -p /tmp/reprotest.5Ab5ie/const_build_path/ && \
disorderfs -q --shuffle-dirents=yes 
/tmp/reprotest.5Ab5ie/const_build_path-before-disorderfs/ 
/tmp/reprotest.5Ab5ie/const_build_path/ && \
umask 0002 && \
export REPROTEST_BUILD_PATH=/tmp/reprotest.5Ab5ie/const_build_path/ && \
export REPROTEST_UMASK=$(umask) && \
faketime +373days+7hours+13minutes \
linux32 \
unshare -r --uts sh -ec '
hostname reprotest-capture-hostname
domainname "reprotest-capture-domainname"
"$@"' - \
sh -ec 'cd "$REPROTEST_BUILD_PATH"; unset REPROTEST_BUILD_PATH; umask 
"$REPROTEST_UMASK"; unset REPROTEST_UMASK; dpkg-buildpackage --no-sign -b'
}

cleanup() {
__c=0; \
export PATH="/tmp/reprotest.5Ab5ie/bin:$PATH" || __c=$?; \
fusermount -u /tmp/reprotest.5Ab5ie/const_build_path/ || __c=$?; \
rmdir /tmp/reprotest.5Ab5ie/const_build_path/ || __c=$?; \
mv /tmp/reprotest.5Ab5ie/const_build_path-before-disorderfs/ 
/tmp/reprotest.5Ab5ie/const_build_path/ || __c=$?; \
mv /tmp/reprotest.5Ab5ie/const_build_path 
/tmp/reprotest.5Ab5ie/build-experiment-1/ || __c=$?; \
rm -rf /tmp/reprotest.5Ab5ie/build-experiment-1-aux || __c=$?; \
exit $__c
}

trap '( cleanup )' HUP INT QUIT ABRT TERM PIPE # FIXME doesn't quite work 
reliably yet

if ( run_build ); then ( cleanup ); else
__x=$?; # save the exit code of run_build
if ( ! false ); then
if ( cleanup ); then :; else echo >&2 "cleanup failed with exit code 
$?"; fi;
fi
exit 

Bug#878249: [PKG-Openstack-devel] Bug#878249: recent OVS upload

[Thomas Goirand]

Hi Ben,

On 10/27/2017 12:45 AM, Ben Pfaff wrote:
> Thanks for doing an upload.
> 
> Open vSwitch users expect to be able to build packages for whatever
> version of Open vSwitch they're using, which is most easily satisfied by
> keeping the Debian packaging with the rest of the tree.  Any other
> solution makes it harder to keep the code in sync with the packaging.
> Removing the debian directory would frustrate this.

You can simply rename it as "debian-upstream" or something. The other
way is to push the debian folder in a separate packaging branch.

I by the way saw a lot of differences between the Debian packaging and
the upstream one, which is a major issue, and the main reason why having
a debian folder upstream is a bad idea: there's 2 source of "truth", and
that should be avoided.

> I'm not a fan of the "dfsg" suffix because it implies that
> DFSG-noncompliant material was removed.  There is nothing
> DFSG-noncompliant about the Debian directory, it is simply inconvenient
> for the way you prefer to maintain the packaging.

Which is why I wrote a debian/README.source explaining the facts. Is
that enough for you? Alternatively, I could use "debian1", but I don't
think a lot of people will even notice, and even less, understand the
difference.

> I see a number of failed builds here:
> https://buildd.debian.org/status/package.php?p=openvswitch=experimental
> 
> Let me analyze them:
> 
> * mips, powerpc, and ppc64 should be fixed by this commit that is
>   already on branch-2.8:
>   https://github.com/openvswitch/ovs/commit/2906ff5e7eb1fb39b497dc05e471

I can incorporate this patch, no pb.

> * m68k is because of looser alignment rules than on other platforms.  I
>   don't care much about m68k, and it's not a Debian required platform,
>   so I don't plan to fix this.

Right, we shall not care.

> * sparc64 failures are due to bus errors.  I would like to investigate,
>   but I don't know how, because there is only one sparc64 machine listed
>   at https://db.debian.org/machines.cgi, and that machine appears to be
>   down (it is not accepting SSH connections at least when I tried just
>   now).

Sparc64 isn't an official port either. See here:
https://www.debian.org/ports/

I don't think we should care.

> * The ppc64el failure is a hang during the testsuite.  Test 2332, which
>   appears to be "ovn -- icmp_reply: 1 HVs, 2 LSs, 1 lport/LS, 1 LR",
>   hung.  I will try to reproduce and fix this.  Even if we do not fix
>   it, it might not recur in later runs, because it indicates a race
>   condition in the testsuite.  (This is almost certainly a bug in the
>   testsuite rather than in OVS itself.)

In such a case, I'd strongly suggest removing this unit test until
further investigation. Is that ok for you too?

> It has been my practice to package the tip of whatever release branch
> we're using, for example in this case to package from the tip of
> branch-2.8.  OVS release branches only accept bug fixes, so this works
> well for getting bug fixes that have not yet made it into an "official"
> release.  In this case, this would have picked up the fix that caused
> three of the builds to fail while running the testsuite.

Well, in such a case, I'd suggest upstream to release more bugfix
releases then! :)

> Thanks again,

My pleasure. I hope the other changes I made are ok with you. Did you
read the debian/changelog? I removed lots of binary packages that were
not technically needed, because that's best practice in Debian (ie: the
FTP masters recommend this). All of them have a Provides: equivalent.
This also simplifies packaging a lot (ie: all /usr/bin things and
manpages are going into openvswitch-common, etc.).

BTW, I always wanted to know: is there a way to do VXLan with OpenStack
and the OpenVSwitch plugin?

Cheers,

Thomas Goirand (zigo)

Bug#878691: please drop transitional package m17n-contrib

[Harshula]

Hi Holger,

Are you referring to m17n-db's

debian/control:
---
Package: m17n-contrib
Section: oldlibs
Priority: extra
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}, m17n-db (>= 1.6.3)
Description: transitional dummy package
 This is a transitional dummy package. It can safely be removed once
 no other package depends on it.
---

Thanks,
#

On 16/10/17 07:08, Holger Levsen wrote:
> Package: m17n-contrib
> Version: 1.7.0-2
> Severity: normal
> user: qa.debian@packages.debian.org
> usertags: transitional
> 
> Please drop the transitional package m17n-contrib for buster,
> as it has been released with jessie and stretch already.
> 
> Thanks for maintaining m17n-db!

Bug#856660: munin-plugins-c: Substitutions missing in manpage

[Matthias Schmitz]

package src:munin-c
tags 856660 + confirmed upstream
thanks

Hi, 

On Fri, 03 Mar 2017 13:43:33 +0100 Jerome Warnier
 wrote:
> Package: munin-plugins-c
> Version: 0.0.9-1
> Severity: minor


> The manpage is missing several substitutions.
> e.g.:
> @@pkglibexecdir@@/munin-plugins-c
it looks like the substitution never worked. 
I'll check how to fix this.

Best wishes,
Matthias


pgp_xGlIHI8Bg.pgp
Description: Digitale Signatur von OpenPGP

Bug#878249: recent OVS upload (was: Re: Bug#878249: Please package >= 2.7.0)

[Ben Pfaff]

On Fri, Oct 20, 2017 at 08:56:24PM +0200, Thomas Goirand wrote:
> I don't mind becoming a co-maintainer, though there's a few things that
> need to change to facilitate packaging. First of all, I'd like to switch
> to a Git packaging workflow, using git-buildpackage. The debian folder
> upstream here should be removed:
> 
> https://github.com/openvswitch/ovs/tree/master/debian
> 
> otherwise, it will clash with what we have in Alioth. Then I'll push
> openvswitch in the Alioth git repository under /git/third-party.
> 
> Also, I will remove the debian/automake.mk and the d/copyright hack.
> Indeed, Debian needs list of copyright holders, not authors.
> 
> Is that fine for you? I'm starting...

Thanks for doing an upload.

Open vSwitch users expect to be able to build packages for whatever
version of Open vSwitch they're using, which is most easily satisfied by
keeping the Debian packaging with the rest of the tree.  Any other
solution makes it harder to keep the code in sync with the packaging.
Removing the debian directory would frustrate this.

I'm not a fan of the "dfsg" suffix because it implies that
DFSG-noncompliant material was removed.  There is nothing
DFSG-noncompliant about the Debian directory, it is simply inconvenient
for the way you prefer to maintain the packaging.  Would you mind
choosing a different suffix?

I see a number of failed builds here:
https://buildd.debian.org/status/package.php?p=openvswitch=experimental

Let me analyze them:

* mips, powerpc, and ppc64 should be fixed by this commit that is
  already on branch-2.8:
  https://github.com/openvswitch/ovs/commit/2906ff5e7eb1fb39b497dc05e471

* m68k is because of looser alignment rules than on other platforms.  I
  don't care much about m68k, and it's not a Debian required platform,
  so I don't plan to fix this.

* sparc64 failures are due to bus errors.  I would like to investigate,
  but I don't know how, because there is only one sparc64 machine listed
  at https://db.debian.org/machines.cgi, and that machine appears to be
  down (it is not accepting SSH connections at least when I tried just
  now).

* The ppc64el failure is a hang during the testsuite.  Test 2332, which
  appears to be "ovn -- icmp_reply: 1 HVs, 2 LSs, 1 lport/LS, 1 LR",
  hung.  I will try to reproduce and fix this.  Even if we do not fix
  it, it might not recur in later runs, because it indicates a race
  condition in the testsuite.  (This is almost certainly a bug in the
  testsuite rather than in OVS itself.)

It has been my practice to package the tip of whatever release branch
we're using, for example in this case to package from the tip of
branch-2.8.  OVS release branches only accept bug fixes, so this works
well for getting bug fixes that have not yet made it into an "official"
release.  In this case, this would have picked up the fix that caused
three of the builds to fail while running the testsuite.

Thanks again,

Ben.

Bug#877233: libstdc++6: gnuplot crashed in libstdc++.so.6 (SIGSEGV)

[Vincent Lefevre]

On 2017-10-27 00:00:06 +0200, Matthias Klose wrote:
> closing this issue. Apparently it us unreproducible, also by upstream. Please
> feel free to reopen and adding instructions for a reproducer.

I still couldn't reproduce the bug. No issues detected by valgrind.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#877813: reprotest: regression between 0.7.1 and 0.7.2

[Ximin Luo]

gregor herrmann:
> [..]
> 
> So currently I have:
> 
> - reprotest called as 
>   env -u TMPDIR -- reprotest --variations=+all,-build_path,-user_group 
> --verbosity 1 . -- schroot default 2>&1 | [..]
> 

Thanks, this helped me reproduce the bug locally. I was having trouble before, 
because the bug only occurs when fileordering is switched on but user_group is 
not switched on.

The bug is because disorderfs was being run as root inside the schroot, but the 
build was being run as the normal unprivileged user. This was because I was 
dropping privs in the wrong place, I've fixed in commit e367967, see if it 
works for you:

https://anonscm.debian.org/git/reproducible/reprotest.git/commit/?id=e367967

(The bug didn't show up because the user_group variation has some hacks in it, 
to force the fileordering variation to run as the target user.)

> [..]
> 
> What I don't understand: The second build starts with:
> 
> [..]
> INFO:root:starting build with source directory: 
> /tmp/autopkgtest.tgbi5X/build-experiment-1/, artifact pattern: ./../*.deb
> ..
> INFO:root:executing build in /tmp/autopkgtest.tgbi5X/const_build_path/
> tail: Î޷¨´ò¿ª'debian/changelog' ¶ÁȡÊý¾: ȨÏ޲»¹»
> dpkg-buildpackage: error: tail of debian/changelog subprocess returned exit 
> status 1
> INFO:root:build successful, copying artifacts
> /bin/sh: 2: cd: can't cd to /tmp/autopkgtest.tgbi5X/build-experiment-1/
> 
> but there is no /tmp/autopkgtest.tgbi5X/build-experiment-1/ directory
> anywhere:
> 
> [..]

This is explained by the fact that reprotest moves stuff from 
build-experiment-1 to const_build_path, in order to run both builds in the same 
build path. The build failed, so reprotest didn't run the cleanup to move the 
directory back. Then, reprotest thought the build was successful (it says 
"INFO:root:build successful" in your log) so it tried to do more stuff with 
/tmp/autopkgtest.tgbi5X/build-experiment-1/, but it's not there because the 
build actually failed.

The fact that reprotest thought the build was successful, was a bug in 0.7.3 
with --no-clean-on-error that I just noticed, which I accidentally fixed in a 
refactoring just before I fixed this bug. The previous code was doing

if ( run_build ); then ( cleanup ); fi

but of course this doesn't preserve the non-zero exit code from run_build, duh. 
The fix for this is in git / will be in 0.7.4 as well.

X

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

Bug#879720: RFS: runescape/0.2-1 [QA] -- Multiplayer online game set in a fantasy world

[Carlos Donizete Froes]

Em qui, 2017-10-26 às 19:58 +0200, Tobias Frost escreveu:
> Ok, but you need to close the bug in the changelog then.
> See https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-b
> ugfix

Thanks a lot for the help. :)

> What's about the bug I filed? (#879784)
> I do not see it has been adressed...

Package in 'mentors.d.n'[1] are with bugs closed. (#866227) and (#879784)

[1] - https://mentors.debian.net/package/runescape

Thanks!

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

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

Bug#879784: runescape: Hardcoded temporary directory

[Carlos Donizete Froes]

> The script runescape.sh has a hardcoded temp directory (~/.rs-temp)  which
> will
> be created on demand and afterwards deleted again. As the name is hardcoded,
> there might be a collsision with an existing directory and user-data may be
> nuked on the cleanup.

Comment added in the line that does the script procedure.

This is a temporary directory where it will be created and this temporary
directory will be deleted next.

This procedure is since the first version of the package, has not changed.

Thanks!

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

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

Bug#879896: libopenvdb-dev should depend on libilmbase-dev

[P. J. Reed]

Package: libopenvdb-dev
Version: 2.1.0-1ubuntu1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I was attempting to compile a program that includes
/usr/include/openvdb/Types.h, which is provided by libopenvdb-dev.

   * What exactly did you do (or not do) that was effective (or ineffective)?

I installed libopenvdb-dev, wrote a program that included the previously
mentioned header, and attempted to compile it.

  * What was the outcome of this action?

It failed to compile because that header includes .  I
investigated and discovered that this header is provided by the package
libilmbase-dev, which is not depended on by libopenvdb-dev.

   * What outcome did you expect instead?

I would have expected all of libopenvdb-dev's dependencies to be installed as a
result of installing it.

Note: I am submitting this bug from an Ubuntu 14.04 computer, but have verified
that it exists in all versions of libopenvdb-dev in both Debian and Ubuntu.



-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-93-generic (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libopenvdb-dev depends on:
ii  libopenvdb2.1  2.1.0-1ubuntu1

libopenvdb-dev recommends no packages.

libopenvdb-dev suggests no packages.

-- no debconf information

Bug#873646: Pending fixes for bugs in the libcommons-modeler-java package

[pkg-java-maintainers]

tag 873646 + pending
thanks

Some bugs in the libcommons-modeler-java package are closed in
revision a267c1c975dd60ed093053d547006d93f1d47e48 in branch 'master'
by Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/libcommons-modeler-java.git/commit/?id=a267c1c

Commit message:

Fixed the build failure with Java 9 (Closes: #873646)

Bug#879821: libgles1-glvnd-nvidia:amd64: upgrade failure to 375.82-6

[Paddy Steed]

Why do I keep on getting these emails, please for the love of God someone
tell me how to unsubscribe from whatever nightmare list this is.

On 26 Oct 2017 11:57, "Vincent Lefevre"  wrote:

Package: libgles1-glvnd-nvidia
Version: 375.82-6
Severity: grave
Justification: renders package unusable

In the upgrade to 375.82-6:

Unpacking nvidia-kernel-dkms (375.82-6) over (375.82-5) ...
Preparing to unpack .../34-nvidia-legacy-check_375.82-6_amd64.deb ...
Unpacking nvidia-legacy-check (375.82-6) over (375.82-5) ...
Preparing to unpack .../35-nvidia-driver-libs-i386_375.82-6_i386.deb ...
Unpacking nvidia-driver-libs-i386:i386 (375.82-6) over (375.82-5) ...
Processing triggers for mime-support (3.60) ...
Setting up libnvidia-eglcore:amd64 (375.82-6) ...
Setting up libnvidia-eglcore:i386 (375.82-6) ...
Processing triggers for desktop-file-utils (0.23-2) ...
Setting up libnvidia-glcore:amd64 (375.82-6) ...
Setting up libnvidia-glcore:i386 (375.82-6) ...
Processing triggers for libc-bin (2.24-17) ...
Setting up nvidia-egl-common (375.82-6) ...
Setting up nvidia-vulkan-common (375.82-6) ...
Setting up nvidia-legacy-check (375.82-6) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up nvidia-alternative (375.82-6) ...
Processing triggers for nvidia-alternative (375.82-6) ...
Setting up libglx-nvidia0:amd64 (375.82-6) ...
Setting up nvidia-vulkan-icd:amd64 (375.82-6) ...
Setting up nvidia-kernel-support (375.82-6) ...
Setting up nvidia-vdpau-driver:amd64 (375.82-6) ...
Setting up libegl-nvidia0:amd64 (375.82-6) ...
Setting up libegl-nvidia0:i386 (375.82-6) ...
Setting up libgles-nvidia2:i386 (375.82-6) ...
Setting up libgles-nvidia2:amd64 (375.82-6) ...
Setting up libnvidia-cfg1:amd64 (375.82-6) ...
Setting up libnvidia-cfg1:i386 (375.82-6) ...
dpkg: dependency problems prevent configuration of
libgles1-glvnd-nvidia:amd64:
 libgles1-glvnd-nvidia:i386 (375.82-6) breaks libgles1 (>> 0) and is
unpacked but not configured.
  libgles1-glvnd-nvidia:amd64 (375.82-6) provides libgles1.

dpkg: error processing package libgles1-glvnd-nvidia:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of
libgles1-glvnd-nvidia:i386:
 libgles1-glvnd-nvidia:amd64 (375.82-6) breaks libgles1 (>> 0) and is
unpacked but not configured.
  libgles1-glvnd-nvidia:i386 (375.82-6) provides libgles1.

dpkg: error processing package libgles1-glvnd-nvidia:i386 (--configure):
 dependency problems - leaving unconfigured
Setting up nvidia-kernel-dkms (375.82-6) ...
[...]
Setting up libnvidia-ml1:amd64 (375.82-6) ...
dpkg: dependency problems prevent configuration of libgles-nvidia1:amd64:
 libgles-nvidia1:amd64 depends on libgles1 (>= 0.2.999) |
libgles1-glvnd-nvidia; however:
  Package libgles1 is not installed.
  Package libgles1-glvnd-nvidia:amd64 which provides libgles1 is not
configured yet.
  Package libgles1-glvnd-nvidia:amd64 is not configured yet.

dpkg: error processing package libgles-nvidia1:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libgles-nvidia1:i386:
 libgles-nvidia1:i386 depends on libgles1 (>= 0.2.999) |
libgles1-glvnd-nvidia; however:
  Package libgles1-glvnd-nvidia:i386 which provides libgles1 is not
configured yet.
  Package libgles1-glvnd-nvidia:i386 is not configured yet.

dpkg: error processing package libgles-nvidia1:i386 (--configure):
 dependency problems - leaving unconfigured
Setting up libgl1-nvidia-glvnd-glx:amd64 (375.82-6) ...
Setting up xserver-xorg-video-nvidia (375.82-6) ...
Setting up nvidia-driver-bin (375.82-6) ...
Setting up libglx-nvidia0:i386 (375.82-6) ...
Setting up nvidia-vulkan-icd:i386 (375.82-6) ...
Setting up nvidia-egl-icd:i386 (375.82-6) ...
Setting up nvidia-egl-icd:amd64 (375.82-6) ...
Setting up libgl1-nvidia-glvnd-glx:i386 (375.82-6) ...
Setting up nvidia-driver-libs:amd64 (375.82-6) ...
Setting up nvidia-driver-libs:i386 (375.82-6) ...
Setting up nvidia-driver (375.82-6) ...
Setting up nvidia-driver-libs-i386:i386 (375.82-6) ...
Processing triggers for glx-alternative-nvidia (0.8.0) ...
Processing triggers for libc-bin (2.24-17) ...
Processing triggers for update-glx (0.8.0) ...
Processing triggers for glx-alternative-nvidia (0.8.0) ...
Processing triggers for libc-bin (2.24-17) ...
Processing triggers for initramfs-tools (0.130) ...
update-initramfs: Generating /boot/initrd.img-4.13.0-1-amd64
Errors were encountered while processing:
 libgles1-glvnd-nvidia:amd64
 libgles1-glvnd-nvidia:i386
 libgles-nvidia1:amd64
 libgles-nvidia1:i386
[...]
E: Sub-process /usr/bin/dpkg returned an error code (1)
dpkg: dependency problems prevent configuration of
libgles1-glvnd-nvidia:amd64:
 libgles1-glvnd-nvidia:i386 (375.82-6) breaks libgles1 (>> 0) and is
unpacked but not configured.
  libgles1-glvnd-nvidia:amd64 (375.82-6) provides libgles1.

dpkg: error processing package libgles1-glvnd-nvidia:amd64 (--configure):
 dependency problems - leaving 

Bug#879821: libgles1-glvnd-nvidia:amd64: upgrade failure to 375.82-6

[Andreas Beckmann]

On 10/26/2017 11:13 PM, Rafał Olejnik wrote:
> Guess having amd64 and i386 might be a reason because on my sid i'm
> getting same error.

having both :amd64 and :i386 packages installed does not seem to work
properly with versioned Provides/Breaks in this special case.

minimal testcase is libgles1-glvnd-nvidia:amd64 +
libgles1-glvnd-nvidia:i386 in a minimal chroot (without
--install-recommends) that gets upgraded from buster to sid.

workaround should be

dpkg -r libgles1-glvnd-nvidia:amd64 libgles1-glvnd-nvidia:i386

(the mesa packages already dropped GLESv1 support)


Andreas

Bug#874264: dash: 'command -v' mistakenly returns a shell script whose executable is not set

[Sean Connor]

Package: dash
Version: 0.5.8-2.5
Severity: normal
Tags: patch

nyuszika7h  writes:

> Indeed, this behavior is certainly wrong and is in violation of the
> POSIX standard.

Is there a reason why the ifdef-outted checks on st_mode
shouldn't be replaced by one call to access(2)?

I've attached a simple patch.

--
Sean Connor
sconnor...@allyinics.org
diff -u dash-0.5.8/debian/changelog dash-0.5.8/debian/changelog
--- dash-0.5.8/debian/changelog
+++ dash-0.5.8/debian/changelog
@@ -1,3 +1,11 @@
+dash (0.5.8-2.6) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use access(2) to determine if files in path are executable. (closes:
+#874264).
+
+ -- Sean Connor   Thu, 26 Oct 2017 14:10:44 -0400
+
 dash (0.5.8-2.5) unstable; urgency=low
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- dash-0.5.8.orig/patches/fix-find_command.patch
+++ dash-0.5.8/patches/fix-find_command.patch
@@ -0,0 +1,28 @@
+Index: dash-0.5.8/src/exec.c
+===
+--- dash-0.5.8.orig/src/exec.c	2017-10-26 15:31:00.491931222 -0400
 dash-0.5.8/src/exec.c	2017-10-26 15:31:12.103931539 -0400
+@@ -409,20 +409,10 @@
+ 			stunalloc(fullname);
+ 			goto success;
+ 		}
+-#ifdef notdef
+-		/* XXX this code stops root executing stuff, and is buggy
+-		   if you need a group from the group list. */
+-		if (statb.st_uid == geteuid()) {
+-			if ((statb.st_mode & 0100) == 0)
+-goto loop;
+-		} else if (statb.st_gid == getegid()) {
+-			if ((statb.st_mode & 010) == 0)
+-goto loop;
+-		} else {
+-			if ((statb.st_mode & 01) == 0)
+-goto loop;
++		if (access(fullname, X_OK))
++		{
++			goto loop;
+ 		}
+-#endif
+ 		TRACE(("searchexec \"%s\" returns \"%s\"\n", name, fullname));
+ 		if (!updatetbl) {
+ 			entry->cmdtype = CMDNORMAL;
only in patch2:
unchanged:
--- dash-0.5.8.orig/patches/series
+++ dash-0.5.8/patches/series
@@ -0,0 +1 @@
+fix-find_command.patch

Bug#871108: munin-c: FTBFS: threads.c:62:30: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 250 [-Werror=format-truncation=]

[Matthias Schmitz]

package munin-c
tags 871108 + confirmed fixed-upstream
thanks


On Sun, 6 Aug 2017 17:31:20 -0400 Lucas Nussbaum 
wrote:
> Source: munin-c
> Version: 0.0.9-1
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20170805 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks for the report. The issue is already fixed upstream. I'll check
if upstream releases a new version soon and if not i'll add a patch to
the actual package. 

Best wishes,
Matthias


pgp31JzTW0C3p.pgp
Description: Digitale Signatur von OpenPGP

Bug#878207: [Pkg-graphite-maint] Bug#878207: graphite-web: Migration files missing

[Lee Begg]

Ok. Obviously I didn't read the README.Debian file closely enough. I had 
missed the --run-syncdb option from the graphite-manage migrate command. 
I have it working correctly now. Sorry about this noise.


Regards

Lee


On 17/10/17 22:38, Jonas Genannt wrote:

Hello,


I'm using the testing packages for graphite/carbon on stable. The
testing and unstable versions are the same (at this time).

ok, so we are using the same Django version.


If you have a django database created by an earlier version, then the
app works, but with a completely fresh install, the django database
for graphite-web is created without the graphite web model tables.

how did you run the migrations, with which command?

Because I have tested it with a sqlite database it worked fine. (fresh
installation into a new vagrant box)

What database do you use?

Greets,
Jonas

Bug#879821: libgles1-glvnd-nvidia:amd64: upgrade failure to 375.82-6

[Rafał Olejnik]

On Thu, 26 Oct 2017 21:57:40 +0100 Luca Boccassi  wrote:
> On Thu, 2017-10-26 at 12:55 +0200, Vincent Lefevre wrote:
> > Package: libgles1-glvnd-nvidia
> > Version: 375.82-6
> > Severity: grave
> > Justification: renders package unusable
> >
> > In the upgrade to 375.82-6:
> >
> > Unpacking nvidia-kernel-dkms (375.82-6) over (375.82-5) ...
> > Preparing to unpack .../34-nvidia-legacy-check_375.82-6_amd64.deb ...
> > Unpacking nvidia-legacy-check (375.82-6) over (375.82-5) ...
> > Preparing to unpack .../35-nvidia-driver-libs-i386_375.82-6_i386.deb
> > ...
> > Unpacking nvidia-driver-libs-i386:i386 (375.82-6) over (375.82-5) ...
> > Processing triggers for mime-support (3.60) ...
> > Setting up libnvidia-eglcore:amd64 (375.82-6) ...
> > Setting up libnvidia-eglcore:i386 (375.82-6) ...
> > Processing triggers for desktop-file-utils (0.23-2) ...
> > Setting up libnvidia-glcore:amd64 (375.82-6) ...
> > Setting up libnvidia-glcore:i386 (375.82-6) ...
> > Processing triggers for libc-bin (2.24-17) ...
> > Setting up nvidia-egl-common (375.82-6) ...
> > Setting up nvidia-vulkan-common (375.82-6) ...
> > Setting up nvidia-legacy-check (375.82-6) ...
> > Processing triggers for man-db (2.7.6.1-2) ...
> > Setting up nvidia-alternative (375.82-6) ...
> > Processing triggers for nvidia-alternative (375.82-6) ...
> > Setting up libglx-nvidia0:amd64 (375.82-6) ...
> > Setting up nvidia-vulkan-icd:amd64 (375.82-6) ...
> > Setting up nvidia-kernel-support (375.82-6) ...
> > Setting up nvidia-vdpau-driver:amd64 (375.82-6) ...
> > Setting up libegl-nvidia0:amd64 (375.82-6) ...
> > Setting up libegl-nvidia0:i386 (375.82-6) ...
> > Setting up libgles-nvidia2:i386 (375.82-6) ...
> > Setting up libgles-nvidia2:amd64 (375.82-6) ...
> > Setting up libnvidia-cfg1:amd64 (375.82-6) ...
> > Setting up libnvidia-cfg1:i386 (375.82-6) ...
> > dpkg: dependency problems prevent configuration of libgles1-glvnd-
> > nvidia:amd64:
> >  libgles1-glvnd-nvidia:i386 (375.82-6) breaks libgles1 (>> 0) and is
> > unpacked but not configured.
> >   libgles1-glvnd-nvidia:amd64 (375.82-6) provides libgles1.
> >
> > dpkg: error processing package libgles1-glvnd-nvidia:amd64 (
> > --configure):
> >  dependency problems - leaving unconfigured
> > dpkg: dependency problems prevent configuration of libgles1-glvnd-
> > nvidia:i386:
> >  libgles1-glvnd-nvidia:amd64 (375.82-6) breaks libgles1 (>> 0) and is
> > unpacked but not configured.
> >   libgles1-glvnd-nvidia:i386 (375.82-6) provides libgles1.
> >
> > dpkg: error processing package libgles1-glvnd-nvidia:i386 (
> > --configure):
> >  dependency problems - leaving unconfigured
> > Setting up nvidia-kernel-dkms (375.82-6) ...
> > [...]
> > Setting up libnvidia-ml1:amd64 (375.82-6) ...
> > dpkg: dependency problems prevent configuration of libgles-
> > nvidia1:amd64:

Guess having amd64 and i386 might be a reason because on my sid i'm 
getting same error.

Bug#879821: libgles1-glvnd-nvidia:amd64: upgrade failure to 375.82-6

[quentin . caillard]

Same bug here

dpkg: des problèmes de dépendances empêchent la configuration de
libgles1-glvnd-nvidia:i386 :
 libgles1-glvnd-nvidia:amd64 (375.82-6) casse libgles1 (>> 0) et est
dépaqueté mais non configuré.
libgles1-glvnd-nvidia:i386 (375.82-6) fournit libgles1.

dpkg: erreur de traitement du paquet libgles1-glvnd-nvidia:i386 (
--configure) :
 problèmes de dépendances - laissé non configuré
dpkg: des problèmes de dépendances empêchent la configuration de
libgles1-glvnd-nvidia:amd64 :
 libgles1-glvnd-nvidia:i386 (375.82-6) casse libgles1 (>> 0) et est
dépaqueté mais non configuré.
libgles1-glvnd-nvidia:amd64 (375.82-6) fournit libgles1.

dpkg: erreur de traitement du paquet libgles1-glvnd-nvidia:amd64 (
--configure) :
 problèmes de dépendances - laissé non configuré
dpkg: des problèmes de dépendances empêchent la configuration de
libgles-nvidia1:i386 :
 libgles-nvidia1:i386 dépend de libgles1 (>= 0.2.999) | libgles1-glvnd-
nvidia ; cependant :
  Le paquet libgles1-glvnd-nvidia:i386 qui fournit libgles1 n'est pas
encore configuré.
 Le paquet libgles1-glvnd-nvidia:i386 n'est pas encore configuré.

dpkg: erreur de traitement du paquet libgles-nvidia1:i386 (
--configure) :
 problèmes de dépendances - laissé non configuré
dpkg: des problèmes de dépendances empêchent la configuration de
libgles-nvidia1:amd64 :
 libgles-nvidia1:amd64 dépend de libgles1 (>= 0.2.999) | libgles1-
glvnd-nvidia ; cependant :
  Le paquet libgles1 n'est pas installé.
  Le paquet libgles1-glvnd-nvidia:amd64 qui fournit libgles1 n'est pas
encore configuré.
 Le paquet libgles1-glvnd-nvidia:amd64 n'est pas encore configuré.

dpkg: erreur de traitement du paquet libgles-nvidia1:amd64 (
--configure) :
 problèmes de dépendances - laissé non configuré
Des erreurs ont été rencontrées pendant l'exécution :
 libgles1-glvnd-nvidia:i386
 libgles1-glvnd-nvidia:amd64
 libgles-nvidia1:i386
 libgles-nvidia1:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

I have i386 packages installed.

On Thu, 26 Oct 2017 21:57:40 +0100 Luca Boccassi 
wrote:
> On Thu, 2017-10-26 at 12:55 +0200, Vincent Lefevre wrote:
> > Package: libgles1-glvnd-nvidia
> > Version: 375.82-6
> > Severity: grave
> > Justification: renders package unusable
> > 
> > In the upgrade to 375.82-6:
> > 
> > Unpacking nvidia-kernel-dkms (375.82-6) over (375.82-5) ...
> > Preparing to unpack .../34-nvidia-legacy-check_375.82-6_amd64.deb
...
> > Unpacking nvidia-legacy-check (375.82-6) over (375.82-5) ...
> > Preparing to unpack .../35-nvidia-driver-libs-i386_375.82-
6_i386.deb
> > ...
> > Unpacking nvidia-driver-libs-i386:i386 (375.82-6) over (375.82-5)
...
> > Processing triggers for mime-support (3.60) ...
> > Setting up libnvidia-eglcore:amd64 (375.82-6) ...
> > Setting up libnvidia-eglcore:i386 (375.82-6) ...
> > Processing triggers for desktop-file-utils (0.23-2) ...
> > Setting up libnvidia-glcore:amd64 (375.82-6) ...
> > Setting up libnvidia-glcore:i386 (375.82-6) ...
> > Processing triggers for libc-bin (2.24-17) ...
> > Setting up nvidia-egl-common (375.82-6) ...
> > Setting up nvidia-vulkan-common (375.82-6) ...
> > Setting up nvidia-legacy-check (375.82-6) ...
> > Processing triggers for man-db (2.7.6.1-2) ...
> > Setting up nvidia-alternative (375.82-6) ...
> > Processing triggers for nvidia-alternative (375.82-6) ...
> > Setting up libglx-nvidia0:amd64 (375.82-6) ...
> > Setting up nvidia-vulkan-icd:amd64 (375.82-6) ...
> > Setting up nvidia-kernel-support (375.82-6) ...
> > Setting up nvidia-vdpau-driver:amd64 (375.82-6) ...
> > Setting up libegl-nvidia0:amd64 (375.82-6) ...
> > Setting up libegl-nvidia0:i386 (375.82-6) ...
> > Setting up libgles-nvidia2:i386 (375.82-6) ...
> > Setting up libgles-nvidia2:amd64 (375.82-6) ...
> > Setting up libnvidia-cfg1:amd64 (375.82-6) ...
> > Setting up libnvidia-cfg1:i386 (375.82-6) ...
> > dpkg: dependency problems prevent configuration of libgles1-glvnd-
> > nvidia:amd64:
> >  libgles1-glvnd-nvidia:i386 (375.82-6) breaks libgles1 (>> 0) and
is
> > unpacked but not configured.
> >   libgles1-glvnd-nvidia:amd64 (375.82-6) provides libgles1.
> > 
> > dpkg: error processing package libgles1-glvnd-nvidia:amd64 (
> > --configure):
> >  dependency problems - leaving unconfigured
> > dpkg: dependency problems prevent configuration of libgles1-glvnd-
> > nvidia:i386:
> >  libgles1-glvnd-nvidia:amd64 (375.82-6) breaks libgles1 (>> 0) and
is
> > unpacked but not configured.
> >   libgles1-glvnd-nvidia:i386 (375.82-6) provides libgles1.
> > 
> > dpkg: error processing package libgles1-glvnd-nvidia:i386 (
> > --configure):
> >  dependency problems - leaving unconfigured
> > Setting up nvidia-kernel-dkms (375.82-6) ...
> > [...]
> > Setting up libnvidia-ml1:amd64 (375.82-6) ...
> > dpkg: dependency problems prevent configuration of libgles-
> > nvidia1:amd64:

Bug#879895: virtualbox-guest-dkms: vboxvideo doesn't build for 4.13 kernel

[James McCoy]

Package: virtualbox-guest-dkms
Version: 5.2.0-dfsg-1
Severity: important

Now that virtualbox 5.2 is in unstable, I would expect it to build
against the kernel that is in unstable.  However, 5.2 explicitly
disables building vboxvideo if drm_rect.h is present in the kernel that
it's building against.

>From /var/lib/dkms/virtualbox-guest/5.2.0/build/vboxvideo/Makefile:

# We want to build on Linux 3.11 and later, plus the 3.10 EL 7.3 and later
# kernels.  This file was added in 3.11 and back-ported to the EL 7.3 
kernel.
ifeq ($(wildcard $(KERN_INCL)/drm/drm_rect.h),)
 BUILD =
endif

$ dpkg -S drm_rect.h
linux-headers-4.13.0-1-common: 
/usr/src/linux-headers-4.13.0-1-common/include/drm/drm_rect.h
linux-headers-4.12.0-2-common: 
/usr/src/linux-headers-4.12.0-2-common/include/drm/drm_rect.h

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

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

Versions of packages virtualbox-guest-dkms depends on:
ii  dkms2.3-3
ii  virtualbox-guest-utils  5.2.0-dfsg-1

virtualbox-guest-dkms recommends no packages.

virtualbox-guest-dkms suggests no packages.

-- no debconf information

Bug#879821: libgles1-glvnd-nvidia:amd64: upgrade failure to 375.82-6

[Luca Boccassi]

On Thu, 2017-10-26 at 12:55 +0200, Vincent Lefevre wrote:
> Package: libgles1-glvnd-nvidia
> Version: 375.82-6
> Severity: grave
> Justification: renders package unusable
> 
> In the upgrade to 375.82-6:
> 
> Unpacking nvidia-kernel-dkms (375.82-6) over (375.82-5) ...
> Preparing to unpack .../34-nvidia-legacy-check_375.82-6_amd64.deb ...
> Unpacking nvidia-legacy-check (375.82-6) over (375.82-5) ...
> Preparing to unpack .../35-nvidia-driver-libs-i386_375.82-6_i386.deb
> ...
> Unpacking nvidia-driver-libs-i386:i386 (375.82-6) over (375.82-5) ...
> Processing triggers for mime-support (3.60) ...
> Setting up libnvidia-eglcore:amd64 (375.82-6) ...
> Setting up libnvidia-eglcore:i386 (375.82-6) ...
> Processing triggers for desktop-file-utils (0.23-2) ...
> Setting up libnvidia-glcore:amd64 (375.82-6) ...
> Setting up libnvidia-glcore:i386 (375.82-6) ...
> Processing triggers for libc-bin (2.24-17) ...
> Setting up nvidia-egl-common (375.82-6) ...
> Setting up nvidia-vulkan-common (375.82-6) ...
> Setting up nvidia-legacy-check (375.82-6) ...
> Processing triggers for man-db (2.7.6.1-2) ...
> Setting up nvidia-alternative (375.82-6) ...
> Processing triggers for nvidia-alternative (375.82-6) ...
> Setting up libglx-nvidia0:amd64 (375.82-6) ...
> Setting up nvidia-vulkan-icd:amd64 (375.82-6) ...
> Setting up nvidia-kernel-support (375.82-6) ...
> Setting up nvidia-vdpau-driver:amd64 (375.82-6) ...
> Setting up libegl-nvidia0:amd64 (375.82-6) ...
> Setting up libegl-nvidia0:i386 (375.82-6) ...
> Setting up libgles-nvidia2:i386 (375.82-6) ...
> Setting up libgles-nvidia2:amd64 (375.82-6) ...
> Setting up libnvidia-cfg1:amd64 (375.82-6) ...
> Setting up libnvidia-cfg1:i386 (375.82-6) ...
> dpkg: dependency problems prevent configuration of libgles1-glvnd-
> nvidia:amd64:
>  libgles1-glvnd-nvidia:i386 (375.82-6) breaks libgles1 (>> 0) and is
> unpacked but not configured.
>   libgles1-glvnd-nvidia:amd64 (375.82-6) provides libgles1.
> 
> dpkg: error processing package libgles1-glvnd-nvidia:amd64 (
> --configure):
>  dependency problems - leaving unconfigured
> dpkg: dependency problems prevent configuration of libgles1-glvnd-
> nvidia:i386:
>  libgles1-glvnd-nvidia:amd64 (375.82-6) breaks libgles1 (>> 0) and is
> unpacked but not configured.
>   libgles1-glvnd-nvidia:i386 (375.82-6) provides libgles1.
> 
> dpkg: error processing package libgles1-glvnd-nvidia:i386 (
> --configure):
>  dependency problems - leaving unconfigured
> Setting up nvidia-kernel-dkms (375.82-6) ...
> [...]
> Setting up libnvidia-ml1:amd64 (375.82-6) ...
> dpkg: dependency problems prevent configuration of libgles-
> nvidia1:amd64:
>  libgles-nvidia1:amd64 depends on libgles1 (>= 0.2.999) | libgles1-
> glvnd-nvidia; however:
>   Package libgles1 is not installed.
>   Package libgles1-glvnd-nvidia:amd64 which provides libgles1 is not
> configured yet.
>   Package libgles1-glvnd-nvidia:amd64 is not configured yet.
> 
> dpkg: error processing package libgles-nvidia1:amd64 (--configure):
>  dependency problems - leaving unconfigured
> dpkg: dependency problems prevent configuration of libgles-
> nvidia1:i386:
>  libgles-nvidia1:i386 depends on libgles1 (>= 0.2.999) | libgles1-
> glvnd-nvidia; however:
>   Package libgles1-glvnd-nvidia:i386 which provides libgles1 is not
> configured yet.
>   Package libgles1-glvnd-nvidia:i386 is not configured yet.
> 
> dpkg: error processing package libgles-nvidia1:i386 (--configure):
>  dependency problems - leaving unconfigured
> Setting up libgl1-nvidia-glvnd-glx:amd64 (375.82-6) ...
> Setting up xserver-xorg-video-nvidia (375.82-6) ...
> Setting up nvidia-driver-bin (375.82-6) ...
> Setting up libglx-nvidia0:i386 (375.82-6) ...
> Setting up nvidia-vulkan-icd:i386 (375.82-6) ...
> Setting up nvidia-egl-icd:i386 (375.82-6) ...
> Setting up nvidia-egl-icd:amd64 (375.82-6) ...
> Setting up libgl1-nvidia-glvnd-glx:i386 (375.82-6) ...
> Setting up nvidia-driver-libs:amd64 (375.82-6) ...
> Setting up nvidia-driver-libs:i386 (375.82-6) ...
> Setting up nvidia-driver (375.82-6) ...
> Setting up nvidia-driver-libs-i386:i386 (375.82-6) ...
> Processing triggers for glx-alternative-nvidia (0.8.0) ...
> Processing triggers for libc-bin (2.24-17) ...
> Processing triggers for update-glx (0.8.0) ...
> Processing triggers for glx-alternative-nvidia (0.8.0) ...
> Processing triggers for libc-bin (2.24-17) ...
> Processing triggers for initramfs-tools (0.130) ...
> update-initramfs: Generating /boot/initrd.img-4.13.0-1-amd64
> Errors were encountered while processing:
>  libgles1-glvnd-nvidia:amd64
>  libgles1-glvnd-nvidia:i386
>  libgles-nvidia1:amd64
>  libgles-nvidia1:i386
> [...]
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> dpkg: dependency problems prevent configuration of libgles1-glvnd-
> nvidia:amd64:
>  libgles1-glvnd-nvidia:i386 (375.82-6) breaks libgles1 (>> 0) and is
> unpacked but not configured.
>   libgles1-glvnd-nvidia:amd64 (375.82-6) provides libgles1.
> 
> dpkg: error processing package 

Bug#877684: Bug#879894: ITP: snapd-glib -- GLib snapd library

[Jeremy Bicha]

Control: block -1 by 879894
Control: unblock -1 by 876862

I have filed the ITP for snapd-glib
https://bugs.debian.org/879894

Thanks,
Jeremy Bicha

Bug#879714: ITP: libusbauth-configparser1 -- Library for USB Firewall including flex/bison parser

[Ben Hutchings]

On Wed, 2017-10-25 at 00:44 +0200, Stefan Koch wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Stefan Koch 
> 
> * Package name: libusbauth-configparser1
>   Version : 1.0
>   Upstream Author : Stefan Koch 
> * URL : https://github.com/kochstefan/usbauth-all/libusba
> uth-configparser
> * License : LGPL-2.1
>   Programming Lang: C
>   Description : Library for USB Firewall including flex/bison
> parser
> 
> The library is used to read the usbauth config file into data
> structures and is used by usbauth and YaST.
> 
> This work was initially created for SUSE in 2015. Part of it was the
> USB interface authorization for the Linux kernel. It's contained in
> Linux since kernel version 4.4.
> Please add the packages libusbauth-configparser, usbauth, usbauth-
> notifier to debian unstable.

You titled this as an ITP (Intent To Package) but this sentence makes
it sound like an RFP (Request For Package).  Which is it?

Ben.

> See also: openSUSE package request
> (https://build.opensuse.org/request/show/533512)
> 
-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow
Lindberg



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

Bug#879894: ITP: snapd-glib -- GLib snapd library

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org
Owner: jbi...@debian.org

Package Name: snapd-glib
Version: 1.24
Upstream Authors : Canonical LTD
License : LGPL-2 or LGPL-3
Programming Lang: C and C++

Description: GLib snapd library
 snapd-glib is a library to allow GLib based applications access to snapd,
 the daemon that controls Snaps.
 .
 Snaps are 'universal' packages that work across many different Linux
 systems, enabling secure distribution of the latest apps and utilities
 for cloud, servers, desktops and the internet of things.

The package also contains a login service and libraries for Qt/QML apps.

Other Info
--
snapd-glib is required for the Snap plugin to be re-enabled in
Debian's GNOME Software package.
https://bugs.debian.org/877684

This package will be maintained under the umbrella of the pkg-ayatana team.

Packaging is at
https://anonscm.debian.org/git/pkg-ayatana/snapd-glib.git

Thanks,
Jeremy Bicha

Bug#859841: zurl: Please migrate to openssl1.1 in Buster

[Jan Niehusmann]

block 859841 by 858398 859671
thanks

On Thu, Oct 12, 2017 at 11:44:44PM +0200, Sebastian Andrzej Siewior wrote:
> this is a remainder about the openssl transition [0]. We really want to
> remove libssl1.0-dev from unstable for Buster. I will raise the severity
> of this bug to serious in a month. Please react before that happens.

I'd really like to react, and in fact zurl is compatible with openssl
1.1, and was already built against it with version 1.7.1-3 in January.

Unfortunately, it depends on curl and qt5 to migrate as well. So it had
to revert to openssl 1.0 (Bug#850881), and fixing this is blocked by
Bug#858398 and Bug#859671.

For qt5, it looks like an upgrade can be expected around the end of this
year: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859671#24

So I think rainsing the severity of this bug in November is too early,
as it doesn't seem to be possible to reasonably fix the bug by then.

Jan

Bug#879893: Search on web returns Internal Server Error

[Ondrej Tuma]

Package: lists.debian.org
Severity: normal

Hi,

i try to search 'pyversions' in archive of debian-pyt...@lists.debian.org, but
i got classic
Apache Internal Server Error.

The url, which i try is:
https://lists.debian.org/cgi-bin/search?P=pyversions=or=Gdebian-
python==10

McBig

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8),
LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8)

Bug#879892: [groovy] No menu entry for groovyConsole

[Dirk Heinrichs]

Package: groovy
Version: 2.4.8-1
Severity: normal

--- Please enter the report below this line. ---
groovy installs a graphical Groovy script console
(/usr/bin/groovyConsole), but there's no menu entry for it, so it has to
be started via shell.

--- System information. ---
Architecture: Kernel:   Linux 4.13.0-0.bpo.1-amd64

Debian Release: 9.1
  600 stretch-backports vwakviie2ienjx6t.onion   500 syncthing
apt.syncthing.net   500 stable  vwakviie2ienjx6t.onion   500
stable  sgvtcaew4bxjd7ln.onion   500 stable  dl.google.com
--- Package information. ---
Depends  (Version) | Installed
==-+-===
antlr  | 2.7.7+dfsg-7
default-jre-headless   | 2:1.8-58
 OR java6-runtime-headless | ivy | 2.4.0-3
junit4 | 4.12-4
libasm-java   (>= 5.0) | 5.2-2
libbsf-java| 1:2.4.0-5
libcommons-cli-java| 1.3.1-3
libcommons-logging-java| 1.2-1
libjansi-java  | 1.14-1
libjline2-java | 2.11-4
libqdox-java   | 1.12.1-2
libservlet3.1-java | 8.5.14-1+deb9u2
libxstream-java| 1.4.9-2


Recommends(Version) | Installed
===-+-===
ant | 1.9.9-1
ant-optional| 1.9.9-1
libgpars-groovy-java  (>= 1.0~) | 1.2.1-7
libjcommander-java  | 1.48-1
testng  | 6.9.12-1


Suggests(Version) | Installed
=-+-===
groovy-doc|
-- 
Dirk Heinrichs 
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de



signature.asc
Description: OpenPGP digital signature

Bug#879538: mandos: (tries to) use GnuTLS OpenPGP support

[Teddy Hogeborn]

Andreas Metzler  writes:

> plugins.d/mandos-client.c actually uses GnuTLS OpenPGP support. This
> code was marked deprecated in 3.5.9 and was removed in 3.6.0. Noop stub
> functions are still shipped to avoid ABI breakage but return 
> GNUTLS_E_UNIMPLEMENTED_FEATURE.
>
> Please drop GnuTLS OpenPGP support in mandos.

We can't do that, it's an integral part of the Mandos client/server
network protocol; removing it would entail creating an entirely new
incompatible protocol.  We plan to do that using a feature not yet
available in GnuTLS called "raw public keys" (RFC7250), but its
developer has not merged it to GnuTLS upstream yet.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#879890: mark libkf5sysguard-data Multi-Arch: foreign

[Helmut Grohne]

Package: libkf5sysguard-data
Version: 4:5.10.5-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:kdeplasma-addons src:kdevelop src:ksysguard 
src:plasma-desktop src:plasma-workspace

The affected packages cannot satisfy their cross build dependencies,
because their dependency on libkf5sysguard-data is unsatisfiable. In
general, Architecture: all packages can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign. In this case, such a
marking is correct, because the package is Architecture: all and it
doesn't have any dependencies nor maintainer scripts. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru libksysguard-5.10.5/debian/changelog 
libksysguard-5.10.5/debian/changelog
--- libksysguard-5.10.5/debian/changelog2017-09-03 09:55:34.0 
+0200
+++ libksysguard-5.10.5/debian/changelog2017-10-26 21:49:40.0 
+0200
@@ -1,3 +1,10 @@
+libksysguard (4:5.10.5-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libkf5sysguard-data Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 26 Oct 2017 21:49:40 +0200
+
 libksysguard (4:5.10.5-2) sid; urgency=medium
 
   * New revision
diff --minimal -Nru libksysguard-5.10.5/debian/control 
libksysguard-5.10.5/debian/control
--- libksysguard-5.10.5/debian/control  2017-09-03 09:55:34.0 +0200
+++ libksysguard-5.10.5/debian/control  2017-10-26 21:49:37.0 +0200
@@ -47,6 +47,7 @@
 
 Package: libkf5sysguard-data
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Breaks: ksysguard (<< 4:5.0.0),
 libkf5sysguard-bin (<< 4:5.0.95),

Bug#879891: libdevice-cdio-perl: FTBFS against libcdio-dev 0.92

[gregor herrmann]

Source: libdevice-cdio-perl
Version: 0.3.0-6
Severity: important
Tags: upstream sid buster
Justification: fails to build from source (but built successfully in the past)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As first noted on Ubuntu (thanks to doko), libdevice-cdio-perl fails
to build with newer version of libcdio-dev, as 0.92-2 in
Debian/experimantal:

Ubuntu:https://launchpadlibrarian.net/343077055/buildlog_ubuntu-bionic-amd64.libdevice-cdio-perl_0.3.0-6build2_BUILDING.txt.gz

Debian/experimental:

dh_auto_build
perl Build
Building Device-Cdio
Copying lib/Device/Cdio.pm -> blib/lib/Device/Cdio.pm
Copying lib/Device/Cdio/Device.pm -> blib/lib/Device/Cdio/Device.pm
Copying lib/Device/Cdio/ISO9660.pm -> blib/lib/Device/Cdio/ISO9660.pm
Copying lib/Device/Cdio/ISO9660/FS.pm -> blib/lib/Device/Cdio/ISO9660/FS.pm
Copying lib/Device/Cdio/ISO9660/IFS.pm -> blib/lib/Device/Cdio/ISO9660/IFS.pm
Copying lib/Device/Cdio/Track.pm -> blib/lib/Device/Cdio/Track.pm
Copying lib/Device/Cdio/Util.pm -> blib/lib/Device/Cdio/Util.pm
process swig files
swig: swig/perliso9660.swg -> perliso9660_wrap.c
swig -o perliso9660_wrap.c -perl -outdir lib swig/perliso9660.swg
Copying lib/perliso9660.pm -> blib/lib/perliso9660.pm
swig: swig/perlmmc.swg -> perlmmc_wrap.c
swig -o perlmmc_wrap.c -perl -outdir lib swig/perlmmc.swg
Copying lib/perlmmc.pm -> blib/lib/perlmmc.pm
swig: swig/perlcdio.swg -> perlcdio_wrap.c
swig -o perlcdio_wrap.c -perl -outdir lib swig/perlcdio.swg
Copying lib/perlcdio.pm -> blib/lib/perlcdio.pm
process c files
  CBuilder: 0.280225
(CC) ./perlcdio_wrap.c -> perlcdio.so
x86_64-linux-gnu-gcc -I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE -fPIC 
-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe 
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-Wno-strict-aliasing -Wno-unused-function -Wno-unused-value 
-Wno-unused-function -Wno-unused-variable -c -D_REENTRANT -D_GNU_SOURCE 
-DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 
-fdebug-prefix-map=/build/libdevice-cdio-perl-0.3.0=. -fstack-protector-strong 
-Wformat -Werror=format-security -g -O2 
-fdebug-prefix-map=/build/libdevice-cdio-perl-0.3.0=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -o 
./perlcdio_wrap.o ./perlcdio_wrap.c
In file included from /usr/lib/x86_64-linux-gnu/perl/5.26/CORE/perl.h:5644:0,
 from ./perlcdio_wrap.c:739:
./perlcdio_wrap.c: In function 'audio_get_status':
./perlcdio_wrap.c:1815:21: warning: implicit declaration of function 
'cdio_from_bcd8'; did you mean 'cdio_open_bsdi'? 
[-Wimplicit-function-declaration]
 newSVuv(cdio_from_bcd8(sub.abs_addr.m)), 0);
 ^
/usr/lib/x86_64-linux-gnu/perl/5.26/CORE/embed.h:228:77: note: in definition of 
macro 'hv_common_key_len'
 #define hv_common_key_len(a,b,c,d,e,f) Perl_hv_common_key_len(aTHX_ 
a,b,c,d,e,f)
 ^
./perlcdio_wrap.c:1814:5: note: in expansion of macro 'hv_store'
 hv_store(audio_st, "abs_m", 5,
 ^~~~
./perlcdio_wrap.c:1815:13: note: in expansion of macro 'newSVuv'
 newSVuv(cdio_from_bcd8(sub.abs_addr.m)), 0);
 ^~~
./perlcdio_wrap.c: In function 'have_driver':
./perlcdio_wrap.c:2235:3: warning: 'CDIO_MIN_DRIVER' is deprecated: please use 
cdio_drivers [-Wdeprecated-declarations]
   if (driver_id < CDIO_MIN_DRIVER || driver_id > CDIO_MAX_DRIVER)
   ^~
In file included from /usr/include/cdio/cdio.h:35:0,
 from ./perlcdio_wrap.c:1552:
/usr/include/cdio/device.h:202:1: note: declared here
 LIBCDIO_DEPRECATED(static const driver_id_t CDIO_MIN_DRIVER, "please use 
cdio_drivers") = DRIVER_AIX;
 ^
./perlcdio_wrap.c:2235:3: warning: 'CDIO_MAX_DRIVER' is deprecated: please use 
cdio_drivers [-Wdeprecated-declarations]
   if (driver_id < CDIO_MIN_DRIVER || driver_id > CDIO_MAX_DRIVER)
   ^~
In file included from /usr/include/cdio/cdio.h:35:0,
 from ./perlcdio_wrap.c:1552:
/usr/include/cdio/device.h:204:1: note: declared here
 LIBCDIO_DEPRECATED(static const driver_id_t CDIO_MAX_DRIVER, "please use 
cdio_drivers") = DRIVER_NRG;
 ^
./perlcdio_wrap.c: In function 'get_cdtext':
./perlcdio_wrap.c:2296:24: error: too many arguments to function 
'cdio_get_cdtext'
 cdtext = ( char **)cdio_get_cdtext (p_cdio, (track_t) track);
^~~
In file included from /usr/include/cdio/cdio.h:61:0,
 from ./perlcdio_wrap.c:1552:
/usr/include/cdio/disc.h:77:13: note: declared here
   cdtext_t *cdio_get_cdtext (CdIo_t *p_cdio);
 ^~~
./perlcdio_wrap.c: In function '_wrap_get_tray_status':
./perlcdio_wrap.c:4846:19: warning: implicit declaration of function 
'mmc_get_tray_status'; did you mean '_wrap_get_tray_status'? 
[-Wimplicit-function-declaration]
 result = (int)mmc_get_tray_status((CdIo_t 

Bug#873480: RPi patch removes single direction maximisation

[Jonas Linde]

Hello!

This bug hit me too so I downloaded the Debian source package and
managed to find which patch it was that caused it. When I recompiled
Openbox without 'rpi/de67618ea9e3e22e7623d56530934d3a3fc272e0.patch'
the problem disappeared.

> From de67618ea9e3e22e7623d56530934d3a3fc272e0 Mon Sep 17 00:00:00 2001
> From: spl 
> Date: Fri, 11 Aug 2017 14:12:54 +0100
> Subject: [PATCH] Remove ability to maximise a window in a single direction.

As indicated by the name of the patch it seems like the ability to
maximise vertically or horizontally was intentionally removed, which I
guess migh make sense in some configurations (eg. with limited screen
size.)

For the general case I beleive this patch should not be applied
though.

Cheers,
-- 
Jonas Linde  - http://jonaseel.se/ - +46-707-492496

Bug#879440: transition: gpsd

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 26/10/17 12:32, Bernd Zeimetz wrote:
> Hi,
> 
> 
> On 10/26/2017 10:52 AM, Emilio Pozuelo Monfort wrote:
>> How do you know that there won't be build failures? Did you review the 
>> upstream
>> changes, particularly the ABI breaks, and verified that none of the rdeps use
>> any of the removed symbols, removed struct fields...?
> 
> yes, I'm doing that since libgps12 or so and never had a transition that
> was not smooth.
> gpsd upstream (including myself, who is doing a lot of testing before a
> release actually happens) is sane and as long as people use documented
> stuff from libgps.h they are safe as long as there is not api breakage
> announced.
> 
>> Can you do a quick rdep
>> rebuild? There are tools to help with that, e.g. ratt.
> 
> done that just for you, but excluding the KDE stuff which builds for way
> too long - yes, all thing just build fine.

Please go ahead.

Emilio

Bug#879529: transition: perl 5.26.1

[Emilio Pozuelo Monfort]

On 26/10/17 19:27, Sven Joachim wrote:
> On 2017-10-26 10:18 +0200, Emilio Pozuelo Monfort wrote:
> 
>> On 26/10/17 09:13, Niko Tyni wrote:
>>> On Mon, Oct 23, 2017 at 09:15:35PM +0200, Emilio Pozuelo Monfort wrote:
 Control: tags -1 confirmed
>
> perl 5.26.1-1 is in experimental. It is binary compatible with 5.26.0
> and therefore Provides both perlapi-5.26.0 and perlapi-5.26.1. However,
> four binNMUs will be needed once it enters unstable due to their strict
> versioned dependencies on the current perl version:
>
>  libpar-packer-perl
>  libdevel-cover-perl
>  libclass-xsaccessor-perl
>  libcommon-sense-perl
>
> Please let us know if/when it's OK to upload.

 Please go ahead.
>>>
>>> Thanks, now uploaded and built on all architectures.
>>> Could you please schedule the binNMUs.
>>
>> Scheduled.
> 
> It seems that something went wrong here and perl was not upgraded to
> 5.26.1 on the buildd chroots, meaning the binNMUs were wasted. :-(

Rescheduled. I always forget that perl is already installed on the chroots so it
needs a manual hint so an upgrade is forced, until the chroots are re-generated
(which happens twice a week).

Cheers,
Emilio

Bug#879886: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Mattia Rizzolo]

On Thu, Oct 26, 2017 at 12:12:05PM -0700, Diane Trout wrote:
> libhts2 introduced an ABI change which broke python-pysam, and a new
> version of python-pysam needed to be released to update to the new ABI.

FTR, this is what changed between the symbols of the version 1.4.1-5 and
1.5-1:

--- 1.4.1-5
+++ dpkg-gensymbolsIEaASY
@@ -178,6 +178,7 @@
  bgzf_flush_try@Base 1.4.1
  bgzf_getc@Base 1.4.1
  bgzf_getline@Base 1.4.1
+ bgzf_hfile@Base 1.5
  bgzf_hopen@Base 1.4.1
  bgzf_index_add_block@Base 1.4.1
  bgzf_index_build_init@Base 1.4.1
@@ -395,7 +396,7 @@
  file_size@Base 1.4.1
  find_file_url@Base 1.4.1
  find_path@Base 1.4.1
- flen@Base 1.4.1
+#MISSING: 1.5# flen@Base 1.4.1
  grp_create_key@Base 1.4.1
  hclose@Base 1.4.1
  hclose_abruptly@Base 1.4.1
@@ -411,6 +412,7 @@
  hfile_plugin_init_libcurl@Base 1.4.1
  hfile_plugin_init_net@Base 1.4.1
  hfile_plugin_init_s3@Base 1.4.1
+ hfile_set_blksize@Base 1.5
  hflush@Base 1.4.1
  hgetc2@Base 1.4.1
  hgetdelim@Base 1.4.1
@@ -436,6 +438,7 @@
  hts_format_file_extension@Base 1.4.1
  hts_get_bgzfp@Base 1.4.1
  hts_get_format@Base 1.4.1
+ hts_get_log_level@Base 1.5
  hts_getline@Base 1.4.1
  hts_hopen@Base 1.4.1
  hts_idx_destroy@Base 1.4.1
@@ -460,6 +463,7 @@
  hts_json_fskip_value@Base 1.4.1
  hts_json_snext@Base 1.4.1
  hts_json_sskip_value@Base 1.4.1
+ hts_log@Base 1.5
  hts_md5_destroy@Base 1.4.1
  hts_md5_final@Base 1.4.1
  hts_md5_hex@Base 1.4.1
@@ -480,6 +484,7 @@
  hts_realloc_or_die@Base 1.4.1
  hts_set_cache_size@Base 1.4.1
  hts_set_fai_filename@Base 1.4.1
+ hts_set_log_level@Base 1.5
  hts_set_opt@Base 1.4.1
  hts_set_thread_pool@Base 1.4.1
  hts_set_threads@Base 1.4.1
@@ -588,7 +593,7 @@
  mfgets@Base 1.4.1
  mfmmap@Base 1.4.1
  mfopen@Base 1.4.1
- mfprintf@Base 1.4.1
+#MISSING: 1.5# mfprintf@Base 1.4.1
  mfread@Base 1.4.1
  mfrecreate@Base 1.4.1
  mfreopen@Base 1.4.1
@@ -704,13 +709,13 @@
  vcf_read@Base 1.4.1
  vcf_write@Base 1.4.1
  vcf_write_line@Base 1.4.1
- vflen@Base 1.4.1
- zfclose@Base 1.4.1
- zfeof@Base 1.4.1
- zfgets@Base 1.4.1
- zfopen@Base 1.4.1
- zfpeek@Base 1.4.1
- zfputs@Base 1.4.1
- zfseeko@Base 1.4.1
- zftello@Base 1.4.1
+#MISSING: 1.5# vflen@Base 1.4.1
+#MISSING: 1.5# zfclose@Base 1.4.1
+#MISSING: 1.5# zfeof@Base 1.4.1
+#MISSING: 1.5# zfgets@Base 1.4.1
+#MISSING: 1.5# zfopen@Base 1.4.1
+#MISSING: 1.5# zfpeek@Base 1.4.1
+#MISSING: 1.5# zfputs@Base 1.4.1
+#MISSING: 1.5# zfseeko@Base 1.4.1
+#MISSING: 1.5# zftello@Base 1.4.1
  zlib_mem_inflate@Base 1.4.1

> libhts2 probably needs a proper symbols file to make it easier to see
> when the ABI is changing. https://wiki.debian.org/UsingSymbolsFiles
> 
> Mattia Rizzolo, also suggests other methods of dealing with managing ABI
> changes.

In pysam's case, it is looking for hts_log, if you had properly checked
the symbols of your package before uploading you should have at least
tweaked the dh_shlibdeps invocation to force a version, or introduced a
.symbols file (very recommended for a case like hstlib where the symbols
seems to be simple).

But then, the ABI is broken, so just nicest symbols handling is not
enough for your case, you need
> Such as bumping soname, changing the package name and use Conflicts, or
> adding versioned Breaks against broken packages

-- 
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#879811: psi-translations: update to version 1.3

[Jan Niehusmann]

Hi Boris,

On Thu, Oct 26, 2017 at 11:59:57AM +0300, Boris Pek wrote:
> Please update package src:psi-translations to version 1.3 and keep it in sync
> with src:psi package.

Definitely a good idea, yes!

Unfortunately, I currently don't have much spare time, so it may take
some time.

> Localization files:
> https://github.com/psi-im/psi-l10n
> 
> Example of packaging rules:
> https://github.com/tehnick/psi-plus-l10n-debian

Thanks for the pointers, those will be very useful for updating the
package.

BTW, I wonder if it would be possible to use a common l10n package for
both psi ans psi+. The differences seem to be rather small.

Jan

Bug#794890: [Pkg-javascript-devel] Bug#794890: Bug#794890: status update

[Jérémy Lal]

2017-10-26 21:25 GMT+02:00 Jérémy Lal :

>
>
> 2017-10-26 21:03 GMT+02:00 Sruthi Chandran :
>
>> On Tue, 13 Jun 2017 10:49:29 +0200 Jérémy Lal  wrote:
>> > 2017-06-13 10:11 GMT+02:00 Alexandre Rossi :
>> >
>> > > Hi,
>> > >
>> > > Any status update on this? Did the effort trying to release with
>> > > embedded deps hit a wall? How can I help?
>> > >
>> > >
>> > Right now npm 5 depends indirectly on both "request" and "got" modules,
>> > which are doing exactly the same thing. Maintaining this requires an
>> amount
>> > of forgiveness i don't have right now.
>> >
>> > Anyway here's what you would want to do:
>> > - start from an empty debian/copyright file (to avoid old dfsg
>> repackagings)
>> > - import new upstream tarball
>> > - populate debian/copyright (including everything in node_modules as
>> well),
>> > it shouldn't be that difficult.
>> >
>> > With this approach the only maintenance burden will be to update
>> > debian/copyright.
>> > Next step will be up to ftpmasters to decide if it's okay to bundle
>> > everything in
>> > that particular case.
>> >
>> > Jérémy
>>
>> I was thinking of packaging npm (by packaging individual modules)
>> working full-time for around one month. I plan to launch a crowd-funding
>> campaign similar to ones launched for packaging grunt[1] and gulp[2].
>> Before going ahead with that, wanted to know the status of your plan of
>> packaging npm. Is your plan still on or shall I go ahead with my plan?
>>
>
> My plan depends on me being available in some parallel universe.
> So YES please please please go ahead, may debian force be with you.
> I might provide some help for technical issues. Or not, depending on
> availability.
>
>
Also note that besides usual packaging needs (like generating
documentation),
there is one trick in npm debian package: the global npmrc that contains
prefix=/usr/local
which in turn ensures
npm install -g 
goes to the right place.

Upstream is deaf to the argument that /usr is not the right prefix,
and to the argument that there should be a well-known global path
for npm configuration (other than /usr/etc/npmrc).

The problem then is that
npm i -g npm
need a manual intervention to make sure that
/usr/local/lib/node_modules/npm/npmrc
is installed and contains prefix=/usr/local
Without it, the default prefix of npm when installed in /usr/local
is /usr/lib
which is wrong and not writable of course.

Jérémy

Bug#879878: Pending fixes for bugs in the geronimo-validation-1.1-spec package

[pkg-java-maintainers]

tag 879878 + pending
thanks

Some bugs in the geronimo-validation-1.1-spec package are closed in
revision fcc08dc6c2f45a876c89bd15d76c120a6de14ac3 in branch 'master'
by Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/geronimo-validation-1.1-spec.git/commit/?id=fcc08dc

Commit message:

Fixed the install path of the javadoc (Closes: #879878)

Bug#867058: golang-1.8 and mips*

[John Paul Adrian Glaubitz]

On 10/26/2017 07:12 PM, peter green wrote:
> Therefore golang maintainers you have two choices.
> 
> 1. Accept John's changes so that your package can be built on mips*.
> 2. File a removal request for the binaries uploaded by John

I assume that gccgo on mips is still broken as this situation hasn't changed,
so I would suggest removing the packages again. I can file a bug for that
since I am the one who is responsible that these packages are there in the
first place.

>> > I was under the impression that the golang maintainers want all 
>> > architectures
>> > bootstrapped from gccgo? This was the reason mips64el support was not in 
>> > stretch despite upstream support for it. If a normal bootstrap would have 
>> > been acceptable,
>> > I would have done it ages ago.
>>
>> Why? What difference does it make? If a different bootstrapping compiler
>> results in a different golang compiler after a second rebuild, there is
>> something wrong with the compiler anyway.
> Self-bootstrapping compilers create a maintenance burden. When things go
> wrong they sometimes can't be fixed through source package changes alone.

Correct me if I'm wrong, but most compilers I know of in Debian are self-
bootstrapping. I recently started working on rustc and that one needs itself
to be built, the same applies for fpc - which you co-maintain - GHC, and 
OpenJDK,
for example. So, I am confident to say that the build system for the golang
packages is not the norm but an exception.

Also, since gccgo is apparently known to produce broken code, I am not sure
I would consider it a good idea to use it as the compiler to build the golang
packages.

> Porterboxes are also of limited utility because you can't install non-archive
> packages on them.

That's correct. But you are forgetting that there is the possibility that
compilers can be cross-compiled on amd64 and for most compilers, that
works pretty well. In fact, there are efforts by people like Helmut Grohne,
whom I support in this effort, to make Debian as a whole more cross-buildable.

> Then there are derivatives to consider, if a self-bootstrapping compiler
> gets broken in a derivative that rebuilds everything then finding someone
> who can un-jam it can be a pain.

I'm not really sure whether I want to accept this argument. I am developing
for Debian and in Debian and I don't see why my work should be limited by
any derivative.

> Whether to take on that burden should be a decision for the maintainers of
> the package, not for some flyby contributer.

That "flyby contributor" you are talking about is maintaining most ports
architectures and has already fixed tons of issues on the various architectures
in Debian. So while I sometimes make mistakes like these, my net contributions
to Debian are hugely positive.

And, as we say in German, "Wo gehobelt wird, da fallen Späne" or, as you
would say in English, "You can't make an omelette without breaking eggs".

In short, if you are touching lots of things in Debian and helping out
at many fronts, you will make such mistakes from time to time. I admit
it was a mistake and I apologize for that. But that still doesn't give
you the right to call me a "flyby contributor".

>> Odd. Last time I did this for fpc [1], you were actually very happy. Now
>> you're getting upset despite the only changes actually necessary are
>> two lines changed in debian/control.in and debian/helpers/goenv.sh.
>>
>> What's the difference now?
> 
> We are happy that you are working on getting packages ported to your 
> architecture.

Who is "we"?

> What we are not happy about is how you are doing it. You need to ensure
> that source goes to the archive either before or at the same time as the 
> binaries and
> you need to either coordinate with maintainers or (if the maintainers are 
> unresponsive)
> follow the normal NMU guidelines.

If it wasn't for me, FPC would still probably not bootstrapped on mips* and m68k
yet and FPC upstream wouldn't have had the possibility to work on the SPARC64
port which they did on hardware that I helped to provide. Again, I am doing so
much for Debian, that I find it a bit unfair that you are preaching me like 
this.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#878303: genrsa manpage suggests using 1024 bit keys

[Sebastian Andrzej Siewior]

control: forwarded -1 https://github.com/openssl/openssl/pull/4547

On 2017-10-13 14:15:13 [+0100], Toni Mueller wrote:
> Hi Sebastian,
Hi Toni,

> that's also one way to go about it, but while we are at it, can we
> change the "should" to a "must"? 

The chapter just vanished. See the pull req.

> Or can the software actually generate
> primes which are even smaller than 64 bits? 

technically yes.

> And what would be the
> applicability of such small keys, anyway?

Education I guess. So I used to do RSA with a pen, paper and a
calculator while learning these kind of things :)

> 
> Cheers,
> --Toni++

Sebastian

Bug#879889: newmat FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: newmat
Version: 1.10.4-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

newmat fails to cross build from source, because it fails running tests
even though DEB_BUILD_OPTIONS contained nocheck. The tests naturally
fail with an "Exec format error". After skipping tests, newmat cross
builds successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru newmat-1.10.4/debian/changelog 
newmat-1.10.4/debian/changelog
--- newmat-1.10.4/debian/changelog  2016-12-11 14:23:04.0 +0100
+++ newmat-1.10.4/debian/changelog  2017-10-26 21:28:03.0 +0200
@@ -1,3 +1,10 @@
+newmat (1.10.4-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Honour DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 26 Oct 2017 21:28:03 +0200
+
 newmat (1.10.4-6) unstable; urgency=medium
 
   [ Philippe Coval ]
diff --minimal -Nru newmat-1.10.4/debian/rules newmat-1.10.4/debian/rules
--- newmat-1.10.4/debian/rules  2016-12-11 14:23:04.0 +0100
+++ newmat-1.10.4/debian/rules  2017-10-26 21:28:01.0 +0200
@@ -55,9 +55,11 @@
dh_testdir
$(MAKE)
 #{ regression tests
+ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
./example
./tmt
./test_exc
+endif
 #}
touch $@
 

Bug#879887: caveconverter: Could not find or load main class footleg.cavesurvey.cmdline.CaveConverter

[Toby Speight]

Package: caveconverter
Version: 0~20170114-2
Severity: important

I installed and tried to run caveconverter, but it simply doesn't start:

/
| $ caveconverter
| Error: Could not find or load main class 
footleg.cavesurvey.cmdline.CaveConverter
\


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

Kernel: Linux 3.16.7-ckt2-balti (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages caveconverter depends on:
ii  default-jre [java8-runtime]2:1.8-59
ii  jarwrapper 0.61
ii  openjdk-8-jre [java8-runtime]  8u144-b01-1

caveconverter recommends no packages.

caveconverter suggests no packages.

-- no debconf information

Bug#794890: [Pkg-javascript-devel] Bug#794890: status update

[Jérémy Lal]

2017-10-26 21:03 GMT+02:00 Sruthi Chandran :

> On Tue, 13 Jun 2017 10:49:29 +0200 Jérémy Lal  wrote:
> > 2017-06-13 10:11 GMT+02:00 Alexandre Rossi :
> >
> > > Hi,
> > >
> > > Any status update on this? Did the effort trying to release with
> > > embedded deps hit a wall? How can I help?
> > >
> > >
> > Right now npm 5 depends indirectly on both "request" and "got" modules,
> > which are doing exactly the same thing. Maintaining this requires an
> amount
> > of forgiveness i don't have right now.
> >
> > Anyway here's what you would want to do:
> > - start from an empty debian/copyright file (to avoid old dfsg
> repackagings)
> > - import new upstream tarball
> > - populate debian/copyright (including everything in node_modules as
> well),
> > it shouldn't be that difficult.
> >
> > With this approach the only maintenance burden will be to update
> > debian/copyright.
> > Next step will be up to ftpmasters to decide if it's okay to bundle
> > everything in
> > that particular case.
> >
> > Jérémy
>
> I was thinking of packaging npm (by packaging individual modules)
> working full-time for around one month. I plan to launch a crowd-funding
> campaign similar to ones launched for packaging grunt[1] and gulp[2].
> Before going ahead with that, wanted to know the status of your plan of
> packaging npm. Is your plan still on or shall I go ahead with my plan?
>

My plan depends on me being available in some parallel universe.
So YES please please please go ahead, may debian force be with you.
I might provide some help for technical issues. Or not, depending on
availability.

Jérémy

Bug#879888: usbview FTCBFS: convert fails to run rsvg-convert

[Helmut Grohne]

Source: usbview
Version: 2.0-21-g6fe2f4f-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

While cross compiling usbview, I run into the following error:

| mkdir -p $(dirname hicolor/64x64/apps/usbview_icon.xpm)
| convert -geometry $(basename $(dirname $(dirname 
hicolor/64x64/apps/usbview_icon.xpm))) usbview_icon.svg 
hicolor/64x64/apps/usbview_icon.xpm
| convert-im6.q16: delegate failed `'rsvg-convert' -o '%o' '%i'' @ 
error/delegate.c/InvokeDelegate/1919.
| convert-im6.q16: unable to open file `/tmp/magick-15542-iTdLe4Tr9dU': No such 
file or directory @ error/constitute.c/ReadImage/544.
| convert-im6.q16: no images defined `hicolor/64x64/apps/usbview_icon.xpm' @ 
error/convert.c/ConvertImageCommand/3258.
| Makefile:963: recipe for target 'hicolor/64x64/apps/usbview_icon.xpm' failed
| make[2]: *** [hicolor/64x64/apps/usbview_icon.xpm] Error 1
| make[2]: Leaving directory '/<>'
| Makefile:354: recipe for target 'all' failed
| make[1]: *** [all] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: make -j1 returned exit code 2
| debian/rules:4: recipe for target 'build-arch' failed
| make: *** [build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

It's not exactly clear to me why imagemagick behaves differently for
cross vs native builds here, but the build succeeds after adding
librsvg2-bin to Build-Depends. Can you apply that?

Helmut
diff --minimal -Nru usbview-2.0-21-g6fe2f4f/debian/changelog 
usbview-2.0-21-g6fe2f4f/debian/changelog
--- usbview-2.0-21-g6fe2f4f/debian/changelog2017-02-04 12:24:40.0 
+0100
+++ usbview-2.0-21-g6fe2f4f/debian/changelog2017-10-26 21:18:24.0 
+0200
@@ -1,3 +1,10 @@
+usbview (2.0-21-g6fe2f4f-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add librsvg2-bin to Build-Depends for convert (closes: #-1).
+
+ -- Helmut Grohne   Thu, 26 Oct 2017 21:18:24 +0200
+
 usbview (2.0-21-g6fe2f4f-1) unstable; urgency=low
 
   * New upstream snapshot (closes: #849000).
diff --minimal -Nru usbview-2.0-21-g6fe2f4f/debian/control 
usbview-2.0-21-g6fe2f4f/debian/control
--- usbview-2.0-21-g6fe2f4f/debian/control  2017-02-04 12:24:38.0 
+0100
+++ usbview-2.0-21-g6fe2f4f/debian/control  2017-10-26 21:18:22.0 
+0200
@@ -5,7 +5,7 @@
 Standards-Version: 3.9.6
 Homepage: http://www.kroah.com/linux-usb/
 Build-Depends: debhelper (>= 9), dh-autoreconf, autoconf-archive,
-  imagemagick, libmagickcore-6.q16-2-extra, libgtk-3-dev
+  imagemagick, libmagickcore-6.q16-2-extra, libgtk-3-dev, librsvg2-bin
 X-Vcs-Upstream-Git: git://github.com/gregkh/usbview.git
 
 Package: usbview

Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Diane Trout]

Package: libhts2
Version: 1.5-1
Severity: critical

Dear Maintainer,

libhts2 introduced an ABI change which broke python-pysam, and a new
version of python-pysam needed to be released to update to the new ABI.

libhts2 probably needs a proper symbols file to make it easier to see
when the ABI is changing. https://wiki.debian.org/UsingSymbolsFiles

Mattia Rizzolo, also suggests other methods of dealing with managing ABI
changes.

Such as bumping soname, changing the package name and use Conflicts, or
adding versioned Breaks against broken packages

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500, 'testing'), 
(500, 'stable'), (110, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libhts2 depends on:
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-17
ii  libcurl3-gnutls  7.55.1-1
ii  liblzma5 5.2.2-1.3
ii  libssl1.11.1.0f-5
ii  zlib1g   1:1.2.8.dfsg-5

libhts2 recommends no packages.

libhts2 suggests no packages.

-- no debconf information

Bug#794890: [Pkg-javascript-devel] Bug#794890: status update

[Sruthi Chandran]

On Tue, 13 Jun 2017 10:49:29 +0200 Jérémy Lal  wrote:
> 2017-06-13 10:11 GMT+02:00 Alexandre Rossi :
>
> > Hi,
> >
> > Any status update on this? Did the effort trying to release with
> > embedded deps hit a wall? How can I help?
> >
> >
> Right now npm 5 depends indirectly on both "request" and "got" modules,
> which are doing exactly the same thing. Maintaining this requires an
amount
> of forgiveness i don't have right now.
>
> Anyway here's what you would want to do:
> - start from an empty debian/copyright file (to avoid old dfsg
repackagings)
> - import new upstream tarball
> - populate debian/copyright (including everything in node_modules as
well),
> it shouldn't be that difficult.
>
> With this approach the only maintenance burden will be to update
> debian/copyright.
> Next step will be up to ftpmasters to decide if it's okay to bundle
> everything in
> that particular case.
>
> Jérémy

I was thinking of packaging npm (by packaging individual modules)
working full-time for around one month. I plan to launch a crowd-funding
campaign similar to ones launched for packaging grunt[1] and gulp[2].
Before going ahead with that, wanted to know the status of your plan of
packaging npm. Is your plan still on or shall I go ahead with my plan?

[1]
https://www.indiegogo.com/projects/package-browserify-node-module-for-debian/x/13540574#/
[2]
https://www.generosity.com/community-fundraising/debian-browserify-2/x/13540574



signature.asc
Description: OpenPGP digital signature

Bug#879885: htslib FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: htslib
Version: 1.5-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

htslib fails to cross build from source, because it configures for the
build architecture by failing to pass --host configure. Deferring that
task to dh_auto_configure easily fixes the cross build. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru htslib-1.5/debian/changelog htslib-1.5/debian/changelog
--- htslib-1.5/debian/changelog 2017-08-04 04:56:42.0 +0200
+++ htslib-1.5/debian/changelog 2017-10-26 21:05:01.0 +0200
@@ -1,3 +1,10 @@
+htslib (1.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 26 Oct 2017 21:05:01 +0200
+
 htslib (1.5-1) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru htslib-1.5/debian/rules htslib-1.5/debian/rules
--- htslib-1.5/debian/rules 2017-08-04 04:56:19.0 +0200
+++ htslib-1.5/debian/rules 2017-10-26 21:04:59.0 +0200
@@ -19,7 +19,7 @@
 
 override_dh_auto_configure:
autoconf
-   ./configure --enable-libcurl
+   dh_auto_configure -- --enable-libcurl
 
 override_dh_auto_build:
dh_auto_build -- \

Bug#879884: RM: virtualjaguar [armel armhf] -- ROM; FTBFS

[John Paul Adrian Glaubitz]

Package: ftp.debian.org
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

Please remove virtualjaguar for armel and armhf from unstable
as the package currently fails to build from source on these
architectures.

The reason for the FTBFS is that the Qt maintainers switched
the GL version from Desktop to ES2 which means that some C++
definitions are not available. Unfortunately, the virtualjaguar
package needs some of these definitions as it currently supports
Desktop GL only.

The reason for the switch is that most armel and armhf hardware
only implements ES2 GL so that most GL applications run without
hardware acceleration.

The upstream developers of virtualjaguar are planning to support
ES2 GL in the future, but since that will most likely take a
while, I am requesting to drop the package for armel and armhf.

Thanks,
Adrian

> [1] 
> https://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/tree/debian/rules#n28

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#852471: Dependency sddm, sddm-theme-maui | sddm-theme is to weak

[Alf Gaida]

Since the time of writing sddm get a new release in debian and some
dependencies are improved - second there are now some native debian sddm
theme packages.

So task-lxqt-desktop should be changed that way:

> diff --git a/debian/control b/debian/control
> index ef6a0a48..0d1faab2 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -187,14 +187,13 @@ Description: LXQt
>   expect to have available on the desktop.
>  Depends: ${misc:Depends},
>   task-desktop,
> - sddm,
> - sddm-theme-maui | sddm-theme,
> + sddm-theme-debian-maui | sddm-theme,
>   lxqt,
>  Recommends: xsane,
>  # orca works with qt, adding accessibility
>     gnome-orca,
>  # libreoffice widgets using just gtk
> -   libreoffice-gtk2,
> +   libreoffice-gtk3,
>  # Package management.
>     synaptic,
>  # firefox (ne iceweasel) is the most popular web browser at the moment,

Bug#879882: cadaver FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: cadaver
Version: 0.23.3-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

cadaver fails to cross build from source, because it uses the build
architecture pkg-config. neon.m4 uses AC_PATH_PROG to discover
pkg-config and thus fails to consider $ac_tool_prefix. Updating that
file is non-trivial, because ./autogen.sh no longer works on Debian
systems. After hacking it up a bit I can see that with the attached
patch the cross build goes further and aborts with a gettext version
mismatch. Please consider applying the attached patch. When doing so,
please close this bug regardless of whether it actually cross builds.
I'll check again.

I believe that cadaver is seriously (aka rc) buggy given that it cannot
regenerate its build system from source.

Helmut
--- cadaver-0.23.3.orig/m4/neon/neon.m4
+++ cadaver-0.23.3/m4/neon/neon.m4
@@ -854,8 +854,8 @@
 
 m4_define([ne_cvar], m4_translit(ne_cv_pkg_[$2], [.-], [__]))dnl
 
-AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
-if test "$PKG_CONFIG" = "no"; then
+PKG_PROG_PKG_CONFIG
+if test "x$PKG_CONFIG" = "x"; then
: Not using pkg-config
$4
 else

Bug#879883: libx32stdc++6-8-dbg: missing Conflicts: libx32stdc++6-7-dbg

[Andreas Beckmann]

Package: libx32stdc++6-8-dbg
Version: 8-20171023-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi doko,

the last round of adding Conflicts seems to have missed this one:

  Selecting previously unselected package libx32stdc++6-8-dbg.
  Preparing to unpack .../15-libx32stdc++6-8-dbg_8-20171023-1_amd64.deb ...
  Unpacking libx32stdc++6-8-dbg (8-20171023-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-ntuDRD/15-libx32stdc++6-8-dbg_8-20171023-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/libx32/debug/libstdc++.a', which is also in 
package libx32stdc++6-7-dbg 7.2.0-12
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-ntuDRD/15-libx32stdc++6-8-dbg_8-20171023-1_amd64.deb


cheers,

Andreas

Bug#879798: FTBFS: testsuite fails with dpkg 1.19, patch attached

[Mattia Rizzolo]

On Wed, Oct 25, 2017 at 10:40:20PM -0600, Adam Conrad wrote:
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * test/test_mk-origtargz: Adjust test for dpkg 1.19's ErrorHandling.pm.
> 
> Fairly self-explanatory, I'd think.  In dpkg 1.19, ErrorHandling.pm was
> normalised to match libdpkg error messages, and this means the expected
> error in the mk-origtargz test is now incorrect.  This patch fixes that.

We like to backport devscripts, and I'd rather not have backports deltas
if possible...

But yes, a bug damn :)

-- 
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#861124: ITP: elpa-writeroom-mode -- distraction-free writing for Emacs

[Nicholas D Steeves]

On Thu, Jun 08, 2017 at 05:23:02PM -0400, Antoine Beaupré wrote:
> On 2017-05-17 10:57:00, Nicholas D Steeves wrote:
> > Control: block -1 by 861772
> >
> > Please do not upload this package yet.  I'm blocking this RFP with an
> > RFS I filed, and have tagged it moreinfo while I investigate the
> > severity of a possible trademark infringement issue.  I expect that to
> > be solved quickly, hopefully before you get back.
> 
> Any news here?

...still waiting for upstream.  I've packaged olivetti-mode in the
meantime, and have CCed you for the RFS bug.  The ITP bug is #879877
FIY.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#879881: RFS: olivetti-mode/1.5.8-1 [ITP]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: wishlist
Control: block 879877 by -1

Dear mentors,

I am looking for a sponsor for my package "olivetti-mode"

* Package name: olivetti-mode
  Version : 1.5.8-1
  Upstream Author : Paul Rankin 
* URL : https://github.com/rnkn/olivetti
* License : GPL-3+
  Section : lisp

It builds this binary package:

elpa-olivetti - simple Emacs minor mode for a nice writing environment

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

https://mentors.debian.net/package/olivetti-mode

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

dget -x 
https://mentors.debian.net/debian/pool/main/o/olivetti-mode/olivetti-mode_1.5.8-1.dsc

Alternatively, sponsor from git:

git clone ssh://git.debian.org/git/pkg-emacsen/pkg/olivetti-mode.git

More information about olivetti-mode can be obtained from 
https://github.com/rnkn/olivetti

Changes since the last upload:

olivetti-mode (1.5.8-1) unstable; urgency=medium

  * Initial release. (Closes: #879877)

 -- Nicholas D Steeves   Thu, 26 Oct 2017 14:11:32 -0400

Regards,
Nicholas D Steeves

Bug#879880: flightgear: fails to upgrade from 'stable' to 'sid' - trying to overwrite /usr/share/man/man1/metar.1.gz

[Andreas Beckmann]

Package: flightgear
Version: 1:2017.3.1+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package flightgear.
  Preparing to unpack .../253-flightgear_1%3a2017.3.1+dfsg-2_amd64.deb ...
  Unpacking flightgear (1:2017.3.1+dfsg-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-4BjngF/253-flightgear_1%3a2017.3.1+dfsg-2_amd64.deb 
(--unpack):
   trying to overwrite '/usr/share/man/man1/metar.1.gz', which is also in 
package metar 20061030.1-2.2+b1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-4BjngF/253-flightgear_1%3a2017.3.1+dfsg-2_amd64.deb


cheers,

Andreas


metar=20061030.1-2.2+b1_flightgear=1%2017.3.1+dfsg-2.log.gz
Description: application/gzip

Bug#879879: python3-monajat: fails to upgrade from 'stable' to 'sid' - trying to overwrite /usr/share/locale/ar/LC_MESSAGES/monajat.mo

[Andreas Beckmann]

Package: python3-monajat
Version: 4.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package python3-monajat.
  Preparing to unpack .../python3-monajat_4.1-1_all.deb ...
  Unpacking python3-monajat (4.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-monajat_4.1-1_all.deb (--unpack):
   trying to overwrite '/usr/share/locale/ar/LC_MESSAGES/monajat.mo', which is 
also in package python-monajat 2.6.5-1
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-monajat_4.1-1_all.deb


cheers,

Andreas


python-monajat=2.6.5-1_python3-monajat=4.1-1.log.gz
Description: application/gzip

Bug#879878: libgeronimo-validation-1.1-spec-java-doc: fails to upgrade from 'stretch' - trying to overwrite /usr/share/doc/libgeronimo-validation-1.0-spec-java/api/allclasses-frame.html

[Andreas Beckmann]

Package: libgeronimo-validation-1.1-spec-java-doc
Version: 1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package 
libgeronimo-validation-1.1-spec-java-doc.
  Preparing to unpack 
.../libgeronimo-validation-1.1-spec-java-doc_1.0-1_all.deb ...
  Unpacking libgeronimo-validation-1.1-spec-java-doc (1.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libgeronimo-validation-1.1-spec-java-doc_1.0-1_all.deb 
(--unpack):
   trying to overwrite 
'/usr/share/doc/libgeronimo-validation-1.0-spec-java/api/allclasses-frame.html',
 which is also in package libgeronimo-validation-1.0-spec-java-doc 1.1-2
  Errors were encountered while processing:
   
/var/cache/apt/archives/libgeronimo-validation-1.1-spec-java-doc_1.0-1_all.deb


Looks like the files are installed in the wrong path ...


cheers,

Andreas


libgeronimo-validation-1.0-spec-java-doc=1.1-2_libgeronimo-validation-1.1-spec-java-doc=1.0-1.log.gz
Description: application/gzip

Bug#879866: Patch solving the issue

[Pierre Dinh-van]

Hi,

I tried to find out by myself where the bugs comes from.

I looked at the code upstream, and noticed that they moved the code
responsible for the reply "Unable to query the local user to accept the
connection." a few line up in unix/xserver/hw/vnc/XserverDesktop.cc

https://github.com/TigerVNC/tigervnc/blob/master/unix/xserver/hw/vnc/XserverDesktop.cc#L314

Looking at the code in rfb::VNCServerST::queryResult
XserverDesktop::queryConnection it's quite clear.
The 'queryConnectId' variable which triggers the Message "Another
connection is currently being queried." is set before the code related
to "Unable to query the local user to accept the connection.", which
doesn't reset the 'queryConnectId' variable.

So it makes sense to move the code before the initialisation of the
queryConnectId.

I build 1.7.0+dfsg-7 with the attached patch on top of the debian
patches, and it solves the issue.

I didn't look deeper to see if it as side effects, but since the
upstream developers did it too, I guess it could be nice to patch !

This bug is a kind of DoS since it needs the user to restart Xorg
completely to allow the service to be reached again.

Cheers

Pierre
--- tigervnc-1.7.0/unix/xserver/hw/vnc/XserverDesktop.cc	2016-09-08 12:31:18.0 +0200
+++ tigervnc-1.7.0.pierre/unix/xserver/hw/vnc/XserverDesktop.cc	2017-10-26 19:19:55.736805114 +0200
@@ -285,19 +285,18 @@
 return rfb::VNCServerST::REJECT;
   }
 
-  queryConnectAddress.replaceBuf(sock->getPeerAddress());
-  if (!userName)
-userName = "(anonymous)";
-  queryConnectUsername.replaceBuf(strDup(userName));
-  queryConnectId = (uint32_t)(intptr_t)sock;
-  queryConnectSocket = sock;
-
   count = vncNotifyQueryConnect();
   if (count == 0) {
 *reason = strDup("Unable to query the local user to accept the connection.");
 return rfb::VNCServerST::REJECT;
   }
 
+  queryConnectAddress.replaceBuf(sock->getPeerAddress());
+  if (!userName)
+userName = "(anonymous)";
+  queryConnectUsername.replaceBuf(strDup(userName));
+  queryConnectId = (uint32_t)(intptr_t)sock;
+  queryConnectSocket = sock;
   return rfb::VNCServerST::PENDING;
 }
 

Bug#871314: [Debian-med-packaging] Bug#871314: pysam 0.12 depends on libhts2 1.5

[Afif Elghraoui]

Hi, Diane,

On October 26, 2017 1:41:30 PM EDT, "Trout, Diane E."  wrote:
>The new version of pysam 0.12 requires libhts2 1.5.
>
>Unfortunately pysam 0.12 just migrated to testing, and libhts2 was
>blocked from migrating by this bug because it breaks pysam 0.11
>
>
Oh, yeah, that should be closed. There is a similar bug holding up samtools 1.5 
for the same reason that can also be closed. And bcftools 1.5 is held up for 
portability regressions on exotic architectures that nobody has time/interest 
for...

regards
Afif

Bug#879877: ITP: olivetti-mode -- simple Emacs minor mode for a nice writing environment

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 

* Package name: olivetti-mode
  Version : 1.5.8
  Upstream Author : Paul Rankin 
* URL : https://github.com/rnkn/olivetti
* License : GPL-3+
  Programming Lang: elisp
  Description : simple Emacs minor mode for a nice writing environment

Like the famous typewriter, Olivetti mode let's you focus on writing
 rather than on the interface.
 .
 Features:
   * Set a desired text body width to automatically resize window
 margins to keep the text comfortably in the middle of the window.
 .
   * Text body width can be the number of characters (an integer) or a
 fraction of the window width (a float between 0.0 and 1.0).
 .
   * Interactively change body width with:
 olivetti-shrink C-c [ [ [ ...
 olivetti-expand C-c ] ] ] ...
 olivetti-set-width C-c \
 .
   * If olivetti-body-width is an integer, the text body width will
 scale with use of text-scale-mode, whereas if a fraction (float)
 then the text body width will remain at that fraction.
 .
   * Optionally remember the state of visual-line-mode on entry and
 recall its state on exit.
 .
   * Optionally hide the mode-line for distraction-free writing.

This package is useful for anyone who uses emacs fullscreen, to reduce
distractions while keeping the blocks of text centered and the lines
short; this increases reading speed, because the eye needs to saccade
less.

In comparison to writeroom-mode, which needs to be renamed upstream
before it can be uploaded to the archive, olivetti is somewhat more
difficult to configure; however, it has enhanced on-the-fly
configuration.

I plan to maintain it as part of the Emacs addons team, and I will
need a sponsor.

Regards,
Nicholas

Bug#879686: fails to install on hercules

[Wouter Verhelst]

For the benefit of the s390 porters (whom I should have Cc'd on this
from the very start):

Unless I'm doing something terribly wrong, it appears that stretch (and
later) don't install on the hercules s390 emulator anymore. Anyone have
any clue what's wrong?

On Tue, Oct 24, 2017 at 03:49:48PM +0200, Wouter Verhelst wrote:
> Package: installation-reports
> Severity: important
> Tags: d-i
> 
> 
> 
> -- Package-specific info:
> 
> Boot method: hercules virtual card reader
> Image version: daily build from 2017-10-23
> Date: 
> 
> Machine: Hercules
> Partitions: 
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [E]
> Detect CD:  [ ]
> Load installer modules: [ ]
> Clock/timezone setup:   [ ]
> User/password setup:[ ]
> Detect hard drives: [ ]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> Comments/Problems:
> 
> Based on the inwstructions at
> http://josefsipek.net/docs/s390-linux/hercules-s390.html (which really
> should find a home on the Debian wiki, but that as an aside) I created a
> file "debian.cnf" with the following contents:
> 
> --
> CPUSERIAL 69# CPU serial number
> CPUMODEL  9672  # CPU model number
> MAINSIZE  1024  # Main storage size in megabytes
> XPNDSIZE  0 # Expanded storage size in megabytes
> CNSLPORT  3270  # TCP port number to which consoles connect
> NUMCPU4 # Number of CPUs
> LOADPARM  0120  # IPL parameter
> OSTAILOR  LINUX # OS tailoring
> PANRATE   SLOW  # Panel refresh rate (SLOW, FAST)
> ARCHMODE  ESAME # Architecture mode ESA/390 or ESAME
> # console
> 001F3270
> # terminal
> 00093215
> # reader
> 000C3505./rdr/kernel.debian ./rdr/parmfile.debian ./rdr/initrd.debian 
> autopad eof
> # printer
> 000E1403./prt/print00e.txt crlf
> # dasd
> 01203390./dasd/3390.LINUX.0120
> # tape
> 05813420
> # network   s390 realbox
> 0A00,0A01  CTCI -n /dev/net/tun -t 1500 10.1.1.2 10.1.1.1 
>
> --
> 
> Next, I created a file "dasd/3390.LINUX.0120" with the following command:
> 
>   dasdinit -lfs -linux dasd/3390.LINUX.0120 3390-3 LIN120 8000
> 
> Next, I downloaded the "initrd.debian", "kernel.debian", and
> "parmfile.debian" from the most recent successful d-i daily build.
> 
> Finally, I started hercules like so:
> 
>   sudo hercules -f debian.cnf
> 
> and entered the (hercules) command "ipl c".
> 
> When the initrd, kernel, and parmfile are from a jessie install, this
> works. When they are from stretch or later(!) however, it does not. The
> kernel boots, and it seems to be doing a bit of initialization, but then
> it stops at:
> 
> [...]
> 34.263205! Key type asymmetric registered 
>   
>
> 35.059693! ctcm: CTCM driver initialized  
>   
>
> Starting system log daemon: syslogd, klogd.   
>   
>
>  1;24r 4l(B)0 m 1;24r H J 24;1H m 
>   
>
>  1;24r 4l(B)0 m 1;24r H J 24;1H m 
>   
>
> Configure the network device  
>   
>
> 
> After this "Configure the network device", d-i *should* show the
> template for me to select the network device type. It does not, however;
> it just sits at the "Configure the network device" line.
> 
> For comparison, on jessie that looks like this:
> 
> [...]
>  5.108239! ctcm: CTCM driver initialized  
>   
>
>  5.115620! lcs: Loading LCS driver
>   
>
> Starting system log daemon: syslogd, klogd.   
>   
>
>  1;24r 4l(B)0 m 1;24r H J 24;1H m 
>   
>
>  

Bug#869529: Missed file tasks/lxqt-desktop

[Alf Gaida]

Tests with the provided images:
* debian-9.0+HACK-amd64-NETINST-1-with-provides.iso does the trick
* tasksel show both LXDE and LXQt so this point is fixed
* installation of both LXDE and LXQt went well, LXQt perfect, LXDE
picked up lxqt-policykit somehow, possible not related to tasksel.
Should be a different issue, will file a bug if analyzed it
* with the unpatched tasksel LXDE picked up more or less LXQt packages,
esp common and session - this behaviour is gone.

I would give it a go, thank you KiBi

Bug#879876: ipython fails after printing help on a variable definition

[Reverend Homer]

Package: ipython
Version: 5.1.0-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Nothing unusual, just "apt install python-ipython ipython"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

In [1]: s = isinstance?

   * What was the outcome of this action?

In [1]: s = isinstance?
Docstring:
isinstance(object, class-or-type-or-tuple) -> bool

Return whether an object is an instance of a class or of a subclass thereof.
With a type as second argument, return whether that is the object's type.
The form using a tuple, isinstance(x, (A, B, ...)), is a shortcut for
isinstance(x, A) or isinstance(x, B) or ... (etc.).
Type:  builtin_function_or_method

In [2]: s = isinstance?
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/traitlets/config/application.py", line 
658, in launch_instance
app.start()
  File "/usr/lib/python2.7/dist-packages/IPython/terminal/ipapp.py", line 348, 
in start
self.shell.mainloop()
  File "/usr/lib/python2.7/dist-packages/IPython/terminal/interactiveshell.py", 
line 440, in mainloop
self.interact()
  File "/usr/lib/python2.7/dist-packages/IPython/terminal/interactiveshell.py", 
line 423, in interact
code = self.prompt_for_code()
  File "/usr/lib/python2.7/dist-packages/IPython/terminal/interactiveshell.py", 
line 333, in prompt_for_code
pre_run=self.pre_prompt, reset_current_buffer=True)
  File "/usr/lib/python2.7/dist-packages/prompt_toolkit/interface.py", line 
408, in run
self._pre_run(pre_run)
  File "/usr/lib/python2.7/dist-packages/prompt_toolkit/interface.py", line 
383, in _pre_run
pre_run()
  File "/usr/lib/python2.7/dist-packages/IPython/terminal/interactiveshell.py", 
line 410, in pre_prompt
self.pt_cli.application.buffer.text = cast_unicode_py2(self.rl_next_input)
  File "/usr/lib/python2.7/dist-packages/prompt_toolkit/buffer.py", line 372, 
in text
assert self.cursor_position <= len(value)
AssertionError

If you suspect this is an IPython bug, please report it at:
https://github.com/ipython/ipython/issues
or send an email to the mailing list at ipython-...@scipy.org

You can print a more detailed traceback right now with "%tb", or use "%debug"
to interactively debug it.

Extra-detailed tracebacks for bug-reporting purposes can be enabled via:
%config Application.verbose_crash=True



   * What outcome did you expect instead?

ipython prints help, removes "?" from the repl and works fine


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

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

Versions of packages ipython depends on:
ii  python-ipython  5.1.0-3

ipython recommends no packages.

ipython suggests no packages.

-- no debconf information

Bug#879720: RFS: runescape/0.2-1 [QA] -- Multiplayer online game set in a fantasy world

[Tobias Frost]

On Wed, Oct 25, 2017 at 10:03:16PM -0200, Carlos Donizete Froes wrote:
> Em qua, 2017-10-25 às 22:44 +0200, Tobias Frost escreveu:
> > Please reupload a fixed packge to mentors.debian.net, when it is ready.
> 
> I sent a fixed package to 'mentors.debian.net' and responded to bug #866227,
> warning about the corrected new version.

Ok, but you need to close the bug in the changelog then.
See 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-bugfix

What's about the bug I filed? (#879784)
I do not see it has been adressed...

--
tobi

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

Bug#879785: cinnamon: windows lose focus often

[Christophe Collaudin]

2017-10-26 19:53 GMT+02:00 Christophe Collaudin <
christophe.collau...@gmail.com>:

> sorry, my email is sending , but i am not yet finish the response
>
>  What was the outcome of this action?
>
=just reboot the computer
i have the same probleme with previous Linux Mint 18.2

>
>* What outcome did you expect instead?
>
=>i expect than I can choose another windows

>
> 2017-10-26 19:51 GMT+02:00 Christophe Collaudin <
> christophe.collau...@gmail.com>:
>
>> hi,
>> here are my response
>>
>> ** Reporter, please consider answering these questions, where appropriate
>> ***
>>
>>* What led up to the situation?
>>= No specific led, just the terminal "ctrl+alt+F1-6" are
>> OK, but no respond on Cinnamon (mouse is moving, but cannot do [atl]+[Tab],
>> the more time, I need to reboot
>>
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>>= the mouse work, but impossible to change focus on
>> windows or to close
>>* What was the outcome of this action?
>>
>>* What outcome did you expect instead?
>>
>> *** End of the template - remove these template lines ***
>>
>> 2017-10-25 21:57 GMT+02:00 collo :
>>
>>> Package: cinnamon
>>> Version: 3.2.7-4
>>> Severity: important
>>>
>>> Dear Maintainer,
>>>
>>> *** Reporter, please consider answering these questions, where
>>> appropriate ***
>>>
>>>* What led up to the situation?
>>>* What exactly did you do (or not do) that was effective (or
>>>  ineffective)?
>>>* What was the outcome of this action?
>>>* What outcome did you expect instead?
>>>
>>> *** End of the template - remove these template lines ***
>>>
>>>
>>>
>>> -- System Information:
>>> Debian Release: 9.2
>>>   APT prefers stable-updates
>>>   APT policy: (500, 'stable-updates'), (500, 'stable')
>>> Architecture: amd64 (x86_64)
>>>
>>> Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
>>> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
>>> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/dash
>>> Init: systemd (via /run/systemd/system)
>>>
>>> Versions of packages cinnamon depends on:
>>> ii  caribou  0.4.21-1+b1
>>> ii  cinnamon-common  3.2.7-4
>>> ii  cinnamon-control-center  3.2.1-3
>>> ii  cinnamon-desktop-data3.2.4-4
>>> ii  cinnamon-screensaver 3.2.13-4
>>> ii  cinnamon-session 3.2.0-4
>>> ii  cinnamon-settings-daemon 3.2.1-3
>>> ii  cjs  3.2.0-3
>>> ii  cups-pk-helper   0.2.6-1+b1
>>> ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
>>> ii  gir1.2-accountsservice-1.0   0.6.43-1
>>> ii  gir1.2-caribou-1.0   0.4.21-1+b1
>>> ii  gir1.2-clutter-1.0   1.26.0+dfsg-3
>>> ii  gir1.2-cmenu-3.0 3.2.0-3
>>> ii  gir1.2-cogl-1.0  1.22.2-2
>>> ii  gir1.2-cvc-1.0   3.2.4-4
>>> ii  gir1.2-gdkpixbuf-2.0 2.36.5-2+deb9u1
>>> ii  gir1.2-gkbd-3.0  3.22.0.1-1+b1
>>> ii  gir1.2-glib-2.0  1.50.0-1+b1
>>> ii  gir1.2-gnomedesktop-3.0  3.22.2-1
>>> ii  gir1.2-gtk-3.0   3.22.11-1
>>> ii  gir1.2-gtkclutter-1.01.8.2-2
>>> ii  gir1.2-javascriptcoregtk-3.0 2.4.11-3
>>> ii  gir1.2-keybinder-3.0 0.3.1-1
>>> ii  gir1.2-meta-muffin-0.0   3.2.1-2
>>> ii  gir1.2-networkmanager-1.01.6.2-3
>>> ii  gir1.2-notify-0.70.7.7-2
>>> ii  gir1.2-pango-1.0 1.40.5-1
>>> ii  gir1.2-polkit-1.00.105-18
>>> ii  gir1.2-soup-2.4  2.56.0-2+deb9u1
>>> ii  gir1.2-upowerglib-1.00.99.4-4+b1
>>> ii  gir1.2-xapp-1.0  1.0.2-1
>>> ii  gkbd-capplet 3.22.0.1-1+b1
>>> ii  gnome-backgrounds3.22.1-1
>>> ii  gnome-themes-standard3.22.2-2
>>> ii  gsettings-desktop-schemas3.22.0-1
>>> ii  iso-flags-png-320x2401.0.1-1
>>> ii  libatk-bridge2.0-0   2.22.0-2
>>> ii  libatk1.0-0  2.22.0-1
>>> ii  libc62.24-11+deb9u1
>>> ii  libcairo21.14.8-1
>>> ii  libcinnamon-menu-3-0 3.2.0-3
>>> ii  libcjs0  3.2.0-3
>>> ii  libclutter-1.0-0 1.26.0+dfsg-3
>>> ii  libcogl-pango20 

Bug#879785: cinnamon: windows lose focus often

[Christophe Collaudin]

sorry, my email is sending , but i am not yet finish the response

 What was the outcome of this action?

   * What outcome did you expect instead?

2017-10-26 19:51 GMT+02:00 Christophe Collaudin <
christophe.collau...@gmail.com>:

> hi,
> here are my response
>
> ** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>= No specific led, just the terminal "ctrl+alt+F1-6" are
> OK, but no respond on Cinnamon (mouse is moving, but cannot do [atl]+[Tab],
> the more time, I need to reboot
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>= the mouse work, but impossible to change focus on windows
> or to close
>* What was the outcome of this action?
>
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
> 2017-10-25 21:57 GMT+02:00 collo :
>
>> Package: cinnamon
>> Version: 3.2.7-4
>> Severity: important
>>
>> Dear Maintainer,
>>
>> *** Reporter, please consider answering these questions, where
>> appropriate ***
>>
>>* What led up to the situation?
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>>* What was the outcome of this action?
>>* What outcome did you expect instead?
>>
>> *** End of the template - remove these template lines ***
>>
>>
>>
>> -- System Information:
>> Debian Release: 9.2
>>   APT prefers stable-updates
>>   APT policy: (500, 'stable-updates'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
>> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
>> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages cinnamon depends on:
>> ii  caribou  0.4.21-1+b1
>> ii  cinnamon-common  3.2.7-4
>> ii  cinnamon-control-center  3.2.1-3
>> ii  cinnamon-desktop-data3.2.4-4
>> ii  cinnamon-screensaver 3.2.13-4
>> ii  cinnamon-session 3.2.0-4
>> ii  cinnamon-settings-daemon 3.2.1-3
>> ii  cjs  3.2.0-3
>> ii  cups-pk-helper   0.2.6-1+b1
>> ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
>> ii  gir1.2-accountsservice-1.0   0.6.43-1
>> ii  gir1.2-caribou-1.0   0.4.21-1+b1
>> ii  gir1.2-clutter-1.0   1.26.0+dfsg-3
>> ii  gir1.2-cmenu-3.0 3.2.0-3
>> ii  gir1.2-cogl-1.0  1.22.2-2
>> ii  gir1.2-cvc-1.0   3.2.4-4
>> ii  gir1.2-gdkpixbuf-2.0 2.36.5-2+deb9u1
>> ii  gir1.2-gkbd-3.0  3.22.0.1-1+b1
>> ii  gir1.2-glib-2.0  1.50.0-1+b1
>> ii  gir1.2-gnomedesktop-3.0  3.22.2-1
>> ii  gir1.2-gtk-3.0   3.22.11-1
>> ii  gir1.2-gtkclutter-1.01.8.2-2
>> ii  gir1.2-javascriptcoregtk-3.0 2.4.11-3
>> ii  gir1.2-keybinder-3.0 0.3.1-1
>> ii  gir1.2-meta-muffin-0.0   3.2.1-2
>> ii  gir1.2-networkmanager-1.01.6.2-3
>> ii  gir1.2-notify-0.70.7.7-2
>> ii  gir1.2-pango-1.0 1.40.5-1
>> ii  gir1.2-polkit-1.00.105-18
>> ii  gir1.2-soup-2.4  2.56.0-2+deb9u1
>> ii  gir1.2-upowerglib-1.00.99.4-4+b1
>> ii  gir1.2-xapp-1.0  1.0.2-1
>> ii  gkbd-capplet 3.22.0.1-1+b1
>> ii  gnome-backgrounds3.22.1-1
>> ii  gnome-themes-standard3.22.2-2
>> ii  gsettings-desktop-schemas3.22.0-1
>> ii  iso-flags-png-320x2401.0.1-1
>> ii  libatk-bridge2.0-0   2.22.0-2
>> ii  libatk1.0-0  2.22.0-1
>> ii  libc62.24-11+deb9u1
>> ii  libcairo21.14.8-1
>> ii  libcinnamon-menu-3-0 3.2.0-3
>> ii  libcjs0  3.2.0-3
>> ii  libclutter-1.0-0 1.26.0+dfsg-3
>> ii  libcogl-pango20  1.22.2-2
>> ii  libcogl-path20   1.22.2-2
>> ii  libcogl201.22.2-2
>> ii  libcroco30.6.11-3
>> ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u1
>> ii  libgirepository-1.0-1

Bug#879785: cinnamon: windows lose focus often

[Christophe Collaudin]

hi,
here are my response

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

   * What led up to the situation?
   = No specific led, just the terminal "ctrl+alt+F1-6" are OK,
but no respond on Cinnamon (mouse is moving, but cannot do [atl]+[Tab], the
more time, I need to reboot

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   = the mouse work, but impossible to change focus on windows
or to close
   * What was the outcome of this action?

   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

2017-10-25 21:57 GMT+02:00 collo :

> Package: cinnamon
> Version: 3.2.7-4
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
>
> -- System Information:
> Debian Release: 9.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages cinnamon depends on:
> ii  caribou  0.4.21-1+b1
> ii  cinnamon-common  3.2.7-4
> ii  cinnamon-control-center  3.2.1-3
> ii  cinnamon-desktop-data3.2.4-4
> ii  cinnamon-screensaver 3.2.13-4
> ii  cinnamon-session 3.2.0-4
> ii  cinnamon-settings-daemon 3.2.1-3
> ii  cjs  3.2.0-3
> ii  cups-pk-helper   0.2.6-1+b1
> ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
> ii  gir1.2-accountsservice-1.0   0.6.43-1
> ii  gir1.2-caribou-1.0   0.4.21-1+b1
> ii  gir1.2-clutter-1.0   1.26.0+dfsg-3
> ii  gir1.2-cmenu-3.0 3.2.0-3
> ii  gir1.2-cogl-1.0  1.22.2-2
> ii  gir1.2-cvc-1.0   3.2.4-4
> ii  gir1.2-gdkpixbuf-2.0 2.36.5-2+deb9u1
> ii  gir1.2-gkbd-3.0  3.22.0.1-1+b1
> ii  gir1.2-glib-2.0  1.50.0-1+b1
> ii  gir1.2-gnomedesktop-3.0  3.22.2-1
> ii  gir1.2-gtk-3.0   3.22.11-1
> ii  gir1.2-gtkclutter-1.01.8.2-2
> ii  gir1.2-javascriptcoregtk-3.0 2.4.11-3
> ii  gir1.2-keybinder-3.0 0.3.1-1
> ii  gir1.2-meta-muffin-0.0   3.2.1-2
> ii  gir1.2-networkmanager-1.01.6.2-3
> ii  gir1.2-notify-0.70.7.7-2
> ii  gir1.2-pango-1.0 1.40.5-1
> ii  gir1.2-polkit-1.00.105-18
> ii  gir1.2-soup-2.4  2.56.0-2+deb9u1
> ii  gir1.2-upowerglib-1.00.99.4-4+b1
> ii  gir1.2-xapp-1.0  1.0.2-1
> ii  gkbd-capplet 3.22.0.1-1+b1
> ii  gnome-backgrounds3.22.1-1
> ii  gnome-themes-standard3.22.2-2
> ii  gsettings-desktop-schemas3.22.0-1
> ii  iso-flags-png-320x2401.0.1-1
> ii  libatk-bridge2.0-0   2.22.0-2
> ii  libatk1.0-0  2.22.0-1
> ii  libc62.24-11+deb9u1
> ii  libcairo21.14.8-1
> ii  libcinnamon-menu-3-0 3.2.0-3
> ii  libcjs0  3.2.0-3
> ii  libclutter-1.0-0 1.26.0+dfsg-3
> ii  libcogl-pango20  1.22.2-2
> ii  libcogl-path20   1.22.2-2
> ii  libcogl201.22.2-2
> ii  libcroco30.6.11-3
> ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u1
> ii  libgirepository-1.0-11.50.0-1+b1
> ii  libgl1-mesa-glx [libgl1] 13.0.6-1+b2
> ii  libglib2.0-0 2.50.3-2
> ii  libglib2.0-bin   2.50.3-2
> ii  libgstreamer1.0-01.10.4-1
> ii  libgtk-3-0   3.22.11-1
> ii  libjs-jquery 

Bug#879875: freeipmi FTCBFS: configure misdetetcs features using the build architecture cpp

[Helmut Grohne]

Source: freeipmi
Version: 1.4.11-1.1
Tags: upstream patch
User: helm...@debian.org
Usertags: rebootstrap

freeipmi fails to cross build from source, because configure misdetects
some features, because it uses the build architecture cpp rather than
the host architecture one. This leads to compilation failures down the
road. The culprit is setting CPP with AC_PATH_PROG. After replacing path
with AC_PROG_CPP, the build succeeds, but the generation of manual pages
now fails, because that $(CPP) invocation assumes cpp semantics while
configure sets it to $ac_tool_prefix-gcc -E. So the attached patch also
sets up a CPP_FOR_BUILD to cover the manual pages. After applying it
freeipmi cross builds successfully. Please use it.

Helmut
Index: freeipmi-1.4.11/configure.ac
===
--- freeipmi-1.4.11.orig/configure.ac
+++ freeipmi-1.4.11/configure.ac
@@ -283,10 +283,12 @@
 dnl Needed for per-target flags
 AM_PROG_CC_C_O
 AC_PROG_LIBTOOL
-AC_PATH_PROG([CPP], [cpp])
-if test -z "${CPP}"; then
+AC_PROG_CPP
+AC_PATH_PROG([CPP_FOR_BUILD], [cpp])
+if test -z "${CPP_FOR_BUILD}"; then
   AC_MSG_ERROR([cannot find cpp])
 fi
+AC_SUBST([CPP_FOR_BUILD])
 AM_CONDITIONAL(WITH_GNU_LD, test "$with_gnu_ld" = "yes")
 AC_PROG_MAKE_SET
 AC_PROG_LN_S
Index: freeipmi-1.4.11/man/Makefile.am
===
--- freeipmi-1.4.11.orig/man/Makefile.am
+++ freeipmi-1.4.11/man/Makefile.am
@@ -189,7 +189,7 @@
 	manpage-common-legacy-output.man
 
 $(MANS_CPP): $(MANS_CPP:%=%.pre)
-	$(CPP) -nostdinc -w -C -P -I$(top_srcdir)/man $@.pre  $@
+	$(CPP_FOR_BUILD) -nostdinc -w -C -P -I$(top_srcdir)/man $@.pre $@
 
 CLEANFILES = $(MANS_CPP) *~
 DISTCLEANFILES = $(MANS_CPP) $(MANS_CPP:%=%.pre) .deps/*.P

Bug#871314: pysam 0.12 depends on libhts2 1.5

[Trout, Diane E.]

The new version of pysam 0.12 requires libhts2 1.5.

Unfortunately pysam 0.12 just migrated to testing, and libhts2 was
blocked from migrating by this bug because it breaks pysam 0.11


Diane

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

Bug#879544: transition: netcdf

[Sebastiaan Couwenberg]

On 10/26/2017 10:12 AM, Emilio Pozuelo Monfort wrote:
> On 22/10/17 20:20, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> Control: block -1 by 878818
>> Control: forwarded -1 
>> https://release.debian.org/transitions/html/auto-netcdf.html
>>
>> NetCDF 4.5.0 has been released and bumps the SOVERSION to 13 requiring a
>> transition.
>>
>> The release candidates have been available in experimental for a while
>> and the final release is there now. It built successfully on all release
>> architectures, and also on hurd & kfreebsd after a fix to the symbols
>> file.
>>
>> Only a single package failed to build, and not due to the changes in netcdf:
> 
> Sounds good. Please go ahead, now that python3.6 is done.

Thanks. netcdf (1:4.5.0-1) has been uploaded to unstable, and built
successfully on all release architectures.

Kind Regards,

Bas

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

Bug#879874: Updating the transmissionrpc Uploaders list

[Tobias Frost]

Source: transmissionrpc
Version: 0.11-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Timur Birsh  wishes no longer to be uploader of 
transmissionrpc.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#849832: icedove: contains JSHint work under non-free licence

[Carsten Schoenert]

Control: tags -1 pending

Dear FTP Team,

could you please remove the following as 'found in version' icedove
packages by Ben Finney and also the respectively source tarballs from
the archive?
As Ben pointed out the marked versions containing a non-free files and
thus the the source tarballs are not DFSG clean.
The affected versions are quite older now and a removal doesn't affect
existing user installations due the up2date security versions in all
releases.

On Tue, Apr 12, 2016 at 03:58:34PM +1000, Ben Finney wrote:

> Control: found -1 icedove/31.5.0-1~deb7u1
> Control: found -1 icedove/31.8.0-1~deb7u1
> Control: found -1 icedove/31.8.0-1~deb8u1
> Control: found -1 icedove/40.0~b1-1
> Control: found -1 icedove/42.0~b2-1

> 
> On 28-Jan-2016, Bastien ROUCARIES wrote:
> > mozilla/dom/system/gonk/tests/marionette/ril_jshint/jshint.js
> > 
> > is licenced under evil licence...
> 
> This is (not an identical copy, but clearly derived from) JSHint
> version 2.1.3 .
> 
> Receipients do not have free-software license in this work. The only
> license granted has the non-free “Good, not Evil” restriction.
> 
> > Please repack and notify archive.debian.org in order to remove old
> > package.
> 
> This same content is found (according to sources.debian.net) in:
> 
> * firefox
> * firefox-esr
> * iceweasel
> * icedove
> 
> 
> 
> Maintainer, should we make separate bug reports for each of those?

PS: Maybe this email comes as double to you (wrongly addressed to
#813054, that's the bug report for firefox-esr), bugs.debian.org was a
bit 'tenacious' yesterday.
I already have written yesterday a email to the BTS but I haven't got a
feedback mail from the system about processing.

Regards and thanks!
Carsten

Bug#867588: buildbot: application fails at runtime requiring sqlalchemy-migrate==0.7.2

[José Carlos]

Bump. Any updates for this bug?

-- 
José Carlos Capurro
(595) 994 40 0144

Bug#879873: O: sxid -- suid, sgid file and directory checking

[Tobias Frost]

Package: wnpp

The current maintainer of sxid, Timur Birsh ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: sxid
Binary: sxid
Version: 4.20130802-1
Maintainer: Timur Birsh 
Build-Depends: debhelper (>= 9)
Architecture: any
Standards-Version: 3.9.4
Format: 3.0 (quilt)
Files:
 fac754c0e9b4ee1fe5dc4095b81e4085 1789 sxid_4.20130802-1.dsc
 0c57c61531ee5f702333644186ce4948 117411 sxid_4.20130802.orig.tar.gz
 a3094c40705af9525cbe1fae4ab8b71d 6160 sxid_4.20130802-1.debian.tar.xz
Vcs-Browser: https://github.com/taem/sxid/tree/deb
Vcs-Git: https://github.com/taem/sxid.git -b deb
Checksums-Sha256:
 79d02eaa40bc2dd4b919bb58e9d6dd78b06ecb85786bc7d6e55fea0c233ec0f9 1789 
sxid_4.20130802-1.dsc
 935d665dc508bc537bc4d0fca352a66610dc8e945d9aeee246b0546a86100124 117411 
sxid_4.20130802.orig.tar.gz
 3cd67ab62bee19ba491f92d2825be24c9420992281b6091b10b9aaa39cee9967 6160 
sxid_4.20130802-1.debian.tar.xz
Homepage: http://linukz.org/sxid.shtml
Package-List: 
 sxid deb admin extra
Directory: pool/main/s/sxid
Priority: source
Section: admin

Package: sxid
Source: sxid (4.20130802-1)
Version: 4.20130802-1+b1
Installed-Size: 75
Maintainer: Timur Birsh 
Architecture: amd64
Depends: libc6 (>= 2.4), exim4 | mail-transport-agent
Description-en: suid, sgid file and directory checking
 This program runs as a cronjob. Basically it tracks any changes in
 your s[ug]id files and folders. If there are any new ones, ones that
 aren't set any more, or they have changed bits or other modes, then it
 reports the changes. You can also run this manually for spot checking.
 .
 It tracks s[ug]id files by SHA-256 checksums. This helps detect if your files
 have been tampered with, would not show under normal name and permissions
 checking. Directories are tracked by inodes.
Description-md5: 3dd02068d3ff5b761c45f4f02ec71a25
Homepage: http://linukz.org/sxid.shtml
Tag: admin::monitoring, implemented-in::c, interface::commandline,
 interface::daemon, role::program, scope::utility, use::monitor,
 works-with::file
Section: admin
Priority: optional
Filename: pool/main/s/sxid/sxid_4.20130802-1+b1_amd64.deb
Size: 31590
MD5sum: 5124f381745f42422a00a750cbf12ef9
SHA256: ff49274488365e9c0ef6e1d183a60e6fe3aa99619b055ed13a21141cf104b888



signature.asc
Description: PGP signature

Bug#879871: O: hunspell-kk -- Kazakh dictionary for hunspell

[Tobias Frost]

Package: wnpp

The current maintainer of hunspell-kk, Timur Birsh ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: hunspell-kk
Binary: hunspell-kk
Version: 1.1-2
Maintainer: Timur Birsh 
Build-Depends: debhelper (>= 7.0.50~)
Build-Depends-Indep: dictionaries-common-dev (>= 1.10.5)
Architecture: all
Standards-Version: 3.9.2
Format: 3.0 (quilt)
Files:
 0704ab77602cd0fe13a3deda738960bb 1223 hunspell-kk_1.1-2.dsc
 919e2de38103b71ec37a1d036d96c156 212888 hunspell-kk_1.1.orig.tar.gz
 3071ce0ab187a2a6894cba8b05ddcacd 2622 hunspell-kk_1.1-2.debian.tar.gz
Vcs-Browser: http://github.com/taem/hunspell-kk/tree/master
Vcs-Git: git://github.com/taem/hunspell-kk.git
Checksums-Sha256:
 99c90d1c799f39b779a727fe7082f04a6742fdf3465b608bafd8765e3fd61720 1223 
hunspell-kk_1.1-2.dsc
 ffe23073970599a593c9ab986b6d4234e14f80c38b7402414668ff9d91f5b793 212888 
hunspell-kk_1.1.orig.tar.gz
 7a8efc986d3e68a57ff9553a5e48d276a01ec38337748ad7920fca737d79e933 2622 
hunspell-kk_1.1-2.debian.tar.gz
Homepage: http://extensions.services.openoffice.org/en/project/dict-kk
Directory: pool/main/h/hunspell-kk
Priority: source
Section: text

Package: hunspell-kk
Version: 1.1-2
Installed-Size: 2256
Maintainer: Timur Birsh 
Architecture: all
Provides: hunspell-dictionary, hunspell-dictionary-kk, myspell-dictionary, 
myspell-dictionary-kk
Depends: dictionaries-common (>= 1.10.5)
Suggests: iceape-browser | iceweasel | icedove, openoffice.org (>= 1.0.3-3)
Conflicts: openoffice.org (<= 1.0.3-2)
Description-en: Kazakh dictionary for hunspell
 This dictionary contains Kazakh wordlist for the hunspell
 spellchecker currently supported by Mozilla and OpenOffice.
Description-md5: 2a25a1bf5003dfcc4ae3090cbf1088f8
Homepage: http://extensions.services.openoffice.org/en/project/dict-kk
Tag: culture::kazakh, made-of::dictionary, role::app-data, suite::kde,
 suite::mozilla, suite::openoffice, use::checking
Section: text
Priority: optional
Filename: pool/main/h/hunspell-kk/hunspell-kk_1.1-2_all.deb
Size: 216296
MD5sum: 53bc07a218472ff69e5cb48311de7a74
SHA256: f31b307cfb4c5614ef92a76b6cda2cb069b7ffefce6161623f1c0ec59428deb0



signature.asc
Description: PGP signature

Bug#879870: O: cd-discid -- CDDB DiscID utility

[Tobias Frost]

Package: wnpp

The current maintainer of cd-discid, Timur Birsh ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: cd-discid
Binary: cd-discid
Version: 1.4-1
Maintainer: Timur Birsh 
Build-Depends: debhelper (>= 9)
Architecture: any
Standards-Version: 3.9.4
Format: 3.0 (quilt)
Files:
 a1f8ffe6b39459e75257f59d2281772c 1798 cd-discid_1.4-1.dsc
 85027b71d08fbbfb11ac2f0db6e8cea7 12435 cd-discid_1.4.orig.tar.gz
 74e2162a1803de28e9ed9c81a9744b6b 3340 cd-discid_1.4-1.debian.tar.xz
Vcs-Browser: https://github.com/taem/cd-discid/tree/deb
Vcs-Git: git://github.com/taem/cd-discid.git -b deb
Checksums-Sha256:
 f2f683c7a6e326bed928da44b3a1bdb90ae2abe8fdf0570cfaeef4a1674c8dcb 1798 
cd-discid_1.4-1.dsc
 ffd68cd406309e764be6af4d5cbcc309e132c13f3597c6a4570a1f218edd2c63 12435 
cd-discid_1.4.orig.tar.gz
 bbe011cf289773c5abea4b68ebf4177c5dafc9fa00db74638dfc7d3e3ee0e4d6 3340 
cd-discid_1.4-1.debian.tar.xz
Homepage: http://linukz.org/cd-discid.shtml
Package-List: 
 cd-discid deb sound optional
Directory: pool/main/c/cd-discid
Priority: source
Section: sound

Package: cd-discid
Source: cd-discid (1.4-1)
Version: 1.4-1+b1
Installed-Size: 30
Maintainer: Timur Birsh 
Architecture: amd64
Depends: libc6 (>= 2.4)
Description-en: CDDB DiscID utility
 In order to do CDDB queries over the Internet, you must know the DiscID of
 the CD you are querying. cd-discid provides you with that information. It
 outputs the discid, the number of tracks, the frame offset of all of the
 tracks, and the total length of the CD in seconds, on one line in
 a space-delimited format. cd-discid was designed as a backend tool for
 cdgrab (now abcde) but will work independently of it.
Description-md5: 5e36cbcb6bf4b1b7273d65c78305914d
Homepage: http://linukz.org/cd-discid.shtml
Tag: hardware::storage, hardware::storage:cd, implemented-in::c,
 interface::commandline, protocol::http, role::program,
 works-with-format::iso9660, works-with::archive, works-with::audio
Section: sound
Priority: optional
Filename: pool/main/c/cd-discid/cd-discid_1.4-1+b1_amd64.deb
Size: 10278
MD5sum: 63444c3dcc1832d968bc39e0e783ba25
SHA256: 5d3e18dee1744e73065a9af62cf6a98cc9dc8dcbe8b5a82d5e6f6004887f3545



signature.asc
Description: PGP signature

Bug#879869: O: aspell-kk -- Kazakh dictionary for GNU Aspell

[Tobias Frost]

Package: wnpp

The current maintainer of aspell-kk, Timur Birsh ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: aspell-kk
Binary: aspell-kk
Version: 0.2-1
Maintainer: Timur Birsh 
Build-Depends: debhelper (>= 7.0.50~), dictionaries-common-dev (>= 0.9.1), 
aspell (>= 0.60)
Architecture: all
Standards-Version: 3.9.1
Format: 3.0 (quilt)
Files:
 d0879ce4f3973ab2c65db9861d4754b9 1187 aspell-kk_0.2-1.dsc
 4fa3331957b6bffa5576faebe450a8f1 562356 aspell-kk_0.2.orig.tar.bz2
 c2d61bcdb8f1c439f9032cedcf2d5d03 2318 aspell-kk_0.2-1.debian.tar.bz2
Vcs-Browser: http://github.com/taem/aspell-kk/tree/master
Vcs-Git: git://github.com/taem/aspell-kk.git
Checksums-Sha256:
 91cc122f667d966689aab1b04fb738b816eeb312cb7c0dbc845bcd7775d34d8f 1187 
aspell-kk_0.2-1.dsc
 9f7e165dd4f911a4c0fbdc9b8c9cc20b1afee75e0534dca7fca2678816fc59d0 562356 
aspell-kk_0.2.orig.tar.bz2
 0f87d0687287dc8f0014375beeb8521135681f35dfbd8c53ac5ac6ddba03214b 2318 
aspell-kk_0.2-1.debian.tar.bz2
Homepage: http://sourceforge.net/projects/kazlinux/
Directory: pool/main/a/aspell-kk
Priority: source
Section: text

Package: aspell-kk
Version: 0.2-1
Installed-Size: 244
Maintainer: Timur Birsh 
Architecture: all
Provides: aspell-dictionary
Depends: aspell (>= 0.60), dictionaries-common (>= 0.9.1)
Description-en: Kazakh dictionary for GNU Aspell
 This package contains all the required files to add support
 for Kazakh language to the GNU Aspell spell checker.
Description-md5: 18d7b9858cc5cf55776acb5372fcef1c
Homepage: http://sourceforge.net/projects/kazlinux/
Tag: culture::kazakh, made-of::dictionary, role::app-data, use::checking
Section: text
Priority: optional
Filename: pool/main/a/aspell-kk/aspell-kk_0.2-1_all.deb
Size: 119182
MD5sum: aafd2f4cc1680632dd78a78df23becdb
SHA256: 6a021f797af1e1852d1fe509f226880bc4935a08297bbc0b86b8d9fdce523360



signature.asc
Description: PGP signature

Bug#784029: RFP: libcdio-paranoia

[Matthias Klose]

Hi, I'll upload libcdio-paranoia 0.94 to experimental, because it's needed for
the libcdio 0.94 update.   I don't intend to maintain this package, so feel free
to suggest yourself as an uploader or maintainer, however I'd like to see the
GCC 7 build failures fixed.

Matthias

Bug#879868: Orphan libcue

[Taylor LeMasurier-Wren]

Package: libcue

I wish to orphan this package because I no longer actively use Debian and I
don't plan on working on packages for now.

Bug#879529: transition: perl 5.26.1

[Sven Joachim]

On 2017-10-26 10:18 +0200, Emilio Pozuelo Monfort wrote:

> On 26/10/17 09:13, Niko Tyni wrote:
>> On Mon, Oct 23, 2017 at 09:15:35PM +0200, Emilio Pozuelo Monfort wrote:
>>> Control: tags -1 confirmed

 perl 5.26.1-1 is in experimental. It is binary compatible with 5.26.0
 and therefore Provides both perlapi-5.26.0 and perlapi-5.26.1. However,
 four binNMUs will be needed once it enters unstable due to their strict
 versioned dependencies on the current perl version:

  libpar-packer-perl
  libdevel-cover-perl
  libclass-xsaccessor-perl
  libcommon-sense-perl

 Please let us know if/when it's OK to upload.
>>>
>>> Please go ahead.
>> 
>> Thanks, now uploaded and built on all architectures.
>> Could you please schedule the binNMUs.
>
> Scheduled.

It seems that something went wrong here and perl was not upgraded to
5.26.1 on the buildd chroots, meaning the binNMUs were wasted. :-(

Cheers,
   Sven