Bug#771545: Possible cause

[nemo Inis]

I just hit this (with reportbug 7.5.0).

I had started reportbug from a terminal inside my XFCE session, and after the 
GUI froze, I
found this on the terminal:

Use sudo to read the kernel log?

I replied "y", and sudo prompted me for my password. After giving it, reportbug 
worked normally.

So I think the issue is that reportbug's GUI is doing I/O on its controlling 
terminal, and sits
there waiting for a reply that never comes (because the user is looking at the 
GUI).

Bug#908924: dma_direct_map_sg: overflow on USB access after upgrade to kernel 4.18

[Nemo Inis]

Package: src:linux
Version: 4.18.6-1
Severity: important

Dear Maintainer,

Plugged my Kobo eReader's USB plug into a machine just upgraded from kernel
4.17 (4.17.17-1) to 4.18 (4.18.6-1), and got 112,738,316 kernel messages in the
the system log:

kernel: ehci-pci :00:1a.7: dma_direct_map_sg: overflow
0x000216f3c000+4096 of device mask 

Downgrading to 4.17 fixes this.

Relevant lspci output:

00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #2 (rev 02) (prog-if 20 [EHCI])
Subsystem: Gigabyte Technology Co., Ltd 82801I (ICH9 Family) USB2 EHCI
Controller
Flags: bus master, medium devsel, latency 0, IRQ 18
Memory at fb204000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci


I think this is https://bugzilla.kernel.org/show_bug.cgi?id=200709




-- Package-specific info:
** Version:
Linux version 4.18.0-1-686-pae (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.6-1 (2018-09-06)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.18.0-1-686-pae 
root=UUID=54edf79e-1432-4836-8ea6-c744253ba306 ro fbcon=scrollback:128k quiet 
ipv6.disable=1

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[7.535676] PM: Image not found (code -22)
[7.560085] cryptd: max_cpu_qlen set to 1000
[7.710342] EXT4-fs (sde1): mounted filesystem with ordered data mode. Opts: 
(null)
[7.871897] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid)
[7.888134] systemd[1]: Detected architecture x86.
[7.891501] systemd[1]: Set hostname to .
[8.068161] random: systemd: uninitialized urandom read (16 bytes read)
[8.068233] systemd[1]: Listening on Journal Audit Socket.
[8.068273] random: systemd: uninitialized urandom read (16 bytes read)
[8.068351] systemd[1]: Listening on Journal Socket (/dev/log).
[8.068370] random: systemd: uninitialized urandom read (16 bytes read)
[8.068456] systemd[1]: Listening on Journal Socket.
[8.070712] systemd[1]: Starting Load Kernel Modules...
[8.071637] systemd[1]: Mounting POSIX Message Queue File System...
[8.073195] systemd[1]: Starting Journal Service...
[8.073487] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[8.081443] loop: module loaded
[8.087374] it87: Found IT8718F chip at 0x290, revision 4
[8.087394] it87: Beeping is supported
[8.092733] sd 2:0:0:0: Attached scsi generic sg0 type 0
[8.092784] sd 3:0:0:0: Attached scsi generic sg1 type 0
[8.092831] sd 4:0:0:0: Attached scsi generic sg2 type 0
[8.092870] sd 5:0:0:0: Attached scsi generic sg3 type 0
[8.092910] sd 7:0:0:0: Attached scsi generic sg4 type 0
[8.092951] sr 9:0:0:0: Attached scsi generic sg5 type 5
[8.093300] EXT4-fs (sde1): re-mounted. Opts: errors=remount-ro,commit=300
[8.112927] RPC: Registered named UNIX socket transport module.
[8.112928] RPC: Registered udp transport module.
[8.112929] RPC: Registered tcp transport module.
[8.112930] RPC: Registered tcp NFSv4.1 backchannel transport module.
[8.156231] nvidia: loading out-of-tree module taints kernel.
[8.156241] nvidia: module license 'NVIDIA' taints kernel.
[8.156242] Disabling lock debugging due to kernel taint
[8.170688] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[8.171674] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[8.171684] NVRM: loading NVIDIA UNIX x86 Kernel Module  340.107  Thu May 24 
21:04:34 PDT 2018
[8.240244] systemd-journald[296]: Received request to flush runtime journal 
from PID 1
[8.615060] snd_hda_intel :01:00.1: Disabling MSI
[8.615069] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[8.650522] snd_hda_codec_realtek hdaudioC0D2: autoconfig for ALC889A: 
line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
[8.650525] snd_hda_codec_realtek hdaudioC0D2:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[8.650527] snd_hda_codec_realtek hdaudioC0D2:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[8.650528] snd_hda_codec_realtek hdaudioC0D2:mono: mono_out=0x0
[8.650529] snd_hda_codec_realtek hdaudioC0D2:dig-out=0x1e/0x0
[8.650531] snd_hda_codec_realtek hdaudioC0D2:inputs:
[8.650533] snd_hda_codec_realtek hdaudioC0D2:  Rear Mic=0x18
[8.650535] snd_hda_codec_realtek hdaudioC0D2:  Front Mic=0x19
[8.650536] snd_hda_codec_realtek hdaudioC0D2:  Line=0x1a
[8.650538] snd_hda_codec_realtek hdaudioC0D2:  CD=0x1c
[8.650539] snd_hda_codec_realtek hdaudioC0D2:dig-in=0x1f
[

Bug#882538: jpeg-6b configure.in (etc.) reconstruction

[Eriberto]

Hi Adam,

Em qui, 8 de mar de 2018 às 14:42, Adam Sampson  escreveu:
>
> This sounded like an interesting software archeology problem...
>
> Tom Lane of IJG posted a slightly later version of jpeg's configure.in
> and associated files to the UnixOS2 mailing list in 2004:
> http://unix.os2site.com/pub/list/unixos2/2004/03/2004Mar31000402.txt
> > Let's see ... configure is built like this:
> >
> > configure: configure.in sed.cfg aclocal.m4
> > autoconf configure.in | sed -f sed.cfg >configure
> > chmod +x configure
>
> I've lightly modified the files he posted so that they exactly reproduce
> the configure script in jpeg-6b, which is what's bundled in outguess and
> various other packages, when built with autoconf 2.12. The modified
> files are attached; you also need libtool.m4 from libtool 1.2.

Thanks a lot for your help. I put the files inside jpeg-6b-steg
directory. When running 'autoconf configure.in | sed -f sed.cfg
>configure', I got:

# autoconf configure.in | sed -f sed.cfg >configure
aclocal.m4:10: error: undefine: undefined macro: AC_INIT_PARSE_ARGS
aclocal.m4:10: the top level
autom4te: /usr/bin/m4 failed with exit status: 1

Can you help? A patch is a good idea.

Regards,

Eriberto

Bug#908923: Please provide stretch-backport for debmake-doc (currently 1.11-1)

[Nicholas D Steeves]

Package: debmake-doc
Version: 1.7-2
Severity: minor

Hi,

I primarily use Debian stable and develop in schroots, LXCs, or VMs.
Would you please consider providing a stretch-backport of debmake-doc?
Given that the Debian New Maintainer's Guide is depreciated, I believe
this is going to become more important.

Alternatively, I'd be happy to backport it and keep an eye on my
Developer Dashboard...  If necessary I could also do bpos for
debian-policy and developers-reference.

Thanks!
Nicholas


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

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

debmake-doc depends on no packages.

Versions of packages debmake-doc recommends:
ii  debmake  4.2.9-1

Versions of packages debmake-doc suggests:
ii  debian-policy 3.9.8.0
ii  developers-reference  3.4.18

-- no debconf information

Bug#908922: xpp: deprecated cupsTempFile is used: printing stdin fails

[Tobias Hoffmann]

Package: xpp
Version: 1.5-cvs20081009-4
Severity: important


When using xpp to print from stdin, e.g. via xpdf or simply using:
$ cat my.pdf | xpp

xpp fails with "Unable to create temporary file." when pressing the
Print button.

>From line 698 in
https://sources.debian.org/src/xpp/1.5-cvs20081009-4/xpp.cxx/
it seems that cupsTempFile is used, which is deprecated and
now always returns NULL. According to cups api doc, cupsTempFile2 or
similar should be used.



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

Kernel: Linux 4.18.0 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xpp depends on:
ii  libc6   2.27-2
ii  libcups22.2.6-4
ii  libfltk1.1  1.1.10-25
ii  libgcc1 1:8-20180312-2
ii  libstdc++6  6.1.1-9

xpp recommends no packages.

xpp suggests no packages.

-- no debconf information

Bug#893377: Re: Bug#893377: RFS: taptempo/1.2.1-1 [ITP]

[Mo Zhou]

control: close -1

On Sat, Sep 15, 2018 at 03:53:02PM +0200, François Mazen wrote:
> Hi Lumin,
> 
> the file msys/mingw-bundledlls.py was committed by mistake. It is only
> needed to generate the Windows package.
> I've removed it in the upstream code and I generated a new release
> (1.4.3). I've also updated the copyright file for the new 1.4.3-1
> package.
> 
> The new package is tagged debian/1.4.3-1 in the packaging repository:
> 
> https://git.tuxfamily.org/taptempo/taptempo_deb_packaging.git/tag/?h=debian/1.4.3-1
> 
> and it's uploaded to mentors (just to check that everything is still
> fine).

Thanks. And uploaded.

Bug#685706: libc-bin: order of /etc/ld.so.conf.d/*.conf

[Alexander Huynh]

Hello all,

I have a branch on Salsa [0] that would provide ordering for the two files I
currently see placed in /etc/ld.so.conf.d/:

  * libc.conf
  * $(uname -m)-linux-gnu.conf

I've also done a sweep of the rest of the repo, adding ordering to other files
that could appear in /etc/ld.so.conf.d/.

Who is the best person to review, and merge? I tried created a merge request
to glibc-team/glibc, but did not have proper permissions.

Unfortunately, I'm not familiar enough with Lintian to add the associated
changes to ensure that files in /etc/ld.so.conf.d/ are numbered.

Thanks for taking a look,
Alex

[0]: 
https://salsa.debian.org/ahrex-guest/glibc/commits/bug-685706-add-ld.so.conf.d-ordering
 

Bug#840829: docker.io: Won't start under cgroupsv2

[Dmitry Smirnov]

Control: found -1 18.06.1+dfsg1-1

On Wednesday, 12 September 2018 7:46:15 PM AEST Hector Oron wrote:
> On Sat, Oct 15, 2016 at 12:37:37PM +0100, Sam Morris wrote:
> > When booting with the systemd.unified_cgroup_hierarchy kernel parameter,
> > systemd mounts the cgroup2 filesystem at /sys/fs/cgroup. As a result,
> > docker no longer starts:

This is still a problem with systemd 237 / Linux 4.17.8 booted with 
systemd.unified_cgroup_hierarchy=1 -- Docker daemon fails to start:


Unable to find cpu cgroup in mounts
Unable to find blkio cgroup in mounts
Unable to find cpuset cgroup in mounts
Error starting daemon: Devices cgroup isn't mounted


I have no other suggestions but to use "rkt" which seems to work flawlwssly 
with cgroup2...

-- 
Cheers,
 Dmitry Smirnov.

---

Truth never damages a cause that is just.
-- Mahatma Gandhi


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

Bug#893377: Re: Bug#893377: RFS: taptempo/1.2.1-1 [ITP]

[Paul Wise]

On Sat, Sep 15, 2018 at 9:53 PM, François Mazen wrote:

> the file msys/mingw-bundledlls.py was committed by mistake. It is only
> needed to generate the Windows package.
> I've removed it in the upstream code and I generated a new release
> (1.4.3). I've also updated the copyright file for the new 1.4.3-1
> package.

Please re-add it in the next version, people using Windows deserve to
be able to automatically rebuild Windows packages from modified
versions of the code.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#908920: rm: libundead [armhf binaries] RoP FTBFS, miscompilation, rdeps never built.

[peter green]

Package: ftp.debian.org

libundead failed to build on armhf after the ldc transition ( 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908670 ) . This build failure 
was triggered by a fix for a miscompilation bug and based on what upstream has 
said I believe that the existing libundead binary was almost-certainly 
mis-compiled.

As far as I can tell libundead only has two reverse dependencies in Debian, 
libbiod and sambamba. Neither of these has ever successfully built on armhf. 
The former has been tried but previously failed with a testsuite failure 
(possibly due to the aforementioned mis compilation) and now fails with the 
same error as libundead. The latter has never been tried because it depends on 
the former.

The best long term fix for the underlying issue would be in llvm but they have 
not yet responded to the bug report (and given the nature of the issue I could 
see them considering it as a feature request rather than a bug per-se). So for 
the time being I believe (and Andreas Tille, the effective maintainer agreed) 
the sensible thing to do is to remove the armhf binaries for libundead.

Bug#908176: [scr564750] jhead 1:3.00-7 ProcessGpsInfo CVE

[cve-request]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> [Suggested description]
> The ProcessGpsInfo function of the gpsinfo.c file of jhead 3.00 may
> allow a remote attacker to cause a denial-of-service attack or
> unspecified other impact via a malicious JPEG file, because of
> inconsistency between float and double in a sprintf format string
> during TAG_GPS_ALT handling.
> 
> --
> 
> [Additional Information]
> http://www.sentex.net/~mwandel/jhead/changes.txt might be updated later.
> 
> --
> 
> [Vulnerability Type]
> Buffer Overflow
> 
> --
> 
> [Vendor of Product]
> jhead
> 
> --
> 
> [Affected Product Code Base]
> jhead - 1:3.00-7
> 
> --
> 
> [Affected Component]
> gpsinfo.c, ProcessGpsInfo, line 104
> 
> --
> 
> [Attack Type]
> Remote
> 
> --
> 
> [Impact Denial of Service]
> true
> 
> --
> 
> [Attack Vectors]
> Open a crafted jpg file
> 
> --
> 
> [Discoverer]
> Hanfang Zhang
> 
> --
> 
> [Reference]
> https://nimo-zhang.github.io/2018/09/07/bug-analysis-1/#more
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908176

Use CVE-2018-16554.


- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
  http://cve.mitre.org/cve/request_id.html ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJbnZ7HAAoJEA2h+fVryJLoR5cQAJx8lYsdLunTsMqt+WgaYPWH
hvgUwtX3azK9GhFIfJjloLmnEe5L0F871V06Ju6/yoJbae14f/OnNavOmJ9Fthz6
1mATVqrHacg5TcrHmDGkslyaUFi+99Q5PFvRAtUuJq05erMbyZB+jrv93BQiVmSy
kap5V1iZ7gGgqZTPRK6a4RybNAONvcL1JCrK+tOu/uiRRGQbOnVdfYL0NIdSyES8
SVCqXjVs7b7yhRz7/0kmc1/olPle6wul7DdBZczQsUJGy0qTf0IiLoQG9xyCM88U
Tk3j6vQJrLKpyKtSgHPmrzyuUc8JEWBZ/LWo/PKH4OzQtNrxozZhzbXN2xRUyb+l
nwSsKDg/ah4qz14PIyK/dIynlgxwcrKGdMcnPdyaqe2eNtpstVbFznr63NSkG69E
5BZ5kprohgigzpjS4O7KDG+GZaIP44N7EdzFzhKHWfdrD0DvA+8MHMYzoM05T0xP
65zQ11iSVp6NpUm/XgiogxBLg+PPJJn1Gm5/FgKyKzqTFmxqNpJhIwpFKcgJahkX
CBR0vZXRK+XuAQ2YY4RTGXhcmDFEBcDJO7uP5JURKlJ5olKU6ARo/XxwJY7NEdd4
E1pbCf1ZJhdmACP2HiyQI8RftBW2cDsGlf/C6gy8bvB8A1eFqjSk5BC5n28jLo6/
TwW37Y8sLAhi87R6LdjJ
=/jOo
-END PGP SIGNATURE-

Bug#908913: stretch-pu: package systemd/232-25+deb9u5

[Cyril Brulebois]

Hi,

