Bug#908858: ca-certificates: hidden dependency on default-jre

2018-09-15 Thread Marc Lehmann
Package: ca-certificates
Version: 20161130+nmu1+deb9u1
Severity: normal

Dear Maintainer,

I get this error when installing openjdk-8-jre:i386 on an amd64 system, which 
pulls in
ca-certificates-java automatically:

   Processing triggers for ca-certificates (20161130+nmu1+deb9u1) ...
   Updating certificates in /etc/ssl/certs...
   0 added, 0 removed; done.
   Running hooks in /etc/ca-certificates/update.d...

   /etc/ca-certificates/update.d/jks-keystore: 86: 
/etc/ca-certificates/update.d/jks-keystore: java: Permission denied
   E: /etc/ca-certificates/update.d/jks-keystore exited with code 1.

The way this happened is that I uninstalled opendjk-8.*, which removed 
ca-certificates-java and default-jre. The result was that there was no "java" 
executable in the PATH anymore.

Then, during installation of openjdk-8-jre:i386, I got the above error.

I was able top work around this by installing default-jre again, which gave me 
a java executable.

I don't know if this is a problem in ca-certificates, ca-certificates-java, 
openjdk or elsewhere, so apologies if I report this against the wrong package.

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

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

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  openssl1.1.0f-3+deb9u2

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information excluded



Bug#908859: 389-ds-base: CVE-2018-14638

2018-09-15 Thread Salvatore Bonaccorso
Source: 389-ds-base
Version: 1.4.0.15-1
Severity: grave
Tags: security
Control: found -1 1.3.8.2-1

Hi,

The following vulnerability was published for 389-ds-base.

CVE-2018-14638[0]:
| A flaw was found in 389-ds-base before version 1.3.8.4-13. The process
| ns-slapd crashes in delete_passwdPolicy function when persistent
| search connections are terminated unexpectedly leading to remote
| denial of service.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-14638
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14638
[1] https://pagure.io/389-ds-base/c/78fc627accacfa4061ce48977e22301f81ea8d73

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#908857: Patch archive in initial post was damaged - sending again

2018-09-15 Thread Guenther Brunthaler
It seems it was not such a good idea to paste the .ar archive directly 
into the mail body.


I assume it got reformatted by my mail client, and will be rejected by 
"ar" as a consequence.


I have enclosed the patch again as an attachment in this follow-up 
posting, fixing that problem.




didiwiki_0.5-13_p1-2018.258.patch.xz
Description: application/xz


Bug#900717: Failed to get GBM bo for flip to new front

2018-09-15 Thread Erik de Castro Lopo


I'm seeing a gazzilion of these messages in /var/log/Xorg.0.log:

   [2366588.693] (EE) modeset(0): Failed to get GBM bo for flip to new front.
   [2366588.693] (EE) modeset(0): present flip failed

My machine currently has an uptime of 27 days, and /var/log/Xorg.0.log
has grown to 2.8G in size and I am getting warnins about my / partition
filling up.

Currently only solution seems to be logging out and restarting X.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/



Bug#908860: linux-image-4.18.0-1-amd64: enable CONFIG_XDP_SOCKETS in debian kernels

2018-09-15 Thread Georg Müller
Package: src:linux
Version: 4.18.6-1
Severity: wishlist



-- Package-specific info:
** Version:
Linux version 4.18.0-1-amd64 (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-amd64 
root=UUID=e2ca7c78-317c-4724-b31e-7114443f40c6 ro quiet

** Not tainted

** Kernel log:
[1.300864] uhci_hcd :00:06.1: detected 2 ports
[1.301331] uhci_hcd :00:06.1: irq 11, io base 0xc100
[1.301444] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001, 
bcdDevice= 4.18
[1.301446] usb usb3: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[1.301448] usb usb3: Product: UHCI Host Controller
[1.301449] usb usb3: Manufacturer: Linux 4.18.0-1-amd64 uhci_hcd
[1.301451] usb usb3: SerialNumber: :00:06.1
[1.301564] hub 3-0:1.0: USB hub found
[1.301575] hub 3-0:1.0: 2 ports detected
[1.336216] uhci_hcd :00:06.2: UHCI Host Controller
[1.336226] uhci_hcd :00:06.2: new USB bus registered, assigned bus 
number 4
[1.336236] virtio-pci :00:07.0: virtio_pci: leaving for legacy driver
[1.336242] uhci_hcd :00:06.2: detected 2 ports
[1.336450] uhci_hcd :00:06.2: irq 11, io base 0xc120
[1.336552] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, 
bcdDevice= 4.18
[1.336554] usb usb4: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[1.336555] usb usb4: Product: UHCI Host Controller
[1.336557] usb usb4: Manufacturer: Linux 4.18.0-1-amd64 uhci_hcd
[1.336558] usb usb4: SerialNumber: :00:06.2
[1.336681] hub 4-0:1.0: USB hub found
[1.336689] hub 4-0:1.0: 2 ports detected
[1.355349] virtio-pci :00:08.0: virtio_pci: leaving for legacy driver
[1.372675] virtio-pci :00:09.0: virtio_pci: leaving for legacy driver
[1.376072] virtio_blk virtio2: [vda] 41943040 512-byte logical blocks (21.5 
GB/20.0 GiB)
[1.377468]  vda: vda1 vda2 < vda5 >
[1.397205] ata1.01: NODEV after polling detection
[1.398061] ata1.00: ATAPI: QEMU DVD-ROM, 2.4.0, max UDMA/100
[1.399567] scsi 0:0:0:0: CD-ROMQEMU QEMU DVD-ROM 2.4. 
PQ: 0 ANSI: 5
[1.448889] sr 0:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[1.448893] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.449566] sr 0:0:0:0: Attached scsi CD-ROM sr0
[1.628107] usb 1-1: new high-speed USB device number 2 using ehci-pci
[1.730591] PM: Image not found (code -22)
[1.786193] usb 1-1: New USB device found, idVendor=0627, idProduct=0001, 
bcdDevice= 0.00
[1.786196] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=5
[1.786199] usb 1-1: Product: QEMU USB Tablet
[1.786201] usb 1-1: Manufacturer: QEMU
[1.786203] usb 1-1: SerialNumber: 42
[1.815440] hidraw: raw HID events driver (C) Jiri Kosina
[1.820198] usbcore: registered new interface driver usbhid
[1.820200] usbhid: USB HID core driver
[1.822954] input: QEMU QEMU USB Tablet as 
/devices/pci:00/:00:06.7/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input3
[1.823056] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 
Mouse [QEMU QEMU USB Tablet] on usb-:00:06.7-1/input0
[1.846324] random: fast init done
[1.846919] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: 
(null)
[1.960977] 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)
[1.961009] systemd[1]: Detected virtualization kvm.
[1.961016] systemd[1]: Detected architecture x86-64.
[1.964317] systemd[1]: Set hostname to .
[2.061830] input: ImExPS/2 Generic Explorer Mouse as 
/devices/platform/i8042/serio1/input/input2
[2.072175] random: systemd: uninitialized urandom read (16 bytes read)
[2.072243] systemd[1]: Listening on fsck to fsckd communication Socket.
[2.072303] random: systemd: uninitialized urandom read (16 bytes read)
[2.072338] systemd[1]: Listening on initctl Compatibility Named Pipe.
[2.072386] random: systemd: uninitialized urandom read (16 bytes read)
[2.072492] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[2.072563] systemd[1]: Listening on udev Control Socket.
[2.072638] systemd[1]: Listening on Journal Audit Socket.
[2.073805] systemd[1]: Created slice system-postgresql.slice.
[2.108679] EXT4-fs (vda1): re-mounted. Opts: errors=remount-ro
[2.134158] RPC: Registered named UNIX socket transport module.
[2.134169] RPC: Registered udp transport module.
[2.134170] RPC: Registered tcp transport module.
[2.134171] RPC: Registered tcp NFSv4.1 backchannel transport module.
[2.201033] systemd-journald[280]: Received request to flush runtime journal 
from PID 1
[2.278211]

Bug#906816: thunderbird: Does not start

2018-09-15 Thread Torbjörn Andersson

On 2018-09-08 12:00, Carsten Schoenert wrote:


Does that rule out an upstreams problem?


Only if we know if the same issue is also not present in the upstream
version 60.0, aka the same version the Debian build is based on.

Debian is using since some months GCC8 and LLVM6.0 so we might again
find some regressions about compiler flags as Mozilla is still using
quite old compilers (compared to GCC8) which working differently while
creating the binary code.


I made a quick attempt at building Thunderbird myself from the Debian 
source package, and it seems to crash the same way as the official one. 
Which could actually be good, since that means that - with the proper 
direction - I *might* be able to help debug why it crashes for me.


What I don't know is how to print any relevant messages for debugging, 
since it's all wrapped up in data types I can't even begin to unravel on 
my own...


Torbjörn



Bug#906570: Acknowledgement (firefox-esr segfaults during startup on arm64)

2018-09-15 Thread Arian Sanusi
This problem still occurs with 60.2.0esr-1



signature.asc
Description: OpenPGP digital signature


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

2018-09-15 Thread Bernd Schumacher
Package: dash
Version: 0.5.10.2-1
Severity: normal

-- Description of the problem --
Next commands are executed as expected:
bs@sid:~$ dash
$ man dash | grep "Output a backslash"
\\  Output a backslash.
$ echo "\\"
\
$ echo "c"
c
$ exit
bs@sid:~$ 

