Bug#907500: Further details on seccomp enablement

[Christian Ehrhardt]

In my former mail I outlined when the feature was "available and built in".
But used by default it was only much later.

IIRC qemu 2.11 (1bd6152a) switched from a huge whitelist to a blacklist and
being filtering by default.

Furthermore since lbvirt 4.3 (3527f9dd) libvirt will enable more of the
modular blacklists by default if >=qemu 2.11 is detected.

But even being default off people could switch it on all the time per
command-line or via lbivirt per seccomp_sandbox= in /etc/libvirt/qemu.conf



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#907530: dicoweb: Problems after dicoweb installation

[Ahmed El-Mahmoudy]

Package: dicoweb
Version: 2.3-2
Severity: important

Reporting on behalf of  Власенко Михаил Викторович 

> I did a dicoweb installation on a VDS with Debian 9.
> Python Version:  2.7.13
> Django Version:  1.10.7
> The web address for this machine is: https://dict.bible.ru/
> Connect to the web site and look at the debugger log, I can not
> understand on my own what's wrong. 
> Maybe it's some kind of bug in dicoweb? I am confused by the fact
> that the file /usr/share/dicoweb/dicoweb.wsgi is missing. I copied
> it from the old version.
> 
> I zip a copy of the debugger log located in the DicowebLog.html
> file and send as an attachment. 
> Regards.
> 
> ... Michael

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


debuglog.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#907500: Seccomp enabled much earlier

[Christian Ehrhardt]

Hi,
quote:
"seccomp support is enabled for the Debian builds only starting from
1:2.12+dfsg-2, issue would be present already before source-wise, but going
to mark the issue as no-dsa for older versions"

IMHO I'd think it is enabled since 1.3.0+dfsg-2exp quite a while back.
The latter changes are sometimes enabling additional architectures, but
"enabled" and thereby potentially affected it was way more back in time.

Picking a random build log in unstable of 2014 [1] has --enable-seccomp as
well as later on the proper detection on the configure run
  seccomp support   yes

[1]:
https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=2.0.0%2Bdfsg-6%2Bb1=1402079442=0

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#907518: New libssl1.1 1.1.1~~pre9-1 in unstable breaks connecting to some wifi networks

[mkhpalm]

Same for me, 

Doesn't work with any of the EAP methods I've tried with WPA
Enterprise.

wpa_supplicant[702]: wlp1s0: CTRL-EVENT-EAP-STARTED EAP authentication
started
wpa_supplicant[702]: wlp1s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0
method=4 -> NAK
wpa_supplicant[702]: wlp1s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0
method=21
wpa_supplicant[702]: wlp1s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method
21 (TTLS) selected
wpa_supplicant[702]: SSL: SSL3 alert: write (local SSL3 detected an
error):fatal:protocol version
wpa_supplicant[702]: OpenSSL: openssl_handshake - SSL_connect
error:1425F18C:SSL routines:ssl_choose_client_version:version too low
wpa_supplicant[702]: wlp1s0: CTRL-EVENT-EAP-FAILURE EAP authentication
failed

Rolling back libssl1.1 to 1.1.0h-4 solves the problem for me.

On Tue, 28 Aug 2018 16:27:59 -0700 Josh Triplett  wrote:
> Package: wpasupplicant
> Version: 2:2.6-18
> Severity: important
> 
> With libssl1.1 1.1.1~~pre9-1, which more aggressively deprecates
smaller
> key sizes by default, I can no longer connect to my office wifi
network:
> 
> wpa_supplicant[523]: OpenSSL: pending error: error:0D07803A:asn1
encoding routines:asn1_item_embed_d2i:nested asn1 error
> wpa_supplicant[523]: OpenSSL: pending error: error:140C800D:SSL
routines:SSL_use_certificate_file:ASN1 lib
> wpa_supplicant[523]: OpenSSL: pending error: error:140C618E:SSL
routines:SSL_use_certificate:ca md too weak
> wpa_supplicant[523]: TLS: Failed to set TLS connection parameters
> wpa_supplicant[523]: EAP-TLS: Failed to initialize SSL.
> wpa_supplicant[523]: wlp4s0: EAP: Failed to initialize EAP method:
vendor 0 method 13 (TLS)
> 
> Downgrading libssl1.1 to 1.1.0h-4 allows me to connect again. Please
> adjust the defaults that wpasupplicant initializes OpenSSL with to
> continue to allow connecting to such networks.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8),
LANGUAGE=C.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages wpasupplicant depends on:
> ii  adduser   3.117
> ii  libc6 2.27-5
> ii  libdbus-1-3   1.12.10-1
> ii  libnl-3-200   3.4.0-1
> ii  libnl-genl-3-200  3.4.0-1
> ii  libpcsclite1  1.8.23-3
> ii  libreadline7  7.0-5
> ii  libssl1.1 1.1.1~~pre9-1
> ii  lsb-base  9.20170808
> 
> wpasupplicant recommends no packages.
> 
> Versions of packages wpasupplicant suggests:
> pn  libengine-pkcs11-openssl  
> pn  wpagui
> 
> -- no debconf information
> 
> 

Bug#907529: emacs-gtk: update to fonts-noto-cjk forces change of font family

[Norbert Preining]

Package: emacs-gtk
Version: 1:25.2+1-11
Severity: normal

Hi,

this is a bug report towards emacs, but the origin of the problem is in
the change of fonts-noto-cjk #907048, thus I include the bug email and
debian-fonts ML in the DebbugsCC.

It seems that with the update of fonts-noto-cjk suddenly my font
configuration in emacs is overriden and Noto CJK is used automatically.

I have removed all of my .emacs/, started a new emacs session,
configured and saved the default font to
Source Code Pro
which gives me a .emacs file as follows (comments removed):
(package-initialize)
(custom-set-variables)
(custom-set-faces
 '(default ((t (:family "Source Code Pro" :foundry "ADBO" :slant normal 
:weight normal :height 136 :width normal)

After configuration the font changes correctly.

Then I close Emacs (quit).

On next restart the following happens:
- Emacs windows open
- switches to Source Code Pro/14
- and an instant later switches again Noto Sans Mono CJK JP
which I can check by going into
Customize Face: default

The change in fonts-noto-cjk is that
/etc/fonts/conf.d/70-fonts-noto-cjk.conf is added, and there the
following code is contained:
   

ja


monospace


Noto Sans Mono CJK JP



It is surprising that this font is selected. It is true that I live in
Japan, but as you can see below I have all locales set up to en_US:
$ locale
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
$

I don't know who to blame, and even less, I don't know how to override
this, since I don't want Noto as default font.

I can only guess that one of the emacs packages installed does something
here. I have added --debug-init and got the following list of packages
Loading /etc/emacs/site-start.d/00debian.el (source)...done
Loading /etc/emacs/site-start.d/00debian-vars.el (source)...done
Loading /etc/emacs/site-start.d/50asymptote.el (source)...done
Loading /etc/emacs/site-start.d/50autoconf.el (source)...done
Loading /etc/emacs/site-start.d/50cafeobj-mode.el (source)...done
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Loading debian-ispell...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50emacs-mozc.el (source)...done
Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...
Loading /usr/share/emacs/site-lisp/latex-cjk-common/cjk-enc.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...done
Loading /etc/emacs/site-start.d/50maxima-emacs.el (source)...done
Loading /etc/emacs/site-start.d/50mu4e.el (source)...done
Loading /etc/emacs/site-start.d/50namazu2.el (source)...done
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...done
Loading /etc/emacs/site-start.d/50scala-mode-el.el (source)...
Loading /usr/share/emacs/site-lisp/scala-mode/scala-mode-auto.el (source)...done
Loading /etc/emacs/site-start.d/50scala-mode-el.el (source)...done
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...done


My questions are:
- who is loading/overriding this font, and why/how?
- how can I define the default font for emacs that it is not overriden
  by Noto?

Thanks

Norbert

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

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common   1:25.2+1-11
ii  emacs-common   1:25.2+1-11
ii  libacl12.2.52-3+b1
ii  libasound2 1.1.6-1
ii  libatk1.0-02.28.1-1
ii  libc6  2.27-5
ii  libcairo-gobject2  1.15.12-1
ii  libcairo2  1.15.12-1
ii  libdbus-1-31.12.10-1
ii  libfontconfig1 2.13.0-5
ii  libfreetype6   2.8.1-2
ii  libgdk-pixbuf2.0-0 2.36.12-2
ii  libgif75.1.4-3
ii  libglib2.0-0   2.56.1-2
ii  libgnutls303.5.19-1
ii  libgomp1   

Bug#905411: New list creation: debian-fundraising

[Louis-Philippe Véronneau]

Hi!

Any news regarding the creation of this ML?

I know you said 'This has to be discussed within the team.', but it's
been a month and it's hard to go forward with this project if we don't
have a platform to discuss on...

Is the answer to our request of a closed ML from listmasters is a strait
'No'?

If that is the only blocker for the creation of that mailing list, I
guess we can work on an open ML for now. I don't think we'll be dealing
with sponsors directly for the next year anyway.

Cheers,