Michael Biebl  (2018-09-15):
> I'd like to make a stable upload for systemd, fixing #901834:
> systemd-networkd fails to start the network service because of race
> condition to dbus
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901834
> 
> Full debdiff is attached, the changelog reads
> 
> systemd (232-25+deb9u5) stretch; urgency=medium
> 
>   * networkd: Do not fail manager_connect_bus() if dbus is not active yet
> (Closes: #901834)
> 
>  -- Michael Biebl   Sat, 15 Sep 2018 21:40:38 +0200
> 
> 
> The issue is fixed in sid/buster, the patches are cherry-picks from
> upstream.
> 
> The changes don't touch udev, i.e. d-i, that said, I've kibi for his
> ack.

No objections, and thanks for the ping.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#908919: ITP: golang-gopkg-cheggaaa-pb.v2 -- simple console progress bar for Go(v2)

[Nobuhiro Iwamatsu]

Package: wnpp
Owner: Nobuhiro Iwamatsu 
Severity: wishlist

* Package name: golang-gopkg-cheggaaa-pb.v2
  Version : 2.0.6
  Upstream Author : Sergey Cherepanov
* URL : https://github.com/cheggaaa/pb
* License : BSD-3-clause
  Programming Lang: Go
  Description : simple console progress bar for Go(v2)

This package provides a simple progress bar for console programs.
This provides version 2.x of this library.

Bug#908918: connect(): Resource temporarily unavailable

[Sergey Lisov]

Package: tsocks
Version: 1.8beta5+ds1-1
Severity: normal

Dear Maintainer,

The libtsocks' connect() function may return with EWOULDBLOCK error if the 
socket is non-blocking and a connection attempt is in progress. However, the 
manual page for connect() says that EALREADY is to be returned in that case. 
Please change the connect() function to return EALREADY instead of EWOULDBLOCK.

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

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

Versions of packages tsocks depends on:
ii  libc6  2.24-11+deb9u3

tsocks recommends no packages.

tsocks suggests no packages.

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

-- no debconf information

Bug#907732: maildir-utils: May need versioned depend on libxapian30

[Mark J. Nelson]

Hi Norbert,

Sorry for the delay replying; lost track of this thread.

> The problem I see is that during build even an old version can be used,
> and during run time a version at least as new as the version it was
> compiled against.
>
> But AFAIS this cannot be expressed in debian/control, and I would prefer
> not introducing a strict dependency.
>
> Are you fine with closing this bug?

Thanks for the explanation. That makes sense, and I'm fine with closing
this bug.

-Mark

-- 
Mark J. Nelson
Falmouth University
http://www.kmjn.org

Bug#908917: [pkg-cryptsetup-devel] Bug#908917: cryptsetup: argon2id as default PBKDF setting for new installs - Buster+

[Guilhem Moulin]

By the way, on new systems formatting encrypted volumes is done by
partman_crypto, which is outside src:cryptsetup.  It's been proposed [0]
to pass `--type=luks2` to `luksFormat` there, but I'd much rather stick
to the upstream format version there too and wait for a version of the
cryptsetup binary (2.1 hopefully) that formats to LUKS2 by default.

-- 
Guilhem.

[0] https://salsa.debian.org/installer-team/partman-crypto/merge_requests/1


signature.asc
Description: PGP signature

Bug#851555: Blends install options removed from tasksel menu

[Ivo De Decker]

Control: severity -1 important

Hi,

On Mon, Jan 16, 2017 at 09:44:09AM +0100, Ole Streicher wrote:
> The change (ba4e0289) also makes it more difficult for others to add
> items to the installer tasksel menu for customized builds without a
> technical reason. And any CTTE decision will anyway make the patch obsolete.

Downgrading this bug, based on the decision.

Cheers,

Ivo

Bug#903904: RFS: wannier90/2.1.0 -- maximally localized Wannier functions

[Adam Borowski]

On Mon, Jul 16, 2018 at 03:44:21PM +0300, Andrius Merkys wrote:
> * Package name: wannier90
>   Version : 2.1.0
>   Upstream Author : Mostofi et al.
> * URL : http://www.wannier.org
> * License : GPL-2+
>   Programming Lang: Fortran
>   Description : maximally localized Wannier functions
> 
> It builds these binary packages:
>   wannier90- Maximally Localized Wannier Functions - executables
>   libwannier90-dev - Maximally Localized Wannier Functions - development files

While I cannot adequately review this package, and thus won't sponsor it,
here's a couple of problems:

1. The copyright file claims GPL-2+ with no authors outside "2017 Wannier
Developers' Group", yet I see at least test-suite/testcode being:
"Copyright (c) 2012 by James Spencer", license: BSD.

2. The package fails to build:

! LaTeX Error: File `ulem.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)

Enter file name: 
! Emergency stop.
 
 
l.19 \newcommand
\tent[1]{\textcolor{red}{#1}} % for tentative changes^^M
!  ==> Fatal error occurred, no output PDF file produced!



Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]

Bug#908917: cryptsetup: argon2id as default PBKDF setting for new installs - Buster+

[procmem]

Package: cryptsetup
Version: 2:2.0.4-2
Severity: important


Dear Maintainer,

As part of my work on a downstream privacy distro I asked the cryptsetup
team on how to transition current LUKS1 systems to use the improved
argon2id algo for the PBKDF implementation when using LUKS2.

Background:
While quantum computing does not have any advantage in speeding up
bruteforcing of PBKDF hashes they have a direct impact on passphrase
length. Using a 20 word diceware passphrase will be needed for
post-quantum passphase entropy of 256 bits. This is excessive and very
difficult for most users to manage hence the importance of PBKDF for
anti-bruteforcing.

The current sha256 PBKDF used in LUKS1 is trivial to parallelize by
adversaries who have large GPU computational power, making it  a useless
countermeasure and leading users to rely on passphrase lenth for only
protection.



***

It would be great if all newly installed systems running Buster and
beyond used LUKS2 and argon2id out of the box instead of having users
optionally opt for a safer configuration.

The recommended config paramters by Milan Broz:

  # cryptsetup luksConvertKey --key-slot 1 --pbkdf argon2id
--pbkdf-force-iterations 50 --pbkdf-memory 1048576 --pbkdf-parallel 4



Original full reply:
[0] https://www.saout.de/pipermail/dm-crypt/2018-September/005968.html


Thanks

Bug#908916: firefox-esr: q

[Vasant]

Package: firefox-esr
Version: 60.2.0esr-1~deb9u2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

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

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


-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv8l)

Kernel: Linux 3.14.29 (SMP w/4 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: sysvinit (via /sbin/init)

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-11+deb9u3
ii  libcairo-gobject2 1.14.8-1
pn  libcairo2 
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
pn  libgtk-3-0
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.40.5-1
pn  libstartup-notification0  
ii  libstdc++66.3.0-18+deb9u1
ii  libvpx4   1.6.1-3+deb9u1
pn  libx11-6  
pn  libx11-xcb1   
pn  libxcb-shm0   
pn  libxcb1   
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
pn  libxext6  
ii  libxfixes31:5.0.3-1
pn  libxrender1   
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages firefox-esr recommends:
ii  libavcodec57  7:3.2.12-1~deb9u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
pn  libcanberra0   
ii  libgssapi-krb5-2   1.15-1+deb9u1
pn  libgtk2.0-0

-- debconf-show failed

Bug#903845: RFS: lv2bm/1.0-1 [ITP] -- LV2 audio plugin tester with uses in autopktest

[Adam Borowski]

On Sun, Jul 15, 2018 at 08:18:32PM +0200, Víctor Cuadrado Juan wrote:
>  * Package name: lv2bm
>Version : 1.0-1
>  * URL : https://github.com/moddevices/lv2bm

> Description: Benchmark CLI tool for LV2 plugins
>  Features:
>   - Allows one to select which LV2 URIs to test
>   - Uses minimum, maximum and default control values to run the plugins
>   - Has a full test mode which check all combinations for discrete 
> controls
>   - Can be used along with valgrind to detect plugin memory issues
> 
> In addition to shipping /usr/bin/lv2bm, the package also ships
> /usr/bin/lv2-plugin_autopkgtest, a script that uses lv2bm to smoke-test
> installed LV2 plugins.

>   https://salsa.debian.org/multimedia-team/lv2bm

I don't have a clue what this is about, but as it's at least not node.js or
a python library, I took a look...

But alas, any use seems to fail:

[~/tmp/pkg]$ lv2bm http://portalmod.com/plugins/caps/CabinetIV
Segmentation fault (core dumped)
[~/tmp/pkg]SEGV$ lv2bm http://lv2plug.in/plugins/eg-amp
Segmentation fault (core dumped)
[~/tmp/pkg]SEGV$ lv2bm --full-test http://lv2plug.in/plugins/eg-amp+
Segmentation fault (core dumped)
[~/tmp/pkg]SEGV$ lv2bm --full-test http://lv2plug.in/plugins/eg-amp
Segmentation fault (core dumped)
[~/tmp/pkg]SEGV$ lv2bm fdlkfsdfdg
error: attempt to map invalid URI `fdlkfsdfdg'
Segmentation fault (core dumped)
[~/tmp/pkg]SEGV$ lv2bm http://example.org
Segmentation fault (core dumped)
[~/tmp/pkg]SEGV$ 


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]

Bug#908889: src:firefox-esr: Fix broken ppc64 build

[Mike Hommey]

severity 908889 normal