Next command is executed, but not as expected and reason for this bugreport:
bs@sid:~$ dash
$ echo "\\c"
$ exit
bs@sid:~$ 

Next commands are workarounds, that behave as expected, but without dash echo
bs@sid:~$ dash
$ /bin/echo "\\c"
\c
$ bash -c 'echo "\\c"'
\c
$ exit
bs@sid:~$ 

-- My assumption --
It seems, dash interprets "\\c" like "\c" which means that Subsequent output is 
suppressed, as shown in the manpage.

If this bugreport is considered as valid by the developers, I believe the same 
bug may also be in other shells like 'busybox sh', 'mksh' and 'posh' and I will 
double check this suspicion and report additional bug reports.

-- 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_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

Versions of packages dash depends on:
ii  debianutils  4.8.6
ii  dpkg 1.19.0.5+b1
ii  libc62.27-6

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true



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

2018-09-15 Thread TS
Hello Axel,

thanks for uploading 5.6.2, but no luck.

I still get reliable:

% zprofile
[7]  + 10408 suspended (tty output)

% pZSH_VERSION
scalar-readonly  ZSH_VERSION='5.6.2'


Debian Bug Tracking System schrieb/wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the zsh package:
> 
> #908818: Zsh: [7] + 23074 suspended (tty output)
> 
> It has been closed by Axel Beckert .



Bug#908863: ruby-bourne: FTBFS (undefined method `reset_instance')

2018-09-15 Thread Santiago Vila
Package: src:ruby-bourne
Version: 1.6.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=ruby --with ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   dh_auto_build -i -O--buildsystem=ruby
dh_ruby --build
   dh_ruby --build
   dh_auto_test -i -O--buildsystem=ruby
dh_ruby --test
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=ruby --with ruby
   dh_testroot -i -O--buildsystem=ruby
   dh_prep -i -O--buildsystem=ruby

[... snipped ...]

