Bug#903748: wayland: Please include debian/changelog entry for 1.14.0-2 upload

[Salvatore Bonaccorso]

Source: wayland
Version: 1.15.0-1
Severity: normal

Hi

Please include the debian/changelog entry for the 1.14.0-2. Cf.
#892031 for details (the BTS version tracking got confused). As the
issue was fixed as well in 1.15.0-1 this information is adapted in the
bug metadata, but would be nice to not loose the information on the
CVE fix in the debian/changelog itself.

Regards,
Salvatore

Bug#892031: stretch-pu: package wayland/1.12.0-1

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo

Hi Adam,

On Tue, Jul 03, 2018 at 08:55:44PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sun, 2018-03-04 at 12:42 +0100, Héctor Orón Martínez wrote:
> >   I would like to apply fix in stable for #889681.
> > 
> 
> The metadata for that bug report suggests that it still applies to
> unstable, possibly because the current changelog is based on the
> experimental uploads and contains no reference to either the 1.14.0-2
> upload or #889681. Please confirm that the bug is actually fixed in
> unstable and fix up the metadata appropriately.

What I think what happened. The issue really was fixed with the
unstable upload as 1.14.0-2 
https://tracker.debian.org/news/937846/accepted-wayland-1140-2-source-into-unstable/

A later 1.15.0-1 upload did though not merged in the debian/changelog
information from 1.14.0-2 and that got lost, which is probably what
confused the BTS version tracking then because 1.14.0-2 not anymore
known.

Regards,
Salvatore

Bug#895537: stretch-pu: package libopenmpt/0.2.7386~beta20.3-3+deb9u3

[Salvatore Bonaccorso]

Hi James,

On Tue, Jul 03, 2018 at 09:07:29PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2018-04-12 at 11:42 +0100, James Cowgill wrote:
> > This fixes CVE-2018-10017 which is a security bug tagged as "no-DSA"
> > by the security team.
> > 
> > The fix is quite simple and looks correct to me. I've done some
> > testing to make sure things still work after this update.
> > 
> 
> Please go ahead; sorry for the delay.

Was now to late for 9.5, but to have it included in next one, can you
already upload it at your earliest possibility? Above is the ack from
Adam.

Regards,
Salvatore

Bug#903749: tracker.debian.org: Random packages are added to a team

[Giovanni Mascellani]

Package: tracker.debian.org
Severity: normal

Hi,

I created a team for packaging the Boost libraries:

  https://tracker.debian.org/teams/boost/

I manually added relevant Boost packages, but other random packages get
added. They other packages maintained or comaintained by me, which have
nothing to do with Boost (like haskell-* and mandelbulber2), and they
are automatically added to the Boost team when they are uploaded. I see
no logic behind this. Can this be disabled? Or, what did I do wrong?

Thanks for the awesome tracker, though, and have a nice day!

Giovanni.

Bug#903750: libreoffice-writer: XML document, minor ARIAL problem

[Hans-J. Ullrich]

Package: libreoffice
Version: 1:6.0.6~rc1-1
Severity: minor

Dear Maintainer,

I discovered a little issue in XML-Files.

Description: 

Do the following
1. Create a new XML Document
2. Create an input field
3. In the properties of that field, choose as Font "Arial"
4. Whemn you choose "Arial", the column named "Standard" changes to kyrillic 
signs. This happens only at font "Arial". Choose another font, the kyrillic 
changes back to "Standard".

Just a very tiny bug and maybe fixed easily. Just wanted to mention it.

Thanks for the great work.

Best regards

Hans



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

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

Versions of packages libreoffice depends on:
ii  libreoffice-avmedia-backend-gstreamer  1:6.0.6~rc1-1
ii  libreoffice-avmedia-backend-vlc1:6.0.6~rc1-1
ii  libreoffice-base   1:6.0.6~rc1-1
ii  libreoffice-calc   1:6.0.6~rc1-1
ii  libreoffice-core   1:6.0.6~rc1-1
ii  libreoffice-draw   1:6.0.6~rc1-1
ii  libreoffice-impress1:6.0.6~rc1-1
ii  libreoffice-math   1:6.0.6~rc1-1
ii  libreoffice-report-builder-bin 1:6.0.6~rc1-1
ii  libreoffice-writer 1:6.0.6~rc1-1
ii  python3-uno1:6.0.6~rc1-1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-7
ii  fonts-liberation2   2.00.1-7
pn  fonts-linuxlibertine
ii  fonts-noto-hinted   20171026-2
ii  fonts-noto-mono 20171026-2
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.0.6~rc1-1
ii  libreoffice-librelogo   1:6.0.6~rc1-1
ii  libreoffice-nlpsolver   0.9+LibO6.0.6~rc1-1
ii  libreoffice-ogltrans1:6.0.6~rc1-1
ii  libreoffice-report-builder  1:6.0.6~rc1-1
ii  libreoffice-script-provider-bsh 1:6.0.6~rc1-1
pn  libreoffice-script-provider-js  
ii  libreoffice-script-provider-python  1:6.0.6~rc1-1
ii  libreoffice-sdbc-postgresql 1:6.0.6~rc1-1
ii  libreoffice-wiki-publisher  1.2.0+LibO6.0.6~rc1-1

Versions of packages libreoffice suggests:
ii  cups-bsd 2.2.8-4
ii  firefox-esr  52.9.0esr-1
ii  ghostscript  9.22~dfsg-2.1
ii  gnupg2.2.8-3
pn  gpa  
ii  gstreamer1.0-libav   1.14.1-1
ii  gstreamer1.0-plugins-bad 1.14.1-1+b1
ii  gstreamer1.0-plugins-base1.14.1-1
ii  gstreamer1.0-plugins-good1.14.1-1
ii  gstreamer1.0-plugins-ugly1.14.1-1+b1
ii  hunspell-de-at [hunspell-dictionary] 20161207-5
ii  hunspell-de-ch [hunspell-dictionary] 20161207-5
ii  hunspell-de-de [hunspell-dictionary] 20161207-5
ii  hyphen-de [hyphen-hyphenation-patterns]  1:6.0.5-1
ii  imagemagick  8:6.9.9.34+dfsg-3+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.9.34+dfsg-3+b1
pn  libgl1   
pn  libreoffice-gnome
pn  libreoffice-grammarcheck 
pn  libreoffice-help 
pn  libreoffice-l10n 
pn  libreoffice-officebean   
ii  libsane  1.0.25-4.1
ii  libxrender1  1:0.9.10-1
ii  myspell-en-us [myspell-dictionary]   1:3.3.0-4+deb8u1
ii  mythes-de [mythes-thesaurus] 20160424-3
ii  openclipart-libreoffice  1:0.18+dfsg-14
ii  openjdk-8-jre8u171-b11-2
ii  pstoedit 3.73-1
ii  thunderbird  1:52.9.1-1
ii  unixodbc 2.3.6-0.1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.0-5
ii  fonts-opensymbol  2:102.10+LibO6.0.6~rc1-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-6
ii  libboost-locale1.62.0 1.62.0+dfsg-6
ii  libc6 2.27-3
ii  libcairo2 1.15.10-3
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.8-4
ii  libcurl3-gnutls   7.60.0-2
ii  libdbus-1-3   1.12.8-3
ii  libdbus-glib-1-2  0.110-2

Bug#903751: basket: please remove the extra libsoprano-dev build dependency

[Pino Toscano]

Source: basket
Version: 2.10~beta+git20160425.b77687f-1
Severity: normal
Tags: patch

Hi,

the libsoprano-dev build dependency was added in version
2.10~beta+git20150905.faa6dce-1; it is used to enable the nepomuk
integration, which is not actually enabled since the nepomuk libraries
are not available anymore (and shared-desktop-ontologies is not
installed either).

basket builds fine without the libsoprano-dev build dependency, so
please remove it. Patch attached for it.

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Debian KDE Extras Team 
 Uploaders: Mark Purcell , Sune Vuorela , 
Luigi Toscano 
 Build-Depends: debhelper (>= 9), pkg-kde-tools (>= 0.5), cmake, libx11-dev, 
pkg-config, libqimageblitz-dev,
- shared-mime-info, libsoprano-dev, kdelibs5-dev, kdepimlibs5-dev (>=4:4.4.3), 
libgpgme11-dev
+ shared-mime-info, kdelibs5-dev, kdepimlibs5-dev (>=4:4.4.3), libgpgme11-dev
 Homepage: http://basket.kde.org/
 Standards-Version: 3.9.8
 Vcs-Git: https://anonscm.debian.org/git/pkg-kde/kde-extras/basket.git

Bug#903752: override: xul-ext-ublock-origin:oldlibs/optional, chromium-ublock-origin:oldlibs/optional

[Laurent Bigonville]

Package: ftp.debian.org
Severity: normal

Hi,

Both xul-ext-ublock-origin and chromium-ublock-origin are now
transitional packages.

Could you please change the override to oldlibs/optional

Thanks,

Laurent Bigonville

Bug#903753: fonts-materialdesignicons-webfont: New package release

[Nicolas Évrard]

Package: fonts-materialdesignicons-webfont
Version: 1.4.57-1
Severity: wishlist

Hello,

While trying this package I noticed numerous icons that were missing
from the debian package that seems to be included on 
https://materialdesignicons.com/

It would be cool if the package was updated to contains the new icons.

Thanks for all the work anyway!


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

-- no debconf information

Bug#903754: pekwm: .pekwm/start file's execute permission was "Nobody" so it didn't work -no wallpaper etc. Changing it to "Anyone" solves the problem.

[Costas Ganis]

Package: pekwm
Version: 0.1.17-3
Severity: important

Dear Maintainer,

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

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

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



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

Kernel: Linux 4.16.0-0.bpo.2-amd64 (SMP w/2 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 pekwm depends on:
ii  libc62.24-11+deb9u3
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libpng16-16  1.6.28-1
ii  libstdc++6   6.3.0-18+deb9u1
ii  libx11-6 2:1.6.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxft2  2.3.2-1+b2
ii  libxinerama1 2:1.1.3-1+b3
ii  libxpm4  1:3.5.12-1
ii  libxrandr2   2:1.5.1-1
ii  menu 2.1.47+b1
ii  x11-utils7.7+3+b1

pekwm recommends no packages.

Versions of packages pekwm suggests:
ii  zenity  3.22.0-1+b1

-- no debconf information

Bug#895537: stretch-pu: package libopenmpt/0.2.7386~beta20.3-3+deb9u3

[Adam D. Barratt]

On Sat, 2018-07-14 at 09:09 +0200, Salvatore Bonaccorso wrote:
> Hi James,
> 
> On Tue, Jul 03, 2018 at 09:07:29PM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Thu, 2018-04-12 at 11:42 +0100, James Cowgill wrote:
> > > This fixes CVE-2018-10017 which is a security bug tagged as "no-
> > > DSA"
> > > by the security team.
> > > 
> > > The fix is quite simple and looks correct to me. I've done some
> > > testing to make sure things still work after this update.
> > > 
> > 
> > Please go ahead; sorry for the delay.
> 
> Was now to late for 9.5, but to have it included in next one, can you
> already upload it at your earliest possibility? Above is the ack from
> Adam.

This was uploaded during this week, which was sadly past the freeze
point for 9.5. It's in stable-new, so should get processed in the first
run through the queue after the point release.

Regards,

Adam

Bug#903708: xfce4: xfce fails to start with all methods

[Sven Joachim]

Control: reassign -1 xserver-xorg-core
Control: forcemerge 900550 -1

On 2018-07-13 10:55 -0400, annadane wrote:

> Package: xfce4
> Version: 4.12.4
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> On a fresh install of Sid (as in minimal Stable -> dist-upgrade), xfce
> fails to start with any of sddm, lightdm, or startx. Here's my xorg
> log; I'm really not certain how to fix it. (PS if it's wrong to
> include paste.d.n links in here instead of full output please let me
> know or just paste it verbatim) http://paste.debian.net/1033571/

Please include such logs directly in the bug report in the future, that makes
them easier to access.  Here is the relevant output:

