Bug#818360: Patch status

[Tobias Lippert]

Dear maintainer,

are there any issues with the patch? If yes, I will be happy to address
them.

Kind regards,
Tobias Lippert

Bug#858122: closed by Salvatore Bonaccorso <car...@debian.org> (Bug#858122: fixed in linux 4.9.16-1)

[Salvatore Bonaccorso]

Hi Julien,

On Mon, Apr 03, 2017 at 09:00:27PM +0200, Julien Aubin wrote:
> Hi Salvatore,
> 
> Regarding this issue which is critical, could you please unblock the
> migration to testing of the 4.9.18 kernel ?

It's not something I can do, but release manager have done so (now),
and the time to migrate will be as well speed up a bit.

Regards,
Salvatore

Bug#859688: libbiod FTBFS on i386: cannot implicitly convert expression (this._stream.position()) of type ulong to uint

[Andreas Tille]

Hi,

may I throw this problem to D packaging team as well?  SOrry, I have no
idea about D. :-(

THanks for any help

   Andreas.

On Thu, Apr 06, 2017 at 02:28:11AM +0300, Adrian Bunk wrote:
> Source: libbiod
> Version: 0.1.0-2
> Severity: important
> 
> https://buildd.debian.org/status/fetch.php?pkg=libbiod=i386=0.1.0-2=1491407467=0
> 
> ...
> [65/149] ldc2  '-Ibiod@sha' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
> '-enable-color' '-O' '-g' '-release' '-relocation-model=pic'  -of 
> 'biod@sha/bio_sff_readrange.d.o' -c ../bio/sff/readrange.d
> FAILED: biod@sha/bio_sff_readrange.d.o 
> ldc2  '-Ibiod@sha' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
> '-enable-color' '-O' '-g' '-release' '-relocation-model=pic'  -of 
> 'biod@sha/bio_sff_readrange.d.o' -c ../bio/sff/readrange.d
> ../bio/sff/readrange.d(72): Error: cannot implicitly convert expression 
> (this._stream.position()) of type ulong to uint
> [66/149] ldc2  '-Ibiod@sha' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
> '-enable-color' '-O' '-g' '-release' '-relocation-model=pic'  -of 
> 'biod@sha/bio_core_bgzf_virtualoffset.d.o' -c ../bio/core/bgzf/virtualoffset.d
> [67/149] ldc2  '-Ibiod@sha' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
> '-enable-color' '-O' '-g' '-release' '-relocation-model=pic'  -of 
> 'biod@sha/bio_core_bgzf_inputstream.d.o' -c ../bio/core/bgzf/inputstream.d
> [68/149] ldc2  '-Ibiod@sha' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
> '-enable-color' '-O' '-g' '-release' '-relocation-model=pic'  -of 
> 'biod@sha/bio_core_bgzf_outputstream.d.o' -c ../bio/core/bgzf/outputstream.d
> [69/149] ldc2  '-Ibiod_test@exe' '-I.' '-I..' '-I' '-I../' 
> '-I/usr/include/d/' '-enable-color' '-O' '-g' '-release' '-unittest'  -of 
> 'biod_test@exe/bio_core_bgzf_outputstream.d.o' -c 
> ../bio/core/bgzf/outputstream.d
> [70/149] ldc2  '-Ibiod_test@exe' '-I.' '-I..' '-I' '-I../' 
> '-I/usr/include/d/' '-enable-color' '-O' '-g' '-release' '-unittest'  -of 
> 'biod_test@exe/bio_core_tinymap.d.o' -c ../bio/core/tinymap.d
> ninja: build stopped: subcommand failed.
> debian/rules:20: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 1
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#859693: sysv-rc-conf: disabling auto-start of a systemd service appears successful but is not

[user]

Package: sysv-rc-conf
Version: 0.99-7
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: user 
To: Debian Bug Tracking System 
Subject: sysv-rc-conf: disabling a systemd service appears to work but the 
service
 still runs
Message-ID: <20170406034251.3634.68427.reportbug@computer>
X-Mailer: reportbug 6.6.3
Date: Wed, 05 Apr 2017 20:42:51 -0700
X-Debbugs-Cc: user@localhost.localdomain

Package: sysv-rc-conf
Version: 0.99-7
Severity: important

Dear Maintainer,

I have lighttpd and sysv-rc-conf installed from the standard Jessie (currently
Stable) repos.

For security and other reasons, I used sysv-rc-conf to disable auto-starting of
lighttpd and some other services. The program's console UI "properly" cleared
the auto-start boxes for lighttpd (and other services) in all runlevels and
exited normally. Upon rebooting, I was very upset to learn that lighttpd had
auto-started anyway (seen with "service lighttpd status" which shows it as
executing with /lib/systemd/system/lighttpd.service ).

Other services, those which start from /etc/init.d/* seem to respond correctly,
though.

Note that this is a real-world impact of related bug #791689

If users are led to believe that a service has been disabled when it is in fact
still running, the consequences could be serious from a security perspective,
not to mention that if updates are made to the unit files themselves, major
conflicts could emerge from duplicate services and so on.

Thank you very much.

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

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

Versions of packages sysv-rc-conf depends on:
ii  libcurses-ui-perl  0.9609-1
ii  sysv-rc2.88dsf-59

sysv-rc-conf recommends no packages.

sysv-rc-conf suggests no packages.

-- no debconf information

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

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

Versions of packages sysv-rc-conf depends on:
ii  libcurses-ui-perl  0.9609-1
ii  sysv-rc2.88dsf-59

sysv-rc-conf recommends no packages.

sysv-rc-conf suggests no packages.

-- no debconf information

Bug#749991: Wrong kernel in debian-installer package

[Alexander Sosedkin]

On Thu, 6 Apr 2017 00:05:17 +0200
Cyril Brulebois  wrote:

> That's unfortunate, yes, but there's no easy way to keep old packages
> around in a given repository.

That's one way to think about it. Got it, keeping old modules is hard.
But I wasn't asking about keeping old modules, I see no point in this.
I was asking about generating and publishing a matching
dists/testing/main/installer-/current on kernel upload.
Why is _that_ hard?

I'm asking less of "why isn't it equal to
https://d-i.debian.org/daily-images tree",
and more of "why not d-i stretch rc 2 rebuilt with new kernel".
And https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749991#59
doesn't quite cut it. Triggering is hard? Maybe, why not cron then?

Bug#859692: initramfs-tools: should depend on busybox

[Russell Coker]

Package: initramfs-tools
Version: 0.127
Severity: important


# dpkg-reconfigure linux-image-4.9.0-2-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-2-amd64
E: busybox or busybox-static, version 1:1.22.0-17~ or later, is required but 
not installed
update-initramfs: failed for /boot/initrd.img-4.9.0-2-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1

This package should depend on busybox|busybox-static instead of giving an
error at runtime.

-- Package-specific info:
-- initramfs sizes
-rw-r--r--. 1 root root 20M Feb 28 14:42 /boot/initrd.img-4.9.0-1-amd64
-rw-r--r--. 1 root root 20M Mar 24 19:49 /boot/initrd.img-4.9.0-2-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.9.0-2-amd64 
root=UUID=a2d7cbbc-23be-4d97-b2bb-de99b0c58c7d ro security=selinux 
rootflags=skip_balance security=selinux init=/bin/systemd

-- resume
RESUME=/dev/mapper/xev-swap
-- /proc/filesystems
btrfs
ext3
ext2
ext4

-- lsmod
Module  Size  Used by
uas24576  0
usb_storage73728  3 uas
bridge135168  0
stp16384  1 bridge
llc16384  2 bridge,stp
cpufreq_userspace  16384  0
cpufreq_powersave  16384  0
cpufreq_conservative16384  0
binfmt_misc20480  1
ext4  585728  2
crc16  16384  1 ext4
jbd2  106496  1 ext4
fscrypto   28672  1 ext4
ecb16384  0
mbcache16384  3 ext4
snd_hda_codec_realtek86016  1
snd_hda_codec_generic69632  1 snd_hda_codec_realtek
snd_hda_intel  36864  0
snd_hda_codec 135168  3 
snd_hda_intel,snd_hda_codec_generic,snd_hda_codec_realtek
snd_hda_core   81920  4 
snd_hda_intel,snd_hda_codec,snd_hda_codec_generic,snd_hda_codec_realtek
snd_hwdep  16384  1 snd_hda_codec
snd_pcm_oss49152  0
intel_rapl 20480  0
x86_pkg_temp_thermal16384  0
snd_mixer_oss  24576  1 snd_pcm_oss
intel_powerclamp   16384  0
snd_pcm   110592  4 
snd_pcm_oss,snd_hda_intel,snd_hda_codec,snd_hda_core
snd_seq_midi   16384  0
snd_seq_midi_event 16384  1 snd_seq_midi
kvm_intel 192512  0
snd_rawmidi32768  1 snd_seq_midi
evdev  24576  17
kvm   589824  1 kvm_intel
irqbypass  16384  1 kvm
intel_cstate   16384  0
iTCO_wdt   16384  0
eeepc_wmi  16384  0
asus_wmi   28672  1 eeepc_wmi
snd_seq65536  2 snd_seq_midi_event,snd_seq_midi
sparse_keymap  16384  1 asus_wmi
rfkill 24576  2 asus_wmi
iTCO_vendor_support16384  1 iTCO_wdt
i915 1232896  5
intel_uncore  118784  0
snd_seq_device 16384  3 snd_seq,snd_rawmidi,snd_seq_midi
intel_rapl_perf16384  0
snd_timer  32768  2 snd_seq,snd_pcm
sg 32768  0
pcspkr 16384  0
serio_raw  16384  0
drm_kms_helper155648  1 i915
snd86016  12 
snd_pcm_oss,snd_hda_intel,snd_hwdep,snd_mixer_oss,snd_seq,snd_hda_codec,snd_timer,snd_rawmidi,snd_hda_codec_generic,snd_seq_device,snd_hda_codec_realtek,snd_pcm
drm   360448  5 i915,drm_kms_helper
wmi16384  1 asus_wmi
soundcore  16384  1 snd
video  40960  2 asus_wmi,i915
tpm_tis16384  0
i2c_algo_bit   16384  1 i915
tpm_tis_core   20480  1 tpm_tis
lpc_ich24576  0
shpchp 36864  0
tpm45056  2 tpm_tis,tpm_tis_core
mei_me 36864  0
mei   102400  1 mei_me
mfd_core   16384  1 lpc_ich
button 16384  1 i915
coretemp   16384  0
loop   28672  0
parport_pc 28672  0
ppdev  20480  0
sunrpc339968  1
lp 20480  0
parport49152  3 lp,parport_pc,ppdev
ip_tables  24576  0
x_tables   36864  1 ip_tables
autofs440960  2
btrfs1060864  1
crc32c_generic 16384  0
xor24576  1 btrfs
raid6_pq  110592  1 btrfs
algif_skcipher 20480  0
af_alg 16384  1 algif_skcipher
hid_generic16384  0
usbhid 53248  0
hid   122880  2 hid_generic,usbhid
dm_crypt   24576  2
dm_mod118784  5 dm_crypt
sr_mod 24576  0
cdrom  61440  1 sr_mod
sd_mod 45056  6
ata_generic16384  0
crct10dif_pclmul   16384  0
crc32_pclmul   16384  0
crc32c_intel   24576  1
ghash_clmulni_intel16384  0
ata_piix   36864  3
aesni_intel   167936  7
libata

Bug#755911: Python3 version

[Arnaud Fontaine]

Hi,

Sorry, I completely forgot about this. I will do it within this week.

Regards,
-- 
Arnaud Fontaine


signature.asc
Description: PGP signature

Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy

[James McCoy]

Control: tag -1 confirmed
Control: reassign -1 xterm
Control: retitle -1 Terminal stays bold after visual bell with bold text 
displayed

On Mon, Mar 20, 2017 at 10:29:20PM +0100, Francesco Poli (wintermute) wrote:
> I have experienced this bug for a fairly long time, when editing
> markdown documents with vim. It has been triggered in a seemingly
> random manner.

It's the visual bell that happens when you get to the top of the buffer
and try to keep going.  That causes Vim to send the BEL (Ctrl-G) to the
terminal.  The way the buffer is currently highlighted (some bold text)
at that point is causing xterm to get stuck.

You can reset it by Ctrl-RightClick -> "Escape Sequence".

It works fine in at least pangoterm, but I haven't tried other more
mainstream terminals.

I'm reassigning to xterm for now.  Rest of the context is below.

> I finally found a reliable way to reproduce it.
> 
> Steps to reproduce:
> 
>   0) open the attached test.md file:
> 
>  $ vim -u NONE test.md
> 
>   1) enable syntax highlighting:
> 
>  :set bg=dark
>  :syn on
> 
>   2) go to the end of the file:
> 
>  [Shift+G]
> 
>   3) go back to the beginning of the file (line by line):
> 
>  [k].[k] ← hold the key pressed until you reach the first line
> 
>   4) visualize file info on the status line:
> 
>  [Ctrl+G]
> 
>   5) the syntax highlighting has gone crazy (even the status line is
>  in boldface!): see the attached screenshot
>  wrong_vim_syntaxmarkdown.png
> 
>   6) exit from vim:
> 
>  :q
> 
>   7) the terminal (xterm), or rather the shell (bash), has also gone
>  crazy (it now prints everything in boldface by default): see
>  the attached screenshot
>  wrong_vim_syntaxmarkdown2.png
> 
>   8) the terminal won't come back to normal behavior until I quit it;
>  another trick to regain the normal behavior of the terminal is
>  opening test.md again, enable syntax highlighting, and exit vim
>  (steps 0, 1, and 6 above)

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

Bug#856920: vim-gtk does not refresh window in full-screen mode with a tiling window manager when multiple tabs are used.

[James McCoy]

On Mon, Mar 06, 2017 at 09:57:29AM +0100, Francesco Paolo Lovergine wrote:
> Package: vim-gtk

Is this reproducible with vim-gtk3?

> In order to reproduce the bug:
> 
> - use a tiled window manager (wm): i'm using awesome for that, not sure about
>   others.

I'm using i3.

> - load vim-gtk in a wm tab in 'max' mode.

Does this mean "fullscreen" (no decorations) or just that it takes up
the entire tab?  I'm using i3's fullscreen mode to try reproducing the
behavior.

Also, do you mean tag here or a tabbed layout in a tag?

> - create a new vim tab with :tabnew.
> - switch to another wm tab and switch back to the gvim-gtk wm tab.
> 
> You will se a grey window with a blinking cursor.

Unfortunately, I don't.  Everything looks fine.  Does this happen when
using "gvim -u NORC" or does it need something in your configuration?

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

Bug#858956: firefox-esr: Geolocation seems to be broken

[Alejandro Carrazzoni]

Package: firefox-esr
Followup-For: Bug #858956

Looks like the issue is now fixed, thanks!



-- Package-specific info:

-- Extensions information
Name: Application Update Service Helper
Location: ${PROFILE_EXTENSIONS}/aushel...@mozilla.org.xpi
Status: enabled

Name: Cookies Manager+
Location: ${PROFILE_EXTENSIONS}/{bb6bc1bb-f824-4702-90cd-35e2fb24f25d}
Status: enabled

Name: Default theme
Location: 
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: user-disabled

Name: Diccionario Español Argentina dictionary
Location: ${PROFILE_EXTENSIONS}/es...@dictionaries.addons.mozilla.org
Status: enabled

Name: DOM Inspector
Location: ${PROFILE_EXTENSIONS}/inspec...@mozilla.org
Status: enabled

Name: Emoji Cheatsheet for GitHub, Basecamp etc.
Location: ${PROFILE_EXTENSIONS}/jid1-xo5sua6qc1d...@jetpack.xpi
Status: enabled

Name: Español (AR) Language Pack locale
Location: 
/usr/lib/firefox-esr/browser/extensions/langpack-es...@firefox-esr.mozilla.org.xpi
Package: firefox-esr-l10n-es-ar
Status: enabled

Name: Grayfox theme
Status: enabled

Name: KeeFox
Location: ${PROFILE_EXTENSIONS}/keefox@chris.tomlinson
Status: enabled

Name: MEGA
Location: ${PROFILE_EXTENSIONS}/fire...@mega.co.nz.xpi
Status: enabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: Personas Plus
Location: ${PROFILE_EXTENSIONS}/perso...@christopher.beard.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: Roomy Bookmarks Toolbar
Location: ${PROFILE_EXTENSIONS}/alone-l...@ya.ru.xpi
Status: enabled

Name: Search by Image for Google
Location: ${PROFILE_EXTENSIONS}/{ab4b5718-3998-4a2c-91ae-18a7c2db513e}.xpi
Status: enabled

Name: Speed Dial
Location: ${PROFILE_EXTENSIONS}/{64161300-e22b-11db-8314-0800200c9a66}.xpi
Status: enabled

Name: Tab Mix Plus
Location: ${PROFILE_EXTENSIONS}/{dc572301-7619-498c-a57d-39143191b318}.xpi
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: User Agent Switcher
Location: ${PROFILE_EXTENSIONS}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}.xpi
Status: enabled

Name: Video DownloadHelper
Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi
Status: user-disabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

Name: YesScript
Location: ${PROFILE_EXTENSIONS}/yesscr...@userstyles.org.xpi
Status: enabled

-- Plugins information
Name: Google Talk Plugin
Location: /opt/google/talkplugin/libnpgoogletalk.so
Package: google-talkplugin
Status: enabled

Name: Google Talk Plugin Video Renderer
Location: /opt/google/talkplugin/libnpo1d.so
Package: google-talkplugin
Status: enabled

Name: Shockwave Flash (24.0.0.194)
Location: 
/usr/lib/browser-plugin-freshplayer-pepperflash/libfreshwrapper-flashplayer.so
Package: browser-plugin-freshplayer-pepperflash
Status: enabled


-- Addons package information
ii  browser-plugin 0.3.5-1+b1   amd64PPAPI-host NPAPI-plugin adapter f
ii  firefox-esr52.0.2esr-1  amd64Mozilla Firefox web browser - Ext
ii  firefox-esr-l1 52.0.2esr-1  all  Spanish (Argentina) language pack
ii  google-talkplu 5.41.3.0-1   amd64Google Talk Plugin

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.1
ii  fontconfig2.11.0-6.7+b1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-9
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.16-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3+b2
ii  libgcc1   1:6.3.0-8
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-1
ii  libgtk-3-03.22.11-1
ii  libgtk2.0-0   2.24.31-2
ii  libhunspell-1.4-0 1.4.1-2+b2
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.40.4-1
ii  libsqlite3-0  3.16.2-3
ii  libstartup-notification0  0.12-4
ii  libstdc++66.3.0-8
ii  libvpx4   1.6.1-2
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6   

Bug#859690: installation-reports: Resume (wake up) from suspend freezes system on DELL XPS-13 9360 with Debian Stretch (new fresh install)

[Pierre Lafaye de Micheaux]

Package: installation-reports
Severity: important

Dear Maintainer,

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

   * What led up to the situation? Was there at the very begining
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Don't know what to do.
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



-- Package-specific info:

Boot method: USB
Image version: 
Date: 

Machine: DELL XPS 13 9360
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170127"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux Inuk-XPS13-Debian9 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 
(2017-01-12) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5904] 
(rev 02)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:5916] (rev 02)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Skylake Processor Thermal Subsystem [8086:1903] (rev 02)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: 00:15.1 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] 
(rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #5 [8086:9d14] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.5 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #6 [8086:9d15] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #9 [8086:9d18] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:9d58] 
(rev 21)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise 
Point-LP PMC [8086:9d21] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Device [8086:9d71] 
(rev 21)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel, snd_soc_skl
lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus 
[8086:9d23] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:075b]
lspci -knn: 01:00.0 PCI bridge [0604]: Intel Corporation DSL6340 Thunderbolt 3 
Bridge [Alpine Ridge 2C 2015] [8086:1576]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 02:00.0 PCI bridge [0604]: Intel Corporation DSL6340 Thunderbolt 3 
Bridge [Alpine Ridge 2C 2015] [8086:1576]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 02:01.0 

Bug#837451: xserver-xorg-core: visual flashes followed by hard crash upon keyboard interaction with thinkpad x201

[Gabriel Filion]

Hi all,

intrigeri:
> Gabriel Filion:
>> but yeah I could disable the force (, luke) and see if I can reproduce
>> the bug again with the newer package versions.
> 
>> I'll see if I can do that on sunday
> 
> Ping?

sorry it took me so much time.

I upgraded xserver-xorg-core to 2:1.19.3-1 (in sid) and removed the
/etc/X11/xorg.conf file that was forcing xorg to load the intel driver.

I then restarted the X display and was able to reproduce the visual
flashes (or rather visible screen refresh) and hard crash followed by an
automatic shutdown about 10s later.



signature.asc
Description: OpenPGP digital signature

Bug#859620: somewhat pending…

[Holger Levsen]

control: retitle -1 add new section(s): wheezysid and/or jessie222sid - or 
stable222sid and/or oldstablesid
thanks

for now we have jessie222sid…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#859378: unblock: screen/4.5.0-5 (pre-approval)

[Cyril Brulebois]

Niels Thykier  (2017-04-04):
> Niels Thykier:
> > Axel Beckert:
> >> https://bugs.debian.org/856824 (which I already fixed in experimental
> >> a while ago) seems to be more severe than I initially thought. If
> >> unfixed, it can lead to a race condition at boot time when running
> >> with systemd as init system. See Marc's explanations at
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856824#24
> >>
> >> So I would upload screen/4.5.0-5 with the same fix as already applied
> >> in experimental (and with no issues or bug reports there so far) to
> >> unstable, too, if you're ok with it.
> >>
> >> I've prepared the upload in the "stretch" branch at
> >> https://anonscm.debian.org/cgit/collab-maint/screen.git/log/?h=stretch
> >>
> >> The diff as currently committed to git (still at UNRELEASED on
> >> purpose) is following, git I recommend to checkout the git
> >> repository and run the following command instead:
> >>
> >>   git show 360c7cbfbe4dd7f2dac029b371da973731e4c2ad --color-words=.
> >>
> >> It makes clear that all of the commit is only removing the string
> >> "var/" over and over again. Nevertheless here's the classic diff for
> >> the change: […]

Testing a mini.iso netboot image with enabled network-console seems to
lead to good results when building against testing or against sid, so no
objections.


KiBi.


signature.asc
Description: Digital signature

Bug#859689: libntirpc must be linked with libatomic on mips and mipsel

[Adrian Bunk]

Package: libntirpc1.4
Version: 1.4.1-1
Severity: serious
Control: affects -1 src:nfs-ganesha

nfs-ganesha FTBFS on mips and mipsel:

https://buildd.debian.org/status/package.php?p=nfs-ganesha=sid

...
[ 55%] Linking C executable sm_notify.ganesha
cd /«PKGBUILDDIR»/src/obj-mips-linux-gnu/Protocols/NLM && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/sm_notify.ganesha.dir/link.txt --verbose=1
/usr/bin/cc  -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g 
-DNDEBUG  -Wl,-z,relro -Wl,-z,now 
CMakeFiles/sm_notify.ganesha.dir/sm_notify.c.o  -o sm_notify.ganesha 
-Wl,-rpath,/usr/lib/mips-linux-gnu/mit-krb5: -rdynamic ../NFS/libnfsproto.a 
../RQUOTA/librquota.a libnlm.a ../9P/lib9p.a ../XDR/libnfs_mnt_xdr.a -lwbclient 
-lnfsidmap -ldbus-1 -lcap -lblkid -luuid ../../os/libgos.a -ldl 
/usr/lib/mips-linux-gnu/mit-krb5/libkrb5.so 
/usr/lib/mips-linux-gnu/mit-krb5/libk5crypto.so -lcom_err 
/usr/lib/mips-linux-gnu/mit-krb5/libgssapi_krb5.so -lpthread -lrt -lntirpc 
../../support/libstring_utils.a 
/usr/lib/gcc/mips-linux-gnu/6/../../../mips-linux-gnu/libntirpc.so: undefined 
reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status
Protocols/NLM/CMakeFiles/sm_notify.ganesha.dir/build.make:116: recipe for 
target 'Protocols/NLM/sm_notify.ganesha' failed
make[4]: *** [Protocols/NLM/sm_notify.ganesha] Error 1


This is a bug that will hit everyone who wants to use libntirpc
on mips or mipsel:


(stretch_mips-dchroot)bunk@minkus:~$ cat test.c
int main(void)
{
return 0;
}
(stretch_mips-dchroot)bunk@minkus:~$ gcc -O2 -Wall test.c -lntirpc
/usr/lib/gcc/mips-linux-gnu/6/../../../mips-linux-gnu/libntirpc.so: undefined 
reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status
(stretch_mips-dchroot)bunk@minkus:~$ gcc -O2 -Wall test.c -lntirpc -latomic
(stretch_mips-dchroot)bunk@minkus:~$ 

Bug#859310: xserver-xorg-video-nvidia-legacy-304xx: Failed to load module nvidia (module does not exist, 0) No drivers available.

[Luca Boccassi]

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

On Sat, 2017-04-01 at 21:12 -0400, A. F. Cano wrote:
> Package: xserver-xorg-video-nvidia-legacy-304xx
> Version: 304.135-2
> Severity: grave
> Tags: patch
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
> 
> All the components of the nvidia-legacy-304xx drivers (kernel and
> xorg)
> were working fine in jessie.  After an upgrade to stretch, the
> nouveau
> driver was unreliable (video artifacts, lock-ups) as it had been
> before
> in jessie.  I had to manually remove packages, blacklist nouveau,
> install and compile the kernel driver, etc...  After all was done X
> wouldn't start.  These are the relevant lines in Xorg.0.log.old
> before the
> fix below:
> 
> [28.868] (II) LoadModule: "nvidia"
> [28.907] (WW) Warning, couldn't open module nvidia
> [28.907] (II) UnloadModule: "nvidia"
> [28.907] (II) Unloading nvidia
> [28.907] (EE) Failed to load module "nvidia" (module does not
> exist, 0)
> [28.907] (EE) No drivers available.
> [28.907] (EE) Fatal server error:
> [28.907] (EE) no screens found(EE) 
> 
> 
>    * What exactly did you do that was effective?
> 
> It appears that the kernel driver packages and the xorg driver
> packages
> don't agree as to the location of the nvidia_drv.so file.  Creating
> this
> symbolic link fixes the problem.
> 
> ln -s /usr/lib/nvidia/legacy-304xx/nvidia_drv.so
> /usr/lib/xorg/modules/drivers/nvidia_drv.so
> 
>    * What was the outcome of this action?
> 
> The X server started correctly.  After that it was only a matter of
> setting it up with nvidia-settings.
> 
> All the information below was collected by reportbug after the
> symbolic
> link above was set up and the system rebooted.  The Xorg.0.log.old
> (also
> below) reflects the problem and contains the few lines included
> above.
> 
> OpenGL and NVIDIA library files installed:
> -rw-r--r-- 1 afc  afc  1248 Apr  1 16:50 /etc/X11/xorg.conf
> lrwxrwxrwx 1 root root   22 Mar 28 22:30 /etc/alternatives/glx ->
> /usr/lib/mesa-diverted

The problem is that your dpkg alternative is set to use mesa rather
than nvidia to provide glx. That's why the symlink was missing.

You can fix this manually by running:

sudo update-glx --config glx

And by choosing /usr/lib/nvidia at the selection menu.

I see you mention you had to fix things up "manually" when moving from
nouveau to nvidia. I assume that's where things went wrong, as this is
normally done automatically when installing through the nvidia-driver
package.

Do you have a log with the exact steps you've taken after the upgrade?

Kind regards,
Luca Boccassi

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

Bug#852395: unblock: gssproxy/0.5.1-2

[Robbie Harwood]

Niels Thykier  writes:

> NeilBrown:
>> On Sun, Mar 05 2017, Daniel Pocock wrote:
>> 
>> The systemd unit files are designed so that svcgssd will only be
>> started if gssproxy didn't start - and gssproxy is tried first.
>> 
>> If you use something other than systemd, similar logic would be
>> needed.
>
> @Robbie: Can you clarify what happens for people who have chosen to
> use sysvinit as init system?  Will they end up with gssproxy or
> svcgssd or a broken NFS?

I don't totally understand these unit files, so this is probably a
better question for the NFS folk.  But:

The gssproxy package contains a sysvinit script, which works just fine
on my sysvinit system.  (And I assume on systemd systems due to lack of
bug reports :) )

Since nfs-common doesn't provide sysvinit scripts as far as I can tell,
I think you already can't run any of this on them, unless I'm missing
something.

So you'd get gssproxy, and no NFS, but that was already the case.


signature.asc
Description: PGP signature

Bug#859688: libbiod FTBFS on i386: cannot implicitly convert expression (this._stream.position()) of type ulong to uint

[Adrian Bunk]

Source: libbiod
Version: 0.1.0-2
Severity: important

https://buildd.debian.org/status/fetch.php?pkg=libbiod=i386=0.1.0-2=1491407467=0

...
[65/149] ldc2  '-Ibiod@sha' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
'-enable-color' '-O' '-g' '-release' '-relocation-model=pic'  -of 
'biod@sha/bio_sff_readrange.d.o' -c ../bio/sff/readrange.d
FAILED: biod@sha/bio_sff_readrange.d.o 
ldc2  '-Ibiod@sha' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
'-enable-color' '-O' '-g' '-release' '-relocation-model=pic'  -of 
'biod@sha/bio_sff_readrange.d.o' -c ../bio/sff/readrange.d
../bio/sff/readrange.d(72): Error: cannot implicitly convert expression 
(this._stream.position()) of type ulong to uint
[66/149] ldc2  '-Ibiod@sha' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
'-enable-color' '-O' '-g' '-release' '-relocation-model=pic'  -of 
'biod@sha/bio_core_bgzf_virtualoffset.d.o' -c ../bio/core/bgzf/virtualoffset.d
[67/149] ldc2  '-Ibiod@sha' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
'-enable-color' '-O' '-g' '-release' '-relocation-model=pic'  -of 
'biod@sha/bio_core_bgzf_inputstream.d.o' -c ../bio/core/bgzf/inputstream.d
[68/149] ldc2  '-Ibiod@sha' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
'-enable-color' '-O' '-g' '-release' '-relocation-model=pic'  -of 
'biod@sha/bio_core_bgzf_outputstream.d.o' -c ../bio/core/bgzf/outputstream.d
[69/149] ldc2  '-Ibiod_test@exe' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
'-enable-color' '-O' '-g' '-release' '-unittest'  -of 
'biod_test@exe/bio_core_bgzf_outputstream.d.o' -c 
../bio/core/bgzf/outputstream.d
[70/149] ldc2  '-Ibiod_test@exe' '-I.' '-I..' '-I' '-I../' '-I/usr/include/d/' 
'-enable-color' '-O' '-g' '-release' '-unittest'  -of 
'biod_test@exe/bio_core_tinymap.d.o' -c ../bio/core/tinymap.d
ninja: build stopped: subcommand failed.
debian/rules:20: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 1

Bug#859659: lintian: version-substvar-for-external-package raised for dbgsym packages from same source

[Luca Boccassi]

On Wed, 2017-04-05 at 16:21 +, Niels Thykier wrote:
> On Wed, 5 Apr 2017 17:15:20 +0100 Luca Boccassi
>  wrote:
> > Package: lintian
> > Version: 2.5.50.1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > TL;DR: Lintian reports the version-substvar-for-external-package
> > error when the
> > "external package" in question is actually a dbgsym package
> > generated by the
> > same source package.
> > 
> > I maintain a source package, dpdk [1], which builds a great many
> > libraries.
> > Consequently, in stretch, a lot of dbgsym packages are generated.
> > 
> > As a shortcut, a colleague wanted to add an empty metapackage,
> > libdpdk-dbgsym,
> > which depends on all the generated -dbgsym packages. Unfortunately
> > Lintian
> > raises the (unoverridable) error mentioned above due to a line
> > similar to this:
> > 
> > Package: libfoo
> > ...
> > 
> > Package: libbar
> > ...
> > 
> > Package: foobar-dbg-meta
> > Depends: libfoo-dbgsym (= ${binary:Version}), libbar-dbgsym (=
> > ${binary:Version})
> > 
> > Given all the dbgsym packages have predictable names, and are
> > created from
> > packages listed in debian/control (ie: libfoo will be in
> > d/control), could
> > Lintian perhaps recognize this and avoid raising this error?
> > 
> > Thank you!
> > 
> > Kind regards,
> > Luca Boccassi
> > 
> > [1] https://tracker.debian.org/pkg/dpdk
> > 
> > [...]
> 
> Hi Luca,
> 
> Unfortunately, you would just trade one issue for another (at least
> in
> Debian).  The dbgsym packages is going to a separate archive and the
> original packages are therefore not permitted to depend on them (the
> debug archive is optional, dependencies being satisfiable is not).
> 
> That said, I can appreciate this might make sense for third-party
> packages.
> 
> Thanks,
> ~Niels

Hi Niels,

I understand, makes sense.

In our specific case at work, as you correctly guessed, we don't have a
separate archive (build and repository management system is Suse's OBS)
so it does work. Of course being an external use case from Debian I
can't ask for it to be supported, so please feel free to close the bug
if you wish.

Thanks!

Kind regards,
Luca Boccassi

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

Bug#859634: nvidia-driver: 5-8 second freeze

[Luca Boccassi]

On Wed, 2017-04-05 at 08:24 -0400, Xavier Ortiz wrote:
> Package: nvidia-driver
> Version: 375.39-1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
>    * What led up to the situation?
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>    * What was the outcome of this action?
>    * What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> was browsing on chrome, whole system froze for a couple of seconds.
> Spotify in
> the background continued with audio.
> 
> This was the journalctl output.
> 
> Apr 05 08:20:53 DebianDesktop /usr/lib/gdm3/gdm-x-session[1469]: (WW)
> NVIDIA(0): WAIT (2, 8, 0x8000, 0x4bfc, 0x4c04)
> Apr 05 08:20:59 DebianDesktop kernel: NVRM: GPU at PCI::01:00:
> GPU-7005a340-d9d1-0a70-4742-2697dbda6882
> Apr 05 08:20:59 DebianDesktop kernel: NVRM: Xid (PCI::01:00): 8,
> Channel
> 0038
> Apr 05 08:21:00 DebianDesktop /usr/lib/gdm3/gdm-x-session[1469]: (WW)
> NVIDIA(0): WAIT (1, 8, 0x8000, 0x4bfc, 0x4c04)
> Apr 05 08:21:02 DebianDesktop kernel: NVRM: os_schedule: Attempted to
> yield the
> CPU while in atomic or interrupt context
> Apr 05 08:21:04 DebianDesktop /usr/lib/gdm3/gdm-x-session[1469]: (II)
> SYN_DROPPED event from "Microsoft Microsoft® 2.4GHz Transceiver v9.0"
> - some
> input events have been lost.

Hi,

The nvidia kernel module is a binary blob, so there it is most likely
nothing we can do about it.

It was already reported upstream:

https://devtalk.nvidia.com/default/topic/903841/linux/nvrm-os_schedule-
attempted-to-yield-the-cpu-while-in-atomic-or-interrupt-context-/

https://devtalk.nvidia.com/default/topic/912392/-solved-xserver-freezes
-during-gaming-attempted-to-yield-the-cpu-while-in-atomic-or-interrupt-
con/

So I would recommend reporting this to the upstream developers.

Could you please post your logs on one of those threads?

Kind regards,
Luca Boccassi

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

Bug#748808: libapache2-mod-auth-memcookie 2.0 switched to libmemcached and apache 2.4 native support

[Mattia Rizzolo]

On Tue, Apr 04, 2017 at 03:53:20PM +0200, Mathieu CARBONNEAUX wrote:
> Hi,
> Please update libapache2-mod-auth-memcookie to 2.0 version, that support 
> apache 2.4 natively and switched to supported libmemcached (in place of no 
> more maintened libmemcache).
> The 2.0 version maintened now at github her : 
> https://zenprojects.github.io/Apache-Authmemcookie-Module/ 


Thanks for the comment, but that's too late.
Whoever cared enough had years to act on this bug, now the package has
been removed from the archive instead.
If anybody wants to reintroduce it, they are free to do it of course.
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#reintroducing-pkgs

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#859687: freeglut: Package freeglut 3.0

[Tim Dengel]

Source: freeglut
Version: 2.8.1-3
Severity: wishlist

Dear Maintainer,

any chance freeglut 3.0 is getting packaged? It has been released back
in April 2015.


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

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

Bug#859567: retro-gtk and gnome-games-app

[Jeremy Bicha]

On Wed, Apr 5, 2017 at 5:54 PM, Markus Koschany  wrote:
> Thank you for the update. That's much better. I am fine with pulling
> from your Git repository directly but I'm not a member of the pkg-gnome
> team, so you need to take care of all the tagging and committing stuff
> by yourself.

Sure. No problem. Since it's a new package, I'll wait to push a tag
until it is accepted by the ftpmasters.

> I have installed tracker and tracker-gui on my system and it appears to
> be working but still there are no games listed in gnome-games-app. It's
> a bit late here, I need to think this over tomorrow.

You could also ask in #gnome-games on irc.gnome.org

Jeremy

Bug#814238: TECkit source repo has moved

[Bobby de Vos]

Greetings,

  * I notice in this bug that the version of TECkit is mentioned is
2.5.4~svn140+ds2-1. The most recent release of TECkit is 2.5.6,
which is related to the next point.
  * Given that there is a string 'svn' in the version number I am
guessing the TECkit sources are taken from an old location running
SVN, the the new source repo is now on GitHub at
https://github.com/silnrsi/teckit
  * The Debian packaging present in the GitHub repo has a diversion so
TECkit will coexist with TeX Live. I used this packing to upload an
Ubuntu package to SIL's own package repo at http://packages.sil.org/
  * It seems to me that ideally TeX Live can be repackaged to depend on
a TECkit package, thus eliminating the need for a diversion.

-- 
Bobby de Vos
/bobby_de...@sil.org/

Bug#859686: recordmydesktop: man page is really ugly

[G. Branden Robinson]

Package: recordmydesktop
Version: 0.3.8.1+svn602-1+b2
Severity: normal

Whoever wrote recordmydesktop's manual page did not have a good grasp of
*roff markup or the effects of the macros.

I've corrected many problems without rewriting it per se.

1. I brought the manual page into line with the guidance and
   recommendations found in man-pages(7), groff_man(7), groff(7), and
   man(7).
2. I added some information about defaults based on review of the source
   code.
3. I made many English language style corrections and tweaks.

Please find attached:

A. A diff of the stock manpage and my revised one;
B. The full text of my revised one;
C. A PDF of the stock manpage;
D. A PDF of (B).

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, 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 recordmydesktop depends on:
ii  libasound21.1.3-5
ii  libc6 2.24-9
ii  libice6   2:1.0.9-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.10+20150825git1ed50c92~dfsg-5
ii  libogg0   1.3.2-1
ii  libpopt0  1.16-10+b2
ii  libsm62:1.2.2-1+b3
ii  libtheora01.1.1+dfsg.1-14+b1
ii  libvorbis0a   1.3.5-4
ii  libvorbisenc2 1.3.5-4
ii  libvorbisfile31.3.5-4
ii  libx11-6  2:1.6.4-3
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  zlib1g1:1.2.8.dfsg-5

recordmydesktop recommends no packages.

recordmydesktop suggests no packages.

-- no debconf information
--- recordmydesktop.1.orig  2017-04-05 08:59:29.438685068 -0400
+++ recordmydesktop.1   2017-04-05 17:50:33.441926686 -0400
@@ -1,567 +1,643 @@
-.TH "RECORDMYDESKTOP" 1 "13/7/2006" "Linux"
-
-
-.SH NAME
-recordMyDesktop \- record desktop sessions to an Ogg\-Theora\-Vorbis file.
-
-
-.SH SYNOPSIS
-
-.Brecordmydesktop
-[
-.B
-Options
-]^
-.B
-filename
-.br
-.br
-.SH DESCRIPTION
-.PP
-recordMyDesktop produces a file(default out.ogv) that contains a video 
and audio recording
-.br
-of a linux desktop session. The default behavior of recording is to mark areas 
that have changed(through libxdamage)
-.br
-and update the frame. This behavior can be changed (option
-.B
-\-\-full\-shots
-) to produce a more accurate result
-.br
-or capture windows that do not generate events on change(windows with 
accelerated 3d context)
-.br
-but this will notably increase the workload.
-.br
-recordMyDesktop doesn't have a commandline interface.
-.br
-After startup, it can be controled only through the following signals:
-.br
-.br
-.B
-SIGUSR1
-causes the program to pause if it's currently recording, and vice-versa.
-.br
-.B
-SIGTERM
-causes normal termination of the recording.
-.br
-.B
-SIGINT
-also causes normal termination.
-.br
-.B
-SIGABRT
-terminates the program and removes the specified output file.
-.br
-.br
-This signals can also be delivered on the application, with the use of 
-shortcuts.
-.br
-See 
-.B
-\-\-pause\-shortcut
+.TH recordMyDesktop 1 2017-04-05
+.SH Name
+recordMyDesktop \- record desktop sessions to an Ogg Theora video file with \
+Vorbis audio
+.SH Synopsis
+.B recordmydesktop
+.PP
+.B recordmydesktop
+.I output-filename
+.PP
+.B recordmydesktop \-\-rescue
+.I path-to-data
+.PP
+.B recordmydesktop
+.RI { image-options | sound-options | encoding-options | miscellaneous-options 
\
+"| ... }
+.PP
+.B recordmydesktop
+.RB { \-h | \-\-help }
+.PP
+.B recordmydesktop \-\-version
+.PP
+.B recordmydesktop \-\-print\-config
+.SH Description
+.B recordMyDesktop
+produces a file
+.RI ( out.ogv
+by default) containing a video and audio recording of an X Window System
+session.
+.PP
+For a typical scenario, recording your session is as simple as
+.RS
+$
+.B recordmydesktop
+.RE
+which will produce a full-screen recording named
+.I out.ogv
+in the current working directory, while the command
+.RS
+$
+.B recordmydesktop ../foo
+.RE
+will save the recording in
+.I foo.ogv
+in the parent of the current working directory.
+.PP
+To end a recording, press
+.BR Control+C .
+(This action sends a
+.B SIGINT
+to
+.BR recordMyDesktop .)
+.PP
+To designate a region of the screen for recording you can type this:
+.RS
+$
+.B recordmydesktop \-x
+.I x-pos
+.B \-y
+.I y-pos
+.B \-\-width
+.I w
+.B \-\-height
+.I h
+.B \-o foo.ogv
+.RE
+where
+.I x-pos
 and
-.B
-\-\-stop\-shortcut
-, on the 
-.B
-Misc.
-section
-of 
-.B
-Options
-bellow.
-.br
- 
-.br
- 
-.br
- 
-A typical scenario of recording can be a command as simple as:
-.br
-.B
-~$ recordmydesktop
-.br
-which will produce a fullscreen 

Bug#748808: libapache2-mod-auth-memcookie 2.0 switched to libmemcached and apache 2.4 native support

[Mathieu CARBONNEAUX]

Hi,
Please update libapache2-mod-auth-memcookie to 2.0 version, that support apache 
2.4 natively and switched to supported libmemcached (in place of no more 
maintened libmemcache).
The 2.0 version maintened now at github her : 
https://zenprojects.github.io/Apache-Authmemcookie-Module/ ;

Cordialement,Mathieu

Bug#859594: git-buildpackage: Suggested clean command is incorrect

[Gavin Lambert]

At 06:27 p.m. 5/04/2017, Guido Günther wrote:
>> Also, according to
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846016
>> this is no longer valid syntax and needs to be changed to
>> "debuild -- clean".
>
>Having a cleaner by default would force people 
to set up two things

>if they want to switch builders (with the exception of
>--git-pbuilder which does this for you). Since most people use
>either sbuild, pbuilder or --export-dir there's 
no point in running

>"debuild -- clean" or any other builder.

Perhaps just update the manpage then?

And have a bit more info about the recommended 
way to run it?  (Using pbuilder isn't mentioned 
until an appendix in the wiki page.)

Bug#748808: update libapache2-mod-auth-memcookie to v2.0

[Mathieu CARBONNEAUX]

Hi,
I'm author of the apache module, the package need to be updated to support 
correctly apache 2.4 and use of libmemcached il place of the old libmemcache.
the project are now hosted at github : 
https://zenprojects.github.io/Apache-Authmemcookie-Module/ 
Best Regard,Mathieu CARBONNEAUX

Bug#748808: libapache2-mod-auth-memcookie 2.0 switched to libmemcached and apache 2.4 native support

[Mathieu CARBONNEAUX]

Hi,
Please update libapache2-mod-auth-memcookie to 2.0 version, that support apache 
2.4 natively and switched to supported libmemcached (in place of no more 
maintened libmemcache).
The 2.0 version maintened now at github her : 
https://zenprojects.github.io/Apache-Authmemcookie-Module/ ;

Cordialement,Mathieu

Bug#748808: libapache2-mod-auth-memcookie 2.0 switched to libmemcached and apache 2.4 native support

[Mathieu CARBONNEAUX]

Hi,
Please update libapache2-mod-auth-memcookie to 2.0 version, that support apache 
2.4 natively and switched to supported libmemcached (in place of no more 
maintened libmemcache).
The 2.0 version maintened now at github her : 
https://zenprojects.github.io/Apache-Authmemcookie-Module/ 

Cordialement,Mathieu

Bug#748808: libapache2-mod-auth-memcookie 2.0 switched to libmemcached and apache 2.4 native support

[Mathieu CARBONNEAUX]

Package: libapache2-mod-auth-memcookie
Version: 1.0.2-8
Severity: serious 

Hi,

Please update libapache2-mod-auth-memcookie to 2.0 version, that support apache 
2.4 natively and switched to supported libmemcached (in place of no more 
maintened libmemcache).

The 2.0 version maintened now at github her : 
https://zenprojects.github.io/Apache-Authmemcookie-Module/ ;

Cordialement,
Mathieu

Bug#749991: Wrong kernel in debian-installer package

[Cyril Brulebois]

Alexander Sosedkin  (2017-04-05):
> > Added tag(s) stretch-ignore.
> 
> Whatever it means, it sounds very wrong.
> 
> I see you guys like discussing workarounds, but how about, you know,
> actually publishing the correct kernel for netboot in the repo?
> Somebody used to do that, why isn't it the case now?
> 
> http://debian.backend.mirrors.debian.org/debian/dists/stretch/main/installer-amd64/
> 
> Netboot's been broken for weeks, how is that normal? And please, don't
> bring up snapshots.debian.org again. Modules and kernel are in the
> same repository tree, how exactly it happens that keep mismatching?
> Can my virt-install just work, huh?

That's unfortunate, yes, but there's no easy way to keep old packages
around in a given repository. So you've got to wait for a release (and
there won't be one for each and every linux upload), or you've got to
adapt your workflow. Testing is work in progress, and this issue won't
be present in released distributions anyway.


KiBi.


signature.asc
Description: Digital signature

Bug#859576: unblock: osmose-emulator/1.0-3

[Carlos Donizete Froes]

control: tags -1 moreinfo
control: retitle -1 unblock: osmose-emulator/1.0-4

Em qua, 2017-04-05 às 17:04 +, Niels Thykier escreveu:
> Ack, please go ahead and remove the moreinfo tag once it has been
> uploaded + built on all relevant release architectures.

unblock osmose-emulator/1.0-4

Thanks!

-- 
Carlos Donizete Froes [a.k.a coringao]
- https://wiki.debian.org/coringao
GPG: 4096R/B638B780
2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#859567: retro-gtk and gnome-games-app

[Markus Koschany]

Am 05.04.2017 um 22:28 schrieb Jeremy Bicha:
> On Wed, Apr 5, 2017 at 3:44 PM, Markus Koschany  wrote:
>> Please improve the package description a little and write one or two
>> additional sentences and explain what libretro is for.
>>
>> I think "retro-gtk is a library to make libretro frontends that use
>> GTK3." doesn't ring a bell for the uninitiated.
> 
> I will see if I can figure out something longer to silence the lintian
> warning. It's not really supposed to ring bells since no one should be
> installing the library directly. It's a library that is only used by
> gnome-games-app and maintained by the same developer.
> 
> The description I used is basically what I was given:
> https://git.gnome.org/browse/retro-gtk/tree/retro-gtk.doap

[...]

Thank you for the update. That's much better. I am fine with pulling
from your Git repository directly but I'm not a member of the pkg-gnome
team, so you need to take care of all the tagging and committing stuff
by yourself.

>> I have successfully installed gnome-games-app but no games show up. What
>> do I need to do to make my *.desktop file based games from Debian main
>> visible in gnome-games-app?
> 
> Are you using Debian GNOME stretch?

Yes

 Do you have the 'gnome'
> metapackage installed?

No. I installed gnome-core eight years ago and never followed the gnome
metapackage. However I did install the gnome metapackage right now,
rebooted the system but it makes no difference.

> Have you disabled tracker?
> 
> For instance, I have the gnome-games metapackage installed so I have
> 17 games that show up in gnome-games-app.

I have installed tracker and tracker-gui on my system and it appears to
be working but still there are no games listed in gnome-games-app. It's
a bit late here, I need to think this over tomorrow.

Markus





signature.asc
Description: OpenPGP digital signature

Bug#856724: [INTL:da] Danish translation of the template apt-listbugs

[Francesco Poli]

On Sat, 1 Apr 2017 11:06:32 +0200 Morten Bo Johansen  wrote:

> On 2017-03-20 Francesco Poli wrote:
> 
[...]
> >> Is there a specific reason why "severity" is translated with
> >> "alvorlighed" in two sentences, but with "vigtighed" in a third
> >> sentence?
[...]
> 
> Thanks for your interest in the Danish translations.
> 
> I am answering in lieu of Joe.

Thanks.

I apologize for not seeing your reply before, but I am not subscribed
to the debian-l10n-danish mailing list.
Please Cc the bug address <856...@bugs.debian.org>, when you reply to
this thread.

> "Vigtighed" means "importance"
> and "alvorlighed" means gravity/graveness. They are both
> interchangeable in this context.

I see, but since "severity" is used as a technical term, I think it
should be translated with the same Danish word everywhere.

> However, I do not think the
> original term "severity" is very good - does e.g. a "wishlist
> bug" has any "severity" at all

I do think a wishlist bug has indeed a severity.
A somewhat low severity (namely of level "wishlist"), but a severity
anyway.

> and does it make sense to use
> the word "severity" when there is none?

I think it would make sense to use the word "severity" even in a
hypothetical case where there is none. It would be a severity equal to
zero, but it would be definable anyway.

However, as I said above, I don't think that there can be a bug with
zero severity. There exist bugs with low severity ("wishlist"
severity), but no bugs with zero severity.
Or, at least, these are the terms and definitions adopted by the Debian
BTS, and apt-listbugs tries to follow the same nomenclature.

> 
> "Importance" is more neutral and better.

Maybe, but it's not the term adopted by the Debian BTS.

By the way, if set up my web browser to request the [BTS home page] in
Danish, I see the following sentence:

| Gyldige alvorlighedsgrader er critical, grave, serious, important,
| normal, minor, wishlist, fixed.

which is the Danish translation of

| Valid severities are critical, grave, serious, important, normal,
| minor, wishlist, fixed.

[BTS home page]: 

Hence, it seems to me that the Danish translation adopted on the BTS
for "severities" is "alvorlighedsgrader".
We should perhaps use the same translation for apt-listbugs (?).

Please let me know.
Thanks for your time!


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


pgpYvIk5iK3jQ.pgp
Description: PGP signature

Bug#859685: sqlcipher: Enable use of usleep in platforms that support it

[Andre Bianchi]

Source: sqlcipher
Version: 3.2.0-2
Severity: normal

SQLCipher inherits from SQLite a compile time option called HAVE_USLEEP
that enables the use of the usleep() system call. If it is not set,
sqlite3_sleep() will have a minimum wait interval of 1 second,
regardless of its argument (see: https://sqlite.org/compile.html).

In the case of concurrent access to a database, the internal sqlcipher
retry strategy is affected. Instead of sleeping for something between 1
and 100 milliseconds, sqlcipher will always sleep for one whole second
before trying to gain write access again. This is a waste of resources
as threads might be sleeping much more than needed, and also affects
applications in which the configured timeout is less than one second.
Also, retry strategies implemented on top of sqlcipher are more
difficult to succeed and be tuned.

To fix this, the HAVE_USLEEP compile time option has to be enabled for
the platforms that support it.

Bug#859684: nvidia-legacy-304xx-kernel-dkms: xserver-xorg-video-nvidia-legacy-304xx not installed

[Bill Hassard]

Package: nvidia-legacy-304xx-kernel-dkms
Version: 304.134-0~deb8u1
Severity: normal

Dear Maintainer,

I installed nvidia-legacy-304xx-kernel-dkms on a new Jessie install following
the procedure in the NvidiaGraphicsDriver wiki. The required xsever-xorg-video-
nvidia-legacy-304xx package was not installed and video did not function. lsmod
showed the driver loaded with Used by 0. After manually installing the xserver-
xorg-video-nvidia-304xx package everthing works as it should.



-- Package-specific info:
uname -a:
Linux ann1 3.16.0-4-686-pae #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) i686 
GNU/Linux

/proc/version:
Linux version 3.16.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86 Kernel Module  304.134  Fri Dec  9 11:47:15 PST 
2016
GCC version:  gcc version 4.8.4 (Debian 4.8.4-1) 

lspci 'VGA compatible controller [0300]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G71 [GeForce 7900 
GT/GTO] [10de:0291] (rev a1) (prog-if 00 [VGA controller])
Subsystem: eVga.com. Corp. Device [3842:c565]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia

dmesg:
[0.00] Console: colour VGA+ 80x25
[0.112713] vgaarb: setting as boot device: PCI::01:00.0
[0.112713] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.112713] vgaarb: loaded
[0.112713] vgaarb: bridge control possible :01:00.0
[0.787064] Linux agpgart interface v0.103
[5.811377] nvidia: module license 'NVIDIA' taints kernel.
[5.825901] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none
[5.826138] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[5.826145] NVRM: loading NVIDIA UNIX x86 Kernel Module  304.134  Fri Dec  9 
11:47:15 PST 2016

Device node permissions:
crw-rw+ 1 root video 226,   0 Apr  5 11:59 /dev/dri/card0
crw-rw  1 root video 195,   0 Apr  5 11:59 /dev/nvidia0
crw-rw  1 root video 195, 255 Apr  5 11:59 /dev/nvidiactl
video:x:44:ann

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Apr  1 23:16 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   49 Apr  1 23:16 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   41 Apr  1 23:16 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Apr  1 23:16 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   49 Apr  1 23:16 
/etc/alternatives/glx--libXvMCNVIDIA.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA.so.1
lrwxrwxrwx 1 root root   57 Apr  1 23:16 
/etc/alternatives/glx--libXvMCNVIDIA_dynamic.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA_dynamic.so.1
lrwxrwxrwx 1 root root   49 Apr  1 23:16 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Apr  1 23:16 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Apr  1 23:16 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   29 Apr  1 23:16 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   28 Apr  1 23:16 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/legacy-304xx
lrwxrwxrwx 1 root root   54 Apr  1 23:16 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/legacy-304xx/libGL.so.1
lrwxrwxrwx 1 root root   54 Apr  1 23:16 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/legacy-304xx/libGL.so.1
lrwxrwxrwx 1 root root   62 Apr  1 23:16 
/etc/alternatives/nvidia--libXvMCNVIDIA.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/legacy-304xx/libXvMCNVIDIA.so.1
lrwxrwxrwx 1 root root   70 Apr  1 23:16 
/etc/alternatives/nvidia--libXvMCNVIDIA_dynamic.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/legacy-304xx/libXvMCNVIDIA_dynamic.so.1
lrwxrwxrwx 1 root root   38 Apr  1 23:16 
/etc/alternatives/nvidia--libglx.so -> /usr/lib/nvidia/legacy-304xx/libglx.so
lrwxrwxrwx 1 root root   62 Apr  1 23:16 
/etc/alternatives/nvidia--libnvidia-cfg.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/legacy-304xx/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   43 Apr  1 23:16 
/etc/alternatives/nvidia--nv-control-dpy -> 
/usr/lib/nvidia/legacy-304xx/nv-control-dpy
lrwxrwxrwx 1 root root   45 Apr  1 

Bug#859682: RM: openssh-blacklist -- RoQA; obsolete

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove openssh-blacklist, it's been almost a decade since that openssl 
bug
and openssh already stopped depending/recommending the blacklist.

(Also acked by Kees)

Cheers,
Moritz

Bug#859683: RM: openvpn-blacklist -- RoQA; obsolete

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove openvpn-blacklist, it's been almost a decade since that openssl 
bug
and openvpn already stopped depending/recommending the blacklist.

(Also acked by Kees)

Cheers,
Moritz
 

Bug#859679: Acknowledgement (heaptrack: frontends miss dependencies on libheaptrack)

[IOhannes m zmoelnig]

On 04/05/2017 10:22 PM, IOhannes m zmoelnig wrote:
> but even in this case, a "Recommends" would be the appropriate
> relationship

to be clear, i think the relationships should be
 heaptrack Depends: libheaptrack
 heaptrack_gui Enhances: heaptrack
or at least
 heaptrack Recommends: libheaptrack

gfmsadr
IOhannes




signature.asc
Description: OpenPGP digital signature

Bug#859681: TechnoTrend_AG_TT-USB_Infrared_Device not working

[karl156]

Package: linux-image-4.9.0-2-armmp
Version: 4.9.13-1
Severity: wishlist
Tags: stretch sid

Hi, this is probably the wrong place to report this bug but since I do
not know a better place I will report it here and hope someone could get
a patch upstream.

I have a Technotrend USB Infrared Remote Control which is not working.
http://technotrend.eu/2724/USB_Infrarot-Empfaenger.html

Other remote controls I have tried worked out-of-the-box, but this one
unfortunately does not.

It looks like the mapping of the scancodes to the keycodes is missing.


proposed mapping:
>  Event code 2 (KEY_1) 1043
>  Event code 3 (KEY_2) 1044
>  Event code 4 (KEY_3) 1045
>  Event code 5 (KEY_4) 1046
>  Event code 6 (KEY_5) 1047
>  Event code 7 (KEY_6) 1048
>  Event code 8 (KEY_7) 1049
>  Event code 9 (KEY_8) 104a
>  Event code 10 (KEY_9) 104b
>  Event code 11 (KEY_0) 104c
>  Event code 103 (KEY_UP) 104d
>  Event code 105 (KEY_LEFT) 1050
>  Event code 106 (KEY_RIGHT) 1041
>  Event code 108 (KEY_DOWN) 1051
>  Event code 113 (KEY_MUTE) 1058
>  Event code 114 (KEY_VOLUMEDOWN) 1066
>  Event code 115 (KEY_VOLUMEUP) 1065
>  Event code 116 (KEY_POWER) 1041
>  Event code 119 (KEY_PAUSE) 107e
>  Event code 128 (KEY_STOP) 107c -- play/pause
>  Event code 141 (KEY_SETUP)  -- missing
>  Event code 159 (KEY_FORWARD) 107f
>  Event code 167 (KEY_RECORD) 107a
>  Event code 168 (KEY_REWIND) 107d
>  Event code 174 (KEY_EXIT) 1053
>  Event code 207 (KEY_PLAY) 107b
>  Event code 352 (KEY_OK) 104f
>  Event code 357 (KEY_OPTION) 1042 -- channel
>  Event code 358 (KEY_INFO) 1052
>  Event code 365 (KEY_EPG) 1062
>  Event code 373 (KEY_MODE) 105a -- tv/radio
>  Event code 388 (KEY_TEXT) 1059
>  Event code 398 (KEY_RED) 1054
>  Event code 399 (KEY_GREEN) 1055
>  Event code 400 (KEY_YELLOW) 1056
>  Event code 401 (KEY_BLUE) 1057
>  Event code 402 (KEY_CHANNELUP) 1063
>  Event code 403 (KEY_CHANNELDOWN) 1064
>  Event code 410 (KEY_SHUFFLE)


> # udevadm info /dev/input/by-id/*
> P: 
> /devices/platform/soc/3f98.usb/usb1/1-1/1-1.4/1-1.4:1.0/rc/rc0/input0/event0
> N: input/event0
> S: input/by-id/usb-TechnoTrend_AG_TT-USB_Infrared_Device-event-ir
> S: input/by-path/platform-3f98.usb-usb-0:1.4:1.0-event-ir
> E: 
> DEVLINKS=/dev/input/by-id/usb-TechnoTrend_AG_TT-USB_Infrared_Device-event-ir 
> /dev/input/by-path/platform-3f98.usb-usb-0:1.4:1.0-event-ir
> E: DEVNAME=/dev/input/event0
> E: 
> DEVPATH=/devices/platform/soc/3f98.usb/usb1/1-1/1-1.4/1-1.4:1.0/rc/rc0/input0/event0
> E: ID_BUS=usb
> E: ID_INPUT=1
> E: ID_INPUT_KEY=1
> E: ID_MODEL=TT-USB_Infrared_Device
> E: ID_MODEL_ENC=TT-USB\x20Infrared\x20Device
> E: ID_MODEL_ID=2003
> E: ID_PATH=platform-3f98.usb-usb-0:1.4:1.0
> E: ID_PATH_TAG=platform-3f98_usb-usb-0_1_4_1_0
> E: ID_REVISION=0101
> E: ID_SERIAL=TechnoTrend_AG_TT-USB_Infrared_Device
> E: ID_TYPE=generic
> E: ID_USB_DRIVER=ttusbir
> E: ID_USB_INTERFACES=:00:
> E: ID_USB_INTERFACE_NUM=00
> E: ID_VENDOR=TechnoTrend_AG
> E: ID_VENDOR_ENC=TechnoTrend\x20AG
> E: ID_VENDOR_ID=0b48
> E: MAJOR=13
> E: MINOR=64
> E: SUBSYSTEM=input
> E: USEC_INITIALIZED=7868779

I always annotated the button I will press and then pressed it one time
> # evtest
> No device specified, trying to scan all of /dev/input/event*
> Available devices:
> /dev/input/event0:  TechnoTrend USB IR Receiver
> /dev/input/event1:  MCE IR Keyboard/Mouse (ttusbir)
> Select the device event number [0-1]: 0
> Input driver version is 1.0.1
> Input device ID: bus 0x3 vendor 0xb48 product 0x2003 version 0x101
> Input device name: "TechnoTrend USB IR Receiver"
> Supported events:
>   Event type 0 (EV_SYN)
>   Event type 1 (EV_KEY)
> Event code 2 (KEY_1)
> Event code 3 (KEY_2)
> Event code 4 (KEY_3)
> Event code 5 (KEY_4)
> Event code 6 (KEY_5)
> Event code 7 (KEY_6)
> Event code 8 (KEY_7)
> Event code 9 (KEY_8)
> Event code 10 (KEY_9)
> Event code 11 (KEY_0)
> Event code 103 (KEY_UP)
> Event code 105 (KEY_LEFT)
> Event code 106 (KEY_RIGHT)
> Event code 108 (KEY_DOWN)
> Event code 113 (KEY_MUTE)
> Event code 114 (KEY_VOLUMEDOWN)
> Event code 115 (KEY_VOLUMEUP)
> Event code 116 (KEY_POWER)
> Event code 119 (KEY_PAUSE)
> Event code 128 (KEY_STOP)
> Event code 141 (KEY_SETUP)
> Event code 159 (KEY_FORWARD)
> Event code 167 (KEY_RECORD)
> Event code 168 (KEY_REWIND)
> Event code 174 (KEY_EXIT)
> Event code 207 (KEY_PLAY)
> Event code 352 (KEY_OK)
> Event code 357 (KEY_OPTION)
> Event code 358 (KEY_INFO)
> Event code 365 (KEY_EPG)
> Event code 373 (KEY_MODE)
> Event code 388 (KEY_TEXT)
> Event code 398 (KEY_RED)
> Event code 399 (KEY_GREEN)
> Event code 400 (KEY_YELLOW)
> Event code 401 (KEY_BLUE)
> Event code 402 (KEY_CHANNELUP)
> Event code 403 (KEY_CHANNELDOWN)
> Event code 410 (KEY_SHUFFLE)
>   Event type 4 (EV_MSC)
> Event code 4 (MSC_SCAN)
> Key repeat handling:
>   Repeat type 20 (EV_REP)
> Repeat 

Bug#859680: apt-cacher-ng: SPfilePatternEx not shown / avail

[Bernd Roth]

Package: apt-cacher-ng
Version: 0.8.0-3
Severity: normal

Dear Maintainer,

i'm a newbie in bug reporting, encountering issues while trying to
enable FreeBSD repo support.

Version apt-cacher-ng/stable,now 0.8.0-3 amd64

I did:
apt-cacher-ng -p debug=1 | grep filePatt

output:

VfilePattern = (^|.*/)(Index|Packages [...]
PfilePattern = .*(\.d?deb|\.rpm|\.drpm [...]
SPfilePattern = (^|.*/).*(\.d?deb|\.rpm [...]
WfilePattern = (^|.*/)(Release|InRelease [...]
VfilePatternEx =
PfilePatternEx =
WfilePatternEx =
SPfilePattern =

end of output.

Multible bugs may apply.

First, the output doesn't show SPfilePatternEx
(or it does show but the label is not correct?).

Second, whatever i set any of the *Ex pattern, nothing is accepted.
At first i thought i did syntax errors. Later i found that no keyword
change is accepted by the -p debug= line but the running apt-cacher-ng does?

While doc/README.gz and README.Debian talking about /etc/apt-cacher-ng/ as
the "default" configuration directory, it is not default 
for "apt-cacher-ng -p debug=1". I didn't test which config is shown.

The initd script for acng includes the -c /etc/apt-cacher-ng config dir.
If i do "apt-cacher-ng -c /etc/apt-cacher-ng -p debug=1" the output reacts
to changes of port and bindaddress,
but not for "SPfilePatternEx: ForTestingOnly*",

output:
Warning, unknown configuration directive: SPfilePatternEx
Error reading main options, terminating.

end of output.

To use the -c parameter to get the actual configuration from the default
directory did confuse me. It may make sense for the config example becaue
it refers to "get a syntax example". If a config was misconfigured with
wrong settings it does not make sense to show this wrongs as a reference
to a valid syntax.

Additional note: I tried testing and unstable acng version 2-1 and 3-1 and
noticed that the config is dumped now with acngtool. But the config comments 
still refer to the -p debug method.
I would like to ask kindly for a hint in the config to the new tool.

Very best regards

Bernd Roth



-- Package-specific info:

-- System Information:
Debian Release: 8.7
  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=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 apt-cacher-ng depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.27
ii  init-system-helpers1.22
ii  libbz2-1.0 1.0.6-7+b3
ii  libc6  2.19-18+deb8u7
ii  libgcc11:4.9.2-10
ii  liblzma5   5.1.1alpha+20120614-2+b3
ii  libssl1.0.01.0.1t-1+deb8u6
ii  libstdc++6 4.9.2-10
ii  libsystemd0215-17+deb8u6
ii  libwrap0   7.6.q-25
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages apt-cacher-ng recommends:
pn  ed  

Versions of packages apt-cacher-ng suggests:
pn  avahi-daemon  
ii  curl  7.38.0-4+deb8u5
pn  doc-base  
ii  libfuse2  2.9.3-15+deb8u2
ii  wget  1.16-1+deb8u1

-- Configuration Files:
/etc/apt-cacher-ng/acng.conf changed [not included]

-- debconf information:
  apt-cacher-ng/port: keep
  apt-cacher-ng/bindaddress: keep
  apt-cacher-ng/cachedir: keep
  apt-cacher-ng/gentargetmode: No automated setup
  apt-cacher-ng/proxy: keep

Bug#859567: retro-gtk and gnome-games-app

[Jeremy Bicha]

On Wed, Apr 5, 2017 at 3:44 PM, Markus Koschany  wrote:
> Please improve the package description a little and write one or two
> additional sentences and explain what libretro is for.

How this?

https://anonscm.debian.org/git/pkg-gnome/retro-gtk.git/tree/debian/control.in

Are you ok with sponsoring from the git repos or do you want me to
push an update to the mentors site?

Thanks,
Jeremy

Bug#858635: unblock (pre-approval): dbus/1.10.18-1 with #857660 fixed

[Simon McVittie]

On Wed, 05 Apr 2017 at 13:23:00 +, Niels Thykier wrote:
> I am fine with it including it in stretch (at least assuming it is done
> prior to the stretch release).

Here's an updated debdiff. An upstream bug reported an invalid memory
access in one of the tests, and the fix seemed low-risk (it only
touches test code), so I added that in; I hope that's OK. I can revert
it if you really want me to.

This is now on its way through unstable.

(The added .gitignore is because dbus/1.10.16-1 was built with different
gbp-buildpackage settings, and doesn't affect binary packages at all.)

S
diffstat for dbus-1.10.16 dbus-1.10.18

 Makefile.in   |2 +-
 NEWS  |   16 +++-
 bus/bus.c |   40 ++--
 configure |   26 +-
 configure.ac  |4 ++--
 debian/.gitignore |   22 ++
 debian/changelog  |   11 +++
 test/corrupt.c|   11 +++
 8 files changed, 97 insertions(+), 35 deletions(-)

diff -Nru dbus-1.10.16/bus/bus.c dbus-1.10.18/bus/bus.c
--- dbus-1.10.16/bus/bus.c	2015-09-30 15:48:40.0 +0100
+++ dbus-1.10.18/bus/bus.c	2017-03-22 09:32:31.0 +
@@ -931,6 +931,27 @@
   !_dbus_pipe_is_stdout_or_stderr (print_pid_pipe))
 _dbus_pipe_close (print_pid_pipe, NULL);
 
+  /* Here we change our credentials if required,
+   * as soon as we've set up our sockets and pidfile.
+   * This must be done before initializing LSMs, so that the netlink
+   * monitoring thread started by avc_init() will not lose CAP_AUDIT_WRITE
+   * when the main thread calls setuid().
+   * https://bugs.freedesktop.org/show_bug.cgi?id=92832
+   */
+  if (context->user != NULL)
+{
+  if (!_dbus_change_to_daemon_user (context->user, error))
+	{
+	  _DBUS_ASSERT_ERROR_IS_SET (error);
+	  goto failed;
+	}
+}
+
+  /* Auditing should be initialized before LSMs, so that the LSMs are able
+   * to log audit-events that happen during their initialization.
+   */
+  bus_audit_init (context);
+
   if (!bus_selinux_full_init ())
 {
   bus_context_log (context, DBUS_SYSTEM_LOG_FATAL, "SELinux enabled but D-Bus initialization failed; check system log\n");
@@ -950,6 +971,11 @@
  "AppArmor D-Bus mediation is enabled\n");
 }
 
+  /* When SELinux is used, this must happen after bus_selinux_full_init()
+   * so that it has access to the access vector cache, which is required
+   * to process  elements.
+   * http://lists.freedesktop.org/archives/dbus/2008-October/010491.html
+   */
   if (!process_config_postinit (context, parser, error))
 {
   _DBUS_ASSERT_ERROR_IS_SET (error);
@@ -962,20 +988,6 @@
   parser = NULL;
 }
 
-  /* Here we change our credentials if required,
-   * as soon as we've set up our sockets and pidfile
-   */
-  if (context->user != NULL)
-{
-  if (!_dbus_change_to_daemon_user (context->user, error))
-	{
-	  _DBUS_ASSERT_ERROR_IS_SET (error);
-	  goto failed;
-	}
-}
-
-  bus_audit_init (context);
-
   dbus_server_free_data_slot (_data_slot);
 
   return context;
diff -Nru dbus-1.10.16/configure dbus-1.10.18/configure
--- dbus-1.10.16/configure	2017-02-16 13:47:19.0 +
+++ dbus-1.10.18/configure	2017-04-05 16:25:13.0 +0100
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for dbus 1.10.16.
+# Generated by GNU Autoconf 2.69 for dbus 1.10.18.
 #
 # Report bugs to .
 #
@@ -591,8 +591,8 @@
 # Identity of this package.
 PACKAGE_NAME='dbus'
 PACKAGE_TARNAME='dbus'
-PACKAGE_VERSION='1.10.16'
-PACKAGE_STRING='dbus 1.10.16'
+PACKAGE_VERSION='1.10.18'
+PACKAGE_STRING='dbus 1.10.18'
 PACKAGE_BUGREPORT='https://bugs.freedesktop.org/enter_bug.cgi?product=dbus'
 PACKAGE_URL=''
 
@@ -1553,7 +1553,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures dbus 1.10.16 to adapt to many kinds of systems.
+\`configure' configures dbus 1.10.18 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1628,7 +1628,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of dbus 1.10.16:";;
+ short | recursive ) echo "Configuration of dbus 1.10.18:";;
esac
   cat <<\_ACEOF
 
@@ -1841,7 +1841,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-dbus configure 1.10.16
+dbus configure 1.10.18
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2617,7 +2617,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by dbus $as_me 1.10.16, which was
+It was created by dbus $as_me 1.10.18, which 

Bug#859567: retro-gtk and gnome-games-app

[Jeremy Bicha]

On Wed, Apr 5, 2017 at 3:44 PM, Markus Koschany  wrote:
> Please improve the package description a little and write one or two
> additional sentences and explain what libretro is for.
>
> I think "retro-gtk is a library to make libretro frontends that use
> GTK3." doesn't ring a bell for the uninitiated.

I will see if I can figure out something longer to silence the lintian
warning. It's not really supposed to ring bells since no one should be
installing the library directly. It's a library that is only used by
gnome-games-app and maintained by the same developer.

The description I used is basically what I was given:
https://git.gnome.org/browse/retro-gtk/tree/retro-gtk.doap

It's a bit confusing because libretro is the name of a bigger and
older project to make game emulators and developer platforms.
libretro-gtk is this library that is basically a separate library that
I guess connects libretro with an app like gnome-games-app. There are
a lot of libretro cores packaged in Debian already but they need a
little integration work to be usable by gnome-games-app.

https://www.libretro.com/

> I have successfully installed gnome-games-app but no games show up. What
> do I need to do to make my *.desktop file based games from Debian main
> visible in gnome-games-app?

Are you using Debian GNOME stretch? Do you have the 'gnome'
metapackage installed?

Have you disabled tracker?

For instance, I have the gnome-games metapackage installed so I have
17 games that show up in gnome-games-app.

Jeremy

Bug#755911: Python3 version

[Ghislain Vaillant]

On Thu, 23 Feb 2017 15:23:38 -0800 Diane Trout  wrote:

I updated the package to use upstream version 0.10.5, pybuild and build
a python3 version. (0.10.2 had an error)

Attached are the changes I made (minus the patch importing the new
version from upstream).

I can push the changes to alioth and make a new release, but I don't
like changing packages I'm not normally responsible for with out some
acknowledgement.


Since you are part of DPMT, and this package is effectively placed under 
team-maintenance, you are welcome to push these changes to the packaging 
repository and make a new release.


Please keep in mind that since we are in freeze, these changes should be 
made on a separate debian/experimental branch and pushed to the 
experimental channel of Debian.


Cheers,
Ghis

Bug#859667: [Pkg-d-devel] Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail

[Iain Buclaw]

Which compiler?  Are NaNs being honoured? What if you were to replace
the `(x != x && f != f)` comparison with `(isNaN(x) && isNaN(f))` ?

On 5 April 2017 at 22:00, Andreas Tille  wrote:
> Hi,
>
> I admit I'm totally clueless and thus I'm asking D language team as well as
> porters for help.
>
> Thanks for any helpful hint
>
>   Andreas.
>
> On Wed, Apr 05, 2017 at 02:43:04PM -0400, Aaron M. Ucko wrote:
>> Source: libundead
>> Version: 1.0.6-1
>> Severity: important
>> Justification: fails to build from source
>>
>> The libundead builds for armhf and ppc64 both failed with test suite
>> errors.  On armf, I see no specific indication of what went wrong, but
>> presume it should be possible to reproduce the problem on a porterbox.
>> On ppc64el, the log reports an assertion failure at
>> https://anonscm.debian.org/cgit/debian-med/libundead.git/tree/src/undead/stream.d#n1458:
>>
>>   core.exception.AssertError@../src/undead/stream.d(1458): Assertion failure
>>
>> Could you please take a look?
>>
>> 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
>>
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>>
>
> --
> http://fam-tille.de
>
> ___
> Pkg-d-devel mailing list
> pkg-d-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-d-devel

Bug#859679: heaptrack: frontends miss dependencies on libheaptrack

[IOhannes m zmoelnig]

Source: heaptrack
Version: 1.0.0-1
Severity: important

Dear Maintainer,

it seems that the 'heaptrack' binary package (and 'heaptrack-gui' as well)
misses a dependency on libheaptrack.
both have no automatic dependency on the library, because they are not directly
using it (so dpkg-shlibdeps misses the dep). instead the main purpose f the
binaries provided by both packages is to inject libheaptrack into a target
binary (by use of LD_PRELOAD).
however, for this to work libheaptrack *must* be installed.

you might insist that a strict dependency ("Depends") is not necessary, and that
there are usecases for having heaptrack(-gui) installed without libheaptrack.
but even in this case, a "Recommends" would be the appropriate relationship (see
policy §7.2: "The Recommends field should list packages that would be found
together with this one in all but unusual installations").


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- no debconf information

Bug#859678: ITP: registration-agent -- standalone SIP registration utility

[Daniel Pocock]

Package: wnpp
Severity: wishlist
Owner: dan...@pocock.pro

https://github.com/resiprocate/registration-agent

License: BSD-3

Daemon process that sends SIP REGISTER requests, allowing the user to
specify an arbitrary Contact header where incoming calls will be directed.

This is useful for people who want to send a REGISTER request to their
ITSP telling it to send calls to their SIP proxy instead of a phone or
Asterisk server.

Bug#839010: bug still there in jessie (mips)

[James Cowgill]

Hi,

On 05/04/17 20:31, Steve Arnold wrote:
> This is still a problem for mips/mipsel but stretch has the
> upstream fixes.  Can you please add the stretch bind9 packages to
> jessie-backports?  I'm building it now on edgerouter (albeit
> slowly) but a lot of other people running on this hardware could
> benefit from the fixes.
> 
> Thanks in advance...

This bug should already be fixed in jessie. Do you have the latest
version from jessie-security (1:9.9.5.dfsg-9+deb8u10)?

James




signature.asc
Description: OpenPGP digital signature

Bug#858767: gscan2pdf: fixes & improvements to gscan2pdf

[Jeff]

Hi Peter,

Thanks for your patches. I have committed everything up to "Canvas.pm:
fix box offsets & text rotation" and pushed the commits, plus some of my
own to the repo on Sourceforge.

At the moment, there are no unit tests for Gscan2pdf::Canvas, and as
prefer to work test-driven, I would like a test which would fail without
this patch.

I am not 100% sure what problem your patch fixes, so would you mind
constructing such a unit test? I would then have no problem committing
the patch.

The unit test would probably have to defined a page with some boxes
before calling Gscan2pdf::Canvas->new() followed by canvas2hocr() and
check the hocr output.

Whilst you are at it, Gscan2pdf::Canvas has quite a few
ProhibitMagicNumbers Perl::Critic overrides. If you know what the
numbers mean, I would appreciate a patch replacing the numbers with
descriptive Readonly variables.

Thanks for your efforts

Regards

Jeff





signature.asc
Description: OpenPGP digital signature

Bug#859677: Request to add cloud-init dependency for 'open-vm-tools'

[Sankar Tanguturi]

Package: open-vm-tools
Version: 2:10.1.0-4449150-4


Hi,


This is Sankar from VMware. I work in a team that manages 'open-vm-tools'. 
Would like to request to add 'cloud-init' dependency for 'open-vm-tools' 
service. I have logged a bug in launchpad and you can check it out at 
https://bugs.launchpad.net/cloud-init/+bug/1667831 for more details.


We need to start 'open-vm-tools' service before 'cloud-init' service starts. 
Following is a patch to be added in 'unit' section for 'open-vm-tools' service 
file.


DefaultDependencies=no
Before=cloud-init-local.service


Here is the total content of 'open-vm-tools.service' file

"""
[Unit]
Description=Service for virtual machines hosted on VMware
Documentation=http://open-vm-tools.sourceforge.net/about.php

ConditionVirtualization=vmware
DefaultDependencies=no
Before=cloud-init-local.service

[Service]
ExecStart=/usr/bin/vmtoolsd
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target
"""


Please do let me know if any other information is required.


Thanks

Sankar

Bug#859676: should install uftpd under /usr/bin since runs on non-privileged port

[Yaroslav Halchenko]

Package: uftp
Version: 4.9.3-1
Severity: wishlist

Probably also to be advised upstream:  since uftpd runs by default on
non-privileged (1044) port, thus could be ran/used by any user, there is no
really reason to keep it under /usr/sbin/ instead of /usr/bin/.

Somewhat relates to #859505 in the effort to make it usable by regular users
and not as a "system service"

Cheers and thanks!

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages uftp depends on:
ii  debconf [debconf-2.0]  1.5.60
ii  libc6  2.24-9
ii  libssl1.1  1.1.0d-2

uftp recommends no packages.

uftp suggests no packages.

-- debconf-show failed

Bug#854554: dpkg: trigger problem with cracklib-runtime while upgrading libcrypt-cracklib-perl from jessie to stretch

[Andreas Beckmann]

On 2017-04-02 01:37, Guillem Jover wrote:
> My expectation is that after the reported state is found on piuparts,
> running:
> 
>   $ dpkg --configure --pending
> 
> or even something like:
> 
>   $ dpkg --configure cracklib-runtime libcrack2
> 
> would let dpkg configure that package correctly w/o complaining about
> the unsatisfiable dependency. Andreas, is that indeed the case? If it
> is then this needs to be reassigned to apt.

OK, let's try that in the chroot after the failure occurred:

# # just verify that the problem is still there
# dpkg --configure cracklib-runtime
dpkg: dependency problems prevent processing triggers for cracklib-runtime:
 cracklib-runtime depends on libcrack2 (>= 2.9.2-1); however:
  Package libcrack2:i386 is not configured yet.

dpkg: error processing package cracklib-runtime (--configure):
 dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
 cracklib-runtime

# dpkg --configure cracklib-runtime libcrack2
Setting up libcrack2:i386 (2.9.2-3+b1) ...
Processing triggers for cracklib-runtime (2.9.2-1) ...
Processing triggers for libc-bin (2.24-9) ...

# dpkg --configure --pending
Setting up perl-modules-5.24 (5.24.1-2) ...
Setting up libgdbm3:i386 (1.8.3-14) ...
Setting up libperl5.24:i386 (5.24.1-2) ...
Setting up bash (4.4-4+b1) ...
[...]


So the fault is in apt ... and that's jessie's version of apt that is
running the upgrade :-(

If I start the upgrade with upgrading only apt (and its dependencies)
and thereafter running the dist-upgrade (with squeeze's version of apt),
I cannot reproduce the bug.


Andreas

Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail

[Andreas Tille]

Hi,

I admit I'm totally clueless and thus I'm asking D language team as well as
porters for help.

Thanks for any helpful hint

  Andreas.

On Wed, Apr 05, 2017 at 02:43:04PM -0400, Aaron M. Ucko wrote:
> Source: libundead
> Version: 1.0.6-1
> Severity: important
> Justification: fails to build from source
> 
> The libundead builds for armhf and ppc64 both failed with test suite
> errors.  On armf, I see no specific indication of what went wrong, but
> presume it should be possible to reproduce the problem on a porterbox.
> On ppc64el, the log reports an assertion failure at
> https://anonscm.debian.org/cgit/debian-med/libundead.git/tree/src/undead/stream.d#n1458:
> 
>   core.exception.AssertError@../src/undead/stream.d(1458): Assertion failure
> 
> Could you please take a look?
> 
> 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
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#859675: radsecproxy: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: radsecproxy
Version: 1.6.7-1
Severity: important
Tags: sid buster fixed-upstream
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans
control: forwarded -1 https://project.nordu.net/browse/RADSECPROXY-66

Please migrate to libssl-dev in the Buster cycle. The bug report about
the FTBFS is #828527. The log of the FTBFS can be found at

https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/radsecproxy_1.6.7-1_amd64-20160529-1530

Sebastian

Bug#859674: qupzilla: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: qupzilla
Version: 1.8.9~dfsg1-3
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle. The bug report about
the FTBFS is #828525. The log of the FTBFS can be found at

https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/qupzilla_1.8.9~dfsg1-3_amd64-20160529-1527

Sebastian

Bug#859673: qtwebsockets-opensource-src: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: qtwebsockets-opensource-src
Version: 5.7.1~20161021-4
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle.

Sebastian

Bug#859671: qtbase-opensource-src: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: qtbase-opensource-src
Version: 5.7.1~20161021+dfsg-5
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle.

Sebastian

Bug#859670: totem does not start due to a GDK error

[Soramichi AKIYAMA]

Package: totem
Version: 3.22.1-1
Severity: important
Tags: stretch

Dear Maintainer,

when totem is invoked, it yields a GDK error and crashes immediately.

It also says something about libGL but I don't think they are relevant to this 
crash
because they also happen for VLC as well, which looks working correctly.

The error message is as follows:

$ totem
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

(totem:6090): Gdk-ERROR **: The program 'totem' received an X Window System 
error.
This probably reflects a bug in the program.
The error was 'GLXBadContext'.
  (Details: serial 211 error_code 169 request_code 154 (GLX) minor_code 6)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap


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

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

Versions of packages totem depends on:
ii  grilo-plugins-0.3   0.3.3-1
ii  gsettings-desktop-schemas   3.22.0-1
ii  gstreamer1.0-clutter-3.03.0.22-1
ii  gstreamer1.0-plugins-bad1.10.4-1
ii  gstreamer1.0-plugins-base   1.10.4-1
ii  gstreamer1.0-plugins-good   1.10.4-1
ii  gstreamer1.0-x  1.10.4-1
ii  libc6   2.24-9
ii  libcairo2   1.14.8-1
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libglib2.0-02.50.3-2
ii  libgstreamer-plugins-base1.0-0  1.10.4-1
ii  libgstreamer1.0-0   1.10.4-1
ii  libgtk-3-0  3.22.11-1
ii  libnautilus-extension1a 3.22.3-1
ii  libpango-1.0-0  1.40.4-1
ii  libpangocairo-1.0-0 1.40.4-1
ii  libtotem-plparser18 3.10.7-1+b1
ii  libtotem0   3.22.1-1
ii  libx11-62:1.6.4-3
ii  totem-common3.22.1-1

Versions of packages totem recommends:
ii  gstreamer1.0-libav 1.10.4-1
ii  gstreamer1.0-plugins-ugly  1.10.4-1
ii  gstreamer1.0-pulseaudio1.10.4-1
ii  totem-plugins  3.22.1-1

Versions of packages totem suggests:
pn  gnome-codec-install  

-- no debconf information

Bug#859672: [software-properties-gtk] Completely unusable and buggy in stretch, fix it or remove it

[Rafael Belmonte]

Package: software-properties-gtk
Version: 0.96.20.2-1
Severity: grave

--- Please enter the report below this line. ---
This application inherit from Ubuntu is very buggy in Debian stretch.
In tab "Debian Software":
-Checkboxes for "main, contrib, non-free" can't be marked, but even
they don't change the state to marked, it seems that they write
something in sources.list file.
-Checkbox for "Source code" is always marked and can't be
clicked/unmarked.
-The server chosen in "Download from" list is not respected, with any
change, it is reverted to Main server and (writes http.us.debian.org in
sources.list).
In "Updates" tab:
-Checkboxes for "Securty updates" and "Recommended updates" are not
clickable.
In "Developer options" tab:
-Checkbox for "Proposed updates" are not clickable.

This is my current sources.list:
---
deb http://httpredir.debian.org/debian/ stretch main contrib non-free
deb-src http://httpredir.debian.org/debian/ stretch main contrib non-
free

deb http://security.debian.org/debian-security stretch/updates main
contrib non-free
deb-src http://security.debian.org/debian-security stretch/updates main
contrib non-free
---
But I also tried to use this tool with an empty sources.list with no
success and same exposed issues.
I can remember that this (Ubuntu native) tool always was very buggy in
Debian, if it is not possible to fix or adapt for Debian, please,
remove it because it is very confusing for users.
Another issue is that it tries to load the UbuntuDrivers module when
launching:
ERROR:root:Cannot import UbuntuDrivers: No module named 'UbuntuDrivers'
--- System information. ---
Architecture: 
Kernel:   Linux 4.9.0-1-amd64

Debian Release: 9.0
  500 testing httpredir.debian.org 
  500 stable  dl.google.com 

--- Package information. ---
Depends   (Version) | Installed
===-+-
gir1.2-gtk-3.0  | 3.22.11-1
python3 | 3.5.3-1
python3-gi  | 3.22.0-2
python3-software-properties (= 0.96.20.2-1) | 0.96.20.2-1
software-properties-common  | 0.96.20.2-1
python3:any   (>= 3.3.2-2~) | 


Package's Recommends field is empty.

Suggests(Version) | Installed
=-+-===
gnome-software| 3.22.5-1

Bug#859567: retro-gtk and gnome-games-app

[Markus Koschany]

Control: owner -1 !

Hello Jeremy,

I intend to sponsor your packages which looks good and Policy compliant
to me.

Two points:

retro-gtk:

Please improve the package description a little and write one or two
additional sentences and explain what libretro is for.

I think "retro-gtk is a library to make libretro frontends that use
GTK3." doesn't ring a bell for the uninitiated.

I have successfully installed gnome-games-app but no games show up. What
do I need to do to make my *.desktop file based games from Debian main
visible in gnome-games-app?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#859669: qpid-proton: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: qpid-proton
Version: 0.14.0-5
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans
control: forwarded -1 https://issues.apache.org/jira/browse/PROTON-1326

Please migrate to libssl-dev in the Buster cycle. The bug report about
the FTBFS is #828521. The log of the FTBFS can be found at

https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/qpid-proton_0.10-2_amd64-20160529-1518

Sebastian

Bug#839010: bug still there in jessie (mips)

[Steve Arnold]

This is still a problem for mips/mipsel but stretch has the
upstream fixes.  Can you please add the stretch bind9 packages to
jessie-backports?  I'm building it now on edgerouter (albeit
slowly) but a lot of other people running on this hardware could
benefit from the fixes.

Thanks in advance...

-- 
Stephen L. Arnold
Principal Scientist / System Architect   sarn...@vctlabs.com
Vanguard Computer Technology Labs, Inc.   http://www.vctlabs.com
81 David Love Pl #212mobile:  (805) 863-8299
Goleta, CA 93117lab:  (805) 683-3503

Bug#859668: unblock: lazarus/1.6.2+dfsg-2

[Paul Gevers]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package lazarus

Dear release managers,

The current package of lazarus-doc-1.6 is as good as empty. It lacks the
documentation it was meant to ship because fpdoc, the Free Pascal documentation
generator was failing silently (i.e. with exit code 0) to generate the
documentation (bug 858553).

After I was able to bisect the line where it was actually failing on, upstream
has been so helpfull to fix the issue.

Please find the debdiff attached.

unblock lazarus/1.6.2+dfsg-2

- -- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'testing'), (50, 
'testing')
Architecture: amd64 (x86_64)

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAljlRNsACgkQnFyZ6wW9
dQrddggAiTFCYyTCH1BfIKf4BSNhTD5YuUr8gCNOlCX2IyqaBG1+YxERf1oqzuxX
39/3QcXdEn/QC+Sk1SNBftcRvV4sy2JY5jDS85z1w6anZiHjC28HWdGPUZi7o74R
tGiltPjGTUbLtWGyuyBBVC2CiqCzjPuJiBk5MS/s5UodTv52LQzFiyWw56M+vp0O
2DWRMHRdvq50C3VTjxvZhEMYhFyOrbNpgE3V4dyNVCN+yGIADICKtzMHA5CqadFO
CJtx/Yr6D0VceGhraiWm28+v7Nf5td+Iim9h2kxw5qVmmkD8O/Xitelth0XkxLg5
xGGXtHc57NXecFsZ6mUEFEuiJGbWiw==
=WgTo
-END PGP SIGNATURE-
diff -Nru lazarus-1.6.2+dfsg/debian/changelog 
lazarus-1.6.2+dfsg/debian/changelog
--- lazarus-1.6.2+dfsg/debian/changelog 2016-12-02 08:40:55.0 +0100
+++ lazarus-1.6.2+dfsg/debian/changelog 2017-04-05 20:46:22.0 +0200
@@ -1,3 +1,10 @@
+lazarus (1.6.2+dfsg-2) unstable; urgency=medium
+
+  * Add fix-fpdoc-crashes-on-lazarus-documentation.patch to prevent the
+lazarus-doc-1.6 package from being nearly empty (Closes: #858553)
+
+ -- Paul Gevers   Wed, 05 Apr 2017 20:46:22 +0200
+
 lazarus (1.6.2+dfsg-1) unstable; urgency=medium
 
   * New upstream bugfix release
diff -Nru 
lazarus-1.6.2+dfsg/debian/patches/fix-fpdoc-crashes-on-lazarus-documentation.patch
 
lazarus-1.6.2+dfsg/debian/patches/fix-fpdoc-crashes-on-lazarus-documentation.patch
--- 
lazarus-1.6.2+dfsg/debian/patches/fix-fpdoc-crashes-on-lazarus-documentation.patch
  1970-01-01 01:00:00.0 +0100
+++ 
lazarus-1.6.2+dfsg/debian/patches/fix-fpdoc-crashes-on-lazarus-documentation.patch
  2017-04-05 20:33:01.0 +0200
@@ -0,0 +1,633 @@
+Description: fpdoc fails to build the documentation leaving the documentation
+ package empty
+Author: Mattias Gaertner 
+Bug-Debian: http://bugs.debian.org/858553
+Source:
+ 
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/fixes_1_6/lcl/graphics.pp?r1=54518=54517=54518=lazarus=patch
+ 
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/fixes_1_6/docs/xml/lcl/graphics.xml?r1=54518=54517=54518=lazarus=patch
+ 
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/fixes_1_6/docs/xml/lcl/forms.xml?r1=54518=54517=54518=lazarus=patch
+ 
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/fixes_1_6/docs/xml/lcl/extctrls.xml?r1=54518=54517=54518=lazarus=patch
+ 
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/fixes_1_6/lcl/include/lcl_defines.inc?r1=54518=54517=54518=lazarus=patch
+ 
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/fixes_1_6/docs/xml/lcl/graphics.xml?r1=54519=54518=54519=lazarus=patch
+ 
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/fixes_1_6/lcl/extctrls.pp?root=lazarus=52280=54527=patch
+Index: lazarus/docs/xml/lcl/extctrls.xml
+===
+--- lazarus.orig/docs/xml/lcl/extctrls.xml
 lazarus/docs/xml/lcl/extctrls.xml
+@@ -6038,8 +6038,8 @@ will copy the contents of the
+   
+   
+   
+-Container with flow layout of controls 
placed in it.Use TFloatPanel if you need a container with float 
layout. The Anchors and Align properties of child controls are ignored. 
+-The floating direction is determined with FlowStyle property.
++Container with flow layout of controls 
placed in it.Use TFloatPanel if you need a container with float 
layout. The Anchors and Align properties of child controls are ignored.
++The floating direction is determined with FlowStyle 
property.
+ 
+   Determine if 
controls in TCustomFlowPanel are wrapped.
+   Use 
ControlList to set extra options of flow panel controls.
+Index: lazarus/docs/xml/lcl/forms.xml
+===
+--- lazarus.orig/docs/xml/lcl/forms.xml
 lazarus/docs/xml/lcl/forms.xml
+@@ -9252,11 +9252,13 @@
+ When True every form must have a resource (e.g. a .res file). 
An exception is raised if the resource is missing when creating a form.
+ The form resource is the lfm file compiled into the executable 
of your 

Bug#858112: gcc-defaults: broken symlinks: gcc-: /usr/share/doc/cpp-/README.Bugs -> ../gcc-6/README.Bugs

[Andreas Beckmann]

Control: severity -1 serious

On Sat, 18 Mar 2017 15:07:06 +0100 Andreas Beckmann  wrote:
> and another one in gdc-
> 
>   /usr/share/doc/gdc-/cpp- -> 
> cpp-

and resulting in packages without copyright file after upgrade
e.g. gdc-mips64-linux-gnuabi64 4:6.3.0-1 -> 4:6.3.0-2

  MISSING COPYRIGHT FILE: /usr/share/doc/gdc-mips64-linux-gnuabi64/copyright
  # ls -lad /usr/share/doc/gdc-mips64-linux-gnuabi64
  drwxr-xr-x 2 root root 40 Mar 20 17:35 
/usr/share/doc/gdc-mips64-linux-gnuabi64
  # ls -la /usr/share/doc/gdc-mips64-linux-gnuabi64/
  total 0
  drwxr-xr-x  2 root root   40 Mar 20 17:35 .
  drwxr-xr-x 94 root root 2500 Mar 20 17:35 ..

Bug#792321: Bug followup

[Diego Gomez]

I can't reproduce it anymore.
I think it's safe to close this.

Regards.

--
Diego.-

PGP:
Keyserver: pgp.mit.edu
Key Id: 4C9582F9
Fingerprint: 5FA9 0673 0870 7855 50CF  FD6E 9433 CBDC 4C95 82F9

On Wed, Apr 5, 2017 at 9:29 AM, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:

> tag 792321 moreinfo
> thanks
>
> As of version 4:5.8.6-1 (even possibly before) I can't find this issue
> anymore. Is some of you still able to reproduce it?
>
> We do have a workaround for this so maybe this should become important,
> but it
> would be better if we can close it.
>
> If I have no replies in ~4 days I'll close the bug. Of course feel free to
> reopen it later if you still can find it.
>
> Bug triagers: if you find this bug open in more than 4 days from now feel
> free
> to close it with version 4:5.8.6-1.
>
> --
> Sólo porque un mensaje pueda no ser recibido no implica que no
> valga la pena enviarlo.
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>

Bug#858553: [lazarus-doc-1.6] Package lazarus-doc-1.6 is empty and does not ship documentation files

[Paul Gevers]

Control: tags -1 pending

Hi Mattias,

On 05-04-17 11:51, Mattias Gaertner wrote:
> The Lazarus fixes branch now runs the build_html.sh without errors
> using fpdoc from FPC 3.0.0.
> svn path:
> http://svn.freepascal.org/svn/lazarus/branches/fixes_1_6
> 
> The following revisions are needed: 54527 54519 54518
> 
> Does that fix the bug?

That works great. Thanks a lot. Just for my understanding, everything in
those commits, except for the changes to lcl/extctrls.pp are done to
actually improve/fix the content of the documentation, right? Only the
change in lcl/extctrls.pp is needed to prevent fpdoc from failing?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#859631: unblock: manpages-zh/1.6.3-1

[Boyuan Yang]

Control: tags -1 - moreinfo

According to buildd status [1], the package was built successfully.

[1] https://buildd.debian.org/status/package.php?p=manpages-zh=sid

--
Sincerely,
Boyuan Yang

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

Bug#706656: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

> I agree this is the best way; my point was that you should not have a
> repository on github with a copy of the source, and the watch file should 
> point
> to Ultimaker's github.  Having a repository with the packaging is good.  You
> can also host that in our team repository on Alioth.  You are a member with
> commit access.

Oh!
I didn't know that.
Gonna move the 4 repos over to Alioth then, once I've figured out the hows and
wheres.

> Ah yes, I heard someone talk about that, and was told that it worked, but
> getting 2.4 was the easier fix for me. :)

Here's the discussion: https://github.com/Ultimaker/Cura/issues/537



signature.asc
Description: OpenPGP digital signature

Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail

[Aaron M. Ucko]

Source: libundead
Version: 1.0.6-1
Severity: important
Justification: fails to build from source

The libundead builds for armhf and ppc64 both failed with test suite
errors.  On armf, I see no specific indication of what went wrong, but
presume it should be possible to reproduce the problem on a porterbox.
On ppc64el, the log reports an assertion failure at
https://anonscm.debian.org/cgit/debian-med/libundead.git/tree/src/undead/stream.d#n1458:

  core.exception.AssertError@../src/undead/stream.d(1458): Assertion failure

Could you please take a look?

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#858190: unblock: manpages/4.10-1

[Dr. Tobias Quathamer]

control: reopen -1
control: retitle -1 unblock: manpages/4.10-2

Am 04.04.2017 um 18:51 schrieb Sven Joachim:

Unfortunately it introduced at least two file conflicts, #859511 and
#859514.  Can you please drop the offending files for now and check
whether there are other clashes in newly added manpages?


Yes, I'm sorry about that. I've now removed all files which conflict 
with manpages from other packages. The debdiff to this new version is 
attached. I'd be glad if this new upload could be considered for an 
unblock as well.


unblock manpages/4.10-2

Thanks a lot and sorry for the mess,
Tobias

diff -Nru manpages-4.10/debian/changelog manpages-4.10/debian/changelog
--- manpages-4.10/debian/changelog	2017-04-04 13:50:44.0 +0200
+++ manpages-4.10/debian/changelog	2017-04-05 20:17:49.0 +0200
@@ -1,3 +1,9 @@
+manpages (4.10-2) unstable; urgency=medium
+
+  * Remove conflicting files. (Closes: #859514, #859511)
+
+ -- Dr. Tobias Quathamer   Wed, 05 Apr 2017 20:17:49 +0200
+
 manpages (4.10-1) unstable; urgency=medium
 
   * Imported Upstream version 4.10
diff -Nru manpages-4.10/debian/rules manpages-4.10/debian/rules
--- manpages-4.10/debian/rules	2017-04-04 13:50:44.0 +0200
+++ manpages-4.10/debian/rules	2017-04-05 20:17:40.0 +0200
@@ -46,6 +46,16 @@
 	rm -f debian/manpages/usr/share/man/man4/sk98lin.4
 	# Temporary fix: Do not install tmpfs.5, see https://bugs.debian.org/847998
 	rm -f debian/manpages/usr/share/man/man5/tmpfs.5
+	# Provided by libbsd-dev
+	rm -f debian/manpages-dev/usr/share/man/man3/explicit_bzero.3
+	# Provided by keyutils
+	rm -f debian/manpages/usr/share/man/man7/keyrings.7
+	rm -f debian/manpages/usr/share/man/man7/persistent-keyring.7
+	rm -f debian/manpages/usr/share/man/man7/process-keyring.7
+	rm -f debian/manpages/usr/share/man/man7/session-keyring.7
+	rm -f debian/manpages/usr/share/man/man7/thread-keyring.7
+	rm -f debian/manpages/usr/share/man/man7/user-keyring.7
+	rm -f debian/manpages/usr/share/man/man7/user-session-keyring.7
 
 # manpages-dev has no docs dir
 override_dh_installdocs:


signature.asc
Description: OpenPGP digital signature

Bug#859666: ghostscript: CVE-2016-10219

[Salvatore Bonaccorso]

Source: ghostscript
Version: 9.20~dfsg-3
Severity: important
Tags: security patch upstream
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=697453

Hi,

the following vulnerability was published for ghostscript.

CVE-2016-10219[0]:
| The intersect function in base/gxfill.c in Artifex Software, Inc.
| Ghostscript 9.20 allows remote attackers to cause a denial of service
| (divide-by-zero error and application crash) via a crafted file.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-10219
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10219
[1] https://bugs.ghostscript.com/show_bug.cgi?id=697453
[2] 
http://www.ghostscript.com/cgi-bin/findgit.cgi?4bef1a1d32e29b68855616020dbff574b9cda08f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#855199: sympa web interface broken with jquery v3

[Dominik George]

Hi,

> This fix is already in the pipe for the next upload as I've already
> stumble upon this bug.

So, what about getting this fixed in stretch? Please fiel an unblock
request, it should probably be accepted because the patch is minimal and
the bug is important.

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#859665: debian-handbook in section 8.4.5

[Sean Smith]

Package: debian-handbook
Version: 8.20151209~deb8u

Handbook has the following text:
The addgroup and delgroup commands add or delete a group, respectively. The 
groupmod command modifies a group's information (its gid or identifier). The 
command passwd -g group changes the password for the group, while the passwd -r 
-g group command deletes it.

It talks about the commmand "passwd -g groupname" to change the password for a 
group.
There's no -g option in the passwd command. From googling and reading the man 
page, I found it's actually "gpasswd" by itself to put in a passwd for a group 
name.

I would make the reader aware that it's not a good idea to put in a password 
for a group as per the man page for gpasswd.

This is my first time submitting a bug and couldn't do it through reportbug.

thanks
Sean

Bug#859664: heimdal-servers, heimdal-clients have obsolete Provides: ftp/ftp-server

[Sergio Gelato]

Package: heimdal-clients
Version: 7.1.0+dfsg-9

kftp and kftpd are no longer part of Heimdal since version 7.0.1.
It is therefore incorrect for heimdal-clients to claim that it
Provides: ftp
and for heimdal-servers to claim that it
Provides: ftp-server

I suspect that the corresponding Conflicts: can also be dropped but
haven't actually tested this. If true, then bug 236902 may be considered
to be fixed.

Bug#840676:

[Michael Lustfield]

Control: owner 840676 !

I ended up creating duplicate packaging and merged my changes which
included a version bump. I didn't look, but remember at least some of
these modifications being present in the current packaging. Sometime
today, I'll take a look and see if any changes still need to be made.
If not, I'll go ahead and close this bug.

Bug#859663: RFS: manpages-zh/1.6.3-1

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "manpages-zh" into unstable.

Unblock request already filed and acked by release team (see #859631).

 * Package name: manpages-zh
   Version : 1.6.3-1
   Upstream Author : Boyuan Yang <073p...@gmail.com>
 * URL : https://github.com/man-pages-zh/manpages-zh
 * License : GFDL-1.2+
   Section : doc

It builds those binary packages:

manpages-zh - Chinese manual pages

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

  https://mentors.debian.net/package/manpages-zh

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

dget -x https://mentors.debian.net/debian/pool/main/m/manpages-zh/
manpages-zh_1.6.3-1.dsc

Alternatively, one can check build results on debomatic-amd64:

  http://debomatic-amd64.debian.net/distribution#unstable/manpages-zh/
1.6.3-1/

Commits pushed onto Alioth:

https://anonscm.debian.org/git/chinese/manpages-zh.git

Changes since the last upload:

 manpages-zh (1.6.3-1) unstable; urgency=medium
 .
   * Upload onto unstable.
   * Mark manpages-zh package Multi-Arch: foreign.

Regards,
Boyuan Yang

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

Bug#690942: python-pgmagick: Image.attribute does not set the attribute but instead appends to it

[Juraj Komačka]

According to 
http://www.graphicsmagick.org/api/attribute.html#setimageattribute 
special handling for EXIF:Orientation has been introduced in 
http://hg.code.sf.net/p/graphicsmagick/code/rev/90be78bb60fb


> The new EXIF:Orientation attribute replaces the existing value rather 
than being concatenated to it as when setting other attributes.


I have reproduced exactly same behaviour for GM core C API with current 
stable from upstream, the problem is resolved in latest developments 
snapshot from (1.4-020170315). AFAIK no additional change is needed in 
python-pgmagick or libgraphicsmagick++.

Bug#859217: closed by "Steinar H. Gunderson" <sgunder...@bigfoot.com> (Re: Bug#859217: nageru: just segfaults)

[Steinar H. Gunderson]

On Sat, Apr 01, 2017 at 08:46:34PM +0200, Steinar H. Gunderson wrote:
> I found a relatively clean fix and uploaded it to unstable. Please test if it
> works for you before I send it on to the release team.

Seemingly it was unblocked without any action on my behalf:

  Migration status: OK: Will attempt migration (Any information below is purely 
informational)
  Maintainer: Steinar H. Gunderson
  2 days old (needed 2 days)
  Ignoring block request by freeze, due to unblock request by nthykier
  Overriding age needed from 10 days to 2 by nthykier
  Piuparts tested OK - https://piuparts.debian.org/sid/source/n/nageru.html
  Valid candidate

I suppose that means someone tested it and found it working for them. :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#859599: unblock: qemu/1:2.8+dfsg-4

[Michael Tokarev]

05.04.2017 20:42, Niels Thykier wrote:
> Control: tags -1 moreinfo
> 
> On Wed, 05 Apr 2017 09:35:19 +0300 Michael Tokarev  wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock package qemu
>>
>> Upstream released a new stable/bugfix version which
>> includes many changes we already had in debian
>> package, but picked up more accurately (especially
>> the 9pfs changes), and includes other bugfixes which
>> were found since 2.8.0 release. After careful review
>> of the changes upstream released I tend to think it
>> is better to have whole set than to cherry-pick from
>> a cherry-pick.
>>
>> I'd rather follow upstream here than to roll our own
>> selection which no one knows how to deal with :)
>>
>> [...]
>>
> 
> Just to be sure, are you recommending 1:2.8+dfsg-4 or that we go with
> upstream's 2.8.1 release?

Historically, for some reason I don't remember what, we
kept the "major" upstream version and source in qemu and
used just a patch (v2.8.1.patch in this case) pulled from
upstream (tarball or git difference, which is the same in
this case).

Note that the version number has just 2 components, and
the unblock request is for 2.8+dfsg-4, which includes
v2.8.1.patch as a single upstream patch.

The bulk of the debdiff (about 90% of it) is due to patch
rearrangement, -- all of the upstream patches being removed
are actually moved to v2.8.1.patch (with additions).

Besides, it just occured to me that I can, at least, make
a set of git differences which where already included in
current debian release, and which are being added in the
proposed v2.8.1.patch.  If that helps, I'll do this.

Thanks!

/mjt

Bug#859599: unblock: qemu/1:2.8+dfsg-4

[Niels Thykier]

Control: tags -1 moreinfo

On Wed, 05 Apr 2017 09:35:19 +0300 Michael Tokarev  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package qemu
> 
> Upstream released a new stable/bugfix version which
> includes many changes we already had in debian
> package, but picked up more accurately (especially
> the 9pfs changes), and includes other bugfixes which
> were found since 2.8.0 release. After careful review
> of the changes upstream released I tend to think it
> is better to have whole set than to cherry-pick from
> a cherry-pick.
> 
> I'd rather follow upstream here than to roll our own
> selection which no one knows how to deal with :)
> 
> [...]
> 

Just to be sure, are you recommending 1:2.8+dfsg-4 or that we go with
upstream's 2.8.1 release?

Thanks,
~Niels

Bug#859631: unblock: manpages-zh/1.6.3-1 (pre-approval)

[Niels Thykier]

Control: tags -1 confirmed moreinfo

On Wed, 05 Apr 2017 19:55:18 +0800 Boyuan Yang <073p...@gmail.com> wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Dear Release Team,
> 
> I would like to upload package manpages-zh 1.6.3 to unstable and have it 
> released with Stretch.
> 
> Manpages-zh provides Chinese man pages. Its current version in testing is 
> 1.6.0-2. Since upstream (actually it is myself) has released new versions to 
> provide with more complete Chinese man pages, I think we should make it into 
> stable release.
> 
> Since it is a documentation package, changes should be harmless. I checked 
> carefully to make sure that no man page collision would happen (like what 
> happened in manpages/4.10-1). Version 1.6.3-1~exp1 is already inside 
> experimental.
> 
> The full debdiff is huge (16000+ lines) with mostly new translations. A 
> stripped version is provided as well (600 lines) to exclude useless info and 
> translation updates.
> 
> If such changes could be allowed, I will proceed and upload it to unstable.
> 
> unblock manpages-zh/1.6.3-1
> 
> --
> Sincerely,
> Boyuan Yang

Ack, please go ahead and remove the moreinfo tag once the upload is
complete and has been built on all relevant release architectures.

Thanks,
~Niels

Bug#776424: [kgb-maintainers] Bug#776424: can be crashed by some network traffic

[Joey Hess]

Antoine Beaupre wrote:
> Joey, did you manage to reproduce this issue without an external
> attacker? Can you still reproduce in 1.34?

Just saw the issue again with 1..34-2

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#859662: ghostscript: CVE-2016-10217

[Salvatore Bonaccorso]

Source: ghostscript
Version: 9.20~dfsg-3
Severity: important
Tags: upstream security
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=697456

Hi,

the following vulnerability was published for ghostscript.

CVE-2016-10217[0]:
| The pdf14_open function in base/gdevp14.c in Artifex Software, Inc.
| Ghostscript 9.20 allows remote attackers to cause a denial of service
| (use-after-free and application crash) via a crafted file that is
| mishandled in the color management module.

To verify with an ASAN build of ghostscript:

cut-cut-cut-cut-cut-cut-
# LD_LIBRARY_PATH=./sobin ./debian/tmp/usr/bin/gs -dNOPAUSE -sDEVICE=bit 
-sOUTPUTFILE=/dev/null -dSAFER /root/gs_uaf_pdf14_cleanup_parent_color_profiles 
-c quit
GPL Ghostscript 9.20 (2016-09-26)
Copyright (C) 2016 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
=
==4082==ERROR: AddressSanitizer: heap-use-after-free on address 0x62a00053b840 
at pc 0x7f9c09ebff67 bp 0x7ffe337bb2a0 sp 0x7ffe337bb298
READ of size 8 at 0x62a00053b840 thread T0
#0 0x7f9c09ebff66 in pdf14_cleanup_parent_color_profiles base/gdevp14.c:2016
#1 0x7f9c09eefcef in pdf14_device_finalize base/gdevp14.c:8293
#2 0x7f9c0a7fd262 in restore_finalize psi/isave.c:952
#3 0x7f9c0a7fc066 in alloc_restore_step_in psi/isave.c:759
#4 0x7f9c0a7fcbfb in alloc_restore_all psi/isave.c:886
#5 0x7f9c0a700455 in gs_main_finit psi/imain.c:978
#6 0x7f9c0a700a74 in gs_to_exit_with_code psi/imain.c:1013
#7 0x7f9c0a700a9b in gs_to_exit psi/imain.c:1018
#8 0x7f9c0a70b97b in gsapi_exit psi/iapi.c:561
#9 0x557197880114 in main psi/dxmainc.c:90
#10 0x7f9c0976b2b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#11 0x55719787fd29 in _start 
(/root/ghostscript-9.20~dfsg/debian/tmp/usr/bin/gs+0xd29)

0x62a00053b840 is located 5696 bytes inside of 20048-byte region 
[0x62a00053a200,0x62a00053f050)
freed by thread T0 here:
#0 0x7f9c0b8b7a10 in free (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1a10)
#1 0x7f9c0a4c960f in gs_heap_free_object base/gsmalloc.c:348
#2 0x7f9c0a46655d in alloc_free_clump base/gsalloc.c:2593
#3 0x7f9c0a45f7d1 in free_all_not_allocator base/gsalloc.c:1000
#4 0x7f9c0a45cf20 in clump_splay_app base/gsalloc.c:602
#5 0x7f9c0a45fa30 in i_free_all base/gsalloc.c:1036
#6 0x7f9c0a7fd475 in restore_free psi/isave.c:989
#7 0x7f9c0a7fc7b8 in restore_space psi/isave.c:847
#8 0x7f9c0a7fc220 in alloc_restore_step_in psi/isave.c:784
#9 0x7f9c0a7fcbfb in alloc_restore_all psi/isave.c:886
#10 0x7f9c0a700455 in gs_main_finit psi/imain.c:978
#11 0x7f9c0a700a74 in gs_to_exit_with_code psi/imain.c:1013
#12 0x7f9c0a700a9b in gs_to_exit psi/imain.c:1018
#13 0x7f9c0a70b97b in gsapi_exit psi/iapi.c:561
#14 0x557197880114 in main psi/dxmainc.c:90
#15 0x7f9c0976b2b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

previously allocated by thread T0 here:
#0 0x7f9c0b8b7d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0x7f9c0a4c8aac in gs_heap_alloc_bytes base/gsmalloc.c:183
#2 0x7f9c0a46560b in alloc_acquire_clump base/gsalloc.c:2430
#3 0x7f9c0a4651c0 in alloc_add_clump base/gsalloc.c:2379
#4 0x7f9c0a4635d3 in alloc_obj base/gsalloc.c:1991
#5 0x7f9c0a46097c in i_alloc_struct base/gsalloc.c:1229
#6 0x7f9c0a7dbb9c in gs_istate_alloc psi/zgstate.c:590
#7 0x7f9c0a4ea417 in gstate_clone base/gsstate.c:1008
#8 0x7f9c0a4e6eaf in gs_gsave base/gsstate.c:325
#9 0x7f9c0a4e712a in gs_gsave_for_save base/gsstate.c:370
#10 0x7f9c0a7879a0 in zsave psi/zvmem.c:84
#11 0x7f9c0a6f3b8a in z2save psi/zdevice2.c:219
#12 0x7f9c0a721f63 in interp psi/interp.c:1310
#13 0x7f9c0a71d2eb in gs_call_interp psi/interp.c:511
#14 0x7f9c0a71cc52 in gs_interpret psi/interp.c:468
#15 0x7f9c0a6fb8d2 in gs_main_interpret psi/imain.c:245
#16 0x7f9c0a6fe323 in gs_main_run_string_end psi/imain.c:663
#17 0x7f9c0a6fdf6a in gs_main_run_string_with_length psi/imain.c:621
#18 0x7f9c0a6fdedc in gs_main_run_string psi/imain.c:603
#19 0x7f9c0a705d7c in run_string psi/imainarg.c:977
#20 0x7f9c0a705b87 in runarg psi/imainarg.c:967
#21 0x7f9c0a705539 in argproc psi/imainarg.c:900
#22 0x7f9c0a701d22 in gs_main_init_with_args psi/imainarg.c:238
#23 0x7f9c0a70b18e in gsapi_init_with_args psi/iapi.c:353
#24 0x5571978800d4 in main psi/dxmainc.c:86
#25 0x7f9c0976b2b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: heap-use-after-free base/gdevp14.c:2016 in 
pdf14_cleanup_parent_color_profiles
Shadow bytes around the buggy address:
  0x0c548009f6b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c548009f6c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c548009f6d0: fd fd fd fd fd fd fd fd 

Bug#858836: unblock: h5py/2.7.0~rc3-2 or h5py/2.7.0-1 (pre-approval)

[Niels Thykier]

Control: tags -1 moreinfo

Ghislain Antony Vaillant:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package h5py
> 
> Whilst improving the DEP-8 tests of h5py to cover all supported Python
> versions, I discovered that the -dbg packages were missing an install
> dependency on Numpy (#858727). Without this fix, using python-h5py-dbg
> or python3-h5py-dbg would result in an ImportError.
> 
> I have prepared an update providing the more comprehensive DEP-8 tests
> and solving the issue with the missing numpy-dbg install dependencies.
> The corresponding debdiff is attached with this email. I would like to
> request your approval for pushing this update to unstable and letting it
> migrate to Stretch.
> 
> On a closing note, upstream recently released h5py version 2.7.0. This
> version does not differ much from 2.7.0~rc3, and providing it would
> allow us to drop the last two patches from the patch queue that had to
> be cherry-picked in order to get rc3 to work. Therefore, perhaps
> shipping 2.7.0 instead of rc3 would be better from a maintenance
> perspective.
> 
> Best regards,
> Ghis
> 
> unblock h5py/2.7.0~rc3-2
> 
> [...]

Hi,

I am happy to ack the provided debdiff.  Alternatively, if you want the
2.7 release, I would like to see the debdiff first.  It does sound like
it would make sense in this case.

Thanks,
~Niels

Bug#858838: unblock: python-qtawesome/0.4.4+ds1-1 (pre-approval)

[Niels Thykier]

Control: tags -1 confirmed moreinfo

Ghislain Antony Vaillant:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package python-qtawesome
> 
> An important bug was found on the QtAwesome Python library but was
> wrongly assigned to spyder at the time of the freeze (#844601). Upstream
> then released version 0.4.4, which only contains the fix for the said
> bug.
> 
> I have prepared an update including the new upstream release fixing this
> bug, also merged a downstream fix from Ubuntu and improved the DEP-8
> tests to cover all supported Python versions. The corresponding debdiff
> is attached with this email. I would like to request your approval for
> pushing this update to unstable and letting it migrate to Stretch.
> 
> Best regards,
> Ghis
> 
> unblock python-qtawesome/0.4.4+ds1-1
> 
> [...]

Please go ahead and remove the moreinfo tag once the upload has been
performed and built on all relevant release architectures.

Thanks,
~Niels

Bug#859661: chromium: Poor integration with gnome-shell after extension removal

[Mark Brown]

Package: chromium
Version: 57.0.2987.98-1
Severity: important

With the removal of extension support there is a NEWS.Debian entry
recommending that either a command line option or an environment
variable is set to reenable them if users rely on them.  Unfortunately
there is no information provided on how to actually accomplish either of
these things and no visible facility to do them exists for this in GNOME
3 which is a pretty standard desktop for Debian.  This results in a very
poor user experience, more technical users will probably figure this out
but less technical users who wish to use extensions will struggle to
understand what they're being asked to do (or why).  It's entirely
likely that some will never see the NEWS.Debian entry in the first
place.

We should do a much better job of explaining this change to users.  It
really should be something directly controllable through the browser UI,
or a "with extensions" version of Chromium could be provided in the
system menus.  Documenting some "create a file here" workaround would
probably work as well though it is a bit less discoverable.

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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.22.0-1
ii  libavcodec57 7:3.2.4-1
ii  libavformat577:3.2.4-1
ii  libavutil55  7:3.2.4-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-8
ii  libdbus-1-3  1.10.16-1
ii  libevent-2.0-5   2.0.21-stable-3
ii  libexpat12.2.0-2
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3+b2
ii  libgcc1  1:6.3.0-11
it  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libharfbuzz0b1.4.2-1
ii  libicu57 57.1-5
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpango-1.0-0   1.40.4-1
ii  libpangocairo-1.0-0  1.40.4-1
ii  libpng16-16  1.6.28-1
ii  libpulse010.0-1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.4-1
ii  libstdc++6   6.3.0-11
ii  libvpx4  1.6.1-3
ii  libwebp6 0.5.2-1
ii  libwebpdemux20.5.2-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-1+b4
ii  libxdamage1  1:1.1.4-2+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-2.2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2.1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+3+b1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information

Bug#859511: libbsd-dev: trying to overwrite '/usr/share/man/man3/explicit_bzero.3.gz', which is also in package manpages-dev 4.10-1

[Sven Joachim]

On 2017-04-05 11:59 +0200, Vincent Lefevre wrote:

> On 2017-04-04 18:41:10 +0200, Sven Joachim wrote:
>> On 2017-04-04 16:29 +0100, Chris Lamb wrote:
>> > Unpacking libbsd-dev:amd64 (0.8.3-1) ...
>> > dpkg: error processing archive 
>> > /tmp/apt-dpkg-install-tduipc/101-libbsd-dev_0.8.3-1_amd64.deb (--unpack):
>> >  trying to overwrite '/usr/share/man/man3/explicit_bzero.3.gz', which is 
>> > also in package manpages-dev 4.10-1
>> 
>> It's libbsd-dev which came first to ship that manpage, manpages-dev only
>> added it in the 4.10-1 upload.
>
> I assume that's because it's a new function in glibc 2.25:
>
> http://man7.org/linux/man-pages/man3/bzero.3.html
>
>   explicit_bzero() first appeared in glibc 2.25.
>
> So, IMHO, manpages-dev does the right thing by providing this
> man page.

It certainly should do so in the long run, but not now since we don't
even have glibc 2.25 in Debian yet, and the manpages 4.10-1 upload was
specifically targeted at stretch (see #858190).

> (There will also be an issue between glibc 2.25 and
> libbsd concerning this function.)

Indeed, that's something for the libbsd maintainer to think about.

Cheers,
   Sven

Bug#858817: unblock: user-manager/4:5.8.5-2

[Niels Thykier]

Control: tags -1 confirmed moreinfo


Maximiliano Curia:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Dear release team,
> 
> KDE Plasma 5.8 is an LTS release that I consider fit to be updated in 
> stretch. 
> This particular request is for user-manager 5.8.5.
> 
> The fixes included in the user-manager 5.8.5 release are: 
>  translation updates
>  2 bug fixes:
>   + Hide "automatic login" button in UserAccounts since is does absolutely
> nothing (4761ae3) KDE#363058
> This is fixed in 5.9
>   + Revert "Do not ask for root permissions when it's unnecessary" (f2c69db)
> KDE#373276
> This broke adding new users when not setting realname or adminflag (i.e.
> at present there is no way to create a !admin user at all).
> 
> On the Debian side there are no changes worth mentioning.
> 
> I'm attaching the full debdiff, the gitlogs of the upstream changes.
> 
> Currently the version 4:5.8.5-1 is in experimental, and I'll upload the
> 4:5.8.5-2 version to unstable if this gets approved.
> 
> Please unblock package user-manager
> 
> Happy hacking,
> 
> unblock user-manager/4:5.8.5-2
> 
> [...]

Ack, please go ahead.

Next time, please consider excluding the translations from the debdiff
(filterdiff -x '**/*.po') as it would have made the review a lot easier.

Thanks,
~Niels

Bug#859576: unblock: osmose-emulator/1.0-3

[Niels Thykier]

Carlos Donizete Froes:
> Em qua, 2017-04-05 às 06:26 +, Niels Thykier escreveu:
>> The rest of the changes does not look terribly important, though I am
>> okay with accepting them as "documentation" changes if the debhelper
>> compat bump is reverted.
> 
> I'll reversing debhelp compat level 9.
> 
> Thanks!
> 

Ack, please go ahead and remove the moreinfo tag once it has been
uploaded + built on all relevant release architectures.

Thanks,
~Niels

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Hugo,

thanks again for the review and the comments!

On Wed, 5 Apr 2017 18:25:04 +0200
Hugo Lefeuvre  wrote:
> > * debian-watch-may-check-gpg-signature  
> 
> I wouldn't override debian-watch-may-check-gpg-signature btw.

Ok, I will revert that override.

> > If I remove `usr/sbin` from dirs, buildpackage fails complaining
> > that the directory does not exist (so something in the build system
> > is slightly broken).  
> 
> The error message is
> 
> /usr/bin/install -c -m 555 -o bin -g bin
> arpwatch /build/arpwatch-2.1a15/debian/arpwatch/usr/sbin /usr/bin/install:
> cannot create regular file
> '/build/arpwatch-2.1a15/debian/arpwatch/usr/sbin': No such file or
> directory Makefile:114: recipe for target 'install' failed 
> 
> looks like the Makefile installs files under usr/sbin, but doesn't
> create the directory if it doesn't exist. This is rather a Makefile
> bug.

With "build system" I meant this process of autotools creating the
Makefile, and `make install` doing something slightly wrong.  Anyway,
that means keeping `usr/sbin` in the dirs file is the correct "fix",
right?

> If the dpkg documentation recommends to do so, then, fine, forget
> about this warning.

But it also makes sense to drop dpkg version constraints at some point.
I wonder if it's not better to ask the dpkg maintainers if that
recommendation still holds…

> Are you already a member of the team ? If yes, could you move your git
> repository to
> https://anonscm.debian.org/git/pkg-security/arpwatch.git ?

I'm not a member of the team yet, where can I apply? :)
Disclaimer: this is my first package…

When pushing to the repository, should the changes go into a separate
branch for experimental (e.g. debian/experimental instead of
debian/master)?
Also I'm uncertain if I should add ~exp1 to the version number. Some
packages seem to do it for experimental uploads, others don't and just
increment the version number once when uploading to unstable later. Do
you have a recommendation?


I have the following on my TODO list which I would like to resolve
before the upload:
* decide on whether to add ~exp1 to version number
* remove the override for debian-watch-may-check-gpg-signature
* update debian/changelog timestamp (which I forgot to do after
  yesterday's changes)
* git-tag the release and push the git repository to its new home


Regards
Lukas


pgplxYA1nteYj.pgp
Description: OpenPGP digital signature

Bug#859490: unblock: haproxy/1.7.5-1 (pre-approval)

[Apollon Oikonomopoulos]

Control: tags -1 - moreinfo

Hi,

On 13:40 Wed 05 Apr , Niels Thykier wrote:
> Ack, please go ahead and remove the moreinfo tag once the upload has
> been built successfully on all relevant release architectures.

Uploaded and built everywhere, thanks!

I'm also attaching the full source debdiff for reference.

Regards,
Apollon
diff -Nru haproxy-1.7.4/CHANGELOG haproxy-1.7.5/CHANGELOG
--- haproxy-1.7.4/CHANGELOG	2017-03-28 00:37:58.0 +0300
+++ haproxy-1.7.5/CHANGELOG	2017-04-03 11:28:32.0 +0300
@@ -1,6 +1,16 @@
 ChangeLog :
 ===
 
+2017/04/03 : 1.7.5
+- BUG/MEDIUM: peers: fix buffer overflow control in intdecode.
+- BUG/MEDIUM: buffers: Fix how input/output data are injected into buffers
+- BUG/MEDIUM: http: Fix blocked HTTP/1.0 responses when compression is enabled
+- BUG/MINOR: filters: Don't force the stream's wakeup when we wait in flt_end_analyze
+- DOC: fix parenthesis and add missing "Example" tags
+- DOC: update the contributing file
+- DOC: log-format/tcplog/httplog update
+- MINOR: config parsing: add warning when log-format/tcplog/httplog is overriden in "defaults" sections
+
 2017/03/27 : 1.7.4
 - MINOR: config: warn when some HTTP rules are used in a TCP proxy
 - BUG/MINOR: spoe: Fix soft stop handler using a specific id for spoe filters
diff -Nru haproxy-1.7.4/CONTRIBUTING haproxy-1.7.5/CONTRIBUTING
--- haproxy-1.7.4/CONTRIBUTING	2017-03-28 00:37:58.0 +0300
+++ haproxy-1.7.5/CONTRIBUTING	2017-04-03 11:28:32.0 +0300
@@ -71,8 +71,10 @@
 
 If your work is very confidential and you can't publicly discuss it, you can
 also mail wi...@haproxy.org directly about it, but your mail may be waiting
-several days in the queue before you get a response. Retransmit if you don't
-get a response by one week.
+several days in the queue before you get a response, if you get a response at
+all. Retransmit if you don't get a response by one week. Please note that
+direct sent e-mails to this address for non-confidential subjects may simply
+be forwarded to the list or be deleted without notification.
 
 If you'd like a feature to be added but you think you don't have the skills to
 implement it yourself, you should follow these steps :
@@ -96,7 +98,9 @@
 at the beginning but it's common sense more than anything else and contributors
 do not think about them anymore after a few patches.
 
-1) Before modifying some code, you have read the LICENSE file ("main license")
+1) Comply with the license
+
+   Before modifying some code, you have read the LICENSE file ("main license")
coming with the sources, and all the files this file references. Certain
files may be covered by different licenses, in which case it will be
indicated in the files themselves. In any case, you agree to respect these
@@ -107,7 +111,9 @@
maintainers are free to reject contributions proposing license changes they
feel are not appropriate or could cause future trouble.
 
-2) Your work may only be based on the latest development version. No development
+2) Develop on development branch, not stable ones
+
+   Your work may only be based on the latest development version. No development
is made on a stable branch. If your work needs to be applied to a stable
branch, it will first be applied to the development branch and only then will
be backported to the stable branch. You are responsible for ensuring that
@@ -119,7 +125,9 @@
re-adapt their code, because they did probably not expect to have to spend
more time discovering your changes and rebasing their work.
 
-3) You have read and understood "doc/codingstyle.txt", and you're actively
+3) Read and respect the coding style
+
+   You have read and understood "doc/coding-style.txt", and you're actively
determined to respect it and to enforce it on your coworkers if you're going
to submit a team's work. We don't care what text editor you use, whether it's
an hex editor, cat, vi, emacs, Notepad, Word, or even Eclipse. The editor is
@@ -133,7 +141,9 @@
noting that poor quality code is painful to read and may result in nobody
willing to waste their time even reviewing your work.
 
-4) The time it takes for you to polish your code is always much smaller than the
+4) Present clean work
+
+   The time it takes for you to polish your code is always much smaller than the
time it takes others to do it for you, because they always have to wonder if
what they see is intended (meaning they didn't understand something) or if it
is a mistake that needs to be fixed. And since there are less reviewers than
@@ -145,7 +155,9 @@
in the company's name but they will find it by themselves, it's obvious it
comes from us" ? No. When in doubt, simply ask for help on the mailing list.
 
-5) There are four levels of importance of quality in the project :
+5) Documentation is very important
+
+   There are four levels of importance of quality in the project :
 
- 

Bug#859660: artemis running issue

[Jerome]

Package: artemis
Version: 16.0.0+dfsg-4~bpo8+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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


When running artemis package, get this issue :

$ art
bash: /usr/bin/art: cannot execute binary file: Exec format error



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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 artemis depends on:
ii  default-jre [java7-runtime]2:1.7-52
ii  jarwrapper 0.48+deb8u1
ii  jemboss6.6.0+dfsg-1
ii  libbatik-java  1.7+dfsg-5
ii  libbiojava-java1:1.7.1-5
ii  libbiojava1.7-java 1:1.7.1-5
ii  libcommons-net2-java   2.2-2
ii  libibatis-java 2.3.4.726-5
ii  libj2ssh-java  0.2.9-4
ii  liblog4j1.2-java   1.2.17-6~bpo8+1
ii  libpostgresql-jdbc-java9.2-1002-1
ii  libsam-java1.113-1
ii  openjdk-7-jre [java7-runtime]  7u111-2.6.7-1~deb8u1
ii  openjdk-8-jre [java7-runtime]  8u121-b13-1~bpo8+1
ii  picard-tools   2.1.1+dfsg-1~bpo8+1

artemis recommends no packages.

artemis suggests no packages.

-- no debconf information

--
-- Jérôme
Un hombre sin cultura se parece a una zebra sin raya.
(Refrán africano)

Bug#857923: golang-go-dbus: build-depend on obsoleted package golang-gocheck-dev

[Roger Shimizu]

On Wed, 5 Apr 2017 08:35:17 +0200
Mattia Rizzolo  wrote:

> On Wed, Apr 05, 2017 at 08:51:05AM +0900, Roger Shimizu wrote:
> > I already checked in the final releasing commit into mentors branch.
> > I didn't go for master branch, in case anything missing before this release.
> 
> ok, if you are going to move everything to master and tag it once it's
> uploaded.

It's uploaded by my sponsor already.
Thanks for your push :-D

> > Instead of NMU, maybe QA upload is more proper for this purpose?
> 
> Not really: QA uploads are for packages that are orphaned, without
> maintainer.
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-qa-upload

Indeed.
Thanks for your info!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1


pgpUHQWki5GOi.pgp
Description: PGP signature

Bug#859531: debian-edu: Please do not recommend transitional package ttf-wqy-* for education-lang-zh-tw-desktop

[Holger Levsen]

Hi,

On Wed, Apr 05, 2017 at 01:14:59AM +0800, Boyuan Yang wrote:
> Binary package education-lang-zh-tw-desktop recommends transitional dummy
> package ttf-wqy-microhei and ttf-wqy-zenhei. Both packages are now dummy
> packages and provided by fonts-wqy-microhei and fonts-wqy-zenhei respectively.
 
thanks for bug report, we should definitly do this.

> Please update your recommend list and recommend directly on the real packages.
 
I just wonder if we install more transitional dummy packages, which we should
replace with their real counterparts…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#859641: Please increase USBIP_VHCI_HC_PORTS and USBIP_VHCI_NR_HCS

[Steve McIntyre]

On Wed, Apr 05, 2017 at 03:51:14PM +0200, Bjørn Mork wrote:
>Steve McIntyre  writes:
>
>> In Linaro we're making a lot of use of USB-over-IP devices these days
>> for our testing lab. We've hit a (very small!) limit defined in kernel
>> config for the number of virtual host controllers and the ports
>> allowed per controller.
>>
>> Currently these are defaulting to
>>
>> CONFIG_USBIP_VHCI_HC_PORTS=8
>> (can be 1 <= CONFIG_USBIP_VHCI_HC_PORTS <= 31)
>>
>> and
>> CONFIG_USBIP_VHCI_NR_HCS=1
>> (can be 1 <= CONFIG_USBIP_VHCI_NR_HCS <= 128)
>>
>> The normal limits are very small; could you please raise these to
>> (say) 31 and 8 for us? There will obviously be a small increase in
>> memory usage in the kernel, but only for users of these particular
>> devices.
>
>FWIW, I believe those constants never should have been accepted. But I
>just gave up after getting this answer:
>http://www.spinics.net/lists/linux-usb/msg134862.html
>
>"Because it is easy to implement." was obviously more important than
>easy to use...  I don't think distro users were considered.

ACK. :-/

>If you care about these limits, then I think you should look into what
>needs to be done to make them dynamic.  I cannot imagine that it is all
>that difficult.  Which of course is easy to say when you don't actually
>plan on doing the work :)

Hmmm. I'd love to help , but not *right* now - I've already got a
stack of things to do to help get Debian Stretch released!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer

Bug#858174: Re: Bug#858174: Please provide an AppArmor profile for Firefox

[Vincas Dargis]

2017.04.05 09:08, intrigeri rašė:

IMO the parts that require third-party kernel patches shall be
upstreamed as well: the end goal would be that the resulting upstream
profile can be pulled as-is by as many distros as possible, including
those that apply these patches, i.e. Ubuntu and OpenSUSE.


Right, agreed, silly me.

Bug#859659: lintian: version-substvar-for-external-package raised for dbgsym packages from same source

[Niels Thykier]

On Wed, 5 Apr 2017 17:15:20 +0100 Luca Boccassi
 wrote:
> Package: lintian
> Version: 2.5.50.1
> Severity: normal
> 
> Dear Maintainer,
> 
> TL;DR: Lintian reports the version-substvar-for-external-package error when 
> the
> "external package" in question is actually a dbgsym package generated by the
> same source package.
> 
> I maintain a source package, dpdk [1], which builds a great many libraries.
> Consequently, in stretch, a lot of dbgsym packages are generated.
> 
> As a shortcut, a colleague wanted to add an empty metapackage, libdpdk-dbgsym,
> which depends on all the generated -dbgsym packages. Unfortunately Lintian
> raises the (unoverridable) error mentioned above due to a line similar to 
> this:
> 
> Package: libfoo
> ...
> 
> Package: libbar
> ...
> 
> Package: foobar-dbg-meta
> Depends: libfoo-dbgsym (= ${binary:Version}), libbar-dbgsym (=
> ${binary:Version})
> 
> Given all the dbgsym packages have predictable names, and are created from
> packages listed in debian/control (ie: libfoo will be in d/control), could
> Lintian perhaps recognize this and avoid raising this error?
> 
> Thank you!
> 
> Kind regards,
> Luca Boccassi
> 
> [1] https://tracker.debian.org/pkg/dpdk
> 
> [...]

Hi Luca,

Unfortunately, you would just trade one issue for another (at least in
Debian).  The dbgsym packages is going to a separate archive and the
original packages are therefore not permitted to depend on them (the
debug archive is optional, dependencies being satisfiable is not).

That said, I can appreciate this might make sense for third-party packages.

Thanks,
~Niels

Bug#858860: RFS: arpwatch [ITA]

[Hugo Lefeuvre]

Hi Lukas,

> I do not have a web based git viewer installed on my server, however
>   git clone https://git.somlen.de/arpwatch.git
> should work. Remember to switch to the `staged-changes` branch.
> 
> (I should probably create a page explaining that this is a git only url
> instead of displaying a 403…)

Fine, thanks !

> > Quick review:
> > 
> > * lintian reports
> > 
> >   P: arpwatch source: source-contains-data-from-ieee-data-oui-db
> > ethercodes.dat 
> > 
> >   but it looks like you already fixed it. If this warning is not
> > relevant anymore please override it.  
> 
> Well, I did not really fix it. ethercodes.dat is still part of the
> source package, it's just no longer put into the binary package. But, as
> it is small and it does not violate the DFSG, Christian Seiler suggested
> on debian-mentors not to repack [1].
> 
> I have not previously overridden that tag because I was not sure if it
> is best practice to override lintian pediantic tags at all (only quite
> few packages seem to do it) as they also don't show up on the
> tracker.debian.org page. Anyways, I've now overridden the following two
> pedantic tags, together with a justification as comment:
> * source-contains-data-from-ieee-data-oui-db

I usually don't override pedantic tags.

However, I think it may be useful in this case because this tag and the 
following
changelog entry could seem to be somewhat contradictory without additional
explanations:

 * use ethercodes from ieee-data

One could think you just forgot to remove the file.

Overriding the tag allows you to explain why you did not remove the
file and why the tag isn't relevant anymore.

But anyway, that's not important, other developers would probably do it
differently.

> * debian-watch-may-check-gpg-signature

I wouldn't override debian-watch-may-check-gpg-signature btw.

> > * There's no copyright entry for you
> 
> Fixed.
> 
> > Nitpicking:
> > 
> > in debian/changelog: why "remove dmassagevendor" ? This changelog
> > entry could be more verbose.  
> 
> Right, I have a longer justification in the git history; I have expanded
> on the changelog entry.
> 
> > $ cme check dpkg
> > [...]
> > Warning in 'dirs:0' value 'usr/sbin': Make sure that this directory is 
> > actually needed. See 
> > L for 
> > details
> > Warning in 'dirs:1' value 'var/lib/arpwatch': Make sure that this
> > directory is actually needed. See
> > L
> > for details  
> 
> If I remove `usr/sbin` from dirs, buildpackage fails complaining that
> the directory does not exist (so something in the build system is
> slightly broken).

The error message is

/usr/bin/install -c -m 555 -o bin -g bin arpwatch 
/build/arpwatch-2.1a15/debian/arpwatch/usr/sbin
/usr/bin/install: cannot create regular file 
'/build/arpwatch-2.1a15/debian/arpwatch/usr/sbin': No such file or directory
Makefile:114: recipe for target 'install' failed 

looks like the Makefile installs files under usr/sbin, but doesn't
create the directory if it doesn't exist. This is rather a Makefile bug.

> `var/lib/arpwatch` is an empty directory created by the package that is
> populated with ethercodes.db during postinst (and then with interface
> specific database files once arpwatch is started). Should I create the
> directory during postinst instead? Creating the empty directory as part
> of the package seems nicer since dpkg will take care of the `rmdir` and
> warn the user if the directory is not empty on uninstall.

OK, fine.

> > [...]
> > Warning in 'control source Vcs-Git' value 
> > 'git://anonscm.debian.org/collab-maint/arpwatch.git': An unencrypted
> > transport protocol is used for this URI. It is recommended to use a
> > secure transport such as HTTPS for anonymous read-only access.
> > 
> > Warning in 'control source Vcs-Git' value 
> > 'git://anonscm.debian.org/collab-maint/arpwatch.git': URL is not the
> > canonical one for repositories hosted on Alioth.  
> 
> I had that on my TODO list but decided to wait and see how I get the
> package sponsored before changing the Url. I've now pointed it to what I
> expect to become its new home in case you are willing to sponsor the
> package:
>   https://anonscm.debian.org/cgit/pkg-security/arpwatch.git
>   https://anonscm.debian.org/git/pkg-security/arpwatch.git
> I've also adjusted debian/control to what I think it should be for team
> maintenance (maintainer is pkg-security-team, added myself as uploader).

Fine. Yes, I'll sponsor your package.

> > Warning in 'control binary:arpwatch Pre-Depends:0' value 'dpkg (>= 
> > 1.16.1)': unnecessary versioned dependency: dpkg (>= 1.16.1).
> > Debian has oldstable -> 1.16.18; stable -> 1.17.27; unstable -> 1.18.23; 
> > testing -> 1.18.23;  
> 
> Ok, I removed the pre-dependenciy.
> 
> In order to setup the file based trigger I followed man deb-triggers(5)
> from dpkg-dev version 1.18.23 (most recent version in