-- 
  ,''`.
 : :'  : Louis-Philippe Véronneau
 `. `'`  po...@debian.org / veronneau.org
   `-

On Sat, 4 Aug 2018 18:53:10 +0200 Alexander Wirt 
wrote:
> On Sat, 04 Aug 2018, Louis-Philippe Véronneau wrote:
> 
> > On 2018-08-04 18:58, Alexander Wirt wrote:
> > >> Subscription Policy: closed, manual approval. We don't want random
> > >> people to subscribe to this ML. This list will eventually be used to
> > >> talk about confidential discussions we've had with sponsors.
> > > in general I can say that we had bad experiences with such closes lists 
> > > and
> > > that we don't want them. This has to be discussed within the team. I also
> > > think debian should be more transparent. 
> > 
> > By 'random', I meant people not part of the Debian project. Bad choice
> > of language on my end, sorry.
> users are also part of the project. 
> 
> > 
> > Is there a way to make the subscription only available to DDs/DMs? I
> > wouldn't mind that.
> No, we don't have such a mechanism.
> 
> Alex
> > 
> > -- 
> >   ,''`.
> >  : :'  : Louis-Philippe Véronneau
> >  `. `'`  po...@debian.org / veronneau.org
> >`-
> > 
> 
> 
> 




signature.asc
Description: OpenPGP digital signature

Bug#907449: liblzma: undefinited reference when link with lzma static library

[Jonathan Nieder]

severity 907449 important
quit

Hi,

Antonio wrote:

> in a program I tested the lzma library for compress with multithread
> function lzma_stream_encoder_mt, with the following results:
>
> - if I link with dynamic library everything is fine
> - if I link with static library, are returned these compilation errors:
>
> g++  -Itr1 -Wl,-Bstatic -lblkid -luuid -lstdc++ -llzma -Wl,-Bdynamic
> -no-pie -lpthread -O3 -flto -Wall -mindirect-branch=thunk -std=c++11
> /usr/bin/ld: /tmp/user/0/ccGxpWk6.ltrans3.ltrans.o: in function ...:
> :(.text+0x2089): undefined reference to `lzma_cputhreads'
> /usr/bin/ld: :(.text+0x20a8): undefined reference to
> `lzma_stream_encoder_mt' collect2: error: ld returned 1 exit status

Thanks for reporting.  I should be able to look into this this weekend.

Sincerely,
Jonathan

Bug#906623: heimdal: FTBFS in buster/sid (hcrypto/engine.h: No such file or directory)

[Brian May]

Santiago Vila  writes:

> make[3]: Entering directory '/<>/heimdal-7.5.0+dfsg/lib/hcrypto'
>   CC   test_rand.o
> In file included from test_rand.c:42:
> rand.h:46:10: fatal error: hcrypto/engine.h: No such file or directory
>  #include 
>   ^~
> compilation terminated.
> make[3]: *** [Makefile:2060: test_rand.o] Error 1
> make[3]: Leaving directory '/<>/heimdal-7.5.0+dfsg/lib/hcrypto'
> make[2]: *** [Makefile:565: all-recursive] Error 1
> make[2]: Leaving directory '/<>/heimdal-7.5.0+dfsg/lib'
> make[1]: *** [Makefile:613: all-recursive] Error 1
> make[1]: Leaving directory '/<>/heimdal-7.5.0+dfsg'
> dh_auto_build: make -j1 returned exit code 2
> make: *** [debian/rules:7: build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> status 2
> 

I simply cannot reproduce this error.

Are you sure you didn't accidentally delete the supplied
./lib/hcrypto/engine.h file?

Regards
-- 
Brian May 

Bug#907528: synergy: low grade TLS certificate generation, now unusable in unstable

[duck]

Package: synergy
Version: 1.8.8-stable+dfsg.1-1.1
Severity: grave
Tags: security


Quack,

With recent openssl upgrade (1.1.0h-4 -> 1.1.1~~pre9-1) the client fails 
to connect with error routines:SSL_CTX_use_certificate:ee key too small.


The following script is used to generate the key: 
/usr/share/synergy/gen_ssl_pem.sh
This script creates a 1024 bits RSA key, which is too small to be 
secure.

This means it is security issue in all Debian suites.

Regards.

--
Marc Dequènes

Bug#901705: new upstream version 0.90.1

[Михаил Новоселов]

Hello, I have build calf 0.90.1 for Ubuntu in 
ppa:mikhailnov/pulseeffects 
https://launchpad.net/~mikhailnov/+archive/ubuntu/pulseeffects/+packages


I enabled SSE only for x86 targets, and now the package is buildable on 
all architectures, in the PPA it has been built for


amd64
arm64
armhf
i386
ppc64el
s390x

Maybe it fill be useful

Packaging is here: 
https://gitlab.com/nixtux-packaging/calf-ubuntu/blob/master/calf-0.90.1/debian/rules 

Bug#849258: Lerna is unlikely to pass license review

[Jeff Epler]

Lerna has added restrictions to its former MIT license.  I think these
restrictions make it unlikely that Lerna can be incorporated into debian's
"main" archive.  For more info, including the (proposed and apparently
accepted) license text, see https://github.com/lerna/lerna/pull/1616

Bug#907527: RM: couchapp -- RoQA; RC-buggy for 9 months, RoQA requested for dependency

[Harlan Lieberman-Berg]

Package: ftp.debian.org
Severity: normal

Hello ftp-masters,

In association with the removal request for python-restkit, I am requesting the 
removal of couchapp.  Though couchapp has a minimally active upstream, it is 
fatally poisoned by the security vulnerabilities in its dependencies and should 
not be used.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

Bug#907526: RM: python-couchdbkit -- RoQA; dead upstream and dependency with RoQA request

[Harlan Lieberman-Berg]

Package: ftp.debian.org
Severity: normal

Hello ftp-masters,

I am requesting the removal of python-couchdbkit due to a separate
RoQA request of one of its dependancies (#907525; python-restkit).
python-couchdbkit has had a dead upstream since October 2015, with a
dead homepage to boot.

In addition, it is affected by the security bug in the dependency that
allows for trivial man-in-the-middling.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

Bug#906903: nvidia-driver: broken(?) dependencies

[Vincent McIntyre]

On a system where I have been successfully mixing stable & backports
I hit the same dependency problem. So I think this is a recent change.
I tried to dig a bit further to see if I could flush out the cause.

TL;DR libegl1-glvnd-nvidia, which I previously installed from backports,
  is only in stable and not (any longer) in stretch-backports.

Does this imply the dependencies of the backported nvidia-egl-icd
need to be tweaked (drop libegl1-glvnd-nvidia)?

Gory details:

# apt -t stretch-backports install nvidia-egl-icd
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 nvidia-egl-icd : Depends: libegl1 (>= 0.2.999) but it is not going to be 
installed or
   libegl1-glvnd-nvidia but it is not going to be 
installed
E: Unable to correct problems, you have held broken packages.

# apt-cache show nvidia-egl-icd | grep Depend | sed -e 's/, /\n/g'
Depends: nvidia-egl-common
libegl1 (>= 0.2.999) | libegl1-glvnd-nvidia
libegl-nvidia0 (= 390.77-1~bpo9+1)
Depends: nvidia-egl-common
libegl1xxx (>= 0.2.999) | libegl1-glvnd-nvidia
libegl-nvidia0 (= 390.48-2~bpo9+3)
Depends: nvidia-egl-common
libegl1 (>= 0.2.999) | libegl1-glvnd-nvidia
libegl-nvidia0 (= 384.130-1)

# dpkg -l libegl1 libegl-nvidia0 
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   Version  Architecture Description
+++-==---=
ii  libegl-nvidia0:amd64   390.48-2~bpo9+3  amd64NVIDIA binary EGL 
library
un  libegl1  (no description 
available)

# dpkg -l libegl1xxx  libegl1-glvnd-nvidia
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   Version  Architecture Description
+++-==---=
ii  libegl1-glvnd-nvidia:a 390.48-2~bpo9+3  amd64Vendor neutral GL 
dispatch library -- libEGL
un  libegl1xxx   (no description 
available)


So as a starting point I have libegl1-glvnd-nvidia installed,
instead of libegl1xxx or libegl1 (neither of which were ever installed).

It seems that for some reason apt now wants libegl1 in preference
to libegl1-glvnd-nvidia, despite the latter being the latest version.
The preferences scoring comes out like this:

# apt-cache policy libegl1
libegl1:
  Installed: (none)
  Candidate: 1.0.0+git20180308-2~bpo9+1
  Version table:
 1.0.0+git20180308-2~bpo9+1 200
200 http://debian-archive.atnf.csiro.au:/debian 
stretch-backports/main amd64 Packages

# apt-cache policy  libegl1-glvnd-nvidia
libegl1-glvnd-nvidia:
  Installed: 390.48-2~bpo9+3
  Candidate: 390.48-2~bpo9+3
  Version table:
 *** 390.48-2~bpo9+3 100
100 /var/lib/dpkg/status
 384.130-1 990
990 http://debian-archive.atnf.csiro.au:/debian stretch/non-free 
amd64 Packages

So it looks like libegl1-glvnd-nvidia has been removed from the
backports suite?

I checked what explicitly installing all the packages that can be
upgraded would do, which may be of interest.

# apt --simulate -t stretch-backports install `cat upgradable`
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions libdrm-amdgpu1
  libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libegl1
  libegl1-mesa libgl1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libgles2
  libgles2-mesa libglvnd0 libglx-mesa0 libglx0 libllvm6.0 libwayland-egl1
  libwayland-egl1-mesa update-glx
Recommended packages:
  libcuda1-i386 nvidia-settings nvidia-driver-libs-i386 libopengl0
  | libopengl0-glvnd-nvidia libgles-nvidia2 nvidia-egl-wayland-icd
  nvidia-vulkan-icd
The following packages will be REMOVED:
  libegl1-glvnd-nvidia libgl1-glvnd-nvidia-glx libglvnd0-nvidia
  libglx0-glvnd-nvidia
The following NEW packages will be installed:
  libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1
  libegl1 libgl1 libgl1-mesa-dri libgles2 libglvnd0 libglx-mesa0 libglx0
  libllvm6.0 libwayland-egl1
The following packages will be upgraded:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions 

Bug#907525: RM: python-restkit -- RoQA; security RC-buggy with dead upstream

[Harlan Lieberman-Berg]

Package: ftp.debian.org
Severity: normal

Hello ftp-masters,

I'm requesting the removal of python-restkit due to a long-term
security issue (CVE-2015-2674).  Despite being reported upstream for
more than three years, python-restkit still does not validate TLS
certificates, and upstream has not had a commit since December 2015.

python-restkit has two reverse-dependencies which have been RC-buggy due to 
python-restkit for nine months now, one of which also has a dead upstream.  I 
am filing separate RoQA requests for both of those packages as well.

Thank you for your help.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

Bug#907524: Support for python 2.7

[Luciano Bello]

Source: python-guess-language
Version: 0.5.2-4
Severity: normal
Tags: patch upstream

In an attempt to put w3af back into sid, we need support for Python 2 in
guess-language. I opened a PR into upstream with it. Please, take a look
https://bitbucket.org/spirit/guess_language/pull-requests/3/python-27-support/diff

It would be great if you can add it.

Cheers, luciano

Bug#907523: fcitx: Not compatible with iso-codes 4.0+

[Boyuan Yang]

Package: fcitx
Severity: important
Control: affects -1 + iso-codes
X-Debbugs-CC: wen...@gmail.com iso-co...@packages.debian.org
Version: 1:4.2.9.6-4
Forwarded: https://gitlab.com/fcitx/fcitx/issues/428

Package iso-codes just upgraded to v4.0, which stops providing XML files. 
However, fcitx still depends on the XML-format files.

I have forwarded this problem to upstream:

 https://gitlab.com/fcitx/fcitx/issues/428

--
Regards,
Boyuan Yang

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

Bug#907488: gitlab: post-inst fails: Could not find gem 'rugged (~> 0.26.0)'

[Pirate Praveen]

On 2018, ഓഗസ്റ്റ് 28 10:43:53 PM IST, Pikrass  wrote:
>Package: gitlab
>Version: 10.6.5+dfsg-2
>Severity: serious
>
>Dear Maintainer,
>
>The post-inst script consistently fails for me with unstable's current
>gitlab package. I tested this with two systems (one buster/sid and one
>sid).


It is a known issue, the version in unstable is broken. It is fixed in 
experimental. I'm waiting for protobuf and grpc versions in experimental to 
reach unstable. Also new gitlab versions are stuck in NEW because of 
gitlab-common binary package was added.

If you want a working version, use people.debian.org/~praveen/gitlab until we 
fix this situation.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#907522: pango1.0: different results on i386 when pango is built with meson

[Jeremy Bicha]

Source: pango1.0
Version: 1.42.4-2
Severity: serious
Forwarded: https://gitlab.gnome.org/GNOME/pango/issues/287
X-Debbugs-CC: seb...@debian.org

Let's keep this package from migrating to testing until this issue is fixed.

See the GNOME bug for more details.

I uploaded this with meson now because I forgot that the bug only
affected i386 (I only checked the amd64 autopkgtest this time before
uploading), and because pango in git master has dropped autotools
support so there is pressure for us to be ready for meson.

Thanks,
Jeremy Bicha

Bug#907521: agda-bin: Dep on lighc-agda-dev should be stronger

[Boyd Stephen Smith Jr.]

Package: agda-bin
Version: 2.5.3-5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

* What led up to the situation?

Upgraded agda-bin to buster for new INJECTIVE pragma

* What exactly did you do (or not do) that was effective (or
  ineffective)?

After the upgrade, all invocations of agda fail:

agda: The lib directory /usr/share/libghc-agda-dev/lib does not exist
CallStack (from HasCallStack):
  error, called at src/full/Agda/Interaction/Options.hs:822:8 in 
Agda-2.5.3-2orSVPe5vZF84kX5CIEyhw:Agda.Interaction.Options

   * What was the outcome of this action?

In my case, easy enough to resolve by installing the *recommended*
libghc-agda-dev package or agda-stdlib.

   * What outcome did you expect instead?

I expected all dependencies that are required for fundamental operations to be
'Depends' not just 'Recommended'.  While I'm not 100% sure, I think the jessie
agda-bin package would operate without installing 'Recommends' as well.

- -- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable'), (850, 
'proposed-updates'), (700, 'testing'), (500, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages agda-bin depends on:
ii  libc6  2.27-5
ii  libffi63.2.1-6
ii  libgmp10   2:6.1.2+dfsg-1
ii  libtinfo6  6.1+20180714-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages agda-bin recommends:
pn  libghc-agda-dev  

Versions of packages agda-bin suggests:
pn  elpa-agda2-mode  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHQEARECADQWIQTFhn3a8g2plxzZYyjnmmovsbVAWQUCW4YB7xYcYnNzQGlndWFu
YXN1aWNpZGUubmV0AAoJEOeaai+xtUBZJxoAoJRJbq0lMC/Gfh+9pqtrRz+RhBFj
AJ9lVafS8fUwA01/w0pNpucNXgiJZg==
=zniq
-END PGP SIGNATURE-

Bug#907520: RM: ldc [ppc64el] -- ROM; Does not build on ppc64el, no upstream support

[Matthias Klumpp]

Package: ftp.debian.org
Severity: normal

Hi!
Please drop the binaries of LDC on the ppc64el architecture.
The package currently FTBFS there, and upstream does not plan on
supporting the architecture without IEEE quad support, which doesn't
seem to be available.

See
https://github.com/ldc-developers/ldc/issues/2824
> My interest in Power is 0, plus the 2 different 128-bit long double ABIs 
> don't improve things either. [Just supporting the new one, IEEE quad, as 
> mid-term goal would be both easy (~full Phobos support already) and 
> preferrable IMO.]

To not block the other architectures from having a recent D compiler,
I would like to drop the ppc64el architecture for now. We can bring it
back later, if upstream supports it.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#907313: Lack of guidelines on purging conffiles in stateless packages

[Gioele Barabucci]

On 28/08/2018 05:21, Russ Allbery wrote:

Guillem Jover  writes:


I think the distinguishing factor here is whether a pathname is a
configuration file or a configuration fragments directory. So, I'd
say:



  * configuration file → /etc/foo/foo.conf → remove on purge, even if
[…]
  * configuration fragment directory → /etc/foo/foo.d/* → do not remove
[…]


This makes sense to me, and your first case would apply if the package has
a specific number of configuration files that can be shadowed in /etc.


I wonder if stateless programms aren't, in a certain sense, using `/etc` 
as a conf fragment directory. Take, for instance, a systemd directory 
like `/etc/systemd/system/`. It is no conventional ".d" directory, but 
it works exactly like that.


After a bit of reflection, I came to the conclusion that purging is a 
sort of relic of a bygone era where sysadmins configured applications by 
_changing_ files instead of _adding_ files.


Most of the current base programs still work in this way, but I suppose 
that it is only a matter of time before everything will switch to the 
stateless paradigm (that is in need of a better name). It is just too 
convenient. At that point the state "configured" would have little 
sense, same thing for the "apt --purge remove" command.


Regards,

--
Gioele Barabucci 

Bug#907266: Bug#907358: ncbi-vdb: fix broken library on i386

[Steve Langasek]

On Tue, Aug 28, 2018 at 09:38:50PM +0200, Andreas Tille wrote:
> > Also, this broken library package would have been detectable at build time
> > if you were building with -Wl,-z,defs in LDFLAGS, as that would have
> > prevented ever generating a shared library with missing symbols.  That's a
> > good idea to do anyway, but in particular it would mean that if you didn't
> > want to support i386 anymore, you could just add this to build flags and not
> > have to worry about changing the architecture list explicitly.

> So I did but was running into new problems which are caused by the hand
> craftet build system (yes, I tried to convince upstream to use some of
> the usual candidates but failed :-((( ).  I was able to add some missing
> libs in pbuilder chroot but whatever trick I try[1] the build system
> always constructs a different command line than I tested inside the
> pbuilder chroot.

> Do you have any idea to stop this insane messing up with library options?

> [1] 
> https://salsa.debian.org/med-team/ncbi-vdb/blob/master/debian/patches/fix_linking.patch

Failure I see in a local build is:

Try to add extra libs to LDFLAGS ... unfortunately this fails as well
CMD=gcc -shared -o 
/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib/libkdf5.so.2.9.2 
-Wl,-soname,libkdf5.so.2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now 
-Wl,-z,defs -Wl,--as-needed -g-ghdf5dir.pic.o hdf5file.pic.o 
hdf5arrayfile.pic.o 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/ilib -lhdf5_serial 
-lz -lmbedx509 -lmbedtls -lmbedcrypto -Wl,-Bstatic -Wl,-whole-archive -lklib 
-lkfs -Wl,-no-whole-archive -Wl,-Bdynamic -lbz2 -ldl -lpthread -lm -lkproc 
-lkfs -lkdb -lkns -lkfg
gcc -shared -o 
/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib/libkdf5.so.2.9.2 
-Wl,-soname,libkdf5.so.2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now 
-Wl,-z,defs -Wl,--as-needed -g-ghdf5dir.pic.o hdf5file.pic.o 
hdf5arrayfile.pic.o 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/ilib -lhdf5_serial 
-lz -lmbedx509 -lmbedtls -lmbedcrypto -Wl,-Bstatic -Wl,-whole-archive -lklib 
-lkfs -Wl,-no-whole-archive -Wl,-Bdynamic -lbz2 -ldl -lpthread -lm
/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/ilib/libklib.a(hashfile.pic.o):
 In function `map_calloc':