On Sat, Sep 15, 2018 at 03:59:13PM +0200, Roberto Guardato wrote:
> Package: src:firefox-esr
> Version: 60.2.0esr
> Severity: serious
> Justification: fails to build from source
> 
> Hi all,
> trying to build firefox-esr on PowerPc64 (ppc64) arch i obtain the following 
> error:
> 
> DEBUG: Executing: `/usr/bin/rustc --print target-list`
> DEBUG: Creating `/tmp/conftest8qrTCp.rs` with content:
> DEBUG: | pub extern fn hello() { println!("Hello world"); }
> DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib 
> --target=powerpc64-unknown-linux-gnu -o /tmp/conftest5k25jo.rlib 
> /tmp/conftest8qrTCp.rs`
> DEBUG: The command returned non-zero exit status 101.
> DEBUG: Its error output was:
> DEBUG: | thread '' panicked at 'failed to acquire jobserver token: 
> Bad file descriptor (os error 9)', librustc_codegen_llvm/back/write.rs:1826:29
> DEBUG: | stack backtrace:
> DEBUG: |0: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
> DEBUG: |1: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
> DEBUG: |2: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
> DEBUG: |3: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
> DEBUG: |4: 
> DEBUG: |5: std::panicking::rust_panic_with_hook
> DEBUG: |6: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
> DEBUG: |7: std::panicking::begin_panic_fmt
> DEBUG: |8: 
> DEBUG: |9: 
> DEBUG: |   10: __rust_maybe_catch_panic
> DEBUG: |   11: 
> DEBUG: |   12: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
> DEBUG: |   13: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
> DEBUG: |   14: 
> DEBUG: | query stack during panic:
> DEBUG: | end of query stack
> DEBUG: | error: failed to acquire jobserver token: Bad file descriptor (os 
> error 9)
> DEBUG: | 
> DEBUG: | error: aborting due to previous error
> DEBUG: | 
> ERROR: Cannot compile for powerpc64-unknown-linux-gnu with /usr/bin/rustc
> The target may be unsupported, or you may not have
> a rust std library for that target installed. Try:
> 
>   rustup target add powerpc64-unknown-linux-gnu
> 
> Many thanks for your support.
> rt1k

Try DEB_BUILD_OPTIONS=parallel=n dpkg-buildpackage instead of
dpkg-buildpackage -jn

Mike

Bug#839961: Upstream is now at v5.7.0

[Phil Endecott]

Hi,

libjs-d3 in Debian has not been updated for more than 2 years.
Version 3.5.17 isn't really very useful.
Please consider updating it, or perhaps officially orphan it if
you are no longer able to maintain it.


Thanks, Phil.

Bug#908494: lightning: no icon to access calendar after upgrade to TB 60

[George B.]

Package: lightning
Followup-For: Bug #908494

And a screenshot to show what it looks like.

Bug#900579: RFS: libminini/1.2.a-1 [ITP]

[Adam Borowski]

On Fri, Jun 01, 2018 at 11:24:39PM +0800, Yangfl wrote:
>  * Package name: libminini
>Version : 1.2.a-1
>Upstream Author : Thiadmer Riemersma
>  * URL : https://www.compuphase.com/minini.htm
> 
> It builds those binary packages:
> 
>   libminini-dev - minimal INI file parser - development headers
>   libminini1 - minimal INI file parser

>   dget -x 
> https://mentors.debian.net/debian/pool/main/libm/libminini/libminini_1.2.a-1.dsc

Sorry for taking so long; there's too many RFSes left rotting...

symbols file produces:

 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@Ba
se 1.2.a-1

which has a Debian revision.


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#908878: glance-common debconf not working as expected - no selection of db backends

[Thomas Goirand]

On 09/15/2018 01:45 PM, Michal Arbet wrote:
> Package: glance-common
> Version: 2:17.0.0-1
> 
> When installing glance with debconf and selected option to configure db
> with dbconfig ( debconf  is of course configured to show lowest priority
> questions and interactive dialog ), question with database backend
> selection is not appearing.

How come it works perfectly for me then?

> So , there is no option to select mysql or different sql backend.
> Package is installing sqlite without asking.

Not what I experienced. Did you make sure to have mysql client installed
before starting to install?

> Expected result is that debconf should ask for database backend,

*IF* you have a mysql client install, yes. Otherwise, dbconfig-common
will not ask for that.

> database administrative account, password, an app username and password
> like it is in other projects ( for example keystone is working good )

I just tried, and it worked perfectly for me with Glance too...

Cheers,

Thomas Goirand (zigo)

Bug#908494: lightning: no icon to access calendar after upgrade to TB 60

[George B.]

Package: lightning
Version: 1:60.0-3
Followup-For: Bug #908494

I have now recreated the issue on a clean install of Sid in a VM.

Steps were:

- install from 9.5.0-netinst ISO with basic packages option
- change sources.list to point to sid and dist-upgrade
- install xorg wdm awesome thunderbird-l10n-en-gb lightning

There is no longer any debconf error below (sending this from the VM)
but no useful information unfortunately.

I have looked in my config editor and there is no settings that match
"extensions.installedDistroAddon".


Thanks,

George

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (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 lightning depends on:
ii  thunderbird  1:60.0-3

lightning recommends no packages.

Versions of packages lightning suggests:
pn  calendar-google-provider  
pn  fonts-lyx 

-- no debconf information

Bug#908898: ublock-origin: debian/watch does not work correctly

[Markus Koschany]

Control: tags -1 pending

Am 15.09.2018 um 20:26 schrieb Sven Joachim:
[...]
> Still, the watch file is useful for tracker.debian.org. 
> 
>> diff --git a/debian/watch b/debian/watch
>> index c0a168727..49d51c087 100644
>> --- a/debian/watch
>> +++ b/debian/watch
>> @@ -1,3 +1,3 @@
>>  version=3
>>  opts=repacksuffix=+dfsg,dversionmangle=s/\+(repack|dfsg|ds|deb)\d*$// \
>> -https://github.com/gorhill/uBlock/releases .*/archive/(.*)\.tar\.gz
>> +https://github.com/gorhill/uBlock/releases .*/archive/\d(.*)\.tar\.gz
> 
> Better use the attached version which does not eat the first digit of the
> upstream version in ublock-origin_*.orig.tar.gz.

Thanks for the report and the patch!

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#908915: Several tests fail (not skipped) without certain packages installed

[Josh Triplett]

Package: lintian
Version: 2.5.103
Severity: normal

When trying to run the lintian testsuite, I got several test failures:

Failed tests (6)
tests::binaries-missing-depends-on-numpy-abi
tests::debhelper-dh-quilt-addon-but-quilt-source-format
tests::debhelper-dh-quilt-addon-but-quilt-source-format-unrel
tests::debhelper-dh-with-quilt
tests::rules-including-deprecated-makefiles
tests::rules-missing-targets-with-known-includes

Looking at the log, these seem to fail without certain packages
installed. I'm not sure if the bug is that those tests lack
Test-Depends, or in some cases if the tests shouldn't be trying to
build.

For example, rules-missing-targets-with-known-includes fails due to
missing /usr/share/javahelper/java-vars.mk:

tests::rules-missing-targets-with-known-includes:  START BUILD LOG
tests::rules-missing-targets-with-known-includes: dpkg-buildpackage: info: 
source package rules-missing-targets-with-known-includes
tests::rules-missing-targets-with-known-includes: dpkg-buildpackage: info: 
source version 1.0
tests::rules-missing-targets-with-known-includes: dpkg-buildpackage: info: 
source distribution unstable
tests::rules-missing-targets-with-known-includes: dpkg-buildpackage: info: 
source changed by Debian Lintian Maintainers 
tests::rules-missing-targets-with-known-includes:  dpkg-source 
-iNEVER_MATCH_ANYTHING -INEVER_MATCH_ANYTHING --auto-commit --before-build 
rules-missing-targets-with-known-includes-1.0
tests::rules-missing-targets-with-known-includes: dpkg-buildpackage: info: host 
architecture amd64
tests::rules-missing-targets-with-known-includes: dpkg-source: warning: 
--auto-commit is not a valid option for Dpkg::Source::Package::V1
tests::rules-missing-targets-with-known-includes:  debian/rules clean
tests::rules-missing-targets-with-known-includes: debian/rules:5: 
/usr/share/javahelper/java-vars.mk: No such file or directory
tests::rules-missing-targets-with-known-includes: make: *** No rule to make 
target '/usr/share/javahelper/java-vars.mk'.  Stop.
tests::rules-missing-targets-with-known-includes: dpkg-buildpackage: error: 
debian/rules clean subprocess returned exit status 2
tests::rules-missing-targets-with-known-includes:  END BUILD LOG
error tests::rules-missing-targets-with-known-includes: internal error: cd 
/home/josh/src/lintian/debian/test-out/tests/rules-missing-targets-with-known-includes/rules-missing-targets-with-known-includes-1.0
 && dpkg-buildpackage -rfakeroot -us -uc -d -iNEVER_MATCH_ANYTHING 
-INEVER_MATCH_ANYTHING --source-option=--auto-commit 
>/home/josh/src/lintian/debian/test-out/tests/rules-missing-targets-with-known-includes/build.rules-missing-targets-with-known-includes
 2>&1 at t/runtests line 466.

And rules-including-deprecated-makefiles fails due to missing
/usr/share/cdbs/1/rules/simple-patchsys.mk:

tests::rules-including-deprecated-makefiles:  START BUILD LOG
tests::rules-including-deprecated-makefiles: dpkg-buildpackage: info: source 
package rules-including-deprecated-makefiles
tests::rules-including-deprecated-makefiles: dpkg-buildpackage: info: source 
version 1.0
tests::rules-including-deprecated-makefiles: dpkg-buildpackage: info: source 
distribution unstable
tests::rules-including-deprecated-makefiles: dpkg-buildpackage: info: source 
changed by Debian Lintian Maintainers 
tests::rules-including-deprecated-makefiles:  dpkg-source 
-iNEVER_MATCH_ANYTHING -INEVER_MATCH_ANYTHING --auto-commit --before-build 
rules-including-deprecated-makefiles-1.0
tests::rules-including-deprecated-makefiles: dpkg-buildpackage: info: host 
architecture amd64
tests::rules-including-deprecated-makefiles: dpkg-source: warning: 
--auto-commit is not a valid option for Dpkg::Source::Package::V1
tests::rules-including-deprecated-makefiles:  debian/rules clean
tests::rules-including-deprecated-makefiles: debian/rules:4: 
/usr/share/cdbs/1/rules/simple-patchsys.mk: No such file or directory
tests::rules-including-deprecated-makefiles: make: *** No rule to make target 
'/usr/share/cdbs/1/rules/simple-patchsys.mk'.  Stop.
tests::rules-including-deprecated-makefiles: dpkg-buildpackage: error: 
debian/rules clean subprocess returned exit status 2
tests::rules-including-deprecated-makefiles:  END BUILD LOG
error tests::rules-including-deprecated-makefiles: internal error: cd 
/home/josh/src/lintian/debian/test-out/tests/rules-including-deprecated-makefiles/rules-including-deprecated-makefiles-1.0
 && dpkg-buildpackage -rfakeroot -us -uc -d -iNEVER_MATCH_ANYTHING 
-INEVER_MATCH_ANYTHING --source-option=--auto-commit 
>/home/josh/src/lintian/debian/test-out/tests/rules-including-deprecated-makefiles/build.rules-including-deprecated-makefiles
 2>&1 at t/runtests line 466.

Should these tests use Test-Depends, or for some of these tests should
lintian just build a source package and check that without trying to
build binary packages?

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 

Bug#908899: reduce installation size

[Gianfranco Costamagna]

Hello Daniel!
On Sat, 15 Sep 2018 18:55:40 +0200 Daniel Baumann 
 wrote:
> Package: virtualbox-ext-pack
> Severity: wishlist
> 
> Hi,
> 
> thank you for maintaining virtual-ext-pack in Debian.
> 
> I have a few suggestions on how to improve the user experience but
> before sending patches, I would like to ask your opinon on it.
> 
> 
> 1. keeping vbox-ext files
> -
> 
> currently virtualbox-ext-pack downloads the ext-pack file, installs it,
> and keeps the downloaded file saved in /usr/share/virtualbox-ext-pack
> (~19MB).
> 
> imho, packages that download stuff should treat any downloaded files as
> 'temporary' files, i.e. they should download, install, and remove any
> afterwards unsed files to not increase runtime-diskusage unecessary. on
> a dpkg-reconfigure, the package should just re-download the necessary files.
> 
> would you accept a patch(es) to..
> 
>   .. remove the ext-pack file after successfull installation of the
>  extension?
> 
>   .. if not, would you agree having a debconf question to make it
>  conditional (so that users get asked, if they want to keep it
>  which would then default to 'yes')?
> 
> 
> 2. contents of the ext-pack extension
> -
> 
> the virtualbox-ext-pack extension currently contains binaries for linux
> (amd64, i386), macosx (amd64), solaris (amd64), and windows (amd64,
> i386). the extension is only usable together with virtualbox, i.e.
> virtualbox uses only the ext-pack parts for the operating system and
> architecture it is running on (regardless what guest operating
> systems/architectures are used).
> 
> on linux (amd64), removing the other-os/arch files saves 35MB (53MB
> total size, 18MB amd64 binaries).
> 
> ever since the introduction of extensions in virtualbox, these files are
> simply gzip compressed tarballs without any cryptographic signature,
> only containing a simple manifest (md5/sha256/sha512 checksums).
> 
> would you accept a patch(es) to..
> 
>   .. removing all unecessary other-os/arch files after installation
>  of the extension?
> 
>  as a datapoint wrt/ to the extension meta-data: i'm doing this in
>  my unofficial package for years and never had any problems since
>  the meta-data in the extension never changed (and if it would,
>  it could be easily adapted), see:
> 

You are free to join the team, and commit what you think is the best approach :)

I think I already remove old files, but not current files after installation.

Please change, push, upload as you wish, as long as testsuite keeps working, and
the package too!

Gianfrancoo

Bug#908914: ccextractor -out=report /dev/null segfaults

[Giuliano Procida]

Package: ccextractor
Version: 0.86+ds1-2
Severity: normal
Tags: upstream

Dear Maintainer,

$ ccextractor -out=report /dev/null
File: /dev/null
Stream Mode: Not Found
EIA-608: No
CEA-708: No
MPEG-4 Timed Text: No
Segmentation fault (core dumped)

I noticed this when running ccextractor on a regular empty file.

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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages ccextractor depends on:
ii  libc6 2.27-5
ii  libfreetype6  2.8.1-2
ii  libpng16-16   1.6.34-2
ii  libutf8proc2  2.2.0-1
ii  zlib1g1:1.2.11.dfsg-1

ccextractor recommends no packages.

ccextractor suggests no packages.

-- no debconf information

Bug#883185: systemd-networkd: physical port in bridge stuck in "configuring", failing systemd-networkd-wait-online.service

[Michael Biebl]

Control: tags -1 + moreinfo

Hi Berni

On Thu, 30 Nov 2017 13:15:25 +0100 Michael Biebl  wrote:
> Am 30.11.2017 um 13:11 schrieb Bernhard Schmidt:
> > Package: systemd
> > Version: 235-3
> > Severity: normal
> > 
> > Hi,
> > 
> > after upgrading from Stretch to Buster the physical interface in my bridge
> > is stuck in "configuring", causing systemd-networkd-wait-online to stall
> > and eventually timeout.
> > 
> > This looks like https://github.com/systemd/systemd/issues/5043, although
> > I'm sure that I did not see this problem in systemd 232 in stable, unlike
> > the upstream reporter.
> 
> Can you please try the patch in
> https://github.com/systemd/systemd/commit/5971cb9de9081b537945d28895df70992e5664d0
> and report back at the upstream bug tracker with your results.

Did you have a check to test with a recent version of systemd if the
problem is still reproducible and if so, if the above patch helps?

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#908913: stretch-pu: package systemd/232-25+deb9u5

[Michael Biebl]

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

Hi,

I'd like to make a stable upload for systemd, fixing #901834:
systemd-networkd fails to start the network service because of race
condition to dbus
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901834

Full debdiff is attached, the changelog reads

systemd (232-25+deb9u5) stretch; urgency=medium

  * networkd: Do not fail manager_connect_bus() if dbus is not active yet
(Closes: #901834)

 -- Michael Biebl   Sat, 15 Sep 2018 21:40:38 +0200


The issue is fixed in sid/buster, the patches are cherry-picks from
upstream.

The changes don't touch udev, i.e. d-i, that said, I've kibi for his
ack.

Regards,
Michael

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index a81c855..740787b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+systemd (232-25+deb9u5) stretch; urgency=medium
+
+  * networkd: Do not fail manager_connect_bus() if dbus is not active yet
+(Closes: #901834)
+
+ -- Michael Biebl   Sat, 15 Sep 2018 21:40:38 +0200
+
 systemd (232-25+deb9u4) stretch; urgency=medium
 
   * core/load-fragment: Add RemoveIPC=
diff --git 
a/debian/patches/network-resolve-remove-comments-related-to-kdbus.patch 
b/debian/patches/network-resolve-remove-comments-related-to-kdbus.patch
new file mode 100644
index 000..2da2e1c
--- /dev/null
+++ b/debian/patches/network-resolve-remove-comments-related-to-kdbus.patch
@@ -0,0 +1,38 @@
+From: Yu Watanabe 
+Date: Wed, 23 Aug 2017 12:38:56 +0900
+Subject: network,resolve: remove comments related to kdbus
+
+(cherry picked from commit d7ea7bb8a8da9f94d8fbc5be2c5c4b2ebe40b7b3)
+---
+ src/network/networkd-manager.c | 3 +--
+ src/resolve/resolved-bus.c | 3 +--
+ 2 files changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/src/network/networkd-manager.c b/src/network/networkd-manager.c
+index 360677d..681fe0b 100644
+--- a/src/network/networkd-manager.c
 b/src/network/networkd-manager.c
+@@ -138,8 +138,7 @@ int manager_connect_bus(Manager *m) {
+ r = sd_bus_default_system(>bus);
+ if (r < 0) {
+ /* We failed to connect? Yuck, we must be in early
+- * boot. Let's try in 5s again. As soon as we have
+- * kdbus we can stop doing this... */
++ * boot. Let's try in 5s again. */
+ 
+ log_debug_errno(r, "Failed to connect to bus, trying again in 
5s: %m");
+ 
+diff --git a/src/resolve/resolved-bus.c b/src/resolve/resolved-bus.c
+index 2ca65e6..f53324a 100644
+--- a/src/resolve/resolved-bus.c
 b/src/resolve/resolved-bus.c
+@@ -1641,8 +1641,7 @@ int manager_connect_bus(Manager *m) {
+ r = sd_bus_default_system(>bus);
+ if (r < 0) {
+ /* We failed to connect? Yuck, we must be in early
+- * boot. Let's try in 5s again. As soon as we have
+- * kdbus we can stop doing this... */
++ * boot. Let's try in 5s again. */
+ 
+ log_debug_errno(r, "Failed to connect to bus, trying again in 
5s: %m");
+ 
diff --git 
a/debian/patches/networkd-do-not-fail-manager_connect_bus-if-dbus-is-not-a.patch
 
b/debian/patches/networkd-do-not-fail-manager_connect_bus-if-dbus-is-not-a.patch
new file mode 100644
index 000..6be5a48
--- /dev/null
+++ 
b/debian/patches/networkd-do-not-fail-manager_connect_bus-if-dbus-is-not-a.patch
@@ -0,0 +1,25 @@
+From: Yu Watanabe 
+Date: Wed, 23 Aug 2017 12:36:36 +0900
+Subject: networkd: do not fail manager_connect_bus() if dbus is not active
+ yet
+
+Fixes #6618.
+
+(cherry picked from commit fb72b1d99f661ea62fd534e4bc1174c6337611c8)
+---
+ src/network/networkd-manager.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/network/networkd-manager.c b/src/network/networkd-manager.c
+index 9174dcc..360677d 100644
+--- a/src/network/networkd-manager.c
 b/src/network/networkd-manager.c
+@@ -136,7 +136,7 @@ int manager_connect_bus(Manager *m) {
+ assert(m);
+ 
+ r = sd_bus_default_system(>bus);
+-if (r == -ENOENT) {
++if (r < 0) {
+ /* We failed to connect? Yuck, we must be in early
+  * boot. Let's try in 5s again. As soon as we have
+  * kdbus we can stop doing this... */
diff --git a/debian/patches/series b/debian/patches/series
index 8252799..3c1ebbe 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -83,6 +83,8 @@ core-load-fragment-add-RemoveIPC-7288.patch
 

Bug#908911: lintian: Allow dir-or-file-in-etc-opt to be overridable

[Chris Lamb]

tags 908911 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/1a218952106765eb35aa28f53dc6c7b397854c10

  debian/changelog   |  4 +++
  private/build-time-data/ftp-master-fatal   |  6 ++--
  private/build-time-data/ftp-master-nonfatal| 16 -
  profiles/debian/ftp-master-auto-reject.profile | 49 --
  4 files changed, 54 insertions(+), 21 deletions(-)


Regards,

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

Bug#908912: uhd: Wrong command suggested when not finding images

[Ruben Undheim]

Source: uhd
Version: 3.12.0.0-3
Severity: normal

Hi Maintainer,

It seems like bug #772412 has crept in again at some point.
(See: https://bugs.debian.org/772412)

Many thanks.

Best regards
Ruben

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

Kernel: Linux 4.18.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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#908911: lintian: Allow dir-or-file-in-etc-opt to be overridable

[Jeremy Bicha]

Source: lintian
Version: 2.5.103
Affects: chrome-gnome-shell

chrome-gnome-shell ships a file in /etc/opt/ [1] so that it integrates
with Google Chrome. Google Chrome installs to /opt/ and uses /etc/opt/
for configuration. Although this stirred up a bit of controversy [2]
in Debian, it seems to me like this is acceptable for Debian. (Despite
chrome-gnome-shell's name, it also integrates with Firefox and
Chromium.)

I tried to set a lintian override but it looks like this tag is listed
as non-overridable in profiles/debian/ftp-master-auto-reject.profile

According to https://bugs.debian.org/840235 it is not actually a
ftp-master autoreject any more.

[1] https://lintian.debian.org/tags/dir-or-file-in-etc-opt.html
[2] https://bugs.debian.org/888549

Thanks,
Jeremy Bicha

Bug#898034: Acknowledgement (adduser: [INTL:de] updated German debconf translation)

[Helge Kreutzmann]

Hello Afif,
On Sat, Sep 15, 2018 at 03:01:52PM -0400, Afif Elghraoui wrote:
> على السبت 15 أيلول 2018 ‫08:08، كتب Helge Kreutzmann:
> > I see that als the dutch and french translations are pending.
> > 
> > If you want, I can do an NMU just with the three translations, but I
> > assume you are doing a MU instead?
> 
> I had actually removed my name from the adduser uploaders. Since I never
> made an upload to realize that change, I can add these translations as
> part of it and do this today.

Thanks for your work and for the upload.

And all the best for your new endavours.

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#908856: libprojectm2v5: unsatisfiable dependency on projectm-data:i386

[Helmut Grohne]

Control: reassign -1 projectm-data
Control: retitle -1 mark projectm-data Multi-Arch: foreign

On Sat, Sep 15, 2018 at 08:04:23AM +0200, Marc Lehmann wrote:
>  clementine:i386 : Depends: projectm-data:i386 (>= 2.0.1+dfsg-6) but it is 
> not installable
>  libprojectm2v5:i386 : Depends: projectm-data:i386 but it is not installable
> 
> apparently, libprojectm2v5 has a dependency to projectm-data:i386, but the
> projectm-data package is Architecture: all.
> 
> I don't know if this is a problem with projectm-data, libprojectm2v5 or
> apt - apologies if I am reporting this against the wrong package.

Yes, it is a problem with projectm-data. It needs to be marked
Multi-Arch: foreign. The multiarch hinter explains that this marking is
safe, because projectm-data entirely lacks dependencies and maintainer
scripts.

Helmut

Bug#908909: Please document debhelper-compat Build-Depends

[Josh Triplett]

tags 908909 + patch
thanks

I submited an MR adding documentation for this:
https://salsa.debian.org/debian/debhelper/merge_requests/11

Bug#898034: Acknowledgement (adduser: [INTL:de] updated German debconf translation)

[Afif Elghraoui]

Hi, Helge

على السبت 15 أيلول 2018 ‫08:08، كتب Helge Kreutzmann:
> Do you have any ETA for including the German Debconf translation? 
> 
> Since this is a central package it would be great if German speaking
> users could see the localiized prompts.
> 
> I see that als the dutch and french translations are pending.
> 
> If you want, I can do an NMU just with the three translations, but I
> assume you are doing a MU instead?

I had actually removed my name from the adduser uploaders. Since I never
made an upload to realize that change, I can add these translations as
part of it and do this today.

regards
Afif

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

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[David Bremner]

Tollef Fog Heen  writes:

>
> The Committee recognises that there is a need for packages to behave
> differently when built on different distributions, but this should be
> done as part of the build process, using current and future practices
> such as patches with conditional behaviour, patching of files during the
> build, rather than at source unpacking time.

Does it need to be said that producing different source packages for
different distributions is also perfectly acceptable? A narrow reading
of this paragraph might give the impression that it is not. One option
would be say something like

  ... on different distributions, but this difference should not be
  done at source unpacking time but e.g. as part of the build
  process...

Arguably this concern is moot because everyone (TM) understands that a
package being built refers to going from a source package to one or more
binary packages.

Bug#908910: libdumbnet FTBFS with debhelper 11.4: dh_prep: Unknown option: k

[Adrian Bunk]

Source: libdumbnet
Version: 1.12-7
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/libdumbnet.html

...
dh_testdir
dh_prep -k
Unknown option: k
dh_prep: unknown option or error during option parsing; aborting
make: *** [debian/rules:20: configure-stamp] Error 25

Bug#908889: src:firefox-esr: Fix broken ppc64 build

[Juhani Numminen]

Control: tag -1 +moreinfo

Dear Roberto,

I'm not a maintainer of firefox-esr, but to me, this bug report seems a bit
incomplete.

On Sat, 15 Sep 2018 15:59:13 +0200 Roberto Guardato  
wrote:

> Package: src:firefox-esr
> Version: 60.2.0esr

Did you mean 60.2.0esr-1?

> Hi all,
> trying to build firefox-esr on PowerPc64 (ppc64) arch i obtain the following 
> error:

Please attach the complete build log.

How did you start the build – did you use a chroot, sbuild, pbuilder...?


Best regards,
Juhani

Bug#908884: On Bug #908884

[Masayuki Hatta]

tags 908884 upstream
thanks

Hi,

Thanks for reporting.

I could reproduce the hung up on sid & buster. Installing
libtomcat8-java 8.5.32-2 fixes the problem.

It seems that some bug has been entered into the upstream Tomcat8
between 8.5.32 and 8.5.33.

https://bz.apache.org/bugzilla/show_bug.cgi?id=62674

Best regards,
MH

-- 
Masayuki Hatta
Associate Professor, Faculty of Economics and Management, Surugadai
University, Japan

http://about.me/mhatta

mha...@gnu.org  / mha...@debian.org / mha...@opensource.jp /
hatta.masay...@surugadai.ac.jp

Bug#908909: Please document debhelper-compat Build-Depends

[Josh Triplett]

Package: debhelper
Version: 11.4
Severity: normal

debhelper(7) does not yet document the new approach of using
debhelper-compat Build-Depends to specify the compat level.

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  0.042-1
ii  dpkg 1.19.0.5+b1
ii  dpkg-dev 1.19.0.5
ii  dwz  0.12-2
ii  file 1:5.34-2
ii  libdpkg-perl 1.19.0.5
ii  man-db   2.8.4-2
ii  perl 5.26.2-7
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201801

-- no debconf information

Bug#908907: Please provide debhelper-compat 12 or document why not

[Josh Triplett]

Package: debhelper
Version: 11.4
Severity: normal

debhelper provides debhelper-compat 9, 10, and 11, but not 12. So,
packages that want to try out the new compat level 12 currently have to
go back to using debian/compat. Could you please provide
debhelper-compat 12?

If there's some reason not to do this, could you please document that
reason (and the recommended alternative for packages using that compat
level) alongside the documentation for debhelper-compat itself?

(Speaking of which, it appears that debhelper(7) doesn't yet document
debhelper-compat Build-Depends.)

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  0.042-1
ii  dpkg 1.19.0.5+b1
ii  dpkg-dev 1.19.0.5
ii  dwz  0.12-2
ii  file 1:5.34-2
ii  libdpkg-perl 1.19.0.5
ii  man-db   2.8.4-2
ii  perl 5.26.2-7
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201801

-- no debconf information

Bug#908908: turn lvm2-dbusd Architecture: all

[Helmut Grohne]

Package: lvm2-dbusd
Version: 2.02.176-4.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Please trun lvm2-dbusd into an Architecture: all package. Doing so
solves a number of problems relevant to bootstrapping:
 * lvm2 cannot be cross built, because its depenedency on python3-pyudev
   cannot be satisfied. Given that python3-pyudev is Architecture: all,
   not even annotating it :native will help here. This package can be
   demoted to Build-Depends-Indep after making lvm2-dbusd Architecture:
   all. Thus cross-Build-Depends become satisfiable (in a non-bootstrap
   setting).
 * There is a longer dependency cycle between lvm2 (via systemd) through
   python3. Turning lvm2-dbusd Architecture: all means that all of the
   python depends can be moved to Build-Depends-Indep solving the cycle.
 * We save approximately 450kb of mirror space. ;)

The attached patch implements the requested feature. I used reproducible
builds to verify that the differences between arch-only, indep-only and
full builds are reasonable. In fact, there is no difference for
lvm2-dbusd and for the Architecture: any packages the differences result
from embedding the ./configure flags and deriving the build-id from the
build directory. So the change should be reasonably safe. Please
consider applying it.

Helmut
diff --minimal -Nru lvm2-2.02.176/debian/changelog 
lvm2-2.02.176/debian/changelog
--- lvm2-2.02.176/debian/changelog  2017-12-03 03:39:59.0 +0100
+++ lvm2-2.02.176/debian/changelog  2018-09-15 20:42:21.0 +0200
@@ -1,3 +1,10 @@
+lvm2 (2.02.176-4.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Turn lvm2-dbusd Architecture: all. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 15 Sep 2018 20:42:21 +0200
+
 lvm2 (2.02.176-4.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff --minimal -Nru lvm2-2.02.176/debian/control lvm2-2.02.176/debian/control
--- lvm2-2.02.176/debian/control2017-11-09 20:40:11.0 +0100
+++ lvm2-2.02.176/debian/control2018-09-15 20:42:15.0 +0200
@@ -5,7 +5,6 @@
 Uploaders: Bastian Blank 
 Build-Depends:
  debhelper (>= 10.9.2),
- dh-python,
  autoconf-archive,
  automake,
  libblkid-dev,
@@ -19,11 +18,13 @@
  libselinux1-dev,
  libsystemd-dev,
  libudev-dev,
+ pkg-config,
+ systemd
+Build-Depends-Indep:
+ dh-python,
  python3-dev,
  python3-dbus,
  python3-pyudev,
- pkg-config,
- systemd
 Standards-Version: 4.1.1
 Homepage: http://sources.redhat.com/lvm2/
 Vcs-Git: https://gitlab.com/debian-lvm/lvm2.git
@@ -56,8 +57,8 @@
  regular block devices.
 
 Package: lvm2-dbusd
-Architecture: linux-any
-Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}, lvm2 (= 
${binary:Version}), dbus,
+Architecture: all
+Depends: ${python3:Depends}, ${misc:Depends}, lvm2 (>= ${source:Version}), 
lvm2 (<< ${source:Version}.1), dbus,
  python3-dbus,
  python3-gi,
  python3-pyudev,
diff --minimal -Nru lvm2-2.02.176/debian/rules lvm2-2.02.176/debian/rules
--- lvm2-2.02.176/debian/rules  2017-12-03 03:37:24.0 +0100
+++ lvm2-2.02.176/debian/rules  2018-09-15 20:42:21.0 +0200
@@ -27,7 +27,8 @@
 endif
 
 %:
-   dh $@ --parallel --with python3
+   dh $@ --parallel $(DH_ADDONS)
+build binary %-indep: DH_ADDONS+=--with=python3
 
 override_dh_auto_configure: SOURCE_FILES = $(filter-out debian, $(wildcard * 
.[^.]*))
 override_dh_auto_configure:
@@ -59,7 +60,7 @@
--enable-cmdlib \
--enable-cmirrord \
--enable-dmeventd \
-   --enable-dbus-service \
+   --$(if $(filter lvm2-dbusd,$(shell 
dh_listpackages)),en,dis)able-dbus-service \
--enable-lvmetad \
--enable-lvmlockd-dlm \
--enable-lvmlockd-sanlock \

Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Michael Biebl]

Am 15.09.18 um 20:31 schrieb Russ Allbery:
> Adding Colin as base-passwd maintainer.
> 
> Sean Whitton  writes:
>> On Fri 10 Aug 2018 at 08:23AM +0200, Michael Biebl wrote:
> 
>>> Currently, DynamicUser gets a uid from within the following range:
>>> 61184 - 65519. Those values can be configured during build time via
>>> -Ddynamic-uid-min= and -Ddynamic-uid-max.
> 
> Those two numbers are oddly specific.  Is there some history behind those
> specific boundaries?

There is
http://0pointer.net/blog/dynamic-users-with-systemd.html

and

https://salsa.debian.org/systemd-team/systemd/blob/master/doc/UIDS-GIDS.md
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#908540: redis: FTBFS randomly (failing tests)

[Chris Lamb]

tags 908540 + pending
thanks

Dear Santiago,

> I've just noticed that the package FTBFS in experimental in
> reproducible builds
[..]
> Would that be enough to consider that the problem is most probably not
> fixed in experimental?

Indeed. I'm really tired of playing whack-a-mole with the testsuite (4+
patches and counting at this point...) so until upstream get their act
together I will simplify everything and run with "|| true" for now.

(We were doing this already on mipsel, so this isn't too crazy...)

Thanks; pending upload.


Regards,

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

Bug#906877: RFS: yuma123/2.11-1

[Herbert Fortes]

Em 15-09-2018 14:36, Vladimir Vassilev escreveu:

Hi Herbert,


I fixed this issue and updated the package now uploaded on mentors.debian.net

Removed the netconf/src/yangdiff/Makefile target from configure.ac with new 
patch 0004-Removed-unused-autoconf-targets.patch

Updated debian/changelog.

Tested a second build in pbuild environment which now works.

Will do second build as part of my release routine from now on.



Cool!

Upload done. As there are new packages. Let's wait FTP-Master.

Thank you for the working done.



Regards,
Herbert

Bug#223988: ~/.fortunes

[Antoine Beaupre]

On Sat, Jul 06, 2013 at 04:46:32PM +0200, Andrea Colangelo wrote:
> I agree with you that adding custom fortunes in a simple way would be a nice
> addition to fortune-mod. OTOH, this should be done by upstream developers, who
> seems vanished, unfortunately.

Well, "upstream" is ... complicated here. fortune was written by Ken
Arnold in something like 1986, about thirty years ago, and didn't change
that much since then. It was part of the ancestral v7 Unix and from
there landed in the various BSDs. The one we have in Debian is
apparently from NetBSD, but I checked and the NetBSD one is actually
pretty similar to the FreeBSD one as well, just like DragonflyBSD.
OpenBSD actually went and audited the heck out of it. Here are the
canonical sources for all of those:

http://cvsweb.netbsd.org/bsdweb.cgi/src/games/fortune/fortune/fortune.c
https://svnweb.freebsd.org/base/head/usr.bin/fortune/fortune/fortune.c
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/games/fortune/fortune/fortune.c
https://gitweb.dragonflybsd.org/dragonfly.git/history/HEAD:/games/fortune/fortune/fortune.c

That said, it might be worth filing a feature request in the FreeBSD
bugtracker, as an upstream. They recently removed all fortune databases
from their source tree so this might actually be quite useful for them.

> Further, the whole way fortne-mod accesses the
> db and extracts fortunes should be deeply straightened up.

Well, that's a hornet's nest, if you ask me. You might break a lot of
things if you don't just add the thing and try to shuffle things around
instead.

Note that there are other fortune implementations out there which might
make implementing this feature much easier. Just one example, linked
(strangely) from wikipedia:

https://software.clapper.org/fortune/
https://github.com/bmc/fortune

There are about half a dozen of those on pypi, for what that's worth...
None of them support ~/.fortunes as far as I know. But many fortunes
program (including FreeBSD's, but not Net or OpenBSD's) allow
environment variables (e.g. FORTUNE_PATH) to modify the search path.

So if that would be acceptable for you, syncing with the FreeBSD
upstream would allow a variation of this to work with environment
variables.

A.

-- 
Dr. King’s major assumption was that if you are nonviolent, if you
suffer, your opponent will see your suffering and will be moved to
change his heart. He only made one fallacious assumption: In order for
nonviolence to work, your opponent must have a conscience. The United
States has none.- Stokely Carmichael


signature.asc
Description: PGP signature

Bug#908906: Please quote the value of INSTALL in description of compat level 11

[Josh Triplett]

Package: debhelper
Version: 11.4
Severity: normal
File: /usr/share/man/man7/debhelper.7.gz

The description for compat level 11 says:

> The makefile buildsystem now passes INSTALL=install --strip-program=true to 
> make(1).

Without quoting here, I first tried to look up a --strip-program option
to *make*, before I realized that this passes
INSTALL='install --strip-program=true' to make. Please include
appropriate quoting.

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  0.042-1
ii  dpkg 1.19.0.5+b1
ii  dpkg-dev 1.19.0.5
ii  dwz  0.12-2
ii  file 1:5.34-2
ii  libdpkg-perl 1.19.0.5
ii  man-db   2.8.4-2
ii  perl 5.26.2-7
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201801

-- no debconf information

Bug#908864: drascula: Incorrect version of the 'drascula.dat' engine data file found. Expected 5.0 but got 4.0.!

[Markus Koschany]

Control: tags -1 pending

On Sat, 15 Sep 2018 12:45:59 +0200 Reiner Herrmann 
wrote:
> In ScummVM 2.0.0 the version requirement of drascula has been bumped:
>   https://github.com/scummvm/scummvm/commit/327dcf9
> They also include an updated drascula.dat in this commit.
> I tested it, and by replacing this file I got it running again.
> 
> In the next ScummVM update there will be another version bump (6.0):
>   https://github.com/scummvm/scummvm/commit/59905ee
> (But the dat file from this commit can't be used with scummvm 2.0, as the
> versions have to match)

Thanks for reporting. Yes, that's unfortunate. Normally this is quite
rare because the game is complete but once in a while they find
something to improve. I'm going to upload the new drascula.dat file
(version 5.0).

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Russ Allbery]

Adding Colin as base-passwd maintainer.

Sean Whitton  writes:
> On Fri 10 Aug 2018 at 08:23AM +0200, Michael Biebl wrote:

>> Currently, DynamicUser gets a uid from within the following range:
>> 61184 - 65519. Those values can be configured during build time via
>> -Ddynamic-uid-min= and -Ddynamic-uid-max.

Those two numbers are oddly specific.  Is there some history behind those
specific boundaries?

>> The debian policy has a section about uids and gids:
>> https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes
>>
>> The overlapping ranges are:
>> 6-64999:
>>  Globally allocated by the Debian project, but only created on demand.
>>  The ids are allocated centrally and statically, but the actual accounts
>>  are only created on users’ systems on demand.
>>
>>  These ids are for packages which are obscure or which require many
>>  statically-allocated ids. These packages should check for and create the
>>  accounts in /etc/passwd or /etc/group (using adduser if it has this
>>  facility) if necessary. Packages which are likely to require further
>>  allocations should have a “hole” left after them in the allocation, to
>>  give them room to grow.

We have needed very few of these over the history of the project.  The
complete currently-allocated list from base-passwd is:

Reserved uids:
uid   | name  | description
--+---+---
63434 | netplan   | netplan
64000 | ftn   | fidogate
64001 | mysql | mysql-server
64005 | tac-plus  | tac-plus user
64010 | alias | qmail alias
64011 | qmaild| qmail daemon
64012 | qmails| qmail send
64013 | qmailr| qmail remove
64015 | qmailq| qmail queue
64016 | qmaill| qmail log
64017 | qmailp| qmail pw
64020 | asterisk  | asterisk
64025 | vpopmail  | vpopmail
64030 | slurm | slurm-llnl package
64035 | hacluster | heartbeat
64045 | ceph  | ceph object storage
64050 | opensrf   | Evergreen ILS
64055 | libvirt-qemu  | libvirt guest migration support
64060 | nova  | OpenStack Compute
64061 | cinder| OpenStack Block Storage
64062 | glance| OpenStack Image

Given that, maybe a solution would be to reserve a range in this space for
systemd dynamic users?

>> 65000-65533:
>>  Reserved.
>>
>> We don't meet the requirement of the 6-64999 range, which says that
>> the ids need to be allocated statically (DynamicUser generated ids are
>> ephemeral).  The 65000-65533 range doesn't go into more detail, what
>> purpose it is reserved.

> I don't know why it's reserved either, but ISTM this is rather too small
> a range for systemd's DynamicUser.  Would you agree?

I think this is reserved just because we've never had another use for it
and were being conservative.

>> There is also:
>> 65536-4294967293:
>>  Dynamically allocated user accounts. By default adduser will not
>>  allocate UIDs and GIDs in this range, to ease compatibility with legacy
>>  systems where uid_t is still 16 bits.
>>
>> I'm not sure if it would be more suitable to pick the DynamicUser ids
>> from this range.

> This strikes me as suitable.  We could either just change systemd's
> configuration, or allocate a section of that range to systemd.

We will definitely have conflicts with local allocations if we start using
UIDs from this space.  We theoretically say that this space is reserved,
but Debian currently doesn't provide anywhere *close* to enough space for
local UID allocation.  Any site that needs more than 50,000 UIDs (which is
extremely common) is almost certainly already using large chunks of this
space.  Both Stanford and Dropbox allocate UIDs from this space, for
instance -- Dropbox because it was convenient to separate from human
users, and Stanford because we couldn't create enough accounts for all of
our users without using this space.

This space is also often used for uidmap for containers.  It's typical to
have a single container user get a full 16-bit UID space that gets mapped
to an equivalent range somewhere in the >2^16 space of the containing
system.

-- 
Russ Allbery (r...@debian.org)   

Bug#869995: Still present in stretch versions, patch attached

[Michael Biebl]

On Sun, 11 Mar 2018 19:48:30 +0100 Marc Haber
 wrote:
> found #869995 232-25+deb9u1
> found #869995 232-25+deb9u2
> tags #869995 patch stretch
> thanks
> 
> Hi,
> 
> I have missed that this bug was actually closed for good. I can confirm
> that the issue is fixed in sid and buster, but is is still a crippling
> bug in stretch.
> 
> I can confirm that the two attached patches fix the issue in 232-25.

I can't find the patches you mentioned anywhere in the git log. This is
complicated by the fact that neither of the two patches has a proper git
patch header with author, description etc.

Without that information I can't consider those patches for a stable
release.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#908898: ublock-origin: debian/watch does not work correctly

[Sven Joachim]

Control: tags -1 + patch

On 2018-09-15 19:18 +0200, Sven Joachim wrote:

> On 2018-09-15 18:39 +0200, Sven Joachim wrote:
>
>> Source: ublock-origin
>> Version: 1.16.14+dfsg-2
>>
>> The regex used in debian/watch is too simplistic, upstream has made
>> releases for legacy Firefox versions which uscan prefers now:
>>
>> Obviously this is not what we want, since this is not the latest version
>> (and not even a valid version).  This particular problem should be easy
>> to fix,
>
> See the attached minimal patch.

Wow, I still managed to botch it. :-(

>> but versions like 1.16.21b7 and 1.16.21rc0 also need some
>> mangling to turn them into 1.16.21~b7 and 1.16.21~rc0, respectively.
>
> Looking at the list of tags, betas and release candidates always seem
> have an odd last number, while releases have an even one.  So maybe this
> is not really important after all, as the next stable upstream version
> will be 1.16.22 and not 1.16.21.

Moreover the upstream tarball is not used anyway, as there are files
lacking in it, which I found out after reading debian/README.source.
Following the recipe there I was able to actually make a local package
of ublock-origin 1.16.21rc0, although that involved more manual steps
than I would have liked.

Still, the watch file is useful for tracker.debian.org. 

> diff --git a/debian/watch b/debian/watch
> index c0a168727..49d51c087 100644
> --- a/debian/watch
> +++ b/debian/watch
> @@ -1,3 +1,3 @@
>  version=3
>  opts=repacksuffix=+dfsg,dversionmangle=s/\+(repack|dfsg|ds|deb)\d*$// \
> -https://github.com/gorhill/uBlock/releases .*/archive/(.*)\.tar\.gz
> +https://github.com/gorhill/uBlock/releases .*/archive/\d(.*)\.tar\.gz

Better use the attached version which does not eat the first digit of the
upstream version in ublock-origin_*.orig.tar.gz.

Cheers,
   Sven

diff --git a/debian/watch b/debian/watch
index c0a168727..78c3eba69 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,3 @@
 version=3
 opts=repacksuffix=+dfsg,dversionmangle=s/\+(repack|dfsg|ds|deb)\d*$// \
-https://github.com/gorhill/uBlock/releases .*/archive/(.*)\.tar\.gz
+https://github.com/gorhill/uBlock/releases .*/archive/(\d.*)\.tar\.gz

Bug#908905: Please remove moderation from debian-openst...@lists.debian.org

[Thomas Goirand]

Package: lists.debian.org
Severity: normal

Dear list-masters,

The list debian-openst...@lists.debian.org is currently moderated, but I
think this should go to a non-moderated list, because:
- The way to approve is very annoying (at least, the default should be to
approve the list, having to replace "DISCARD" by "APPROVE" is super
annoying).
- The spam filter is efficient, and therefore, it is my opinion that the
delay added by my moderation is not needed.

Thanks for your work maintaining Debian's lists,
Cheers,

Thomas Goirand (zigo)

Bug#908904: /usr/include/mgl2/config.h: error: unable to find numeric literal operator ‘operator""i’

[Marius Mikucionis]

Package: libmgl-dev
Version: 2.4.2.1-2
Severity: normal
File: /usr/include/mgl2/config.h

Dear Maintainer,

The package is unusable in the context "g++ -std=c++11" or newer (c++14, c++17).
The same issue is in bug report 800460, but it is archived.
Here is a sample program:

#include 
int main() {
mglGraph gr;
gr.FPlot("sin(pi*x)");
gr.WriteFrame("mgl_test.svg");
}

The compiler responds as follows:

In file included from /usr/include/mgl2/abstract.h:23,
 from /usr/include/mgl2/data_cf.h:23,
 from /usr/include/mgl2/data.h:23,
 from /usr/include/mgl2/mgl_cf.h:24,
 from /usr/include/mgl2/mgl.h:23,
 from tests.cpp:16:
/usr/include/mgl2/define.h:304:19: error: unable to find numeric literal 
operator ‘operator""i’
 const mdual mgl_I=_Complex_I;
   ^~
/usr/include/mgl2/define.h:304:19: note: add ‘using namespace 
std::complex_literals’ (from ) to enable the C++14 user-defined 
literal suffixes


I believe this is due to syntax clash between C99 and C++11
(C++14 introduces complex literals to support expressions like "1i").
libmgl-dev is trying to support both but C complex numbers do not make sense in 
C++ context.
I cannot see any userspace workaround other than downgrade my code to pre-C++11.

I propose to disable C complex numbers starting with C++11:

--- /usr/include/mgl2/config.h  2018-09-15 19:57:46.661432502 +0200
+++ /usr/include/mgl2/config.h.orig 2018-09-15 19:25:14.843095200 +0200
@@ -28,11 +28,7 @@
 #define MGL_HAVE_PTHREAD   1
 #define MGL_HAVE_PTHR_WIDGET   1
 #define MGL_HAVE_ATTRIBUTE 1
-#if defined(__cplusplus) && __cplusplus < 201103
 #define MGL_HAVE_C99_COMPLEX   1
-#else
-#define MGL_HAVE_C99_COMPLEX   0
-#endif
 #endif
 
 #define MGL_SIZEOF_LONG8


Marius

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

Kernel: Linux 4.18.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)
LSM: AppArmor: enabled

Versions of packages libmgl-dev depends on:
ii  libgl1-mesa-dev [libgl-dev]  18.1.7-1
ii  libgsl-dev   2.5+dfsg-5
ii  libmgl-fltk7.5.0 2.4.2.1-2
ii  libmgl-glut7.5.0 2.4.2.1-2
ii  libmgl-mpi7.5.0  2.4.2.1-2
ii  libmgl-qt5-7.5.0 2.4.2.1-2
ii  libmgl-wnd7.5.0  2.4.2.1-2
ii  libmgl-wx7.5.0   2.4.2.1-2
ii  libmgl7.5.0  2.4.2.1-2
ii  libpng-dev   1.6.34-2

libmgl-dev recommends no packages.

libmgl-dev suggests no packages.

-- no debconf information

Bug#908903: zonecheck unusable in buster/sid

[Santiago R.R.]

Package: zonecheck
Version: 3.0.5-3
Severity: grave

Dear Sebastien,

zonecheck in my sid environment is unusable. It ends up in ERROR when
e.g. checking debian.org:

/usr/lib/ruby/vendor_ruby/dnsruby.rb:413: warning: constant ::TimeoutError is 
deprecated
/usr/lib/ruby/vendor_ruby/Dnsruby/code_mapper.rb:110: warning: constant 
::Fixnum is deprecated
[… removing duplicated warnings]
ZONE  : debian.org
NS <= : dnsnode.debian.org [194.146.106.126, 2001:67C:1010:32::53]
NS: sec2.rcode0.net [176.97.158.100, 2001:67C:10B8::100]
NS: sec1.rcode0.net [192.174.68.100, 2001:67C:1BC::100]

/usr/share/zonecheck/test/connectivity.rb:128: warning: Object#timeout is 
deprecated, use Timeout.timeout instead.
[… removing duplicated warnings]
# terminated with exception (report_on_exception is true):
/usr/lib/ruby/vendor_ruby/Dnsruby/dnssec.rb:260:in `try_validation': comparison 
of Integer with Dnsruby::Message::SecurityLevel failed (ArgumentError)
from /usr/lib/ruby/vendor_ruby/Dnsruby/dnssec.rb:229:in 
`validate_with_query'
from /usr/lib/ruby/vendor_ruby/Dnsruby/validator_thread.rb:108:in 
`validate'
from /usr/lib/ruby/vendor_ruby/Dnsruby/validator_thread.rb:60:in 
`do_validate'
from /usr/lib/ruby/vendor_ruby/Dnsruby/validator_thread.rb:37:in `block 
in run'
ERROR: comparison of Integer with Dnsruby::Message::SecurityLevel failed


