Bug#926180: New trouble

[Julien Puydt]

Hi,

the trouble seems to be that when generating the documentation, it tries 
to run examples to generate picture, and doesn't find a graphic card 
(even a virtual one).


I suggest to move the bug against libjogl2-java, as it might miss a 
depend on whatever is needed for correct operation.


JP

Bug#926207: iotop: unable to run on kernels with retpoline (spectre)

[Paul Wise]

Control: tags -1 + unreproducible fixed-upstream
Control: forwarded -1 
https://repo.or.cz/iotop.git/commit/7c51ce0e29bd135c216f18e18f0c4ab769af0d6f 
https://repo.or.cz/iotop.git/commit/0392b205b5c3973a326721c2e9f97f0fa2eefa82

On Mon, 2019-04-01 at 16:43 -0600, Neil Tallim wrote:

> I'm afraid there's a flaw in the version of iotop available in Debian (even in
> sid): retpoline support adds a blank line to /proc//status, which iotop 
> was
> not able to deal with before May of 2018. The effect of this is a crash with a
> Python stack-trace. It affects all usage of iotop on any kernels with spectre
> mitigation.

As far as I can tell the commit that added blank lines to the
/proc/*/status files was never added to Debian or mainline kernels and
indeed iotop works for me with Linux 4.19.28-2 from Debian unstable.

Could you provide some info I can use to reproduce this?

$ uname -rv
4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)

$ sudo sh -c 'grep -l "^ *$" /proc/*/status'

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: 
disabled, RSB filling

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#926211: python3-stdeb: --package argument not respected under Python 3

[Stuart Longland]

Package: python3-stdeb
Version: 0.8.5-1
Severity: normal

Dear Maintainer,

Hi,

Trying to build an updated `docker-compose` binary from
https://github.com/docker/compose.git on our CI server internally using
`stdeb` 0.8.5 on Debian Stretch in a Docker container:

* `python setup.py --command-package stdeb.command sdist_dsc --package
   docker-compose --debian-version=141debian9p8 bdist_deb` produces
  `docker-compose_1.25.0~dev0-141debian9p8_all.deb`
* `python3 setup.py --command-package stdeb.command sdist_dsc --package
   docker-compose --debian-version=140debian9p8 bdist_deb` produces
  `python3-docker-compose_1.25.0~dev0-139debian9p8_all.deb`

Why the discrepancy?

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

Kernel: Linux 4.18.3-vk4msl-ws-03489-gd26d3f0fab1a (SMP w/16 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages python3-stdeb depends on:
ii  debhelper   10.2.5
ii  python3 3.5.3-1
ii  python3-requests2.12.4-1
ii  python3-setuptools  33.1.1-1

Versions of packages python3-stdeb recommends:
ii  apt-file 3.1.4
ii  dpkg-dev 1.18.25
ii  python3-all  3.5.3-1

Versions of packages python3-stdeb suggests:
pn  python3-all-dev  

-- no debconf information

Bug#926210: teckit: new upstream version

[Norbert Preining]

Package: teckit
Version: 2.5.8+ds2-5
Severity: normal

Hi Daniel,

2.5.9 is out, do you want to work on it or should I do something?

Best

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

Kernel: Linux 5.0.5 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages teckit depends on:
ii  libc6   2.28-8
ii  libexpat1   2.2.6-1
ii  libgcc1 1:8.3.0-4
ii  libstdc++6  8.3.0-4
ii  libteckit0  2.5.8+ds2-5

teckit recommends no packages.

teckit suggests no packages.

-- no debconf information

Bug#452721: #452721 is kind of important

[Elliott Mitchell]

found 452721 4.8.5+shim4.10.2+xsa282-1+deb9u11
quit

I'm inclined to suggest #452721 is actually a bit more than merely
wishlist.  The ordering of domain start/restore/stop/save can be
extremely important.  The current behavior of the xendomains init script
is rather simplistic.

I would argue for the use of tagging along the lines of what was
standardized for init scripts.  Domains acting as LDAP/NIS/syslog would
need to start before fileserver domains.  Mailserver domains would start
after nearly all other domains had start.  These would likely be stopped
in /almost/ the reverse order (there could be reasons for
stopping/suspending them in an unrelated order).

Rather more interestingly, one might desire some domains to start in
parallel with some services started by init scripts; yet others to start
near the end of the init process.  Perhaps modify /etc/init.d/xendomains
to be called multiple times during system startup/shutdown?  Maybe there
could be links /etc/rc2.d/S02xendomains:early,
/etc/rc2.d/S03xendomains:middle, and /etc/rc2.d/X04xendomains:late which
start "early", "middle", and "late" domains?

Pretty much it really needs to be redone from the ground up.



Related, but perhaps a distinct issue is what happens when one runs
`/etc/init.d/xendomains reload`.  The current behavior is to pause/stop
all domains and then resume/start all domains.  One use for this is for
when qemu-system-i386 gets security updates.  In such case the desired
behavior is to stop and then start each domain (which results in shorter
downtimes for each domain, even though the whole process takes just as
long).


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#908765: seems like this already exists

[Jeffrey Cliff]

in package ~/node-babel-6.26.0+dfsg/packages/
there's already a node-babel-preset-es2016
node5 seems to be specifically for nodejs v5 which is a few versions ago
i'm thinking this may not be necessary after all

Bug#926209: RM: python-softlayer -- ROM; Low popcon, no human maintainer

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

This package has never been widely used.  I'm no longer a Softlayer customer,
so I can't really maintain it properly anymore.  Given the upstream churn,
this package isn't really suitable for maintenance by QA upload.

Scott K

Bug#926032: [chromium] Buggy / Solarized videos

[Edwin Lim]

Turning off Hardware-accelerated video decode from chrome://flags makes the
video render normally again.

Cheers,
Ed.

Bug#924965: libssh2

[mehdi]

hi,
on jessie, after upgrade to libssh2-1_1.4.3-4.1+deb8u2, the following PHP
code doesn't work anymore.

could it be related to this fix?
https://github.com/libssh2/libssh2/commit/ca2744483eac4e707084df5fc55cc69d57571dde


 PHP Warning:  ssh2_auth_pubkey_file(): Authentication failed for test
using public key: Unable to send userauth-publickey request in - on line 3

Bug#923084: Misuse of dh_python3

[Unit 193]

Howdy,

This problem occurs since dh_python3 is passed the Debian working directory as 
follows:


  dh_python3 -p ${APP_PACKAGE} ${working_dir}/${package_share_dir}/

Just trimming '${working_dir}' will solve this problem, though at this stage 
dh_python3 could be called with no options and it would do the right thing.


dh_python3 reads the path as follows:

  if not dpath:
  self.proot = "debian/%s" % self.package
  else:
  dpath = dpath.strip('/')
  self.proot = join('debian', self.package, dpath)

Meaning that any path passed as an argument is prefixed with 
'debian/$package/', which in this case ends up being 
'debian/gandi-cli/debian/gandi-cli/...'


As always, thanks for maintaining gandi-cli in Debian!


~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

Bug#920530: apparmor: Apparmour breaks bind/named DLZ with samba

[Bernhard Schmidt]

Control: reopen -1

Am 01.04.19 um 23:52 schrieb Steven Monai:

Hi Steve,

> As of now, this bug still affects Buster.

Thanks for reporting. I don't have samba AD with bind9 running on
Buster, your feedback is appreciated.

> When the apparmor profile 'usr.sbin.named' is set to 'enforce' mode
> (which it is, by default), the 'bind9' service fails to start, and the
> log informs me of this:
> 
> Apr  1 09:04:59 dc1 kernel: [   21.422095] audit: type=1400
> audit(1554134699.848:10): apparmor="DENIED" operation="open"
> profile="/usr/sbin/named" name="/var/lib/samba/bind-dns/named.conf"
> pid=403 comm="isc-worker" requested_mask="r" denied_mask="r"
> fsuid=108 ouid=0

Have you configured /var/lib/samba/bind-dns/named.conf manually by any
chance? On my stretch system this file is in /var/lib/samba/private,
which is whitelisted based on the reports in this bug in the apparmor
policy.

> When the 'usr.sbin.named' profile is set to 'complain' mode, the 'bind9'
> service is able to start successfully, and the log records the following
> lines:
> 
> Apr  1 09:18:35 dc1 kernel: [  836.519140] audit: type=1400
> audit(1554135515.061:13): apparmor="ALLOWED" operation="open"
> profile="/usr/sbin/named" name="/var/lib/samba/bind-dns/named.conf"
> pid=1123 comm="isc-worker" requested_mask="r" denied_mask="r"
> fsuid=108 ouid=0
> Apr  1 09:18:35 dc1 kernel: [  836.681568] audit: type=1400
> audit(1554135515.221:14): apparmor="ALLOWED" operation="file_mmap"
> profile="/usr/sbin/named"
> name="/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_11.so" pid=1123
> comm="isc-worker" requested_mask="m" denied_mask="m" fsuid=108 ouid=0
> Apr  1 09:18:35 dc1 kernel: [  836.708281] audit: type=1400
> audit(1554135515.249:15): apparmor="ALLOWED" operation="file_mmap"
> profile="/usr/sbin/named"
> name="/usr/lib/x86_64-linux-gnu/samba/gensec/krb5.so" pid=1123
> comm="isc-worker" requested_mask="m" denied_mask="m" fsuid=108 ouid=0
> Apr  1 09:18:35 dc1 kernel: [  836.726233] audit: type=1400
> audit(1554135515.269:16): apparmor="ALLOWED" operation="file_mmap"
> profile="/usr/sbin/named"
> name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/asq.so" pid=1123
> comm="isc-worker" requested_mask="m" denied_mask="m" fsuid=108 ouid=0
> Apr  1 09:18:35 dc1 kernel: [  836.726597] audit: type=1400
> audit(1554135515.269:17): apparmor="ALLOWED" operation="file_mmap"
> profile="/usr/sbin/named"
> name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/ldap.so" pid=1123
> comm="isc-worker" requested_mask="m" denied_mask="m" fsuid=108 ouid=0
> Apr  1 09:18:35 dc1 kernel: [  836.728118] audit: type=1400
> audit(1554135515.269:18): apparmor="ALLOWED" operation="file_mmap"
> profile="/usr/sbin/named"
> name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/ldb.so" pid=1123
> comm="isc-worker" requested_mask="m" denied_mask="m" fsuid=108 ouid=0
> Apr  1 09:18:35 dc1 kernel: [  836.728753] audit: type=1400
> audit(1554135515.269:19): apparmor="ALLOWED" operation="file_mmap"
> profile="/usr/sbin/named"
> name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/mdb.so" pid=1123
> comm="isc-worker" requested_mask="m" denied_mask="m" fsuid=108 ouid=0
> Apr  1 09:18:35 dc1 kernel: [  836.729100] audit: type=1400
> audit(1554135515.269:20): apparmor="ALLOWED" operation="file_mmap"
> profile="/usr/sbin/named"
> name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/paged_results.so"
> pid=1123 comm="isc-worker" requested_mask="m" denied_mask="m"
> fsuid=108 ouid=0
> Apr  1 09:18:35 dc1 kernel: [  836.729404] audit: type=1400
> audit(1554135515.269:21): apparmor="ALLOWED" operation="file_mmap"
> profile="/usr/sbin/named"
> name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/paged_searches.so"
> pid=1123 comm="isc-worker" requested_mask="m" denied_mask="m"
> fsuid=108 ouid=0
> Apr  1 09:18:35 dc1 kernel: [  836.729696] audit: type=1400
> audit(1554135515.269:22): apparmor="ALLOWED" operation="file_mmap"
> profile="/usr/sbin/named"
> name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/rdn_name.so" pid=1123
> comm="isc-worker" requested_mask="m" denied_mask="m" fsuid=108 ouid=0
> 
> I am uncertain how best to update the 'usr.sbin.named' profile so that
> the bind9 service will start and function correctly while confined by
> apparmor. Please advise.

Try adding this into /etc/apparmor.d/local/usr.sbin.named

/{usr/,}lib/@{multiarch}/samba/bind9/*.so rm,
/{usr/,}lib/@{multiarch}/samba/gensec/*.so rm,
/{usr/,}lib/@{multiarch}/ldb/modules/ldb/*.so rm,

and reload apparmor. Does this help?

I need to read up on bind9+samba again that the default paths are.

Bernhard

Bug#926208: Bad Dual-Stack initscript error handling

[Bernhard Schmidt]

Package: isc-dhcp-server
Version: 4.4.1-2
Severity: important

Hi,

I don't really have a good non-intrusive idea to fix this. I also don't see
other reports about this (for code that was supposedly added before stretch),
so I wonder what I'm missing. 

/etc/init.d/isc-dhcp-server tries to start both an IPv4 and an IPv6 server in
the default configuration (both INTERFACESv[46] empty). Or if you have both
set. If the IPv6 server does not start due to any reason (missing
configuration, typo in the configuration, misconfigured NIC) you end up with
some bad state.

root@opsvm:~# systemctl start isc-dhcp-server
Job for isc-dhcp-server.service failed because the control process exited with 
error code.
See "systemctl status isc-dhcp-server.service" and "journalctl -xe" for details.

Apr 01 22:37:29 opsvm isc-dhcp-server[3057]: Launching IPv4 server only.
Apr 01 22:37:29 opsvm dhcpd[3066]: Internet Systems Consortium DHCP Server 4.4.1
Apr 01 22:37:29 opsvm dhcpd[3066]: Copyright 2004-2018 Internet Systems 
Consortium.
Apr 01 22:37:29 opsvm dhcpd[3066]: All rights reserved.
Apr 01 22:37:29 opsvm dhcpd[3066]: For info, please visit 
https://www.isc.org/software/dhcp/
Apr 01 22:37:30 opsvm dhcpd[3069]: Internet Systems Consortium DHCP Server 4.4.1
Apr 01 22:37:30 opsvm dhcpd[3069]: Copyright 2004-2018 Internet Systems 
Consortium.
Apr 01 22:37:30 opsvm dhcpd[3069]: All rights reserved.
Apr 01 22:37:30 opsvm dhcpd[3069]: For info, please visit 
https://www.isc.org/software/dhcp/
Apr 01 22:37:30 opsvm dhcpd[3069]: Wrote 0 group decls to leases file.
Apr 01 22:37:30 opsvm dhcpd[3069]: Wrote 0 deleted host decls to leases file.
Apr 01 22:37:30 opsvm dhcpd[3069]: Wrote 0 new dynamic host decls to leases 
file.
Apr 01 22:37:30 opsvm dhcpd[3069]: Wrote 136 leases to leases file.
Apr 01 22:37:30 opsvm dhcpd[3069]: Server starting service.
Apr 01 22:37:32 opsvm isc-dhcp-server[3057]: Starting ISC DHCPv4 server: dhcpd.
Apr 01 22:37:32 opsvm isc-dhcp-server[3057]: Launching IPv6 server only.
Apr 01 22:37:32 opsvm dhcpd[3076]: Wrote 0 NA, 0 TA, 0 PD leases to lease file.
Apr 01 22:37:32 opsvm dhcpd[3076]: 
Apr 01 22:37:32 opsvm dhcpd[3076]: No subnet6 declaration for ens18 
(2001:1b10:100:3::53aa:12a).
Apr 01 22:37:32 opsvm dhcpd[3076]: ** Ignoring requests on ens18.  If this is 
not what
Apr 01 22:37:32 opsvm dhcpd[3076]:you want, please write a subnet6 
declaration
Apr 01 22:37:32 opsvm dhcpd[3076]:in your dhcpd.conf file for the network 
segment
Apr 01 22:37:32 opsvm dhcpd[3076]:to which interface ens18 is attached. **
Apr 01 22:37:32 opsvm dhcpd[3076]: 
Apr 01 22:37:32 opsvm dhcpd[3076]: 
Apr 01 22:37:32 opsvm dhcpd[3076]: Not configured to listen on any interfaces!
Apr 01 22:37:32 opsvm dhcpd[3076]: 
Apr 01 22:37:32 opsvm dhcpd[3076]: If you think you have received this message 
due to a bug rather
Apr 01 22:37:32 opsvm dhcpd[3076]: than a configuration issue please read the 
section on submitting
Apr 01 22:37:32 opsvm dhcpd[3076]: bugs on either our web page at www.isc.org 
or in the README file
Apr 01 22:37:32 opsvm dhcpd[3076]: before submitting a bug.  These pages 
explain the proper
Apr 01 22:37:32 opsvm dhcpd[3076]: process and the information we find helpful 
for debugging.
Apr 01 22:37:32 opsvm dhcpd[3076]: 
Apr 01 22:37:32 opsvm dhcpd[3076]: exiting.
Apr 01 22:37:34 opsvm isc-dhcp-server[3057]: Starting ISC DHCPv6 server: 
dhcpd6check syslog for diagnostics. ... failed!
Apr 01 22:37:34 opsvm isc-dhcp-server[3057]:  failed!


root@opsvm:~# systemctl status isc-dhcp-server
● isc-dhcp-server.service - LSB: DHCP server
   Loaded: loaded (/etc/init.d/isc-dhcp-server; generated)
   Active: failed (Result: exit-code) since Mon 2019-04-01 22:37:34 UTC; 9s ago

root  3069  0.0  0.2  13632  9376 ?Ss   22:37   0:00 
/usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf ens18 moni123 mgmt100

So there is the IPv4 daemon running, but systemd thinks the whole service has
failed.

This leads to various weird things. You cannot stop the daemon using systemctl

root@opsvm:~# systemctl stop isc-dhcp-server
root@opsvm:~# systemctl status isc-dhcp-server
● isc-dhcp-server.service - LSB: DHCP server
   Loaded: loaded (/etc/init.d/isc-dhcp-server; generated)
   Active: failed (Result: exit-code) since Mon 2019-04-01 22:37:34 UTC; 2min 
35s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 3057 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, 
status=1/FAILURE)
Tasks: 1 (limit: 4696)
   Memory: 6.5M
   CGroup: /system.slice/isc-dhcp-server.service
   └─3069 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf ens18 moni123 
mgmt100

root  3069  0.0  0.2  13632  8860 ?Ss   22:37   0:00 
/usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf ens18 moni123 mgmt100

You cannot start or restart it, because it would then just try starting the
daemon again

Apr 01 22:40:54 opsvm isc-dhcp-server[3599]: Starting ISC DHCPv4 server: 
dhcpddhcpd service already running (pid file /var/run/dhcpd.pid currenty 

Bug#926207: iotop: unable to run on kernels with retpoline (spectre)

[Neil Tallim]

Package: iotop
Version: 0.6-24-g733f3f8-1
Severity: important
Tags: upstream

I'm afraid there's a flaw in the version of iotop available in Debian (even in
sid): retpoline support adds a blank line to /proc//status, which iotop was
not able to deal with before May of 2018. The effect of this is a crash with a
Python stack-trace. It affects all usage of iotop on any kernels with spectre
mitigation.

The upstream commit that addresses the issue is also the most recent one since
then:
https://repo.or.cz/iotop.git/commit/7c51ce0e29bd135c216f18e18f0c4ab769af0d6f

-- System Information:
Distributor ID: Debian
Description:Debian
Release:testing
Codename:   buster
Architecture: x86_64

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

Versions of packages iotop depends on:
ii  python3  3.7.1-3

iotop recommends no packages.

iotop suggests no packages.

-- no debconf information

Bug#926206: unblock: espeakup/1:0.80-14

[Cyril Brulebois]

Samuel Thibault  (2019-04-02):
> Please unblock package espeakup: as reported in Bug#925973, the current
> version of espeakup would stop it on preinst and start it on postinst.
> For a screen reader for blind users this is really bad because if
> anything goes wrong in between, the user is left without a screen
> reader. We should thus pass --restart-after-upgrade to dh_systemd_start
> to just restart the screen reader after successful upgrade.
> 
> Cc-ing kibi because of the udeb: this doesn't have any effect on the
> udeb.

Thanks for that; no objections.


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


signature.asc
Description: PGP signature

Bug#926206: unblock: espeakup/1:0.80-14

[Samuel Thibault]

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

Hello,

Please unblock package espeakup: as reported in Bug#925973, the current
version of espeakup would stop it on preinst and start it on postinst.
For a screen reader for blind users this is really bad because if
anything goes wrong in between, the user is left without a screen
reader. We should thus pass --restart-after-upgrade to dh_systemd_start
to just restart the screen reader after successful upgrade.

Cc-ing kibi because of the udeb: this doesn't have any effect on the
udeb.

unblock espeakup/1:0.80-14

Thanks!

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

Kernel: Linux 5.0.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE
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)

-- 
Samuel
il y a 10 catégories de personnes dans le monde : ceux qui comprennent le
binaire, et ceux qui ne le comprennent pas
diff -Nru espeakup-0.80/debian/changelog espeakup-0.80/debian/changelog
--- espeakup-0.80/debian/changelog  2019-02-20 15:44:59.0 +0100
+++ espeakup-0.80/debian/changelog  2019-03-29 17:03:23.0 +0100
@@ -1,3 +1,9 @@
+espeakup (1:0.80-14) unstable; urgency=medium
+
+  * rules: Restart espeakup after upgrade (Closes: Bug#925973).
+
+ -- Samuel Thibault   Fri, 29 Mar 2019 17:03:23 +0100
+
 espeakup (1:0.80-13) unstable; urgency=medium
 
   * debian/espeakup.finish-install: Fix writing down card id.
diff -Nru espeakup-0.80/debian/rules espeakup-0.80/debian/rules
--- espeakup-0.80/debian/rules  2019-01-01 17:07:20.0 +0100
+++ espeakup-0.80/debian/rules  2019-03-29 17:03:23.0 +0100
@@ -41,3 +41,6 @@
 override_dh_gencontrol:
echo 'espeak-ng:Version=$(ESPEAK_NG_VERSION)' >> 
debian/espeakup-udeb.substvars
dh_gencontrol
+
+override_dh_systemd_start:
+   dh_systemd_start --restart-after-upgrade

Bug#924800: [PATCH] resolve race in test cleanup by making second attempt more forceful

[Sean Whitton]

Hello Joey,

Thank you for your reply.

On Mon 01 Apr 2019 at 11:28AM -04, Joey Hess wrote:

> I'd certianly like to use removePathForcibly -- after all it was added
> in response to a bug report I filed about this very kind of problem.
>
> But, the first version of ghc to include it was 8.4.2, which is newer
> than the 8.0 minimum I think git-annex supports now, and also newer than
> what's in Debian stable. So it would need to be
> #if MIN_VERSION_directory(1,2,7)

Okay, fair enough, it makes sense for this hotfix for the Debian buster
release not to make it upstream.

> It also seems very unlikely that something would wait around for 10
> seconds while git-annex is delaying to let any processes that might be
> running finish their cleanup, and then run at exactly the same time as
> the removeDirectoryRecursive. Since the earlier removeDirectoryRecursive
> failed on the same file, I have the feeling the problem is not actually
> with the file vanishing out from under it, but something else to do with
> it being a socket..

Yes, this line of thought occurred to me as well.

> It seems to me that removePathForcibly would probably at best ignore
> the error in removal and so leave a .t directory hanging around at the
> end?

I just tested this -- `dgit build && ls .t` -- and it does not leave it
hanging around.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833182: drmSetMaster failed: Permission denied

[Thanatermesis]

If you installed systemd, maybe you need to install libpam-systemd too to
solve this issue

El lun., 1 abr. 2019 a las 17:18, Greg Wooledge ()
escribió:

> I ran into this bug upon upgrading from stretch to buster today.
>
> This system is an HP EliteDesk desktop PC with:
>
> 00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM
> Registers [8086:191f] (rev 07)
> 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics
> 530 [8086:1912] (rev 06)
>
>
> I have the relevant non-free firmware installed.
>
> wooledg:~$ sudo dmesg | grep -i firmware
> [sudo] password for wooledg:
> [0.194776] Spectre V2 : Enabling Restricted Speculation for firmware
> calls
> [0.231494] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
> [3.892737] i915 :00:02.0: firmware: direct-loading firmware
> i915/skl_dmc_ver1_27.bin
> [3.893012] [drm] Finished loading DMC firmware
> i915/skl_dmc_ver1_27.bin (v1.27)
>
>
> Under stretch, I was able to run 'startx' from tty1 as my non-root user
> account, without needs_root_rights=yes in Xwrapper.config.  X ran as me,
> using the modeset driver, and logged in ~/.local/share/xorg/.
>
> After the upgrade, running startx gave me these errors:
>
> wooledg:~$ grep EE .local/share/xorg/Xorg.0.log
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [  1140.120] (EE) systemd-logind: failed to get session: PID 1762 does not
> belong to any known session
> [  1140.193] (EE) modeset(0): drmSetMaster failed: Permission denied
> [  1140.193] (EE)
> [  1140.193] (EE) AddScreen/ScreenInit failed for driver 0
> [  1140.193] (EE)
> [  1140.193] (EE)
> [  1140.193] (EE) Please also check the log file at
> "/home/wooledg/.local/share/xorg/Xorg.0.log" for additional information.
> [  1140.193] (EE)
> [  1140.205] (EE) Server terminated with error (1). Closing log file.
>
>
> I used lynx from the console to search for a workaround.  I tried purging
> the xserver-xorg-legacy package, without success.  I tried reinstalling
> it, without success.
>
> I ended up putting needs_root_rights=yes in /etc/X11/Xwrapper.config.
> Now, it runs as root, and logs in /var/log/, but at least it's working.
>
> wooledg:~$ grep EE /var/log/Xorg.0.log
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [  1178.050] (EE) systemd-logind: failed to get session: PID 1812 does not
> belong to any known session
> [  1178.270] (II) Initializing extension MIT-SCREEN-SAVER
>
>
> I can't tell whether the systemd-logind error is relevant or not.
>
> Various packages that are installed:
>
> wooledg:~$ dpkg -l linux-image\* libpam-systemd xserver-xorg-\* | grep
> '^.i'
> ii  libpam-systemd:amd64241-1amd64
> system and service manager - PAM module
> ii  linux-image-4.19.0-4-amd64  4.19.28-2amd64
> Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.9.0-7-amd64   4.9.110-3+deb9u2 amd64
> Linux 4.9 for 64-bit PCs
> ii  linux-image-4.9.0-8-amd64   4.9.144-3.1  amd64
> Linux 4.9 for 64-bit PCs
> ii  linux-image-amd64   4.19+104 amd64
> Linux for 64-bit PCs (meta-package)
> ii  xserver-xorg-core   2:1.20.3-1   amd64
> Xorg X server - core server
> ii  xserver-xorg-input-all  1:7.7+19 amd64
> X.Org X server -- input driver metapackage
> ii  xserver-xorg-input-libinput 0.28.2-1 amd64
> X.Org X server -- libinput input driver
> ii  xserver-xorg-input-wacom0.34.99.1-1  amd64
> X.Org X server -- Wacom input driver
> ii  xserver-xorg-legacy 2:1.20.3-1   amd64
> setuid root Xorg server wrapper
> ii  xserver-xorg-video-all  1:7.7+19 amd64
> X.Org X server -- output driver metapackage
> ii  xserver-xorg-video-amdgpu   18.1.99+git20190207-1amd64
> X.Org X server -- AMDGPU display driver
> ii  xserver-xorg-video-ati  1:18.1.99+git20190207-1  amd64
> X.Org X server -- AMD/ATI display driver wrapper
> ii  xserver-xorg-video-fbdev1:0.5.0-1amd64
> X.Org X server -- fbdev display driver
> ii  xserver-xorg-video-intel2:2.99.917+git20180925-2 amd64
> X.Org X server -- Intel i8xx, i9xx display driver
> ii  xserver-xorg-video-nouveau  1:1.0.16-1   amd64
> X.Org X server -- Nouveau display driver
> ii  xserver-xorg-video-qxl  0.1.5-2+b1   amd64
> X.Org X server -- QXL display driver
> ii  xserver-xorg-video-radeon   1:18.1.99+git20190207-1  amd64
> X.Org X server -- AMD/ATI Radeon display driver
> ii  xserver-xorg-video-vesa 1:2.4.0-1amd64
> X.Org X server -- VESA display driver
> ii  xserver-xorg-video-vmware   1:13.3.0-2   amd64
> X.Org X server 

Bug#923484: sbuild: Fix Build-Space tag to report used Disc Space

[Aurelien Jarno]

control: severity -1 important

On 2019-04-02 00:01, Aurelien Jarno wrote:
> Would it be possible to do an upload with such a patch so that it can
> get into buster, even if the severity is normal?

I have been pointed out that given this information is used extract data
to feed the wanna-build db, the severity of this bug should be bumpted
to important. I am doing that with this mail.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#920530: apparmor: Apparmour breaks bind/named DLZ with samba

[Steven Monai]

Greetings.

As of now, this bug still affects Buster.

I have installed samba (2:4.9.4+dfsg-4), bind9 (1:9.11.5.P4+dfsg-1), and 
apparmor (2.13.2-9).

In my testing environment, Samba is configured as an Active Directory 
controller, and it is using the BIND_DLZ backend for DNS.

When the apparmor profile 'usr.sbin.named' is set to 'enforce' mode (which it 
is, by default), the 'bind9' service fails to start, and the log informs me of 
this:

Apr  1 09:04:59 dc1 kernel: [   21.422095] audit: type=1400 
audit(1554134699.848:10): apparmor="DENIED" operation="open" 
profile="/usr/sbin/named" name="/var/lib/samba/bind-dns/named.conf" pid=403 
comm="isc-worker" requested_mask="r" denied_mask="r"
fsuid=108 ouid=0

When the 'usr.sbin.named' profile is set to 'complain' mode, the 'bind9' 
service is able to start successfully, and the log records the following lines:

Apr  1 09:18:35 dc1 kernel: [  836.519140] audit: type=1400 
audit(1554135515.061:13): apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/named" name="/var/lib/samba/bind-dns/named.conf" pid=1123 
comm="isc-worker" requested_mask="r"
denied_mask="r" fsuid=108 ouid=0
Apr  1 09:18:35 dc1 kernel: [  836.681568] audit: type=1400 
audit(1554135515.221:14): apparmor="ALLOWED" operation="file_mmap" 
profile="/usr/sbin/named" 
name="/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_11.so" pid=1123 
comm="isc-worker"
requested_mask="m" denied_mask="m" fsuid=108 ouid=0
Apr  1 09:18:35 dc1 kernel: [  836.708281] audit: type=1400 
audit(1554135515.249:15): apparmor="ALLOWED" operation="file_mmap" 
profile="/usr/sbin/named" name="/usr/lib/x86_64-linux-gnu/samba/gensec/krb5.so" 
pid=1123 comm="isc-worker"
requested_mask="m" denied_mask="m" fsuid=108 ouid=0
Apr  1 09:18:35 dc1 kernel: [  836.726233] audit: type=1400 
audit(1554135515.269:16): apparmor="ALLOWED" operation="file_mmap" 
profile="/usr/sbin/named" 
name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/asq.so" pid=1123 
comm="isc-worker"
requested_mask="m" denied_mask="m" fsuid=108 ouid=0
Apr  1 09:18:35 dc1 kernel: [  836.726597] audit: type=1400 
audit(1554135515.269:17): apparmor="ALLOWED" operation="file_mmap" 
profile="/usr/sbin/named" 
name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/ldap.so" pid=1123 
comm="isc-worker"
requested_mask="m" denied_mask="m" fsuid=108 ouid=0
Apr  1 09:18:35 dc1 kernel: [  836.728118] audit: type=1400 
audit(1554135515.269:18): apparmor="ALLOWED" operation="file_mmap" 
profile="/usr/sbin/named" 
name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/ldb.so" pid=1123 
comm="isc-worker"
requested_mask="m" denied_mask="m" fsuid=108 ouid=0
Apr  1 09:18:35 dc1 kernel: [  836.728753] audit: type=1400 
audit(1554135515.269:19): apparmor="ALLOWED" operation="file_mmap" 
profile="/usr/sbin/named" 
name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/mdb.so" pid=1123 
comm="isc-worker"
requested_mask="m" denied_mask="m" fsuid=108 ouid=0
Apr  1 09:18:35 dc1 kernel: [  836.729100] audit: type=1400 
audit(1554135515.269:20): apparmor="ALLOWED" operation="file_mmap" 
profile="/usr/sbin/named" 
name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/paged_results.so" pid=1123 
comm="isc-worker"
requested_mask="m" denied_mask="m" fsuid=108 ouid=0
Apr  1 09:18:35 dc1 kernel: [  836.729404] audit: type=1400 
audit(1554135515.269:21): apparmor="ALLOWED" operation="file_mmap" 
profile="/usr/sbin/named" 
name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/paged_searches.so" pid=1123 
comm="isc-worker"
requested_mask="m" denied_mask="m" fsuid=108 ouid=0
Apr  1 09:18:35 dc1 kernel: [  836.729696] audit: type=1400 
audit(1554135515.269:22): apparmor="ALLOWED" operation="file_mmap" 
profile="/usr/sbin/named" 
name="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/rdn_name.so" pid=1123 
comm="isc-worker"
requested_mask="m" denied_mask="m" fsuid=108 ouid=0

I am uncertain how best to update the 'usr.sbin.named' profile so that the 
bind9 service will start and function correctly while confined by apparmor. 
Please advise.

Thanks,
-S.M.

Bug#817286: (no subject)

[Georg Faerber]

signature.asc
Description: PGP signature

Bug#923484: sbuild: Fix Build-Space tag to report used Disc Space

[Aurelien Jarno]

Hi,

On 2019-02-28 21:14, Helge Deller wrote:
> Package: sbuild
> Version: 0.78.1-1
> Severity: normal
> Tags: patch
> 
> sbuild fails to report used "Disc space" when building debian packages.
> This can be seen for various architecturs which are already using this
> sbuild version for their buildds. Here are examples for m68, ppc64 and
> hppa:
> https://buildd.debian.org/status/logs.php?pkg=globus-net-manager=m68k
> https://buildd.debian.org/status/logs.php?pkg=globus-net-manager=ppc64
> 
> For hppa arch I've applied the patch below, and with that change sbuild
> will now report the size in the "Build-Space:" tag of the build log:
> https://buildd.debian.org/status/logs.php?pkg=globus-net-manager=hppa

DSA just started to upgrade build daemons to buster for test purpose.
They are affected by the same issue. For example:
https://buildd.debian.org/status/fetch.php?pkg=pacemaker=i386=2.0.1-2=1554121370=0

> Can you apply the patch below (or a correct variant of it) to the next
> sbuild uploads?
> I'm happy to test any other patch as well.
> 
> Thanks,
> Helge
> 
> 
> diff -up /usr/share/perl5/Sbuild/Build.pm.org /usr/share/perl5/Sbuild/Build.pm
> --- /usr/share/perl5/Sbuild/Build.pm.org  2019-02-28 21:00:01.033696326 
> +0100
> +++ /usr/share/perl5/Sbuild/Build.pm  2019-02-28 21:01:11.885230625 +0100
> @@ -2783,7 +2783,7 @@ sub check_space {
>  # the required space.
>  unless( defined $dscdir && -d $dscdir)
>  {
> - return -1;
> + # DO NOT: return -1;
>  }
  
There are actually 2 issues with the current code:
- $dscdir is a relative path to the build directory, so $pkgbuilddir
  should be used instead to not depend on the current directory.
- The test should be done inside of the chroot.

Therefore the following patch fixes the issue for me:

--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -2781,7 +2781,7 @@ sub check_space {
 
 # if the source package was not yet unpacked, we will not attempt to 
compute
 # the required space.
-unless( defined $dscdir && -d $dscdir)
+unless( defined $dscdir && $self->test_directory($pkgbuilddir) )
 {
return -1;
 }

Would it be possible to do an upload with such a patch so that it can
get into buster, even if the severity is normal?

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#925973: Linux 9 stretch What to do about reviving speakup?

[Samuel Thibault]

Kirk Reiser, le lun. 01 avril 2019 17:46:16 -0400, a ecrit:
> Hi Samuel: Sorry, yes it seems to be working

Ok, thanks!

> except that an isolated install doesn't really cover the situation
> where a general upgrade or full-upgrade is taking place and how that
> will affect your changes. We may need to wait until the new package
> will be installed along with many others to find out how affective it
> is.

I agree.  But with the current freeze that isn't going to happen.

I'll push this then.

Samuel

Bug#925973: Linux 9 stretch What to do about reviving speakup?

[Kirk Reiser]

Hi Samuel: Sorry, yes it seems to be working except that an isolated
install doesn't really cover the situation where a general upgrade or
full-upgrade is taking place and how that will affect your changes. We
may need to wait until the new package will be installed along with
many others to find out how affective it is.

  Kirk

On Mon, 1 Apr 2019, Samuel Thibault wrote:


Hello Kirk,

Could you please check that version 1:0.80-14 fixes the issue?
It does work in my tests, by as history has shown, my tests are usually
not enough, and real tests by an actual users is needed to make really
sure the issue is gone.

Debian is getting frozen, if people want the fix in, they need to check
that it does work.

Samuel

Samuel Thibault, le ven. 29 mars 2019 18:31:44 +0100, a ecrit:

Samuel Thibault, le ven. 29 mars 2019 17:21:51 +0100, a ecrit:

Thanks for it!  I'll fix that for Buster. Unfortunately the next upgrade
will again have the issue, since it's the prerm script which stops
espeakup. But the upgrade after that (or a reinstall) should be fine.


Could you try to install version 1:0.80-14 from

deb http://incoming.debian.org/debian-buildd buildd-unstable main contrib 
non-free

The upgrade should still have the issue, but if you re-install with
--reinstall you shouldn't have the issue any more.

Samuel

Bug#926043: CVE-2019-0816

[Moritz Mühlenhoff]

Hi Thomas,

On Sun, Mar 31, 2019 at 12:33:45AM +0100, Thomas Goirand wrote:
> If I understand well the problem, the issue is simply that some extra
> Microsoft keys may end up being setup into an Azure Debian instance. I
> don't see this as a very "grave" security issue because:
> 
> 1/ Azure users must trust Azure anyways, otherwise, they should just
> stop doing hosting there.

It's still a big difference whether Microsoft has access during the provision
phase vs. the running system (where it may contain sensitive data).

Metaphorically speaking, I'm fine with builders having access to my house
while it's under construction, but not with them having the keys once the
house is built.

> 2/ It only affects Azure users.

But Azure is an official use case, isn't it? We only recently pushed
a DSA for the Azure agent e.g.

> I'm not even sure that our image is really using cloud-init to do the
> ssh key provisioning, if I'm not mistaking, it's using the Azure agent
> to do that (can Bastian confirm this?).

I don't know, if it can be confirmed it doesn't affect Debian, when we
can close the bug, ofc.

> In any case, can we downgrade this bug to "important"? Or am I missing
> something here?

Instead of arguing over bug severities, can't we rather fix the bug?
Ubuntu fixed this already and their versions seems fairly close.

Cheers,
Moritz

Bug#926140: additional information

[Balthasar Szczepański]

Additional information:

If instead of current version I use SD card image from 2017:
https://get.debian.org/debian/dists/stable/main/installer-armhf/20170615/images/netboot/SD-card-images/
then I don't get the problem of getting stuck in this step.
The installer actually starts.
But because I have the old version then I get kernel mismatch:

   lu [!!] Download installer components tqk
   x   x
   x No kernel modules were found. This probably is due to a mismatch  x
   x between the kernel used by this version of the installer and the  x
   x kernel version available in the archive.  x
   x   x
   x If you're installing from a mirror, you can work around this problem  x
   x by choosing to install a different version of Debian. The install x
   x will probably fail to work if you continue without kernel modules.x
   x   x
   x Continue the install without loading kernel modules?  x
   x   x
   x x
   x   x
   mqqqj

Bug#926204: qscintilla2: debian/watch does not find latest upstream version

[Mike Miller]

Source: qscintilla2
Version: 2.10.4+dfsg-2
Severity: normal

Dear Maintainer,

The debian/watch file for qscintilla2 does not notice the latest
upstream version 2.11.1.

Scraping the upstream homepage gives the latest version

$ curl -sL 
"http://www.riverbankcomputing.co.uk/software/qscintilla/download; \
| perl -n -e 'if (/.*(QScintilla_gpl-[.[0-9]+\.tar\.gz).*/) { print 
"$1\n"; }'
QScintilla_gpl-2.11.1.tar.gz
QScintilla_gpl-2.11.tar.gz
…