,
| [  1275.433] (EE) Backtrace:
| [  1275.433] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4d) [0x55abecc798dd]
| [  1275.433] (EE) 1: /usr/lib/xorg/Xorg (0x55abecac6000+0x1b7599) 
[0x55abecc7d599]
| [  1275.433] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f0b655d+0x128e0) [0x7f0b655e28e0]
| [  1275.433] (EE) 3: /usr/lib/xorg/Xorg (miRenderColorToPixel+0xe) 
[0x55abecbedbde]
| [  1275.433] (EE) 4: /usr/lib/xorg/modules/libexa.so (0x7f0b629f6000+0xf13b) 
[0x7f0b62a0513b]
| [  1275.433] (EE) 5: /usr/lib/xorg/Xorg (0x55abecac6000+0x13a8b6) 
[0x55abecc008b6]
| [  1275.433] (EE) 6: /usr/lib/xorg/Xorg (0x55abecac6000+0x12ec1c) 
[0x55abecbf4c1c]
| [  1275.433] (EE) 7: /usr/lib/xorg/Xorg (0x55abecac6000+0x5b008) 
[0x55abecb21008]
| [  1275.433] (EE) 8: /usr/lib/xorg/Xorg (0x55abecac6000+0x5f008) 
[0x55abecb25008]
| [  1275.433] (EE) 9: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xe7) 
[0x7f0b65435b17]
| [  1275.433] (EE) 10: /usr/lib/xorg/Xorg (_start+0x2a) [0x55abecb0ed0a]
| [  1275.433] (EE) 
| [  1275.433] (EE) Segmentation fault at address 0x8
| [  1275.433] (EE) 
| Fatal server error:
| [  1275.433] (EE) Caught signal 11 (Segmentation fault). Server aborting
`

This is bug #900550 in xserver-xorg-core, I have just cherry-picked the
upstream fix[1].

Cheers,
   Sven


1. 
https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/aa7aaeb5223830a3670dc658152e28f125c17de8

Bug#903755: RFS: tvb-data/1.5.5-1 [ITP] -- friendly greeter

[Umar Parooq]

Package: sponsorship-requests
  Severity: normal [wishlist]

  Dear mentors,

  I am looking for a sponsor for my package "tvb-data"

 * Package name: tvb-data
   Version : 1.5.5-1
   Upstream Author : [TVB TEAM ]
 * URL : [https://github.com/the-virtual-brain/tvb-framework]
 * License : [GPL-3.0+]
   Section : python

  It builds those binary packages:

tvb-data   - various demonstration datasets for the virtual brain

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

  https://mentors.debian.net/package/tvb-data


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

dget -x 
https://mentors.debian.net/debian/pool/main/t/tvb-data/tvb-data_1.5.5-1.dsc

  More information about tvb-data can be obtained from
https://github.com/the-virtual-brain/tvb-data.


  Regards,
   umar haruna abdullahi

Bug#903713: plasma-browser-integration: "This_file_is_part_of_KDE" in debian/copyright?

[Maximiliano Curia]

¡Hola Chris!

El 2018-07-13 a las 16:39 +0100, Chris Lamb escribió:

Source: plasma-browser-integration
Version: 5.13.1-1
Severity: serious
X-Debbugs-CC: Maximiliano Curia 



I just ACCEPTed plasma-browser-integration from NEW but noticed it
declares "This_file_is_part_of_KDE" as an copyright holder.



This seems very... odd.


Agreed, this is caused by the templates used in po files. For example in 
po/ca/plasma_runner_browsertabs.po it says:

# Translation of plasma_runner_browsertabs.po to Catalan
# Copyright (C) 2017 This_file_is_part_of_KDE
# This file is distributed under the license LGPL version 2.1 or
# version 3 or later versions approved by the membership of KDE e.V.
#
# Josep Ma. Ferrer , 2017.

Josep here is clearly the author, but there is no copyright assigment 
statement with his name. My interpretation of this is that the intention 
is to assign the copyright to the kde project, although it's not a hundred 
percent clear. So I go with whatever the file says.


Happy hacking,
--
"The best way to predict the future is to invent it."
-- Alan Kay
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#903713: plasma-browser-integration: "This_file_is_part_of_KDE" in debian/copyright?

[Chris Lamb]

¡Hola!,

> My interpretation of this is that the intention is to assign the copyright
> to the kde project, although it's not a hundred percent clear.

I should have been clearer, sorry — I understand you are going with
whatever the file says but I am requesting that you make this clearer,
perhaps by getting a statement from upstream or similar.

"This_file_is_part_of_KDE" is really not suitable as an author,
whatever the file says, after all.


Regards,

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

Bug#903756: Please create mitmproxy CA certificate and run update-ca-alternatives on install

[Víctor Cuadrado Juan]

Package: mitmproxy
Version: 3.0.3-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

If possible it would be nice if with some preinst and postrm the package created
the needed CA certificate in the correct place, and run update-ca-certificates,
analogous to what manually needs to be done by:

$ mitmproxy --listen-port 9000 # creates certs in ~/.mitmproxy
$ sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem 
/usr/local/share/ca-certificates/mitmproxy-ca-cert.crt
$ sudo update-ca-certificates


Kind regards,
Víctor Cuadrado Juan



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

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

Versions of packages mitmproxy depends on:
ii  dpkg  1.19.0.5+b1
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-1
ii  python3   3.6.5-3
ii  python3-blinker   1.4+dfsg1-0.1
ii  python3-brotli1.0.5-1
ii  python3-certifi   2018.4.16-1
ii  python3-click 6.7-5
ii  python3-cryptography  2.2.2-1
ii  python3-h11   0.8.1-1
ii  python3-h23.0.1-4
ii  python3-hyperframe5.1.0-1
ii  python3-kaitaistruct  0.8-1
ii  python3-ldap3 2.4.1-1
ii  python3-openssl   18.0.0-1
ii  python3-passlib   1.7.1-1
ii  python3-pyasn10.4.2-3
ii  python3-pyparsing 2.2.0+dfsg1-2
ii  python3-pyperclip 1.6.0-2
ii  python3-requests  2.18.4-2
ii  python3-ruamel.yaml   0.15.34-1+b1
ii  python3-sortedcontainers  2.0.4-1
ii  python3-tornado   5.0.2-1+b1
ii  python3-urwid 2.0.1-2+b1
ii  python3-wsproto   0.11.0-2

mitmproxy recommends no packages.

mitmproxy suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAltJyHkACgkQIj8Vylqv
DngvSgf+Mj4fgv0qy9/rYQ/mag0tUrQbq6kAY5JAXFcH5anwBefjc9KoXibfez/m
J4W2wATXKj3Cm0kI+/5W134xNMM3RryGsX9xs+dixR8V9Z8uNdPmDh5JB2wNh5ov
08b8EmaYbRKH0NR2eVxoxb95NsGS0n+yHPh26CbQpRQxNzt6PESwacLayuegHBMO
OQERzQbas3xIMFgehqEFT2V19sPNnvkWBVZtKdSBZhAKkIxqN4ym0kQWq51mfRRS
DcXL9FnyJ8HpXsUoULwc1Hbj5JDJpr6Mir5XNRQYcnVutDJx0S1fP7dpWgaNLmhr
OkYblClwopv8uyp/S10ZIsfDm9mymg==
=cd3Q
-END PGP SIGNATURE-

Bug#901473: jenkins.debian.org: Vary merged-usr in reproducibility testing?

[Michael Biebl]

debootstrap was changed (again) in 1.0.102 to now default to
--merged-usr [1].

Systems are not forcefully upgraded to a merged-usr setup atm though.
buildds are regularly re-created from scratch and will thus have a
merged-usr setup.
This means, binaries that were built in a merged-usr buildd environment
will now run on a lot of non-merged-usr setups.

If we could auto-detect any problems resulting from that via the
reproducible builds effort, this would be great.

regards,
Michael



[1] https://packages.qa.debian.org/d/debootstrap/news/20180613T134920Z.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839046

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

Bug#903713: plasma-browser-integration: "This_file_is_part_of_KDE" in debian/copyright?

[Maximiliano Curia]

¡Hola Luigi!

El 2018-07-14 a las 10:37 +0100, Chris Lamb escribió:

My interpretation of this is that the intention is to assign the copyright
to the kde project, although it's not a hundred percent clear.



I should have been clearer, sorry — I understand you are going with
whatever the file says but I am requesting that you make this clearer,
perhaps by getting a statement from upstream or similar.



"This_file_is_part_of_KDE" is really not suitable as an author,
whatever the file says, after all.


Chris raised the issue of the po files distributed by kde containing some (not 
very clear) template parts, in particular the copyright assignments to 
This_file_is_part_of_KDE.


With your kde i18n team hat on, would you consider it feasible to replace 
these strings with something clearer?


If the intention is for the translators to assign the copyright to kde it 
should be assigned to KDE.e.V, if the intention is for each translator to keep 
the copyright assignment the This_file_is_part_of_KDE part of the template 
needs to be updated to say AUTHOR .


The first case should be "scriptable" the second case, would need to manually 
modifying each po file that contains the "This_file_is_part_of_KDE" text.


Happy hacking,
--
"Brilliant opportunities are cleverly disguised as insolvable problems."
-- Gardener's Philosophy

"The reverse is also true." -- Corollary
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#903757: gimp: Free Select Tool: Add or Substract selection only after pressing ENTER-Key

[Reiner]

Package: gimp
Version: 2.10.2-1
Severity: normal

Dear Maintainer,

since gimp version 2.10.x the free selection tool can add or aubstract 
selection only after pressing the "enter"-Key. No Problems with other 
selections tools (rectangle, elipse, fuzzy select) and no problems with older 
gimp versions (2.8.x, 2.6.x)
 
regards
Reiner


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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.2-1
ii  libaa1   1.4p5-44+b2
ii  libbabl-0.1-00.1.50-1
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.27-4
ii  libcairo21.15.10-3
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.1.0-10
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgegl-0.4-00.4.2-1
ii  libgexiv2-2  0.10.8-1
ii  libgimp2.0   2.10.2-1
ii  libglib2.0-0 2.56.1-2
ii  libgs9   9.22~dfsg-2.1
ii  libgtk2.0-0  2.24.32-2
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b1.8.2-2
ii  libheif1 1.3.2-1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-2
ii  liblzma5 5.2.2-1.3
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2
ii  libopenexr23 2.2.1-4
ii  libopenjp2-7 2.3.0-1
ii  libpango-1.0-0   1.42.1-2
ii  libpangocairo-1.0-0  1.42.1-2
ii  libpangoft2-1.0-01.42.1-2
ii  libpng16-16  1.6.34-2
ii  libpoppler-glib8 0.63.0-2
ii  librsvg2-2   2.40.20-2
ii  libstdc++6   8.1.0-10
ii  libtiff5 4.0.9-6
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-12
ii  libx11-6 2:1.6.5-1
ii  libxcursor1  1:1.1.15-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.22~dfsg-2.1

Versions of packages gimp suggests:
pn  gimp-data-extras  
ii  gimp-help-de [gimp-help]  2.8.2-0.1
pn  gimp-python   
ii  gvfs-backends 1.36.1-1+b1
ii  libasound21.1.6-1

-- no debconf information

Bug#903758: babl FTBFS on Alpha: misuse of -Ofast with non-finite floating point

[Michael Cree]

Source: babl
Version: 0.1.50-1
Severity: important
Justification: failed to build from source (but built in the past)
Tags: patch
User: debian-al...@lists.debian.org
Usertags: ftbfs

babl FTBFS on Alpha [1] with what on the surface looks like a linker error
but is actually misuse of the -Ofast compiler option.  babl unconditionally
uses the -Ofast option when compiling with gcc.  This implies
-ffast-math which the gcc manual makes clear is not compliant with
standards and on some architectures may break if used with non-finite
math.  Alpha is one of those architectures. 

If we remove -Wl,-z,defs from the linker flags specified in debian/rules
then the link succeeds on Alpha but the test suite fails with floating
point exceptions, because non-finite math is used.

I attach a patch that adds a --disable-ofast option to the configure
script so it is possible to build without -Ofast.  The second patch
is a change to debian/rules to detect if building with Alpha then
supply the --disable-ofast option when invoking configure. With these
babl builds to completion, with the test suite passing, on Alpha.

Cheers
Michael.

[1]
https://buildd.debian.org/status/fetch.php?pkg=babl&arch=alpha&ver=0.1.50-1&stamp=1526902985&raw=0
--- a/configure.ac
+++ b/configure.ac
@@ -136,6 +136,9 @@
 WEBSITE_LOCATION=public_html/babl/
 AC_SUBST(WEBSITE_LOCATION)
 
+AC_ARG_ENABLE([ofast],
+  [  --disable-ofast  disable use of -Ofast (default=no)],,
+  enable_ofast="yes")
 
 if eval "test x$GCC = xyes"; then
   case " $CFLAGS " in
@@ -161,8 +164,13 @@
 BABL_DETECT_CFLAGS(extra_warnings, '-Wold-style-definition')
 CFLAGS="$CFLAGS $extra_warnings"
 
-BABL_DETECT_CFLAGS(extra_warnings, '-Ofast' )
-CFLAGS="$CFLAGS $extra_warnings"
+if test "x$enable_ofast" = xyes; then
+  BABL_DETECT_CFLAGS(extra_warnings, '-Ofast' )
+  CFLAGS="$CFLAGS $extra_warnings"
+else
+  BABL_DETECT_CFLAGS(extra_warnings, '-O3' )
+  CFLAGS="$CFLAGS $extra_warnings"
+fi
 
 fi
 
--- babl-0.1.50/debian/rules	2018-05-21 14:36:01.0 +1200
+++ babl-0.1.50+alpha/debian/rules	2018-07-14 21:14:49.322785083 +1200
@@ -10,6 +10,12 @@
 	sse_flags := --enable-mmx --enable-sse --enable-sse2
 endif
 
+# Disable use of -Ofast (thus -ffath-math) on Alpha
+ofast_flags :=
+ifeq ($(DEB_HOST_ARCH_CPU),alpha)
+	ofast_flags := --disable-ofast
+endif
+
 %:
 	dh $@ --with gnome
 
@@ -20,7 +26,8 @@
 	dh_auto_configure -- \
 		$(sse_flags) \
 		--disable-sse4_1 \
-		--disable-f16c
+		--disable-f16c \
+		$(ofast_flags)
 
 override_dh_install:
 	find debian/tmp -name '*.la' -print -delete

Bug#901473: [Qa-jenkins-dev] Bug#901473: jenkins.debian.org: Vary merged-usr in reproducibility testing?

[Mattia Rizzolo]

On Sat, Jul 14, 2018 at 11:59:37AM +0200, Michael Biebl wrote:
> debootstrap was changed (again) in 1.0.102 to now default to
> --merged-usr [1].
> 
> Systems are not forcefully upgraded to a merged-usr setup atm though.
> buildds are regularly re-created from scratch and will thus have a
> merged-usr setup.
> This means, binaries that were built in a merged-usr buildd environment
> will now run on a lot of non-merged-usr setups.

Is that really so?  I expect buildds to run with stable's debootstrap,
so for now they should be using non-merged-usr chroots.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#903759: pdb2pqr: autopkgtest regression

[Graham Inggs]

Source: pdb2pqr
Version: 2.1.1+dfsg-2
User: debian...@lists.debian.org
Usertags: needs-update

Hi Maintainer

Since 2017-06-15, pdb2pqr's auopkgtests have been failing [1].
Unfortunately, debci logs no longer exist, so it is not easy to tell
which package(s) changed.

More recent logs seem to indicate two failures:

autopkgtest [00:08:50]: test installation-test: [---
Run pdb2pqr...
Usage: pdb2pqr [options] PDB_PATH PQR_OUTPUT_PATH

pdb2pqr: error: Unable to find file 1FAS!
...
installation-testFAIL non-zero exit status 2


autopkgtest [00:08:54]: test ligands-test: [---
cp: cannot stat '/usr/share/doc/pdb2pqr-doc/examples/*': No such file
or directory
autopkgtest [00:08:54]: test ligands-test: ---]
autopkgtest [00:08:54]: test ligands-test:  - - - - - - - - - -
results - - - - - - - - - -
ligands-test FAIL non-zero exit status 1

Regards
Graham


[1] https://ci.debian.net/packages/p/pdb2pqr/unstable/amd64/

Bug#903441: dgit: autopkgtest failures in Ubuntu [and 1 more messages]

[Mattia Rizzolo]

On Fri, Jul 13, 2018 at 06:22:43PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Bug#903441: dgit: autopkgtest failures in Ubuntu 
> [and 1 more messages]"):
> > Sorry, this is due to #903696 in autopkgtest, which I just filed.  I
> > should have CC'd you.
> > 
> > 5.9+exp4 is supposed to fix it.  This time, for sure.
> 
> Wow!  It actually DTRT!  Please do let me know whether it fixes the
> symptoms, in Ubuntu, of my incorrect dch invocations.

It does, and now autopkgtests pass on Ubuntu! :D

5.9+exp4 landed successfully in the release pocket afterwards :)

Thank you!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#901473: [Qa-jenkins-dev] Bug#901473: jenkins.debian.org: Vary merged-usr in reproducibility testing?

[Michael Biebl]

Am 14.07.2018 um 12:28 schrieb Mattia Rizzolo:
> On Sat, Jul 14, 2018 at 11:59:37AM +0200, Michael Biebl wrote:
>> debootstrap was changed (again) in 1.0.102 to now default to
>> --merged-usr [1].
>>
>> Systems are not forcefully upgraded to a merged-usr setup atm though.
>> buildds are regularly re-created from scratch and will thus have a
>> merged-usr setup.
>> This means, binaries that were built in a merged-usr buildd environment
>> will now run on a lot of non-merged-usr setups.
> 
> Is that really so?  I expect buildds to run with stable's debootstrap,
> so for now they should be using non-merged-usr chroots.

I would have expected that buildds use debootstrap from unstable, but
I'm not a buildd admin, so I trust you to know more about that then me.
Thanks for correcting me on that and sorry if that caused confusion.

Still, in the hopefully not too distant future, we will have such a
debootstrap in stable, so it's probably a good idea to be prepared for
that by then. TTBOMK, there are no plans to forcefully upgrade systems
to a merged-usr setup on stretch → buster upgrades.

Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#903760: grub-pc: BOBOOOGrub fails to update to the newer kernel of Debian 9 in second partition

[Khurram Mahmood]

Package: grub-pc
Version: 2.02~beta3-5
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

1. update-grub2 works; but fails to detect the newer version of kernel:

$ grep -m1 -A12 stretch /boot/grub/grub.cfg 
menuentry 'Debian GNU/Linux 9 (stretch) (on /dev/sda2)' --class debian --class 
gnu-linux --class gnu --class os $menuentry_id_option 
'osprober-gnulinux-simple-3290fac5-347e-440e-a722-f7dbdebc528f' {
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
3290fac5-347e-440e-a722-f7dbdebc528f
else
  search --no-floppy --fs-uuid --set=root 
3290fac5-347e-440e-a722-f7dbdebc528f
fi
linux /boot/vmlinuz-4.9.0-6-amd64 root=/dev/sda2
initrd /boot/initrd.img-4.9.0-6-amd64
}

2. See the kernels available:

$ ls /media/hdd/sda2/boot/
config-4.9.0-6-amd64  initrd.img-4.9.0-6-amd64  System.map-4.9.0-7-amd64
config-4.9.0-7-amd64  initrd.img-4.9.0-7-amd64  vmlinuz-4.9.0-6-amd64
grub  System.map-4.9.0-6-amd64  vmlinuz-4.9.0-7-amd64


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

I ran:

# grub-install --recheck --no-floppy /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

# update-grub2

But it didnt correct the problem.

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda5 / ext4 rw,relatime,errors=remount-ro,commit=600,data=ordered 0 0
/dev/sda3 /media/hdd/sda3 ext4 rw,relatime,commit=600,data=ordered 0 0
/dev/sda2 /media/hdd/sda2 ext4 rw,relatime,commit=600,data=ordered 0 0
/dev/sda6 /media/hdd/sda6 ext4 rw,relatime,commit=600,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="6"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 
--hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  
b635f48f-40fe-4a54-8fac-f5953137b67e
else
  search --no-floppy --fs-uuid --set=root b635f48f-40fe-4a54-8fac-f5953137b67e
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=3
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=3
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 
--hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  
b635f48f-40fe-4a54-8fac-f5953137b67e
else
  search --no-floppy --fs-uuid --set=root b635f48f-40fe-4a54-8fac-f5953137b67e
fi
insmod png
if background_image /usr/share/desktop-base/softwaves-theme/grub/grub-4x3.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --cl

Bug#903761: bind: fails to install: rndc-confgen: The -r option has been deprecated.

[Andreas Beckmann]

Package: bind
Version: 1:9.13.1+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Selecting previously unselected package bind.
  (Reading database ... 
(Reading database ... 5477 files and directories currently installed.)
  Preparing to unpack .../bind_1%3a9.13.1+dfsg-1_amd64.deb ...
  Unpacking bind (1:9.13.1+dfsg-1) ...
  Setting up bind (1:9.13.1+dfsg-1) ...
  Adding group `bind' (GID 150) ...
  Done.
  Adding system user `bind' (UID 150) ...
  Adding new user `bind' (UID 150) with group `bind' ...
  Not creating home directory `/var/cache/bind'.
  rndc-confgen: The -r option has been deprecated.
  dpkg: error processing package bind (--configure):
   installed bind package post-installation script subprocess returned error 
exit status 1
  Errors were encountered while processing:
   bind


cheers,

Andreas


bind_1:9.13.1+dfsg-1.log.gz
Description: application/gzip

Bug#903762: boinc-server-maker: fails to install: SyntaxError in /usr/lib/boinc-server-maker/sched/pymw_assimilator.py

[Andreas Beckmann]

Package: boinc-server-maker
Version: 7.12.0+dfsg-1exp2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Selecting previously unselected package boinc-server-maker.
  (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 11991 files and directories currently installed.)
  Preparing to unpack .../boinc-server-maker_7.12.0+dfsg-1exp2_amd64.deb ...
  Unpacking boinc-server-maker (7.12.0+dfsg-1exp2) ...
  Setting up boinc-server-maker (7.12.0+dfsg-1exp2) ...
  Adding user `www-data' to group `boincadm' ...
  Adding user www-data to group boincadm
  Done.