In stretch, I am getting the same Object#timeout warnings, but at least
it returns no error, and debian.org gets a SUCCESS :)

/usr/lib/ruby/vendor_ruby/dnsruby.rb:413: warning: constant ::TimeoutError is 
deprecated
ZONE  : debian.org
NS <= : dnsnode.debian.org [194.146.106.126, 2001:67C:1010:32::53]
NS: sec1.rcode0.net [192.174.68.100, 2001:67C:1BC::100]
NS: sec2.rcode0.net [176.97.158.100, 2001:67C:10B8::100]

/usr/share/zonecheck/test/connectivity.rb:128:in `chk_udp': Object#timeout is 
deprecated, use Timeout.timeout instead.
[… removing duplicated warnings]
   ___
 ,---.|
 |warning|| ~
 `---'
w> The 'refresh' period should be between 1H and 2D
 | Adv: default registry policy
 |   The registry requires the SOA fields to be inside a defined range:
 | the 'expire' should be between 1W and 6W, the 'minimum' between 3M and
 | 1W, the 'refresh' between 1H and 2D, and at last the 'retry' between
 | 15M and 1D.
 `- -- -- - -  -
 :   The refresh value is 30M and should be between 1H and 2D.
 `. .. .. . .  .
=> dnsnode.debian.org/2001:67C:1010:32::53
=> dnsnode.debian.org/194.146.106.126
=> sec1.rcode0.net/192.174.68.100
=> sec2.rcode0.net/176.97.158.100
=> sec2.rcode0.net/2001:67C:10B8::100
=> sec1.rcode0.net/2001:67C:1BC::100