But uscan and tracker.d.o only show version 2.10.8

$ uscan --report
uscan: Newest version of qscintilla2 on remote site is 2.10.8, local 
version is 2.10.4+dfsg
 (mangled local version is 2.10.4)
uscan:=> Newer package available from
  https://qa.debian.org/watch/sf.php/pyqt/QScintilla_gpl-2.10.8.tar.gz

Thank you for your work on this package.


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

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Bug#925327: gpsd: CVE-2018-17937

[Bernd Zeimetz]

Hi,

> Once uploaded to unstable, can you ask for an unblock so it will reach
> buster?

sure, will do.
I'll also see what can/should be ported to stable.


Bern
d

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#926203: unblock: pacemaker/2.0.1-2

[Ferenc Wágner]

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

Please unblock package pacemaker

Dear Release Team,

As reported in #925354, the newly reintroduced pacemaker-dev package
missed Breaks+Replaces against some long-obsolete packages from wheezy,
leading to file conflicts in certain situations.  The version already in
unstable fixes this bug, please unblock it.

Thanks,
Feri.

diff -Nru pacemaker-2.0.1/debian/changelog pacemaker-2.0.1/debian/changelog
--- pacemaker-2.0.1/debian/changelog2019-03-04 21:34:46.0 +0100
+++ pacemaker-2.0.1/debian/changelog2019-04-01 13:39:28.0 +0200
@@ -1,3 +1,19 @@
+pacemaker (2.0.1-2) unstable; urgency=medium
+
+  * [d8939cc] Avoid file conflicts with leftover packages from wheezy.
+Pacemaker-dev in wheezy was a metapackage pulling in several -dev
+packages.  It is removed during the jessie dist-upgrade due to
+dependency problems, and jessie does not have pacemaker at all, so these
+obsolete -dev packages are left behind, unless replaced by the
+renamed -dev packages from jessie-backports or later from stretch, both
+of which requires manual action.  Lacking that, a manual install of the
+reintroduced pacemaker-dev from buster will try to overwrite headers
+from those obsolete -dev packages causing file conflicts, because the
+old Breaks+Replaces relations weren't carried over from the stretch
+packages. (Closes: #925354)
+
+ -- Ferenc Wágner   Mon, 01 Apr 2019 13:39:28 +0200
+
 pacemaker (2.0.1-1) unstable; urgency=medium
 
   * [7d6ff2e] New upstream release (2.0.1)
diff -Nru pacemaker-2.0.1/debian/control pacemaker-2.0.1/debian/control
--- pacemaker-2.0.1/debian/control  2019-03-04 21:30:38.0 +0100
+++ pacemaker-2.0.1/debian/control  2019-03-29 09:06:28.0 +0100
@@ -332,6 +332,10 @@
  liblrmd-dev (<< 2),
  libpengine-dev (<< 2),
  libstonithd-dev (<< 2),
+# header ghosts from wheezy, where pacemaker-dev used to exist:
+ libcrmcluster1-dev,
+ libcrmcommon2-dev,
+ libpengine3-dev,
 Replaces:
  libcib-dev (<< 2),
  libcrmcluster-dev (<< 2),
@@ -340,6 +344,10 @@
  liblrmd-dev (<< 2),
  libpengine-dev (<< 2),
  libstonithd-dev (<< 2),
+# header ghosts from wheezy, where pacemaker-dev used to exist:
+ libcrmcluster1-dev,
+ libcrmcommon2-dev,
+ libpengine3-dev,
 Description: cluster resource manager development
  ${S:X-Common-Description}
  .

unblock pacemaker/2.0.1-2

Bug#926202: mpt3sas driver stuck in endless resetting loop under load

[jaroslav]

Package: linux-image-4.19.0-0.bpo.2-amd64
Version: 4.19.16-1~bpo9+1

When testing 4.19 from backports, we ran into an issue which manifests 
under heavy I/O load. The driver gets stuck in endless resetting loop, 
affecting I/O performance badly.


Affected server uses Supermicro H11DSi-NT motherboard and LSI 3008 HBA 
(Supermicro part number is AOC-S3008L-L8I). Six software (Linux MD) 
RAID1 arrays are formed from 12 drives (6 rotating, 6 SSDs). The issue 
can be triggered reliably by forcing the arrays to resync (with 
sync_speed_max set to 60 for all of them) and running pvmove between 
two of the SSD arrays at the same time. After few seconds the server 
becomes unresponsive, array resync speed drops to near zero, same for 
pvmove progress. Accesing files which are not present in memory (or 
saving files) takes several seconds.


For testing purposes, we tried to move all the hard drives into another 
server that has the same LSI hardware, but the issue persisted. Neither 
of those servers is in production use yet, so we should be able to test 
potential solutions and patches easily.


This is logged in dmesg (triple dot indicates same message repeating for 
different drives):


[  242.680063] mpt3sas_cm0: fault_state(0x5862)!
[  242.680114] mpt3sas_cm0: sending diag reset !!
[  243.713254] mpt3sas_cm0: diag reset: SUCCESS
[  243.742277] mpt3sas_cm0: CurrentHostPageSize is 0: Setting default 
host page size to 4k

[  243.897265] mpt3sas_cm0: _base_display_fwpkg_version: complete
[  243.897639] mpt3sas_cm0: LSISAS3008: FWVersion(16.00.01.00), 
ChipRevision(0x02), BiosVersion(08.37.00.00)

[  243.897705] mpt3sas_cm0: Protocol=(
[  243.897706] Initiator
[  243.897732] ,Target
[  243.897752] ),
[  243.897770] Capabilities=(
[  243.897785] TLR
[  243.897806] ,EEDP
[  243.897821] ,Snapshot Buffer
[  243.897837] ,Diag Trace Buffer
[  243.897859] ,Task Set Full
[  243.897883] ,NCQ
[  243.897904] )
[  243.897988] mpt3sas_cm0: sending port enable !!
[  251.003196] mpt3sas_cm0: port enable: SUCCESS
[  251.003376] mpt3sas_cm0: search for end-devices: start
[  251.003835] scsi target0:0:0: handle(0x000a), 
sas_addr(0x50030480180580c0)
[  251.003886] scsi target0:0:0: enclosure logical 
id(0x50030480180580ff), slot(0)
[  251.003980] scsi target0:0:1: handle(0x000b), 
sas_addr(0x50030480180580c1)
[  251.004029] scsi target0:0:1: enclosure logical 
id(0x50030480180580ff), slot(1)

...
[  251.021639] scsi target0:0:12: handle(0x0016), 
sas_addr(0x50030480180580fd)
[  251.022166] scsi target0:0:12: enclosure logical 
id(0x50030480180580ff), slot(12)

[  251.022740] mpt3sas_cm0: search for end-devices: complete
[  251.023281] mpt3sas_cm0: search for end-devices: start
[  251.023817] mpt3sas_cm0: search for PCIe end-devices: complete
[  251.024365] mpt3sas_cm0: search for expanders: start
[  251.024934]  expander present: handle(0x0009), 
sas_addr(0x50030480180580ff)

[  251.025502] mpt3sas_cm0: search for expanders: complete
[  251.026038] mpt3sas_cm0: _base_fault_reset_work: hard reset: success
[  251.026086] mpt3sas_cm0: removing unresponding devices: start
[  251.028140] mpt3sas_cm0: removing unresponding devices: end-devices
[  251.029484] mpt3sas_cm0:  Removing unresponding devices: pcie 
end-devices

[  251.030795] mpt3sas_cm0: removing unresponding devices: expanders
[  251.032106] mpt3sas_cm0: removing unresponding devices: complete
[  251.033412] mpt3sas_cm0: scan devices: start
[  251.035183] mpt3sas_cm0: scan devices: expanders start
[  251.038769] mpt3sas_cm0: break from expander scan: 
ioc_status(0x0022), loginfo(0x310f0400)

[  251.040140] mpt3sas_cm0: scan devices: expanders complete
[  251.041496] mpt3sas_cm0: scan devices: end devices start
[  251.043860] mpt3sas_cm0: break from end device scan: 
ioc_status(0x0022), loginfo(0x310f0400)

[  251.044991] mpt3sas_cm0: scan devices: end devices complete
[  251.046109] mpt3sas_cm0: scan devices: pcie end devices start
[  251.047237] mpt3sas_cm0: log_info(0x3003011d): originator(IOP), 
code(0x03), sub_code(0x011d)
[  251.048402] mpt3sas_cm0: log_info(0x3003011d): originator(IOP), 
code(0x03), sub_code(0x011d)
[  251.049505] mpt3sas_cm0: break from pcie end device scan: 
ioc_status(0x0021), loginfo(0x3003011d)

[  251.050319] mpt3sas_cm0: pcie devices: pcie end devices complete
[  251.050966] mpt3sas_cm0: scan devices: complete
[  251.503219] sd 0:0:0:0: Power-on or device reset occurred
[  251.503261] sd 0:0:2:0: Power-on or device reset occurred
...
[  252.007740] sd 0:0:8:0: Power-on or device reset occurred

One second later the kernel logs

[  253.080085] mpt3sas_cm0: fault_state(0x5862)!

and the whole process repeats itself. It keeps repeating until the 
server is shut down.


lspci info for the HBA is:
02:00.0 Serial Attached SCSI controller [0107]: LSI Logic / Symbios 
Logic SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097] (rev 02)


