Bug#923715: [Ceph-maintainers] Bug#923715: This doesn't make the package unusable

[Alfredo Deza]

On Wed, Apr 3, 2019 at 11:15 AM Thomas Goirand  wrote:
>
> On 4/2/19 11:23 PM, Alfredo Deza wrote:
> > On Tue, Apr 2, 2019 at 4:48 PM Thomas Goirand  wrote:
> >>
> >> Hi,
> >>
> >> Using ceph-volume is absolutely *NOT* mandatory, this is only a way to
> >> setup your ceph cluster, but that's really not the only one.
> >>
> >> I've been using ceph-osd without it, and the ceph-osd@.service is really
> >> enough, provided that you know how to set it up properly.
> >>
> >> Therefore, this bug is *NOT* of severity grave, because the definition is:
> >>
> >> "makes the package in question unusable by most or all users,
> >> or causes data loss, or introduces a security hole allowing
> >> access to the accounts of users who use the package."
> >>
> >> There's no security hole or data loss, it is just maybe a little harder
> >> to use ceph-osd.
> >
> > I would argue that an unusable ceph-volume would make Ceph unusable
> > for most users.
>
> My understanding is that ceph-volume is a conveniency tool only, just
> like ceph-deploy (which I gave up on, btw...). It isn't at all
> mandatory. BTW, I don't really understand why one would need a
> ceph-volume@.service at all, since we already have ceph-osd@.service.
> Can you explain? isn't this redundant?

The ceph-volume unit will map to each OSD that has been created. Upon
system startup, each unit will try to discover the devices
associated with an OSD, mount them (if needed, for example in
Filestore), and decrypt them if required. The associated ceph-osd unit
will then be started at the end of the process.

This is part of the activation process that is documented in detail
here: 
http://docs.ceph.com/docs/master/ceph-volume/lvm/activate/#ceph-volume-lvm-activate

>
> > Running ceph-osd@.service is not enough, since one of the
> > responsibilities of ceph-volume is to ensure that
> > everything is in place for the OSD to start when the system boots,
> > with all the complexity that may involve: encrypted,
> > bluestore or filestore, block/block.db/block.wal, journals, etc...
>
> I've done all of this using my own script, and it isn't hard. FYI, this
> is included in openstack-cluster-installer, also in Debian Sid/Buster.
> It's a "push button" install of Ceph (and OpenStack if you need that
> too), if you're searching for something simple.
>
> If you want to set things up by hand, you may reuse this script too (and
> adapt it to your needs, of course, as this tightly integrates with OCI):
>
> https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer/blob/debian/stein/bin/oci-make-osd
>
> Comments on it, or even better, improvements, would be welcome.
>
> > You may be able to run an OSD manually, but that doesn't mean it is
> > the way we would recommend for a stable system.
>
> I don't see how setting-up things with another tool, or even by hand,
> makes Ceph OSD unstable.

I'm re-using the description for "grave":

 "...makes the package in question unusable by most or all users"

In this case, most users will not be able to deploy a Ceph cluster
with an unusable ceph-volume.

All the Ceph automation is done interacting with ceph-volume, and the
most used deployment tooling uses ceph-volume (vs. a script):

SeaSalt, ceph-deploy, ceph-ansible, and most recently Rook.


>
> >> It would still be desirable to get this fixed ASAP though, and probably
> >> deserving a fix before Buster is out.
>
> As I wrote above, it is useless to discuss, just send a patch, and we'll
> go from there.
>
> Cheers,
>
> Thomas Goirand (zigo)

Bug#926309: gdm3: gdm-x-session calls Xsession with broken arguments

[Matijs van Zuijlen]

On 03/04/2019 12:14, Simon McVittie wrote:
> On Wed, 03 Apr 2019 at 11:12:49 +0200, Matijs van Zuijlen wrote:
>> Version: 3.32.0-1
>>
>> Since a couple of weeks, I guess
> 
> This is presumably a regression in the gdm3 version in experimental,
> or a regression in some related GNOME 3.32 component in experimental
> (maybe gnome-session or similar). buster/sid are hopefully unaffected?

Oh, I actually only installed the version from experimental because
reportbug told me to try it. The version in unstable has the same
problem, I'm afraid.

Kind regards,
Matijs



signature.asc
Description: OpenPGP digital signature

Bug#926328: network-manager-gnome: nm-applet crashes with a coredump when try to create a new WiFi network

[Jiang Jun]

Package: network-manager-gnome
Version: 1.8.20-1
Severity: normal

Dear Maintainer,

I am experiencing a crash every time I try to create a hot-spot WiFi using nm-
applet menu. The steps were:

1. Click nm-applet(I am using Xfce4 and xfce-panel, BTW), in the drop down
menu, click Creat New WiFi Network...
2. In the pop up window, fill in Network Name and Key.
3. In the WiFi security drop down menu, select None or WEP 128bit Passphrase or
WEP 40/128, doesn't matter, the result will be the same (a crash).
4. Click Create. And nm-applet will disappear from the panel Notification Area.

In journalctl you'll see: https://cfp.vim-cn.com/cbfwN


And there will be a new coredump in coredumpctl list like:

Wed 2019-04-03 23:06:44 CST   19318  1000  1000   6 present   /usr/bin/nm-
applet

coredumpctl info shows this: https://cfp.vim-cn.com/cbfwP



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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.12-1
ii  dbus-x11 [dbus-session-bus]   1.12.12-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.1-2
ii  libatk1.0-0   2.30.0-2
ii  libayatana-appindicator3-10.5.3-4
ii  libc6 2.28-8
ii  libcairo2 1.16.0-4
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-1
ii  libgtk-3-03.24.5-1
ii  libjansson4   2.12-1
ii  libmm-glib0   1.10.0-1
ii  libnm01.14.6-2
ii  libnma0   1.8.20-1
ii  libnotify40.7.7-4
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libsecret-1-0 0.18.7-1
ii  libselinux1   2.8-1+b1
ii  network-manager   1.14.6-2
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring3.28.2-5
ii  iso-codes4.2-1
ii  mobile-broadband-provider-info   20170903-1
ii  notification-daemon  3.20.0-4
ii  xfce4-notifyd [notification-daemon]  0.4.3-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#926329: nut-server: upsd dies if upsd.conf contains LISTEN line with nonexistant ip

[Jon Bendtsen]

Package: nut-server
Version: 2.7.4-5
Severity: normal
Tags: upstream newcomer

Dear Maintainer,

After reconfiguring 1 network interface to a new range, but forgetting to 
remove the last line, then one with 192.168.123.9 from /etc/nut/upsd.conf

LISTEN 127.0.0.1 3493
LISTEN 192.168.119.253 3493
LISTEN 192.168.123.9 3493

The nut daemon refused to run after it at a later date was restarted. Syslog 
just reported:

Apr  2 20:54:11 dkfitlet upsd[16941]: Network UPS Tools upsd 2.7.4
Apr  2 20:54:11 dkfitlet upsd[16941]: not listening on 192.168.123.9 port 3493
Apr  2 20:54:11 dkfitlet upsd[16941]: listening on 192.168.119.253 port 3493
Apr  2 20:54:11 dkfitlet upsd[16941]: listening on 127.0.0.1 port 3493
Apr  2 20:54:11 dkfitlet upsd[16941]: no listening interface available

Notice the last line message: "no listening interface available" which is not 
true, as 2 out of 3 configured LISTEN addresses was available. Notice also that 
syslog does not say that upsd exitted.

After removing the bad line from upsd.conf "LISTEN 192.168.123.9 3493" 
everything started working fine.

I would expect that upsd listens to the addresses it can find and not just exit.


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

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

Versions of packages nut-server depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u4
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1.1+deb9u1
ii  libupsclient42.7.4-5
ii  libusb-0.1-4 2:0.1.12-30
ii  libwrap0 7.6.q-26
ii  lsb-base 9.20161125
ii  nut-client   2.7.4-5
ii  udev 232-25+deb9u9

nut-server recommends no packages.

Versions of packages nut-server suggests:
ii  nut-cgi   2.7.4-5
ii  nut-ipmi  2.7.4-5
ii  nut-snmp  2.7.4-5
ii  nut-xml   2.7.4-5

-- Configuration Files:
/etc/nut/ups.conf [Errno 13] Permission denied: '/etc/nut/ups.conf'
/etc/nut/upsd.conf [Errno 13] Permission denied: '/etc/nut/upsd.conf'
/etc/nut/upsd.users [Errno 13] Permission denied: '/etc/nut/upsd.users'

-- no debconf information

Bug#923715: [Ceph-maintainers] Bug#923715: This doesn't make the package unusable

[Thomas Goirand]

On 4/2/19 11:23 PM, Alfredo Deza wrote:
> On Tue, Apr 2, 2019 at 4:48 PM Thomas Goirand  wrote:
>>
>> Hi,
>>
>> Using ceph-volume is absolutely *NOT* mandatory, this is only a way to
>> setup your ceph cluster, but that's really not the only one.
>>
>> I've been using ceph-osd without it, and the ceph-osd@.service is really
>> enough, provided that you know how to set it up properly.
>>
>> Therefore, this bug is *NOT* of severity grave, because the definition is:
>>
>> "makes the package in question unusable by most or all users,
>> or causes data loss, or introduces a security hole allowing
>> access to the accounts of users who use the package."
>>
>> There's no security hole or data loss, it is just maybe a little harder
>> to use ceph-osd.
> 
> I would argue that an unusable ceph-volume would make Ceph unusable
> for most users.

My understanding is that ceph-volume is a conveniency tool only, just
like ceph-deploy (which I gave up on, btw...). It isn't at all
mandatory. BTW, I don't really understand why one would need a
ceph-volume@.service at all, since we already have ceph-osd@.service.
Can you explain? isn't this redundant?

> Running ceph-osd@.service is not enough, since one of the
> responsibilities of ceph-volume is to ensure that
> everything is in place for the OSD to start when the system boots,
> with all the complexity that may involve: encrypted,
> bluestore or filestore, block/block.db/block.wal, journals, etc...

I've done all of this using my own script, and it isn't hard. FYI, this
is included in openstack-cluster-installer, also in Debian Sid/Buster.
It's a "push button" install of Ceph (and OpenStack if you need that
too), if you're searching for something simple.

If you want to set things up by hand, you may reuse this script too (and
adapt it to your needs, of course, as this tightly integrates with OCI):

https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer/blob/debian/stein/bin/oci-make-osd

Comments on it, or even better, improvements, would be welcome.

> You may be able to run an OSD manually, but that doesn't mean it is
> the way we would recommend for a stable system.

I don't see how setting-up things with another tool, or even by hand,
makes Ceph OSD unstable.

>> It would still be desirable to get this fixed ASAP though, and probably
>> deserving a fix before Buster is out.

As I wrote above, it is useless to discuss, just send a patch, and we'll
go from there.

Cheers,

Thomas Goirand (zigo)

Bug#926312: [debian-mysql] Bug#926312: MariaDB couldn't start after fresh install

[Otto Kekäläinen]

Hello!

Thanks for reporting.

The file /etc/mysql/debian-start is shipped as part of the
mariadb-server-10.1 package:
https://packages.debian.org/stretch/amd64/mariadb-server-10.1/filelist

This has been the case for about 4 years and there has not been any
recent changes to this:
https://salsa.debian.org/mariadb-team/mariadb-10.1/blame/stretch/debian/mariadb-server-10.1.install

I would be surprised if a fresh install, the most typical use case,
would be broken.

Are you sure the install is really fresh?

I have no idea how this could have happened. I'd appreciate if you dig
deeper. There is an upcoming stable update to MariaDB so if there is a
problem, it would get fixed and shipped soon.

Bug#926326: elpa-elpy: configuration issues

[Faheem Mitha]

Package: elpa-elpy
Version: 1.28.0-1
Severity: normal

Dear Maintainer,

I've been struggling with getting elpy to work on Debian stable.

For right now, some comments and suggestions about README.Debian.

1) There's a typo in your code:

(setq python-shell-interpreter "python"
  python-shell-interpreter-args "-i")
  elpy-rpc-python-command "python")

It should be:

(setq python-shell-interpreter "python"
  python-shell-interpreter-args "-i"
  elpy-rpc-python-command "python")

2) You should mention that elpy isn't loaded by default, and indicate
how to load it. Historically, Debian packages autoload modes once
installed, and personally I find that more convenient. But I
understand if you don't load it to preserce compatibility with
upstream EPLA.

The elpy manual mentions in
https://elpy.readthedocs.io/en/latest/introduction.html that elpy
should be enabled with

(package-initialize)
(elpy-enable)

Just the second line works for me here. I'm not sure what the first
part does. Some sort of global enable, apparently.

3) I suggest mentioning the upstream manual in README.Debian. Namely,
https://elpy.readthedocs.io/en/latest/

4) And if I were writing the README.Debian, I'd also mention that C-c
C-c runs the buffer, and that you need C-c C-z to open up a Python
interpreter buffer. This would help people to get going quickly,
instead of flailing around trying to figure out what to do.

These commands are both in
https://elpy.readthedocs.io/en/latest/ide.html

C-c C-y r (elpy-shell-send-region-or-buffer)
[...]
Also bound to C-c C-c.

and

C-c C-z (elpy-shell-switch-to-shell)

There are a ton of commands in that manual, and it's really
confusing. But you really only need a couple to get going. That manual
really needs a quickstart page.

Do you happen to know if it is possible to configure emacs to open a
Python buffer in elpy mode by default and skip the C-c C-z?

5) I'm also running into the error message mentioned in
https://github.com/jorgenschaefer/elpy/issues/1521

Should I report it here? Or just upstream? I added a comment to that
thread.

6) Your bug report template should include the output of
elpy-config. I've included mine at the bottom. I'm not sure what is going on 
with

Elpy..: Not found (Python), 1.28.0 (Emacs Lisp)

though. What's the difference between those two cases?

7) I suggest adding Python 2 packages to the package
dependencies/recommends/suggests too. Like for Jedi. People are still
using Python 2, and are likely to be doing so for awhile.

Regards, Faheem Mitha

-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages elpa-elpy depends on:
ii  elpa-company0.9.9-2
ii  elpa-find-file-in-project   5.7.3-1
ii  elpa-highlight-indentation  0.7.0-1
ii  elpa-pyvenv 1.20-1
ii  elpa-s  1.12.0-2
ii  elpa-yasnippet  0.11.0-2
ii  emacsen-common  2.0.8
ii  flake8  3.2.1-1
ii  python3 3.5.3-1
ii  python3-flake8  3.2.1-1

Versions of packages elpa-elpy recommends:
ii  emacs 46.1
ii  python3-jedi  0.10.0~git1+f05c071-1

Versions of packages elpa-elpy suggests:
pn  black
ii  python3-autopep8 1.4.3-1
ii  python3-jupyter-console  5.0.0-1
ii  python3-pip  9.0.1-2
pn  yapf3

-- debconf-show failed


Output of M-x elpy-config

Elpy Configuration

Virtualenv: None
RPC Python: 2.7.13 (/usr/bin/python)
Interactive Python: python (/usr/bin/python)
Emacs.: 25.1.1
Elpy..: Not found (Python), 1.28.0 (Emacs Lisp)
Jedi..: 0.12.0
Rope..: 0.10.3
Autopep8..: 0.9.1
Yapf..: Not found
Black.: Not found
Syntax checker: flake8 (/usr/bin/flake8)

You have not activated a virtual env. While Elpy supports this, it is
often a good idea to work inside a virtual env. You can use M-x
pyvenv-activate or M-x pyvenv-workon to activate a virtual env.