/tmp/ncbi-vdb/libs/klib/hashfile.c:288: undefined reference to `KLockAcquire'
/tmp/ncbi-vdb/libs/klib/hashfile.c:321: undefined reference to `KLockUnlock'
/tmp/ncbi-vdb/libs/klib/hashfile.c:328: undefined reference to `KLockUnlock'
[...]

When using -Wl,--as-needed, each object needs to be listed on the
commandline /after/ those objects that use it.

A correct commandline would be:

gcc -shared -o 
/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib/libkdf5.so.2.9.2 
-Wl,-soname,libkdf5.so.2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now 
-Wl,-z,defs -Wl,--as-needed -g-ghdf5dir.pic.o hdf5file.pic.o 
hdf5arrayfile.pic.o 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/ilib -lhdf5_serial 
-lz -Wl,-Bstatic -Wl,-whole-archive -lklib -lkfs -Wl,-no-whole-archive 
-Wl,-Bdynamic -lbz2 -ldl -lpthread -lm -lkfs -lkq -lkproc -lkdb -lkns -lkfg 
-lksproc -lmbedx509 -lmbedtls -lmbedcrypto -lz

So this seems to be sufficient:

CMD="$CMD -lkfs -lkq -lkproc -lkdb -lkns -lkfg -lksproc -lmbedx509 
-lmbedtls -lmbedcrypto -lz"

Though there is another similar error when trying to link libdiagnose.so
later.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#907519: ca-certificates-mono: maintscript accesses internal dpkg database

[Harlan Lieberman-Berg]

The merge request is: https://salsa.debian.org/dotnet-team/mono/merge_requests/1

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#907519: ca-certificates-mono: maintscript accesses internal dpkg database

[Harlan Lieberman-Berg]

Source: mono
Severity: normal
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-inert

Hello Mono Mantainers,

This package contains a maintainer script which directly accesses the dpkg 
database:

- debian/ca-certificates-mono.postinst

This a problem for multiple reasons. Even though the layout and format
of the dpkg database is administrator friendly, and it's expected that
those might need to mess with it, in case of emergency, this interface
does not extend to other programs besides the dpkg suite of tools. The
admindir can also be configured differently at dpkg build or run-time.
And finally, the contents and its format, will be changing in the near
future.

In addition in this particular case, the maintainer script is a
work-around for a missing dpkg trigger in another package that was
added in old-old-stable.

I will send a merge request to simply remove this file, as it is no
longer needed.

Thank you!

Sincerely,


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

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

Bug#907518: New libssl1.1 1.1.1~~pre9-1 in unstable breaks connecting to some wifi networks

[Josh Triplett]

Package: wpasupplicant
Version: 2:2.6-18
Severity: important

With libssl1.1 1.1.1~~pre9-1, which more aggressively deprecates smaller
key sizes by default, I can no longer connect to my office wifi network:

wpa_supplicant[523]: OpenSSL: pending error: error:0D07803A:asn1 encoding 
routines:asn1_item_embed_d2i:nested asn1 error
wpa_supplicant[523]: OpenSSL: pending error: error:140C800D:SSL 
routines:SSL_use_certificate_file:ASN1 lib
wpa_supplicant[523]: OpenSSL: pending error: error:140C618E:SSL 
routines:SSL_use_certificate:ca md too weak
wpa_supplicant[523]: TLS: Failed to set TLS connection parameters
wpa_supplicant[523]: EAP-TLS: Failed to initialize SSL.
wpa_supplicant[523]: wlp4s0: EAP: Failed to initialize EAP method: vendor 0 
method 13 (TLS)

Downgrading libssl1.1 to 1.1.0h-4 allows me to connect again. Please
adjust the defaults that wpasupplicant initializes OpenSSL with to
continue to allow connecting to such networks.

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

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

Versions of packages wpasupplicant depends on:
ii  adduser   3.117
ii  libc6 2.27-5
ii  libdbus-1-3   1.12.10-1
ii  libnl-3-200   3.4.0-1
ii  libnl-genl-3-200  3.4.0-1
ii  libpcsclite1  1.8.23-3
ii  libreadline7  7.0-5
ii  libssl1.1 1.1.1~~pre9-1
ii  lsb-base  9.20170808

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information

Bug#905670: cpuset: maintscript accesses internal dpkg database

[Harlan Lieberman-Berg]

tag 905670 +pending
thanks

Hello,

As part of a cleanup of packages with the lintian tag
"maintainer-script-should-not-use-dpkg-database-directly", I've
uploaded an NMU for this package to DELAYED/10 that simply drops the
preinst completely.  It has been entirely obsoleted by the removal of
pycentral.

There doesn't seem to be a current VCS for this package, but the patch
is trivial (simply rm the appropriate file).

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

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

[Graham Inggs]

Control: severity -1 serious
Control: found -1 ghostscript/9.22~dfsg-3

Hi Jonas

I'm bumping the severity of this bug to prevent ghostscript from
migrating until the cups autopkgtest regression has been investigated.

Regards
Graham

Bug#904652: pulseaudio: looses device and replace it with dummy package so no sound possible

[Felipe Sateler]

On Sat, Aug 11, 2018 at 9:54 AM Meinolf Gödde  wrote:

> The problem is back again. So i hope it helps.
>

The log file is empty :(.


Anyway, are you using MATE? Another bug with the same symptoms seems to be
caused by the mate volume manager (see bug #906622).

Saludos
-- 

Saludos,
Felipe Sateler

Bug#907505: /bin/gzip: error while loading shared libraries: cannot restore segment prot after reloc

[Christian Göttsche]

Control: severity -1 grave
Control: tags -1 pending

Thanks for your report and analysis.
I could reproduce it and the removal of MemoryDenyWriteExecute fixed it.
Patch on the way:
https://salsa.debian.org/debian/logrotate/commit/b779814f1ace71febdf7af425f043c000312c322.

Best regards
  Christian Göttsche

Bug#907517: RFP: libjs-jingle-media-session -- implementation of Jingle media session in JavaScript

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

* Package name: libjs-jingle-media-session
  Version : v2.3.0
  Upstream Author : Lance Stout 
* URL : https://github.com/otalk/jingle-media-session
* License : MIT
  Programming Lang: JavaScript
  Description : implementation of Jingle media session in JavaScript

dependency for libjs-jingle, libjs-strophe.jinglejs, and libjs-jsxc

Bug#907516: RFP: libjs-jingle-filetransfer-session -- implementation of Jingle filetransfer session in JavaScript

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

* Package name: libjs-jingle-filetransfer-session
  Version : v2.0.2
  Upstream Author : Lance Stout 
* URL : https://github.com/otalk/jingle-filetransfer-session
* License : MIT
  Programming Lang: JavaScript
  Description : implementation of Jingle filetransfer session in JavaScript

dependency for libjs-jingle, libjs-strophe.jinglejs, and libjs-jsxc

Bug#907499: Preferences > Keyboard and Mouse settings are lost/have not effect after logout/login

[Alf Gaida]

Please make sure that the settings file is not write protected (or
better: you should have the rights to write the file:
~/.config/lxqt/session.conf).

Bug#907515: RFP: libjs-jingle-session -- implementation of Jingle session in JavaScript

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

* Package name: libjs-jingle-session
  Version : v2.0.3
  Upstream Author : Lance Stout 
* URL : https://github.com/otalk/jingle-session
* License : MIT
  Programming Lang: JavaScript
  Description : implementation of Jingle session in JavaScript

dependency for libjs-jingle, libjs-strophe.jinglejs, and libjs-jsxc

Bug#907497: [Qa-jenkins-dev] Bug#907497: jenkins.debian.org: reproducible: reports outdated kernel variations

[Mattia Rizzolo]

On Tue, Aug 28, 2018 at 8:57 PM Vagrant Cascadian  wrote:
> https://tests.reproducible-builds.org/debian/index_variations.html lists:
>
>   Linux 4.9.0-6-armmp #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) armv7l
>   Linux 4.9.0-6-armmp-lpae #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) armv7l
>
> But no currently active systems are running these kernels. I suspect it
> is some cached kernel version leftover from before several armhf systems
> were removed

Indeed it is.
Nothing is currently cleaning up
/srv/reproducible-results/node-information/$hostname when a node is
removed, so it's storing also all removed and renamed nodes.

Of course I could just remove those files manually, but we would
forget to do it next time, so I'm leaving this open and the files in
place until we add some checks for non-known files (could just be
something that checks the list of file presents in that directory and
compares it with the list of hosts in jenkins_node_definitions.sh,
most likely to be run by reproducible_html_nodes_info.sh).

> I've also seen this happen when a system is down for a prolonged period
> and the last known kernel was an older kernel, although the case could
> be made that that's more-or-less correct.

maybe said checks should also consider jenkins-home/offline_nodes why not :)

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo

Bug#906749: python3-geopy: too old, does not include geopy.extra.rate_limiter.RateLimiter

[Daniele Tricoli]

Hello Thorsten,

On Tuesday, August 28, 2018 3:54:32 PM CEST Thorsten Glaser wrote:
> thanks for the feedback. In the meantime I managed to do it
> by running my script in the top-level directory of a clone
> of upstream’s repository, so the immediate need is gone,
> although we might need it occasionally still.

I have completed the update of the package and already sent a RFS.

If you need immediately geopy 1.16-1 you can build the update package from 
git[¹] but it should be uploaded before the end of the week.

HTH,

[¹] https://salsa.debian.org/python-team/modules/geopy

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

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

Bug#907514: ITP: bat -- bat: A cat(1) clone with wings

[Raju Devidas]

Package: wnpp
Severity: wishlist
Owner: Raju Devidas  

* Package name: bat
  Version : 0.5.0
  Upstream Author : David Peter 
* URL : https://github.com/sharkdp/bat
* License : MIT/Apache-2.0
  Programming Lang: Rust
  Description : bat: A cat(1) clone with wings
Bat is a clone of cat but with more features such as
syntax highlighting,  Git integration, automatic paging, 
file concatenation etc.  
It also supports theming, different output styles etc. 

There is an RFP for this (#907080)
I intend to maintain this package under Debian Rust Team. 

Bug#907513: RM: mshr -- ROM; no longer built

[Drew Parsons]

Package: ftp.debian.org
Severity: normal

The mshr-demos package was getting in the way of builds and
autopkgtests for mshr. The simplest solution was to get rid of it and
include demos with the python package.

But, zombie plague among us, mshr-demos are still trying to eat the
brains of mshr and preventing it reaching the safehaven of testing.

Please give mshr-demos a headshot.

Drew

Bug#907512: logwatch: some systemd-logind messages not filtered out

[Peter.Chubb]

Package: logwatch
Version: 7.4.3+git20161207-2
Severity: normal

Dear Maintainer,


In the logwatch output I see hundreds of messages like:
systemd-logind: Session 5 logged out. Waiting for processes to exit.: 1 
Time(s)

I think these are normal systemd syslog spam, and should be filtered
out. (this is on a busy server that has many users using ssh to it to perform
short tasks)

Peter C

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

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

Versions of packages logwatch depends on:
ii  exim4-daemon-light [mail-transport-agent]  4.91-7
ii  perl   5.26.2-7

Versions of packages logwatch recommends:
ii  libdate-manip-perl   6.72-1
ii  libsys-cpu-perl  0.61-2+b3
ii  libsys-meminfo-perl  0.99-1+b2

Versions of packages logwatch suggests:
pn  fortune-mod  

-- Configuration Files:
/etc/cron.daily/00logwatch changed [not included]

-- no debconf information

-- 
Dr Peter Chubb Tel: +61 2 9490 5852  http://ts.data61.csiro.au/
Trustworthy Systems Group Data61, CSIRO (formerly NICTA)

Bug#907301: plasma-desktop: no system tray whith task bar and no context menu of desktop

[Matteo]

Thanks, it works!

On Tue, 28 Aug 2018 23:17:59 +0200 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= <
bernha...@mailbox.org> wrote:

> Hello Matteo,

> user atte installed first libkf5runner5, then libkf5plasma5,

> you tried the other way around.

>

> You probably can try also to put both on the same command:

>

> dpkg -i libkf5runner5_5.49.0-1_amd64.deb libkf5plasma5_5.49.0-1_amd64.deb

>

> Kind regards,

> Bernhard

>

>

Bug#907509: fcoe-utils: Filter non-error from stderr to fix autopkgtests on some qemu platforms

[Adam Conrad]

Package: fcoe-utils
Version: 1.0.31+git20160622.5dfd3e4-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch



In Ubuntu, the attached patch was applied to achieve the following:

  * Filter non-error message about PCI capability support from stderr in our
autopkgtests for qemu platforms where we find a PCI bridge without caps.

On the Ubuntu autopkgtest VMs, we discovered that sometimes fcoeadm discovers
a PCI bridge, and sometimes it doesn't.  For instance, on amd64, it currently
does not, but on i386 and arm64, it does.

When it discovers a bridge, it then helpfully yells at us that PCI caps aren't
supported, and does said yelling to stderr, which autopkgtest then interprets
as a test failure.

There are three ways of dealing with this:

1) Patch the upstream code to output that to stdout, not stderr, it doesn't
   really seem like an ERROR, per se, more informative.
2) Filter that message out of stderr for the tests (this is what I do here)
3) Ignore stderr in autopkgtest, but I think that's a silly idea, as we may
   well care about OTHER things on stderr and want to treat that as a fail.

So, yeah.  As mentioned, this patch went for the middle option as the path
of least obvious ick.  I had to change the test script to /bin/bash to make
use of silly subshell redirection tricks, but it fixes the problem for us,
and the tests now pass[1] on arm64 and i386.

... Adam

[1] http://autopkgtest.ubuntu.com/packages/fcoe-utils

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

Kernel: Linux 4.17.0-7-lowlatency (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/tests/fcoemon 
fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/tests/fcoemon
--- fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/tests/fcoemon  2018-07-18 
22:01:35.0 -0600
+++ fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/tests/fcoemon  2018-08-27 
15:36:07.0 -0600
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 set -e
 
@@ -14,7 +14,7 @@
 run fcoeadm --create $IFACE
 run fcoeadm --reset $IFACE
 run fcoeadm --Scan $IFACE
-run fcoeadm --interface
+run fcoeadm --interface 2> >(grep -v "^PCI capabilities are not supported$" 
>&2)
 run fcoeadm --fcf
 run fcoeadm --target
 run fcoeadm --lun

Bug#907124: stretch-pu: package dropbear/2016.74-5

[Guilhem Moulin]

On Sun, 26 Aug 2018 at 14:52:06 +0100, Adam D. Barratt wrote:
> +dropbear (2016.74-5+deb9u1) stable; urgency=medium
> 
> Please make the distribution "stretch", and feel free to upload.

Oops yes sorry, uploaded with the correct distribution now.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#907510: fcoe-utils: One more gcc-8 warning fix

[Adam Conrad]

Package: fcoe-utils
Version: 1.0.31+git20160622.5dfd3e4-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch



In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/fix-gcc-warnings.patch: One more gcc warning fix for PPC.

It seems that your previous round of fixes[1] got everything except one spot
that gets caught (for some reason) only on ppc64el.  Applying the same logic
to that function with this patch, it now builds fine[2] there too:

[1] https://launchpad.net/ubuntu/+source/fcoe-utils/1.0.31+git20160622.5dfd3e4-4
[2] 
https://launchpad.net/ubuntu/+source/fcoe-utils/1.0.31+git20160622.5dfd3e4-4ubuntu2

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

Kernel: Linux 4.17.0-7-lowlatency (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/control 
fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/control
--- fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/control2018-08-27 
15:36:15.0 -0600
+++ fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/control2018-08-28 
13:05:14.0 -0600
@@ -1,8 +1,7 @@
 Source: fcoe-utils
 Section: misc
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian FCoE Team 
+Maintainer: Debian FCoE Team 
 Uploaders: Liang Guo ,
  Jacob Luna Lundberg ,
  Valentin Vidic ,
diff -Nru 
fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/patches/fix-gcc-warnings.patch 
fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/patches/fix-gcc-warnings.patch
--- fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/patches/fix-gcc-warnings.patch 
2018-07-18 22:01:35.0 -0600
+++ fcoe-utils-1.0.31+git20160622.5dfd3e4/debian/patches/fix-gcc-warnings.patch 
2018-08-28 13:05:08.0 -0600
@@ -58,6 +58,15 @@
if (rc < 0)
 --- a/fcoeadm_display.c
 +++ b/fcoeadm_display.c
+@@ -187,7 +187,7 @@
+   DIR *dir;
+   struct dirent *dp;
+   void (*f)(char *dirname, enum disp_style style);
+-  char path[1024];
++  char path[2048];
+ 
+   f = func;
+ 
 @@ -249,7 +249,7 @@
uint64_t lba = 0;
uint32_t blksize = 0;

Bug#907511: installation-reports: debian buster rc3 fails network, modules, partitioning

[banerian]

Package: installation-reports
Severity: important


Dear Maintainer,

-- Package-specific info:

Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/buster_di_alpha3/multi-arch/iso-cd/debian-buster-DI-alpha3-amd64-i386-netinst.iso
  2018-06-12
Date: August 2018

Machine: Supermicro R331.v5
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [E]
Detect CD:  [O]
Load installer modules: [E]
Clock/timezone setup:   [E]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [E]
Install base system:[E]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Installer with 4.16.x kernel failed with network device detection, despite 
4.9.0-n kernels of stretch having proper module, and in fact also the 4.17 
kernel in buster.

Installer reported that lvm was not available.

Installer found disk, but after defining a partition size, would not allow any 
options
beyond FAT16, FAT32, swap, or "do not use"  ... even when the disk was 
pre-partitioned. 
No option to define a root partition, no option for ext3/4 xfs, btrfs, etc.

Was not able to proceed with installation.

Ended up skipping Buster, rolled back to:

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

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


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

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

Bug#907501: Acknowledgement (ITP: golang-docker-go-docker -- official go SDK for docker)

[Leo "Costela" Antunes]

FYI: the current version doesn't build because it relies on unreleased code
in golang-github-docker-distribution-dev.
WIP can be found here:
https://salsa.debian.org/costela/golang-docker-go-docker

On Tue, Aug 28, 2018 at 10:00 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 907501:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907501.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   debian-de...@lists.debian.org
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  w...@debian.org
>
> If you wish to submit further information on this problem, please
> send it to 907...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 907501: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907501
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#906816: thunderbird: Does not start

[Rubén Gómez Antolí]

Hi all,

El 28/08/18 a las 20:48, Carsten Schoenert escribió:

[...]

>> Temporarily moving ~/.thunderbird /rhu4a0c1.default/Mail/Local Folder out of
>> the way did allow me to start Thunderbird. Unfortunately, "Local Folders" is
>> apparently where my main mailbox resides, so that's not a good workaround.
>> (I'm using POP, not IMAP, so my mail is stored locally.)
>>
>> Any suggestions for where I go from here?
> 
> Yes, the line gdb is showing were thunderbird is crashing is the
> interesting part, I'm sure this will show us an upstream issue. I see a
> small possibility that gcc8 might be the root for this crash. But then I
> also expect we would see a lot more bug reports related to thunderbird
> crashes.
> 
> If the other reporters could give a message if they also use POP would
> also interesting! Also if the redo the steps of Torbjörn and get the
> same output would good to knoe. As written earlier, if the issue can be
> reproduced it's mostly much easier to get it fixed.

I'm using POP mail too, and my mail is mainly in "Local folders" too.

Sorry for forgotten to use strace in my last message for help a bit
more, has been years from my last usage of it.

Tell us if you need some more test.

Thank you for your effort.

Best regards.

Salud y Revolución.

Lobo.
-- 
Libertad es poder elegir en cualquier momento. Ahora yo elijo GNU/Linux,
para no atar mis manos con las cadenas del soft propietario.
Porque la libertad no es tu derecho, es tu responsabilidad.
http://www.mucharuina.com
-
Desde El Ejido, en Almería, usuario registrado Linux #294013
http://www.counter.li.org

Bug#907301: plasma-desktop: no system tray whith task bar and no context menu of desktop

[Bernhard Übelacker]

Hello Matteo,
user atte installed first libkf5runner5, then libkf5plasma5,
you tried the other way around.

You probably can try also to put both on the same command:

dpkg -i libkf5runner5_5.49.0-1_amd64.deb libkf5plasma5_5.49.0-1_amd64.deb 

Kind regards,
Bernhard

Bug#896171: MS DOS partition table recognized as Atari AHDI

[John Paul Adrian Glaubitz]

On 8/28/18 6:29 PM, Emmanuel Kasper wrote:
> Ok i can reproduce the issue using the pc6.mbr posted by bouke:
> 
> cp pc6.mbr disk.img
> # otherwise parted complains "Can't have a partition outside the disk"
> truncate -s 600GB disk.img

Could be that CloneZilla is writing a corrupted partition table. I have
only ever seen this issue in cases where people were using CloneZilla.

> CCing John as he is the original atari patch author
> 
> @john: I am heavily suspecting here the disk signature, but maybe you
> have a better idea ?

You can just backport this patch that upstream has to workaround this
problem [1]. Basically, they just changed the order in which partitions
are probed and thus, parted probes for MS-DOS first, then later for
Atari.

I hope I'll find some time in the near future to properly investigate
this issue though. The idea is to have a look at how the kernel does
the Atari partition probing, the code there seems more reliable.

Thanks,
Adrian

> [1] 
> http://git.savannah.gnu.org/cgit/parted.git/commit/?id=395f8aabfecb28820006d37ec37e9ffe1d2eb1e3

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#907507: coreutils: /bin/dd throws a sig fault in mutex_optimistic_spin+0x164/0x1b0

[Dennis Clarke]

Package: coreutils
Version: 8.26-3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

  Attempt to kill -9 $pid for a process running dd 


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

  Could not kill the process as it seemed hung. 
  I pulled the USB memory stick out of the machine.

   * What was the outcome of this action?

  At some point later the process died as "killed" and 
  the shell prompt was visible.

   * What outcome did you expect instead?

  Expect a normal process to stop when CTRL-C or a kill -9 is 
  issued. 


Other information : 


[694328.800840] usb-storage 1-8:1.0: USB Mass Storage device detected
[694328.801128] scsi host4: usb-storage 1-8:1.0
[694328.801428] usbcore: registered new interface driver usb-storage
[694328.805712] usbcore: registered new interface driver uas
[694329.827892] scsi 4:0:0:0: Direct-Access SanDisk  Cruzer Micro 0.1  
PQ: 0 ANSI: 2
[694329.828724] sd 4:0:0:0: Attached scsi generic sg4 type 0
[694329.831605] sd 4:0:0:0: [sde] 3911679 512-byte logical blocks: (2.00 
GB/1.86 GiB)
[694329.831791] sd 4:0:0:0: [sde] Write Protect is off
[694329.831800] sd 4:0:0:0: [sde] Mode Sense: 03 00 00 00
[694329.831979] sd 4:0:0:0: [sde] No Caching mode page found
[694329.831985] sd 4:0:0:0: [sde] Assuming drive cache: write through
[694329.837463]  sde: sde1
[694329.838365] sd 4:0:0:0: [sde] Attached SCSI removable disk
[694675.048650] INFO: task systemd-udevd:226 blocked for more than 120 seconds.
[694675.048660]   Tainted: P   O4.9.0-7-amd64 #1 Debian 
4.9.110-3+deb9u2
[694675.048663] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[694675.048668] systemd-udevd   D0   226  1 0x0104
[694675.048677]  98a79f4cf400 98a74a50f400 98a7a327af00 
98a7b6c18980
[694675.048686]  98a71e5c4fc0 b066c1d1fb68 b3e0fed9 
b3e103c2
[694675.048694]   98a7b6c18980 b38c2df4 
98a7a327af00
[694675.048702] Call Trace:
[694675.048716]  [] ? __schedule+0x239/0x6f0
[694675.048724]  [] ? schedule+0x32/0x80
[694675.048734]  [] ? mutex_optimistic_spin+0x164/0x1b0
[694675.048741]  [] ? schedule+0x32/0x80
[694675.048749]  [] ? schedule_preempt_disabled+0xa/0x10
[694675.048757]  [] ? __mutex_lock_slowpath+0xb4/0x130
[694675.048766]  [] ? mutex_lock+0x1b/0x30
[694675.048775]  [] ? __blkdev_get+0x6a/0x410
[694675.048783]  [] ? blkdev_get+0x126/0x330
[694675.048791]  [] ? blkdev_get_by_dev+0x40/0x40
[694675.048798]  [] ? do_dentry_open+0x1fb/0x300
[694675.048807]  [] ? path_openat+0x6a3/0x14f0
[694675.048815]  [] ? vsnprintf+0xf3/0x4f0
[694675.048821]  [] ? do_filp_open+0x91/0x100
[694675.048829]  [] ? __seccomp_filter+0x74/0x270
[694675.048835]  [] ? memzero_explicit+0xe/0x10
[694675.048842]  [] ? __check_object_size+0xfa/0x1d8
[694675.048849]  [] ? do_sys_open+0x12e/0x210
[694675.048857]  [] ? do_syscall_64+0x8d/0xf0
[694675.048863]  [] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
[694719.825638] usb 1-8: USB disconnect, device number 27
[694719.836400] sd 4:0:0:0: [sde] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT 
driverbyte=DRIVER_OK
[694719.836404] sd 4:0:0:0: [sde] tag#0 CDB: Write(10) 2a 00 00 2a 59 58 00 00 
f0 00
[694719.836406] blk_update_request: I/O error, dev sde, sector 2775384
[694719.836407] Buffer I/O error on dev sde, logical block 2775384, lost async 
page write
[694719.836409] Buffer I/O error on dev sde, logical block 2775385, lost async 
page write
[694719.836410] Buffer I/O error on dev sde, logical block 2775386, lost async 
page write
[694719.836411] Buffer I/O error on dev sde, logical block 2775387, lost async 
page write
[694719.836412] Buffer I/O error on dev sde, logical block 2775388, lost async 
page write
[694719.836413] Buffer I/O error on dev sde, logical block 2775389, lost async 
page write
[694719.836414] Buffer I/O error on dev sde, logical block 2775390, lost async 
page write
[694719.836415] Buffer I/O error on dev sde, logical block 2775391, lost async 
page write
[694719.836417] Buffer I/O error on dev sde, logical block 2775392, lost async 
page write
[694719.836418] Buffer I/O error on dev sde, logical block 2775393, lost async 
page write


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


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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-3+b1
ii  libattr1 1:2.4.47-2+b2
ii  libc62.24-11+deb9u3
ii  libselinux1  2.6-3+b3

Bug#907508: fusiondirectory: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: fusiondirectory
Version: na
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for fusiondirectory's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


fusiondirectory_pt.po.gz
Description: application/gzip

Bug#907157: cura-engine: FTBFS in buster/sid (Error copying directory)

[Juhani Numminen]

Dear maintainer,

Applying this patch might fix the FTBFS. I haven't tried myself yet.

https://github.com/Ultimaker/CuraEngine/commit/5aad55bf67e52ce5bdb27a3925af8a4cab441b38#diff-af3b638bc2a3e6c650974192a53c7291


Cheers,
Juhani

Bug#906294: haveged: New upstream version

[Jérémy Bobbio]

On 16/08/2018 19:22, Steffen Moeller wrote:
> Package: haveged
> Version: 1.9.1-6
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Version 1.9.6 is available. Please kindly inform me if you would appreciate 
> to be helped out.

The package is in collab-maint, please go ahead!

I'm now set on retiring from Debian but I'm still haven't found a large
enough time window to do so. If you want to be listed as the maintainer,
feel free to do so.

Thanks!
-- 
Lunar



signature.asc
Description: OpenPGP digital signature

Bug#907506: kinit: "Add to panel (Widget)" does not work

[Alan W. Irwin]

Package: kinit
Version: 5.47.0-1
Severity: normal

Dear Maintainer,

With the latest version of the KDE desktop available for Debian Buster
it appears to be impossible to launch multiple instances of
applications from the panel.  For example, if I explore klauncher ->
applications -> internet I find two web browsers (Firefox ESR and
konqueror) and if explore klauncher -> applications -> system I find
konsole.  If I right click on any of those applications two of the
options are "Pin to task manager" and "Add to panel (Widget)".  The
first of those works, but only allows you to launch a single instance
of the application at a given time from the task manager which is not
useful to me since I need to launch multiple instances (especially for
konsole but sometimes for the browsers as well as other KDE
applications).

According to web sources "Add to panel (Widget)" should give me what I
want which is a separate panel launcher for each application that I
use a lot such as Firefox ESR, konqueror, and konsole, but this
functionality does not work (i.e., no launchers appear on the panel
for any of these applications).  I routinely configured such
individual launchers on the panel (by a method which I cannot remember
exactly, but I think it was drag and drop from klauncher to panel)
when I was running a KDE desktop for Debian Buster a couple months ago
so I am pretty sure one of the KDE desktop upgrades in the last month
or so clobbered this long-standing and important individual
application launcher capability for the panel.

N.B. It is possible klauncher is fine, and instead the updated panel
is screwing up this capability.  However, I have chosen to report this
bug for kinit because I know klauncher belongs to that package while I
have been unable to discover what application runs the panel so I
cannot figure out which package the panel belongs to.  But I encourage you
to shift this bug report to the package containing the panel if that
is where the fault lies.

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

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

Versions of packages kinit depends on:
ii  kio  5.47.0-1
ii  libc62.27-5
ii  libcap2  1:2.25-1.2
ii  libcap2-bin  1:2.25-1.2
ii  libkf5configcore55.47.0-1
ii  libkf5coreaddons55.47.0-1
ii  libkf5crash5 5.47.0-1
ii  libkf5i18n5  5.47.0-1
ii  libkf5kiocore5   5.47.0-1
ii  libkf5kiowidgets55.47.0-1
ii  libkf5service-bin5.47.0-1
ii  libkf5service5   5.47.0-1
ii  libkf5windowsystem5  5.47.0-1
ii  libqt5core5a 5.11.1+dfsg-6
ii  libqt5dbus5  5.11.1+dfsg-6
ii  libqt5gui5   5.11.1+dfsg-6
ii  libstdc++6   8.2.0-4
ii  libx11-6 2:1.6.6-1
ii  libxcb1  1.13-3

kinit recommends no packages.

kinit suggests no packages.

-- no debconf information

Bug#907450: python-os-faults: «Command u'os-inject-fault --help' failed: [Errno 2] No such file or directory» in documentation

[Chris Lamb]

Hi Thomas,

> Thanks for this bug report, it's very valuable for me, because it's hard
> for me to track reproducibility.

I appear to have confused you, apologies.

Whilst the problem was found during reproducibility testing, your
documentation is broken right now; it contains error messages instead
of the output of the program.


Regards,

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

Bug#907505: /bin/gzip: error while loading shared libraries: cannot restore segment prot after reloc

[Andreas Pommer]

Package: logrotate
Version: 3.14.0-3
Severity: normal

Dear Maintainer,

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

Yesterday on my servers the logrotate package was updated. The change in this
upgrade was the migration from invocation by cron to a systemd timer. This
night logrotate tried to run and do its job, and failed:

Aug 28 00:00:01 fu.fsck.at logrotate[14276]: error: Compressing program wrote 
following message to stderr when compressing log /var/log/syslog.1:
Aug 28 00:00:01 fu.fsck.at logrotate[14276]: /bin/gzip: error while loading 
shared libraries: cannot restore segment prot after reloc: Operation not 
permitted
Aug 28 00:00:01 fu.fsck.at logrotate[14276]: error: failed to compress log 
/var/log/syslog.1

I encountered this error on all i686 systems, but not on the amd64 systems.

Some results from googling indicate that this might be related to SELinux.
I do not use SELinux, but apparmor. However, there are no rules active
related to logrotate or gzip.

After reading https://github.com/systemd/systemd/issues/5400 I suspect that
MemoryDenyWriteExecute in the logrotate.service file is causing this.


-- Package-specific info:
Contents of /etc/logrotate.d
total 40
-rw-r--r-- 1 root root 120 Oct 21  2017 alternatives
-rw-r--r-- 1 root root 442 Sep  3  2017 apache2
-rw-r--r-- 1 root root 173 Aug  6  2012 apt
-rw-r--r-- 1 root root 130 Aug 21 22:23 btmp
-rw-r--r-- 1 root root 112 Oct 21  2017 dpkg
-rw-r--r-- 1 root root 313 Mar 19  2014 fail2ban
-rw-r--r-- 1 root root 120 Nov 27  2014 munin-node
-rw-r--r-- 1 root root 501 Jul  1  2017 rsyslog
-rw-r--r-- 1 root root 235 May 27  2015 unattended-upgrades
-rw-r--r-- 1 root root 145 Feb 19  2018 wtmp


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

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

Versions of packages logrotate depends on:
ii  cron [cron-daemon]  3.0pl1-130
ii  libacl1 2.2.52-3+b1
ii  libc6   2.27-5
ii  libpopt01.16-11
ii  libselinux1 2.8-1+b1
ii  systemd-sysv239-7

Versions of packages logrotate recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1

logrotate suggests no packages.

-- no debconf information

Bug#907301: plasma-desktop: no system tray whith task bar and no context menu of desktop

[Matteo]

I have same issue.


DE: KDE 5.47.0 / Plasma 5.13.4

Kernel: x86_64 Linux 4.17.0-3-amd64


When I try the Bernhard/atte's solution I get this error:


# dpkg -i /home/iux/Downloads/libkf5plasma5_5.49.0-1_amd64.deb
dpkg: regarding .../libkf5plasma5_5.49.0-1_amd64.deb containing
libkf5plasma5:amd64: libkf5plasma5:amd64 breaks libkf5runner5 (<< 5.49)
 libkf5runner5:amd64 (version 5.47.0-1) is present and installed.

dpkg: error processing archive
/home/iux/Downloads/libkf5plasma5_5.49.0-1_amd64.deb (--install): installing
libkf5plasma5:amd64 would break libkf5runner5:amd64, and deconfiguration is
not permitted (--auto-deconfigure might help)
Errors were encountered while processing:
/home/iux/Downloads/libkf5plasma5_5.49.0-1_amd64.deb

Bug#866878: release.debian.org: should autopkgtest regressions be considered RC?

[Paul Gevers]

Hi Graham,

On Mon, 03 Jul 2017 15:35:00 + Niels Thykier  wrote:
> The status quo is that:
> 
>  * A failure can be RC if it basically shows that the package is broken
>or have significantly regressed in functionality (possibly caused by
>a dependency).
> 
>  * But autopkgtests failures in themselves are not RC at the moment.

Do you still consider this the status quo? Currently we are filing bug
reports when there is regression in testing, we are finding serious
issues, but unfortunately we can't always figure out in a reasonable
time how broken the package actually is.

As we want to move to the blocking state soon (once we have improved
britney to calculate the set of packages from unstable that are needed
to test, such that we can disable the apt-get fallback in autopkgtest;
code ready, testing ongoing) wouldn't it be reasonable to file the bugs
we are filing against both packages (the triggering one and the failing
one) at a higher level? Of course with the clear explanation that if the
maintainers consider the issue to be non-critical they shouldn't
hesitate to lower it?

>  * Analyse autopkgtests failures and file bugs as appropriate (RC when
>the package appears to be actually broken, non-RC otherwise).
>- Patches are probably very welcome here as well.

We are doing that, but as I mentioned above, often it isn't easy for a
bystander to judge and so far I have been reluctant to do this at higher
than normal severity unless I was really convinced the autopkgtest
showed complete broken packages.

This is the list of failures we have spotted the last couple of months
(some were filed before by Adrian Bunk due to FTBFS on
reproducible-builds):
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org

Paul



signature.asc
Description: OpenPGP digital signature

Bug#906816: thunderbird: Does not start

[Torbjörn Andersson]

On 2018-08-28 20:48, Carsten Schoenert wrote:
> Yes, the line gdb is showing were thunderbird is crashing is the
> interesting part, I'm sure this will show us an upstream issue. I see
> a small possibility that gcc8 might be the root for this crash. But
> then I also expect we would see a lot more bug reports related to
> thunderbird crashes.

I was going to bed, but I figured a hasty reply now might still be more 
useful than a more carefully written reply in eight hours or so. :-)


Here's the start of the backtrace I got from gdb. I hope that provides 
enough context:


#0  0x7f22828eb9b0 in 
mozilla::detail::nsTStringRepr::First() const 
(this=this@entry=0x7fff9ca7a5c0)

at ./obj-thunderbird/dist/include/mozilla/Assertions.h:40
#1  0x7f22828182a2 in 
nsMsgLocalStoreUtils::nsShouldIgnoreFile(nsTSubstring&) 
(name=...) at ./comm/mailnews/local/src/nsMsgLocalStoreUtils.cpp:31
#2  0x7f228281676c in 
nsMsgBrkMBoxStore::AddSubFolders(nsIMsgFolder*, nsCOMPtr&, 
bool) (this=0x7f225ea661f0, parent=0x7f226cf24438, path=..., deep=true) 
at ./comm/mailnews/local/src/nsMsgBrkMBoxStore.cpp:1063
#3  0x7f2282816ad8 in 
nsMsgBrkMBoxStore::DiscoverSubFolders(nsIMsgFolder*, bool) 
(this=0x7f225ea661f0, aParentFolder=0x7f226cf24438, aDeep=)

at ./comm/mailnews/local/src/nsMsgBrkMBoxStore.cpp:69
#4  0x7f22827fd29e in 
nsMsgLocalMailFolder::GetSubFolders(nsISimpleEnumerator**) 
(this=this@entry=0x7f226cf24400, aResult=0x7fff9ca7a770)

at ./obj-thunderbird/dist/include/nsCOMPtr.h:798
#5  0x7f2282687c7b in nsMsgDBFolder::ListFoldersWithFlags(unsigned 
int, nsIMutableArray*) (this=0x7f226cf24400, aFlags=4096, 
aFolders=0x7f225edffbe0)

at ./obj-thunderbird/dist/include/nsCOMPtr.h:1367

I tried printing the 'name' parameter from nsShouldIgnoreFile(), but I 
don't know if it's at all helpful:


(gdb) print name
$2 = (nsAString &) @0x7fff9ca7a5c0: 
{> = {mData = 0x7f2285e2be84 
 u"", mLength = 0,

mDataFlags = mozilla::detail::StringDataFlags::TERMINATED,
mClassFlags = (mozilla::detail::StringClassFlags::INLINE | 
mozilla::detail::StringClassFlags::NULL_TERMINATED)}, static 
kMaxCapacity = 1073741817}


Regards,

Torbjörn

Bug#907504: kinit: "type to search" has quit working

[Alan W. Irwin]

Package: kinit
Version: 5.47.0-1
Severity: normal

Dear Maintainer,

For the KDE launcher (klauncher) that is available on the panel, if
you search for an application by typing its name a search bar comes up
as per usual, but that search bar no longer finds any applications no
matter what you type for the search.  This functionality (which I use
a lot whenever I run a KDE desktop) worked when I was running a KDE
desktop for Debian Buster a couple months ago so I am pretty sure one
of the kinit upgrades in the last month or so clobbered this important
search functionality for klauncher.

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

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

Versions of packages kinit depends on:
ii  kio  5.47.0-1
ii  libc62.27-5
ii  libcap2  1:2.25-1.2
ii  libcap2-bin  1:2.25-1.2
ii  libkf5configcore55.47.0-1
ii  libkf5coreaddons55.47.0-1
ii  libkf5crash5 5.47.0-1
ii  libkf5i18n5  5.47.0-1
ii  libkf5kiocore5   5.47.0-1
ii  libkf5kiowidgets55.47.0-1
ii  libkf5service-bin5.47.0-1
ii  libkf5service5   5.47.0-1
ii  libkf5windowsystem5  5.47.0-1
ii  libqt5core5a 5.11.1+dfsg-6
ii  libqt5dbus5  5.11.1+dfsg-6
ii  libqt5gui5   5.11.1+dfsg-6
ii  libstdc++6   8.2.0-4
ii  libx11-6 2:1.6.6-1
ii  libxcb1  1.13-3

kinit recommends no packages.

kinit suggests no packages.

-- no debconf information

Bug#904777: transition: libraw

[Matteo F. Vescovi]

Hi!

On 2018-08-28 at 10:23 (+0200), Emilio Pozuelo Monfort wrote:
> Go ahead.

Uploaded. Thanks.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#907503: openssh: CVE-2018-15919: user enumeration via auth2-gss.c

[Salvatore Bonaccorso]

Source: openssh
Version: 1:6.7p1-1
Severity: normal
Tags: security upstream

Hi,

The following vulnerability was published for openssh, filling as bug
in BTS mainly for tracking. I do not think a DSA is needed for it, and
as a side note, upstream does not want to threat such a user
enumeration as a vulnerability. Once a fix is available it would still
be sensible to have at least for buster, disputable on what to do for
stretch.

CVE-2018-15919[0]:
| Remotely observable behaviour in auth-gss2.c in OpenSSH through 7.8
| could be used by remote attackers to detect existence of users on a
| target system when GSS2 is in use. NOTE: the discoverer states 'We
| understand that the OpenSSH developers do not want to treat such a
| username enumeration (or "oracle") as a vulnerability.'

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-15919
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15919
[1] https://bugzilla.novell.com/show_bug.cgi?id=1106163
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1623184

Regards,
Salvatore

Bug#907491: goobook fails to authenticate

[Kurt Roeckx]

This is most likely caused by google sending invalid certificates
if you talk TLS 1.3 but don't send the SNI extention. See
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication

Bug#907494: hgsvn: package is missing most of its files

[Vincent Danjean]

  Hi,

Le 28/08/2018 à 18:51, Nick Smallbone a écrit :
> Package: hgsvn
> Version: 0.1.8-1.1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> After installing hgsvn, I tried to run hgimportsvn but was greeted
> with:
> 
> % hgimportsvn
> zsh: command not found: hgimportsvn
> 
> A closer look reveals that the package does not actually install
> hgsvn. For some reason, it only includes the manpages and
> documentation. Here is the output of dpkg -L hgsvn - notice the empty
> /usr/bin directory:

Whaou! The package is in this state since several years
(as this is the version currently in stretch), since 2015-08-22
exactly (upload of the NMU version). And this is the first
bug report.

  I do not use it anymore and, as the upstream website changed,
I just see I'm several version late.


  I will try to update/redo this package. Any help is welcome.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#907502: ITP: matrix-python-sdk -- Matrix Client SDK for Python

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: matrix-python-sdk
  Version : 0.3.2
  Upstream Author : mat...@matrix.org
* URL : http://www.matrix.org
* License : Apache License 2.0
  Programming Lang: Python
  Description : Matrix Client SDK for Python

  This is a Matrix client-server SDK for Python 2.7 and 3.4+.
  The SDK provides 2 layers of interaction. The low-level layer just
  wraps the raw HTTP API calls. The high-level layer wraps the low-level
  layer and provides an object model to perform actions on.

Bug#907501: ITP: golang-docker-go-docker -- official go SDK for docker

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: golang-docker-go-docker
  Version : 1.0.0
  Upstream Author : Docker Inc.
* URL : https://docker.io/go-docker
* License : TBD (https://github.com/docker/go-docker/issues/10)
  Programming Lang: go
  Description : official go SDK for docker

This is the official SDK for interacting with the docker deamon in go.

- end description -

This package is needed to build at least one other ITP: #907356
Maintainment would be in the pkg-go team.


Cheers

Bug#797268: Man page doesn't describe --imgur option

[Karolis Martinkus]

This is already fixed in current version in Testing (1.9.3-1). Can be
closed.

Karolis M.

Bug#907380: tex-common: setting up of tex-common fails

[Julian Gilbey]

On Tue, Aug 28, 2018 at 12:48:28PM +0200, fulvio ciriaco wrote:
> wow, lots of problems with bin in the path:
> root@fulvio:/# cd /usr/sbin
> root@fulvio:/usr/sbin# ls
> bash: bin/ls: No such file or directory
> 
> ok, nothing to do with tex-common anyhow, sorry.

Yes, putting "bin" in PATH is really bad practice, and as root it's
positively dangerous.  You should only ever have absolute directories
in PATH.

Best wishes,

   Julian

Bug#907499: Preferences > Keyboard and Mouse settings are lost/have not effect after logout/login

[local10]

Package: lxqt   
Version: 27

Issue 1: mouse left handed setting is not applied after logout/login

1. Set Preferences > Keyboard and Mouse > Mouse > [X] Left handed
2. Logout out of lxqt then login back
3. Goto Preferences > Keyboard and Mouse > Mouse, [X] Left handed is checked 
but the mouse behaves as a right handed mouse. It necessary for me to uncheck 
and the recheck the left handed setting for the mouse to become Left handed.


Issue 2: mouse Acceleration setting seems to have no effect

Set Preferences > Keyboard and Mouse > Mouse > Acceleration to different values 
from 1 to 10. Mouse pointer appears to move with the same speed and not 
affected by the mouse Acceleration setting.

Thanks

Bug#907500: qemu: CVE-2018-15746: seccomp: blacklist is not applied to all threads

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.12+dfsg-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for qemu.

CVE-2018-15746[0]:
seccomp: blacklist is not applied to all threads

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-15746
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15746
[1] https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg04892.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg02289.html

Please adjust the affected versions in the BTS as needed. seccomp
support is enabled for the Debian builds only starting from
1:2.12+dfsg-2, isue would be present already before source-wise, but
going to mark the issue as no-dsa for older versions.

Regards,
Salvatore

Bug#906375: libitext5-java: FTBFS in buster/sid (method marshal in class org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature cannot be applied to given types)

[Jochen Sprickerhof]

Hi,

I looked into this, but haven't found an easy solution.

* Santiago Vila  [2018-08-17 11:20]:

[ERROR] 
/<>/src/main/java/com/itextpdf/text/pdf/security/MakeXmlSignature.java:[443,22]
 method marshal in class org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature cannot be 
applied to given types;
 required: 
org.apache.jcp.xml.dsig.internal.dom.XmlWriter,java.lang.String,javax.xml.crypto.XMLCryptoContext
 found: 
org.w3c.dom.Node,org.w3c.dom.Node,java.lang.String,javax.xml.crypto.dsig.dom.DOMSignContext
 reason: actual and formal argument lists differ in length


The problem is that libitext5-java is using an internal API of 
libxml-security-java here which was reworked in version 2. Discussion 
and patch can be found here:


https://issues.apache.org/jira/browse/SANTUARIO-349

Problem is that it introduces a new class Marshaller, used to generate 
the same result as needed by libitext5-java but it's not public, so we 
can't access it easily.


Itext has moved on to version 7 in the meantime, not use the internal 
API, as far as I've seen. But it has a different API itself, so we would 
have to port all depending packages to it (which are figtree, hibiscus 
and umlet).


I'm not sure if I will find time for this soon, so help would be very 
welcome here.


As a quick fix we could probably hack around the visibility modifiers of 
Marshaller, but I guess that would be rather ugly. Just mentioning it 
for completeness.


* Andreas Tille  [2018-08-25 17:44]:

[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for com.itextpdf:itextpdf:5.5.13: Cannot 
access central (https://repo.maven.apache.org/maven2) in offline mode and the 
artifact com.itextpdf:itext-parent:pom:1.0.0 has not been downloaded from it 
before. and 'parent.relativePath' points at no local POM @ line 5, column 11
[FATAL] Non-resolvable parent POM for com.itextpdf:itext-pdfa:5.5.13: Cannot 
access central (https://repo.maven.apache.org/maven2) in offline mode and the 
artifact com.itextpdf:itext-parent:pom:1.0.0 has not been downloaded from it 
before. and 'parent.relativePath' points at no local POM @ line 5, column 11
[FATAL] Non-resolvable parent POM for com.itextpdf:itext-xtra:5.5.13: Cannot 
access central (https://repo.maven.apache.org/maven2) in offline mode and the 
artifact com.itextpdf:itext-parent:pom:1.0.0 has not been downloaded from it 
before. and 'parent.relativePath' points at no local POM @ line 5, column 11
[FATAL] Non-resolvable parent POM for com.itextpdf.tool:xmlworker:5.5.13: 
Cannot access central (https://repo.maven.apache.org/maven2) in offline mode 
and the artifact com.itextpdf:itext-parent:pom:1.0.0 has not been downloaded 
from it before. and 'parent.relativePath' points at no local POM @ line 5, 
column 11
@
[ERROR] The build could not read 4 projects -> [Help 1]


I've looked into this as well and have some patches to make it work up 
to the same error this bug is about. If you still want to have them, I 
can send a pull request.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#907266: Bug#907358: ncbi-vdb: fix broken library on i386

[Andreas Tille]

Control: tags -1 help

Hi Steve,

On Sun, Aug 26, 2018 at 03:04:40PM -0700, Steve Langasek wrote:
> Package: ncbi-vdb
> Version: 2.9.1-1+dfsg-1
> Severity: grave
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu cosmic ubuntu-patch
> 
> Dear Andreas,
> 
> The libncbi-vdb2 library is broken on i386, because while it has managed to
> build, it has unresolvable references:
> ...
> It would also be perfectly reasonable to drop i386 as a supported
> architecture for ncbi-vdb if you prefer; but I suggest you then make sure to
> actually do this, rather than shipping a broken library package on i386.

Thanks to your patch I decided to leave i386 for the moment but its
definitely a candidate for removal.

> Also, this broken library package would have been detectable at build time
> if you were building with -Wl,-z,defs in LDFLAGS, as that would have
> prevented ever generating a shared library with missing symbols.  That's a
> good idea to do anyway, but in particular it would mean that if you didn't
> want to support i386 anymore, you could just add this to build flags and not
> have to worry about changing the architecture list explicitly.

So I did but was running into new problems which are caused by the hand
craftet build system (yes, I tried to convince upstream to use some of
the usual candidates but failed :-((( ).  I was able to add some missing
libs in pbuilder chroot but whatever trick I try[1] the build system
always constructs a different command line than I tested inside the
pbuilder chroot.

Do you have any idea to stop this insane messing up with library options?


[1] 
https://salsa.debian.org/med-team/ncbi-vdb/blob/master/debian/patches/fix_linking.patch

-- 
http://fam-tille.de

Bug#891063:

[Vincent Lefevre]

On 2018-08-28 11:39:08 -0700, Chris Waters wrote:
> Programs are allowed to use the environment to communicate with each
> other. Programs *do*. If you assume they won't, you're likely to
> experience more "breakage". The problem is not with these programs;
> the problem is with your assumptions.

But that would have been possible without breaking everything (e.g. by
checking the owner of the directory before writing anything there).

And this is not my assumptions, but assumptions implied by historical
su's behavior.

> > I've reported a bug against su:
> 
> The behavior of su is defined by POSIX and the Single User Spec. It's
> not a bug.

No, su is not part of the utilities described by POSIX.

And if it were, that would have been a very strong argument against
the dconf behavior.

> > And you're suggesting sudo while there will be the same issue.
> 
> No. The sudo -e option doesn't run your editor as root;

Unfortunately, this is not documented and the sentence "Note that
unlike most commands run by sudo, the editor is run with the invoking
user's environment unmodified." is confusing. Instead of saying "with
the invoking user's environment unmodified", it should have said
"without becoming the other user".

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

Bug#905927: [Pkg-postgresql-public] Bug#905927: postgresql-10 breaks pglogical autopkgtest:

[Christoph Berg]

Re: To Paul Gevers 2018-08-26 <20180826201819.gb30...@msg.df7cb.de>
> I'll post another update once upstream has released any details.

https://www.postgresql.org/message-id/20180828153806.fgfnul2imeltzmib%40alvherre.pgsql

Christoph

Bug#907301: plasma-desktop: no system tray whith task bar and no context menu of desktop

[Michael Franzl]

Hello,

I am also hit by this. It happened on all my Buster machines after the 
last upgrade. The temporary workaround by Bernhard/atte worked for me -- 
thanks so much for posting it.


Best regards,
Michael

Bug#907450: python-os-faults: «Command u'os-inject-fault --help' failed: [Errno 2] No such file or directory» in documentation

[Thomas Goirand]

On 08/28/2018 08:50 AM, Chris Lamb wrote:
> Source: python-os-faults
> Version: 0.1.17-1
> Severity: important
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> Hi,
> 
> Whilst working on the Reproducible Builds effort [0], we noticed
> that python-os-faults could not be built reproducibly because it
> prints an error message in the documentation that includes the
> build path:
> 
>   Command u'os-inject-fault --help' failed: [Errno 2] No such file or 
> directory
> 
> .. instead of the output of that 'os-inject-fault --help'
> 
> A patch is attached, but this merely to demonstrate the problem;
> it is _not_ the correct fix as it uses the previous version of
> python-os-faults.
> 
> I tried a quick hack with PATH etc. but because of the python2/python3
> binary name split it is not obvious how to do this.
> 
>  [0] https://reproducible-builds.org/
> 
> 
> Regards,

Hi Chris,

Thanks for this bug report, it's very valuable for me, because it's hard
for me to track reproducibility.

No worries, I believe I know how to fix this package to make it
reproducible. At least, I'll try.

Cheers,

Thomas Goirand (zigo)

Bug#907498: elasticsearch-curator: autopkgtest fails: dependency removed from debian

[Paul Gevers]

Source: elasticsearch-curator
Version: 5.2.0-1
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainers,

I was looking into the failure of your package on the ci.debian.org
infrastructure. Although I don't know what the original reasons were why
the autopkgtest failed (the logs have been recycled), in the current
situation it is failing because you declare a test dependency on
elasticsearch which has been removed from Debian. Could you please have
a look and fix your autopkgtest?

Thanks for considering.

Paul

https://ci.debian.net/data/packages/unstable/amd64/e/elasticsearch-curator/latest-autopkgtest/log.gz



signature.asc
Description: OpenPGP digital signature

Bug#907497: jenkins.debian.org: reproducible: reports outdated kernel variations

[Vagrant Cascadian]

Package: jenkins.debian.org
Severity: minor

Thanks for maintaining jenkins!

https://tests.reproducible-builds.org/debian/index_variations.html lists:

  Linux 4.9.0-6-armmp #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) armv7l
  Linux 4.9.0-6-armmp-lpae #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) armv7l

But no currently active systems are running these kernels. I suspect it
is some cached kernel version leftover from before several armhf systems
were removed (#903321: reproducible: Remove armhf systems with only 1GB
of ram).

I've also seen this happen when a system is down for a prolonged period
and the last known kernel was an older kernel, although the case could
be made that that's more-or-less correct.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#907496: libcurlpp0: Always fails with "No URL set!"

[Ted Percival]

Package: libcurlpp0
Version: 0.8.1-2+b1
Severity: grave
Justification: renders package unusable

libcurlpp0 appears to always fail with a "No URL set!" error message.
I only tested the "Easy" API.

For example even the first example in its repo

doesn't work:

$ g++ -Wall example00.cpp `curlpp-config --cflags --libs` `curl-config --cflags 
--libs`
$ ./a.out 
No URL set!

I recompiled libcurlpp using both 7 & 8[1] and when linking the example program 
to
the new build it works fine (both static & dynamic libs). So I'm not sure where
the problem lies but even after reinstalling the Debian package I could only get
it to work with my local libcurlpp.

[1] GCC package versions:
g++-7: 7.3.0-28
g++-8: 4:8.2.0-1

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

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

Versions of packages libcurlpp0 depends on:
ii  libc6   2.27-5
ii  libcurl47.61.0-1
ii  libgcc1 1:8.2.0-4
ii  libstdc++6  8.2.0-4

libcurlpp0 recommends no packages.

libcurlpp0 suggests no packages.

-- no debconf information

Bug#906816: thunderbird: Does not start

[Carsten Schoenert]

Hello Torbjörn,

On Tue, Aug 28, 2018 at 06:38:03PM +0200, Torbjörn Andersson wrote:
> For what it's worth, Thunderbird 60.0-2 doesn't start for me either. I tried
> following the instructions in the Debian Wiki, and this is what I found:
> 
> Only Thunderbird has changed. If I reinstall 52.9.1-1, the crash goes away.

well, it's of course possible that internally something has changed that
way you or the other reporters will see now a crash.

> Safe mode makes no difference.

O.k. Than we can exclude some problems which might come along with
AddOns which are now incompatible.

> Starting with a dummy profile (where I haven't even tried to set up any mail
> server or access my old mail) does work. I haven't tried setting up a proper
> profile yet.

Thanks for checking this, by this we can probably also exclude some
AppArmor misbehavior. This is unlikely nevertheless if you did not have
issues with AppArmor and the previous Thunderbird ESR version.

> Sometimes I do get AppArmor messages about Thunderbird in "dmesg", but not
> every time I start so I don't know if they're relevant. I did try disabling
> AppArmor, but it didn't make any difference. I may have done it wrong,
> though.

No, you don't have done anything wrong. For AppArmor it's mostly easy to
see, Thunderbird is usable or not. For a more detailed answer the
messages you have got would be needed. I guess these are not related to
this bug report.

> I wanted to try "thunderbird -g", as suggested by the man page, but I don't
> have thunderbird-dbgsym installed, and it doesn't seem to be available for
> amd64 in sid.

It is, but you need to add an additional source to your sources.list. I
added a hint into the output of 'thunderbird -help' right now, you are
the first person who spotted this issue.

> Even if it was, there doesn't seem to be any run-mozilla.sh script
> with the new version of Thunderbird, though there is one in the old
> version. By the way, "thunderbird --help" says it's thunderbird-dbg I
> need, but that doesn't seem to exist either.

Yes, the next issue you have found. thunderbird-dbg is now migrated to
thunderbird-dbgsym. I changed this too within the starting wrapper and
man page file. Will be fixed within the next upload.

So, what di you need to do now?

You need to add an extra line to your sources.list, pick the entry for
unstable from here:

  https://wiki.debian.org/SourcesList#Debug_Symbol_Packages

Next update the package list as usual by 'sudo apt update' and install
the dbgsym for thunderbird.

 $ sudo apt install -t unstable thunderbird-dbgsym

Next you need to call gdb manually as the wrapper script needs to
modified first.

 $ gdb -ex run /usr/lib/thunderbird/thunderbird

Please be patient, thew start of thunderbird take significantly longer
as usual. If you don't want to start thunderbird directly remove the
options '-ex run'.

> Since I was out of any better ideas, I ran it through strace. This piece of
> the output may be relevant:

Yeah, good try and catch!

> lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/home/d91tan", {st_mode=S_IFDIR|0700, st_size=12288, ...}) = 0
> lstat("/home/d91tan/.thunderbird", {st_mode=S_IFDIR|S_ISGID|0755,
> st_size=4096, ...}) = 0
> lstat("/home/d91tan/.thunderbird/rhu4a0c1.default",
> {st_mode=S_IFDIR|S_ISGID|0700, st_size=4096, ...}) = 0
> lstat("/home/d91tan/.thunderbird/rhu4a0c1.default/Mail",
> {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
> lstat("/home/d91tan/.thunderbird/rhu4a0c1.default/Mail/Local Folders",
> {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
> access("/home/d91tan/.thunderbird/rhu4a0c1.default/Mail/Local Folders",
> F_OK) = 0
> stat("/home/d91tan/.thunderbird/rhu4a0c1.default/Mail/Local Folders",
> {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
> openat(AT_FDCWD, "/home/d91tan/.thunderbird/rhu4a0c1.default/Mail/Local
> Folders", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 45
> fstat(45, {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
> getdents(45, /* 91 entries */, 32768)   = 3016
> getdents(45, /* 0 entries */, 32768)= 0
> close(45)   = 0
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
> unlink("/home/d91tan/.thunderbird/rhu4a0c1.default/lock") = 0
> close(8)= 0
> 
> Temporarily moving ~/.thunderbird /rhu4a0c1.default/Mail/Local Folder out of
> the way did allow me to start Thunderbird. Unfortunately, "Local Folders" is
> apparently where my main mailbox resides, so that's not a good workaround.
> (I'm using POP, not IMAP, so my mail is stored locally.)
> 
> Any suggestions for where I go from here?

Yes, the line gdb is showing were thunderbird is crashing is the
interesting part, I'm sure this will show us an upstream issue. I see a
small possibility that gcc8 might be the root for this crash. But then I
also expect we would see a lot more bug reports related to thunderbird
crashes.

If the other reporters 

Bug#907495: please ship the x11idle binary

[Antoine Beaupre]

Package: org-mode
Version: 9.1.14+dfsg-1
Severity: wishlist

The org-mode "timetracker" has a feature to detect idle time in X11
which relies on the `x11idle` binary:

https://orgmode.org/manual/Resolving-idle-time.html#FOOT84

That program is actually shipped with the org-mode source packaged in
Debian, in ./contrib/scripts/x11idle.c but is not shipped in the
Debian package.

I frequently have to recompile this program by hand and reinstall it
in /usr/local/bin. That's silly and whenever I cleanup that /usr/local
(which always ends up being a mess), this is one of the precious
little cluttery things I need to remember to keep.

Could we ship this with the package please? Maybe as a separate binary
package? It can be built with:

gcc -l X11 -l Xss x11idle.c -o x11idle

I'd be happy to provide a patch if you are open to this idea.

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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.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 org-mode depends on:
ii  elpa-org  9.1.14+dfsg-1

org-mode recommends no packages.

org-mode suggests no packages.

-- debconf-show failed

Bug#907494: hgsvn: package is missing most of its files

[Nick Smallbone]

Package: hgsvn
Version: 0.1.8-1.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After installing hgsvn, I tried to run hgimportsvn but was greeted
with:

% hgimportsvn
zsh: command not found: hgimportsvn

A closer look reveals that the package does not actually install
hgsvn. For some reason, it only includes the manpages and
documentation. Here is the output of dpkg -L hgsvn - notice the empty
/usr/bin directory:

/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/hgsvn
/usr/share/doc/hgsvn/changelog.Debian.gz
/usr/share/doc/hgsvn/buildinfo_all.gz
/usr/share/doc/hgsvn/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/hgimportsvn.1.gz
/usr/share/man/man1/hgpushsvn.1.gz
/usr/share/man/man1/hgpullsvn.1.gz
/usr/bin

Nick

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

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

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


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

Kernel: Linux 4.17.0-0.bpo.1-amd64 (SMP w/4 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: sysvinit (via /sbin/init)

Versions of packages hgsvn depends on:
ii  mercurial 4.0-1+deb9u1
ii  python2.7.13-2
ii  python-pkg-resources  33.1.1-1
ii  subversion1.9.5-1+deb9u2

hgsvn recommends no packages.

hgsvn suggests no packages.

-- no debconf information

Bug#891063:

[Chris Waters]

On Sun, Aug 26, 2018 at 2:57 PM Vincent Lefevre  wrote:
>
> On 2018-08-24 18:04:29 -0700, Chris Waters wrote:
> > Ok, sorry that I can't remember *all* the ways that "su" without a
> > login option is broken. Even with that, it's still plenty broken, as
> > you have observed,
>
> No, it had worked very well for *years*, until it got broken by
> dconf. That's dconf that introduced the breakage.

The fact that it had worked for years doesn't mean it was ever safe or
reliable. Lots of things can work for years while having the potential
for great disaster: race conditions, unsanitized input, etc. Calling
su without the login option is just one more of those.

> > There are simply too many things that can break when you have random
> > environment variables left around pointing who-knows-where.
>
> In general, that's the problem of the end user. The problem here is
> that environment variables are set behind his back.

Programs are allowed to use the environment to communicate with each
other. Programs *do*. If you assume they won't, you're likely to
experience more "breakage". The problem is not with these programs;
the problem is with your assumptions.

> I've reported a bug against su:

The behavior of su is defined by POSIX and the Single User Spec. It's
not a bug.

> And you're suggesting sudo while there will be the same issue.

No. The sudo -e option doesn't run your editor as root; it makes a
temporary copy, allows you to edit that *as yourself*, then copies the
file back as root. So there's no problem.

On the other hand, if you *don't* use the -e option (which I've never
used), and just say "sudo emacs", then the environment is properly
cleaned up, but the working directory remains. Which seems to be
exactly what you were trying to achieve in the first place.

But we're drifting off topic, which is emacs itself. There are, as you
can see, many many ways to avoid the problem you experienced. Which
was caused by your reliance on unsafe behavior. Not a bug in emacs.

Bug#882557: signon-ui FTBFS on amd64: SignOnUiTest::testRequestWithIndicator() Received signal 11

[Santiago Vila]

On Fri, 24 Nov 2017, Adrian Bunk wrote:

> Source: signon-ui
> Version: 0.17+15.10.20150810-2
> Severity: serious
> Tags: buster sid
> 
> Some recent change in unstable makes signon-ui FTBFS on amd64:
> 
> https://tests.reproducible-builds.org/debian/history/signon-ui.html
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/signon-ui.html

This is very strange. I can't reproduce this anymore in buster.

If the reason for this is some buggy build-dependency which is now fixed,
such build-dependency (whatever it is) probably entered testing
between 2018-08-13 and 2018-08-24 (according to my build logs).

Thanks.

Bug#907486: libpam-systemd: Depends: systemd-shim (>= 10-4~) but it is not going to be installed

[Michael Biebl]

On 8/28/18 19:59, Felipe Sateler wrote:
> On Tue, Aug 28, 2018, 14:00 Robbie Harwood  > wrote:

> This would make systemd-shim unusable.
> 
> 
> Indeed. See bugs #901404 and #901405 for things that need to be fixed in
> 10-4. Systemd-shim is currently broken, and is not working in its
> current form. 

Aside from those two bugs there is also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895292 which needs to
be addressed before systemd-shim is functional again.

Unfortunately we don't really have anyone still caring for the sysvinit
related bits in Debian.
So for, it has been mostly the systemd team which kept sysvinit on life
support, but we no longer have the time  for that.

-- 
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#907493: ghostscript breaks cups autopkgtest: test times out

[Paul Gevers]

Source: ghostscript, cups
Version: ghostscript/9.22~dfsg-3
Version: cups/2.2.8-5
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update timeout

Dear maintainers,

With a recent upload of ghostscript the autopkgtest of cups started to
fail in testing and unstable due to the test timing out. It now takes
more than 2:47 hours to complete the test, while in the past it ran
typically slightly more than 6 minutes.

As ghostscript was uploaded with urgency high this regression is NOT
delaying of the migration of ghostscript to testing [1] and cups will be
hit by this in testing tomorrow. I have assigned the bug to both
packages. Could you please investigate the situation and reassign the
bug to the right package? If needed, please change the bug's severity as
appropriate.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ghostscript

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cups/894494/log.gz



signature.asc
Description: OpenPGP digital signature

Bug#907489: sambamba FTBFS

[Andreas Tille]

Control: tags -1 help

Hi Matthias,

do you have any idea?  Its most probably connected to the
libbiod bug.

Kind regards

 Andreas.

On Tue, Aug 28, 2018 at 08:32:32PM +0300, Adrian Bunk wrote:
> Source: sambamba
> Version: 0.6.7-2
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sambamba.html
> 
> ...
> [5/74] ldc2 -Isambamba@exe -I. -I.. -I/usr/include/d -enable-color -O -g 
> -release -wi   -of 'sambamba@exe/sambamba_sort.d.o' -c ../sambamba/sort.d
> FAILED: sambamba@exe/sambamba_sort.d.o 
> ldc2 -Isambamba@exe -I. -I.. -I/usr/include/d -enable-color -O -g -release 
> -wi   -of 'sambamba@exe/sambamba_sort.d.o' -c ../sambamba/sort.d
> /usr/lib/ldc/x86_64-linux-gnu/include/d/std/numeric.d(1845): Error: 
> read-modify-write operations are not allowed for `shared` variables. Use 
> `core.atomic.atomicOp!"+="(s, e)` instead.
> /usr/lib/ldc/x86_64-linux-gnu/include/d/std/numeric.d(1871): Error: 
> read-modify-write operations are not allowed for `shared` variables. Use 
> `core.atomic.atomicOp!"*="(e, f)` instead.
> ../sambamba/sort.d(427): Error: template instance 
> `std.numeric.normalize!(shared(float)[])` error instantiating
> ../sambamba/sort.d(265):instantiated from here: 
> `mergeSortedChunks!(compareReadNames)`
> ../sambamba/sort.d(445): Error: forward reference to inferred return type of 
> function call `function (ulong j)
> {
> return (lazy float progress)
> {
> atomicStore(merging_progress[j], progress);
> synchronized(bar) {
> bar.update(dotProduct(merging_progress, weights));
> }
> }
> ;
> }
> (i)`
> ../sambamba/sort.d(267): Error: template instance 
> `sambamba.sort.Sorter.mergeSortedChunks!(mixedCompareReadNames)` error 
> instantiating
> ../sambamba/sort.d(269): Error: template instance 
> `sambamba.sort.Sorter.mergeSortedChunks!(compareCoordinatesAndStrand)` error 
> instantiating
> [6/74] ldc2 -Isambamba@exe -I. -I.. -I/usr/include/d -enable-color -O -g 
> -release -wi   -of 'sambamba@exe/sambamba_merge.d.o' -c ../sambamba/merge.d
> FAILED: sambamba@exe/sambamba_merge.d.o 
> ldc2 -Isambamba@exe -I. -I.. -I/usr/include/d -enable-color -O -g -release 
> -wi   -of 'sambamba@exe/sambamba_merge.d.o' -c ../sambamba/merge.d
> /usr/lib/ldc/x86_64-linux-gnu/include/d/std/numeric.d(1845): Error: 
> read-modify-write operations are not allowed for `shared` variables. Use 
> `core.atomic.atomicOp!"+="(s, e)` instead.
> /usr/lib/ldc/x86_64-linux-gnu/include/d/std/numeric.d(1871): Error: 
> read-modify-write operations are not allowed for `shared` variables. Use 
> `core.atomic.atomicOp!"*="(e, f)` instead.
> ../sambamba/merge.d(407): Error: template instance 
> `std.numeric.normalize!(shared(float)[])` error instantiating
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#907492: pam should use build profiles

[Helmut Grohne]

Source: pam
Version: 1.1.8-3.8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

pam was one of the early adopters when it came to build profiles. That
is why it uses the singular DEB_BUILD_PROFILE rather than the current
DEB_BUILD_PROFILES. It also does not annotate Build-Depends.

Given that build profiles are quite well supported now, I think it is
time to update pam. Let me propose the attached patch to that end.

 * Use DEB_BUILD_PROFILES rather than DEB_BUILD_PROFILE.
 * Rename the profile from stage1 to a more descriptive pkg.pam.noaudit.
 * Support unknown profiles (e.g. nocheck in addition to
   pkg.pam.noaudit)
 * Annotate droppable Build-depends.

Helmut
diff -u pam-1.1.8/debian/changelog pam-1.1.8/debian/changelog
--- pam-1.1.8/debian/changelog
+++ pam-1.1.8/debian/changelog
@@ -1,3 +1,11 @@
+pam (1.1.8-3.9) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert DEB_BUILD_PROFILE=stage1 to DEB_BUILD_PROFILES=pkg.pam.noaudit.
+(Closes: #-1)
+
+ -- Helmut Grohne   Tue, 28 Aug 2018 19:19:35 +0200
+
 pam (1.1.8-3.8) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u pam-1.1.8/debian/control pam-1.1.8/debian/control
--- pam-1.1.8/debian/control
+++ pam-1.1.8/debian/control
@@ -4,7 +4,7 @@
 Uploaders: Sam Hartman , Roger Leigh 
 Maintainer: Steve Langasek 
 Standards-Version: 3.9.8
-Build-Depends: libcrack2-dev (>= 2.8), bzip2, debhelper (>= 9), quilt (>= 
0.48-1), flex, libdb-dev, libselinux1-dev [linux-any], po-debconf, 
dh-autoreconf, autopoint, libaudit-dev [linux-any], pkg-config, libfl-dev, 
libfl-dev:native, docbook-xsl, docbook-xml, xsltproc, libxml2-utils, w3m
+Build-Depends: libcrack2-dev (>= 2.8), bzip2, debhelper (>= 9), quilt (>= 
0.48-1), flex, libdb-dev, libselinux1-dev [linux-any], po-debconf, 
dh-autoreconf, autopoint, libaudit-dev [linux-any] , 
pkg-config, libfl-dev, libfl-dev:native, docbook-xsl, docbook-xml, xsltproc, 
libxml2-utils, w3m
 Build-Conflicts-Indep: fop
 Build-Conflicts: libdb4.2-dev, libxcrypt-dev
 Vcs-Bzr: https://alioth.debian.org/scm/loggerhead/pkg-pam/debian/sid
diff -u pam-1.1.8/debian/rules pam-1.1.8/debian/rules
--- pam-1.1.8/debian/rules
+++ pam-1.1.8/debian/rules
@@ -21,7 +21,7 @@
dh $@ --with quilt,autoreconf
 
 # avoid libaudit-dev when bootstrapping
-ifneq (,$(filter $(DEB_BUILD_PROFILE),stage1))
+ifneq (,$(filter pkg.pam.noaudit,$(DEB_BUILD_PROFILES)))
   CONFIGURE_OPTS += --disable-audit
 endif  
 

Bug#876759: daisy-player: Broken autopkgtest

[Paul Gevers]

Hi Jos,

You as the creator of daisy-player do not really need to care about
autopkgtest, which is something we can add in Debian to test installed
Debian packages. In practice these autopkgtests often run test suites
that are created and maintained upstream (the creators), but often also
not. In the case of daisy-player, I tried to call "daisy-player -h" to
see if the package could at least be found and return the help page
(that is one of the reasons why I asked you to add that).

So unless you want to add a test suite to daisy-player (please do so if
you feel comfortable; and similar to ebook-speaker) you as upstream can
ignore this bug. However, before you add data to the source to actually
test, consider copyright and license of the data. For autopkgtest we
could add wget/curl commands to get things from the daisy site if you
would want to use that.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#907491: goobook fails to authenticate

[Sergio Mendoza]

Package: goobook
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'm running debian unstable.  I have not been able to work properly with
goobook and can't find a solution for it.  It requires immediate assitance.
This is happening in all computers I have with Debian (quite a few):

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

>

Cheers,

Sergio



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

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

Versions of packages goobook depends on:
ii  python2.7.15-3
ii  python-gdata  2.0.18+dfsg1-2
ii  python-httplib2   0.9.2+dfsg-1
ii  python-oauth2client   4.1.2-3
ii  python-pkg-resources  39.2.0-1
ii  python-setuptools 39.2.0-1
ii  python-simplejson 3.15.0-1+b1

goobook recommends no packages.

Versions of packages goobook suggests:
ii  python-keyring  13.1.0-1

Bug#907486: libpam-systemd: Depends: systemd-shim (>= 10-4~) but it is not going to be installed

[Michael Biebl]

Control: reassign -1 systemd-shim
Control: forcemerge 903295 -1

On 8/28/18 18:56, Robbie Harwood wrote:
> Package: libpam-systemd
> Version: 238-5
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> (This bug has been reported also against systemd-shim:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903295 )
> 
> libpam-systemd requires systemd-shim version >=10-4~.  No such version exists.
> 
> This would make systemd-shim unusable.
> 

sytemd-shim is currently unusable, that's why there is such a versioned
dependency. Someone needs to make a 10-4 upload for systemd-shim which
fixes the package.
Re-assigning to systemd-shim, since there is nothing that can be done
about this in libpam-systemd.


-- 
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#907486: libpam-systemd: Depends: systemd-shim (>= 10-4~) but it is not going to be installed

[Felipe Sateler]

Control: forcemerge 903295 -1

On Tue, Aug 28, 2018, 14:00 Robbie Harwood  wrote:

> Package: libpam-systemd
> Version: 238-5
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> (This bug has been reported also against systemd-shim:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903295 )
>

Merging with that report, since it is systemd-shim that needs fixing. There
is no need to file additional reports.



> libpam-systemd requires systemd-shim version >=10-4~.  No such version
> exists.
>
> This would make systemd-shim unusable.
>

Indeed. See bugs #901404 and #901405 for things that need to be fixed in
10-4. Systemd-shim is currently broken, and is not working in its current
form.

Saludos

Bug#902470: Status?

[olivier sallou]

Cool, thanks

Le mar. 28 août 2018 à 18:46, Alexandre Viau  a écrit :

> On Sat, 25 Aug 2018 19:44:12 +0200 olivier sallou 
> wrote:
> > Hi,
> > My packages have been removed from testing due to this bug.
> > Can we remove failing test and lower bug severity waiting for upstream
> fix?
>
> I have uploaded a fix.
>
> Cheers,
>
> --
> Alexandre Viau
> av...@debian.org
>
>

Bug#907490: gnome-shell: Unrecoverable failure in required component org.gnome.Shell.desktop

[william l-k]

Package: gnome-shell
Version: 3.28.3-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,


After a recent power failure lasting multiple hours, the battery backup on my
laptop ran out of power and the system shut down. Once power was restored and I
restarted the machine, I booted into a minimal GUI with black background and
x-cursor. Without gnome controls, I was unable to get a terminal from the
minimal session, so I switched to another tty. From there I was able to
troubleshoot.

None of the following solved the problem:

rebooting
update/upgrade then rebooting
merging last lvm-snapshot of the root directory
alt +f2 and then r
sudo systemctl restart gdm
killall -HUP gnome-shell
sudo systemctl restart gdm

>From GDM controls:
trying default x11 and gnome

Trying alternate kernel


The portion of the log near the times of start attempts had sections like
these:


Aug 28 10:13:07 Username gnome-session-binary[8534]: Unrecoverable failure in
required component org.gnome.SettingsDaemon.Power.desktop
Aug 28 10:13:07 Username dbus-daemon[603]: [system] Activating via systemd:
service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostna
Aug 28 10:13:07 Username gnome-session-binary[8534]: Unrecoverable failure in
required component org.gnome.SettingsDaemon.XSettings.desktop
Aug 28 10:13:07 Username gnome-session-binary[8534]: WARNING: App
'org.gnome.SettingsDaemon.Wacom.desktop' exited with code 1
Aug 28 10:13:07 Username gnome-session-binary[8534]: WARNING: App
'org.gnome.SettingsDaemon.Clipboard.desktop' exited with code 1
Aug 28 10:13:07 Username gnome-session[8534]: Unable to init server: Could not
connect: Connection refused
Aug 28 10:13:07 Username unknown[8630]: Cannot open display:
Aug 28 10:13:07 Username dbus-daemon[8532]: [session uid=1000 pid=8532]
Activating via systemd: service name='org.gtk.vfs.Daemon' unit='gvfs-daemon.se
Aug 28 10:13:07 Username gnome-session[8534]: Unable to init server: Could not
connect: Connection refused
Aug 28 10:13:07 Username unknown[8635]: Cannot open display:
Aug 28 10:13:07 Username gnome-session-binary[8534]: WARNING: App
'org.gnome.SettingsDaemon.Keyboard.desktop' exited with code 1
Aug 28 10:13:07 Username org.gnome.SettingsDaemon.Mouse.desktop[8606]: Unable
to init server: Could not connect: Connection refused
Aug 28 10:13:07 Username gnome-session[8534]: gnome-session-binary[8534]:
WARNING: App 'org.gnome.SettingsDaemon.MediaKeys.desktop' exited with code 1
Aug 28 10:13:07 Username gnome-session[8534]: gnome-session-binary[8534]:
WARNING: App 'org.gnome.SettingsDaemon.Wacom.desktop' exited with code 1
Aug 28 10:13:07 Username gnome-session[8534]: gnome-session-binary[8534]:
WARNING: App 'org.gnome.SettingsDaemon.Wacom.desktop' respawning too quickly
Aug 28 10:13:07 Username gnome-session[8534]: gnome-session-binary[8534]:
WARNING: App 'org.gnome.SettingsDaemon.Clipboard.desktop' exited with code 1
Aug 28 10:13:07 Username gnome-session[8534]: gnome-session-binary[8534]:
WARNING: App 'org.gnome.SettingsDaemon.Clipboard.desktop' respawning too qui
Aug 28 10:13:07 Username systemd[1]: Starting Time & Date Service...
Aug 28 10:13:07 Username org.gnome.SettingsDaemon.MediaKeys.desktop[8609]:
Cannot open display:
Aug 28 10:13:07 Username gnome-session-binary[8534]: WARNING: App
'org.gnome.SettingsDaemon.Color.desktop' exited with code 1
Aug 28 10:13:07 Username unknown[8638]: cannot open display:
Aug 28 10:13:07 Username gnome-session[8534]: gnome-session-binary[8534]:
WARNING: App 'org.gnome.SettingsDaemon.Keyboard.desktop' exited with code 1
Aug 28 10:13:07 Username gnome-session[8534]: gnome-session-binary[8534]:
WARNING: App 'org.gnome.SettingsDaemon.Keyboard.desktop' respawning too quic
Aug 28 10:13:07 Username gnome-session[8534]: gnome-session-binary[8534]:
WARNING: App 'org.gnome.SettingsDaemon.Color.desktop' exited with code 1
Aug 28 10:13:07 Username gnome-session[8534]: gnome-session-binary[8534]:
WARNING: App 'org.gnome.SettingsDaemon.Color.desktop' respawning too quickly
Aug 28 10:13:07 Username gnome-session-binary[8534]: WARNING: App
'org.gnome.SettingsDaemon.Power.desktop' exited with code 1
Aug 28 10:13:07 Username gnome-session-binary[8534]: Unrecoverable failure in
required component org.gnome.SettingsDaemon.Wacom.desktop
Aug 28 10:13:07 Username org.gnome.SettingsDaemon.Power.desktop[8613]: Cannot
open display:
Aug 28 10:13:07 Username gnome-session-binary[8534]: WARNING: App
'org.gnome.SettingsDaemon.Power.desktop' respawning too quickly
Aug 28 10:13:07 Username gnome-session-binary[8534]: Unrecoverable failure in
required component org.gnome.SettingsDaemon.Clipboard.desktop
Aug 28 10:13:07 Username gnome-session-binary[8534]: WARNING: App
'org.gnome.SettingsDaemon.XSettings.desktop' exited with code 1
Aug 28 10:13:07 Username gnome-session-binary[8534]: Unrecoverable failure in
required component org.gnome.SettingsDaemon.Keyboard.desktop
Aug 28 10:13:07 Username 

Bug#907489: sambamba FTBFS

[Adrian Bunk]

Source: sambamba
Version: 0.6.7-2
Severity: serious
Tags: ftbfs

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

...
[5/74] ldc2 -Isambamba@exe -I. -I.. -I/usr/include/d -enable-color -O -g 
-release -wi   -of 'sambamba@exe/sambamba_sort.d.o' -c ../sambamba/sort.d
FAILED: sambamba@exe/sambamba_sort.d.o 
ldc2 -Isambamba@exe -I. -I.. -I/usr/include/d -enable-color -O -g -release -wi  
 -of 'sambamba@exe/sambamba_sort.d.o' -c ../sambamba/sort.d
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/numeric.d(1845): Error: 
read-modify-write operations are not allowed for `shared` variables. Use 
`core.atomic.atomicOp!"+="(s, e)` instead.
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/numeric.d(1871): Error: 
read-modify-write operations are not allowed for `shared` variables. Use 
`core.atomic.atomicOp!"*="(e, f)` instead.
../sambamba/sort.d(427): Error: template instance 
`std.numeric.normalize!(shared(float)[])` error instantiating
../sambamba/sort.d(265):instantiated from here: 
`mergeSortedChunks!(compareReadNames)`
../sambamba/sort.d(445): Error: forward reference to inferred return type of 
function call `function (ulong j)
{
return (lazy float progress)
{
atomicStore(merging_progress[j], progress);
synchronized(bar) {
bar.update(dotProduct(merging_progress, weights));
}
}
;
}
(i)`
../sambamba/sort.d(267): Error: template instance 
`sambamba.sort.Sorter.mergeSortedChunks!(mixedCompareReadNames)` error 
instantiating
../sambamba/sort.d(269): Error: template instance 
`sambamba.sort.Sorter.mergeSortedChunks!(compareCoordinatesAndStrand)` error 
instantiating
[6/74] ldc2 -Isambamba@exe -I. -I.. -I/usr/include/d -enable-color -O -g 
-release -wi   -of 'sambamba@exe/sambamba_merge.d.o' -c ../sambamba/merge.d
FAILED: sambamba@exe/sambamba_merge.d.o 
ldc2 -Isambamba@exe -I. -I.. -I/usr/include/d -enable-color -O -g -release -wi  
 -of 'sambamba@exe/sambamba_merge.d.o' -c ../sambamba/merge.d
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/numeric.d(1845): Error: 
read-modify-write operations are not allowed for `shared` variables. Use 
`core.atomic.atomicOp!"+="(s, e)` instead.
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/numeric.d(1871): Error: 
read-modify-write operations are not allowed for `shared` variables. Use 
`core.atomic.atomicOp!"*="(e, f)` instead.
../sambamba/merge.d(407): Error: template instance 
`std.numeric.normalize!(shared(float)[])` error instantiating

Bug#907488: gitlab: post-inst fails: Could not find gem 'rugged (~> 0.26.0)'

[Pikrass]

Package: gitlab
Version: 10.6.5+dfsg-2
Severity: serious

Dear Maintainer,

The post-inst script consistently fails for me with unstable's current
gitlab package. I tested this with two systems (one buster/sid and one
sid).

Installation log follows.

8<--

Setting up gitlab (10.6.5+dfsg-2) ...
Creating/updating git user account...
Making git owner of /var/lib/gitlab...
Could not find gem 'rugged (~> 0.26.0)' in any of the gem sources listed
in your Gemfile.
dpkg: error processing package gitlab (--configure):
 installed gitlab package post-installation script subprocess returned
 error exit status 1
 Errors were encountered while processing:
  gitlab

>8--

I think the problem comes from the dependency on ruby-rugged, which is
pinned to ">= 0.26~".
The package in buster and sid is at version 0.27.4+ds-1.
The Gemfile, however, pins it to "~> 0.26.0", meaning that versions 0.27
and superior aren't acceptable.


Kind regards,
Pikrass.


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

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

Versions of packages gitlab depends on:
ii  adduser3.117
ii  asciidoctor1.5.7.1-1
ii  bc 1.07.1-2+b1
ii  bundler1.16.1-3
ii  dbconfig-pgsql 2.0.9
ii  debconf [debconf-2.0]  1.5.69
ii  exim4-daemon-heavy [mail-transport-agent]  4.91-6
ii  git1:2.18.0-1
ii  gitlab-shell   7.1.2+dfsg-2
ii  gitlab-workhorse   4.3.1+debian-1
ii  lsb-base   9.20170808
ii  nginx  1.13.12-1
ii  nginx-full [nginx] 1.13.12-1
ii  nodejs 8.11.2~dfsg-1
ii  npm5.8.0+ds-2
ii  openssh-client 1:7.7p1-4
ii  postgresql-client  10+193
ii  postgresql-client-10 [postgresql-client]   10.5-1
ii  postgresql-contrib 10+193
ii  rake   12.3.1-3
ii  redis-server   5:4.0.11-2
ii  ruby   1:2.5.1
ii  ruby-ace-rails-ap  4.1.1-1
ii  ruby-acts-as-taggable-on   5.0.0-2
ii  ruby-addressable   2.5.2-1
ii  ruby-akismet   2.0.0-1
ii  ruby-allocations   1.0.3-1+b4
ii  ruby-arel  6.0.4-1
ii  ruby-asana 0.6.0-1
ii  ruby-asciidoctor-plantuml  0.0.8-1
ii  ruby-asset-sync2.4.0-1
ii  ruby-attr-encrypted3.1.0-1
ii  ruby-babosa1.0.2-2
ii  ruby-base320.3.2-3
ii  ruby-batch-loader  1.2.1-1
ii  ruby-bcrypt-pbkdf  1.0.0-1+b2
ii  ruby-bootstrap-form2.7.0-1
ii  ruby-bootstrap-sass3.3.5.1-5.1
ii  ruby-browser   2.2.0-2
ii  ruby-carrierwave   1.2.2-1
ii  ruby-charlock-holmes   0.7.5-1+b2
ii  ruby-chronic   0.10.2-3
ii  ruby-chronic-duration  0.10.6-1
ii  ruby-commonmarker  0.17.9-1
ii  ruby-connection-pool   2.2.0-1
ii  ruby-creole0.5.0-2
ii  ruby-d3-rails  3.5.6+dfsg-1
ii  ruby-default-value-for 3.0.1-1
ii  ruby-devise4.4.3-1
ii  ruby-devise-two-factor 3.0.0-2
ii  ruby-diffy 3.2.1-1
ii  ruby-doorkeeper4.4.2-1
ii  ruby-doorkeeper-openid-connect 1.3.0-1
ii  ruby-dropzonejs-rails  0.7.1-1
ii  ruby-email-reply-trimmer   0.1.6-1
ii  ruby-escape-utils  1.2.1-1+b1
ii  ruby-excon 0.60.0-1
ii  ruby-faraday   0.13.1-2
ii  ruby-fast-blank1.0.0-1+b1
ii  ruby-flipper   0.13.0-3
pn  ruby-flipper-active-record 
pn  

Bug#582630: logrotate fails on missing logfiles even when it shouldn't

[Holger Levsen]

Hi Christian,

thanks for your heads up!

On Wed, Aug 22, 2018 at 11:22:44PM +0200, Christian Göttsche wrote:
> I tested a non-existing directory with version 3.14.0-2 and the
> configuration option missinok.
> That resulted in no error.
> Also I ran piuparts on munge_0.5.13-1_amd64.deb and the logrotate
> tests all succeed.

nice!

> Can you reproduce any of this issue with version 3.14.0-2 or newer?

I've just done
https://salsa.debian.org/debian/piuparts/commit/e931a77a7c19cbb1584bf5f65ac885ed0c581fd4
"Enable the logrotate-test again, see #582630. (Closes: #604807)" and am
now deploying this to piuparts.debian.org, so in a few days we should
have some results.

I'm just wondering whether we'll now find packages which should use
'missingok' but are not using it...


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


signature.asc
Description: PGP signature

Bug#907487: Broken patch debian/patches/unset_OS2_UseTypoMetrics.patch

[Jan-Marek Glogowski]

Package: fonts-liberation
Version: 1:1.07.4-7

Dear maintainers,

actually I was bitten by the bug fixed in 1:1.07.4-6 on Ubuntu 18.04
(https://bugs.launchpad.net/ubuntu/bionic/+source/libreoffice/+bug/1769654) and 
then I had a look at
the proposed fix / diff and saw in the unpatched debian package:

@@ -17,7 +17,7 @@ XUID: [1021 131 222397055 13598569]
 FSType: 0
 OS2Version: 3
 OS2_WeightWidthSlopeOnly: 0
-OS2_UseTypoMetrics: 1
+OS2_UseTypoMetrics 0
 CreationTime: 1095817380
 ModificationTime: 1399616628
 PfmFamily: 17

which looked broken. I guess it just works, because the default of 
OS2_UseTypoMetrics is 0, but I
didn't check that.

I checked Debian - same patch.

Then I had a look at the SRPM packages for the bug fix in Fedora, which isn't 
fixed by a patch at
all, but by:

# Fedora fix for https://bugzilla.redhat.com/show_bug.cgi?id=1526510
sed -i 's/OS2_UseTypoMetrics: 1/OS2_UseTypoMetrics: 0/g' src/*.sfd

The I had a look at the Fontforge code and found:
https://github.com/fontforge/fontforge/blob/master/fontforge/sfd.c#L7946

So I guess the binary result is the same, but just in case the generating font 
programs become more
strict, please fix the patch.

Thanks

Jan-Marek

Bug#907486: libpam-systemd: Depends: systemd-shim (>= 10-4~) but it is not going to be installed

[Robbie Harwood]

Package: libpam-systemd
Version: 238-5
Severity: grave
Justification: renders package unusable

Dear Maintainer,

(This bug has been reported also against systemd-shim:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903295 )

libpam-systemd requires systemd-shim version >=10-4~.  No such version exists.

This would make systemd-shim unusable.

root@hpsiddie:/home/manul# apt-get dist-upgrade -d sysvinit-core+ 
libpam-systemd+
Reading package lists... Done
Building dependency tree   
Reading state information... Done
sysvinit-core is already the newest version (2.88dsf-59.10).
Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libpam-systemd : Depends: systemd-shim (>= 10-4~) but it is not going to 
be installed or
   systemd-sysv but it is not going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused 
by held packages.

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

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

Versions of packages libpam-systemd depends on:
ii  dbus1.12.10-1
ii  libc6   2.27-5
ii  libpam-runtime  1.1.8-3.8
ii  libpam0g1.1.8-3.8
ii  systemd 238-5
ii  systemd-shim10-3

libpam-systemd recommends no packages.

libpam-systemd suggests no packages.

-- no debconf information

Bug#859234:

[Damyan Ivanov]

Package: firebird3.0-server
Version: 3.0.3.32900.ds4-4
Severity: normal
Submitter: pblndrssn...@gmail.com

-=| Pablo Sánchez[gmail], 28.08.2018 09:47:49 -0300 |=-
> Hi !
> Bug seems to be present on armhf (raspberry pi model 3+) .
> 
> In /var/log/syslog I get :
> ...
> Aug 28 00:04:34 raspberrypi systemd[1]: Started User Manager for UID 1001.
> Aug 28 00:04:43 raspberrypi fbguard[449]: Time out waiting for fbserver
> process start

This is not the same problem. Filing as a new one.

So you are saying that during system start-up, firebird3.0-server 
can't be started within the default timeout of 90 seconds? Is the 
system overloaded during that time?

If it starts fine later (presumably when the system is not 
overloaded), then perhaps you want to change the default service start 
timeout in /etc/systemd/system.conf (DefaultTimeoutStartSec).


-- dam

Bug#906816: thunderbird: Does not start

[Torbjörn Andersson]

For what it's worth, Thunderbird 60.0-2 doesn't start for me either. I 
tried following the instructions in the Debian Wiki, and this is what I 
found:


Only Thunderbird has changed. If I reinstall 52.9.1-1, the crash goes away.

Safe mode makes no difference.

Starting with a dummy profile (where I haven't even tried to set up any 
mail server or access my old mail) does work. I haven't tried setting up 
a proper profile yet.


Sometimes I do get AppArmor messages about Thunderbird in "dmesg", but 
not every time I start so I don't know if they're relevant. I did try 
disabling AppArmor, but it didn't make any difference. I may have done 
it wrong, though.


I wanted to try "thunderbird -g", as suggested by the man page, but I 
don't have thunderbird-dbgsym installed, and it doesn't seem to be 
available for amd64 in sid. Even if it was, there doesn't seem to be any 
run-mozilla.sh script with the new version of Thunderbird, though there 
is one in the old version. By the way, "thunderbird --help" says it's 
thunderbird-dbg I need, but that doesn't seem to exist either.


Since I was out of any better ideas, I ran it through strace. This piece 
of the output may be relevant:


lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/d91tan", {st_mode=S_IFDIR|0700, st_size=12288, ...}) = 0
lstat("/home/d91tan/.thunderbird", {st_mode=S_IFDIR|S_ISGID|0755, 
st_size=4096, ...}) = 0
lstat("/home/d91tan/.thunderbird/rhu4a0c1.default", 
{st_mode=S_IFDIR|S_ISGID|0700, st_size=4096, ...}) = 0
lstat("/home/d91tan/.thunderbird/rhu4a0c1.default/Mail", 
{st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
lstat("/home/d91tan/.thunderbird/rhu4a0c1.default/Mail/Local Folders", 
{st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
access("/home/d91tan/.thunderbird/rhu4a0c1.default/Mail/Local Folders", 
F_OK) = 0
stat("/home/d91tan/.thunderbird/rhu4a0c1.default/Mail/Local Folders", 
{st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/home/d91tan/.thunderbird/rhu4a0c1.default/Mail/Local 
Folders", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 45

fstat(45, {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
getdents(45, /* 91 entries */, 32768)   = 3016
getdents(45, /* 0 entries */, 32768)= 0
close(45)   = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
unlink("/home/d91tan/.thunderbird/rhu4a0c1.default/lock") = 0
close(8)= 0

Temporarily moving ~/.thunderbird /rhu4a0c1.default/Mail/Local Folder 
out of the way did allow me to start Thunderbird. Unfortunately, "Local 
Folders" is apparently where my main mailbox resides, so that's not a 
good workaround. (I'm using POP, not IMAP, so my mail is stored locally.)


Any suggestions for where I go from here?

Regards,

Torbjörn Andersson