Bug#893940: RM: ghextris -- RoQA: unmaintained; depends on gnome-python-desktop

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: ghext...@packages.debian.org

ghextris was removed from Debian Testing in November because it
depends on the unmaintained gnome-python-desktop (from GNOME 2) [1].

I emailed the ghextris maintainer Christoph Egger on December 31,
January 28, and February 26 to first ask for permission to file a
removal bug for ghextris and then to warn that I would file a removal
bug anyway if I didn't get a reply. I didn't get a reply.

ghextris's last upstream release was apparently 12 years ago.

Please remove ghextris from Debian.

[1] https://bugs.debian.org/790576

Thanks,
Jeremy Bicha

Bug#893939: colorhug-client: drop libtool-bin from Build-Depends

[Helmut Grohne]

Source: colorhug-client
Version: 0.2.8-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

We want to drop libtool-bin from the archive. colorhug-client still
Build-Depends on it. If you need a configured libtool, please use the
libtool package and libtoolize. A successful rebuild with the dependency
dropped indicates that colorhug-client already uses libtoolize. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru colorhug-client-0.2.8/debian/changelog 
colorhug-client-0.2.8/debian/changelog
--- colorhug-client-0.2.8/debian/changelog  2017-03-07 17:16:30.0 
+0100
+++ colorhug-client-0.2.8/debian/changelog  2018-03-24 06:47:36.0 
+0100
@@ -1,3 +1,10 @@
+colorhug-client (0.2.8-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop libtool-bin from Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 24 Mar 2018 06:47:36 +0100
+
 colorhug-client (0.2.8-3) unstable; urgency=medium
 
   * Avoid running tests in valgrind as it's not really stable across
diff --minimal -Nru colorhug-client-0.2.8/debian/control 
colorhug-client-0.2.8/debian/control
--- colorhug-client-0.2.8/debian/control2017-03-07 17:16:28.0 
+0100
+++ colorhug-client-0.2.8/debian/control2018-03-24 06:47:36.0 
+0100
@@ -10,7 +10,6 @@
 intltool,
 itstool,
 libtool,
-libtool-bin,
 libxml2-utils,
 docbook-utils,
 yelp-tools,

Bug#893938: RM: pyrenamer -- RoQA; unmaintained, depends on python-desktop

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: pyrena...@packages.debian.org

pyrenamer was removed from Debian Testing in December because it
depends on the unmaintained gnome-python-desktop (from GNOME 2) [1].

I emailed the pyrenamer maintainer Adolfo González Blázquez on
December 31, January 28, and February 28 to first ask for permission
to file a removal bug for pyrenamer and then to warn that I would file
a removal bug anyway if I didn't get a reply. I didn't get a reply.

pyrenamer's last upstream release was a decade ago.

Please remove pyrenamer from Debian.

[1] https://bugs.debian.org/845954

Thanks,
Jeremy Bicha

Bug#893937: RM: linux-headers-marvell linux-image-marvell linux-image-marvell-dbg -- NBS; new version 4.15 doesn't build these anymore

[Mattia Rizzolo]

Package: ftp.debian.org

version 90 (-> linux 4.15) doesn't build any armel binary anymore.

For some reason this not detected as cruft, so they need to be manually
purged away.

% dak rm -Rnbp linux-headers-marvell linux-image-marvell linux-image-marvell-dbg
Will remove the following packages from unstable:

linux-headers-marvell |4.14+89 | armel
linux-image-marvell |4.14+89 | armel
linux-image-marvell-dbg |4.14+89 | armel

Maintainer: Debian Kernel Team 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


I trust the obsolete source will go away by itself later on.

-- 
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#892883: mirrors: Debian mirror opensource.nchc.org.tw: add as candidate of ftp.tw

[Steven Shiau]

Hi,
Yes, we have updated ftpsync on our mirror server 
(opensource.nchc.org.tw or a.k.a free.nchc.org.tw), and is ready to 
receive push mirror.

Now I'd like to ask the mirrors team where may we receive the push trigger?
Thank you very much.

Steven

On 3/24/2018 AM 11:49, Yao Wei wrote:

Hi,

You should update your ftpsync program first, which is here:

http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz

Also push mirror for ccTLD mirror seems to be necessary. You can 
consider setting that up with mirrors.xtom.com.hk 
 (this is what ftp.ntou.edu.tw 
 do) or ask the mirrors team here for 
receiving push from upstream.


Yao Wei
On Sat, 24 Mar 2018 at 09:28 Steven Shiau > wrote:



On 2018年03月14日 11:14, Yao Wei (魏銘廷) wrote:
> Package: mirrors
> Severity: wishlist
> X-Debbugs-CC: debian-mirr...@lists.debian.org
, Steven Shiau
>, Ceasar Sun
Chen-kai >, Thomas
>
>
> Hi,
>
> As stated in the debian-mirrors mailing list, NCHC wants to list
> ftp.tw.debian.org  as their primary
mirror:
>
> https://lists.debian.org/debian-mirrors/2018/03/msg0.html
>
> Also, according to the mirror status webpage:
>
> https://mirror-master.debian.org/status/mirror-status.html
>
> NCHC needs to use ftpsync rather than typical rsync to sync the
mirror,
> because of lacking sitetrace.
Thanks. If we follow the doc
https://salsa.debian.org/mirror-team/archvsync/, is it a must to
receive
an update trigger for ftpsync? If so, which upstream do you recommend
and where is public key of that upstream?
Thank you very much.

Steven
>
> Yao Wei

--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0



--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#893936: gitlab: pkg_resources.DistributionNotFound: The 'python-gitlab==1.3.0' distribution was not found and is required by the application

[Paul Wise]

Package: gitlab-cli
Version: 1:1.3.0-1
Severity: serious
File: /usr/bin/gitlab
Usertags: crash

The dependencies of gitlab-cli need to be more specific about which
version of python3-gitlab is to be installed. gitlab-cli requires the
same version of python3-gitlab as the version of gitlab-cli:

$ gitlab
Traceback (most recent call last):
  File "/usr/bin/gitlab", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3195, 
in 
@_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3179, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3208, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 681, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 999, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 885, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'python-gitlab==1.3.0' distribution was 
not found and is required by the application

$ apt-cache show gitlab-cli | grep python3-gitlab
Depends: python3, python3-gitlab

$ apt policy python3-gitlab
python3-gitlab:
  Installed: 7.5.0-1
  Candidate: 7.5.0-1
  Version table:
 1:1.3.0-1 800
800 https://deb.debian.org/debian unstable/main amd64 Packages
 *** 7.5.0-1 900
900 https://deb.debian.org/debian testing/main amd64 Packages
800 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gitlab-cli depends on:
ii  python3 3.6.4-1
ii  python3-gitlab  7.5.0-1

gitlab-cli recommends no packages.

gitlab-cli suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#891937: [Pkg-mailman-hackers] Bug#891937: mailman3-suite: Hyperkitty tries to connect postgres on system using sqlite

[Markus Gschwendt]

Sorry for the late Answer. I had lots of work last week.

I tried again but got stuck on restarting 'mailman-web'.
There is a '/var/run/mailman3/web/ directory which is empty and the log
reports a different directory for the pid file:

writing pidfile to /run/mailman3-web/mailman3-web.pid
open("/run/mailman3-web/mailman3-web.pid"): No such file or directory
[core/utils.c line 3590]

Markus

Bug#893935: /lib/modules/4.9.0-6-amd64/kernel/drivers/mmc/host/rtsx_usb_sdmmc.ko: Idle load from rmmod rtsx_usb_sdmmc

[Tomasz Warniełło]

Please note the connection to:
https://lkml.org/lkml/2014/11/5/905

as presented in this answer:
https://unix.stackexchange.com/a/433192/181255

2018-03-24 4:51 GMT+01:00 Tomasz Warniełło :

> Package: src:linux
> Version: 4.9.82-1+deb9u3
> Severity: important
> File: /lib/modules/4.9.0-6-amd64/kernel/drivers/mmc/host/rtsx_usb_sdmmc.ko
>
> Dear Maintainer,
>
> I observed high load in idle system in `top`. The load was ca. 2.00, the
> CPU i5.
> I checked i/o and net and didn't find load. There were always 3 processes
> in the D state:
> two kworkers and rtsx_usb_ms_1. I did `rmmod rtsx_usb_ms`, which didn't
> help,
> but then I did `rmmod rtsx_usb_sdmmc` and the load went down to 0.00.
>
> The situation is also described here:
> https://unix.stackexchange.com/questions/433052/high-
> load-on-i5-with-no-visible-reason/433192#433192
>
>
> -- Package-specific info:
> ** Version:
> Linux version 4.9.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version
> 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3
> (2018-03-02)
>
> ** Command line:
> BOOT_IMAGE=/vmlinuz-4.9.0-6-amd64 root=/dev/mapper/tomasz--laptop--f--vg-root
> ro quiet acpi_osi=Linux
>
> ** Not tainted
>
> ** Kernel log:
> [7.590362] Console: switching to colour dummy device 80x25
> [7.590434] [drm] Replacing VGA console driver
> [7.592890] uvcvideo: Found UVC 1.00 device FJ Camera (04f2:b413)
> [7.595472] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters,
> 655360 ms ovfl timer
> [7.595474] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
> [7.595475] RAPL PMU: hw unit of domain package 2^-14 Joules
> [7.595476] RAPL PMU: hw unit of domain dram 2^-14 Joules
> [7.595476] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
> [7.600777] Intel(R) Wireless WiFi driver for Linux
> [7.600780] Copyright(c) 2003- 2015 Intel Corporation
> [7.601096] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [7.601097] [drm] Driver supports precise vblank timestamp query.
> [7.603501] Bluetooth: hci0: read Intel version: 370710018002030d00
> [7.605666] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=
> io+mem,decodes=io+mem:owns=io+mem
> [7.608162] bluetooth hci0: firmware: direct-loading firmware
> intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
> [7.608166] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
> [7.615990] iwlwifi :03:00.0: firmware: direct-loading firmware
> iwlwifi-7260-17.ucode
> [7.616459] iwlwifi :03:00.0: loaded firmware version 17.352738.0
> op_mode iwlmvm
> [7.622788] snd_hda_codec_realtek hdaudioC1D0: ALC269VC: SKU not ready
> 0x909701f0
> [7.623075] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC269VC:
> line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
> [7.623077] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0
> (0x0/0x0/0x0/0x0/0x0)
> [7.623079] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1
> (0x15/0x0/0x0/0x0/0x0)
> [7.623080] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
> [7.623081] snd_hda_codec_realtek hdaudioC1D0:inputs:
> [7.623083] snd_hda_codec_realtek hdaudioC1D0:  Mic=0x18
> [7.623084] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
> [7.640540] uvcvideo 1-7:1.0: Entity type for entity Extension 3 was
> not initialized!
> [7.640543] uvcvideo 1-7:1.0: Entity type for entity Processing 2 was
> not initialized!
> [7.640545] uvcvideo 1-7:1.0: Entity type for entity Camera 1 was not
> initialized!
> [7.640648] input: HDA Digital PCBeep as /devices/pci:00/:00:
> 1b.0/sound/card1/input14
> [7.641879] input: FJ Camera as /devices/pci:00/:00:
> 14.0/usb1/1-7/1-7:1.0/input/input17
> [7.641976] usbcore: registered new interface driver uvcvideo
> [7.641977] USB Video Class driver (1.1.1)
> [7.642217] input: HDA Intel PCH Mic as /devices/pci:00/:00:
> 1b.0/sound/card1/input15
> [7.642280] input: HDA Intel PCH Headphone as
> /devices/pci:00/:00:1b.0/sound/card1/input16
> [7.643665] intel_rapl: Found RAPL domain package
> [7.643667] intel_rapl: Found RAPL domain core
> [7.643668] intel_rapl: Found RAPL domain uncore
> [7.643669] intel_rapl: Found RAPL domain dram
> [7.651834] iwlwifi :03:00.0: Detected Intel(R) Wireless N 7260,
> REV=0x144
> [7.654762] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
> [7.655217] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
> [7.659544] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post:
> no)
> [7.660680] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:
> 00/PNP0A08:00/LNXVIDEO:00/input/input18
> [7.665352] iTCO_vendor_support: vendor-support=0
> [7.667957] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
> [7.668017] iTCO_wdt: Found a Lynx Point TCO device (Version=2,
> TCOBASE=0x1860)
> [7.669127] iTCO_wdt: initialized. 

Bug#893935: /lib/modules/4.9.0-6-amd64/kernel/drivers/mmc/host/rtsx_usb_sdmmc.ko: Idle load from rmmod rtsx_usb_sdmmc

[Tomasz Warniełło]

Package: src:linux
Version: 4.9.82-1+deb9u3
Severity: important
File: /lib/modules/4.9.0-6-amd64/kernel/drivers/mmc/host/rtsx_usb_sdmmc.ko

Dear Maintainer,

I observed high load in idle system in `top`. The load was ca. 2.00, the CPU i5.
I checked i/o and net and didn't find load. There were always 3 processes in 
the D state:
two kworkers and rtsx_usb_ms_1. I did `rmmod rtsx_usb_ms`, which didn't help,
but then I did `rmmod rtsx_usb_sdmmc` and the load went down to 0.00.

The situation is also described here:
https://unix.stackexchange.com/questions/433052/high-load-on-i5-with-no-visible-reason/433192#433192


-- Package-specific info:
** Version:
Linux version 4.9.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-6-amd64 root=/dev/mapper/tomasz--laptop--f--vg-root 
ro quiet acpi_osi=Linux

** Not tainted

** Kernel log:
[7.590362] Console: switching to colour dummy device 80x25
[7.590434] [drm] Replacing VGA console driver
[7.592890] uvcvideo: Found UVC 1.00 device FJ Camera (04f2:b413)
[7.595472] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms 
ovfl timer
[7.595474] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[7.595475] RAPL PMU: hw unit of domain package 2^-14 Joules
[7.595476] RAPL PMU: hw unit of domain dram 2^-14 Joules
[7.595476] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[7.600777] Intel(R) Wireless WiFi driver for Linux
[7.600780] Copyright(c) 2003- 2015 Intel Corporation
[7.601096] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[7.601097] [drm] Driver supports precise vblank timestamp query.
[7.603501] Bluetooth: hci0: read Intel version: 370710018002030d00
[7.605666] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[7.608162] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
[7.608166] Bluetooth: hci0: Intel Bluetooth firmware file: 
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
[7.615990] iwlwifi :03:00.0: firmware: direct-loading firmware 
iwlwifi-7260-17.ucode
[7.616459] iwlwifi :03:00.0: loaded firmware version 17.352738.0 
op_mode iwlmvm
[7.622788] snd_hda_codec_realtek hdaudioC1D0: ALC269VC: SKU not ready 
0x909701f0
[7.623075] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC269VC: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[7.623077] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[7.623079] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x15/0x0/0x0/0x0/0x0)
[7.623080] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[7.623081] snd_hda_codec_realtek hdaudioC1D0:inputs:
[7.623083] snd_hda_codec_realtek hdaudioC1D0:  Mic=0x18
[7.623084] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
[7.640540] uvcvideo 1-7:1.0: Entity type for entity Extension 3 was not 
initialized!
[7.640543] uvcvideo 1-7:1.0: Entity type for entity Processing 2 was not 
initialized!
[7.640545] uvcvideo 1-7:1.0: Entity type for entity Camera 1 was not 
initialized!
[7.640648] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card1/input14
[7.641879] input: FJ Camera as 
/devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/input/input17
[7.641976] usbcore: registered new interface driver uvcvideo
[7.641977] USB Video Class driver (1.1.1)
[7.642217] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input15
[7.642280] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input16
[7.643665] intel_rapl: Found RAPL domain package
[7.643667] intel_rapl: Found RAPL domain core
[7.643668] intel_rapl: Found RAPL domain uncore
[7.643669] intel_rapl: Found RAPL domain dram
[7.651834] iwlwifi :03:00.0: Detected Intel(R) Wireless N 7260, 
REV=0x144
[7.654762] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[7.655217] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[7.659544] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[7.660680] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input18
[7.665352] iTCO_vendor_support: vendor-support=0
[7.667957] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[7.668017] iTCO_wdt: Found a Lynx Point TCO device (Version=2, 
TCOBASE=0x1860)
[7.669127] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[7.680044] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[7.680054] [drm] Initialized i915 1.6.0 20160919 for :00:02.0 on minor 0
[7.710550] Adding 4095996k swap on 
/dev/mapper/tomasz--laptop--f--vg-swap_1.  Priority:-1 extents:1 
across:4095996k SSFS
[7.713849] input: HDA Intel HDMI HDMI/DP,pcm=3 as 

Bug#892883: mirrors: Debian mirror opensource.nchc.org.tw: add as candidate of ftp.tw

[Yao Wei]

Hi,

You should update your ftpsync program first, which is here:

http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz

Also push mirror for ccTLD mirror seems to be necessary. You can consider
setting that up with mirrors.xtom.com.hk (this is what ftp.ntou.edu.tw do)
or ask the mirrors team here for receiving push from upstream.

Yao Wei
On Sat, 24 Mar 2018 at 09:28 Steven Shiau  wrote:

>
> On 2018年03月14日 11:14, Yao Wei (魏銘廷) wrote:
> > Package: mirrors
> > Severity: wishlist
> > X-Debbugs-CC: debian-mirr...@lists.debian.org, Steven Shiau <
> ste...@nchc.org.tw>, Ceasar Sun Chen-kai , Thomas <
> tho...@nchc.org.tw>
> >
> > Hi,
> >
> > As stated in the debian-mirrors mailing list, NCHC wants to list
> > ftp.tw.debian.org as their primary mirror:
> >
> >   https://lists.debian.org/debian-mirrors/2018/03/msg0.html
> >
> > Also, according to the mirror status webpage:
> >
> >   https://mirror-master.debian.org/status/mirror-status.html
> >
> > NCHC needs to use ftpsync rather than typical rsync to sync the mirror,
> > because of lacking sitetrace.
> Thanks. If we follow the doc
> https://salsa.debian.org/mirror-team/archvsync/, is it a must to receive
> an update trigger for ftpsync? If so, which upstream do you recommend
> and where is public key of that upstream?
> Thank you very much.
>
> Steven
> >
> > Yao Wei
>
> --
> Steven Shiau 
> Public Key Server PGP Key ID: 4096R/163E3FB0
> Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0
>
>

Bug#893851: ffcall: Fix build for MIPS release 6

[YunQiang Su]

On Fri, Mar 23, 2018 at 9:38 PM, YunQiang Su  wrote:
> On Fri, Mar 23, 2018 at 8:41 PM, Sébastien Villemot
>  wrote:
>> On Fri, Mar 23, 2018 at 08:02:58PM +0800, YunQiang Su wrote:
>>> On Fri, Mar 23, 2018 at 7:58 PM, YunQiang Su  wrote:
>>> > On Fri, Mar 23, 2018 at 7:27 PM, Sébastien Villemot
>>> >  wrote:
>>> >> Dear YunQiang,
>>> >>
>>> >> On Fri, Mar 23, 2018 at 06:15:08PM +0800, YunQiang Su wrote:
>>> >>> Package: src:ffcall
>>> >>> Version: 2.1-1
>>> >>>
>>> >>> MIPS release 6 drops some instructions: bnel/beql included.
>>> >>> For r6, we should use bne/beq for replace.
>>> >>>
>>> >>> The patch has submit in salsa as a merge request.
>>> >>>
>>> >>> https://salsa.debian.org/common-lisp-team/ffcall/merge_requests/1
>>> >>
>>> >> Thanks for your report and your patch.
>>> >>
>>> >> You may have overlooked the fact that these assembly files are actually
>>> >> generated by GCC from C source code (see the DEP-3 header of
>>> >> debian/patches/mips-fpxx.patch), so your proposed patch is not very
>>> >> maintainable in the long term.
>>> >
>>> > Oh, thanks. Since then, I guess we should generate these .S files
>>> > when build instead of put them in the source code.
>>> >
>>> > I will have a look at it.
>>>
>>> After read Makefile.devel, I think that we should call the right
>>> target in debian/rules.
>>> Should this the ideal way?
>>
>> This could be a possiblity, but this is not supported by upstream. And we 
>> would
>> have to patch this Makefile.devel to make it work (it expects non-standard
>> names for GCC). So I do not really like this solution.
>>
>
> In fact we can patch it to use $(CC), and pass it when we call these targets,
> and then we can drop the patch for the .S/.s files.
> The length of patch file will be much shorter.

