Bug#844189: qemu-kvm: virtinst with initrd-inject and location hangs since 2.7+dfsg-3~bpo8+2

[Andreas Herrmann]

Package: qemu-kvm
Version: 1:2.7+dfsg-3~bpo8+2
Severity: important

After upgrading from 2.6+dfsg-3.1~bpo8+1 to 2.7+dfsg-3~bpo8+2
virt-install does not longer work. No matter if using LVM or
FiberChannel Storage

/usr/bin/virt-install --debug --connect=qemu:///system --name damhirsch
--ram=512 --disk=/dev/mapper/sav01_damhirsch,bus=virtio,cache=none
--vcpus 2 --network network=br905,mac=52:54:00:97:80:13 --virt-type kvm
--cpu kvm64 --os-type linux --os-variant=debianwheezy
--initrd-inject=preseed.cfg
--location=http://ftp.de.debian.org/debian/dists/jessie/main/installer-amd64
--graphics none --extra-args='auto=false console=tty0
console=ttyS0,115200n8 serial'

This command would start an installtion on 2.6+dfsg-3.1~bpo8+1 but it
just hangs without error:


[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (cli:187) Launched
with command line: /usr/share/virt-manager/virt-install --debug
--connect=qemu:///system --name damhirsch --ram=512
--disk=/dev/mapper/sav01_damhirsch,bus=virtio,cache=none --vcpus 2
--network network=br905,mac=52:54:00:97:80:13 --virt-type kvm --cpu
kvm64 --os-type linux --os-variant=debianwheezy
--initrd-inject=preseed.cfg
--location=http://ftp.de.debian.org/debian/dists/jessie/main/installer-amd64
--graphics none --extra-args=auto=false console=tty0
console=ttyS0,115200n8 serial
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (cli:195)
Requesting libvirt URI qemu:///system
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (cli:199) Received
libvirt URI qemu:///system
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (virt-install:193)
Requesting virt method 'default', hv type 'kvm'.
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (virt-install:432)
Received virt method 'kvm'
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (virt-install:433)
Hypervisor name is 'hvm'
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (guest:208) Setting
Guest.os_variant to 'debianwheezy'
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG
(distroinstaller:403) DistroInstaller location is a network source.
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:302)
Finding distro store for
location=http://ftp.de.debian.org/debian/dists/jessie/main/installer-amd64
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:142)
HTTP hasFile: didn't find
http://ftp.de.debian.org/debian/dists/jessie/main/installer-amd64/.treeinfo:
HTTP Error 404: Not Found
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:325)
Prioritizing distro store=
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:99)
Fetching URI:
http://ftp.de.debian.org/debian/dists/jessie/main/installer-amd64/current/images/MANIFEST
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:110)
Saved file to /var/tmp/virtinst-MANIFEST.3Y61nb
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:340)
Detected distro name=Debian osvariant=linux
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (virt-install:551)
Guest.has_install_phase: True

Starting install...
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG
(distroinstaller:417) Using scratchdir=/var/lib/libvirt/boot
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:302)
Finding distro store for
location=http://ftp.de.debian.org/debian/dists/jessie/main/installer-amd64
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:142)
HTTP hasFile: didn't find
http://ftp.de.debian.org/debian/dists/jessie/main/installer-amd64/.treeinfo:
HTTP Error 404: Not Found
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:325)
Prioritizing distro store=
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:99)
Fetching URI:
http://ftp.de.debian.org/debian/dists/jessie/main/installer-amd64/current/images/MANIFEST
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:110)
Saved file to /var/lib/libvirt/boot/virtinst-MANIFEST.6vZYMM
Retrieving file MANIFEST...
| 3.3 kB 00:00 ... 
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:340)
Detected distro name=Debian osvariant=linux
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:99)
Fetching URI:
http://ftp.de.debian.org/debian/dists/jessie/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:110)
Saved file to /var/lib/libvirt/boot/virtinst-linux.gbnRDk
Retrieving file linux...
| 6.0 MB 00:00 ... 
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:99)
Fetching URI:
http://ftp.de.debian.org/debian/dists/jessie/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG (urlfetcher:110)
Saved file to /var/lib/libvirt/boot/virtinst-initrd.gz.Ufsdsd
Retrieving file initrd.gz...
|  29 MB 00:00 ... 
[Sun, 13 Nov 2016 08:47:55 virt-install 14115] DEBUG
(distroinstaller:233) Copying preseed.cfg to the initrd.

Bug#844185: RFS: fvwm/2.6.7 (Update)

[Jaimos Skriletz]

Hello,

I was running a test in a clean build environment and found an error
with lintian. This has been fixed. I also updated the maintainers name
to mine in the control file. The files for review have been updated.

http://fvwmforums.org/fvwm-2.6.7/

jaimos

Bug#722249: Current status?

[Petter Reinholdtsen]

I just uploaded simplescreenrecorder again to unstable based on the
package available as 0.3.6-7 from
https://mentors.debian.net/package/simplescreenrecorder >.

I fixed an issue with the rules file, corrected the copyright file and
merged the changelog entries to make sure the -1 entry is the first one
in Debian.  The diff is attached.

-- 
Happy hacking
Petter Reinholdtsen
diff --git a/debian/changelog b/debian/changelog
index 45aa523..1eaec6b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,22 +1,26 @@
-simplescreenrecorder (0.3.6-7) unstable; urgency=medium
+simplescreenrecorder (0.3.6-1) unstable; urgency=medium
 
   * Team upload.
-  * Initial release. (Closes: #782804: ITP: simplescreenrecorder --
-Screen recorder for X11 and OpenGL)
-  * Initial release. (Closes: #722249: ITP: simplescreenrecorder -- a
-simple program to record)
+  * Initial release. (Closes: #782804, #722249)
+
+  [ Olivier Humbert ]
+  * Changed to use ffmpeg instead of libav.
+  * debian/patches/1001-build-failure-fix.patch:
+- added following Sebastinas suggestion on #debian-multimedia@oftc.
+- patch has been included upstream.
   * debian/changelog :
-- upload to unstable rather than UNRELEASED.
-- cleaning the "Initial release" from previous entries.
+- translate the French parts of the past entries to English.
   * debian/libsimplescreenrecorder.install
-- remove this file to fit everything in only one package. See 
+- remove this file to fit everything in only one package. See
   https://github.com/MaartenBaert/ssr/issues/464 .
   * debian/simplescreenrecorder.install :
 - removing this file - not needed anymore.
   * debian/simplescreenrecorder.triggers :
-- rename "debian/libsimplescreenrecorder.triggers" ->
-  "debian/simplescreenrecorder.triggers".
+- added to fix the "package-must-activate-ldconfig-trigger" error
+  reported by Lintian, following this recommendation:
+  https://lintian.debian.org/tags/package-must-activate-ldconfig-trigger.html.
   * debian/control :
+- change the Maintainer field to the debian-multimedia team.
 - remove package creation for libsimplescreenrecorder.
 - remove the "Recommends: libsimplescreenrecorder (= ${binary:Version})"
   since it doesn't exist anymore as an external package but is incorporated
@@ -25,48 +29,16 @@ simplescreenrecorder (0.3.6-7) unstable; urgency=medium
   * debian/sources/lintian-overrides :
 - adding this file to relax lintian output's 2 warnings.
   * debian/rules :
-- removing the *.la files.
-
- -- Olivier Humbert   Mon, 12 Sep 2016 23:56:51 +0200
-
-simplescreenrecorder (0.3.6-6) UNRELEASED; urgency=medium
-
-  * Team upload.
-- fixing the "package-must-activate-ldconfig-trigger" error reported by
-  Lintian for the libsimplescreenrecorder package.
-  * debian/libsimplescreenrecorder.triggers:
-- file created, following this recommendation:
-https://lintian.debian.org/tags/package-must-activate-ldconfig-trigger.html
-
- -- Olivier Humbert   Wed, 08 Jun 2016 10:50:10 +0200
-
-simplescreenrecorder (0.3.6-5) UNRELEASED; urgency=medium
-
-  * Team upload.
-- switch from libav to ffmpeg.
-  * debian/rules:
 - remove the "--disable-ffmpeg-versions" configure option.
-  * debian/patches/1001-build-failure-fix.patch:
-- patch has been included upstream.
-  * debian/control:
-change the Maintainer field to the debian-multimedia team.
-  * debian/changelog:
-- translate the French parts of the past entries to English.
-
- -- Olivier Humbert   Tue, 31 May 2016 18:44:46 +0200
-
-simplescreenrecorder (0.3.6-4) UNRELEASED; urgency=medium
-
-  * Team upload.
-  * Patch added following Sebastinas suggestion on #debian-multimedia@oftc.
-
- -- Olivier Humbert   Fri, 27 May 2016 16:58:57 +0200
-
-simplescreenrecorder (0.3.6-3) UNRELEASED; urgency=medium
+- removing the *.la files.
 
-  * Team upload.
+  [ Petter Reinholdtsen ]
+  * debian/copyright :
+- Adjusted based on feedback from 'debmake -k'.
+  * debian/rules :
+- Made sure .la files are removed after they are installed.
 
- -- Olivier Humbert   Fri, 27 May 2016 15:38:46 +0200
+ -- Petter Reinholdtsen   Sun, 13 Nov 2016 06:57:25 +
 
 simplescreenrecorder (0.3.6-0librazik3) jessie; urgency=medium
 
diff --git a/debian/copyright b/debian/copyright
index 2665be2..1b1e7b1 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -10,7 +10,7 @@ Files:
  glinject/elfhacks.c
  glinject/elfhacks.h
 Copyright: 2007-2008 Pyry Haulos 
-License: as-is-1
+License: Zlib
  This software is provided 'as-is', without any express or implied warranty.
  In no event will the authors be held liable for any damages arising from the
  use of this software.
@@ -36,9 +36,8 @@ Files:
  glinject/Global.h
  glinject/GLXFrameGrabber.h
  

Bug#844188: pdf2htmlex: FTBFS with fontforge due to use of library_version_configuration structure

[Vasudev Kamath]

Source: pdf2htmlex
Severity: serious
User: pkg-fonts-de...@lists.alioth.debian.org
Usertags: fontforge-transition

Dear Maintainer,

pdf2htmlex fails to build with new fontforge uploaded to unstable. The build
logs can be found here ¹. This mainly happening due to use of
*library_version_configuration* structure which is not public in new fontforge.

I also tried building pdf2htmlex by removing patch _allow-old-libfontforge_ and
pdf2htmlex builds fine. Since new fontforge is already in unstable it should be
now safe to drop this patch.

¹ https://angband.pl/tmp/ff13/failed/pdf2htmlex_amd64.build

Best Regards,

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

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

Bug#824532: udev: Include udev rules for more U2F devices

[Simon Josefsson]

Hi. The udev file is needed by all applications using u2f, and not all uses 
libu2f-host.  For example, chromium needs the udev rule to work. It just needs 
to be present on all systems for u2f to work. Alternatively, every package that 
wants to talk to a u2f device needs to ship the file which doesn't scale very 
well. Is there any history regarding other udev files for hardware with similar 
properties?

/Simon

Michael Biebl  skrev: (12 november 2016 21:10:20 CET)
>Control: tags -1 + moreinfo
>
>On Tue, 17 May 2016 17:43:45 +1000 Robert Norris 
>wrote:
>> Package: udev
>> Version: 229-6
>> Severity: wishlist
>> 
>> 70-debian-uaccess.rules includes rules for Yubico U2F devices. There
>are
>> other U2F devices coming onto the market, and it would be good to
>> include those too.
>> 
>> https://github.com/Yubico/libu2f-host/blob/master/70-u2f.rules
>> 
>
>Hm, I'm not sure if shipping 70-debian-uaccess.rules in the udev
>package
>was a good idea in the first place. Imho this file should be maintained
>by the libu2f-host package, and apparently it already ships a rules
>file
>for that
>
>Martin, can we please drop debian/extra/rules/70-debian-uaccess.rules
>and reassign this bug to libu2f-host?
>
>I see that the rules file currently shipped by libu2f-host0 is using
>group plugdev, but that is a bug in the package. It should have a
>build-depends on udev, so it installs the correct version:
>
>PKG_CHECK_MODULES([UDEV], [udev >= 188],
>  udevrulesfile=70-u2f.rules,
>  udevrulesfile=70-old-u2f.rules,
>  )
>
>The package should install 70-u2f.rules and not 70-old-u2f.rules
>-- 
>Why is it that all of the instruments seeking intelligent life in the
>universe are pointed away from Earth?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#844187: lspci -v for Bug #844187

[Paul Harper]

pharper@artilect:~/Videos$ lspci -v
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family
DRAM Controller (rev 09)
Subsystem: Intel Corporation 2nd Generation Core Processor Family DRAM
Controller
Flags: bus master, fast devsel, latency 0
Capabilities: 

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Intel Corporation 2nd Generation Core Processor Family
Integrated Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at e000 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 1000 [size=64]
Expansion ROM at  [disabled]
Capabilities: 
Kernel driver in use: i915

00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series
Chipset Family MEI Controller #1 (rev 04)
Subsystem: Intel Corporation 7 Series/C210 Series Chipset Family MEI
Controller #1
Flags: bus master, fast devsel, latency 0, IRQ 43
Memory at e0706100 (64-bit, non-prefetchable) [size=16]
Capabilities: 
Kernel driver in use: mei_me

00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI])
Subsystem: Intel Corporation 7 Series/C210 Series Chipset Family USB
Enhanced Host Controller #2
Flags: bus master, medium devsel, latency 0, IRQ 21
Memory at e0705800 (32-bit, non-prefetchable) [size=1K]
Capabilities: 
Kernel driver in use: ehci-pci

00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family
High Definition Audio Controller (rev 04)
Subsystem: Intel Corporation 7 Series/C210 Series Chipset Family High
Definition Audio Controller
Flags: bus master, fast devsel, latency 0, IRQ 44
Memory at e070 (64-bit, non-prefetchable) [size=16K]
Capabilities: 
Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family
PCI Express Root Port 2 (rev c4) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: e040-e04f
Capabilities: 
Kernel driver in use: pcieport

00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family
PCI Express Root Port 3 (rev c4) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
Memory behind bridge: e060-e06f
Prefetchable memory behind bridge: e050-e05f
Capabilities: 
Kernel driver in use: pcieport

00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI])
Subsystem: Intel Corporation 7 Series/C210 Series Chipset Family USB
Enhanced Host Controller #1
Flags: bus master, medium devsel, latency 0, IRQ 19
Memory at e0705c00 (32-bit, non-prefetchable) [size=1K]
Capabilities: 
Kernel driver in use: ehci-pci

00:1f.0 ISA bridge: Intel Corporation 7 Series Chipset Family LPC
Controller (rev 04)
Subsystem: Intel Corporation 7 Series Chipset Family LPC Controller
Flags: bus master, medium devsel, latency 0
Capabilities: 
Kernel driver in use: lpc_ich