w> The 'retry' period should be between 15M and 1D
 | Adv: default registry policy
 |   The registry requires the SOA fields to be inside a defined range:
 | the 'expire' should be between 1W and 6W, the 'minimum' between 3M and
 | 1W, the 'refresh' between 1H and 2D, and at last the 'retry' between
 | 15M and 1D.
 `- -- -- - -  -
 :   The retry value is 10M and should be between 15M and 1D.
 `. .. .. . .  .
=> dnsnode.debian.org/2001:67C:1010:32::53
=> dnsnode.debian.org/194.146.106.126
=> sec1.rcode0.net/192.174.68.100
=> sec2.rcode0.net/176.97.158.100
=> sec2.rcode0.net/2001:67C:10B8::100
=> sec1.rcode0.net/2001:67C:1BC::100

==> SUCCESS (but 12 warning(s))


JFTR, according to
https://www.nic.cz/public_media/IT15/prezentace/Patrik_Wallstrom.pdf
(slide 3), zonecheck (in ruby) is considered as old code. It has been
deprecated in favor of zonemaster (in perl), currently RFP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780184

Cheers,

 -- Santiago


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

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

Versions of packages zonecheck depends on:
ii  iputils-ping  3:20180629-2
ii  ruby  1:2.5.1
ii  ruby-dnsruby  1.54-2

Versions of packages zonecheck recommends:
pn  libopenssl-ruby  

zonecheck suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#908818: [Pkg-zsh-devel] Bug#908818: Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)

[TS]

--  --

> Could you please send a bug report upstream (zsh-work...@zsh.org)?
> Ideally, the bug report would include a reproduction script that sets up
> a new temporary directory, creates a minimal zshrc in it, and runs
> 'ZDOTDIR=/path/to/dir zsh -d' and provokes the bug.
> 
> Thanks!
> 
> Daniel

done.

zsh-workers 43468
http://www.zsh.org/mla/workers/2018/msg01272.html


kind regards,

 Thilo

Bug#906877: RFS: yuma123/2.11-1

[Vladimir Vassilev]

Hi Herbert,


I fixed this issue and updated the package now uploaded on 
mentors.debian.net


Removed the netconf/src/yangdiff/Makefile target from configure.ac with 
new patch 0004-Removed-unused-autoconf-targets.patch


Updated debian/changelog.

Tested a second build in pbuild environment which now works.

Will do second build as part of my release routine from now on.


Regards,

Vladimir


On 09/15/2018 02:11 PM, Herbert Fortes wrote:

Hi Vladimir Vassilev,

> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "yuma123"

The package does not build twice because the generated
netconf/src/yangdiff/Makefile file.

Please add the file to dh_clean's routine. A debian/clean
file with 'netconf/src/yangdiff/Makefile' solves the
issue.



Regards,
Herbert

>
> * Package name    : yuma123
>   Version : 2.11-1
>   Upstream Author : Vladimir Vassilev 
> * URL :https://sourceforge.net/projects/yuma123
> * License : BSD
>   Section : net
>
> It builds those binary packages:
>
> libyangrpc-dev - NETCONF/YANG development files
> libyangrpc2 - NETCONF/YANG library for simple manager clients
> libyuma-base - Configuration script, YANG models and documentation
> libyuma-dev - NETCONF/YANG development files
> libyuma2 - NETCONF/YANG library
> netconfd - NETCONF (RFC-6241) agent
> netconfd-module-ietf-interfaces - SIL module for netconfd implementing
> ietf-interfaces.yang
> netconfd-module-ietf-system - SIL module for netconfd implementing
> ietf-system.yang
> yangcli - NETCONF/YANG command line client application
> yangdump - Validate YANG modules and convert them to different formats
>
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/yuma123
>
> Alternatively, one can download the package with dget using this 
command:

>
>     dget -x
> 
https://mentors.debian.net/debian/pool/main/y/yuma123/yuma123_2.11-1.dsc

>
> More information about yuma123 can be obtained
> fromhttp://yuma123.org/wiki   .
>
> Changes since the last upload:
>
> * New upstream release
>
> Regards,
> Vladimir Vassilev
>
>
>

Bug#908902: mercurial: hg commit -m 'my updates' (goes awry due to space in message)

[Steve Newcomb]

Package: mercurial
Version: 4.7.1-1
Severity: important

Dear Maintainer,

The bash command line:
% hg commit -m 'my updates'

results in:
abort: 2017_original/180914_updates/updates: No such file or directory

... which is true, there is no such file or directory.  However, I wasn't trying to 
commit any such file.  I was trying to do a general commit with the commit message 
"my updates".

It worked as expected only when I removed the space from the message:
% hg commit -m 'my_updates'.




-- 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.17.0-3-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mercurial depends on:
ii  libc6 2.27-6
ii  mercurial-common  4.7.1-1
ii  python2.7.15-3
ii  ucf   3.0038

Versions of packages mercurial recommends:
ii  openssh-client  1:7.8p1-1

Versions of packages mercurial suggests:
pn  kdiff3 | kdiff3-qt | kompare | meld | tkcvs | mgdiff  
pn  qct   

-- no debconf information

Bug#908463: [Pkg-privacy-maintainers] Bug#908463: torbrowser-launcher: Fails to start "Web Content" processes due to outdated AppArmor policy

[gregor herrmann]

On Sat, 15 Sep 2018 11:01:39 +0900, Roger Shimizu wrote:

> > After upgrading to 0.2.9-4, adequate complains:
> >
> > torbrowser-launcher: obsolete-conffile 
> > /etc/apparmor.d/local/torbrowser.Tor.tor
> > torbrowser-launcher: obsolete-conffile 
> > /etc/apparmor.d/local/torbrowser.Browser.plugin-container
> > torbrowser-launcher: obsolete-conffile 
> > /etc/apparmor.d/local/torbrowser.Browser.firefox
> 
> Sorry, I don't have these errors when upgrading package.
> 
> 
> # dpkg -i torbrowser-launcher_0.2.9-4_amd64.deb
> (Reading database ... 272719 files and directories currently installed.)
> Preparing to unpack torbrowser-launcher_0.2.9-4_amd64.deb ...
> Unpacking torbrowser-launcher (0.2.9-4) over (0.2.9-3) ...
> Setting up torbrowser-launcher (0.2.9-4) ...
> Installing new version of config file
> /etc/apparmor.d/torbrowser.Browser.firefox ...
> Processing triggers for desktop-file-utils (0.23-1) ...
> Processing triggers for mime-support (3.60) ...
> Processing triggers for man-db (2.7.6.1-2) ...
> 
> 
> > After getting rid of them, I have a starting torbrowser again.
> >
> > Looks like some dpkg-maintscript-helper(1) magic is needed here ...
> 
> Could you provide an example, or even patch?
> Thanks!

After looking at the package/repo:

The files under /etc/apparmor.d/local were created in 0.2.9-1 (with
the upstream import) and were removed in 0.2.9-2, probably with
0016-Remove-apparmor-local-path-from-setup.py.patch. Or maybe with
debian/patches/0015-AppArmor-remove-boilerplate-from-local-override-file.patch.
Or with both :)

This is somewhat confusing but 0.2.9-1 seems to be the only release
with

drwxr-xr-x root/root 0 2018-01-29 15:17 ./etc/apparmor.d/local/
-rw-r--r-- root/root   134 2018-01-28 19:33 
./etc/apparmor.d/local/torbrowser.Browser.firefox
-rw-r--r-- root/root   133 2018-01-28 19:33 
./etc/apparmor.d/local/torbrowser.Browser.plugin-container
-rw-r--r-- root/root   133 2018-01-28 19:33 
./etc/apparmor.d/local/torbrowser.Tor.tor

(That also means that adequate must have warned me earlier?)

Anyway, these conffiles are not shipped any more; either that's a
mistake or they need to be properly removed.

There is already debian/torbrowser-launcher.maintscript which IMO
needs three new lines:

rm_conffile /etc/apparmor.d/local/torbrowser.Tor.tor 0.2.9-2~ 
torbrowser-launcher
rm_conffile /etc/apparmor.d/local/torbrowser.Browser.plugin-container 0.2.9-2~ 
torbrowser-launcher
rm_conffile /etc/apparmor.d/local/torbrowser.Browser.firefox 0.2.9-2~ 
torbrowser-launcher

Or maybe s/0.2.9-2~/0.2.9-5~/ , if I'm reading dpkg-maintscript-helper(1)
correctly.

HTH,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Peter Jones: Hooked onto your love


signature.asc
Description: Digital Signature

Bug#853310: android-platform-system-core: ftbfs with GCC-7

[殷啟聰 | Kai-Chung Yan]

> Anyway, I sponsored this upload targetting experimental.

Thank you for the sponsor. I am surprised it got cleared in the queue so 
quickly.

There's a FTFBS on MIPS, I think I can handle it.



signature.asc
Description: OpenPGP digital signature

Bug#908898: ublock-origin: debian/watch does not work correctly

[Sven Joachim]

On 2018-09-15 18:39 +0200, Sven Joachim wrote:

