Bug#837621: simpleid: PHP Fatal error: Cannot redeclare random_bytes()

[Ying-Chun Liu (PaulLiu)]

Hi,

I met the same problem.

I found it is because PHP 7+ provides random_bytes() natively. Thus make
simpleid failed.

The upstream has already fixed this issue. And I checked the latest
version 1.0.2 the patch is already there.

Please see
https://trac.simpleid.koinic.net/browser/git/www/random.inc.php?rev=e8320760ac135bbcea59805d9a36b2b99401bc9f

Yours,
Paul


-- 
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu) 



signature.asc
Description: OpenPGP digital signature

Bug#878968: libglvnd0-nvidia: undefined symbol: _glapi_tls_Current makes system unusable

[Hendrik Tews]

Package: libglvnd0-nvidia
Version: 375.82-5
Severity: critical

Dear Maintainer,

after updating some packages this morning, X11 did not come up
any more and the system was completely unusable. Apparently gdm
was restarting continuously, making it impossible to enter
anything in a terminal window. I needed to boot in recovery mode
to get access again.

The syslog contains

/usr/lib/gdm3/gdm-x-session[2703]: (EE) Failed to load 
/usr/lib/xorg/modules/extensions/libglx.so: 
/usr/lib/x86_64-linux-gnu/libGL.so.1: undefined symbol: _glapi_tls_Current

and I get the same undefined symbol error when I try startx.

After installing libglvnd0 (and purging libglvnd0-nvidia)
everything is fine again. In contrast to what is reported in
https://lists.debian.org/debian-kde/2017/10/msg00028.html, the
problem appears again, when I reinstall libglvnd0-nvidia.

Bye,

Hendrik


-- Package-specific info:
uname -a:
Linux cert 4.13.0-1-amd64 #1 SMP Debian 4.13.4-1 (2017-10-01) x86_64 GNU/Linux

/proc/version:
Linux version 4.13.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
6.4.0 20170920 (Debian 6.4.0-7)) #1 SMP Debian 4.13.4-1 (2017-10-01)

lspci 'VGA compatible controller [0300]':
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 
[8086:191b] (rev 06) (prog-if 00 [VGA controller])
Subsystem: Lenovo HD Graphics 530 [17aa:5056]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

dmesg:

Device node permissions:
crw-rw+ 1 root video 226,   0 Oct 17 21:58 /dev/dri/card0
crw-rw+ 1 root video 226, 128 Oct 17 21:58 /dev/dri/renderD128

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Oct 17 21:58 pci-:00:02.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Oct 17 21:58 pci-:00:02.0-render -> ../renderD128
video:x:44:tews

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root 15 Sep 28 22:04 
/usr/lib/x86_64-linux-gnu/libEGL.so.1 -> libEGL.so.1.0.0
-rw-r--r-- 1 root root  76344 Sep 28 22:04 
/usr/lib/x86_64-linux-gnu/libEGL.so.1.0.0
lrwxrwxrwx 1 root root 14 Sep 28 22:04 /usr/lib/x86_64-linux-gnu/libGL.so.1 
-> libGL.so.1.0.0
-rw-r--r-- 1 root root 567624 Sep 28 22:04 
/usr/lib/x86_64-linux-gnu/libGL.so.1.0.0
lrwxrwxrwx 1 root root 18 Sep 28 22:04 
/usr/lib/x86_64-linux-gnu/libGLESv2.so.2 -> libGLESv2.so.2.0.0
-rw-r--r-- 1 root root  55616 Sep 28 22:04 
/usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0
-rw-r--r-- 1 root root 29 Jul  7 07:31 
/usr/lib/xorg/modules/extensions/libglx.so
-rw-r--r-- 1 root root   5883 Oct 17 09:07 /var/log/Xorg.0.log

/etc/modprobe.d:
total 24
drwxr-xr-x   2 root root  4096 Sep 18 13:14 .
drwxr-xr-x 162 root root 12288 Oct 17 21:55 ..
-rw-r--r--   1 root root   154 Nov 30  2016 amd64-microcode-blacklist.conf
-rw-r--r--   1 root root   154 Nov  9  2016 intel-microcode-blacklist.conf


/etc/modules-load.d:
-rw-r--r-- 1 root root  195 Mar  1  2017 /etc/modules

/etc/modules-load.d/:
total 20
drwxr-xr-x   2 root root  4096 Oct 17 08:42 .
drwxr-xr-x 162 root root 12288 Oct 17 21:55 ..
-rw-r--r--   1 root root   119 Jan 19  2017 cups-filters.conf
lrwxrwxrwx   1 root root10 Oct 11 00:46 modules.conf -> ../modules


Files from nvidia-installer:

Config and logfiles:

<< /home/tews/.local/share/xorg/Xorg.0.log >>
[32.985] 
X.Org X Server 1.19.3
Release Date: 2017-03-15
[32.991] X Protocol Version 11, Revision 0
[32.992] Build Operating System: Linux 4.9.0-3-amd64 x86_64 Debian
[32.994] Current Operating System: Linux cert 4.13.0-1-amd64 #1 SMP Debian 
4.13.4-1 (2017-10-01) x86_64
[32.994] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.13.0-1-amd64 
root=/dev/mapper/cert--vg-root1 ro single
[32.998] Build Date: 07 July 2017  06:22:09AM
[33.000] xorg-server 2:1.19.3-2 (https://www.debian.org/support) 
[33.001] Current version of pixman: 0.34.0
[33.005]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[33.005] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[33.012] (==) Log file: "/home/tews/.local/share/xorg/Xorg.0.log", Time: 
Tue Oct 17 21:58:39 2017
[33.019] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[33.024] (==) No Layout section.  Using the first Screen section.
[33.024] (==) No screen section available. Using defaults.
[33.024] (**) |-->Screen "Default Screen Section" (0)
[33.024] (**) |   |-->Monitor ""
[33.024] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[33.024] (==) Automatically adding devices
[33.024] (==) Automatically enabling 

Bug#877322: git-buildpackage autoremoval

[Guido Günther]

Hi,
On Tue, Oct 17, 2017 at 10:27:03PM +0100, Ian Jackson wrote:
> Guido Günther writes ("Re: Bug#877322: git-buildpackage autoremoval"):
> > On Tue, Oct 17, 2017 at 02:57:33PM +0100, Ian Jackson wrote:
> > > This bug means that the autoremoval robot wants to remove
> > > git-buildpackage.  I'm getting mails about it planning to remove dgit,
> > > to clear the way.
> > > 
> > > Do you intend to upload the docs change to sid soon ?
> > 
> > Yes, before the autoremoval for sure. Sorry for being a pain here but I
> > wanted to give gbp as much exposure as possible in experimental.
> 
> OK, fine.  Thanks for the reassurance.  If the deadline gets closer I
> may ping you again :-).

Sure. I have 1 more bug to go that affects 0.9.x but not 0.8.x that I
want to get done before moving to sid.
Cheers,
 -- Guido

Bug#878967: debian-policy: clarify purpose of debian/changelog

[Ross Vandegrift]

Package: debian-policy
Version: 4.1.1.1
Severity: normal

Section 4.4 explains quite a bit about debian/changelog, but doesn't really
explain its purpose.  I took its purpose to be recording history and driving
automation - which led to some mistakes that might've been avoided.  During a
recent thread on mentors [1], I learned that the purpose is to provide a human
readable list of changes between released versions of Debian.  This came as a
surprise.

I'm not sure how this should be worded best, but I found a number of the
comments on the thread to be helpful, especially [2].

Thanks,
Ross

[1] https://lists.debian.org/debian-mentors/2017/10/msg00145.html
[2] https://lists.debian.org/debian-mentors/2017/10/msg00178.html

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable'), (40, 'unstable'), (30, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.4.9-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

Bug#878935: Unsatisfiable dependencies on !amd64

[Ritesh Raj Sarraf]

Thanks for reporting this bug.

On Tue, 2017-10-17 at 21:23 +0200, Alexander Kurtz wrote:
> Package: libbpfcc
> Version: 0.3.0-3
> Severity: serious
> Justification: Makes the package uninstallable on most architectures
> 
> Hi!
> 
> As [0] shows, libbpfcc has unsatisfiable dependencies on everything
> but
> amd64. This is because [1] is inherently wrong, "linux-headers-amd64"
> is of course only available on amd64, the other architectures have
> their own meta-packages [2]. Unfortunately there is (AFAIK) no good
> way
> to properly solve the "this package needs the current kernel headers
> installed" problem in Debian because
> 
>1. There are no (real or virtual) "linux-{image,headers}-
>   generic" packages (like in Ubuntu [3,4]) which have the same
> name on
>   all architectures.
>2. Even if there were such packages, there's no guarantee that
> "linux-
>   headers-generic" would point to the headers matching the
> *currently
>   running* kernel (which is what libbcc needs). In fact, with
> partial
>   upgrades, migrations from unstable to testing, upgraded-but-
> not-yet-
>   rebooted machines, etc., it is quite likely that libbpfcc will
> be
>   broken even if all its dependencies are fulfilled.
> 
> I therefore ask you to
> 
>1. Revert [1].
>2. Reopen [5] and put a note regarding the requirements of the
> kernel
>   headers in README.Debian and/or the package description.
>3. Talk to the Debian Linux maintainers to find a proper solution
> to
>   this problem. It's probably not going to be easy, but these
> kinds of
>   problems really deserve to be fixed properly.
> 

Yes. My bad. I completely missed about the dependency's limitation
across architectures. I'll fix it soon.

README.Debian is the wise way to deal with it. There were similar
situation with systemtap too.

> Yes, this sucks. I have run into #877925 myself and also thought that
> this should be simply solvable with a dependency. Oh, well, at least
> you may take comfort in the fact that others [6] have also run into
> this problem... ;-)
> 
> Best regards
> 
> Alexander Kurtz
> 
> [0] https://tracker.debian.org/pkg/bpfcc
> [1] https://anonscm.debian.org/git/collab-maint/bpfcc.git/commit/?id=
> f73049e48fd98dd01d4475f88f6b490e6a1b34bb
> [2] https://packages.debian.org/source/sid/linux
> [3] https://packages.ubuntu.com/artful/linux-image-generic
> [4] https://packages.ubuntu.com/artful/linux-headers-generic
> [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877925
> [6] https://anonscm.debian.org/git/pkg-dkms/dkms.git/tree/debian/cont
> rol#n24
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

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

Bug#878966: nagios-plugins-contrib FTBFS with libvarnishapi-dev 5.2.0-1

[Adrian Bunk]

Source: nagios-plugins-contrib
Version: 21.20170222
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nagios-plugins-contrib.html

...
check_varnish.c: In function 'check_stats_cb':
check_varnish.c:193:33: error: 'const struct VSC_point' has no member named 
'section'
  assert(sizeof(tmp) > (strlen(pt->section->fantom->type) + 1 +
 ^
check_varnish.c:194:19: error: 'const struct VSC_point' has no member named 
'section'
  strlen(pt->section->fantom->ident) + 1 +
   ^
check_varnish.c:195:21: error: 'const struct VSC_point' has no member named 
'desc'; did you mean 'sdesc'?
  strlen(pt->desc->name) + 1));
 ^
...

Bug#876907: (no subject)

[Nikita Youshchenko]

forwarded 876907 https://bugs.kde.org/show_bug.cgi?id=377956
thanks

Same issue is mentioned in KDE bug tracker at
https://bugs.kde.org/show_bug.cgi?id=377956

Bug#878402: [debian-mysql] Bug#878402: Security fixes from the October 2017 CPU

[Lars Tangvald]

CVE List for 5.5:

CVE-2017-10268
CVE-2017-10378
CVE-2017-10379
CVE-2017-10384

--
Lars

On 13. okt. 2017 12:34, Norvald H. Ryeng wrote:

Source: mysql-5.5
Version: 5.5.57-0+deb8u1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for October 2017 will be released on
Tuesday, October 17. According to the pre-release announcement [1], it
will contain information about CVEs fixed in MySQL 5.5.58.

The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1] http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.alioth.debian.org_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=HPjEzLhETPj8fl9HCxxISaaV3f5tXDpGXDR3R2IELxg&m=dEyRpHvFwIr1RTEceqC6iy_yrzTaCF3pVSkZ3JFfOe4&s=0PVa9j2CKG1CAypoPA9B0-RLcMLbS5ifPg3jULC2EMw&e=

Bug#878965: systemd spam syslog with Detaching egress BPF program from cgroup failed: Invalid argument

[Boris Shtrasman]

Package: systemd
Version: 235-2
Severity: normal
Tags: upstream

Dear Maintainer,

Systemd spams my syslog with systemd[1]: Detaching egress BPF program
from cgroup failed: Invalid argument after boot and reloads.

systemd[1]: Detaching egress BPF program from cgroup failed: Invalid argument
systemd[1]: Attaching egress BPF program to cgroup 
/sys/fs/cgroup/unified/system.slice/systemd-udevd.service failed: Invalid 
argument
systemd[1]: Detaching egress BPF program from cgroup failed: Invalid argument

most the syslog is filled with that message:

grep "gress BPF program"  /var/log/syslog | wc -l:
1296

grep ""  /var/log/syslog | wc -l
1508

The kernel BPF settings (standard kernel from debian) :

grep BPF /boot/config-4.13.0-1-amd64
# CONFIG_CGROUP_BPF is not set
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_NETFILTER_XT_MATCH_BPF=m
CONFIG_NET_CLS_BPF=m
CONFIG_NET_ACT_BPF=m
CONFIG_BPF_JIT=y
CONFIG_LWTUNNEL_BPF=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_BPF_EVENTS=y
CONFIG_TEST_BPF=m

-- Package-specific info:

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.116
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-11
ii  libaudit1   1:2.8.1-1
ii  libblkid1   2.30.2-0.1
ii  libc6   2.24-17
ii  libcap2 1:2.25-1.1
ii  libcryptsetup4  2:1.7.5-1
ii  libgcrypt20 1.7.9-1
ii  libgpg-error0   1.27-3
ii  libidn111.33-2
ii  libip4tc0   1.6.1-2
ii  libkmod224-1
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.3
ii  libmount1   2.30.2-0.1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.7-2
ii  libsystemd0 235-2
ii  mount   2.30.2-0.1
ii  procps  2:3.3.12-3
ii  util-linux  2.30.2-0.1

Versions of packages systemd recommends:
ii  dbus1.11.20-1
ii  libpam-systemd  235-2

Versions of packages systemd suggests:
ii  policykit-10.105-18
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 235-2

-- debconf-show failed

Bug#876907: same here ...

[Nikita Youshchenko]

found 876907 4:5.8.6-2.1
thanks

Same happens on stretch. And is quite annoying ...

Looks like changing virtual desktop is not the only way to reproduce it. 
It happens on some other window manager (new windows appear, etc) 
related events as well.

Bug#878936: Solved: gpg - Inaccessible keys (?) after upgrade

[Frank B. Brokken]

Dear maintainer(s),

Wrt the bugreport I filed yesterday: after closely reading Gnu's gnupg
documentation I solved the problem I encountered yesterday, so I think this
issue can be closed.

My current gpg.conf file now merely needs 

use-agent