If we figure out a command
   $(CROSS_TOOL)
which can has options like "mips64-linux gcc",
then the patch can be even shorter.

>
> Anyway, we will have to patch it.
> Wish my attached patch can change your mind. ;)
>
>> Another possibility, that I would prefer, is to treat mipsr6 as a different 
>> ABI
>> (which it actually is), adding the corresponding *.S files with a patch. Do 
>> you
>> think this is feasible?
>
> The patch work may be much bigger than the solution 1.
> and the patch will be much longer.
> If you still prefer this solution, I will try to figure out a patch.
>
>>
>> If not, then I think I still prefer to incorporate the first version of your
>> patch.
>>
>> --
>> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
>> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
>> ⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
>> ⠈⠳⣄  http://www.debian.org
>
>
>
> --
> YunQiang Su



-- 
YunQiang Su

Bug#893867: Solution not working for already installed 10.5.5 version

[Er_Maqui]

Hi,

I've checked, this solution does not work if you have installed or
half-installed already Gitlab 10.5.5.

Deleting manually the file, these error does not appears.

Regards,

http://maqui.darkbolt.net/
Linux registered user ~#363219
PGP keys avaiables at KeyServ. ID: 0x4233E9F2
Los hombres somos esclavos de la historia

Bug#893919: [Pkg-emacsen-addons] Bug#893919: RFS: yasnippet-snippets/0~git20180307.2b4c4d7e-3 [RC]

[Nicholas D Steeves]

Hi!

On Fri, Mar 23, 2018 at 02:27:15PM -0700, Sean Whitton wrote:
> Hello,
> 
> On Fri, Mar 23 2018, Nicholas D Steeves wrote:
> 
> > After many hours trying to work around bug #893598 while attempting to
> > transition yasnippet-snippets to a dummy package I have had to
> > conclude that yasnippet-snippets must remain the package that contains
> > the snippets until buster+1.
> 
> Please justify this conclusion.  Someone on debian-mentors might see a
> way out.
> 
> -- 
> Sean Whitton

I believe that it is preferable to have two packages with files that
upgrade without warnings than the alternative of a dummy package that
causes dpkg to emit warnings on upgrade.

I tried every combination of maintscript,
yasnippet-snippet.maintscript, and elpa-yasnippet.maintscript that I
could think of, a variety of postrm experiments, and a variety of ways
to treat the two packages in d/control.  With yasnippet-snippets as an
empty dummy package the following always occurred:

Unpacking yasnippet-snippets (0~git20180307.2b4c4d7e-3) over (0~git20161123-1) 
...
dpkg: warning: unable to delete old directory 
'/usr/share/yasnippet-snippets/tuareg-mode': Directory not empty
dpkg: warning: unable to delete old directory 
'/usr/share/yasnippet-snippets/scala-mode': Directory not empty
dpkg: warning: unable to delete old directory 
'/usr/share/yasnippet-snippets/ruby-mode': Directory not empty
dpkg: warning: unable to delete old directory 
'/usr/share/yasnippet-snippets/js-mode': Directory not empty
dpkg: warning: unable to delete old directory 
'/usr/share/yasnippet-snippets/clojure-mode': Directory not empty
dpkg: warning: unable to delete old directory
'/usr/share/yasnippet-snippets': Directory not empty

The one exception was when I even tried a yasnippet-snippet.postrm
which removed files from elpa-yasnippet-snippet...but that's an
unacceptable approach because a dummy package should be safe to remove
and shouldn't remove files from another package.

Given that these warnings go away when yasnippet-snippets contains the
snippets I have concluded that the snippets must remain as part of
this package for one release.  Given buster will have both an
elpa-yasnippet-snippets and a yasnippet-snippets package the most
significant reason against seems to be that users lose the ability to
remove a dummy package...

If someone sees a way around this, please ask if I've tried it :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#893934: openssh-client: Potentially unintended dependency on libbsd

[Guillem Jover]

Package: openssh-client
Version: 1:7.6p1-4
Severity: normal

Hi!

I just noticed that the latest version of this package depends on
libbsd0, which at first thought it was nice given my previous bug
request :), but then realized it was probably unintended when I
checked the actual sources. Here's the reasons why:

  * Build-Depends on libedit-dev, which pulls in libbsd-dev.
  * configure.ac uses AC_CHECK_LIB instead of AC_SEARCH_LIBS to
check for daemon(), which detects daemon() from glibc and
concludes that libsd is needed.

Thanks,
Guillem

Bug#893739: gettext: FTBFS with openjdk-9 as default-jdk

[Santiago Vila]

severity 893739 serious
thanks

Hi.

This is really a serious bug because it's a FTBFS bug.

The reason I bother to raise the severity even if I'm about to apply
the proposed patch in short is that there is yet another serious bug
around that would prevent the package from entering testing.

Hopefully the testing scripts will detect that this release has one
less serious bug than the previous one and will let it pass to buster.

Thanks.

Bug#892883: mirrors: Debian mirror opensource.nchc.org.tw: add as candidate of ftp.tw

[Steven Shiau]

On 2018年03月14日 11:14, Yao Wei (魏銘廷) wrote:
> Package: mirrors
> Severity: wishlist
> X-Debbugs-CC: debian-mirr...@lists.debian.org, Steven Shiau 
> , Ceasar Sun Chen-kai , Thomas 
> 
>
> Hi,
>
> As stated in the debian-mirrors mailing list, NCHC wants to list
> ftp.tw.debian.org as their primary mirror:
>
>   https://lists.debian.org/debian-mirrors/2018/03/msg0.html
>
> Also, according to the mirror status webpage:
>
>   https://mirror-master.debian.org/status/mirror-status.html
>
> NCHC needs to use ftpsync rather than typical rsync to sync the mirror,
> because of lacking sitetrace.
Thanks. If we follow the doc
https://salsa.debian.org/mirror-team/archvsync/, is it a must to receive
an update trigger for ftpsync? If so, which upstream do you recommend
and where is public key of that upstream?
Thank you very much.

Steven
>
> Yao Wei

-- 
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#893771: Fwd: [djvu:bugs] #288 Clearing highlights no longer works

[Leon Bottou]

--- Begin Message ---
Fixed (commit d12583)

In fact the bug has been there forever, but did not show because qt4 was less 
strict than the qt5 xcb driver in interpreting update areas. Lots of little 
annotation display bugs have been corrected.


---