This issue appears to be similar to one I found in Ubuntu bug tracker - 

Bug#925327: gpsd: CVE-2018-17937

[Salvatore Bonaccorso]

Hi Bernd,

On Mon, Apr 01, 2019 at 12:41:30AM +0200, Bernd Zeimetz wrote:
> Hi,
> 
> On 3/30/19 8:32 AM, Salvatore Bonaccorso wrote:
> > Hi Bernd,
> > 
> > On Fri, Mar 29, 2019 at 10:54:50PM +0100, Bernd Zeimetz wrote:
> >> Hi Salvatore,
> >>
> >>> The following vulnerability was published for gpsd, not competely sure
> >>> on severity and on if the referenced upstream commit is enough.
> >>> Ideally though the fix seems ideal to go to buster.
> >>
> >> I've tried to get more information out of Upstream, but did not get a
> >> reply yet. So I'll prepare an upload with the mentioned commit. Looking
> >> trough the commit logs from gpsd it seems to be the only relevant one.
> > 
> > Ack thank you for investigating, I was neither more successfull to
> > determine if that's enough.
> > 
> > Cc;ing the security team alias, if anyone has more ideas.
> 
> So I'd go with
> https://github.com/bzed/pkg-gpsd/blob/buster/debian/patches/json-cve-fix
> 
> which contains all changes to json.c/.h up to
> a399e85c1201400e281f2c1dc29dde21c29b0088
> 
> from the upstream repository.
> 
> Later changes are not relevant here.
> 
> Any objections?

Makes sense.

Once uploaded to unstable, can you ask for an unblock so it will reach
buster?

Regards,
Salvatore

Bug#926201: ITP: qtmips -- MIPS CPU simulator for education purposes with pipeline and cache visualization.

[Pavel Pisa]

Package: wnpp
Severity: wishlist
Owner: Pavel Pisa 

* Package name: qtmips
  Version : 0.6.8
  Upstream Author : Pavel Pisa 
* URL : https://github.com/cvut/QtMips/
* License : GPL
  Programming Lang: C++
  Description : MIPS CPU simulator for education purposes with pipeline and 
cache visualization.

The project has started as diploma theses work of Karel Koci.
The complete text of the thesis Graphical CPU Simulator
with Cache Visualization is available from the online
archive of the Czech Technical University in Prague.

  
https://dspace.cvut.cz/bitstream/handle/10467/76764/F3-DP-2018-Koci-Karel-diploma.pdf

The document provides analysis of available alternative simulators,
overview of the project architecture and basic usage information.

The used MIPS CPU building block diagram, and a pipeline model matches
lecture slides prepared by Michal Stepanovsky for the subject Computer
Architectures. The course is based on the book Computer Organization
and Design, The HW/SW Interface written by professors Paterson
and Henessy.

Reasons to package

 - We have not found appropriate tool for teaching of CPU pipeline
   and cache basis. There are expensive professional tools which work
   on real CPUs RTL level and many tools to provide approximation
   computations of the cache performance etc. We have used MipsIt
   emulator
 
https://www.eit.lth.se/fileadmin/eit/courses/eit090/MipsIt/MipsITEnvRef.html
   in the past but it is Windows only and dated. SPIM
   is widely used but it provides no pipeline and extension
   is almost impossible because it interprets instructions
   directly. MARS is even better with IDE ideal for education
   but again its internals are centered about software
   instructions emulation. QtMips decodes instructions
   to set of signals which are propagated through pipeline
   stages similar way as on real hardware. Result is quite
   low speed with huge graphics overhead but with internal
   state visualization. On the other hand it is much faster
   then complete chip with RTL simulation.

 - The QtMips simulator is used in the course for 350 students
   now and even other faculty expressed interest to use it.
   It can be quite useful for many universities and it
   matches well the classic and widely used book for the subject.

 - I have led the diploma thesis and I have done substantial
   enhancements in the past months to make emulator fit needs
   of our seminaries. I have intent to mantain the package
   as time allows. The backup person is Karel Koci - initial
   project author.

 - Project is already built in Ubuntu launchapd
 https://launchpad.net/qtmips
   and Suse Open Build Service
 https://build.opensuse.org/package/show/home:ppisa/qtmips

Bug#923634: fdroidserver: File not found - gradlew-fdroid on fdroid build --server

[Gerion Entrup]

Can confirm this bug. It affects also stretch-backports. Is there some kind of 
workaround or a quickfix?

Bug#926074: RSS-Feed: Server ignores 'Last-Modified' date

[Raphael Hertzog]

Hi,

On Sun, 31 Mar 2019, Christian Buhtz wrote:
> As developer of a RSS/Atom newsreader I found problems with the RSS-Feed 
> offerd
> by Debian-Tracker.
> 
> The 'Last-Modified' date is ignored when used in a second request in the 'If-
> Modified-Since' field.
> When there are only some seconds between two requests, the expected behaviour,
> when using the date from the first request directly, is that in the second
> request should no feed entries.
> 
> In my newsreader I use Pythons 'aiohttp' package but in that example below I
> use 'feedparser' for easier handling. The problem is reproducable with both.
> 
> Side note: I know (and do) that as a workaround I can check the "published"
> dates of each entry and delete them if my newsreader still have them. But this
> is Debian and I am hopefull that this can be improved.

We are relying on a Django object to implement the feed so if anything,
this should be improved at this level:
https://docs.djangoproject.com/en/1.11/ref/contrib/syndication/

I would suggest to file your suggestion to the Django developers.

Unless Django expects us to setup a ConditionGETMiddleware to replace
the answer by a NotModified answer:
https://docs.djangoproject.com/en/1.11/ref/middleware/#module-django.middleware.http

We could enable this but I wonder if it would have other unexpected
side-effects in other parts of the code.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#925586: android-sdk-helper FTBFS with libgradle-core-java

[Jongmin Kim]

Control: found -1 4.4.1-5

-- 
Jongmin Kim

OpenPGP key located at https://jongmin.dev/pgp
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#926200: open-build-service: Use debconf to configure obs-worker and obs-server

[Lucas Kanashiro]

Source: open-build-service
Severity: wishlist

Dear Maintainer,

To configure the frontend (obs-api) location in obs-server and server
(obs-server) location in obs-worker, and the number of workers running, we
could ask users while installing them via debconf.

That would make user's life much easier. After the installation of the packages
would have no need to edit manually config files.


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

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

Bug#926187: dh-python: dh_python3 replaces shebang with /usr/bin/python2 not /usr/bin/python3

[Piotr Ozarowski]

> I see.   So you mean upstream would need to use
>   #!/usr/bin/env python3
> to get it handled as /usr/bin/python3

yes

(I know some upstreams think /usr/bin/python is Python 3.X…)

Bug#926199: stretch-pu: package libreoffice/1:5.2.7-1+deb9u6

[Rene Engelhard]

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

Hi,

now that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925
is finally fixed in stretch-p-u I think it's time to fix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913641 in the sense
that we conflict against the "broken" OpenJDK (and build-conflict
against it. So we can remove the "build hack" needed to be introduced
in the +deb9u5 security update).

I also included a simple documentation fix I noticed when seeing
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926009

Diff is