> Source: ublock-origin
> Version: 1.16.14+dfsg-2
>
> The regex used in debian/watch is too simplistic, upstream has made
> releases for legacy Firefox versions which uscan prefers now:
>
> ,
> | $ uscan --verbose
> | uscan info: uscan (version 2.18.4) See uscan(1) for help
> | uscan info: Scan watch files in .
> | uscan info: Check debian/watch and debian/changelog in .
> | uscan info: package="ublock-origin" version="1.16.14+dfsg-2" (as seen in 
> debian/changelog)
> | uscan info: package="ublock-origin" version="1.16.14+dfsg" (no 
> epoch/revision)
> | uscan info: ./debian/changelog sets package="ublock-origin" 
> version="1.16.14+dfsg"
> | uscan info: Process watch file at: debian/watch
> | package = ublock-origin
> | version = 1.16.14+dfsg
> | pkg_dir = .
> | uscan info: opts: 
> repacksuffix=+dfsg,dversionmangle=s/\+(repack|dfsg|ds|deb)\d*$//
> | uscan info: line: https://github.com/gorhill/uBlock/releases 
> .*/archive/(.*)\.tar\.gz
> | uscan info: Parsing repacksuffix=+dfsg
> | uscan info: Parsing dversionmangle=s/\+(repack|dfsg|ds|deb)\d*$//
> | uscan info: line: https://github.com/gorhill/uBlock/releases 
> .*/archive/(.*)\.tar\.gz
> | uscan info: Last orig.tar.* tarball version (from debian/changelog): 
> 1.16.14+dfsg
> | uscan info: Last orig.tar.* tarball version (dversionmangled): 1.16.14
> | uscan info: Requesting URL:
> |https://github.com/gorhill/uBlock/releases
> | uscan info: Matching pattern:
> |
> (?:(?:https://github.com)?\/gorhill\/uBlock\/releases)?.*/archive/(.*)\.tar\.gz
> | uscan info: Found the following matching hrefs on the web page (newest 
> first):
> |/gorhill/uBlock/archive/firefox-legacy-1.16.4.4.tar.gz 
> (firefox-legacy-1.16.4.4) index=firefox-legacy-1.16.4.4-1 
> |/gorhill/uBlock/archive/firefox-legacy-1.16.4.3.tar.gz 
> (firefox-legacy-1.16.4.3) index=firefox-legacy-1.16.4.3-1 
> |/gorhill/uBlock/archive/firefox-legacy-1.16.4.2.tar.gz 
> (firefox-legacy-1.16.4.2) index=firefox-legacy-1.16.4.2-1 
> |/gorhill/uBlock/archive/1.16.21rc0.tar.gz (1.16.21rc0) 
> index=1.16.21rc0-1 
> |/gorhill/uBlock/archive/1.16.21b7.tar.gz (1.16.21b7) index=1.16.21b7-1 
> |/gorhill/uBlock/archive/1.16.20.tar.gz (1.16.20) index=1.16.20-1 
> |/gorhill/uBlock/archive/1.16.18.tar.gz (1.16.18) index=1.16.18-1 
> |/gorhill/uBlock/archive/1.16.16.tar.gz (1.16.16) index=1.16.16-1 
> |/gorhill/uBlock/archive/1.16.14.tar.gz (1.16.14) index=1.16.14-1 
> |/gorhill/uBlock/archive/1.16.12.tar.gz (1.16.12) index=1.16.12-1 
> | uscan info: Looking at $base = https://github.com/gorhill/uBlock/releases 
> with
> | $filepattern = .*/archive/(.*)\.tar\.gz found
> | $newfile = /gorhill/uBlock/archive/firefox-legacy-1.16.4.4.tar.gz
> | $newversion  = firefox-legacy-1.16.4.4 which is newer than
> | $lastversion = 1.16.14+dfsg
> | uscan info: Matching target for downloadurlmangle: 
> https://github.com/gorhill/uBlock/archive/firefox-legacy-1.16.4.4.tar.gz
> | uscan info: Upstream URL(+tag) to download is identified as
> https://github.com/gorhill/uBlock/archive/firefox-legacy-1.16.4.4.tar.gz
> | uscan info: Filename (filenamemangled) for downloaded file: 
> firefox-legacy-1.16.4.4.tar.gz
> | uscan: Newest version of ublock-origin on remote site is 
> firefox-legacy-1.16.4.4, local version is 1.16.14+dfsg
> |  (mangled local version is 1.16.14)
> | uscan:=> Newer package available from
> |   
> https://github.com/gorhill/uBlock/archive/firefox-legacy-1.16.4.4.tar.gz
> `
>
> Obviously this is not what we want, since this is not the latest version
> (and not even a valid version).  This particular problem should be easy
> to fix,

See the attached minimal patch.

> but versions like 1.16.21b7 and 1.16.21rc0 also need some
> mangling to turn them into 1.16.21~b7 and 1.16.21~rc0, respectively.

Looking at the list of tags, betas and release candidates always seem
have an odd last number, while releases have an even one.  So maybe this
is not really important after all, as the next stable upstream version
will be 1.16.22 and not 1.16.21.

Cheers,
   Sven

diff --git a/debian/watch b/debian/watch
index c0a168727..49d51c087 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,3 @@
 version=3
 opts=repacksuffix=+dfsg,dversionmangle=s/\+(repack|dfsg|ds|deb)\d*$// \
-https://github.com/gorhill/uBlock/releases .*/archive/(.*)\.tar\.gz
+https://github.com/gorhill/uBlock/releases .*/archive/\d(.*)\.tar\.gz

Bug#908897: filesystem location of the *.vbox-extpack file

[Daniel Baumann]

On 09/15/2018 06:34 PM, Daniel Baumann wrote:
>   .. move from /usr/share/virtualbox-ext-pack to
>  /var/cache/virtualbox-ext-pack?
> 
>   .. give precedence and use files in /usr/share/virtualbox-ext-pack
>  over /var/cache/virtualbox-ext-pack?

and for the sake of completness: in order to make installation of
extensions with the virtualbox extension-manager installable while
having a read-only /usr..

.. /usr/lib/virtualbox/ExtensionPacks would need to be replaced with
   a symlink pointing to e.g. /var/lib/virtualbox/ExtensionPacks

.. shipped extensions by the package (currently one 'VNC'), would be
   stored in e.g. /usr/lib/virtualbox/extensions, and symlinked to
   /var/lib/virtualbox/ExtensionPacks during postinst

for an example that I use in production doing above, see the relevant
files..

  * matomo, the "main" package:


https://sources.progress-linux.org/distributions/dschinn-backports-extras/packages/matomo/tree/debian/rules

https://sources.progress-linux.org/distributions/dschinn-backports-extras/packages/matomo/tree/debian/matomo.postinst

https://sources.progress-linux.org/distributions/dschinn-backports-extras/packages/matomo/tree/debian/matomo.postrm

  * matomo-plugin-loginldap, an extension for matomo:


https://sources.progress-linux.org/distributions/dschinn-backports-extras/packages/matomo-plugin-loginldap/tree/debian/rules?h=progress-linux

https://sources.progress-linux.org/distributions/dschinn-backports-extras/packages/matomo-plugin-loginldap/tree/debian/matomo-plugin-loginldap.postinst?h=progress-linux

Regards,
Daniel

Bug#908901: miniupnpd: French debconf translation

[Baptiste Jammet]

Package: miniupnpd
Version: N/A
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the french translation for debconf templates, 
proofread by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
# French po-debconf translation for miniupnpd
# Copyright (C) 2013
# This file is distributed under the same license as the miniupnpd package.
#
# Baptiste Jammet , 2013, 2018.
msgid ""
msgstr ""
"Project-Id-Version: miniupnpd\n"
"Report-Msgid-Bugs-To: miniup...@packages.debian.org\n"
"POT-Creation-Date: 2018-05-24 00:00+0800\n"
"PO-Revision-Date: 2018-08-28 21:38+0100\n"
"Last-Translator: Baptiste Jammet \n"
"Language-Team: French \n"
"Language: french\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: boolean
#. Description
#: ../miniupnpd.templates:2001
msgid "Start the MiniUPnP daemon automatically?"
msgstr "Faut-il démarrer le démon MiniUPnP automatiquement ?"

#. Type: boolean
#. Description
#: ../miniupnpd.templates:2001
msgid ""
"Choose this option if the MiniUPnP daemon should start automatically, now "
"and at boot time."
msgstr ""
"Choisissez cette option si vous voulez que le démon MiniUPnP démarre "
"automatiquement, maintenant et à chaque démarrage du système."

#. Type: string
#. Description
#: ../miniupnpd.templates:3001
#| msgid "LAN IP address to listen on for UPnP queries:"
msgid "Interfaces to listen on for UPnP queries:"
msgstr "Interfaces à écouter pour les requêtes UPnP :"

#. Type: string
#. Description
#: ../miniupnpd.templates:3001
#| msgid ""
#| "The MiniUPnP daemon will listen for requests on the local network. Please "
#| "enter the IP address it should listen on."
msgid ""
"The MiniUPnP daemon will listen for requests on the local network. Please "
"enter the interfaces or IP addresses it should listen on, separated by space."
msgstr ""
"Le démon MiniUPnP sera à l'écoute de requêtes sur le réseau local. Veuillez "
"indiquer les interfaces ou les adresses IP, séparées par des espaces, sur "
"lesquelles il écoutera."

#. Type: string
#. Description
#: ../miniupnpd.templates:3001
msgid ""
"Interface names are preferred, and required if you plan to enable IPv6 port "
"forwarding."
msgstr ""
"Il est préférable d'indiquer le nom des interfaces. Cela est même requis si "
"vous projetez d'activer la redirection de port IPv6."

#. Type: string
#. Description
#: ../miniupnpd.templates:4001
msgid "External WAN network interface to open ports on:"
msgstr "Interface réseau WAN sur laquelle il faut ouvrir des ports :"

#. Type: string
#. Description
#: ../miniupnpd.templates:4001
msgid ""
"The MiniUPnP daemon will listen on a specific IP address on the local "
"network, then open ports on the WAN interface. Please enter the name of the "
"WAN network interface on which the MiniUPnP daemon should perform port "
"forwarding."
msgstr ""
"Le démon MiniUPnP écoutera sur une adresse IP spécifique du réseau local, "
"puis ouvrira certains ports sur l'interface WAN. Veuillez indiquer le nom de "
"l'interface de réseau WAN sur laquelle le démon MiniUPnP mettra en place des "
"redirections de ports."

#. Type: boolean
#. Description
#: ../miniupnpd.templates:5001
msgid "Enable IPv6 firewall chain?"
msgstr "Faut-il activer la chaîne de pare-feu IPv6 ?"

#. Type: boolean
#. Description
#: ../miniupnpd.templates:5001
msgid ""
"Please specify whether the MiniUPnP daemon should run its ip6tables script "
"on startup to initialize the IPv6 firewall chain."
msgstr ""
"Veuillez indiquer si le démon MiniUPnP doit exécuter ses scripts ip6tables "
"au démarrage pour initialiser la chaîne de pare-feu IPv6."

#. Type: boolean
#. Description
#: ../miniupnpd.templates:5001
msgid ""
"Note: This option is useless if you don't block any IPv6 forwarded traffic."
msgstr ""
"Note : cette option est inutile si la redirection de trafic IPv6 n'est pas "
"bloquée."

Bug#868686: proper fix proposed and workaround described

[Barak A. Pearlmutter]

The relevant RFC is here: https://www.ietf.org/rfc/rfc3261.txt

>  SIP URIs [have] a similar form to an email address, typically containing a 
> username and a host name.  In this case, it is sip:b...@biloxi.com, where 
> biloxi.com is the domain

So in the URI sip:b...@biloxi.com, the username is "bob".

This report refers to a "username" as the email address used for
creating the account. If the username itself contains an "@"
character, it would have to be escaped, according to the RFC:

> For each component, the set of valid BNF expansions defines exactly which 
> characters may appear unescaped.  All other characters MUST be escaped.

> For example, "@" is not in the set of characters in the user component, so 
> the user "j@s0n" must have at least the @ sign encoded, as in "j%40s0n".

So to answer this question:

> Given that SIP account names can not contain at signs, what do you suggest 
> the program do when such username is entered?

The answer is: escape it as "%40". But in the meantime, this issue can
be worked around by manually giving the username with the @ escaped in
this fashion.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Tollef Fog Heen 

> ]] Sean Whitton 
> 
> > The concrete question that I am asking the committee to decide, in my
> > capacity as a Policy delegate, is whether or not vendor-specific patch
> > series should be permitted in the Debian archive.
> 
> It's now been five days since I mailed the various package
> maintainers. I intend to write up a resolution and then call for a vote
> in the not-too-distant future, so if there is anything we have not
> covered in the discussion so far, please chime in sooner rather than
> later

That turned out to be in the rather more distant future than I
intended.  Apologies about that.

A first draft is below, feedback on wording and content appreciated.

=== DRAFT Resolution ===

Vendor-specific patch series are a feature of dpkg that can be used to
apply a different series of quilt patches when the source package is
unpacked on different systems.  Since Debian source packages are usually
treated as a pure transport format (like tar), this property can cause
confusion and frustration for users.  Examples could be if only the
series file for one vendor is updated, or a source package is unpacked
on one system and then transferred to a system with a different vendor
for debugging.

The Committee recognises that there is a need for packages to behave
differently when built on different distributions, but this should be
done as part of the build process, using current and future practices
such as patches with conditional behaviour, patching of files during the
build, rather than at source unpacking time.

Since this feature is used by several packages today, we need a
reasonable transition period.  They will be considered buggy from when
this resolution is accepted, but it will not be considered severe enough
to warrant immediate removal from Debian.  After Buster is released, use
of a vender-specific patch series will be a violation of a MUST
directive in Debian policy.

The Committee therefore resolves that:

1. Any use of dpkg's vendor-specific patch series feature is a bug for
   packages in the Debian archive (including contrib and non-free).

   This should be implemented in Debian Policy by declaring that a a
   package SHOULD NOT contain a non-default series file.

2. After Buster is released, use of the vendor-specific patch series
   feature is forbidden in the Debian archive.

   This should be implemented in Debian Policy by declaring that a a
   package MUST NOT contain a non-default series file.

=== End DRAFT Resolution ===

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#908900: diffoscope: tests fail with colord 1.4.3

[Chris Lamb]

Package: diffoscope
Version: 101
Severity: important

Since the upload of colord 1.4.3, the diffoscope testsuite fails with:


  === FAILURES 
===
  __ test_diff 
___
  
  differences = []
  
  @skip_unless_tools_exist('cd-iccdump')
  def test_diff(differences):
  if 'ne_SU' in differences[0].unified_diff:
  pytest.skip("Endian-specific differences detected; see "
  "")
  
  expected_diff = get_data('icc_expected_diff')
  >   assert differences[0].unified_diff == expected_diff
  E   AssertionError: assert '@@ -1,20 +1,...4 bytes]\n \n' == '@@ -1,20 
+1,2... [24 bytes]\n'
  E   @@ -1,20 +1,20 @@
  Eicc:
  EHeader:
  E  Size   = 14684 bytes
  E  Version= 4.3
  E  Profile Kind   = display-device
  E  Colorspace = rgb
  E  Conn. Space= xyz
  E   -  Date, Time = 2016-02-15, 21:02:09
  E   +  Date, Time = 2016-02-15, 21:03:22
  E  Flags  = Not embedded profile, Use anywhere
  E  Dev. Attrbts   = reflective, glossy
  E  Rndrng Intnt   = perceptual
  E  Creator= lcms
  E - -  Profile ID = 0477fa4bb5ae5ae9a778f5cd72eb45a4
  E - +  Profile ID = 06017f17ec507191e9d859f2324fca53
  E + -  Profile ID = 0x0477fa4b
  E + +  Profile ID = 0x06017f17
  E +  
  Etag 00:
  E  sig'desc' [0x64657363]
  E  size   38
  E  type   'mluc' [0x6d6c7563]
  EText:
  E  en_US: sRGB [24 bytes]
  E -
  

We would normally:

 1. Update the expected diff for this latest version.

 2. Add a minimum version check directive for pytest.

However, the `cd-iccdump` command has no --version command and, whilst
the `colord` binary does, it relies on the daemon running to return any
output.


Regards,

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

Bug#908818: [Pkg-zsh-devel] Bug#908818: Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)

[TS]

--  --

> I can't reproduce the bug with a zshrc that contains nothing but an
> (unconditional) zmodload zsh/zprof.  I'm using a self-compiled
> static build from upstream git, not a package build.
> 
> Could you please send a bug report upstream (zsh-work...@zsh.org)?
> Ideally, the bug report would include a reproduction script that sets up
> a new temporary directory, creates a minimal zshrc in it, and runs
> 'ZDOTDIR=/path/to/dir zsh -d' and provokes the bug.
> 
> Thanks!
> 
> Daniel
> 

Hello shortest testcase i can come with atteched. Will send it upstream, too.

with 5.6.2:

% su -l heinb
Password:
tosh% exec zsh
zsh: suspended (tty output)
tosh% fg
[2]  + continued
num  callstime   selfname
---
tosh%



with 5.5.1:

% su -l heinb
Password:
tosh% exec zsh
num  callstime   selfname
---
tosh%



kind regards,

 Thilo

builtin zmodload zsh/zprof
lessx() {
less --quit-if-one-screen --chop-long-lines -X "${@}"
}
READNULLCMD='lessx'
zprof |& lessx

Bug#908555: pydicom dependencies

[Darcy Mason]

Hi, I came across this bug report and wanted to clarify -- gdcm is only an
optional dependency for pydicom, although perhaps it has been set up
differently here depending on how it is being used.

Bug#908899: reduce installation size

[Daniel Baumann]

Package: virtualbox-ext-pack
Severity: wishlist

Hi,

thank you for maintaining virtual-ext-pack in Debian.

I have a few suggestions on how to improve the user experience but
before sending patches, I would like to ask your opinon on it.


1. keeping vbox-ext files
-

currently virtualbox-ext-pack downloads the ext-pack file, installs it,
and keeps the downloaded file saved in /usr/share/virtualbox-ext-pack
(~19MB).

imho, packages that download stuff should treat any downloaded files as
'temporary' files, i.e. they should download, install, and remove any
afterwards unsed files to not increase runtime-diskusage unecessary. on
a dpkg-reconfigure, the package should just re-download the necessary files.

would you accept a patch(es) to..

  .. remove the ext-pack file after successfull installation of the
 extension?

  .. if not, would you agree having a debconf question to make it
 conditional (so that users get asked, if they want to keep it
 which would then default to 'yes')?


2. contents of the ext-pack extension
-

the virtualbox-ext-pack extension currently contains binaries for linux
(amd64, i386), macosx (amd64), solaris (amd64), and windows (amd64,
i386). the extension is only usable together with virtualbox, i.e.
virtualbox uses only the ext-pack parts for the operating system and
architecture it is running on (regardless what guest operating
systems/architectures are used).

on linux (amd64), removing the other-os/arch files saves 35MB (53MB
total size, 18MB amd64 binaries).

ever since the introduction of extensions in virtualbox, these files are
simply gzip compressed tarballs without any cryptographic signature,
only containing a simple manifest (md5/sha256/sha512 checksums).

would you accept a patch(es) to..

  .. removing all unecessary other-os/arch files after installation
 of the extension?

 as a datapoint wrt/ to the extension meta-data: i'm doing this in
 my unofficial package for years and never had any problems since
 the meta-data in the extension never changed (and if it would,
 it could be easily adapted), see:


https://sources.progress-linux.org/distributions/dschinn-backports-extras/packages/virtualbox-extension-pack/tree/debian/rules

  .. if not, would you agree having a debconf question to make it
 conditional (so that users get asked to multiselect which
 other-os/arch files they want to keep which would then default to
 all of them)?


Implementing 1. and 2. would decrease the installation size on e.g.
linux/amd64 from 72MB to 18MB, saving 54MB of disk space.

Regards,
Daniel

Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Simon McVittie]

On Sat, 15 Sep 2018 at 08:47:19 -0700, Sean Whitton wrote:
> On Fri 10 Aug 2018 at 08:23AM +0200, Michael Biebl wrote:
> > There is also:
> > 65536-4294967293:
> >  Dynamically allocated user accounts. By default adduser will not
> >  allocate UIDs and GIDs in this range, to ease compatibility with legacy
> >  systems where uid_t is still 16 bits.
> >
> > I'm not sure if it would be more suitable to pick the DynamicUser ids
> > from this range.
> 
> This strikes me as suitable.  We could either just change systemd's
> configuration, or allocate a section of that range to systemd.

Beware that if systemd dynamic users are above the 16-bit boundary, then
they won't work well with systemd-nspawn and other container systems that
give a 16-bit uid range to each container (mapping uids N+0 to N+65535
in the top-level uid namespace to uids 0 to 65535 in the container's
uid namespace, where N is large; so when systemd inside the container
thinks it's allocating uid 64923 to a service, it's really uid N+64923
in the top-level init namespace). That's a useful technique because
it assigns a unique uid to each process that ought to be protected from
other processes, which protects both the host system and other containers
from a compromised container.

smcv

Bug#908898: ublock-origin: debian/watch does not work correctly

[Sven Joachim]

Source: ublock-origin
Version: 1.16.14+dfsg-2

The regex used in debian/watch is too simplistic, upstream has made
releases for legacy Firefox versions which uscan prefers now:

,
| $ uscan --verbose
| uscan info: uscan (version 2.18.4) See uscan(1) for help
| uscan info: Scan watch files in .
| uscan info: Check debian/watch and debian/changelog in .
| uscan info: package="ublock-origin" version="1.16.14+dfsg-2" (as seen in 
debian/changelog)
| uscan info: package="ublock-origin" version="1.16.14+dfsg" (no epoch/revision)
| uscan info: ./debian/changelog sets package="ublock-origin" 
version="1.16.14+dfsg"
| uscan info: Process watch file at: debian/watch
| package = ublock-origin
| version = 1.16.14+dfsg
| pkg_dir = .
| uscan info: opts: 
repacksuffix=+dfsg,dversionmangle=s/\+(repack|dfsg|ds|deb)\d*$//
| uscan info: line: https://github.com/gorhill/uBlock/releases 
.*/archive/(.*)\.tar\.gz
| uscan info: Parsing repacksuffix=+dfsg
| uscan info: Parsing dversionmangle=s/\+(repack|dfsg|ds|deb)\d*$//
| uscan info: line: https://github.com/gorhill/uBlock/releases 
.*/archive/(.*)\.tar\.gz
| uscan info: Last orig.tar.* tarball version (from debian/changelog): 
1.16.14+dfsg
| uscan info: Last orig.tar.* tarball version (dversionmangled): 1.16.14
| uscan info: Requesting URL:
|https://github.com/gorhill/uBlock/releases
| uscan info: Matching pattern:
|
(?:(?:https://github.com)?\/gorhill\/uBlock\/releases)?.*/archive/(.*)\.tar\.gz
| uscan info: Found the following matching hrefs on the web page (newest first):
|/gorhill/uBlock/archive/firefox-legacy-1.16.4.4.tar.gz 
(firefox-legacy-1.16.4.4) index=firefox-legacy-1.16.4.4-1 
|/gorhill/uBlock/archive/firefox-legacy-1.16.4.3.tar.gz 
(firefox-legacy-1.16.4.3) index=firefox-legacy-1.16.4.3-1 
|/gorhill/uBlock/archive/firefox-legacy-1.16.4.2.tar.gz 
(firefox-legacy-1.16.4.2) index=firefox-legacy-1.16.4.2-1 
|/gorhill/uBlock/archive/1.16.21rc0.tar.gz (1.16.21rc0) index=1.16.21rc0-1 
|/gorhill/uBlock/archive/1.16.21b7.tar.gz (1.16.21b7) index=1.16.21b7-1 
|/gorhill/uBlock/archive/1.16.20.tar.gz (1.16.20) index=1.16.20-1 
|/gorhill/uBlock/archive/1.16.18.tar.gz (1.16.18) index=1.16.18-1 
|/gorhill/uBlock/archive/1.16.16.tar.gz (1.16.16) index=1.16.16-1 
|/gorhill/uBlock/archive/1.16.14.tar.gz (1.16.14) index=1.16.14-1 
|/gorhill/uBlock/archive/1.16.12.tar.gz (1.16.12) index=1.16.12-1 
| uscan info: Looking at $base = https://github.com/gorhill/uBlock/releases with
| $filepattern = .*/archive/(.*)\.tar\.gz found
| $newfile = /gorhill/uBlock/archive/firefox-legacy-1.16.4.4.tar.gz
| $newversion  = firefox-legacy-1.16.4.4 which is newer than
| $lastversion = 1.16.14+dfsg
| uscan info: Matching target for downloadurlmangle: 
https://github.com/gorhill/uBlock/archive/firefox-legacy-1.16.4.4.tar.gz
| uscan info: Upstream URL(+tag) to download is identified as
https://github.com/gorhill/uBlock/archive/firefox-legacy-1.16.4.4.tar.gz
| uscan info: Filename (filenamemangled) for downloaded file: 
firefox-legacy-1.16.4.4.tar.gz
| uscan: Newest version of ublock-origin on remote site is 
firefox-legacy-1.16.4.4, local version is 1.16.14+dfsg
|  (mangled local version is 1.16.14)
| uscan:=> Newer package available from
|   https://github.com/gorhill/uBlock/archive/firefox-legacy-1.16.4.4.tar.gz
`

Obviously this is not what we want, since this is not the latest version
(and not even a valid version).  This particular problem should be easy
to fix, but versions like 1.16.21b7 and 1.16.21rc0 also need some
mangling to turn them into 1.16.21~b7 and 1.16.21~rc0, respectively.

Bug#908897: filesystem location of the *.vbox-extpack file

[Daniel Baumann]

Package: virtualbox-ext-pack
Severity: wishlist

Hi,

thank you for maintaining virtual-ext-pack in Debian.

I have a few suggestions on how to improve the user experience but
before sending patches, I would like to ask your opinon on it.


files that get downloaded should be placed in /var (I suggest
/var/cache/virtualbox-ext-pack) rather than the current
/usr/share/virtualbox-ext-pack. IIRC debian's /usr is (still) supposed
to be usable read-only.

even better would be if the package would only download to /var/cache if
the correct file is not present in /usr/share already. that way, on
systems with a shared read-only /usr (such as netbooted live systems),
the sysadmin can deploy the file presistently "pre-downloaded" in
/usr/share (and have users "install" it in demand by accepting the
license prior use).

would you accept a patch(es) to..

  .. move from /usr/share/virtualbox-ext-pack to
 /var/cache/virtualbox-ext-pack?

  .. give precedence and use files in /usr/share/virtualbox-ext-pack
 over /var/cache/virtualbox-ext-pack?

Regards,
Daniel

Bug#908831: linux-image-4.18.0-1-amd64: After upgrade from kernel 4.17 to 4.18 virt-manager dosent work

[Ben Hutchings]

On Fri, 2018-09-14 at 18:01 +0100, José Gramaxo wrote:
> Package: src:linux
> Version: 4.18.6-1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> Upgrade kernel from 4.17 to 4.18
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Downgrade kernel to 4.17 or 4.16
>* What was the outcome of this action?
> virt-manager works
>* What outcome did you expect instead?
[...]

I hit this problem too.  The current versions of virt-manager, libvirt,
etc. in unstable do work.  But I recognise that this is still a kernel
bug that needs to be fixed (particularly for stretch-backports).

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.




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

Bug#907491: closed by Paul Gevers (Re: goobook fails to authenticate)

[Sergio Mendoza]

Hi again,

  Today after an upgrade once again the problem appears:

sergio@izta:~$ goobook query sergio
Traceback (most recent call last):
  File "/usr/bin/goobook", line 11, in 
load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
  File "/usr/share/goobook/goobook/application.py", line 94, in main
args.func(config, args)
  File "/usr/share/goobook/goobook/application.py", line 125, in do_query
goobk = GooBook(config)
  File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
self.cache.load()
  File "/usr/share/goobook/goobook/goobook.py", line 257, in load
self.update()
  File "/usr/share/goobook/goobook/goobook.py", line 264, in update
self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
  File "/usr/share/goobook/goobook/goobook.py", line 395, in fetch_contacts
res = self._get(query)
  File "/usr/share/goobook/goobook/goobook.py", line 371, in _get
connection_type=httplib2.HTTPSConnectionWithTimeout)
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 
562, in new_request
redirections, connection_type)
  File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