File "/usr/lib/boinc-server-maker/sched/pymw_assimilator.py", line 50
  except Exception,msg:
  ^
  SyntaxError: invalid syntax
  
  dpkg: error processing package boinc-server-maker (--configure):
   installed boinc-server-maker package post-installation script subprocess 
returned error exit status 1
  Errors were encountered while processing:
   boinc-server-maker


cheers,

Andreas


boinc-server-maker_7.12.0+dfsg-1exp2.log.gz
Description: application/gzip

Bug#903691: systemd-localed.service: Failed to set up mount namespacing: Bad address

[Michael Biebl]

control: tags -1 moreinfo unreproducible

Am 13.07.2018 um 13:29 schrieb Michael Biebl:

> Can you reproduce the problem with 4.16, i.e. is that a regression
> introduced by 4.17?
> I'm asking, because I'm running 4.14 and can't reproduce the issue.

I meant 4.16 here, not 4.14.

That said, I have now also installed 4.17:

linux-image-4.17.0-1-amd64:
  Installiert:   4.17.6-1
  Installationskandidat: 4.17.6-1
  Versionstabelle:
 *** 4.17.6-1 500

I can't reproduce any problems though.
Do you have SELinux, AppArmor or anything like that enabled? Does it
help if you disable it?
Is systemd running inside a container?
Any hints how we might be able to reproduce the problem?

-- 
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#903764: nmu: librep_0.92.6-1

[Andreas Beckmann]

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

nmu librep_0.92.6-1 . ANY . experimental . -m "Rebuild against libgdbm5."

librep-dev/experimental still depends on the no longer available
libgdbm3.

Andreas

Bug#903763: exiv2: CVE-2018-14046

[Salvatore Bonaccorso]

Source: exiv2
Version: 0.26-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/Exiv2/exiv2/issues/378

Hi,

The following vulnerability was published for exiv2, filling with RC
severity so that the only affected version in experimental does not
enter buster.

CVE-2018-14046[0]:
| Exiv2 0.26 has a heap-based buffer over-read in WebPImage::decodeChunks
| in webpimage.cpp.

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-14046
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14046
[1] https://github.com/Exiv2/exiv2/issues/378

Regards,
Salvatore

Bug#902897: virtualbox broken by binutils master (new R_X86_64_PLT32 relocation type)

[Jan Nordholz]

Hi Gianfranco,

please include upstream's v2 patch, they missed one occurrence of _PC32
in ldrELFRelocatable.cpp.h in the first version...


Jan

Bug#903765: nmu: tvc_5.0.3+dfsg-2

[Andreas Beckmann]

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

nmu tvc_5.0.3+dfsg-2 . ANY . experimental . -m "Rebuild against 
libbamtools2.5.1."

That was missed during the transition in sid.


Andreas

Bug#898741: stretch-pu: package hdparm/9.51+ds-1+deb9u1

[Adam D. Barratt]

On Thu, 2018-07-05 at 21:34 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2018-05-15 at 16:48 +0200, Alex Mestiashvili wrote:
> > hdparm tries to configure APM on every (non-USB/non-firewire) disk
> > in the system without first checking if APM is supported.
> > However, sending APM commands to disks that don't support it can
> > have
> > side-effects. This upload fixes the issue by enabling APM only on
> > devices which support it.
> > 
> 
> Please go ahead.
> 

I missed that hdparm builds a udeb, so CCing the d-i RM for
confirmation.

KiBi - hdparm is in the "could be handled by britney" list in
hints/freeze, which I think we'd previously agreed meant it didn't need
d-i sign-off, but I'm not 100% sure of that right now.

Regards,

Adam

Bug#892764: i3-wm 4.13-1+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: i3-wm
Version: 4.13-1+deb9u1

Explanation: fix crash upon restart when using marks

Bug#895537: libopenmpt 0.2.7386~beta20.3-3+deb9u3 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libopenmpt
Version: 0.2.7386~beta20.3-3+deb9u3

Explanation: fix "up11: Out-of-bounds read loading IT / MO3 files with many 
pattern loops" [CVE-2018-10017]

Bug#903713: plasma-browser-integration: "This_file_is_part_of_KDE" in debian/copyright?

[Luigi Toscano]

Maximiliano Curia ha scritto:

¡Hola Luigi!

El 2018-07-14 a las 10:37 +0100, Chris Lamb escribió:

My interpretation of this is that the intention is to assign the copyright
to the kde project, although it's not a hundred percent clear.



I should have been clearer, sorry — I understand you are going with
whatever the file says but I am requesting that you make this clearer,
perhaps by getting a statement from upstream or similar.



"This_file_is_part_of_KDE" is really not suitable as an author,
whatever the file says, after all.


Chris raised the issue of the po files distributed by kde containing some (not 
very clear) template parts, in particular the copyright assignments to 
This_file_is_part_of_KDE.


I'm not sure that's a copyright assignment. Usually we have the FLA for that:
https://ev.kde.org/rules/fla.php

I suspect that it was a replacement of the standard copyright assignation to 
the FSF which was there in the early days but it really did not fit.
I tracked it back to this change, from 2006 (the string was later changed to 
used underscores instead of spaces):

https://websvn.kde.org/?view=revision&revision=505466

The message is probably incorrect (without copyright is all reserved, not 
public domain) but it has been like that for a while.


I'm not sure I'm allowed to decide if it's a copyright assignment or not. I'm 
probably going to ask the board of the KDE e.V., as it is a legal question.
I added Albert Astal Cid, who is and has been in charge of in the i18n team 
more than me, he was part of the board in the past, and maybe we can discuss 
what to do.



With your kde i18n team hat on, would you consider it feasible to replace 
these strings with something clearer?


If the intention is for the translators to assign the copyright to kde it 
should be assigned to KDE.e.V, if the intention is for each translator to keep 
the copyright assignment the This_file_is_part_of_KDE part of the template 
needs to be updated to say AUTHOR .


The first case should be "scriptable" the second case, would need to manually 
modifying each po file that contains the "This_file_is_part_of_KDE" text.


As I said, I don't think it's the first case, but I can ask to the e.V.

If it's going to be the second case, I don't think that's practical when the 
list of authors is still in the file. Shouldn't a string like

Copyright (C) the respective authors (see below)
work? Or something more legally fitting.


Finally, a request: please lower the severity of this bug. It's not a 
regression, and I would assume good faith on something that has been the same 
for the past 10+ years, without having a "serious" bug in the middle.


Ciao
--
Luigi

Bug#850587: Sponsoring of cohomcalg

[Doug Torrance]

On 07/14/2018 02:46 AM, Andreas Tille wrote:

I realised that this package is open on the SoB page and has not yet hit
Debian.  Please keep me updated about the status - I can upload a new
version if needed.

Sorry if I missed some information and feel free to ping me in case you
need further help (with this or other packages of yours)


No problem!  It's been sponsored a couple times already, but was 
rejected from NEW because of a logo with a non-free license.


I believed everything is fixed now.  I pushed a few more little updates 
to git just now.  If you could sponsor again, that would be great!


Thanks,
Doug

Bug#761627: libtomcrypt-dev: arch-dependent file in "Multi-Arch: same" package

[François Poirotte]

Hi Michael,

I just noticed that this issue is not present anymore in Debian Buster 
(libtomcrypt-dev 1.18.1-1).
Judging from the git history upstream, it seems to have been fixed by 
your patch:

https://github.com/libtom/libtomcrypt/commit/4ab63ccd3a6ed5e11fa616fafc9915ef694e8775#diff-cd5dbf3629c558b0104ba8f0937d6816

So I think this bug can now be closed.

Best regards,
François

On Sat, 22 Jul 2017 22:40:26 +0200 Michael Stapelberg 
 wrote:

> Thanks for the ping.
>
> I applied your patch and tried to build the package, but it fails to 
build

> (build log attached).
>
> I’m not sure if that is because of your patch or an unrelated issue, 
but I

> don’t have the time to debug LaTeX issues right now. Any help welcome.
>
> On Wed, Jul 19, 2017 at 11:46 AM, François Poirotte 
> wrote:
>

Bug#903691: systemd-localed.service: Failed to set up mount namespacing: Bad address

[Grand T]

I am running regular Debian alone on the hard disk of my HP laptop, apparmor is 
now by default, but I confirm the environment is noy the cause. All things 
equal , everything is good wiyj kernel 4.16


another example of how the problem is:


root@debian:/home/guy# systemd-analyze plot > kernel-417.svg
Failed to get host information from systemd: Failed to activate service 
'org.freedesktop.hostname1': timed out (service_start_timeout=25000ms)
root@debian:/home/guy# systemctl --failed
  UNIT  LOAD   ACTIVE SUBDESCRIPTION
● systemd-hostnamed.service loaded failed failed Hostname Service

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB= The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
root@debian:/home/guy# systemctl status systemd-hostnamed.service
● systemd-hostnamed.service - Hostname Service
   Loaded: loaded (/lib/systemd/system/systemd-hostnamed.service; static; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2018-07-14 15:29:45 CEST; 1min 
10s ago
 Docs: man:systemd-hostnamed.service(8)
   man:hostname(5)
   man:machine-info(5)
   https://www.freedesktop.org/wiki/Software/systemd/hostnamed
  Process: 3903 ExecStart=/lib/systemd/systemd-hostnamed (code=exited, 
status=226/NAMESPACE)
 Main PID: 3903 (code=exited, status=226/NAMESPACE)

juil. 14 15:29:45 debian systemd[1]: Starting Hostname Service...
juil. 14 15:29:45 debian systemd[3903]: systemd-hostnamed.service: Failed to 
set up mount namespacing: Bad address
juil. 14 15:29:45 debian systemd[3903]: systemd-hostnamed.service: Failed at 
step NAMESPACE spawning /lib/systemd/systemd-hos
juil. 14 15:29:45 debian systemd[1]: systemd-hostnamed.service: Main process 
exited, code=exited, status=226/NAMESPACE
juil. 14 15:29:45 debian systemd[1]: systemd-hostnamed.service: Failed with 
result 'exit-code'.
juil. 14 15:29:45 debian systemd[1]: Failed to start Hostname Service.
root@debian:/home/guy#





De : Michael Biebl 
Envoyé : samedi 14 juillet 2018 13:46
À : GT; 903...@bugs.debian.org
Objet : Re: Bug#903691: systemd-localed.service: Failed to set up mount 
namespacing: Bad address

control: tags -1 moreinfo unreproducible

Am 13.07.2018 um 13:29 schrieb Michael Biebl:

> Can you reproduce the problem with 4.16, i.e. is that a regression
> introduced by 4.17?
> I'm asking, because I'm running 4.14 and can't reproduce the issue.

I meant 4.16 here, not 4.14.

That said, I have now also installed 4.17:

linux-image-4.17.0-1-amd64:
  Installiert:   4.17.6-1
  Installationskandidat: 4.17.6-1
  Versionstabelle:
 *** 4.17.6-1 500

I can't reproduce any problems though.
Do you have SELinux, AppArmor or anything like that enabled? Does it
help if you disable it?
Is systemd running inside a container?
Any hints how we might be able to reproduce the problem?

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

Bug#903766: nmu: hdf5_1.10.2+repack-1~exp1

[Andreas Beckmann]

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

nmu hdf5_1.10.2+repack-1~exp1 . ANY . experimental . -m "Rebuild against 
libopenmpi3."

This was missed during the openmpi transition.


Andreas

Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8

[Michael J. Redd]

Package: linux-image-4.9.0-7-amd64
Version: 4.9.110-1

Description:


After installing the latest Stretch kernel, 4.9.110-1, on a server
running Xen Hypervisor 4.8, bootstrapping the kernel fails. GRUB loads
the hypervisor as normal, which then attempts to load the Dom0 kernel.
Once that process starts, the system simply reboots. Nothing is output
to the console after Xen does its thing (screen goes black), so I
cannot offer any insights into what the kernel may be doing before it
fails.

If I roll back to the previous Stretch kernel, linux-image-4.9.0-6-
amd64 (4.9.88-1+deb9u1), the hypervisor starts the Dom0 kernel as
normal and the system boots successfully.

Setup:
==

Xen Hypervisor version: 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
Kernel version: linux-image-4.9.0-7-amd64 (4.9.110-1)

Bug#903691: systemd-localed.service: Failed to set up mount namespacing: Bad address

[Michael Biebl]

Am 14.07.2018 um 15:37 schrieb Grand T:
> I am running regular Debian alone on the hard disk of my HP laptop,
> apparmor is now by default, but I confirm the environment is noy the
> cause. All things equal , everything is good wiyj kernel 4.16

Could you show me the output of

ls -la / /var


-- 
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#900533: chromium 67.0.3396.62-1: youtube video, gif's, html5, and movies no longer work

[ZevenOS]

I can confirm this bug in stable security.
It needs to be reopened.
Applying the patch mentioned by Jiri Palece (
https://salsa.debian.org/chromium-team/chromium/commit/402b98bb1079079a788696650e0a922b1e16bed8
)

Fixes the issue for me.
So I advise to rebuild chromium with it.

I built this package for Neptune so our users don't have a broken
browser for too long.

Greetings
Leszek Lesner
-- 
ZevenOS / Neptune Team
http://www.zevenos.com / http://www.neptuneos.com
Leszek Lesner 

Bug#903768: libimlib2: The message "Using O_TMPFILE" is flooding log file

[Dtux]

Package: libimlib2
Version: 1.4.8-1
Severity: normal

Dear Maintainer,

libimlib2 (1.5.1-1) seem cause the fill up of the Xorg log file with the
message : "Using O_TMPFILE"

like (in  Xorg.0.log )
...
[   929.247] Using O_TMPFILE
[   929.247] Using O_TMPFILE
[   929.249] Using O_TMPFILE
[   929.250] Using O_TMPFILE
...

or (with journalctrl)

...
slim[755]: Using O_TMPFILE
...

Downgrade to 1.4.8-1 fix this bug for me .

Thanks



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

Kernel: Linux 4.16.0-2-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)

Versions of packages libimlib2 depends on:
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.27-3
ii  libfreetype6 2.8.1-2
ii  libgif7  5.1.4-3
ii  libid3tag0   0.15.1b-13
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpng16-16  1.6.34-1
ii  libtiff5 4.0.9-6
ii  libx11-6 2:1.6.5-1
ii  libxext6 2:1.3.3-1+b2
ii  zlib1g   1:1.2.11.dfsg-1

libimlib2 recommends no packages.

libimlib2 suggests no packages.

-- no debconf information

Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8

[Michael J. Redd]

This also apparently affects at least PV guests. Upgrading a PV domU to
 kernel 4.9.110-1 and rebooting yields the following output via xl's
console:


Loading Linux 4.9.0-6-amd64 ...
Loading Linux 4.9.0-7-amd64 ...
Loading initial ramdisk ...   [ vmlinuz-4.9.0-7-
amd6  2.69MiB  66%  1.67MiB/s ]
[0.128044] dmi: Firmware registration
failed.a  17.29MiB  100%  9.75MiB/s ]
[1.408778] dmi-sysfs: dmi entry is absent.
[1.427758] general protection fault:  [#1] SMP
[1.427767] Modules linked in:
[1.427778] CPU: 0 PID: 1 Comm: init Not tainted 4.9.0-7-amd64 #1
Debian 4.9.110-1
[1.427789] task: 88000ee36040 task.stack: c90040068000
[1.427798] RIP: e030:[]  []
ret_from_fork+0x2d/0x70
[1.427815] RSP: e02b:c9004006bf50  EFLAGS: 00010006
[1.427823] RAX: 0002175f5000 RBX: 816076d0 RCX:
ea310e1f
[1.427833] RDX: 0002 RSI: 0002 RDI:
c9004006bf58
[1.427840] RBP:  R08:  R09:
88000a9e5000
[1.427847] R10: 8080808080808080 R11: fefefefefefefeff R12:

[1.427854] R13: 179f3966a73fde7b R14: 06f99905e8f3edfb R15:
cf60f5f9fd8e4751
[1.427866] FS:  () GS:88000fc0()
knlGS:
[1.427873] CS:  e033 DS:  ES:  CR0: 80050033
[1.427879] CR2: 7ffd37e72eb9 CR3: 0a9f4000 CR4:
00042660
[1.427889] Stack:
[1.427893]    

[1.427906]    

[1.427921]    

[1.427943] Call Trace:
[1.427951] Code: c7 e8 b8 fe a8 ff 48 85 db 75 2f 48 89 e7 e8 5b ed
9e ff 50 90 0f 20 d8 65 48 0b 04 25 e0 02 01 00 78 08 65 88 04 25 e7 02
01 00 <0f> 22 d8 58 66 66 90 66 66 90 e9 c1 07 00 00 4c 89 e7 eb 11 e8 
[1.428148] RIP  [] ret_from_fork+0x2d/0x70
[1.428160]  RSP 
[1.428168] ---[ end trace cb1a96e88a7c4794 ]---
[1.428298] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[1.428298] 
[1.428316] Kernel Offset: disabled


Note that the guest bootloader being used here is pvGRUB; not sure if
that is relevant but thought I would include it. Similarly, rolling the
domU back to the previous kernel/selecting the previous kernel via
pvGRUB allows the VM to boot normally.

Bug#903769: libcommons-lang3-java: NPE with OpenJDK11 and maven-javadoc

[Erich Schubert]

Package: libcommons-lang3-java
Version: 3.7-1
Severity: important

When building a maven projects javadoc, I see the following NPE:

Execution attach-javadocs of goal org.apache.maven.plugins:maven-javadoc-
plugin:3.0.0:javadoc-no-fork failed.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject

(LifecycleModuleBuilder.java:117)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject

(LifecycleModuleBuilder.java:81)
    at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:183)
    at org.debian.maven.Wrapper.main (Wrapper.java:89)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native 