diff -Nru libreoffice-5.2.7/debian/changelog libreoffice-5.2.7/debian/changelog
--- libreoffice-5.2.7/debian/changelog  2019-01-23 18:51:09.0 +0100
+++ libreoffice-5.2.7/debian/changelog  2019-01-23 18:51:09.0 +0100
@@ -1,3 +1,15 @@
+libreoffice (1:5.2.7-1+deb9u6) stretch; urgency=medium
+
+  * debian/patches/mention-java-common-package.diff: update message to
+reflect current config dir...
+  * debian/patches/disableClassPathURLCheck.diff: revert openjdk is fixed
+
+  * debian/control.in:
+- make -core conflict against openjdk-8-jre-headless (= 8u181-b13-2~deb9u1)
+  (closes: 913641#) and build-conflict against it
+
+ -- Rene Engelhard   Wed, 23 Jan 2019 18:51:09 +0100
+
 libreoffice (1:5.2.7-1+deb9u5) stretch-security; urgency=high

   * debian/patches/disableClassPathURLCheck.diff: add workaround to
diff -Nru libreoffice-5.2.7/debian/control libreoffice-5.2.7/debian/control
--- libreoffice-5.2.7/debian/control2019-01-23 18:51:09.0 +0100
+++ libreoffice-5.2.7/debian/control2019-01-23 18:51:09.0 +0100
@@ -183,6 +183,7 @@
  nvidia-glx-dev,
  nvidia-glx-legacy-dev,
  nvidia-libopencl1,
+ openjdk-8-jre-headless (= 8u181-b13-2~deb9u1),
  qt3-dev-tools
 Standards-Version: 3.9.4
 Vcs-Git: https://anonscm.debian.org/git/pkg-openoffice/libreoffice.git
@@ -430,7 +431,10 @@
 myspell-sw (<< 1:3.1.0-3),
 myspell-th (<< 1:3.1.0-3),
 myspell-tl (<< 0.4-0-5)
-Conflicts: cacao-oj6-jre, libreoffice-filter-binfilter, libreoffice-unbundled
+Conflicts: cacao-oj6-jre,
+   libreoffice-filter-binfilter,
+   libreoffice-unbundled,
+   openjdk-8-jre-headless (= 8u181-b13-2~deb9u1)
 Provides: libreoffice-bundled
 Replaces: libreoffice-calc (<< 1:3.3.2-5),
   libreoffice-common (<< 1:4.4.0~rc3-1),
diff -Nru libreoffice-5.2.7/debian/control.in 
libreoffice-5.2.7/debian/control.in
--- libreoffice-5.2.7/debian/control.in 2018-11-23 07:50:05.0 +0100
+++ libreoffice-5.2.7/debian/control.in 2019-01-23 18:51:09.0 +0100
@@ -20,6 +20,7 @@
  libc6-dev (= 2.6.1-4) [i386 amd64],
  libcairo2 (= 1.4.8-1),
  libxul-dev (= 1.8.0.13~pre070720-0etch1),
+ openjdk-8-jre-headless (= 8u181-b13-2~deb9u1),
  nvidia-glx-dev,
  nvidia-glx-legacy-dev,
  qt3-dev-tools,
@@ -269,7 +270,7 @@
 myspell-th (<< 1:3.1.0-3),
 myspell-tl (<< 0.4-0-5),
 browser-plugin-libreoffice
-Conflicts: cacao-oj6-jre, libreoffice-filter-binfilter, libreoffice-unbundled
+Conflicts: cacao-oj6-jre, libreoffice-filter-binfilter, libreoffice-unbundled, 
openjdk-8-jre-headless (= 8u181-b13-2~deb9u1)
 Provides: libreoffice-bundled
 Replaces: libreoffice-calc (<< 1:3.3.2-5),
   libreoffice-common (<< 1:4.4.0~rc3-1),
diff -Nru libreoffice-5.2.7/debian/patches/disableClassPathURLCheck.diff 
libreoffice-5.2.7/debian/patches/disableClassPathURLCheck.diff
--- libreoffice-5.2.7/debian/patches/disableClassPathURLCheck.diff  
2018-12-28 11:20:29.0 +0100
+++ libreoffice-5.2.7/debian/patches/disableClassPathURLCheck.diff  
1970-01-01 01:00:00.0 +0100
@@ -1,10 +0,0 @@
 a/configure.ac-old 2018-12-28 11:10:35.953066686 +0100
-+++ b/configure.ac 2018-12-28 11:11:06.049403639 +0100
-@@ -6976,6 +6976,7 @@
-
- # set to limit VM usage for JunitTests
- JAVAIFLAGS=-Xmx64M
-+JAVAIFLAGS="$JAVAIFLAGS 
-Djdk.net.URLClassPath.disableClassPathURLCheck=true"
- # set to limit VM usage for javac
- JAVAFLAGS=-J-Xmx128M
- fi
diff -Nru libreoffice-5.2.7/debian/patches/mention-java-common-package.diff 
libreoffice-5.2.7/debian/patches/mention-java-common-package.diff
--- libreoffice-5.2.7/debian/patches/mention-java-common-package.diff   
2017-09-17 15:36:00.0 +0200
+++ libreoffice-5.2.7/debian/patches/mention-java-common-package.diff   
2019-01-23 18:51:09.0 +0100
@@ -8,7 +8,7 @@
  fprintf(stderr,"javaldx: Could not find a Java Runtime Environment! 
\n");
 +fprintf(stderr,"Please ensure that a JVM and the package 
libreoffice-java-common\n");
 +fprintf(stderr,"is installed.\n");
-+fprintf(stderr,"If it is already installed then 

Bug#926198: obs-api: Permissions and database setup should be done in maintainers scripts, not in a post-installation one

[Lucas Kanashiro]

Package: obs-api
Severity: minor

Dear Maintainer,

The debian/README.Debian file instructs to run a post-installation script to
finish the obs-api setup:

$ /usr/share/obs/api/script/rake-tasks.sh setup

This script changes files permissions and finishes the database setup. These
things should be done mostly in debian/obs-api.postinst script.

Having that in mind, I expect to install the obs-api package, answer debconf,
and then have a funcional OBS API and web interface running.


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

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

Versions of packages obs-api depends on:
ii  adduser  3.118
pn  apache2  
pn  dbconfig-common  
ii  debconf [debconf-2.0]1.5.71
pn  default-mysql-client | virtual-mysql-client  
ii  gsfonts  1:8.11+urwcyr1.0.7~pre44-4.4
pn  libapache2-mod-passenger 
pn  libapache2-mod-xforward  
ii  libgd-perl [libgd-gd2-perl]  2.71-2
ii  libjs-bootstrap  3.4.1+dfsg-1
pn  libjs-html5shiv  
ii  lsb-base 10.2019031300
ii  memcached1.5.6-1
ii  ruby 1:2.5.1
pn  ruby-activemodel-serializers-xml 
pn  ruby-acts-as-list
pn  ruby-acts-as-tree
ii  ruby-addressable 2.5.2-1
pn  ruby-bcrypt  
ii  ruby-bunny   2.9.2-1
pn  ruby-capybara
pn  ruby-chunky-png  
pn  ruby-cliver  
pn  ruby-clockwork   
pn  ruby-cocoon  
pn  ruby-codemirror-rails
ii  ruby-coderay 1.1.2-2
pn  ruby-coffee-rails
ii  ruby-colorize0.8.1-1
pn  ruby-crack   
pn  ruby-crass   
pn  ruby-cssmin  
pn  ruby-daemons 
pn  ruby-dalli   
pn  ruby-data-migrate
pn  ruby-delayed-job 
pn  ruby-delayed-job-active-record   
pn  ruby-docile  
ii  ruby-erubis  2.7.0-3
pn  ruby-escape-utils
ii  ruby-execjs  2.6.0-1
pn  ruby-feature 
pn  ruby-flot-rails  
pn  ruby-font-awesome-rails  
pn  ruby-gssapi  
ii  ruby-haml5.0.4-3
pn  ruby-hike
ii  ruby-i18n1.5.3-1
pn  ruby-innertube   
pn  ruby-joiner  
pn  ruby-jquery-datatables-rails 
pn  ruby-jquery-rails
pn  ruby-jquery-ui-rails 
ii  ruby-json2.1.0+dfsg-2+b1
pn  ruby-kaminari
pn  ruby-kgio
pn  ruby-ldap
ii  ruby-metaclass   0.0.4-1
ii  ruby-method-source   0.9.2-1
pn  ruby-middleware  
ii  ruby-mime-types  3.2.2-1
pn  ruby-momentjs-rails  
pn  ruby-mousetrap-rails 
pn  ruby-mysql2  
ii  ruby-nokogiri1.10.0+dfsg1-2
ii  ruby-nokogumbo   1.4.2+ds-1+b5
ii  ruby-parser  3.11.0-1
pn  ruby-peek
ii  ruby-pkg-config  1.3.6-1
pn  ruby-pundit  
pn  ruby-rails   
pn  ruby-rails-tokeninput
pn  ruby-raindrops   
ii  ruby-redcarpet   3.4.0-4+b1
pn  ruby-responders  
pn  ruby-riddle   

Bug#925586: android-sdk-helper FTBFS with libgradle-core-java

[Jongmin Kim]

Control: notfound -1 libgradle-core-java/4.4.1-5
Control: found -1 src:gradle/4.4.1-5


-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#926197: facter: custom facts that aren't suitable override built-in facts

[Aurelien Jarno]

Source: facter
Version: 3.11.0-1.1
Severity: important
Tags: upstream
Forwarded: https://tickets.puppetlabs.com/browse/FACT-1873

DSA is using facter with a small ruby fact to define operatingsystem for
GNU/kFreeBSD:

| Facter.add(:operatingsystem) do
| confine :kernel => 'GNU/kFreeBSD'
| setcode do
| if FileTest.exists?("/etc/debian_version")
| "Debian"
|end
| end
| end

When upgrading from the stretch to the buster version of Facter, this
small snippet actually hides the operatingsystem fact:

| 2019-04-01 10:50:20.906683 DEBUG puppetlabs.facter - fact "osfamily" has 
resolved to "Debian".
| 2019-04-01 10:50:20.906760 DEBUG puppetlabs.facter - fact 
"operatingsystemmajrelease" has resolved to "buster/sid".
| 2019-04-01 10:50:20.906821 DEBUG puppetlabs.facter - fact 
"operatingsystemrelease" has resolved to "buster/sid".
| 2019-04-01 10:50:20.906919 DEBUG puppetlabs.facter - fact "hardwaremodel" has 
resolved to "x86_64".
| 2019-04-01 10:50:20.906995 DEBUG puppetlabs.facter - fact "architecture" has 
resolved to "amd64".
| 2019-04-01 10:50:20.907062 DEBUG puppetlabs.facter - fact "lsbdistid" has 
resolved to "Debian".
| 2019-04-01 10:50:20.907131 DEBUG puppetlabs.facter - fact "lsbdistcodename" 
has resolved to "n/a".
| 2019-04-01 10:50:20.907197 DEBUG puppetlabs.facter - fact 
"lsbdistdescription" has resolved to "Debian GNU/Linux buster/sid".
| 2019-04-01 10:50:20.907266 DEBUG puppetlabs.facter - fact "lsbmajdistrelease" 
has resolved to "testing/unstable".
| 2019-04-01 10:50:20.907333 DEBUG puppetlabs.facter - fact "lsbdistrelease" 
has resolved to "testing/unstable".
| 2019-04-01 10:50:20.907401 DEBUG puppetlabs.facter - fact "operatingsystem" 
has resolved to "Debian".
| 2019-04-01 10:50:20.907471 DEBUG puppetlabs.facter - fact "selinux" has 
resolved to false.
| 2019-04-01 10:50:20.907546 DEBUG puppetlabs.facter - fact "os" has resolved 
to {
|   architecture => "amd64",
|   distro => {
| codename => "n/a",
| description => "Debian GNU/Linux buster/sid",
| id => "Debian",
| release => {
|   full => "testing/unstable",
|   major => "testing/unstable"
| }
|   },
|   family => "Debian",
|   hardware => "x86_64",
|   name => "Debian",
|   release => {
| full => "buster/sid",
| major => "buster/sid"
|   },
|   selinux => {
| enabled => false
|   }
| }.
| 2019-04-01 10:50:20.907640 DEBUG puppetlabs.facter - fact "operatingsystem" 
resolved to null and the existing value of "Debian" will be removed.
| 2019-04-01 10:50:20.909461 ERROR puppetlabs.facter - error while resolving 
custom facts in /var/lib/puppet/lib/facter/service_provider.rb: Could not 
autoload puppet/provider/service/freebsd: Could not autoload 
puppet/provider/service/init: undefined method `downcase' for nil:NilClass

It is first correctly defined, but then this ruby fact is overriding the
built-in operatingsystem fact. As the ruby fact is confined to a
different kernel, this should not happens.

It happens that this has been fixed reported and fixed upstream
recently: https://tickets.puppetlabs.com/browse/FACT-1873

Thanks to Apollon Oikonomopoulos for the help debugging this and on the
link to the upstream ticket.

Bug#926196: util-linux: "su --pty" is unusable

[Daniel Kahn Gillmor]

Package: util-linux
Version: 2.33.1-0.1
Severity: normal
Control: tags -1 upstream patch
Control: forwarded -1 https://github.com/karelzak/util-linux/issues/767

If i run "su --pty" i expect to get a functional terminal.  However,
the width of the terminal is not available, and special characters do
not get treated appropriately.

I raised this upstream, and karelzak provided a prompt fix.

I suspect that the --pty flag for su and runuser has simply never been
regularly used or tested :(

A cherry-picked patch from upstream is attached.

 --dkg

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

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

Versions of packages util-linux depends on:
ii  fdisk  2.33.1-0.1
ii  libaudit1  1:2.8.4-2
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-8
ii  libcap-ng0 0.7.9-2
ii  libmount1  2.33.1-0.1
ii  libpam0g   1.3.1-5
ii  libselinux12.8-1+b1
ii  libsmartcols1  2.33.1-0.1
ii  libsystemd0241-1
ii  libtinfo6  6.1+20181013-2
ii  libudev1   241-1
ii  libuuid1   2.33.1-0.1
ii  login  1:4.5-1.1
ii  zlib1g 1:1.2.11.dfsg-1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.0.4-4
ii  util-linux-locales  2.33.1-0.1

-- debconf information excluded
From: Karel Zak 
Date: Wed, 6 Mar 2019 11:54:51 +0100
Subject: su: fix --pty terminal initialization

* use proper winsize rather than uninitialized variable (Oops...)

* set the current terminal to the raw mode

* disable ECHO for non-terminal execution to be compatible with
  non-pty output

Addresses: https://github.com/karelzak/util-linux/issues/767
Signed-off-by: Karel Zak 
(cherry picked from commit 282ca3d87b4ab2e3f077c959fd5e0f87980120d6)
---
 login-utils/su-common.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/login-utils/su-common.c b/login-utils/su-common.c
index e0604e2..e35f2ac 100644
--- a/login-utils/su-common.c
+++ b/login-utils/su-common.c
@@ -276,29 +276,26 @@ static void pty_create(struct su_context *su)
 
if (su->isterm) {
DBG(PTY, ul_debug("create for terminal"));
-   struct winsize win;
 
/* original setting of the current terminal */
if (tcgetattr(STDIN_FILENO, >stdin_attrs) != 0)
err(EXIT_FAILURE, _("failed to get terminal 
attributes"));
-
-   /* reuse the current terminal setting for slave */
-   slave_attrs = su->stdin_attrs;
-   cfmakeraw(_attrs);
-
ioctl(STDIN_FILENO, TIOCGWINSZ, (char *)>win);
-
/* create master+slave */
-   rc = openpty(>pty_master, >pty_slave, NULL, 
_attrs, );
+   rc = openpty(>pty_master, >pty_slave, NULL, 
>stdin_attrs, >win);
 
+   /* set the current terminal to raw mode; pty_cleanup() reverses 
this change on exit */
+   slave_attrs = su->stdin_attrs;
+   cfmakeraw(_attrs);
+   slave_attrs.c_lflag &= ~ECHO;
+   tcsetattr(STDIN_FILENO, TCSANOW, _attrs);
} else {
DBG(PTY, ul_debug("create for non-terminal"));
rc = openpty(>pty_master, >pty_slave, NULL, NULL, NULL);
 
-   /* set slave attributes */
if (!rc) {
tcgetattr(su->pty_slave, _attrs);
-   cfmakeraw(_attrs);
+   slave_attrs.c_lflag &= ~ECHO;
tcsetattr(su->pty_slave, TCSANOW, _attrs);
}
}
@@ -311,12 +308,14 @@ static void pty_create(struct su_context *su)
 
 static void pty_cleanup(struct su_context *su)
 {
-   if (su->pty_master == -1)
+   struct termios rtt;
+
+   if (su->pty_master == -1 || !su->isterm)
return;
 
DBG(PTY, ul_debug("cleanup"));
-   if (su->isterm)
-   tcsetattr(STDIN_FILENO, TCSADRAIN, >stdin_attrs);
+   rtt = su->stdin_attrs;
+   tcsetattr(STDIN_FILENO, TCSADRAIN, );
 }
 
 static int write_output(char *obuf, ssize_t bytes)

Bug#926187: dh-python: dh_python3 replaces shebang with /usr/bin/python2 not /usr/bin/python3

[Drew Parsons]

On 2019-04-02 03:23, Piotr Ożarowski wrote:

To clarify, I meant that dh_python3 replaces the shebangs with
/usr/bin/python2 (not /usr/bin/python) instead of /usr/bin/python3.


not a bug, it's a feature :)

If upstream claims it's for Python 2.X then that's what it is.
If it's not, use --shebang /usr/bin/python3


I see.   So you mean upstream would need to use
  #!/usr/bin/env python3
to get it handled as /usr/bin/python3

Bug#926179: debian-security-support: Please mark qtwebengine-opensource-src as limited-support

[Salvatore Bonaccorso]

Control: tags -1 + patch pending

Hi Benjamin,

On Mon, Apr 01, 2019 at 12:19:44PM -0400, Benjamin Barenblat wrote:
> Package: debian-security-support
> Version: 2019.02.01
> Tags: patch
> 
> QtWebEngine isn’t explicitly listed in the release notes as “not covered
> by security support” [1], but QtWebKit is. QtWebEngine probably belongs
> in the same boat – it has a steady stream of CVEs that are quickly
> patched upstream, but no DSAs have been issued. Please add
> qtwebengine-opensource-src to security-support-limited.

I commited 
https://salsa.debian.org/debian/debian-security-support/commit/8b6e9d663ceaef0a87a78459ec0376ec07f51374

Regards,
Salvatore

Bug#926187: dh-python: dh_python3 replaces shebang with /usr/bin/python2 not /usr/bin/python3

[Drew Parsons]

Package: dh-python
Version: 3.20190308
Followup-For: Bug #926187
Control: retitle -1 dh-python: dh_python3 replaces shebang with 
/usr/bin/python2 not /usr/bin/python3

Bug#926187: dh-python: dh_python3 replaces shebang with /usr/bin/python2 not /usr/bin/python3

[Piotr Ożarowski]

> To clarify, I meant that dh_python3 replaces the shebangs with
> /usr/bin/python2 (not /usr/bin/python) instead of /usr/bin/python3.

not a bug, it's a feature :)

If upstream claims it's for Python 2.X then that's what it is.
If it's not, use --shebang /usr/bin/python3


signature.asc
Description: PGP signature

Bug#926194: e2wm/emacs-window-layout: unintended dist-upgrade dependency resolution due to missing "emacsen" dependency if installed together with emacs25-lucid

[Axel Beckert]

Package: e2wm
Version: 1.4-1
Severity: serious
Control: affects -1 + emacs-lucid emacs25-lucid
Control: clone -1 -2
Control: reassign -2 emacs-window-layout
Control: found -2 emacs-window-layout/1.4

Dear Maintainer,

if I upgrade a machine with emacs25-lucid and e2wm or
emacs-window-layout installed from e.g. Stretch to Buster, I can't
upgrade emacs25-lucid to emacs-lucid, because e2wm/emacs-window-layout
in Buster only depend on "emacs25-nox | emacs25", but not on any of the
generic virtual emacs packages like "emacs" or "emacsen".

Historically that worked, because emacs25-lucid did provide also
"emacs25" in Stretch, but since it's just a transitional package in
Buster, it no more provides emacs25 but depends on emacs-lucid which
itself only provides the current virtual emacs packages "emacs" and
"emacsen" (plus some other more generic things like "editor" which are
not relevant in this case).

So please change the dependencies to at least include "emacs" or even
better — because backwards compatible — "emacsen".

P.S.: IMHO this is release-critical because there is a dependency
missing which mislead both apt as well as aptitude on dist-upgrades:

* apt wants to replace emacs25-lucid (a lean GUI variant) with
  the non-gui variant emacs25-nox (which is not intended at all), and,

* depending on settings, aptitude suggests to not upgrade emacs25-lucid
  or to replace it with emacs25-nox as first suggestion, too:

  The following packages have unmet dependencies:
   emacs-lucid : Conflicts: emacs-nox but 1:26.1+1-3.2 is to be installed
   emacs-nox : Conflicts: emacs-lucid but 1:26.1+1-3.2 is to be installed
  The following actions will resolve these dependencies:

   Remove the following packages:
  1) emacs25-lucid [25.1+1-4+deb9u1 (now)]

   Keep the following packages at their current version:
  2) emacs-lucid [Not Installed]

On just "apt upgrade" or "aptitude safe-upgrade" both keep back
emacs25-lucid.

All these dependency resolution issues have no real reason except
missing (uptodate alternative) dependencies.

Bug#497831: Missing Depends on lib64z1

[Simon McVittie]

(I'm aware I'm digging up a decade-old bug, but I happened to see it
while checking whether #926191 was already open.)

On Thu, 04 Sep 2008 at 19:25:05 +0200, Goswin von Brederlow wrote:
> I think zlib1g-dbg should have
> 
> Depends: lib64z1 (= 1:1.2.3.3.dfsg-12)
> 
> to ensure that it will always match the version exactly. Without that
> the lib64z1 can be uninstalled (which doesn't hurt as then you would
> not have anything to debug) or more importantly have a different
> version.

10 years later, in the glorious(?) multiarch future, I think the vast
majority of users of zlib1g-dbg should only be interested in zlib1g, not
lib64z1. To avoid the mismatched version, I'd suggest either migrating to
the automatically-generated -dbgsym packages (see "Alternatively..." in
#926191), or using something like this:

Package: zlib1g-dbg
Depends: zlib1g (= ${binary:Version})
Breaks: lib64z1 (<< ${binary:Version}), lib64z1 (>> ${binary:Version})

smcv

Bug#926193: linux-image-4.19.0-4-amd64: Please disable kernel-commit d179b88d in drm/i915/fbdev

[Klaumi Klingsporn]

Package: src:linux
Version: 4.19.28-2
Severity: normal
Tags: upstream

Dear Maintainer,

after todays upgrade to linux-image-4.19.0-4 my system was unable to
start the xserver (on Intel Graphic HD 405) any more though it was and
is able with linux-image-4.19.0-2.

After hours of googleing and researching I learned that this is
actually a bug of the xserver-core package which is only triggered by
the new kernel because of kernel-commit
d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 for drm/i915/fbdev: "Actually
configure untiled displays". See:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=218b6d525b036463f3af0e9a1da9d0285ee2bc5b

The real bug in the xserver-core package is known and open upstream.
See: https://bugs.freedesktop.org/show_bug.cgi?id=109806
and
https://gitlab.freedesktop.org/xorg/xserver/issues/542.

Because of this the linux-image-4.19.0-4 is useless for me and other
Intel- Graphic-Users. It would be nice if you could remove and hold
back the kernel- commit for drm/i915/fbdev until the xserver-core bug
is fixed upstream (and in the debian package), so that Intel-Graphic
users can use an actual kernel.

Thanks for maintaining the kernel-packages!

Klaumi




-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Acer
product_name: TravelMate B117-M
product_version: V1.23
chassis_vendor: Acer
chassis_version: Chassis Version
bios_vendor: Insyde Corp.
bios_version: V1.23
board_vendor: Acer
board_name: Lepus_BA
board_version: V1.23

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Atom/Celeron/Pentium
Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register
[8086:2280] (rev 35) Subsystem: Acer Incorporated [ALI]
Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC
Transaction Register [1025:108c] Control: I/O+ Mem+ BusMaster+
SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR-  Kernel driver in use: i915 Kernel
modules: i915

00:0b.0 Signal processing controller [1180]: Intel Corporation
Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power
Management Controller [8086:22dc] (rev 35) Subsystem: Acer Incorporated
[ALI] Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power
Management Controller [1025:108c] Control: I/O+ Mem+ BusMaster+
SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-  Kernel driver in use: proc_thermal Kernel
modules: processor_thermal_device

00:13.0 SATA controller [0106]: Intel Corporation Atom/Celeron/Pentium
Processor x5-E8000/J3xxx/N3xxx Series SATA Controller [8086:22a3] (rev
35) (prog-if 01 [AHCI 1.0]) Subsystem: Acer Incorporated [ALI]
Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SATA
Controller [1025:108c] Control: I/O+ Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status:
Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 
Kernel driver in use: ahci Kernel modules: ahci

00:14.0 USB controller [0c03]: Intel Corporation Atom/Celeron/Pentium
Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller [8086:22b5]
(rev 35) (prog-if 30 [XHCI]) Subsystem: Acer Incorporated [ALI]
Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI
Controller [1025:108c] Control: I/O- Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status:
Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-  Kernel driver in use: xhci_hcd Kernel
modules: xhci_pci

00:1a.0 Encryption controller [1080]: Intel Corporation
Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted
Execution Engine [8086:2298] (rev 35) Subsystem: Acer Incorporated
[ALI] Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series
Trusted Execution Engine [1025:108c] Control: I/O- Mem+ BusMaster+
SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:1b.0 Audio device [0403]: Intel Corporation Atom/Celeron/Pentium
Processor x5-E8000/J3xxx/N3xxx Series High Definition Audio Controller
[8086:2284] (rev 35) Subsystem: Acer Incorporated [ALI]
Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series High
Definition Audio Controller [1025:108c] Control: I/O- Mem+ BusMaster+
SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation Atom/Celeron/Pentium
Processor x5-E8000/J3xxx/N3xxx Series PCI Express Port #1 [8086:22c8]
(rev 35) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+
SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- 

Bug#926192: ITP: vtkplotter -- a python class for scientific visualization of 3D objects with VTK

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: vtkplotter
  Version : 2019.1.2
  Upstream Author : Marco Musy 
* URL : https://vtkplotter.embl.es/
* License : MIT
  Programming Lang: Python
  Description : a python class for scientific visualization of 3D objects 
with VTK

A python module for scientific visualization, analysis and animation
of 3D objects and point clouds based on VTK and numpy.

Intuitive and straightforward API which can be combined with VTK seamlessly in 
a program, whilst mantaining access to the full range of VTK native classes.

It includes a large set of working examples for the all following 
functionalities:

*   Import meshes from VTK format, STL, Wavefront OBJ, 3DS, XML, Neutral, GMSH, 
OFF, PCD (PointCloud), volumetric TIFF stacks, SLC, MHD, 2D images PNG, JPEG.
*   Export meshes as ASCII or binary to VTK, STL, OBJ, PLY formats.
*   Mesh analysis through the built-in methods of VTK package. Additional 
analysis tools like Moving Least Squares, mesh morphing.
*   Tools to visualize and edit meshes (cutting a mesh with another mesh, 
slicing, normalizing, moving vertex positions, etc..). Interactive cutter 
widget.
*   Split mesh based on surface connectivity. Extract the largest connected 
area.
*   Calculate mass properties, like area, volume, center of mass, average size 
etc.
*   Calculate vertex and face normals, curvatures, feature edges. Fill mesh 
holes.
*   Subdivide faces of a mesh, increasing the number of vertex points. Mesh 
simplification.
*   Coloring and thresholding of meshes based on associated scalar or vectorial 
data.
*   Point-surface operations: find nearest points, determine if a point lies 
inside or outside a mesh.
*   Create primitive objects like: spheres, arrows, cubes, torus, ellipsoids...
*   Generate glyphs (associating a mesh to each vertex of a source mesh).
*   Create animations easily by just defining the position of the displayed 
objects in the 3D scene. Add trailing lines to moving objects automatically.
*   Straightforward support for multiple sync-ed or independent renderers in 
the same window.
*   Registration (alignment) of meshes with different techniques.
*   Mesh smoothing with Laplacian and WindowedSinc algorithms.
*   Delaunay triangulation in 2D and 3D.
*   Generate meshes by joining nearby lines in space.
*   Find the closest path from one point to another, travelling along the edges 
of a mesh.
*   Find the intersection of a mesh with a line (or with another mesh).
*   Analysis of Point Clouds:
-  Moving Least Squares smoothing of 2D, 3D and 4D clouds
-  Fit lines, planes and spheres in space
-  Perform PCA (Principal Component Analysis) on point coordinates
-  Identify outliers in a distribution of points
-  Decimate a cloud to a uniform distribution.
*   Basic histogramming and function plotting in 1D and 2D.
*   Interpolate scalar and vectorial fields with Radial Basis Functions and 
Thin Plate Splines.
*   Analysis of volumetric datasets:
-  Isosurfacing of volumes
-  Direct maximum projection rendering
-  Generate volumetric signed-distance data from an input surface mesh
-  Probe a volume with lines and planes.
*   Add sliders and buttons to interact with the scene and the individual 
objects.
*   Examples using SHTools package for spherical harmonics expansion of a mesh 
shape.
*   Integration with the Qt5 framework.
*   Support for FEniCS/dolfin package.

vtkplotter is published in M. Musy et al. "vtkplotter, a python module
for scientific visualization and analysis of 3D objects and point
clouds based on VTK (Visualization Toolkit)",
Zenodo, 10 February 2019, doi:10.5281/zenodo.2561402.

This package will be maintained under the Debian Science team
(alongside FEniCS/dolfin)

Bug#926190: stretch-pu: package postfix/3.1.12-0+deb9u1

[Scott Kitterman]

On Mon, 01 Apr 2019 14:30:04 -0400 Scott Kitterman  
wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> This is the next in a series.  It contains upstream bug fix releases 3.1.10,
> 3.1.11, and 3.1.12.  I held off after 3.1.10 since it contains somewhat more
> new/changed code than these usually do.  Both 3.1.11 and 3.1.12 have since
> been released with no corrections needed to the refactored code.
> 
> I have been running 3.1.10/11 in production for some time and currently have
> 3.1.12 in production.  All with no issues.
> 
> I am particularly motivated to move forward with another stable update now
> because 3.1.12 fixes an LMTP performance issue that likely has been hurting
> any high volume receivers and is a regression for oldstable -> stable.  
There
> are also fixes for several smtputf8 fixes that are oldstable -> stable
> regressions.
> 
> Other than the openssl related refactoring that has been extensively tested
> by the postfix community, most of the changes are documentation.  The other
> code changes seem reasonably compact and low risk.

Forgot to mention in the original bug that there's also a pending unblock 
request for 3.4.5-1 (#926188) that will cover getting the LMTP performance fix 
into Buster.

Scott K

Bug#925586: android-sdk-helper FTBFS with libgradle-core-java

[Jongmin Kim]

Control: notfound -1 libgradle-core-java/4.4.1
Control: found -1 libgradle-core-java/4.4.1-5

Re-set the version, caused by my mistake. I tested this only on 4.4.1-5
which is affected.

-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#925586: android-sdk-helper FTBFS with libgradle-core-java

[Jongmin Kim]

Control: found -1 libgradle-core-java/4.4.1


-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#926149: AMD: Add nomodeset kernel parameter to avoid black screen

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2019-04-01 at 15:59 +0800, 積丹尼 Dan Jacobson wrote:
> Package: installation-reports
> 
> With the latest AMD CPUs the kernel will attempt to use the AMDGPU
> kernel driver. Alas this will result in a black screen on the minimal
> system installed by the installer.

The installer should not do this.

If the necessary firmware is installed, the amdgpu driver should work,
of course.  If the firmware is not installed, the driver is supposed to
bail out early (this is a Debian-specific patch).

Was the firmware (firmware-amd-graphics package) installed on your test
system?

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon




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

Bug#926162: unblock: opensaml/3.0.1-1

[Niels Thykier]

Control: tags -1 moreinfo confirmed

Ferenc Wágner:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package opensaml
> 
> Dear Release Team,
> 
> [...]
> 
> If you're fine with this, I'm ready to upload opensaml/3.0.1-1 to
> unstable.
> 
> Thanks,
> Feri.
> 
> [...]
> 
> unblock opensaml/3.0.1-1
> 


Please go ahead with the upload and remove the moreinfo tag when it is
ready for unblocking.

Thanks,
~Niels

Bug#926191: zlib1g-dbg: please mark zlib1g-dbg as Multi-Arch: same

[Simon McVittie]

Package: zlib1g-dbg
Version: 1:1.2.11.dfsg-1
Severity: wishlist

It looks as though zlib1g-dbg packages from multiple architectures can be
installed in parallel without collisions (all filenames outside /usr/share
are hash-based). In a future upload please consider adding Multi-Arch: same:

Package: zlib1g-dbg
Multi-Arch: same
(etc.)

This should be enough to allow these detached debug symbols to be used to
debug 32- and 64-bit programs, native and cross programs, etc. without
removing one architecture's package and installing another.

Alternatively, you could remove the zlib1g-dbg package from d/control
and change

dh_strip -s --dbg-package=zlib1g-dbg

to

dh_strip -s --dbgsym-migration="zlib1g-dbg (<< X~)"

where X is the version number in which you made that change. This
would result in zlib1g-dbgsym, lib64z1-dbgsym, etc. packages with
Conflicts/Replaces on zlib1g-dbg (<< X~) being generated mechanically by
debhelper and placed in the http://deb.debian.org/debian-debug lookaside
repository by dak, and zlib1g-dbgsym would inherit the Multi-Arch: same
field from zlib1g. (This is supported since stretch, and does not
require going through the NEW queue, unlike most new binary packages.)

For some context for this request, I'm trying to build a self-contained
biarch 32- and 64-bit "SDK" runtime environment with development files
and debug symbols for a whole stack of packages, and I was pleased to
find that this is mostly possible already: zlib1g was one of only a few
libraries in my stack where I can install debug symbols for one word-size
but not the other at the same time.

smcv

Bug#926188: unblock: postfix/3.4.5-1

[Niels Thykier]

Control: tags -1 moreinfo confirmed

Scott Kitterman:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package postfix
> 
> [...]
> Thanks,
> 
> Scott K
> 
> unblock postfix/3.4.5-1
> 

Please go ahead with the upload and remove the moreinfo tag when it is
ready for unblocking.

Thanks,
~Niels

Bug#926190: stretch-pu: package postfix/3.1.12-0+deb9u1

[Scott Kitterman]

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

This is the next in a series.  It contains upstream bug fix releases 3.1.10,
3.1.11, and 3.1.12.  I held off after 3.1.10 since it contains somewhat more
new/changed code than these usually do.  Both 3.1.11 and 3.1.12 have since
been released with no corrections needed to the refactored code.

I have been running 3.1.10/11 in production for some time and currently have
3.1.12 in production.  All with no issues.

I am particularly motivated to move forward with another stable update now
because 3.1.12 fixes an LMTP performance issue that likely has been hurting
any high volume receivers and is a regression for oldstable -> stable.  There
are also fixes for several smtputf8 fixes that are oldstable -> stable
regressions.

Other than the openssl related refactoring that has been extensively tested
by the postfix community, most of the changes are documentation.  The other
code changes seem reasonably compact and low risk.

Usual fix list:

  [ Scott Kitterman ]

  * Add detailed smarthost instructions to README.Debian.  Thanks to Celejar
for the input.  Closes: #919444
  * Refresh patches

  [Wietse Venema]

  * 3.1.10
- Bugfix (introduced: Postfix 2.11): minor memory leak when
  minting issuer certs. This affects a tiny minority of use
  cases. Viktor Dukhovni, based on a fix by Juan Altmayer
  Pizzorno for the ssl_dane library. File: tls/tls_dane.c.
- Bugfix (introduced: Postfix 3.0): with smtputf8_enable=yes,
  table lookups could casefold the search string when searching
  a lookup table that does not use fixed-string keys (regexp,
  pcre, tcp, etc.). Historically, Postfix would not case-fold
  the search string with such tables. File: util/dict_utf8.c.
  Closes: #917512
- Multiple 'bit rot' fixes for OpenSSL API changes, including
  support to disable TLSv1.3, to avoid issuing multiple session
  tickets. Viktor Dukhovni. Files: proto/postconf.proto,
  proto/TLS_README.html, tls/tls.h, tls/tls_server.c,
  tls/tls_misc.c.
- Bugfix (introduced: 3.0): smtpd_discard_ehlo_keywords could
  not disable "SMTPUTF8". because the lookup table was using
  "EHLO_MASK_SMTPUTF8" instead. File: global/ehlo_mask.c.
- Documentation: update documentation for Postfix versions
  that support disabling TLS 1.3. File: proto/postconf.proto.
- Improved logging of TLS 1.3 summary information, and improved
  reporting of the same info in Received: message headers.
  Viktor Dukhovni. Files: proto/FORWARD_SECRECY_README.html,
  posttls-finger/posttls-finger.c, smtpd/smtpd.c, tls/tls.h,
  tls/tls_client.c, tls/tls_misc.c, tls/tls_proxy.h,
  tls/tls_proxy_context_print.c, tls/tls_proxy_context_scan.c,
  tls/tls_server.c.
  * 3.1.11
- Bugfix (introduced: postfix-2.11): with posttls-finger,
  connections to unix-domain servers always resulted in "Failed
  to establish session" even after a connection was established.
  Jaroslav Skarva.  File: posttls-finger/posttls-finger.c.
  * 3.1.12
- Bugfix (introduced: Postfix 2.2): reject_multi_recipient_bounce
  has been producing false rejects starting with the Postfix
  2.2 smtpd_end_of_data_restrictons, and for the same reasons,
  did the same with the Postfix 3.4 BDAT command. The latter
  was reported by Andreas Schulze. File: smtpd/smtpd_check.c.
- Bugfix (introduced: Postfix 3.0): LMTP connections over
  UNIX-domain sockets were cached but not reused, due to a
  cache lookup key mismatch. Therefore, idle cached connections
  could exhaust LMTP server resources, resulting in two-second
  pauses between email deliveries. This problem was investigated
  by Juliana Rodrigueiro. File: smtp/smtp_connect.c.

Thanks for considering,

Scott K
diff -Nru postfix-3.1.9/debian/changelog postfix-3.1.12/debian/changelog
--- postfix-3.1.9/debian/changelog	2019-02-08 09:07:54.0 -0500
+++ postfix-3.1.12/debian/changelog	2019-04-01 13:01:06.0 -0400
@@ -1,3 +1,61 @@
+postfix (3.1.12-0+deb9u1) stretch; urgency=medium
+
+  [Scott Kitterman]
+
+  * Add detailed smarthost instructions to README.Debian.  Thanks to Celejar
+for the input.  Closes: #919444
+  * Refresh patches
+
+  [Wietse Venema]
+
+  * 3.1.10
+- Bugfix (introduced: Postfix 2.11): minor memory leak when
+  minting issuer certs. This affects a tiny minority of use
+  cases. Viktor Dukhovni, based on a fix by Juan Altmayer
+  Pizzorno for the ssl_dane library. File: tls/tls_dane.c.
+- Bugfix (introduced: Postfix 3.0): with smtputf8_enable=yes,
+  table lookups could casefold the search string when searching
+  a lookup table that does not use fixed-string keys (regexp,
+  pcre, tcp, etc.). Historically, Postfix would not case-fold
+  the search string with such tables. File: util/dict_utf8.c.
+  Closes: 

Bug#926187: dh-python: dh_python3 replaces shebang with /usr/bin/python2 not /usr/bin/python3

[Drew Parsons]

Package: dh-python
Version: 3.20190308
Followup-For: Bug #926187

To clarify, I meant that dh_python3 replaces the shebangs with
/usr/bin/python2 (not /usr/bin/python) instead of /usr/bin/python3.

Bug#926123: unblock: cabextract/1.9-2

[Eric Sharkey]

On Sun, Mar 31, 2019 at 3:58 PM Jens Reyer  wrote:

> Passing on Jonathan's question to you.
>
> [..]
> The debhelper compat change is a problem. Would you or the maintainer be
> interested in an upload reverting it?
>

 I'd rather release buster with cabextract 1.9-1.  There's no bug in it.
If you want to unblock libmspack and get that into buster, that's fine, and
1.9-1 is compatible with that.  There's no need to do anything to
cabextract in buster due to the mspack bug.

Eric Sharkey

Bug#926151: chromium: Youtube not working in latest testing version on recent intel hw

[Uli Martens]

Hey there,

I've got the same problem since today's upgrade from 72.0.3626.121-1 to
73.0.3683.75-1, on a NUC8I5BEH (also with intel video).

The workaround from
https://bbs.archlinux.org/viewtopic.php?pid=1836760#p1836760 fixed it
for me. vainfo output for this system is:

| libva info: VA-API version 1.4.0
| libva info: va_getDriverName() returns 0
| libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
| libva info: Found init function __vaDriverInit_1_4
| libva info: va_openDriver() returns 0
| vainfo: VA-API version: 1.4 (libva 2.4.0)
| vainfo: Driver version: Intel i965 driver for Intel(R) Coffee Lake - 2.3.0
| vainfo: Supported profile and entrypoints
|   VAProfileMPEG2Simple:   VAEntrypointVLD
|   VAProfileMPEG2Simple:   VAEntrypointEncSlice
|   VAProfileMPEG2Main  :   VAEntrypointVLD
|   VAProfileMPEG2Main  :   VAEntrypointEncSlice
|   VAProfileH264ConstrainedBaseline:   VAEntrypointVLD
|   VAProfileH264ConstrainedBaseline:   VAEntrypointEncSlice
|   VAProfileH264ConstrainedBaseline:   VAEntrypointEncSliceLP
|   VAProfileH264Main   :   VAEntrypointVLD
|   VAProfileH264Main   :   VAEntrypointEncSlice
|   VAProfileH264Main   :   VAEntrypointEncSliceLP
|   VAProfileH264High   :   VAEntrypointVLD
|   VAProfileH264High   :   VAEntrypointEncSlice
|   VAProfileH264High   :   VAEntrypointEncSliceLP
|   VAProfileH264MultiviewHigh  :   VAEntrypointVLD
|   VAProfileH264StereoHigh :   VAEntrypointVLD
|   VAProfileVC1Simple  :   VAEntrypointVLD
|   VAProfileVC1Main:   VAEntrypointVLD
|   VAProfileVC1Advanced:   VAEntrypointVLD
|   VAProfileNone   :   VAEntrypointVideoProc
|   VAProfileJPEGBaseline   :   VAEntrypointVLD
|   VAProfileJPEGBaseline   :   VAEntrypointEncPicture
|   VAProfileVP8Version0_3  :   VAEntrypointVLD
|   VAProfileHEVCMain   :   VAEntrypointVLD
|   VAProfileHEVCMain10 :   VAEntrypointVLD
|   VAProfileVP9Profile0:   VAEntrypointVLD
|   VAProfileVP9Profile2:   VAEntrypointVLD

greetings,
   Uli

Bug#926189: rmagic does not compile with Perl5 v26 because of an unescaped left angle brace

[Christopher Lansdown]

Package: rmagic
Version: 2.21-5

With Perl5 v26, rmagic no longer compiles (as in, perl -c /usr/bin/rmagic 
returns errors)

Line 322 is:

$statistics{Log_File} =~ s/\${infile}/$infile/gi;
   
But unescaped angle braces are no longer deprecated in Perl5 v26, but simply 
fail to compile
Accordingly, line 322 should be:

   $statistics{Log_File} =~ s/\$\{infile\}/$infile/gi;

This problem is specific to the perl version (Perl5 v26 is the default in 
Ubuntu 18.04, which I'm using) and is not OS or hardware dependent.

Many thanks,
Christopher Lansdown

-- 
www.chrislansdown.com
"Let us endeavor so to live that when we come to die even the undertaker 
will be sorry."  -- Mark Twain, "Pudd'nhead Wilson's Calendar"
== Evil Overlord Quote of the Day (www.eviloverlord.com) =
112. I will not rely entirely upon "totally reliable" spells that can be
neutralized by relatively inconspicuous talismans. 

Bug#926188: unblock: postfix/3.4.5-1

[Scott Kitterman]

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

Please unblock package postfix

As mentioned in the last unblock request, for postfix we've been doing stable
updates of new 3.1 series versions and I'm trying to follow a similar
approach during freeze, particularly due to the late switch to postfix 3.4.

Of course, as soon as I think it's quieted down and it's safe to update, there
is another one.  I would like to go ahead with this now and not wait because
there is a companion 3.1 update for stable that I would like to proceed with
sooner rather than later and I don't want stable to get ahead of testing in
terms of fixes/functionality.

There are two fixes in this release:

  * 3.4.5
- With message_size_limit=0 (which is NOT DOCUMENTED), BDAT
  chunks were always rejected as too large. File: smtpd/smtpd.c
- Bugfix (introduced: Postfix 3.0): LMTP connections over
  UNIX-domain sockets were cached but not reused, due to a
  cache lookup key mismatch. Therefore, idle cached connections
  could exhaust LMTP server resources, resulting in two-second
  pauses between email deliveries. This problem was investigated
  by Juliana Rodrigueiro. File: smtp/smtp_connect.c.

The latter fix is a regression from oldstable -> stable.  For high volume
LMTP users, the impact is likley significant, but difficult to diagnose.  I
definitely want this fixed in stable and I think we want it fixed in buster
too.

The first fix represents the next in a series of existing code limitations
that present problems not that BDAT is implemented.

As you can see, the diff is pretty trivial.  I have the package ready to
upload when ack'ed.

Thanks,

Scott K

unblock postfix/3.4.5-1
diff -Nru postfix-3.4.4/debian/changelog postfix-3.4.5/debian/changelog
--- postfix-3.4.4/debian/changelog	2019-03-25 11:03:58.0 -0400
+++ postfix-3.4.5/debian/changelog	2019-04-01 13:30:19.0 -0400
@@ -1,3 +1,19 @@
+postfix (3.4.5-1) UNRELEASED; urgency=medium
+
+  [Wietse Venema]
+
+  * 3.4.5
+- With message_size_limit=0 (which is NOT DOCUMENTED), BDAT
+  chunks were always rejected as too large. File: smtpd/smtpd.c
+- Bugfix (introduced: Postfix 3.0): LMTP connections over
+  UNIX-domain sockets were cached but not reused, due to a
+  cache lookup key mismatch. Therefore, idle cached connections
+  could exhaust LMTP server resources, resulting in two-second
+  pauses between email deliveries. This problem was investigated
+  by Juliana Rodrigueiro. File: smtp/smtp_connect.c.
+
+ -- Scott Kitterman   Mon, 01 Apr 2019 13:27:26 -0400
+
 postfix (3.4.4-1) unstable; urgency=medium
 
   [Wietse Venema]
diff -Nru postfix-3.4.4/HISTORY postfix-3.4.5/HISTORY
--- postfix-3.4.4/HISTORY	2019-03-14 19:57:12.0 -0400
+++ postfix-3.4.5/HISTORY	2019-03-30 10:33:58.0 -0400
@@ -24195,3 +24195,16 @@
 	does the same with the Postfix 3.4 BDAT command. The latter
 	was reported by Andreas Schulze. File: smtpd/smtpd_check.c.
 
+20190319
+
+	With message_size_limit=0 (which is NOT DOCUMENTED), BDAT
+	chunks were always rejected as too large. File: smtpd/smtpd.c
+
+20190328
+
+	Bugfix (introduced: Postfix 3.0): LMTP connections over
+	UNIX-domain sockets were cached but not reused, due to a
+	cache lookup key mismatch. Therefore, idle cached connections
+	could exhaust LMTP server resources, resulting in two-second
+	pauses between email deliveries. This problem was investigated
+	by Juliana Rodrigueiro. File: smtp/smtp_connect.c.
diff -Nru postfix-3.4.4/html/postconf.5.html postfix-3.4.5/html/postconf.5.html
--- postfix-3.4.4/html/postconf.5.html	2019-02-10 12:12:57.0 -0500
+++ postfix-3.4.5/html/postconf.5.html	2019-03-24 18:59:02.0 -0400
@@ -6241,7 +6241,7 @@
 (default: empty)
 
  The name of an optional logfile that is written by the Postfix
-postlogd(8) service. A non-empty value selects logging to syslogd(8).
+postlogd(8) service. An empty value selects logging to syslogd(8).
 Specify "/dev/stdout" to select logging to standard output. Stdout
 logging requires that Postfix is started with "postfix start-fg".
 
diff -Nru postfix-3.4.4/man/man5/postconf.5 postfix-3.4.5/man/man5/postconf.5
--- postfix-3.4.4/man/man5/postconf.5	2019-02-03 11:58:44.0 -0500
+++ postfix-3.4.5/man/man5/postconf.5	2019-03-24 18:59:03.0 -0400
@@ -3750,7 +3750,7 @@
 This feature is available in Postfix 2.3 and later.
 .SH maillog_file (default: empty)
 The name of an optional logfile that is written by the Postfix
-\fBpostlogd\fR(8) service. A non\-empty value selects logging to \fBsyslogd\fR(8).
+\fBpostlogd\fR(8) service. An empty value selects logging to \fBsyslogd\fR(8).
 Specify "/dev/stdout" to select logging to standard output. Stdout
 logging requires that Postfix is started with "postfix start\-fg".
 .PP
diff -Nru postfix-3.4.4/proto/postconf.proto postfix-3.4.5/proto/postconf.proto
--- 

Bug#926187: dh-python: dh_python3 replaces shebang with /usr/bin/python not /usr/bin/python3

[Drew Parsons]

Package: dh-python
Version: 3.20190308
Severity: normal

I'm trying to update petsc 3.11 to build with python3 rather than
python2 (petsc 3.11 in the petsc experimental branch on salsa now
supports python3 in its configure script).

Some of petsc's python scripts have a generic shebang, 
  #!/usr/bin/env python 
e.g. PetscBinaryIOTrajectory.py and other scripts in
lib/petsc/bin/ These scripts are installed in package
libpetsc3.11-dev-common, in /usr/share/petsc/3.11/lib/petsc/bin/

I've set petsc's debian/rules to dh $@ --with python3
dh_python3 is invoked by the build, and updates the #!/usr/bin/env python 
shebangs.

But dh_python3 updates the shebangs to /usr/bin/python instead of
/usr/bin/python3

I would have expected dh_python3 to update them to /usr/bin/python3,
at least if dh --with python3 is used without python2.

Is this a bug in dh_python3?

(I can override it with dh_python3 --shebang of course, but I'm trying
to use automatic defaults where possible)


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

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

Versions of packages dh-python depends on:
ii  python33.7.3-1
ii  python3-distutils  3.7.3-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev  1.19.6
ii  libdpkg-perl  1.19.6

-- no debconf information

Bug#924523: unblock: plinth/19.2

[Sunil Mohan Adapa]

On Wed, 13 Mar 2019 15:07:27 -0700 Sunil Mohan Adapa 
wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Please unblock package plinth
> (binary packages: plinth, freedombox)
> 
> Due to incorrect release planning, we missed the full freeze deadline by a few
> hours. We assumed packages may transition on 12th March and did our release 
> few
> hours after 2019-03-02 00:00 UTC (package was accepted at 20:47:49 UTC). We
> request you to make an exception and transition FreedomBox release 19.2.
> 

Please let us know if any further information will help with this request.

Thank you,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#913641: [r...@debian.org: fixed openjdk-8 apparently available....]

[Rene Engelhard]

[ initally sent it to the wrong bug... ]

Hi,

ah, so it seems this is fixed in openjdk-8 from stable-security
now since
https://lists.debian.org/debian-security-announce/2019/msg00054.html

See e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#144 ff.
and the security team confirms this.

Regards,

Rene

Bug#926186: debian-edu-config: should invalidate the nscd netgroup cache in case of changes

[Wolfgang Schweer]

Package: debian-edu-config
Version: 2.10.63
Severity: important

After a main server installation the users' home 
directory mounting (depending on netgroup membership) on a workstation 
failed because the nscd caching content had been wrong. This problem 
also showed up from time to time in the past and is really annoying.

The failure can be avoided if the related tool 'gosa-sync-dns-nfs' is 
modified by adding 'nscd -i netgroup' to the end of the script. This 
tool is called automatically just after a workstation has been created 
or modified; the added command invalidates the nscd netgroup cache and 
is actually recommended to run in such a case (see man nscd).

Wolfgang


signature.asc
Description: PGP signature

Bug#926185: mailman: Provided apache.conf does not expose archives under mod_authz

[Sam Kemp]

Package: mailman
Version: 1:2.1.29-1
Severity: normal
Tags: patch

Dear Maintainer,

List archives are by default located under /var/lib and are therefore not
visible through the web server under the default Debian apache2.conf.

The provided configuration template installed at /etc/mailman/apache.conf fixes
this issue in a standard installation, but not in the (commented) section for a
dedicated virtual host.

Patch attached to remedy this.

Would it be worth considering splitting the template file into two, in any
case, to allow more thorough commenting of the two scenarios? I'd be happy to
take that on if confirmed.

Sam



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

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

Versions of packages mailman depends on:
pn  apache2 | httpd
ii  cron [cron-daemon] 3.0pl1-132
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-8
ii  logrotate  3.14.0-4
ii  lsb-base   10.2019031300
ii  python 2.7.15-4
pn  python-dnspython   
ii  ucf3.0038+nmu1

Versions of packages mailman recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.92-2

Versions of packages mailman suggests:
pn  listadmin  
pn  lynx   
pn  mailman3-full  
pn  spamassassin   
--- apache.conf~2019-04-01 17:47:59.116512727 +0100
+++ apache.conf 2019-04-01 17:52:55.544641572 +0100
@@ -50,6 +50,7 @@
 #
 #Options FollowSymLinks
 #AllowOverride None
+#Require all granted
 #
 #
 #Alias /pipermail/ /var/lib/mailman/archives/public/
--- apache.conf~2019-04-01 17:47:59.116512727 +0100
+++ apache.conf 2019-04-01 17:52:55.544641572 +0100
@@ -50,6 +50,7 @@
 #
 #Options FollowSymLinks
 #AllowOverride None
+#Require all granted
 #
 #
 #Alias /pipermail/ /var/lib/mailman/archives/public/
--- apache.conf~2019-04-01 17:47:59.116512727 +0100
+++ apache.conf 2019-04-01 17:52:55.544641572 +0100
@@ -50,6 +50,7 @@
 #
 #Options FollowSymLinks
 #AllowOverride None
+#Require all granted
 #
 #
 #Alias /pipermail/ /var/lib/mailman/archives/public/
--- apache.conf~2019-04-01 17:47:59.116512727 +0100
+++ apache.conf 2019-04-01 17:52:55.544641572 +0100
@@ -50,6 +50,7 @@
 #
 #Options FollowSymLinks
 #AllowOverride None
+#Require all granted
 #
 #
 #Alias /pipermail/ /var/lib/mailman/archives/public/

Bug#926184: debian-edu-config: don't prompt users to set up the initial LXQt session manually

[Wolfgang Schweer]

Package: debian-edu-config
Version: 2.10.63
Severity: important

While testing recent official installation images (both netinst and BD 
type) for different installation scenarios and desktop environments, I 
noticed that a user needs to do the initial desktop setup manually 
(specify the window manager, configure the panel) if LXQt is used as DE. 
This problem showed up now that the lxqt-branding-debian' package is 
available and installed by default.

Cfengine can be used to provide a decent user experience, just use the 
XDG environment approach for all DEs instead of desktop-profiles. (To 
disable desktop-profiles'PERSONALITY=sheep' is needed in 
/etc/default/desktop-profiles.)

Wolfgang


signature.asc
Description: PGP signature

Bug#911925: fixed openjdk-8 apparently available....

[Rene Engelhard]

Hi,

ah, so it seems this is fixed in openjdk-8 from stable-security
now since
https://lists.debian.org/debian-security-announce/2019/msg00054.html

See e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#144 ff.
and the security team confirms this.

Regards,

Rene

Bug#926181: want automatic forwarding of patches to the upstream branch

[Ian Jackson]

Osamu Aoki writes ("Bug#926181: want automatic forwarding of patches to the 
upstream branch"):
> Package: dgit
> Version: 8.4
> Severity: wishlist

Hi.  Thanks for your message.  I'm always interested in hearing what
people want so please don't be discouraged by what I say next:

> In case of the Debian maintainer is the same person as the upstream
> maintainer, I would like to see automatic support to the operation
> described in dgit-maint-merge(7).  This is nice alternative to native
> package workflow and nice upstream history.

I am struggling to understand how you think this could work
automatically.  The biggest problem is that the data model in
dgit-maint-merge(7) does not necessarily break the Debian delta into
individual commits.

Also a problem is that I don't think there is an easy way of
discovering what the upstream is like and how to submit patches there.

(As an aside: I don't think any of this depends on whether the Debian
maintainer is the same person as the upstream with a different hat
on.)

> |FORWARDING PATCHES UPSTREAM
> | The basic steps are:
> |
> | 1.  Create a new branch based off upstream's master branch.
> | 3.  Push the branch somewhere and ask upstream to merge it, or use 
> git-format-patch(1) or git-request-pull(1).

So (taking things out of order) these require knowing what the
upstream is and how to find its master branch and submit a merge
request.

It's true that we do have some metadata conventions for this kind of
thing in Debian.  But maybe the task of automating steps 1 and 3
should be a separate program, in devscripts maybe ?  It doesn't seem
dgit specific.

> | 2.  git-cherry-pick(1) commits from your master branch onto your new branch.

This is the hardest part.  I think in general only the maintainer will
know what commit(s) to cherry-pick.

> I want automated operation which goes like:

You seem to think that with dgit-maint-merge(7) there is a nice linear
list of the commits which are in Debian but not upstream.  But there
isn't: in the general case, there is a lot of merging and the only
reasonably condensed representation of the Debian delta is the output
of `git diff' between the upstream and Debian branches.

I think what you really want to make this easy is a different data
model.  Have you looked at git-debrebase or gbp pq ?  Both of those
maintain the Debian delta as a linear series of commits.

git-debrebase already knows how to do many of the manipulations you
describe.  For example:

>  * for commit changing within debian/* only
>--> ignore
>  * for commit changing outside of debian/* only
>--> apply as is with the same commit messages
>  * for commit changing everything
>--> apply changes outside of debian/*
>--> use the same commit message

git-debrebase already knows how to separate commits out into "Debian"
parts and "upstream files" parts, and can split a "mixed" commit into
its two halves.  So it can leave you with a tidy delta queue.

Perhaps there should be a
   git-debrebase list
which shows you the delta queue and maybe some of your other
suggestions might make good git-debrebase features.

I hope my explanations make some kind of sense.  If not maybe we need
a less formal but more interactive channel such as irc; feel free to
look for me as Diziet on oftc and freenode.

Ian.

Bug#926183: debian-edu-config: fails to install LTSP chroot if BD iso image is used

[Wolfgang Schweer]

Package: debian-edu-config
Version: 2.10.63
Severity: important

While testing recent official Debian Edu installation images (both 
netinst and BD type) for different installation scenarios and desktop 
environments, I noticed that the LTSP chroot installation failed in case 
of the BD image (where no mirror is queried by design).

A minimal change will fix it:
Add DIST="buster" to etc/ltsp/ltsp-build-client.conf

Wolfgang


signature.asc
Description: PGP signature

Bug#926182: guile-2.2: autoreconf'ed scripts using guile.m4 cannot find guild & guile-config/tools

[Ahmed El-Mahmoudy]

Package: guile-2.2
Version: 2.2.4+1-1
Severity: normal

Building gwave against guile-2.2 fails if gwave runs dh_autoreconf, that 
is bexause the autoreconf'ed configure script fails to find guild 
and guile-config/tools binaries, relevant configure log below:

configure: checking for guile 2.2
configure: found guile 2.2
checking for guile-2.2... /usr/bin/guile-2.2
checking for Guile version >= 2.2... 2.2.4
checking for guild-2.2... no
checking for guile-config-2.2... no
checking for guile-tools-2.2... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for GUILE... yes
configure: error: 'guild' binary not found; please check your guile-2.x 
installation.

The problem is because after autoreconf, the configure script searches 
for guild with the -2.2 suffix, yet the guile-2.2-dev package installs 
guild without that suffix, although guile binary has the -2.2 suffix in 
guile-2.2 package. Yet in /usr/share/aclocal/guile.m4 it says:

# @code{guile} is still not found, signal an error. The suffix, if any,
# that was required to find @code{guile} will be used for @code{guild}
# as well.

Hence,I beleive that that there is an issue with guile-2.2 package. 
Either the guild & guile-config/tools binaries shpuld be insyalled with 
-2.2 suffix (probably installing symlinks with no suffix to the 
respective -2.2 suffixed binaries), or the guile.m4 script needs to be 
fixed.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#926009: openjdk-11 breaks libreoffice autopkgtests

[Rene Engelhard]

Hi,

On Mon, Apr 01, 2019 at 06:41:07PM +0200, Rene Engelhard wrote:
> *shrugs*. So another
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913641 where this
> isn't fixed in (current) stable even after months after it was fixed
> for other suites?
> 
> It has a build workaround upstream, no runtime

Ah, just saw
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#149
which means it's fixed in security at least...

Regards,
 
Rene

Bug#923810: ITP: ruby-sassc -- Use libsass with Ruby

[Manas Kashyap]

Any update on this? i have pushed the changes and all , so please see it if
its ready to be uploaded.

On Sat, Mar 30, 2019 at 9:28 PM Manas Kashyap 
wrote:

> As i talked with ruby-team , so they advised me on learning the new
> techniques more and also as adding gbp.conf is a nice thing to do and
> practice , so , i will keep it maintained in sass-team
>
>
> On Thu, Mar 28, 2019 at 12:38 AM Jonas Smedegaard  wrote:
>
>> Quoting Manas Kashyap (2019-03-27 17:37:49)
>> > So, As Jonas said , that the way we do in ruby-team , keeping sbuild
>> > happy and checking it from meta build command , is not similar to the
>> > way it is maintained by sass team , so i would like to maintain this
>> > ruby-sassc package in ruby-team , therefore i request , to please
>> > delete the repo from sass team and i will ask in ruby-team to create a
>> > desired repo and will add it there.
>>
>> Too bad this is the outcome, but that is your choice to make.
>>
>> You have the power in the Sass team to delete the repository yourself,
>> but if you don't do that - e.g. if you unsubscribe from the team while
>> leaving behind the repository - then I will clean up after you.
>>
>> Thanks for your interest in maintaining ruby-sassc, regardless how.
>> Hope to hear more from you in the future.  Did you perhaps consider
>> attending the next Debconf?  You are quite welcome!
>>
>>   https://debconf19.debconf.org/
>>
>>
>>  - Jonas
>>
>> --
>>  * Jonas Smedegaard - idealist & Internet-arkitekt
>>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>>
>>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>>
>

Bug#926181: want automatic forwarding of patches to the upstream branch

[Osamu Aoki]

Package: dgit
Version: 8.4
Severity: wishlist

In case of the Debian maintainer is the same person as the upstream
maintainer, I would like to see automatic support to the operation
described in dgit-maint-merge(7).  This is nice alternative to native
package workflow and nice upstream history.

|FORWARDING PATCHES UPSTREAM
| The basic steps are:
|
| 1.  Create a new branch based off upstream's master branch.
|
| 2.  git-cherry-pick(1) commits from your master branch onto your new branch.
|
| 3.  Push the branch somewhere and ask upstream to merge it, or use 
git-format-patch(1) or git-request-pull(1).
|
| For example (and it is only an example):
|
| % # fork foo.git on GitHub
| % git remote add -f fork g...@github.com:spwhitton/foo.git
| % git checkout -b fix-error upstream/master
| % git config branch.fix-error.pushRemote fork
| % git cherry-pick master^2
| % git push
| % # submit pull request on GitHub
|
| Note that when you merge an upstream release containing your forwarded 
patches, git and dgit will transparently handle "dropping" the patches that 
have been forwarded, "retaining" the ones that
| haven't.

This is quite a chore which may be helped by automation.

I want automated operation which goes like:

1) Full automatic

 $ dgit update-upstream

 * for commit changing within debian/* only
   --> ignore
 * for commit changing outside of debian/* only
   --> apply as is with the same commit messages
 * for commit changing everything
   --> apply changes outside of debian/*
   --> use the same commit message
 * merge commit from the last upstream commit to master branch

Please note changes are taken from the last commit point used for merge

2) List commit candidates

 $ dgit update-upstream -l
   drop 5c8c1e update packaging policy
   pick 192837 Switch from GNU Makefiles to CMake
   trim 5a6c7e Document the switch to CMake
   pick 918273 Fix detection of OpenSSL in CMake
   pick afbecd http: add support for TLS v1.3
   pick fdbaec Fix detection of cURL in CMake on Windows

3) Exclude specific commits with commandline

 $ dgit update-upstream -x 12345678 -x 1a2b3c4d

 * Do the same as "Full automatic" but exclude commit hash 12345678 and 1a2b3c4d

4) Exclude specific commits with editor selection:

 $ dgit update-upstream -i

 * make git-rebase like editor dialog marking each commit with
   list sent to editor as:
   drop 5c8c1e update packaging policy
   pick 192837 Switch from GNU Makefiles to CMake
   trim 5a6c7e Document the switch to CMake
   pick 918273 Fix detection of OpenSSL in CMake
   pick afbecd http: add support for TLS v1.3
   pick fdbaec Fix detection of cURL in CMake on Windows
 Here;
   - drop drop debian/* changes
   - pick pick upstream only change
   - trim trim debian/* changes but pick upstream only change
 User can specify:
   - drop   (for any)
   - pick   (for pick)
   - trim   (for trim)
   - reword (for pick or trim) --> allow to change commit message

If the last 4) is too much, maybe we can skip since this is easily 
done with "git rebase -i ?" after "dgit update-upstream"

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

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

Versions of packages dgit depends on:
ii  apt 1.8.0
ii  ca-certificates 20190110
ii  coreutils   8.30-3
ii  curl7.64.0-1
ii  devscripts  2.19.4
ii  dpkg-dev1.19.5
ii  dput1.0.3
ii  git [git-core]  1:2.20.1-2
ii  git-buildpackage0.9.13
pn  libdigest-sha-perl  
ii  libdpkg-perl1.19.5
ii  libjson-perl4.02000-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  liblocale-gettext-perl  1.07-3+b4
ii  libtext-glob-perl   0.10-1
ii  libtext-iconv-perl  1.7-5+b7
ii  libwww-perl 6.36-1
ii  perl5.28.1-5

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.9p1-9

Versions of packages dgit suggests:
ii  cowbuilder  0.88
ii  pbuilder0.230.2

-- no debconf information

Bug#926009: openjdk-11 breaks libreoffice autopkgtests

[Rene Engelhard]

# so let's assign it back to both until this is sorted out..
reassign -1 src:libreoffice, src:openjdk-11
thanks

Hi,

On Mon, Apr 01, 2019 at 01:40:09AM +0200, Matthias Klose wrote:
> Control: reassign -1 src:libreoffice
> 
> > IMHO correctly so, some of the changes are so far away from the
> > freeze policy..
> 
> pointy comments won't help, because you will see these changes at least in the

You might call it pointy, but this is the fact.

> first buster security update

*shrugs*. So another
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913641 where this
isn't fixed in (current) stable even after months after it was fixed
for other suites?

It has a build workaround upstream, no runtime

> so maybe some backports for libreoffice are needed? is that fixed in 6.2.x?

I don't even know yet what needs to be changed... That said, I actually
first noticed this the day before Paul filed the bug - with 6.3.0 alpha
git snapshot. So any LO is affected.

Here we could ignore test failures, too, but that wouldn't help at all
for the functionality still needing Java or the autopkgtests :/

Regards,

Rene

Bug#926180: scilab: FTBFS on all

[Ivo De Decker]

package: src:scilab
version: 6.0.1-7
severity: serious
tags: ftbfs

Hi,

The latest version of scilab in unstable fails on all:

https://buildd.debian.org/status/logs.php?pkg=scilab=all

I don't see any relevant changes that might cause this, so I'm filing this bug
against the version in testing (even though that one builds fine). If it turns
out to be related to the new version, feel free to update the version
information.

All the packages installed during the buils of 6.0.1-8 seem to be identical.
The only difference is that all previous attempts were done on buildd
x86-csail-02, while the failing builds are done on x86-bm-01.

Cheers,

Ivo

Bug#926178: grub2 efi boot installs grub.cfg file that seems to be ignored (just stays at prompt)

[Norbert Lange]

Package: grub2
Version: 2.02+dfsg1-16
Severity: important

Hello,

setting up some new systems I ran into the issue that
newer versions of grub-install will place multiple
files into /boot/efi/EFI. One among them is 'grub.cfg'
which tried to set 'root' by searching for the UUID,
then loading the real boot/grub/grub.cfg.

It appears to me, that is file is never used, as
grub just drops to the prompt without any notification.

The older version 2.02+dfsg1-4 is installing a single file,
and boots correctly.



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

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

Versions of packages grub2 depends on:
ii  grub-common  2.02+dfsg1-16
pn  grub-pc  

grub2 recommends no packages.

grub2 suggests no packages.

Bug#926179: debian-security-support: Please mark qtwebengine-opensource-src as limited-support

[Benjamin Barenblat]

Package: debian-security-support
Version: 2019.02.01
Tags: patch

QtWebEngine isn’t explicitly listed in the release notes as “not covered
by security support” [1], but QtWebKit is. QtWebEngine probably belongs
in the same boat – it has a steady stream of CVEs that are quickly
patched upstream, but no DSAs have been issued. Please add
qtwebengine-opensource-src to security-support-limited.

[1] 
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#browser-security
--- debian-security-support/security-support-limited.orig	2018-11-25 08:39:43 +0100
+++ debian-security-support/security-support-limited	2019-04-01 12:14:58 -0400
@@ -17,6 +17,7 @@
 mozjs17 Not covered by security support, only suitable for trusted content
 mozjs24 Not covered by security support, only suitable for trusted content
 ocsinventory-server Only supported behind an authenticated HTTP zone
+qtwebengine-opensource-src No security support upstream and backports not feasible, only for use on trusted content
 qtwebkitNo security support upstream and backports not feasible, only for use on trusted content
 qtwebkit-opensource-src No security support upstream and backports not feasible, only for use on trusted content
 sql-ledger  Only supported behind an authenticated HTTP zone

Bug#818366: synaptic: fails to start under Wayland

[Sebastien CHAVAUX]

Hello everyone,

Let me give my opinion, I think that Synaptic is a graphical manager 
that is important and used a lot, not having synaptic would cause a lot 
of worries and discontent, removed the part of repair facility that 
Debian was too big to bring .


Why not make a conflict with Wayland / Gnome? It's not possible to make 
sure that synaptic installs on a conflict that would remove Wayland?


This is a mistake.

I also think it has had an impact on the GNOME / Wayland user, but not 
on XFCE or other offices that have been long-term thinking and have not 
changed. Why are we deprived of part of the user?


Thank you in advance hoping not to attract the wrath.

Bug#815724: libnet-ssh2-perl: Public key authentication fails when key generated with -a

[Francois Gouget]

Before the first step one should do:
  cd ~/.ssh

Three years later this bug is still present.
I guess that makes sense since the last changelog entry for libssh2 goes 
back to october 2016!


Fortunately there is a workaround: add this use statement right before 
the "use Net::SSH2" line:

use Net::OpenSSH::Compat::SSH2 qw(:supplant);

This causes the script to use Net::OpenSSH which actually works. 
Unfortunately this workaround will not work for all scripts but 
migrating to Net::OpenSSH is still a good idea to avoid Net::SSH2's 
compatibility and maintenance issues.


-- 
Francois Gouget   http://fgouget.free.fr/
 Theory is where you know everything but nothing works.
Practice is where everything works but nobody knows why.
  Sometimes they go hand in hand: nothing works and nobody knows why.

Bug#925973: Linux 9 stretch What to do about reviving speakup?

[Samuel Thibault]

Hello Kirk,

Could you please check that version 1:0.80-14 fixes the issue?
It does work in my tests, by as history has shown, my tests are usually
not enough, and real tests by an actual users is needed to make really
sure the issue is gone.

Debian is getting frozen, if people want the fix in, they need to check
that it does work.

Samuel

Samuel Thibault, le ven. 29 mars 2019 18:31:44 +0100, a ecrit:
> Samuel Thibault, le ven. 29 mars 2019 17:21:51 +0100, a ecrit:
> > Thanks for it!  I'll fix that for Buster. Unfortunately the next upgrade
> > will again have the issue, since it's the prerm script which stops
> > espeakup. But the upgrade after that (or a reinstall) should be fine.
> 
> Could you try to install version 1:0.80-14 from 
> 
> deb http://incoming.debian.org/debian-buildd buildd-unstable main contrib 
> non-free
> 
> The upgrade should still have the issue, but if you re-install with
> --reinstall you shouldn't have the issue any more.
> 
> Samuel

Bug#447701: Status of this bug?

[Josh Triplett]

This bug seems to have been open for more than a decade, spanning the
entire duration of the last couple of releases.
python3-software-properties Recommends unattended-upgrades, which means
it gets pulled in automatically on a default desktop install. The
debian-installer team stopped installing unattended-upgrades by default
as of Buster alpha 4, at the request of the Debian security team
(https://lists.debian.org/debian-boot/2018/05/msg00250.html). I don't
think it's appropriate for a Python module package (and one that gets
pulled in by dependencies from other packages) to pull in
unattended-upgrades, even by Recommends or Suggests.

Bug#924800: [PATCH] resolve race in test cleanup by making second attempt more forceful

[Joey Hess]

Sean Whitton wrote:
> Errors are like this:
> 
> .t/gpgtest/9/S.gpg-agent.extra: 
> removeDirectoryRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:r
>  emovePathRecursive:getSymbolicLinkStatus: does not exist (No such file or 
> directory)
> 
> i.e. the problem seems to be files vanishing while
> removeDirectoryRecursive is running.  removePathForcibly ignores such
> errors.

> + removePathForcibly tmpdir

I'd certianly like to use removePathForcibly -- after all it was added
in response to a bug report I filed about this very kind of problem.

But, the first version of ghc to include it was 8.4.2, which is newer
than the 8.0 minimum I think git-annex supports now, and also newer than
what's in Debian stable. So it would need to be 
#if MIN_VERSION_directory(1,2,7)

It also seems very unlikely that something would wait around for 10
seconds while git-annex is delaying to let any processes that might be
running finish their cleanup, and then run at exactly the same time as
the removeDirectoryRecursive. Since the earlier removeDirectoryRecursive
failed on the same file, I have the feeling the problem is not actually
with the file vanishing out from under it, but something else to do with
it being a socket.. It seems to me that removePathForcibly would
probably at best ignore the error in removal and so leave a .t directory
hanging around at the end?

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#900912: "AtkWrapper not found" error impacting JOSM on Ubuntu/Mint

[Samuel Thibault]

Samuel Thibault, le lun. 01 avril 2019 15:54:17 +0200, a ecrit:
> Vincent Privat, le ven. 24 août 2018 18:33:56 +0200, a ecrit:
> > Patching openjdk with your try/catch proposal and making the ATK wrapper a
> > Recommends sounds a good idea.
> > 
> > Don't wait for openjdk guys for an answer: they simply don't care anymore 
> > with
> > desktop technologies.
> 
> FI, I plan to upload the attached NMU, which does it:

But currently the 11.0.3+4-3 version is blocked in unstable, and notably
due to a regression on libreoffice, so I'm not sure what to do for now.

Samuel

> adding the ATK wrapper classpath, catching ATK wrapper load failure,
> so we can enable it again.
> 
> Samuel

> diff -Nru openjdk-11-11.0.3+4/debian/changelog 
> openjdk-11-11.0.3+4/debian/changelog
> --- openjdk-11-11.0.3+4/debian/changelog  2019-03-29 09:06:03.0 
> +0100
> +++ openjdk-11-11.0.3+4/debian/changelog  2019-03-31 17:49:09.0 
> +0200
> @@ -1,3 +1,13 @@
> +openjdk-11 (11.0.3+4-3.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * patches/jaw-classpath.diff: Fix finding the Java ATK wrapper.
> +  * patches/jaw-optional.diff: Make failing to load the Java ATK wrapper
> +  non-fatal.
> +  * rules: Enable Java ATK wrapper for Buster. Closes: #900912.
> +
> + -- Samuel Thibault   Sun, 31 Mar 2019 17:49:09 +0200
> +
>  openjdk-11 (11.0.3+4-3) unstable; urgency=medium
>  
>[ Matthias Klose ]
> diff -Nru openjdk-11-11.0.3+4/debian/patches/jaw-classpath.diff 
> openjdk-11-11.0.3+4/debian/patches/jaw-classpath.diff
> --- openjdk-11-11.0.3+4/debian/patches/jaw-classpath.diff 1970-01-01 
> 01:00:00.0 +0100
> +++ openjdk-11-11.0.3+4/debian/patches/jaw-classpath.diff 2019-03-31 
> 17:49:09.0 +0200
> @@ -0,0 +1,14 @@
> +Fix finding the Java ATK wrapper, see #900912
> +
> +Index: openjdk-10-10.0.1+10/src/hotspot/os/linux/os_linux.cpp
> +===
> +--- openjdk-10-10.0.1+10.orig/src/hotspot/os/linux/os_linux.cpp
>  openjdk-10-10.0.1+10/src/hotspot/os/linux/os_linux.cpp
> +@@ -369,6 +369,7 @@ void os::init_system_properties_values()
> + }
> + Arguments::set_java_home(buf);
> + set_boot_path('/', ':');
> ++Arguments::append_sysclasspath("/usr/share/java/java-atk-wrapper.jar");
> +   }
> + 
> +   // Where to look for native libraries.
> diff -Nru openjdk-11-11.0.3+4/debian/patches/jaw-optional.diff 
> openjdk-11-11.0.3+4/debian/patches/jaw-optional.diff
> --- openjdk-11-11.0.3+4/debian/patches/jaw-optional.diff  1970-01-01 
> 01:00:00.0 +0100
> +++ openjdk-11-11.0.3+4/debian/patches/jaw-optional.diff  2019-03-31 
> 17:49:09.0 +0200
> @@ -0,0 +1,20 @@
> +Make failing to load the Java ATK wrapper non-fatal
> +
> +---
> + src/java.desktop/share/classes/java/awt/Toolkit.java |4 
> + 1 file changed, 4 insertions(+)
> +
> +--- a/src/java.desktop/share/classes/java/awt/Toolkit.java
>  b/src/java.desktop/share/classes/java/awt/Toolkit.java
> +@@ -610,7 +610,11 @@ public abstract class Toolkit {
> + }
> + });
> + if (!GraphicsEnvironment.isHeadless()) {
> ++  try {
> + loadAssistiveTechnologies();
> ++  } catch (java.awt.AWTError e) {
> ++// too bad
> ++  }
> + }
> + }
> + return toolkit;
> diff -Nru openjdk-11-11.0.3+4/debian/patches/series 
> openjdk-11-11.0.3+4/debian/patches/series
> --- openjdk-11-11.0.3+4/debian/patches/series 2019-03-28 09:32:28.0 
> +0100
> +++ openjdk-11-11.0.3+4/debian/patches/series 2019-03-31 17:49:09.0 
> +0200
> @@ -38,3 +38,5 @@
>  jdk-improve-gtk3-compatibility.patch
>  keep-gtk2-as-default.patch
>  8221083.diff
> +jaw-classpath.diff
> +jaw-optional.diff
> diff -Nru openjdk-11-11.0.3+4/debian/rules openjdk-11-11.0.3+4/debian/rules
> --- openjdk-11-11.0.3+4/debian/rules  2019-03-28 20:44:54.0 +0100
> +++ openjdk-11-11.0.3+4/debian/rules  2019-03-31 17:49:09.0 +0200
> @@ -1081,13 +1081,13 @@
>  ifeq ($(with_bridge),atk)
>  #  only add releases that are known to work with atk
>  #  by default leave atk disabled
> -#  ifneq (,$(filter $(distrel),))
> -#cp -p debian/accessibility-atk.properties.enabled \
> +  ifneq (,$(filter $(distrel),buster))
> + cp -p debian/accessibility-atk.properties.enabled \
>   $(d)/$(basedir)/conf/accessibility.properties
> -#  else
> +  else
>   cp -p debian/accessibility-atk.properties.disabled \
>   $(d)/$(basedir)/conf/accessibility.properties
> -#  endif
> +  endif
>  else
>   cp -p debian/accessibility.properties $(d)/$(basedir)/conf/
>  endif
> @@ -1427,23 +1427,26 @@
>endif
>  endif
>  
> -ifeq (0,1)
> -# FIXME: ext not longer supported
>  ifeq ($(with_bridge),atk)
>   : # create links for the atk wrapper
> +  ifeq (0,1)
> +  # FIXME: ext no longer supported
>   echo 

Bug#554444: libdebian-installer: Unable to parse Packages files with long lines

[Asbjørn Sloth Tønnesen]

retitle 55 libdebian-installer: Unable to parse Packages files with long 
lines
severity 55 important
block 904699 by 55
thanks

On 11/4/09 5:04 PM, Ricardo Salveti de Araujo wrote:

After looking at the libdebian-installer code, I found that the
problem is related with the READSIZE variable, as I got a package that
had more than 16384 characters at the recommends field.

I know that this is quite a huge line, but at OE we have quite many
packages that are split in a lot of different packages.


I was unable to find an example OE Packages file, but I believe that
10 years later Debian now have longer lines.

On 8/5/18 11:13 AM, Cyril Brulebois wrote in #904699:
> That's a very good catch, and indeed a rather sad situation. Given the
> current size of that Provides line, I fear bumping from 16k to 64k might
> only paper over the issue for a while, and that it might come back later
> on.

It would be sad if buster's libdebian-installer, and thereby cdebootstrap,
would be unable to parse it's own release.

IMHO I think this is close to RC, but will leave that up to DD's to decide.

Given that buster is frozen it's properly only feasible to get the 64K or 128K
fix approved. Rewriting the parser will properly have to wait for the next 
cycle.


Top 10 long lines in buster:

$ curl -Ls 
https://deb.debian.org/debian/dists/buster/main/binary-amd64/Packages.gz
|zcat|awk '{if($1=="Package:")pkg=$2;print length,pkg,$1;}'|sort -nr|head -10

59936 librust-winapi-dev Provides:
13786 qt4-demos-dbg Build-Ids:
11326 libc6-dbg Build-Ids:
9900 mono-devel Replaces:
9786 mono-devel Breaks:
8579 inspircd-dbg Build-Ids:
7960 gstreamer1.0-libav Gstreamer-Elements:
7625 libmono-cil-dev Depends:
7515 oca-core Provides:
6946 parl-desktop-world Depends:

--
Best regards
Asbjørn Sloth Tønnesen

Bug#833182: drmSetMaster failed: Permission denied

[Greg Wooledge]

I ran into this bug upon upgrading from stretch to buster today.

This system is an HP EliteDesk desktop PC with:

00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM 
Registers [8086:191f] (rev 07)
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 
[8086:1912] (rev 06)


I have the relevant non-free firmware installed.

wooledg:~$ sudo dmesg | grep -i firmware
[sudo] password for wooledg: 
[0.194776] Spectre V2 : Enabling Restricted Speculation for firmware calls
[0.231494] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[3.892737] i915 :00:02.0: firmware: direct-loading firmware 
i915/skl_dmc_ver1_27.bin
[3.893012] [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin 
(v1.27)


Under stretch, I was able to run 'startx' from tty1 as my non-root user
account, without needs_root_rights=yes in Xwrapper.config.  X ran as me,
using the modeset driver, and logged in ~/.local/share/xorg/.

After the upgrade, running startx gave me these errors:

wooledg:~$ grep EE .local/share/xorg/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1140.120] (EE) systemd-logind: failed to get session: PID 1762 does not 
belong to any known session
[  1140.193] (EE) modeset(0): drmSetMaster failed: Permission denied
[  1140.193] (EE)
[  1140.193] (EE) AddScreen/ScreenInit failed for driver 0
[  1140.193] (EE)
[  1140.193] (EE)
[  1140.193] (EE) Please also check the log file at 
"/home/wooledg/.local/share/xorg/Xorg.0.log" for additional information.
[  1140.193] (EE)
[  1140.205] (EE) Server terminated with error (1). Closing log file.


I used lynx from the console to search for a workaround.  I tried purging
the xserver-xorg-legacy package, without success.  I tried reinstalling
it, without success.

I ended up putting needs_root_rights=yes in /etc/X11/Xwrapper.config.
Now, it runs as root, and logs in /var/log/, but at least it's working.

wooledg:~$ grep EE /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1178.050] (EE) systemd-logind: failed to get session: PID 1812 does not 
belong to any known session
[  1178.270] (II) Initializing extension MIT-SCREEN-SAVER


I can't tell whether the systemd-logind error is relevant or not.

Various packages that are installed:

wooledg:~$ dpkg -l linux-image\* libpam-systemd xserver-xorg-\* | grep '^.i'
ii  libpam-systemd:amd64241-1amd64
system and service manager - PAM module
ii  linux-image-4.19.0-4-amd64  4.19.28-2amd64
Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.9.0-7-amd64   4.9.110-3+deb9u2 amd64
Linux 4.9 for 64-bit PCs
ii  linux-image-4.9.0-8-amd64   4.9.144-3.1  amd64
Linux 4.9 for 64-bit PCs
ii  linux-image-amd64   4.19+104 amd64
Linux for 64-bit PCs (meta-package)
ii  xserver-xorg-core   2:1.20.3-1   amd64
Xorg X server - core server
ii  xserver-xorg-input-all  1:7.7+19 amd64
X.Org X server -- input driver metapackage
ii  xserver-xorg-input-libinput 0.28.2-1 amd64
X.Org X server -- libinput input driver
ii  xserver-xorg-input-wacom0.34.99.1-1  amd64
X.Org X server -- Wacom input driver
ii  xserver-xorg-legacy 2:1.20.3-1   amd64
setuid root Xorg server wrapper
ii  xserver-xorg-video-all  1:7.7+19 amd64
X.Org X server -- output driver metapackage
ii  xserver-xorg-video-amdgpu   18.1.99+git20190207-1amd64
X.Org X server -- AMDGPU display driver
ii  xserver-xorg-video-ati  1:18.1.99+git20190207-1  amd64
X.Org X server -- AMD/ATI display driver wrapper
ii  xserver-xorg-video-fbdev1:0.5.0-1amd64
X.Org X server -- fbdev display driver
ii  xserver-xorg-video-intel2:2.99.917+git20180925-2 amd64
X.Org X server -- Intel i8xx, i9xx display driver
ii  xserver-xorg-video-nouveau  1:1.0.16-1   amd64
X.Org X server -- Nouveau display driver
ii  xserver-xorg-video-qxl  0.1.5-2+b1   amd64
X.Org X server -- QXL display driver
ii  xserver-xorg-video-radeon   1:18.1.99+git20190207-1  amd64
X.Org X server -- AMD/ATI Radeon display driver
ii  xserver-xorg-video-vesa 1:2.4.0-1amd64
X.Org X server -- VESA display driver
ii  xserver-xorg-video-vmware   1:13.3.0-2   amd64
X.Org X server -- VMware display driver

Bug#926177: unblock: puppet-module-swift/13.1.0-4

[Thomas Goirand]

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

Please unblock package puppet-module-swift,

When patching puppet-module-swift, to remove the "nobarrier" option
from fstab (not supported anymore in Buster), I did a syntax mistake
(missing closing single quote at the end of the string). This last
upload fixes it.

I've atteched the (one liner) debdiff.

Please unblock puppet-module-swift/13.1.0-4

Cheers,

Thomas Goirand (zigo)
diff -Nru puppet-module-swift-13.1.0/debian/changelog 
puppet-module-swift-13.1.0/debian/changelog
--- puppet-module-swift-13.1.0/debian/changelog 2019-01-24 14:00:43.0 
+0100
+++ puppet-module-swift-13.1.0/debian/changelog 2019-04-01 17:01:12.0 
+0200
@@ -1,3 +1,9 @@
+puppet-module-swift (13.1.0-4) unstable; urgency=medium
+
+  * Fix remove-nobarrier-option.patch braking Puppet's syntax.
+
+ -- Thomas Goirand   Mon, 01 Apr 2019 17:01:12 +0200
+
 puppet-module-swift (13.1.0-3) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru 
puppet-module-swift-13.1.0/debian/patches/remove-nobarrier-option.patch 
puppet-module-swift-13.1.0/debian/patches/remove-nobarrier-option.patch
--- puppet-module-swift-13.1.0/debian/patches/remove-nobarrier-option.patch 
2019-01-24 14:00:43.0 +0100
+++ puppet-module-swift-13.1.0/debian/patches/remove-nobarrier-option.patch 
2019-04-01 17:01:12.0 +0200
@@ -14,7 +14,7 @@
 +$options = 'noatime,nodiratime,loop'
} else {
 -$options = 'noatime,nodiratime,nobarrier'
-+$options = 'noatime,nodiratime
++$options = 'noatime,nodiratime'
}
  
if($fstype == 'xfs'){

Bug#926154: falkon: new version of falkon available

[Georges Khaznadar]

Dear Klaumi,

Klaumi Klingsporn a écrit :
> Package: falkon
> Version: 3.1.0-0~kmk1
> Severity: normal
> 
> Dear Maintainer,
> 
> since 19 March 2019 a new version of falkon is released (actually the second 
> new release after
> the one in testing ;-) ).
> 
> Would be nice if the new version was packaged before buster goes into freeze.

Buster has already entered the freeze: no new versions of packages are
allowed into testing.

I shall upload updates to salsa's Git repository, and publish the new
package into unstable when Buster becomes stable.

Best regards,   Georges.

> If it helps: I tried
> to build packages by myself, they work fine so far. You can find them at
> http://apt.klaumikli.de/testing.
> 
> Thanks for maintaining falkon for debian!
> 
> Klaumi
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (200, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_DE:de: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 falkon depends on:
> ii  libc62.28-8
> ii  libgcc1  1:8.3.0-4
> ii  libglib2.0-0 2.58.3-1
> ii  libgnome-keyring03.12.0-1+b2
> ii  libqt5core5a 5.11.3+dfsg1-1
> ii  libqt5dbus5  5.11.3+dfsg1-1
> ii  libqt5gui5   5.11.3+dfsg1-1
> ii  libqt5network5   5.11.3+dfsg1-1
> ii  libqt5positioning5   5.11.3+dfsg-2
> ii  libqt5printsupport5  5.11.3+dfsg1-1
> ii  libqt5qml5   5.11.3-4
> ii  libqt5quick5 5.11.3-4
> ii  libqt5quickwidgets5  5.11.3-4
> ii  libqt5sql5   5.11.3+dfsg1-1
> ii  libqt5sql5-sqlite5.11.3+dfsg1-1
> ii  libqt5webchannel55.11.3-2
> ii  libqt5webenginecore5 5.11.3+dfsg-2+b1
> ii  libqt5webenginewidgets5  5.11.3+dfsg-2+b1
> ii  libqt5widgets5   5.11.3+dfsg1-1
> ii  libqt5x11extras5 5.11.3-2
> ii  libssl1.11.1.1b-1
> ii  libstdc++6   8.3.0-4
> ii  libxcb1  1.13.1-2
> ii  qml-module-qtwebengine   5.11.3+dfsg-2+b1
> 
> falkon recommends no packages.
> 
> falkon suggests no packages.
> 
> -- no debconf information

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#921471: Should pdf2htmlex be removed?

[Johannes Schauer]

Quoting Scott Kitterman (2019-04-01 16:43:14)
> > > > Alright, I think it's time to pull the plug. :(
> > > > 
> > > > Reassigning and retitling accordingly.
> > > 
> > > Unfortunately, it's not quite there yet:
> > > 
> > > Checking reverse dependencies...
> > > # Broken Build-Depends:
> > > clips: pdf2htmlex
> > > 
> > > Dependency problem found.
> > > 
> > > clips is in Testing, so if this is going to be removed from Buster it will
> > > either have to be removed too or drop the build-depends.  Please remove
> > > the
> > > moreinfo tag when it's sorted.
> > 
> > I don't know which script you are running but as far as I can see:
> > 
> > https://sources.debian.org/src/clips/6.24-3.2/debian/control/
> > 
> > The version of clips in testing (6.24-3.2) does *not* build-depend on
> > pdf2htmlex.
> > 
> > The version in unstable does, yes but as it is, this does not affect
> > testing, right?
> > 
> > What am I missing?
> 
> dak checks unstable (since that's what the FTP team changes directly), so 
> that's why it shows up.  I'll go ahead with the removal then.  Someone needs 
> an RC bug against the version of clips in unstable for the soon to be missing 
> build-depend.
> 
> Thanks for taking the time to check.

Thank you! I already contacted the maintainer after your last mail.

cheers, josch


signature.asc
Description: signature

Bug#924833: Bug#926150: unblock: sip4/4.19.14+dfsg-2

[Paul Gevers]

Hi Dmitry,

On 01-04-2019 10:13, Dmitry Shachnev wrote:
> unblock sip4/4.19.14+dfsg-2

unblocked, thanks.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#925876: RFS: libgsm/1.0.18-2 [RC]

[gregor herrmann]

On Fri, 29 Mar 2019 14:37:10 +0100, gregor herrmann wrote:

> On Wed, 27 Mar 2019 13:51:28 -0700, Felix Lechner wrote:
> 
> > I am looking for a sponsor for my package "libgsm"
> 
> > dget -x 
> > https://mentors.debian.net/debian/pool/main/libg/libgsm/libgsm_1.0.18-2.dsc
> > 
> >   Changes since the last upload:
> > 
> >   [ gregor herrmann ]
> >   * Fix "unhandled symlink to directory conversion:
> > /usr/share/doc/PACKAGE":
> > add libgsm1-dev.maintscript for the symlink_to_dir transition.
> > (Closes: #919438)
> > 
> >   [ Felix Lechner ]
> >   * Bump Standards-Version to 4.3.0
> 
> I had a look at the package, but either I'm doing something wrong or
> something went wrong in the update from 1.0.18-1 to -2: The diff
> (attached) looks kinda unexpected.

I see that bartm has uploaded 1.0.18-2, and the diff contains only
the changes for #919438 - thanks to both of you!

I guess this RFS bug can be closed now?
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#921471: Should pdf2htmlex be removed?

[Scott Kitterman]

On Monday, April 01, 2019 09:25:17 AM Johannes Schauer wrote:
> Control: tag -1 - moreinfo
> 
> Quoting Scott Kitterman (2019-04-01 06:26:13)
> 
> > > Alright, I think it's time to pull the plug. :(
> > > 
> > > Reassigning and retitling accordingly.
> > 
> > Unfortunately, it's not quite there yet:
> > 
> > Checking reverse dependencies...
> > # Broken Build-Depends:
> > clips: pdf2htmlex
> > 
> > Dependency problem found.
> > 
> > clips is in Testing, so if this is going to be removed from Buster it will
> > either have to be removed too or drop the build-depends.  Please remove
> > the
> > moreinfo tag when it's sorted.
> 
> I don't know which script you are running but as far as I can see:
> 
> https://sources.debian.org/src/clips/6.24-3.2/debian/control/
> 
> The version of clips in testing (6.24-3.2) does *not* build-depend on
> pdf2htmlex.
> 
> The version in unstable does, yes but as it is, this does not affect
> testing, right?
> 
> What am I missing?

dak checks unstable (since that's what the FTP team changes directly), so 
that's why it shows up.  I'll go ahead with the removal then.  Someone needs 
an RC bug against the version of clips in unstable for the soon to be missing 
build-depend.

Thanks for taking the time to check.

Scott K

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

Bug#923845: finish-install still contains obsolete(?) upstart support

[Cyril Brulebois]

Control: tag -1 patch

Steve McIntyre  (2019-03-06):
> Package: finish-install
> Version: 2.100
> Severity: minor
> 
> Noticed while committing other changes in finish-install.d/90console -
> it still has support in here for upstart (for setting up serial
> console). I've left this along for now, but adding this bug as a
> reminder to look again in future.
> 
> Checking https://tracker.debian.org/pkg/upstart, we've not had upstart
> in Debian unstable for 3 years now.

Candidate patch in the bullseye branch:
  https://salsa.debian.org/installer-team/finish-install/commits/bullseye

BTW, it seems the 2.99 tag pointed at the same commit as the 2.100 one,
so I've deleted it. Copying Holger who was apparently the uploader for a
possible redo and re-push.


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


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Alexander Larsson]

On Tue, Mar 26, 2019 at 9:09 AM Alexander Larsson
 wrote:
>
> On Tue, Mar 26, 2019 at 7:15 AM Akira TAGOH  wrote:
> >
> > Hi Alex,
> >
> > Have you tried new implementation yet? I believe it should be
> > reflected our discussion though, I want to see some comment from you
> > because flatpak is only customer for salt thing so far. if it works, I
> > can commit it to master and make a release for them.
>
> I have not, but I will put it on the list, will have a look later this week.

So, i'm trying to test this, but I'm running into a weird issue I
don't understand.
I started by creating a new flatpak runtime, deriving from gnome 3.30,
adding just the fontconfig from your branch.
All the files requred are here:
  https://gist.github.com/alexlarsson/8912637dd6173591a8dec7c043cfa01d
Including a build.sh which will build the entire thing.

The weird thing is that i'm failing to create the cache in one of two cases.
What happens is that flatpak-builder first builds the SDK, and after
building that it runs the "cleanup-commands", which (see the gist for
the commands) produces this output:


CLEANUP SDK
created /etc/fonts/conf.d/50-flatpak-salted.conf:



/usr/share/fonts

regenerating system caches for sdk
Fontconfig warning: "/usr/etc/fonts/fonts.conf", line 33: empty font
directory name ignored
Fontconfig warning:
"/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf", line 7:
empty font directory name ignored
/usr/share/fonts: caching, new cache contents: 0 fonts, 7 dirs
/usr/share/fonts/cantarell: caching, new cache contents: 5 fonts, 0 dirs
/usr/share/fonts/dejavu: caching, new cache contents: 22 fonts, 0 dirs
/usr/share/fonts/eosrei-emojione: caching, new cache contents: 1 fonts, 0 dirs
/usr/share/fonts/gnu-free: caching, new cache contents: 12 fonts, 0 dirs
/usr/share/fonts/google-crosextra-caladea: caching, new cache
contents: 4 fonts, 0 dirs
/usr/share/fonts/google-crosextra-carlito: caching, new cache
contents: 4 fonts, 0 dirs
/usr/share/fonts/liberation-fonts: caching, new cache contents: 12 fonts, 0 dirs
/run/host/fonts: skipping, no such directory
/run/host/user-fonts: skipping, no such directory
/usr/share/fonts/cantarell: skipping, looped directory detected
/usr/share/fonts/dejavu: skipping, looped directory detected
/usr/share/fonts/eosrei-emojione: skipping, looped directory detected
/usr/share/fonts/gnu-free: skipping, looped directory detected
/usr/share/fonts/google-crosextra-caladea: skipping, looped directory detected
/usr/share/fonts/google-crosextra-carlito: skipping, looped directory detected
/usr/share/fonts/liberation-fonts: skipping, looped directory detected
/usr/cache/fontconfig: cleaning cache directory
/app/cache/fontconfig: not cleaning non-existent cache directory
/run/host/fonts-cache: not cleaning non-existent cache directory
/run/host/user-fonts-cache: not cleaning non-existent cache directory
/usr/var/cache/fontconfig: cleaning cache directory
fc-cache: succeeded
resulting /usr/cache/fontconfig:
total 184
-rw-rw-r-- 1 1000 1000  2536 Apr  1 14:25
240592bdd7bdf1b16d89e7edeb4d2486-le64.cache-7
-rw-rw-r-- 1 1000 1000 77096 Apr  1 14:25
38abaa55af3aedbc13e8d17a987f8026-le64.cache-7
-rw-rw-r-- 1 1000 1000 47104 Apr  1 14:25
46df990863fe9cfbed3fe21e89696ec6-le64.cache-7
-rw-rw-r-- 1 1000 1000  6936 Apr  1 14:25
612dd7798ef7fe64f776a6e49f128560-le64.cache-7
-rw-rw-r-- 1 1000 1000  8376 Apr  1 14:25
b599ef9b1adc87dbcc1c41de14b1d733-le64.cache-7
-rw-rw-r-- 1 1000 1000  6312 Apr  1 14:25
b5aefa49b91159320ae79a3bc3a8ec09-le64.cache-7
-rw-r--r-- 1 1000 1000   200 Apr  1 14:25 CACHEDIR.TAG
-rw-rw-r-- 1 1000 1000   424 Apr  1 14:25
e9903abff2d89c54a7d6bfcd0dde9b25-le64.cache-7
-rw-rw-r-- 1 1000 1000 19928 Apr  1 14:25
e9b75eee6795385ae3f53a200406b963-le64.cache-7

Then it starts over with the platform (non-devel runtime) and does
something similar to it.
This produces the following output:

CLEANUP PLATFORM
created /etc/fonts/conf.d/50-flatpak-salted.conf:



/usr/share/fonts

regenerating system caches for platform
Fontconfig warning: "/usr/etc/fonts/fonts.conf", line 33: empty font
directory name ignored
Fontconfig warning:
"/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf", line 7:
empty font directory name ignored
/usr/share/fonts: caching, new cache contents: 0 fonts, 7 dirs
/usr/share/fonts/cantarell: caching, new cache contents: 5 fonts, 0 dirs
/usr/share/fonts/dejavu: caching, new cache contents: 22 fonts, 0 dirs
/usr/share/fonts/eosrei-emojione: caching, new cache contents: 1 fonts, 0 dirs
/usr/share/fonts/gnu-free: caching, new cache contents: 12 fonts, 0 dirs
/usr/share/fonts/google-crosextra-caladea: caching, new cache
contents: 4 fonts, 0 dirs
/usr/share/fonts/google-crosextra-carlito: caching, new cache
contents: 4 fonts, 0 dirs
/usr/share/fonts/liberation-fonts: caching, new cache contents: 12 fonts, 0 dirs
/run/host/fonts: skipping, no such directory
/run/host/user-fonts: skipping, no such directory
/usr/share/fonts/cantarell: skipping, 

Bug#926176: isc-dhcp-relay: Provide configuration and init support for dhcrelay -6

[Santiago Ruano Rincón]

Package: isc-dhcp-relay
Version: 4.4.1-2
Severity: wishlist

Dear Maintainer,

dhcrelay supports both DHCPv4 and DHCPv6 but their operation mode and
command arguments conflict with each other. A different instance has to
be run for each one of them. Currently, isc-dhcp-relay only includes
debconf and init script for DHCPv4. It would be great to have a similar
support for DHCPv6 too.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#926175: apt-listchanges: only a single changelog is shown when multiple packages are updated

[Nicholas Joll]

Package: apt-listchanges
Version: 3.16
Kernel: 5.0.5-050005-generic
libc-2.27.so
Linux Mint 19.1 x64 Cinnamon

When I update >1 package at once, and whether using Mint's 'Mint Update
tool' or apt, apt-list changes only displays a changelog for *one* of
the packages.

My listchanges.conf file:

[apt]
frontend=gtk
which=both
email_address=none
email_format=text
confirm=true
headers=false
reverse=false
save_seen=/var/lib/apt/listchanges.db
no_network=false
*
*

Bug#924009: Potential fix

[Pierre Jolivet]

I’ve proposed a potential fix here, 
https://github.com/FreeFem/FreeFem-sources/issues/77#issuecomment-476626962 
, 
and I’d like to know if everything is OK for you with the correct ./configure 
flag.

Thanks in advance,
Pierre

Bug#900912: "AtkWrapper not found" error impacting JOSM on Ubuntu/Mint

[Samuel Thibault]

Hello,

Vincent Privat, le ven. 24 août 2018 18:33:56 +0200, a ecrit:
> Patching openjdk with your try/catch proposal and making the ATK wrapper a
> Recommends sounds a good idea.
> 
> Don't wait for openjdk guys for an answer: they simply don't care anymore with
> desktop technologies.

FI, I plan to upload the attached NMU, which does it: adding the ATK
wrapper classpath, catching ATK wrapper load failure, so we can enable
it again.

Samuel
diff -Nru openjdk-11-11.0.3+4/debian/changelog 
openjdk-11-11.0.3+4/debian/changelog
--- openjdk-11-11.0.3+4/debian/changelog2019-03-29 09:06:03.0 
+0100
+++ openjdk-11-11.0.3+4/debian/changelog2019-03-31 17:49:09.0 
+0200
@@ -1,3 +1,13 @@
+openjdk-11 (11.0.3+4-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * patches/jaw-classpath.diff: Fix finding the Java ATK wrapper.
+  * patches/jaw-optional.diff: Make failing to load the Java ATK wrapper
+  non-fatal.
+  * rules: Enable Java ATK wrapper for Buster. Closes: #900912.
+
+ -- Samuel Thibault   Sun, 31 Mar 2019 17:49:09 +0200
+
 openjdk-11 (11.0.3+4-3) unstable; urgency=medium
 
   [ Matthias Klose ]
diff -Nru openjdk-11-11.0.3+4/debian/patches/jaw-classpath.diff 
openjdk-11-11.0.3+4/debian/patches/jaw-classpath.diff
--- openjdk-11-11.0.3+4/debian/patches/jaw-classpath.diff   1970-01-01 
01:00:00.0 +0100
+++ openjdk-11-11.0.3+4/debian/patches/jaw-classpath.diff   2019-03-31 
17:49:09.0 +0200
@@ -0,0 +1,14 @@
+Fix finding the Java ATK wrapper, see #900912
+
+Index: openjdk-10-10.0.1+10/src/hotspot/os/linux/os_linux.cpp
+===
+--- openjdk-10-10.0.1+10.orig/src/hotspot/os/linux/os_linux.cpp
 openjdk-10-10.0.1+10/src/hotspot/os/linux/os_linux.cpp
+@@ -369,6 +369,7 @@ void os::init_system_properties_values()
+ }
+ Arguments::set_java_home(buf);
+ set_boot_path('/', ':');
++Arguments::append_sysclasspath("/usr/share/java/java-atk-wrapper.jar");
+   }
+ 
+   // Where to look for native libraries.
diff -Nru openjdk-11-11.0.3+4/debian/patches/jaw-optional.diff 
openjdk-11-11.0.3+4/debian/patches/jaw-optional.diff
--- openjdk-11-11.0.3+4/debian/patches/jaw-optional.diff1970-01-01 
01:00:00.0 +0100
+++ openjdk-11-11.0.3+4/debian/patches/jaw-optional.diff2019-03-31 
17:49:09.0 +0200
@@ -0,0 +1,20 @@
+Make failing to load the Java ATK wrapper non-fatal
+
+---
+ src/java.desktop/share/classes/java/awt/Toolkit.java |4 
+ 1 file changed, 4 insertions(+)
+
+--- a/src/java.desktop/share/classes/java/awt/Toolkit.java
 b/src/java.desktop/share/classes/java/awt/Toolkit.java
+@@ -610,7 +610,11 @@ public abstract class Toolkit {
+ }
+ });
+ if (!GraphicsEnvironment.isHeadless()) {
++  try {
+ loadAssistiveTechnologies();
++  } catch (java.awt.AWTError e) {
++// too bad
++  }
+ }
+ }
+ return toolkit;
diff -Nru openjdk-11-11.0.3+4/debian/patches/series 
openjdk-11-11.0.3+4/debian/patches/series
--- openjdk-11-11.0.3+4/debian/patches/series   2019-03-28 09:32:28.0 
+0100
+++ openjdk-11-11.0.3+4/debian/patches/series   2019-03-31 17:49:09.0 
+0200
@@ -38,3 +38,5 @@
 jdk-improve-gtk3-compatibility.patch
 keep-gtk2-as-default.patch
 8221083.diff
+jaw-classpath.diff
+jaw-optional.diff
diff -Nru openjdk-11-11.0.3+4/debian/rules openjdk-11-11.0.3+4/debian/rules
--- openjdk-11-11.0.3+4/debian/rules2019-03-28 20:44:54.0 +0100
+++ openjdk-11-11.0.3+4/debian/rules2019-03-31 17:49:09.0 +0200
@@ -1081,13 +1081,13 @@
 ifeq ($(with_bridge),atk)
 #  only add releases that are known to work with atk
 #  by default leave atk disabled
-#  ifneq (,$(filter $(distrel),))
-#  cp -p debian/accessibility-atk.properties.enabled \
+  ifneq (,$(filter $(distrel),buster))
+   cp -p debian/accessibility-atk.properties.enabled \
$(d)/$(basedir)/conf/accessibility.properties
-#  else
+  else
cp -p debian/accessibility-atk.properties.disabled \
$(d)/$(basedir)/conf/accessibility.properties
-#  endif
+  endif
 else
cp -p debian/accessibility.properties $(d)/$(basedir)/conf/
 endif
@@ -1427,23 +1427,26 @@
   endif
 endif
 
-ifeq (0,1)
-# FIXME: ext not longer supported
 ifeq ($(with_bridge),atk)
: # create links for the atk wrapper
+  ifeq (0,1)
+  # FIXME: ext no longer supported
echo "usr/share/java/java-atk-wrapper.jar 
$(basedir)/lib/ext/java-atk-wrapper.jar" \
>> $(d_jre).links
-   echo "usr/lib$(multiarch_dir)/jni/libatk-wrapper.so 
$(basedir)/lib/ext/libatk-wrapper.so" \
+  endif
+   echo "usr/lib$(multiarch_dir)/jni/libatk-wrapper.so 
$(basedir)/lib/libatk-wrapper.so" \
>> $(d_jre).links
 else ifeq ($(with_bridge),yes)
+ ifeq (0,1)
+# FIXME: ext no longer supported
: # create links for 

Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)

[Thorsten Glaser]

Hi Emmanuel,

> > When it's ready please let me review the update before uploading.
> 
> OK.

Here we are, now. I’m posting the entire diff, but with comments
in between. This is exactly what’s on git master right now. I’d
like to merge the fixes for #925928 and #925929 and upload once
you have reviewed this.

diff --git a/debian/libexec/tomcat-locate-java.sh 
b/debian/libexec/tomcat-locate-java.sh
old mode 100755
new mode 100644
index 341f9b15..b6dbb01e
--- a/debian/libexec/tomcat-locate-java.sh
+++ b/debian/libexec/tomcat-locate-java.sh
@@ -1,4 +1,3 @@
-#!/bin/sh
 #
 # Script looking for a Java runtime suitable for running Tomcat
 #

This script is only ever sourced, not executed, so it ought to not
have a shebang and not be executable. (As it merely sets a variable,
executing it makes no sense anyway.)

diff --git a/debian/libexec/tomcat-start.sh b/debian/libexec/tomcat-start.sh
index 31aaecf8..f22a3422 100755
--- a/debian/libexec/tomcat-start.sh
+++ b/debian/libexec/tomcat-start.sh
@@ -15,7 +15,7 @@ export JAVA_OPTS
 
 # Enable the Java security manager?
 SECURITY=""
-[ "$TOMCAT_SECURITY" = "yes" ] && SECURITY="-security"
+[ "$SECURITY_MANAGER" = "true" ] && SECURITY="-security"
 
 
 # Start Tomcat

This unbreaks using the SECURITY_MANAGER parameter, which
TOMCAT_SECURITY was renamed to (also yes/no → true/not true).
It’s an unrelated fix discovered in the meantime.

diff --git a/debian/README.Debian b/debian/README.Debian
index d11fb47b..c005bb0b 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -54,6 +54,13 @@ Getting started
   systemctl daemon-reload
   systemctl restart tomcat9
 
+⚠ This is supported only when Tomcat is started with the systemd unit.
+
+Using Tomcat with other init systems is supported, however that will
+negate the security hardening detailed above, make Tomcat not have
+its own temporary directory, not drop privileges/capabilities after
+start, and not be restarted on crashing. Use at your own risk.
+
   * To run more than one Tomcat instance on your server, install the package
 tomcat9-user and run the tomcat9-instance-create utility.
 You should remove the tomcat9 package if you don't want Tomcat to
diff --git a/debian/logging.properties b/debian/logging.properties
index 37fa30d1..69ac42f0 100644
--- a/debian/logging.properties
+++ b/debian/logging.properties
@@ -33,7 +33,9 @@ handlers = 1catalina.org.apache.juli.AsyncFileHandler, 
2localhost.org.apache.jul
 2localhost.org.apache.juli.AsyncFileHandler.maxDays = 90
 
 java.util.logging.ConsoleHandler.level = FINE
+# use one of these depending on whether you use systemd or not, or roll your 
own
 java.util.logging.ConsoleHandler.formatter = org.apache.juli.SystemdFormatter
+#java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
 
 
 

These update some comments for non-systemd users and warn them off.

diff --git a/debian/control b/debian/control
index 41ab0f8f..a1652a93 100644
--- a/debian/control
+++ b/debian/control
@@ -47,7 +47,7 @@ Package: tomcat9
 Architecture: all
 Depends:
  lsb-base (>= 3.0-6),
- systemd (>= 215),
+ systemd (>= 215) | adduser,
  tomcat9-common (>= ${source:Version}),
  ucf,
  ${misc:Depends}
diff --git a/debian/tomcat9.lintian-overrides b/debian/tomcat9.lintian-overrides
new file mode 100644
index ..9b0d6593
--- /dev/null
+++ b/debian/tomcat9.lintian-overrides
@@ -0,0 +1,2 @@
+# handled in dependencies and maintainer script as alternative
+tomcat9: maintainer-script-needs-depends-on-adduser postinst
diff --git a/debian/tomcat9.postinst b/debian/tomcat9.postinst
index 55fb55c2..7cd34950 100644
--- a/debian/tomcat9.postinst
+++ b/debian/tomcat9.postinst
@@ -5,6 +5,7 @@
 
 set -e
 
+# Note these are no longer configurable (as of commit 
243d00dc688ea47f4c7cde570ccaaa70efe269bf)
 TOMCAT_USER="tomcat"
 TOMCAT_GROUP="tomcat"
 
@@ -12,8 +13,18 @@ CONFFILES="tomcat-users.xml web.xml server.xml 
logging.properties context.xml ca
 
 case "$1" in
 configure)
-   # Create the tomcat user as defined in /usr/lib/sysusers.d/tomcat9.conf
-   systemd-sysusers
+   if which systemd-sysusers >/dev/null; then
+   # Create the tomcat user as defined in 
/usr/lib/sysusers.d/tomcat9.conf
+   systemd-sysusers
+   elif id tomcat >/dev/null 2>&1; then
+   : The tomcat user already exists
+   else
+   # Create the tomcat user without systemd
+   adduser --system --home /var/lib/tomcat9 \
+   --shell /usr/sbin/nologin --no-create-home \
+   --group --disabled-password --disabled-login \
+   --gecos 'Apache Tomcat' tomcat
+   fi
 
# Install the configuration files
for conffile in $CONFFILES;

This restores the ability to create the tomcat user without systemd.

diff --git a/debian/libexec/sysv-getjre.sh b/debian/libexec/sysv-getjre.sh
new