1608, in request
(response, content) = self._request(conn, authority, uri, request_uri, 
method, body, headers, redirections, cachekey)
  File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
1350, in _request
(response, content) = self._conn_request(conn, request_uri, method, body, 
headers)
  File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
1272, in _conn_request
conn.connect()
  File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 
1059, in connect
raise SSLHandshakeError(e)
httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify 
failed (_ssl.c:726)


Cheers,

Sergio.


On Thu, Sep 13, 2018 at 07:15:03AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the goobook package:
> 
> #907491: goobook fails to authenticate
> 
> It has been closed by Paul Gevers .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Paul Gevers 
>  by
> replying to this email.
> 
> 
> -- 
> 907491: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907491
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Thu, 13 Sep 2018 09:12:55 +0200
> From: Paul Gevers 
> To: 907491-d...@bugs.debian.org
> Subject: Re: goobook fails to authenticate
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
>  Thunderbird/52.9.1
> 
> On Tue, 11 Sep 2018 12:54:45 -0500 Sergio Mendoza 
> wrote:
> > Yes, goobook works fine and smooth.
> 
> > On Tue, Sep 11, 2018 at 06:51:00PM +0200, Kurt Roeckx wrote:
> > > Now that bug #907278 is fixed, I think this is fixed too.
> 
> So, let's mark this bug so. openssl has the appropriate versioned Breaks
> relation with the python-httplib2 package, so users of testing/buster
> are protected even during partial upgrade.
> 
> Paul
> 




> Date: Tue, 28 Aug 2018 13:10:06 -0500
> From: Sergio Mendoza 
> To: Debian Bug Tracking System 
> Subject: goobook fails to authenticate
> Reply-To: ser...@mendozza.org
> X-Mailer: reportbug 7.5.0
> 
> Package: goobook
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I'm running debian unstable.  I have not been able to work properly with
> goobook and can't find a solution for it.  It requires immediate assitance.
> This is happening in all computers I have with Debian (quite a few):
> 
> sergio@izta:~$ goobook dquery sergio
> Traceback (most recent call last):
>   File "/usr/bin/goobook", line 11, in 
> load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
>   File "/usr/share/goobook/goobook/application.py", line 94, in main
> args.func(config, args)
>   File "/usr/share/goobook/goobook/application.py", line 130, in
> do_query_details
> goobk = GooBook(config)
>   File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
> self.cache.load()
>   File "/usr/share/goobook/goobook/goobook.py", line 257, in load
> self.update()
>   File "/usr/share/goobook/goobook/goobook.py", line 264, in update
> self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
>   File "/usr/share/goobook/goobook/goobook.py", line 395, in fetch_contacts
> res = self._get(query)
>   File "/usr/share/goobook/goobook/goobook.py", line 371, in _get
> connection_type=httplib2.HTTPSConnectionWithTimeout)
>   File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line
> 562, in new_request
> redirections, connection_type)
>   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
> 1608, in request
> (response, content) = 

Bug#908896: Algol 68 Genie source code page migrated

[Tomas Fasth]

Package: algol68g
Version: 2.8-2

Dear Marcel,

Thank you for pointing out the page migration. I have submitted this
message to the Debian Bug System so it will not be forgotten.

Best regards,
-- Tomas Fasth 


Den mån 20 aug. 2018 kl 15:05 skrev algol68g :

> Dear Tomas,
>
> I happened to note on page:
>
> https://tracker.debian.org/pkg/algol68g
>
> next note: "Problems while searching for a new upstream version. uscan
> had problems while searching for a new upstream version: In debian/watch
> no matching files for watch line
>http://jmvdveer.home.xs4all.nl/algol.html algol68g-(.+)\.ta ..."
>
> This is likely caused by me migrating the page to:
>
> https://jmvdveer.home.xs4all.nl/en.algol-68-genie.html
>
> Since this server offers no htacces redirects, a straightforward html
> redirect is in place for the old page. Apparently uscan cannot follow
> such html redirect?
>
> I hope this explains the situation. If I can do anything to help, please
> let me know.
>
> Best regards,
> Marcel
>

Bug#908895: RFP: node-eslint-restricted-globals -- A list of confusing globals that should be restricted to be used as globals

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-eslint-restricted-globals
  Version : 0.0.1
  Upstream Author : Siddharth "sidoshi" Doshi 
* URL : https://notabug.org/themusicgod1/eslint-restricted-globals
* License : MIT
  Programming Lang: javascript
  Description : A list of confusing globals that should be restricted to be 
used as globals