Method)

    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard
(Launcher.java:330)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:238)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
attach-
javadocs of goal 
org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:javadoc-

no-fork failed.
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:148)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject

(LifecycleModuleBuilder.java:117)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject

(LifecycleModuleBuilder.java:81)
    at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:183)
    at org.debian.maven.Wrapper.main (Wrapper.java:89)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native 
Method)

    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard
(Launcher.java:330)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:238)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: java.lang.NullPointerException
    at org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast
(SystemUtils.java:1654)
    at
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable
(AbstractJavadocMojo.java:3703)
    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
(AbstractJavadocMojo.java:2001)
    at org.apache.maven.plugins.javadoc.JavadocReport.generate
(JavadocReport.java:134)
    at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
(JavadocReport.java:329)
    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
(AbstractJavadocMojo.java:1909)
    a

Bug#900009: libXm causes the GUI to crash

[Graham Inggs]

Hi Miroslaw

I was able to reproduce this crash with motif 2.3.8-2.

Would you please report this issue in the upstream bug tracker [1]?
They may be better able to determine whether this is a bug in motif, or in medm.

If you do, please reply here with the bug number.

Regards
Graham

[1] http://bugs.motifzone.net/

Bug#903770: nvidia-graphics-drivers: Cannot be upgraded in stretch 9.5 without removing several GNOME & KDE packages

[Bas Couwenberg]

Source: nvidia-graphics-drivers
Version: 384.130-1
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The nvidia-driver packages cannot be updated as part of the stretch 9.5
stable update without removing several GNOME & KDE packages:

 The following packages were automatically installed and are no longer required:
   analitza-common apg avogadro-data bluez breeze breeze-cursor-theme 
breeze-icon-theme cheese-common cracklib-runtime crda cups-pk-helper 
dleyna-server dns-root-data dnsmasq-base folks-common fonts-hack-ttf 
fonts-oxygen
   frameworkintegration gir1.2-evince-3.0 gir1.2-gst-plugins-base-1.0 
gir1.2-gstreamer-1.0 gir1.2-gtksource-3.0 gir1.2-javascriptcoregtk-4.0 
gir1.2-webkit2-4.0 gnome-bluetooth gnome-control-center-data 
gnome-online-accounts
   gnome-user-share gstreamer1.0-libav gtk3-engines-breeze ieee-data 
iputils-arping iw kaccounts-providers kalzium-data kate5-data kde-cli-tools 
kde-cli-tools-data kde-config-gtk-style kde-config-sddm kde-style-breeze
   kde-style-breeze-qt4 kde-style-oxygen-qt5 kde-style-qtcurve-qt4 
kde-style-qtcurve-qt5 kded5 khotkeys khotkeys-data kmenuedit ksysguard 
ksysguard-data ksysguardd kwin-style-breeze kwrited libaccounts-glib0 
libaccounts-qt5-1
   libanalitzaplot7 libanalitzawidgets7 libapache2-mod-dnssd libappstreamqt2 
libavfilter6 libclutter-1.0-common libcogl-common libcolord-gtk1 libcrack2 
libcryptui0a libdee-1.0-4 libdleyna-connector-dbus-1.0-1 libdleyna-core-1.0-3
   libebur128-1 libedataserverui-1.2-1 libegl-nvidia0 libegl1-nvidia 
libevdocument3-4 libevview3-3 libfakekey0 libfolks-eds25 libfolks-telepathy25 
libfolks25 libgadu3 libgles-nvidia1 libgles-nvidia2 libgles1-glvnd-nvidia
   libgles2-glvnd-nvidia libgnome-autoar-gtk-0-0 libgoa-backend-1.0-1 
libgrilo-0.3-0 libgssdp-1.0-3 libgtksourceview-3.0-1 
libgtksourceview-3.0-common libgtkspell3-3-0 libgupnp-1.0-4 libgupnp-av-1.0-2 
libgupnp-dlna-2.0-3 libgxps2
   libkaccounts1 libkf5activitiesstats1 libkf5bluezqt-data libkf5bluezqt6 
libkf5calendarevents5 libkf5jsembed-data libkf5jsembed5 libkf5modemmanagerqt6 
libkf5networkmanagerqt6 libkf5people-data libkf5people5 libkf5peoplebackend5
   libkf5peoplewidgets5 libkf5plasmaquick5 libkf5purpose-bin libkf5purpose5 
libkf5style5 libkf5su-bin libkf5su-data libkf5su5 libkf5sysguard-bin 
libkf5sysguard-data libkfontinst5 libkfontinstui5 libkopete4 libksgrd7 
libksignalplotter7
   libkworkspace5-5 libmeanwhile1 libmediaart-2.0-0 libmusicbrainz5-2 libndp0 
libnma0 libnss-myhostname libnvidia-cfg1 libnvidia-eglcore libopenbabel4v5 
libopenconnect5 libopengl0-glvnd-nvidia libortp9 libotr5 liboxygenstyle5-5
   liboxygenstyleconfig5-5 libpgm-5.2-0 libplasma-geolocation-interface5 
libpoppler-glib8 libpowerdevilcore2 libpowerdevilui5 libprocesscore7 
libprocessui7 libprotobuf-c1 libpst4 libpwquality-common libpwquality1 
libpython3.5
   libqca2-plugin-ossl libqt5clucene5 libqt5concurrent5 libqt5designer5 
libqt5designercomponents5 libqt5help5 libqtcurve-utils2 librubberband2 
librygel-core-2.6-2 librygel-db-2.6-2 librygel-renderer-2.6-2 
librygel-server-2.6-2
   libscim8v5 libsignon-plugins-common1 libsignon-qt5-1 libsodium18 libstoken1 
libtaskmanager6 libteamdctl0 libtomcrypt0 libtommath1 libuv1 libvulkan1 
libweather-ion7 libxcb-dpms0 libxcb-glx0:i386 libxcb-record0 libxdamage1:i386
   libytnef0 libzeitgeist-2.0-0 libzmq5 mobile-broadband-provider-info 
mousetweaks network-manager network-manager-gnome nodejs nvidia-driver-bin 
nvidia-persistenced oxygen-sounds plasma-desktop-data plasma-discover-common
   plasma-integration powerdevil powerdevil-data pulseaudio-module-bluetooth 
pulseaudio-module-gconf python-zeitgeist python3-pyqt5 python3-sip qdbus-qt5 
qml-module-org-kde-activities qml-module-org-kde-analitza
   qml-module-org-kde-bluezqt qml-module-org-kde-draganddrop 
qml-module-org-kde-extensionplugin qml-module-org-kde-kcoreaddons 
qml-module-org-kde-kholidays qml-module-org-kde-kio 
qml-module-org-kde-kquickcontrols
   qml-module-org-kde-kwindowsystem qml-module-org-kde-purpose 
qml-module-org-kde-solid qml-module-qt-labs-folderlistmodel 
qml-module-qt-labs-settings qml-module-qtquick-controls-styles-breeze 
qml-module-qtquick-dialogs
   qml-module-qtquick-privatewidgets qttools5-dev-tools realmd rygel seahorse 
seahorse-daemon signon-plugin-oauth2 sni-qt software-properties-kde sshfs 
systemsettings user-manager wireless-regdb zeitgeist zeitgeist-core
   zeitgeist-datahub
 Use 'apt autoremove' to remove them.
 The following packages will be REMOVED:
   bluedevil evolution evolution-plugins gir1.2-clutter-1.0 
gir1.2-clutter-gst-1.0 gir1.2-clutter-gst-3.0 gir1.2-cogl-1.0 
gir1.2-coglpango-1.0 gir1.2-gtkclutter-1.0 gnome-contacts gnome-control-center 
gnome-sushi
   gstreamer1.0-clutter-3.0 kalgebra kalgebra-common kalzium kate kde kde-full 
kde-plasma-desktop kde-standard kdeconnect kdeedu kdemultimedia kdenetwork 
kinfocenter kopete kscreen libavogadro1 libchamplain-0.12-0
   libchamplain-gtk-

Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8

[Andy Smith]

Also same symptoms in a PV guest under Xen 4.10. Works if booted on
previous kernel. Also prevents installation of stable using the
netboot image at e.g.




Cheers,
Andy

Bug#903771: c99: buggy POSIX abs(INT_MIN)

[Vincent Lefevre]

Package: gcc
Version: 4:7.3.0-3
Severity: normal

In the new POSIX abs() specification:

  If the result cannot be represented, the result shall be {INT_MIN}.

instead of being undefined behavior. See:

  http://austingroupbugs.net/view.php?id=1108#c4041

Thus the following program


#include 
#include 
#include 

int main (void)
{
  volatile int i = INT_MIN;
  int j;

  j = abs (i);
  printf ("%d %d\n", j, j >= 0);
  return 0;
}


should output -2147483648 0 when compiled with the c99 utility. But:

zira:~> c99 -O2 -o tst tst.c
zira:~> ./tst
-2147483648 1

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

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

Versions of packages gcc depends on:
ii  cpp4:7.3.0-3
ii  gcc-7  7.3.0-25

Versions of packages gcc recommends:
ii  libc6-dev [libc-dev]  2.27-4

Versions of packages gcc suggests:
ii  autoconf  2.69-11+local1
ii  automake  1:1.15.1-3.1
ii  bison 2:3.0.4.dfsg-1+b1
pn  flex  
ii  gcc-doc   5:7.2.0-2
ii  gcc-multilib  4:7.3.0-3
ii  gdb   7.12-6+b2
ii  libtool   2.4.6-2.1+local1
ii  make  4.2.1-1.1
ii  manpages-dev  4.16-1

-- no debconf information

Bug#903770: nvidia-graphics-drivers: Cannot be upgraded in stretch 9.5 without removing several GNOME & KDE packages

[Andreas Beckmann]

On 2018-07-14 17:04, Bas Couwenberg wrote:
> The nvidia-driver packages cannot be updated as part of the stretch 9.5
> stable update without removing several GNOME & KDE packages:

>  The following NEW packages will be installed:
>libgl1 libgl1:i386 libgl1-nvidia-glx libglvnd0 libglvnd0:i386 
> libglx-nvidia0:i386 libglx0 libglx0:i386 libnvidia-glcore:i386

Most of these packages are from stretch-backports, so you are not
upgrading a clean stretch system ...

And the nvidia packages in stretch-backports now require mesa+libglvnd
from stretch-backports.


Andreas

Bug#903770: nvidia-graphics-drivers: Cannot be upgraded in stretch 9.5 without removing several GNOME & KDE packages

[Sebastiaan Couwenberg]

On 07/14/2018 05:19 PM, Andreas Beckmann wrote:
> On 2018-07-14 17:04, Bas Couwenberg wrote:
>> The nvidia-driver packages cannot be updated as part of the stretch 9.5
>> stable update without removing several GNOME & KDE packages:
> 
>>  The following NEW packages will be installed:
>>libgl1 libgl1:i386 libgl1-nvidia-glx libglvnd0 libglvnd0:i386 
>> libglx-nvidia0:i386 libglx0 libglx0:i386 libnvidia-glcore:i386
> 
> Most of these packages are from stretch-backports, so you are not
> upgrading a clean stretch system ...

They are from stretch-backports because of the apt resolver, the only
backports installed on that system are josm, qgis & libsfcgal1.

> And the nvidia packages in stretch-backports now require mesa+libglvnd
> from stretch-backports.

But I don't want the backport.

Disabling stretch-backports sources gives better results:

 The following packages will be REMOVED:
   libegl1-nvidia libgldispatch0-nvidia
 The following NEW packages will be installed:
   libegl1-glvnd-nvidia libglvnd0-nvidia libnvidia-egl-wayland1
   nvidia-egl-common nvidia-egl-icd nvidia-egl-wayland-common
   nvidia-egl-wayland-icd
 The following packages will be upgraded:
   libegl-nvidia0 libgl1-glvnd-nvidia-glx libgl1-nvidia-glvnd-glx
   libgles-nvidia1 libgles-nvidia2 libgles1-glvnd-nvidia
   libgles2-glvnd-nvidia libglx-nvidia0 libglx0-glvnd-nvidia
   libnvidia-cfg1 libnvidia-eglcore libnvidia-glcore
   libnvidia-ml1 libopengl0-glvnd-nvidia nvidia-alternative
   nvidia-driver nvidia-driver-bin nvidia-driver-libs nvidia-kernel-dkms
   nvidia-kernel-support nvidia-vdpau-driver nvidia-vulkan-icd
   xserver-xorg-video-nvidia
 23 upgraded, 7 newly installed, 2 to remove and 0 not upgraded.