The directory ~/.local/bin/ is not in your PATH. As there is no active
virtualenv, installing Python packages locally will place executables
in that directory, so Emacs won't find them. If you are missing some
commands, do add this directory to your PATH -- and then do
`elpy-rpc-restart'.

The Python interpreter could not find the elpy module. Make sure the
module is installed.

[run] easy_install --user elpy

Bug#926327: qgit: Crash on some malformed git repositories

[Boyuan Yang]

Package: qgit
Version: 2.8-1
Severity: normal
X-Debbugs-CC: w...@debian.org

Dear qgit maintainer,

Months ago I submitted https://bugs.debian.org/894416 and later I realized
that the crash of qgit should be caused by some certain git repositories. As a
result, I prepared a broken git repository that can crash the qgit program.

Git repo download link (actually it's the www.debian.org website repo):

https://drive.google.com/open?id=1yMVLNQ3t6JP4n3Nv_Cnsp7mPrLhT3rQ1

How to reproduce:

1. extract the broken git repo from .tar.xz tarball
2. run "qgit" within the working directory
3. select "whole history" in range selection
4. the program will crash.

hosiet@gaolab004 [~/src/debian/webmaster-team/webwml] [master]
-> % qgit
ASSERT in Cache::load, corrupted SHA after �yyy�
ERROR: unable to load file names cache
[1]17309 segmentation fault  qgit

Could you please take a look? Thanks!

--
Regards,
Boyuan Yang


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

Bug#926325: raspi3-firmware: console tty0 is not the main console

[Fabian Pietsch]

Package: raspi3-firmware
Version: 1.20190215-1
Severity: normal

Dear Maintainer,

due to the order of the console=... arguments on the kernel command
line, given to the firmware in /boot/firmware/cmdline.txt, constructed
by your hook script /etc/kernel/postinst.d/z50-raspi3-firmware,
the serial console is the main system console. (The last argument wins.)

This means that, e.g., systemd boot messages won't appear on the
HDMI-connected display. This also means that systemd units with
StandardOutput=journal+console won't be able to give live comment
on what they are doing / waiting for at boot to the person sitting in
front of the monitor.

Due to the construction of the Raspberry Pi 3 board and presumed usual
use I consider it easier and more likely to connect a monitor (or TV)
via an HDMI cable, than to first wire something up to even have a serial
port at all in the first place.

If still the serial console should be the default main console, and the
HDMI-connected display only an additional console, please make this
configurable in, e.g., /etc/default/raspi3-firmware. (It could be nice
to be able to set additional kernel cmdline arguments or even override
the complete cmdline from there, btw.)

For the time being, to avoid editing (and later merging on upgrade)
a 143 lines script conffile /etc/kernel/postinst.d/z50-raspi3-firmware
(see above), I place this little sed script which exchanges the position
of two console=... arguments if the first (not the final) is tty0:


/etc/kernel/postinst.d/z51-raspi3-fixup and symlinked from
/etc/initramfs/post-update.d/z51-raspi3-fixup:

#!/bin/bash
# (Note: This will not suffice with more than two console=...)
exec -- sed -e 's/\(console=tty0 \)\(console=[^ ]* \)/\2\1/' -i 
/boot/firmware/cmdline.txt


This changes /boot/firmware/cmdline.txt from, e.g. (with raised CMA
in /etc/default/raspi3-firmware), this:

| console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw elevator=deadline 
fsck.repair=yes net.ifnames=0 cma=128M rootwait

..to this:

| console=ttyS1,115200 console=tty0 root=/dev/mmcblk0p2 rw elevator=deadline 
fsck.repair=yes net.ifnames=0 cma=128M rootwait

That is, tty0 boots as the main console, receiving, e.g.,
systemd boot output.

The result can be checked by /proc/consoles:

| tty0 -WU (EC p  )4:7
| ttyS1-W- (E  p a)4:65

Look for flag "C = it is preferred console", according to
/usr/share/doc/linux-doc/Documentation/filesystems/proc.txt.gz


Regards, Fabian


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

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

Versions of packages raspi3-firmware depends on:
ii  dosfstools  4.1-2

raspi3-firmware recommends no packages.

raspi3-firmware suggests no packages.

-- Configuration Files:
/etc/default/raspi3-firmware changed:
CMA=128M


-- no debconf information

Bug#924888: why bsd.license?

[Laura Arjona Reina]

El 3 de abril de 2019 14:34:16 CEST, MJ Ray  escribió:
>On Mon, 1 Apr 2019 12:26:13 +0200
>Laura Arjona Reina  wrote:
>
>> BSD, and
>> 
>> I have checked that the content of the bsd.license file matches the
>> BSD-3-Clause license at opensource.org, so I've updated the links to
>> 
>> https://opensource.org/licenses/BSD-3-Clause
>> 
>> and removed the file.
>
>Could you add a redirect instead of breaking links from other
>documentation, please?  In line with Cool URIs Don't Change,
>https://www.w3.org/Provider/Style/URI.html
>
>https://manpages.debian.org/testing/pal/vcard2pal.1.en.html could
>probably be fixed by us, as could the links from our wiki, but it looks
>like there are also links to it from code on github.

I'll try to submit today a patch for the Apache configuration with redirects.

Kind regards
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Bug#923484: Bug#926161: sbuild fails to build packages for wheezy ELTS

[Johannes Schauer]

Hi,

Quoting Mike Gabriel (2019-04-02 10:51:06)
> On  Di 02 Apr 2019 09:07:33 CEST, Emilio Pozuelo Monfort wrote:
> > This looks alright. Please also include the patch from #923484  (hopefully
> > after an ack from the maintainers).
> Please do the upload with #923484 and #926161 fixed to unstable and  send me
> the .debdiff off-list / off-bts. I will then file the unblock  bug for it.
> 
> It is ok, to upload first, then request unblocking for the two bugs named.

wonderful! The upload fixing both bugs to unstable did just happen.

https://tracker.debian.org/news/1037233/accepted-sbuild-0781-2-source-into-unstable/

Unblock request is here:

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

Thanks to all involved for resolving this situation so smoothly! :)

cheers, josch


signature.asc
Description: signature

Bug#926324: unblock: sbuild/0.78.1-2

[Johannes 'josch' Schauer]

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

Please unblock package sbuild as discussed in #926161. Debdiff attached.

unblock sbuild/0.78.1-2
diff -Nru sbuild-0.78.1/debian/changelog sbuild-0.78.1/debian/changelog
--- sbuild-0.78.1/debian/changelog  2019-02-09 07:25:07.0 +0100
+++ sbuild-0.78.1/debian/changelog  2019-04-03 14:08:12.0 +0200
@@ -1,3 +1,16 @@
+sbuild (0.78.1-2) unstable; urgency=medium
+
+  [ Mike Gabriel ]
+  * debian/patches: Add support-gzip-in-wheezy.patch. The gzip command
+in Debian wheezy lacks support for the --keep cmdline option, so
+avoid using it. (closes: #926161)
+
+  [ Aurelien Jarno ]
+  * debian/patches: Add fix-disk-space-directory-check.patch. The right
+directory has to be checked inside the chroot. (closes: #923484)
+
+ -- Johannes 'josch' Schauer   Wed, 03 Apr 2019 14:08:12 
+0200
+
 sbuild (0.78.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru sbuild-0.78.1/debian/patches/fix-disk-space-directory-check.patch 
sbuild-0.78.1/debian/patches/fix-disk-space-directory-check.patch
--- sbuild-0.78.1/debian/patches/fix-disk-space-directory-check.patch   
1970-01-01 01:00:00.0 +0100
+++ sbuild-0.78.1/debian/patches/fix-disk-space-directory-check.patch   
2019-04-03 13:59:20.0 +0200
@@ -0,0 +1,25 @@
+Description: test $pkgbuilddir inside the chroot instead of $dscdir outside of 
it
+Author: Aurelien Jarno 
+
+--- a/lib/Sbuild/Build.pm
 b/lib/Sbuild/Build.pm
+@@ -2776,16 +2776,14 @@ sub check_space {
+ my $sum = 0;
+ 
+ my $dscdir = $self->get('DSC Dir');
++return -1 unless (defined $dscdir);
++
+ my $build_dir = $self->get('Build Dir');
+ my $pkgbuilddir = "$build_dir/$dscdir";
+ 
+ # if the source package was not yet unpacked, we will not attempt to 
compute
+ # the required space.
+-unless( defined $dscdir && -d $dscdir)
+-{
+-  return -1;
+-}
+-
++return -1 unless ($self->get('Session')->test_directory($pkgbuilddir));
+ 
+ my ($space, $spacenum);
+ 
diff -Nru sbuild-0.78.1/debian/patches/series 
sbuild-0.78.1/debian/patches/series
--- sbuild-0.78.1/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ sbuild-0.78.1/debian/patches/series 2019-04-03 13:59:20.0 +0200
@@ -0,0 +1,2 @@
+fix-disk-space-directory-check.patch
+support-gzip-in-wheezy.patch
diff -Nru sbuild-0.78.1/debian/patches/support-gzip-in-wheezy.patch 
sbuild-0.78.1/debian/patches/support-gzip-in-wheezy.patch
--- sbuild-0.78.1/debian/patches/support-gzip-in-wheezy.patch   1970-01-01 
01:00:00.0 +0100
+++ sbuild-0.78.1/debian/patches/support-gzip-in-wheezy.patch   2019-04-03 
13:58:53.0 +0200
@@ -0,0 +1,16 @@
+Description: gzip in wheezy lacks --keep option, so avoid using it.
+Author: Mike Gabriel 
+
+--- a/lib/Sbuild/ResolverBase.pm
 b/lib/Sbuild/ResolverBase.pm
+@@ -1445,8 +1445,8 @@
+ closedir($dh);
+ }
+ 
+-system('gzip', '--keep', '--force', 'Packages') == 0 or die "gzip failed: 
$?\n";
+-system('gzip', '--keep', '--force', 'Sources') == 0 or die "gzip failed: 
$?\n";
++system('gzip -c --force Packages > Packages.gz') == 0 or die "gzip failed: 
$?\n";
++system('gzip -c --force Sources  > Sources.gz' ) == 0 or die "gzip failed: 
$?\n";
+ 
+ my $packages_md5 = hash_file('Packages', 'md5sum');
+ my $sources_md5 = hash_file('Sources', 'md5sum');

Bug#925134: grub-efi-amd64-signed: doesn't mount cryptodisk

[Paolo Miotto]

I noticed that I haven't told that I'm on buster (I took it for granted based 
on the package version).


On 2019-03-30 I upgraded my system and I suffer again of this bug: without 
explicit "insmod luks" in /boot/efi/EFI/debian/grub.cfg the boot stops in a 
grub shell.


This packages where upgraded by the update (from /var/log/apt/history.log, 
purged from apps upgrades):

Start-Date: 2019-03-30  20:55:36
Commandline: apt full-upgrade
Requested-By:
Upgrade: grub-efi:amd64 (2.02+dfsg1-13, 2.02+dfsg1-16), grub-common:amd64 
(2.02+dfsg1-13, 2.02+dfsg1-16), grub2-common:amd64 (2.02+dfsg1-13, 
2.02+dfsg1-16), grub-efi-amd64-bin:amd64 (2.02+dfsg1-13, 2.02+dfsg1-16),  
grub-efi-amd64:amd64 (2.02+dfsg1-13, 2.02+dfsg1-16), 
grub-efi-amd64-signed:amd64 (1+2.02+dfsg1+13, 1+2.02+dfsg1+16)
End-Date: 2019-03-30  20:55:52

Start-Date: 2019-03-30  20:56:05
Commandline: apt autoremove --purge
Requested-By:
Purge: efibootmgr:amd64 (15-1)
End-Date: 2019-03-30  20:56:05


I've tried to reinstall efibootmgr but nothing changes.


I can do some tests, but I need directions.


--

Mandi.

Paolo

Bug#926134: antlr4: Please package Python 3 runtime

[Benjamin Barenblat]

Control: tags 926134 wontfix

On Wednesday, April  3, 2019, at  7:30 AM EDT, Emmanuel Bourg wrote:
> The Java Team would prefer maintaining only the Java part of ANTLR 4.
> Ideally the python part should be maintained separately […].

Sounds fine – I’ll keep an eye on https://bugs.debian.org/897129.

Bug#878170: Problem elsewhere, you can close it

[Michel Dänzer]

On 2019-04-03 2:26 p.m., Anton Ivanov wrote:
> I found the underlying root cause and the fix by chance when trawling
> the web for something else.
> 
> The issue is compositing in the window manager.
> 
> If compositing is enabled the video WILL tear. If compositing is
> disabled the videos display correctly.
> 
> Definitely the case for xfce4.

It's an xfwm4 (configuration) issue then.


-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#913657: (no subject)

[Santiago Ruano Rincón]

Control: notfound -1 3.3-1
Control: tags -1 + wontfix

El 02/04/19 a las 17:39, BOUTELIER Sébastien escribió:
> Same bug here. 
> 
> With grep on any squid log file (~ 350M), there is a huge difference. 
> 
> I compiled grep 2.20 and 3.3 for stretch using pbuilder and put grep
> binaries on a server: 
> pbuilder build grep_3.3-1.dsc
> pbuilder build grep_2.20-4.1.dsc
> intall deb, scp grep binaries to server and rename it.
> 
> All binaries are using the same libs.
> 
> root@cachessl:/var/log/squid# time /var/tmp/grep33 10.21.73.68
> access.log | wc -l 
> 1139
> 
> real0m0,681s
> user0m0,556s
> sys 0m0,112s
> root@cachessl:/var/log/squid# time /var/tmp/grep220 10.21.73.68
> access.log | wc -l 
> 1139
> 
> real0m1,920s
> user0m1,744s
> sys 0m0,168s
> root@cachessl:/var/log/squid# time /var/tmp/grep227 10.21.73.68
> access.log | wc -l 
> 1139
> 
> real0m30,639s
> user0m30,480s
> sys 0m0,144s
> 
> Same result with -a option.
> 
> -- 
> BOUTELIER Sébastien
> Tel: 04 94 14 29 47
> 

Thanks for the info. Unfortunately, I find it difficult to solve this
issue in stretch. In general, changes in {old,}stable are restricted to
solve bugs whose severity is critical, and I don't think it is the case
here. It would be possible to upload to stretch-backport the same
version found in buster though.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#926323: should recommend xprintidle

[Sébastien Villemot]

Package: safeeyes
Version: 2.0.6-1
Severity: normal

Dear Maintainer,

safeeyes should Recommend (or at least Suggest) xprintidle, which is needed for
detecting when the system is idle (and therefore postponing the break).

Cheers,

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

Bug#926322: libssl1.1: datovka app is crashing after upgrade to libssl 1.1.1b

[Štěpán Liška]

Package: libssl1.1
Version: 1.1.1b
Severity: important

Dear Maintainer,

Bug in openssl version 1.1.1b is the case of crashing application datovka.
After the discussion on gitlab issue for datovka package it has been idetified
that the bug is somewhere inside the openssl library and it has been introduced
in version 1.1.1b.

Please take a look on the discussion here:
https://gitlab.labs.nic.cz/datovka/datovka/issues/410

and here:
https://github.com/openssl/openssl/issues/8375

debug output from datovka just before crash:
==
debug: Starting download owner info task in thread '0x7f42599ef700'
debug: Download owner info task finished in thread '0x7f42599ef700'
debug: Starting download user info task in thread '0x7f42599ef700'
debug: Download user info task finished in thread '0x7f42599ef700'
debug: Starting download password info task in thread '0x7f42599ef700'
debug: Download password info task finished in thread '0x7f42599ef700'
debug: Starting download message task in thread '0x7f42599ef700'
debug: Trying to download complete message '658202054'
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = datovka path = /home/stepan/bin pid = 26230
KCrash: Arguments: /home/stepan/bin/datovka -D
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from
kdeinit
==



Please, try to resolve this bug as soon as possible, Datovka is very important
app for communication with government in Czechia, we use it for backuping the
messages with government and the messages are removed from servers in 90 days
period. Without this application it is quite time consuming manual work to
backup messages.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (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_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=cs:en_US (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#878170: Problem elsewhere, you can close it

[Anton Ivanov]

I found the underlying root cause and the fix by chance when trawling 
the web for something else.


The issue is compositing in the window manager.

If compositing is enabled the video WILL tear. If compositing is 
disabled the videos display correctly.


Definitely the case for xfce4.

--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

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

[Ben Hutchings]

On Wed, 2019-04-03 at 10:14 +0800, 積丹尼 Dan Jacobson wrote:
> So the question becomes why does that installer ISO know how to properly deal
> with the
> 
> BH> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
> [AMD/ATI] Carrizo [1002:9874] (rev e6)
> BH>   Subsystem: ASUSTeK Computer Inc. Device [1043:8719]
> 
> giving nice splash screens, a snappy graphical install interface, crisp
> non-graphical rescue shells etc. ... but then the system that it
> installs oddly cannot deal with that hardware anymore? (Black screen.)

The installer normally uses a dumb framebuffer driver (probably efifb
on this system) that is built into the kernel.  This is too low-
performance for a proper desktop.

Ben.

> Note the whole experiment was done offline as to reduce outside
> interference in isolating the problem.
-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.




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

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

[Alexander Larsson]

On Tue, Apr 2, 2019 at 2:35 PM Akira TAGOH  wrote:
>
> Thanks for testing, Alex.

Doing some more testing, and I think I have found an issue.

On the host i regenerate caches with your branch, getting FC_DEBUG=16
output (among other output):

  cache: /6ba42aef58711b5caaf10d690066-le64.cache-7 (dir:
/usr/share/fonts/cantarell, salt: (null))
  cache: /6ba42aef58711b5caaf10d690066-le64.cache-7 (dir:
/usr/share/fonts/cantarell, salt: (null))
  charsets 5 -> 1 leaves 75 -> 15
  cache: /6ba42aef58711b5caaf10d690066-le64.cache-7 (dir:
/usr/share/fonts/cantarell, salt: (null))

In the flatpak-generated config in the sandbox have:
/run/host/fonts
/run/host/fonts

Then, running fc-list in the sandbox prints:

  cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir:
/run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell),
salt: (null))
  cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir:
/run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell),
salt: (null))
  charsets 5 -> 1 leaves 75 -> 15
  cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir:
/run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell),
salt: (null))
  FcDirCacheWriteDir dir "/run/host/fonts/cantarell" file
"/home/alex/.var/app/org.gnome.eog/cache/fontconfig//85bba0c73358da0b93a259c9d2b16b14-le64.cache-7"

Note how these get different checksums, meaning that the host cache is
not used. I think this is due to the double-slash in "mapped to
/usr/share/fonts//cantarell".

Bug#925334: vc4: CMA fills up and screen not updated anymore on raspi3

[Fabian Pietsch]

Hi,


* Fabian Pietsch (Wed, 03 Apr 2019 12:30:01 +0200):
> As suggested, I tested more compact cmdline.txt, though:
> 
> | root=/dev/mmcblk0p2
> 
> | console=tty0 root=/dev/mmcblk0p2
> 
> | console=tty0 root=/dev/mmcblk0p2 cma=128M
> 
> With the first two, cma defaulted to 64M and already the lightdm login
> screen stops updating after a few seconds to minutes. With the 3rd,
> the bug initially didn't happen so I used X a bit, then logged out and
> let the system fall idle; the bug then seems to have happened
> 9868 seconds after boot (according to dmesg --follow).

Another round (system mostly idle except for manually renaming enx[...]
to eth0 after boot and restarting wicd, which came with lxde meta-package
to manage the networking, to get a correct system time via NTP)  ->
3960 seconds after boot (in dmesg). That seems to suggest to me that
the cmdline.txt built by raspi3-firmware was not the issue, here.
Still don't know whether it's possible or sensible to disable the
"weird" initial cmdline passed by the firmware, though.

In any case, the tile binning error ...

| kernel: vc4_v3d 3fc0.v3d: Failed to allocate memory for tile binning: 
-12. You may need to enable CMA or give it more memory.

... together with a preceding, e.g., ...

| kernel: [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
| kernel: [drm]V3D:  23468kb BOs (10)
| kernel: [drm] V3D shader:144kb BOs (35)
| kernel: [drm]   dumb:   8148kb BOs (4)

... is usually surrounded (in journal) by nothing but many:

| kernel: alloc_contig_range: [36400, 37500) PFNs busy

What I'm trying to say is that there seems to be no log-noticeable
concurrent activity going on.  Watching the CMA use via /proc/meminfo
suggests that it's much more than half free, most of the time.
The tile binning error seems to be entirely random, at this point.


Looking at the source[1], vc4_allocate_bin_bo() seems to use a strategy
of successively allocating memory until it randomly finds a block that
fits certain requirements. Maybe randomly sometimes there is no such
block available, leading to it failing with -ENOMEM. It's not clear
to me, though, when and why the function is called, seemingly randomly
on an idle system. It reads to me as an initialization, not something
that is randomly repeated. (?)

[1] 
https://sources.debian.org/src/linux/4.19.28-2/drivers/gpu/drm/vc4/vc4_v3d.c/#L244


Again, it would be nice if the resulting device error state could
somehow be reset / the function retried with more/different CMA free
at a later point during the same boot. Perhaps that's already possible
(maybe even in a general way?) but I don't know how.

(Trying to unbind the driver (vc4_v3d) via sysfs led to a kernel oops
(IIRC paging fault?), and an attempt to bind it again was rejected
without any noticeable action.)


Regards, Fabian

-- 
Fabian "canvon" Pietsch - https://www.canvon.de/

Bug#924642: stretch-pu: package rsync/3.1.2-1+deb9u1

[Paul Slootman]

On Wed 03 Apr 2019, Adam D. Barratt wrote:
> > 
> > There doesn't appear to be an uploaded version anywhere that I can see.
> 
> This now happened, but
> 
> > Please attach a source debdiff to this report.
> 
> this hasn't. If it had, I'd have asked you to rebuild the package so the
> changelog didn't claim it was uploaded to stretch-security (I'm still
> debating whether to do so anyway, as it'll be less confusing for users).

I'm willing to do whatever you think is best, please feel free to tell
me what to do :-)


Thanks and sorry for the bother,
Paul

Bug#924888: why bsd.license?

[MJ Ray]

On Mon, 1 Apr 2019 12:26:13 +0200
Laura Arjona Reina  wrote:

> BSD, and
> 
> I have checked that the content of the bsd.license file matches the
> BSD-3-Clause license at opensource.org, so I've updated the links to
> 
> https://opensource.org/licenses/BSD-3-Clause
> 
> and removed the file.

Could you add a redirect instead of breaking links from other
documentation, please?  In line with Cool URIs Don't Change,
https://www.w3.org/Provider/Style/URI.html

https://manpages.debian.org/testing/pal/vcard2pal.1.en.html could
probably be fixed by us, as could the links from our wiki, but it looks
like there are also links to it from code on github.

-- 

MJR http://mjr.towers.org.uk/
Member of http://www.software.coop/ (but this email is my personal view
only)

Bug#926321: openafs: FTBFS on arm64

[Paul Martin]

Source: openafs
Version: 1.6.20-2+deb9u2
Severity: normal
Tags: patch, ftbfs, stretch

It would be nice if openafs were to be available on ARM64 architecture 
in Debian Stretch and Ubuntu Bionic.

The OpenStack Infrastructure project in particular would benefit from 
this package suite being available.
diff --git a/debian/control b/debian/control
index 2adc3f2..171ef43 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Vcs-Git: git://anonscm.debian.org/pkg-k5-afs/openafs.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-k5-afs/openafs.git
 
 Package: openafs-client
-Architecture: alpha amd64 arm armel armhf i386 ia64 powerpc powerpcspe ppc64 
s390 s390x sparc
+Architecture: alpha amd64 arm arm64 armel armhf i386 ia64 powerpc powerpcspe 
ppc64 s390 s390x sparc
 Depends: ${shlibs:Depends}, ${misc:Depends}, lsb-base (>= 3.0-6)
 Recommends: lsof, openafs-modules-dkms (>= ${source:Version})
  | openafs-modules-source (>= ${source:Version})
@@ -34,7 +34,7 @@ Description: AFS distributed filesystem client support
 
 Package: openafs-fuse
 Priority: extra
-Architecture: alpha amd64 arm armel armhf i386 ia64 powerpc ppc64 s390 s390x 
sparc
+Architecture: alpha amd64 arm arm64 armel armhf i386 ia64 powerpc ppc64 s390 
s390x sparc
 Depends: ${shlibs:Depends}, ${misc:Depends},
  openafs-client (= ${binary:Version})
 Description: AFS distributed file system experimental FUSE client
@@ -50,7 +50,7 @@ Description: AFS distributed file system experimental FUSE 
client
 
 Package: openafs-kpasswd
 Priority: extra
-Architecture: alpha amd64 arm armel armhf i386 ia64 powerpc powerpcspe ppc64 
s390 s390x sparc
+Architecture: alpha amd64 arm arm64 armel armhf i386 ia64 powerpc powerpcspe 
ppc64 s390 s390x sparc
 Depends: ${shlibs:Depends}, ${misc:Depends},
  openafs-client (= ${binary:Version})
 Conflicts: krb5-user, heimdal-clients, kerberos4kth-clients
@@ -65,7 +65,7 @@ Description: AFS distributed filesystem old password changing
  package for new cells or for cells using Kerberos v5.
 
 Package: openafs-fileserver
-Architecture: alpha amd64 arm armel armhf i386 ia64 powerpc powerpcspe ppc64 
s390 s390x sparc
+Architecture: alpha amd64 arm arm64 armel armhf i386 ia64 powerpc powerpcspe 
ppc64 s390 s390x sparc
 Depends: ${shlibs:Depends}, ${misc:Depends}, lsb-base (>= 3.0-6), 
openafs-client
 Recommends: ntp | time-daemon
 Suggests: openafs-doc
@@ -78,7 +78,7 @@ Description: AFS distributed filesystem file server
  installed on any machine that will export files into AFS.
 
 Package: openafs-dbserver
-Architecture: alpha amd64 arm armel armhf i386 ia64 powerpc powerpcspe ppc64 
s390 s390x sparc
+Architecture: alpha amd64 arm arm64 armel armhf i386 ia64 powerpc powerpcspe 
ppc64 s390 s390x sparc
 Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends},
  openafs-fileserver
 Recommends: openafs-client
@@ -106,7 +106,7 @@ Description: AFS distributed filesystem documentation
  protocol documentation, and other OpenAFS documentation.
 
 Package: openafs-krb5
-Architecture: alpha amd64 arm armel armhf i386 ia64 powerpc powerpcspe ppc64 
s390 s390x sparc
+Architecture: alpha amd64 arm arm64 armel armhf i386 ia64 powerpc powerpcspe 
ppc64 s390 s390x sparc
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Breaks: openafs-client (<< 1.4.7.dfsg1-1)
 Description: AFS distributed filesystem Kerberos 5 integration
@@ -121,7 +121,7 @@ Description: AFS distributed filesystem Kerberos 5 
integration
 
 Package: libkopenafs1
 Section: libs
-Architecture: alpha amd64 arm armel armhf i386 ia64 powerpc ppc64 s390 s390x 
sparc
+Architecture: alpha amd64 arm arm64 armel armhf i386 ia64 powerpc ppc64 s390 
s390x sparc
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: AFS distributed file system runtime library (PAGs)
  AFS is a distributed filesystem allowing cross-platform sharing of
@@ -134,7 +134,7 @@ Description: AFS distributed file system runtime library 
(PAGs)
 
 Package: libafsauthent1
 Section: libs
-Architecture: alpha amd64 arm armel armhf i386 ia64 powerpc ppc64 s390 s390x 
sparc
+Architecture: alpha amd64 arm arm64 armel armhf i386 ia64 powerpc ppc64 s390 
s390x sparc
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: AFS distributed file system runtime library (authentication)
  AFS is a distributed filesystem allowing cross-platform sharing of
@@ -146,7 +146,7 @@ Description: AFS distributed file system runtime library 
(authentication)
 
 Package: libafsrpc1
 Section: libs
-Architecture: alpha amd64 arm armel armhf i386 ia64 powerpc ppc64 s390 s390x 
sparc
+Architecture: alpha amd64 arm arm64 armel armhf i386 ia64 powerpc ppc64 s390 
s390x sparc
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: AFS distributed file system runtime library (RPC layer)
  AFS is a distributed filesystem allowing cross-platform sharing of
@@ -159,7 +159,7 @@ Description: AFS distributed file system runtime library 
(RPC layer)
 Package: libopenafs-dev
 Section: libdevel
 Priority: extra
-Architecture: 

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

[Alexander Larsson]

I noticed this in the FC_DEBUG=16 output:
   /run/host/fonts -> /usr/share/fonts (salt: (null))

Printf NULL like this is fine in glibc, but can crash in other OSes,
so might be nice to fix.

Bug#783653: pymol: segmentation fault confirmed

[merkys]

Control: found -1 1.8.4.0+dfsg-1
Control: found -1 2.2.0+dfsg-4

Found the same problem both in 1.8.4.0+dfsg-1 and 2.2.0+dfsg-4 versions.

Andrius 

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#924642: stretch-pu: package rsync/3.1.2-1+deb9u1

[Adam D. Barratt]

On 2019-03-31 19:57, Adam D. Barratt wrote:

Control: tags -1 + moreinfo

On Fri, 2019-03-15 at 11:23 +0100, Paul Slootman wrote:

There are a couple of CVEs that have been fixed by 3.1.2-1+deb9u2.
After discussing this with a member of the security team it was not
considered important enough to warrant a DSA, but it would be good if
it
could be included in a point release for stretch.

The changelog is:

  * Apply CVEs from 2016 to the zlib code.
closes:#924509

The only change was the addition of 4 patches to the zlib code.

The uploaded version was compiled on a stretch system.



There doesn't appear to be an uploaded version anywhere that I can see.


This now happened, but


Please attach a source debdiff to this report.


this hasn't. If it had, I'd have asked you to rebuild the package so the 
changelog didn't claim it was uploaded to stretch-security (I'm still 
debating whether to do so anyway, as it'll be less confusing for users).


Regards,

Adam

Bug#925913: uhubctl: autopkgtest always fails

[Graham Inggs]

Hi Gustavo

On 2019/04/03 03:40, gustavo panizzo wrote:

I've just uploaded 2.0.0-4 to experimental


That worked perfectly, thanks!
See http://autopkgtest.ubuntu.com/packages/u/uhubctl/disco/amd64

It would be nice to have this fixed for Buster.  I have it on good 
authority that a targeted fix for autopkgtests will be eligible for an 
unblock.


Regards
Graham

Bug#924344: glib2.0: CVE-2019-9633

[Salvatore Bonaccorso]

Control: notfound -1 2.58.3-1

Hi Philip, hi Simon,

On Wed, Apr 03, 2019 at 01:18:36PM +0100, Philip Withnall wrote:
> On Wed, 2019-04-03 at 13:00 +0100, Simon McVittie wrote:
> > On Fri, 29 Mar 2019 at 20:13:17 +0100, Moritz Mühlenhoff wrote:
> > > On Mon, Mar 11, 2019 at 09:32:02PM +0100, Salvatore Bonaccorso
> > > wrote:
> > > > Version: 2.58.3-1
> > 
> > Do we know for sure that 2.58.x is vulnerable? I've tried the
> > reproducer
> > from the upstream bug and didn't see criticals or a crash.
> > 
> > > > Forwarded: https://gitlab.gnome.org/GNOME/glib/issues/1649
> > 
> > This bug says "Another likely regression from Happy Eyeballs". GLib's
> > implementation of RFC 8305 "Happy Eyeballs" is a new feature (or new
> > optimization, depending how you look at it) in 2.59.x/2.60.x.
> 
> Yeah, this bug should be present in 2.59.x where (x < 2). It was fixed
> by commit d553d92d6e9f53cbe5a34166fcb919ba652c6a8e, which is present in
> 2.59.2 onwards. The bug was not present in 2.58.x.
> 
> I’ve left a comment about it here:
> https://gitlab.gnome.org/GNOME/glib/issues/1649#note_481826

Thanks for the update. Then this means that the initial triage
information from myself was just wrong. I have updated the tracker
according to your update now.

Thanks for your both work,

Salvatore

Bug#926291: [Pkg-puppet-devel] Bug#926291: puppetdb 6 not compatible with puppet-master 5

[Apollon Oikonomopoulos]

Control: tags -1 unreproducible moreinfo

Hi,

On 20:23 Tue 02 Apr , Cwsights wrote:
> Package: puppetdb
> Version: 6.2.0-3
> Severity: normal
> 
> Hi,
>   Debian (Buster) packages puppetdb 6 and puppet-master(-passenger) 5.  
> Unfortunately
> puppetdb 6 requires puppet-master to be 6.0.0 or later[1].  This makes it 
> impossible
> to use the puppet-master in buster with the puppetdb in buster.
> 
> [1] https://puppet.com/docs/puppetdb/6.2/index.html#puppet-600

It is true that upstream's release notes mention this restriction.  
However, there seems to be no *technical* requirement for this. Have you 
encountered an actual issue while trying to use PuppetDB 6 with Puppet 5 
masters?

Regards,
Apollon

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

[Thorsten Glaser]

On Wed, 3 Apr 2019, Emmanuel Bourg wrote:

> > I really insist on being able to install tomcat9 without having to
> > install a whole other init system, even if it is not used.
> 
> See this as a compromise?

I don’t know… the missing initscript is an RC bug, so the compromise
would start _after_ it’s added…

> > systemd-sysusers is a service… does that mean the service needs to
> > run in order for it to be useful? If not now, then perhaps later?
> 
> It's a oneshot service, the command is just fired once at boot time.
> There is nothing running in the background.

Ah, okay. I’m a bit concerned about the need for things like dbus,
which aren’t otherwise required to be run on a server (at least with
the headless JRE).

> Extracting systemd-sysusers into a smaller package is probably a good
> idea. However it means trading an overhead for the sysvinit users only
> with a small overhead for everyone, not sure the systemd maintainers
> will agree.

True, we’ll see. Perhaps a split package for “tools from systemd that
can also be used standalone under other init systems without needing
to run all those dæmons” might make more sense than a package with only
systemd-sysusers. The alternative, a package reimplementing systemd-
sysusers as, say shell script, for sysvinit users, is probably even
less sensible, but one I’d prefer over having to install the whole thing
(also, the overhead is only for the package maintainers and ftpmasters
and mirrors, not the users).

> > But can we keep things working for buster, please?
> 
> If #926316 isn't fixed I don't mind using adduser temporarily.

You mention the libpam-systemd alternative part. There’s work
being done implementing things with elogind, but given #925489
chances that this will be usable in buster are about 0.

I’d prefer if we could upload this with adduser now, considering
more changes as well as changes to other packages are almost not
done right now due to the freeze situation (we *are* expecting
buster within $smallnum weeks now).

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#926276: Should guacamole-client be removed?

[Mike Gabriel]

Hi Moritz,

On  Di 02 Apr 2019 22:04:34 CEST, Moritz Muehlenhoff wrote:


Source: guacamole-client
Severity: serious

Should guacamole-client be removed?

guacamole-client hasn't been updated since 2016, is removed from testing
since 1.5 years and has four RC bugs at this point

Cheers,
Moritz


My suggestion to 'Nik was to drop FreeRDP support for a while and fix  
the other issues and keep that in unstable.


However, it's the maintainers call at the end.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpQMOeZEz0sF.pgp
Description: Digitale PGP-Signatur

Bug#924344: glib2.0: CVE-2019-9633

[Philip Withnall]

On Wed, 2019-04-03 at 13:00 +0100, Simon McVittie wrote:
> On Fri, 29 Mar 2019 at 20:13:17 +0100, Moritz Mühlenhoff wrote:
> > On Mon, Mar 11, 2019 at 09:32:02PM +0100, Salvatore Bonaccorso
> > wrote:
> > > Version: 2.58.3-1
> 
> Do we know for sure that 2.58.x is vulnerable? I've tried the
> reproducer
> from the upstream bug and didn't see criticals or a crash.
> 
> > > Forwarded: https://gitlab.gnome.org/GNOME/glib/issues/1649
> 
> This bug says "Another likely regression from Happy Eyeballs". GLib's
> implementation of RFC 8305 "Happy Eyeballs" is a new feature (or new
> optimization, depending how you look at it) in 2.59.x/2.60.x.

Yeah, this bug should be present in 2.59.x where (x < 2). It was fixed
by commit d553d92d6e9f53cbe5a34166fcb919ba652c6a8e, which is present in
2.59.2 onwards. The bug was not present in 2.58.x.

I’ve left a comment about it here:
https://gitlab.gnome.org/GNOME/glib/issues/1649#note_481826

Philip


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

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

[Emmanuel Bourg]

Le 03/04/2019 à 13:39, Thorsten Glaser a écrit :

> I really insist on being able to install tomcat9 without having to
> install a whole other init system, even if it is not used.

See this as a compromise?


> I’ve seen that
> systemd-sysusers is a service… does that mean the service needs to
> run in order for it to be useful? If not now, then perhaps later?

It's a oneshot service, the command is just fired once at boot time.
There is nothing running in the background.


> If we weren’t this deep into the freeze, I’d offer to write a
> systemd-less replacement that parses the same configuration files
> and upload it separately. Or maybe, if systemd-sysusers really has
> no dependency on anything else except libsystemd0, it could become
> split off into another package.

Extracting systemd-sysusers into a smaller package is probably a good
idea. However it means trading an overhead for the sysvinit users only
with a small overhead for everyone, not sure the systemd maintainers
will agree.


> But can we keep things working for buster, please?

If #926316 isn't fixed I don't mind using adduser temporarily.

Emmanuel Bourg

Bug#783653: pymol: segmentation fault confirmed

[merkys]

Version: 1.8.4.0+dfsg-1build1

Hello,

seemingly the same bug is observed using pymol 1.8.4.0+dfsg-1build1 on
Ubuntu-18.04. The greeting message of pymol tells that my graphics
driver is blacklisted:

 Detected OpenGL version 2.0 or greater. Shaders available.
 Detected GLSL version 1.40.
 OpenGL graphics engine:
  GL_VENDOR:   nouveau
  GL_RENDERER: NV137
  GL_VERSION:  3.1 Mesa 18.2.8
 Detected blacklisted graphics driver.  Disabling shaders.
 Detected 24 CPU cores.  Enabled multithreaded rendering.

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen

[Vincent Lefevre]

On 2019-04-03 13:42:50 +0200, Vincent Lefevre wrote:
> On 2019-02-07 13:43:20 +0100, Egmont Koblinger wrote:
> > You can disable this behavior with:
> > 
> >   printf '\e[?1007l'
> 
> This has no effect when using GNU Screen. For instance:
> 
> $ printf '\e[?1007l' ; screen sleep 20
> 
> then when using the mouse wheel:
> 
> ^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A
> 
> There isn't such an issue with xterm. It is not Screen that enables
> Alternate Scroll Mode, otherwise one would get the same behavior in
> xterm.
> 
> I suspect that GNOME Terminal "forgets" this setting under some
> conditions.

I think that the cause is that Screen does a reset (since it starts
a virtual terminal), as I can reproduce the same issue after a
"tput reset". Thus "printf '\e[?1007l'" is not sufficient. Actually,
a reset should not have an effect on the Alternate Scroll Mode, as
in xterm, it doesn't as shown by:

$ printf '\e[?1007l'
$ screen sleep 20
$ printf '\e[?1007h'
$ screen sleep 20

and using the mouse wheel in Screen for both instances (after the
printf '\e[?1007h', the Alternate Scroll Mode remains enabled while
the default is disabled in xterm).

Note: Executing "printf '\e[?1007l'" inside screen as a workaround is
incorrect as there is no way to know whether the parent terminal will
accept this sequence or will behave in a strange manner. Moreover,
this is not possible when "screen" is followed by a command.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#926320: localslackirc: Doesn't show anything which I wrote via web interface

[Axel Beckert]

Package: localslackirc
Version: 1.2-1
Severity: normal

Hi,

I just installed localslackirc on Debian Sid, generated a token on
https://api.slack.com/custom-integrations/legacy-tokens (redirected from
https://api.slack.com/docs/oauth-test-tokens as mentioned in
/usr/share/doc/localslackirc/README.md.gz) and saved it in
~/.localslackirc

I then started it with "localslackirc -j" and connected with
irssi. Autojoining all channels seems to have worked, I see also the
user list for each channel, but I don't see anything I wrote myself in a
channel via the web client.

Happened with irssi 1.1.2 as well as 1.2.0 (Debian package 1.2.0-2).

Additionally I got the following crash and double traceback of
localslackirc upon "/quit irssi restart" in irssi:

Unknown command:  b'QUIT :irssi restart'
Unknown command:  b'CAP LS'
Traceback (most recent call last):
  File "/usr/bin/localslackirc", line 498, in 
main()
  File "/usr/bin/localslackirc", line 488, in main
ircclient.command(i)
  File "/usr/bin/localslackirc", line 408, in command
handlers[cmdid](cmd)
  File "/usr/bin/localslackirc", line 107, in _userhandler
self._sendreply(1, 'Welcome to localslackirc')
  File "/usr/bin/localslackirc", line 101, in _sendreply
bytemsg,
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/localslackirc", line 502, in 
traceback.print_last()
  File "/usr/lib/python3.7/traceback.py", line 173, in print_last
raise ValueError("no last exception")
ValueError: no last exception
localslackirc -j  10.31s user 1.59s system 1% cpu 13:39.31 total

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

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

Versions of packages localslackirc depends on:
ii  python33.7.3-1
ii  python3-requests   2.21.0-1
ii  python3-typedload  1.15-1
ii  python3-websocket  0.53.0-1

localslackirc recommends no packages.

localslackirc suggests no packages.

-- no debconf information

Bug#924344: glib2.0: CVE-2019-9633

[Simon McVittie]

On Fri, 29 Mar 2019 at 20:13:17 +0100, Moritz Mühlenhoff wrote:
> On Mon, Mar 11, 2019 at 09:32:02PM +0100, Salvatore Bonaccorso wrote:
> > Version: 2.58.3-1

Do we know for sure that 2.58.x is vulnerable? I've tried the reproducer
from the upstream bug and didn't see criticals or a crash.

> > Forwarded: https://gitlab.gnome.org/GNOME/glib/issues/1649

This bug says "Another likely regression from Happy Eyeballs". GLib's
implementation of RFC 8305 "Happy Eyeballs" is a new feature (or new
optimization, depending how you look at it) in 2.59.x/2.60.x.

smcv

Bug#924911: closed by Matthias Klose (Bug#924911: fixed in gcc-8 8.3.0-4)

[Andreas Beckmann]

On 2019-03-26 13:21, Debian Bug Tracking System wrote:
> #924911: gcc-8-base: please add Breaks: gnat-6 (<< 6.4)

That worked as expected :-)
Thanks!

Andreas

Bug#925969: tomcat8: Variable expansion not supported in /etc/default/tomcat8

[Emmanuel Bourg]

Le 29/03/2019 à 16:32, Igor Blanco a écrit :

> The issue seems to be related to the usage of ${JAVA_OPTS} as a variable 
> expansion. Systemd does not supporte variable expansion in "Environment" 
> attributes
> and it seems like it doesn't either when environmentFiles are loaded.

Thank you for reporting this issue Igor. /etc/default/tomcat8 should
probably be sourced from tomcat-start.sh instead of being used with the
EnvironmentFile directive. It looks like that's what upstream suggests [1].

[1] https://github.com/systemd/systemd/issues/4416#issuecomment-255169835

Bug#926009: openjdk-11 breaks libreoffice autopkgtests

[Rene Engelhard]

reassign 926009 src:openjdk-11
clone 926009 -1
found -1 11.0.3+4-2 
reassign -1 src:libreoffice
forwarded -1 https://bugs.documentfoundation.org/show_bug.cgi?id=124503
retitle -1 LibreOffice does not recognize new "Debian" JDK (openjdk 11 >= 
11.0.3+4-2)
thanks

Hi,

On Wed, Apr 03, 2019 at 07:41:19AM +0200, Rene Engelhard wrote:
> On Tue, Apr 02, 2019 at 11:44:27PM +0200, Rene Engelhard wrote:
> > Indeed, after adding "Debian" as a copy of "Oracle Corporation" javaldx
> > works again.
> 
> I retract that, no idea what I did when testing this, maybe I just tried
> in the wrong console window (given the time and tiredness not
> unlikely..) ...

Olivier pointed me to javavendors.cxx which also needs to be patched.

Done in git now and it seems to work now, really :-)

I still think the java(.vm).vendor change should be reverted, though.

Reassigning a clone of this to LO, I'll add "Debian" as a supported
vendor nevertheless for now to get it building right now...

Regards,
  
Rene

Bug#925106: php7.3-common: please add Breaks: php7.0-curl, gforge-common (<< 6)

[Ondřej Surý]

Hi Andreas,

there will be new upstream release of PHP 7.3 this week, so I’ll handle it as 
one batch, ok?

I just wonder if there’s a way how to fix that without breaking 
co-installability with php7.0-curl from external repositories.

What if we fixed this in php7.0-curl package?  (I keep separate sources for it.)

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 23 Mar 2019, at 16:50, Andreas Beckmann  wrote:
> 
> Followup-For: Bug #925106
> 
> Hi,
> 
> next round, let's add a Breaks: gforge-common (<< 6), too.
> That's the version from jessie (there is no gforge-common in stretch, so
> the jessie version may be kept installed on long grown system upgrades),
> which will fail to remove under php7.3:
> 
>  Removing gforge-shell-postgresql (5.3.2+20141104-3+deb8u3) ...
>  PHP Deprecated:  Methods with the same name as their class will not be 
> constructors in a future version of PHP; Error has a deprecated constructor 
> in /usr/share/gforge/common/include/Error.class.php on line 36
>  PHP Fatal error:  Cannot declare class Error, because the name is already in 
> use in /usr/share/gforge/common/include/Error.class.php on line 36
>  dpkg: error processing package gforge-shell-postgresql (--remove):
>   installed gforge-shell-postgresql package pre-removal script subprocess 
> returned error exit status 255
> 
> This happens in multiple gforge packages, but can be prevented by
> uninstalling it before php7.3 gets installed.
> 
> 
> Andreas
> 

Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen

[Vincent Lefevre]

On 2019-02-07 13:43:20 +0100, Egmont Koblinger wrote:
> You can disable this behavior with:
> 
>   printf '\e[?1007l'

This has no effect when using GNU Screen. For instance:

$ printf '\e[?1007l' ; screen sleep 20

then when using the mouse wheel:

^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A

There isn't such an issue with xterm. It is not Screen that enables
Alternate Scroll Mode, otherwise one would get the same behavior in
xterm.

I suspect that GNOME Terminal "forgets" this setting under some
conditions.

Moreover, it is not possible to use "printf '\e[?1007l'" easily when
using "--" + some arbitrary command (whose arguments may contain
spaces and other special characters, so that using "sh -c ..." to
execute the printf first would be complex and error prone).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Thorsten Glaser]

On Wed, 3 Apr 2019, Emmanuel Bourg wrote:

> Assuming #926316 gets fixed, I think we should focus only on providing a
> usable sysvinit script as required by the policy. Supporting people

I really insist on being able to install tomcat9 without having to
install a whole other init system, even if it is not used.

> Regarding the weight, at this point you've already installed the JRE and
> Tomcat, the few extra MB for systemd are negligible.

It’s also about attack surface, or other tools that assume something
(such as systemd being actually run when installed). I’ve seen that
systemd-sysusers is a service… does that mean the service needs to
run in order for it to be useful? If not now, then perhaps later?

> There is a growing consensus around the idea that imperative maintainer
> scripts are a bad thing and they should be replaced with something
> declarative. systemd-sysusers does exactly that for the user creation,

Not all of them, but I can see this for some cases. On the other hand,
user creation with adduser is *really* light.

If we weren’t this deep into the freeze, I’d offer to write a
systemd-less replacement that parses the same configuration files
and upload it separately. Or maybe, if systemd-sysusers really has
no dependency on anything else except libsystemd0, it could become
split off into another package.

But can we keep things working for buster, please?

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#926134: antlr4: Please package Python 3 runtime

[Emmanuel Bourg]

Hi Benjamin,

Le 31/03/2019 à 21:52, Benjamin Barenblat a écrit :

> Coq now needs the ANTLR 4 runtime for Python 3 to generate its HTML
> documentation. Would you be willing to add it to the antlr4 package?

The Java Team would prefer maintaining only the Java part of ANTLR 4.
Ideally the python part should be maintained separately, so a dedicated
package as suggested in #897129 is a good idea.

Emmanuel Bourg

Bug#926061: bug 926061 is forwarded to https://github.com/liblouis/liblouisutdml/issues/50

[Christian Egli]

forwarded 926061 https://github.com/liblouis/liblouisutdml/issues/50

Upstream bug has been moved to 
https://github.com/liblouis/liblouisutdml/issues/50


thanks

Bug#926315: [PATCH] debian/rules: Ship openssl.cnf in libssl1.1-udeb, as required to use OpenSSL by other udebs, e.g. wget-udeb. Closes: #926315

[Dimitri John Ledkov]

---
 debian/changelog | 7 +++
 debian/rules | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 920d74c030..bb3fd13682 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+openssl (1.1.1b-2) UNRELEASED; urgency=medium
+
+  * debian/rules: Ship openssl.cnf in libssl1.1-udeb, as required to use
+OpenSSL by other udebs, e.g. wget-udeb. Closes: #926315
+
+ -- Dimitri John Ledkov   Wed, 03 Apr 2019 12:02:03 +0100
+
 openssl (1.1.1b-1) unstable; urgency=medium
 
   [ Sebastian Andrzej Siewior ]
diff --git a/debian/rules b/debian/rules
index 5ef5069c68..cf25fddb13 100755
--- a/debian/rules
+++ b/debian/rules
@@ -120,6 +120,8 @@ override_dh_auto_install-arch:
ln -s /etc/ssl/{certs,openssl.cnf,private} debian/tmp/usr/lib/ssl/
cp -pf debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcrypto.so.* 
debian/libcrypto1.1-udeb/usr/lib/
cp -pf debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libssl.so.* 
debian/libssl1.1-udeb/usr/lib/
+   mkdir -p debian/libssl1.1-udeb/usr/lib/ssl
+   cp debian/tmp/etc/ssl/openssl.cnf debian/libssl1.1-udeb/usr/lib/ssl/
cp -auv build_shared/lib*.so* debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/
for opt in $(OPTS); \
do set -xe; \
-- 
2.20.1

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Mattia Rizzolo]

On Wed, Apr 03, 2019 at 06:45:28AM -0400, Chris Lamb wrote:
> My conception is that as we call diffoscope on the two .changes files
> it will report they are reproducible as, well, the binary package will
> (likely…) be identical.

Yup.  It would.

> > The tricky part is that that "tarball" we have been talking about is not
> > saved anywhere.
> 
> Nod, I guess we would want that for true jenkins.debian.org "please
> save the build artifacts" support but for now getting a red/green
> light would be interesting in/of itself.

I think it would work out of the box already.

Now, regarding building d-i as a normal package, I hit a bit of a
readblock because it fails while trying to download the files in the
nodes running in the future.
What d-i does it copying the url from the host's (or, well, the
chroot's) /etc/apt/sources.list, but it seems it doesn't also pick up an
eventual [check-valid-until=no] placed on the same line :\

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Samuel Thibault]

Chris Lamb, le mer. 03 avril 2019 06:45:28 -0400, a ecrit:
> > > Whilst it may build indeed these files they do not appear in the
> > > binary package:
> > 
> > > Thus, they cannot affect the reproducibility status of the debian-
> > > installer source package. […]
> >
> > Yes they do!
> 
> Oh, hang on, does src:debian-installer's .changes file include these
> extra files? That might be what I'm missing.

It seems so, see in

https://buildd.debian.org/status/fetch.php?pkg=debian-installer=amd64=20190118=1547858681=0

Checksums-Sha1:
 726c95c9add3222b6c4b744f8cf1e18afd44437e 528261542 
debian-installer-images_20190118_amd64.tar.gz
 324185c8187548dd86e301910751e1f83413ae5c 10730 
debian-installer_20190118_amd64.buildinfo
 870d941832bcdd7fbde0b04974d5e46c812d76b2 734340 
debian-installer_20190118_amd64.deb
Checksums-Sha256:
 698b1c32e0f3d1da174ed96af64040d65eac955ccec110d7b651b615ff3c74ae 528261542 
debian-installer-images_20190118_amd64.tar.gz
 633371431ea7a425163f7a8360d56e1fa401fffcfff8612fe80078cdb40add4b 10730 
debian-installer_20190118_amd64.buildinfo
 7e82f489df6d36a37bc9c810cb24d4cfbdc1eb95e5aa539d19691c28d24c6dfa 734340 
debian-installer_20190118_amd64.deb
Files:
 843efa1eba8e58e04bd174647431fbc6 528261542 raw-installer - 
debian-installer-images_20190118_amd64.tar.gz
 9daa2e9db4355b189c60132a97eb4103 10730 devel optional 
debian-installer_20190118_amd64.buildinfo
 4c9e4745b8dd0e673af2548f11bc5796 734340 devel optional 
debian-installer_20190118_amd64.deb

Samuel

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Cyril Brulebois]

Chris Lamb  (2019-04-03):
> Hi Mattia,
> 
> > > Whilst it may build indeed these files they do not appear in the
> > > binary package:
> > 
> > > Thus, they cannot affect the reproducibility status of the debian-
> > > installer source package. […]
> >
> > Yes they do!
> 
> Oh, hang on, does src:debian-installer's .changes file include these
> extra files? That might be what I'm missing.

Yes:

kibi@armor:~/debian-installer$ dcmd debian-installer_20190118_amd64.changes
debian-installer-images_20190118_amd64.tar.gz
debian-installer_20190118_amd64.buildinfo
debian-installer_20190118_amd64.deb
debian-installer_20190118_amd64.changes

The tarball is uploaded alongside the other files; “just” treated
“somewhat differently” by dak.
 

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


signature.asc
Description: PGP signature

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Chris Lamb]

Hi Mattia,

> > Whilst it may build indeed these files they do not appear in the
> > binary package:
> 
> > Thus, they cannot affect the reproducibility status of the debian-
> > installer source package. […]
>
> Yes they do!

Oh, hang on, does src:debian-installer's .changes file include these
extra files? That might be what I'm missing.

My conception is that as we call diffoscope on the two .changes files
it will report they are reproducible as, well, the binary package will
(likely…) be identical.

> The tricky part is that that "tarball" we have been talking about is not
> saved anywhere.

Nod, I guess we would want that for true jenkins.debian.org "please
save the build artifacts" support but for now getting a red/green
light would be interesting in/of itself.


Best wishes,

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

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

[Emmanuel Bourg]

Le 02/04/2019 à 23:01, Thorsten Glaser a écrit :

> Most people using Debian without systemd have APT pinning or other
> measures in place that prevent the systemd package, which ships the
> systemd-sysusers binary (and service?), from being installed, in
> order to not sneakily being converted to systemd (it did happen).

I did some tests in a VM with a minimal install where I switched to
sysvinit with:
  apt install sysvinit-core
  cp /usr/share/sysvinit/inittab /etc/inittab
  reboot
  apt remove systemd

In Stretch I can install the systemd package and it won't switch the
init system as advertised. In Buster unfortunately installing systemd
pulls systemd-sysv through libpam-systemd and the init system is
switched. The --no-install-recommends flag has to be used to avoid that.
I've filed a bug for systemd (#926316).

Assuming #926316 gets fixed, I think we should focus only on providing a
usable sysvinit script as required by the policy. Supporting people
allergic to systemd and using APT pinning to exclude it is out of topic
(they should only exclude systemd-sysv anyway, not systemd).


> What is the issue with using adduser, which is the standard Debian
> tool doing the same job, instead? After all, depending on systemd
> just to create a system user and group is very heavy-weight.

There is a growing consensus around the idea that imperative maintainer
scripts are a bad thing and they should be replaced with something
declarative. systemd-sysusers does exactly that for the user creation,
that's why I favored it over the traditional adduser.

Regarding the weight, at this point you've already installed the JRE and
Tomcat, the few extra MB for systemd are negligible.


> OK, removed.
> 
> 
> OK, reverted.

Thank you


> Did you have a chance to test this on a buster/systemd Debian?
> I don’t currently have such a machine existing in a meaningful
> way. (Granted, I could probably cobble together some test VM,
> but I’m sure you have something at hand.)

I haven't checked yet.

Emmanuel Bourg

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Mattia Rizzolo]

On Wed, Apr 03, 2019 at 06:21:39AM -0400, Chris Lamb wrote:
> Whilst it may build indeed these files they do not appear in the
> binary package:

> Thus, they cannot affect the reproducibility status of the debian-
> installer source package. This prompted my paragraph regarding at
> least including these files' hashes, etc.

Yes they do!

The tricky part is that that "tarball" we have been talking about is not
saved anywhere.  Once it is uploaded to ftp-master it's unpacked and
then discarded, so you can't quite get your hands on it without doing a
local build of debian-installer.

Furthermore now d-i as released wouldn't build anyway because it tries
to look up linux 4.19.0-1 instead of 4.19.0-4... And after changing that
it tries to look for the non-existent hyperv-modules-4.19.0-4-amd64-di,
and here I don't want to go digging in d-i… :( - so I can't show you
that tarball I'm talking about right now...

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#925334: vc4: CMA fills up and screen not updated anymore on raspi3

[Fabian Pietsch]

Hi,

* Romain Perier (Wed, 27 Mar 2019 21:33:19 +0100):
> Return-Path: 
> Message-ID: <20190327203319.ga15...@debby.home>
> From: Romain Perier 
> Subject: Re: Bug#925334: vc4: CMA fills up and screen not updated anymore
>  on raspi3
> To: Fabian Pietsch , 925...@bugs.debian.org
> User-Agent: Mutt/1.10.1 (2018-07-13)
> 
> On Wed, Mar 27, 2019 at 03:29:21PM +0100, Fabian Pietsch wrote:

[...]

> > the bug is still present in the current version. It took a freshly
> > booted, idle system 3304 seconds for the bug to occur, though,
> > so this time rather an hour (than 10-30min as stated before).

[...]

> > So vc4_v3d which reported the error seems to be in status=error
> > and counts as suspended. Manual attempts to get it to resume again,
> > now that more cma is free again, failed, but there are probably ways
> > I don't know about.

[...]

> Could you test, two stuffs for me ? :
> 
> 1. The VC4 driver seems to use runtime pm operations, could you try to
> disable runtime suspend completly (there are kernel parameters for this
> if I remember correctly) ?

Didn't find anything useful to that regard in linux-doc Documentation/
and by googling. Could you please tell me how?

> 2. Your kernel cmdline are... weird, could you try with minimalistic
> kernel cmdline ? Only keep console= for logging to uart and/or to your
> tty0 and keep your rootfs.

The initial part until the two spaces seems to be auto-generated by the
firmware at boot, so I guess I can't change or suppress it; if it should
be possible, again, please tell me how.

My kernel cmdline as passed *to* the firmware is:

| fabian@rpi3:~$ cat /boot/firmware/cmdline.txt
| console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw elevator=deadline 
fsck.repair=yes net.ifnames=0 cma=128M rootwait

This is just auto-generated by the raspi3-firmware package to which
you (Romain Perier) seem to be contributing.

As suggested, I tested more compact cmdline.txt, though:

| root=/dev/mmcblk0p2

| console=tty0 root=/dev/mmcblk0p2

| console=tty0 root=/dev/mmcblk0p2 cma=128M

With the first two, cma defaulted to 64M and already the lightdm login
screen stops updating after a few seconds to minutes. With the 3rd,
the bug initially didn't happen so I used X a bit, then logged out and
let the system fall idle; the bug then seems to have happened
9868 seconds after boot (according to dmesg --follow).

Regards, Fabian

-- 
Fabian "canvon" Pietsch - https://www.canvon.de/

Bug#926317: libyder.pc Requires.private systemd, but systemd not in debian/control

[Harald Welte]

Package: libyder-dev
Version: 1.4.4-4
Severity: normal

I'm experiencing problems building yder-based applications:,
libyder.pc (after applying debian/cmake.patch) has a Requires.private to
the pacakge 'systemd'.  However, 'systemd' is not listed in the
'Depends' line of debian/control.

This leads to the absurd situation that I can build + install
libyder-dev, but other yder-using applications will not get past their
cmaake/autoconf step as 'systemd' is not neccessarily installed.

So at the very least, 'systemd' should be listed in 'Depends'.

I'm somewhat doubtful about this entire method of using pkg-config
'Requires.private'.  It may make sense in the absence of a package
manager.  But as we're talking about a Debian package here: Dependencies
should be tracked at package installation time using dpkg/apt, and not
some pkg-config private mechanism, IMHO.

Also, I'm not entirely sure why there's a dependency on 'systemd', and
not 'libsystemd' as in the upstream source.  The Debian changelog
unfortunately doesn't explain why that cmake.patch is used.

Thanks in advance.

-- 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.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libyder-dev depends on:
ii  libjansson-dev  2.12-1
ii  liborcania-dev  1.2.9-5
ii  libsystemd-dev  241-2
ii  libyder2.0  1.4.4-4

libyder-dev recommends no packages.

libyder-dev suggests no packages.

-- no debconf information

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Chris Lamb]

Dear Mattia,

> > TIL. However, as these generated files do not appear in the binary
> > debian-installer package it is likely that that our testing framework
> > will (after the mooted networking exception is made) entirely-
> > correctly report that the src:debian-installer package is reproducible
> > as its declared artifects contain only documentation. This will be
> > somewhat misleading about the true reproducibility status of our installer.
> 
> It doesn't contain only documentation.
> src:debian-installer also builds a
> debian-installer-images_$(VERSION)_$(ARCH).tar.gz that does contain
> binary stuff, including the initrd, kernel image, mini.iso, etc etc.

Whilst it may build indeed these files they do not appear in the
binary package:

$ find | head
.
./usr
./usr/share
./usr/share/doc
./usr/share/doc/debian-installer
./usr/share/doc/debian-installer/talks
./usr/share/doc/debian-installer/talks/fosdem07
./usr/share/doc/debian-installer/talks/fosdem07/README
./usr/share/doc/debian-installer/talks/fosdem07/fosdem1.tgz
./usr/share/doc/debian-installer/talks/d-i_debconf7

$ find | grep images

$ 

Thus, they cannot affect the reproducibility status of the debian-
installer source package. This prompted my paragraph regarding at
least including these files' hashes, etc.

> Right, to cover this we would need to do a full build of the cd image.
> I have no idea whatsoever how that's done (and, as others said, it's
> outside of the debian-boot office, it's within debian-cd).

I see I've been conflating the -boot and -cd work here, sorry. Well,
if full debian-cd rebuilds are out of scope for now (!) we should
at-least cover any "debian-boot" related stuff.

Now, I am certain I am missing something but would this latter
approach just (!) involve adding another Jenkins job that tracks the
HEAD of debian- installer.git (ooh, another advantage; time) which
calls "make -C build release" in two environments?


Regards,

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

Bug#926314: unblock: debian-edu-doc/2.10.15

[Wolfgang Schweer]

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

Please unblock package debian-edu-doc

It contains documentation updates to match the latest changes in 
debian-edu-install/2.10.21 and debian-edu-config/2.10.64 as well as 
translation updates. Holger Levsen has already uploaded the package.

The full source debdiff against the package in testing is huge due to 
the PO and POT files, so a reduced one is attached instead.

(debdiff debian-edu-doc_2.10.14.dsc debian-edu-doc_2.10.15.dsc|diffstat)

Also, the diff for all files below the debian/ directory is attached 
(taken from the full source debdiff).

unblock debian-edu-doc/2.10.15

Regards,
Wolfgang
 debian/changelog|   26 
 debian/copyright|   12 
 debian/mail_stats_to_list   |4 
 documentation/audacity/audacity-manual.cs.po|   15 
 documentation/audacity/audacity-manual.fr.po|   31 
 documentation/audacity/audacity-manual.nb.po|   32 
 documentation/audacity/audacity-manual.nl.po|   33 
 documentation/audacity/audacity-manual.pl.po|   15 
 documentation/audacity/audacity-manual.pot  |   15 
 documentation/audacity/audacity-manual.pt_BR.po |   15 
 documentation/audacity/audacity-manual.sv.po|   15 
 documentation/audacity/audacity-manual.uk.po|   18 
 documentation/audacity/audacity-manual.xml  |6 
 documentation/audacity/audacity-manual.zh.po|   15 
 documentation/audacity/audacity-manual.zh_Hant.po   |   25 
 documentation/debian-edu-buster/debian-edu-buster-manual.da.po  |  615 ---
 documentation/debian-edu-buster/debian-edu-buster-manual.de.po  |  645 ---
 documentation/debian-edu-buster/debian-edu-buster-manual.es.po  |  504 +++--
 documentation/debian-edu-buster/debian-edu-buster-manual.fr.po  |  632 ---
 documentation/debian-edu-buster/debian-edu-buster-manual.it.po  |  843 +-
 documentation/debian-edu-buster/debian-edu-buster-manual.ja.po  |  632 ---
 documentation/debian-edu-buster/debian-edu-buster-manual.nb.po  |  644 ---
 documentation/debian-edu-buster/debian-edu-buster-manual.nl.po  |  732 
 documentation/debian-edu-buster/debian-edu-buster-manual.pl.po  |  316 +--
 documentation/debian-edu-buster/debian-edu-buster-manual.pot|  276 +--
 documentation/debian-edu-buster/debian-edu-buster-manual.xml|  146 -
 documentation/debian-edu-buster/debian-edu-buster-manual.zh.po  |  510 +++---
 documentation/debian-edu-buster/debian-edu-buster-manual.zh_Hant.po |  276 +--
 documentation/debian-edu-itil/debian-edu-itil-manual.nb.po  |   99 -
 documentation/debian-edu-itil/debian-edu-itil-manual.nl.po  |   11 
 documentation/debian-edu-itil/debian-edu-itil-manual.pot|4 
 documentation/debian-edu-itil/debian-edu-itil-manual.xml|2 
 documentation/debian-edu-itil/debian-edu-itil-manual.zh.po  |4 
 documentation/debian-edu-itil/debian-edu-itil-manual.zh_Hant.po |   12 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.da.po|   36 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.de.po|   31 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.es.po|   35 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.fr.po|   36 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.it.po|   27 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.ja.po|   25 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.nb.po|   32 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.nl.po|   33 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.pl.po|   27 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.pot  |   12 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.xml  |4 
 documentation/debian-edu-stretch/debian-edu-stretch-manual.zh.po|   35 
 documentation/rosegarden/rosegarden-manual.es.po|   10 
 documentation/rosegarden/rosegarden-manual.fr.po|   17 
 documentation/rosegarden/rosegarden-manual.nb.po|   22 
 documentation/rosegarden/rosegarden-manual.nl.po|   20 
 documentation/rosegarden/rosegarden-manual.pl.po|   10 
 documentation/rosegarden/rosegarden-manual.pot  |   10 
 documentation/rosegarden/rosegarden-manual.xml  |4 
 documentation/rosegarden/rosegarden-manual.zh.po|   10 
 

Bug#926315: openssl: wget https://google.com fails in d-i

[Dimitri John Ledkov]

Package: openssl
Version: 1.1.1b-1
Severity: important

Dear Maintainer,

$ wget https://google.com

fails in Buster alpha installer, when used from a booted netinst iso
in a tty. It also means that fetch-url fails, and thus one cannot use
https preseeding.

A fix/workaround, is $ touch /usr/lib/ssl/openssl.cnf it appears that
openssl requires for that file to be present, and it cannot be a
dangling symlink. However, in udeb environment such file does not
exists. I guess that maybe libssl1.1-udeb should ship an empty
openssl.cnf there, or ship the regular deb's /etc/ssl/openssl.cnf in
/usr/lib/ssl/openssl.cnf in the udeb.

Regards,

Dimitri.

Bug#926309: gdm3: gdm-x-session calls Xsession with broken arguments

[Simon McVittie]

On Wed, 03 Apr 2019 at 11:12:49 +0200, Matijs van Zuijlen wrote:
> Version: 3.32.0-1
> 
> Since a couple of weeks, I guess

This is presumably a regression in the gdm3 version in experimental,
or a regression in some related GNOME 3.32 component in experimental
(maybe gnome-session or similar). buster/sid are hopefully unaffected?

> GDK_BACKEND based on session type

codesearch.debian.net doesn't find that string anywhere, and it doesn't
look like the name of an X session, so I'm puzzled too.

smcv

Bug#926316: systemd: Installing the systemd package switches the init system to systemd

[Emmanuel Bourg]

Package: systemd
Version: 241-1
Severity: normal

Hi,

The description of the systemd package states that installing it will not
switch the init system, unfortunately that's what happens, unless systemd
is installed with --no-install-recommends. It looks like a recommended
dependency (libpam-systemd?) triggers the removal of sysvinit-core.

I haven't been able to track exactly why it happens in testing with the
version 241-1. With the version 241-2 in sid I guess the removal of
systemd-shim from the alternative dependencies of libpam-systemd [1]
last week doesn't help.


root@sysvinit:~# ps aux
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root 1  0.0  0.0   7900  1980 pts/1Ss+  09:29   0:00 init [2]
root   884  0.0  0.1 156188  2412 ?Ssl  09:29   0:00 
/usr/sbin/rsyslogd
root   912  0.0  0.0   5508  1968 ?Ss   09:29   0:00 
/usr/sbin/cron
root   940  0.0  0.1   4000  3300 ?Ss   09:29   0:00 /bin/bash
root  1237  0.0  0.0   2420  1480 pts/0Ss+  09:31   0:00 
/sbin/getty --noclear 38400 tty1
root  1238  0.0  0.0   2420  1556 pts/1Ss+  09:31   0:00 
/sbin/getty --noclear 38400 tty2
root  2269  0.0  0.1   7640  2724 ?R+   09:53   0:00 ps aux

root@sysvinit:~# ls -l /sbin/init
-rwxr-xr-x 1 root root 53016 Feb 14 20:33 /sbin/init

root@sysvinit:~# apt install systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer 
required:
  initscripts insserv startpar sysv-rc
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  dbus libargon2-1 libcryptsetup12 libdbus-1-3 libexpat1 libjson-c3 
libnss-systemd libpam-systemd systemd-sysv
Suggested packages:
  default-dbus-session-bus | dbus-session-bus systemd-container policykit-1
The following packages will be REMOVED:
  sysvinit-core
The following NEW packages will be installed:
  dbus libargon2-1 libcryptsetup12 libdbus-1-3 libexpat1 libjson-c3 
libnss-systemd libpam-systemd systemd systemd-sysv
0 upgraded, 10 newly installed, 1 to remove and 0 not upgraded.
Need to get 4786 kB of archives.
After this operation, 16.7 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.

root@sysvinit:~# apt install systemd --no-install-recommends
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libargon2-1 libcryptsetup12 libjson-c3
Suggested packages:
  systemd-container policykit-1
Recommended packages:
  libpam-systemd dbus
The following NEW packages will be installed:
  libargon2-1 libcryptsetup12 libjson-c3 systemd
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 3733 kB of archives.
After this operation, 14.4 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.

Emmanuel Bourg

[1] https://salsa.debian.org/systemd-team/systemd/commit/8d292a0a

Bug#926313: leptonica-progs: trying to overwrite '/usr/bin/imagetops', which is also in package netpbm

[Jakub Wilk]

Package: leptonica-progs
Version: 1.78.0-1
Severity: serious

leptonica-progs fails to upgrade here:

  Unpacking leptonica-progs (1.78.0-1) over (1.76.0-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-HhGtJC/7-leptonica-progs_1.78.0-1_i386.deb (--unpack):
   trying to overwrite '/usr/bin/imagetops', which is also in package netpbm 
2:10.0-15.3+b2
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-HhGtJC/7-leptonica-progs_1.78.0-1_i386.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)


--
Jakub Wilk

Bug#570623: reprepro: please add multiple version management

[Benjamin Drung]

Am Sonntag, den 31.03.2019, 15:12 +0200 schrieb Vincent Bernat:
> Package: reprepro
> Version: 5.3.0-1
> Followup-For: Bug #570623
> 
> What is the status of this feature? The merge request is not
> available anymore

It seems that the support for pull requests were disabled.

>  and the GitHub repository of the fork is not up-to-date with
> 5.3.0.

I refreshed the patches on top of version 5.3.0 and pushed it to 
https://salsa.debian.org/bdrung/reprepro/ and 
https://github.com/profitbricks/reprepro

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Mattia Rizzolo]

On Wed, Apr 03, 2019 at 05:50:26AM -0400, Chris Lamb wrote:
> Hey Cyril & Samuel,
> 
> > > It doesn't build the netinst/CD/DVD iso images indeed (debian-cd handles
> > > that). But it builds the initrd used there (and the netboot mini.iso).
> > 
> > Right. Check the tarball (!) produced by building src:debian-installer;
> > that's what gets installed in installer-$arch directories in the
> > archive; then consumed by debian-cd to produce “full-blown” installation
> > images.
> 
> TIL. However, as these generated files do not appear in the binary
> debian-installer package it is likely that that our testing framework
> will (after the mooted networking exception is made) entirely-
> correctly report that the src:debian-installer package is reproducible
> as its declared artifects contain only documentation. This will be
> somewhat misleading about the true reproducibility status of our installer.

It doesn't contain only documentation.
src:debian-installer also builds a
debian-installer-images_$(VERSION)_$(ARCH).tar.gz that does contain
binary stuff, including the initrd, kernel image, mini.iso, etc etc.

> However, as this would not incorporate anything that debian-cd does
> with them to produce the "full-blown" images I suspect that this will
> not be enough to cover everything. Just to underline this point in a
> silly way we would not be aware of, for example, debian-cd running
> "echo $RANDOM >> /target/ somefile.txt", even with the above hack.

Right, to cover this we would need to do a full build of the cd image.
I have no idea whatsoever how that's done (and, as others said, it's
outside of the debian-boot office, it's within debian-cd).

In the meantime I did what I mentioned,
https://salsa.debian.org/qa/jenkins.debian.net/commit/e3117ca244b230c04e324814e20c02032026a5cf
and the build for unstable/arm64 is running.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#926310: No problem with command line

[Raphaël Plasson]

For more information: I tried with the command line (time nextcloudcmd
--non-interactive -u user -p password -s nextcloud-directory
https://nextcloud-server), the sync takes only a couple of seconds...

The problems seems to come from the GUI, rather than from the sync
framework itself!

Raphaël

Bug#926312: MariaDB couldn't start after fresh install

[Joey Schulze]

Package: mariadb-server-10.1
Version: 10.1.37-0+deb9u1
Architecture: amd64

After a fresh installation of Debian stretch, a following installation
of said package results in an error:

Here's the transcript:

Setting up mariadb-client-10.1 (10.1.37-0+deb9u1) ...
Setting up mariadb-server-10.1 (10.1.37-0+deb9u1) ...
Job for mariadb.service failed because the control process exited with error 
code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
mariadb.service couldn't start.

journalctl -xe says:

Apr 03 11:30:14 Alpha mysqld[6861]: Version: '10.1.37-MariaDB-0+deb9u1'  
socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Debian
Apr 03 11:30:14 Alpha systemd[6888]: mariadb.service: Failed at step EXEC 
spawning /etc/mysql/debian-start: No such file or direct
-- Subject: Process /etc/mysql/debian-start could not be executed


Apparently, said script doesn't seem to be part of this package anymore.

Looking at a different host (with architecture i386 though),
/etc/mysql/debian-start was part of this package once:

$ ls -l /etc/mysql/debian-start
-rwxr-xr-x 1 root root 1509 Jun  7  2017 /etc/mysql/debian-start
$ dpkg -S /etc/mysql/debian-start
mariadb-server-10.1: /etc/mysql/debian-start
$ dpkg -l mariadb-server-10.1
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture   Description
+++-==-==-==-==
ii  mariadb-server-10.110.1.26-0+deb9u1   i386   MariaDB 
database server binaries

I've copied the script from the old packge to the new server and
mariadb was able to start.

Could it be that script got lost somehow?

Regards

Joey

--
Let's call it an accidental feature.  -- Larry Wall

Please always Cc to me when replying to me on the lists.

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Holger Levsen]

Hi,

kudos for the progress so far!

On Wed, Apr 03, 2019 at 05:50:26AM -0400, Chris Lamb wrote:
> Just throwing out ideas here but perhaps this binary package could
> contain at least the hashes of the generated files you mention? 

or we setup debian-cd builds as well..!


-- 
tschau,
Holger

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


signature.asc
Description: PGP signature

Bug#926311: soundscaperenderer-nox: leaves alternatives after upgrade and purge: /usr/bin/ssr-*

[Andreas Beckmann]

Package: soundscaperenderer-nox
Version: 0.5.0~dfsg-3
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-removal-and-or-configuration-purging

The leftover files are actually alternatives that were installed by the
package but have not been properly removed.

While there is ongoing discussion how to remove alternatives correctly
(see https://bugs.debian.org/71621 for details) the following strategy
should work for regular cases:
* 'postinst configure' always installs the alternative
* 'prerm remove' removes the alternative
* 'postrm remove' and 'postrm disappear' remove the alternative
In all other cases a maintainer script is invoked (e.g. upgrade,
deconfigure) the alternatives are not modified to preserve user
configuration.
Removing the alternative in 'prerm remove' avoids having a dangling link
once the actual file gets removed, but 'prerm remove' is not called in
all cases (e.g. unpacked but not configured packages or disappearing
packages) so the postrm must remove the alternative again
(update-alternatives gracefully handles removal of non-existing
alternatives).

Note that the arguments for adding and removing alternatives differ, for
removal it's 'update-alternatives --remove  '.

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

This was observed after an upgrade from stretch to buster.
Obsolete alternatives should be cleaned up in the postinst.

>From the attached log (scroll to the bottom...):

0m45.5s INFO: Warning: Package purging left files on system:
  /etc/alternatives/ssr-aap -> /usr/bin/ssr-aap.nox  not owned
  /etc/alternatives/ssr-aap.1.gz -> /usr/share/man/man1/ssr-aap.nox.1.gz
 not owned
  /etc/alternatives/ssr-binaural -> /usr/bin/ssr-binaural.noxnot owned
  /etc/alternatives/ssr-binaural.1.gz -> 
/usr/share/man/man1/ssr-binaural.nox.1.gz   not owned
  /etc/alternatives/ssr-brs -> /usr/bin/ssr-brs.nox  not owned
  /etc/alternatives/ssr-brs.1.gz -> /usr/share/man/man1/ssr-brs.nox.1.gz
 not owned
  /etc/alternatives/ssr-generic -> /usr/bin/ssr-generic.nox  not owned
  /etc/alternatives/ssr-generic.1.gz -> 
/usr/share/man/man1/ssr-generic.nox.1.gz not owned
  /etc/alternatives/ssr-vbap -> /usr/bin/ssr-vbap.noxnot owned
  /etc/alternatives/ssr-vbap.1.gz -> /usr/share/man/man1/ssr-vbap.nox.1.gz  
 not owned
  /etc/alternatives/ssr-wfs -> /usr/bin/ssr-wfs.nox  not owned
  /etc/alternatives/ssr-wfs.1.gz -> /usr/share/man/man1/ssr-wfs.nox.1.gz
 not owned
  /usr/bin/ssr-aap -> /etc/alternatives/ssr-aap  not owned
  /usr/bin/ssr-binaural -> /etc/alternatives/ssr-binauralnot owned
  /usr/bin/ssr-brs -> /etc/alternatives/ssr-brs  not owned
  /usr/bin/ssr-generic -> /etc/alternatives/ssr-generic  not owned
  /usr/bin/ssr-vbap -> /etc/alternatives/ssr-vbapnot owned
  /usr/bin/ssr-wfs -> /etc/alternatives/ssr-wfs  not owned
  /usr/share/man/man1/ssr-aap.1.gz -> /etc/alternatives/ssr-aap.1.gz not 
owned
  /usr/share/man/man1/ssr-binaural.1.gz -> /etc/alternatives/ssr-binaural.1.gz  
 not owned
  /usr/share/man/man1/ssr-brs.1.gz -> /etc/alternatives/ssr-brs.1.gz not 
owned
  /usr/share/man/man1/ssr-generic.1.gz -> /etc/alternatives/ssr-generic.1.gz
 not owned
  /usr/share/man/man1/ssr-vbap.1.gz -> /etc/alternatives/ssr-vbap.1.gz   not 
owned
  /usr/share/man/man1/ssr-wfs.1.gz -> /etc/alternatives/ssr-wfs.1.gz not 
owned


cheers,

Andreas


soundscaperenderer-nox_0.5.0~dfsg-3.log.gz
Description: application/gzip

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Chris Lamb]

Hey Cyril & Samuel,

> > It doesn't build the netinst/CD/DVD iso images indeed (debian-cd handles
> > that). But it builds the initrd used there (and the netboot mini.iso).
> 
> Right. Check the tarball (!) produced by building src:debian-installer;
> that's what gets installed in installer-$arch directories in the
> archive; then consumed by debian-cd to produce “full-blown” installation
> images.

TIL. However, as these generated files do not appear in the binary
debian-installer package it is likely that that our testing framework
will (after the mooted networking exception is made) entirely-
correctly report that the src:debian-installer package is reproducible
as its declared artifects contain only documentation. This will be
somewhat misleading about the true reproducibility status of our installer.

Just throwing out ideas here but perhaps this binary package could
contain at least the hashes of the generated files you mention? That way,
at least if they vary between our test builds then we will implicitly see
that in the package's reproducibility status.

However, as this would not incorporate anything that debian-cd does
with them to produce the "full-blown" images I suspect that this will
not be enough to cover everything. Just to underline this point in a
silly way we would not be aware of, for example, debian-cd running
"echo $RANDOM >> /target/ somefile.txt", even with the above hack.

Thanks for your input btw. :)


Best wishes,

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

Bug#917423: systemd-sysv: centrally document which "legacy" packages/replaced are replaced by systemd

[Michael Biebl]

Am 03.04.19 um 01:58 schrieb Christoph Anton Mitterer:
> On Wed, 2019-04-03 at 00:15 +0200, Michael Biebl wrote:
>> Feel free to submit additions/corrections/updates to the release-
>> notes,
>> if you think those changes are not satisfactory.
> 
> I think it's good start... one perhaps missing thing:
> 
> I vaguely recall to have read somewhere, that some of the *acpi*
> packages was also considered to be obsoleted/replaced by systemd.
> Was it acpid? But I might be wrong.

https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#idm1558




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



signature.asc
Description: OpenPGP digital signature

Bug#926310: nextcloud-desktop: High CPU Usage for several minutes when sync

[Raphael Plasson]

Package: nextcloud-desktop
Version: 2.5.1-2
Severity: normal

Dear Maintainer,

I switched from the owncloud to the nextcloud client, for synchronizing my data 
with a private nextcloud server (v15.0.5). While the syncronization with the 
owncloud client goes smoothly and is almost instantaneous, it takes several 
minutes with one cpu used at 100%, with a freeze of the nextcloud window until 
completion. This happens at the first syncronization when connecting, but at 
each event (I tried to just add a simple and short textfile on the cloud, the 
nextclooud app freezes for several minutes just for adding it when it is 
detected on the server). Please note that I have several GB of data 
syncronized, if this problem can be related to my case. The syncronization, as 
I said before, goes smoothly with the debian owncloud client, but also with the 
old nextcloud client v2.3.3 from 
http://ppa.launchpad.net/nextcloud-devs/client/ubuntu. As such, the 2.5.1 
version of nextcloud client is practically barely usable.

Thank you,
Raphaël



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

Kernel: Linux 4.19.0-4-amd64 (SMP w/24 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nextcloud-desktop depends on:
ii  libc6 2.28-8
ii  libgcc1   1:8.3.0-4
ii  libnextcloudsync0 2.5.1-2
ii  libqt5concurrent5 5.11.3+dfsg1-1
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5dbus5   5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5keychain1   0.9.1-2
ii  libqt5network55.11.3+dfsg1-1
ii  libqt5positioning55.11.3+dfsg-2
ii  libqt5printsupport5   5.11.3+dfsg1-1
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1
ii  libqt5webchannel5 5.11.3-2
ii  libqt5webenginecore5  5.11.3+dfsg-2+b1
ii  libqt5webenginewidgets5   5.11.3+dfsg-2+b1
ii  libqt5webkit5 5.212.0~alpha2-21
ii  libqt5widgets55.11.3+dfsg1-1
ii  libqt5xml55.11.3+dfsg1-1
ii  libsqlite3-0  3.27.2-2
ii  libssl1.1 1.1.1b-1
ii  libstdc++68.3.0-4
ii  nextcloud-desktop-common  2.5.1-2
ii  nextcloud-desktop-l10n2.5.1-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages nextcloud-desktop recommends:
pn  nextcloud-desktop-doc  

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Cyril Brulebois]

Samuel Thibault  (2019-04-03):
> Hello,
> 
> Chris Lamb, le mer. 03 avril 2019 05:01:44 -0400, a ecrit:
> > > Does the installer need anything special?  I thought d-i was just like
> > > any other package when it came to regular building it.
> > 
> > For some reason I thought that src:debian-installer was a special-case
> > package (or simply used for its build-depends) and it does not
> > "really" build the images.
> 
> It doesn't build the netinst/CD/DVD iso images indeed (debian-cd handles
> that). But it builds the initrd used there (and the netboot mini.iso).

Right. Check the tarball (!) produced by building src:debian-installer;
that's what gets installed in installer-$arch directories in the
archive; then consumed by debian-cd to produce “full-blown” installation
images.

(You might have seen some special casing in dak; that's us!)


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


signature.asc
Description: PGP signature

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Samuel Thibault]

Hello,

Chris Lamb, le mer. 03 avril 2019 05:01:44 -0400, a ecrit:
> > Does the installer need anything special?  I thought d-i was just like
> > any other package when it came to regular building it.
> 
> For some reason I thought that src:debian-installer was a special-case
> package (or simply used for its build-depends) and it does not
> "really" build the images.

It doesn't build the netinst/CD/DVD iso images indeed (debian-cd handles
that). But it builds the initrd used there (and the netboot mini.iso).

Samuel

Bug#926309: gdm3: gdm-x-session calls Xsession with broken arguments

[Matijs van Zuijlen]

Package: gdm3
Version: 3.32.0-1
Severity: normal

Dear maintainer,

Since a couple of weeks, I guess, logging into the GNOME X session from
gdm3 shows a popup with the message:

Xsession: unsupported number of arguments (5); falling back to default 
session.

This message also appears in the logs:

Apr 03 09:26:34 bean /usr/lib/gdm3/gdm-x-session[3709]: /etc/gdm3/Xsession: 
Beginning session setup...
Apr 03 09:26:34 bean /usr/lib/gdm3/gdm-x-session[3709]: 
dbus-update-activation-environment: setting 
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus
Apr 03 09:26:34 bean /usr/lib/gdm3/gdm-x-session[3709]: 
dbus-update-activation-environment: setting DISPLAY=:0
Apr 03 09:26:34 bean /usr/lib/gdm3/gdm-x-session[3709]: 
dbus-update-activation-environment: setting 
XAUTHORITY=/run/user/1001/gdm/Xauthority
Apr 03 09:26:34 bean /usr/lib/gdm3/gdm-x-session[3709]: Xsession: 
unsupported number of arguments (5); falling back to default session.

I have amended the /etc/X11/Xsession.d/20x11-common_process-args script
to also print the passed arguments, and they are:

GDK_BACKEND based on session type

I'm not sure where to look next ...

Kind regards,
Matijs

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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.45-2
ii  adduser   3.118
ii  dconf-cli 0.30.1-2
ii  dconf-gsettings-backend   0.30.1-2
ii  debconf [debconf-2.0] 1.5.71
ii  gir1.2-gdm-1.03.32.0-1
ii  gnome-session [x-session-manager] 3.30.1-2
ii  gnome-session-bin 3.30.1-2
ii  gnome-settings-daemon 3.30.2-3
ii  gnome-shell   3.30.2-3
ii  gnome-terminal [x-terminal-emulator]  3.30.2-2
ii  gsettings-desktop-schemas 3.28.1-1
ii  libaccountsservice0   0.6.45-2
ii  libaudit1 1:2.8.4-2
ii  libc6 2.28-8
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libgdm1   3.32.0-1
ii  libglib2.0-0  2.58.3-1
ii  libglib2.0-bin2.58.3-1
ii  libgtk-3-03.24.5-1
ii  libkeyutils1  1.6-6
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd241-2
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.44.10-1
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-2
ii  libwrap0  7.6.q-28
ii  libx11-6  2:1.6.7-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.13.1-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  10.2019031300
ii  mutter [x-window-manager] 3.30.2-6
ii  openbox [x-window-manager]3.6.1-8
ii  policykit-1   0.105-25
ii  procps2:3.3.15-2
ii  rxvt-unicode [x-terminal-emulator]9.22-6
ii  tilix [x-terminal-emulator]   1.8.9-1
ii  ucf   3.0038+nmu1
ii  x11-common1:7.7+19
ii  x11-xserver-utils 7.7+8
ii  xterm [x-terminal-emulator]   344-1

Versions of packages gdm3 recommends:
ii  at-spi2-core2.30.0-7
ii  desktop-base10.0.0
ii  x11-xkb-utils   7.7+4
ii  xserver-xephyr  2:1.20.4-1
ii  xserver-xorg1:7.7+19
ii  zenity  3.30.0-2

Versions of packages gdm3 suggests:
pn  gnome-orca
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.28.2-5

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
[security]
[xdmcp]
[chooser]
[debug]


-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Chris Lamb]

Hey Mattia et al.,

> Does the installer need anything special?  I thought d-i was just like
> any other package when it came to regular building it.

For some reason I thought that src:debian-installer was a special-case
package (or simply used for its build-depends) and it does not
"really" build the images. Obviously, I hope you are absolutely right
and this is much easier than I thought to resolve.

(I think I got some of this preconception from various README files
which imply one should build via the Makefile, not via building
src:debian-installer.)

Thinking about it, a d-i *release* might trigger or other go through
some other codepaths — perhaps even manual ones — that might lead to
an unreproducible package.. and thus we would definitely want to
exercise these.

> If d-i is like I assume it be, there should a regular buildinfo as well,
> see https://buildinfo.debian.net/sources/debian-installer for what I
> mean.

Nod. However, we would need to double check that the src:debian-
installer .buildinfo includes or otherwise takes into consideration:

 a) The actual generated ISOs/.img/netboot images etc. and not just
the binary packages as usual. (I mean we only really care about
the former here, right?)

 b) Any sources downloaded directly from the archive.

As above, perhaps there is some kind of "release" codepath we need to
definitely and specifically test too? -boot can you chime in here on
this angle?

> So the reason src:debian-installer does not build at this moment [..]

For completeness (and/or people following along):

  http://tests.reproducible-builds.org/debian-installer

… specifically:

  make[2]: Entering directory '/build/1st/debian-installer-20190118/build'
  WARNING: mirror 'http://deb.debian.org/debian' appears to be invalid; skipping
  WARNING: mirror 'http://deb.debian.org/debian' appears to be invalid; skipping
  […]
  Building dependency tree...
  E: Unable to locate package acpi-modules-4.19.0-1-amd64-di
  E: Couldn't find any package by glob 'acpi-modules-4.19.0-1-amd64-di'
  E: Couldn't find any package by regex 'acpi-modules-4.19.0-1-amd64-di'
  […]

> One way to workaround this problem of src:debian-installer, would be for
> our building script to instruct pbuilder to not block the network when
> it's building this special package.

I think that's fine, especially if we add this to the log and that
it's well-commented as a magic exception. You happy to go-ahead with
this?


Best wishes,

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

Bug#926305: nis startup scripts are completely broken

[Elimar Riesebieter]

* Anton Ivanov  [2019-04-03 09:43 +0100]:

> Package: nis
> Version: 3.17.1-3+b1
> Severity: critical
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
> Startup scripts are completely broken. Something in the systemd 
> conversion/autogeneration.
> 
> The ypbind binary is never started, the script goes into "backgrounded" and 
> fails. From there
> on the system is unusable - you cannot log in, UIDs and groups do not 
> resolve, etc.
> 
> The same system operated correctly before buster upgrade and will operate 
> correctly if
> ypbind is invoked from the command line.
> 
> This looks like a pure systemd conversion issue of some sort.

At my systems installing nscd helped. As well setting "YPBINDARGS="
in /etc/default/nis must be.

Elimar
-- 
  Learned men are the cisterns of knowledge,
  not the fountainheads ;-)

Bug#926308: python3-karborclient: fails to install: update-alternatives: error: alternative path /usr/bin/python3-karbor doesn't exist

[Andreas Beckmann]

Package: python3-karborclient
Version: 1.2.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up python3-karborclient (1.2.0-1) ...
  update-alternatives: error: alternative path /usr/bin/python3-karbor doesn't 
exist
  dpkg: error processing package python3-karborclient (--configure):
   installed python3-karborclient package post-installation script subprocess 
returned error exit status 2
  Processing triggers for ca-certificates (20190110) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   python3-karborclient


cheers,

Andreas


python3-karborclient_1.2.0-1.log.gz
Description: application/gzip

Bug#926307: zvmcloudconnector-api,python3-zvmcloudconnector: both ship /lib/systemd/system/sdkserver.service

[Andreas Beckmann]

Package: zvmcloudconnector-api,python3-zvmcloudconnector
Version: 1.4.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package python3-zvmcloudconnector.
  Preparing to unpack .../21-python3-zvmcloudconnector_1.4.0-2_all.deb ...
  Unpacking python3-zvmcloudconnector (1.4.0-2) ...
  Selecting previously unselected package zvmcloudconnector-api.
  Preparing to unpack .../22-zvmcloudconnector-api_1.4.0-2_all.deb ...
  Unpacking zvmcloudconnector-api (1.4.0-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-Pi8YLa/22-zvmcloudconnector-api_1.4.0-2_all.deb 
(--unpack):
   trying to overwrite '/lib/systemd/system/sdkserver.service', which is also 
in package python3-zvmcloudconnector 1.4.0-2
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-Pi8YLa/22-zvmcloudconnector-api_1.4.0-2_all.deb


cheers,

Andreas


zvmcloudconnector-api_1.4.0-2.log.gz
Description: application/gzip

Bug#924119: Please fix this issue

[Xavier]

Hello,

this bug seems easy to fix and will remove docker.io from Buster. Please
fix it ;-)

Cheers,
Xavier

Bug#926306: RFS: socklog/2.1.0-9

[Mathieu Mirmont]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "socklog"

* Package name: socklog
  Version : 2.1.0-9
  Upstream Author : Gerrit Pape 
* URL : http://smarden.org/socklog
* License : BSD
  Section : admin

It builds those binary packages:

socklog - system and kernel logging services (programs)
socklog-run - system and kernel logging services

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/socklog/socklog_2.1.0-9.dsc

Changes since the last upload:

  * Convert the package to debhelper (Closes: #857208)
  * patches: Import previous patches
  * patch: remove the chkshsgr test
  * watch: add the uscan watch file
  * socklog-run: migrate to dh-runit (Closes: #668718, #834089)
  * gitlab-ci.yml: add GitLab CI file
  * control: update the Vcs fields
  * doc-base: register the html documentation
  * lintian: add overrides

Cheers,

-- 
Mathieu Mirmont 


signature.asc
Description: PGP signature

Bug#925035: put kzonecheck into knot-dnsutils?

[Arsen STASIC]

Hi,

I support this too!

Bind packages have the same setup, which makes more sense to me.
Package bind9 contains nameserver.
Package bind9utils contains mutiple tools.

I use bind for DNSSEC signing and I would like to check the signed zone 
with a different software (but I don't need knot running as a service)


dpkg -L bind9utils |grep dnssec-verify$
/usr/sbin/dnssec-verify

dpkg -L knot |grep kzonecheck$ 
/usr/bin/kzonecheck


cheers,
-arsen

On Tue, 19 Mar 2019 15:10:38 +0100 Daniel Baumann 
 wrote:

Package: knot
Severity: wishlist

Hi,

I'm maintaining zone files in a git repository, which are then via ssh
trigger deployed to the knot master, which is a fairly convenient setup.

Now, in order to not accept syntax errors in zone files on the git
server in the first place (and thus both avoiding automatic deployment
to the knot server and have the "faulty" git commits not make it in the
repository at all).. it would be very nice if the kzonecheck utility
could be moved from knot to knot-dnsutils.

Currently, I would need to install knot on the git server just to get
kzonecheck which is not really a good idea.

Regards,
Daniel

Bug#926305: nis startup scripts are completely broken

[Anton Ivanov]

Package: nis
Version: 3.17.1-3+b1
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

Startup scripts are completely broken. Something in the systemd 
conversion/autogeneration.

The ypbind binary is never started, the script goes into "backgrounded" and 
fails. From there
on the system is unusable - you cannot log in, UIDs and groups do not resolve, 
etc.

The same system operated correctly before buster upgrade and will operate 
correctly if
ypbind is invoked from the command line.

This looks like a pure systemd conversion issue of some sort.

-- Package-specific info:

NIS domain: home 

-- 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/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nis depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  hostname   3.21
ii  libc6  2.28-8
ii  libgdbm6   1.18.1-4
ii  libsystemd0241-1
ii  lsb-base   10.2019031300
ii  make   4.2.1-1.2
ii  netbase5.6
ii  rpcbind [portmap]  1.2.5-0.3

nis recommends no packages.

Versions of packages nis suggests:
pn  nscd  

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

-- debconf information:
* nis/domain: home

Bug#926295: RFS: minder/1.1.3-1 [ITP]

[Mo Zhou]

control: tag -1 +moreinfo

Hi Yangfl,

Thank you for your debianization work.  I'm quite interested in such a
non-java mind mapper, as an alternative the freeplane. Well, despite of
the werid binary executable name:

  drwxr-xr-x root/root 0 2019-03-26 13:57 ./usr/bin/
  -rwxr-xr-x root/root534736 2019-03-26 13:57 
./usr/bin/com.github.phase1geo.minder
  drwxr-xr-x root/root 0 2019-03-26 13:57 ./usr/share/
  drwxr-xr-x root/root 0 2019-03-26 13:57 ./usr/share/applications/
  -rw-r--r-- root/root   591 2018-10-26 02:46 
./usr/share/applications/com.github.phase1geo.minder.desktop

However I ended up with illegal memory access after playing it for a minute:
> fish: “com.github.phase1geo.minder” terminated by signal SIGSEGV (Address 
> boundary error)

Not mature enough.

On Wed, Apr 03, 2019 at 11:13:20AM +0800, Yangfl wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "minder"
> 
> * Package name: minder
>   Version : 1.1.3-1
>   Upstream Author : Trevor Williams 
> * URL : https://github.com/phase1geo/Minder
> * License : GPL v3
>   Section : x11
> 
> It builds those binary packages:
> 
>   minder - Mind-mapping application
> 
> To access further information about this package, please visit the
> following URL:
> 
> https://mentors.debian.net/package/minder
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/m/minder/minder_1.1.3-1.dsc
> 
> More information about minder can be obtained from https://www.example.com.
> 
> Changes since the last upload:
> 
> [your most recent changelog entry]
> 
> 
> Regards,
>  Yangfl
> 

Bug#926218: range-v3: FTBFS with gcc 8.3

[Santiago Vila]

On Tue, Apr 02, 2019 at 10:57:39PM +0300, Коля Гурьев wrote:
> Control: forwarded -1 https://github.com/ericniebler/range-v3/issues/856

Hi. I believe this one (failure with GCC 9) could be a bit closer:

https://github.com/ericniebler/range-v3/issues/1033

Thanks.

Bug#926304: freecad: autopkgtest regression

[Graham Inggs]

Source: freecad
Version: 0.18+dfsg1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of 0.18+dfsg1-1, freecad has been failing its own 
autopkgtests [1] with the following error:


TestFem (unittest.loader._FailedTest) ... ERROR

Regards
Graham


[1] https://ci.debian.net/packages/f/freecad/unstable/amd64/

Bug#891294: plasma-discover: Discover->settings->software sources does nothing

[Laura Arjona Reina]

Package: plasma-discover
Version: 5.14.5.1-1
Followup-For: Bug #891294

Hello
I can reproduce this bug in version 5.14.5.1-1 (current buster).

I have launched plasma-discover from console so I can get some output in the
terminal, here it is:

---
larjona@larjona-pc:~$ LC_ALL="C" plasma-discover &
[3] 1906
larjona@larjona-pc:~$ adding empty sources model
QStandardItemModel(0x55d434b7b7b0)
no packages for "org.kde.plasma.activitybar"
no packages for "org.kde.plasma.systemloadviewer"
no packages for "io.devdocs.webapp"
no packages for "org.kde.plasma.showActivityManager"
no packages for "org.kde.plasma.grouping"
no packages for "org.kde.plasma.binaryclock"
no packages for "org.kde.plasma.diskquota"
no packages for "org.kde.kscreen"
no packages for "libgphoto2"
no packages for "libu2f-udev"
no packages for "org.debian.debian"
no packages for "org.kde.plasma.kimpanel"
no packages for "org.kde.konqueror.desktop"
no packages for "org.kde.plasma.timer"
no packages for "im.riot.webapp"
no packages for "org.kde.plasma.appmenu"
no packages for "org.kde.plasma.quicklaunch"
invalid kns backend! "/etc/xdg/ksysguard.knsrc" because: "Config group not
found! Check your KNS3 installation."
invalid kns backend! "/etc/xdg/servicemenu.knsrc" because: "Config group not
found! Check your KNS3 installation."
could not find "inkscape.desktop" ""
could not find "org.kde.development" ""
could not find "inkscape.desktop" ""
could not find "org.kde.development" ""
could not find "inkscape.desktop" ""
could not find "org.kde.development" ""
could not find "inkscape.desktop" ""
could not find "org.kde.development" ""
qrc:/qml/SourcesPage.qml:30:27: QML AbstractListItem: Binding loop detected for
property "implicitHeight"
file:///usr/lib/x86_64-linux-
gnu/qt5/qml/QtQuick/Controls.2/org.kde.desktop/ToolTip.qml:45: TypeError:
Cannot read property 'hovered' of null
org.kde.kdesu: Daemon not safe (not sgid), not using it.

PackageKit stopped running!


When I force-close the dialog asking for password and/or plasma-discover, I
don't get any other message in the console.

Kind regards,

Laura Arjona Reina
https://wiki.debian.org/LauraArjona



-- 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=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-discover depends on:
ii  appstream0.12.5-1
ii  apt-config-icons 0.12.5-1
ii  kio  5.54.1-1
ii  libappstreamqt2  0.12.5-1
ii  libc62.28-8
ii  libkf5attica55.54.0-1
ii  libkf5configcore55.54.0-1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5itemmodels55.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5newstuffcore5  5.54.0-2
ii  libkf5notifications5 5.54.0-1
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libpackagekitqt5-1   1.0.1-1
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  libqt5qml5   5.11.3-4
ii  libqt5quick5 5.11.3-4
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libqt5xml5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-4
ii  packagekit   1.1.12-5
ii  plasma-discover-common   5.14.5.1-1
ii  qml-module-org-kde-kcoreaddons   5.54.0-1
ii  qml-module-org-kde-kirigami2 5.54.0-1
ii  qml-module-org-kde-kquickcontrols5.54.0-1
ii  qml-module-org-kde-kquickcontrolsaddons  5.54.0-1
ii  qml-module-org-kde-qqc2desktopstyle  5.54.0-1
ii  qml-module-qtquick-dialogs   5.11.3-2

Versions of packages plasma-discover recommends:
ii  apt-config-icons-large   0.12.5-1
ii  software-properties-kde  0.96.20.2-1

Versions of packages plasma-discover suggests:
pn  apt-config-icons-hidpi   
pn  plasma-discover-backend-flatpak  

-- no debconf information

Bug#926218: range-v3: FTBFS with gcc 8.3

[Santiago Vila]

On Tue, Apr 02, 2019 at 10:57:39PM +0300, Коля Гурьев wrote:

> Thank you for the report! Which hardware architecture do you use to
> build the package?

I'm using amd64, nothing special. Are you sure this problem is the
same as the one in the "forwarded" issue in github? In case it helps,
I've triggered rebuilds everywhere here:

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

Thanks.

Bug#921559:

[Dylan Aïssi]

Control: severity -1 important

Hi,

I tried to reproduce this problem with an up-to-date (2019-04-01) live Buster.
And I was not able to reproduce this problem with all my Android
devices (Nexus 5, Nexus 7, Galaxy S3, Galaxy J5 2018 and Galaxy Tab A
2018). So, I reduce the severity of this bug for the moment.

Best,
Dylan

Bug#926303: release.debian.org: Upgrade strategy for apache2 in Buster

[Xavier Guimard]

Package: release.debian.org
Severity: normal

Hi all,

New Apache 2.4.39 fixes many bugs (including 5 CVEs [1]) with only 2
minor new features. Do you think it is a good idea to upgrade Apache
version in Buster or do you prefer a 2.4.38 with 2.4.39 fixes (means
2.4.39 without ~2 commits) or only CVEs fixes ? I'll wait for your
response before uploading to unstable.

Cheers,
Xavier

[1]: http://www.apache.org/dist/httpd/CHANGES_2.4.39

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

Bug#923882: [Pkg-sssd-devel] Bug#923882: Bug#923882: Bug#923882: sssd-tools: sssctl list-domains is broken

[Timo Aaltonen]

On 21.3.2019 16.23, Timo Aaltonen wrote:
> On 21.3.2019 16.02, Jan Luca Naumann wrote:
>> Another way could be to check in the postinst files if there is already
>> an existing sssd.conf file and, if yes, do not enable the systemd units.
>>
>> This should prevent breaking existing installations but would allow to
>> use the services after adjusting sssd.conf and new users would use the
>> sockets directly. Admins of existing installations could be informed
>> about this change via the NEWS file.
>>
>> Would that be a useful solution?
> 
> No I think that would be very confusing :)
> 
> I've pushed a new upstream plus added socket activation back (though the
> changelog doesn't mention it) here:
> 
> https://aaltoset.kapsi.fi/sssd
> 
> if you can test that it'd be great

I tested it myself and works fine, this is now pushed to experimental so
it should be easier to test.

I'm hoping this would be fine for buster too.


-- 
t

Bug#916641: jaxb: leaves alternatives after purge: /usr/bin/{schemagen, xjc}

[Emmanuel Bourg]

Le 03/04/2019 à 01:04, Andreas Beckmann a écrit :

> I've now uploaded this as a NMU to DELAYED/5.

Hi Andreas,

Thank you for the patch. I'm going to merge and upload it.

Emmanuel Bourg

Bug#926118: unblock: libmspack/0.10.1-1

[duck]

Quack,

Thanks Jens for warning me, I did not receive the notification.

I already asked for an unblock, explaining the situation (like why it 
was blocked out of testing, why the recent fixes…), but it was rejected 
without any comment on my rational:

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

I'm not convinced backporting a bunch of patches on top of 0.8-1 
(important and security fixes), which would end-up creating an untested 
version would be a safe solution. 0.9.1-1 and now 0.10.1-1 have been 
around for some time without problem.
So I hope the release team will change their mind, or suggest a 
solution.


\_o<

--
Marc Dequènes

Bug#926302: unblock: ciftilib/1.5.3-2

[Andreas Tille]

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

Please unblock package ciftilib


diff -Nru ciftilib-1.5.3/debian/changelog ciftilib-1.5.3/debian/changelog
--- ciftilib-1.5.3/debian/changelog 2019-01-30 10:15:35.0 +0100
+++ ciftilib-1.5.3/debian/changelog 2019-04-02 21:49:25.0 +0200
@@ -1,3 +1,11 @@
+ciftilib (1.5.3-2) unstable; urgency=medium
+
+  * gbp.conf: drop pq settings
+  * Cherry-pick upstream fix for FTBFS on big endian.
+Thanks to Adrian Bunk for reporting (Closes: #921555)
+
+ -- Ghislain Antony Vaillant   Tue, 02 Apr 2019 21:49:25 
+0200
+
 ciftilib (1.5.3-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru ciftilib-1.5.3/debian/gbp.conf ciftilib-1.5.3/debian/gbp.conf
--- ciftilib-1.5.3/debian/gbp.conf  2019-01-30 10:15:35.0 +0100
+++ ciftilib-1.5.3/debian/gbp.conf  2019-04-02 21:49:25.0 +0200
@@ -4,6 +4,3 @@
 upstream-tag = upstream/%(version)s
 debian-tag = debian/%(version)s
 pristine-tar = True
-
-[pq]
-patch-numbers = False
diff -Nru 
ciftilib-1.5.3/debian/patches/0001-force-endian-of-datatype-example-to-make-tests-pass-.patch
 
ciftilib-1.5.3/debian/patches/0001-force-endian-of-datatype-example-to-make-tests-pass-.patch
--- 
ciftilib-1.5.3/debian/patches/0001-force-endian-of-datatype-example-to-make-tests-pass-.patch
   1970-01-01 01:00:00.0 +0100
+++ 
ciftilib-1.5.3/debian/patches/0001-force-endian-of-datatype-example-to-make-tests-pass-.patch
   2019-04-02 21:49:25.0 +0200
@@ -0,0 +1,30 @@
+From: Tim Coalson 
+Date: Mon, 1 Apr 2019 16:56:12 -0500
+Subject: force endian of datatype example to make tests pass on bigendian
+ systems
+
+---
+ example/datatype.cxx | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/example/datatype.cxx b/example/datatype.cxx
+index a293856..1da380b 100644
+--- a/example/datatype.cxx
 b/example/datatype.cxx
+@@ -19,14 +19,14 @@ int main(int argc, char** argv)
+ if (argc < 3)
+ {
+ cout << "usage: " << argv[0] << "  " << 
endl;
+-cout << "  rewrite the input cifti file to the output filename, using 
uint8 and data scaling." << endl;
++cout << "  rewrite the input cifti file to the output filename, using 
uint8 and data scaling, little-endian." << endl;
+ return 1;
+ }
+ try
+ {
+ CiftiFile inputFile(argv[1]);//on-disk reading by default
+ inputFile.setWritingDataTypeAndScaling(NIFTI_TYPE_UINT8, -1.0, 
6.0);//tells it to use this datatype to best represent this specified range of 
values [-1.0, 6.0] whenever this instance is written
+-inputFile.writeFile(argv[2]);//if this is the same filename as the 
input, CiftiFile actually detects this and reads the input into memory first
++inputFile.writeFile(argv[2], CiftiVersion(), CiftiFile::LITTLE);//if 
this is the same filename as the input, CiftiFile actually detects this and 
reads the input into memory first
+ //otherwise, it will read and write one row at a time, using very 
little memory
+ //inputFile.setWritingDataTypeNoScaling(NIFTI_TYPE_FLOAT32);//this is 
how you would revert back to writing as float32 without rescaling
+ } catch (CiftiException& e) {
diff -Nru ciftilib-1.5.3/debian/patches/series 
ciftilib-1.5.3/debian/patches/series
--- ciftilib-1.5.3/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ ciftilib-1.5.3/debian/patches/series2019-04-02 21:49:25.0 
+0200
@@ -0,0 +1 @@
+0001-force-endian-of-datatype-example-to-make-tests-pass-.patch


unblock ciftilib/1.5.3-2

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

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

Bug#925972: src:groonga: Non-working maintainer address

[Kentaro Hayashi]

> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
> 
>   packa...@groonga.org
> host aspmx.l.google.com [2a00:1450:400c:c0c::1a]
> SMTP error from remote mail server after RCPT TO::
> 550-5.1.1 The email account that you tried to reach does not exist. 
> Please try
> 550-5.1.1 double-checking the recipient's email address for typos or
> 550-5.1.1 unnecessary spaces. Learn more at
> 550 5.1.1  https://support.google.com/mail/?p=NoSuchUser 
> p16si1506256wre.147 - gsmtp

This is caused by recent mail service migration for groonga.org.
The issue has fixed now.

Bug#926299: unblock: busybox/1:1.30.1-4

[Cyril Brulebois]

Hi Niels,

Niels Thykier  (2019-04-03):
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> (X-CC'ed kibi + debian-boot).
> 
> Hi kibi/d-i,
> 
> The recent upload of busybox fixes the bug #925979 in busybox-udeb.
> 
> Should we (RT) unblock it now or do you prefer waiting (as I
> understand it there is d-i release coming up).
> 
> unblock busybox/1:1.30.1-4

If you see a package that gets uploaded with a patch of mine for a bug
report I opened, mentioning I'd like to see it fixed before the next d-i
release, you can assume it's on my radar already and it doesn't need to
go through an individual unblock request.

See also:
  https://lists.debian.org/debian-release/2019/04/msg00014.html


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


signature.asc
Description: PGP signature