===
Error: test_passes_if_invocation_count_correct(PureHaveReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/<>/test/unit/have_received_test.rb:13:in `teardown'
===
E
===
Error: test_passes_if_invocation_exists(PureHaveReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/<>/test/unit/have_received_test.rb:13:in `teardown'
===
E
===
Error: 
test_passes_if_invocation_exists_for_impersonating_mock(PureHaveReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/<>/test/unit/have_received_test.rb:13:in `teardown'
===
E
===
Error: 
test_passes_if_invocation_exists_with_exact_arguments(PureHaveReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/<>/test/unit/have_received_test.rb:13:in `teardown'
===
E
===
Error: 
test_passes_if_invocation_exists_with_wildcard_arguments(PureHaveReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/<>/test/unit/have_received_test.rb:13:in `teardown'
===
...
Finished in 0.158188284 seconds.
---
137 tests, 365 assertions, 0 failures, 33 errors, 0 pendings, 0 omissions, 0 
notifications
99.2701% passed
---
866.06 tests/s, 2307.38 assertions/s
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-bourne returned 
exit code 1
make: *** [debian/rules:6: binary-indep] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The build was made in my autobuilder on buster with "dpkg-buildpackage -A"
but it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-bourne.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.



Bug#908862: neutron: FTBFS (failing tests)

2018-09-15 Thread Santiago Vila
Package: src:neutron
Version: 2:13.0.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package but it failed:


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python3,systemd
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_autoreconf -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions

[... snipped ...]

  File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
self.force_reraise()
  File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
six.reraise(self.type_, self.value, self.tb)
  File "/usr/lib/python3/dist-packages/six.py", line 693, in reraise
raise value
  File "/usr/lib/python3/dist-packages/neutron_lib/db/api.py", line 179, in 
wrapped
return f(*dup_args, **dup_kwargs)
  File "/<>/neutron/plugins/ml2/drivers/type_tunnel.py", line 154, 
in sync_allocations
allocs = ctx.session.query(self.model).all()
  File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 2783, in 
all
return list(self)
  File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 2935, in 
__iter__
return self._execute_and_instances(context)
  File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 2958, in 
_execute_and_instances
result = conn.execute(querycontext.statement, self._params)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 948, in 
execute
return meth(self, multiparams, params)
  File "/usr/lib/python3/dist-packages/sqlalchemy/sql/elements.py", line 269, 
in _execute_on_connection
return connection._execute_clauseelement(self, multiparams, params)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1060, 
in _execute_clauseelement
compiled_sql, distilled_params
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1200, 
in _execute_context
context)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1409, 
in _handle_dbapi_exception
util.raise_from_cause(newraise, exc_info)
  File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 203, in 
raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 186, in 
reraise
raise value.with_traceback(tb)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1193, 
in _execute_context
context)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 508, 
in do_execute
cursor.execute(statement, parameters)
oslo_db.exception.DBNonExistentTable: (sqlite3.OperationalError) no such table: 
ml2_geneve_allocations [SQL: 'SELECT ml2_geneve_allocations.geneve_vni AS 
ml2_geneve_allocations_geneve_vni, ml2_geneve_allocations.allocated AS 
ml2_geneve_allocations_allocated \nFROM ml2_geneve_allocations'] (Background on 
this error at: http://sqlalche.me/e/e3q8)


--
Ran 14783 tests in 3712.856s

FAILED (failures=292, skipped=1221)
make[1]: *** [debian/rules:46: override_dh_install] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
on buster but it also fails here in buster and sid:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neutron.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Please re-re-reconsider uploading packages in source-only form 
(dpkg-buildpackage -S).
I can't compare my build log with the official one because there is
simply no official build log:

https://buildd.debian.org/status/package.php?p=neutron

Thanks.



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

2018-09-15 Thread TS
TS schrieb/wrote:
> Hello Axel,
> 
> thanks for uploading 5.6.2, but no luck.
> 
> I still get reliable:
> 
> % zprofile
> [7]  + 10408 suspended (tty output)
> 
> % pZSH_VERSION
> scalar-readonly  ZSH_VERSION='5.6.2'

After downgrading Zsh to 5.4.2-3...

% asi zsh
izsh  |  5.4.2-3   |  5.6.2-1
izsh-common   |  5.4.2-3   |  5.6.2-1
izsh-doc  |  5.4.2-3   |  5.6.2-1

% policy zsh
zsh:
  Installed: 5.4.2-3
  Candidate: 5.6.2-1
  Version table:
 5.6.2-1 500
500 http://ftp2.de.debian.org/debian unstable/main amd64 Packages
 5.6.1-1 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
 *** 5.4.2-3 500
500 file:/home/archive-local/local local/private amd64 Packages
100 /var/lib/dpkg/status


...i am not able to reproduce the "[7]  + 10408 suspended (tty output)" thing.


HTH



kind regards,

 Thilo



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

2018-09-15 Thread Hans Joachim Desserud

Package: drascula
Version: 1.0+ds2-3
Severity: grave

Dear Maintainer,

When attempting to run drascula it fails, and shows the following error:
Incorrect version of the 'drascula.dat' engine data file found. Expected 
5.0 but got 4.0.


This was originally reported in Ubuntu as
https://bugs.launchpad.net/ubuntu/+source/drascula/+bug/1792016
but I found it also affects Debian Sid.

-- 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_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)
LSM: AppArmor: enabled

Versions of packages drascula depends on:
ii  scummvm  2.0.0+dfsg-1+b1

Versions of packages drascula recommends:
ii  drascula-music  1.0+ds2-3

Versions of packages drascula suggests:
pn  drascula-french   
pn  drascula-german   
pn  drascula-italian  
pn  drascula-spanish  

-- no debconf information


--
mvh / best regards
Hans Joachim Desserud
http://desserud.org



Bug#907493: ghostscript breaks cups autopkgtest: test times out

2018-09-15 Thread Jonas Smedegaard
Quoting Paul Gevers (2018-09-15 07:41:54)
> On 14-09-18 22:26, Jonas Smedegaard wrote:
> > Another release of Ghostscript is now in experimental.  Can someone 
> > please test if those autopkgtests still fail?
> 
> 9.25~dfsg-1~exp1 passed the cups test.
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/cups/994233/log.gz

Great!  I'll make a release for unstable now.

Thanks for all the help to everyone involved!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


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

2018-09-15 Thread TS
--  --

> After downgrading Zsh to 5.4.2-3...
--  --

Tested with 5.5.1-1

% asi zsh
izsh  |  5.5.1-1   |  5.6.2-1
izsh-common   |  5.5.1-1   |  5.6.2-1
izsh-doc  |  5.5.1-1   |  5.6.2-1

> 
> 
> ...i am not able to reproduce the "[7]  + 10408 suspended (tty output)" thing.

up to 5.5.1-1 seem fine, problem starts with 5.6


> 
> 
> HTH
> 
> 
> 
> kind regards,
> 
>  Thilo
> 



Bug#908865: exim4: Default CHECK_RCPT_REMOTE_LOCALPARTS blocks legal email addresses (in particular the % character)

2018-09-15 Thread Rainer Dorsch
Package: exim4
Version: 4.84.2-2+deb8u5
Severity: important
Tags: patch

Dear Maintainer,

I just realized that the default configuration of exim4 in Debian blocks legal 
email addresses with legel syntax.

E.g. list%u...@gmx.de is rejected and generates a 

restricted characters in address

entry in the rejectlog.

These email addresses are used by the most popular German email provider for 
distribution lists

https://hilfe.gmx.net/email/einstellungen/verteiler-anlegen.html

(I applogize for the German page, but I did not find an English version).


I changed CHECK_RCPT_REMOTE_LOCALPARTS by adding

# accept % in email addresses (local part, i.e. not domain)
# This PCRE specifies regular expressions which when matched, exim4 will reject 
the message
# The : seems to be a logical or
# Default
# CHECK_RCPT_REMOTE_LOCALPARTS = ^[./|] : ^.*[@%!`#&?] : ^.*/\\.\\./
CHECK_RCPT_REMOTE_LOCALPARTS = ^[./|] : ^.*[@!`#&?] : ^.*/\\.\\./

to /etc/exim4/conf.d/main/00_localconfig

I suggest to change the apply this change to the default of 
CHECK_RCPT_REMOTE_LOCALPARTS if there is no strong reason not to do that.

Certainly any other way to validate this legal (and probably reasonably common 
email addresses in Germany) is equally welcome.

Thanks
Rainer

PS: Although I would expect that this issue affects quite a few people in 
Germany, I did not find another matching bug report. If I missed it, please 
make this a duplicate.


-- Package-specific info:
Exim version 4.84_2 #1 built 10-Feb-2018 14:37:56
Copyright (c) University of Cambridge, 1995 - 2014
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2014
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DKIM Old_Demime PRDR OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='internet'
dc_other_hostnames='bokomoko.de;fdor.de'
dc_local_interfaces=''
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'
mailname:bokomoko.de

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

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

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  exim4-base 4.84.2-2+deb8u5
ii  exim4-daemon-heavy 4.84.2-2+deb8u5

exim4 recommends no packages.

exim4 suggests no packages.

-- debconf information:
* exim4/drec:



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

2018-09-15 Thread Andrej Shadura
Control: tag -1 upstream wontfix

On Sat, 15 Sep 2018 10:19:43 +0200 Bernd Schumacher  wrote:
> Package: dash
> Version: 0.5.10.2-1
> Severity: normal
> 
> -- Description of the problem --
> Next commands are executed as expected:
> bs@sid:~$ dash
> $ man dash | grep "Output a backslash"
> \\  Output a backslash.
> $ echo "\\"
> \
> $ echo "c"
> c
> $ exit
> bs@sid:~$ 
> 
> Next command is executed, but not as expected and reason for this bugreport:
> bs@sid:~$ dash
> $ echo "\\c"
> $ exit
> bs@sid:~$ 
> 
> Next commands are workarounds, that behave as expected, but without dash echo
> bs@sid:~$ dash
> $ /bin/echo "\\c"
> \c
> $ bash -c 'echo "\\c"'
> \c
> $ exit
> bs@sid:~$ 
> 
> -- My assumption --
> It seems, dash interprets "\\c" like "\c" which means that Subsequent output 
> is 
> suppressed, as shown in the manpage.
> 
> If this bugreport is considered as valid by the developers, I believe the 
> same 
> bug may also be in other shells like 'busybox sh', 'mksh' and 'posh' and I 
> will 
> double check this suspicion and report additional bug reports.

This does not appear to be a bug, since dash’s echo interprets escapes
by default:

https://www.mail-archive.com/dash@vger.kernel.org/msg01713.html

-- 
Cheers,
  Andrej



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

2018-09-15 Thread TS
--  --

> 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.




kind regards,

 Thilo



Bug#908866: tcpdf: CVE-2018-17057

2018-09-15 Thread Salvatore Bonaccorso
Source: tcpdf
Version: 6.2.13+dfsg-1
Severity: grave
Tags: patch security upstream

Hi,

The following vulnerability was published for tcpdf.

CVE-2018-17057[0]:
| An issue was discovered in TCPDF before 6.2.22. Attackers can trigger
| deserialization of arbitrary data via the phar:// wrapper.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-17057
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17057
[1] 
https://github.com/tecnickcom/TCPDF/commit/1861e33fe05f653b67d070f7c106463e7a5c26e

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#879863: developer-reference conflicts with Policy on priority "extra" vs "optional"

2018-09-15 Thread Tobias Frost
Control: tags -1 pending

MR has been merged.



Bug#907605: developers-reference: Alioth references in README-contrib

2018-09-15 Thread Tobias Frost
Control: tags -1 pending

On Thu, 30 Aug 2018 08:20:19 +0200 Tobias Frost >  
> I've preaded this MR for it:
> https://salsa.debian.org/debian/developers-reference/merge_requests/2
> 
MR is merged. (Thanks Raphaël!)

-- 
tobi



Bug#891620: Transition of linphone

2018-09-15 Thread Dr. Tobias Quathamer
Dear all,

unfortunately, there's basically no progress in this bug report, as far
as I can tell. So I think that it's unlikely that kopete will be able to
build with libmediastreamer 2.16.

Would it be an option to provide *both* library versions for buster? We
could use the new source package "mediastreamer2", which is in
experimental. We would need to rename the binary packages built from
that source package, e.g. like this:

  libmediastreamer-base10 -> libmediastreamer2-base10
  libmediastreamer-dev-> libmediastreamer2-dev
  libmediastreamer-voip10 -> libmediastreamer2-voip10

This way, the new linphone version could depend on libmediastreamer2-dev
instead of libmediastreamer-dev, using the new library version.

For kopete, we create a new source package and split off the
mediastreamer (and ortp) libraries from the old linphone package.

The package could be named e.g. "mediastreamer" (without the "2") and
build the binary packages

  libmediastreamer-base3
  libmediastreamer-dev
  libortp-dev
  libortp9

This way, kopete can still use the old library for buster, while
allowing the new version of linphone into buster as well.

Considering that the freeze is only a few months away, I doubt that we
otherwise have a chance to get linphone in buster in time.

Would this be acceptable for the release team as well? Or am I missing
something here?

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature


Bug#908867: developers-reference: Updated German translation

2018-09-15 Thread Tobias Frost
Package: src:developers-reference
Version: 3.4.20
Severity: normal
Tags: patch

Please see the merge request 
https://salsa.debian.org/debian/developers-reference/merge_requests/3

(As soon as the salvaging MR is merged, I will also translate this)

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#842308: Intent to NMU colplot to fix longstanding l10n bugs

2018-09-15 Thread Helge Kreutzmann
Hello Troy,
I intend to NMU colplot early October to fix longstanding l10n
bugs[1]. The changelog would be something like the following:

colplot (5.0.1-4.1) UNRELEASED; urgency=medium

  * Non-maintainer upload.
  * Update Dutch translation (Closes: #821448)
  * Add Danish translation (Closes: #830644)
  * Update German translation (Closes: #842308)
  * Update Italian translation (Closes: #846930)
  * Update Portuguese translation (Closes: #858654)
  * Update Russian translation (Closes: #883991)
  * Add the copyright of the translators to debian/copyright

 -- Helge Kreutzmann   Sat, 15 Sep 2018 11:52:55 +0200

Please tell me if you are currently preparing a new release yourself
and would like me to skip the NMU.

Greetings

   Helge

[1] https://i18n.debian.org/nmu-radar/nmu_bypackage.html

-- 
  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#908868: RFH: docker.io -- Linux container runtime

2018-09-15 Thread Dmitry Smirnov
Package: wnpp
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org
Control: affects -1 docker.io

docker.io is a very demanding package to maintain.
Maintaining Docker is a big commitment and more maintainers are needed.

Any help is appreciated; most of the effort is likely to be with Docker's 
dependency tree.

-- 
Regards,
 Dmitry Smirnov.

---

Continuous effort - not strength or intelligence - is the key to unlocking
our potential.
-- Winston Churchill


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


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

2018-09-15 Thread Reiner Herrmann
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)


signature.asc
Description: PGP signature


Bug#907889: Uses --without systemd and overrides for dh_installsystemd

2018-09-15 Thread Peter Pentchev
Control: tag -1 + confirmed pending

On Mon, Sep 03, 2018 at 07:07:40PM +0200, Michael Biebl wrote:
> Source: dante
> Version: 1.4.2+dfsg-3
> Severity: normal
> 
> Hi,
> 
> I noticed that your package uses dh '@' --without systemd
> and at the same time overrides for dh_installsystemd.
> As you are using dh_installsystemd, it means you must be using dh compat
> 11 (btw, you should add a debian/compat for that).
> But in compat level 11, the systemd sequence has been removed, so it's
> rather pointless to have a --without systemd.

Thanks for noticing this; I removed the --without systemd invocation in
my Git repository, the change will be in the next dante upload.

Thanks for making Debian better, and keep up the great work!

Best regards,
Peter

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


signature.asc
Description: PGP signature


Bug#895320: ps2pdf crashes

2018-09-15 Thread Jonas Smedegaard
Quoting Jonas Smedegaard (2018-09-14 22:33:14)
> A new release of ghostscript is now in experimental.
> 
> Could you please help test if that succeeds?

Didn't help.  But neither do downgrading to 9.22~dfsg-2.1 in unstable 
since 2018-04-20.  Seems the cause of this is somewhere else than 
ghostscript.

texlive, perhaps?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


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

2018-09-15 Thread Michael Tsang
Package: korganizer
Version: 4:17.12.3-2
Severity: normal
Tags: l10n

Dear Maintainer,

The date of Tuen Ng Festival in Hong Kong is wrong in korganizer. The calendar
shows 7 May 2019, however, according to the gov't website, it should be 7 June
2019.

The authoritative source can be found below.

https://www.gov.hk/en/about/abouthk/holiday/2019.htm

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

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

Versions of packages korganizer depends on:
ii  kdepim-runtime   4:17.12.3-2
ii  kio  5.49.0-1
ii  libc62.27-6
ii  libgcc1  1:8.2.0-6
ii  libkf5akonadicalendar5abi1   4:17.12.3-1
ii  libkf5akonadicontact54:17.12.3-2
ii  libkf5akonadicore5abi1   4:17.12.3-3
ii  libkf5akonadimime5   4:17.12.3-1
ii  libkf5akonadinotes5  4:17.12.3-1
ii  libkf5akonadisearchpim5  4:17.12.3-1
ii  libkf5akonadiwidgets5abi14:17.12.3-3
ii  libkf5calendarcore5abi1  4:17.12.3-1
ii  libkf5calendarsupport5abi1   4:17.12.3-1
ii  libkf5calendarutils5 4:17.12.3-1
ii  libkf5codecs55.49.0-1
ii  libkf5completion55.49.0-1
ii  libkf5configcore55.49.0-1
ii  libkf5configgui5 5.49.0-1
ii  libkf5configwidgets5 5.49.0-1
ii  libkf5contacts5  4:17.12.3-1
ii  libkf5coreaddons55.49.0-1
ii  libkf5crash5 5.49.0-1
ii  libkf5dbusaddons55.49.0-1
ii  libkf5eventviews54:17.12.3-2
ii  libkf5holidays5  1:5.49.0-1
ii  libkf5i18n5  5.49.0-1
ii  libkf5iconthemes55.49.0-1
ii  libkf5identitymanagement517.12.3-1
ii  libkf5incidenceeditor5abi1   17.12.3-2
ii  libkf5itemmodels55.49.0-1
ii  libkf5itemviews5 5.49.0-1
ii  libkf5jobwidgets55.49.0-1
ii  libkf5kcmutils5  5.49.0-1
ii  libkf5kdepimdbusinterfaces5  4:17.12.3-1
ii  libkf5kiocore5   5.49.0-1
ii  libkf5kiowidgets55.49.0-1
ii  libkf5kontactinterface5  17.12.3-1
ii  libkf5libkdepim-plugins  4:17.12.3-1
ii  libkf5libkdepim5 4:17.12.3-1
ii  libkf5libkdepimakonadi5  4:17.12.3-1
ii  libkf5mailtransport5 17.12.3-1
ii  libkf5mailtransportakonadi5  17.12.3-1
ii  libkf5mime5abi1  17.12.3-2
ii  libkf5newstuff5  5.49.0-1
ii  libkf5notifications5 5.49.0-1
ii  libkf5parts5 5.49.0-1
ii  libkf5pimcommon5abi1 4:17.12.3-1
ii  libkf5pimcommonakonadi5  4:17.12.3-1
ii  libkf5pimtextedit5abi1   17.12.3-2
ii  libkf5service-bin5.49.0-1
ii  libkf5service5   5.49.0-1
ii  libkf5widgetsaddons5 5.49.0-1
ii  libkf5windowsystem5  5.49.0-1
ii  libkf5xmlgui55.49.0-1
ii  libphonon4qt5-4  4:4.10.1-1
ii  libqt5core5a 5.11.1+dfsg-8
ii  libqt5dbus5  5.11.1+dfsg-8
ii  libqt5gui5   5.11.1+dfsg-8
ii  libqt5widgets5   5.11.1+dfsg-8
ii  libstdc++6   8.2.0-6
ii  phonon4qt5   4:4.10.1-1

korganizer recommends no packages.

korganizer suggests no packages.

-- no debconf information



Bug#908871: cups: completed jobs stay in queue

2018-09-15 Thread Felix C. Stegerman
Package: cups
Version: 2.2.8-5
Severity: normal

Dear Maintainer,

Wondering why my printer didn't seem to want to print anymore, I
noticed that completed print jobs stay in the queue, preventing any
subsequent jobs from printing (unless I lprm the completed job).

Tried with lpr, lp and printing from chromium.  Same results.

Since I don't print very often, I don't know exactly when this change
occurred, but everything was working fine about a month ago AFAIK.

Printer: HP LaserJet p2015n Series, hpcups 3.17.1 (via JetDirect).

Happy to help debug this if you let me know what I can try.

Thanks.

- Felix

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

Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii  cups-client2.2.8-5
ii  cups-common2.2.8-5
ii  cups-core-drivers  2.2.8-5
ii  cups-daemon2.2.8-5
ii  cups-filters   1.21.2-1
ii  cups-ppdc  2.2.8-5
ii  cups-server-common 2.2.8-5
ii  debconf [debconf-2.0]  1.5.69
ii  ghostscript9.22~dfsg-3
ii  libavahi-client3   0.7-4
ii  libavahi-common3   0.7-4
ii  libc-bin   2.27-6
ii  libc6  2.27-6
ii  libcups2   2.2.8-5
ii  libcupscgi12.2.8-5
ii  libcupsimage2  2.2.8-5
ii  libcupsmime1   2.2.8-5
ii  libcupsppdc1   2.2.8-5
ii  libgcc11:8.2.0-6
ii  libstdc++6 8.2.0-6
ii  libusb-1.0-0   2:1.0.22-2
ii  poppler-utils  0.63.0-2
ii  procps 2:3.3.15-2

Versions of packages cups recommends:
ii  avahi-daemon 0.7-4
ii  colord   1.4.3-3
ii  cups-filters [ghostscript-cups]  1.21.2-1
ii  printer-driver-gutenprint5.2.13-2+b1

Versions of packages cups suggests:
ii  cups-bsd   2.2.8-5
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20180604-1
ii  hplip  3.17.10+repack0-5
ii  printer-driver-hpcups  3.17.10+repack0-5
ii  smbclient  2:4.8.5+dfsg-1
ii  udev   239-9

-- debconf information excluded



Bug#832730: add option to mount /lib/live/mount/medium read-write

2018-09-15 Thread Daniel Baumann
close 832730 20161101-1
thanks

Hi,

this has actually been already fixed for stretch, hence closing the bug.

Regards,
Daniel



Bug#908872: ITP: node-pentest-tool-lite -- Check the website for common vulnerabilities.

2018-09-15 Thread Udit Gupta
Package: wnpp
Severity: wishlist
Owner: Udit Gupta 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name : node-pentest-tool-lite
Version : 0.0.13
Upstream Author : Matej Jellus  (
https://www.juffalow.com)
* URL : https://github.com/juffalow/pentest-tool-lite
* License : Expat
Programming Lang: JavaScript
Description : A tool to check the websites common vulnerabilities
.
It checks the common vulnerabilities like
if http redirects to https
if HSTS is set
if cookies has secure and httpOnly flags
if directory indexing is enabled
if X-Frame-Options header is set
if X-XSS-Protection header is set
if server fingerprint header is set
if all JavaScript & CSS files are accessible
if all JavaScript & CSS files are minified
if any of JavaScript files contains console logs
if all JavaScript & CSS files have caching header set
if all JavaScript & CSS files have X-Content-Type-Options header set
if references / links are accessible
if wp-admin is accessible
if generator is disabled / WordPress version is hidden
.
Node.js is an event-based server-side JavaScript engine.


Bug#908873: grpc: Please provide a more current version in unstable, including Python bindings

2018-09-15 Thread Hilko Bengen
Source: grpc
Version: 1.3.2-1
Severity: normal
Control: block 908848 by -1

Dear Maintainers,

it is good to see that things have progressed in experimental. I am
going to need the Python bindings for my fleetspeak ITP (#908848).

Please let me know if I can help in any way.

Cheers,
-Hilko



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

2018-09-15 Thread Michal Arbet
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.

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

Expected result is that debconf should ask for database backend , database
administrative account, password, an app username and password like it is
in other projects ( for example keystone is working good )


Thanks,
Michal Arbet


Bug#908879: pyparted: FTBFS randomly (ImportError: No module named _ped)

2018-09-15 Thread Santiago Vila
Package: src:pyparted
Version: 3.11.1-12
Severity: important
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem pybuild --with python2,python3
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python2.7-dbg setup.py config 
running config
I: pybuild base:217: python3.6 setup.py config 
running config
I: pybuild base:217: python3.6-dbg setup.py config 
running config

[... snipped ...]

  File "/<>/tests/test_parted_alignment.py", line 23, in 
import _ped
ImportError: No module named _ped


==
ERROR: tests.test_parted_geometry (unittest.loader.ModuleImportFailure)
--
ImportError: Failed to import test module: tests.test_parted_geometry
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/unittest/loader.py", line 232, in 
_get_module_from_name
__import__(name)
  File "/<>/tests/test_parted_geometry.py", line 23, in 
import parted
  File 
"/<>/.pybuild/cpython2_2.7_dbg_parted/build/parted/__init__.py", 
line 33, in 
import _ped
ImportError: No module named _ped


==
ERROR: tests.test__ped_chsgeometry (unittest.loader.ModuleImportFailure)
--
ImportError: Failed to import test module: tests.test__ped_chsgeometry
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/unittest/loader.py", line 232, in 
_get_module_from_name
__import__(name)
  File "/<>/tests/test__ped_chsgeometry.py", line 22, in 
import _ped
ImportError: No module named _ped


--
Ran 22 tests in 0.008s

FAILED (errors=18, skipped=4)
make[2]: *** [Makefile:42: test] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:18: override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:9: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A" but a
similar error happens in reproducible builds in a random way, for example,
here:

https://tests.reproducible-builds.org/debian/logs/unstable/i386/pyparted_3.11.1-12.build2.log.gz

I've put a bunch of my own build logs here:

https://people.debian.org/~sanvila/build-logs/pyparted/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

If you could not reproduce this, please say so and I could give you
access to a machine where it happens all the time.

Thanks.



Bug#908880: debian-edu-config: Stop using dh_gconf

2018-09-15 Thread Jeremy Bicha
Source: debian-edu-config
Version: 2.10.35
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf

Please stop using dh_gconf. We intend to remove it during the Bullseye
cycle. See https://bugs.debian.org/908845 .

This file isn't useful since GNOME hasn't used gconf in years so this
setting is just being ignored. (I don't see any similar setting in
gsettings.)

https://salsa.debian.org/debian-edu/debian-edu-config/blob/master/debian/gconf-defaults

Thanks,
Jeremy Bicha



Bug#908881: gwaei: Drop unused dh_gconf

2018-09-15 Thread Jeremy Bicha
Source: gwaei
Version: 3.6.2-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf

Please stop using dh_gconf. We intend to remove it during the Bullseye
cycle. See https://bugs.debian.org/908845 .

Since gwaei doesn't ship any gconf schemas, it's not being used anyway.

I recommend converting your debian/rules to the simple "dh7 style"
rules. That will handle a lot of things automatically for you without
you missing anything or adding rules that shouldn't be there.

Thanks,
Jeremy Bicha



Bug#903393: console-setup 1.185 WARNING: Unknown X keysym "dead_belowmacron"

2018-09-15 Thread xiscu
Dear Developers,
I'm able to reproduce it also on 1.185:

# apt policy console-setup
console-setup:
  Installed: 1.185
  Candidate: 1.185
  Version table:
 *** 1.185 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
 10 http://ftp.de.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

# update-initramfs -u||echo "Failed"
update-initramfs: Generating /boot/initrd.img-4.18.0-1-amd64
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"

Regards,
xiscu



Bug#908882: revolt: Drop unused dh_gconf

2018-09-15 Thread Jeremy Bicha
Source: revolt
Version: 0.0+git20170627.3f5112b-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
X-Debbugs-CC: uho...@debian.org

Please stop using dh_gconf. We intend to remove it during the Bullseye
cycle. See https://bugs.debian.org/908845 .

As far as I can tell, revolt doesn't use gconf at all so the line
should just be removed from debian/rules.

Thanks,
Jeremy Bicha



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

2018-09-15 Thread Helge Kreutzmann
Hello Afif,
On Sun, May 06, 2018 at 06:51:04AM +, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 898034: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898034.

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?

Thanks for maintaining adduser

  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#906877: RFS: yuma123/2.11-1

2018-09-15 Thread Herbert Fortes

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#908884: i2p: FTBFS (autobuilder hangs)

2018-09-15 Thread Santiago Vila
Package: src:i2p
Version: 0.9.36-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh_prep
mkdir -p /<>/installer/lib/wrapper/all
ln -sf /usr/share/java/wrapper.jar 
/<>/installer/lib/wrapper/all/wrapper.jar
if [ ! -e /<>/debian/routerversion.java.bak ]; then \
cp /<>/router/java/src/net/i2p/router/RouterVersion.java 
/<>/debian/routerversion.java.bak; \
fi
sed -e "s/\(.*EXTRA\ =\ \)[^ ]*\"\(.*\)\"/\1\"\2-$EXTRAPREFIX$DEBIANVERSION\"/" 
< /<>/router/java/src/net/i2p/router/RouterVersion.java > 
/<>/router/java/src/net/i2p/router/RouterVersion.java.tmp
mv -f /<>/router/java/src/net/i2p/router/RouterVersion.java.tmp 
/<>/router/java/src/net/i2p/router/RouterVersion.java
mkdir -p /<>/apps/jetty/jettylib
ln -sf /usr/share/java/jetty9-continuation.jar 
/<>/apps/jetty/jettylib/jetty-continuation.jar
ln -sf /usr/share/java/jetty9-deploy.jar 
/<>/apps/jetty/jettylib/jetty-deploy.jar
ln -sf /usr/share/java/jetty9-http.jar 
/<>/apps/jetty/jettylib/jetty-http.jar
ln -sf /usr/share/java/jetty9-io.jar 
/<>/apps/jetty/jettylib/jetty-io.jar
ln -sf /usr/share/java/jetty9-rewrite.jar 
/<>/apps/jetty/jettylib/jetty-rewrite-handler.jar
ln -sf /usr/share/java/jetty9-security.jar 
/<>/apps/jetty/jettylib/jetty-security.jar
ln -sf /usr/share/java/jetty9-servlet.jar 
/<>/apps/jetty/jettylib/jetty-servlet.jar
ln -sf /usr/share/java/jetty9-servlets.jar 
/<>/apps/jetty/jettylib/jetty-servlets.jar
ln -sf /usr/share/java/jetty9-start.jar 
/<>/apps/jetty/jettylib/jetty-start.jar
ln -sf /usr/share/java/jetty9-util.jar 
/<>/apps/jetty/jettylib/jetty-util.jar
ln -sf /usr/share/java/jetty9-webapp.jar 
/<>/apps/jetty/jettylib/jetty-webapp.jar
ln -sf /usr/share/java/jetty9-xml.jar 
/<>/apps/jetty/jettylib/jetty-xml.jar
ln -sf /usr/share/java/jetty9-server.jar 
/<>/apps/jetty/jettylib/org.mortbay.jetty.jar
ln -sf /usr/share/java/jetty9-jmx.jar 
/<>/apps/jetty/jettylib/org.mortbay.jmx.jar
ln -sf /usr/share/java/servlet-api-3.1.jar 
/<>/apps/jetty/jettylib/javax.servlet.jar
ln -sf /usr/share/java/jsp-api-2.3.jar 
/<>/apps/jetty/jettylib/jsp-api.jar
mkdir -p /<>/apps/jetty/jettylib
ln -sf /usr/share/java/tomcat8-api.jar 
/<>/apps/jetty/jettylib/tomcat-api.jar
ln -sf /usr/share/java/tomcat8-coyote.jar 
/<>/apps/jetty/jettylib/tomcat-coyote.jar
ln -sf /usr/share/java/tomcat8-el-api.jar 
/<>/apps/jetty/jettylib/commons-el.jar
ln -sf /usr/share/java/tomcat8-jasper.jar 
/<>/apps/jetty/jettylib/jasper-runtime.jar
ln -sf /usr/share/java/tomcat8-jasper-el.jar 
/<>/apps/jetty/jettylib/jasper-el.jar
ln -sf /usr/share/java/tomcat8-juli.jar 
/<>/apps/jetty/jettylib/commons-logging.jar
ln -sf /usr/share/java/tomcat8-util.jar 
/<>/apps/jetty/jettylib/tomcat-util.jar
ln -sf /usr/share/java/tomcat8-util-scan.jar 
/<>/apps/jetty/jettylib/tomcat-util-scan.jar
ln -sf /usr/share/java/taglibs-standard-spec.jar 
/<>/apps/susidns/src/lib/jstl.jar
ln -sf /usr/share/java/taglibs-standard-impl.jar 
/<>/apps/susidns/src/lib/standard.jar
ln -sf /usr/share/java/taglibs-standard-jstlel.jar 
/<>/apps/susidns/src/lib/jstlel.jar
ln -sf /usr/share/java/libintl.jar /<>/core/java/build/libintl.jar
ln -sf /usr/share/java/gnu-getopt.jar 
/<>/core/java/build/gnu-getopt.jar
TZ=UTC JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8 ant preppkg-unix javadoc
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
Buildfile: /<>/build.xml

checkForMtn:

getMtnRev:

getReleaseNumber:
 [echo] Release number is 0.9.36

getBuildNumber:
 [echo] Build number is 0-1

setBuildTimestamp:

buildProperties:
 [echo] Building version 0.9.36-0-1 (mtn rev unknown)

buildCore:

depend:

compile:
[mkdir] Created dir: /<>/core/java/build/obj
[javac] Compiling 353 source files to /<>/core/java/build/obj
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 7
[javac] /<>/core/java/src/net/i2p/I2PAppContext.java:37: 
warning: [deprecation] SimpleScheduler in net.i2p.util has been deprecated
[javac] import net.i2p.util.SimpleScheduler;
[javac]^
[javac] 
/<>/core/java/src/net/i2p/crypto/provider/I2PProvider.java:23: 
warning: [deprecation] Provider(String,double,String) in Provider has been 
deprecated
[javac] super(PROVIDER_NAME, 0.1, INFO);
[javac] ^
[javac] Note: 
/<>/core/java/src/net/i2p/util/SimpleByteCache.java uses unchecked 
or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 3 warnings

jarUpToDate:

listChangedFiles:

jar:
  [jar] Building jar: /<>/core/java/build/i2p.jar
 [copy] Copying 1 file to /<>/build

buildrouter:

depend:

dependVersion:

compile:
[mkdir] Created dir: /<>/router/java/build
[mkdir] Created dir: /<>/router/java/build/obj
[javac] Compiling 478 source files to /<>/router/java/build/obj
[javac] warning: [options] bootstrap class path not 

Bug#863972: [src:mesa]

2018-09-15 Thread Antonio Russo
Please find refreshed a patch by Andrew Cook [1], in merge request [2].

I have build the package on amd64 and i386, and confirmed that it works with 
gallium nine, e.g., [3].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781078
[2] https://salsa.debian.org/xorg-team/lib/mesa/merge_requests/3
[3] https://launchpad.net/~commendsarnex/+archive/ubuntu/winedri3



Bug#906610: lintian should check that changes and changelog distribution are identical

2018-09-15 Thread Chris Lamb
H Jakub et al.,

> lintian should check that changes and changelog distribution are
> identical

  < _jwilk> lamby: As I mentioned on #-devel, #906610 looks like a
duplicate of #542747, which is already fixed...
  < lamby> _jwilk: Please follow-up on the BTS, thanks
  
  [..]
  
  < lamby> _jwilk: Did you see « Fri 07 08:39 < lamby> _jwilk: Please
  follow-up on the BTS, thanks »  (+0100)
  < _jwilk> lamby: Yeah, but I would need to overcome my sheer laziness
first...

  [..]  
  
  < _jwilk> I pointed it out before upload...
  < _jwilk> (both to bug submitter and to Lintian maintainer)
  < lamby> _jwilk: Well… I didn't look into it, asking you to follow-up
   to the BTS.

I'll take the initiative and follow-up here. So, we need to revert this
change, or merge them, or...? Thanks in advance.


Best wishes,

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



Bug#908885: ITP: ring-kde -- Qt based client for the Ring daemon.

2018-09-15 Thread Scarlett Gately Moore
Package: wnpp
Severity: wishlist
Owner: Scarlett Gately Moore 

* Package name: ring-kde
  Version : 3.0.0
  Upstream Author : BlueSystems GmbH
* URL : https://download.kde.org/stable/ring-kde/
* License : LGPL-2.1+, GPL-3+, GPL 3, GPL-2+
  Programming Lang: C++
  Description : Qt based client for the Ring daemon.

Ring is a free and universal communication
platform which preserves the users' privacy and freedoms.
 .
 * A telephone: a simple tool to connect, communicate and share.
 * A teleconferencing tool: easily join calls to create conferences with
 multiple participants.
 * A media sharing tool: Ring supports a variety of video input options,
 including mutliple cameras and image and video files, and the selection of
 audio inputs and outputs; all this is supported by multiple high quality
 audio and video codecs.
 * A messenger: send text messeges during calls or out of calls
 (as long as your peer is connected).
 * A building block for your IoT project: re-use the universal communications
 technology of Ring with its portable library on your system of choice.

I plan on maintaining this.



Bug#764614: this is still failing

2018-09-15 Thread Pirate Praveen
Control:  fixed -1 5.8.0+ds3-1

On Thu, 19 Jul 2018 12:16:08 +0530 Pirate Praveen
 wrote:

> Control: forcemerge 904071 -1
>

> pravi@andhaka:/tmp/lirc$ npm install --production lirc

It is working now.

pravi@nishumbha:/tmp$ npm install --production lirc
npm WARN deprecated coffee-script@1.12.7: CoffeeScript on NPM has moved
to "coffeescript" (no hyphen)
npm WARN deprecated coffee-script@1.6.3: CoffeeScript on NPM has moved
to "coffeescript" (no hyphen)
npm WARN notice [SECURITY] uglify-js has the following vulnerability: 2
low. Go here for more details:
https://nodesecurity.io/advisories?search=uglify-js&version=2.2.5 - Run
`npm i npm@latest -g` to upgrade your npm version, and then `npm audit`
to get more info.
npm WARN deprecated coffee-script@1.5.0: CoffeeScript on NPM has moved
to "coffeescript" (no hyphen)
npm WARN notice [SECURITY] debug has the following vulnerability: 1 low.
Go here for more details:
https://nodesecurity.io/advisories?search=debug&version=2.6.8 - Run `npm
i npm@latest -g` to upgrade your npm version, and then `npm audit` to
get more info.
npm WARN notice [SECURITY] uglify-js has the following vulnerability: 2
low. Go here for more details:
https://nodesecurity.io/advisories?search=uglify-js&version=1.2.5 - Run
`npm i npm@latest -g` to upgrade your npm version, and then `npm audit`
to get more info.
npm WARN deprecated graceful-fs@1.1.14: please upgrade to graceful-fs 4
for compatibility with current and future versions of Node.js
npm WARN notice [SECURITY] mime has the following vulnerability: 1
moderate. Go here for more details:
https://nodesecurity.io/advisories?search=mime&version=1.2.9 - Run `npm
i npm@latest -g` to upgrade your npm version, and then `npm audit` to
get more info.
npm WARN notice [SECURITY] ws has the following vulnerabilities: 2 high,
1 low. Go here for more details:
https://nodesecurity.io/advisories?search=ws&version=0.4.32 - Run `npm i
npm@latest -g` to upgrade your npm version, and then `npm audit` to get
more info.
npm WARN notice [SECURITY] lactate has the following vulnerability: 1
high. Go here for more details:
https://nodesecurity.io/advisories?search=lactate&version=0.13.12 - Run
`npm i npm@latest -g` to upgrade your npm version, and then `npm audit`
to get more info.

> keygrip@0.2.4 install /tmp/node_modules/keygrip
> [ -x /usr/bin/nodejs ] && /usr/bin/nodejs ./install.js || node
./install.js


> ws@0.4.32 install /tmp/node_modules/ws
> (node-gyp rebuild 2> builderror.log) || (exit 0)

make: Entering directory '/tmp/node_modules/ws/build'
  CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
bufferutil.target.mk:97: recipe for target
'Release/obj.target/bufferutil/src/bufferutil.o' failed
make: Leaving directory '/tmp/node_modules/ws/build'
npm WARN saveError ENOENT: no such file or directory, open
'/tmp/package.json'
npm notice created a lockfile as package-lock.json. You should commit
this file.
npm WARN enoent ENOENT: no such file or directory, open '/tmp/package.json'
npm WARN tmp No description
npm WARN tmp No repository field.
npm WARN tmp No README data
npm WARN tmp No license field.

+ lirc@0.10.0
added 79 packages from 356 contributors in 22.689s



Bug#905674: #905674: please describe ftpmasters' official position

2018-09-15 Thread Adam Borowski
Hi!
It would be nice if we had an official ftpmasters' position.  So far, all
we have are remarks on IRC.

The case here is the package "parallel" having recentlish grown a demand for
either a citation or 1€.  This is explicitely forbidden by the GPL FAQ:
https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation
and interpreting the request as a demand rather than mere suggestion is
reinforced by the alternative being a (high) monetary fee rather than
nothing.

The issue has been raised by multiple people on multiple bug trackers.


Unless my analysis is wrong, I see the following options: either

* the demand is considered a part of the license, in which case the package
  needs to be moved to non-free or removed from the archive completely
  (depending whether the demand is considered overriding a part of the GPL3
  or being a conflicting addition)

* the demand is a part of the code only.  It then can be removed (as it
  causes practical problems like #884793), against express wishes of the
  upstream -- although in this case, per the legal demands made by upstream
  in newer versions, we'd need to rename the package[1][2].

  + renaming doesn't sound like a bad idea: pkg:parallel diverts
/usr/bin/parallel from pkg:moreutils despite having a completely
incompatible interface, thus breaking unrelated software that depends
on moreutils.  Folks on IRC seemed to be of opinion that this means
"programs with different functionality but with the same filenames"
rather than "two programs having the same functionality but different
implementations" (Policy 10.1) (authoritativeness of random folks on
IRC (even if otherwise qualified), again...).

In either case, four packages {,Build-}Depending on parallel would need to
be adjusted: freebayes roary symfony last-align.


[1]. Although how Ole Tange can claim trademark on a name used by Tollef
Fog Heen and others earlier is beyond me.  The US registration is for
"GNU Parallel" rather than "parallel"...

[2]. And/or executable name.
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.



Bug#850322: npm: CVE-2016-3956

2018-09-15 Thread Pirate Praveen
Control: fixed -1 5.8.0+ds-1

On Thu, 05 Jan 2017 22:16:38 +0100 Salvatore Bonaccorso
 wrote:

> the following vulnerability was published for npm.
>
> CVE-2016-3956[0]:
> | The CLI in npm before 2.15.1 and 3.x before 3.8.3, as used in Node.js
> | 0.10 before 0.10.44, 0.12 before 0.12.13, 4 before 4.4.2, and 5 before
> | 5.10.0, includes bearer tokens with arbitrary requests, which allows
> | remote HTTP servers to obtain sensitive information by reading
> | Authorization headers.
>
> No fix has been made for 1.x versions.
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

This bug was not noticed while uploading 5.8, so security tracker will
need a manual update.



Bug#908826: vagrant/stable is incompatible with virtualbox/stretch-backports (now 5.2)

2018-09-15 Thread Antonio Terceiro
On Fri, Sep 14, 2018 at 05:10:48PM +0200, Lucas Nussbaum wrote:
> Package: vagrant
> Version: 1.9.1+dfsg-1+deb9u1
> Severity: normal
> 
> Hi,
> 
> vagrant 1.9.1+dfsg-1+deb9u1 is now incompatible with virtualbox from
> stretch-backports (version 5.2.18-dfsg-1~bpo9+1). It worked fine with
> virtualbox 5.1.30-dfsg-1~bpo9+1.
> 
> vagrant from stretch-backports works fine with virtualbox from
> stretch-backports.
> 
> When starting vagrant, I get:
> $ vagrant up
> No usable default provider could be found for your system.
> 
> Vagrant relies on interactions with 3rd party systems, known as
> "providers", to provide Vagrant with resources to run development
> environments. Examples are VirtualBox, VMware, Hyper-V.
> 
> The easiest solution to this message is to install VirtualBox, which
> is available for free on all major platforms.
> 
> If you believe you already have a provider available, make sure it
> is properly installed and configured. You can see more details about
> why a particular provider isn't working by forcing usage with
> `vagrant up --provider=PROVIDER`, which should give you a more specific
> error message for that particular provider.
> 
> (while of course virtualbox is available, and works fine outside of
> Vagrant)

Can you please test the .deb from
https://people.debian.org/~terceiro/tmp/vagrant-stretch/
?


signature.asc
Description: PGP signature


Bug#904422: npm: complains about too-new nodejs

2018-09-15 Thread Pirate Praveen
On Tue, 24 Jul 2018 08:46:42 +0200 Matthias Urlichs
 wrote:
> Package: npm
> Version: 5.8.0+ds-1
> Severity: minor
>
> npm WARN npm npm does not support Node.js v10.4.0
> npm WARN npm You should probably upgrade to a newer version of node as we
> npm WARN npm can't make any promises that npm will work with this version.
> npm WARN npm Supported releases of Node.js are the latest release of
4, 6, 7, 8, 9.

> npm WARN npm You can find the latest version at https://nodejs.org/

npm 5.8 is now in unstable/testing and they have nodejs 8, so this only
affects nodejs in experimental.



Bug#742619: linux: Please reenable CONFIG_SCSI_PROC_FS

2018-09-15 Thread Mi

Please re-consider the "wontfix" decision.

This makes it impossible to use LTO tape drives on Debian, and it forced 
me to install CentOS on the machine controlling the tape loader, when 
all my other Linux machines are Debian.


Mi



Bug#875621: Still not fixed

2018-09-15 Thread Ben Hutchings
On Fri, 2018-09-14 at 09:16 +0200, Han Boetes wrote:
> > 
> > Source: linux
> > Source-Version: 4.13.10-1
> > We believe that the bug you reported is fixed in the latest version of
> > linux, which is due to be installed in the Debian FTP archive.
> 
> 
> Dear maintainer,
> 
> With every new kernel release I hope these simple instructions from the
> dmesg are followed:
> 
> psmouse serio2: synaptics: The touchpad can support a better bus than the
> > too old PS/2 protocol. Make sure MOUSE_PS2_SYNAPTICS_SMBUS and RMI4_SMB are
> > enabled to get a better touchpad experience.
> 
> 
> But every time I check I see:
> 
> % grep -i rmi4_smb /boot/config-4.18.0-1-amd64
> > # CONFIG_RMI4_SMB is not set
> 
> 
> Why is it so hard to enable this kernel option?!

We did it once before and it caused a regression (bug #880471).  So,
before we enable it again someone will need to investigate and check
that the regression won't happen again.

Ben.

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



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


Bug#908886: [wireless-tools] if-pre-up.d script includes ifconfig, but does not depend on net-tools

2018-09-15 Thread sch0rsch

Package: wireless-tools
Version: 30~pre9-12+b1

Error message on "ifup ":
DHCPOFFER of 192.168.0.8 from 192.168.0.1 DHCPACK of 192.168.0.8 from 
192.168.0.1 bound to 192.168.0.8 -- renewal in 610632848 seconds. 
/etc/network/if-pre-up.d/wireless-tools: 141: 
/etc/network/if-pre-up.d/wireless-tools: ifconfig: not found Error for 
wireless request "Set Power Management" (8B2C) : SET failed on device 
wlan0 ; Operation not permitted. Internet Systems Consortium DHCP Client 
4.3.5 Copyright 2004-2016 Internet Systems Consortium. All rights 
reserved. For info, please visit https://www.isc.org/software/dhcp/


Steps to reproduce:
1. Setup a WiFi device, where the driver does not allow to apply all 
WiFi settings, before its interface is up.
2. Setup the system to use "wireless-tools" and "ifupdown" to bring up 
the interfaces.

3. Remove the package "net-tools"
4. Reboot and/or "ifup "

Result:
- As "/etc/network/if-pre-up.d/wireless-tools" fails, not all WiFi 
settings are applied.


Debugging:
- It is due to "ifconfig" being called within the if-pre-up.d script, if 
it fails to apply at least one WiFi setting. This seems to be a rare 
case, where WiFi drivers do not allow to apply settings, before the WiFi 
interface is up. But to handle this, is the purpose of the script.
- This was no issue until and including Debian Wheezy, as the "ifupdown" 
package depended on "net-tools". But since Jessie, "ifupdown" depends on 
"iproute2" only, which replaces the nowadays as deprecated seen "net-tools".


Solutions:
1. Add "net-tools" to the dependency list of "wireless-tools". I do not 
recommend, as "net-tools" is seen as obsolete. Also, since 
"wireless-tools" does not depend on "ifupdown" and there are other 
methods to automate interface start (e.g. systemd-networkd, bypassing 
/etc/network/if-*), the dependency would not be always true.
2. Use "iproute2" commands to bring up the interface, since this is the 
direct replacement for "net-tools" and "ifupdown" itself is dependant 
for it.


Reference discussion:
- https://github.com/Fourdee/DietPi/issues/2070#issuecomment-421105192

Additions:
- We found this issue just by chance. The actual reason for applying the 
WiFi setting(s) failed, was a wrong entry, which then triggered the 
ifconfig call.
- We never faced this issue before on "DietPi" (Debian based) distro, 
even that for a while "net-tools" is not pre-installed any more. So the 
cases where WiFi drivers do not allow to apply settings pre-up seem to 
be very rare and/or settings are applied afterwards by other WiFi 
related tools.
- But I hope by having a look into the script, the issue is obvious 
enough to fixed, even that related errors cannot be replicated without 
special WiFi devices/drivers or simply wrong WiFi settings.


Best regards,

MichaIng



Bug#711810: npm: bash completion script clobbers $COMP_WORDBREAKS

2018-09-15 Thread Pirate Praveen
Control: fixed -1 5.8.0+ds-1

On Sat, 15 Aug 2015 13:25:50 -0600 Anthony Fok  wrote:

> There is a fix landed to the completion script in d7271b8 [2]
> – the lib/utils/completion.sh included in the tree at that
> version (which will be part of the next npm@2 release,
> coming out later tonight as npm@next) fixes this issue.
>
> The fix has been pushed to the @latest npm@2.13.5,
> which can be fetched by a simple "npm install npm".
>
> Please consider upgrading to 2.13.5 (See also Bug#794890),
> or at least fetch the lib/utils/completion.sh therein and
> put it in Debian's current npm-1.4.21.

We have 5.8.0 in the archive now.



Bug#908857: diffstat

2018-09-15 Thread Guenther Brunthaler
Adding statistics in order to provide an estimate about the extent of 
the of changes:


$ diffstat didiwiki_0.5-13_p1-2018.258.patch
 didi.c |7 +++
 http.c |6 ++
 wiki.c |   16 
 wikitext.h |8 +---
 4 files changed, 30 insertions(+), 7 deletions(-)



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

2018-09-15 Thread Sandro Knauß
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

--
On Samstag, 15. September 2018 13:15:43 CEST Michael Tsang wrote:
> Package: korganizer
> Version: 4:17.12.3-2
> Severity: normal
> Tags: l10n
> 
> Dear Maintainer,
> 
> The date of Tuen Ng Festival in Hong Kong is wrong in korganizer. The
> calendar shows 7 May 2019, however, according to the gov't website, it
> should be 7 June 2019.
> 
> The authoritative source can be found below.
> 
> https://www.gov.hk/en/about/abouthk/holiday/2019.htm
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_HK.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en_HK:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages korganizer depends on:
> ii  kdepim-runtime   4:17.12.3-2
> ii  kio  5.49.0-1
> ii  libc62.27-6
> ii  libgcc1  1:8.2.0-6
> ii  libkf5akonadicalendar5abi1   4:17.12.3-1
> ii  libkf5akonadicontact54:17.12.3-2
> ii  libkf5akonadicore5abi1   4:17.12.3-3
> ii  libkf5akonadimime5   4:17.12.3-1
> ii  libkf5akonadinotes5  4:17.12.3-1
> ii  libkf5akonadisearchpim5  4:17.12.3-1
> ii  libkf5akonadiwidgets5abi14:17.12.3-3
> ii  libkf5calendarcore5abi1  4:17.12.3-1
> ii  libkf5calendarsupport5abi1   4:17.12.3-1
> ii  libkf5calendarutils5 4:17.12.3-1
> ii  libkf5codecs55.49.0-1
> ii  libkf5completion55.49.0-1
> ii  libkf5configcore55.49.0-1
> ii  libkf5configgui5 5.49.0-1
> ii  libkf5configwidgets5 5.49.0-1
> ii  libkf5contacts5  4:17.12.3-1
> ii  libkf5coreaddons55.49.0-1
> ii  libkf5crash5 5.49.0-1
> ii  libkf5dbusaddons55.49.0-1
> ii  libkf5eventviews54:17.12.3-2
> ii  libkf5holidays5  1:5.49.0-1
> ii  libkf5i18n5  5.49.0-1
> ii  libkf5iconthemes55.49.0-1
> ii  libkf5identitymanagement517.12.3-1
> ii  libkf5incidenceeditor5abi1   17.12.3-2
> ii  libkf5itemmodels55.49.0-1
> ii  libkf5itemviews5 5.49.0-1
> ii  libkf5jobwidgets55.49.0-1
> ii  libkf5kcmutils5  5.49.0-1
> ii  libkf5kdepimdbusinterfaces5  4:17.12.3-1
> ii  libkf5kiocore5   5.49.0-1
> ii  libkf5kiowidgets55.49.0-1
> ii  libkf5kontactinterface5  17.12.3-1
> ii  libkf5libkdepim-plugins  4:17.12.3-1
> ii  libkf5libkdepim5 4:17.12.3-1
> ii  libkf5libkdepimakonadi5  4:17.12.3-1
> ii  libkf5mailtransport5 17.12.3-1
> ii  libkf5mailtransportakonadi5  17.12.3-1
> ii  libkf5mime5abi1  17.12.3-2
> ii  libkf5newstuff5  5.49.0-1
> ii  libkf5notifications5 5.49.0-1
> ii  libkf5parts5 5.49.0-1
> ii  libkf5pimcommon5abi1 4:17.12.3-1
> ii  libkf5pimcommonakonadi5  4:17.12.3-1
> ii  libkf5pimtextedit5abi1   17.12.3-2
> ii  libkf5service-bin5.49.0-1
> ii  libkf5service5   5.49.0-1
> ii  libkf5widgetsaddons5 5.49.0-1
> ii  libkf5windowsystem5  5.49.0-1
> ii  libkf5xmlgui55.49.0-1
> ii  libphonon4qt5-4  4:4.10.1-1
> ii  libqt5core5a 5.11.1+dfsg-8
> ii  libqt5dbus5  5.11.1+dfsg-8
> ii  libqt5gui5   5.11.1+dfsg-8
> ii  libqt5widgets5   5.11.1+dfsg-8
> ii  libstdc++6   8.2.0-6
> ii  phonon4qt5   4:4.10.1-1
> 
> korganizer recommends no packages.
> 
> korganizer suggests no packages.
> 
> -- no debconf information



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


Bug#850322: npm: CVE-2016-3956

2018-09-15 Thread Salvatore Bonaccorso
Hi!

On Sat, Sep 15, 2018 at 06:19:29PM +0530, Pirate Praveen wrote:
> Control: fixed -1 5.8.0+ds-1
> 
> On Thu, 05 Jan 2017 22:16:38 +0100 Salvatore Bonaccorso
>  wrote:
> 
> > the following vulnerability was published for npm.
> >
> > CVE-2016-3956[0]:
> > | The CLI in npm before 2.15.1 and 3.x before 3.8.3, as used in Node.js
> > | 0.10 before 0.10.44, 0.12 before 0.12.13, 4 before 4.4.2, and 5 before
> > | 5.10.0, includes bearer tokens with arbitrary requests, which allows
> > | remote HTTP servers to obtain sensitive information by reading
> > | Authorization headers.
> >
> > No fix has been made for 1.x versions.
> >
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> This bug was not noticed while uploading 5.8, so security tracker will
> need a manual update.

Thanks, I have updated the security-tracker information!

FTR, we never update automatically a fixed version.

Regards,
Salvatore



Bug#908799: Confirmation of Fix

2018-09-15 Thread Ron Lovell
New packages libcoarrays-openmpi-dev and libcaf-openmpi-3 2.2.0-3 do
resolve the issue on my system.

I'm proceeding on the assumption that cafrun(1) (from old package
open-coarrays-bin) might never return to Debian, so I'm switching to
mpiexec(1) on all my Linux VMs (the others being Fedora Rawhide and
openSUSE Tumbleweed). That seems to be working fine for me.

Thanks for the quick fix!
-- 
James Ronald Lovell 
Huntsville, AL, USA


Bug#896698: deprecating needs-recommends

2018-09-15 Thread Michael Biebl
Hi Paul

On Thu, 30 Aug 2018 12:03:31 +0200 Paul Gevers  wrote:
> I have just pushed commit 9fade8dcb501250f704da9c77af1f8e6165dc941 that
> documents that we want to remove the needs-recommends option as we
> discussed in https://lists.debian.org/debian-ci/2018/06/msg00016.html.

So I have this specific case where I found needs-recommends quite
convenient:
I have a package (firewalld) which has optional dependencies like ipset
or ebtables. If those are not installed, firewalld will log a warning
and continue with the functionality disabled.

I want to ship two autopkgtests:
One with recommends installed, in which case no errors and warnings are
allowed in the log.
One without recommends installed, in which case errors are not allowed
in the log, but warnings are.

Now, if needs-recommends is going to be deprecated/removed, I'll have to
specify the Recommends twice: once in debian/tests/control and
debian/control and I don't like this duplication as this is prone to get
out-of-sync.

Just wanted to provide a data point why it might be useful to keep
needs-recommends.

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#908887: dnsruby: include latest DNS trust anchor (KSK-2017)

2018-09-15 Thread Santiago R.R.
Source: dnsruby
Severity: important
Tags: upstream patch

Hi Ondřej,

The DNS Root Key Signing Key (KSK) Rollover is scheduled for 11 October
2018 [1]. After this date, DNS resolvers will need to have the new key
(KSK-2017) to perform DNSSEC validation.

[1] https://www.icann.org/news/announcement-2018-08-22-en

AFAICS, dnsruby has the KSK-2010 built-in [2], and enables dnssec by
default. Users or software relying on dnsruby may encounter problems
once the rollover occurs.

[2] https://sources.debian.org/src/dnsruby/1.54-2/lib/Dnsruby/dnssec.rb/#L82

Unless #760469 got fixed (dnsruby: Please use root zone hints, key or
anchor from dns-root-data package), dnsruby should also include the
KSK-2017 key. Upstream has added it in the current master branch:

https://github.com/alexdalitz/dnsruby/commit/55edc31a2150e4617edb6664d440e6141f535e6a

Best regards,

 -- Santiago

P.S. Since dnssec seems to be enabled by default, the bug severity could
be maybe higher. But I let Ondřej decide :)


signature.asc
Description: PGP signature


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

2018-09-15 Thread 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.


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

2018-09-15 Thread 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]

2018-09-15 Thread 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#908889: src:firefox-esr: Fix broken ppc64 build

2018-09-15 Thread 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#908870: korganizer: Tuen Ng Festival date in 2019 is wrong

2018-09-15 Thread 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#907586: Problem logging in to hppa debian porterbox panama.debian.net

2018-09-15 Thread 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#908890: developers-reference: As alioth is gone, replace references to Salsa

2018-09-15 Thread 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#908818: [Pkg-zsh-devel] Bug#908818: Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)

2018-09-15 Thread 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#888243: Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

2018-09-15 Thread 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#888546: Bug#888243: Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

2018-09-15 Thread 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

2018-09-15 Thread 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#908742: Want way to reset tar-ignore list

2018-09-15 Thread 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#908892: RFS: picocli/3.5.2-2 [RC]

2018-09-15 Thread 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#908861: Acknowledgement (dash: echo "\\c" does not print a backslash followed by c)

2018-09-15 Thread 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#908106: dpkg ignores ASCII file named *.so when building source package

2018-09-15 Thread 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#908893: stretch-pu: package globus-gsi-credential_7.11-1+deb9u1

2018-09-15 Thread 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(
+ &callback_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(
+ &callback_data_index);
+ 
diff -Nru globus-gsi-credent

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

2018-09-15 Thread 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&arch=all&ver=0.25-1&stamp=1536904015&raw=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

2018-09-15 Thread 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

2018-09-15 Thread 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#902809: want dgit smash-working-tree-timestamps [and 1 more messages]

2018-09-15 Thread 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#908895: RFP: node-eslint-restricted-globals -- A list of confusing globals that should be restricted to be used as globals

2018-09-15 Thread 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#908896: Algol 68 Genie source code page migrated

2018-09-15 Thread 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#908831: linux-image-4.18.0-1-amd64: After upgrade from kernel 4.17 to 4.18 virt-manager dosent work

2018-09-15 Thread 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)

2018-09-15 Thread 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) = self._req

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

2018-09-15 Thread 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#908898: ublock-origin: debian/watch does not work correctly

2018-09-15 Thread 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#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

2018-09-15 Thread 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#908899: reduce installation size

2018-09-15 Thread 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#908818: [Pkg-zsh-devel] Bug#908818: Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)

2018-09-15 Thread 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

2018-09-15 Thread 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#908900: diffoscope: tests fail with colord 1.4.3

2018-09-15 Thread 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#904302: Whether vendor-specific patch series should be permitted in the archive

2018-09-15 Thread 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#908897: filesystem location of the *.vbox-extpack file

2018-09-15 Thread 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

2018-09-15 Thread 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

2018-09-15 Thread 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#908898: ublock-origin: debian/watch does not work correctly

2018-09-15 Thread 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#853310: android-platform-system-core: ftbfs with GCC-7

2018-09-15 Thread 殷啟聰 | 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#908463: [Pkg-privacy-maintainers] Bug#908463: torbrowser-launcher: Fails to start "Web Content" processes due to outdated AppArmor policy

2018-09-15 Thread 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#908902: mercurial: hg commit -m 'my updates' (goes awry due to space in message)

2018-09-15 Thread 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#906877: RFS: yuma123/2.11-1

2018-09-15 Thread 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
>
>
>





  1   2   >