I shouldn't have to disable the backports sources for `apt-get
dist-upgrade` to work correctly.

Kind Regards,

Bas

Bug#903772: tor: Fails to start with alternative config file ('Caught a bad syscall attempt (syscall openat)')

[Jan]

Package: tor
Version: 0.3.3.7-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

when trying to run an instance of Tor with a custom config file, e.g.
tor -f ~/myconf, it will fail due to a (buggy) seccomp filter:

 T= 1531579290
(Sandbox) Caught a bad syscall attempt (syscall openat)
tor(+0x1a689a)[0x56184d39189a]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x4b)[0x7f548fb333ab]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x4b)[0x7f548fb333ab]
tor(tor_open_cloexec+0x40)[0x56184d377920]
tor(start_writing_to_file+0x17a)[0x56184d38b39a]
tor(+0x1a047b)[0x56184d38b47b]
tor(+0x1a05c8)[0x56184d38b5c8]
tor(or_state_save+0x15b)[0x56184d2a97ab]
tor(+0x5497b)[0x56184d23f97b]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba)[0x7f5490d549ba]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7f5490d55537]
tor(do_main_loop+0x2b4)[0x56184d2406f4]
tor(tor_run_main+0x1025)[0x56184d242bd5]
tor(tor_main+0x3a)[0x56184d23b18a]
tor(main+0x19)[0x56184d23af19]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f548f585a87]
tor(_start+0x2a)[0x56184d23af6a]

The fix [1] mentioned in the discussion of the bug on Tor's bugtracker [2] 
solves the problem.


Regards, Jan


PS: I'm unsure whether bugs like this are supposed to be reported here. My 
apologies if they shouldn't be. However, I figured it will 1) help others 
encountering the bug and 2) make sure the package maintainer is aware of it.

[1] 
https://github.com/Jigsaw52/tor/commit/9ec292e1c45a522a7d3b3c9a1c2630bf05047990
[2] https://trac.torproject.org/projects/tor/ticket/25440


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

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

Versions of packages tor depends on:
ii  adduser 3.117
ii  libc6   2.27-3
ii  libcap2 1:2.25-1.2
ii  libevent-2.1-6  2.1.8-stable-4
ii  liblzma55.2.2-1.3
ii  libseccomp2 2.3.3-3
ii  libssl1.1   1.1.0h-4
ii  libsystemd0 239-5
ii  libzstd11.3.4+dfsg-3
ii  lsb-base9.20170808
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages tor recommends:
ii  logrotate3.11.0-0.1
ii  tor-geoipdb  0.3.3.7-1
pn  torsocks 

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
ii  socat1.7.3.2-2
pn  tor-arm  
pn  torbrowser-launcher  

-- Configuration Files:
/etc/tor/torrc changed [not included]

-- no debconf information

Bug#903773: dlocate: option -lsbin no more works (doesn't show any results anymore)

[Axel Beckert]

Package: dlocate
Version: 1.07+nmu1
Severity: important

"dlocate -lsbin $pkg" no more works for me, I always get either empty
output or solely error messages from "stat" (very likely caused by
localepurge):

→ dlocate -lsbin zsh
→ dlocate -lsbin debian-goodies
→ dlocate -lsbin dash
→ dlocate -lsbin coreutils
stat: cannot stat '/usr/share/locale/af/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/be/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/bg/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/ca/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/cs/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/da/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/el/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/eo/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/es/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/et/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/eu/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/fi/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/fr/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/ga/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/gl/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/hr/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/hu/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/ia/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/id/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/it/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/ja/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/kk/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/ko/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/lg/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/lt/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/ms/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/nb/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/nl/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/pl/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/pt/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/pt_BR/LC_MESSAGES/coreutils.mo': No such 
file or directory
stat: cannot stat '/usr/share/locale/ro/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/ru/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/sk/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/sl/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/sr/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/sv/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/tr/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/uk/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/vi/LC_MESSAGES/coreutils.mo': No such file 
or directory
stat: cannot stat '/usr/share/locale/zh_CN/LC_MESSAGES/coreutils.mo': No such 
file or directory
stat: cannot stat '/usr/share/locale/zh_TW/LC_MESSAGES/coreutils.mo': No such 
file or directory
→ dlocate -lsbin devscripts
stat: cannot stat '/usr/share/man/fr/man1/annotate-output.1.gz': No such file 
or directory
stat: cannot stat '/usr/share/man/fr/man1/archpath.1.gz': No such file or 
directory
stat: cannot stat '/usr/share/man/fr/man1/bts.1.gz': No such file or directory
stat: cannot stat '/usr/share/man/fr/man1/build-rdeps.1.gz': No such file or 
directory
stat: cannot stat '/usr/share/man/fr/man1/chdist.1.gz': No such file or 
directory
stat: cannot stat '/usr/share/man/fr/man1/checkbashisms.1.gz': No such file or 
directory
stat: cannot stat '/usr/share/man/fr/man1/cowpoke.1.gz': No such file or 
directory
stat: cannot stat '/usr/share/man/fr/man1/cvs-debc.1.gz': No such file or 
directory
stat: cannot stat

Bug#903772: tor: Fails to start with alternative config file ('Caught a bad syscall attempt (syscall openat)')

[Peter Palfrader]

On Sat, 14 Jul 2018, Jan wrote:

> Dear Maintainer,
> 
> when trying to run an instance of Tor with a custom config file, e.g.
> tor -f ~/myconf, it will fail due to a (buggy) seccomp filter:

> PS: I'm unsure whether bugs like this are supposed to be reported
> here. My apologies if they shouldn't be. However, I figured it will 1)
> help others encountering the bug and 2) make sure the package
> maintainer is aware of it.

If it's already reported upstream, then reporting it in the Debian BTS
as well is usually not helpful and just causes more work and duplicated
information.

Thanks for letting me know, though.

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#902635: qtscript-opensource-src: Please include patch to workaround memory issues on sparc64

[Lisandro Damián Nicanor Pérez Meyer]

El sáb., 14 de jul. de 2018 02:15, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> escribió:

> On 06/29/2018 07:32 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Point is: is this a fix or papering over the real problem? I would like
> to
> > know *for sure* that I'm not applying a hack with this patch. In other
> words:
> > why it should use 32bits instead of 64?
>
> It's a workaround because the 64-bit tagged pointers assume a 48 bit
> virtual
> address space as on x86_64 while SPARC has a 52-bit virtual address space.
>
> And since the Linux kernel allocates memory from top to bottom, any tagged
> pointers will get mangled on sparc64.


Totally understandable. I ACK the change then. If you can create a merge
request on salsa the better, else I'll see to do it myself soon.

Ideally it would be done in the experimental branch, as we plan to push
that version to unstable real soon now.

>
>

Bug#903774: libcommons-compress-java: Build incompatible with Java 8, without need?

[Erich Schubert]

Package: libcommons-compress-java
Version: 1.13-2
Severity: normal

Maven with Java 8 can no longer build jars.

Caused by: java.lang.NoSuchMethodError:
java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer;
    at 
org.apache.commons.compress.archivers.zip.ZipFile.tryToLocateSignature

(ZipFile.java:969)
    at
org.apache.commons.compress.archivers.zip.ZipFile.positionAtEndOfCentralDirectoryRecord
(ZipFile.java:946)
    at
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory
(ZipFile.java:874)
    at
org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory
(ZipFile.java:612)
    at org.apache.commons.compress.archivers.zip.ZipFile.
(ZipFile.java:294)
    at org.apache.commons.compress.archivers.zip.ZipFile.
(ZipFile.java:217)
    at org.apache.commons.compress.archivers.zip.ZipFile.
(ZipFile.java:186)
    at org.codehaus.plexus.archiver.jar.JarArchiver.grabFilesAndDirs
(JarArchiver.java:785)
    at org.codehaus.plexus.archiver.jar.JarArchiver.createIndexList
(JarArchiver.java:455)
    at org.codehaus.plexus.archiver.jar.JarArchiver.finalizeZipOutputStream
(JarArchiver.java:377)

This is caused by the following line:

https://sources.debian.org/src/libcommons-compress-
java/1.13-2/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java/#L969

ByteBuffer used to inherit rewind() from Buffer.

Apparently in OpenJDK11, a new override for this method was added that 
returns

a ByteBuffer, which makes method chaining easier (in older JDK,
buf.rewind().something() would only work if something is defined on Buffer).
But this new signature cannot be found with earlier JDKs, and causes the
incompatibility seen above.

The root cause is in the JDK11, here:
http://hg.openjdk.java.net/jdk/jdk11/file/a602706ccaaa/src/java.base/share/classes/java/nio/X-Buffer.java.template#l1163
which specializes the rewind() method's return type.

This issue can *possibly* be resolved by casting wordBbuf to Buffer 
where possible (it will likely also apply to flip(), clear(), reset(), 
mark(), limit(), position(), and possibly some other methods), and that 
may or may not be enough to restore compatibility with older JDKs.


But supposedly the better approach is to compile commons-compress 
against Java

8 for now?



-- 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.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcommons-compress-java depends on:
ii  libcommons-parent-java  43-1

libcommons-compress-java recommends no packages.

Versions of packages libcommons-compress-java suggests:
ii  libxz-java  1.8-2

-- no debconf information

Bug#901473: [Qa-jenkins-dev] Bug#901473: jenkins.debian.org: Vary merged-usr in reproducibility testing?

[Philipp Kern]

On 14.07.2018 13:01, Michael Biebl wrote:
> Am 14.07.2018 um 12:28 schrieb Mattia Rizzolo:
>> On Sat, Jul 14, 2018 at 11:59:37AM +0200, Michael Biebl wrote:
>>> debootstrap was changed (again) in 1.0.102 to now default to
>>> --merged-usr [1].
>>>
>>> Systems are not forcefully upgraded to a merged-usr setup atm though.
>>> buildds are regularly re-created from scratch and will thus have a
>>> merged-usr setup.
>>> This means, binaries that were built in a merged-usr buildd environment
>>> will now run on a lot of non-merged-usr setups.
>>
>> Is that really so?  I expect buildds to run with stable's debootstrap,
>> so for now they should be using non-merged-usr chroots.
> 
> I would have expected that buildds use debootstrap from unstable, but
> I'm not a buildd admin, so I trust you to know more about that then me.
> Thanks for correcting me on that and sorry if that caused confusion.

For the record: buildds usually (except new architectures) run stable
and hence have no easy way of pulling in a newer debootstrap. That also
makes them relatively easy to reason about. Packages we forked in the
past were sbuild and sometimes schroot (although we try very hard to
avoid that).

> Still, in the hopefully not too distant future, we will have such a
> debootstrap in stable, so it's probably a good idea to be prepared for
> that by then. TTBOMK, there are no plans to forcefully upgrade systems
> to a merged-usr setup on stretch → buster upgrades.

I suppose this point still stands. :)

Kind regards
Philipp Kern

Bug#903770: nvidia-graphics-drivers: Cannot be upgraded in stretch 9.5 without removing several GNOME & KDE packages

[Andreas Beckmann]

Control: tag -1 stretch wontfix
Control: retitle -1 nvidia-graphics-drivers: Cannot be upgraded in stretch 9.5 
with stretch-backports enabled (wants to remove several GNOME & KDE packages)

On 2018-07-14 17:27, Sebastiaan Couwenberg wrote:
> On 07/14/2018 05:19 PM, Andreas Beckmann wrote:
>> On 2018-07-14 17:04, Bas Couwenberg wrote:
>>> The nvidia-driver packages cannot be updated as part of the stretch 9.5
>>> stable update without removing several GNOME & KDE packages:
>>
>>>  The following NEW packages will be installed:
>>>libgl1 libgl1:i386 libgl1-nvidia-glx libglvnd0 libglvnd0:i386 
>>> libglx-nvidia0:i386 libglx0 libglx0:i386 libnvidia-glcore:i386
>>
>> Most of these packages are from stretch-backports, so you are not
>> upgrading a clean stretch system ...
> 
> They are from stretch-backports because of the apt resolver, the only
> backports installed on that system are josm, qgis & libsfcgal1.
> 
>> And the nvidia packages in stretch-backports now require mesa+libglvnd
>> from stretch-backports.
> 
> But I don't want the backport.

Probably blame it on apt for considering the backport at all ...

> Disabling stretch-backports sources gives better results:
> 
>  The following packages will be REMOVED:
>libegl1-nvidia libgldispatch0-nvidia
>  The following NEW packages will be installed:
>libegl1-glvnd-nvidia libglvnd0-nvidia libnvidia-egl-wayland1
>nvidia-egl-common nvidia-egl-icd nvidia-egl-wayland-common
>nvidia-egl-wayland-icd
>  The following packages will be upgraded:
>libegl-nvidia0 libgl1-glvnd-nvidia-glx libgl1-nvidia-glvnd-glx
>libgles-nvidia1 libgles-nvidia2 libgles1-glvnd-nvidia
>libgles2-glvnd-nvidia libglx-nvidia0 libglx0-glvnd-nvidia
>libnvidia-cfg1 libnvidia-eglcore libnvidia-glcore
>libnvidia-ml1 libopengl0-glvnd-nvidia nvidia-alternative
>nvidia-driver nvidia-driver-bin nvidia-driver-libs nvidia-kernel-dkms
>nvidia-kernel-support nvidia-vdpau-driver nvidia-vulkan-icd
>xserver-xorg-video-nvidia
>  23 upgraded, 7 newly installed, 2 to remove and 0 not upgraded.

That looks like expected. It's a bit unfortunate, but the new upstream
release requires several new/renamed/removed packages. Hopefully this 
was the last big nvidia-driver change needed in stable, switching to
390.xx for the next CVE should be more smooth (and then we will finally 
have reached a new legacy branch that has a longer support frame
upstream).

> I shouldn't have to disable the backports sources for `apt-get
> dist-upgrade` to work correctly.

That can't be solved differently in this case (unless we make the
backported packages use mesa from stretch (and *not* backports) again,
preventing installation of several backports requiring the newer mesa).
I couldn't get a working setup supporting both mesa versions (due to the
libglvnd switch), any invalid mixture of packages results in the 
backported driver not working in stable-backports at all.


Andreas

Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings

[Thomas Leuxner]

Package: linux-image-4.9.0-7-amd64
Version: 4.9.110-1

Hi,

after upgrading today I started seeing these:

Jul 14 12:46:18 edi kernel: [   29.601249] sit: IPv6, IPv4 and MPLS over IPv4 
tunneling driver
Jul 14 12:46:24 edi kernel: [   35.920488] sit: non-ECT from 238.163.0.0 with 
TOS=0x2
Jul 14 12:46:24 edi kernel: [   35.956189] sit: non-ECT from 238.163.0.0 with 
TOS=0x2
Jul 14 12:46:24 edi kernel: [   35.980514] sit: non-ECT from 238.163.0.0 with 
TOS=0x2
Jul 14 12:46:25 edi kernel: [   36.207554] sit: non-ECT from 0.12.0.0 with 
TOS=0xb
Jul 14 12:46:25 edi kernel: [   36.230568] sit: non-ECT from 0.12.0.0 with 
TOS=0x6
Jul 14 12:46:25 edi kernel: [   36.413928] sit: non-ECT from 0.12.0.0 with 
TOS=0x6
Jul 14 12:46:25 edi kernel: [   36.437173] sit: non-ECT from 0.12.0.0 with 
TOS=0x6#

Regards
Thomas


signature.asc
Description: Message signed with OpenPGP

Bug#903775: libgradle-plugins-java: fails to upgrade from 'sid' - trying to overwrite /usr/share/maven-repo/org/gradle/gradle-workers/debian/gradle-workers-debian.pom

[Andreas Beckmann]

Package: libgradle-plugins-java
Version: 4.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../4-libgradle-plugins-java_4.4-1_all.deb ...
  Unpacking libgradle-plugins-java (4.4-1) over (3.4.1-7) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-l0IZ07/4-libgradle-plugins-java_4.4-1_all.deb (--unpack):
   trying to overwrite 
'/usr/share/maven-repo/org/gradle/gradle-workers/debian/gradle-workers-debian.pom',
 which is also in package libgradle-core-java 3.4.1-7
  dpkg: considering deconfiguration of libgradle-plugins-java, which would be 
broken by installation of libgradle-core-java ...
  dpkg: yes, will deconfigure libgradle-plugins-java (broken by 
libgradle-core-java)
  Preparing to unpack .../5-libgradle-core-java_4.4-1_all.deb ...
  De-configuring libgradle-plugins-java (3.4.1-7) ...
  Unpacking libgradle-core-java (4.4-1) over (3.4.1-7) ...
  Replacing files in old package libgradle-plugins-java (3.4.1-7) ...
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-l0IZ07/4-libgradle-plugins-java_4.4-1_all.deb


cheers,

Andreas


libgradle-plugins-java_4.4-1.log.gz
Description: application/gzip

Bug#903770: nvidia-graphics-drivers: Cannot be upgraded in stretch 9.5 without removing several GNOME & KDE packages

[Sebastiaan Couwenberg]

On 07/14/2018 06:41 PM, Andreas Beckmann wrote:
> On 2018-07-14 17:27, Sebastiaan Couwenberg wrote:
>> On 07/14/2018 05:19 PM, Andreas Beckmann wrote:
>>> On 2018-07-14 17:04, Bas Couwenberg wrote:
 The nvidia-driver packages cannot be updated as part of the stretch 9.5
 stable update without removing several GNOME & KDE packages:
>>>
  The following NEW packages will be installed:
libgl1 libgl1:i386 libgl1-nvidia-glx libglvnd0 libglvnd0:i386 
 libglx-nvidia0:i386 libglx0 libglx0:i386 libnvidia-glcore:i386
>>>
>>> Most of these packages are from stretch-backports, so you are not
>>> upgrading a clean stretch system ...
>>
>> They are from stretch-backports because of the apt resolver, the only
>> backports installed on that system are josm, qgis & libsfcgal1.
>>
>>> And the nvidia packages in stretch-backports now require mesa+libglvnd
>>> from stretch-backports.
>>
>> But I don't want the backport.
> 
> Probably blame it on apt for considering the backport at all ...
> 
>> Disabling stretch-backports sources gives better results:
>>
>>  The following packages will be REMOVED:
>>libegl1-nvidia libgldispatch0-nvidia
>>  The following NEW packages will be installed:
>>libegl1-glvnd-nvidia libglvnd0-nvidia libnvidia-egl-wayland1
>>nvidia-egl-common nvidia-egl-icd nvidia-egl-wayland-common
>>nvidia-egl-wayland-icd
>>  The following packages will be upgraded:
>>libegl-nvidia0 libgl1-glvnd-nvidia-glx libgl1-nvidia-glvnd-glx
>>libgles-nvidia1 libgles-nvidia2 libgles1-glvnd-nvidia
>>libgles2-glvnd-nvidia libglx-nvidia0 libglx0-glvnd-nvidia
>>libnvidia-cfg1 libnvidia-eglcore libnvidia-glcore
>>libnvidia-ml1 libopengl0-glvnd-nvidia nvidia-alternative
>>nvidia-driver nvidia-driver-bin nvidia-driver-libs nvidia-kernel-dkms
>>nvidia-kernel-support nvidia-vdpau-driver nvidia-vulkan-icd
>>xserver-xorg-video-nvidia
>>  23 upgraded, 7 newly installed, 2 to remove and 0 not upgraded.
> 
> That looks like expected. It's a bit unfortunate, but the new upstream
> release requires several new/renamed/removed packages. Hopefully this 
> was the last big nvidia-driver change needed in stable, switching to
> 390.xx for the next CVE should be more smooth (and then we will finally 
> have reached a new legacy branch that has a longer support frame
> upstream).
> 
>> I shouldn't have to disable the backports sources for `apt-get
>> dist-upgrade` to work correctly.
> 
> That can't be solved differently in this case (unless we make the
> backported packages use mesa from stretch (and *not* backports) again,
> preventing installation of several backports requiring the newer mesa).
> I couldn't get a working setup supporting both mesa versions (due to the
> libglvnd switch), any invalid mixture of packages results in the 
> backported driver not working in stable-backports at all.

Thanks for the feedback, since this cannot fixed, you can close this bug.

Kind Regards,

Bas

Bug#903777: Very rare failure, "sem_open: File exists"

[Ian Jackson]

Package: faketime
Version: 0.9.7-2

I was running pre-release tests of dgit: autopkgtest running the DEP-8
test suites, in an schroot.  The test suite does
  faketime debchange ...

In one of my runs today, I got this error:
  + faketime @151500 dch -v 2.0-1 -m 'new upstream (did gbp import-orig)'
  sem_open: File exists

I did `ipcs' and it shows only two `Semaphore Arrays'.  (I have a lot
of `Shared Memory Segments'.)

AFAICT this error was transient even within the chroot (I think the
next test reused the chroot; they certainly passed).  I don't really
have any other information.

If you like I can run my tests in future with a modified version of
faketime, but empirically, I have never seen this error before, so
unless something has changed the failure rate is going to be one every
several years in my environment.

It may be easier to find the bug by code inspection.

I did a web search for the error message and got this bug report from
2016:
  https://github.com/wolfcw/libfaketime/issues/96

But I'm basically never sigkilling my faketime processes.  They will
occasionally get a ^C or something, I guess.  (Also, I'm not sure why
this usage of faketime needs a semaphore at all, given that that in
that bug the effect of the faketime wrapper can apparently be produced
simply by setting env vars.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#865443: Want different deletion handling in split brain mode

[Ian Jackson]

Control: retitle -1 Want different deletion handling in split brain mode

This bug had a confusing title.  I think what it is about is this:

I wrote:

> I think what you are saying is that your HEAD ("master", I think) does
> not contain these files.  However, the source package that you are
> expecting to generate _does_ contain them, since there is no patch to
> remove them.
...
> I think there are three options:
> 
> 1. You could delete the files from the orig tarball (eg by repacking).
> 
> 2. You could re-add the files to your master branch.
> 
> 3. You could add a quilt patch which deletes them.
> 
> 4. dgit could automatically generate a quilt patch which deletes them
>and include it only in the dgit view.

Felipe suggested:

> 5. dgit mimics dpkg-source and ignores deletions and thus adds the
>files back in the dgit view.

Tangentially relevant is this change in dgit 2.13:

 Changed behaviour:
  * quilt fixup: Permit creation of patches which delete files, by psssing
--include-removal to dpkg-source, and tolerating it when we do our
quilt fixup analysis.  dpkg-source has supported this since at least
stretch.  Closes:#848901.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#903756: (no subject)

[Víctor Cuadrado Juan]

retitle 903756 Please document need for creating mitmproxy CA certificate and 
running update-ca-alternatives on install

After consideration, I would prefer if a README.Debian is shipped, documenting 
the need to perform:

$ mitmproxy --listen-port 9000 # creates certs in ~/.mitmproxy
$ sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem 
/usr/local/share/ca-certificates/mitmproxy-ca-cert.crt
$ sudo update-ca-certificates

Kind regards,


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#903778: linux-image-amd64-signed-template: copyright file missing (policy 12.5)

[Andreas Beckmann]

Package: linux-image-amd64-signed-template
Version: 4.18~rc4-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

a test with piuparts revealed that your package misses the copyright
file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/#copyright-information

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

0m28.3s ERROR: WARN: Inadequate results from running adequate!
  linux-image-amd64-signed-template: missing-copyright-file 
/usr/share/doc/linux-image-amd64-signed-template/copyright

  MISSING COPYRIGHT FILE: 
/usr/share/doc/linux-image-amd64-signed-template/copyright
  # ls -lad /usr/share/doc/linux-image-amd64-signed-template
  ls: cannot access '/usr/share/doc/linux-image-amd64-signed-template': No such 
file or directory
  # ls -la /usr/share/doc/linux-image-amd64-signed-template/
  ls: cannot access '/usr/share/doc/linux-image-amd64-signed-template/': No 
such file or directory


cheers,

Andreas


linux-image-amd64-signed-template_4.18~rc4-1~exp1.log.gz
Description: application/gzip

Bug#903779: emacs-nox: copyright file missing after upgrade (policy 12.5)

[Andreas Beckmann]

Package: emacs-nox
Version: 1:25.2+1-7
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

a test with piuparts revealed that your package misses the copyright
file after an upgrade, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/#copyright-information

After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.

This was observed on the following upgrade paths:

  sid -> experimental

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

0m25.0s ERROR: WARN: Inadequate results from running adequate!
  emacs-nox: missing-copyright-file /usr/share/doc/emacs-nox/copyright

  MISSING COPYRIGHT FILE: /usr/share/doc/emacs-nox/copyright
  # ls -lad /usr/share/doc/emacs-nox
  drwxr-xr-x 2 root root 40 May 28 18:55 /usr/share/doc/emacs-nox
  # ls -la /usr/share/doc/emacs-nox/
  total 0
  drwxr-xr-x   2 root root   40 May 28 18:55 .
  drwxr-xr-x 103 root root 2160 May 28 18:55 ..

Additional info may be available here:
https://wiki.debian.org/MissingCopyrightFile

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


cheers,

Andreas


emacs-nox_1:25.2+1-7.log.gz
Description: application/gzip

Bug#841414: closed by Ian Jackson (Bug#841414: fixed in dgit 5.10)

[Ian Jackson]

Debian Bug Tracking System writes ("Bug#841414 closed by Ian Jackson 
 (Bug#841414: fixed in dgit 5.10)"):
> #841414: Should occasionally run git-gc in dgit-repos

FAOD this is not only fixed in dgit in Debian sid, but also deployed
on the Debian dgit server infrastructure.

Ian.

Bug#903514:

[James Van Zandt]

Package: gimp
Version: 2.10.2-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I may have the same problem.  I updated many packages yesterday, and today
gimp will not launch.


Christoph reported that opening a .png file generated a splash screen
then error messages about babl and python.  However, I get nothing (no
error message or splash screen) for any of these:

gimp
gimp foo.png# file does not exist
gimp g14601.png # file does exist

In each case, I got a segfault when I interrupted with ^C:

  home:~$ gimp foo.png
  ^CSegmentation fault (core dumped)

I initially did not have gimp-python installed, but installing it didn't
help.


I then tried launching gimp with strace:
  strace -o /tmp/log gimp

This time I got a splash screen (the first one I'd seen), with a progress
bar
stuck at 70%, the progress statement

 Querying new Plug-ins
 resynthesizer

plus these messages:

  GEGL-Message: 12:45:41.515: Module
'/usr/lib/x86_64-linux-gnu/gegl-0.4/ff-load.so' load error:
/usr/lib/x86_64-linux-gnu/libhogweed.so.4: undefined symbol:
__gmpn_cnd_sub_n
  GEGL-Message: 12:45:41.534: Module
'/usr/lib/x86_64-linux-gnu/gegl-0.4/ff-save.so' load error:
/usr/lib/x86_64-linux-gnu/libhogweed.so.4: undefined symbol:
__gmpn_cnd_sub_n
  Missing fast-path babl conversion detected, Implementing missing babl
fast paths
  accelerates GEGL, GIMP and other software using babl, warnings are
printed on
  first occurance of formats used where a conversion has to be synthesized
  programmatically by babl based on format description

  *WARNING* missing babl fast path(s): "R'G'B' double" to "CIE Lab double"

The strace file showed that the last file opened was
/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py:

home:~$ grep -n  "open" /tmp/log |tail -22
  39878:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/cml-explorer",
O_RDONLY) = 14
  39961:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/checkerboard",
O_RDONLY) = 14
  40059:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/cartoon", O_RDONLY) =
14
  40147:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/border-average",
O_RDONLY) = 14
  40250:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/blur", O_RDONLY) = 14
  40317:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/blinds", O_RDONLY) = 14
  40413:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/animation-play",
O_RDONLY) = 14
  40505:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/animation-optimize",
O_RDONLY) = 14
  40712:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/align-layers",
O_RDONLY) = 14
  40799:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/webexport", O_RDONLY)
= 14
  40912:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_trans",
O_RDONLY) = 14
  41229:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_resynth",
O_RDONLY) = 14
  41337:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_opacity",
O_RDONLY) = 14
  41441:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_color_levels",
O_RDONLY) = 14
  41613:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_color_huesat",
O_RDONLY) = 14
  41765:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/wavelet-denoise",
O_RDONLY) = 14
  41874:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/streak", O_RDONLY) = 14
  41955:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/separate_import",
O_RDONLY) = 14
  42063:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/separate", O_RDONLY) =
14
  42610:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/resynthesizer_gui",
O_RDONLY) = 14
  42759:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/resynthesizer",
O_RDONLY) = 14
  42875:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py",
O_RDONLY) = 14


The next time gimp froze again after opening the same file, but the
progress statement in the splash screen was:

  Querying new Plug-ins
  plugin-uncrop.py

(The last line is from memory.  The splash screen got covered by other
windows, and was not re-rendered when uncovered.)

The second strace output ended like this:

  home:~$ tail -50 /tmp/log2
  poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 0) = 0 (Timeout)
  recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily
unavailable)
  recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily
unavailable)
  recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily
unavailable)
  recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily
unavailable)
  recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily
unavailable)
  recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily
unavailable)
  recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily
unavailable)
  recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily
unavailable)
  poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
revents=POLLOUT}])
  writev(3,
[{iov_base="5\30\4\0,\2\300\3\3\0\300\3\0\5e\0\213\4\6\0-\2\300\3,\2\300\3\204\1\0\0"...,
iov_len=1688}, {iov_base=NULL, iov_len=0}, {io

Bug#902635: qtscript-opensource-src: Please include patch to workaround memory issues on sparc64

[John Paul Adrian Glaubitz]

On 07/14/2018 06:20 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> Totally understandable. I ACK the change then. If you can create a merge 
> request on salsa the better, else I'll see to do it myself soon.
> 
> Ideally it would be done in the experimental branch, as we plan to push that 
> version to unstable real soon now.

I'm testing a better fix now.

I just realized that JavaScriptCore does not enable ASLR on anything but
Darwin x86_64. With the ASLR code that's in there, we might be able to
get the code working on sparc64 with a little tweaking.

Adrian

-- 
 .''`.  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#903668: RFS: enchive/3.4-3 [ITP]

[Sergio Durigan Junior]

Control: owner -1 !
Control: tags -1 + moreinfo

On Thursday, July 12 2018, Zebulon McCorkle wrote:

>   Dear mentors,

Hello Zebulon,

>   I am looking for a sponsor for my package "enchive"
>
>  * Package name: enchive
>Version : 3.4-3
>Upstream Author : Christopher Wellons 
>  * URL : https://github.com/skeeto/enchive
>  * License : Unlicense
>Section : utils
>
>   It builds those binary packages:
>
> enchive- long-term archive encryption tool
>
>   To access further information about this package, please visit the 
> following URL:
>
>   https://mentors.debian.net/package/enchive
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x 
> https://mentors.debian.net/debian/pool/main/e/enchive/enchive_3.4-3.dsc
>
>   Or from Salsa using this command:
>
> gbp clone https://salsa.debian.org/zebmccorkle-guest/enchive.git
>
>   More information about hello can be obtained from 
> https://github.com/skeeto/enchive
>   and https://nullprogram.com/blog/2017/03/12/.

Thanks for the package.  There are some issues with it that you need to
address before we move forward.  I'll enumerate them.

1) Under the debian/ directory, you're distributing 3 files that are not
needed:

  debhelper-build-stamp
  enchive.debhelper.log
  enchive.substvars