Some global variables in browser are likely to be used by people without the 
intent of using them as globals, such as
status, name etc. And because eslint ( #743404 ) thinks of them as valid global 
variables, it does not warn in case of
bugs. node-eslint-restricted-globals blacklists confusing globals which are 
exported from this package.  It contains
the list of variables that we think should not be used without a 'window' 
qualifier. But as this is just a javascript
array you can add, remove variables or even make your own list of variables.

There's significant(more than 100 separate NPM packages) work that has been 
built on top of node-eslint-restricted-globals
in particular, some dependencies of 'node-babel-preset-es2016-node5' ( #908765 
).

Bug#902809: want dgit smash-working-tree-timestamps [and 1 more messages]

[Sean Whitton]

control: reassign -1 devscripts
control: retitle -1 New script: smash-working-tree-timestamps
control: severity -1 wishlist

Hello,

On Mon 09 Jul 2018 at 04:20PM +0100, Ian Jackson wrote:

> We definitely need it to touch files which came from `git checkout',
> `git reset' and so on.
>
> If one is trying to use some existing build machinery which has
> timestamp-related bugs, then it is likely that totally untracked files
> which are actually build products will want to be older than the
> source files being touched.
>
> I don't think .gitignore should influence the behaviour, because we
> are trying to cope with broken packages, whose .gitignore is likely to
> be unhelpful.
>
> There is a question about files the user has created, which are not
> build products, and which have not been added to HEAD or to the index.
> We can't distinguish these from build products.  I suggest we treat
> them as build products, and advise the user to commit before building
> (or at least `git add' anything they intend to keep).

This reasoning all seems fine to me.

I guess that experience using the script to avoid FTBFS will reveal
whether this behaviour needs to be tweaked; we probably shouldn't
overthink it.

> Something like
>   #!/bin/bash
>   set -o pipefail
>   git ls-files -z | xargs -0r touch -h -r . --
>
> This does not include files which are in HEAD, not in the index, but
> in the working tree.  Ie files which were git rm'd, but not committed,
> and then recreated.

Those seem likely to be build products that were accidentally committed
(because, e.g., accidentally included in the source package).  So that
seems right, too.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#908824: libnet-server-mail-perl FTBFS: t/starttls.t failure

[Damyan Ivanov]

-=| gregor herrmann, 14.09.2018 16:08:50 +0200 |=-
> Control: tag -1 + unreproducible
> 
> On Fri, 14 Sep 2018 16:52:38 +0300, Adrian Bunk wrote:
> 
> > Source: libnet-server-mail-perl
> > Version: 0.25-1
> > Severity: serious
> > Tags: ftbfs
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=libnet-server-mail-perl=all=0.25-1=1536904015=0
> 
> Thanks for the bug report.
>  
> > ...
> > Test Summary Report
> > ---
> > t/starttls.t (Wstat: 9 Tests: 3 Failed: 0)
> >   Non-zero wait status: 9
> >   Parse errors: No plan found in TAP output
> > Files=4, Tests=33,  2 wallclock secs ( 0.05 usr  0.04 sys +  0.67 cusr  
> > 0.20 csys =  0.96 CPU)
> > Result: FAIL
> > Failed 1/4 test programs. 0/33 subtests failed.
> > make[1]: *** [Makefile:861: test_dynamic] Error 255
> 
> Hm, the package builds for me.
> 
> 
> The buildd failure is:
> 
> # Error: TLS handshake failed SSL connect attempt failed at t/starttls.t line 
> 116.
> # kill 9, 17145 (server)
> t/starttls.t .. 
> ok 1 - Accepted client for Test01: STARTTLS support
> ok 2 - Accepted client for Test02: STARTTLS invalid parameters
> ok 3 - Accepted client for Test03: STARTTLS handshake
> All 3 subtests passed 
> 
> 
> Line 116 in the test is:
> 
>112my $rv =
>113  IO::Socket::SSL->start_SSL( $s,
>114SSL_verify_mode => 
> IO::Socket::SSL::SSL_VERIFY_NONE, );
>115
>116( defined $rv && ref $rv eq 'IO::Socket::SSL' )
>117  or die "TLS handshake failed >" . 
> IO::Socket::SSL::errstr();


Building the package several times (sbuild) passes here most of the 
time and then:

# Error: Can't call method "peerhost" on an undefined value at t/starttls.t line
 131.
# kill 9, 28330 (server)
t/starttls.t .. 
ok 1 - Accepted client for Test01: STARTTLS support
ok 2 - Accepted client for Test02: STARTTLS invalid parameters
ok 3 - Accepted client for Test03: STARTTLS handshake
All 3 subtests passed 

Adding
$SIG{PIPE} = 'IGNORE';
at the start of the test seems to make it pass all the time.

I wonder if this is the correct fix.

-- Damyan

Bug#908894: ITP: lazygit -- Simple terminal UI for git commands

[Jongmin Kim]

Package: wnpp
Severity: wishlist
Owner: Jongmin Kim 
X-Debbugs-CC: debian-de...@lists.debian.org, team+pkg...@tracker.debian.org

* Package name: lazygit
  Version : 0.2.1
  Upstream Author : Jesse Duffield 
* URL : https://github.com/jesseduffield/lazygit
* License : Expat
  Programming Lang: Go
  Description : Simple terminal UI for git commands

 lazygit is a simple terminal UI for git commands that makes git easy to
 use. All features of lazygit can be easily used by using the directional
 keys and simple keystrokes of the keyboard.
 .
 lazygit provides the following git features with cool interface:
  * Adding files easily
  * Resolving merge conflicts
  * Easily check out recent branches
  * Scroll through logs/diffs of branches/commits/stash
  * Quick push/pull
  * Squash down and rename commits

lazygit is an easy-to-use git terminal UI for wrapping a bunch of git
commands. It also provides visualising the branches which have difficult
and complex relationships.

Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Sean Whitton]

[copying in debian-policy]

Hello,

On Fri 10 Aug 2018 at 08:23AM +0200, Michael Biebl wrote:

> Currently, DynamicUser gets a uid from within the following range:
> 61184 - 65519. Those values can be configured during build time via
> -Ddynamic-uid-min= and -Ddynamic-uid-max.
>
> The debian policy has a section about uids and gids:
> https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes
>
> The overlapping ranges are:
> 6-64999:
>  Globally allocated by the Debian project, but only created on demand.
>  The ids are allocated centrally and statically, but the actual accounts
>  are only created on users’ systems on demand.
>
>  These ids are for packages which are obscure or which require many
>  statically-allocated ids. These packages should check for and create the
>  accounts in /etc/passwd or /etc/group (using adduser if it has this
>  facility) if necessary. Packages which are likely to require further
>  allocations should have a “hole” left after them in the allocation, to
>  give them room to grow.
>
> 65000-65533:
>  Reserved.
>
> We don't meet the requirement of the 6-64999 range, which says that
> the ids need to be allocated statically (DynamicUser generated ids are
> ephemeral).
> The 65000-65533 range doesn't go into more detail, what purpose it is
> reserved.

I don't know why it's reserved either, but ISTM this is rather too small
a range for systemd's DynamicUser.  Would you agree?

> There is also:
> 65536-4294967293:
>  Dynamically allocated user accounts. By default adduser will not
>  allocate UIDs and GIDs in this range, to ease compatibility with legacy
>  systems where uid_t is still 16 bits.
>
> I'm not sure if it would be more suitable to pick the DynamicUser ids
> from this range.

This strikes me as suitable.  We could either just change systemd's
configuration, or allocate a section of that range to systemd.

We probably don't need the legacy systems compatibility anymore.  So
maybe at some point adduser will start creating users in this range.  So
maybe we should carve out a section of that range for systemd, for
future proofing?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#908893: stretch-pu: package globus-gsi-credential_7.11-1+deb9u1

[Mattias Ellert]

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

This is a proposed update to the globus-gsi-credential package in
Debian 9 (stretch). I have created it in response to a request that was
sent to me via e-mail (included below).

Mattias

 Vidarebefordrat meddelande 
Från: Dave Dykstra 
Till: Mattias Ellert 
Ämne: libglobus-gsi-credential1 fix for stretch
Datum: Fri, 14 Sep 2018 15:56:24 -0500

Hi Mattias,

There's been a fix
https://github.com/globus/globus-toolkit/issues/115
affecting cvmfs-x509-helper in Debian testing libglobus-gsi-credential1
version 7.14-1 since last November, but it still hasn't made it into
Debian 9 stretch or stretch-updates.  Could you backport it there?
Meanwhile I have been maintaining a patched copy in the cvmfs-contrib
repository (https://cvmfs-contrib.github.io).

Dave

diff -Nru globus-gsi-credential-7.11/debian/changelog globus-gsi-credential-7.11/debian/changelog
--- globus-gsi-credential-7.11/debian/changelog	2016-11-08 23:25:05.0 +0100
+++ globus-gsi-credential-7.11/debian/changelog	2018-09-15 16:15:42.0 +0200
@@ -1,3 +1,11 @@
+globus-gsi-credential (7.11-1+deb9u1) stretch; urgency=medium
+
+  * Fix issue with voms proxy and openssl 1.1
+  * https://github.com/globus/globus-toolkit/issues/115
+  * https://github.com/globus/globus-toolkit/pull/116
+
+ -- Mattias Ellert   Sat, 15 Sep 2018 16:15:42 +0200
+
 globus-gsi-credential (7.11-1) unstable; urgency=medium
 
   * GT6 update
diff -Nru globus-gsi-credential-7.11/debian/patches/globus-gsi-credential-voms-openssl-1.1.patch globus-gsi-credential-7.11/debian/patches/globus-gsi-credential-voms-openssl-1.1.patch
--- globus-gsi-credential-7.11/debian/patches/globus-gsi-credential-voms-openssl-1.1.patch	1970-01-01 01:00:00.0 +0100
+++ globus-gsi-credential-7.11/debian/patches/globus-gsi-credential-voms-openssl-1.1.patch	2018-09-15 16:09:00.0 +0200
@@ -0,0 +1,70 @@
+From 924cb64dda4dae571456772bd1db62d5bbe25ccf Mon Sep 17 00:00:00 2001
+From: Mischa Salle 
+Date: Mon, 23 Oct 2017 20:16:26 +0200
+Subject: [PATCH] Simple patch for GT issue #115
+
+This patch reorders the the setting of the check_issued and the initialization
+of the X509_STORE_CTX object with the X509_STORE thereby solving
+https://github.com/globus/globus-toolkit/issues/115
+---
+ .../source/library/globus_gsi_cred_handle.c   | 28 +--
+ 1 file changed, 14 insertions(+), 14 deletions(-)
+
+diff --git a/library/globus_gsi_cred_handle.c b/library/globus_gsi_cred_handle.c
+index 9877ad603d..e890f56abf 100644
+--- a/library/globus_gsi_cred_handle.c
 b/library/globus_gsi_cred_handle.c
+@@ -1745,19 +1745,19 @@ globus_gsi_cred_verify_cert_chain(
+ 
+ if (X509_STORE_load_locations(cert_store, NULL, cert_dir))
+ {
++#if OPENSSL_VERSION_NUMBER < 0x1010L
++/* override the check_issued with our version */
++cert_store->check_issued = globus_gsi_callback_check_issued;
++#else
++X509_STORE_set_check_issued(cert_store, globus_gsi_callback_check_issued);
++#endif
++
+ store_context = X509_STORE_CTX_new();
+ X509_STORE_CTX_init(store_context, cert_store, cert,
+ cred_handle->cert_chain);
+ X509_STORE_CTX_set_depth(store_context,
+  GLOBUS_GSI_CALLBACK_VERIFY_DEPTH);
+ 
+-#if OPENSSL_VERSION_NUMBER < 0x1010L
+-/* override the check_issued with our version */
+-store_context->check_issued = globus_gsi_callback_check_issued;
+-#else
+-X509_STORE_set_check_issued(X509_STORE_CTX_get0_store(store_context), globus_gsi_callback_check_issued);
+-#endif
+-
+ globus_gsi_callback_get_X509_STORE_callback_data_index(
+ _data_index);
+ 
+@@ -1937,19 +1937,19 @@ globus_gsi_cred_verify_cert_chain_when(
+ 
+ if (X509_STORE_load_locations(cert_store, NULL, cert_dir))
+ {
++/* override the check_issued with our version */
++#if OPENSSL_VERSION_NUMBER < 0x1010L
++cert_store->check_issued = globus_gsi_callback_check_issued;
++#else
++X509_STORE_set_check_issued(cert_store, globus_gsi_callback_check_issued);
++#endif
++
+ store_context = X509_STORE_CTX_new();
+ X509_STORE_CTX_init(store_context, cert_store, cert,
+ cred_handle->cert_chain);
+ X509_STORE_CTX_set_depth(store_context,
+  GLOBUS_GSI_CALLBACK_VERIFY_DEPTH);
+ 
+-/* override the check_issued with our version */
+-#if OPENSSL_VERSION_NUMBER < 0x1010L
+-store_context->check_issued = globus_gsi_callback_check_issued;
+-#else
+-X509_STORE_set_check_issued(X509_STORE_CTX_get0_store(store_context), globus_gsi_callback_check_issued);
+-#endif
+-
+ globus_gsi_callback_get_X509_STORE_callback_data_index(
+ _data_index);
+ 
diff -Nru 

Bug#908106: dpkg ignores ASCII file named *.so when building source package

[Guillem Jover]

Control: forcemerge 718984 -1

On Thu, 2018-09-06 at 07:58:59 +, Mo Zhou wrote:
> Package: dpkg
> Version: 1.19.0.5+b1
> Severity: normal
> Justification: triggers confusing FTBFS under a certain condition

> Procedure to reproduce:
> 
>   1. clone https://salsa.debian.org/science-team/tensorflow
>   2. checkout lumin/A1u30 or equivalently 
> a2d2212c63bc23ada20bef0eeb6284e6f3a022ec
>   3. build source package
>   4. ASCII files debian/bazelDumps/*.so are missing from the debian.tar.gz 
> tarball.
> 
> My workaround is just to rename these ASCII files

This was somewhat already filed in the past. It should be fixed, but
when I looked at it, AFAIR, it was "complicated". I'm thinking a
better way to go about this might be to just drop the binary
exclusions as described in #735377. Will need to dig into that again.

Thanks,
Guillem

Bug#908861: Acknowledgement (dash: echo "\\c" does not print a backslash followed by c)

[bernd]

Please close this bug as invalid.
Sorry for this invalid bug report.
I found out, this is no bug.

The reason that confuse me was:
$ [ "" = '\\' ] && echo "is the same"
is the same

Also /bin/echo and bash behaves the same way when called with option -e
$ /bin/echo -e "\\c"
$ /bin/echo -e "c"
\c
$ bash -c 'echo -e "\\c"'
$ bash -c 'echo -e "c"'
\c





binlrzRb6p1E8.bin
Description: Öffentlicher PGP-Schlüssel

Bug#908892: RFS: picocli/3.5.2-2 [RC]

[Miroslav Kravec]

Package: sponsorship-requests
Severity: important
X-Debbugs-CC: debian-j...@lists.debian.org


Dear mentors,

I am looking for a sponsor for my package "picocli":

 * Package name: picocli
   Version : 3.5.2-2
   Upstream Author : Remko Popma 
 * URL : https://picocli.info/
 * URL (GitHub): https://github.com/remkop/picocli
 * License : Apache-2.0
   Section : java

It builds those binary packages:

libpicocli-java - Tiny command line interpreter library for Java
applications

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

  https://mentors.debian.net/package/picocli

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/picocli/picocli_3.5.2-2.dsc

Changes since the last upload:

* debian/copyright: add missing copyright contributions (Closes: #908606)

Kind regards,
Miroslav Kravec

Bug#908742: Want way to reset tar-ignore list

[Guillem Jover]

Hi!

On Thu, 2018-09-13 at 12:03:09 +0100, Ian Jackson wrote:
> Package: dpkg-dev
> Version: 1.19.0.5
> Control: block 908417 by -1

> Recently a dgit user complained that if their package has a tar-ignore
> in debian/source/options, things go wrong.  See #908417.
> 
> dgit needs to run dpkg-source in such a way that all things in the
> input directory end up in the source package, except precisely the
> top-level .git directory.  To do this it passes a slew of -I and -i
> options to dpkg-source.
> 
> But if the source package contains a tar-ignore option in
> debian/source/options, this does not work, because the -I options
> stack up.
> 
> Simply having the user remove tar-ignore from the source package's
> debian/source/options is IMO best, but as you see in #908417 that does
> have downsides.
> 
> If dpkg-source provided a --reset-tar-ignore option which cancelled
> all previous --tar-ignore options (including those from
> debian/source/options), then dgit could pass that option and
> everything would work right.

Hmm, I found this bug description and the problem from the referenced
bug to be a bit of a mismatch. I checked the notmuch referenced history
where I noticed in commit 514fb397c9f7cfc80f0b14bd28bb2acdb4cd30ca that
the problem was the standalone tar-ignore option. The current options
file now contains:

,--- debian/source/options
single-debian-patch
tar-ignore=.git
tar-ignore=performance-test/download/*.tar.xz
`---

With that in mind, I'm not sure whether your request is to ignore
*only* those standalone tar-ignore options or any of them regarldess
of these taking an argument or not?

Because I'd think in general you'd want to honor the ignore rules from
the source package itself, except for the dpkg-source defaults. OTOH I
guess those same ignores would be covered by things such as .gitignore
or similar VCS-specific files.

I think both options, never-add-tar-ignore-defaults-even-if-specified
and clear-all-tar-ignore are valid, and I might add both, just wanted
to make sure I understand which one you are requesting here.

Thanks,
Guillem

Bug#888243: Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

[Holger Levsen]

On Thu, Sep 13, 2018 at 11:35:50PM +0200, Santiago Vila wrote:
> On Thu, Sep 13, 2018 at 08:59:39PM +, Holger Levsen wrote:
> > a.) using /opt/etc and shipping files there is fine today and piuparts
> > should not complain here
> Could you briefly explain in which way the most recent FHS is more
> permissive than previous releases?

I'm not going to dig up and compare different FHS versions now, but this
is what I recall from when FHS 3.0 was announced..

But then, I just checked
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html and 
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html#etcoptConfigurationFilesForOpt
and noticed that neither speaks of /opt/etc, just /etc/opt...

> if we allow using /etc/opt in Debian packages, I would like to think
> that it would be only to support packages not in Debian already using
> it, (like the present case), not an open door to use /etc/opt widely.
> 
> (In other words, IMHO, a warning from piuparts would still be desirable).

piuparts(.d.o) doesnt really have the concept of warnings, there are
either errors or not. But maybe this is something lintian could detect?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#888546: Bug#888243: Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

[Holger Levsen]

On Fri, Sep 14, 2018 at 12:01:07AM +0200, Santiago Vila wrote:
> Holger, this one (#888546) is the bug that you reported. If you think
> it is really a bug in piuparts, feel free to reassign again.

well, this bug is about a file/directory vanishing and I think it is
correct that piuparts complains about those.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#888243: Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

[Holger Levsen]

On Thu, Sep 13, 2018 at 05:15:48PM -0400, Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila  wrote:
> > What I said is that no sane package in Debian/main should need to put
> > files directly in /etc/opt. That's an oddity, a very unorthodox thing,
> > it would be like a Debian package in main putting stuff directly in /opt.
> chrome-gnome-shell (in this case) is an addon for the Google Chrome
> web browser. Since Chrome installs to /opt/ (which is encouraged by
> FHS), /etc/opt/ is the only standards-compliant location for
> chrome-gnome-shell to ship the configuration files it needs to provide
> its core functionality.
 
This makes sense to me.

> There is no reason this functionality cannot be offered in Debian. We
> got complaints when we supported other browsers but not Google Chrome.

also :)

> > I filed the bug because I believe it's the root of the problem you
> > have with piuparts, but in either case, feel free to disagree on that
> > one and claim FHS compliance, as far as you don't ask other people to
> > fix the consequences of putting files in /etc/opt.
> 
> I am asking for help. I have never created or dealt with noawait
> triggers so I don't know how to implement Guillem's suggested
> workaround.

debian-edu-artwork is a package which uses noawait triggers. I also
found the lintian hints quite helpful:

debian-edu-artwork$ rgrep noawait *
debian/changelog:into -noawait ones. Thanks lintian and #debian-qa.
debian/changelog:  * d-e-a-softwaves.triggers: Use interest-noawait to avoid 
triggers cycle.
debian/debian-edu-artwork-lines.triggers:interest-noawait 
/usr/share/plasma/desktoptheme
debian/debian-edu-artwork-softwaves.triggers:interest-noawait 
/usr/share/plasma/desktoptheme
debian/debian-edu-artwork-softwaves.triggers:interest-noawait /etc/plymouth
debian/debian-edu-artwork-softwaves.triggers:interest-noawait 
/usr/share/doc/debian-edu-artwork-lines


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#908818: [Pkg-zsh-devel] Bug#908818: Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)

[Daniel Shahaf]

TS wrote on Sat, 15 Sep 2018 11:39 +0200:
> > up to 5.5.1-1 seem fine, problem starts with 5.6
> 
> for the record what zprofile does...
> 
> zprofile() {
> ZSH_PROFILE_RC=1 zsh "$@"
> }
> 
> ...is it activates this code snipped in my .zshrc:
> 
> #
> #   zprofile
> #
> (( ${+ZSH_PROFILE_RC} )) && builtin zmodload zsh/zprof
> 
> 
> in case you want test yourself.

Thanks for testing 5.6.2.

I can't reproduce the bug with a zshrc that contains nothing but an
(unconditional) zmodload zsh/zprof.  I'm using a self-compiled
static build from upstream git, not a package build.

Could you please send a bug report upstream (zsh-work...@zsh.org)?
Ideally, the bug report would include a reproduction script that sets up
a new temporary directory, creates a minimal zshrc in it, and runs
'ZDOTDIR=/path/to/dir zsh -d' and provokes the bug.

Thanks!

Daniel

Bug#908890: developers-reference: As alioth is gone, replace references to Salsa

[Tobias Frost]

Package: src:developers-reference
Severity: normal
Tags: patch

I found during the translation to German that there are a few references
to alioth, but at this service is no longer, those references needs
updating.

MR: https://salsa.debian.org/debian/developers-reference/merge_requests/6

Please note that this MR needs reviewing, language and contentwise.
For example I'm not sure if section 4.12 should be deleted completly or
(like in the MR) described as past service…

Cheers,
-- 
tobi

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

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

Bug#907586: Problem logging in to hppa debian porterbox panama.debian.net

[John David Anglin]

On 2018-09-14 7:55 PM, John David Anglin wrote:

With g++-8 8.2.0-6 and its fix for BTS #907586, I was able to build the
nordugrid-arc package in a schroot on the panama porterbox.

Great.

I have committed fix to trunk and gcc-8:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00801.html

Will patch gcc 6 and 7 if things look good.

I gave back nordugrid-arc package.
Unfortunately, the fix applied for BTS #907586 is not the final patch 
applied above.


Dave

--
John David Anglin  dave.ang...@bell.net

Bug#908870: korganizer: Tuen Ng Festival date in 2019 is wrong

[Sandro Knauß]

Control: Forwarded -1 https://bugs.kde.org/show_bug.cgi?id=398670

The bug tracker of Debian can handle the forwarded command to get status 
updates automatically.

hefee

--
On Samstag, 15. September 2018 15:55:37 CEST Michael Tsang wrote:
> https://bugs.kde.org/show_bug.cgi?id=398670
> 
> On Saturday 15 September 2018 21:12:22 HKT Sandro Knauß wrote:
> > Control: reassign -1 src:kholidays
> > Control: notfound -1 4:17.12.3-2
> > Control: found -1 1:5.49.0-1
> > Control: tags -1 +upstream
> > 
> > Hey,
> > 
> > Thanks for your bugreport. The bug itself is not not korganizer it is
> > kholidays as kholidays has the list of all holidays. The bug itself is not
> > a Debian one, it is an upstream bug. So please open an upstream bug
> > report at https://bugs.kde.org and leave a note about the upstream
> > bugreport here.
> > 
> > If you have any questions, do not hesitate to ask.
> > 
> > hefee



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

Bug#908889: src:firefox-esr: Fix broken ppc64 build

[Roberto Guardato]

Package: src:firefox-esr
Version: 60.2.0esr
Severity: serious
Justification: fails to build from source

Hi all,
trying to build firefox-esr on PowerPc64 (ppc64) arch i obtain the following 
error:

DEBUG: Executing: `/usr/bin/rustc --print target-list`
DEBUG: Creating `/tmp/conftest8qrTCp.rs` with content:
DEBUG: | pub extern fn hello() { println!("Hello world"); }
DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib 
--target=powerpc64-unknown-linux-gnu -o /tmp/conftest5k25jo.rlib 
/tmp/conftest8qrTCp.rs`
DEBUG: The command returned non-zero exit status 101.
DEBUG: Its error output was:
DEBUG: | thread '' panicked at 'failed to acquire jobserver token: Bad 
file descriptor (os error 9)', librustc_codegen_llvm/back/write.rs:1826:29
DEBUG: | stack backtrace:
DEBUG: |0: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
DEBUG: |1: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
DEBUG: |2: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
DEBUG: |3: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
DEBUG: |4: 
DEBUG: |5: std::panicking::rust_panic_with_hook
DEBUG: |6: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
DEBUG: |7: std::panicking::begin_panic_fmt
DEBUG: |8: 
DEBUG: |9: 
DEBUG: |   10: __rust_maybe_catch_panic
DEBUG: |   11: 
DEBUG: |   12: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
DEBUG: |   13: rust_metadata_std_9ebdad0dc3fb665c33af16b135b6af8
DEBUG: |   14: 
DEBUG: | query stack during panic:
DEBUG: | end of query stack
DEBUG: | error: failed to acquire jobserver token: Bad file descriptor (os 
error 9)
DEBUG: | 
DEBUG: | error: aborting due to previous error
DEBUG: | 
ERROR: Cannot compile for powerpc64-unknown-linux-gnu with /usr/bin/rustc
The target may be unsupported, or you may not have
a rust std library for that target installed. Try:

  rustup target add powerpc64-unknown-linux-gnu

Many thanks for your support.
rt1k

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

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

Bug#908888: Please update the upstream version (1.61.2)

[Santiago R.R.]

Source: dnsruby
Version: 1.54-2
Severity: normal
Tags: upstream

Hi Ondřej,

Please, consider packaging a more recent version of dnsruby. The newest
as of today is 1.61.2:
https://rubygems.org/gems/dnsruby/versions/1.61.2

Cheers, and thanks for your work,

 -- Santiago


signature.asc
Description: PGP signature

Bug#893377: Re: Bug#893377: RFS: taptempo/1.2.1-1 [ITP]

[François Mazen]

Hi Lumin,

the file msys/mingw-bundledlls.py was committed by mistake. It is only
needed to generate the Windows package.
I've removed it in the upstream code and I generated a new release
(1.4.3). I've also updated the copyright file for the new 1.4.3-1
package.

The new package is tagged debian/1.4.3-1 in the packaging repository:

https://git.tuxfamily.org/taptempo/taptempo_deb_packaging.git/tag/?h=debian/1.4.3-1

and it's uploaded to mentors (just to check that everything is still
fine).

Best Regards,
François




Le vendredi 14 septembre 2018 à 03:09 +, Mo Zhou a écrit :
> On Thu, Sep 13, 2018 at 10:57:42PM +0200, François Mazen wrote:
> > Hi Lumin,
> > 
> > congratulation for your promotion as Debian Developer!
> > 
> > I downgraded the standard version of my package from 4.2.1 to 4.1.4
> > and
> > I uploaded it to mentors but Lintian has been updated in the
> > meantime.
> > So I've kept the 4.2.1 version and you can upload:
> > https://mentors.debian.net/package/taptempo
> 
> Oops, I have no idea when msys/mingw-bundledlls.py appeared in
> the source package but you have to add it to the copyright file.
> 
> The rest looks good to me. Please tag debian/1.4.2-1 in your
> packaging
> repository after fixing the copyright. I'll directly upload the
> package from your git repo instead of mentors. (So you don't have to
> upload to mentors again)

Bug#908870: korganizer: Tuen Ng Festival date in 2019 is wrong

[Michael Tsang]

https://bugs.kde.org/show_bug.cgi?id=398670

On Saturday 15 September 2018 21:12:22 HKT Sandro Knauß wrote:
> Control: reassign -1 src:kholidays
> Control: notfound -1 4:17.12.3-2
> Control: found -1 1:5.49.0-1
> Control: tags -1 +upstream
> 
> Hey,
> 
> Thanks for your bugreport. The bug itself is not not korganizer it is
> kholidays as kholidays has the list of all holidays. The bug itself is not a
> Debian one, it is an upstream bug. So please open an upstream bug report at
> https://bugs.kde.org and leave a note about the upstream bugreport here.
> 
> If you have any questions, do not hesitate to ask.
> 
> hefee

-- 
Sent from KMail

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