(and so `pinentry-mode loopback' was removed). My gpg-agent.conf file now
contains

default-cache-ttl 1200
pinentry-program /usr/bin/pinentry-curses


and so the line `allow-loopback-pinentry' was removed (the more generic
specification `pinentry-program /usr/bin/pinentry' probably also works, but so
far I didn't configure that)

In addition, whenever I open a new terminal (xterm, rxvt, virtual terminal)
the session's startup script executes (for bash):

GPG_TTY=`tty`   # note the backticks!
export GPG_TTY

For tcsh it is:

setenv GPG_TTY `tty`# note the backticks!

After these specifications gpg again worked as before.

Kind regards,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA

Bug#878744: close request :(

[Anthony Lee]

Sorry...It may not the bug of libinput, i've downgrade my libinput to the
version 1.8.2-1, but the bug still exists...
Probably the problem has caughted by KDE, so just close this bug tracking
for sure ...

Bug#802393: Upstream moved to gitlab

[Petter Reinholdtsen]

Control: forwarded -1 https://gitlab.xiph.org/xiph/vorbis/issues/2230

Update URL to upstream issue for this problem.

-- 
Happy hacking
Petter Reinholdtsen

Bug#772877: Upstream moved to gitlab

[Petter Reinholdtsen]

Control: forwarded -1 https://gitlab.xiph.org/xiph/vorbis/issues/1975

Update URL to upstream issue for this segfault problem.

-- 
Happy hacking
Petter Reinholdtsen

Bug#878964: ITP: python-easydev -- common utilities to ease the development of Python packages

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Team 
Control: block 878962 by -1
Control: block 878963 by -1

* Package name: python-easydev
  Version : 0.9.35
  Upstream Author : Thomas Cokelaer
* URL : https://easydev-python.readthedocs.io/en/latest/
* License : BSD
  Programming Lang: Python
  Description : common utilities to ease the development of Python packages

 The package easydev provides miscellaneous functions that are often used in
 other Python packages. easydev should help developers in speeding up their
 own developments.

This is a dependency of hinge and python-colormap. It will be maintained by the 
Debian Med team.

Bug#738850: ITP: iniparser -- a stand-alone INI file reading/writing library

[Salvatore Bonaccorso]

Control: tags -1 + pending

Hi

On Wed, Oct 11, 2017 at 11:07:11AM +0200, Salvatore Bonaccorso wrote:
> Hi Klee
> 
> Is it still planned to package iniparser for Debian? 
> 
> I know another small Projekt which I likely will use which depends on
> iniparser, so I wonder if uploading for Debian is still planned.

I took over Klee's initial packaging and uploaded the package (now
sitting in NEW).

https://ftp-master.debian.org/new/iniparser_4.0-1.html

If someone of you both would prefer to maintain it please let me know!

Regards,
Salvatore

Bug#878963: ITP: python-colormap -- ease manipulation of matplotlib colormaps and color codecs

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Team 
Control: block 878962 by -1

* Package name: python-colormap
  Version : 1.0.1
  Upstream Author : Thomas Cokelaer
* URL : https://colormap.readthedocs.io/
* License : BSD
  Programming Lang: Python
  Description : ease manipulation of matplotlib colormaps and color codecs

 The colormap package provides simple utilities to convert colors between RGB,
 HEX, HLS, HUV and a class to easily build colormaps for matplotlib. All
 matplotlib colormaps and some R colormaps are available altogether. The
 plot_colormap method (see below) is handy to quickly pick up a colormaps and
 the test_colormap is useful to see test a new colormap.

This is a dependency for hinge and so will be maintained by Debian Med as well.

Bug#878962: ITP: hinge -- long read genome assembler based on hinging

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Team 

* Package name: hinge
  Version : 0.5
  Upstream Author : Govinda Kamath,
Fei Xia,
Ilan Shomorony,
Thomas Courtade, and
David Tse
* URL : https://github.com/HingeAssembler/HINGE
* License : BSD
  Programming Lang: C++, Python
  Description : long read genome assembler based on hinging

 HINGE is a genome assembler that seeks to achieve optimal repeat resolution
 by distinguishing repeats that can be resolved given the data from those that
 cannot. This is accomplished by adding “hinges” to reads for constructing an
 overlap graph where only unresolvable repeats are merged. As a result, HINGE
 combines the error resilience of overlap-based assemblers with
 repeat-resolution capabilities of de Bruijn graph assemblers.


This will be maintained by the Debian Med team.

Bug#878961: debootstrap fails to resolve dependencies on virtual packages

[Daniel Drake]

Package: debootstrap
Version: 1.0.81ubuntu3.2
Severity: normal

debootstrap is unable to operate if the packages being included have a
virtual dependency which is not otherwise resolved.

Easy reproducer:
  # debootstrap --include=libnet-ssleay-perl stretch stretch
  [...]
  W: Failure while configuring base packages.  This will be re-attempted up to 
five times.
  W: See debootstrap.log for details (possibly the package libnet-ssleay-perl 
is at fault)

The log shows error:
  dpkg: dependency problems prevent configuration of libnet-ssleay-perl:
   libnet-ssleay-perl depends on perl-openssl-abi-1.1; however:
Package perl-openssl-abi-1.1 is not installed.

libnet-ssleay-perl depends on perl-openssl-abi-1.1, which is a virtual package
provided by perl-openssl-defaults.

debootstrap's pkgdetails_perl dependency resolution mechanism does not
consider virtual packages, so the dependency on perl-openssl-abi-1.1 is
basically ignored.

The expected outcome is for it to be resolved to perl-openssl-defaults,
which would then be installed along with the other packages and result in a
usable bootstrap.

I've reproduced this on v1.0.81ubuntu3.2 but from code inspection I can see
the same problem exists in current git - nothing examines Provides here.

Also reported at
https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/86536

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

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

Versions of packages debootstrap depends on:
ii  wget  1.18-2ubuntu1

Versions of packages debootstrap recommends:
ii  gnupg   2.1.15-1ubuntu7
ii  ubuntu-keyring  2016.10.27

debootstrap suggests no packages.

-- no debconf information

Bug#878960: requires iptables 1.6.1

[Daniel Baumann]

Package: nftables
Version: 0.8-1

Hi,

nftables requires iptables >= 1.6.1 in order to build. It's not so much
of a problem since sid has new enough iptables, however, it FTBFS'es on
stretch when backporting. It would be nice if you could bump the
build-dependencies accordingly.

Regards,
Daniel

Bug#878959: ITP: golang-github-k0kubun-colorstring - Go library for colorizing strings for terminal output

[Nobuhiro Iwamatsu]

Package: wnpp
Owner: Nobuhiro Iwamatsu 
Severity: wishlist

* Package name: golang-github-k0kubun-colorstring
  Version : 0.0~git20150214.0.9440f19
  Upstream Author : Takashi Kokubun
* URL : https://github.com/k0kubun/colorstring
* License : Expat
  Programming Lang: go
  Description : Go library for colorizing strings for terminal output

   colorstring is a Go library for outputting colored strings to a console
  using a simple inline syntax in your string to specify the color to print
as.

Bug#878755: RFS: node-macaddress/0.2.8-1 [ITP]

[Boyuan Yang]

在 2017年10月16日星期一 CST 下午8:59:48，Pirate Praveen 写道：
> On തിങ്കള്‍ 16 ഒക്ടോബര്‍ 2017 06:58 വൈകു, Boyuan Yang wrote:
> > It's my first package about nodejs modules. Any comments would be welcome.
> 
> Hi Boyuan,
> 
> The package looks good. Enabling tests would be nice. See
> https://wiki.debian.org/Javascript/Nodejs/Npm2Deb#Run_tests_if_available
> 
> Thanks
> Praveen

Thanks. I studied autopkgtest and added upstream-provided test to both 
dh_auto_test and autopkgtest. The new upload was pushed onto both mentors.d.n 
and git packaging repository [1]. Local test for autopkgtest also passed. [2]

Regards,
Boyuan Yang

[1] http://anonscm.debian.org/git/collab-maint/node-macaddress.git/
[2] I tried "autopkgtest ./node-macaddress_0.2.8-1.dsc -- schroot unstable-
amd64-sbuild" and the test passed successfully

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

Bug#821882: golang-github-k0kubun-pp: changing from RFP to ITP

[Nobuhiro Iwamatsu]

retitle 821882 ITP: golang-github-k0kubun-pp -- Go library for colored
pretty printing
owner 821882 !
thanks

Hi,

I am intrested in this package, I am going to package this.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#873520: lintian: Check for bad-distribution in debian/changelog too

[Chris Lamb]

Hi Jeremy,

> > However, unless I'm missing something this would mean that every
> > time you built a package locally as part of regular development it
> > would emit this tag.
> 
> I don't see that as a problem, but I really don't like seeing packages
> with UNRELEASED changelogs in Debian.

Thanks for your input. :)  I, too, do not like seeing packages in the
archive with UNRELEASED distributions.

However, many developers have a workflow where they develop with their
changelog set to UNRELEASED and check that the resulting builds are
"Lintian clean" before setting this to unstable and then uploading.

As this would emit a tag in this situation and whilst they could ignore
it, ensuring Lintian's output does not get become ignored is an important
and critical part of its maintainership.

(Is there some way we can detect the cowbuilder use-case? I do not use
that tool so don't know what the true situation is there.)


Regards,

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

Bug#878958: apt: let admins decide security matters not the apt team

[Nomen Nescio]

Package: apt
Version: 1.4.8
Severity: wishlist

Dear Maintainer,

Aptitude developers have taken the liberty of deciding for everyone
subjectively what quality of cryptographic signature is adequate for
everyone in a single sweeping decision, without knowing the individual
threat models and assets that the decision is trying to protect.  This
decision is in the wrong hands.  Sys admins are accountable for the
security of the systems they control, and so responsibility and
control should go to the same people who have accountability.

Specifically, consider the SHA1 removal, documented here:

  https://wiki.debian.org/Teams/Apt/Sha1Removal

If the apt team must decide on everyones security standards, blocking
SHA1 was a good move.  But that's not the case.  The apt suite of
tools could have some sensible defaults as far as which signing
algorithms are accepted or not, but ultimately the admin should be in
control of her own system.  Maybe an admin finds SHA256 insufficient,
and requires an even higher standard.  Who is the apt team to tell her
which algorithm she may and may not trust?

There is a hack to say trust all, which can even be used on a per
repository basis or all repositories, but this is the wrong mechanism
as it disables validity checking entirely.  The sys admin should
control which algorithms are fit for purpose, and the apt tool should
check validity on admin-permitted algorithms.

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/gc2latex.list present, but not submitted) --


-- (/etc/apt/sources.list.d/gc2latex.list.save present, but not submitted) --


-- (/etc/apt/sources.list.d/gc2latex.list~ present, but not submitted) --


-- (/etc/apt/sources.list.d/ring-nightly-main.list present, but not submitted) 
--


-- (/etc/apt/sources.list.d/ring-nightly-main.list.save present, but not 
submitted) --


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

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1508228706 WARNING 
torsocks[12992]: [syscall] Unsupported syscall number 217. Denying the call (in 
tsocks_syscall() at syscall.c:488)
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1508228706 WARNING torsocks[12994]: 
[syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() 
at syscall.c:488)
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2017.5
ii  gpgv2.1.18-8~deb9u1
ii  init-system-helpers 1.48
ii  libapt-pkg5.0   1.4.8
ii  libc6   2.24-11+deb9u1
ii  libgcc1 1:6.3.0-18
ii  libstdc++6  6.3.0-18

Versions of packages apt recommends:
ii  gnupg  2.1.18-8~deb9u1

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.7-1
ii  dpkg-dev1.18.24
ii  powermgmt-base  1.31+nmu1
pn  python-apt  
ii  synaptic0.84.2

-- debconf information excluded

Bug#878957: ITP: r-cran-cardata -- GNU R package for datasets for Companion to Applied Regression

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-cardata
  Version : 3.0-0
  Upstream Author : John Fox, Sanford Weisberg and Brad Price
* URL or Web page : https://cran.r-project.org/package=carData
* License : GPL (>= 2)
  Description : GNU R package for datasets for Companion to Applied 
Regression

This package was carved out of r-cran-car (which has been in Debian since
2003) and is now a Build-Depends for it.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#874153: FTBFS with Java 9: jre/bin/java

[Dirk Eddelbuettel]

Simon,

With your new rJava_0.9-9 I tried this against Debian's openjdk-9-jdk -- but
with R 3.4.2 as built against openjdk-7 -- and it still fails:

checking whether setjmp.h is POSIX.1 compatible... yes
checking whether sigsetjmp is declared... yes
checking whether siglongjmp is declared... yes
checking Java support in R... present:
interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
archiver: '/usr/lib/jvm/default-java/bin/jar'
compiler: '/usr/lib/jvm/default-java/bin/javac'
header prep.: '/usr/lib/jvm/default-java/bin/javah'
cpp flags   : '-I/usr/lib/jvm/default-java/include 
-I/usr/lib/jvm/default-java/include/linux'
java libs   : '-L/usr/lib/jvm/default-java/jre/lib/amd64/server -ljvm'
checking whether Java run-time works... ./configure: line 3736: 
/usr/lib/jvm/default-java/jre/bin/java: No such file or directory
no
configure: error: Java interpreter '/usr/lib/jvm/default-java/jre/bin/java' 
does not work
ERROR: configuration failed for package 'rJava'
* removing '/build/rjava-0.9-9/debian/r-cran-rjava/usr/lib/R/site-library/rJava'
/usr/share/R/debian/r-cran.mk:101: recipe for target 'R_any_arch' failed
make: *** [R_any_arch] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2


Any ideas?  I saw that r-devel got some changes related to javareconf.  Do we
need to port that to r-patched?  Can you advise?

Many thanks,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#878956: sddm doesn't update utmp or wtmp

[Ron Murray]

Package: sddm
Version: 0.15.0-1
Severity: normal

Dear Maintainer,

sddm doesn't seem to update /run/utmp or /var/log/wtmp. Logging in with it, the
'w' command gives me:

> ron@khufu:~$ w
>  21:09:47 up 36 min,  0 users,  load average: 0.10, 0.08, 0.20
> USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT

'last' gets me:
> ron@khufu:~$ last | head
> reboot   system boot  4.13.7-khufu-0   Tue Oct 17 16:33   still running
> reboot   system boot  4.13.7-khufu-0   Tue Oct 17 15:43 - 20:32  (04:49)
> reboot   system boot  4.13.7-khufu-0   Mon Oct 16 16:51 - 01:15  (08:24)
> reboot   system boot  4.13.6-khufu-0   Mon Oct 16 16:10 - 20:50  (04:40)
> reboot   system boot  4.13.6-khufu-0   Mon Oct 16 15:32 - 20:09  (04:37)
> reboot   system boot  4.13.6-khufu-0   Sun Oct 15 15:31 - 02:05  (10:33)
> reboot   system boot  4.13.6-khufu-0   Sun Oct 15 05:24 - 14:19  (08:55)
> reboot   system boot  4.13.6-khufu-0   Sun Oct 15 05:21 - 05:23  (00:02)
> reboot   system boot  4.13.6-khufu-0   Sat Oct 14 23:53 - 05:23  (05:30)

... and so on. (Lots of reboots because the box is dual-boot, and I need
Windows for games).

Finally, looking at both /var/run/utmp and /var/log/wtmp with bvies shows lots
of reboots, with the occasional SSH login. No logins from sddm.

Problem has been in evidence since I first installed sddm, long ago. Not
reported before because I assumed someone else would get to it first.

This also happens on my work Linux box.

Thanks,

 .Ron





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

Kernel: Linux 4.13.7-khufu-0 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sddm depends on:
ii  adduser   3.116
ii  debconf   1.5.63
ii  libc6 2.24-17
ii  libgcc1   1:7.2.0-8
ii  libpam0g  1.1.8-3.6
ii  libqt5core5a  5.9.1+dfsg-9
ii  libqt5dbus5   5.9.1+dfsg-9
ii  libqt5gui55.9.1+dfsg-9
ii  libqt5network55.9.1+dfsg-9
ii  libqt5qml55.9.1-6
ii  libqt5quick5  5.9.1-6
ii  libstdc++67.2.0-8
ii  libsystemd0   235-2
ii  libxcb-xkb1   1.12-1
ii  libxcb1   1.12-1
ii  qml-module-qtquick2   5.9.1-6
ii  tigervnc-standalone-server [xserver]  1.7.0+dfsg-7
ii  tightvncserver [xserver]  1:1.3.9-9
ii  x11-common1:7.7+19
ii  xserver-xephyr [xserver]  2:1.19.3-2
ii  xserver-xorg [xserver]1:7.7+19
ii  xvfb [xserver]2:1.19.3-2

Versions of packages sddm recommends:
ii  libpam-systemd 235-2
ii  sddm-theme-breeze [sddm-theme] 4:5.10.5-2
ii  sddm-theme-debian-breeze [sddm-theme]  4:5.10.5-2
ii  sddm-theme-debian-elarun [sddm-theme]  0.15.0-1
ii  sddm-theme-debian-maui [sddm-theme]0.15.0-1
ii  sddm-theme-elarun [sddm-theme] 0.15.0-1
ii  sddm-theme-maldives [sddm-theme]   0.15.0-1
ii  sddm-theme-maui [sddm-theme]   0.15.0-1

Versions of packages sddm suggests:
pn  libpam-kwallet5  

-- debconf information:
* shared/default-x-display-manager: sddm
  sddm/daemon_name: /usr/bin/sddm

Bug#878948:

[Sebastian Wyngaard]

I can also confirm encountering this bug on testing.

Downgrading the above-mentioned packages works for me too. Thanks!

Bug#878955: Drop root permissions by default like other sshd, postfix, and others

[Nicholas D Steeves]

Package: lxc
Version: 1:2.0.7-2
Severity: normal

Dear Maintainer[s],

Sshd, postfix, and most other system services drop permissions are quickly as 
possible.  Given that LXC supports unpriviledged containers, could we please do 
the following?

1. Create an lxc user and group
2. Default to unpriviledged container creation
   - in /var/lib/lxc, as we do now
3. Use lxc for both /etc/subuid and /etc/subgid
4. Default permissive policy when upgrading
   a. include a file to allow bind mounts
   b. include a file to allow more permissive networking
   c. and others
5. Default restrictive policy for fresh installations

I'm working on many other projects at the moment, so it will be a while before 
I can contribute anything towards solving this bug.

I also wonder if the LXC "pivot" can be leveraged in case (a) is infeasible.  
eg: as root, set up mounts in pre-location, pivot into place, drop permissions 
to lxc:lxc.  Then, when stopping a container as root reverse this sequence.

Proxmox is downstream from Debian and IIRC has transitioned from OpenVZ to LXC, 
so maybe we could consult them and merge some of their work?

Cheers,
Nicholas

Bug#878954: libunwind-dev, breakage when building with -std=c99

[peter green]

Package: libunwind-dev

I was trying to build mesa in raspbian and the build environment happened to 
have libunwind-dev
installed and mesa tried to use it, resulting in a build failure.

../../../../src/gallium/auxiliary/util/u_debug_stack.c:114:4: error: expected 
‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘asm’
 unw_getcontext(&context);

Some discussion on #dri-devel on freenode and some local testing revealed that 
unw_getcontext is broken when building on arm with
-std=c99 , building a trivial test file fails with the same error the mesa 
build failed with. The trivial test file is given below.

#include 
void test(void) {
   unw_context_t context;
   unw_getcontext(&context);
}

There is apparently a patch for this at 
http://patchwork.ozlabs.org/patch/783462/ but I have not tested said patch.

Bug#878953: libpurple0: please stop linking to libfarstream

[Michael Stone]

Package: libpurple0
Version: 2.12.0-1+b1
Severity: wishlist

Linking to libfarstream means pulling in gstreamer-plugins-bad, which in
addition to having literally hundreds of megabytes of dependencies, describes
itself as "plugins which aren't up to par", for example they may be unreviewed
or rarely used code. Getting those dependencies should require a more conscious
intent than a side effect of installing a program like pidgin which, though it
can theoretically be used for video chat, is far more commonly used for text
chat. In my experience the video chat features have never worked very well, but
if there are really people who use it perhaps that can be separated into a
different package so people who just want to IM don't have to increase the
attack surface of anything that uses gstreamer.

Mike Stone

Bug#878952: scdaemon: avoid ptrace on scdaemon?

[Daniel Kahn Gillmor]

Package: scdaemon
Version: 2.2.1-2
Severity: normal

Debian currently ships with
debian/patches/block-ptrace-on-agent/Avoid-simple-memory-dumps-via-ptrace.patch,
which blocks a simple attack where any process running as the same
user can trace its system calls and memory.  This isn't bulletproof,
but it raises the bar against a casual attacker.

However, we're not shipping the same protection for scdeamon.

This means, for example, that a process running as the same user could
attach strace to scdaemon and snoop PINs or traffic sent to and from
the smartcard.

Should we add a similar "prctl(PR_SET_DUMPABLE, 0)" to scdaemon as
well?

--dkg

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

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

Versions of packages scdaemon depends on:
ii  gpg-agent  2.2.1-2
ii  libassuan0 2.4.3-3
ii  libc6  2.24-17
ii  libgcrypt201.7.9-1
ii  libgpg-error0  1.27-3
ii  libksba8   1.3.5-2
ii  libnpth0   1.5-2
ii  libusb-1.0-0   2:1.0.21-2

scdaemon recommends no packages.

scdaemon suggests no packages.

-- no debconf information

Bug#878912: docker.io: docker run fails saying that containerd-shim not installed

[Tianon Gravi]

tags 878912 + moreinfo unreproducible
severity normal
thanks

On 17 October 2017 at 10:05, Antonio Terceiro  wrote:
> On a completely up to date sid system:
>
> $ docker run -it --rm debian:sid
> docker: Error response from daemon: containerd-shim not installed on system.

I can't seem to reproduce; created a completely fresh Sid instance,
installed docker.io, and got the following result:


The following NEW packages will be installed:
   dmsetup (2:1.02.142-1)
   docker-containerd (0.2.3+git+docker1.13.1~ds1-1)
   docker-runc (1.0.0~rc2+git+docker1.13.1~ds1-2)
   docker.io (1.13.1~ds2-3)
   golang-libnetwork (0.8.0-dev.2+git20170202.599.45b4086-3)
   iptables (1.6.1-2)
   libapparmor1 (2.11.0-11)
   libdevmapper1.02.1 (2:1.02.142-1)
   libip4tc0 (1.6.1-2)
   libip6tc0 (1.6.1-2)
   libiptc0 (1.6.1-2)
   libnetfilter-conntrack3 (1.0.6-2)
   libnfnetlink0 (1.0.1-3+b1)
   libseccomp2 (2.3.1-2.1)
   libsqlite3-0 (3.20.1-2)
   libxtables12 (1.6.1-2)
0 upgraded, 16 newly installed, 0 to remove and 25 not upgraded.


$ docker version
Client:
 Version:  1.13.1
 API version:  1.26
 Go version:   go1.9.1
 Git commit:   092cba3
 Built:Sat Oct 14 16:54:40 2017
 OS/Arch:  linux/amd64

Server:
 Version:  1.13.1
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.9.1
 Git commit:   092cba3
 Built:Sat Oct 14 16:54:40 2017
 OS/Arch:  linux/amd64
 Experimental: false


$ docker run -it --rm debian:sid
Unable to find image 'debian:sid' locally
sid: Pulling from library/debian
3a8649ffa174: Pull complete
Digest: sha256:58c8f0c963c0813cbad2809a12b1ca9031e3ab5aa31258f2675c65a42475dc23
Status: Downloaded newer image for debian:sid
root@b9ed033bd019:/# ls -l
total 48
lrwxrwxrwx   1 root root7 Oct  9 00:00 bin -> usr/bin
drwxr-xr-x   2 root root 4096 Jun 25 22:19 boot
drwxr-xr-x   5 root root  360 Oct 17 23:54 dev
drwxr-xr-x  30 root root 4096 Oct 17 23:54 etc
drwxr-xr-x   2 root root 4096 Jun 25 22:19 home
lrwxrwxrwx   1 root root7 Oct  9 00:00 lib -> usr/lib
lrwxrwxrwx   1 root root9 Oct  9 00:00 lib32 -> usr/lib32
lrwxrwxrwx   1 root root9 Oct  9 00:00 lib64 -> usr/lib64
lrwxrwxrwx   1 root root   10 Oct  9 00:00 libx32 -> usr/libx32
drwxr-xr-x   2 root root 4096 Oct  9 00:00 media
drwxr-xr-x   2 root root 4096 Oct  9 00:00 mnt
drwxr-xr-x   2 root root 4096 Oct  9 00:00 opt
dr-xr-xr-x 440 root root0 Oct 17 23:54 proc
drwx--   2 root root 4096 Oct  9 00:00 root
drwxr-xr-x   4 root root 4096 Oct  9 00:00 run
lrwxrwxrwx   1 root root8 Oct  9 00:00 sbin -> usr/sbin
drwxr-xr-x   2 root root 4096 Oct  9 00:00 srv
dr-xr-xr-x  12 root root0 Oct 17 23:54 sys
drwxrwxrwt   2 root root 4096 Oct  9 00:00 tmp
drwxr-xr-x  13 root root 4096 Oct  9 00:00 usr
drwxr-xr-x  11 root root 4096 Oct  9 00:00 var



Have you restarted your Docker daemon since upgrading?  If not, it's
likely still running the old daemon referencing the older packages,
and the package tries to be careful about automatically restarting
your daemon because that can cause downtime for your containers.

Since this looks to be environmental, I've downgraded the severity and
updated the tags of this bug accordingly.

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

[Michael Stone]

On Tue, Oct 17, 2017 at 10:26:06PM +0200, Guus Sliepen wrote:

On Mon, Oct 16, 2017 at 10:21:10PM -0400, Michael Stone wrote:

On Tue, Oct 17, 2017 at 12:05:30AM +0200, Guus Sliepen wrote:
> despite fears of OpenBSD only caring about themselves, I have found that
> it is easier to compile LibreSSL for various platforms (even non-POSIX
> ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
> is ridiculous, as it is OpenSSL iself that has changed its API in a
> non-backwards compatible way that is now causing this discussion.

It is not ridiculous to point out that LibreSSL is released every six months
and supported for one year after release, while OpenSSL is supported for at
least 2 years, and 5 years for LTS releases.


That is certainly not ridiculous. But, I had a look at the release plan
for OpenSSL at https://www.openssl.org/policies/releasestrat.html, and
it seems there only is one LTS release, namely 1.0.2, which will be
supported until the very end of 2019. 1.1.0 is only supported until
September 2018. In that context it is strange that we switched to 1.1.0
in stretch already. Let's hope there is an LTS for 1.1.x in time for
buster.


I'd expect a 1.1.1 release with a relatively small delta (no major API 
changes, and a relatively straightforward backporting effort) from 1.1. 
The LTS is most valuable for an API branch no longer being actively 
developed, and if 1.1.1 was followed by 1.2, I'd expect LTS for 1.1.1.



It's not unrealistic to think
that a Debian stable could release with a LibreSSL that's already
unsupported upstream. It is also not ridiculous to point out that a number
of distributions have an interest in long term maintenance of released
versions of OpenSSL, while there is no such community around LibreSSL.


Maybe not currently for Debian or Fedora derivatives, but some
distributions (Alpine, OpenELEC amongst others) have switched to
LibreSSL as the default, and some (Gentoo, unsurprisingly) have it as an
option.


Without getting into a discussion of various distributions, suffice it 
to say that these are not ones known for long term binary support.



As I continue to think about it, it may actually end up being better to
embed a constrained subset of LibreSSL in OpenSSH than worry about either
maintaining the entire LibreSSL package over a period of years, or fork.


I don't see why it couldn't be in its own package even if OpenSSH was
the only user. It doesn't change the maintenance burden.


Because the parts of libressl used in openssh (a subset of libcrypto) 
historically have had fewer problems then the mess of stuff in libssl.  
The attack surface of that subset of functions in ssh is a lot lower 
than "any package that uses ssl and happens to link to libressl".


Mike Stone

Bug#821842: golang-github-kotakanbe-go-pingscanner: changing from RFP to ITP

[Nobuhiro Iwamatsu]

retitle 821842 ITP: golang-github-kotakanbe-go-pingscanner -- Go
library for scanning hosts in CIDR range
owner821842 !
thanks

Hi,

I am intrested in this package, I am going to package this.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#873520: lintian: Check for bad-distribution in debian/changelog too

[Jeremy Bicha]

On Tue, Oct 17, 2017 at 7:23 PM, Chris Lamb  wrote:
> However, unless I'm missing something this would mean that every
> time you built a package locally as part of regular development it
> would emit this tag.

I don't see that as a problem, but I really don't like seeing packages
with UNRELEASED changelogs in Debian.

Thanks,
Jeremy Bicha

Bug#863518: Closing bug

[Arturo Borrero Gonzalez]

Hi,

closing this bug now. This seems bogus.

Bug#862318: bug fixed in nftables v0.8

[Arturo Borrero Gonzalez]

Control: fixed -1 0.8-1
Hi,

this bug is fixed in nftables v0.8 which is now in the archive.

Bug#870078: libsane1 breaks all 3rd party scanner drivers

[Jeremy Bicha]

I am reopening this bug because I think the original reporter's
suggestion was right. The fact that he runs Ubuntu doesn't matter for
the bug that was reported.

Please see the Impact and Test Case I added to the description of
https://launchpad.net/bugs/1707352

I am adding Provides: libsane to Ubuntu's libsane1 and I strongly
encourage you to make this change in Debian also.

Thanks,
Jeremy Bicha

Bug#862320: nftables v0.8 available in Debian

[Arturo Borrero Gonzalez]

Hi,

Debian now contains nftables v0.8 which includes support for ct helpers.

Bug#878951: waagent: Create /var/lib/waagent directory with perm 0700

[Stephen Zarkos]

Package: waagent
Version: 2.2.14-1~deb9u1
Severity: normal

Hi Bastian,

The postinst script for the waagent package creates the /var/lib/waagent dir 
with mode "u+rwx".
This appears OK, but with the default umask the result is that /var/lib/waagent 
is created with
mode 0755. It would be better if it was 0700. So in postinst instead of setting 
mode "u+rwx" we
could perhaps use something like "u+rwx,g=,o=" instead.

For example, the upstream agent will create /var/lib/waagent on the fly with 
perm 0700 if it does
not already exist: 
https://github.com/Azure/WALinuxAgent/blob/4316e399cee9359c59298ff494b58ffbf5121e2b/azurelinuxagent/daemon/main.py#L110



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

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

Versions of packages waagent depends on:
ii  bind9-host [host]  1:9.10.3.dfsg.P4-12.3+deb9u3
ii  ca-certificates20161130+nmu1
ii  eject  2.1.5+deb1+cvs20081104-13.2
ii  host   1:9.10.3.dfsg.P4-12.3+deb9u3
ii  init-system-helpers1.48
ii  iptables   1.6.0+snapshot20161117-6
ii  net-tools  1.60+git20161116.90da8a0-1
ii  openssh-server 1:7.4p1-10+deb9u1
ii  openssl1.1.0f-3
ii  parted 3.2-17
ii  python33.5.3-1
ii  python3-pkg-resources  33.1.1-1
ii  sudo   1.8.19p1-2.1

waagent recommends no packages.

waagent suggests no packages.

-- no debconf information

Bug#873612: lintian: please check latest-debian-changelog-entry-without-new-date for sources as well

[Mattia Rizzolo]

On Wed, Oct 18, 2017 at 12:20:47AM +0100, Chris Lamb wrote:
> Fixed in Git:

Thanks!

Do you think you could also take care (once lintian is backported,
installed, etc etc) to have it added to the autorejects done in dak?

As it really makes no sense to have backward-running changelogs, and I'm
sure that this bug was triggered by some sort of discussion on IRC
proposing the same…

-- 
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#873520: lintian: Check for bad-distribution in debian/changelog too

[Chris Lamb]

tags 873520 + patch wontfix
thanks

Hi,

> lintian: Check for bad-distribution in debian/changelog too

Patch attached (see below).

However, unless I'm missing something this would mean that every
time you built a package locally as part of regular development it
would emit this tag.

I think this would be far too annoying, so am marking this as wontfix
unless one can think of a nicer way of detecting this.




  commit 0c261c49b135a50a88b443ed8dc1a627b2c6358d
  Author: Chris Lamb 
  Date:   Tue Oct 17 19:17:30 2017 -0400
  
  Check source packages for UNRELEASED distributions too. (Closes: #873520)
  
   checks/source-changelog.desc   | 7 
+++
   checks/source-changelog.pm | 4 
   debian/changelog   | 2 ++
   .../changelog-file-national-encoding/debian/debian/changelog.in| 2 +-
   t/tests/changelog-file-unreleased/desc | 2 ++
   t/tests/changelog-file-unreleased/tags | 1 +
   t/tests/standards-version-timewarp-unrel/desc  | 2 ++
   t/tests/standards-version-timewarp-unrel/tags  | 1 +
   8 files changed, 20 insertions(+), 1 deletion(-)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
>From 0c261c49b135a50a88b443ed8dc1a627b2c6358d Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Tue, 17 Oct 2017 19:17:30 -0400
Subject: [PATCH] Check source packages for UNRELEASED distributions too.
 (Closes: #873520)

---
 checks/source-changelog.desc   | 7 +++
 checks/source-changelog.pm | 4 
 debian/changelog   | 2 ++
 .../changelog-file-national-encoding/debian/debian/changelog.in| 2 +-
 t/tests/changelog-file-unreleased/desc | 2 ++
 t/tests/changelog-file-unreleased/tags | 1 +
 t/tests/standards-version-timewarp-unrel/desc  | 2 ++
 t/tests/standards-version-timewarp-unrel/tags  | 1 +
 8 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/checks/source-changelog.desc b/checks/source-changelog.desc
index 32f4615ea..949c1b3c2 100644
--- a/checks/source-changelog.desc
+++ b/checks/source-changelog.desc
@@ -16,3 +16,10 @@ Info: The latest Debian changelog entry has either the same or even an
  This can result in subtle bugs due to the SOURCE_DATE_EPOCH
  environment variable being the same between the older and newer
  versions.
+
+Tag: unreleased-changelog-distribution
+Severity: important
+Certainty: certain
+Info: The distribution in the latest Debian changelog entry indicates
+ that this package was not intended to be released yet.
+Ref: #873520
diff --git a/checks/source-changelog.pm b/checks/source-changelog.pm
index d37c4d5ea..29f19502d 100644
--- a/checks/source-changelog.pm
+++ b/checks/source-changelog.pm
@@ -29,6 +29,10 @@ sub run {
 my ($pkg, undef, $info, undef, undef) = @_;
 
 my @entries = $info->changelog->data;
+
+tag 'unreleased-changelog-distribution' if
+@entries and lc($entries[0]->Distribution) eq 'unreleased';
+
 if (@entries > 1) {
 my $first_timestamp = $entries[0]->Timestamp;
 my $second_timestamp = $entries[1]->Timestamp;
diff --git a/debian/changelog b/debian/changelog
index 2facee400..e61f6e367 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -29,6 +29,8 @@ lintian (2.5.56) UNRELEASED; urgency=medium
   * checks/source-changelog.{desc.pm}:
 + [CL] Move latest-debian-changelog-entry-without-new-date tag into a
   new check of type "source".  (Closes: #873612)
++ [CL] Check source packages for UNRELEASED distributions too.
+  (Closes: #873520)
   * checks/watch-file.pm:
 + [CL] Include the offending URI in debian-watch-uses-insecure-uri
   output, not the line number.
diff --git a/t/tests/changelog-file-national-encoding/debian/debian/changelog.in b/t/tests/changelog-file-national-encoding/debian/debian/changelog.in
index 39df74576..27145cd14 100644
--- a/t/tests/changelog-file-national-encoding/debian/debian/changelog.in
+++ b/t/tests/changelog-file-national-encoding/debian/debian/changelog.in
@@ -1,4 +1,4 @@
-{$source} ({$version}) UNRELEASED; urgency=low
+{$source} ({$version}) unstable; urgency=low
 
   * Lintian Test Suite.
   * Test: {$testname}
diff --git a/t/tests/changelog-file-unreleased/desc b/t/tests/changelog-file-unreleased/desc
index 0b0285429..f5a0f3494 100644
--- a/t/tests/changelog-file-unreleased/desc
+++ b/t/tests/changelog-file-unreleased/desc
@@ -4,4 +4,6 @@ Description: Suppress new date warnings for UNRELEASED
 Test-Against:
  latest-changelog-entry-without-new-date
  latest-debian-changelog-entry-without-new-date
+Test-For:
+ unreleased-changelog-distribution
 Refere

Bug#873612: lintian: please check latest-debian-changelog-entry-without-new-date for sources as well

[Chris Lamb]

Hi Mattia,

> Do you think you could also take care (once lintian is backported,
> installed, etc etc) to have it added to the autorejects done in dak?

I will try and remember. Thanks :)



Regards,

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

Bug#878912: Works for me

[Javier Barroso]

$ apt list --installed  'docker*'
Listando... Hecho
docker-containerd/unstable,now 0.2.3+git+docker1.13.1~ds1-1 amd64
[instalado, automático]
docker-runc/unstable,now 1.0.0~rc2+git+docker1.13.1~ds1-2 amd64
[instalado, automático]
docker.io/unstable,now 1.13.1~ds2-3 amd64 [instalado]
$ dpkg -S /usr/bin/containerd-shim /usr/bin/docker-containerd-shim
containerd: /usr/bin/containerd-shim
docker-containerd: /usr/bin/docker-containerd-shim

But :

$ aptitude why containerd
Automatically installed, current version
0.2.3+git20170126.85.aa8187d~ds1-2, priority opcional
No dependencies require to install containerd

$ sudo apt remove containerd
...

And

$ docker container [ stop / start ] idcontainer work # work before and
after removing containerd

I do not want to tag this bug as fixed, maybe work for me but not for you

Regards

Bug#873612: lintian: please check latest-debian-changelog-entry-without-new-date for sources as well

[Chris Lamb]

tags 873612 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=b1223f09dc46bf06e6294a17b4bed99df70f045a


Regards,

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

Bug#877075: sikulix: hard coded dependency on libopencv2.4-java

[Gilles Filippini]

Mattia Rizzolo a écrit le 18/10/2017 à 01:11 :
> On Wed, Oct 18, 2017 at 12:58:32AM +0200, Gilles Filippini wrote:
>> On Tue, 17 Oct 2017 12:48:29 +0200 Mattia Rizzolo  wrote:
>>> On Tue, Oct 17, 2017 at 10:26:11AM +0200, Gilles Filippini wrote:
 How about mavenizing OpenCV Java lib so that ${maven:Depends} would find
 out the right libopencvX.Y-java dependency?
>>>
>>> I'll happily accept patches for that.
>>
>> Attached.
> 
> Thank you!
> 
> It will definitely be part of the next upload, although I'd like to
> avoid to do a 4th upload in just 3 days… OpenCV is not exactly light,
> there are several architectures where it takes more than 12h to build.
> Could you consider keeping the hardconded lib just a little longer and
> bump the version?

Will do it by tomorrow.

> We will have to do another opencv transition soon after this one ended
> anyway (if we manage to get it build right the way we want it…), so we
> will have ways to employ this thing soon enough.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#878950: nftables: update nftables to 0.8

[Arturo Borrero Gonzalez]

Control: tags -1 pending


On 18 October 2017 at 01:01, Matteo Croce  wrote:
> Package: nftables
> Version: 0.7-2
> Severity: wishlist
>
> Dear Maintainer,
>
> Please consider updating nftables to 0.8 which finally
> supports TCP MSS clamping to MTU.
>

Doing that right now :-)

Bug#877075: sikulix: hard coded dependency on libopencv2.4-java

[Mattia Rizzolo]

On Wed, Oct 18, 2017 at 12:58:32AM +0200, Gilles Filippini wrote:
> On Tue, 17 Oct 2017 12:48:29 +0200 Mattia Rizzolo  wrote:
> > On Tue, Oct 17, 2017 at 10:26:11AM +0200, Gilles Filippini wrote:
> > > How about mavenizing OpenCV Java lib so that ${maven:Depends} would find
> > > out the right libopencvX.Y-java dependency?
> > 
> > I'll happily accept patches for that.
> 
> Attached.

Thank you!

It will definitely be part of the next upload, although I'd like to
avoid to do a 4th upload in just 3 days… OpenCV is not exactly light,
there are several architectures where it takes more than 12h to build.
Could you consider keeping the hardconded lib just a little longer and
bump the version?

We will have to do another opencv transition soon after this one ended
anyway (if we manage to get it build right the way we want it…), so we
will have ways to employ this thing soon enough.

-- 
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#878950: nftables: update nftables to 0.8

[Matteo Croce]

Package: nftables
Version: 0.7-2
Severity: wishlist

Dear Maintainer,

Please consider updating nftables to 0.8 which finally
supports TCP MSS clamping to MTU.

Regards,

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

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

Versions of packages nftables depends on:
ii  libnftnl7  1.0.8-1

nftables recommends no packages.

nftables suggests no packages.

-- Configuration Files:
/etc/nftables.conf changed [not included]

-- no debconf information

Bug#878949: libopencv3.2-java - Please install maven artifacts

[Gilles Filippini]

Package: libopencv3.2-java
Version: 3.2.0+dfsg-2
Severity: normal
Control: block 877075 by -1
Control: tags -1 + patch

On Tue, 17 Oct 2017 12:48:29 +0200 Mattia Rizzolo  wrote:
> On Tue, Oct 17, 2017 at 10:26:11AM +0200, Gilles Filippini wrote:
> > How about mavenizing OpenCV Java lib so that ${maven:Depends} would find
> > out the right libopencvX.Y-java dependency?
> 
> I'll happily accept patches for that.

Attached.

Thanks,

_g.
diff -Nru opencv-3.2.0+dfsg/debian/changelog opencv-3.2.0+dfsg/debian/changelog
--- opencv-3.2.0+dfsg/debian/changelog  2017-10-16 23:44:22.0 +0200
+++ opencv-3.2.0+dfsg/debian/changelog  2017-10-17 18:57:08.0 +0200
@@ -1,3 +1,10 @@
+opencv (3.2.0+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install maven artifacts
+
+ -- Gilles Filippini   Tue, 17 Oct 2017 18:57:08 +0200
+
 opencv (3.2.0+dfsg-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru opencv-3.2.0+dfsg/debian/control opencv-3.2.0+dfsg/debian/control
--- opencv-3.2.0+dfsg/debian/control2017-10-16 23:42:54.0 +0200
+++ opencv-3.2.0+dfsg/debian/control2017-10-17 18:57:08.0 +0200
@@ -13,6 +13,7 @@
  dh-python,
  doxygen,
  javahelper,
+ maven-repo-helper,
  libavcodec-dev,
  libavformat-dev,
  libavresample-dev,
diff -Nru opencv-3.2.0+dfsg/debian/libopencv3.2-java.poms 
opencv-3.2.0+dfsg/debian/libopencv3.2-java.poms
--- opencv-3.2.0+dfsg/debian/libopencv3.2-java.poms 1970-01-01 
01:00:00.0 +0100
+++ opencv-3.2.0+dfsg/debian/libopencv3.2-java.poms 2017-10-17 
18:57:08.0 +0200
@@ -0,0 +1 @@
+debian/pom.xml --usj-name=opencv
diff -Nru opencv-3.2.0+dfsg/debian/pom.xml opencv-3.2.0+dfsg/debian/pom.xml
--- opencv-3.2.0+dfsg/debian/pom.xml1970-01-01 01:00:00.0 +0100
+++ opencv-3.2.0+dfsg/debian/pom.xml2017-10-17 18:57:08.0 +0200
@@ -0,0 +1,29 @@
+http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
+4.0.0
+org.opencv
+opencv
+jar
+3.2.0
+OpenCV
+
+
+License Agreement For Open Source Computer Vision Library 
(3-clause BSD License)
+
+
+
+http://opencv.org/
+
+scm:git:https://github.com/Itseez/opencv.git
+https://github.com/Itseez/opencv
+
+
+
+Kerry Billingham
+contact (at) AvionicEngineers (d0t) c(0)m
+Java Technics
+www.javatechnics.com
+
+
+
+
diff -Nru opencv-3.2.0+dfsg/debian/rules opencv-3.2.0+dfsg/debian/rules
--- opencv-3.2.0+dfsg/debian/rules  2017-10-16 22:38:08.0 +0200
+++ opencv-3.2.0+dfsg/debian/rules  2017-10-17 18:57:08.0 +0200
@@ -60,7 +60,7 @@
$(CMAKE_ARCH_FLAGS)
 
 %:
-   dh $@ --with python2,python3,javahelper --parallel
+   dh $@ --with python2,python3,javahelper,jh_maven_repo_helper --parallel
 
 override_dh_clean:
rm -rvf modules/python/src2/hdr_parser.pyc


signature.asc
Description: OpenPGP digital signature

Bug#878948:

[Arturo Borrero Gonzalez]

Control: found -1 17.2.2-1

Bug#821901: golang-github-google-subcommands: changing from RFP to ITP

[Nobuhiro Iwamatsu]

retitle 821901 ITP: golang-github-google-subcommands -- a subcommand
library for Google Go
owner 821901 !
thanks

Hi,

I am intrested in this package, I am going to package this.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#878947: mksh -n: "internal error: can't allocate ..."

[Jakub Wilk]

Package: mksh
Version: 56b-2

mksh runs out of memory when checking syntax of some scripts, for 
example:


  $ mksh -n -c '${0$(($(o[))&$(($(o[))&)'
  internal error: can't allocate 2147483668 data bytes


-- System Information:
Architecture: i386

Versions of packages mksh depends on:
ii  libc6  2.24-17

--
Jakub Wilk

Bug#878855: please drop transitional package rcs-latex

[Julian Gilbey]

reassign 878855 ftp.debian.org
retitle 878855 RM: rcs-latex -- ROM; transitional package no longer needed
thanks

See the QA report below - this transitional package is no longer
needed in buster.

Best wishes,

   Julian

On Tue, Oct 17, 2017 at 11:33:24AM +0200, Holger Levsen wrote:
> Package: rcs-latex
> Version: 3.1.debian.1
> Severity: normal
> user: qa.debian@packages.debian.org
> usertags: transitional
> 
> Please drop the transitional package rcs-latex for buster,
> as it has been released with wheezy, jessie and stretch already.
> 
> Thanks for maintaining rcs-latex!
> 
> 
> -- 
> cheers,
>   Holger

Bug#781372: lintian: Please permit empty md5sums files

[Chris Lamb]

tags 781372 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d03b70d46928b86c214bbf36887176e6a10370dd


Regards,

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

Bug#878909: RFS: xabacus/8.1.3+dfsg1-1 [ITA]

[Adam Borowski]

On Tue, Oct 17, 2017 at 06:39:02PM +0200, Innocent De Marchi wrote:
>  * Package name: xabacus
>Version : 8.1.3+dfsg1-1

>   Changes since the last upload:
> 
>   * New maintainer (Closes: #870519).
>   * Deleted unnecessary sources directory win32 and repackaging.
>   * Update debian/watch file to version 4 and added dversionmangle
> option.
>   * Update Standards-Version (4.1.1):
> - Removed autotools-dev dependency on debian/control.
>   * Added Chris Lamb patch on debian/rules (Closes: #865994).
  ^^
Could you please explain what the patch does?

Kind of like: "Make the build reproducible, thanks Chris Lamb.".

>   * Changed the Priority field to optional from xmabacus 
> on debian/control.
>   * Removed duplicate field Priority on debian/control.
>   * Added Keywords field on debian/*.desktop files.
>   * Removed obsolete menu files on debian directory.
>   * Re-written the debian/copyright file to the standard 1.0 format.

The new version puts a helper script into $PATH: /usr/games/play.sh
This doesn't look like a good place for a private helper.  Its name is also
pretty generic, not conflicting with other programs only because
filename extensions are banned in $PATH (Policy §10.4).

Thus, could you please move it into a private dir?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

Bug#878946: coreutils: ls displays unneeded quotes in output

[George Bateman]

Package: coreutils
Version: 8.28-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

ls on a filename with spaces gives quotes for no particular reason:

'a b'

Tabs are substantially worse:

'a'$'\t''b'

Can this be fixed?

Best wishes,
George Bateman.

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 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 coreutils depends on:
ii  libacl1  2.2.52-3+b1
ii  libattr1 1:2.4.47-2+b2
ii  libc62.24-17
ii  libselinux1  2.7-2

coreutils recommends no packages.

coreutils suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEhCkfJ9Js3nBacaLYxBeqnEA5788FAlnmfd0bHGdlb3JnZS5i
YXRlbWFuMTZAZ21haWwuY29tAAoJEMQXqpxAOe/P3HUIAJRmUW6X4aEWWO3HJ5dh
QNHv7l+YXfeZckDHPR0g3ClBMOKd5snprjRbINhZG/slL6TMTi6vmPQxNLOgBKaW
RcQT8qAzYfLsVReVBKeyUD1TJ5ueVCVzMACxtG/w5GnFtCvHOtdL7HUBbjzwSYpg
I/jcpWvxzvLPsNYkppl/C6/Z0wedbFJqHOa+JJx1F5eLf+fwEfB4ueylT1zP/lyv
29FsQJ4LVFztileaFTS4XFZfmsDhA681aK9ciqQZIdckKmjl3kkoGSi0RxK7u0Y6
zZklPiYqsZi8YorzB9vSuFwCJo4MaHah7EPguvzzqGuu2AvV/2NsR1aPWLvzRajl
XSI=
=OKMP
-END PGP SIGNATURE-

Bug#878031: [pkg-cryptsetup-devel] Bug#878031: cryptsetup: Freeze while typing decryption password

[Jonas Meurer]

Hi Doug,

please send a copy of your replies to the bugreport (use reply to all),
so others than me (e.g. co-maintainers of the package) can read them as
well.

Am 10.10.2017 um 23:19 schrieb Doug S:
> Should I try "cryptsetup open /dev/sda2 cryptolvm --debug" ? I really
> don't know the command. It's what the Debian installer sets by default.
> But how could I open the device at runtime? Debian needs the partition
> to be open in order to keep running, right? How would I close it and
> open again?

So you're talking about the disk unlocking that's happening early in the
boot process? Apparently you have your root disk encrypted so the
unlocking happens in initramfs.

In that case you're right, it's impossible to re-lock and re-unlock the
device while running the system.

In case that you're able to, please do the following:

* boot your system with the kernel commandline 'break=top'. An initramfs
  emergency shell should be spawned.
* Inside the initramfs emergency shell, run the cryptsetup command
  manually:

  # cryptsetup --debug luksOpen \
UUID=e12ee94c-924e-43c2-8578-276388731e95 sda3_crypt

* Save the output to some persistant storage and send it to us.

The fact that you encounter the same freeze with Fedora sounds
suspicious. Probably it's some hardware issues?

You could also remove the 'quiet' kernel commandline option and see
whether you see any useful boot logging messages.

Cheers,
 jonas

> 2017-10-08 19:57 GMT-03:00 Jonas Meurer  >:
> 
> Hi Doug,
> 
> Am 08.10.2017 um 23:42 schrieb Doug S.:
> >   As I begin typing the first characters of my decryption
> password, the prompt
> > seems to freeze and ignore some of those characters, which leads
> to typing the
> > wrong password every first attempt. It does not happen again for the
> > consecutive attempts.
> >
> >   I do not use Plymouth in Debian. This is also reproducible in Fedora
> > Workstation 26 (with Plymouth, which lets me see the freeze
> happening).
> 
> Can you please provide the exact commands that you use to unlock your
> dm-drypt volume? Also, please run them with '--debug' and attach the
> output.
> 
> Cheers
>  jonas
> 
> > -- Package-specific info:
> > -- /proc/cmdline
> > BOOT_IMAGE=/vmlinuz-4.9.0-4-amd64 root=/dev/mapper/alq14--vg-root
> ro quiet
> >
> > -- /etc/crypttab
> > sda3_crypt UUID=e12ee94c-924e-43c2-8578-276388731e95 none luks
> >
> > -- /etc/fstab
> > # /etc/fstab: static file system information.
> > #
> > # Use 'blkid' to print the universally unique identifier for a
> > # device; this may be used with UUID= as a more robust way to name
> devices
> > # that works even if disks are added and removed. See fstab(5).
> > #
> > #                
> > /dev/mapper/alq14--vg-root /               ext4   
> errors=remount-ro 0       1
> > # /boot was on /dev/sda2 during installation
> > UUID=d8773f5e-4431-4ee2-bdcf-309fd1dfd507 /boot           ext2   
> defaults        0       2
> > # /boot/efi was on /dev/sda1 during installation
> > UUID=F673-568B  /boot/efi       vfat    umask=0077      0       1
> > /dev/mapper/alq14--vg-home /home           ext4    defaults       
> 0       2
> > /dev/mapper/alq14--vg-swap_1 none            swap    sw           
>   0       0
> >
> > -- lsmod
> > Module                  Size  Used by
> > fuse                   98304  3
> > ctr                    16384  4
> > ccm                    20480  2
> > nls_ascii              16384  1
> > nls_cp437              20480  1
> > vfat                   20480  1
> > fat                    69632  1 vfat
> > snd_hda_codec_hdmi     49152  1
> > iTCO_wdt               16384  0
> > iTCO_vendor_support    16384  1 iTCO_wdt
> > dell_wmi               16384  0
> > arc4                   16384  2
> > sparse_keymap          16384  1 dell_wmi
> > rtsx_usb_ms            20480  0
> > intel_rapl             20480  0
> > x86_pkg_temp_thermal    16384  0
> > intel_powerclamp       16384  0
> > ath9k                  94208  0
> > dell_led               16384  1
> > ath9k_common           32768  1 ath9k
> > coretemp               16384  0
> > kvm_intel             192512  0
> > ath9k_hw              446464  2 ath9k,ath9k_common
> > dell_laptop            20480  0
> > dell_smbios            16384  3 dell_wmi,dell_led,dell_laptop
> > dcdbas                 16384  1 dell_smbios
> > i915                 1232896  21
> > ath                    32768  3 ath9k_hw,ath9k,ath9k_common
> > memstick               20480  1 rtsx_usb_ms
> > kvm                   589824  1 kvm_intel
> > mac80211              671744  1 ath9k
> > dell_smm_hwmon         16384  0
> > irqbypass              16384  1 kvm
> > intel_cstate      

Bug#878945: Request from cloud team: please add a debconf option for PasswordAuthentication

[Jimmy Kaplowitz]

Package: openssh-server
Version: 1:7.6p1-2
Severity: wishlist

Hello from the Debian cloud team sprint at Microsoft! We were just
discussing the appropriate default value for the PasswordAuthentication
option in sshd_config in Debian's cloud images. Most of these currently
set it to 'no' by modifying the config file; we'd like a debconf option
for this to be added, so that we make the change that way and offer a better
user experience across package upgrades.

Justification for the different default on most clouds:

While defaulting this to 'yes' makes sense in Debian's general case,
most of the major public clouds center their best practices around SSH
keys and support this with tooling and infratructure. Additionally,
public cloud VM instances are frequently targeted by attackers testing
passwords, who will of course not have any authorized SSH keys.

Although this meets the Debian BTS's definition of wishlist severity, we
on the cloud team view this as a reasonably important change by those
standards, so that we stay secure without manually modifying
sshd_config.

Thanks for your consideration.

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

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

Versions of packages openssh-server depends on:
ii  adduser  3.116
ii  debconf  1.5.63
ii  dpkg 1.18.24
ii  init-system-helpers  1.50
ii  libaudit11:2.8-1
ii  libc62.24-17
ii  libcomerr2   1.43.6-1
ii  libgssapi-krb5-2 1.15.1-2
ii  libkrb5-31.15.1-2
ii  libpam-modules   1.1.8-3.6
ii  libpam-runtime   1.1.8-3.6
ii  libpam0g 1.1.8-3.6
ii  libselinux1  2.7-2
ii  libssl1.0.2  1.0.2l-2
ii  libsystemd0  235-2
ii  libwrap0 7.6.q-26
ii  lsb-base 9.20170808
ii  openssh-client   1:7.6p1-2
ii  openssh-sftp-server  1:7.6p1-2
ii  procps   2:3.3.12-3
ii  ucf  3.0036
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages openssh-server recommends:
ii  libpam-systemd  235-2
ii  ncurses-term6.0+20170902-1
ii  xauth   1:1.0.9-1+b2

Versions of packages openssh-server suggests:
ii  ksshaskpass [ssh-askpass]  4:5.10.5-2
pn  molly-guard
pn  monkeysphere   
pn  rssh   
pn  ufw

-- debconf information excluded

Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

[Sebastian Andrzej Siewior]

On 2017-10-17 11:51:19 [+0100], Colin Watson wrote:
> > I didn't even figure out if they want to alter their code or not.
> 
>   
> https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036370.html

let me check.

> I don't see any benefit in conducting a discussion in which we assume
> bad faith.  There are different opinions on what makes for a good API
> transition, and pressures coming from different choices upstream
> (remembering that Debian's immediate upstream for OpenSSH is OpenSSH
> Portable, which itself has OpenBSD as an upstream) and from available
> development and review time, but simplifying that as "playing hard to
> get" isn't particularly helpful.

I'm sorry.

Sebastian

Bug#802211: RFC: wip patch to force sulogin on locked root accounts

[Felipe Sateler]

Control: forwarded -1 https://github.com/systemd/systemd/pull/7116

On Tue, Oct 17, 2017 at 5:36 PM, Stijn van Drongelen  wrote:
>
> Hi Felipe,
>
> On 15 October 2017 at 14:30, Felipe Sateler  wrote:
> >
> > Excellent. I would suggest though to fix this first for 235, and
> > upstream. That way whatever solution is implemented for stretch[1] can
> > be designed with compatibility with buster in mind.
> >
> >
> > [1] If the release team ACKs the change, too.
>
> Yes, that makes sense as a first step. I have submitted a pull request
> for upstream [1] and attached a patch against 235-2 (I hope I formatted
> it properly...).

Thanks, I'm marking the bug as forwarded. Formatting looks okay to me.

-- 

Saludos,
Felipe Sateler

Bug#878878: default-dbus-session-bus: Not installable on non-Linux

[James Clarke]

On 17 Oct 2017, at 22:39, Samuel Thibault  wrote:
> 
> Hello,
> 
> It seems I missed the whole thread, so found the same issue
> independently :)
> 
> Simon McVittie, on mar. 17 oct. 2017 16:21:06 +0100, wrote:
>> Thanks. Hmm, so the error is:
>> 
>>sbuild-build-depends-opencv-dummy : Depends: libgtk-3-dev but it is not 
>> going to be installed
>> 
>> which is amazingly helpful.
> 
> Adding  -o Debug::pkgProblemResolver=yes provides the useful
> information:
> 
> Investigating (0) dconf-service:hurd-i386 < none -> 0.26.1-1 @un uN Ib >
> Broken dconf-service:hurd-i386 Depends on default-dbus-session-bus:hurd-i386 
> < none @un H >
>  Considering dbus-user-session:hurd-i386 0 as a solution to 
> dconf-service:hurd-i386 7
>  Holding Back dconf-service:hurd-i386 rather than change 
> default-dbus-session-bus:hurd-i386
> ...

Indeed, that's how I debugged it too.

>> The dependency chain:
>> 
>>libgtk-3-dev Depends dconf-gsettings-backend | gsettings-backend
>>dconf-gsettings-backend Depends dconf-service
>>dconf-service Depends d-d-s-b | d-s-b
>> 
>> so we already have two layers of "if you accepted the alternative you'd
>> be fine". I thought sbuild's allergy to alternatives only extended as
>> far as direct dependencies?
> 
> That wouldn't be acceptable anyway, for the same reason as the direct
> dependencies.

Agreed. Note that in this case it's not sbuild ignoring the alternatives
as Simon mentioned, but apt itself; this is the default behaviour you get
from `apt-get install libgtk-3-dev`.

Regards,
James

Bug#878502: wrong/missing copyright for clang-tools-extra/clang-tidy/tool/run-clang-tidy.py (and others!)

[Nicholas D Steeves]

Hi Sylvestre,

On Sat, Oct 14, 2017 at 08:42:19AM +0200, Sylvestre Ledru wrote:
>Hello,
> 
>Le 14/10/2017 à 05:16, Nicholas D Steeves a écrit :
> 
>  I would submit a patch, but I'm sure what conventions the LLVM/Clang team 
> follow.
> 
>We don't really have a convention for this. So, feel free to submit a
>patch with what you think is the best!

Patches attached.  I broke them up into multiple commits in case you
wanted to reject by patch instead of by hunk.  Feel free to squash
them if you prefer fewer commits.

See commit messages for more info.  My method was:

Update from ./LICENSE.txt
Update from ./clang-tools-extra/CODE_OWNERS.TXT
For files that don't have date ranges in the header, get this info
from git history.

My assumption was that clang-tools-extra is joint copyright between
"University of Illinois at Urbana-Champaign" and those named in
CODE_OWNERS.TXT.  If I'm wrong about this I'd be happy to remove those
three lines from 0004-Add-copyright-for-clang-tools-extra.patch.
Alternatively, feel free to fixup the patch.

Sincerely,
Nicholas
From 8ea289a51284356f7652ad7ffb1001d4982eb3e3 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Tue, 17 Oct 2017 14:44:53 -0400
Subject: [PATCH 1/4] Update U-OF-I-BSD-LIKE years from ./LICENSE.TXT

---
 debian/copyright | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/copyright b/debian/copyright
index a50dd550..b6139179 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -370,7 +370,7 @@ License: U-OF-I-BSD-LIKE
  University of Illinois/NCSA
  Open Source License
  .
- Copyright (c) 2003-2013 University of Illinois at Urbana-Champaign.
+ Copyright (c) 2003-2017 University of Illinois at Urbana-Champaign.
  All rights reserved.
  .
  Developed by:
-- 
2.11.0



0001-Update-U-OF-I-BSD-LIKE-years-from-.-LICENSE.TXT.patch.sig
Description: PGP signature
From 6c1dbddb60a7edcfd819d6c1e5a4733b06baf5d8 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Tue, 17 Oct 2017 14:55:28 -0400
Subject: [PATCH 2/4] Add copyright for md5 contributions from ./LICENSE.txt

---
 debian/copyright | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/debian/copyright b/debian/copyright
index b6139179..70ccf153 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -132,6 +132,21 @@ Copyright: 1992, 1993, 1994 Henry Spencer
1992, 1993, 1994 The Regents of the University of California
 License: BSD-3-clause
 
+Files: lib/Support/MD5.cpp llvm/include/llvm/Support/MD5.h
+Copyright: 2001 Alexander Peslyak aka Solar Designer 
+License: solar-public-domain
+ This software was written by Alexander Peslyak in 2001.  No copyright is
+ claimed, and the software is hereby placed in the public domain.
+ In case this attempt to disclaim copyright and place the software in the
+ public domain is deemed null and void, then the software is
+ Copyright (c) 2001 Alexander Peslyak and it is hereby released to the
+ general public under the following terms:
+ .
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted.
+ .
+ * There's ABSOLUTELY NO WARRANTY, express or implied.
+
 Files: lib/Target/ARM/*
 Copyright: ARM Limited
 License: ARM
-- 
2.11.0



0002-Add-copyright-for-md5-contributions-from-.-LICENSE.t.patch.sig
Description: PGP signature
From 6b3defc1b83c4663bfa636b28cf1314a868125e6 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Tue, 17 Oct 2017 17:19:47 -0400
Subject: [PATCH 3/4] Update Copyright years for Files: * from ./LICENSE.TXT

---
 debian/copyright | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/copyright b/debian/copyright
index 70ccf153..f5b3185d 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -3,7 +3,7 @@ Upstream-Name: LLVM/Clang
 Source: http://llvm.org/releases/download.html
 
 Files: *
-Copyright: 2003-2007 University of Illinois at Urbana-Champaign.
+Copyright: 2003-2017 University of Illinois at Urbana-Champaign.
 License: U-OF-I-BSD-LIKE
 
 Files: */install-sh
-- 
2.11.0



0003-Update-Copyright-years-for-Files-from-.-LICENSE.TXT.patch.sig
Description: PGP signature
From b20d80da15d29337c13a59f66331c6cfb9472e6f Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Tue, 17 Oct 2017 17:21:12 -0400
Subject: [PATCH 4/4] Add copyright for clang-tools-extra

Copyright info taken from ./clang-tools-extra/CODE_OWNERS.TXT
Date range taken from git history of:
https://github.com/llvm-mirror/clang-tools-extra.git

Note: CODE_OWNERS.TXT states that clang-rename is copyright Manual
Klimek, but clang-rename seems to have been moved from
clang-tools-extra/clang-rename to clang/tools/clang-rename
---
 debian/copyright | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/debian/copyright b/debian/copyright
index f5b3185d..c52a66f3 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -100,6 +100,21 @@ Files: clang/lib/Headers/tgmath.h
 Copyright: 2009 Howard Hinnant
 License: Expat
 
+Files: clang-tool

Bug#878878: default-dbus-session-bus: Not installable on non-Linux

[Samuel Thibault]

Hello,

It seems I missed the whole thread, so found the same issue
independently :)

Simon McVittie, on mar. 17 oct. 2017 16:21:06 +0100, wrote:
> Thanks. Hmm, so the error is:
> 
> sbuild-build-depends-opencv-dummy : Depends: libgtk-3-dev but it is not 
> going to be installed
> 
> which is amazingly helpful.

Adding  -o Debug::pkgProblemResolver=yes provides the useful
information:

Investigating (0) dconf-service:hurd-i386 < none -> 0.26.1-1 @un uN Ib >
Broken dconf-service:hurd-i386 Depends on default-dbus-session-bus:hurd-i386 < 
none @un H >
  Considering dbus-user-session:hurd-i386 0 as a solution to 
dconf-service:hurd-i386 7
  Holding Back dconf-service:hurd-i386 rather than change 
default-dbus-session-bus:hurd-i386
...

> The dependency chain:
> 
> libgtk-3-dev Depends dconf-gsettings-backend | gsettings-backend
> dconf-gsettings-backend Depends dconf-service
> dconf-service Depends d-d-s-b | d-s-b
> 
> so we already have two layers of "if you accepted the alternative you'd
> be fine". I thought sbuild's allergy to alternatives only extended as
> far as direct dependencies?

That wouldn't be acceptable anyway, for the same reason as the direct
dependencies.

Samuel

Bug#878867: cups-filters: unreadable file /usr/lib/cups/backend/cups-brf

[Alexander Kurtz]

Hi!

On Tue, 2017-10-17 at 23:08 +0200, Samuel Thibault wrote:
> Yes, this is on purpose, just like in the cups-pdf package: it has to
> be run as root.

Yes, I suspected as much; this seems to be pretty much the same
situation as with bug #862732 [0]. I think that the same solution can
also be applied here: Make the file world-readable, but only executable
for root (although I seriously question cups' design choice to abuse
file permissions for configuration / policy storage here, but that's
another matter).

> Which error/failure/warning do you actually get due to this?

I think that /usr (and all other read-only parts of the OS) should
really be world-readable. There are a couple of good reasons for this
(unprivileged checksum verification, ability to copy parts of the host
OS in user chroots, direct auditing/debugging of current program
versions, unprivileged backups, etc.), but the real argument is "Why
not?": Shipping files in in a FLOSS OS, but restricting read-access is
security theater at best (that didn't stop Ubuntu though... [1]).

Best regards

Alexander Kurtz

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862732
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725

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

Bug#877053: sound-juicer: produces corrupt flac files

[Andreas Hehn]

> ripping a CD track and encoding to FLAC results in a corrupted FLAC
> file, which is not playable by some media players.
> 
> While totem, mplayer and vlc are able to play the resulting file,
> Quod Libet does not.
> 

Here's a correction to my original report:
None of the players could play the file correctly.

totem plays the file, but fails when you move the seek control beyond a
certain point.

mplayer and vlc skip the first couple of seconds (in my test case 1m48s)
of the produced flac file and mplayer reports:
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
libavcodec version 57.89.100 (external)
[flac @ 0x7f364efdedc0]invalid sync code
[flac @ 0x7f364efdedc0]invalid frame header
[flac @ 0x7f364efdedc0]decode_frame() failed

Best,
Andreas

Bug#878944: firefox: Pop-up prefs error on startup

[Phil Dibowitz]

Package: firefox
Version: 57.0~b6-1
Severity: normal

Dear Maintainer,

[yes I know I'm using experiemental, but I figured it was worth passing
this along anyway]

Just upgraded to 57.0~b6-1 and when I start FF I get a dialog with:

```
[Exception... "Could not convert JavaScript argument arg 0 
[nsISupports.QueryInterface]"  nsresult: "0x80570009 
(NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: 
resource://cck2/Preferences.jsm :: get _prefSvc :: line 544"  data: no]

get _prefSvc@resource://cck2/Preferences.jsm:544:19
_get@resource://cck2/Preferences.jsm:87:1
get@resource://cck2/Preferences.jsm:81:12
init@resource://cck2/CCK2.jsm:149:25
@cck2.cfg:134:1
```

Clicking OK lets FF start up and it seems to operate just fine, so it's
not a show-stopper for me, but I wanted to pass it along.

I imagine there's some preference either from history or from a plugin
the new version doesn't like, or maybe this beta build is missing
something.

Thanks for packaging FF!

-- Package-specific info:


-- Addons package information

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

Kernel: Linux 4.12.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)

Versions of packages firefox depends on:
ii  debianutils   4.8.2
ii  fontconfig2.12.3-0.2
ii  libatk1.0-0   2.26.0-2
ii  libc6 2.24-17
ii  libcairo-gobject2 1.14.10-1
ii  libcairo2 1.14.10-1
ii  libdbus-1-3   1.11.16+really1.10.24-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-6
ii  libfontconfig12.12.3-0.2
ii  libfreetype6  2.8-0.2
ii  libgcc1   1:7.2.0-8
ii  libgdk-pixbuf2.0-02.36.10-2
ii  libglib2.0-0  2.54.1-1
ii  libgtk-3-03.22.22-1
ii  libgtk2.0-0   2.24.31-2
ii  libhunspell-1.6-0 1.6.2-1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.16-1
ii  libnss3   2:3.33-1
ii  libpango-1.0-01.40.12-1
ii  libsqlite3-0  3.20.1-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++67.2.0-8
ii  libvpx4   1.6.1-3
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3
ii  zlib1g1:1.2.8.dfsg-5

firefox recommends no packages.

Versions of packages firefox suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-3
ii  libgssapi-krb5-2   1.15.1-2
pn  mozplugger 

-- no debconf information

Bug#877322: git-buildpackage autoremoval

[Ian Jackson]

Guido Günther writes ("Re: Bug#877322: git-buildpackage autoremoval"):
> On Tue, Oct 17, 2017 at 02:57:33PM +0100, Ian Jackson wrote:
> > This bug means that the autoremoval robot wants to remove
> > git-buildpackage.  I'm getting mails about it planning to remove dgit,
> > to clear the way.
> > 
> > Do you intend to upload the docs change to sid soon ?
> 
> Yes, before the autoremoval for sure. Sorry for being a pain here but I
> wanted to give gbp as much exposure as possible in experimental.

OK, fine.  Thanks for the reassurance.  If the deadline gets closer I
may ping you again :-).

Regards,
Ian.

Bug#869586: botch: Fails ADT tests with python3.6

[Adrian Bunk]

Control: retitle -1 botch FTBFS with Python 3.6 as default
Control: severity -1 serious
Control: tags -1 - moreinfo
Control: found -1 0.21-4

On Sat, Aug 05, 2017 at 08:06:00PM +1200, Michael Hudson-Doyle wrote:
> I guess we'll see what happens when Python 3.6 is made the default in
> Debian.
>...

FTBFS with the same error:
https://buildd.debian.org/status/package.php?p=botch&suite=sid

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#871964: swt-gtk: Build-depends on libwebkitgtk-dev which is deprecated

[Adrian Bunk]

On Sat, Aug 12, 2017 at 11:43:58PM -0400, Jeremy Bicha wrote:
>...
> The package does build successfully without the libwebkitgtk-dev
> build-dependency.

But the resulting library will still dynamically load it.

> It feels to me like the libswt-webkit-gtk-3-jni was already broken
> since it doesn't have a dependency on any webkitgtk library

The missing dependency sounds like a bug.

> (I think
> the correct one would be libwebkitgtk-3.0-0 but that is still part of
> the deprecated libraries which are being removed.)

It does use libwebkitgtk-1.0-0:
https://sources.debian.net/src/swt-gtk/3.8.2-4/webkitgtk.h/

I just tried, and it does work when libwebkitgtk-1.0-0 is installed  
(and fails without).

>...
> On behalf of the Debian WebKit Maintainers,
> Jeremy Bicha

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#878867: cups-filters: unreadable file /usr/lib/cups/backend/cups-brf

[Samuel Thibault]

Hello,

Alexander Kurtz, on mar. 17 oct. 2017 12:33:46 +0200, wrote:
> Your package ships a file in /usr which is unreadable for regular
> users, see the subject line for more details!

Yes, this is on purpose, just like in the cups-pdf package: it has to be
run as root.

Which error/failure/warning do you actually get due to this?

Samuel

Bug#878903: units: Unknown units: Fahrenheit, Celsius, Kelvin

[Stephen Kitt]

Control: forcemerge 200262 -1

Hi Alex,

Le 17/10/2017 17:50, Alex Wilk a écrit :

$ units Fahrenheit

Unknown unit 'Fahrenheit'
$ units Celsius
   :(
Unknown unit 'Celsius'
$ units Kelvin
   :(
Unknown unit 'Kelvin'


See “Temperature Conversions” in the units manpage.

Regards,

Stephen

Bug#878930: psychopy: Please update to 1.85.4

[Yaroslav Halchenko]

On Tue, 17 Oct 2017, Jeremy Bicha wrote:

> Source: psychopy
> Version: 1.85.3.dfsg-1

> According to http://www.psychopy.org/changelog.html

> the 1.85.3 release was incorrectly generated. You likely want 1.85.4 instead.

oh... thanks Jeremy... I will try to fix it up soonish
for 1.85.4 I had to fix up few things and didn't have time yet

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#858995: wget: FTBFS on hurd-i386

[Svante Signell]

Cc: debian-hurd

Another ping, almost two months later.


On Sun, 2017-08-27 at 10:30 +0200, Svante Signell wrote:
> found 858995 1.19.1-4
> thanks
> 
> ping again
> 
> The upstream patch has already been added to grep and findutils
> (#867120).
> 

Bug#876033: primusrun doesn't find libGL.so.1

[devfra]

On martedì 17 ottobre 2017 20:53:49 CEST Luca Boccassi wrote:
> What's the output of:
> 
> dpkg -l | grep 375.82-5

$ dpkg -l | grep 375.82-5
ii  libegl-nvidia0:amd64375.82-5   amd64   NVIDIA binary EGL library
ii  libegl-nvidia0:i386 375.82-5   i386NVIDIA binary EGL library
ii  libgl1-nvidia-glx:amd64 375.82-5   amd64   NVIDIA binary OpenGL/GLX...
ii  libglx-nvidia0:amd64375.82-5   amd64   NVIDIA binary GLX library
ii  libglx-nvidia0:i386 375.82-5   i386NVIDIA binary GLX library
ii  libnvidia-eglcore:amd64 375.82-5   amd64   NVIDIA binary EGL core l...
ii  libnvidia-eglcore:i386  375.82-5   i386NVIDIA binary EGL core l...
ii  libnvidia-glcore:amd64  375.82-5   amd64   NVIDIA binary OpenGL/GLX...
ii  libnvidia-glcore:i386   375.82-5   i386NVIDIA binary OpenGL/GLX...
ii  libnvidia-ml1:amd64 375.82-5   amd64   NVIDIA Management Librar...
ii  nvidia-alternative  375.82-5   amd64   allows the selection of ...
ii  nvidia-egl-common   375.82-5   amd64   NVIDIA binary EGL driver...
ii  nvidia-egl-icd:amd64375.82-5   amd64   NVIDIA EGL installable c...
ii  nvidia-egl-icd:i386 375.82-5   i386NVIDIA EGL installable c...
ii  nvidia-kernel-dkms  375.82-5   amd64   NVIDIA binary kernel mod...
ii  nvidia-kernel-support   375.82-5   amd64   NVIDIA binary kernel mod...
ii  nvidia-legacy-check 375.82-5   amd64   check for NVIDIA GPUs re...
ii  nvidia-vdpau-driver:amd64   375.82-5   amd64   Video Decode and Present...
ii  xserver-xorg-video-nvidia   375.82-5   amd64   NVIDIA binary Xorg driver

Thanks.

Bug#802211: RFC: wip patch to force sulogin on locked root accounts

[Stijn van Drongelen]

Hi Felipe,

On 15 October 2017 at 14:30, Felipe Sateler  wrote:
>
> Excellent. I would suggest though to fix this first for 235, and
> upstream. That way whatever solution is implemented for stretch[1] can
> be designed with compatibility with buster in mind.
>
>
> [1] If the release team ACKs the change, too.

Yes, that makes sense as a first step. I have submitted a pull request
for upstream [1] and attached a patch against 235-2 (I hope I formatted
it properly...). As mentioned in the comments of the PR, I've tested it
a bit in VirtualBox, but corrupting /etc/fstab stopped triggering
emergency mode at some point. I'm not sure if I tested it well.

As far as I can see, systemd moved on to use the meson build system
after stretch's version was released, so I'm not sure if sulogin-shell.c
can be backported easily. However, the patch itself is very simple,
so porting the patch shouldn't be much of an obstacle.

> It is my understanding that sulogin --force will still ask for
> password if getpwnam works.

You're right! I should've read the manpage for sulogin.

>> 3) [...]
>
> This has the drawback of requiring to modify ExecStart, and thus risk
> becoming incompatible if the sulogin wrapper changes interface.
>
>> 4) [...]
>
> I don't have an opinion here.

I've left the sulogin-shell interface as it was.

Regards,
Stijn van Drongelen

 [1] https://github.com/systemd/systemd/pull/7116
Author: Stijn van Drongelen 
Bug: https://github.com/systemd/systemd/issues/7115
Bug-Debian: https://bugs.debian.org/802211
Description: use sulogin --force for rescue and emergency mode
 Assuming that sulogin-shell is only used for rescue and emergency mode,
 it always needs to invoke `sulogin --force`. When the root account is
 locked, sulogin would otherwise refuse to login, causing systemd to
 boot the default target.
 .
 Additionally, this patch also changes the opening message of
 sulogin-shell to accurately describe this behaviour. It also suggests
 `journalctl -xb -p3` rather than `journalctl -xb`, as users of
 especially emergency mode are probably only interested in errors
 (or worse).

--- systemd-235.orig/src/sulogin-shell/sulogin-shell.c
+++ systemd-235/src/sulogin-shell/sulogin-shell.c
@@ -81,14 +81,15 @@ static void fork_wait(const char* const
 }
 
 static void print_mode(const char* mode) {
-printf("You are in %s mode. After logging in, type \"journalctl -xb\" to view\n"
-"system logs, \"systemctl reboot\" to reboot, \"systemctl default\" or ^D to boot\n"
-"into default mode.\n", mode);
+printf("You are in %s mode. If the root account is enabled, you must log in\n"
+   "as root after this message. In the shell, type \"journalctl -xb -p3\" to view\n"
+   "the error log for the current boot, \"systemctl reboot\" to reboot,\n"
+   "\"systemctl default\" or ^D to boot into default mode.\n", mode);
 fflush(stdout);
 }
 
 int main(int argc, char *argv[]) {
-static const char* const sulogin_cmdline[] = {SULOGIN, NULL};
+static const char* const sulogin_cmdline[] = {SULOGIN, "--force", NULL};
 int r;
 
 log_set_target(LOG_TARGET_AUTO);

Bug#878943: mutter: 2.26 regression: one-dimensional window maximize no longer possible

[Zack Weinberg]

Package: mutter
Version: 3.26.1-5
Severity: normal

With the GNOME 2.26 mutter, one-dimensional window maximize no longer
works correctly.  Specifically, if you set one of the "titlebar actions"
in gnome-tweak-tool's "windows" tab to either "toggle maximize vertically"
or "toggle maximize horizontally", then triggering the action will
cause the window to be fully maximized instead of maximized in only the
desired direction.

I waited to file this bug until both the 2.26 gnome-shell and the
2.26 gnome-tweak-tool appeared in unstable, but the behavior has been
consistently wrong since 2.26 mutter appeared in unstable, so I'm
pretty sure it's mutter's fault.

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

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

Versions of packages mutter depends on:
ii  gnome-settings-daemon  3.26.1-2
ii  gsettings-desktop-schemas  3.24.1-1
ii  libc6  2.24-17
ii  libglib2.0-0   2.54.1-1
ii  libmutter-1-0  3.26.1-5
ii  libx11-6   2:1.6.4-3
ii  libxcomposite1 1:0.4.4-2
ii  mutter-common  3.26.1-5
ii  zenity 3.24.0-1

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:3.26.1-2
pn  xdg-user-dirs 

-- no debconf information

Bug#878942: linkchecker: New upstream maintainers - source reference has changed

[Olivier Aubert]

Package: linkchecker
Version: 9.3-4
Severity: normal

Dear QA group,

This (orphaned) package also seems to have been orphaned by its original 
upstream author,
and development is now done by a new developer group [1] [2].

The new source can be found at https://github.com/linkcheck/linkchecker

[1] https://github.com/wummel/linkchecker/issues/686
[2] https://github.com/linkcheck/linkchecker/issues/1

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

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

Versions of packages linkchecker depends on:
ii  libc62.24-17
ii  python   2.7.13-2
ii  python-requests  2.18.1-1
ii  python-urllib3   1.21.1-1

linkchecker recommends no packages.

Versions of packages linkchecker suggests:
pn  clamav-daemon   
pn  linkchecker-gui 
pn  linkchecker-web 
pn  python-argcomplete  
ii  python-cssutils 1.0.2-1
ii  python-gconf2.28.1+dfsg-1.2
pn  python-geoip
pn  python-meliae   
pn  python-twill

-- no debconf information

Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

[Guus Sliepen]

On Mon, Oct 16, 2017 at 10:21:10PM -0400, Michael Stone wrote:

> On Tue, Oct 17, 2017 at 12:05:30AM +0200, Guus Sliepen wrote:
> > despite fears of OpenBSD only caring about themselves, I have found that
> > it is easier to compile LibreSSL for various platforms (even non-POSIX
> > ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
> > is ridiculous, as it is OpenSSL iself that has changed its API in a
> > non-backwards compatible way that is now causing this discussion.
> 
> It is not ridiculous to point out that LibreSSL is released every six months
> and supported for one year after release, while OpenSSL is supported for at
> least 2 years, and 5 years for LTS releases.

That is certainly not ridiculous. But, I had a look at the release plan
for OpenSSL at https://www.openssl.org/policies/releasestrat.html, and
it seems there only is one LTS release, namely 1.0.2, which will be
supported until the very end of 2019. 1.1.0 is only supported until
September 2018. In that context it is strange that we switched to 1.1.0
in stretch already. Let's hope there is an LTS for 1.1.x in time for
buster.

> It's not unrealistic to think
> that a Debian stable could release with a LibreSSL that's already
> unsupported upstream. It is also not ridiculous to point out that a number
> of distributions have an interest in long term maintenance of released
> versions of OpenSSL, while there is no such community around LibreSSL.

Maybe not currently for Debian or Fedora derivatives, but some
distributions (Alpine, OpenELEC amongst others) have switched to
LibreSSL as the default, and some (Gentoo, unsurprisingly) have it as an
option.

I see two main forces determining which fork of a library will be used:
either distributions themselves will choose based on technical and other
merits, or important applications will favor one of the forks, forcing
the decision for distributions. OpenSSH is now applying some force, I
have no idea what programs are out there that can only work with
OpenSSL. I assume those that moved to OpenSSL 1.1 and ditched OpenSSL
1.0 compatibility, but I wonder how many there are.

It would be interesting to recompile all packages that Build-Depend:
libssl-dev with LibreSSL, and see what actually breaks...

> As I continue to think about it, it may actually end up being better to
> embed a constrained subset of LibreSSL in OpenSSH than worry about either
> maintaining the entire LibreSSL package over a period of years, or fork.

I don't see why it couldn't be in its own package even if OpenSSH was
the only user. It doesn't change the maintenance burden.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#873118: Pending fixes for bugs in the commons-io package

[pkg-java-maintainers]

tag 873118 + pending
thanks

Some bugs in the commons-io package are closed in revision
190076e2660c9c7b1e68993f2ead7925909ef48f in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/commons-io.git/commit/?id=190076e

Commit message:

Ignore test failures.

Could be a problem with file permissions in the build environment. It 
doesn't
look that serious to me.

Closes: #873118

Bug#878901: dh-make-perl: FTBFS with dpkg >= 1.19: "Insecure dependency in eval while running with -T switch"

[Guillem Jover]

Hi!

On Tue, 2017-10-17 at 19:48:07 +0300, Niko Tyni wrote:
> On Tue, Oct 17, 2017 at 05:44:26PM +0200, gregor herrmann wrote:
> > Package: dh-make-perl
> > Version: 0.95
> > Severity: serious
> > Tags: buster sid
> > Justification: fails to build from source
> 
> > As first seen on ci.debian.net, dh-make-perl's test suite fails with
> > libdpkg-perl 1.19.0 and 1.19.0.1:
> > 
> > Insecure dependency in eval while running with -T switch at 
> > /usr/share/perl5/Dpkg/Vendor.pm line 164.
> 
> > The -T seems to come from t/debian-version.t itself; no idea yet why
> > it is a problem now and why it's used here in the first place.

> It looks like Dpkg::Vendor::get_vendor_info() contents have become
> tainted, probably due to changes in Dpkg::Control::HashCore. It used to
> dig the values out with regexp captures but now uses split.
> 
>  
> https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?h=sid&id=9e5e03e9a6ddf74bb22ffc5ea8794a14a592d6b6
> 
> A test case is
> 
>   perl -T -MDpkg::Vendor=get_vendor_info -MScalar::Util=tainted -e 'die if 
> tainted get_vendor_info()->{Vendor}'
> 
> which dies on libdpkg-perl 1.19.0.1 but not 1.18.24.
> 
> I don't know if the earlier untainting was accidental or intended.
> Copying the dpkg maintainers.

TBH, I was not aware that anyone was running Dpkg modules in taint
mode. And I don't think anyone has writen code for the modules with
that in mind. I'm not sure either how much of it is taint clean, for
example.

If people are really running this code in taint mode, I'm willing to
discuss which parts of the API would make sense to cover or not, and
what tradeoffs related to performance to take, etc.

Thanks,
Guillem

Bug#878941: RFS: sane-backends/1.0.27-1~experimental3

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "sane-backends"

   Package name: sane-backends
   Version : 1.0.27-1~experimental3
   Upstream Author : Sane Devel ML 
   URL : http://www.sane-project.org/
   License : GPL-2+ with sane exception, GPL-2+, GFDL-1.1, 
 Artistic, LGPL-2.1+, 
   Section : graphics

  It builds those binary packages:

  libsane-common - API library for scanners -- documentation and support files
  libsane-dev - API development library for scanners [development files]
  libsane1   - API library for scanners
  sane-utils - API library for scanners -- utilities

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

  https://mentors.debian.net/package/sane-backends


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

dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.27-1~experimental3.dsc
git: 
https://anonscm.debian.org/cgit/collab-maint/sane-backends.git?h=release%2Fexperimental%2F1.0.27-1_experimental3



  Changes since the last upload:

  * debian/control:
- Drop outdated Recommends libsane-extras-dev to libsane-dev
  binary package (Closes: #868265).
- Drop outdated texlive and texlive-latex-extra Build-Dependency.
  * debian/rules:
- Drop create and install the /etc/sane.d/dll.d directory.
- Move rules from override_dh_install-arch and override_dh_auto_install-arch
  to override_dh_install-indep and override_dh_auto_install-indep
  to build the arch all packages without error (CLoses: #870455).
- At dh_systemd_enable use debian/saned.socket instead saned.socket.
  * Move libsane-common.install.in to libsane-common.install.
  * debian/copyright:
- Add year 2017 for debian/*.
  * New debian/patches/0150-genesys-Fix-use-of-uninitialized-variable.patch:
- Initializing usb_mode (Closes:# 869673).
  Thanks to Florian Lindemann  and
  Olaf Meeuwissen .
  * Move install of man pages from debian/rules to libsane-common.manpages and
sane-utils.manpages (Closes: #872366).
  * Move umax_pp.5 from libsane-common to sane-utils.
  * debian/sane-utils.saned.init:
- Add parameter to --retry at the stop section (Closes: #871543).
  * libsane1.README.Debian:
- Remove references to the libsane-extras package.
  * Correct typos in the previous changelog entry.
  * Declare compliance with Debian Policy 4.1.1 (No changes needed).
  * Move rm_conffile from libsane-common.preinst to libsane-
common.maintscript.


  Regards,
   Jörg Frings-Fürst


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB
Wire:  @joergfringsfuerst
Skype: joergpenguin
Ring:  jff

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#878515: lintian: Use of uninitialized value in string eq at …/checks/fields.pm line 512. / Use of uninitialized value in string ne at …/checks/fields.pm lines 521 and 537.

[Niels Thykier]

Chris Lamb:
> Hi Axel,
> 
>> lintian: Use of uninitialized value  in string eq at […]
> 
> Thanks for this. :)
> 
>> I propose a new tag "section-is-empty"
> 
> We could re-use "no-section-field" and simply modify the description
> to also say "or empty".
> 
> I just tried to fix this, but when creating testcases with a blank
> source and binary Sections, I get (for source)
> 
> Use of uninitialized value $file in hash element at 
> /home/lamby/git/debian/lintian/lintian/lib/Lintian/Collect/Changes.pm line 
> 142.
> 
> ... and the following when I add a binary with an empty Section:
> 
> tests::fields-section-general:  dpkg-genchanges  
> >../fields-section-general_1.0_amd64.changes
> tests::fields-section-general: dpkg-genchanges: error: package 
> fields-section-general has section contrib/devel in control file but - in 
> files list
> tests::fields-section-general: dpkg-buildpackage: error: dpkg-genchanges 
> subprocess returned exit status 25
> 
> 
> How are you creating this frankenpackage? :)
> 
> 
> Regards,
> 



You may want to use the t/debs test suite and the t/changes for this
kind of package (basically just a deb with nothing else and a .changes
with nothing else).  The latter as we apparently have a bug in
L::C::Changes as well. :)

Thanks,
~Niels

Bug#876766: libegl1-glvnd-nvidia: Cannot upgrade libegl1-glvnd-nvidia -> conflicts with libegl1

[Nikita Maximov]

The Provides
will be back once mesa 17.x and libglvnd are ready to migrate to testing.


I want to remind that mesa 17 is in testing, but Provides are still missing in 
libglvnd packages for all non-stable branches (both 378.2-5 and 384.90-1).

Bug#878940: xpat2: Windows should be large enough to fit contents

[Andrej Mernik]

Package: xpat2
Version: 1.07-20
Severity: wishlist

Dear Maintainer,

currently, the game starts in a window which is wide/tall enough for some
games, but too narrow for the others (Spider, Seahaven, Monte Carlo, Midnight
Oil, etc.). This can cause confusion.

Ideally, the game should start in a window with dimensions big enough to fit
all games.

The same problem also applies to the help popup window which is tiny by default
(see screenshot). This window should also be at least as big as the main
window.

Best Regards,
Andrej Mernik



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

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

Versions of packages xpat2 depends on:
ii  libc6 2.24-11+deb9u1
ii  libx11-6  2:1.6.4-3
ii  libxaw7   2:1.0.13-1+b2
ii  libxmu6   2:1.1.2-2
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.1.5-1

xpat2 recommends no packages.

xpat2 suggests no packages.

-- no debconf information

Bug#878899: dpkg-buildpackage no longer calls build, only binary

[Guillem Jover]

Hi!

On Tue, 2017-10-17 at 16:31:05 +0100, James Clarke wrote:
> On Tue, Oct 17, 2017 at 06:03:20PM +0300, Adrian Bunk wrote:
> > Package: dpkg-dev
> > Version: 1.19.0.1
> > Severity: serious
> >
> > 14:39 < _rene_> hmm. dpkg-dev 1.19.0.1 broken for anyone else? looks like 
> > it doesn't call build(-arch,indep) anymore at
> > dpkg-buildpackage -b, but just binary?
> >
> > I seen the same debugging a FTBFS.
> 
> I believe this is caused by [0]:
> 
> [16:26:57]my understanding is that rules_requires_root is going 
> to be returning 0 for the build-* targets
> [16:27:06]jrtc27: clearly the default tries to be binary-targets 
> which would preserve the original behaviour
> [16:27:19]since $rules_requires_root{'binary-targets'} will be 
> set, but $target_legacy_root{'build'} will be false
> [16:27:33]aha
> [16:28:17]so I think the two instances of 
> rules_requires_root($buildtarget) should be rules_requires_root($binarytarget)
> [16:28:33]jrtc27: thank you. so it should say "return if not 
> any_target_requires_root;" in build_target_fallback
> [16:28:43]or that
> [16:28:53]rules_requires_root('build') is correct to return 0
> [16:28:58]build doesn't need root :P
> [16:29:08]no package building today I guess

Right, thanks for the analisys! I've fixed this locally now, and will
be included in 1.19.0.2.

Although, I've to say, the Severity looks a bit unfair (while practically
correct), because any package that gets broken due to build rules not
being called is violating several Debian policy MUSTS anyway.

I'll open a discussion on d-d later today.

Thanks,
Guillem

Bug#878919: libdpkg-perl needs Breaks: pkg-kde-tools (<< 0.15.28~)

[Guillem Jover]

Control: severity -1 important

Hi!

On Tue, 2017-10-17 at 20:23:46 +0300, Adrian Bunk wrote:
> Package: libdpkg-perl
> Version: 1.19.0.1
> Severity: serious
> 
> Due to #878892

That package is using a private module with no API guarantees, as stated
in README.api and marked as such via its version.

I'll add the Breaks, but meh. :)

Thanks,
Guillem

Bug#878910: [patch] change suggests btrfs-tools to btrfs-progs

[Nicholas D Steeves]

On Tue, Oct 17, 2017 at 08:23:21PM +0200, Axel Beckert wrote:
> Control: tag -1 + confirmed
> 
> Hi Nicholas,
> 
> Nicholas D Steeves wrote:
> > Trivial fix for renamed package.
> 
> Thanks for the bug report and patch!

You're welcome.  Sorry I didn't submit one sooner!

> > It sounds like btrfs-tools (transitional dummy package) will be
> > present in buster, so this can be put off until buster+1.
> 
> Putting off until buster+1 doesn't make sense, even if the
> transitional package might be present.
> 
> But since I prefer to keep xen-tools installable on older releases,
> too, I'll probably use "btrfs-progs | btrfs-tools".

Of course, that's your prerogative :-)

btrfs-progs is also available in old-stable-backports, btw:
https://packages.debian.org/jessie-backports/btrfs-progs

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#876033: primusrun doesn't find libGL.so.1

[Luca Boccassi]

On Tue, 2017-10-17 at 17:08 +0200, devfra wrote:
> Hello
> 
> The new version of primus have arrived today in Testing, everything
> works but 
> there is still a problem with the 32 bit version of LibGL.so.1.
> 
> I have a couple of 32-bit only applications that I run with wine,
> they give me 
> the following message:
> 
> primus: fatal: failed to load any of the libraries: /usr/lib/x86_64-
> linux-gnu/
> nvidia/libGL.so.1:/usr/lib/i386-linux-
> gnu/nvidia/libGL.so.1:/usr/lib/nvidia/
> libGL.so.1
> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1: wrong ELF class:
> ELFCLASS64
> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1: cannot open shared object
> file: No 
> such file or directory
> /usr/lib/nvidia/libGL.so.1: cannot open shared object file: No such
> file or 
> directory
> 
> Other 64 bit applications work with bumblebee as expected.

What's the output of:

dpkg -l | grep 375.82-5

-- 
Kind regards,
Luca Boccassi

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

Bug#878939: xfce4: Applications Menu does not create/ignores local entries (e.g. Wine menu)

[Gianfranco Del Borrello]

Package: xfce4
Version: 4.12.3
Severity: normal

Dear Maintainer,

I've recently installed Debian 9 32 bit Xfce and after installing some games 
with Wine I noticed that their menu entries weren't present.
I tried adding them with Menulibre but this editor considered those entries 
present. I tried then to tell the Applications Menu to use a custom file 
(~/.config/menus/xfce-applications.menu) but no luck. Additionally, Whiskers 
Menu includes those entries as well.
These issues aren't present on Debian 8 64 bit Xfce, which I still use on my 
main PC.
I hope I've provided enough information to solve the issue.
Kind regards,
Gianfranco Del Borrello

-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages xfce4 depends on:
ii  gtk2-engines-xfce3.2.0-2
ii  libxfce4ui-utils 4.12.1-2
ii  orage4.12.1-3
ii  thunar   1.6.11-1
ii  xfce4-appfinder  4.12.0-2
ii  xfce4-panel  4.12.1-2
ii  xfce4-pulseaudio-plugin  0.2.4-1
ii  xfce4-session4.12.1-5
ii  xfce4-settings   4.12.1-1
ii  xfconf   4.12.1-1
ii  xfdesktop4   4.12.3-3
ii  xfwm44.12.4-1

Versions of packages xfce4 recommends:
ii  desktop-base  9.0.2+deb9u1
ii  tango-icon-theme  0.8.90-6
ii  thunar-volman 0.8.1-2
ii  xfce4-notifyd 0.3.4-1
ii  xorg  1:7.7+19

Versions of packages xfce4 suggests:
pn  gtk3-engines-xfce
ii  xfce4-goodies4.12.3
ii  xfce4-power-manager  1.4.4-4

-- no debconf information

Bug#869545: Debian 8, trim/discard requires support of hw_disk_bus=scsi in openstack raw

[Paul Isaac's]

Hi Thomas,
the final aim is to enable fstrim/discard on a bootable image. However which 
way that can be accomplished.

Regards

Paul.

> On 17 Oct 2017, at 21:21, Thomas Goirand  wrote:
> 
> Hi Paul,
> 
> Could you be explicit into what means:
> 
> "The request is therefore to have a raw image built that includes the
> support for hw_disk_bus=scsi when using virtio-scsi"
> 
> What shall we do to have the image compliant to the above?
> 
> Cheers,
> 
> Thomas Goirand (zigo)

Bug#878935: libbpfcc needs a way to ensure the current kernel's headers are installed

[Alexander Kurtz]

Hi!

(Applications linked against) libbpfcc will dynamically compile and
load C source code into eBPF byte code at runtime and load the result
into the kernel for various purposes (e.g. socket filtering, tracing,
etc.).

For this to work, it needs the kernel headers of the *currently running
kernel* [0,1]. Therefore, the maintainer of libbpfcc in Debian added a
corresponding dependency [2] which unfortunately breaks everything but
amd64 [3] and does also not quite fix the original bug [4].

Please comment on bug #877925 [4] and/or #878922 [3] regarding on how
to solve the "this package needs the current kernel's headers
installed" problem!

Best regards

Alexander Kurtz

[0] https://github.com/iovisor/bcc/issues/397
[1] https://github.com/iovisor/bcc/issues/743
[2] 
https://anonscm.debian.org/git/collab-maint/bpfcc.git/commit/?id=f73049e48fd98dd01d4475f88f6b490e6a1b34bb
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878935
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877925

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

Bug#878938: kmail: crashes when filling in contact info from "recent contacts" in coposer

[Shawn Sörbom]

Package: kmail
Version: 4:16.04.3-4~deb9u1
Severity: important

Dear Maintainer,

An abort() signal is thrown in kmail composer when filling in the "To:" field 
from the recent contacts drop-down menu, causing a crash.
This only seems to happen with certain contacts. I have not been able to 
isolate what makes these contacts unique. 
Please contct me if you need more details.
I have attatched a stacktrace.

Application: KMail (kmail), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fe1edb12940 (LWP 10115))]

Thread 9 (Thread 0x7fe1d97ff700 (LWP 10127)):
#0  0x7fff344bb949 in ?? ()
#1  0x7fff344bbbd9 in clock_gettime ()
#2  0x7fe20d317996 in clock_gettime () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x7fe20dcae091 in qt_clock_gettime (ts=0x7fe1d97fe9e0, clock=) at tools/qelapsedtimer_unix.cpp:109
#4  do_gettime (frac=, sec=) at 
tools/qelapsedtimer_unix.cpp:164
#5  qt_gettime () at tools/qelapsedtimer_unix.cpp:173
#6  0x7fe20de2ace9 in QTimerInfoList::updateCurrentTime 
(this=this@entry=0x7fe1c0002cd0) at kernel/qtimerinfo_unix.cpp:91
#7  0x7fe20de2b295 in QTimerInfoList::timerWait (this=0x7fe1c0002cd0, 
tm=...) at kernel/qtimerinfo_unix.cpp:388
#8  0x7fe20de2c63e in timerSourcePrepareHelper (timeout=0x7fe1d97feab4, 
src=) at kernel/qeventdispatcher_glib.cpp:132
#9  timerSourcePrepare (source=, timeout=0x7fe1d97feab4) at 
kernel/qeventdispatcher_glib.cpp:165
#10 0x7fe201fd3edd in g_main_context_prepare () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x7fe201fd491b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x7fe201fd4b0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7fe20de2d06b in QEventDispatcherGlib::processEvents 
(this=0x7fe1c8c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#14 0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1d97fec80, 
flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#15 0x7fe20dc040f3 in QThread::exec (this=) at 
thread/qthread.cpp:507
#16 0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf7955430) at 
thread/qthread_unix.cpp:368
#17 0x7fe203fa6494 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#18 0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 8 (Thread 0x7fe1daddf700 (LWP 10125)):
#0  0x7fe20d2fd71d in read () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fe202018d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fe201fd44be in g_main_context_check () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fe201fd4994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fe201fd4b0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7fe20de2d06b in QEventDispatcherGlib::processEvents 
(this=0x7fe1cc0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#6  0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1daddec80, 
flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#7  0x7fe20dc040f3 in QThread::exec (this=) at 
thread/qthread.cpp:507
#8  0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf785d990) at 
thread/qthread_unix.cpp:368
#9  0x7fe203fa6494 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#10 0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 7 (Thread 0x7fe1db7fe700 (LWP 10123)):
#0  0x7fe20d3016ad in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fe201fd49f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fe201fd4b0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fe20de2d06b in QEventDispatcherGlib::processEvents 
(this=0x7fe1c80008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#4  0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1db7fdc80, 
flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#5  0x7fe20dc040f3 in QThread::exec (this=) at 
thread/qthread.cpp:507
#6  0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf78876a0) at 
thread/qthread_unix.cpp:368
#7  0x7fe203fa6494 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#8  0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 6 (Thread 0x7fe1dbfff700 (LWP 10121)):
#0  0x7fe20d2fd71d in read () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fe202018d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fe201fd44be in g_main_context_check () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fe201fd4994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fe201fd4b0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7fe20de2d06b in QEventDispatcherGlib::processEvents 
(this=0x7fe1d8c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#6  0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1dbffec80, 

Bug#878932: generator-scripting-language: Incomplete debian/copyright?

[Luca Boccassi]

Control: tags -1 pending

On Tue, 2017-10-17 at 20:08 +0100, Chris Lamb wrote:
> Source: generator-scripting-language
> Version: 4.1.5-1
> Severity: serious
> Justication: Policy 12.5
> X-Debbugs-CC: Luca Boccassi 
> 
> Hi,
> 
> I just ACCEPTed generator-scripting-language from NEW but noticed it 
> was missing attribution in debian/copyright for at least Todd Miller
> within sflstr.c.
> 
> (This is not exhaustive so please check over the entire package 
> carefully and address these on your next upload.)
> 
> 
> Regards,

Hi Chris,

Thank you, and good catch!

I ran licensecheck but it only reported GPL-3 for that file. I had done
some manual greps but evidently failed to notice it.

$ licensecheck -r . | grep sflstr
./src/sflstr.c: GPL (v3 or later)
./src/sflstr.h: GPL (v3 or later)

I've now done some more grepping for common terms and I cannot see
other copyright/licenses.

I'll upload as soon as I get the confirmation email.

-- 
Kind regards,
Luca Boccassi

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

Bug#878937: visp: port baseline violation on i386+amd64 (also causes FTBFS on amd64)

[Adrian Bunk]

Source: visp
Version: 3.0.1-2
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=visp&arch=i386&ver=3.0.1-2&stamp=1487064152&raw=0

...
-- Performing Test HAVE_CXX_MSSE2
-- Performing Test HAVE_CXX_MSSE2 - Success
-- Performing Test HAVE_C_MSSE2
-- Performing Test HAVE_C_MSSE2 - Success
-- Performing Test HAVE_CXX_MSSE3
-- Performing Test HAVE_CXX_MSSE3 - Success
-- Performing Test HAVE_C_MSSE3
-- Performing Test HAVE_C_MSSE3 - Success
-- Performing Test HAVE_CXX_MSSSE3
-- Performing Test HAVE_CXX_MSSSE3 - Success
-- Performing Test HAVE_C_MSSSE3
-- Performing Test HAVE_C_MSSSE3 - Success
...
-- C++ flags (Release): -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Wextra -fopenmp 
-fvisibility=hidden -msse2 -msse3 -mssse3 -fPIC -g -O2 
-fdebug-prefix-map=/«PKGBUILDDIR»=. -specs=/usr/share/dpkg/no-pie-compile.specs 
-fstack-protector-strong -Wformat -Werror=format-security
-- C++ flags (Debug):   -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Wextra -fopenmp 
-fvisibility=hidden -msse2 -msse3 -mssse3 -fPIC -g
-- C Compiler:  /usr/bin/cc
-- C flags (Release):   -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Wextra -fopenmp 
-fvisibility=hidden -msse2 -msse3 -mssse3 -fPIC -g -O2 
-fdebug-prefix-map=/«PKGBUILDDIR»=. -specs=/usr/share/dpkg/no-pie-compile.specs 
-fstack-protector-strong -Wformat -Werror=format-security
-- C flags (Debug): -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Wextra -fopenmp 
-fvisibility=hidden -msse2 -msse3 -mssse3 -fPIC -g
...
The following tests FAILED:
  2 - testConversion (ILLEGAL)
  4 - testCropAdvanced (ILLEGAL)
 14 - testIoPPM (ILLEGAL)
 16 - testReadImage (ILLEGAL)
 37 - testHistogram (ILLEGAL)
 71 - testKeyPoint-5 (ILLEGAL)
 72 - testKeyPoint-6 (ILLEGAL)
 73 - testKeyPoint-7 (ILLEGAL)
100 - imageDiskRW (ILLEGAL)
Errors while running CTest
Makefile:107: recipe for target 'test' failed
make[2]: *** [test] Error 8


The baseline of the amd64 port includes nothing higher than SSE2.

The baseline of the i386 port includes no SSE (not even MMX).

Bug#869545: Debian 8, trim/discard requires support of hw_disk_bus=scsi in openstack raw

[Thomas Goirand]

Hi Paul,

Could you be explicit into what means:

"The request is therefore to have a raw image built that includes the
support for hw_disk_bus=scsi when using virtio-scsi"

What shall we do to have the image compliant to the above?

Cheers,

Thomas Goirand (zigo)

Bug#878848: skimage

[Stefan van der Walt]

Hi Ole

On Tue, Oct 17, 2017, at 11:46, Ole Streicher wrote:
> On 17.10.2017 20:22, Stefan van der Walt wrote:
> > As upstream maintainer, I admit to being a bit confused: we agreed to
> > move maintenance to the Debian Science Team, but then watched as skimage
> > was dropped from testing.  If the team does not take responsibility for
> > keeping the package up to date, who is ultimately responsible?
> 
> In my opinion: The "Uploader" still has most responsibility, but others
> also can step in and help with a low threshold if problems appear.
> Either by submitting to git, or with directly uploading an update.

Thanks for helping me understand this.  So, in the case of skimage being
removed from testing, who should have handled the issue, ideally?

Stéfan

Bug#878935: Unsatisfiable dependencies on !amd64

[Alexander Kurtz]

Package: libbpfcc
Version: 0.3.0-3
Severity: serious
Justification: Makes the package uninstallable on most architectures

Hi!

As [0] shows, libbpfcc has unsatisfiable dependencies on everything but
amd64. This is because [1] is inherently wrong, "linux-headers-amd64"
is of course only available on amd64, the other architectures have
their own meta-packages [2]. Unfortunately there is (AFAIK) no good way
to properly solve the "this package needs the current kernel headers
installed" problem in Debian because

   1. There are no (real or virtual) "linux-{image,headers}-
  generic" packages (like in Ubuntu [3,4]) which have the same name on
  all architectures.
   2. Even if there were such packages, there's no guarantee that "linux-
  headers-generic" would point to the headers matching the *currently
  running* kernel (which is what libbcc needs). In fact, with partial
  upgrades, migrations from unstable to testing, upgraded-but-not-yet-
  rebooted machines, etc., it is quite likely that libbpfcc will be
  broken even if all its dependencies are fulfilled.

I therefore ask you to

   1. Revert [1].
   2. Reopen [5] and put a note regarding the requirements of the kernel
  headers in README.Debian and/or the package description.
   3. Talk to the Debian Linux maintainers to find a proper solution to
  this problem. It's probably not going to be easy, but these kinds of
  problems really deserve to be fixed properly.

Yes, this sucks. I have run into #877925 myself and also thought that
this should be simply solvable with a dependency. Oh, well, at least
you may take comfort in the fact that others [6] have also run into
this problem... ;-)

Best regards

Alexander Kurtz

[0] https://tracker.debian.org/pkg/bpfcc
[1] 
https://anonscm.debian.org/git/collab-maint/bpfcc.git/commit/?id=f73049e48fd98dd01d4475f88f6b490e6a1b34bb
[2] https://packages.debian.org/source/sid/linux
[3] https://packages.ubuntu.com/artful/linux-image-generic
[4] https://packages.ubuntu.com/artful/linux-headers-generic
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877925
[6] https://anonscm.debian.org/git/pkg-dkms/dkms.git/tree/debian/control#n24

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