If you run dh_clean on your package, you'll see that it removes these
files.  So please remove them.

2) You're bumping the package version (on d/changelog) every time you
make a modification, however, the package hasn't been released yet.
Your initial version should always be "3.4-1", even if you have to make
modifications.  Then, when it's released, you should start bumping the
version.

3) I like git-buildpackage and appreciate that you're using a repository
to package the software:

  https://salsa.debian.org/zebmccorkle-guest/enchive

However, I noticed that you haven't pushed the "upstream" branch, and
therefore it's not possible to use "gbp buildpackage" directly because
it can't reconstruct the upstream tarball.  Please push this branch.

4) On d/control, Standards-Version should be 4.1.5.

5) Instead of overriding dh_installchangelogs (on d/rules), you can
instead create a "debian/docs" file and list whatever files you would
like to install.  For example, I think it's a good idea to install
README.md as well.

6) You need to provide a watch file for the package.

7) On d/copyright, the "Format:" field should use https.

8) On d/copyright, instead of listing all files of the project in the
first license specification, you can just use "*" instead.  The other
license specifications below it will take care of specific cases.

9) While I commend you for choosing to license your work under the
debian/ directory with GPLv3+, in this specific case I suggest you
relicense it using the project's license (or using a license that is
compatible with it).  This is useful because sometimes you might want to
submit Debian-specific patches to upstream, and if the licenses don't
match you'll find yourself in a difficult situation.  In your case,
either the "Unlicense" public domain license, or the BSD-3-clause
license should be fine (but IANAL).

10) Still on d/copyright, the license of the first set of files should
be "public-domain", and not "UNLICENSE".  The license for src/sha256.h
is the same as the one for the .c file, and there's no need to put the
"Copyright: Public Domain" text in the "License:" field, so you can have
something like:

  Files: src/sha256.*
  Copyright: Brad Conte (brad AT bradconte.com)
  License: public-domain
   This code is presented "as is" without any guarantees.

11) Please remove the "Disclaimer:" field on d/copyright.

12) The program offers an Emacs mode, and therefore it should be
installed.  Take a look at how/where to install .el files.


Hm, I'll stop here.  There are more things I noticed, but let's start
with this list first.

Let me know if you have any questions.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#903780: gitlab: fails to install: Could not find gem 'fog-google (~> 0.5)'

[Andreas Beckmann]