00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port
SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
Subsystem: Intel Corporation 7 Series Chipset Family 6-port SATA
Controller [AHCI mode]
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 42
I/O ports at 1060 [size=8]
I/O ports at 1070 [size=4]
I/O ports at 1068 [size=8]
I/O ports at 1074 [size=4]
I/O ports at 1040 [size=32]
Memory at e0705000 (32-bit, non-prefetchable) [size=2K]
Capabilities: 
Kernel driver in use: ahci

00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus
Controller (rev 04)
Subsystem: Intel Corporation 7 Series/C210 Series Chipset Family SMBus
Controller
Flags: medium devsel, IRQ 23
Memory at e0706000 (64-bit, non-prefetchable) [size=256]
I/O ports at 0400 [size=32]
Kernel driver in use: i801_smbus

00:1f.6 Signal processing controller: Intel Corporation 7 Series/C210
Series Chipset Family Thermal Management Controller (rev 04)
Flags: fast devsel, IRQ 139
Memory at e0704000 (64-bit, non-prefetchable) [size=4K]
Capabilities: 

01:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network
Adapter (rev 01)
Subsystem: Foxconn International, Inc. Device e052
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at e040 (64-bit, non-prefetchable) [size=512K]
Expansion ROM at e048 [disabled] [size=64K]
Capabilities: 
Kernel driver in use: ath9k

02:00.0 Ethernet controller: Broadcom 

Bug#844186: RFH: libjs-handlebars -- need help in modifying grunt to build libjs-handlebars (and other modules with Gruntfile.js)

[Pirate Praveen]

On Sun, 13 Nov 2016 10:13:46 +0530 Pirate Praveen 
wrote:
> To be able to build libjs-handlebars from handlebars node module, we
> need to modify grunt.

libjs-handlebars$ grunt --verbose
Initializing
Command-line options: --verbose

Reading "Gruntfile.js" Gruntfile...OK

Registering Gruntfile tasks.
Reading package.json...ERROR
Loading "Gruntfile.js" tasks...ERROR
>> Error: Unable to read "package.json" file (Error code: MODULE_NOT_FOUND).
>>   at Object.util.error (/usr/lib/nodejs/grunt-legacy-util/index.js:54:39)
>>   at Object.file.read (/usr/lib/nodejs/grunt/lib/grunt/file.js:235:22)
>>   at Object.file.readJSON (/usr/lib/nodejs/grunt/lib/grunt/file.js:241:18)
>>   at Object.module.exports 
>> (/home/pravi/forge/debian/git/pkg-javascript/libjs-handlebars/Gruntfile.js:5:21)
>>   at loadTask (/usr/lib/nodejs/grunt/lib/grunt/task.js:318:10)
>>   at Task.task.init (/usr/lib/nodejs/grunt/lib/grunt/task.js:437:5)
>>   at Object.grunt.tasks (/usr/lib/nodejs/grunt/lib/grunt.js:111:8)
>>   at Object.module.exports [as cli] 
>> (/usr/lib/nodejs/grunt/lib/grunt/cli.js:27:9)
>>   at Object. (/usr/lib/nodejs/grunt-cli/bin/grunt:49:20)
>>   at Module._compile (module.js:425:26)
>>   at Object.Module._extensions..js (module.js:432:10)
>>   at Module.load (module.js:356:32)
>>   at Function.Module._load (module.js:311:12)
>>   at Function.Module.runMain (module.js:457:10)
>>   at startup (node.js:136:18)
>>   at node.js:972:3

No tasks specified, running default tasks.
Running tasks: default
Warning: Task "default" not found. Use --force to continue.

Aborted due to warnings.



signature.asc
Description: OpenPGP digital signature

Bug#844187: gnome-core: Gnome 3 Brightness Keys not working on Acer C7 Chromebook with Coreboot

[Paul Harper]

Package: gnome-core
Version: 1:3.14+3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
I installed Debian Jessie on my Acer C7 Chromebook. I found that the sound
volume keys worked but the F6-F7 Brightness Keys did not.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
At the command line I can change the brightness with.

 xrandr --output LVDS1 --brightness 0.6


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



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

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

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme 3.14.0-2
ii  at-spi2-core   2.14.0-1
ii  baobab 3.14.1-1
ii  caribou0.4.15-1
ii  caribou-antler 0.4.15-1
ii  dconf-gsettings-backend0.22.0-1
ii  dconf-tools0.22.0-1
ii  empathy3.12.7-1
ii  eog3.14.1-1
ii  evince 3.14.1-2+deb8u1
ii  evolution-data-server  3.12.9~git20141128.5242b0-2+deb8u2
ii  fonts-cantarell0.0.16-1
ii  gdm3   3.14.1-7
ii  gkbd-capplet   3.6.0-1
ii  glib-networking2.42.0-2
ii  gnome-backgrounds  3.14.1-1
ii  gnome-bluetooth3.14.0-2
ii  gnome-calculator   3.14.1-1
ii  gnome-contacts 3.14.1-1
ii  gnome-control-center   1:3.14.2-3
ii  gnome-dictionary   3.14.1-1
ii  gnome-disk-utility 3.12.1-1+b1
ii  gnome-font-viewer  3.14.0-2
ii  gnome-keyring  3.14.0-1+b1
ii  gnome-menus3.13.3-6
ii  gnome-online-accounts  3.14.2-1
ii  gnome-online-miners3.14.0-2
ii  gnome-packagekit   3.14.0-1
ii  gnome-screenshot   3.14.0-1
ii  gnome-session  3.14.0-2
ii  gnome-settings-daemon  3.14.2-3
ii  gnome-shell3.14.4-1~deb8u1
ii  gnome-shell-extensions 3.14.2-1
ii  gnome-sushi3.12.0-2+b1
ii  gnome-system-log   3.9.90-2
ii  gnome-system-monitor   3.14.1-1
ii  gnome-terminal 3.14.1-1+deb8u1
ii  gnome-themes-standard  3.14.2.2-1
ii  gnome-user-guide   3.14.1-1
ii  gnome-user-share   3.14.0-2
ii  gsettings-desktop-schemas  3.14.1-1
ii  gstreamer1.0-plugins-base  1.4.4-2
ii  gstreamer1.0-plugins-good  1.4.4-2
ii  gstreamer1.0-pulseaudio1.4.4-2
ii  gtk2-engines   1:2.20.2-3
ii  gucharmap  1:3.14.1-1
ii  gvfs-backends  1.22.2-1
ii  gvfs-bin   1.22.2-1
ii  gvfs-fuse  1.22.2-1
ii  iceweasel  45.4.0esr-1~deb8u2
ii  libatk-adaptor 2.14.0-2
ii  libcanberra-pulse  0.30-2.1
ii  libcaribou-gtk-module  0.4.15-1
ii  libcaribou-gtk3-module 0.4.15-1
ii  libgtk-3-common3.14.5-1+deb8u1
ii  libpam-gnome-keyring   3.14.0-1+b1
ii  metacity   1:3.14.3-1
ii  mousetweaks3.12.0-1
ii  nautilus   3.14.1-2
ii  policykit-1-gnome  0.105-2
ii  pulseaudio 5.0-13
ii  sound-theme-freedesktop0.8-1
ii  totem  3.14.0-2
ii  tracker-gui1.2.4-2
ii  vino   3.14.0-2+b1
ii  yelp   3.14.1-1
ii  zenity 3.14.0-1

Versions of packages gnome-core recommends:
ii  anacron2.3-23
ii  network-manager-gnome  0.9.10.0-2

Versions of packages gnome-core suggests:
ii  gnome  1:3.14+3

-- no debconf information

Bug#843959: [debian-mysql] Bug#843959: can't upgrade if not running all the time

[積丹尼 Dan Jacobson]

Yes, same as ubuntu. And now much more than just your package gets
affected by this problem:

# deborphan
deborphan: The status file is in an improper state.
One or more packages are marked as half-installed, half-configured,
unpacked, triggers-awaited or triggers-pending. Exiting.

A workaround I found was not what one would perhaps expect,
# systemctl start mysql && aptitude safe-upgrade && systemctl stop mysql
but instead one must do
# systemctl enable mysql && aptitude safe-upgrade && systemctl disable mysql

Anyway, just don't check if it is enabled or not, or at least have a
dpkg configuration preference you can ask the user and remember about
it.

By the way, you then start mysql but don't remember to stop it when you
are finished. "Didn't Mom teach you to leave the room like you found
it?"

Bug#716226: Unable to deliver your item, #58783

[FedEx 2Day]

Hello,
We could not deliver your parcel. Shipment Label is attached to email.
Bridget Shvey - Area Manager FedEx , CA
Sincerely


FedEx.doc
Description: MS-Word document

Bug#843485: mention () vs (()) of filename

[積丹尼 Dan Jacobson]

All I know is "one may have noticed () vs. (())". I don't know how they
got there. So I am not the best person to write about it.

Bug#843485: mention () vs (()) of filename

[Ben Hutchings]

On Sun, 2016-11-13 at 12:22 +0800, 積丹尼 Dan Jacobson wrote:
> BH> The extra parentheses have no special meaning.
> 
> Well please document how they got there at least.

As I explained, that program did it:

> BH> What the documentation ought to mention is that a thread's name can
> BH> be overridden using prctl(PR_SET_NAME, ...). Care to send a patch?
> 
> I have no kernel knowledge.

You can write text files.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.



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

Bug#844186: RFH: libjs-handlebars -- need help in modifying grunt to build libjs-handlebars (and other modules with Gruntfile.js)

[Pirate Praveen]

package: wnpp
control: block 837467 by -1

To be able to build libjs-handlebars from handlebars node module, we
need to modify grunt.

summary of the current situation
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2016-November/015240.html

Looking for help from people with javascript knowledge to modify grunt
so that the packaged grunt can be used to build other projects
(currently grunt only works if installed locally in a project).



signature.asc
Description: OpenPGP digital signature

Bug#844185: RFS: fvwm/2.6.7 [ITA] -- f? virtual window manager

[Jaimos Skriletz]

Package: sponsorship-requests
Severity: normal

Hello mentors,

I am looking for a sponsor for me to maintain the package fvwm:

Package name: fvwm
Version: 2.6.7
Upstream Author: fvwm-work...@fvwm.org
URL: http://fvwm.org
License: GPL-2
Section: x11

I am looking to update and maintain the latest release of fvwm in
Debian. I have created a source package for review along with have had
a short correspondence with the current maintainer, sharing my work
with him. The current maintainer said he no longer uses fvwm and if
I'm willing to take responsibility I am welcomed to.

I have shared my work with the maintainer but besides that one short
email, he has not gotten back to me. Once this bug is submitted, I
will send the bug ID to the maintainer and ask for him to respond
publicly for verification.

This will be the first package I have maintained, yet I am an active
member of the #debian irc community where I go by "somiaj".

A copy of the source (and other files generated) can be found at:
http://fvwmforums.org/fvwm-2.6.7/

My changelog to update the package to 2.6.7:

fvwm (1:2.6.7-1) unstable; urgency=low

  * Complies with Policy v3.9.8.
  * New upstream version. (Closes: #820425)
- Fvwm now has a default config. See /usr/share/doc/fvwm/NEWS.Debian.gz
- Removed the following modules:
FvwmDragWell, FvwmGTK, FvwmSave, FvwmSaveDesk, FvwmScroll,
FvwmTabs, FvwmTaskBar, FvwmTheme, FvwmWharf, FvwmWinList,
FvwmWindowMenu, FvwmIconBox.
- fvwm-menu-desktop updated (now a python script). (Closes: #808292)
- New features and bug fixes. For a full list between 2.6.5 and 2.6.7
  see /usr/share/doc/fvwm/NEWS.gz
  * Removed the old system.fvwm2rc config examples.
  * Upstream moved from cvs to git. Updated watch file.
  * Removed old Debian menu methods. Use XDG menus with fvwm-menu-desktop.
  * html documentation no longer built (outdated/broken links).
  * Package build is reproducible. (Closes: #831646)
  * Fixed conflicting array sizes of TabCom. (Closes: #801612)
  * Upstream no longer includes a debian/ directory, so Debian no longer has
to repackage the upstream source without debian/. Removed .ds from version.

Thanks for your consideration,

jaimos

Bug#844180: warn 'This module is deprecated' in package Description and Tags

[積丹尼 Dan Jacobson]

Sure there is https://debtags.debian.org/search/ but in fact rather hard
to understand.

Bug#844180: warn 'This module is deprecated' in package Description and Tags

[積丹尼 Dan Jacobson]

> "gh" == gregor herrmann  writes:

>> Also add some deprecated Tags.

gh> What are "deprecated Tags"?

I was thinking in addition to
Tags: admin::logging, devel::lang:perl, implemented-in::perl, protocol::http, 
protocol::ssl
you could add something like
upstream::deprecated
but there is no list anywhere in
https://wiki.debian.org/Debtags/
that one can check the existing list of tags to see if there is any that
already contain the word deprecated. So I don't know.

Bug#840061: Enable I2C/IPMI and EDAC for X-Gene

[Ben Hutchings]

On Wed, 2016-11-02 at 14:45 +, Phil Endecott wrote:
> The buffer overflow fix is now upstream here:
> 
>    
> https://git.kernel.org/cgit/linux/kernel/git/wsa/linux.git/commit/drivers/i2c?id=603616017c35f4d0fbdbcace72adf9bf949c4a65
> 
> I expect it to be in 4.10, and also some stable updates.

It went into 4.8.7.  I'll enable the drivers for the next upload, which
includes 4.8.7.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.



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

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Ben Hutchings]

Control: tag -1 moreinfo

On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
[...]
> Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't yet
> tried 4.8.0-1 from unstable, not sure if it's impacted.
[...]

Please do.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.



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

Bug#843485: mention () vs (()) of filename

[積丹尼 Dan Jacobson]

BH> The extra parentheses have no special meaning.

Well please document how they got there at least.

BH> What the documentation ought to mention is that a thread's name can
BH> be overridden using prctl(PR_SET_NAME, ...). Care to send a patch?

I have no kernel knowledge.

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Ben Hutchings]

On Sun, 2016-11-06 at 10:00 -0800, Vagrant Cascadian wrote:
> Package: src:linux
> Version: 4.8.5-1
> Severity: important
> 
> When upgrading to linux 4.8.x on an Odroid-XU4 system, it no longer
> detects the USB sata adapter where rootfs is located.
> 
> Downgrading to the 4.7.x kernel from jessie-backports works fine.
> 
> I didn't see anything obviously missing when diffing /boot/config-*.
> 
> Boot log attached.
> 
> If there's nothing obvious fromt the boot log, I can try taking it
> offline and doing an install with stretch or sid to do more
> debugging.

This message (from the core hub driver) looks important:

2016-11-06_17:33:29.19077 [7.510995] usb usb3-port1: connect-debounce failed

The device tree source for Exynos 5422 was changed between 4.7 and 4.8
so some of the USB definitions could be shared with the 5410 (commit
cb0896562228703209644e92926ed445150cc594).  This obviously shouldn't
have a functional difference to the 5422 but maybe it did?

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.


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

Bug#843533: linux-image-4.8.0-1-amd64: Mouse stops working when watching debconf 2016 videos

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2016-11-07 at 11:41 -0200, Rafael schipiura wrote:
> Package: src:linux
> Version: 4.8.5-1
> Severity: important
> 
> The mouse stops working when a debconf 2016 video starts playing.
> Restarting the X.org server or reconnecting the mouse doesn't solve
> it. Also doesn't happen when using the 4.7 kernel.
[...]

Do you mean the mouse cursor stops moving?  Or disappears?  If you
close the video player, does it start working again?

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.



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

Bug#843485: mention () vs (()) of filename

[Ben Hutchings]

Control: tag -1 upstream
Control: retitle -1 proc.txt does not mention that task names can be overridden

On Mon, 2016-11-07 at 07:09 +0800, 積丹尼 Dan Jacobson wrote:
> Package: linux-doc-4.8
> Version: 4.8.5-1
> Severity: wishlist
> File: /usr/share/doc/linux-doc-4.8/Documentation/filesystems/proc.txt.gz
> 
> One only sees
>   tcomm filename of the executable
> 
> But no explanation of () vs (())
> 
> $ perl -anwle 'print $F[1]' /proc/[0-9]*/stat|sort -u|head
> ((sd-pam))
> (Xorg)
> (acpi_thermal_pm)

The extra parentheses have no special meaning.  What the
documentation ought to mention is that a thread's name can be
overridden using prctl(PR_SET_NAME, ...).  Care to send a patch?

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.



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

Bug#843510: linux-image-4.8.0-rc8-amd64-unsigned: Task timeout when workstation is connected

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2016-11-07 at 09:51 +0100, Alexandre wrote:
> Package: src:linux
> Version: 4.8~rc8-1~exp1
> Severity: grave
> Justification: renders package unusable
[...]

Please re-test with the current version 4.8.5-1.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.


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

Bug#843457: mysql-workbench: Dependency gdal-abi-2-1-1 no longer in repo

[Dmitry Smirnov]

On Thursday, 10 November 2016 9:16:16 AM AEDT Alessio Gaeta wrote:
> Any news on that one?
> 
> mysql-workbench is stuck in unstable since more than a year now, and it is
> not in testing anymore since September.

MySQL Workbench (M-W) can not be built any more:

 * 6.3.4 was the last release supporting MySQL 5.6. All later releases 
require MySQL 5.7.

 * M-W depends on mysql-connector-c++ that also needs MySQL 5.7.

 * M-W and mysql-connector-c++ FTBFS with MariaDB.

 * M-W depends on libgdal-dev that is built against MariaDB.
   MariaDB and MySQL libraries conflict with each other.

Needless to say that Oracle could not care less about MariaDB support...


> The freeze is approaching: do we
> will not have mysql-workbench in Stretch?

Most likely MySQL Workbench will not be in Stretch unless someone finds a way 
to build it for MariaDB...


> Is this package abandoned?

Sort of... It needs new upstream capable of maintaining fork...

-- 
Best wishes,
 Dmitry Smirnov.

---

Success consists of going from failure to failure without loss of enthusiasm.
-- Winston Churchill


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

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for review and a sponsor for my package "src:muse-el".
I've CC'd Sean Whitton who is willing to help me with elpa, LISP, and
any emacs-on-Debian integration issues.
Here are a few things I'm wondering about:

Are the generated packages in the correct sections for an elpafied
package?
Is removing hrefs to favicon.ico (Bug: #775885) sufficient?
Distributing a favicon.ico seems unnecessary and honestly, I'm
against it. In Canada, because the author retains all distribution
rights in the absence of a license or declared copyright, even
something as trivial as a favicon.ico can be unredistributable.  I
couldn't find the license on Michael Olson's website
, so I decided it was best not to copy it.

Do my patches look ok?
Should elpafied packages continue to be arch-independent?
Is debian/changelog too verbose and could it be condensed?

Package name: muse-el
Version : 3.20+dfsg-1
Section : editors

It builds those binary packages:

  elpa-muse  - Author and publish projects using Wiki-like markup
  muse-el- transitional dummy package for elpa-muse.

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

  https://mentors.debian.net/package/muse-el

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/muse-el/muse-el_3.20+dfsg-1.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

muse-el (3.20+dfsg-1) unstable; urgency=medium

  * New Maintainer.
  * debian/control:
- Bump required debhelper to >=9.
- Update emacs dependency.
- Add emacs-goodies-el dependency, which provides htmlize.el.
  * Switch to debcompat 9; Switch to 3.0 (quilt) non-native packaging.
  * Add patch to fix privacy breaches; removes hrefs. (Closes: #775885)
  * Elpafy! (depends on dh-elpa).
  * Add patch to disable non-DFSG compliant texi stuff.
  * Install docs and examples the new dh_way.
  * debian/rules:
- add override to build examples and autoloads.
- add override to install upstream changelog series.
  * debian/copyright:
- Fix misattributed source (found by comparing timestamps in comments
  between gna.org tarballs and git sources).
- Update format.
- Add debian/* section.
  * Include images used by the QuickStart.muse example. (Closes: #720121)
  * Add patch to use Debian's "see" command instead of "open".  Thank
you Kevin Ryde, I didn't know about the existence of "see" before
reading this bug report. (Closes: #720126)
  * Patch README to explain how installed files relate to src:muse-el.

 -- Nicholas D Steeves   Tue, 18 Oct 2016 20:58:45 -0400


Regards,
Nicholas D Steeves

Bug#844173: iotop: crashes with ValueError: need more than 1 value to unpack

[Adam Borowski]

On Sun, Nov 13, 2016 at 10:53:11AM +0800, Paul Wise wrote:
> On Sun, 2016-11-13 at 00:55 +0100, Adam Borowski wrote:
> 
> > On a jessie box, both 0.6-1 and 0.6-2 (mindlessly recompiled against jessie)
> > crash with the following backtrace:
> ...
> >   File "/usr/lib/python3/dist-packages/iotop/data.py", line 196, in 
> > parse_proc_pid_status
> > key, value = line.split(':\t', 1)
> > ValueError: need more than 1 value to unpack
> 
> The commit referenced above fixes this.
> 
> Could you confirm that it works?

Yeah, thanks!

> What is the `uname -a` for your system?

It has the vserver patch set applied, this is where the two entries come
from.  I'd prefer to keep the rest of the version non-public because
$REASONS.


Meow!
-- 
A true bird-watcher waves his tail while doing so.

Bug#844173: iotop: crashes with ValueError: need more than 1 value to unpack

[Paul Wise]

Control: tags -1 + upstream fixed-upstream
Control: forwarded -1 
http://repo.or.cz/iotop.git/commitdiff/7814f30a5ed65acd07f284bba991ca557788ee80
Control: retitle -1 iotop: crashes on non-mainline Linux with ValueError: need 
more than 1 value to unpack

On Sun, 2016-11-13 at 00:55 +0100, Adam Borowski wrote:

> On a jessie box, both 0.6-1 and 0.6-2 (mindlessly recompiled against jessie)
> crash with the following backtrace:
...
>   File "/usr/lib/python3/dist-packages/iotop/data.py", line 196, in 
> parse_proc_pid_status
> key, value = line.split(':\t', 1)
> ValueError: need more than 1 value to unpack

The commit referenced above fixes this.

Could you confirm that it works?

What is the `uname -a` for your system?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#844139: python-django: FTBFS: Tests failures

[Scott Kitterman]

On Sat, 12 Nov 2016 21:15:22 +0100 Lucas Nussbaum  wrote:
> Source: python-django
> Version: 1:1.10.3-1
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-2016 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
...
> 
> This failure happens on a CPU with TSX extensions available, but is not
> reproducible on a machine without them. 

==
FAIL: test_fuzzy_compiling (i18n.test_compilation.FuzzyTranslationTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/<>/tests/i18n/test_compilation.py", line 218, in 
test_fuzzy_compiling
self.assertEqual(ugettext('Lenin'), force_text('Ленин'))
  File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python2.7/unittest/case.py", line 924, in 
assertMultiLineEqual
self.fail(self._formatMessage(msg, standardMsg))
  File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
raise self.failureException(msg)
AssertionError: u'Lenin' != u'\u041b\u0435\u043d\u0438\u043d'
- Lenin
+ \u041b\u0435\u043d\u0438\u043d

The non-lazy evaluation test passes and the lazy evaluation code last changed 
before 1.10.0 was released, so if this is a problem in 1.10.3 in unstable, it 
also affects 1.10.1 in testing.

Scott K

Bug#844180: Pending fixes for bugs in the libhttp-recorder-perl package

[pkg-perl-maintainers]

tag 844180 + pending
thanks

Some bugs in the libhttp-recorder-perl package are closed in revision
86d7160a129d2f1db5fe7214a10e3a2af9cc7aff in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libhttp-recorder-perl.git/commit/?id=86d7160

Commit message:

Add deprecation notice to long description.

Closes: #844180

Bug#844180: warn 'This module is deprecated' in package Description and Tags

[gregor herrmann]

On Sun, 13 Nov 2016 08:54:35 +0800, 積丹尼 Dan Jacobson wrote:

> We read
> SYNOPSIS
>This module is deprecated
> 
> Therefore please also in the package Description do mention the same.

Added in git.

> Also add some deprecated Tags.

What are "deprecated Tags"?
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Juilliard Ensemble, Berberian,: Due pezzi für Violine und Klavier I 
(Calmo)


signature.asc
Description: Digital Signature

Bug#844181: remove the first systemctl SysV service script synchronizing warning, only leave the second

[Michael Biebl]

Am 13.11.2016 um 01:21 schrieb 積丹尼 Dan Jacobson:
> Package: systemd
> Version: 232-3
> File: /bin/systemctl
> 
> Do you see how users might be alarmed if they see:

Not sure if they are alarmed. But anyway, this is is more or less a
duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806812
A bug you filed yourself already.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#844182: Size (ALT+F8) does not work if window is full-screen

[積丹尼 Dan Jacobson]

Package: icewm
Version: 1.3.8+mod+20160906-1
Severity: minor

Size (ALT+F8) does not work if window is full-screen.

Bug#844183: linux-image-3.16.0-4-amd64: Failed to start aufs on latest kernel

[Andrew Zhao]

Package: src:linux
Version: 3.16.36-1+deb8u2
Severity: important

Dear Maintainer,

I upgraded the linux kernel this week to the latest version, and could not 
start aufs.

The syslog has the error 
aufs: Unknown symbol setf1

and
mount: Unknown filesystem type aufs

Downgrading the kernel fixes this issue


This is a pretty severe regression since it makes aufs unusable.

(I'm making this report from a different machine though, but I upgraded the 
kernel on the same day)

-Andrew Zhao

-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/zinc-root ro quiet

** Not tainted

** Kernel log:
[6.492023] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[6.517891] [drm] Initialized drm 1.1.0 20060810
[6.519176] ACPI Warning: SystemIO range 
0x0828-0x082F conflicts with OpRegion 
0x0800-0x084F (\PMRG) (20140424/utaddress-254)
[6.519187] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[6.519234] lpc_ich: Resource conflict(s) found affecting gpio_ich
[6.519459] i801_smbus :00:1f.3: SMBus using PCI Interrupt
[6.545644] EDAC MC1: Giving out device to module i7core_edac.c controller 
i7 core #1: DEV :fe:03.0 (POLLED)
[6.545681] EDAC PCI0: Giving out device to module i7core_edac controller 
EDAC PCI controller: DEV :fe:03.0 (POLLED)
[6.546070] EDAC MC0: Giving out device to module i7core_edac.c controller 
i7 core #0: DEV :ff:03.0 (POLLED)
[6.546097] EDAC PCI1: Giving out device to module i7core_edac controller 
EDAC PCI controller: DEV :ff:03.0 (POLLED)
[6.546336] EDAC i7core: Driver loaded, 2 memory controller(s) found.
[6.594246] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. 
Using workaround
[6.599734] input: PC Speaker as /devices/platform/pcspkr/input/input7
[6.649967] iTCO_vendor_support: vendor-support=0
[6.652903] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[6.652953] iTCO_wdt: Found a ICH10R TCO device (Version=2, TCOBASE=0x0860)
[6.653275] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[6.713868] [drm] radeon kernel modesetting enabled.
[6.714551] [drm] initializing kernel modesetting (RV100 0x1002:0x515E 
0x15D9:0xF280).
[6.714570] [drm] register mmio base: 0xFBCF
[6.714571] [drm] register mmio size: 65536
[6.714646] radeon :01:01.0: VRAM: 128M 0xF000 - 
0xF7FF (32M used)
[6.714648] radeon :01:01.0: GTT: 512M 0xD000 - 
0xEFFF
[6.714655] [drm] Detected VRAM RAM=128M, BAR=128M
[6.714657] [drm] RAM width 16bits DDR
[6.714884] [TTM] Zone  kernel: Available graphics memory: 6162282 kiB
[6.714886] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[6.714887] [TTM] Initializing pool allocator
[6.714893] [TTM] Initializing DMA pool allocator
[6.714913] [drm] radeon: 32M of VRAM memory ready
[6.714915] [drm] radeon: 512M of GTT memory ready.
[6.714931] [drm] GART: num cpu pages 131072, num gpu pages 131072
[6.736902] [drm] PCI GART of 512M enabled (table at 0xBAB8).
[6.736969] radeon :01:01.0: WB disabled
[6.736977] radeon :01:01.0: fence driver on ring 0 use gpu addr 
0xd000 and cpu addr 0x8800ba0bb000
[6.736980] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[6.736982] [drm] Driver supports precise vblank timestamp query.
[6.736999] [drm] radeon: irq initialized.
[6.737015] [drm] Loading R100 Microcode
[6.737032] radeon :01:01.0: firmware: failed to load radeon/R100_cp.bin 
(-2)
[6.737109] radeon :01:01.0: Direct firmware load failed with error -2
[6.737111] radeon :01:01.0: Falling back to user helper
[6.737691] [drm:r100_cp_init] *ERROR* Failed to load firmware!
[6.737757] radeon :01:01.0: failed initializing CP (-12).
[6.737819] radeon :01:01.0: Disabling GPU acceleration
[6.737887] [drm] radeon: cp finalized
[6.738800] [drm] No TV DAC info found in BIOS
[6.738805] [drm] No valid Ext TMDS info found in BIOS
[6.738857] [drm] Radeon Display Connectors
[6.738858] [drm] Connector 0:
[6.738860] [drm]   VGA-1
[6.738862] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[6.738863] [drm]   Encoders:
[6.738865] [drm] CRT1: INTERNAL_DAC1
[6.738866] [drm] Connector 1:
[6.738867] [drm]   DVI-I-1
[6.738869] [drm]   HPD2
[6.738871] [drm]   DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c
[6.738872] [drm]   Encoders:
[6.738873] [drm] CRT2: INTERNAL_DAC2
[6.738875] [drm] DFP2: INTERNAL_DVO1
[6.781350] [drm] fb mappable at 0xF004
[6.781354] [drm] vram apper at 0xF000
[

Bug#843518: webdis: new upstream version

[Andrii Senkovych]

Hello, Ricardo!

Thank you for the heads up and for interest in webdis. I've done
packaging of the new upstream version along with some other changes
and sent a request to sponsor the package. Hope to see it in the
Debian Archive soon. Meanwhile you can review the package in the new
Git repo:

https://anonscm.debian.org/cgit/collab-maint/webdis.git

Have a nice day!

-- 
Best regards,
Andrii Senkovych

2016-11-07 13:13 GMT+02:00 Ricardo Mones :
> Source: webdis
> Severity: wishlist
>
> Hi maintainer!
>
> There's a new upstream release of webdis since february (0.1.2).
> Would be nice to have it packaged for Debian before the release.
>
> Thanks in advance and best regards,
>
> -- System Information:
> Debian Release: 8.6
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Bug#844181: remove the first systemctl SysV service script synchronizing warning, only leave the second

[積丹尼 Dan Jacobson]

Package: systemd
Version: 232-3
File: /bin/systemctl

Do you see how users might be alarmed if they see:

# systemctl enable mysql
Synchronizing state of mysql.service with SysV service script with 
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable mysql
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides 
LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' 
overrides LSB defaults (0 1 6).
# systemctl enable mysql
Synchronizing state of mysql.service with SysV service script with 
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable mysql

And thus need to execute the command the second time just to make sure?

Going the other way makes

# systemctl disable mysql
Synchronizing state of mysql.service with SysV service script with 
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable mysql
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides 
LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' 
overrides LSB defaults (0 1 6).
# systemctl disable mysql
Synchronizing state of mysql.service with SysV service script with 
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable mysql
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides 
LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' 
overrides LSB defaults (0 1 6).
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides 
LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' 
overrides LSB defaults (0 1 6).
# systemctl disable mysql
Synchronizing state of mysql.service with SysV service script with 
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable mysql
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides 
LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' 
overrides LSB defaults (0 1 6).
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides 
LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' 
overrides LSB defaults (0 1 6).

Apparently there is a 'before' inspection and warning, then the command
is executed, and then there is an 'after' inspection and warning. (Each
single warning I am talking about consists of two lines.)

So you need to eliminate the 'before' inspection and warning, or at
least the 'before' warning.

Or, at least write the steps as they probably really occur:

# systemctl disable mysql
Synchronizing state of mysql.service with SysV service script with 
/lib/systemd/systemd-sysv-install.
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides 
LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' 
overrides LSB defaults (0 1 6).
Executing: /lib/systemd/systemd-sysv-install disable mysql
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides 
LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' 
overrides LSB defaults (0 1 6).

Bug#844180: warn 'This module is deprecated' in package Description and Tags

[積丹尼 Dan Jacobson]

Package: libhttp-recorder-perl
Version: 0.07-2

We read
SYNOPSIS
   This module is deprecated

Therefore please also in the package Description do mention the same.
Users would like to know before considering installing it, and rather
important, don't you think?

Also add some deprecated Tags.

P.S., it is rather hard to understand how one is supposed to use the
package anyway just using its docs alone...

Bug#843127: [Paul Wise] Bug#843127: notmuch: race condition in `notmuch new`?

[Austin Clements]

Quoth David Bremner on Nov 04 at  1:26 pm:
> 
> Paul Wise wrote:
> 
> > Last night I got this error from my `notmuch new --quiet` cron job. The
> > file that the error message complains about is now in the cur directory
> > of the maildir at the following path.
> >
> > /path/to/mail/cur/1478190211.H80553P18378.chianamo:2,
> >
> > I wonder if this some kind of race condition in `notmuch new` processing.
> > Perhaps it should be using inotify to find out about file movements?
> >
> > Unexpected error with file 
> > /path/to/mail/new/1478190211.H80553P18378.chianamo
> > add_file: Something went wrong trying to read or write a file
> > Error opening /path/to/mail/new/1478190211.H80553P18378.chianamo: No such 
> > file or directory
> > Note: A fatal error was encountered: Something went wrong trying to read or 
> > write a file
> 
> I agree it looks like a race condition. inotify sounds a bit
> overcomplicated and perhaps non-portable? It should probably just
> tolerate disappearing files better, consider that a warning.

Inotify really *is* the solution. This is a symptom of a much bigger
problem: scandir makes no guarantees in the presence of concurrent
directory modification. If you delete or rename a file while notmuch
new is running, it may think *completely unrelated* files in the same
directory were also deleted. Even if scandir were atomic, if you move
a mail from one directory to another between notmuch scanning the
destination directory and notmuch scanning the source directory, it'll
think the mail has been deleted and potentially remove it from the DB.

The "recommended" solution is to scandir is to start an inotify watch
before the scan and redo (or update) the scan if there are any
changes. For notmuch, it would make sense to extend that to watching
all directories to make sure it can catch renames during the scan.

A possible alternative, though I haven't worked out the details, might
be to keep a close eye on the directory mtimes. Roughly, for each
directory, check the mtime before scanning, wait if necessary until
the mtime != the current time, do the scan and process the files
optimistically. Once all directories are processed, re-check all of
the mtimes and if any have changed, do something like starting over
but hopefully more intelligent.

Bug#844156: gajim: suggests/uses python-gnomekeyring which is deprecated

[W. Martin Borgert]

On 2016-11-12 21:50, Michael Biebl wrote:
> gajim suggests python-gnomekeyring, which is long deprecated and going
> to be removed from the archive. It should switch to using the GObject
> Introspection bindings for gnome-keyring, gir1.2-gnomekeyring-1.0.

I asked upstream and they immediately prepared a patch to use
gir1.2-secret-1 instead of gnomekeyring (or kwallet):

https://hg.linkmauve.fr/gajim/rev/29d90ff79494

I assume, that this code will be in the next release, and we
probably can apply it already, if necessary.

Bug#825380: [Pkg-samba-maint] Bug#825380: winbind: Netbios name resolution can't find Windows clients

[Tim Boundy]

Yes, I have 2:4.4.7+dfsg-1 of libnss-winbind installed

I've attached the 'strace ping google.com' output when using wins in
nsswitch.conf

On 13 November 2016 at 08:44, Mathieu Parent  wrote:

>  is.Hello,
>
> 2016-11-09 10:14 GMT+01:00 Tim Boundy :
> > I've just updated to 2:4.4.7+dfsg-1 to see if there's any improvement.
> > Massive regression. Now I can't ping via dns.
> >
> > ping: google.com: System error
> >
> > If I remove wins from nsswitch.conf, dns starts working again.
>
> Do you have libnss-winbind installed? This is where libnss_wins.so.2 is.
>
> If you already have this package. What does outputs?:
>
> sudo strace ping google.com
>
> Regards
> --
> Mathieu Parent
>


strace_ping
Description: Binary data

Bug#844179: ITP: libconfig-methodproxy-perl -- Perl module for specifying method calls in a static configuration

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libconfig-methodproxy-perl
  Version : 0.02
  Upstream Author : Aran Deltac 
* URL : https://metacpan.org/release/Config-MethodProxy
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module for specifying method calls in a static 
configuration

The method proxy concept provided by the Config::MethodProxy module is
a particular data structure which, when found, is replaced by the value
returned by calling that method.  In this way static configuration can be
setup to call your code and return dynamic contents.  This makes static
configuration much more powerful, and provides the ability to be more
declarative in how dynamic values make it into the configuration.

This module is needed as a dependency for a new version of
libmoox-buildargs-perl.  I intend to maintain it within the Debian
Perl group.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#844164: vim: since version 8, vim ignores indentation settings in /etc/vim/vimrc.local

[James McCoy]

On Sat, Nov 12, 2016 at 11:12:09PM +0100, Mikulas Patocka wrote:
> I see, but it is annoying to the users who upgrade the Debian distribution 
> and who are used to the old settings.

That's why there's a NEWS entry to tell them about the change and how
they can change the behavior.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#834724: curl: (35) gnutls_handshake() failed: Public key signature verification has failed.

[Kamaraju Kusumanchi]

Confirm that Tim Small solution worked for me as well. I am running
Debian Stretch and removing libgnutls-deb0-28 fixed the error.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages curl depends on:
ii  libc62.24-3
ii  libcurl3-gnutls  7.50.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

curl recommends no packages.

curl suggests no packages.

-- no debconf information

-- 
Kamaraju S. Kusumanchi
http://raju.shoutwiki.com/wiki/Blog

Bug#837629: OpenRD* with debian's u-boot 2016.09

[Rick Thomas]

On 11/02/16 10:38, Vagrant Cascadian wrote:

I've uploaded u-boot 2016.11~rc3 to the cascadia.debian.net
repository. I won't hold my breath, but give it a try...
Good thing you didn't hold your breath.  I tried it.  Same result as 
before:  No response after "reset".


I think I heard that support for armel will be withdrawn from Debian 
after Stretch.  If that's true,

there's not much percentage in expending any more effort on this project.

It was worth a try, I guess, but facts are facts and time marches on.

Let me know if there's anything else I can do that would be helpful. For 
example, I've got a couple of sheevaplug devices.  Has anything more 
recent than "2016.09-rc2+dfsg1-1 (Aug 30, 2016)" been

tested on a sheevaplug?

Rick

Bug#844178: Better systemd integration

[Michael Biebl]

Package: exim4
Version: 4.88~RC4-2
Severity: normal

Hi,

having a native systemd service for exim4 would be great. The sysv init
script does a *lot* of stuff though, so I don't know, how easily a
systemd conversion is possible. As an intermediate step, you can at
least help systemd along a little, and tell it, that the sysv init scrip
starts a long running process. For that, the magic # pidfile comment
exists. If that is set, systemd will set the proper type (Type=forking)
and will correctly set the main pid, i.e. it will notice if the main
process this.

So, while I would appreciate if exim4 would provide native systemd
support (and if you any questions trying to that, please contact the
pkg-systemd-maintainers@a.l.d.o m-l), we can a least improve the
status-quo by adding 

--- exim4.dpkg-dist 2016-09-25 14:46:29.0 +0200
+++ exim4   2015-11-16 14:25:07.0 +0100
@@ -18,6 +18,7 @@
 # Short-Description: exim Mail Transport Agent
 # Description:   exim is a Mail Transport agent
 ### END INIT INFO
+# pidfile: /var/run/exim4/exim.pid


Thansk for considering,
Michael


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

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

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  exim4-base 4.88~RC4-2
ii  exim4-daemon-light 4.88~RC4-2

exim4 recommends no packages.

exim4 suggests no packages.

-- debconf information excluded

Bug#844177: New upstream release available

[Michael Biebl]

Source: appstream-glib
Version: 0.6.4-2
Severity: normal

Hi,

there is a new upstream release 0.6.5 available which is a prerequisite
for gnome-software 3.22.2.

Would be great to have it packaged in time for stretch.

Regards,
Michael

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

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

Bug#823822: Downgrading severity

[Dmitry Smirnov]

On Friday, 11 November 2016 10:43:35 AM AEDT Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Hi Dmitry! Please allow me to explain you why I'm downgrading the severity
> of this bug.

No worries. Thank you for explanation. I've bumped severity only due to  
#823822 (quiterss' FTBFS on timeout due to 150+ min in lupdate)...


> On the other hand running lrelease at build time is actually a very
> nice idea.

Thanks for suggestion. I'll try to replace lupdate with lrelease...


> If somehow upstream needs to run lupdate *after* the tarballs or the git
> tag has been pushed then you can safely run it before packaging the source
> code. This is of course not nice, but upstream shouldn't be forcing you to
> do this in the first place.

I've introduced 'lupdate' as workaround for run-time segfaults in some 
locales due to missing translations (as I recall). I know no indicators to 
notice when 'lupdate' is necessary... If 'lrelease' is insufficient then it 
may be preferable to run 'lupdate' on build-time as a precaution.


> So the tool is not used in it's right place and a workaround is available,
> thus downgrading the severity to important.

OK. Makes sense.


> Please note that I *do* acknowledge the bug.

Thank you. :)


> I have been looking at
>   https://bugreports.qt.io/browse/QTBUG-27936[1]
> and a good test case could really serve well here.

QuiteRSS may be a good case...


-- 
Regards,
 Dmitry Smirnov.

---

However beautiful the strategy, you should occasionally look at the
results.
-- Winston Churchill


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

Bug#567968: magicrescue can't recreate xcf files

[Eriberto Mota]

The libgimp-perl was removed from Debian via bug #634349 (18 Jul
2011). As solution, the recipe gimp-xcf will be removed from
magicrescue.

Eriberto

Bug#832010: Please enable LZ4 compression

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 21, 2016 at 07:28:26PM +0200, Yuri D'Elia wrote:
> On Thu, Jul 21 2016, Michael Biebl  wrote:
> > And in Debian we build against libxz, so xz compression is used for core
> > files.
> 
> Indeed, and it's pretty slow.
> 
> > What would we gain by switching from xz to lz4. Can you provide numbers?
> 
> I don't have enough time to back it up comparing exactly the difference
> between LZ4 and XZ in coredump, but if you compare regular XZ to LZ4 you
> can expect anywhere between 10x and 50x improvement in compression
> speed while maintaining an acceptable compression ratio.

systemd itself includes a benchmark:

$ ./test-compress-benchmark
XZ/zeros: compressed & decompressed 57898278 bytes in 2.02s (27.37MiB/s), mean 
compresion 99.96%, skipped 0 bytes
LZ4/zeros: compressed & decompressed 2031958921 bytes in 2.00s (968.65MiB/s), 
mean compresion 99.60%, skipped 0 bytes
XZ/simple: compressed & decompressed 58918934 bytes in 2.01s (27.97MiB/s), mean 
compresion 99.95%, skipped 0 bytes
LZ4/simple: compressed & decompressed 2544957269 bytes in 2.00s (1213.26MiB/s), 
mean compresion 99.60%, skipped 0 bytes
XZ/random: compressed & decompressed 12258687 bytes in 2.08s (5.62MiB/s), mean 
compresion 44.33%, skipped 168354 bytes
LZ4/random: compressed & decompressed 2235751628 bytes in 2.00s (1065.61MiB/s), 
mean compresion 44.94%, skipped 24251355 bytes

You can also specify different test time as an argument.

Zbyszek

Bug#842903: sphinx: Cirular build dependency on python3-xapian

[Al Nikolov]

Control: retitle -1 sphinx: Circular build dependency on xapian-bindings


В Ср, 02/11/2016 в 12:18 +0300, Dmitry Shachnev пишет:

> However, I only need it for tests, so it is safe to remove (and I can add
> it to the autopkgtests to make sure nothing breaks when Xapian is upgraded).

Yes, that would be extremely lovely to untie this annoying knot.

Perhaps, even more logical would be to contribute these tests to
xapian-bindings instead? (I assume, what these tests are actually
testing xapian-bindings functionality, not sphinx).


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

Bug#844176: emacs-goodies-el: partially incompatible with xemacs21

[Aaron M. Ucko]

Package: emacs-goodies-el
Version: 36.0
Severity: important

Byte-compilation of emacs-goodies-el now fails under xemacs21:

  While compiling toplevel forms in file 
/usr/share/xemacs21/site-lisp/emacs-goodies-el/emacs-goodies-el.el:
!! Symbol's function definition is void ((define-globalized-minor-mode))
  >>Error occurred processing emacs-goodies-el.el: 
  Symbol's function definition is void: define-globalized-minor-mode
  
  [...]
  While compiling toplevel forms in file 
/usr/share/xemacs21/site-lisp/emacs-goodies-el/maplev.el:
!! Symbol's value as variable is void ((global-button-lock-mode))
  >>Error occurred processing maplev.el: 
  Symbol's value as variable is void: global-button-lock-mode

Could you please take a look and either fix these two files for
xemacs21 or exclude them there?

Thanks!

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

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

Versions of packages emacs-goodies-el depends on:
ii  bash   4.4-1
ii  dpkg   1.18.10
ii  emacs  46.1
ic  emacs23 [emacsen]  23.4+1-4.1+b1
ii  emacs24 [emacsen]  24.5+1-7
ii  emacs25 [emacsen]  25.1+1-2
ii  install-info   6.3.0.dfsg.1-1+b1
ii  xemacs21-mule [emacsen]21.4.24-4
ii  xemacs21-nomule [emacsen]  21.4.24-4

Versions of packages emacs-goodies-el recommends:
ii  perl-doc  5.24.1~rc3-3
ii  wget  1.18-4

emacs-goodies-el suggests no packages.

-- no debconf information

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#832339: [steam] can't find xdg-open when needed

[Michael Gilbert]

control: tag -1 upstream, confirmed
control: severity -1 minor

You'll need to take this problem to Valve.

Best wishes,
Mike

Bug#844175: ITP: neofetch -- Shows Linux System Information with Distribution Logo

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: neofetch
  Version : 1.9.1
  Upstream Author : Dylan Araps 
* URL : https://github.com/dylanaraps/neofetch.git
* License : Expat
  Programming Lang: Bash
  Description :  Shows Linux System Information with Distribution Logo

 Neoftech is a cross-platform and easy-to-use system information
 command line script that collects your Linux system information
 and display it on the terminal next to an image, it could be your
 distributions logo or any ascii art of your choice.

Bug#844059: debbugs: control server should reject fixed versions that do not exist and result in a no-op

[Don Armstrong]

Control: tag -1 wontfix

On Sat, 12 Nov 2016, Johannes Schauer wrote:
> I naively expected, that the version passed to the "fixed" command is
> compared with a greater than or equal comparison. Thus, I indicated
> that a bug was fixed in upstream version X while the corresponding
> upload to Debian included the Debian revision and was thus version
> X-1. It seems that using version X had no effect as far as the bts was
> concerned and that only after I specified the actually uploaded
> version X-1 did the bts mark all later versions as fixed. I propose to
> either:
> 
>  - let the control server reject the versions that will result in a
>no-op

It currently warns if you give it a version which it doesn't know about.
Since it's possible to close bugs before they're actually in the
archive, the BTS can't disallow versions which it doesn't know about.

>  - do a version comparison, marking all versions greater than or equal
>to X as fixed

That won't work, because it's perfectly valid to have a bug which is
found in a version which is greater than the fixed version, but isn't on
the same path as the fixed version.

For example, if a bug is fixed by a security update in stable, that
doesn't mean it is fixed in unstable.

-- 
Don Armstrong  https://www.donarmstrong.com

Science is a way of trying not to fool yourself. The first principle
is that you must not fool yourself, and you are the easiest person to
fool.
 -- Richard Feynman "What is and What Should be the Role of Scientific
Culture in Modern Society"; 1964

Bug#844174: eccodes: FTBFS: cannot remove 'debian/libeccodes-doc/...'

[Aaron M. Ucko]

Source: eccodes
Version: 2.0.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of eccodes covering only its architecture-dependent binary
packages (as on the autobuilders, or with dpkg-buildpackage -B) have
been failing:

  # replace jquery with symlink. Run after dh_installdocs
  rm debian/libeccodes-doc/usr/share/doc/libeccodes-doc/html/jquery.js
  rm: cannot remove 
'debian/libeccodes-doc/usr/share/doc/libeccodes-doc/html/jquery.js': No such 
file or directory
  debian/rules:104: recipe for target 'override_dh_fixperms' failed
  make[1]: *** [override_dh_fixperms] Error 1
  make[1]: Leaving directory '/«PKGBUILDDIR»'
  debian/rules:49: recipe for target 'binary-arch' failed
  make: *** [binary-arch] Error 2
  dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit 
status 2

Could you please take a look?  Splitting override_dh_fixperms per
#844167 should help here.

Thanks!

BTW, I'm filing this bug as a regression because it would affect binNMUs.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#844173: iotop: crashes with ValueError: need more than 1 value to unpack

[Adam Borowski]

Package: iotop
Version: 0.6-1
Severity: normal

Hi!
On a jessie box, both 0.6-1 and 0.6-2 (mindlessly recompiled against jessie)
crash with the following backtrace:

[~]# iotop
Traceback (most recent call last):
  File "/usr/sbin/iotop", line 17, in 
main()
  File "/usr/lib/python3/dist-packages/iotop/ui.py", line 620, in main
main_loop()
  File "/usr/lib/python3/dist-packages/iotop/ui.py", line 610, in 
main_loop = lambda: run_iotop(options)
  File "/usr/lib/python3/dist-packages/iotop/ui.py", line 508, in run_iotop
return curses.wrapper(run_iotop_window, options)
  File "/usr/lib/python3.4/curses/__init__.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
  File "/usr/lib/python3/dist-packages/iotop/ui.py", line 501, in 
run_iotop_window
ui.run()
  File "/usr/lib/python3/dist-packages/iotop/ui.py", line 155, in run
self.process_list.duration)
  File "/usr/lib/python3/dist-packages/iotop/ui.py", line 434, in 
refresh_display
lines = self.get_data()
  File "/usr/lib/python3/dist-packages/iotop/ui.py", line 415, in get_data
return list(map(format, processes))
  File "/usr/lib/python3/dist-packages/iotop/ui.py", line 388, in format
cmdline = p.get_cmdline()
  File "/usr/lib/python3/dist-packages/iotop/data.py", line 292, in get_cmdline
proc_status = parse_proc_pid_status(self.pid)
  File "/usr/lib/python3/dist-packages/iotop/data.py", line 196, in 
parse_proc_pid_status
key, value = line.split(':\t', 1)
ValueError: need more than 1 value to unpack

The two problematic entries are:
VxID: 0
NxID: 0

Note a space rather than a tab after the colon.

This is a non-mainline kernel, but as tabs are not enforced anywhere and
come from a multitude of places in the kernel, it's quite likely that spaces
might appear there in the future, at least temporarily.


Meow!

Bug#844172: eccodes: FTBFS: Can't rename module file 'modules/grib_api.mod0'

[Aaron M. Ucko]

Source: eccodes
Version: 2.0.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Parallel builds of eccodes have been failing:

  f951: Fatal Error: Can't rename module file 'modules/grib_api.mod0' to 
'modules/grib_api.mod': No such file or directory
  compilation terminated.
  fortran/CMakeFiles/eccodes_f90.dir/build.make:109: recipe for target 
'fortran/CMakeFiles/eccodes_f90.dir/grib_f90.f90.o' failed
  make[4]: *** [fortran/CMakeFiles/eccodes_f90.dir/grib_f90.f90.o] Error 1
  make[4]: Leaving directory '/«PKGBUILDDIR»/debian/build'
  fortran/CMakeFiles/eccodes_f90.dir/build.make:125: recipe for target 
'fortran/CMakeFiles/eccodes_f90.dir/grib_f90.f90.o.provides' failed
  make[3]: *** [fortran/CMakeFiles/eccodes_f90.dir/grib_f90.f90.o.provides] 
Error 2
  make[3]: Leaving directory '/«PKGBUILDDIR»/debian/build'
  CMakeFiles/Makefile2:2922: recipe for target 
'fortran/CMakeFiles/eccodes_f90.dir/all' failed
  make[2]: *** [fortran/CMakeFiles/eccodes_f90.dir/all] Error 2
  make[2]: *** Waiting for unfinished jobs

Could you please take a look?  I'm filing this bug as a regression
because it would likely affect binNMUs.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#844041: nvidia-cuda-toolkit: FTBFS (cannot create /dev/tty)

[Santiago Vila]

On Sun, Nov 13, 2016 at 12:25:42AM +0100, Andreas Beckmann wrote:

> Did you repeat the test several times? Does it always fail?
> 
> Since I have no clue what happened here and I don't know how to reproduce it, 
> I'm downgrading the severity.

I tried to build it three times on two different autobuilders and it
always failed, so it's not random.

To reproduce it, please try to build it with sbuild and "union-type=overlay".

Just use a file called /etc/schroot/chroot.d/stretch containing this:

[stretch]
type=directory
description=Debian stretch
directory=/chroot/stretch
groups=sbuild
root-groups=sbuild
preserve-environment=true
union-type=overlay

where /chroot/stretch has a stretch chroot created with debootstrap.

Then you can enter the chroot by writing "schroot -c stretch"
or tell sbuild that "stretch" is the name of the chroot.

I believe this is a problem with "union-type=overlay" but I have not
had time to check it (sorry). Even in such case, very few packages
do not build with such option, it may be worth to know why it fails
and maybe find a workaround.

(For example, one of the packages that failed with union-type=overlay
has an orig.tar.gz not containing any directory entries, that kind
of thing is easy to fix).

Thanks.

Bug#842731: steam: Incomplete dependencies

[Michael Gilbert]

control: tag -1 moreinfo

Valve links in a bunch of libraries that are actually unused.  Adding
them as dependencies isn't useful.

If you can narrow down specifically which dependency is missing for
your setup, I'm happy to add it.

Best wishes,
Mike

Bug#844120: gwsetup does not use /etc/geneweb/gwsetup_only.txt

[Guillaume Brochu]

Dear John,


Thank you for reporting this bug. I am currently working on the package 
and I will include your modification to the gwsetup wrapper.


With best regards,


Guillaume Brochu


Le 2016-11-12 à 12:09, John Lines a écrit :

Package: gwsetup
Version: 6.08+git20160228+dfsg-2
Severity: normal
Tags: patch

Dear Maintainer,

Having geneweb and gwsetup installed on a headless machine it is useful
to be able to use gwsetup from another system.

The supplied grsetup.wrapper does not supply the '-only' argument to the
daemon. The attached patch points gwsetup to the supplied -only file.


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

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

Versions of packages gwsetup depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.59
ii  dpkg   1.18.14
ii  geneweb6.08+git20160228+dfsg-2
ii  libc6  2.24-5

gwsetup recommends no packages.

gwsetup suggests no packages.

-- debconf information:
   gwsetup/port: 2316
   gwsetup/run_mode: Always on

Bug#844170: RM: default-libmysqlclient-dev [all] -- ROM; absolete arch:all package

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

default-libmysqlclient-dev is now arch:any for better support for being
used in cross build scenarios

default-libmysqlclient-dev | 1.0.0 | unstable| all
default-libmysqlclient-dev | 1.0.1 | unstable| amd64, arm64, 
armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, 
mipsel, powerpc, ppc64el, s390x


Andreas

Bug#842174: [sddm] sddm crashes when second session is started

[Johannes Zarl-Zierl]

Hi Maximiliano,

On Freitag, 11. November 2016 11:01:02 CET Maximiliano Curia wrote:
> I think that xdm and lxdm don't support this, you'll need lightdm or gdm3
> for starting a new session.

Using lightdm I could reproduce this. Actually, lightdm's reaction is a lot 
worse than sddm (lightdm ends up in an endless loop and prevents me from 
accessing a text console due to the whole VT switching).

So I guess that makes Xorg or nvidia-legacy-340xx-driver the main suspects?


> I've produced a patch that handles reading an empty displaynumber (which
> means that the file was closed), sadly I can't test it, as I would need an X
> video driver that can't handle more than one display.
> 
> I'm attaching it, please let me know if you can test this.

I'll look into "apt-get source" and dpkg-buildpackage so that I can test 
this...

> I'll forward this information upstream.

Thanks.

Cheers,
  Johannes

Bug#844041: nvidia-cuda-toolkit: FTBFS (cannot create /dev/tty)

[Andreas Beckmann]

Control: severity -1 normal
Control: tags -1 moreinfo unreproducible

On 2016-11-12 00:45, Santiago Vila wrote:
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:

but the last buildd arch:all build succeeded:

https://buildd.debian.org/status/fetch.php?pkg=nvidia-cuda-toolkit=all=8.0.44-2=1477563848

> rm -f -r nvidia-cuda-amd64 nvidia-cuda-amd64.tmp
> sh cuda-linux64-rel-8.0.44-21122537.run --noexec --keep --target 
> nvidia-cuda-amd64.tmp
> Creating directory nvidia-cuda-amd64.tmp
> Verifying archive integrity... All good.
> Uncompressing NVIDIA 
> 

Bug#843532: [Pkg-dns-devel] Bug#843532: Bug#843532: dnssec-trigger: broken by OpenSSL 1.1.0

[Ondřej Surý]

I have forwarded both patches to the nlnetlabs-maintainers list. Thanks.

-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Thu, Nov 10, 2016, at 23:49, Sebastian Andrzej Siewior wrote:
> On 2016-11-10 12:10:41 [+0100], Ondřej Surý wrote:
> > Sebastian,
> 
> Hi Ondřej,
> 
> > thanks for the patch. The 0.13~svn685-7 version in unstable includes
> > your patch,
> > and I would really appreciate if someone could test whether
> > dnssec-trigger now
> > works.
> 
> I managed to get around to test it. So the initial error is gone - the
> daemon can be started. Are going the forward the two patches upstream or
> should I do it?
> 
> > Ondrej
> 
> Sebastian
> 
> ___
> pkg-dns-devel mailing list
> pkg-dns-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel

Bug#844169: RM: ruby-chef-config -- ROM; obsolete

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal

Please remove src:ruby-chef-config. It has been superseded by a
ruby-chef-config built from the chef source package.

$ rmadison ruby-chef-config
ruby-chef-config | 12.7.2-1  | unstable   | source, all
ruby-chef-config | 12.14.60-2| testing| all
ruby-chef-config | 12.14.60-2| unstable   | all



signature.asc
Description: PGP signature

Bug#844035: RFS: hylafax/3:6.0.6-7 [RC] -- Flexible client/server fax software

[Chris Lamb]

Joachim Wiedorn wrote:

> Is that o.k. that until now the new package is not visible
> on the qa.debian.org site ?

Huh, odd.. Not sure what's going on there, sorry.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#844168: python-mongoengine: Binary packages building requires downloading from pypi

[Al Nikolov]

Package: python-mongoengine
Version: 0.10.6-1
Severity: important

Dear Maintainer,

This version introduces, I believe, unacceptable behavior while building from 
source package,
namely at testing stage. 

--- cut buildlog here ---
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:170: python2.7 setup.py test 
running test
Searching for pymongo>=2.7.1
Reading https://pypi.python.org/simple/pymongo/
Download error on https://pypi.python.org/simple/pymongo/: [Errno 111] 
Connection refused -- Some packages may not be found!
Couldn't find index page for 'pymongo' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
Download error on https://pypi.python.org/simple/: [Errno 111] Connection 
refused -- Some packages may not be found!
No local packages or download links found for pymongo>=2.7.1
error: Could not find suitable distribution for 
Requirement.parse('pymongo>=2.7.1')
E: pybuild pybuild:256: test: plugin distutils failed with: exit code=1: 
python2.7 setup.py test 
dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir . returned exit 
code 13
--- cut buildlog here ---

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

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

Versions of packages python-mongoengine depends on:
ii  python  2.7.9-1
ii  python-gridfs   2.7.2-1
ii  python-pymongo  2.7.2-1
ii  python2.7   2.7.9-2+deb8u1

Versions of packages python-mongoengine recommends:
ii  python-django  1.7.11-1+deb8u1

python-mongoengine suggests no packages.

-- no debconf information

Bug#844115: Version tracking no longer knows about unstable versions

[James Clarke]

Control: tags -1 patch
Control: user bugs.debian@packages.debian.org
Control: usertag -1 bugscan

On Sat, Nov 12, 2016 at 05:13:15PM +, Mattia Rizzolo wrote:
> On Sat, Nov 12, 2016 at 06:06:35PM +0200, Adrian Bunk wrote:
> > This is likely caused by
> > https://lists.debian.org/debian-devel-announce/2016/11/msg5.html
>
> Not only this, unknown-package@ receive email of packages with known
> maintainer.
>
> You can have a look at archive-unknown-package on quantz to see them,
> for example I just receive notification that 835685 is closed, but that
> bug really is on a package with a maintainer.
> (removing myself from the alias until this is fixed).

Attached is a patch for bugscan which I believe should fix the issue.
It has been semi-tested (I extracted the methods to a separate file,
stubbed out the config and ran readpackages), but it's not exactly easy
to test properly...

Regards,
James
>From 8984ec2d25b0d0c73423350cc29139cd71237926 Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Sat, 12 Nov 2016 22:29:25 +
Subject: [PATCH] Handle .xz, .bz2 and uncompressed Sources and Packages files

---
 scanlib.pm | 39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/scanlib.pm b/scanlib.pm
index 7cd2e63..ee995ec 100644
--- a/scanlib.pm
+++ b/scanlib.pm
@@ -30,7 +30,27 @@ package scanlib;
 our (%maintainer,%section,%packagelist,%debbugssection,%bugs);
 
 
-# Read the list of maintainer 
+sub findcompressedfile {
+   my ($file) = @_;
+   my @types = (
+   { cat => "xzcat", ext => ".xz" },
+   { cat => "bzcat", ext => ".bz2" },
+   { cat => "zcat", ext => ".gz" },
+   { cat => "cat", ext => "" },
+   );
+   for my $type (@types) {
+   my $cat = $type->{cat};
+   my $ext = $type->{ext};
+   my $fileext = $file . $ext;
+   if (-f $fileext and system("which $cat >/dev/null 2>&1") == 0) {
+   return ($fileext, $cat);
+   }
+   }
+   die "Unable to find compressed file for $file";
+}
+
+
+# Read the list of maintainer
 sub readmaintainers() {
my $pkg;# Name of package
my $mnt;# Maintainer name & 
email
@@ -55,8 +75,9 @@ sub readsources {
 my ($root,$archive) = @_;
 
for my $sect (@bugcfg::sections) {
-   open(P, "zcat $root/$sect/source/Sources.gz|")
-   or die open "open: $sect sourcelist: $!\n";
+   my ($file, $cat) = 
findcompressedfile("$root/$sect/source/Sources");
+   open(P, "$cat $file|")
+   or die "open: $sect sourcelist ($cat $file): $!\n";
while () {
chomp;
next unless m/^Package:\s/;
@@ -71,23 +92,25 @@ sub readpackages {
 my ($root,$archive) = @_;
for my $arch ( @bugcfg::architectures ) {
for my $sect ( @bugcfg::sections) {
-   open(P, "zcat $root/$sect/binary-$arch/Packages.gz|")
-   or die "open: 
$root/$sect/binary-$arch/Packages.gz: $!\n";
+   my ($file, $cat) = 
findcompressedfile("$root/$sect/binary-$arch/Packages");
+   open(P, "$cat $file|")
+   or die "open: $cat $file: $!\n";
while () {
chomp;
next unless m/^Package:\s/; # We're only 
interested in the packagenames
s/^Package:\s*//;   # Strip 
the fieldname
$section{$_} = "$archive/$sect";
-   print "$root/$sect/binary-$arch/Packages.gz\n" 
if ($_ eq 'xtla');
+   print "$file\n" if ($_ eq 'xtla');
}
close(P);
}
}
 # handle the source packages
 for my $sect (@bugcfg::sections) {
+   my ($file, $cat) = findcompressedfile("$root/$sect/source/Sources");
my $fh;
-   open($fh,'-|','zcat',"$root/$sect/source/Sources.gz") or
-   die "Unable to open zcat $root/$sect/source/Sources.gz for reading: 
$!";
+   open($fh,'-|',"$cat","$file") or
+   die "Unable to open $cat $file for reading: $!";
while (<$fh>) {
chomp;
next unless m/^Package:\s/; # We're only interested in the 
packagenames
-- 
2.10.2

Bug#843141: [Debichem-devel] Bug#843141: Bug#843141: src:ga hijacked libga-dev from another package

[Michael Banck]

Hi,

On Sun, Nov 13, 2016 at 12:20:34AM +0200, Adrian Bunk wrote:
> On Sat, Nov 12, 2016 at 10:56:43PM +0100, Michael Banck wrote:
> > On Fri, Nov 04, 2016 at 01:11:16PM +0200, Adrian Bunk wrote:
> > > On Fri, Nov 04, 2016 at 12:37:30PM +0200, Graham Inggs wrote:
> > > > On 4 November 2016 at 11:47, Adrian Bunk  wrote:
> > > > > libga-dev in Debian is built from  of src:galib since 2008,
> > > > > but due to its higher version number src:ga has hijacked
> > > > > this package (likely not intentionally).
> > 
> > Ouch. I have to admit I probaby didn't check when I packaged it, but I'm
> > surprised ftp-master didn't catch it, either.
> 
> How could they catch it?

When they process NEW, check whether any of the NEW packages already
exist.
 
> Binary packages move between source packages all the time,
> and src:ga might just be a new version or fork of src:galib

Well, might be, but in that case the description and/or copyright could
get reviewed. They review the copyright quite thoroughly for licensing
issues anyway...

But anyway, we digress.
 
> > > > src:galib seems unmaintained since then, was orphaned in 2012
> > > > (#674871), and removed from testing in July 2016 (due to #812053).
> > > > 
> > > > Would an option here be to just RM src:galib?
> > > >...
> > > 
> > > this is not an option, since that would upgrade jessie users of 
> > > libga-dev to a completely unrelated package.
> > 
> > As libga-dev ships three different libs anyway, one option would be to
> > rename it to "ga-libs-dev", how does that sound?  The other option would
> > be "libglobalarrays-dev".
> > 
> > Thoughts?
> 
> Part of the problem is that both ship a libga

That part should be fixed by Conflicts, methinks.  But yeah, good point.


Michael

Bug#844167: eccodes: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

Package: src:eccodes
Version: 2.0.0-1
Severity: serious

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=cmake --with=python3 
--builddirectory=/<>/debian/build
   dh_testdir -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_update_autotools_config -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_autoreconf -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' 
-o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec 
md5sum {} \; > debian/autoreconf.before
autoreconf -f -i
aclocal: warning: couldn't open directory 'm4': No such file or directory
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'config'.
libtoolize: copying file 'config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'

[... snipped ...]

install -p -m0644 debian/copyright 
debian/libeccodes-doc/usr/share/doc/libeccodes-doc/copyright
   dh_installchangelogs -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
install -p -m0644 debian/changelog 
debian/libeccodes-doc/usr/share/doc/libeccodes-doc/changelog.Debian
install -p -m0644 ./ChangeLog 
debian/libeccodes-doc/usr/share/doc/libeccodes-doc/changelog
   dh_python3 -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
D: dh_python3 dh_python3:158: version: 2.20160818
D: dh_python3 dh_python3:159: argv: ['/usr/bin/dh_python3', '-i', 
'-O--buildsystem=cmake', '-O--builddirectory=/<>/debian/build']
D: dh_python3 dh_python3:160: options: {'vrange': None, 'depends_section': 
None, 'arch': False, 'no_shebang_rewrite': False, 'skip_private': False, 
'no_ext_rename': False, 'suggests': None, 'clean_dbg_pkg': True, 'requires': 
None, 'O': '--builddirectory=/<>/debian/build', 'depends': None, 
'suggests_section': None, 'compile_all': False, 'guess_deps': True, 'regexpr': 
None, 'ignore_shebangs': False, 'recommends_section': None, 'verbose': False, 
'shebang': None, 'package': None, 'recommends': None, 'no_package': None}
D: dh_python3 dh_python3:161: args: []
D: dh_python3 dh_python3:163: supported Python versions: 3.5 (default=3.5)
D: dh_python3 debhelper:100: skipping package libeccodes-doc (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:153: source=eccodes, binary packages=[]
E: dh_python3 dh_python3:173: no package to act on (python3-foo or one with 
${python3:Depends} in Depends)
   dh_perl -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_link -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_strip_nondeterminism -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
   dh_compress -i -O--buildsystem=cmake 
-O--builddirectory=/<>/debian/build
cd debian/libeccodes-doc
chmod a-x usr/share/doc/libeccodes-doc/changelog 
usr/share/doc/libeccodes-doc/changelog.Debian
gzip -9nf usr/share/doc/libeccodes-doc/changelog 
usr/share/doc/libeccodes-doc/changelog.Debian
cd '/<>'
rm -f debian/*.debhelper.log
   debian/rules override_dh_fixperms
make[1]: Entering directory '/<>'
dh_fixperms
find debian/libeccodes-doc  -print0 2>/dev/null | xargs -0r chown 
--no-dereference 0:0
find debian/libeccodes-doc ! -type l  -print0 2>/dev/null | xargs -0r 
chmod go=rX,u+rw,a-s
find debian/libeccodes-doc/usr/share/doc -type f  ! -regex 
'debian/libeccodes-doc/usr/share/doc/[^/]*/examples/.*' -print0 2>/dev/null | 
xargs -0r chmod 0644
find debian/libeccodes-doc/usr/share/doc -type d  -print0 2>/dev/null | 
xargs -0r chmod 0755
find debian/libeccodes-doc/usr/share/man -type f  -print0 2>/dev/null | 
xargs -0r chmod 0644
find debian/libeccodes-doc/usr/include -type f  -print0 2>/dev/null | 
xargs -0r chmod 0644
find debian/libeccodes-doc/usr/share/applications -type f  -print0 
2>/dev/null | xargs -0r chmod 0644
find debian/libeccodes-doc/usr/lib/x86_64-linux-gnu/perl5/5.24 
debian/libeccodes-doc/usr/share/perl5 -type f -perm -5 -name '*.pm'  -print0 
2>/dev/null | xargs -0r chmod a-X
find debian/libeccodes-doc -perm -5 -type f \( -name '*.so.*' -o -name 
'*.so' -o -name '*.la' -o -name '*.a' -o -name '*.js' -o -name '*.css' -o -name 
'*.jpeg' -o -name '*.jpg' -o -name '*.png' -o -name '*.gif' -o -name '*.cmxs' 
\)  -print0 2>/dev/null | xargs -0r chmod 0644
find debian/libeccodes-doc/usr/lib -type f -name '*.ali'  -print0 
2>/dev/null | xargs -0r chmod uga-w
test -e /usr/bin/dh_buildinfo && dh_buildinfo
gzip -9nf debian/buildinfo >debian/buildinfo.gz
install -g 0 -o 0 -m0644 

Bug#824532: udev: Include udev rules for more U2F devices

[Michael Biebl]

Am 12.11.2016 um 23:07 schrieb Rob N ★:
> On Sun, Nov 13, 2016, at 07:10 AM, Michael Biebl wrote:
>> Hm, I'm not sure if shipping 70-debian-uaccess.rules in the udev
>> package was a good idea in the first place. Imho this file should be
>> maintained by the libu2f-host package, and apparently it already ships
>> a rules file for that
> 
> I would argue that the rules file should be shipped wherever standard
> device support stuff is shipped (I think that is udev, though anything
> else installed as "standard" would be fine).

I'm not willing to maintain a hardware database *downstream* in udev.


> libu2f-host is not required to use U2F devices. A supporting web browser
> is all that's needed, typically Chromium etc, and soon Firefox.

Maybe libu2f-host should split those rules out into a -common package
then, which chromium, firefox and those applications, that need it, can
depend on.





-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#843141: [Debichem-devel] Bug#843141: Bug#843141: src:ga hijacked libga-dev from another package

[Adrian Bunk]

On Sat, Nov 12, 2016 at 10:56:43PM +0100, Michael Banck wrote:
> On Fri, Nov 04, 2016 at 01:11:16PM +0200, Adrian Bunk wrote:
> > On Fri, Nov 04, 2016 at 12:37:30PM +0200, Graham Inggs wrote:
> > > Hi Adrian
> > 
> > Hi Graham,
> > 
> > > On 4 November 2016 at 11:47, Adrian Bunk  wrote:
> > > > libga-dev in Debian is built from  of src:galib since 2008,
> > > > but due to its higher version number src:ga has hijacked
> > > > this package (likely not intentionally).
> 
> Ouch. I have to admit I probaby didn't check when I packaged it, but I'm
> surprised ftp-master didn't catch it, either.

How could they catch it?

Binary packages move between source packages all the time,
and src:ga might just be a new version or fork of src:galib

> > > src:galib seems unmaintained since then, was orphaned in 2012
> > > (#674871), and removed from testing in July 2016 (due to #812053).
> > > 
> > > Would an option here be to just RM src:galib?
> > >...
> > 
> > this is not an option, since that would upgrade jessie users of 
> > libga-dev to a completely unrelated package.
> 
> As libga-dev ships three different libs anyway, one option would be to
> rename it to "ga-libs-dev", how does that sound?  The other option would
> be "libglobalarrays-dev".
> 
> Thoughts?

Part of the problem is that both ship a libga

> Michael

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#843654: Use Debian pjproject and libsrtp

[Andrey Gursky]

Alexandre,

> Alexandre, could you please add "forwarded upstream" links for each of
> these patches and what Ring bugs are they suppose to fix?

sorry, I haven't received your mails (CC: me?), now found them on the
bug report page. Thanks.

Andrey

Bug#844165: More info

[Nekki Nekki]

dpkg -l | grep virtualbox
ii  virtualbox
5.1.8-dfsg-6 amd64x86 virtualization
solution - base binaries
ii  virtualbox-dkms
5.1.8-dfsg-6 all  x86 virtualization
solution - kernel module sources for dkms
ii  virtualbox-guest-additions-iso
5.1.8-1  all  guest additions iso image
for VirtualBox
ii  virtualbox-guest-dkms
5.1.8-dfsg-6 all  x86 virtualization
solution - guest addition module source for dkms
ii  virtualbox-guest-utils
5.1.8-dfsg-6 amd64x86 virtualization
solution - non-X11 guest utilities
ii  virtualbox-guest-x11
5.1.8-dfsg-6 amd64x86 virtualization
solution - X11 guest utilities
ii  virtualbox-qt
5.1.8-dfsg-6 amd64x86 virtualization
solution - Qt based user interface

Bug#844164: Acknowledgement (vim: since version 8, vim ignores indentation settings in /etc/vim/vimrc.local)

[Mikulas Patocka]

On Sat, 12 Nov 2016, Debian Bug Tracking System wrote:

> If you wish to submit further information on this problem, please
> send it to 844...@bugs.debian.org.

BTW. I found out, that if I create an empty file ~/.vimrc, vim8 will 
actually process the content of /etc/vim/vimrc.local correctly.

So, it seems like a bug in the config file processing - if ~/.vimrc is not 
present, vim will not honor some settings in /etc/vim/vimrc.local

Mikulas

Bug#824532: udev: Include udev rules for more U2F devices

[Rob N ★]

On Sun, Nov 13, 2016, at 07:10 AM, Michael Biebl wrote:
> Hm, I'm not sure if shipping 70-debian-uaccess.rules in the udev
> package was a good idea in the first place. Imho this file should be
> maintained by the libu2f-host package, and apparently it already ships
> a rules file for that

I would argue that the rules file should be shipped wherever standard
device support stuff is shipped (I think that is udev, though anything
else installed as "standard" would be fine).

libu2f-host is not required to use U2F devices. A supporting web browser
is all that's needed, typically Chromium etc, and soon Firefox.

Including it makes these devices work out-of-the-box, which is what
people expect. Requiring a library package to be installed that isn't
even used just raises the bar unnecessarily.

(just like every other device I don't own but have udev rules
installed for).

Bug#843141: [Debichem-devel] Bug#843141: Bug#843141: src:ga hijacked libga-dev from another package

[Michael Banck]

On Fri, Nov 04, 2016 at 01:11:16PM +0200, Adrian Bunk wrote:
> On Fri, Nov 04, 2016 at 12:37:30PM +0200, Graham Inggs wrote:
> > Hi Adrian
> 
> Hi Graham,
> 
> > On 4 November 2016 at 11:47, Adrian Bunk  wrote:
> > > libga-dev in Debian is built from  of src:galib since 2008,
> > > but due to its higher version number src:ga has hijacked
> > > this package (likely not intentionally).

Ouch. I have to admit I probaby didn't check when I packaged it, but I'm
surprised ftp-master didn't catch it, either.

> > src:galib seems unmaintained since then, was orphaned in 2012
> > (#674871), and removed from testing in July 2016 (due to #812053).
> > 
> > Would an option here be to just RM src:galib?
> >...
> 
> this is not an option, since that would upgrade jessie users of 
> libga-dev to a completely unrelated package.

As libga-dev ships three different libs anyway, one option would be to
rename it to "ga-libs-dev", how does that sound?  The other option would
be "libglobalarrays-dev".

Thoughts?


Michael

Bug#844122: linux: allow disabling linux-source-$ver build via config

[Bastian Blank]

On Sat, Nov 12, 2016 at 06:18:47PM +, Luca Boccassi wrote:
> Building linux-source-X.Y takes about ~10 minutes, and in the context
> of a continuous integration build where the result is tested and then
> discarded it is only a waste of time.

Could you explain a bit more what you are doing?  Compressing the debug
packages needs way more time already.

Regards,
Bastian

-- 
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.

Bug#841096: [Debichem-devel] Bug#841096: espresso: FTBFS (make install fails)

[Santiago Vila]

On Sat, Nov 12, 2016 at 10:43:11PM +0100, Michael Banck wrote:
> Hi Santiago,
> 
> On Wed, Nov 09, 2016 at 05:38:43PM +0100, Santiago Vila wrote:
> > The problem seems to be in the install target of the top-level
> > Makefile, which reads like this:
> 
> Thanks a lot for tracking this down, I've forwarded it upstream and
> uploaded a new revision with your patch.
> 
> Does -3 build fine for you now?

I usually test packages when they reach testing, but if you tried
adding "| LC_ALL=sort" to the find command to reproduce the problem
and now it does no longer fail when you do the same, then the problem
is probably fixed.

Thanks.

Bug#843654: Use Debian pjproject and libsrtp

[Andrey Gursky]

Hi Tzafrir, hi Bernhard, hi Alexandre

On Tue, 8 Nov 2016 16:24:58 +0100 Tzafrir Cohen wrote:

> On Tue, Nov 08, 2016 at 04:15:49PM +0100, Andrey Gursky wrote:
> > Source: ring
> > Version: 20161104.4.17a0616~dfsg1-2
> > Severity: normal
> > 
> > Dear maintainer,
> > 
> > A week ago pjproject 2.5.5 has been made available in Debian. The same
> > as in ring-daemon contribs. However ring applies following patches:
> > endianness.patch
> > gnutls.patch
> > notestsapps.patch
> > ipv6.patch
> > ice_config.patch
> > multiple_listeners.patch
> > pj_ice_sess.patch
> > fix_turn_fallback.patch
> > fix_ioqueue_ipv6_sendto.patch
> > 
> > The biggest one gnutls.patch can be dropped, since packaged pjproject
> > can dynamically link to a SSL library. Is the rest important? If not,
> > then the packaged pjproject could be used already. If not, is pjproject
> > not really usable without them? Then they should be forwarded upstream
> > and for now applied in the packaged pjproject. Or there are some issues
> > with that? Please share the current status.
> 
> For the record, pjproject is currently used by a single other package:
> asterisk. Upstream of asterisk recommends applying a set of their own
> patches:
> 
> http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=tree;f=third-party/pjproject/patches;hb=13

Tzafrir, thanks for pointing this out. I've just noticed that these
patches have been included in pjproject.

Bernhard, what do you think about including the bug-fix patches from
the Ring's pjproject also? For the same reasons as for Asterisk [1]:

> This is not allowed or severely disencouraged in most distributions, for
> very good reasons.
>
> https://fedoraproject.org/wiki/Bundled_Libraries
> https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

Alexandre, could you please add "forwarded upstream" links for each of
these patches and what Ring bugs are they suppose to fix?

Thanks,
Andrey

[1] 
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2016-November/019650.html

Bug#844142: norwegian: FTBFS: rm: cannot remove 'munch[123].tmp': No such file or directory

[Petter Reinholdtsen]

[Lucas Nussbaum]
> During a rebuild of all packages in sid, your package failed to build on
> amd64.

I believe this package can not be built in parallell.  Could this be the
trigger for this build problem?

-- 
Happy hacking
Petter Reinholdtsen

Bug#844165: virtualbox: Virtualbox & guests windows moving "alone" when mouse pointer moves.

[Nekki Nekki]

Package: virtualbox
Version: 5.1.8-dfsg-6
Severity: Important

Dear Maintainers,

Virtualbox is since a few weeks completely unusable. It's hard for me to
describe the issue,
so I recorded what happens with virtualbox and uploaded it to youtube.
The problem is: virtualbox main window and virtualbox guests windows moves
down when the mouse
pointer reaches tint2 panel (it move down, up left or right, depending on
the position of tint2).
The problem disappears if i use fbpanel or xfce4-panel. I run openbox. With
recent updates of virtualbox stuff,
the problem have disappeared. Now, it's present again.
Please check the video https://youtu.be/r5VT0kp9JZw
Thanks for your work,
Awtul



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

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

Versions of packages virtualbox depends on:
ii  adduser   3.115
ii  init-system-helpers   1.46
ii  libc6 2.24-5
ii  libcurl3-gnutls   7.51.0-1
ii  libdevmapper1.02.12:1.02.136-1
ii  libgcc1   1:6.2.0-13
ii  libgsoap102.8.35-3
ii  libpng16-16   1.6.26-1
ii  libpython3.5  3.5.2-7
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libssl1.0.2   1.0.2j-4
ii  libstdc++66.2.0-13
ii  libvncserver1 0.9.10+dfsg-3+b1
ii  libvpx4   1.6.0-3
ii  libx11-6  2:1.6.3-1
ii  libxcursor1   1:1.1.14-1+b1
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.4+dfsg1-2.1
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-2
ii  python3   3.5.1-4
ii  python3.5 3.5.2-7
pn  python3:any   
ii  virtualbox-dkms [virtualbox-modules]  5.1.8-dfsg-6
ii  zlib1g1:1.2.8.dfsg-2+b3

Versions of packages virtualbox recommends:
ii  libgl1-mesa-glx [libgl1]  12.0.4-2
ii  libqt5core5a  5.7.1~20161021+dfsg-5
ii  libqt5opengl5 5.7.1~20161021+dfsg-5
ii  libqt5widgets55.7.1~20161021+dfsg-5
ii  virtualbox-qt 5.1.8-dfsg-6

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  5.1.8-1

-- no debconf information

Bug#844166: lintian: false positive in a license paragraph

[Joao Eriberto Mota Filho]

Package: lintian
Version: 2.5.49
Severity: normal

Dear Maintainer,

My package libofa has these lintians:

I: libofa0: spelling-error-in-copyright a a (duplicate word) a
I: libofa0-dev: spelling-error-in-copyright a a (duplicate word) a

These messages was caused by the following text line:

 following Attribution Information: (a) a copyright notice including the name

Thanks.

Regards,

Eriberto

Bug#841096: [Debichem-devel] Bug#841096: espresso: FTBFS (make install fails)

[Michael Banck]

Hi Santiago,

On Wed, Nov 09, 2016 at 05:38:43PM +0100, Santiago Vila wrote:
> The problem seems to be in the install target of the top-level
> Makefile, which reads like this:

Thanks a lot for tracking this down, I've forwarded it upstream and
uploaded a new revision with your patch.

Does -3 build fine for you now?


Michael

Bug#825380: [Pkg-samba-maint] Bug#825380: winbind: Netbios name resolution can't find Windows clients

[Mathieu Parent]

 is.Hello,

2016-11-09 10:14 GMT+01:00 Tim Boundy :
> I've just updated to 2:4.4.7+dfsg-1 to see if there's any improvement.
> Massive regression. Now I can't ping via dns.
>
> ping: google.com: System error
>
> If I remove wins from nsswitch.conf, dns starts working again.

Do you have libnss-winbind installed? This is where libnss_wins.so.2 is.

If you already have this package. What does outputs?:

sudo strace ping google.com

Regards
-- 
Mathieu Parent

Bug#844164: vim: since version 8, vim ignores indentation settings in /etc/vim/vimrc.local

[Mikulas Patocka]

Package: vim
Version: 2:8.0.0022-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
I want to set up indentation rules that I am used to.
On vim7, it is possible to modify indentation rules in
/etc/vim/vimrc.local, but on vim8, most of the settings in
/etc/vim/vimrc.local are ignored.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I have this /etc/vim/vimrc.local file:
set nocp
set autoindent
set nocindent
set backupcopy=auto,breakhardlink
set bs=indent
set t_Co=1
hi ModeMsg term=none
hi NonText term=none
hi SpecialKey term=none
hi MatchParen term=none
syntax off
filetype off
filetype plugin off
filetype indent off

   * What was the outcome of this action?

Vim8 ignores some of the above settings
Vim automatically turns on the "cindent" rule if the file has "c"
extension (despite the fact that there is "filetype off" and "nocindent").

The command ":set backupcopy" shows "backupcopy=auto" (the breakhardlink flag 
is ignored)
The command ":set bs" shows "backspace=indent,eol,start" (the setting should be 
just "indent")
The command ":filetype" shows "filetype detection:ON  plugin:ON  indent:ON" (it 
should be turned off)


   * What outcome did you expect instead?
Vim should honor the configuration file /etc/vim/vimrc.local

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


-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 4.9.0-rc4+ (SMP w/12 CPU cores; PREEMPT)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages vim depends on:
ii  libacl1  2.2.52-3
ii  libc62.24-3
ii  libgpm2  1.20.4-6.2
ii  libselinux1  2.6-3
ii  libtinfo56.0+20160917-1
ii  vim-common   2:8.0.0022-1
ii  vim-runtime  2:8.0.0022-1

vim recommends no packages.

Versions of packages vim suggests:
pn  ctags
pn  vim-doc  
pn  vim-scripts  

-- no debconf information

Bug#844163: geda-gschem: gschem crashes with segmentation fault on help

[ael]

Package: geda-gschem
Version: 1:1.8.2-5
Severity: normal

I have not used gschem for a while so needed to refresh my memory.
I opened it on a schematic which was fine, but opening the help menu
and clicking on any of the entries resulted in a crash and core dump.

Trying the first entry gave this in the status window:

Backtrace:
In ice-9/boot-9.scm:
 160: 12 [catch #t # ...]
In unknown file:
   ?: 11 [apply-smob/1 #]
In ice-9/boot-9.scm:
 160: 10 [catch #t # ...]
In unknown file:
   ?: 9 [apply-smob/1 #]
   ?: 8 [eval-string "(help-manual)" #]
   ?: 7 [call-with-input-string "(help-manual)" ...]
In ice-9/boot-9.scm:
2404: 6 [save-module-excursion #]
In ice-9/eval-string.scm:
  44: 5 [read-and-eval # #:lang ...]
  37: 4 [lp (help-manual)]
In gschem/gschemdoc.scm:
  86: 3 [show-wiki "geda:documentation"]
In unknown file:
   ?: 2 [string-join (#f "wiki") "/" suffix]
In ice-9/boot-9.scm:
 105: 1 [# 
wrong-type-arg ...]
In unknown file:
   ?: 0 [apply-smob/1 # wrong-type-arg ...]

ERROR: In procedure apply-smob/1:
ERROR: In procedure string-append: Wrong type (expecting string): #f

-

Trying gdb on the core dump showed:


Core was generated by `gschem A701A_probed.sch'.
Program terminated with signal SIGSEGV, Segmentation fault.

===


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

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

Versions of packages geda-gschem depends on:
ii  geda-symbols 1:1.8.2-5
ii  guile-2.0-libs   2.0.13+1-2
ii  libc62.24-5
ii  libcairo21.14.6-1+b1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgeda421:1.8.2-5
ii  libglib2.0-0 2.50.1-1
ii  libgtk2.0-0  2.24.31-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libstroke0   0.5.1-8

Versions of packages geda-gschem recommends:
pn  extra-xdg-menus  

geda-gschem suggests no packages.

-- no debconf information

Bug#844035: RFS: hylafax/3:6.0.6-7 [RC] -- Flexible client/server fax software

[Joachim Wiedorn]

Hello Chris,

Chris Lamb wrote on 2016-11-12 09:48:

> Uploading to ftp-master (via ftp to ftp.upload.debian.org):
>   Uploading hylafax_6.0.6-7.dsc: done.
>   Uploading hylafax_6.0.6.orig.tar.gz: done.
>   Uploading hylafax_6.0.6-7.debian.tar.xz: done.
>   Uploading hylafax-client-dbg_6.0.6-7_amd64.deb: done.
>   Uploading hylafax-client_6.0.6-7_amd64.deb: done.
>   Uploading hylafax-server-dbg_6.0.6-7_amd64.deb: done.
>   Uploading hylafax-server_6.0.6-7_amd64.deb: done.
>   Uploading hylafax_6.0.6-7_20161112T094537z-0e26557c.buildinfo: done.
>   Uploading hylafax_6.0.6-7_amd64.changes: done.
> Successfully uploaded packages.

Thank you for sponsoring.

Is that o.k. that until now the new package is not visible
on the qa.debian.org site ?

---
Have a nice day.

Joachim (Germany)


pgpifWZQJo5es.pgp
Description: Digitale Signatur von OpenPGP

Bug#844162: src:kodi: validation failure with new fontforge

[Adam Borowski]

Package: src:kodi
Version: 17.0~beta5+dfsg1-1
Severity: normal

Hi!
The new version of fontforge, just uploaded to unstable, has a more stringent
validator, which causes:

fontforge -script /<>/kodi-17.0~beta5+dfsg1/debian/mergefonts.ff \
/usr/share/fonts/truetype/droid/DroidSansFallbackFull.ttf \
/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf \
/<>/kodi-17.0~beta5+dfsg1/media/Fonts/arial.ttf
Copyright (c) 2000-2014 by George Williams. See AUTHORS for Contributors.
 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
 with many parts BSD <http://fontforge.org/license.html>. Please read LICENSE.
 Based on sources from 20161112-ML-D.
 Based on source from git with hash:
Cannot find your hotkey definition file!
This font contains both a 'kern' table and a 'GPOS' table.
  The 'kern' table will only be read if there is no 'kern' feature in 'GPOS'.
Use-my-metrics flag set on at least two components in glyph 685
The glyph named Omega is mapped to U+03A9.
  But its name indicates it should be mapped to U+2126.

I don't know the first two problems, but the last one is caused by a
confusion between U+03A9 GREEK CAPITAL LETTER OMEGA and U+2126 OHM SIGN;
in an Adobe name list used by fontforge for some strange reason the name
"Omega" maps to the latter.  The list was apparently changed by Adobe some
time ago, between fontforge 20120731 and 20161005.  A workaround is to
explicitly use "Omega.greek".  There's some discussion at:
https://github.com/fontforge/fontforge/issues/2920


Meow!

Bug#844161: jessie-pu: package redmine/3.0~20140825-8~deb8u4

[Antonio Terceiro]

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

Hi,

I would like to update redmine in jessie.

redmine (3.0~20140825-8~deb8u4) jessie; urgency=medium

  * debian/postinst: handle dependency check failure when triggered, to avoid
breaking in the middle of dist-upgrades.
  * gemfile-adjustments.patch: avoid opening database configuration that are
not readable (Closes: #826663)

 -- Antonio Terceiro   Sat, 12 Nov 2016 19:00:15 -0200

full diff attached

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index ec0e42a..9a894b7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+redmine (3.0~20140825-8~deb8u4) jessie; urgency=medium
+
+  * debian/postinst: handle dependency check failure when triggered, to avoid
+breaking in the middle of dist-upgrades.
+  * gemfile-adjustments.patch: avoid opening database configuration that are
+not readable (Closes: #826663)
+
+ -- Antonio Terceiro   Sat, 12 Nov 2016 19:00:15 -0200
+
 redmine (3.0~20140825-8~deb8u3) jessie; urgency=medium
 
   * gemfile-adjustments.patch: load all database drivers for all Redmine
diff --git a/debian/patches/gemfile-adjustments.patch b/debian/patches/gemfile-adjustments.patch
index 0db0aa3..f38d5e3 100644
--- a/debian/patches/gemfile-adjustments.patch
+++ b/debian/patches/gemfile-adjustments.patch
@@ -45,7 +45,7 @@
 -if File.exist?(database_file)
 +seen_adapters = {}
 +Dir['{config,/etc/redmine/*}/database.yml'].select do |f|
-+  File.exists?(f)
++  File.readable?(f)
 +end.each do |database_file|
database_config = YAML::load(ERB.new(IO.read(database_file)).result)
adapters = database_config.values.map {|c| c['adapter']}.compact.uniq
diff --git a/debian/postinst b/debian/postinst
index 0abb494..2990058 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -12,7 +12,25 @@ RAKE_VERBOSE=false
 
 # update Gemfile.lock, always
 rm -f /var/lib/redmine/Gemfile.lock
-(cd /usr/share/redmine && bundle --local --quiet)
+cd /usr/share/redmine
+if ! bundle --local --quiet; then
+  if [ "$1" = "triggered" ]; then
+# probably triggered in the middle of an system upgrade; ignore failure
+# but abort here
+echo "#"
+echo "# Failed to detect redmine dependencies; if you are in the middle of an #"
+echo "# upgrade, this is probably fine, there will be another attempt later.  #"
+echo "#   #"
+echo "# If you are NOT in the middle of an upgrade, there is probably a real  #"
+echo "# issue. Please report a bug.   #"
+echo "#"
+exit 0
+  else
+# something is really broken
+exit 1
+  fi
+fi
+cd - >/dev/null
 chown www-data:www-data /var/lib/redmine/Gemfile.lock
 
 # remove and purge old instances each time postinst is called


signature.asc
Description: PGP signature

Bug#843960: [Pkg-openssl-devel] Bug#843960: Bug#843960: /test/recipes/90-test_srp.t: Keys mismatch during build tests

[Sebastian Andrzej Siewior]

On 2016-11-12 21:57:29 [+0100], Kurt Roeckx wrote:
> > Yes, you are right. Maybe we shouldn't run the testsuite in parallel.
> The test suite should not be running parallel? As far as I know
> that's not supported, and we're not doing it.

I think so. Looking at logs of armel, amd64, arm64 the "keys missmatch"
line is the same spot. It is probably something else that led to this…

> Kurt

Sebastian

Bug#826297: really should document the Debian way to create /shutdown-log.txt

[Michael Biebl]

Am 11.11.2016 um 01:58 schrieb 積丹尼 Dan Jacobson:
>> "MB" == Michael Biebl  writes:
> 
> MB> With merged-usr this will be obsolete
> 
> OK. What should I mention in the patch do deal with both cases, pre
> merged-usr and post merged-usr? Or maybe I can make one sized fits all
> instructions?

/lib should work, even with merged-usr. After all /lib/ will be a
symlink to /usr/lib


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#843073: dpkg-shlibdeps: broken on i386 with merged /usr

[Helmut Grohne]

On Sat, Nov 05, 2016 at 10:40:30PM +0100, Marco d'Itri wrote:
> This is a more complex issue, since it does not happen on my i386 
> system.
> It has been discussed in #810499 but I am not sure about the best way to 
> fix this.

It depends on the search order for library directories. dpkg-shlibdeps
parses /etc/ld.so.conf and has its own idea on which directories to
search built into the Dpkg::Shlibdeps module. Thus the failure comes and
goes as the search order changes. By changing the search order, you can
even reproduce in on amd64:

sbuild -d sid --add-depends=usrmerge --chroot-setup-commands="sed -i 

Bug#844159: virt-manager: suggests/uses python-gnomekeyring which is deprecated

[Michael Biebl]

Source: virt-manager
Version: 1:1.4.0-3
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs python-gnomekeyring gnome-python-desktop

Hi,

virt-manager suggests python-gnomekeyring, which is long deprecated and
going to be removed from the archive. It should switch to using the
GObject Introspection bindings for gnome-keyring,
gir1.2-gnomekeyring-1.0.

This would mean switching to GObject Introspection for other bindings as
well, e.g. GLib and GTK+, so making the switch to GTK+ 3 at the same
time would make a lot of sense.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Stretch release as we're going to try
to remove it this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/action/show/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/action/show/Projects/PyGObject

Bug#844160: apache2-dev should depend on libssl1.0-dev

[Adrian Bunk]

Package: apache2-dev
Version: 2.4.23-5
Severity: serious

Looking at mod_ssl_openssl.h and the comment in #828330,
I'd suggest the change below to add a dependency on libssl1.0-dev
to apache2-dev.

This would prevent packages from build-depending (directly or
indirectly) on both apache2-dev and the OpenSSL 1.1 libssl-dev.

--- debian/control.old  2016-11-12 13:18:55.0 +
+++ debian/control  2016-11-12 13:30:56.0 +
@@ -121,7 +121,7 @@
 Package: apache2-dev
 Architecture: any
 Depends: ${misc:Depends}, openssl,
- libapr1-dev, libaprutil1-dev, debhelper (>= 9), ${perl:Depends}
+ libapr1-dev, libaprutil1-dev, debhelper (>= 9), ${perl:Depends}, 
libssl1.0-dev | libssl-dev (<< 1.1)
 Provides: dh-apache2
 Description: Apache HTTP Server (development headers)
  The Apache HTTP Server Project's goal is to build a secure, efficient and

Bug#843960: [Pkg-openssl-devel] Bug#843960: Bug#843960: /test/recipes/90-test_srp.t: Keys mismatch during build tests

[Kurt Roeckx]

On Sat, Nov 12, 2016 at 09:44:53PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-12 21:21:23 [+0100], Kurt Roeckx wrote:
> > On Sat, Nov 12, 2016 at 08:51:09PM +0100, Sebastian Andrzej Siewior wrote:
> > > Why did it say "Keys mismatch" then? I don#t see this in a normal built.
> > 
> > I see it in all the logs? But it seems to be at a slighty different line.
> 
> Yes, you are right. Maybe we shouldn't run the testsuite in parallel.
> Also the fact the published only a snipped of testsuite output is
> something that let me jump in conclusions :/

The test suite should not be running parallel? As far as I know
that's not supported, and we're not doing it.


Kurt

Bug#844158: osc: suggests/uses python-gnomekeyring which is deprecated

[Michael Biebl]

Source: osc
Version: 0.155.1-1
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs python-gnomekeyring gnome-python-desktop

Hi,

osc suggests python-gnomekeyring, which is long deprecated and going
to be removed from the archive. It should switch to using the GObject
Introspection bindings for gnome-keyring, gir1.2-gnomekeyring-1.0.

This would mean switching to GObject Introspection for other bindings as
well, e.g. GLib and GTK+, so making the switch to GTK+ 3 at the same
time would make a lot of sense.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Stretch release as we're going to try
to remove it this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/action/show/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/action/show/Projects/PyGObject

Bug#842796: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

Lucas,

Thanks for trying a build run with TSX enabled.

On Sat, 12 Nov 2016, Lucas Nussbaum wrote:
> I did an archive rebuild on Amazon EC2 using m4.16xlarge instances, that
> use a CPU with TSX enabled.

What microcode revision is that Xeon E5-2686 running?

> I've filed bugs for the packages that failed during that rebuild, but
> don't fail on m4.large instances:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-ftbfs-2016;users=debian...@lists.debian.org

We still need that instrumented libc if one is to test applications,
though, as most packages have little in the way of automated regression
test suites.  And people need to test the packages (using the
applications) with such an instrumented libc installed (or running on a
box with TSX active).

-- 
  Henrique Holschuh

Bug#844156: gajim: suggests/uses python-gnomekeyring which is deprecated

[Michael Biebl]

Source: gajim
Version: 0.16.6-1
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs python-gnomekeyring gnome-python-desktop

Hi,

gajim suggests python-gnomekeyring, which is long deprecated and going
to be removed from the archive. It should switch to using the GObject
Introspection bindings for gnome-keyring, gir1.2-gnomekeyring-1.0.

This would mean switching to GObject Introspection for other bindings as
well, e.g. GLib and GTK+, so making the switch to GTK+ 3 at the same
time would make a lot of sense.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Stretch release as we're going to try
to remove it this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/action/show/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/action/show/Projects/PyGObject

Bug#844157: gtg: suggests/uses python-gnomekeyring which is deprecated

[Michael Biebl]

Source: gtg
Version: 0.3.1-4
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs python-gnomekeyring gnome-python-desktop

Hi,

gtg suggests python-gnomekeyring, which is long deprecated and going
to be removed from the archive. It should switch to using the GObject
Introspection bindings for gnome-keyring, gir1.2-gnomekeyring-1.0.

This would mean switching to GObject Introspection for other bindings as
well, e.g. GLib and GTK+, so making the switch to GTK+ 3 at the same
time would make a lot of sense.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Stretch release as we're going to try
to remove it this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/action/show/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/action/show/Projects/PyGObject

Bug#844155: screenlets: recommends/uses python-gnomekeyring which is deprecated

[Michael Biebl]

Source: screenlets
Version: 0.1.2-8.1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs python-gnomekeyring gnome-python-desktop

Hi,

screenlets recommends python-gnomekeyring, which is long
deprecated and going to be removed from the archive. It should
switch to using the GObject Introspection bindings for gnome-keyring,
gir1.2-gnomekeyring-1.0.

This would mean switching to GObject Introspection for other bindings
as well, e.g. GLib and GTK+, so making the switch to GTK+ 3 at the
same time would make a lot of sense.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Stretch release as we're going to
try to remove it this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/action/show/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/action/show/Projects/PyGObject