** [bugs:#288] Clearing highlights no longer works**

**Status:** open
**Group:** djview
**Created:** Fri Mar 23, 2018 09:05 AM UTC by Janusz
**Last Updated:** Fri Mar 23, 2018 09:05 AM UTC
**Owner:** nobody


I would like to draw your attention to my bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893771.
To say the truth, I don't use djview4 often, but the relevant code is used in
https://bitbucket.org/mrudolf/djview-poliqarp/
and there I will be missing the feature very much (I don't use djview4poliqarp 
systematically, but when I use it, then I use it very intensively developing 
indexes for a digitalized dictionary).
I would be very happy to help to diagnose the problem, unfortunately my skills 
are rather limited (I tried to use git bisec but got quite confused).
Best regards
Janusz


---

Sent from sourceforge.net because you indicated interest in 




To unsubscribe from further messages, please visit 
--- End Message ---

Bug#893771: Fwd: [djvu:bugs] #288 Clearing highlights no longer works

[Leon Bottou]

Upstream says: 
Fixed (commit d12583)
In fact the bug has been there forever, but did not show because qt4 was less 
strict than the qt5 xcb driver in interpreting update areas. Lots of little 
annotation display bugs have been corrected.


---

Bug#893924: python3-distutils: Please describe road map/recommendations for users of distutils

[Simon McVittie]

On Sat, 24 Mar 2018 at 07:09:23 +0800, Matthias Klose wrote:
> On 24.03.2018 03:35, Simon McVittie wrote:
> > I assume there is a reason (size on disk? dependencies? update
> > frequency?) why most of distutils shouldn't be in -stdlib, but in the
> > absence of a reference in the changelog, I can only guess at why that is.
> 
> distutils is a build tool, and we should not need it in a runtime environment.
> It looks like .version is used too much in a runtime context, but that should 
> be
> the only subpackage used in a runtime context.  sysconfig should be preferred
> over distutils.sysconfig in python3.

Thanks. So is the motivation behind this change that you want to make
libpython3.x-stdlib have a smaller size on disk / in the archive?

smcv

Bug#893924: python3-distutils: Please describe road map/recommendations for users of distutils

[Simon McVittie]

On Fri, 23 Mar 2018 at 19:35:55 +, Simon McVittie wrote:
> When a small subset of distutils moved back, I assume that the
> intention was to un-break the relatively common(?) case of users of
> distutils.version that do not need the rest of the module, such as
> the gdbus-codegen tool in libglib2.0-dev-bin. However, it isn't clear
> whether the Python maintainers consider this to be a workaround to keep
> those packages working in the short term (in which case they need to
> pick up a new dependency on python3-distutils for the longer term), or
> whether distutils.version is going to remain part of the API of -stdlib
> in the long term (in which case packages like libglib2.0-dev-bin should
> not depend on the full -distutils package because that would negate the
> benefit of splitting it out).

Some notes from IRC:

 doko: I see you moved distutils.version back to
   libpython3.6-stdlib. is that temporary/transient, or is your
   intention that it goes back to being part of the ABI guaranteed
   by the python3 package?
 doko: (in other words, can packages like libglib2.0-dev-bin that
   only need distutils.version but not e.g. distutils.sysconf drop
   their dependency on python3-distutils again?)
 smcv: yes, .version should stay there. I wouldn't like .sysconfig
   there, because python3 has a proper sysconfig module, and glib2.0
   seems to prefer that one over .sysconfig

(I think doko mentioning sysconfig was a reference to its use in
the AM_PATH_PYTHON macro, which does indeed prefer sysconfig over
distutils.sysconfig - but libglib2.0-dev-bin also legitimately has a
runtime dependency on a small part of distutils, not just a build-time
dependency, because gdbus-codegen uses distutils.version.LooseVersion to
sort version numbers in a way that is predictable cross-platform.)

Also:

 What is the plan for finding all runtime dependencies on 
python3-distutils?
 bunk: good question. codesearch for "(from|import) *distutils"
   is the best I can think of?
and some subsequent discussion of how that codesearch will produce a
very large number of false positives (for example in AM_PATH_PYTHON),
which should be eliminated before filing bugs.

On Fri, 23 Mar 2018 at 20:30:17 +, Jeremy Stanley wrote:
> This may also serve to help narrow down (via reverse dependency) the
> list of packages which will trigger violent reactions when mixed in
> the same context with pip 10 invocations, per
> https://github.com/pypa/pip/issues/4805 .

Am I right in saying that there is a distutils limitation that means
the Python equivalent of "make uninstall" isn't reliable for packages
installed with distutils, and as a result, upstream developers want to
deprecate distutils?

While deprecating libraries that have unfixable problems is a reasonable
goal, I'm reasonably sure that installing a library with apt/dpkg and
uninstalling it with "sudo pip uninstall" is not something we (should)
aim to support? Or am I misunderstanding?

(Packages that were merely built with distutils won't normally depend
on distutils in any case, only build-depend.)

I thought the upstream Python maintainers strongly objected to the idea
of us installing something that claims to be Python but doesn't have
the complete Python standard library (in the interests of having Python
mean something predictable between OSs), but perhaps that information is
out of date and doesn't apply to distutils any more?

smcv

Bug#893933: Request for new mailing list: freedombox

[James Valleroy]

Package: lists.debian.org
Severity: wishlist

List Name
-

freedombox

Rationale
-

FreedomBox is is a pure blend of Debian and has been contributing to
Debian since 2011.

freedombox-disc...@lists.alioth.debian.org, has been the place for
discussions on decisions taken for the FreedomBox project. This is the
primary communication channel for hundreds of people participating in
the FreedomBox community.

Users also participate on the list to ask for support and developer
help. We have been exploring the setup for a web forum to handle support
requests and this list is likely to not receive much support requests in
future.

Short Description
-

Discussion on FreedomBox, a pure blend for private, inexpensive home
servers.

Long Description


Mailing list for discussion on development topics related to FreedomBox
and for providing user support.

FreedomBox is a free software self-hosting web server to deploy
decentralized applications on small machines at home. See
https://freedombox.org and https://wiki.debian.org/FreedomBox

Category


Developers

Subscription Policy
---

open

Post Policy
---

open

Web Archive
---

yes

Migration from existing list


We wish migration of member subscriptions and archives from the earlier
list freedombox-disc...@lists.alioth.debian.org.  Since posting this
information in bug report may not be appropriate, please let know how to
provide this data.

Bug#891872: transition: curl

[Dimitri John Ledkov]

On Fri, 2 Mar 2018 10:04:44 +0100 Emilio Pozuelo Monfort 
wrote:
> On 01/03/18 22:31, Alessandro Ghedini wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > Hello,
> >
> > I'd like to request a transition for curl in order to unblock the
migration
> > to OpenSSL 1.1 (#871056).
>
> Good!
>
> > This is necessary due to the fact that the curl ABI
> > exposes a structure inherited from libssl itself, which was changed in
the 1.1
> > update (see #844018 for more information).
> >
> > It is for the most part a clean ABI bump, however a few packages that
build
> > depend on both libcurl and libssl will need source uploads so they can
also
> > migrate to OpenSSL 1.1. The following packages were identified as part
of the
> > discussion in #858398:
> >
> > * hhvm: #858927 (sid-only)
> > * lastpass-cli: #858991
> > * libapache2-mod-auth-cas: 858992
> > * netsurf: #859230
> > * xmltooling: #859831
> > * zurl: #859841
>
> xmltooling / Shibboleth / xml-security-c don't seem ready yet. Apparently
there
> are patches upstream but there have been no new releases and they are not
easy
> to backport. I suppose at some point we'll need to stop blocking on them.
They
> can be fixed later and re-enter testing when that happens, there's still
plenty
> of time before the freeze.

Indeed xmltooling requires both openssl based curl, and openssl-1.0. In
Ubuntu, we did not manage to resolve it, hence I have uploaded "curl3"[0]
package into ubuntu that provides libcurl-openssl1.0-dev, which builds curl
against openssl1.0 and provides a library that xmltooling can link against.

This was done out of time constraints due to imminent Ubuntu release.
Ideally xmltooling should be ported to openssl-1.1 as a long term
maintainable solution.

Regards,

Dimitri.

[0] https://launchpad.net/ubuntu/+source/curl3/7.58.0-2ubuntu2

Bug#893120: debian-edu-install: uninstallable on ahrd disk thrice the size mentioned in manual

[Dominik George]

Hi,

> In Oslo we discussed about what should be the default desktop (being 
> MATE at that time); iirc we decided to keep KDE as default but to 
> recommend LXDE for LTSP clients. On the mailing lists there was feedback 
> (also after the Stretch release) that LXDE was well suited for LTSP. So 
> it's somehow known...

> […]

> KDE works quite well for profiles 'Standalone', 'Roaming-Workstation' 
> and 'Workstation'. Just for LTSP clients a decent desktop like KDE (or 
> GNOME) isn't really suited.

If MATE was the default, why was LXDE chosen?

Also, I do not think that MATE is not a "decent desktop".

For buster, please let's decide for one default for all, set that both
on the media and in the manual, and extra points for not diverting from
Debian's default ;).

-nik

-- 
Dominik George (1. Vorstandsvorsitzender, pädagogischer Leiter)
Teckids e.V. - Erkunden, Entdecken, Erfinden.
https://www.teckids.org/


signature.asc
Description: PGP signature

Bug#893924: python3-distutils: Please describe road map/recommendations for users of distutils

[Matthias Klose]

On 24.03.2018 03:35, Simon McVittie wrote:
> Package: python3-distutils
> Version: 3.6.5~rc1-2
> Severity: wishlist
> X-Debbugs-Cc: debian-pyt...@lists.debian.org
> 
> I'm confused about the current status of distutils, and what should be
> done by packages that depend on it to be as future-proof as possible. I
> don't think I'm the only one confused by this, so it would be very
> helpful if a maintainer could clarify what the intention is so that
> other maintainers can do the right things.
> 
> When structural changes like this are needed, I think it would
> be useful for them to be represented by a bug (perhaps of the form
> "libpython3.6-stdlib: should not contain distutils" or something similar)
> that gives the reasons for the structural change and describes the
> action that should be taken by maintainers of dependent packages. This
> bug could be referenced in the changelog and would be an obvious central
> coordination point for whatever changes are needed, including follow-ups
> if unforeseen fallout means the plan has to change. The release team
> would probably also appreciate it being treated as a transition so that
> they can plan around it.
> 
> Since that didn't happen in this case, I'm opening this bug in the hope
> that it can fulfil a similar role.
> 
> So far, the sequence of events goes something like this:
> 
> * 13 December 2017: distutils moves from -stdlib into its own package
> * 20 March 2018: -stdlib stops depending on distutils, packages start
>   to fail to build from source
> * 22-23 March 2018: A small subset of distutils (__init__.py and version.py)
>   moves back to -stdlib

and once the current dh-python package moves to testing, dh-python will gain a
dependency on python3-distutils.

> I assume there is a reason (size on disk? dependencies? update
> frequency?) why most of distutils shouldn't be in -stdlib, but in the
> absence of a reference in the changelog, I can only guess at why that is.

distutils is a build tool, and we should not need it in a runtime environment.
It looks like .version is used too much in a runtime context, but that should be
the only subpackage used in a runtime context.  sysconfig should be preferred
over distutils.sysconfig in python3.

> When a small subset of distutils moved back, I assume that the
> intention was to un-break the relatively common(?) case of users of
> distutils.version that do not need the rest of the module, such as
> the gdbus-codegen tool in libglib2.0-dev-bin. However, it isn't clear
> whether the Python maintainers consider this to be a workaround to keep
> those packages working in the short term (in which case they need to
> pick up a new dependency on python3-distutils for the longer term), or
> whether distutils.version is going to remain part of the API of -stdlib
> in the long term (in which case packages like libglib2.0-dev-bin should
> not depend on the full -distutils package because that would negate the
> benefit of splitting it out).
> 
> I'm aware that structural changes that break dependencies are sometimes
> necessary in pursuit of a goal (I've done them myself, most recently
> moving glib-compile-resources to libglib2.0-dev-bin for #885019), but
> when making them, having a plan visible to everyone is beneficial.
> Please could you clarify the situation?
> 
> Related bug reports include:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893755
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893847
> 
> Thanks,
> smcv
> 

Bug#893561: libtablelayout-java: license does not seem to meet the DFSG

[Francesco Poli]

On Thu, 22 Mar 2018 18:30:53 +0100 Markus Koschany wrote:

> Am 19.03.2018 um 22:28 schrieb Francesco Poli (wintermute):
[...]
> > I noticed that the license was
> > [discussed](https://lists.debian.org/debian-legal/2009/06/msg00050.html)
> > on debian-legal a long time ago.
> > My
> > [opinion](https://lists.debian.org/debian-legal/2009/06/msg00053.html)
> > was that at least two clauses fail to meet the DFSG.
> 
> In the end the ftp-team accepted the package into Debian and that is the
> only thing that counts.

Was the debian-legal discussion pointed out to the FTP Masters?
Did they explain the rationale behind their decision? 

> 
> > 
> > The debian/copyright file states, in part:
> > 
> > | The source code has been modified to make the package suitable for main 
> > (see
> > | license III. 4.). The package namespace has been changed from
> > | info.clearthought.layout to org.debian.tablelayout.
> > 
> > Personally, I don't think that applying a patch that changes the namespace
> > is enough to make the package suitable for Debian main.
> 
> This is certainly enough. We change the namespace all the time in Debian
> Java packages by using maven.rules for example. Also using patch files
> is explicitly allowed by DFSG 4.

The issue is not the requirement to modify the package through patch
files. Patch-only clauses are explicitly allowed by DFSG#4, as you
correctly point out.
As I have previously said, the issue is that the license forbids to
create a derived work that uses the info.clearthought namespace/package.

This goes beyond what is allowed by DFSG#4, which only talks about
patch files and requirements to change the *name* or the *version
number*.

> 
> > I mean: it's true that it is now possible to create drop-in replacements
> > for the Debian package (without further changing the namespace), but it is
> > still forbidden to create a modified version that changes the namespace
> > back to "info.clearthought".
> > 
> > I think that this restriction goes beyond what is allowed by DFSG#4.
> 
> This is your personal opinion. It was already discussed on debian-legal
> back in 2009 that the license is still acceptable and in the spirit of
> the DFSG.

Wait, it was indeed discussed on debian-legal back in 2009.

The thread is the very
[one](https://lists.debian.org/debian-legal/2009/06/msg00050.html)
I cited in my bug report.

There were two replies, one by Joe Smith and one by me.
Joe said that the license is acceptable and within the spirit of the
DFSG.
On the other hand, I said that two clauses fail to meet the DFSG.

Now, I respect Joe's opinion, but it's not clear to me why you claim
that *his* reply represents the outcome of the debian-legal discussion,
while *my* reply is just my personal opinion...

> 
> > Additionally, the license is clearly GPL-incompatible, which may
> > be an issue for other packages that link with this library.
> > 
> > Is it possible to persuade the upstream copyright holder to
> > drop clauses III.3 and III.4?
> > Or, even better, to re-license the library under well-vetted and
> > clearly DFSG-free terms, such as the
> > [Expat/MIT license](http://www.jclark.com/xml/copying.txt)
> > or the
> > [zlib license](http://www.zlib.net/zlib_license.html)
> > ?
> 
> No. We do not need to persuade the upstream copyright holder to change
> the license as long as the package was accepted by the ftp-team. If you
> think a package is GPL-incompatible

The license of libtablelayout-java is *clearly* GPL-incompatible, no
doubt about it.

It is a patch-only license and has restrictions on namespace change for
derived works.
These restrictions (and possibly other ones) are not included in the
GNU GPL v2 or v3, nor allowed by them.

> and you are not sure whether you can
> use it together with this library you should seek legal advice in your
> country. This is out-of-scope for Debian and as far as I am and the rest
> of the team are concerned, this is not an issue for us. Closing as
> not-a-bug.

It seems to be an issue for Debian: there are packages in Debian which
are GPL-licensed and link (directly or indirectly) with
libtablelayout-java.

Linking a GPL-licensed program or library with a GPL-incompatible
library requires special permission from the copyright holders of the
GPL-licensed program or library, as explain in the dedicated GPL
[FAQ](https://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat).

Some examples of GPL-licensed packages which link with
libtablelayout-java:

 • [jfractionlab](https://packages.debian.org/jfractionlab)
   [is 
GPL-v3-licensed](https://tracker.debian.org/media/packages/j/jfractionlab/copyright-0.91-3)
   without any special exception and is linked with libtablelayout-java

 • [sweethome3d](https://packages.debian.org/sweethome3d)
   [is 
GPL-v2-licensed](https://tracker.debian.org/media/packages/s/sweethome3d/copyright-5.7dfsg-2)
   without any special exception and is linked with libtablelayout-java
   (indirectly through 

Bug#893837: python-apt: FTBFS on all architectures (missing build-dep python3-distutils-extra?)

[Matthias Klose]

On 23.03.2018 16:12, Julian Andres Klode wrote:
> Control: clone -1 -2
> Control: reassign -2 python3.6 3.6.5~rc1-2
> Control: retitle -2 python3.6: uncoordinated dropping of python3-distutils 
> dep breaks builds
> 
> On Fri, Mar 23, 2018 at 08:59:14AM +0800, Boyuan Yang wrote:
>> Source: python-apt
>> Version: 1.6.0~rc1
>> Severity: grave
>> Justification: renders package unusable
>>
>> Dear Maintainer,
>>
>> python-apt 1.6.0~rc1 FTBFS on every architectures.
>>
>> Buildd logs indicate that a build-dependency (python3-distutils-extra) is
>> likely to be missing:
>>
>> dh clean --with python2,python3,sphinxdoc
>>dh_auto_clean
>> python2.7-dbg setup.py clean -a
>> running clean
>> 'build/lib.linux-x86_64-2.7-pydebug' does not exist -- can't clean it
>> 'build/bdist.linux-x86_64' does not exist -- can't clean it
>> 'build/scripts-2.7' does not exist -- can't clean it
>> python3.6-dbg setup.py clean -a
>> Traceback (most recent call last):
>>   File "setup.py", line 9, in 
>> from distutils.core import setup, Extension
>> ModuleNotFoundError: No module named 'distutils'
> 
> It says distutils.core, not distutils extra. And wooo
> 
>  python3.6 (3.6.5~rc1-2) unstable; urgency=medium
>  .
>* python3.6: Drop dependency on python3-distutils.
>* Fix issue #32305, libregrtest regression when backporting issue #32305.
>  Closes: #890621, #890844.
> 
> sigh.
> 

dh-python will gain a dependency on python3-distutils, so no need to change
anything on your side.

Bug#893932: RM: evas-loaders -- RoQA; binary package now built by src:efl

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

The libevas-loaders binary package is now built by src:efl,
therefore the obsolete src:evas-loaders should be removed.

Bug#890691: closed by michael.cru...@gmail.com (Michael R. Crusoe) (Bug#890691: fixed in ruby-crb-blast 0.6.9-1)

[Adrian Bunk]

Control: reopen -1

On Fri, Mar 02, 2018 at 04:21:13PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:ruby-bio package:
> 
> #890691: ruby-bio FTBFS with ruby 2.5
>...
>  ruby-crb-blast (0.6.9-1) unstable; urgency=medium
>  .
>* New upstream release. Tests pass again. (Closes: #890691)
>...

I don't know which bug this was supposed to close
(ruby-crb-blast still FTBFS, see #892066) likely
not this one in ruby-bio that still FTBFS:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-bio.html

cu
Adrian

-- 

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

Bug#891060: Atheros AR9271 ath9k_htc USB WiFi connected but IP traffic stops

[Ben Caradoc-Davies]

On 22/03/18 12:38, Ben Caradoc-Davies wrote:

Modified patch accepted upstream:
mac80211: add ieee80211_hw flag for QoS NDP support
https://patchwork.kernel.org/patch/10299025/
Also requires a new one-line patch from the module maintainer to turn on 
the new flag:

ath9k_htc: use non-QoS NDP for AP probing
https://patchwork.kernel.org/patch/10299031/
Patches attached. Note that the mac80211 patch for master will not apply 
to 4.15.x source which lacks TDLS_BUFFER_STA change; please use the 
backport version ("...-backport.patch) of the mac80211 patch, also 
attached, for 4.15.x, where it applies cleanly.


These two patches have been merged into mainline torvalds/master and 
should be included in 4.16-rc7:


mac80211: add ieee80211_hw flag for QoS NDP support
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7c181f4fcdc62e5dc7a87fd33387d322262c3b52

ath9k_htc: use non-QoS NDP for AP probing
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60b01bcce97191f473fa869df2713143936d6ef4

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#893504: Pending fixes for bugs in the javatools package

[pkg-java-maintainers]

tag 893504 + pending
thanks

Some bugs in the javatools package are closed in revision
80d345a9d7a164a2888513e6351bf5c7cbe89a1b in branch 'master' by Chris
Lamb

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/javatools.git/commit/?id=80d345a

Commit message:

Made the generated MANIFEST.MF files reproducible (Closes: #893504)

Bug#893931: jarwrapper: No longer use the d32/d64 options to detect the JVM data model

[Emmanuel Bourg]

Package: jarwrapper
Version: 0.62
Severity: important

jarwrapper uses the -d32/-d64 options to detect if the JVM is running
in 32 or 64 bits mode. Theses options are no longer working with Java 10.
An alternative querying the value of the sun.arch.data.model system
property must be implemented.

Bug#893902: w3m should not break some table cells' text into two lines when simple_preserve_space=1

[Tatsuya Kinoshita]

Control: retitle -1 w3m should not break some table cells' text into two lines 
when simple_preserve_space=1
Control: tags -1 + pending

On March 24, 2018 at 12:54AM +0800, jidanni (at jidanni.org) wrote:
> $ w3m -dump -no-graph t.html
> +---+
> |時刻 |X 車|Y 車|
> |-++|
> |08:30|交大 上 |交大 上 |
> | |客  |客  |
> +---+
>
> It should not insert a virtual  before the 客 on such short lines.

Fixed in the Git repo.

  - 
https://salsa.debian.org/debian/w3m/commit/73302179ea4119c4908892c0a3e725ab24a420fa

Thanks,
--
Tatsuya Kinoshita



pgp3bNhsBG_d9.pgp
Description: PGP signature

Bug#893930: mmm-mode: broken under XEmacs: Cannot open load file: cl-lib

[Aaron M. Ucko]

Package: mmm-mode
Version: 0.5.5-1
Severity: important

Byte-compiling mmm-mode 0.5.5 under XEmacs fails:

  Compiling /usr/share/xemacs21/site-lisp/mmm-mode/mmm-auto.el...
  While compiling toplevel forms in file 
/usr/share/xemacs21/site-lisp/mmm-mode/mmm-auto.el:
!! File error (("Cannot open load file" "cl-lib"))
  >>Error occurred processing mmm-auto.el: Cannot open load file: cl-lib
  [...]
  While compiling toplevel forms in file 
/usr/share/xemacs21/site-lisp/mmm-mode/mmm-vars.el:
!! File error (("Cannot open load file" "cl-lib"))
  >>Error occurred processing mmm-vars.el: Cannot open load file: cl-lib
  
  Done
  ERROR: install script from mmm-mode package failed
  dpkg: error processing package mmm-mode (--configure):
   installed mmm-mode package post-installation script subprocess returned 
error exit status 1

AFAICT, simply flipping the "require" lines back to (require 'cl)
(conditionally or otherwise) won't suffice, because there are also
corresponding code changes all over.  As such, you may wish to
consider ditching XEmacs support, and perhaps switching over to
dh-elpa while you're at it.  (dh-elpa already concerns itself
exclusively with GNU Emacs.)

Could you please take a look?

Thanks!

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

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

Versions of packages mmm-mode depends on:
ii  dpkg   1.19.0.5
ic  emacs23 [emacsen]  23.4+1-4.1+b1
ii  emacs24 [emacsen]  24.5+1-11+deb9u1
ii  emacs25 [emacsen]  25.2+1-6+b1
ii  emacsen-common 2.0.8
ii  install-info   6.5.0.dfsg.1-2
ii  xemacs21-basesupport   2009.02.17.dfsg.2-4
ii  xemacs21-mule [emacsen]21.4.24-5
ii  xemacs21-nomule [emacsen]  21.4.24-5

mmm-mode recommends no packages.

mmm-mode suggests no packages.

-- no debconf information

Bug#893919: [Pkg-emacsen-addons] Bug#893919: RFS: yasnippet-snippets/0~git20180307.2b4c4d7e-3 [RC]

[Sean Whitton]

Hello,

On Fri, Mar 23 2018, Nicholas D Steeves wrote:

> After many hours trying to work around bug #893598 while attempting to
> transition yasnippet-snippets to a dummy package I have had to
> conclude that yasnippet-snippets must remain the package that contains
> the snippets until buster+1.

Please justify this conclusion.  Someone on debian-mentors might see a
way out.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#893929: libqt4-dev-bin: kopete FTBFS

[Jiri Palecek]

Package: libqt4-dev-bin
Version: 4:4.8.7+dfsg-13
Severity: normal
Tags: patch
File: /usr/bin/moc-qt4

Dear Maintainer,

I tried to rebuild kopete from source and got errors such as these:

Generating s5b.moc
/mnt/extras/src/kopete-17.08.3/protocols/jabber/libiris/src/irisnet/noncore/cutestuff/bytestream.h:52:
 Parse error at "defined"

Apparently this is caused by a nonconformity of moc's preprocessor which
manifests itself when macro

major(arg)

is defined, as, unfortunately file  does. The line 52
in the error message refers to a line in this particular file (not in
the file it reports, which is a bit confusing.

This has been noted before. I have found a rethat bugreprot of the same
problem here: https://bugzilla.redhat.com/show_bug.cgi?id=1396755. Their
solution is to work it around by a hack that filters that particular
include out. A proper fix would be to make the preprocessor correct, but
that would require too much work.

Therefore, I propose this patch, that, in line with redhat hacks it
around. I've checked that with the patch, kopete builds successfully.

Index: qt4-x11-4.8.7+dfsg/src/tools/moc/main.cpp
===
--- qt4-x11-4.8.7+dfsg.orig/src/tools/moc/main.cpp
+++ qt4-x11-4.8.7+dfsg/src/tools/moc/main.cpp
@@ -191,6 +191,7 @@ int runMoc(int _argc, char **_argv)
 // Workaround a bugs while parsing some boost headers. See QTBUG-22829 
 pp.macros["BOOST_TT_HAS_OPERATOR_HPP_INCLUDED"];
 pp.macros["BOOST_LEXICAL_CAST_INCLUDED"];
+pp.macros["_SYS_SYSMACROS_H_OUTER"];
 
 QByteArray filename;
 QByteArray output;

Regards
Jiri Palecek

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.14.0-rc3-bughunt (SMP w/2 CPU cores)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libqt4-dev-bin depends on:
ii  libc6  2.27-2
ii  libgcc11:8-20180312-2
ii  libqt4-qt3support  4:4.8.7+dfsg-13.1
ii  libqt4-xml 4:4.8.7+dfsg-13.1
ii  libqtcore4 4:4.8.7+dfsg-13.1
ii  libqtdbus4 4:4.8.7+dfsg-13.1
ii  libqtgui4  4:4.8.7+dfsg-13.1
ii  libstdc++6 8-20180312-2
ii  qtchooser  64-ga1b6736-4
ii  zlib1g 1:1.2.8.dfsg-5

libqt4-dev-bin recommends no packages.

libqt4-dev-bin suggests no packages.

-- no debconf information

Bug#893120: debian-edu-install: uninstallable on ahrd disk thrice the size mentioned in manual

[Wolfgang Schweer]

On Fri, Mar 23, 2018 at 08:18:19PM +, Holger Levsen wrote:
> On Mon, Mar 19, 2018 at 11:58:52PM +0100, Wolfgang Schweer wrote:
> > On Mon, Mar 19, 2018 at 01:21:33PM +, Holger Levsen wrote:
> > > isnt this bug a manifestation of three bugs:
> > As far as I can tell: only sort of. In the first place the bug shows 
> > that communicating how to install different profiles could be better. 
> > Maybe there should be BIG and FAT hints; but it might be wishful 
> > thinking this could make a difference.
>  
> I'm not sure why you advocate only documenting this in the manual,
> instead of changing the default…

The default desktop is set as kernel command line param. This is done 
when the ISO image is generated (see e.g. CONF-stretch-usbstick.sh for 
the BD ISO image). So no way to change it now.

In Oslo we discussed about what should be the default desktop (being 
MATE at that time); iirc we decided to keep KDE as default but to 
recommend LXDE for LTSP clients. On the mailing lists there was feedback 
(also after the Stretch release) that LXDE was well suited for LTSP. So 
it's somehow known...
 
> maybe we can use the minidebconf in hamburg to get usuable
> debian-edu-buster images build on debian.org infrastructure…

sounds good.
 
> > > 2. ltsp default should be lxde clients
> > LTSP thin clients need LXDE (or another lightweiht DE like Xfce or MATE) 
> > on the server side as well; so IMO the recommondatation in the manual 
> > install chapter (use 'desktop=lxde') is already the right solution.
> 
> again: my suggestion was to change the default because KDE is broken. I
> really dont get why you suggest to keep KDE and then to document that
> people should not use it.

KDE works quite well for profiles 'Standalone', 'Roaming-Workstation' 
and 'Workstation'. Just for LTSP clients a decent desktop like KDE (or 
GNOME) isn't really suited.

Wolfgang



signature.asc
Description: PGP signature

Bug#854545: dvb-usb not working with kernel compiled from linux-source-4.9.2-2~bpo8+1

[Matthieu]

Package: src:linux
Version: 4.9.82-1+deb9u3
Followup-For: Bug #854545

Dear Maintainer,

with the current kernel, my DVB-T adaptater no longer work.

It seems related to the error "transfer buffer not dma capable".

Regards

-- Package-specific info:
** Version:
Linux version 4.9.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-amd64 
root=UUID=426ca88b-4a62-4386-ba38-2dc4aa367bed ro quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:

[   11.281807] dvb-usb: found a 'LITE-ON USB2.0 DVB-T Tuner' in warm state.
[   11.281935] dvb-usb: will pass the complete MPEG2 transport stream to the 
software demuxer.
[   11.286085] DVB: registering new adapter (LITE-ON USB2.0 DVB-T Tuner)
[   12.292699] [ cut here ]
[   12.292729] WARNING: CPU: 3 PID: 29 at 
/build/linux-YDazDa/linux-4.9.82/drivers/usb/core/hcd.c:1587 
usb_hcd_map_urb_for_dma+0x394/0x590 [usbc
ore]
[   12.292730] transfer buffer not dma capable
[   12.292731] Modules linked in: dvb_usb_dibusb_mc dvb_usb_dibusb_mc_common 
dvb_usb_dibusb_common hid_generic dib3000mc dibx000_common dvb_usb 
dvb_core rc_core usbhid hid intel_powerclamp coretemp kvm_intel amdkfd kvm 
radeon snd_hda_codec_realtek snd_hda_codec_generic irqbypass snd_hda_
intel snd_hda_codec snd_hda_core iTCO_wdt iTCO_vendor_support ttm snd_hwdep 
hp_wmi sparse_keymap rfkill drm_kms_helper evdev snd_pcm drm serio_r
aw i2c_algo_bit pcspkr crct10dif_pclmul snd_timer crc32_pclmul snd 
ghash_clmulni_intel intel_cstate intel_uncore soundcore shpchp button lpc_ich
 mfd_core mei_me mei sg wmi tpm_infineon acpi_cpufreq sunrpc parport_pc ppdev 
lp parport ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_gener
ic fscrypto ecb mbcache sr_mod cdrom sd_mod crc32c_intel aesni_intel ahci 
aes_x86_64 glue_helper
[   12.292811]  lrw gf128mul libahci ablk_helper cryptd libata psmouse ehci_pci 
ehci_hcd scsi_mod e1000e usbcore ptp usb_common pps_core
[   12.292830] CPU: 3 PID: 29 Comm: kworker/3:0 Not tainted 4.9.0-6-amd64 #1 
Debian 4.9.82-1+deb9u3
[   12.292832] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF 
PC/304Ah, BIOS 786H1 v01.05 06/09/2010
[   12.292845] Workqueue: usb_hub_wq hub_event [usbcore]
[   12.292846]   ac92e074 b92080d7b550 

[   12.292848]  ac6776be 8ffd8e7b1d80 b92080d7b5a8 

[   12.292849]  b92080d7b76c 8ffd8d5f5000 0002 
ac67773f
[   12.292851] Call Trace:
[   12.292856]  [] ? dump_stack+0x5c/0x78
[   12.292859]  [] ? __warn+0xbe/0xe0
[   12.292861]  [] ? warn_slowpath_fmt+0x5f/0x80
[   12.292863]  [] ? lock_timer_base+0x74/0x90
[   12.292869]  [] ? usb_hcd_map_urb_for_dma+0x394/0x590 
[usbcore]
[   12.292870]  [] ? try_to_del_timer_sync+0x4d/0x80
[   12.292875]  [] ? usb_hcd_submit_urb+0x34d/0xaf0 [usbcore]
[   12.292877]  [] ? del_timer_sync+0x50/0x50
[   12.292878]  [] ? list_del+0x9/0x30
[   12.292884]  [] ? usb_start_wait_urb+0xaa/0x170 [usbcore]
[   12.292889]  [] ? usb_start_wait_urb+0x6d/0x170 [usbcore]
[   12.292892]  [] ? dvb_usb_generic_rw+0x157/0x1c0 [dvb_usb]
[   12.292894]  [] ? dibusb_i2c_msg+0xcf/0x130 
[dvb_usb_dibusb_common]
[   12.292896]  [] ? dibusb_i2c_xfer+0x129/0x140 
[dvb_usb_dibusb_common]
[   12.292898]  [] ? __i2c_transfer+0x10e/0x3e0
[   12.292899]  [] ? dvb_usb_start_feed+0x10/0x10 [dvb_usb]
[   12.292901]  [] ? dvb_usb_fe_sleep+0x50/0x50 [dvb_usb]
[   12.292902]  [] ? i2c_transfer+0x5d/0xc0
[   12.292904]  [] ? dib3000mc_read_word+0x9a/0x100 
[dib3000mc]
[   12.292905]  [] ? dib3000mc_identify+0x14/0x100 [dib3000mc]
   12.292907]  [] ? dib3000mc_attach+0x68/0x460 [dib3000mc]
[   12.292908]  [] ? 
dibusb_dib3000mc_frontend_attach+0x4b/0x150 [dvb_usb_dibusb_mc_common]
[   12.292910]  [] ? dvb_usb_adapter_frontend_init+0xe6/0x190 
[dvb_usb]
[   12.292911]  [] ? dvb_usb_device_init+0x4e9/0x660 [dvb_usb]
[   12.292917]  [] ? usb_probe_interface+0x162/0x2c0 [usbcore]
[   12.292919]  [] ? driver_probe_device+0x223/0x430
[   12.292920]  [] ? __driver_attach+0xe0/0xe0
[   12.292923]  [] ? bus_for_each_drv+0x64/0xb0
[   12.292924]  [] ? __device_attach+0xd9/0x150
[   12.292925]  [] ? bus_probe_device+0x8a/0xa0
[   12.292927]  [] ? device_add+0x36b/0x620
[   12.292932]  [] ? usb_set_configuration+0x5c8/0x8c0 
[usbcore]
[   12.292938]  [] ? generic_probe+0x28/0x80 [usbcore]
[   12.292939]  [] ? driver_probe_device+0x223/0x430
[   12.292940]  [] ? __driver_attach+0xe0/0xe0
[   12.292941]  [] ? bus_for_each_drv+0x64/0xb0
[   12.292942]  [] ? __device_attach+0xd9/0x150
[   12.292943]  [] ? bus_probe_device+0x8a/0xa0
[   12.292945]  [] ? device_add+0x36b/0x620
[   12.292950]  [] ? usb_new_device+0x263/0x470 [usbcore]
[   12.292955]  [] ? hub_event+0xbfc/0x15c0 [usbcore]
[   12.292957]  [] ? process_one_work+0x18a/0x420
[   12.292958]  [] ? worker_thread+0x4d/0x490
[   12.292959]  [] ? 

Bug#893928: libgoogle-perftools-dev: Support multi-arch

[Camil Staps]

Package: libgoogle-perftools-dev
Version: 2.5-2.2
Severity: normal

Dear Maintainer,

Currently it is not possible to install both the i386 and the amd64
version of this package. My use case for this is that I develop a
program and build it for both platforms and want to profile both
versions.

When I have the amd64 version installed, apt will not let me install the
i386 version, and vice versa. I initially asked a question about this on
the Unix/Linux Stack Exchange:
https://unix.stackexchange.com/q/433101/37050

Apparently, the control file has to be changed to allow for this
situation. I do not know if there are technical reasons that this is
currently not possible, or that it is just an organisational matter.

Many thanks for your time.
If an update to the package in Stretch is possible that would be great,
but I don't know what the policies are.

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

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

Versions of packages libgoogle-perftools-dev depends on:
ii  libgoogle-perftools4  2.5-2.2
ii  libtcmalloc-minimal4  2.5-2.2
ii  libunwind8-dev1.1-4.1

libgoogle-perftools-dev recommends no packages.

libgoogle-perftools-dev suggests no packages.

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#893924: python3-distutils: Please describe road map/recommendations for users of distutils

[Jeremy Stanley]

This may also serve to help narrow down (via reverse dependency) the
list of packages which will trigger violent reactions when mixed in
the same context with pip 10 invocations, per
https://github.com/pypa/pip/issues/4805 .
-- 
Jeremy Stanley

Bug#893921: libharu: add support for free-form triangle shading objects

[Kyle Edwards]

We have not submitted this patch to any other distros, and none that we 
know of have included it (I don't see it in Ubuntu or RedHat.) Would it 
be acceptable for us to create a "For Debian" branch on our Gitlab 
libharu repository so you can pull from that?



On 03/23/2018 03:41 PM, Johan Van de Wauw wrote:

Pull request with discussion here:
https://github.com/libharu/libharu/pull/157

Has this been implemented by other distro's?

If kitware can support VTK, perhaps they can invest some time in 
proposing a new release with some of the other pull requests? I think 
this is a better way forward for the community than having maintainers 
of different distro's having to add patches to support features.


On Fri, Mar 23, 2018 at 8:19 PM, Kyle Edwards 
> wrote:


Source: libharu
Severity: wishlist
Tags: patch

Dear Maintainer,

I am working on an official Kitware-supported Debian/Ubuntu
package for
the upcoming VTK 9. We are using a custom shading feature developed
in-house for libharu. We have submitted our changes upstream, but the
project has been abandoned and the patch will most likely never be
accepted. Please backport the included patch so that we can bring
VTK 9
to Debian. Thank you for your support.


***
patches/0001-Add-support-for-free-form-triangle-Shading-objects.patch
From 9e8ba2f5453552909e52fde5ec30856004a616d0 Mon Sep 17 00:00:00 2001
From: "David C. Lonie" >
Date: Wed, 10 May 2017 11:07:28 -0400
Subject: [PATCH] Add support for free-form triangle Shading objects.

---
 include/hpdf.h           |  24 -
 include/hpdf_error.h     |   3 +
 include/hpdf_objects.h   |   2 +
 include/hpdf_pages.h     |   5 +
 include/hpdf_types.h     |  14 +++
 src/CMakeLists.txt       |   1 +
 src/hpdf_page_operator.c |  31 +++
 src/hpdf_pages.c         |  55 ++-
 src/hpdf_shading.c       | 231
+++
 9 files changed, 362 insertions(+), 4 deletions(-)
 create mode 100644 src/hpdf_shading.c

diff --git a/include/hpdf.h b/include/hpdf.h
index e369f67..40e3c41 100644
--- a/include/hpdf.h
+++ b/include/hpdf.h
@@ -77,6 +77,7 @@ typedef HPDF_HANDLE   HPDF_Dict;
 typedef HPDF_HANDLE   HPDF_EmbeddedFile;
 typedef HPDF_HANDLE   HPDF_OutputIntent;
 typedef HPDF_HANDLE   HPDF_Xref;
+typedef HPDF_HANDLE   HPDF_Shading;

 #else

@@ -1171,6 +1172,11 @@ HPDF_EXPORT(HPDF_STATUS)
 HPDF_Page_SetExtGState  (HPDF_Page        page,
                          HPDF_ExtGState   ext_gstate);

+/* sh */
+HPDF_EXPORT(HPDF_STATUS)
+HPDF_Page_SetShading  (HPDF_Page    page,
+                       HPDF_Shading shading);
+

 /*--- Special graphic state operator
--*/

@@ -1450,7 +1456,23 @@ HPDF_Page_SetCMYKStroke  (HPDF_Page page,

 /*--- Shading patterns
---*/

-/* sh --not implemented yet */
+/* Notes for docs:
+ * - ShadingType must be HPDF_SHADING_FREE_FORM_TRIANGLE_MESH
(the only
+ *   defined option...)
+ * - colorSpace must be HPDF_CS_DEVICE_RGB for now.
+ */
+HPDF_EXPORT(HPDF_Shading)
+HPDF_Shading_New  (HPDF_Doc         pdf,
+                   HPDF_ShadingType type,
+                   HPDF_ColorSpace  colorSpace,
+                   HPDF_REAL xMin, HPDF_REAL xMax,
+                   HPDF_REAL yMin, HPDF_REAL yMax);
+
+HPDF_EXPORT(HPDF_STATUS)
+HPDF_Shading_AddVertexRGB(HPDF_Shading shading,
+                         
HPDF_Shading_FreeFormTriangleMeshEdgeFlag edgeFlag,
+                          HPDF_REAL x, HPDF_REAL y,
+                          HPDF_UINT8 r, HPDF_UINT8 g, HPDF_UINT8 b);

 /*--- In-line images
-*/

diff --git a/include/hpdf_error.h b/include/hpdf_error.h
index b04e2cd..ef4fa61 100644
--- a/include/hpdf_error.h
+++ b/include/hpdf_error.h
@@ -145,6 +145,9 @@ extern "C" {
 #define HPDF_INVALID_U3D_DATA                     0x1083
 #define HPDF_NAME_CANNOT_GET_NAMES                0x1084
 #define HPDF_INVALID_ICC_COMPONENT_NUM            0x1085
+/*                                                0x1086 */
+/*                                                0x1087 */
+#define HPDF_INVALID_SHADING_TYPE                 0x1088

 
/*---*/

diff --git a/include/hpdf_objects.h b/include/hpdf_objects.h
index 525adda..b16de02 100644
--- a/include/hpdf_objects.h
+++ b/include/hpdf_objects.h
@@ -61,6 +61,7 @@ extern "C" {
 #define  HPDF_OSUBCLASS_EXT_GSTATE_R  0x0B00  /* read only 

Bug#893120: debian-edu-install: uninstallable on ahrd disk thrice the size mentioned in manual

[Holger Levsen]

On Mon, Mar 19, 2018 at 11:58:52PM +0100, Wolfgang Schweer wrote:
> On Mon, Mar 19, 2018 at 01:21:33PM +, Holger Levsen wrote:
> > isnt this bug a manifestation of three bugs:
> As far as I can tell: only sort of. In the first place the bug shows 
> that communicating how to install different profiles could be better. 
> Maybe there should be BIG and FAT hints; but it might be wishful 
> thinking this could make a difference.
 
I'm not sure why you advocate only documenting this in the manual,
instead of changing the default…

> > 1. netinst image needs to be redone to include updated packages.
> Yes, this would solve the problem for now.
> >(can we build images using stable-proposed-updates?)
> No idea; also: is there enough space available on ftp.s.no? In general 
> it would be nice to have the ISOs updated after each stable point 
> release.

oh, yes, sigh. no idea about diskspace on ftp/a.s.no, but this is
definitly demotivating. (the diskspace issues on that machine have been
a problem for 10 years now.)

maybe we can use the minidebconf in hamburg to get usuable
debian-edu-buster images build on debian.org infrastructure…

> > 2. ltsp default should be lxde clients
> LTSP thin clients need LXDE (or another lightweiht DE like Xfce or MATE) 
> on the server side as well; so IMO the recommondatation in the manual 
> install chapter (use 'desktop=lxde') is already the right solution.

again: my suggestion was to change the default because KDE is broken. I
really dont get why you suggest to keep KDE and then to document that
people should not use it.

> > 3. insufficient diskspace^wfree space on partitions, in general and esp.
> >for kde ltsp clients
> IMO this is only a follow-up problem (and affecting only Stretch).

ok.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#884929: Please proceed to remove Drupal7 - Dependencies have been removed; big security problem upcoming

[Gunnar Wolf]

Hi,

I have been notified that drupal7-mod-civicrm is finally no longer
built, so the last rdep on drupal7 has been cleared.

The Drupal developers have issued a preventive warning, informing they
will publish a highly critical bug fix for Drupal 7 and 8.x next
Wednesday.

I will update the Drupal versions in stable and olstable, but it would
be great if it could be removed from Unstable by then.

Of course, I will provide updated packages otherwise.

Thank you very much,


signature.asc
Description: PGP signature

Bug#893927: mark python-ply Multi-Arch: foreign

[Helmut Grohne]

Package: python-ply
Version: 3.11-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:firefox src:firefox-esr src:libgap-sage src:nml

The affected packages cannot satify their cross Build-Depends, because
their transitive dependency on python-ply or python3-ply is
unsatisfiable. In general, Architecture: all packages can never satify
cross Build-Depends unless marked Multi-Arch: foreign. In these cases,
the only source of architecture-dependence is the Python byte
compilation, because there are no dependencies other than python and
their maintainer scripts do nothing but performing the byte compilation.
Still, python-ply is usable even without byte compiled files, so foreign
embedded interpreters (a very rare use case) continues to work. Marking
them Multi-Arch: foreign is a reasonable trade-off. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru ply-3.11/debian/changelog ply-3.11/debian/changelog
--- ply-3.11/debian/changelog   2018-02-21 19:37:19.0 +0100
+++ ply-3.11/debian/changelog   2018-03-23 21:04:41.0 +0100
@@ -1,3 +1,10 @@
+ply (3.11-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark all packages Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 23 Mar 2018 21:04:41 +0100
+
 ply (3.11-1) unstable; urgency=medium
 
   [ Stefano Rivera ]
diff --minimal -Nru ply-3.11/debian/control ply-3.11/debian/control
--- ply-3.11/debian/control 2018-02-21 19:37:19.0 +0100
+++ ply-3.11/debian/control 2018-03-23 21:04:24.0 +0100
@@ -19,6 +19,7 @@
 
 Package: python-ply
 Architecture: all
+Multi-Arch: foreign
 Depends: ${python:Depends}, ${misc:Depends}
 Provides: ${python:Provides}, ${python-ply:Provides}
 Breaks: ${python:Breaks}
@@ -39,6 +40,7 @@
 
 Package: python3-ply
 Architecture: all
+Multi-Arch: foreign
 Depends: ${python3:Depends}, ${misc:Depends}
 Provides: ${python3:Provides}, ${python3-ply:Provides}
 Breaks: ${python3:Breaks}
@@ -60,6 +62,7 @@
 Package: python-ply-doc
 Section: doc
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: Lex and Yacc implementation for Python (documentation)
  PLY   is   yet  another   implementation   of   lex   and  yacc   for

Bug#893921: libharu: add support for free-form triangle shading objects

[Johan Van de Wauw]

Pull request with discussion here:
https://github.com/libharu/libharu/pull/157

Has this been implemented by other distro's?

If kitware can support VTK, perhaps they can invest some time in proposing
a new release with some of the other pull requests? I think this is a
better way forward for the community than having maintainers of different
distro's having to add patches to support features.

On Fri, Mar 23, 2018 at 8:19 PM, Kyle Edwards 
wrote:

> Source: libharu
> Severity: wishlist
> Tags: patch
>
> Dear Maintainer,
>
> I am working on an official Kitware-supported Debian/Ubuntu package for
> the upcoming VTK 9. We are using a custom shading feature developed
> in-house for libharu. We have submitted our changes upstream, but the
> project has been abandoned and the patch will most likely never be
> accepted. Please backport the included patch so that we can bring VTK 9
> to Debian. Thank you for your support.
>
>
> *** patches/0001-Add-support-for-free-form-triangle-Shading-objects.patch
> From 9e8ba2f5453552909e52fde5ec30856004a616d0 Mon Sep 17 00:00:00 2001
> From: "David C. Lonie" 
> Date: Wed, 10 May 2017 11:07:28 -0400
> Subject: [PATCH] Add support for free-form triangle Shading objects.
>
> ---
>  include/hpdf.h   |  24 -
>  include/hpdf_error.h |   3 +
>  include/hpdf_objects.h   |   2 +
>  include/hpdf_pages.h |   5 +
>  include/hpdf_types.h |  14 +++
>  src/CMakeLists.txt   |   1 +
>  src/hpdf_page_operator.c |  31 +++
>  src/hpdf_pages.c |  55 ++-
>  src/hpdf_shading.c   | 231 ++
> +
>  9 files changed, 362 insertions(+), 4 deletions(-)
>  create mode 100644 src/hpdf_shading.c
>
> diff --git a/include/hpdf.h b/include/hpdf.h
> index e369f67..40e3c41 100644
> --- a/include/hpdf.h
> +++ b/include/hpdf.h
> @@ -77,6 +77,7 @@ typedef HPDF_HANDLE   HPDF_Dict;
>  typedef HPDF_HANDLE   HPDF_EmbeddedFile;
>  typedef HPDF_HANDLE   HPDF_OutputIntent;
>  typedef HPDF_HANDLE   HPDF_Xref;
> +typedef HPDF_HANDLE   HPDF_Shading;
>
>  #else
>
> @@ -1171,6 +1172,11 @@ HPDF_EXPORT(HPDF_STATUS)
>  HPDF_Page_SetExtGState  (HPDF_Pagepage,
>   HPDF_ExtGState   ext_gstate);
>
> +/* sh */
> +HPDF_EXPORT(HPDF_STATUS)
> +HPDF_Page_SetShading  (HPDF_Pagepage,
> +   HPDF_Shading shading);
> +
>
>  /*--- Special graphic state operator --
> */
>
> @@ -1450,7 +1456,23 @@ HPDF_Page_SetCMYKStroke  (HPDF_Page  page,
>
>  /*--- Shading patterns --
> -*/
>
> -/* sh --not implemented yet */
> +/* Notes for docs:
> + * - ShadingType must be HPDF_SHADING_FREE_FORM_TRIANGLE_MESH (the only
> + *   defined option...)
> + * - colorSpace must be HPDF_CS_DEVICE_RGB for now.
> + */
> +HPDF_EXPORT(HPDF_Shading)
> +HPDF_Shading_New  (HPDF_Doc pdf,
> +   HPDF_ShadingType type,
> +   HPDF_ColorSpace  colorSpace,
> +   HPDF_REAL xMin, HPDF_REAL xMax,
> +   HPDF_REAL yMin, HPDF_REAL yMax);
> +
> +HPDF_EXPORT(HPDF_STATUS)
> +HPDF_Shading_AddVertexRGB(HPDF_Shading shading,
> +  HPDF_Shading_FreeFormTriangleMeshEdgeFlag
> edgeFlag,
> +  HPDF_REAL x, HPDF_REAL y,
> +  HPDF_UINT8 r, HPDF_UINT8 g, HPDF_UINT8 b);
>
>  /*--- In-line images --
> ---*/
>
> diff --git a/include/hpdf_error.h b/include/hpdf_error.h
> index b04e2cd..ef4fa61 100644
> --- a/include/hpdf_error.h
> +++ b/include/hpdf_error.h
> @@ -145,6 +145,9 @@ extern "C" {
>  #define HPDF_INVALID_U3D_DATA 0x1083
>  #define HPDF_NAME_CANNOT_GET_NAMES0x1084
>  #define HPDF_INVALID_ICC_COMPONENT_NUM0x1085
> +/*0x1086 */
> +/*0x1087 */
> +#define HPDF_INVALID_SHADING_TYPE 0x1088
>
>  /*--
> -*/
>
> diff --git a/include/hpdf_objects.h b/include/hpdf_objects.h
> index 525adda..b16de02 100644
> --- a/include/hpdf_objects.h
> +++ b/include/hpdf_objects.h
> @@ -61,6 +61,7 @@ extern "C" {
>  #define  HPDF_OSUBCLASS_EXT_GSTATE_R  0x0B00  /* read only object */
>  #define  HPDF_OSUBCLASS_NAMEDICT  0x0C00
>  #define  HPDF_OSUBCLASS_NAMETREE  0x0D00
> +#define  HPDF_OSUBCLASS_SHADING   0x0E00
>
>
>
> @@ -595,6 +596,7 @@ typedef HPDF_Array HPDF_Destination;
>  typedef HPDF_Dict  HPDF_U3D;
>  typedef HPDF_Dict  HPDF_OutputIntent;
>  typedef HPDF_Dict  HPDF_JavaScript;
> +typedef HPDF_Dict  HPDF_Shading;
>
>  #ifdef __cplusplus
>  }
> diff --git a/include/hpdf_pages.h b/include/hpdf_pages.h
> index 44b816c..60b1d84 100644
> --- a/include/hpdf_pages.h
> +++ b/include/hpdf_pages.h
> @@ -55,6 +55,7 

Bug#893926: mark projectm-data Multi-Arch: foreign

[Helmut Grohne]

Package: projectm-data
Version: 2.1.0+dfsg-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:clementine src:qmmp

The affected packages fail to cross build from source, because their
transitive dependency on projectm-data is unsatisfiable. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign. In this case, such a marking is correct,
because projectm-data is a data package without any dependencies or
maintainer scripts. Please consider applying the attached patch.

Helmut
diff --minimal -Nru projectm-2.1.0+dfsg/debian/changelog 
projectm-2.1.0+dfsg/debian/changelog
--- projectm-2.1.0+dfsg/debian/changelog2016-07-28 23:25:07.0 
+0200
+++ projectm-2.1.0+dfsg/debian/changelog2018-03-23 20:54:13.0 
+0100
@@ -1,3 +1,10 @@
+projectm (2.1.0+dfsg-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark projectm-data Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 23 Mar 2018 20:54:13 +0100
+
 projectm (2.1.0+dfsg-4) unstable; urgency=medium
 
   * Acknowledge NMU
diff --minimal -Nru projectm-2.1.0+dfsg/debian/control 
projectm-2.1.0+dfsg/debian/control
--- projectm-2.1.0+dfsg/debian/control  2016-07-28 23:12:18.0 +0200
+++ projectm-2.1.0+dfsg/debian/control  2018-03-23 20:53:51.0 +0100
@@ -57,6 +57,7 @@
 
 Package: projectm-data
 Architecture: all
+Multi-Arch: foreign
 Section: libs
 Replaces: libprojectm-data (<< 2.0.1)
 Breaks: libprojectm-data (<< 2.0.1)

Bug#893925: imagemagick: drop libtool-bin from Build-Depends

[Helmut Grohne]

Source: imagemagick
Version: 8:6.9.9.34+dfsg-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Please drop libtool-bin from Build-Depends. We want to remove that
package from unstable. It contains a pre-configured libtool. If you want
to use libtool, please use the libtool package and run libtoolize. In
this case, it seems that the dependency is entirely unused as a build
without it succeeds. Please consider applying the attached patch.

Helmut
diff --minimal -Nru imagemagick-6.9.9.34+dfsg/debian/changelog 
imagemagick-6.9.9.34+dfsg/debian/changelog
--- imagemagick-6.9.9.34+dfsg/debian/changelog  2018-02-18 00:12:41.0 
+0100
+++ imagemagick-6.9.9.34+dfsg/debian/changelog  2018-03-23 20:34:51.0 
+0100
@@ -1,3 +1,10 @@
+imagemagick (8:6.9.9.34+dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused Build-Depends: libtool-bin. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 23 Mar 2018 20:34:51 +0100
+
 imagemagick (8:6.9.9.34+dfsg-3) unstable; urgency=high
 
   * Upload to unstable (urgency high due to security issues).
diff --minimal -Nru imagemagick-6.9.9.34+dfsg/debian/control 
imagemagick-6.9.9.34+dfsg/debian/control
--- imagemagick-6.9.9.34+dfsg/debian/control2018-02-18 00:12:41.0 
+0100
+++ imagemagick-6.9.9.34+dfsg/debian/control2018-03-23 20:34:50.0 
+0100
@@ -36,8 +36,6 @@
  pkg-kde-tools,
 # for libgomp symbols
  dpkg-dev (>= 1.17.6),
-# for test of poc
- libtool-bin
 # for documentation
 Build-Depends-Indep: doxygen, doxygen-latex, graphviz,
 libxml2-utils,

Bug#822635: udev rules for USB device access effective at boot, but not on hotplug

[Josh Triplett]

On Fri, Mar 23, 2018 at 05:17:11PM +0100, Michael Biebl wrote:
> On Mon, 22 Jan 2018 18:10:58 +0100 Michael Biebl 
> wrote:
> > Hi Josh!
> > 
> > On Wed, 21 Dec 2016 20:15:12 +0100 Michael Biebl  wrote:
> > > On Fri, 6 May 2016 18:12:27 -0500 Martin Pitt  wrote:
> > > > Control: tag -1 moreinfo
> > > > 
> > > > Hello Josh,
> > > > 
> > > > Josh Triplett [2016-04-25 13:48 -0700]:
> > > > > ~$ cat /etc/udev/rules.d/99-local-gnubby.rules
> > > > > SUBSYSTEMS=="usb", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0200", 
> > > > > TAG+="uaccess"
> > > > >
> > > > > If I boot with the device attached, this seems to take effect:
> > > > >
> > > > > However, if I unplug and replug the device, this rule no longer seems 
> > > > > to take
> > > > > effect:
> > > > 
> > > > The uaccess tag is evaluated in /lib/udev/rules.d/73-seat-late.rules,
> > > > thus 99-* is too late. Can you please move it to e. g.
> > > > 70-gnubby.rules? I'm fairly sure it will work then, but I'll keep the
> > > > bug open until you confirm, just in case.
> > > > 
> > > 
> > > The dump from Josh shows, that the uaccess udev property is properly
> > > set. So I don't think it's an udev rules ordering issue.
> > > 
> > > I think the problem rather is, that you are already logged in and the
> > > ACLs are only applied on login or when the session becomes active.
> > > 
> > > I assume if you log out and re-login after the hotplug, the ACL is
> > > properly applied?
> > 
> > Any updates on this bug report? Is there still something which needs to
> > be addressed on the systemd side? If so we need to further investigate
> > the issue.
> 
> Josh, any updates on this?

I'm not currently using the device, so I don't know the status of this
issue.

Regarding the mention of when the ACLs are applied, though, is that true
in general? I thought that if you hotplugged a device that the user is
supposed to have access to, they'd immediately get access to it.

Bug#893924: python3-distutils: Please describe road map/recommendations for users of distutils

[Simon McVittie]

Package: python3-distutils
Version: 3.6.5~rc1-2
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

I'm confused about the current status of distutils, and what should be
done by packages that depend on it to be as future-proof as possible. I
don't think I'm the only one confused by this, so it would be very
helpful if a maintainer could clarify what the intention is so that
other maintainers can do the right things.

When structural changes like this are needed, I think it would
be useful for them to be represented by a bug (perhaps of the form
"libpython3.6-stdlib: should not contain distutils" or something similar)
that gives the reasons for the structural change and describes the
action that should be taken by maintainers of dependent packages. This
bug could be referenced in the changelog and would be an obvious central
coordination point for whatever changes are needed, including follow-ups
if unforeseen fallout means the plan has to change. The release team
would probably also appreciate it being treated as a transition so that
they can plan around it.

Since that didn't happen in this case, I'm opening this bug in the hope
that it can fulfil a similar role.

So far, the sequence of events goes something like this:

* 13 December 2017: distutils moves from -stdlib into its own package
* 20 March 2018: -stdlib stops depending on distutils, packages start
  to fail to build from source
* 22-23 March 2018: A small subset of distutils (__init__.py and version.py)
  moves back to -stdlib

I assume there is a reason (size on disk? dependencies? update
frequency?) why most of distutils shouldn't be in -stdlib, but in the
absence of a reference in the changelog, I can only guess at why that is.

When a small subset of distutils moved back, I assume that the
intention was to un-break the relatively common(?) case of users of
distutils.version that do not need the rest of the module, such as
the gdbus-codegen tool in libglib2.0-dev-bin. However, it isn't clear
whether the Python maintainers consider this to be a workaround to keep
those packages working in the short term (in which case they need to
pick up a new dependency on python3-distutils for the longer term), or
whether distutils.version is going to remain part of the API of -stdlib
in the long term (in which case packages like libglib2.0-dev-bin should
not depend on the full -distutils package because that would negate the
benefit of splitting it out).

I'm aware that structural changes that break dependencies are sometimes
necessary in pursuit of a goal (I've done them myself, most recently
moving glib-compile-resources to libglib2.0-dev-bin for #885019), but
when making them, having a plan visible to everyone is beneficial.
Please could you clarify the situation?

Related bug reports include:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893755
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893847

Thanks,
smcv

Bug#893923: nmu: libalien-wxwidgets-perl_0.69+dfsg-1 libwx-perl_1:0.9932-2

[Niko Tyni]

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

These are uninstallable in sid since the latest wxwidgets3.0 upload.
Could you please binNMU them?

nmu libalien-wxwidgets-perl_0.69+dfsg-1 . ANY . unstable . -m "Rebuild for 
wxwidgets3.0 3.0.4"
nmu libwx-perl_1:0.9932-2 . ANY . unstable . -m "Rebuild for wxwidgets3.0 3.0.4"

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

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

Bug#893922: gnome-vfs: Please don't release with Buster

[Jeremy Bicha]

Source: gnome-vfs
Version: 2.32.1-6
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gnome-vfs-removal
Tags: sid buster

The Debian GNOME team plans to remove gnome-vfs from Debian Testing
soon so that it will not be included in Debian 10 "Buster".

Affected packages can be seen at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintain...@lists.alioth.debian.org;tag=gnome-vfs-removal

This was announced at
https://lists.debian.org/debian-devel/2018/02/msg00169.html

Thanks,
Jeremy Bicha

Bug#893920: qalc: Don't recommend libgnomevfs2-common

[Jeremy Bicha]

Package: qalc
Version: 0.9.7-9.2
Severity: important
Tags: buster sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gnome-vfs-removal


Please don't have qalc recommend libgnomevfs2-common. gnome-vfs will
be removed from Debian Testing soon.

Thanks,
Jeremy Bicha

Bug#893921: libharu: add support for free-form triangle shading objects

[Kyle Edwards]

Source: libharu
Severity: wishlist
Tags: patch

Dear Maintainer,

I am working on an official Kitware-supported Debian/Ubuntu package for
the upcoming VTK 9. We are using a custom shading feature developed
in-house for libharu. We have submitted our changes upstream, but the
project has been abandoned and the patch will most likely never be
accepted. Please backport the included patch so that we can bring VTK 9
to Debian. Thank you for your support.


*** patches/0001-Add-support-for-free-form-triangle-Shading-objects.patch
>From 9e8ba2f5453552909e52fde5ec30856004a616d0 Mon Sep 17 00:00:00 2001
From: "David C. Lonie" 
Date: Wed, 10 May 2017 11:07:28 -0400
Subject: [PATCH] Add support for free-form triangle Shading objects.

---
 include/hpdf.h   |  24 -
 include/hpdf_error.h |   3 +
 include/hpdf_objects.h   |   2 +
 include/hpdf_pages.h |   5 +
 include/hpdf_types.h |  14 +++
 src/CMakeLists.txt   |   1 +
 src/hpdf_page_operator.c |  31 +++
 src/hpdf_pages.c |  55 ++-
 src/hpdf_shading.c   | 231 +++
 9 files changed, 362 insertions(+), 4 deletions(-)
 create mode 100644 src/hpdf_shading.c

diff --git a/include/hpdf.h b/include/hpdf.h
index e369f67..40e3c41 100644
--- a/include/hpdf.h
+++ b/include/hpdf.h
@@ -77,6 +77,7 @@ typedef HPDF_HANDLE   HPDF_Dict;
 typedef HPDF_HANDLE   HPDF_EmbeddedFile;
 typedef HPDF_HANDLE   HPDF_OutputIntent;
 typedef HPDF_HANDLE   HPDF_Xref;
+typedef HPDF_HANDLE   HPDF_Shading;
 
 #else
 
@@ -1171,6 +1172,11 @@ HPDF_EXPORT(HPDF_STATUS)
 HPDF_Page_SetExtGState  (HPDF_Pagepage,
  HPDF_ExtGState   ext_gstate);
 
+/* sh */
+HPDF_EXPORT(HPDF_STATUS)
+HPDF_Page_SetShading  (HPDF_Pagepage,
+   HPDF_Shading shading);
+
 
 /*--- Special graphic state operator --*/
 
@@ -1450,7 +1456,23 @@ HPDF_Page_SetCMYKStroke  (HPDF_Page  page,
 
 /*--- Shading patterns ---*/
 
-/* sh --not implemented yet */
+/* Notes for docs:
+ * - ShadingType must be HPDF_SHADING_FREE_FORM_TRIANGLE_MESH (the only
+ *   defined option...)
+ * - colorSpace must be HPDF_CS_DEVICE_RGB for now.
+ */
+HPDF_EXPORT(HPDF_Shading)
+HPDF_Shading_New  (HPDF_Doc pdf,
+   HPDF_ShadingType type,
+   HPDF_ColorSpace  colorSpace,
+   HPDF_REAL xMin, HPDF_REAL xMax,
+   HPDF_REAL yMin, HPDF_REAL yMax);
+
+HPDF_EXPORT(HPDF_STATUS)
+HPDF_Shading_AddVertexRGB(HPDF_Shading shading,
+  HPDF_Shading_FreeFormTriangleMeshEdgeFlag edgeFlag,
+  HPDF_REAL x, HPDF_REAL y,
+  HPDF_UINT8 r, HPDF_UINT8 g, HPDF_UINT8 b);
 
 /*--- In-line images -*/
 
diff --git a/include/hpdf_error.h b/include/hpdf_error.h
index b04e2cd..ef4fa61 100644
--- a/include/hpdf_error.h
+++ b/include/hpdf_error.h
@@ -145,6 +145,9 @@ extern "C" {
 #define HPDF_INVALID_U3D_DATA 0x1083
 #define HPDF_NAME_CANNOT_GET_NAMES0x1084
 #define HPDF_INVALID_ICC_COMPONENT_NUM0x1085
+/*0x1086 */
+/*0x1087 */
+#define HPDF_INVALID_SHADING_TYPE 0x1088
 
 /*---*/
 
diff --git a/include/hpdf_objects.h b/include/hpdf_objects.h
index 525adda..b16de02 100644
--- a/include/hpdf_objects.h
+++ b/include/hpdf_objects.h
@@ -61,6 +61,7 @@ extern "C" {
 #define  HPDF_OSUBCLASS_EXT_GSTATE_R  0x0B00  /* read only object */
 #define  HPDF_OSUBCLASS_NAMEDICT  0x0C00
 #define  HPDF_OSUBCLASS_NAMETREE  0x0D00
+#define  HPDF_OSUBCLASS_SHADING   0x0E00
 
 
 
@@ -595,6 +596,7 @@ typedef HPDF_Array HPDF_Destination;
 typedef HPDF_Dict  HPDF_U3D;
 typedef HPDF_Dict  HPDF_OutputIntent;
 typedef HPDF_Dict  HPDF_JavaScript;
+typedef HPDF_Dict  HPDF_Shading;
 
 #ifdef __cplusplus
 }
diff --git a/include/hpdf_pages.h b/include/hpdf_pages.h
index 44b816c..60b1d84 100644
--- a/include/hpdf_pages.h
+++ b/include/hpdf_pages.h
@@ -55,6 +55,7 @@ typedef struct _HPDF_PageAttr_Rec {
 HPDF_Dict  fonts;
 HPDF_Dict  xobjects;
 HPDF_Dict  ext_gstates;
+HPDF_Dict  shadings;
 HPDF_GStategstate;
 HPDF_Point str_pos;
 HPDF_Point cur_pos;
@@ -101,6 +102,10 @@ const char*
 HPDF_Page_GetExtGStateName  (HPDF_Page   page,
  HPDF_ExtGState  gstate);
 
+const char*
+HPDF_Page_GetShadingName  (HPDF_Pagepage,
+   HPDF_Shading shading);
+
 
 HPDF_Box
 HPDF_Page_GetMediaBox  (HPDF_Pagepage);
diff --git a/include/hpdf_types.h b/include/hpdf_types.h
index 8b3e0a8..a2e2157 100644
--- a/include/hpdf_types.h

Bug#893886: partman-auto: increase max size of /boot on amd64+i386?

[Steve Langasek]

Hi Steven,

On Fri, Mar 23, 2018 at 02:24:15PM +, Steven Chamberlain wrote:
> I get lots of user feedback from Ubuntu users that /boot is "too small"
> and quickly becomes full.  That's been the case for at least 3 years.
> https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1357093

Note that there are various bugs relating to failures in Ubuntu to
automatically clean up old kernels as part of the upgrade.  Making /boot
larger by default doesn't help at all with this, it only defers the pain.

The upcoming 18.04 release is the first release where I expect Ubuntu to get
this entirely right.

> There are a few aspects to this:

>  1. if a user chooses full-disk encryption, the size of /boot is not
> adjustable;  only by manually creating that, dm-crypt and LVM
> instead, but that's not easy.

>  2. it's really painful to enlarge /boot once a dm-crypt partition is
> created alongside it and filled with user data.

>  3. users of Software Center / Synaptic install kernel upgrades, but
> usually aren't that aware that old, unneeded kernels remain
> installed;  the GUIs have no autoremove function, and autoremove can
> sometimes remove things a novice user didn't intend.

> Some aspects are Ubuntu-specific:

>  4. they bump the ABI number in every kernel update, IIRC something
> related to the signing machinery for Secure Boot.  (vorlon@ in Cc
> can maybe explain?)

When running under a full Secure Boot regime, users want to ensure that
all code loaded by the kernel is signed.  This is achieved by signing all
the kernel modules shipped as part of the package with an ephemeral key
whose private half is discarded at the end of the build and whose public
half is embedded in vmlinux.  Thus, under Secure Boot enforcement, each
kernel is only able to load kernel modules from its own build and not from
any other; and an in-place upgrade of a kernel package breaks module loading
until reboot.

In Ubuntu it was already common practice to bump the ABI with nearly every
kernel update.  Secure Boot just means it's now enforced (s/nearly //).

>  5. they store both signed and unsigned kernel images in /boot,
> so each installed kernel ABI version requires more disk space.

That is a bug which we expect to resolve in Ubuntu for the 18.04 release.

> Thinking ahead, the latter two points might also apply to Debian
> someday.  The kernel itself and initrds may also become bigger over the
> next years.

> If that happens, and users have an installed system with full-disk
> encryption, they may be unable to increase the size of /boot, and so be
> obstructed from upgrading to the next Debian (or Ubuntu) release, or the
> one after.

> That the actual, root causes persist in Ubuntu after 3 years, despite a
> huge install base, good user support channels and paid developers, is
> slightly sad, but makes me think it merits working around (or preemptive
> action in the case of Debian), even at the expense of 256MB disk space.

> So in recipes-amd64-efi, is it feasible we double the max. size of /boot
> from 256MB to 512MB?

> "640K ought to be enough for everyone."

Note that the answer to this question does not impact Ubuntu at all, because
as of Ubuntu 17.10, Ubuntu's partman-auto already uses 512MiB as the
*minimum* size for /boot (max: 768MiB).  So if you're looking to bugginess
in the behavior of Ubuntu as a justification for bumping the size of /boot
in Debian, it doesn't provide much.

The particular rationale for the current Ubuntu /boot sizing is given here:

  https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1716999

The formula used would sensibly apply in Debian as well, but the exact
values of kernel/bootloader/initramfs sizes should be checked in Debian and
plugged in.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#893919: RFS: yasnippet-snippets/0~git20180307.2b4c4d7e-3 [RC]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "yasnippet-snippets".  While
I have DM permissions for the package, it is necessary to seek
sponsorship because this upload introduces a new bin:package
(elpa-yasnippet-snippets).  I've spoken with Sean Whitton on IRC and
he advocates that the elpa-package is a must.

After many hours trying to work around bug #893598 while attempting to
transition yasnippet-snippets to a dummy package I have had to
conclude that yasnippet-snippets must remain the package that contains
the snippets until buster+1.

Package name: yasnippet-snippets
Version : 0~git20180307.2b4c4d7e-3
Upstream Author : Andrea Crotti 
URL : https://github.com/AndreaCrotti/yasnippet-snippets
License : GPL-3+
Section : lisp

It builds these binary packages:

elpa-yasnippet-snippets - Andrea Crotti's official YASnippet snippets 
[configuration]
yasnippet-snippets - Andrea Crotti's official YASnippet snippets

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

https://mentors.debian.net/package/yasnippet-snippets

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

dget -x 
https://mentors.debian.net/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0~git20180307.2b4c4d7e-3.dsc

More information about yasnippet-snippets can be obtained from 
https://github.com/AndreaCrotti/yasnippet-snippets

Alternatively, one can clone the git repo of the package using this command:

git clone https://salsa.debian.org/emacsen-team/yasnippet-snippets.git
# I am requestion sponsorship @commit: b4fbc92

Changes since the last upload:

yasnippet-snippets (0~git20180307.2b4c4d7e-3) unstable; urgency=medium

  * Add elpa-yasnippet-snippets package:
- Add 0003-Synchronise-declared-version-with-MELPA.patch.
- d/control: Change section to lisp.
- d/control: Add elpa-yasnippet-snippets section.
- d/control: Rely on ${elpa:Depends} for dependency resolution.
- d/control: yasnippet-snippets now depends on elpa-yasnippet-snippets.
  * Update yasnippet-snippets.maintscript to run for this version.

 -- Nicholas D Steeves   Fri, 23 Mar 2018 14:38:33 -0400

yasnippet-snippets (0~git20180307.2b4c4d7e-2) unstable; urgency=medium


Regards,
Nicholas D Steeves

Bug#893918: openvas-manager: drop unused Build-Depends: flawfinder

[Helmut Grohne]

Source: openvas-manager
Version: 7.0.2-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

openvas-manager Build-Depends on flawfinder. I tried to figure out why
and found that its source code only mentions this tools in comments. It
doesn't occur in a build log either. And when building openvas-manager
without this dependency, you the same package (up to build path
differences) as when building with it (thanks to reproducible builds). I
conclude that this dependency is unused.  The dependency happens to be
unsatisfiable for cross building. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru openvas-manager-7.0.2/debian/changelog 
openvas-manager-7.0.2/debian/changelog
--- openvas-manager-7.0.2/debian/changelog  2017-12-01 07:30:20.0 
+0100
+++ openvas-manager-7.0.2/debian/changelog  2018-03-23 19:57:03.0 
+0100
@@ -1,3 +1,10 @@
+openvas-manager (7.0.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused Build-Depends: flawfinder. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 23 Mar 2018 19:57:03 +0100
+
 openvas-manager (7.0.2-2) unstable; urgency=medium
 
   [ Gianfranco Costamagna ]
diff --minimal -Nru openvas-manager-7.0.2/debian/control 
openvas-manager-7.0.2/debian/control
--- openvas-manager-7.0.2/debian/control2017-12-01 07:30:20.0 
+0100
+++ openvas-manager-7.0.2/debian/control2018-03-23 19:57:03.0 
+0100
@@ -11,7 +11,6 @@
libsqlite3-dev, 
pkg-config, 
xmltoman, 
-   flawfinder,
gnutls-bin (>= 3.2.15)
 Standards-Version: 4.1.2
 Homepage: http://www.openvas.org/

Bug#893917: O: antpm -- ANT+ information retrieval client for Garmin GPS products

[Christian Perrier]

Package: wnpp
Severity: normal

I intend to orphan the antpm package. I am the only uploader, the
pkg-running group is anything but active and I intend to reduce my
involvment in packaging (probably as I intend to resign from Debian in
one year or so)

The package description is:
 This software uses the Garmin ANT+ proprietary USB keys and
 communication protocol to retrieve information (such as GPS traces)
 from some Garmin Forerunner watches such as Forerunner 405 and 310XT.
 .
 The underlying ANT+minus implements the ANT/ANT+/ANT-FS protocols to
 provide these tools: garmin-ant-downloader, antpm-downloader,
 antpm-fit2gpx, and antpm-usbmon2ant.
 .
 ANT+minus is a userspace implementation of a wire protocol similar
 to the ANT/ANT+/ANT-FS protocols. The goal is to be able to communicate
 with any ANT capable device in order to e.g. retrieve sports tracks. The
 c++ implementation is currently available under both linux and win.
 Communication with watches other than the 310XT might work, but are
 untested. Please report your experience to help improving the software.
 .
 The software was originally named "gant" but renamed when packaged
 to avoid confusion with existing Java software.

Bug#893915: greenbone-security-assistant: drop unused Build-Depends: flawfinder, splint

[Helmut Grohne]

Source: greenbone-security-assistant
Version: 7.0.2+dfsg.1-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

greenbone-security-assistant Build-Depends on flawfinder and splint. I
tried to figure out why and found that its source code only mentions
these tools in comments. They don't occur in a build log either. And
when building greenbone-security-assistant without these dependencies,
you get a bit-identicial package as when building with them (thanks to
reproducible builds). I conclude that these dependencies are unused.
The flawfinder dependency happens to be unsatisfiable for cross
building. Please consider applying the attached patch.

Helmut
diff --minimal -Nru greenbone-security-assistant-7.0.2+dfsg.1/debian/changelog 
greenbone-security-assistant-7.0.2+dfsg.1/debian/changelog
--- greenbone-security-assistant-7.0.2+dfsg.1/debian/changelog  2017-06-20 
05:29:45.0 +0200
+++ greenbone-security-assistant-7.0.2+dfsg.1/debian/changelog  2018-03-23 
19:48:54.0 +0100
@@ -1,3 +1,10 @@
+greenbone-security-assistant (7.0.2+dfsg.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused Build-Depends: flawfinder, split. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 23 Mar 2018 19:48:54 +0100
+
 greenbone-security-assistant (7.0.2+dfsg.1-2) unstable; urgency=medium
 
   * Move package from experimental to sid archive
diff --minimal -Nru greenbone-security-assistant-7.0.2+dfsg.1/debian/control 
greenbone-security-assistant-7.0.2+dfsg.1/debian/control
--- greenbone-security-assistant-7.0.2+dfsg.1/debian/control2017-06-20 
05:29:45.0 +0200
+++ greenbone-security-assistant-7.0.2+dfsg.1/debian/control2018-03-23 
19:48:54.0 +0100
@@ -14,9 +14,7 @@
pkg-config,
xsltproc,
xmltoman,
-   libxml2-dev,
-   flawfinder,
-   splint
+   libxml2-dev
 Standards-Version: 4.0.0
 Homepage: http://www.openvas.org/
 Vcs-Git: 
https://anonscm.debian.org/git/pkg-security/greenbone-security-assistant.git

Bug#893916: O: antpm -- ANT+ information retrieval client for Garmin GPS products

[Christian Perrier]

Package: wnpp
Severity: normal

I intend to orphan the antpm package.

The package description is:
 This software uses the Garmin ANT+ proprietary USB keys and
 communication protocol to retrieve information (such as GPS traces)
 from some Garmin Forerunner watches such as Forerunner 405 and 310XT.
 .
 The underlying ANT+minus implements the ANT/ANT+/ANT-FS protocols to
 provide these tools: garmin-ant-downloader, antpm-downloader,
 antpm-fit2gpx, and antpm-usbmon2ant.
 .
 ANT+minus is a userspace implementation of a wire protocol similar
 to the ANT/ANT+/ANT-FS protocols. The goal is to be able to communicate
 with any ANT capable device in order to e.g. retrieve sports tracks. The
 c++ implementation is currently available under both linux and win.
 Communication with watches other than the 310XT might work, but are
 untested. Please report your experience to help improving the software.
 .
 The software was originally named "gant" but renamed when packaged
 to avoid confusion with existing Java software.

Bug#893914: libcgicc3: Add contrib/FCgiIO functionality

[LeJacq, Jean Pierre]

Package: libcgicc3
Version: 3.2.16-0.1
Severity: wishlist

Dear Maintainer,

Many users of libcgicc require the FastCGI interface. The upstream
source provides this in the contrib directory. It is relatively simple
to enable this with minimal overhead added to users that only require
CGI.

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (1000, 'stable'), (500, 'stable-updates'), (2, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages libcgicc3 depends on:
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libstdc++6  6.3.0-18+deb9u1

libcgicc3 recommends no packages.

libcgicc3 suggests no packages.

-- no debconf information

Bug#889904: /etc/flash-kernel/dtbs versioning

[Uwe Kleine-König]

Hello Joey,

On Thu, Feb 08, 2018 at 11:35:33AM -0400, Joey Hess wrote:
> Package: flash-kernel
> Version: 3.90
> Severity: normal
> 
> There's a good chance that the devicetree file for one version of the
> kernel will not work with another version. I suspect this was the case,
> and confirmed it today when my cubietruck failed to boot with mismatched
> versions.
> 
> So, it would be good if /etc/flash-kernel/dtbs could prefer a filename
> with the kernel version in it, over the unversioned file.

Right, in theory the dtbs are independant from the kernel, but real life
is different. That's why the linux image packages ship their matchin
device trees. I don't know your setup, but it would be easiest to use
these. If you don't provide your own dtb and just use

DTB-Id: sun7i-a20-cubietruck.dtb

everything should simply work.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#889732: libconfig-model-dpkg-perl: Does not recognize Salsa platform in Vcs field

[gregor herrmann]

On Fri, 23 Mar 2018 15:33:38 +0100, gregor herrmann wrote:

> I tried the same for Vcs-Git and got interesting errors, but they
> also appear with Vcs-Browser:
> 
> If I add
> 
> [ 'Vcs-Browser', 'http://anonscm.debian.org/cgit/foo-team/bar.git','', 
> $expected_warn ],
> 
> to the @vcs_tests array in t/dependency-check.t, I get
> 
> #   Failed test 'fixed Vcs-Browser URL'
> #   at t/dependency-check.t line 478.
> #  got: 
> 'https://salsa.debian.org/perl-team/modules/packages/libdist-zilla-plugins-cjm-perl'
> # expected: ''
> 
> Looks like the "old" value is still there somehow?

I've pushed some commits re Vcs-Git and a test for the fixup
mechanism to a branch gregoa/nomorealioth.
Unfortunately the tests in t/dependency-check.t still fails, as
decribed above.

I guess we also need a change for the other Vcs-* fields. I've played
a bit with ideas like

@@ -437,13 +437,11 @@ The information is meant to be useful for a user 
knowledgeable in the given Vers
 'summary' => 'URL of the VCS repository',
 'type' => 'leaf',
 'value_type' => 'uniline',
-'warn_unless' => {
-  'debian-uri' => {
-'code' => '!defined $_ or ! /debian.org/ or 
m{^https?://anonscm.debian.org/arch} ;',
-'fix' => 
's!https?://[\\w\\.-]+/(arch/)*!https://anonscm.debian.org/arch/!;',
-'msg' => 'URL is not the canonical one for repositories hosted on 
Debian infrastructure.'
+'warn_if_match' => {
+  '(?:alioth|arch|anonscm)\.debian\.org' => {
+'msg' => 'URL points to old Debian infrastructure.'
   }
-}
+},
   },
   'Vcs-Bzr',
   {


but maybe we need to unset the value as well with a "fix => $_ =
undef" here?


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Andrew Lloyd Webber & Tim Rice: Gethsemane (I Only Want To Say)


signature.asc
Description: Digital Signature

Bug#875557: Info received (Bug#875557: systemd: service mark as enabled but not in reality)

[Michael Biebl]

hm, the email address bounces here:

>
>The mail system
>
> : host mx.cblue.be[193.104.37.23] said: 550 Unrouteable
> address (in reply to RCPT TO command)
>
>
>
> Reporting-MTA: dns; dd17218.kasserver.com
> X-Postfix-Queue-ID: A90216801856
> X-Postfix-Sender: rfc822; bi...@debian.org
> Arrival-Date: Fri, 23 Mar 2018 17:12:34 +0100 (CET)
>
> Final-Recipient: rfc822; sth...@cblue.be
> Original-Recipient: rfc822;sth...@cblue.be
> Action: failed
> Status: 5.0.0
> Remote-MTA: dns; mx.cblue.be
> Diagnostic-Code: smtp; 550 Unrouteable address
>


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



signature.asc
Description: OpenPGP digital signature

Bug#893913: RFP: qtspell -- spell-checking functionality to Qt's text widgets

[E. Serradilla]

Package: wnpp
Severity: wishlist

* Package name: qtspell
  Version : 0.8.4
  Upstream Author : Sandro Mani 
* URL : https://github.com/manisandro/qtspell
* License : GPL
  Programming Lang: C++
  Description : spell-checking functionality to Qt's text widgets

QtSpell adds spell-checking functionality to Qt's text widgets, using 
the enchant spell-checking library.



This package is necessary for building the qt front-end of gimagereader 
(bug#891414). It would be very nice if someone would possibly volunteer 
to maintain the package since it will greatly enhance the compatibility 
of gimagereader across different window managers and desktop environments.


There is a sample debian directory in the upstream source code tree:

https://github.com/manisandro/qtspell/tree/master/packaging/debian

and an ubuntu ppa with the debianized package:

https://launchpad.net/~sandromani/+archive/ubuntu/gimagereader

that could be very helpful.

Bug#893912: firmware-realtek: Failed to load rtl_bt/rtl8821a_config.bin

[Rathorian]

Package: firmware-realtek
Version: 20161130-3
Severity: important

Dear Maintainer,

Every time I start Debian, I get an error message saying:
"bluetooth hci0: firmware: failed to load rtl_bt/rtl8821a_config.bin"

I have also tried to install the package since stretch-backports, without
any success.

Cordially
Rathorian

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

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.130

-- no debconf information

Bug#893911: RM: msgpack-python -- RoQA; binary packages are now built by src:python-msgpack

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

The python{,3}-msgpack binary packages are now
built by src:python-msgpack.

Bug#893731: [Piuparts-devel] Bug#893731: [piuparts] Please add docker support

[Holger Levsen]

On Thu, Mar 22, 2018 at 09:36:46AM -0300, Agustin Henze wrote:
> I have added doc for the new param and reworded some others :), please find 
> the
> patches attached. I have pushed to the PR[0] as well because IMO it's easier
> for doing review there. 

yep, many thanks, also for the updated/new patches!

> It'd be awesome if you migrate the project to salsa,

I will do, latest til the end of May ;-)

> Also, I tested a little bit more using no option, --schroot and the new one
> --docker-image. I'd be really happy if you do some testing on your side and
> give me some feedback.

I've done some review...

>  *--schroot*='SCHROOT-NAME'::
> -  Use schroot session named SCHROOT-NAME for the chroot, instead of building 
> a new one with debootstrap.
> +  Use schroot session named SCHROOT-NAME for the testing environment.

why drop the second half here?

>  parser.add_option("--schroot", metavar="SCHROOT-NAME", action="store",
> -  help="Use schroot session named SCHROOT-NAME for the 
> chroot, instead of building " +
> -   "a new one with debootstrap.")
> +  help="Use schroot session named SCHROOT-NAME for the 
> testing environment.")

same

>  *-k*, *--keep-tmpdir*::
> -  Don't remove the temporary directory for the chroot when the program ends.
> +  Depending on which option is passed, it keeps the environment used for 
> testing after the program ends::
> +   * By default it doesn't remove the temporary directory for the chroot
> +   * if --schroot is used, the schroot session is not terminated
> +   * or if --docker-image is used, the container created is not destroyed.
 
I think I prefer:

Depending on which option is passed, it keeps the environment used for testing 
after the program ends::
 * By default it doesn't remove the temporary directory for the chroot,
 * or if --schroot is used, the schroot session is not terminated,
 * or if --docker-image is used, the container created is not destroyed.

(twice "or if" at the beginning and always commas at the end)

> -  help="Don't remove the temporary directory for the " +
> -   "chroot when the program ends.")
> +  help="It keeps the environment used for testing after "
> +  "the program ends.")

-> "Keep the environment used for testing after the programm ends."

> --- a/piuparts.py
> +++ b/piuparts.py
[...]
> +import json

doesn't this need a new dependency?

>  def create_resolv_conf(self):
> +if settings.docker_image:
> +# Do nothing, docker already takes care of this
> +return

and

>  def terminate_running_processes(self):
> +if settings.docker_image:
> +# docker takes care of this
> +return

here I wonder: is it really cleaner to return if docker is used or
wouldnt it be better to not call it in the first place?



The rest looks fine to me and I'll happily merge once you fixed up those
little things. Thanks again!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#885677: is rebuilding lablgtk2 without gnomecanvas an option?

[Enrico Tassi]

On Fri, Mar 23, 2018 at 06:40:18PM +0100, Enrico Tassi wrote:
> Dear Jeremy, I'm an upstream of some of the software that depends on
> lablgtk2. Porting to GTK+3 is not an easy option, since lablgtk3 does
> not exist (and will not exist as far as I know).
> 
> As far as I understand, the main offender here is libgnomecanvas2-0.

Sorry, I meant gnomecanvas2 *and* gtksourceview2.
-- 
Enrico Tassi

Bug#893909: fails to download simon1/2 games from GOG

[Dmitry Eremin-Solenikov]

Package: game-data-packager
Version: 58
Severity: normal

GOG has changed names of Simon the Sourcerer and StS2 games, thus making
g-d-p unable to detect/download those games from GOG. Please update gog
names of corresponding titles to simon_the_sorcerer_legacy and
simon_the_sorcerer_2_legacy. Thank you!

-- 
With best wishes
Dmitry


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

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

Versions of packages game-data-packager depends on:
ii  dpkg1.19.0.5
ii  fakeroot1.22-2
ii  python3 3.6.4-1
ii  python3-debian  0.1.32
ii  python3-yaml3.12-1+b1

Versions of packages game-data-packager recommends:
ii  game-data-packager-runtime  58

Versions of packages game-data-packager suggests:
ii  arj   3.10.22-17
ii  binutils  2.30-8
ii  cabextract1.6-1.1
ii  cdparanoia3.10.2+debian-13
ii  dynamite  0.1.1-2+b2
ii  gcc   4:7.2.0-1d1
pn  gdebi | gdebi-kde 
ii  gir1.2-gdkpixbuf-2.0  2.36.11-2
ii  innoextract   1.6-1+b2
pn  lgc-pg
ii  lgogdownloader3.3-1+b1
ii  lhasa [lzh-archiver]  0.3.1-2+b1
ii  make  4.1-9.1
ii  p7zip-full16.02+dfsg-6
pn  steam 
pn  steamcmd  
ii  unace-nonfree 2.5-9
pn  unar  
ii  unrar 1:5.5.8-1
ii  unshield  1.4.2-1
ii  unzip 6.0-21
ii  vorbis-tools  1.4.0-10.1
ii  xdelta1.1.3-9.2
ii  xdelta3   3.0.11-dfsg-1+b1

-- no debconf information

Bug#885677: is rebuilding lablgtk2 without gnomecanvas an option?

[Enrico Tassi]

Dear Jeremy, I'm an upstream of some of the software that depends on
lablgtk2. Porting to GTK+3 is not an easy option, since lablgtk3 does
not exist (and will not exist as far as I know).

As far as I understand, the main offender here is libgnomecanvas2-0.

I was wandering if we could rebuild lablgtk2 switching off support for
some gnome technology: that is get rid of the binary package
liblablgtk2-gnome-ocaml but keep the others)

Lablgtk2 is made of optional components that can be switched off at
configure time. Eg on my system I currently get:

LablGTK configuration:
GtkGLArea   yes
libgladeyes
librsvg yes
libgnomecanvas  yes
libgnomeui  yes
libpanelapplet  not found
gtkspellyes
gtksourceview 1 not found
gtksourceview 2 yes
quartz  not found

If it is a viable option for you, can you tell me which of the above
are going to be a problem for Buster (in addition to libgnomecanvas)?

Best
-- 
Enrico Tassi

Bug#893910: gnumeric: space separator not recognized when copying from another application

[Jean-Paul Guillonneau]

Package: gnumeric
Version: 1.12.35-1
Severity: normal

Dear Maintainer,

gnumeric no more recognized the space separator for thousands for french when
copying from another application (libreoffice does). I’m using Buster and
update every few days.

Regards.



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

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

Versions of packages gnumeric depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  gnumeric-common1.12.35-1
ii  gsfonts1:8.11+urwcyr1.0.7~pre44-4.4
ii  libatk1.0-02.28.1-1
ii  libc6  2.27-2
ii  libcairo2  1.15.10-1
ii  libgdk-pixbuf2.0-0 2.36.11-2
ii  libglib2.0-0   2.56.0-2
ii  libgoffice-0.10-10 0.10.35-1
ii  libgsf-1-114   1.14.41-2
ii  libgtk-3-0 3.22.29-1
ii  libpango-1.0-0 1.40.14-1
ii  libpangocairo-1.0-01.40.14-1
ii  libxml22.9.4+dfsg1-6.1
ii  procps 2:3.3.12-4
ii  pxlib1 0.6.7-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnumeric recommends:
ii  evince3.28.0-1
ii  gnumeric-doc  1.12.35-1
ii  lp-solve  5.5.0.15-4+b1

Versions of packages gnumeric suggests:
ii  fonts-liberation1:1.07.4-5
pn  gnumeric-plugins-extra  
pn  libgsf-1-dev

-- debconf information:
  gnumeric/existing-process: false
  gnumeric/existing-process-title:

Bug#893908: u-boot-tegra: jetson-tx1 requires elf binary

[Vagrant Cascadian]

Package: u-boot-tegra
Severity: serious
Version: 2018.03+dfsg1-1

The Linux_for_Tegra tools require the u-boot elf binary in order to
install, and the "uboot.elf" and corresponding "u-boot" symlink were
removed in this version of u-boot, effectively making this package
unusable.

https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1


There may be other lingering issues with this version that I need to
look into as well, so marking as serious to block migration to testing
for now.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#893907: lynx: The subdomain name 'news' freezes Lynx

[Pelle Hjek]

Package: lynx
Version: 2.8.9dev16-3
Severity: important

Dear Maintainer,

When I use Lynx to read a web page, it freezes when the web page starts
with the subdomain 'news.' For example, on the terminal when I type in
this:

lynx news.ycombinator.com

Then Lynx freezes while displaying this message in the status bar:

Making NNTP connection to news.ycombinator.com

Lynx handles https://news.ycombinator.com just fine, but when https://
is missing, Lynx just assumes that I'm looking for something one Usenet.

Same problem with news.google.com, news.yahoo.com, etc.

I think it would be more reasonable if Lynx assumed HTTP unless told
otherwise, or perhaps had a time out in case NNTP lookup failed.
Freezing indefinitely is not the best option in that case.


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

Kernel: Linux 4.15.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lynx depends on:
ii  libbsd0   0.8.7-1
ii  libbz2-1.01.0.6-8.1
ii  libc6 2.27-1
ii  libgnutls30   3.5.18-1
ii  libidn11  1.33-2.1
ii  libncursesw5  6.1-1
ii  libtinfo5 6.1-1
ii  lynx-common   2.8.9dev16-3
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages lynx recommends:
ii  mime-support  3.60

lynx suggests no packages.

-- no debconf information

Bug#893906: ubertooth: demote firmware dependencies to Build-Depends-Indep

[Helmut Grohne]

Source: ubertooth
Version: 2017.03.R2-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ubertooth Build-Depends on pretty heavy arm-none-eabi packages that are
not actually required for an indep-only build. They can be demoted to
Build-Depends-Indep relatively easily as the attached patch
demonstrates. This is beneficial to cross building, because those
dependencies happen to be unsatisfiable for cross builds. Please
consider applying the attached patch. I verified (with reproducible
builds) that it doesn't change the arch-any build (modulo build ids).

Helmut
diff --minimal -Nru ubertooth-2017.03.R2/debian/changelog 
ubertooth-2017.03.R2/debian/changelog
--- ubertooth-2017.03.R2/debian/changelog   2017-07-16 20:40:08.0 
+0200
+++ ubertooth-2017.03.R2/debian/changelog   2018-03-23 17:43:51.0 
+0100
@@ -1,3 +1,10 @@
+ubertooth (2017.03.R2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Demote firmware dependencies to Build-Depends-Indep. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 23 Mar 2018 17:43:51 +0100
+
 ubertooth (2017.03.R2-2) unstable; urgency=low
 
   * debian/control:
diff --minimal -Nru ubertooth-2017.03.R2/debian/control 
ubertooth-2017.03.R2/debian/control
--- ubertooth-2017.03.R2/debian/control 2017-07-16 20:40:08.0 +0200
+++ ubertooth-2017.03.R2/debian/control 2018-03-23 17:41:29.0 +0100
@@ -11,10 +11,10 @@
libbluetooth-dev,
libbtbb-dev (>= 2017.03.R2),
python-all-dev,
-   txt2man,
-   gcc-arm-none-eabi,
-   libnewlib-arm-none-eabi,
-   libstdc++-arm-none-eabi-newlib
+   txt2man
+Build-Depends-Indep: gcc-arm-none-eabi,
+ libnewlib-arm-none-eabi,
+ libstdc++-arm-none-eabi-newlib
 Standards-Version: 4.0.0
 Vcs-Browser: https://github.com/rubund/debian-ubertooth/tree/master
 Vcs-Git: https://github.com/rubund/debian-ubertooth.git
diff --minimal -Nru ubertooth-2017.03.R2/debian/rules 
ubertooth-2017.03.R2/debian/rules
--- ubertooth-2017.03.R2/debian/rules   2017-03-15 14:24:13.0 +0100
+++ ubertooth-2017.03.R2/debian/rules   2018-03-23 17:43:51.0 +0100
@@ -10,6 +10,7 @@
 SOURCE_DATE ?= $(shell dpkg-parsechangelog --show-field Date)
 SOURCE_DATE_UTC ?= $(shell LC_ALL=C date -u -d "$(SOURCE_DATE)")
 CHANGELOG_DATE ?= $(shell LC_ALL=C date -u -d "$(SOURCE_DATE)" +"%d %B %Y")
+DOPACKAGES = $(shell dh_listpackages)
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
@@ -38,19 +39,25 @@

dh_auto_configure --sourcedirectory=host -- 
-DLIB_SUFFIX=/$(DEB_HOST_MULTIARCH) \
  -DUBERTOOTH_GROUP=plugdev -DUDEV_RULES_PATH=/lib/udev/rules.d
+ifneq ($(filter ubertooth-firmware,$(DOPACKAGES)),)
dh_auto_configure --sourcedirectory=firmware
+endif
 
 override_dh_auto_build:
dh_auto_build --sourcedirectory=host
+ifneq ($(filter ubertooth-firmware,$(DOPACKAGES)),)
dh_auto_build --sourcedirectory=firmware -- TIMESTAMP="-DTIMESTAMP=''" \
  COMPILE_BY="-D'COMPILE_BY=\"user\"'" 
COMPILE_HOST="-D'COMPILE_HOST=\"localhost\"'"
+endif
cat debian/ubertooth.pc.in | sed 
's/DEB_HOST_MULTIARCH/$(DEB_HOST_MULTIARCH)/' | \
  sed 's/UPSTREAM_PACKAGE_VERSION/$(UPSTREAM_PACKAGE_VERSION)/' > 
debian/ubertooth.pc
 
 override_dh_auto_install:
-   chmod a-x firmware/*/*.bin
dh_auto_install --sourcedirectory=host
+ifneq ($(filter ubertooth-firmware,$(DOPACKAGES)),)
+   chmod a-x firmware/*/*.bin
dh_auto_install --sourcedirectory=firmware
+endif
mkdir -p debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig
cp debian/ubertooth.pc 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig/
rm debian/tmp/usr/bin/ubertooth-tx # The tool does nothing - not fully 
implemented. Skip installing

Bug#861649: Newer version uploaded

[Gard Spreemann]

On Tuesday 13 March 2018 13:58:07 CET Tobias Frost wrote:
> On Sun, Mar 11, 2018 at 06:48:10PM +0100, Gard Spreemann wrote:
> > On Sunday 11 March 2018 00:18:32 CET Gard Spreemann wrote:
> > > On Wednesday 7 March 2018 19:32:48 CET Tobias Frost wrote:
> > > > Please review d/copyright. I found at least one undocumented file which
> > > > is licensed Apache 2.0 and another one under LGPL3+. Neither are in 
> > > > d/copyright.
> > > 
> > > I'm looking into this, and will get back to you.
> > > 
> > 
> > I've updated the copyright information for the Apache 2.0-licensed
> > file, as well as another MIT-licensed file with missing coverage.
> 
> Thanks!.
> 
> Note that some files are claimed copyright just by "20xx INRIA" and
> "20xx INRIA (France)"
> As copyright must be verbatim, you need to addtionalyl write this in 
> d/copyright.
> Not sure about all those other variants of INRIA: Are they different
> organisattions (like a subsidiary) of just different writing of the same
> one? In the first case, you need to have one stanca for every different
> organisations,
> (hint: license-reconcile might help here)

I got in touch with upstream, who says:

[Begin quote]
This is a problem we have seen, but it was "too late", everybody
copy/paste the colleague copyright and just changed the Inria center's
name...  I have started to change it every where, every time I fix a
bug, but from what you say, I shall change it once for every files ;-)

The correct Copyright is "Inria".

If you want, I can change it everywhere and make a new version if it
can accelerate the submission.
[End quote]

It certainly sounds great if they can fix this upstream, but would a
statement like this suffice for now?
 
> Speaking about external sources... I see that there is also cpython in
> the source. As cpython is packaged, can it be also removed via
> Files-Exluded (as you said, you're repacking already, so we can reduce
> the size of the source package even more)

Maybe I misunderstood, but I can't see a bundled cpython. Did you mean
the cython subdirectory? It just contains .pyx sources to be compiled
with cython.

> Older stuff already mentioned, but still not fixed:
>   - many versioned build dependencies are already satisfied since
>   oldstable. As thus those old version constraint can be removed,
>   especially as this is a new package.

I've fixed this now (but haven't made a new upload).


Thanks a lot for your help. I'll upload a new version (also having a
new dependency that has become necessary after a change to sid's
Python package) when I hear back from you about the copyright question
above.


 Best,
 Gard

Bug#848239: on purge, not remove?

[Antoine Beaupré]

On 2018-03-23 20:11:50, kact...@gnu.org wrote:
> I agree with you. /purge/ is actually more reasonable. Will fix it.

Awesome! Thanks for your work!

A.

PS: I sent you a merge request on gitlab regarding documentation, as an
experiment... Let me know how it works for you!

-- 
During times of universal deceit, telling the truth becomes a
revolutionary act.   - Georges Orwell

Bug#893905: Two vulnerabilities (CVE-2018-8801 / one CVE-less)

[Moritz Muehlenhoff]

Package: gitlab
Severity: grave
Tags: security

Please see
https://about.gitlab.com/2018/03/20/critical-security-release-gitlab-10-dot-5-dot-6-released/

Cheers,
Moritz

Bug#893884: [pkg-boost-devel] Bug#893884: libboost-locale1.62.0: LC_CTYPE overrides value of LC_ALL

[Steve M. Robbins]

On Fri, Mar 23, 2018 at 03:52:38PM +0100, Nicolas Dandrimont wrote:

> I've looked at the upstream history, but this source file has been imported
> as-is in SVN 7 years ago and hasn't been touched since, therefore I couldn't
> find the upstream rationale for this resolution order.

Did you ask upstream?  Or file a report in the upstream bug tracker?

Thanks,
-Steve



signature.asc
Description: PGP signature

Bug#848239: on purge, not remove?

[KAction]

[2018-03-23 12:30] Antoine Beaupré 
> Control: found -1 1.3.1
> 
> 1.3.1 removes the user on *remove*, not *purge*, is that intentional?
> 
> Maybe I missed a part of the conversation, but it seems to me it would
> be more reasonable to delete the user on purge, as it is more likely
> files owned by that user will be gone in that state, e.g. config
> files...

I agree with you. /purge/ is actually more reasonable. Will fix it.


pgpyxKR3y_sBz.pgp
Description: PGP signature

Bug#893904: RFS: dh-sysuser/1.3.2

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dh-sysuser"

* Package name : dh-sysuser
  Version  : 1.3.2
  Upstream Author  : Dmitry Bogatov 
* Url  : https://salsa.debian.org/runit-team/dh-sysuser
* Licenses : GPL-3+
  Programming Lang : Perl
  Section  : admin

 dh-sysuser provides a debhelper sequence addon named 'sysuser'
 and command 'dh_sysuser', which provide declarating way to
 ensure, that required users are present after package installation
 and correctly handled after package removal.

It builds those binary packages:

  * dh-sysuser
  * sysuser-helper

This package succesfully builds on debomatic machine:

  http://debomatic-i386.debian.net/distribution#unstable/dh-sysuser/1.3.2

Alternatively, you can access package debian/ directory via git from URL:
https://salsa.debian.org/runit-team/dh-sysuser.git

More information about dh-sysuser can be obtained from
https://salsa.debian.org/runit-team/dh-sysuser

Changes since last upload:

  * Remove user on purge, not remove (Closes: #848239)
+ Thanks: Antoine Beaupré 

Regards,
  Dmitry Bogatov

Bug#893870: RM: luakit -- RoQA; orphaned web browser; depends on unmaintained webkitgtk

[Jeremy Bicha]

On Fri, Mar 23, 2018 at 1:07 PM, Mason Larobina
 wrote:
> Are you aware there is active luakit development again?

Yes, I am aware that there was a new luakit release last year. The
problem is that it is not well-maintained in Debian.

Thanks,
Jeremy Bicha

Bug#869666: SYSERR(root): timeout writing message to

[Will Aoki]

On Fri, Mar 23, 2018 at 10:03:40AM -0600, Will Aoki wrote:
> We can confirm the same problem and that it was fixed by downgrading the
> sendmail packages to 8.14.4-8+deb8u2. The problem's a bit tricky in that
> the log message suggests that the destination server is at fault, where
> it's really Sendmail trying to look up names in To: that aren't in the
> envelope.

This appears to be a change in 8.15.1 regarding header rewriting, and
several other folks were caught by surprise:

https://forums.freebsd.org/threads/timeout-writing-message-to-local.55563/
https://groups.google.com/forum/#!topic/comp.mail.sendmail/_Io7xEYqF1s

To deal with this, it's necessary to turn off hostname canonicalization.
As I understand it,

Khost host -t

should result in the previous behavior, but the documentation recommends
turning off hostname canonialication with

FEATURE(`nocanonify')

This change does work, although I haven't yet tested operationally to
verify nothing of ours was relying on the old behavior.

Bug#893870: RM: luakit -- RoQA; orphaned web browser; depends on unmaintained webkitgtk

[Mason Larobina]

Hi folks,

Are you aware there is active luakit development again?

aidanholm@ is the new maintainer and has removed the webkitgtk1 dependency
among other fixes:

https://luakit.github.io/
https://github.com/luakit/luakit
https://github.com/aidanholm

Regards,

Mason

On 24 March 2018 at 00:28, Jeremy Bicha  wrote:

> Package: ftp.debian.org
> X-Debbugs-Cc: lua...@packages.debian.org, groo...@groolot.net
>
> luakit was orphaned about 3 years ago [1]
>
> It was removed from Testing 8 months ago because it depends on the
> unmaintained webkitgtk.
>
> There is an ITA/RFS bug in progress, but it has been in progress for 9
> months and is still not ready for upload to Debian. (I apologize for
> not helping more, but I'm not interested in being partially
> responsible for this particular package.)
>
> I think at some point we should just let the package be removed from
> Debian so it doesn't block the webkitgtk removal. I also think that
> web browsers need to be reasonably well-maintained in Debian or else
> it is a disservice to our users. Therefore, I'm filing this removal
> bug..
>
> [1] https://bugs.debian.org/738447
>
> Thanks,
> Jeremy Bicha
>

Bug#893903: python3.4 for jessie embed an obsolete argparse.py

[Louis Pery]

Package: libpython3.4-minimal

Version: 3.4.2-1


argparse.py version embedded with python3.4 is obsolete.

Last 2 commits here are missing:
https://github.com/python/cpython/commits/3.4/Lib/argparse.py

Which include this issue resolution: https://bugs.python.org/issue9351

Thank you for looking into it.

---
Louis.

Bug#893902: w3m should not break some table cells' text into two lines

[積丹尼 Dan Jacobson]

X-debbugs-Cc: yama...@jpl.org
Package: w3m
Version: 0.5.3-36

w3m should not break some table cells' text into two lines into such cases:

$ w3m -dump -no-graph t.html
+---+
|時刻 |X 車|Y 車|
|-++|
|08:30|交大 上 |交大 上 |
| |客  |客  |
+---+

It should not insert a virtual  before the 客 on such short lines.

Title: TEST


  
  

  
時刻
X 車
Y 車
  
  
08:30
交大 上客
交大 上客
  

  

Bug#893901: modem-manager-gui: FTBFS on various architectures - missing -lm

[James Cowgill]

Source: modem-manager-gui
Version: 0.0.18-4
Severity: serious
Tags: sid buster

Hi,

modem-manager-gui FTBFS on various architectures with the error:
> gcc `pkg-config --cflags gtk+-3.0 gthread-2.0 gmodule-2.0 gtkspell3-3.0 
> appindicator3-0.1` -Wl,-z,relro -Wl,-z,now -Wl,--as-needed settings.o 
> strformat.o libpaths.o dbus-utils.o notifications.o addressbooks.o ayatana.o 
> smsdb.o trafficdb.o providersdb.o modem-settings.o ussdlist.o encoding.o 
> vcard.o netlink.o polkit.o svcmanager.o mmguicore.o contacts-page.o 
> traffic-page.o scan-page.o info-page.o ussd-page.o sms-page.o devices-page.o 
> preferences-window.o welcome-window.o connection-editor-window.o main.o 
> `pkg-config --libs gtk+-3.0 gthread-2.0 gmodule-2.0 gtkspell3-3.0 
> appindicator3-0.1` -lgdbm -o modem-manager-gui
> /usr/bin/ld: encoding.o: undefined reference to symbol 'ceil@@GLIBC_2.0'
> //lib/mips64el-linux-gnuabi64/libm.so.6: error adding symbols: DSO missing 
> from command line
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:17: modem-manager-gui] Error 1
> make[2]: Leaving directory '/<>/src'
> make[1]: *** [Makefile:8: modem-manager-gui] Error 2
> dh_auto_build: make -j4 -O returned exit code 2
> make: *** [debian/rules:6: build-arch] Error 25
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

I'm guessing this only happens on some architectures because ceil was
inlined by the compiler as an intrinsic on those architectures.

In any case, modem-manager-gui should be linked against libm with -lm.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#893900: versioned dependencies are incorrect when epochs are present

[Sébastien Villemot]

Package: dh-octave
Version: 0.3.2
Severity: normal

Hi,

I just realized that dh-octave generates incorrect versioned dependencies on
octave Forge packages that have epochs.

Currently the only package with an epoch is octave-econometrics, and since it
has no reverse dependency, this bug has no practical consequence.

But I'm still reporting it for completeness, and because this situation may
change in the future (see also #893895 for a similar bug in dh-r).

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#893899: ITP: r-cran-libcoin -- GNU R linear test statistics for permutation inference

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-libcoin
  Version : 1.0-1
  Upstream Author : Torsten Hothorn 
* URL : https://cran.r-project.org/package=libcoin
* License : GPL
  Programming Lang: GNU R
  Description : GNU R linear test statistics for permutation inference
 Basic infrastructure for linear test statistics and permutation
 inference in the framework of Strasser and Weber (1999)
 . This package must not be used by end-users.
 CRAN package 'coin' implements all user interfaces and is ready to be
 used by anyone.


Remark: This package is needed to run the full test suite of
 r-cran-coin (see #882865).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-libcoin

Bug#893895: dh-r: versioned dependencies are incorrect when epochs are present

[Andreas Tille]

On Fri, Mar 23, 2018 at 05:24:55PM +0100, Sébastien Villemot wrote:
> 
> I now realize that packages are supposed to be buildable without network
> access, so query the apt cache is the way to go.
> 
> I'm wondering how similar helpers for other languages solve this problem 
> (maybe
> they don't, i.e. they just decided to avoid epochs – at least it's what we are
> doing in the Debian Octave Group).

Too bad that I squashed this bug simply for esthetical reasons. :-(

On the other hand there exist other r-cran packages featuring epochs
since a long time (r-cran-sp is just one example).  So at least now
this problem has become visible.

Sorry for this

 Andreas.

-- 
http://fam-tille.de

Bug#860915: cloud-initramfs-tools: Please re-enable generation of the overlayroot package

[Nikolay Turpitko]

Dear Maintainer,

I'm experimenting with overlayroot package in the VirtualBox, Debian
9  (4.9.82-1+deb9u3).
I was able to make it work for me using this solution:
https://yulistic.gitlab.io/2016/05/overlayroot-not-work i
ng-with-custom-kerne l/

.

As I understand it, main changes to make it work are:

- uncomment package definition;

- rename: overlayfs -> overlay;

- add "workdir" option;

I'll try to attach the patch with my changes, but as I've never did it
before, I'm not sure it will not be rejected by anti-spam.


Also I found that upstream (Ubuntu) repository for this package moved to
git and contains quite a lot of changes (more than I have experience to
properly deal with).
I tried to install package from Ubuntu directly (version 0.40:
https://packages.ubuntu.com/bionic/all/overlayroot/download) and it worked
for me with these parameters:
`overlayroot="tmpfs:swap=1,recurse=0,debug=1,driver=overlay"`. Probably,
it's better to use code from upstream.


enable-overlayroot.patch
Description: Binary data

Bug#893898: libprelude FTBFS: missing Build-Depends: python3-distutils

[Helmut Grohne]

Source: libprelude
Version: 4.1.0-4
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

libprelude fails to build from source:

| make[6]: Leaving directory '/<>/bindings/perl'
| Making all in docs
| Making all in api
| make[5]: Nothing to be done for 'all'.
| Making all in manpages
| make[5]: Nothing to be done for 'all'.
| make[5]: Nothing to be done for 'all-am'.
| Making all in tests
| make[4]: Nothing to be done for 'all'.
| cd bindings/python && python2.7 setup.py build
| running build
| running build_py
| running build_ext
| cd bindings/python && python3.6 setup.py build
| Traceback (most recent call last):
|   File "setup.py", line 26, in 
| from distutils.sysconfig import get_python_lib
| ModuleNotFoundError: No module named 'distutils.sysconfig'
| make[1]: *** [debian/rules:43: build-python3.6] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:61: build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Likely it needs to add python3-distutils to Build-Depends after
python3.6 dropped it from Depends.

Also please rebuild libprelude against a version of gem2deb that fixes
#892131.

Helmut

Bug#848239: on purge, not remove?

[Antoine Beaupré]

Control: found -1 1.3.1

1.3.1 removes the user on *remove*, not *purge*, is that intentional?

Maybe I missed a part of the conversation, but it seems to me it would
be more reasonable to delete the user on purge, as it is more likely
files owned by that user will be gone in that state, e.g. config
files...

Thanks!

A.

-- 
Lorsque l'on range des objets dans des tiroirs, et que l'on a plus
d'objets que de tiroirs, alors un tiroir au moins contient deux
objets.
- Lejeune-Dirichlet, Peter Gustav

Bug#893897: Preferred method to request update from maintainer scripts not documented

[Robie Basak]

Source: initramfs-tools
Version: 0.130
Severity: wishlist

bcache-tools currently just calls "update-initramfs -u" from its
postinst. On initial review, this seemed inefficient to me over using
the trigger.

It looks like you actually wrap yourself to activate the trigger, so in
practice it makes no difference. I wondered whether you have any
preference or recommendation on which method to use, and I couldn't find
anything. I looked for a README.Debian and in update-initramfs(8).

I asked on IRC, and smcv suggested that given you support a trigger,
that's probably the preferred way, but there was a suggestion that I
should file a bug for you to document this, so here it is.

Please document how you recommend that other package maintainer scripts
should request an initramfs update.

While you're there, debian/README looks pretty out of date, too :)

Thanks,

Robie


signature.asc
Description: PGP signature

Bug#893895: dh-r: versioned dependencies are incorrect when epochs are present

[Sébastien Villemot]

On Fri, Mar 23, 2018 at 05:17:01PM +0100, Sébastien Villemot wrote:

> Unfortunately that means that dh-r will no longer be fully functional offline
> (querying the local apt cache could be a fallback, but there's no guarantee
> that it is up-to-date, even when running unstable).

I now realize that packages are supposed to be buildable without network
access, so query the apt cache is the way to go.

I'm wondering how similar helpers for other languages solve this problem (maybe
they don't, i.e. they just decided to avoid epochs – at least it's what we are
doing in the Debian Octave Group).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#822635: udev rules for USB device access effective at boot, but not on hotplug

[Michael Biebl]

On Mon, 22 Jan 2018 18:10:58 +0100 Michael Biebl 
wrote:
> Hi Josh!
> 
> On Wed, 21 Dec 2016 20:15:12 +0100 Michael Biebl  wrote:
> > On Fri, 6 May 2016 18:12:27 -0500 Martin Pitt  wrote:
> > > Control: tag -1 moreinfo
> > > 
> > > Hello Josh,
> > > 
> > > Josh Triplett [2016-04-25 13:48 -0700]:
> > > > ~$ cat /etc/udev/rules.d/99-local-gnubby.rules
> > > > SUBSYSTEMS=="usb", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0200", 
> > > > TAG+="uaccess"
> > > >
> > > > If I boot with the device attached, this seems to take effect:
> > > >
> > > > However, if I unplug and replug the device, this rule no longer seems 
> > > > to take
> > > > effect:
> > > 
> > > The uaccess tag is evaluated in /lib/udev/rules.d/73-seat-late.rules,
> > > thus 99-* is too late. Can you please move it to e. g.
> > > 70-gnubby.rules? I'm fairly sure it will work then, but I'll keep the
> > > bug open until you confirm, just in case.
> > > 
> > 
> > The dump from Josh shows, that the uaccess udev property is properly
> > set. So I don't think it's an udev rules ordering issue.
> > 
> > I think the problem rather is, that you are already logged in and the
> > ACLs are only applied on login or when the session becomes active.
> > 
> > I assume if you log out and re-login after the hotplug, the ACL is
> > properly applied?
> 
> Any updates on this bug report? Is there still something which needs to
> be addressed on the systemd side? If so we need to further investigate
> the issue.

Josh, any updates on this?




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



signature.asc
Description: OpenPGP digital signature

Bug#893895: dh-r: versioned dependencies are incorrect when epochs are present

[Sébastien Villemot]

Package: dh-r
Version: 20171201
X-Debbugs-CC: debia...@lists.debian.org

On Fri, Mar 23, 2018 at 05:12:09PM +0100, Andreas Tille wrote:

> On Fri, Mar 23, 2018 at 04:44:11PM +0100, Sébastien Villemot wrote:

> > Actually, I am wrong: epochs are very wrong for CRAN packages, because they
> > break dh-r which (I think) is then not able to generate the right versioned
> > dependency…
> 
> Uhmmm.  I did not intend to break anything - but we should file a bug
> report against dh-r.  Would you mind doing this since you realised
> what is broken?

Essentially dh-r should query the package database to figure out which CRAN
packages have an epoch, and adapt its generated versioned dependencies.

Unfortunately that means that dh-r will no longer be fully functional offline
(querying the local apt cache could be a fallback, but there's no guarantee
that it is up-to-date, even when running unstable).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#893896: reaver FTCBFS: does not propaget CC to sub Makefiles

[Helmut Grohne]

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

reaver fails to cross build from source, because its build system fails
to propagate the passed cross compiler to sub Makefiles. The attached
patch fixes that and makes reaver cross build successfully. Please
consider applying it.

Helmut
Index: reaver-1.4/src/Makefile.in
===
--- reaver-1.4.orig/src/Makefile.in
+++ reaver-1.4/src/Makefile.in
@@ -16,22 +16,22 @@
 	$(CC) $(CFLAGS) $(INC) wpscrack.c *.o $(LDFLAGS) -o reaver
 
 libwps.o:
-	(cd $(LIBWPS_DIR) && make)
+	$(MAKE) -C $(LIBWPS_DIR) 'CC=$(CC)'
 
 wps: libutils libcrypto
-	(cd wps && make)
+	$(MAKE) -C wps 'CC=$(CC)'
 
 libutils:
-	(cd utils && make)
+	$(MAKE) -C utils 'CC=$(CC)'
 
 libcrypto: libtls
-	(cd crypto && make)
+	$(MAKE) -C crypto 'CC=$(CC)'
 
 libtls:
-	(cd tls && make)
+	$(MAKE) -C tls 'CC=$(CC)'
 
 libiw:
-	(cd lwe && make BUILD_STATIC=y libiw.a)
+	$(MAKE) -C lwe BUILD_STATIC=y 'CC=$(CC)' libiw.a
 
 init.o:
 	$(CC) $(CFLAGS) init.c -c

Bug#875557: systemd: service mark as enabled but not in reality

[Michael Biebl]

Control: tags -1 + moreinfo

On Tue, 12 Sep 2017 10:08:49 +0200 Michael Biebl  wrote:
> Am 12.09.2017 um 09:45 schrieb sthiry:
> > Package: systemd
> > Version: 232-25+deb9u1
> > Severity: normal
> > 
> > Hello,
> > 
> > I use multiple php-fpm process to run apache websites and I have to create 
> > one process by site, so I have a service file named php7-fpm@.service. It 
> > let me create service like this php7-fpm@mysite that 
> > I have to enable once it is created. So I notice that when I enable one 
> > service, the others are mark as enabled when I type "service php7-fpm* 
> > status", but they are not enabled. So you have to enable all
> > services.
> 
> Can you please include the full service file you are using and the
> output of the commands.

Would be great, if you can provide the requested information.


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



signature.asc
Description: OpenPGP digital signature

Bug#893008: wide-dhcpv6 FTBFS with flex 2.6.4-6

[Roger Shimizu]

control: tags -1 +pending

On Thu, Mar 15, 2018 at 10:55 PM, Adrian Bunk  wrote:
> Source: wide-dhcpv6
> Version: 20080615-19
> Severity: serious
> Tags: buster sid patch
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/wide-dhcpv6.html
>
> ...
> gcc -Wl,-z,relro -Wl,-z,now -o dhcp6ctl dhcp6_ctlclient.o base64.o auth.o 
> strlcpy.o strlcat.o arc4random.o -lfl
> /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libfl.so: undefined 
> reference to `yylex'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:74: dhcp6ctl] Error 1
>
>
> Fix is attached.

Dear Adrian,

Thanks for the report and patch!

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

Bug#869666: SYSERR(root): timeout writing message to

[Will Aoki]

We can confirm the same problem and that it was fixed by downgrading the
sendmail packages to 8.14.4-8+deb8u2. The problem's a bit tricky in that
the log message suggests that the destination server is at fault, where
it's really Sendmail trying to look up names in To: that aren't in the
envelope.

sendmail.mc with most comments removed:

define(`_USE_ETC_MAIL_')dnl
include(`/usr/share/sendmail/cf/m4/cf.m4')dnl
VERSIONID(`$Id: sendmail.mc, v 8.13.4-3 2005-06-03 16:49:22 cowboy Exp $')
OSTYPE(`debian')dnl
DOMAIN(`debian-mta')dnl
dnl # Items controlled by /etc/mail/sendmail.conf - DO NOT TOUCH HERE
undefine(`confHOST_STATUS_DIRECTORY')dnl#DAEMON_HOSTSTATS=
dnl # Items controlled by /etc/mail/sendmail.conf - DO NOT TOUCH HERE
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Family=inet,  Name=MTA-v4, Port=smtp')dnl
DAEMON_OPTIONS(`Family=inet,  Name=MSP-v4, Port=submission')dnl
define(`SMTP_MAILER_MAXRCPTS', 10)
define(`confMAX_DAEMON_CHILDREN', 150)dnl
define(`confPRIVACY_FLAGS',dnl
`needmailhelo,needexpnhelo,needvrfyhelo,restrictqrun,restrictexpand,nobodyreturn,authwarnings')dnl
KDNSTXT dns -R TXT
C{BadIdentUsers}squid CacheFlowServer proxyuser
define(`confBIND_OPTS', `')dnl
define(`confCONNECTION_RATE_THROTTLE', `15')dnl
define(`confCONNECTION_RATE_WINDOW_SIZE',`10m')dnl
FEATURE(`access_db', , `skip')dnl
FEATURE(`greet_pause', `1000')dnl 1 seconds
FEATURE(`delay_checks', `friend', `n')dnl
define(`confBAD_RCPT_THROTTLE',`3')dnl
FEATURE(`conncontrol', `nodelay', `terminate')dnl
FEATURE(`ratecontrol', `nodelay', `terminate')dnl
define(`confMAX_MESSAGE_SIZE', 5000)
FEATURE(`blacklist_recipients')dnl
FEATURE(`mailertable')dnl
FEATURE(`virtusertable')dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
include(`/etc/mail/tls/starttls.m4')dnl
include(`/etc/mail/sasl/sasl.m4')dnl
define(`confAUTH_OPTIONS', `p,y')dnl
FEATURE(`always_add_domain')dnl
MASQUERADE_AS(`my-domain.example.com')dnl
FEATURE(`allmasquerade')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`dnsbl', `zen.spamhaus.org', `$>GetTXT $&{client_addr} $| 
zen.spamhaus.org $| Host $| " blocked: see " $| for details')
define(`confMILTER_MACROS_ENVRCPT', `{rcpt_mailer}, {rcpt_host}, {rcpt_addr}, 
b')
INPUT_MAIL_FILTER(`greylist',`S=local:/path/to/milter-greylist.sock', F=, 
T=C:6s;E:12s)dnl
INPUT_MAIL_FILTER(`clmilter',`S=local:/path/to/clmilter.sock, F=, 
T=C:70s;E:4m')dnl
INPUT_MAIL_FILTER(`spamassassin', `S=local:/path/to/spamass.sock, F=, 
T=C:2m;R:2m;E:8m')dnl
define(`confINPUT_MAIL_FILTERS', `greylist, clmilter, spamassassin')
MAILER_DEFINITIONS
MAILER(`local')dnl
MAILER(`smtp')dnl
LOCAL_RULESETS
SGetTXT
R$-.$-.$-.$- $| $+ $| $+ $| $+ $| $+$: $6 $1.$2.$3.$4 $7 $(DNSTXT 
$4.$3.$2.$1.$5 $) $8
SLocal_check_relay
R$* $: $(dequote "" $&_ $)
RIDENT:$*   $: $1
R$={BadIdentUsers}@$*   $#error $@ 5.7.1 $: "550 Access denied because 
your ident string is " $1
LOCAL_CONFIG
O 
CipherList=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:HIGH:ECDHE-RSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:!aNULL:!MD5
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 
+SSL_OP_CIPHER_SERVER_PREFERENCE

Bug#893200: TC Chair election

[Niko Tyni]

On Fri, Mar 23, 2018 at 05:59:47PM +0200, Niko Tyni wrote:
> On Sat, Mar 17, 2018 at 10:25:28AM +0100, Didier 'OdyX' Raboud wrote:
> 
> > ===BEGIN===
> > 
> > The chair of the Debian Technical Committee will be:
> > 
> > A : Didier Raboud 
> > B : Tollef Fog Heen 
> > C : Phil Hands 
> > D : Margarita Manterola 
> > E : David Bremner 
> > F : Niko Tyni 
> > G : Gunnar Wolf 
> > H : Simon McVittie 
> > ===END===
> 
> I vote: C = D > E = F = G > A = B > H

Argh, signed with a wrong key. Sorry about that.

This one is (hopefully) better.
-- 
Niko Tyni   nt...@debian.org


signature.asc
Description: PGP signature