Package: gitlab
Version: 10.6.5+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Selecting previously unselected package gitlab.
  (Reading database ... 
(Reading database ... 43843 files and directories currently installed.)
  Preparing to unpack .../gitlab_10.6.5+dfsg-2_all.deb ...
  Unpacking gitlab (10.6.5+dfsg-2) ...
  Setting up gitlab (10.6.5+dfsg-2) ...
  Creating/updating gitlab user account...
  adduser: Warning: The home directory `/var/lib/gitlab' does not belong to the 
user you are currently creating.
  Making gitlab owner of /var/lib/gitlab...
  [ESC][31mCould not find gem 'fog-google (~> 0.5)' in any of the gem sources 
listed in
  your Gemfile.[ESC][0m
  dpkg: error processing package gitlab (--configure):
   installed gitlab package post-installation script subprocess returned error 
exit status 1
  Errors were encountered while processing:
   gitlab


cheers,

Andreas


gitlab_10.6.5+dfsg-2.log.gz
Description: application/gzip

Bug#903781: sbuild: Please add /dev/dri to default mounts, to support running GPU-based tests

[Ximin Luo]

Package: sbuild
Version: 0.76.0-1
Severity: normal

Dear Maintainer,

Please add /dev/dri to the default sbuild mounts, this is needed to run
GPU-based tests. For example the leela-zero package cannot run tests until I
add the following line to /etc/schroot/sbuild/fstab:

/dev/dri/dev/drinonerw,bind 0   0

After that then everything works fine.

You can test by entering an schroot and running

 $ apt-get install clinfo mesa-opencl-icd
 $ clinfo -l

replacing "mesa-opencl-icd" with another package that provides opencl-icd
depending on what your graphics driver is. If everything is succesful then
clinfo will output some "Device" lines, otherwise it will only output
"Platform" lines (or nothing at all). The default sbuild setup fails, until
I add the /dev/dri line that I mentioned above.

X

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

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

Versions of packages sbuild depends on:
ii  adduser 3.117
ii  libsbuild-perl  0.76.0-1
ii  perl5.26.2-6

Versions of packages sbuild recommends:
ii  autopkgtest  5.3.1
ii  debootstrap  1.0.101
ii  schroot  1.6.10-5

Versions of packages sbuild suggests:
pn  deborphan  
ii  kmod   25-1
ii  wget   1.19.5-1

-- no debconf information

Bug#903783: minissdpd: Lots of "Address already in use" syslog messages

[Vincas Dargis]

Package: minissdpd
Version: 1.5.20180223-2
Severity: normal

Dear Maintainer,

I've discovered that syslog contains lots of "Address already in use"
messages:

```
-- Logs begin at Sat 2018-07-14 19:49:37 EEST, end at Sat 2018-07-14
21:08:02 EEST. --
liep. 14 19:49:42 vinco systemd[1]: Starting keep memory of all UPnP
devices that announced themselves...
liep. 14 19:49:42 vinco minissdpd[1815]: setsockopt(udp,
IP_ADD_MEMBERSHIP)(): No such device
liep. 14 19:49:42 vinco systemd[1]: Started keep memory of all UPnP
devices that announced themselves.
liep. 14 19:49:42 vinco minissdpd[1815]: Failed to add IPv4 multicast
membership for interface .
liep. 14 19:49:42 vinco minissdpd[1818]: ssdpDiscover: sendto: Network
is unreachable
liep. 14 19:49:42 vinco minissdpd[1818]: ssdpDiscover: sendto: Cannot
assign requested address
liep. 14 19:49:47 vinco minissdpd[1818]: setsockopt(udp,
IPV6_JOIN_GROUP)(FF02::C, ): Address already in use
liep. 14 19:49:47 vinco minissdpd[1818]: setsockopt(udp,
IPV6_JOIN_GROUP)(FF02::C, ): Address already in use
liep. 14 19:49:47 vinco minissdpd[1818]: setsockopt(udp,
IPV6_JOIN_GROUP)(FF02::C, ): Address already in use
liep. 14 19:49:49 vinco minissdpd[1818]: setsockopt(udp,
IPV6_JOIN_GROUP)(FF02::C, ): Address already in use
liep. 14 19:49:50 vinco minissdpd[1818]: setsockopt(udp,
IPV6_JOIN_GROUP)(FF02::C, ): Address already in use
```

Not sure is this expected. My provider does not give me IPV6 address
(though my OpenWRT router provides lan address), maybe I just should
have disabled ipv6, as I see now (while reporting this bug) there is
debconf option for that?

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

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

Versions of packages minissdpd depends on:
ii  debconf [debconf-2.0]  1.5.67
ii  libc6  2.27-4
ii  libnfnetlink0  1.0.1-3+b1
ii  lsb-base   9.20170808

minissdpd recommends no packages.

minissdpd suggests no packages.

-- debconf information:
* minissdpd/start_daemon: true
  minissdpd/ip6: true
* minissdpd/listen: 0.0.0.0

Bug#903768: libimlib2: The message "Using O_TMPFILE" is flooding log file

[Markus Koschany]

Control: reassign -1 src: xorg-server
Control: retitle -1 xorg-server: O_TMPFILE ErrorF should be DebugF
Control: found -1 2:1.19.6-1
Control: fixed -1 2:1.20.0-1


Am 14.07.2018 um 16:27 schrieb Dtux:
> Package: libimlib2
> Version: 1.4.8-1
> Severity: normal
> 
> Dear Maintainer,
> 
> libimlib2 (1.5.1-1) seem cause the fill up of the Xorg log file with the
> message : "Using O_TMPFILE"
> 
> like (in  Xorg.0.log )
> ...
> [   929.247] Using O_TMPFILE
> [   929.247] Using O_TMPFILE
> [   929.249] Using O_TMPFILE
> [   929.250] Using O_TMPFILE

Hi,

thanks for reporting. This issue is not caused by imlib2 but by code in
xorg-server. This issue was fixed upstream a few months ago in [1]. The
current version in Sid includes the fix and it will probably migrate to
testing sometime.

Regards,

Markus


[1]
https://cgit.freedesktop.org/xorg/xserver/commit/?id=d36128a72acac4d54813c52c93efefad2dc9af41



signature.asc
Description: OpenPGP digital signature

Bug#903782: gitea: modifies conffiles (policy 10.7.3): /etc/gitea/conf/app.ini

[Andreas Beckmann]

Package: gitea
Version: 1.3.2+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies conffiles.
This is forbidden by the policy, see
https://www.debian.org/doc/debian-policy/#configuration-files

10.7.3: "[...] The easy way to achieve this behavior is to make the
configuration file a conffile. [...] This implies that the default
version will be part of the package distribution, and must not be
modified by the maintainer scripts during installation (or at any
other time)."

Note that once a package ships a modified version of that conffile,
dpkg will prompt the user for an action how to handle the upgrade of
this modified conffile (that was not modified by the user).

Further in 10.7.3: "[...] must not ask unnecessary questions
(particularly during upgrades) [...]"

If a configuration file is customized by a maintainer script after
having asked some debconf questions, it may not be marked as a
conffile. Instead a template could be installed in /usr/share and used
by the postinst script to fill in the custom values and create (or
update) the configuration file (preserving any user modifications!).
This file must be removed during postrm purge.
ucf(1) may help with these tasks.
See also https://wiki.debian.org/DpkgConffileHandling

In https://lists.debian.org/debian-devel/2012/09/msg00412.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

debsums reports modification of the following files,
from the attached log (scroll to the bottom...):

  /etc/gitea/conf/app.ini

cheers,

Andreas


gitea_1.3.2+dfsg-3.log.gz
Description: application/gzip

Bug#903781: sbuild: Please add /dev/dri to default mounts, to support running GPU-based tests

[Johannes Schauer]

Control: reassign -1 src:schroot

Quoting Ximin Luo (2018-07-14 20:08:28)
> Please add /dev/dri to the default sbuild mounts, this is needed to run
> GPU-based tests. For example the leela-zero package cannot run tests until I
> add the following line to /etc/schroot/sbuild/fstab:
> 
> /dev/dri/dev/drinonerw,bind 0   0
> 
> After that then everything works fine.
> 
> You can test by entering an schroot and running
> 
>  $ apt-get install clinfo mesa-opencl-icd
>  $ clinfo -l
> 
> replacing "mesa-opencl-icd" with another package that provides opencl-icd
> depending on what your graphics driver is. If everything is succesful then
> clinfo will output some "Device" lines, otherwise it will only output
> "Platform" lines (or nothing at all). The default sbuild setup fails, until
> I add the /dev/dri line that I mentioned above.

this is not an "sbuild mount". What is mounted or not is a property of the
backend and in this case it's something the schroot backend has to take care
of. Thus, reassigning.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#903784: python3-pycsw: fails to install: SyntaxError

[Andreas Beckmann]

Package: python3-pycsw
Version: 2.2.0+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Selecting previously unselected package python3-pycsw.
  (Reading database ... 
(Reading database ... 9155 files and directories currently installed.)
  Preparing to unpack .../python3-pycsw_2.2.0+dfsg-3_all.deb ...
  Unpacking python3-pycsw (2.2.0+dfsg-3) ...
  Setting up python3-pycsw (2.2.0+dfsg-3) ...
File "/usr/lib/python3/dist-packages/pycsw/ogc/csw/csw2.py", line 1936
  if self.parent.async:
 ^
  SyntaxError: invalid syntax
  
File "/usr/lib/python3/dist-packages/pycsw/ogc/csw/csw3.py", line 2013
  if self.parent.async:
 ^
  SyntaxError: invalid syntax
  
File "/usr/lib/python3/dist-packages/pycsw/server.py", line 78
  self.async = False
   ^
  SyntaxError: invalid syntax
  
  dpkg: error processing package python3-pycsw (--configure):
   installed python3-pycsw package post-installation script subprocess returned 
error exit status 1
  Errors were encountered while processing:
   python3-pycsw


Could this be related to python 3.7?


cheers,

Andreas


python3-pycsw_2.2.0+dfsg-3.log.gz
Description: application/gzip

Bug#903785: falkon: Missing dependency

[Dtux]

Package: falkon
Version: 3.0.0-3
Severity: normal
Tags: patch

Dear Georges,

After install, impossible to load the shortcut thumbnail in startpage.

Error message:
qrc:data/thumbnailer.qml:2:1: module "QtWebEngine" is not installed

Install "qml-module-qtwebengine" (+qml-module-qtquick2,
libqt5webengine5,libqt5test5) solves the problem .

Best regards, Thanks.



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

Kernel: Linux 4.16.0-2-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)

Versions of packages falkon depends on:
ii  libc62.27-3
ii  libgcc1  1:8.1.0-9
ii  libkf5wallet-bin 5.47.0-1
ii  libkf5wallet55.47.0-1
ii  libqt5core5a 5.10.1+dfsg-7
ii  libqt5dbus5  5.10.1+dfsg-7
ii  libqt5gui5   5.10.1+dfsg-7
ii  libqt5network5   5.10.1+dfsg-7
ii  libqt5positioning5   5.10.1+dfsg-3
ii  libqt5printsupport5  5.10.1+dfsg-7
ii  libqt5qml5   5.10.1-4
ii  libqt5quick5 5.10.1-4
ii  libqt5quickwidgets5  5.10.1-4
ii  libqt5sql5   5.10.1+dfsg-7
ii  libqt5sql5-sqlite5.10.1+dfsg-7
ii  libqt5webchannel55.10.1-2
ii  libqt5webenginecore5 5.10.1+dfsg-4
ii  libqt5webenginewidgets5  5.10.1+dfsg-4
ii  libqt5widgets5   5.10.1+dfsg-7
ii  libqt5x11extras5 5.10.1-2
ii  libssl1.11.1.0h-4
ii  libstdc++6   8.1.0-9
ii  libxcb1  1.13-1

falkon recommends no packages.

falkon suggests no packages.

-- no debconf information

Bug#903431: binutils: new binutils version breaks valgrind, can't determine stacktraces

[Andres Freund]

Hi,

On 2018-07-09 13:34:44 -0700, Andres Freund wrote:
> after upgrading binutils (from 2.30-22 to 2.30.90.20180705-1) *newly*
> built binaries don't work well with valgrind anymore. Binaries built
> with an older version of binutils, verified by downgrading, continue
> to work well with valgrind.
> 
> The stack traces after the upgrade are useless. This both makes using
> valgrind nearly pointless, as well as breaking valgrind suppression
> files (which rely on useful backtraces).
> 
> A trivial example is the following:
> 
> $ dpkg-query --showformat='${Version}' --show binutils
> 2.30-22
> 
> $ cat ~/tmp/uninitialized.c
> int
> main(int argc, char **argv)
> {
>   int foo;
> 
>   if (foo == 3)
> return 0;
>   else
> return 1;
> }
> 
> $ gcc ~/tmp/uninitialized.c -o uninitialized
> $ valgrind ./uninitialized
> ...
> ==16745== Conditional jump or move depends on uninitialised value(s)
> ==16745==at 0x108609: main (in /home/andres/tmp/uninitialized)
> ..
> 
> # dpkg -i  *binutils*2.30.90*
> 
> $ dpkg-query --showformat='${Version}\n' --show binutils
> 2.30.90.20180627-1
> 
> $ gcc ~/tmp/uninitialized.c -o uninitialized
> ...
> ==18603== Conditional jump or move depends on uninitialised value(s)
> ==18603==at 0x109159: ??? (in /home/andres/tmp/uninitialized)
> ==18603==by 0x4CADB16: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so)
> ...
> 
> but if I force gold to be used:
> $ gcc -fuse-ld=gold ~/tmp/uninitialized.c -o uninitialized
> $ valgrind ./uninitialized
> 
> ==18665== Conditional jump or move depends on uninitialised value(s)
> ==18665==at 0x108619: main (in /home/andres/tmp/uninitialized)
> 
> so this seems somewhat likely to be related to GNU ld changes, rather
> than a valgrind issue. I haven't yet figured out which of the changes
> between the two versions is to blame

Appears to be an issue in valgrind:
https://bugs.kde.org/show_bug.cgi?id=395682#c9

I'll try to reassign the bug to valgrind.

Greetings,

Andres Freund

Bug#901312: elastix does not start: symbol lookup error: elastix: undefined symbol: _ZN8vnl_math5hypotEd

[Andreas Beckmann]

Control: notfixed -1 4.8-12
Control: close -1

On Mon, 11 Jun 2018 14:19:30 +0300 Juhani Numminen
 wrote:
> Control: fixed -1 4.8-12
> Control: retitle -1 elastix does not start: symbol lookup error: elastix: 
> undefined symbol: _ZN8vnl_math5hypotEdd
> 
> I'm not seeing this failure in buster (with the the newer ITK-4.12).
> Unfortunately I don't know how to test if the program actually works
> beyond not crashing at startup.
> 
> Bug retitled because on stretch, I am seeing the error, but I get
> two d's in the error message: "...Edd" instead of "...Ed".

This was fixed by a binNMU in stretch, included in today's point release.
binNMUs versions cannot be represented to the bts, therefore I'm
clearing the fixed version of this bug s.t. bts treats it as 'invalid'
and the bug can be closed and archived.


Andreas

Bug#903786: stretch-pu: package tor/0.2.9.16-1

[Peter Palfrader]

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

Hi!

I'd like to update Tor in stable from 0.2.9.15 to 0.2.9.16.

Primary reason is the update of the bridge authority.  The old
one went away, and it's the place that bridges report to so we can
tell clients about them.

https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=tor-0.2.9.16
has the full upstream changelog.

If you agree, I can prepare a package, and either upload it directly
or present again for review.

Ideally, we'd make the updated package available via -updates before
the next point release already.

Cheers,

Upstream diff:

[git|release-0.2.9] weasel@orinoco:~/projects/tor/tor$ diffstat d
 .editorconfig   |   33
 .travis.yml |   42
 ChangeLog   |   95
 Makefile.am |9
 ReleaseNotes|   93
 configure.ac|8
 contrib/win32build/tor-mingw.nsi.in |2
 scripts/maint/checkSpace.pl |6
 src/common/address.c|4
 src/common/crypto.c |7
 src/common/sandbox.c|   26
 src/config/geoip|32959 
 src/config/geoip6   | 8206 
 src/or/auth_dirs.inc|   34
 src/or/config.c |   34
 src/or/dirserv.c|   13
 src/or/include.am   |1
 src/or/networkstatus.c  |1
 src/or/nodelist.c   |   13
 src/or/protover.c   |   13
 src/or/relay.c  |1
 src/or/router.c |   15
 src/or/routerlist.c |2
 src/or/shared_random_state.c|1
 src/test/ntor_ref.py|9
 src/test/test_crypto.c  |   41
 src/test/test_dir.c |   20
 src/test/test_hs.c  |7
 src/test/test_shared_random.c   |2
 src/win32/orconfig.h|2
 30 files changed, 23657 insertions(+), 18042 deletions(-)

[abridged diff attached]
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/
diff --git a/ChangeLog b/ChangeLog
index 0934ae786..9b3906ab1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,4 +1,97 @@
- Changes in version 0.2.9.15 - 2018-03-03
+Changes in version 0.2.9.16 - 2018-07-13
+  Tor 0.2.9.16 moves to a new bridge authority, meaning people running
+  bridge relays should upgrade. We also take this opportunity to backport
+  other minor fixes.
+
+  o Directory authority changes:
+- The "Bifroest" bridge authority has been retired; the new bridge
+  authority is "Serge", and it is operated by George from the
+  TorBSD project. Closes ticket 26771.
+
+  o Directory authority changes (backport from 0.3.3.7):
+- Add an IPv6 address for the "dannenberg" directory authority.
+  Closes ticket 26343.
+
+  o Major bugfixes (directory authorities, backport from 0.3.4.1-alpha):
+- When directory authorities read a zero-byte bandwidth file, they
+  would previously log a warning with the contents of an
+  uninitialised buffer. They now log a warning about the empty file
+  instead. Fixes bug 26007; bugfix on 0.2.2.1-alpha.
+
+  o Minor features (sandbox, backport from 0.3.3.4-alpha):
+- Explicitly permit the poll() system call when the Linux
+  seccomp2-based sandbox is enabled: apparently, some versions of
+  libc use poll() when calling getpwnam(). Closes ticket 25313.
+
+  o Minor features (continuous integration, backport from 0.3.4.1-alpha):
+- Our .travis.yml configuration now includes support for testing the
+  results of "make distcheck". (It's not uncommon for "make check"
+  to pass but "make distcheck" to fail.) Closes ticket 25814.
+- Our Travis CI configuration now integrates with the Coveralls
+  coverage analysis tool. Closes ticket 25818.
+
+  o Minor features (compilation, backport from 0.3.4.4-rc):
+- When building Tor, prefer to use Python 3 over Python 2, and more
+  recent (contemplated) versions over older ones. Closes
+  ticket 26372.
+
+  o Minor features (geoip):
+- Update geoip and geoip6 to the July 3 2018 Maxmind GeoLite2
+  Country database. Closes ticket 26674.
+
+  o Minor bugfixes (correctness, client, backport from 0.3.4.1-alpha):
+- Upon receiving a malformed connected cell, stop processing the
+  cell immediately. Previously we would mark the connection for
+  close, but continue processing the cell as if the connection were
+  open. Fixes bug 26072; bugfix on 0.2.4.7-alpha.
+
+  o Minor bugfixes (Linux seccomp2 sandbox, backport from 0.3.4.1-alpha):
+- Allow the nanosleep() sy

Bug#901001: python3-minimal should Pre-Depend on python3.N-minimal

[Andreas Beckmann]

Followup-For: Bug #901001

Hi,

are there known upgrade problems related to this bug when upgrading
from jessie to stretch (python 3.4 -> 3.5) or could we tag this bug
as 'sid buster'?


Andreas

Bug#903787: znc: privilege escalation to admin permission (injection of rogue values in znc.conf)

[Salvatore Bonaccorso]

Source: znc
Version: 1.6.5-1
Severity: grave
Tags: patch security upstream
Justification: user security hole

Hi

See

https://github.com/znc/znc/commit/a7bfbd93812950b7444841431e8e297e62cb524e
https://github.com/znc/znc/commit/d22fef8620cdd87490754f607e7153979731c69d

which would allow privilege escalation by a remote non-admin user.

Regards,
Salvatore

Bug#903789: wine64-development: missing version 3.12-2?

[Michael Gardner]

Package: wine64-development
Version: 3.12-1
Severity: normal

I installed wine64-development, then when I tried to install the 
wine-development metapackage it failed due to requiring version >= 3.12-2. 
That's the current version of wine32-development, but wine64-development is 
still at 3.12-1 for some reason.

-- Package-specific info:
/usr/bin/wine does not exist.

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

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

Versions of packages wine64-development depends on:
ii  libc62.27-4
ii  libwine-development  3.12-1

Versions of packages wine64-development recommends:
pn  wine-development
pn  wine32-development  

Versions of packages wine64-development suggests:
pn  libwine-gecko-2.47
pn  wine64-development-preloader  

Versions of packages wine64-development is related to:
ii  fonts-wine  3.0.2-2
pn  wine-development
pn  wine32-development  
ii  wine64-development  3.12-1

-- no debconf information

Bug#903788: znc: path traversal flaw

[Salvatore Bonaccorso]

Source: znc
Version: 0.045-1
Severity: grave
Tags: patch security upstream
Justification: user security hole

Hi

See https://github.com/znc/znc/commit/a4a5aeeb17d32937d8c7d743dae9a4cc755ce773
allowing path traversal and can lead to expose some files which
shouldn't be, or potentially lead to a crash.

Regards,
Salvatore

Bug#903713: plasma-browser-integration: "This_file_is_part_of_KDE" in debian/copyright?

[Chris Lamb]

severity 903713 important
thanks

Hi Luigi,

> Finally, a request: please lower the severity of this bug. It's not a 
> regression, and I would assume good faith on something that has been the same 
> for the past 10+ years

Don't worry; good faith assumed throughout. Downgrading to non-RC :-)


Best wishes,

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

Bug#903790: ncurses: parallel build failure

[Helmut Grohne]

Source: ncurses
Version: 6.1+20180210-4
User: helm...@debian.org
Usertags: rebootstrap
Tags: unreproducible

Hi Sven,

Since very recently, I see a weird build failure for ncurses. I guess
that it is related to Ben's make-dfsg upload, but I cannot tell for sure
yet. Unfortunately, I lost the relevant build logs, but let me try to
give you as much data as I still have.

Thus far, I've seen the failure twice. The linker complains about a
truncated libmenuw.so. Presumably it happens during the objdir-test
build and linking libmenuw.so appears to happen concurrently.

Settings that reproduced the issue:
 * cross build for m68k
 * DEB_BUILD_OPTIONS="nocheck noddebs parallel=9"
 * DEB_BUILD_PROFILES=nobiarch (shouldn't matter for m68k)
 * Everything on tmpfs.
 * SCHED_BATCH

If I set parallel=1 in the very same (rebootstrap) setting, I cannot
reproduce it. Since jenkins.d.n sets parallel=1, you cannot see it there
at all.

I then tried reproducing it outside rebootstrap using sbuild, but no
matter what I tried, I couldn't reproduce it there. Turning parallel up
or down didn't help, but I don't know how reliable the issue is.

During my testing, I once ran into a native, parallel build that hung.
In the hung state, there were two make processes each consuming CPU
indefinitely. Attaching to them with strace indicated that they weren't
doing any syscalls.

I somewhat suspect that there is no failure on ncurses' side, but the
make-dfsg side is broken, but I cannot prove that suspicion.

So what can I do? I think documenting the symptoms with this bug is
vaguely useful. I suggest leaving the bug open for maybe two weeks to
accumulate more detail (if any). If it turns out that nobody else can
reproduce parallel build failures, the bug should be closed.

Hope this vague report helps. If not, please do close it.

Helmut

Bug#903791: ITP: utf8gen -- convert Unicode hexadecimal code points to UTF-8

[Paul Hardy]

Package: wnpp
Severity: wishlist
Owner: "Paul Hardy" 
Version: 1.0
Upstream Author: Paul Hardy
URL: http://unifoundry.com/utf8gen/
License: GPL 2+, GFDL 1.3+
Programming Language: C
Description: convert ASCII hexadecimal Unicode code points to UTF-8

The utf8gen package contains one program, utf8gen, which reads
hexadecimal numbers interpreted as Unicode code points and produces
formatted output.  The numbers are provided one per line.  Each
number is optionally followed by a space plus miscellaneous text.

The output is specified by providing printf(3)-style format strings
on the command line.  This provides the flexibility to print UTF-8
byte values in any desired base, echo the input value formatted as
a comment in any desired programming language, or even to provide
HTML-like table entries.  Optional miscellaneous text on each input
line can be copied to the output.

The suggested additional packages allow converting the man page
to PDF and converting the Texinfo user guide to PDF and/or HTML.

--

Paul Hardy

Bug#903698: sphinxbase: build appears broken for multiple python3 versions

[Samuel Thibault]

Paul Gevers, le ven. 13 juil. 2018 13:46:45 +0200, a ecrit:
> I think this is caused by the fact that we loop over $pyver in the
> d/rules file, but apparently that is broken for multiple python3 versions.

I don't think that's the problem: I tried to pause after the
dh_install step, and we have this:

€ find debian | grep pyt
debian/tmp/usr/lib/python2.7
debian/tmp/usr/lib/python2.7/dist-packages
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.py
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/__init__.py
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyc
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyo
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyc
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so
debian/tmp/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyo
debian/tmp/usr/lib/python3.6
debian/tmp/usr/lib/python3.6/site-packages
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/sphinxbase.py
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__init__.py
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0.0.0
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-36.pyc
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/__init__.cpython-36.opt-1.pyc
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-36.opt-1.pyc
debian/tmp/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/__init__.cpython-36.pyc
debian/tmp/usr/lib/python3.7
debian/tmp/usr/lib/python3.7/site-packages
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/sphinxbase.py
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__init__.py
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/_sphinxbase.so.0.0.0
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/_sphinxbase.so.0
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/_sphinxbase.so
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-37.opt-1.pyc
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/__init__.cpython-37.opt-1.pyc
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/__init__.cpython-37.pyc
debian/tmp/usr/lib/python3.7/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-37.pyc
debian/python3-sphinxbase.debhelper.log
debian/python3-sphinxbase.install
debian/python-sphinxbase
debian/python-sphinxbase/usr
debian/python-sphinxbase/usr/lib
debian/python-sphinxbase/usr/lib/python2.7
debian/python-sphinxbase/usr/lib/python2.7/dist-packages
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.py
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/__init__.py
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyc
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/sphinxbase.pyo
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyc
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so.0
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/_sphinxbase.so
debian/python-sphinxbase/usr/lib/python2.7/dist-packages/sphinxbase/__init__.pyo
debian/python3-sphinxbase
debian/python3-sphinxbase/usr
debian/python3-sphinxbase/usr/lib
debian/python3-sphinxbase/usr/lib/python3.6
debian/python3-sphinxbase/usr/lib/python3.6/site-packages
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/sphinxbase.py
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/__init__.py
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0.0.0
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/__pycache__
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/sphinxbase.cpython-36.pyc
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/__pycache__/__init__.cpython-36.opt-1.pyc
debian/python3-sphinxbase/usr

Bug#903380: libxmlada: FTBFS with unicode-data 11

[Nicolas Boulenguez]

Package: src:libxmlada
Followup-For: Bug #903380

Hello.

Updating libxmlada for a new unicode version requires a renaming of
the -dev package for xmlada and all its reverse dependencies.

Such migrations happen in experimental. Most packages are already
renamed for unrelated reasons (gcc-8 migration and new XMLAda
release).

The XMLAda update should be straightforward, but will have to wait for
the reupload of migrated packages to unstable, once all such changes
are finished in experimental.

Bug#903792: libclamunrar7: broken symlinks: /usr/share/doc/libclamunrar7/* -> ../libclamav7/*

[Andreas Beckmann]

Package: libclamunrar7
Version: 0.100.0-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m30.1s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libclamunrar7/changelog.gz -> ../libclamav7/changelog.gz
  /usr/share/doc/libclamunrar7/README.gz -> ../libclamav7/README.gz
  /usr/share/doc/libclamunrar7/FAQ -> ../libclamav7/FAQ
  /usr/share/doc/libclamunrar7/BUGS -> ../libclamav7/BUGS
  /usr/share/doc/libclamunrar7/AUTHORS -> ../libclamav7/AUTHORS


cheers,

Andreas


libclamunrar7_0.100.0-1.log.gz
Description: application/gzip

Bug#903793: libgmap1-dev: broken symlink: /usr/lib/x86_64-linux-gnu/libgmap.so -> libgmap.so.1.0.0

[Andreas Beckmann]

Package: libgmap1-dev
Version: 2017-11-15-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m37.4s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/libgmap.so -> libgmap.so.1.0.0

The package has these dependencies:

Package: libgmap1-dev
Source: gmap
Version: 2017-11-15-1
Depends: gmap (= 2017-11-15-1) | libgmap1 (= 2017-11-15-1)

which does not sound like a good idea if gmap does not provide the required
shared library.


cheers,

Andreas


libgmap1-dev_2017-11-15-1.log.gz
Description: application/gzip

Bug#903794: lmbench-doc: broken symlinks: /usr/share/doc/lmbench-doc/man/*.8 -> lmbench.8

[Andreas Beckmann]

Package: lmbench-doc
Version: 3.0-a9+debian.1-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + lmbench

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m27.6s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/lmbench-doc/man/memsize.8 -> lmbench.8
  /usr/share/doc/lmbench-doc/man/hello.8 -> lmbench.8
  /usr/share/doc/lmbench-doc/man/flushdisk.8 -> lmbench.8

I doubt that you wanted to place these symlinks in /usr/share/doc ...


cheers,

Andreas


lmbench-doc_3.0-a9+debian.1-2.log.gz
Description: application/gzip

Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH)

[Thomas Preud'homme]

On jeudi 12 juillet 2018 18:28:21 BST Sune Vuorela wrote:
> On Wednesday, July 11, 2018 10:08:23 PM CEST Vagrant Cascadian wrote:
> > Ideally QT_RCC_SOURCE_DATE_OVERRIDE would get set based on
> > SOURCE_DATE_EPOCH, otherwise build tools have an arbitrary growing
> 
> No. As explained, we need to look at each individual package to check if the
> timestamp is actually used for anything. It can be. It probably is.
> 
> I think a better fix might be to specifically mark in the rcc file if the
> dates are important or not. But it requires involvement upstream. (Or maybe
> if the rcc file is autogenerated or not). I don't think it is a problem for
> non- autogenerated rcc files.

Agreed, it's only a problem for files autogenerated at build time. rcc on a 
file that's part of the source tarball is gonna give a reproducible result.

Best regards,

Thomas

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

Bug#903795: upower: After update, no longer shows KbdBacklight interface

[Renan Marks]

Package: upower
Version: 0.99.8-2
Severity: normal

Dear Maintainer,

After upgrading upower to 0.99.8 from version 0.99.7, the interface 
/org/freedesktop/UPower/devices/KbdBacklight disapeared, 
although I still can change my keyboard backlight brightness by righting the 
values 0, 1 or 2 to /sys/class/leds/dell\:\:kbd_backlight/brightness.

Without the KbdBacklight interface, the KDE Plasma battery/power widget cannot 
show a slider to adjust the keyboard brightness from Desktop.

When using the UPower version 0.99.7 the interface was present and the KDE 
Plasma battery/power widget showed the slider to adjust the keyboard brightness.

Cordially,
Renan


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

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

Versions of packages upower depends on:
ii  dbus   1.12.8-3
ii  libc6  2.27-3
ii  libglib2.0-0   2.56.1-2
ii  libgudev-1.0-0 232-2
ii  libimobiledevice6  1.2.1~git20180302.3a37a4e-1
ii  libplist3  2.0.0-4
ii  libupower-glib30.99.8-2
ii  libusb-1.0-0   2:1.0.22-2
ii  udev   239-5

Versions of packages upower recommends:
ii  policykit-1  0.105-20

upower suggests no packages.

-- no debconf information

Bug#903796: open-build-service: CVE-2018-7688

[Salvatore Bonaccorso]

Source: open-build-service
Version: 2.7.4-2
Severity: important
Tags: security upstream
Forwarded: https://bugzilla.suse.com/show_bug.cgi?id=1094820

Hi,

The following vulnerability was published for open-build-service.

CVE-2018-7688[0]:
| A missing permission check in the review handling of openSUSE Open
| Build Service before 2.9.3 allowed all authenticated users to modify
| sources in projects where they do not have write permissions.

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-7688
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7688
[1] https://bugzilla.suse.com/show_bug.cgi?id=1094820

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#903797: open-build-service: CVE-2018-7689

[Salvatore Bonaccorso]

Source: open-build-service
Version: 2.7.4-2
Severity: grave
Tags: security upstream
Forwarded: https://bugzilla.suse.com/show_bug.cgi?id=1094819

Hi,

The following vulnerability was published for open-build-service.

CVE-2018-7689[0]:
| Lack of permission checks in the InitializeDevelPackage function in
| openSUSE Open Build Service before 2.9.3 allowed authenticated users
| to modify packages where they do not have write permissions.

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-7689
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7689
[1] https://bugzilla.suse.com/show_bug.cgi?id=1094819

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#886813: screen: GNU screen wipes X selection (copy buffer / clipboard) on init with TERM=xterm-256color

[Axel Beckert]

Control: tag -1 + unreproducible moreinfo

Hi Walter,

thanks for the bug report.

Walter Doekes wrote:
> That fix also fixes the following problem:
> 
>   "Soft reset shouldn't wipe out selection" (2017)
>   https://bugzilla.gnome.org/show_bug.cgi?id=789954

In the meanwhile (in March 2018) this has been marked as fixed in VTE.

> Can we get the screenrc fix replaced by one that also matches
> xterm-256color to fix the VTE bug as well? Adding an asterisk would
> suffice:
>   
>   termcapinfo xterm* 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l'

That also would have been my suggestion.

> Steps to reproduce:
> 
>   - fire up gnome-terminal
>   - put something in X selection
>   - start screen: TERM=xterm-256color screen
>   - observe how the selection has been cleared

Thanks for the very explicit steps to reproduce

But I can not reproduce this as of now in unstable, at least not with
lxterminal (which is vte-based as well). (Haven't tried it earlier,
though.)

> Yes, I am aware that this should ideally be fixed in VTE, as screen
> simply uses the :is= description as intended.

It seems as if the bug has been fixed in VTE in the meanwhile.

So I wonder if we still need that workaround in screen or if we can
just close this bug report.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#903155: #903155 tracker.debian.org is incredibly slow with certain cert9.db

[Mike Hommey]

On Sun, Jul 15, 2018 at 02:57:23AM +1000, Dmitry Smirnov wrote:
> Finally I've managed to isolate the problem.
> Removing "cert9.db" from profile folder relieves symptoms entirely.
> 
> I could not reproduce the problem on new profile created on Firefox 61 
> however I could easily reproduce on few computers around where profiles were 
> upgraded from Firefox ESR.
> 
> Structure of "cert9.db" is valid: it returns "ok" on "pragma 
> integrity_check;" and re-creating it from its own ".dump" did not have any 
> effect on the problem. I tried to remove records from "cert9.db" but could 
> not track the problem to the particular record. It seems that slowness 
> correlates with number of records in "nssPublic" table.
> 
> 
> $ sqlite3 cert9.db
> select count(*) from nssPublic;
> 355
> 
> 
> With only 355 rows, Firefox 61 cripples on "tracker.debian.org". I can't 
> explain why only one particular site is affected so much. However what seems 
> to amplify the problem is that we have "/home" (including Firefox profiles) 
> on network file system.

sqlite doesn't work well on NFS. That's a long standing known issue. See
e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1432484 (comment 30
has a workaround)

> I'm attaching problematic "cert9.db". I've used it as reproducer with new 
> Firefox profile: when copied into profile folder, opening [1] is 
> significantly slower, it takes _minutes_ if profile is on network file system 
> but opens reasonably fast if "cert9.db" is moved to tmpfs and symlinked back 
> to profile folder.
> 
> Once again, strangest thing is how much "tracker.debian.org" is affected 
> comparing to pretty much any other site.

That's because tracker.debian.org, for some reason, asks for a
client-side SSL certificate.

Mike

Bug#902897: Info received (Bug#902897: virtualbox broken by binutils master (new R_X86_64_PLT32 relocation type))

[Jan Nordholz]

(adding a few more pieces of information)

... and they also messed this up in SVN r73086; they fixed only the
switch/case statement in RelocateSectionExecDyn(), exactly the function
that is *not* exercised for VMMR0.r0 as that's an ET_REL file, not an
ET_DYN. :)

Reiterating: the rev2 patch in the upstream bugreport looks good; they
imported the wrong version into SVN.


Jan