Bug#911832: polyfill should be dropped

[Kunal Mehta]

Hi,

First, I filed  upstream
about the test failures.

However, as I looked a bit more, I'm not sure why this package exists in
Debian in the first place. The purpose of the polyfill is to have pure
PHP fallback implementations for when the PHP install is missing an
extension or on an older version. But neither of those apply to Debian
where we can just depend on the PHP extension itself.

For example, instead of depending upon php-symfony-polyfill-mbstring,
the package should depend upon php-mbstring. All of the
php-symfony-polyfill-php* packages are useless since we're already
providing PHP 7.3.

The vast majority of dependencies are in src:symfony, so it shouldn't be
too difficult to remove:

km@km-pt:~$ reverse-depends src:php-symfony-polyfill
Reverse-Depends
===
* civicrm-common(for php-symfony-polyfill-iconv)
* php-respect-validation(for php-symfony-polyfill-mbstring)
* php-symfony   (for php-symfony-polyfill-php56)
* php-symfony   (for php-symfony-polyfill-ctype)
* php-symfony   (for php-symfony-polyfill-apcu)
* php-symfony   (for php-symfony-polyfill-mbstring)
* php-symfony   (for php-symfony-polyfill-php70)
* php-symfony   (for php-symfony-polyfill-intl-icu)
* php-symfony-cache (for php-symfony-polyfill-apcu)
* php-symfony-config(for php-symfony-polyfill-ctype)
* php-symfony-console   (for php-symfony-polyfill-mbstring)
* php-symfony-doctrine-bridge   (for php-symfony-polyfill-ctype)
* php-symfony-doctrine-bridge   (for php-symfony-polyfill-mbstring)
* php-symfony-dom-crawler   (for php-symfony-polyfill-ctype)
* php-symfony-dom-crawler   (for php-symfony-polyfill-mbstring)
* php-symfony-filesystem(for php-symfony-polyfill-ctype)
* php-symfony-form  (for php-symfony-polyfill-ctype)
* php-symfony-form  (for php-symfony-polyfill-mbstring)
* php-symfony-framework-bundle  (for php-symfony-polyfill-mbstring)
* php-symfony-http-foundation   (for php-symfony-polyfill-php70)
* php-symfony-http-foundation   (for php-symfony-polyfill-mbstring)
* php-symfony-http-kernel   (for php-symfony-polyfill-ctype)
* php-symfony-inflector (for php-symfony-polyfill-ctype)
* php-symfony-intl  (for php-symfony-polyfill-intl-icu)
* php-symfony-ldap  (for php-symfony-polyfill-php56)
* php-symfony-lock  (for php-symfony-polyfill-php70)
* php-symfony-property-access   (for php-symfony-polyfill-php70)
* php-symfony-security  (for php-symfony-polyfill-php70)
* php-symfony-security  (for php-symfony-polyfill-php56)
* php-symfony-security-bundle   (for php-symfony-polyfill-php70)
* php-symfony-security-core (for php-symfony-polyfill-php56)
* php-symfony-security-csrf (for php-symfony-polyfill-php56)
* php-symfony-security-csrf (for php-symfony-polyfill-php70)
* php-symfony-security-http (for php-symfony-polyfill-php56)
* php-symfony-security-http (for php-symfony-polyfill-php70)
* php-symfony-serializer(for php-symfony-polyfill-ctype)
* php-symfony-templating(for php-symfony-polyfill-ctype)
* php-symfony-translation   (for php-symfony-polyfill-mbstring)
* php-symfony-twig-bundle   (for php-symfony-polyfill-ctype)
* php-symfony-validator (for php-symfony-polyfill-mbstring)
* php-symfony-validator (for php-symfony-polyfill-ctype)
* php-symfony-var-dumper(for php-symfony-polyfill-mbstring)
* php-symfony-web-profiler-bundle  (for php-symfony-polyfill-php70)
* php-symfony-web-server-bundle  (for php-symfony-polyfill-ctype)
* php-symfony-yaml  (for php-symfony-polyfill-ctype)
* php-webmozart-assert  (for php-symfony-polyfill-ctype)

I'm not sure how exactly the best way to remove the dependency is since
it's automatically generated from composer.json. We could update
pkg-php-tools to modify php-symfony-polyfill-* dependencies?

HTH,
-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#915296: mpb-doc: /usr/share/doc/mpb/examples/Makefile* causes unreproducibility

[Andreas Henriksson]

Hi,

Thanks for quickly fixing the reported issue.

Just wanted to also mention that to reach "fully reproducible" build,
the package still has problems in mpb-doc as the file shipped in
/usr/share/doc/mpb/examples/Makefile.gz embeds full path of build
directory and other issues.

It seems to me like the Makefiles (Makefile.am, Makefile.in and
Makefile.gz) aren't actually useful to ship in the binary package
(as EXTRA_DIST is the only content of Makefile.am it seems to be
only for upstreams purpose of marking which files should be included
in the tarball generation). I would thus suggest you simply
"rm -f usr/share/doc/mpb/examples/Makefile*" to make the package fully
reproducible.

Regards,
Andreas Henriksson

Bug#917196: qtbase 5.11.2 binNMUs in experimental

[Pino Toscano]

Hi,

while the transition is over in unstable, there are still things to do
in experimental.  Can you please issue binNMUs for affected packages
there? There should be only kmymoney.

Thanks,
-- 
Pino Toscano

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

Bug#918091: nmu: usbguard_0.7.4+ds-1

[Adrian Bunk]

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

nmu usbguard_0.7.4+ds-1 . amd64 . unstable . -m "Rebuild on current unstable"

Sponsor upload not built on up-to-date unstable,
libusbguard0 is not installable in unstable.

Source-only uploads would avoid such problems.

Bug#918092: locate: according to man-pages, --localpath should include paths but produces an error

[me]

Package: locate
Version: 4.4.2-9+b1
Severity: normal

instead of including the paths handed over through --localpath, oder instead of
following the paths edscribed in updatedb.conf, updatedb produces an error,
that the variable does not exist, or the switch in unkown.

It DOES search my other hard disks, though, if I remove /media from the
prunepaths.
Baiscally that was, what I wanted, so, if it is supposed to stay this way, man-
pages need to be updated.

Thanks!



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

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

Versions of packages locate depends on:
ii  findutils  4.4.2-9+b1
ii  libc6  2.19-18+deb8u10

locate recommends no packages.

locate suggests no packages.

-- no debconf information

Bug#917196: qtbase 5.11.2 binNMUs in experimental

[Emilio Pozuelo Monfort]

On 03/01/2019 09:19, Pino Toscano wrote:
> Hi,
> 
> while the transition is over in unstable, there are still things to do
> in experimental.  Can you please issue binNMUs for affected packages
> there? There should be only kmymoney.

Done.

Cheers,
Emilio

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

[Samuel Thibault]

Control: reopen -1
Control: affects -1 + sphinxbase

Oops, this bug was erroneously closed because its mention was remaining
in the sphinxbase changelog.

Bug#918093: doomsday: Avoid 3D models error on launcher

[jEsuSdA]

Package: doomsday
Version: 2.1.1-build2905
Severity: important

Dear Maintainer,

As you can see here:
https://tracker.dengine.net/issues/2312#change-8623

There is a problem when launching Doomsday with some 3D models and improvements
addons.

The bug provoques rendering failures.

The solution is very simple: add the LC_NUMERIC=C variable before launch
Doomsday.

So, maybe you could force modify the doomsday package to force the variable
setting and all the games will work properly.

Thanks a lot.

P.S.: In addition, there is a newer version of doomsday, so it will be
fantastic to have it with official debian packages.



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

Kernel: Linux 4.18.0-20.2-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages doomsday depends on:
ii  libfluidsynth1   1.1.8-1
ii  libminizip1  1.1-8+b1
ii  libncurses5  6.1-1
ii  libqt5gui5   5.11.2+dfsg-7
ii  libqt5x11extras5 5.11.2-2
ii  libsdl2-mixer-2.0-0  2.0.2+dfsg1-2
ii  libxrandr2   2:1.5.1-1
ii  libxxf86vm1  1:1.1.4-1+b2

doomsday recommends no packages.

doomsday suggests no packages.

-- no debconf information

Bug#918095: RM: libpcl-apps1.8 libpcl-common1.8 libpcl-dev libpcl-features1.8 libpcl-filters1.8 libpcl-io1.8 libpcl-kdtree1.8 libpcl-keypoints1.8 libpcl-ml1.8 libpcl-octree1.8 libpcl-outofcore1.8 libp

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal

This is a follow up for #917078.

Thanks!

Jochen

Bug#918031: openmpi: mpi_init pmix error (gds_dstore.c line 1030)

[Samuel Thibault]

Samuel Thibault, le jeu. 03 janv. 2019 00:42:20 +0100, a ecrit:
> Samuel Thibault, le jeu. 03 janv. 2019 00:41:57 +0100, a ecrit:
> > In the attached patch I have fixed it, and then mpirun works fine on
> > GNU/Hurd.
> 
> Here is the actual patch

Which was already merged upstream :)
https://github.com/pmix/pmix/pull/1019#event-2051528325

Samuel

Bug#918097: initramfs-tools-core: Error while building DKMS modules when kernel has all its modules built in

[Mikhail Morfikov]

Package: initramfs-tools-core
Version: 0.132
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I wanted to build a custom kernel using the linux-source package from the
Debian repository. I haven't changed much, the only thing I wanted to do is to
build in all the modules my machine needs and remove all the others. Such
kernels don't have modules in *.ko files and it looks like mkinitramfs has some
issues with that.

Basically, the problem is in the /usr/share/initramfs-tools/hook-functions
script file with the following line:

find "${DESTDIR}/lib/modules/${version}/kernel" -name '*.ko*'

Since none of the modules listed above in the file were copied to the temp
destination folder, the kernel/ subdir doesn't exist and hence the above
command returns error. The initramfs image is building fine, but DKMS packages
return something similar to the following:

# dpkg --configure -a
Setting up sysdig-dkms (0.24.1-1) ...
Removing old sysdig-0.24.1 DKMS files...

-  Uninstall Beginning 
Module:  sysdig
Version: 0.24.1
Kernel:  4.19.13-amd64-morficzny (x86_64)
- -

Status: Before uninstall, this module version was ACTIVE on this kernel.

sysdig-probe.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.19.13-amd64-morficzny/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod...

DKMS: uninstall completed.

- --
Deleting module version: 0.24.1
completely from the DKMS tree.
- --
Done.
Loading new sysdig-0.24.1 DKMS files...
Building for 4.19.13-amd64-morficzny 4.20.0-amd64-morficzny
Building initial module for 4.19.13-amd64-morficzny
Error! Bad return status for module build on kernel: 4.19.13-amd64-morficzny
(x86_64)
Consult /var/lib/dkms/sysdig/0.24.1/build/make.log for more information.
dpkg: error processing package sysdig-dkms (--configure):
 installed sysdig-dkms package post-installation script subprocess returned
error exit status 10
Errors were encountered while processing:
 sysdig-dkms

I changed my kernel config a little bit:

# egrep \=m /boot/config-4.19.13-amd64-morficzny
CONFIG_BTRFS_FS=m
CONFIG_XOR_BLOCKS=m
CONFIG_RAID6_PQ=m

And after rebuilding the kernel when I want to created the initramfs image I
can see the the kernel/ subdir:

# tree
/var/tmp/mkinitramfs_p7rDVj/usr/lib/modules/4.19.13-amd64-morficzny/kernel/
/var/tmp/mkinitramfs_p7rDVj/usr/lib/modules/4.19.13-amd64-morficzny/kernel/
├── crypto
│   └── xor.ko
├── fs
│   └── btrfs
│   └── btrfs.ko
└── lib
└── raid6
└── raid6_pq.ko

5 directories, 3 files

Will this qualify as bug or should I fix this in some way myself since it's not
the Debian distribution's kernel?



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

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

Versions of packages initramfs-tools-core depends on:
ii  coreutils8.30-1
ii  cpio 2.12+dfsg-6
ii  e2fsprogs1.44.5-1
ii  klibc-utils  2.0.4-14
ii  kmod 25-2
ii  udev 240-2

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.27.2-3

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.8-5




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwt2AAACgkQzQRoEHcb
ZSDrjg//X6cMtoFjEw3BOAg+1EpKTQ1/yfJSAW611NgsgfvvPurncPx5X3XtQ0sH
/I47mXSB4ds3/KuGIJb96SXgOChBqvfdS/7ajirGL11Ou4Ujfmb9CC0sOpUe3uba
OKNdB+QiwHMDlfKdvDMk0LXN4i7fx9hCUukAkhE1s9xbqCk+veTmHpnv5BomIoX/
AqfdmeN2Y08MDdd5K8S/g1/4fVg9QUSE8+9dP9r1Bw7nqdp4EpSj7ZSKtifSayRb
k+AENOn0nMoXQP9zTYbzIv8k3LvB6+rTBf67ST1uMGGIljuf78VveJqMvJfBgS8P
8VNDdx8O5J2U2Dn9S4j4NOiKJLkQIBELyR+hTF4AQrPJ8BHquPvvCbUyVLL9SV4S
Wz8gylSP9uWwYlEjN/9vfFtMhZIiJ5Maloow4SKYgjw6+5w7BDtpp/f35Vji2+cc
9JKf+xTVuMRmMQn43NAj6a+JcUv6i9n9wy9C9HsC2qt6NnVdTx2+YGdx+vqwAz/0
QewOxkeuHgqLrRD4aUSkrZ4Z2vcfW+5ccXiej0+QsMyHt1gWgMU3DbZcNdpK/k2+
JioqBC2aLN37FfQzAhB/KDFwJ1XmJCqi1GKdk431Z/urtAFlPB/X08aDRUf/QfVq
wwD8hUwzLB3hSHqGDmKCuY0Z/y/uz1tW7B79tPgZIiIneX3loIY=
=G9Xp
-END PGP SIGNATURE-

Bug#918055: gnss-sdr FTBFS: test failures on most architectures

[Christoph Berg]

Re: Adrian Bunk 2019-01-02 
<154646203791.10492.4665092979015134393.reportbug@localhost>
> No actual debugging done, so part of the guesses above might be wrong.

Fwiw, I guess it's been broken like that all the time, but this upload
enabled the testsuite.

Christoph

Bug#918056: Subject: adb: unable to connect for root: insufficient permissions for device

[seamlik]

Without the `udev` rules you will have to run ADB with root permission. 
Installing `android-sdk-platform-tools-common` will set you up a working `udev` 
rules.

Unfortunately for now you will need to install it from Sid, as some components 
of the SDK are broken and removed from Testing.



signature.asc
Description: OpenPGP digital signature

Bug#917789: Wrong tarball id (pristine-tar) when import-orig with --components

[Guido Günther]

Hi,
On Thu, Jan 03, 2019 at 02:01:15AM +, Mo Zhou wrote:
> On Sun, Dec 30, 2018 at 12:53:18PM +0100, Guido Günther wrote:
> > > I noticed that the pristine-tar tarball id for the source is incorrect
> > > if the set of orig-tarballs are imported with
> > > 
> > >   gbp-import-orig XXX.orig.tar.xz --components YYY
> > > 
> > > For example, after importing the opencv tarball, I have to manually
> > > fix the reference for the main component, while the id "contrib"
> > > component is correct:
> > 
> > By incorrect I _assume_ you mean it's pointing to the wrong tree? gbp
> > basically passes on data to pristine tar - it doesn't calculate these
> > things by itself so I would again _assume_ it's pointing pristine-tar to
> > the wrong git tree? Which tree is it pointing as in your case and which
> > tree should it point at?
> > The whole machinery is in use by e.g. thunderbird since some time so I
> > don't think it completely bogus.
> >  -- Guido
> 
> Yes, it's pointing to a wrong tree. The correct reference should be
> 
>   ~/D/o/opencv ❯❯❯ git cat-file -p upstream
>   tree a18a03170473e1773e1f571e561441bc83a3861e
> 
> However gbp/pristine-tar refers a67d0acc9952eb94c9dc0f50eb1f73777695418e
> (I don't know what this hash points to)
> 
> Another observation is that, the tarball can be checked out from the
> repo where orig tarballs were imported. But after cloning the repo to
> another machine, doing the same checkout would end up with failure,
> even if all branches and commits have been pushed.

What's your checkout command on the other machine? Did you specify the
components. Please don't omit the commands you're using for import and
export
 -- Guido

Bug#918098: .pyc files not deleted

[Laurent Bigonville]

Source: python3-stdlib-extensions
Version: 3.7.2-1
Severity: serious

Hi,

When upgrading the packages today, dpkg is showing the follwing
messages:

[...]
Dépaquetage de python3-lib2to3 (3.7.2-1) sur (3.7.1-1) ...
dpkg: avertissement: impossible de supprimer l'ancien répertoire  « 
/usr/lib/python3.6/lib2to3/pgen2 » : Le dossier n'est pas vide
dpkg: avertissement: impossible de supprimer l'ancien répertoire  « 
/usr/lib/python3.6/lib2to3/fixes » : Le dossier n'est pas vide
dpkg: avertissement: impossible de supprimer l'ancien répertoire  « 
/usr/lib/python3.6/lib2to3 » : Le dossier n'est pas vide
[...]
Dépaquetage de python3-distutils (3.7.2-1) sur (3.7.1-1) ...
dpkg: avertissement: impossible de supprimer l'ancien répertoire  « 
/usr/lib/python3.6/distutils/command » : Le dossier n'est pas vide
dpkg: avertissement: impossible de supprimer l'ancien répertoire  « 
/usr/lib/python3.6/distutils » : Le dossier n'est pas vide
dpkg: avertissement: impossible de supprimer l'ancien répertoire  « 
/usr/lib/python3.6 » : Le dossier n'est pas vide

And indeed, the directories are still existing with a log of .pyc files
in them.

AFAIKS, python3-stdlib-extensions is not using dh_python (why?) but a custom
postinst/prerm script and this is not working as expected.

Kind regards,

Laurent Bigonville

-- 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.19.0-1-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#873341: SBT is uninstallable; depends on nonexistent packages

[Antonio Ospite]

On Fri, 07 Dec 2018 22:57:34 +0100
Antonio Ospite  wrote:

> Package: sbt
> Version: 0.13.13-2
> Followup-For: Bug #873341
> 
> Dear Maintainer,
> 
> just a curiosity, are you trying to package the latest 0.13.x version or
> the newer 1.x version? https://www.scala-sbt.org/download.html
>

BTW, it looks like sbt is actually installable again in
debian unstable, as its dependencies libsbt-test-interface-java and
libscala-tools-sbinary-java are readily available.

So this bug report could be closed IMHO, and a new one about using a
new upstream version may be opened.

Anyways from the little I've seen, for sbt to be really usable with
the majority of projects, the combination of sbt and scala versions
also matters.

For instance, some downloadable packages are not available for the
combination sbt_0.13 and scala_2.11 which is what we have in debian.

The most supported combinations seem to be:
  - sbt_0.13 + scala_2.10
  - sbt_1.0 + scala_2.12

An example of this can be seen by trying to locally build sbt itself,
or scala[1], or the kaitai compiler mentioned below.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845113#22

> JFYI I would use sbt to try to build the Kitai Struct compiler:
> https://github.com/kaitai-io/kaitai_struct_compiler
> 

Are there any plans to improve the situation?

Thank you,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#918099: what is so special about TZ?

[積丹尼 Dan Jacobson]

Package: bash-completion
Version: 1:2.8-5

Why does
$ grep TZ a
not expand?
$ grep TZa a
Does.

Same problem with ls, whatever command.

No there is no file called TZ.

No other environment variable names don't trigger the problem.

Bug#918097: initramfs-tools-core: Error while building DKMS modules when kernel has all its modules built in

[Mikhail Morfikov]

It looks like the DKMS error was because of my mistake and not the initramfs
one -- the ARCH=x86_64 env variable caused the issue, so just ignore the info 
about 
DKMS.



signature.asc
Description: OpenPGP digital signature

Bug#912975: [Pkg-xen-devel] Bug#912975: xen-hypervisor-4.8-amd64: Dom0 crashes randomly without logs on Debian Stretch with Xen 4.8.4

[Patrick Beckmann]

Hi,

this bug description sounds a lot like a problem we have with two Xen
Dom0s, so I am replying here.

One of our machines has been running stable on Debian 8 and was newly
upgraded to Debian 9, another one is new hardware with a fresh
installation. With the most recent Debian 9 they crash at a rate from
every 3 days to 3 times a day, suspected to be depending on load.
Versions are
- Xen hypervisor: 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
- Linux Kernel:   4.9.130-2

On Tue, 6 Nov 2018 18:54:53 +0100 Hans van Kranenburg 
wrote:
> Are you able to configure and capture output from serial console?

We have been able to capture the output of our new machine crashing.
Please find it attached to this e-mail. Unfortunately it lacks the lines
during boot time. If you need them or any other information, please let
me know.

> Can you confirm that this is the only change that you made between the
> before/after scenario? I mean, if you downgrade the packages, or you
> drop the old hypervisor xen-x.y-amd64.gz in /boot again, it's stable again?

We would try this next with Xen version
4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9.

Best Regards,
Patrick Beckmann
[SOL Session operational.  Use ~? for help]
[   99.992731] xen-blkback: backend/vbd/19/51712: prepare for reconnect

[  101.634684] xen-blkback: backend/vbd/20/51712: prepare for reconnect

[  103.653671] xen-blkback: backend/vbd/19/51712: using 4 queues, protocol 1 
(x86_64-abi) persistent grants

[  103.827314] vif vif-19-0 vif19.0: Guest Rx ready

[  103.827427] IPv6: ADDRCONF(NETDEV_CHANGE): vif19.0: link becomes ready

[  103.827534] br02: port 15(vif19.0) entered blocking state

[  103.827541] br02: port 15(vif19.0) entered forwarding state

[  104.476998] xen-blkback: backend/vbd/20/51712: using 4 queues, protocol 1 
(x86_64-abi) persistent grants

[  104.660889] vif vif-20-0 vif20.0: Guest Rx ready

[  104.661018] IPv6: ADDRCONF(NETDEV_CHANGE): vif20.0: link becomes ready

[  104.661168] br026: port 2(vif20.0) entered blocking state

[  104.661184] br026: port 2(vif20.0) entered forwarding state

(XEN) d8 L1TF-vulnerable L1e 01a23320 - Shadowing
(XEN) d8 L1TF-vulnerable L1e 01a23320 - Shadowing
(XEN) d8 L1TF-vulnerable L1e 01a23320 - Shadowing
(XEN) d11 L1TF-vulnerable L1e 020c3320 - Shadowing
(XEN) d13 L1TF-vulnerable L1e 01a3b320 - Shadowing
(XEN) d15 L1TF-vulnerable L1e 01a23320 - Shadowing



Debian GNU/Linux 9 caribou hvc0



caribou login: 


Debian GNU/Linux 9 caribou hvc0



caribou login: [ 4676.600094] br02: port 14(vif17.0) entered disabled state

[ 4676.744064] br02: port 14(vif17.0) entered disabled state

[ 4676.745573] device vif17.0 left promiscuous mode

[ 4676.745618] br02: port 14(vif17.0) entered disabled state

[ 4683.146619] br02: port 14(vif21.0) entered blocking state

[ 4683.146678] br02: port 14(vif21.0) entered disabled state

[ 4683.146921] device vif21.0 entered promiscuous mode

[ 4683.153997] IPv6: ADDRCONF(NETDEV_UP): vif21.0: link is not ready

[ 4683.639331] xen-blkback: backend/vbd/21/51712: using 1 queues, protocol 1 
(x86_64-abi) 

[ 4684.544484] xen-blkback: backend/vbd/21/51712: prepare for reconnect

[ 4684.938636] xen-blkback: backend/vbd/21/51712: using 1 queues, protocol 1 
(x86_64-abi) 

[ 4692.235692] xen-blkback: backend/vbd/21/51712: prepare for reconnect

[ 4694.917436] vif vif-21-0 vif21.0: Guest Rx ready

[ 4694.917800] IPv6: ADDRCONF(NETDEV_CHANGE): vif21.0: link becomes ready

[ 4694.917918] br02: port 14(vif21.0) entered blocking state

[ 4694.917926] br02: port 14(vif21.0) entered forwarding state

[ 4694.921344] xen-blkback: backend/vbd/21/51712: using 2 queues, protocol 1 
(x86_64-abi) persistent grants




Debian GNU/Linux 9 caribou hvc0



caribou login: (XEN) [ Xen-4.8.5-pre  x86_64  debug=n   Not tainted ]
(XEN) CPU:32
(XEN) RIP:e008:[] 
guest_4.o#sh_page_fault__guest_4+0x75d/0x1e30
(XEN) RFLAGS: 00010202   CONTEXT: hypervisor (d8v0)
(XEN) rax: 7fb5797e6580   rbx: 8310f4372000   rcx: 81c0e060
(XEN) rdx:    rsi: 8310f4372000   rdi: 0001fed5
(XEN) rbp: 8310f4372000   rsp: 8340250e7c78   r8:  0001fed5
(XEN) r9:     r10:    r11: 
(XEN) r12: 81c0e06ff6a8   r13: 0407fad6   r14: 830078da7000
(XEN) r15: 8340250e7ef8   cr0: 80050033   cr4: 00372660
(XEN) cr3: 00407ec02001   cr2: 81c0e06ff6a8
(XEN) fsb: 7fb58fc26700   gsb:    gss: 8801fea0
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen code around  
(guest_4.o#sh_page_fault__guest_4+0x75d/0x1e30):
(XEN)  ff ff 03 00 4e 8d 24 c1 <49> 8b 0c 24 f6 c1 01 0f 84 b6 06 00 00 48 c1 e1
(XEN) Xen stack trace from rsp=8340250e7c78:
(XEN)7fb5797e6580 027372df 82d080323600 8310f4372648
(XEN)8310f43726a8 027372df 8340250e7d50 8340250e7d98

Bug#918100: syncthing: new upstream 1.0.0

[Jonatan Nyberg]

package: syncthing
severity: normal

Please consider to upgrade to the current upstream version
(1.0.0).

Regards,
Jonatan

Bug#918101: cfengine3: Please package new LTS release (3.12) before Buster freezes

[Moritz Schlarb]

Source: cfengine3
Severity: wishlist

Dear Maintainer,

please consider packaging the latest LTS release (3.12.1) before the Buster
freezes begin.

IMHO this makes sense if you look at the upstream support timeline at
https://cfengine.com/product/supported-versions/ - support for 3.10 will stop
just after Buster is actually released, whereas 3.12 will overlap more with the
Buster support timeline.

Christoph and I are happy to help with the package maintanance.

Regards,
Moritz



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

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

Bug#918056: Subject: adb: unable to connect for root: insufficient permissions for device

[Yvan Masson]

Le 03/01/2019 à 10:44, seam...@debian.org a écrit :
> Without the `udev` rules you will have to run ADB with root permission. 
> Installing `android-sdk-platform-tools-common` will set you up a working 
> `udev` rules.
> 
> Unfortunately for now you will need to install it from Sid, as some 
> components of the SDK are broken and removed from Testing.
> 

Thanks for the fast answer! You are right, installing
android-sdk-platform-tools-common from sid solved the issue.

Regards,
Yvan



signature.asc
Description: OpenPGP digital signature

Bug#873341: SBT is uninstallable; depends on nonexistent packages

[Emmanuel Bourg]

Hi Antonio,

Le 03/01/2019 à 10:59, Antonio Ospite a écrit :

> Are there any plans to improve the situation?

We lack contributors to maintain the Scala ecosystem in Debian and some
help would be really welcome. I spent some time updating our scala
package but I'm not a Scala developer and I don't have the time to look
into this anymore.

If someone wants to pick the ball the next steps are to:
1. build SBT 1.0 without the embedded libraries
2. build Scala 2.12

Emmanuel Bourg

Bug#917638: SOLVED. I am awfully sorry (Was: Bug#917638: infnoise: Job dev-infnoise.device/start failed with result 'timeout')

[Mader, Alexander]

Gegen 21:31 des 01.01.19 verlautete von Stephen Kitt:

That suggests something wrong with the device :-(. Does it show up when you
run lsusb? Mine shows

Bus 001 Device 039: ID 0403:6015 Future Technology Devices International, Ltd 
Bridge(I2C/SPI/UART/FIFO)


Hello Stephen,

I really beg your pardon: I did not read the full description and just 
thought to install a software talking to standard devices not realizing 
the need for the extra hardware.


There is no device attached to the computer, therefore everything works 
as expected. Please, close the report. I wish this embarrassment could 
be deleted permanently :-(


I am sorry for bothering you.

Best regards, Alexander.

Bug#918102: simple-cdd: build of custom iso failes in docker container with not tty and openssl 1.1.0j-1~deb9u1 installed

[Mayer, Dirk]

Package: simple-cdd
Version: 0.6.6

Hello Debian community,
when I try to build a custom Debian installer ISO with simple-cdd and the 
latest openssl libs installed, the following (truncated) error occurs:

$ build-simple-cdd --conf detox.conf --logfile detox_mirror.log --verbose 
--debug --mirror-only
...
...
2019-01-03 10:21:52,957 INFO detox.conf: new var keyboard=en_US
2019-01-03 10:21:52,957 INFO detox.conf: new var locale=en_US.UTF-8
gpg: directory '/home/bob/.gnupg' created
gpg: /home/bob/.gnupg/trustdb.gpg: trustdb created
2019-01-03 10:21:53,048 DEBUG Checking configuration...
2019-01-03 10:21:53,185 DEBUG Creating build environment in 
/builds/pd-de/systec/detox/CI/make_iso/simple_cdd...
2019-01-03 10:21:53,195 ERROR GPG standard error: gpg: cannot open '/dev/tty': 
No such device or address
2019-01-03 10:21:53,196 ERROR GPG standard error: 
2019-01-03 10:21:53,196 ERROR Importing 
/usr/share/keyrings/debian-archive-keyring.gpg into 
/builds/pd-de/systec/detox/CI/make_iso/simple_cdd/tmp/gpg-keyring failed, gpg 
error code 2

The build environment is a NON-interactive Debian stretch container with NO tty 
available.
The container has the latest ssl related packages installed: 
$ apt list libssl1.1 openssl gnupg2
gnupg2/now 2.1.18-8~deb9u3 all [installed,local]
libssl1.1/now 1.1.0j-1~deb9u1 amd64 [installed,local]
openssl/now 1.1.0j-1~deb9u1 amd64 [installed,local]

$ uname -a
Linux 21be976d7d1f 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) x86_64 
GNU/Linux
$ cat /etc/debian_version
9.6

Before the upgrade from openssl 1.1.0f-3+deb9u2 to the current version this was 
not an issue.

The following (attached) patch adds a '--batch' parameter to the gpg calls in 
the file simple_cdd/gnupg.py
This prevents the error message complaining about no tty available. With this 
change I am able to build Debian ISOs inside a Docker container again.
However, it makes sense to use the batch parameter in non-interactive 
environments anyway.

$ git format-patch master

>From e0ee289a03835dd563c13df7fe555fd15c3a04a8 Mon Sep 17 00:00:00 2001
From: Dirk Mayer 
Date: Thu, 3 Jan 2019 10:14:41 +0100
Subject: [PATCH] added --batch param to gpg calls

Signed-off-by: Dirk Mayer 
---
 simple_cdd/gnupg.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/simple_cdd/gnupg.py b/simple_cdd/gnupg.py
index 78ffe7e..628b924 100644
--- a/simple_cdd/gnupg.py
+++ b/simple_cdd/gnupg.py
@@ -30,7 +30,7 @@ class Gnupg:


 def common_gpg_args(self):
-args = ["gpg", "--no-default-keyring"]
+args = ["gpg", "--batch", "--no-default-keyring"]
 for k in self.env.get("keyring"):
 args.extend(("--keyring", k))
 return args
@@ -66,7 +66,7 @@ class Gnupg:
 """
 env = dict(os.environ)
 env["GNUPGHOME"] = self.env.get("GNUPGHOME")
-proc = subprocess.Popen(["gpg", "--import", keyring_file], 
stdout=subprocess.PIPE, stderr=subprocess.PIPE, env=env)
+proc = subprocess.Popen(["gpg", "--batch", "--import", keyring_file], 
stdout=subprocess.PIPE, stderr=subprocess.PIPE, env=env)
 stdout, stderr = proc.communicate()
 retval = proc.wait()
 if retval != 0:
@@ -80,6 +80,7 @@ class Gnupg:
 keyring file
 """
 keys_raw = subprocess.check_output(["gpg",
+"--batch",
 "--no-default-keyring",
 "--keyring", keyring_file,
 "--list-keys",
--
2.17.1




0001-added-batch-param-to-gpg-calls.patch
Description: 0001-added-batch-param-to-gpg-calls.patch

Bug#916750: lighttpd: reorganize lighttpd binary packages to reduce dependencies (ldap/mysql) and package count

[Helmut Grohne]

Happy new year!

In the mean time, Glenn Strauss and nobody else replied. I intend to
proceed with the drafted plan:

On Tue, Dec 18, 2018 at 09:55:34AM +0100, Helmut Grohne wrote:
>  * lighttpd-modules-mysql: mod_authn_mysql, mod_mysql_vhost,
>mod_vhostdb_mysql

Glenn Strauss proposed calling the module lighttpd-modules-mariadb.
Stefan Bühler said that the functions still call mysql_ and #include
. Therefore the package shall be called lighttpd-modules-mysql.

>  * lighttpd-modules-ldap: mod_authn_ldap, mod_vhostdb_ldap

Proceed.

>  * lighttpd (base package): mod_access, mod_accesslog, mod_alias,
>mod_auth, mod_authn_file, mod_cgi, mod_dirlisting, mod_evasive,
>mod_evhost, mod_expire, mod_extforward, mod_fastcgi,
>mod_flv_streaming, mod_indexfile, mod_proxy, mod_redirect,
>mod_rewrite, mod_rrdtool, mod_scgi, mod_secdownload, mod_setenv,
>mod_simple_vhost, mod_sockproxy, mod_ssi, mod_staticfile, mod_status,
>mod_uploadprogress, mod_userdir, mod_usertrack, mod_vhostdb,
>mod_wstunnel

Keep.

>  * The modules mod_authn_gssapi, mod_cml, mod_geoip, mod_magnet,
>mod_trigger_b4_dl and mod_webdav presently have their own binary
>packages and they each have significant library piles. Maybe it is
>best to leave these as is.

Keep.

>  * The remaining modules are mod_compress, mod_deflate and mod_openssl.
>These pull zlib1g, libbz2-1.0 and libssl1.1. At least the first two
>are transitively essential already and mod_openssl seems to be very
>popular, so it likely is best to leave them with the main binary
>package.

Keep these with the main lighttpd base package. Rationale:

While splitting out mod_openssl is an interesting idea in future, doing
so will become easier once lighttpd gains Provides. Presently splitting
does not bear a benefit as lighttpd itself calls RAND_poll from openssl,
so the dependency will be kept anyway. This is not a final "no". We'll
create lighttpd-mod-openssl now as a virtual package. People can start
depending on it.

> Then Stefan and Glenn proposed adding new modules:
>  * mod_vhostdb_dbi
>  * mod_vhostdb_pgsql
>  * mod_authn_pam
>  * mod_authn_sasl

Given Stefans and Glenns input, I think adding four binary packages is a
reasonable tradeoff. I'll look into adding them.

Therefore my plan is:

 * Add lighttpd-mod-* Provides.
 * Add lighttpd-modules-mysql.
 * Add transitional dummy packages lighttpd-mod-authn-mysql
   lighttpd-mod-mysql-vhost.
 * Add lighttpd-modules-ldap.
 * Add transitional dummy package lighttpd-mod-autn-ldap.
 * Add real packages lighttpd-mod-vhostdb-dbi,
   lighttpd-mod-vhostdb-pgsql, lighttpd-mod-authn-pam,
   lighttpd-mod-authn-sasl.
 * lighttpd Recommends all modules that it formerly included and puts up
   a NEWS.Debian explaining the split.

I intend to perform these (and only these) changes in experimental, give
it a brief testing period and then push them to unstable.

After buster:
 * Drop transitional dummy packages.
 * Demote Recommends to Suggests.

For buster, we'll gain 6 binary packages. After buster, we drop 2.

Other changes (that do not add binary packages) can be performed on
unstable in parallel.

Please raise objections quickly.

Helmut

Bug#918103: ipv6: Consider sk_bound_dev_if when binding a socket to an address

[Ralf Jung]

Package: linux-image-4.18.0-0.bpo.3-amd64
Version: 4.18.20-2~bpo9+1
Severity: normal
Tags: upstream

Dear Maintainer,

I reported an upstream bug at 
 that got a patch 
submitted with .
It would be great to have this patch applied to the next Debian kernel update.

Kind regards,
Ralf

Bug#793404: massive waste of CPU time in debian/rules by inline commands

[Niels Thykier]

Hi,

In the past 3½ years, several things have been improved and I am
therefore taking the liberty of closing this bug against general
(remaining issues as I understand it will be in individual packages).

In particular, I think we have identified all major issues, solved most
of them and triaged/assigned the remaining ones.

For individual packages, improvements are often a question of:

 * Migrating to "Rules-Requires-Root: no" where possible.
 * Avoid calling dpkg-parsechangelog directly and instead use dpkg's
   makefile snippets.
 * Replace "comment only" override targets with completely empty
   override targets.

(Not necessarily listed in order of "best performance for value" as that
depends on exactly what the package does)

On Fri, 24 Jul 2015 12:19:36 +0200 Jakub Wilk  wrote:
> * Jonas Smedegaard , 2015-07-23, 21:40:
> >>One mistake boost makes is using ":=" instead of plain "=". Contrary 
> >>to popular belief, the former almost always causes more evaluation of 
> >>$(shell) stuff, specially when dh is involved.
> >Could you elaborate on that?
> 
> dpkg-buildpackage -B will run debian/rules 4 times: once to determine if 
> build-arch exist, and once for every target: clean, build(-arch), 
> binary-arch.
> 
> dh adds even more debian/rules invocations. It runs it once every target 
> (clean, build(-arch), binary-arch), and once for every override.
> 
> So your ":=" variable will be evaluated 4 times, or 7+N times if you use 
> dh.
> 
> "=" variables will be evaluated only when they are used, which is less 
> than 4 or 7+N in most cases.
> 
> -- 
> Jakub Wilk
> 
> 

This issue is still prevalent but we now have support for reducing the
number of calls to debian/rules, which is "opt-in" for packages at the
moment.

With "Rules-Requires-Root: no" (recently added to policy), you can
remove two debian/rules invocation on the dpkg side and one on the dh
side.  Which brings us down to:

  * 2 calls from dpkg (one for clean and one for the binary target)
  * 2+N calls for dh to probe the rules file for override targets plus
the N (non-empty) overrides a package might have.


Guillem Jover wrote:
> Control: block -1 by 793330
> 
> Hi!
> 
> [...]
> 
> There are multiple culprits that pile up here:
> 
> 1) The /usr/share/dpkg/architecture.mk and /usr/share/dpkg/buildflags.mk
>lazy and caching value initialization is not effective. I had noticed
>it but had not yet checked if it was a problem with the makefiles or
>in make, etc. It appears is a bad interaction with the foreach, which
>defeats the lazy and cached evaluation. I guess I'll try to make the
>foreach work, or revert to an unrolled implementation.
> 

I believe this has been fixed now.

> 2) debhelper's Dh_Lib.pm does not try to use existing dpkg-architecture
>variables from the environment. Those should not be expected to be
>present, but when using dpkg-buildpackage they will be present so it
>would be an optimization. I'll file a bug report about this.
> 

This has been fixed now.

> 3) Slow dpkg-parsechangelog implementation and usage:
> 

Lintian now flags use of dpkg-parsechangelog in most cases and
recommends people to migrate to the optimized makefile snippets in dpkg.

https://lintian.debian.org/tags/debian-rules-parses-dpkg-parsechangelog.html

>> In the emulated m68k environment, it spends about half an hour (guessed,
>> not measured) before starting the actual build, doing things like:
>> 
>> |  \_ /usr/bin/perl -w /usr/bin/dh build --with python2 --with python3
>> |  \_ /usr/bin/make -f debian/rules override_dh_auto_configure
>> |  \_ /bin/sh -c dpkg-parsechangelog | grep Version | cut -d' ' 
>> -f2
>> |  \_ /usr/bin/perl /usr/bin/dpkg-parsechangelog
>> |  |   \_ /usr/bin/perl /usr/lib/dpkg/parsechangelog/debian 
>> -ldebian/changelog --file debia
> 
> 3.1) As mentioned in the thread, callers can avoid the other shell
>  commands and pipes by using -S.
> 

(Will be handled by the lintian tag)

> 3.2) debian/rules (or debhelper/cdbs) will still call the program for
>  different changelog values. But dpkg-buildpackage has to parse the
>  current and previous entries anyway, so we could preset values for
>  those in the environment that could opportunistically be used by
>  debian/rules and debhelper/cdbs. A possible drawback is that
>  packages might accidentally rely on those variables w/o setting
>  them beforehand.
> 

This has not been implemented.  However, debhelper has implemented two
features to improve performance here:

 * debhelper now uses the Dpkg module internally instead of forking
   dpkg-parsechangelog, which reduces a bit of runtime.

 * debhelper now caches the result from d/changelog so we at most parse
   that file once per helper needs to know the version ($dh{VERSION}).
   (Down from "one per binary package built per helper needing
   $dh{VERSION}")

In the default sequence, the only (non-error) 

Bug#916279: qemu-system-common: Overwrite /usr/share/doc-base/qemu-system-doc without declaring replacement

[Michael Tokarev]

Control: severity -1 minor

02.01.2019 1:03, Laurent Bigonville wrote:

Le 1/01/19 à 21:35, Michael Tokarev a érit :

[]>>> Well this bug has been reopened that mean that the package will never 
migrate


That's sort of unfortunate...


Indeed, it would be unfortunate to not have 3.1 in buster.


Current 2.12 in buster is quite buggy, I didn't realize how buggy it really 
is.. :(
To me the main priority was to let 3.1 into buster as fast as possible.


You could either close the bug if you are sure it will not cause an issue on 
upgrade, or maybe ask the release team?


I'll downgrade the severity of it for now, since the main
part is fixed by the last upload anyway.

Thanks!

/mjt

Bug#905335: botan: Incomplete debian/copyright?

[GCS]

Hi Chris,

On Fri, Aug 3, 2018 at 11:09 AM Chris Lamb  wrote:
> I just ACCEPTed botan from NEW but noticed it was missing attribution
> in debian/copyright for at least a pcks11 code copy and (possibly?) a
> curve25519 code copy.
>
> This is in no way exhaustive so please check over the entire package
> carefully and address these on your next upload.
 I've update the package to its 2.8.0 version and it's in the NEW
queue with corrected debian/copyright.
If you have time, please review it.

Thanks,
Laszlo/GCS

Bug#918104: include current tramp

[積丹尼 Dan Jacobson]

Package: emacs-common
Version: 1:26.1+1-3
Severity: wishlist
File: /usr/share/emacs/26.1/lisp/net/tramp.elc

Please always use freshest tramp. Upstream is already at 2.41.

Bug#915504: sbt: Fails to detect version of java

[Antonio Ospite]

Package: sbt
Version: 0.13.13-2
Followup-For: Bug #915504

Dear Maintainer,

the issue has been fixed upstream:
https://github.com/sbt/sbt-launcher-package/commit/5a0bde442dec7d9a1bdc35655541902fb873172a#diff-edd0ab5838b2fa424d30f94df800e1f9

Some other fixes are also upstream:
https://github.com/sbt/sbt-launcher-package/commit/a638ad49ac484ba87e512f6dfebf8aa83e4b3ad7#diff-edd0ab5838b2fa424d30f94df800e1f9
https://github.com/sbt/sbt-launcher-package/commit/21cf71e384b8d3dba4c56d167837a9236d294c9d#diff-edd0ab5838b2fa424d30f94df800e1f9

Since sbt-launch-lib.bash is a self contained script, creating a patch
from the latest upstream version should not be too problematic:

$ cd /tmp
$ wget 
https://raw.githubusercontent.com/sbt/sbt-launcher-package/master/src/universal/bin/sbt-launch-lib.bash
$ diff -u /usr/share/sbt/bin/sbt-launch-lib.bash sbt-launch-lib.bash

Ciao,
   Antonio

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

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

Versions of packages sbt depends on:
ii  libsbt-java0.13.13-2
ii  openjdk-8-jre [java8-runtime]  8u191-b12-2

sbt recommends no packages.

sbt suggests no packages.

-- no debconf information
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#873341: SBT is uninstallable; depends on nonexistent packages

[Antonio Ospite]

On Thu, 3 Jan 2019 11:45:29 +0100
Emmanuel Bourg  wrote:

> Hi Antonio,
> 
> Le 03/01/2019 à 10:59, Antonio Ospite a écrit :
> 
> > Are there any plans to improve the situation?
> 
> We lack contributors to maintain the Scala ecosystem in Debian and some
> help would be really welcome. I spent some time updating our scala
> package but I'm not a Scala developer and I don't have the time to look
> into this anymore.
>

Thank you Emmanuel, I am not a Scala developer either, I just wanted to
build one project written in it, and I was trying to do so using the
tools provided in Debian.

> If someone wants to pick the ball the next steps are to:
> 1. build SBT 1.0 without the embedded libraries
> 2. build Scala 2.12
>

I was wondering if downgrading scala to 2.10 might be somewhat useful
and less work. Fedora is also still shipping scala 2.10.

Ciao,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#917904: tightvncserver does not ask for password set by vncpasswd

[Ola Lundqvist]

Hi

You should have a log file in ~/.vnc

I think the following configuration files are worth saving and checking:
/etc/vnc.conf
~/.vncrc
/etc/X11/xorg.conf (should only be for font stuff though)

I think the $authType is of most importance. It should be
$authType = "-rfbauth $vncUserDir/passwd";

Also an output of "ps xa" can help as you will then know if -rfbauth hass
been added to the Xtightvncserver command or not run by tightvncserver
script.

// Ola

On Wed, 2 Jan 2019 at 15:46, Christoph Terasa  wrote:

> Hi Ola,
>
> thank you for your answer. I checked:
>
> $ ls -l /etc/alternatives/vnc*
> lrwxrwxrwx 1 root root 24 Jul 27  2017 /etc/alternatives/vncconnect ->
> /usr/bin/tightvncconnect
> lrwxrwxrwx 1 root root 40 Jul 27  2017 /etc/alternatives/vncconnect.1.gz
> -> /usr/share/man/man1/tightvncconnect.1.gz
> lrwxrwxrwx 1 root root 23 Jul 27  2017 /etc/alternatives/vncpasswd ->
> /usr/bin/tightvncpasswd
> lrwxrwxrwx 1 root root 39 Jul 27  2017 /etc/alternatives/vncpasswd.1.gz ->
> /usr/share/man/man1/tightvncpasswd.1.gz
> lrwxrwxrwx 1 root root 23 Jul 27  2017 /etc/alternatives/vncserver ->
> /usr/bin/tightvncserver
> lrwxrwxrwx 1 root root 39 Jul 27  2017 /etc/alternatives/vncserver.1.gz ->
> /usr/share/man/man1/tightvncserver.1.gz
>
>
> Before I will purge my configuration as well, I would try to keep my
> system in its current state. Is there are way to get more debugging info
> from tightvncserver, or a log file? The man page does not seem to mention
> anything in that regard.
>
>
> kind regards,
> Christoph
>
>
> On 1/2/19 1:26 AM, Ola Lundqvist wrote:
>
> Hi Jan
>
> Thank you for the report.
> I have now tested this myself. I purged all vnc software installed,
> installed tightvncserver, run tightvncserver and then run vncpasswd to set
> a password.
> I failed to reproduce the problem. I'm asked for a password.
>
> So the question is what you did differently. Can it be so that you have
> some other vncpasswd software as an alternative and that happen to not be
> updating the same things?
>
> Best regards
>
> // Ola
>
> On Mon, 31 Dec 2018 at 15:33, Jan Christoph Terasa 
> wrote:
>
>> Package: tightvncserver
>> Version: 1:1.3.9-9
>> Severity: grave
>> Tags: security
>> Justification: user security hole
>>
>> Dear Maintainer,
>>
>> I installed tightvncserver on my VPS machine via apt. This did set up
>> tightvncserver as an alternative for vncserver. Using a normal user
>> account and
>> starting vncserver for the first time asks for a 8-letter password. My
>> assumption
>> is this password will be used to authenticate users when connecting to
>> the vnc
>> server.
>>
>> After starting the vnc server via vncserver script, it is served on port
>> 5901.
>> On the client machine I use vinagre to connect to the server on port
>> 5901. When
>> connecting, I am not asked for a password, but rather directly taken to
>> the X
>> session. I would have expected the server to ask for the password I
>> specified
>> earlier.
>>
>> As a workaround, to ensure the integrity of the system, I set up iptable
>> rules to
>> not allow direct WAN connections to this port, but only allow local
>> connections
>> and use an SSH tunnel for connecting to the vnc server.
>>
>>
>> kind regards,
>> Christoph
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers oldstable-updates
>>   APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500,
>> 'oldstable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.14.17--std-ipv6-64 (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/bash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages tightvncserver depends on:
>> ii  libc62.27-8
>> ii  libjpeg62-turbo  1:1.5.2-2+b1
>> ii  libx11-6 2:1.6.7-1
>> ii  libxext6 2:1.3.3-1+b2
>> ii  perl 5.28.0-3
>> ii  x11-common   1:7.7+19
>> ii  x11-utils7.7+4
>> ii  xauth1:1.0.10-1
>> ii  xserver-common   2:1.20.3-1
>> ii  zlib1g   1:1.2.11.dfsg-1
>>
>> Versions of packages tightvncserver recommends:
>> ii  x11-xserver-utils  7.7+8
>> ii  xfonts-base1:1.0.4+nmu1
>>
>> Versions of packages tightvncserver suggests:
>> pn  tightvnc-java  
>>
>> -- no debconf information
>>
>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> /  o...@inguza.comFolkebogatan 26\
> |  o...@debian.org   654 68 KARLSTAD|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>  ---
>
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/

Bug#917586: other kernel change affecting nvidia

[Luca Boccassi]

Control: tags -1 pending

On Thu, 2019-01-03 at 02:54 +0100, Jiri Palecek wrote:
> Hello,
> 
> commit 
> https://github.com/torvalds/linux/commit/ae2b01f37044c10e975d22116755
> df56252b09d8 
> also affects nvidia. vm_insert_pfn is used in 
> nvidia-drm/nvidia-drm-gem-nvkms-memory.c. It can be easily converted
> to 
> vmf_insert_pfn, by removing the following switch (which only
> converts 
> the errno to a vm fault, which vmf_... returns directly).
> 
> With this and the ipmi_user_t fixed, nvidia module can be compiled
> again.
> 
> Regards
> 
>  Jiri Palecek


Yes there's a few more, the fixes are pending upload.

-- 
Kind regards,
Luca Boccassi

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

Bug#917984: [Pkg-dpdk-devel] Bug#917984: Bug#917984: Bug#917984: Can not link ODP with newer DPDK

[Luca Boccassi]

On Thu, 2019-01-03 at 02:29 +0300, Dmitry Eremin-Solenikov wrote:
> Hello,
> 
> чт, 3 янв. 2019 г. в 02:09, Luca Boccassi :
> > On Wed, 2019-01-02 at 14:55 +0300, Dmitry Eremin-Solenikov wrote:
> > > ср, 2 янв. 2019 г. в 14:49, Luca Boccassi :
> > > > On Wed, 2019-01-02 at 01:43 +0300, Dmitry Eremin-Solenikov
> > > > wrote:
> > > > Strange that libtool is messing things up, I've used the same
> > > > pkgconfig
> > > > file in a few different projects that use autoconf/automake and
> > > > I
> > > > haven't seen this issue.
> > > 
> > > libtool rearranges/squashes linking flags in an attempt to find
> > > 'better'
> > > linking flags. Unfortunately this fail for DPDK. We have worked
> > > around
> > > this by squashing all PMDs into a single gcc argument:
> > > -Wl,--whole-archive,-lrte_pmd_af_packet,-lrte_pmd_ark,,-
> > > lrte_pmd_vmxnet3_uio,--no-whole-archive
> > > -ldpdk
> > > 
> > > Thus libtool won't move PMDs from --whole-archive/--no-whole-
> > > archive
> > > brackets.
> > > 
> > > > I had a look on github, and it does not seem that odp is
> > > > currently
> > > > using pkg-config, but rather doing some manual check - is there
> > > > a
> > > > branch in a fork or a patch you could point me to so that I can
> > > > try
> > > > to
> > > > reproduce?
> > > 
> > > No, I have not pushed my code to github yet. The easies way to
> > > reproduce
> > > is to statically link a sample program with libtool and check
> > > that
> > > generated
> > > ELF contains all PMDs.
> > 
> > That looks like a very very old libtool bug:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650
> > 
> > Have you tried patching config/ltmain.sh as it's suggested on that
> > bug?
> 
> I can try doing that as a test, but I wouldn't like to have patched
> ltmain.sh
> in the source tree.

Another workaround has been suggested and I've verified that it works:
parse the output of pkg-config --libs --static libdpdk and change the
string "-Wl,--whole-archive -lrte_pmdfoo -lrte_pmdbar ... -Wl,--no-
whole-archive" intoto "-Wl,--whole-archive,-lrte_pmdfoo,-
lrte_pmdbar,...,--no-whole-archive"

Basically, trick libtool into thinking that it's a single linker flag:

libtool --mode=link --tag=CC gcc test.o -o a.out -lrte_telemetry -lrte_bpf 
-lrte_flow_classify -lrte_pipeline -lrte_table -lrte_port -lrte_vhost 
-lrte_security -lrte_sched -lrte_reorder -lrte_rawdev -lrte_pdump -lrte_power 
-lrte_meter -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni -lrte_jobstats 
-lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -lrte_distributor 
-lrte_cryptodev -lrte_compressdev -lrte_cfgfile -lrte_bitratestats -lrte_bbdev 
-lrte_acl -lrte_timer -lrte_hash -lrte_metrics -lrte_pci -lrte_ethdev -lrte_net 
-lrte_mbuf -lrte_mempool -lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline 
-Wl,--whole-archive,-lrte_common_cpt,-lrte_common_dpaax,-lrte_common_octeontx,-lrte_bus_dpaa,-lrte_bus_fslmc,-lrte_bus_ifpga,-lrte_bus_pci,-lrte_bus_vdev,-lrte_bus_vmbus,-lrte_mempool_bucket,-lrte_mempool_dpaa,-lrte_mempool_dpaa2,-lrte_mempool_octeontx,-lrte_mempool_ring,-lrte_mempool_stack,-lrte_pmd_af_packet,-lrte_pmd_ark,-lrte_pmd_atlantic,-lrte_pmd_avf,-lrte_pmd_avp,-lrte_pmd_axgbe,-lrte_pmd_bond,-lrte_pmd_bnx2x,-lrte_pmd_bnxt,-lrte_pmd_cxgbe,-lrte_pmd_dpaa,-lrte_pmd_dpaa2,-lrte_pmd_e1000,-lrte_pmd_ena,-lrte_pmd_enetc,-lrte_pmd_enic,-lrte_pmd_failsafe,-lrte_pmd_fm10k,-lrte_pmd_i40e,-lrte_pmd_ifc,-lrte_pmd_ixgbe,-lrte_pmd_kni,-lrte_pmd_liquidio,-lrte_pmd_mlx4,-lrte_pmd_mlx5,-lrte_pmd_netvsc,-lrte_pmd_nfp,-lrte_pmd_null,-lrte_pmd_octeontx,-lrte_pmd_pcap,-lrte_pmd_qede,-lrte_pmd_ring,-lrte_pmd_sfc,-lrte_pmd_softnic,-lrte_pmd_tap,-lrte_pmd_thunderx,-lrte_pmd_vdev_netvsc,-lrte_pmd_vhost,-lrte_pmd_virtio,-lrte_pmd_vmxnet3,-lrte_pmd_aesni_gcm,-lrte_pmd_aesni_mb,-lrte_pmd_caam_jr,-lrte_pmd_ccp,-lrte_pmd_dpaa_sec,-lrte_pmd_dpaa2_sec,-lrte_pmd_null_crypto,-lrte_pmd_octeontx_crypto,-lrte_pmd_openssl,-lrte_pmd_crypto_scheduler,-lrte_pmd_virtio_crypto,-lrte_pmd_octeontx_compress,-lrte_pmd_qat,-lrte_pmd_zlib,-lrte_pmd_dpaa_event,-lrte_pmd_dpaa2_event,-lrte_pmd_octeontx_event,-lrte_pmd_opdl_event,-lrte_pmd_skeleton_event,-lrte_pmd_sw_event,-lrte_pmd_dsw_event,-lrte_pmd_bbdev_null,-lrte_pmd_skeleton_rawdev,-lrte_pmd_dpaa2_cmdif,-lrte_pmd_dpaa2_qdma,-lrte_pmd_ifpga_rawdev,--no-whole-archive
 -lrte_telemetry -lrte_bpf -lrte_flow_classify -lrte_pipeline -lrte_table 
-lrte_port -lrte_vhost -lrte_security -lrte_sched -lrte_reorder -lrte_rawdev 
-lrte_pdump -lrte_power -lrte_meter -lrte_member -lrte_lpm -lrte_latencystats 
-lrte_kni -lrte_jobstats -lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev 
-lrte_efd -lrte_distributor -lrte_cryptodev -lrte_compressdev -lrte_cfgfile 
-lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash -lrte_metrics 
-lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf -lrte_mempool -lrte_ring -lrte_eal 
-lrte_kvargs -lrte_cmdline -Wl,-Bdynamic -Wl,--no-as-needed -pthread -lm -ldl 
-lnuma -lz -lIPSec_MB -lpcap -lbsd -lmnl -lmlx4 -lpthread -lmlx5

Bug#917859: vim FTBFS building for armel,armhf on arm64

[James McCoy]

On Wed, Jan 02, 2019 at 06:53:29PM +, Steve McIntyre wrote:
> Hi James, and Happy New Year to you and yours!

Thanks!

> On Mon, Dec 31, 2018 at 10:50:25AM -0500, James McCoy wrote:
> >The "Test_compiler line 24" one is odd.  All that test does is create a
> >file foo.pl
> >
> >#!/usr/bin/perl -w
> >use strict;
> >$foo=1;
> >
> >and then run "perl -c foo.pl".  It expects there to be 1 line of output,
> >stating that "$foo" isn't declared.  However, there appears to be 11
> >lines of output.  That should be easy to verify independently.
> >
> >Is there a way for me to replicate this new environment on the
> >porterboxes so I can debug further?
> 
> amdahl is the arm64 porterbox, and I've just checked - it has armel
> and armhf schroots configured too. That should hopefully cover what
> you need - shout if you need anything more!

Unfortunately, I wasn't able to reproduce either of the issues on
amdahl.  I built in both armel and armhf chroots.

Still looking into the screen dump issue.  In the mean time, I'll be
pulling in a new upstream patch level soon, so I guess we can see if
that helps at all.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#917607: udev 240 Makes System Unbootable; rootfs Not Found

[Vincent Lefevre]

On 2018-12-29 16:06:38 -0800, Leo L. Schwab wrote:
>   JPGs attached.  The messages appear to be coming from initramfs,
> which is trying to locate and mount the rootfs, and failing.

Same problem, with the keyboard not working, so that I couldn't do
anything here. I reported the bug against the Linux kernel, because
everything is fine with a 4.18 kernel (which I had fortunately kept,
otherwise I would have to find a rescue CD somewhere...):

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

FYI, /etc/fstab contains:

[some comments]
#
# / was on /dev/sda5 during installation
UUID=4bcb3bbd-f516-4ddf-be96-6fa3a8cdc8a0 /   ext4
errors=remount-ro 0   1
# swap was on /dev/sda6 during installation
UUID=3a31982a-76fe-493b-a6b0-a627706c26c7 noneswapsw
  0   0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0
/dev/sr1/media/cdrom1   udf,iso9660 user,noauto 0   0
/dev/sdb1   /media/mem  auto user,noauto,noatime0   0

I've also installed a 4.9 kernel from stable, and it doesn't work
either.

cventin:~> ll /boot
total 94072
-rw-r--r-- 1 root root  3311600 2018-11-23 20:15:55 System.map-4.18.0-3-amd64
-rw-r--r-- 1 root root  3345217 2018-12-30 10:04:03 System.map-4.19.0-1-amd64
-rw-r--r-- 1 root root  3195896 2018-10-27 20:46:16 System.map-4.9.0-8-amd64
-rw-r--r-- 1 root root   204256 2018-11-23 20:15:55 config-4.18.0-3-amd64
-rw-r--r-- 1 root root   206377 2018-12-30 10:04:03 config-4.19.0-1-amd64
-rw-r--r-- 1 root root   186563 2018-10-27 20:46:16 config-4.9.0-8-amd64
drwxr-xr-x 5 root root 4096 2019-01-03 10:35:40 grub/
-rw-r--r-- 1 root root 24916605 2018-12-18 10:13:40 initrd.img-4.18.0-3-amd64
-rw-r--r-- 1 root root 25372831 2019-01-03 09:57:04 initrd.img-4.19.0-1-amd64
-rw-r--r-- 1 root root 21031503 2019-01-03 10:35:35 initrd.img-4.9.0-8-amd64
-rw-r--r-- 1 root root  5126016 2018-11-23 20:15:55 vmlinuz-4.18.0-3-amd64
-rw-r--r-- 1 root root  5172512 2018-12-30 10:04:03 vmlinuz-4.19.0-1-amd64
-rw-r--r-- 1 root root  4232992 2018-10-27 20:46:16 vmlinuz-4.9.0-8-amd64

Perhaps what makes 4.18 work is that initrd.img-4.18.0-3-amd64 is
old enough.

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

Bug#918105: munin-plugins-core: postgres_connections_ return zeros after 2.0.44-1~bpo9+1 upgrade

[Vincas Dargis]

Package: munin-plugins-core
Version: 2.0.44-1~bpo9+1
Severity: normal

Dear Maintainer,

I have noticed that postgres_connections_* graphs started rendering zero
height graphs after upgrading munin from Streth Backports. This is
output example:

```
# munin-run postgres_connections_ALL
active.value 0
idle.value 0
idletransaction.value 0
unknown.value 0
waiting.value 0
```

Please see screenshot attached.

There's no way numbers should be actually zero - this is production
system, and this reproduced on three different machines.

Other plugin, like postgres_connections_db, still works fine:

```
 munin-run postgres_connections_db
 db_v2.value 29
 postgres.value 0
 template1.value 0
```

There are no relevant error messages in munin-node.log.

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

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/6 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)

Versions of packages munin-plugins-core depends on:
ii  munin-common  2.0.44-1~bpo9+1
ii  perl  5.24.1-3+deb9u5

Versions of packages munin-plugins-core recommends:
ii  libnet-snmp-perl  6.0.1-2

Versions of packages munin-plugins-core suggests:
ii  acpi  1.7-1+b1
ii  conntrack 1:1.4.4+snapshot20161117-5
pn  default-mysql-client  
ii  ethtool   1:4.8-1+b1
ii  hdparm9.51+ds-1+deb9u1
pn  libcache-cache-perl   
ii  libdbd-mysql-perl 4.041-2
ii  libdbd-pg-perl3.7.4-1~pgdg90+1
ii  libhttp-date-perl 6.02-1
ii  liblwp-useragent-determined-perl  1.07-1
ii  libnet-dns-perl   1.07-1
ii  libnet-ip-perl1.26-1
pn  libnet-irc-perl   
pn  libnet-ldap-perl  
ii  libnet-netmask-perl   1.9022-1
pn  libnet-telnet-perl
ii  libxml-parser-perl2.44-2+b1
ii  libxml-simple-perl2.22-1
ii  lm-sensors1:3.4.0-4
ii  logtail   1.3.18
ii  net-tools 1.60+git20161116.90da8a0-1
ii  python3   3.5.3-1
ii  ruby  1:2.3.3
ii  smartmontools 6.5+svn4324-1

-- no debconf information

Bug#918044: petsc4py: breaks slepc4py autopkgtests

[Drew Parsons]

Source: petsc4py
Followup-For: Bug #918044

It's the other way around.  slepc4py depends on petsc4py, petsc4py
does not depend on slepc4py.

As far as I can see the tests are working fine.  slepc4py 3.9 requires
petsc4py 3.9, and therefore fails when attempting to install with
petsc4py 3.10.  The versioned dependencies are already there.

The true villain here is numpy, I think.

Drew

Bug#917722: pybind11: FTBFS: dh_auto_test: returned exit code 2

[Drew Parsons]

Source: pybind11
Followup-For: Bug #917722

This looks like more fallout from the new numpy.  Bad numpy, bad.

Bug#918051: maildir-utils: Please enable guile-2.2 on armel and ia64

[Norbert Preining]

Hi Adrian,

> guile-2.2 is now available on both armel and ia64,
> please enable it also there.

https://lists.debian.org/debian-tex-maint/2018/12/msg00019.html

No foreseeable action from my side in the future.

Sorry for the inconveniences

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#918106: linux-image-4.9.0-8-amd64: segfault with logrotate

[marc Revival]

Package: src:linux
Version: 4.9.130-2
Severity: important

Dear Maintainer,


   * What led up to the situation?

A  logrotate in the cron is rotating all the logs daily of a rsyslog (> 2 TB)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
i try a fsck and safe-upgrade or full upgrade with no results on the
segfault.

   * What was the outcome of this action?
Nothing better
   * What outcome did you expect instead?
No segfault and a logrotate that end with
a positiv result.

Thanks

-- Package-specific info:
** Version:
Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.130-2 (2018-10-27)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-8-amd64 root=/dev/mapper/VG0-slash ro quiet

** Not tainted

** Kernel log:
[3.096359] PM: Image not found (code -22)
[3.096362] PM: Hibernation image not present or could not be loaded.
[3.174896] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: 
(null)
[3.962764] ip_tables: (C) 2000-2006 Netfilter Core Team
[4.146857] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[4.147329] systemd[1]: Detected virtualization vmware.
[4.147393] systemd[1]: Detected architecture x86-64.
[4.148555] random: crng init done
[4.148596] random: 7 urandom warning(s) missed due to ratelimiting
[4.183538] systemd[1]: Set hostname to .
[5.27] systemd[1]: Listening on Device-mapper event daemon FIFOs.
[5.444570] systemd[1]: Listening on Journal Socket.
[5.444625] systemd[1]: Listening on udev Kernel Socket.
[5.444686] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[5.444709] systemd[1]: Reached target Remote File Systems.
[5.444757] systemd[1]: Listening on Journal Socket (/dev/log).
[5.763542] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro
[6.221680] vmw_vmci :00:07.7: Found VMCI PCI device at 0x11080, irq 16
[6.223181] vmw_vmci :00:07.7: Using capabilities 0xc
[6.236827] Guest personality initialized and is active
[6.238885] VMCI host device registered (name=vmci, major=10, minor=58)
[6.238925] Initialized host personality
[6.310305] NET: Registered protocol family 40
[7.935252] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
[7.935262] ACPI: Power Button [PWRF]
[7.951039] ACPI: AC Adapter [ACAD] (on-line)
[8.131446] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[8.131473] sr 1:0:0:0: Attached scsi generic sg0 type 5
[8.131628] sd 2:0:0:0: Attached scsi generic sg1 type 0
[8.131734] sd 2:0:1:0: Attached scsi generic sg2 type 0
[8.131839] sd 2:0:2:0: Attached scsi generic sg3 type 0
[8.131937] sd 2:0:3:0: Attached scsi generic sg4 type 0
[8.181580] [drm] Initialized
[8.182287] input: PC Speaker as /devices/platform/pcspkr/input/input5
[8.198738] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 
10737418240 ms ovfl timer
[8.198742] RAPL PMU: hw unit of domain pp0-core 2^-0 Joules
[8.198745] RAPL PMU: hw unit of domain package 2^-0 Joules
[8.198748] RAPL PMU: hw unit of domain dram 2^-0 Joules
[8.321344] [drm] DMA map mode: Using physical TTM page addresses.
[8.321594] [drm] Capabilities:
[8.321600] [drm]   Rect copy.
[8.321602] [drm]   Cursor.
[8.321603] [drm]   Cursor bypass.
[8.321605] [drm]   Cursor bypass 2.
[8.321606] [drm]   8bit emulation.
[8.321607] [drm]   Alpha cursor.
[8.321609] [drm]   Extended Fifo.
[8.321610] [drm]   Multimon.
[8.321612] [drm]   Pitchlock.
[8.321613] [drm]   Irq mask.
[8.321614] [drm]   Display Topology.
[8.321616] [drm]   GMR.
[8.321617] [drm]   Traces.
[8.321619] [drm]   GMR2.
[8.321620] [drm]   Screen Object 2.
[8.321622] [drm]   Command Buffers.
[8.321623] [drm]   Command Buffers 2.
[8.321625] [drm]   Guest Backed Resources.
[8.321627] [drm] Max GMR ids is 64
[8.321629] [drm] Max number of GMR pages is 65536
[8.321631] [drm] Max dedicated hypervisor surface memory is 0 kiB
[8.321633] [drm] Maximum display memory size is 4096 kiB
[8.321636] [drm] VRAM at 0xe800 size is 4096 kiB
[8.321638] [drm] MMIO at 0xfe00 size is 256 kiB
[8.321641] [drm] global init.
[8.321763] [TTM] Zone  kernel: Available graphics memory: 8209152 kiB
[8.321766] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[8.321768] [TTM] Initializing pool allocator
[8.321775] [TTM] Initializing DMA pool allocator
[8.322075] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[8.322082] [drm] No driver support for vblank timestamp query.
[8.322624] [drm] Screen Target Display device initialized
[8.322708] [drm] width 640
[8.322726] [drm] height

Bug#477498: Prix

[Cocconi Danilo]

From: Cocconi Danilo
Sent: Thursday, January 3, 2019 7:53 AM
Subject: Prix

Vous avez un prix. Contactez 
(donationi...@sbcglobal.net) pour plus de 
détails.

Bug#916750: lighttpd: reorganize lighttpd binary packages to reduce dependencies (ldap/mysql) and package count

[Helmut Grohne]

Control: tags -1 + patch

On Thu, Jan 03, 2019 at 12:04:33PM +0100, Helmut Grohne wrote:
> Therefore my plan is:
> 
>  * Add lighttpd-mod-* Provides.
>  * Add lighttpd-modules-mysql.
>  * Add transitional dummy packages lighttpd-mod-authn-mysql
>lighttpd-mod-mysql-vhost.
>  * Add lighttpd-modules-ldap.
>  * Add transitional dummy package lighttpd-mod-autn-ldap.
>  * Add real packages lighttpd-mod-vhostdb-dbi,
>lighttpd-mod-vhostdb-pgsql, lighttpd-mod-authn-pam,
>lighttpd-mod-authn-sasl.
>  * lighttpd Recommends all modules that it formerly included and puts up
>a NEWS.Debian explaining the split.

I've implemented (but not uploaded this). I'm attaching two patches
based on your patches. They build and mostly pass lintian, but I didn't
test much else (piuparts, autopkgtest, actually running, etc.) yet.
Reviews appreciated. I intend to upload during the weekend.

Helmut
>From e53c24c891132cf9bb82db8b2a6df16c2657494f Mon Sep 17 00:00:00 2001
From: Helmut Grohne 
Date: Thu, 3 Jan 2019 13:24:02 +0100
Subject: [PATCH 1/2] split mysql-modules-{mysql,ldap}

Add provides for all lighttpd-mod-* and start relocating modules. Group
mysql and ldap modules together to remove the libmariadb and libldap
dependencies from the main lighttpd package.
---
 debian/changelog|  9 
 debian/control  | 83 +
 debian/lighttpd-mod-authn-ldap.install  |  1 -
 debian/lighttpd-mod-authn-mysql.install |  1 -
 debian/lighttpd-mod-mysql-vhost.install |  1 -
 debian/lighttpd-modules-ldap.install|  2 +
 debian/lighttpd-modules-mysql.install   |  3 ++
 debian/lighttpd.install |  2 -
 debian/rules| 13 ++
 9 files changed, 101 insertions(+), 14 deletions(-)
 delete mode 100644 debian/lighttpd-mod-authn-ldap.install
 delete mode 100644 debian/lighttpd-mod-authn-mysql.install
 delete mode 100644 debian/lighttpd-mod-mysql-vhost.install
 create mode 100644 debian/lighttpd-modules-ldap.install
 create mode 100644 debian/lighttpd-modules-mysql.install

diff --git a/debian/changelog b/debian/changelog
index 37ca06b..c369b5b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+lighttpd (1.4.52-2+exp1) UNRELEASED; urgency=medium
+
+  * QA Upload.
+  * Add lighttpd-mod-* Provides.
+  * Move mysql modules to new binary package lighttpd-modules-mysql.
+  * Move ldap modules to new binary package lighttpd-modules-ldap.
+
+ -- Helmut Grohne   Thu, 03 Jan 2019 12:14:06 +0100
+
 lighttpd (1.4.52-2) unstable; urgency=medium
 
   * QA Upload.
diff --git a/debian/control b/debian/control
index 735384c..203e2a9 100644
--- a/debian/control
+++ b/debian/control
@@ -36,13 +36,16 @@ Package: lighttpd
 Architecture: any
 Provides:
  httpd,
- httpd-cgi
+ httpd-cgi,
+ ${lighttpd:ModuleProvides},
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
  mime-support,
  lsb-base (>= 3.0-6),
 Recommends:
+ lighttpd-modules-ldap,
+ lighttpd-modules-mysql,
  spawn-fcgi,
  perl:any,
 Suggests:
@@ -78,17 +81,73 @@ Description: documentation for lighttpd
  .
  This package contains documentation for lighttpd.
 
-Package: lighttpd-mod-mysql-vhost
+Package: lighttpd-modules-ldap
+Architecture: any
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+ lighttpd (= ${binary:Version}),
+Breaks:
+ lighttpd (<< 1.4.52-2+exp1),
+ lighttpd-mod-authn-ldap (<< 1.4.52-2+exp1),
+Replaces:
+ lighttpd (<< 1.4.52-2+exp1),
+ lighttpd-mod-authn-ldap (<< 1.4.52-2+exp1),
+Provides:
+ ${lighttpd:ModuleProvides},
+Description: LDAP-based modules for lighttpd
+ This package contains the following modules:
+  * mod_authn_ldap: With this module, it is possible to perform
+authentication against an LDAP server.
+  * mod_vhostdb_ldap: Database backend module for using LDAP as
+a source for virtual host configuration using mod_vhostdb.
+ .
+ Do not depend on this package. Depend on the provided lighttpd-mod-*
+ packages instead.
+
+Package: lighttpd-modules-mysql
 Architecture: any
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
  lighttpd (= ${binary:Version}),
-Description: MySQL-based virtual host configuration for lighttpd
+Breaks:
+ lighttpd (<< 1.4.52-2+exp1),
+ lighttpd-mod-mysql-vhost (<< 1.4.52-2+exp1),
+ lighttpd-mod-autn-mysql (<< 1.4.52-2+exp1),
+Replaces:
+ lighttpd (<< 1.4.52-2+exp1),
+ lighttpd-mod-mysql-vhost (<< 1.4.52-2+exp1),
+ lighttpd-mod-autn-mysql (<< 1.4.52-2+exp1),
+Provides:
+ ${lighttpd:ModuleProvides},
+Description: MySQL-based modules for lighttpd
+ This package contains the following modules:
+  * mod_autn_mysql: With this module, it is possible to perform
+authentication using a MySQL table.
+  * mod_mysql_vhost: With this module, it is possible to write the
+configuration for virtual hosts into a MySQL table instead of
+including it in the lighttpd configuration file. Deprecated.
+  * mod_vhostdb_mysql: Database backend module for using MySQL as
+a source for virtual host configuration using 

Bug#918107: Random boot failure using VMware Paravirtual Adapter

[Thomas Kotzian]

Package: linux-image-4.19.0-1-amd64
Version: 4.19.12-1

Random boot failures on VMware when VM uses the Paravirtual Adapter. I drop 
into a busybox shell after the first line from the kernel. No disk found. 
Normally the 2nd line mentions the disk - this line doesn’t appear on failing 
boots - no disk is accessible. Rebooting sometimes works.

Kernel 4.18.0-3-amd64 work all the time. 4.19.3-1 is also broken.

LSI SCSI controller works fine on every reboot.

I have looked through the changelog of 4.19.12. it mentions code re-arrangement 
in pv_scsi driver - maybe something broke there?

Bug#918108: RM: gnome-panel [s390x] -- ROM; ANAIS

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-CC: gnome-pa...@packages.debian.org

gnome-panel no longer builds on s390x because it build-depends on gdm3
which build-depends on gjs which build-depends on mozjs60 which fails
too many build tests. See https://bugs.debian.org/906016

Therefore, please remove gnome-panel's and sensors-applet's binaries on s390x.

This should allow gnome-panel 3.30.0-2 to migrate to Testing.

dak output

# Broken Depends:
gnome-flashback: gnome-session-flashback
sensors-applet: sensors-applet

# Broken Build-Depends:
gnome-applets: libpanel-applet-dev (>= 3.24.1)
sensors-applet: libpanel-applet-dev (>= 3.0.0)
workrave: libpanel-applet-dev

dak interpretation
=
gnome-session-flashback is arch:all so there's nothing to be done there.
workrave no longer Build-Depends on libpanel-applet-dev on s390x.
gnome-applets binaries have already been removed on s390x.
sensors-applet should be removed on s390x.

Thanks,
Jeremy Bicha

Bug#918109: ITP: antlr4-cpp-runtime -- ANTLR Parser Generator (C++ runtime support)

[Andrius Merkys]

Package: wnpp
Severity: wishlist
Owner: Andrius Merkys 
Control: block 914434 by -1

* Package name: antlr4-cpp-runtime
  Version : 4.7.2
  Upstream Author : Terence Parr
* URL : http://www.antlr4.org
* License : BSD-3-clause
  Programming Lang: Java
  Description : ANTLR Parser Generator (C++ runtime support)

ANTLR (ANother Tool for Language Recognition) is a powerful parser
generator for reading, processing, executing, or translating structured
text or binary files. It's widely used to build languages, tools, and
frameworks. From a grammar, ANTLR generates a parser that can build and
walk parse trees.

This package contains C++ libraries and development files. To be
maintained by the Java Team.

Best,
Andrius Merkys

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

Bug#917995: debian-policy: drop section 1.6 Translations

[Sean Whitton]

Hello,

On Wed 02 Jan 2019 at 09:38am -0800, Jonathan Nieder wrote:

> Section 1.6 of policy is interesting to me for other reasons.  Its
> function is to make Debian policy usable as a normative document.

Indeed.

> That leads me in a few directions:
>
>  1. There is no reason in principle that policy in another language
> could not serve just as well in that capacity, as long as it is of
> sufficient quality and well reviewed.  We could change this
> section to list criteria for a version of policy to have normative
> status --- e.g.
>
>  a. in a language understood by at least one of the policy editors
>  b. unilateral changes to that version are only made by policy
> editors or their explicit delegates
>  c. non-unilateral changes following the usual process of review
> on the policy list to gather seconds from a Debian Developer
>
>  2. There is something very idealistic about treating policy as a
> standards document.  In practice, even in English, it has not been
> air-tight enough for that, and has worked best as a part of a
> system that includes the ability to get help interpreting it from
> the policy list.

Very interesting.  I had never thought of treating Policy as a standards
document as something involving a fair dose of optimism, but I think
you're right that it does.

It seems that some parts of Policy are much closer to being parts of a
standards document than other parts are.

> In that context, would removing section 1.6 be so bad?  We could
> add a note to section 1.1 to help people parsing standardeses to
> understand the best way to resolve confusing or ambiguous
> passages: instead of trying to read deeply into confusing
> language, file a bug and work with release managers and/or policy
> editors to get it clarified.
>
>  3. I would be against removing section 1.6 without a change along the
> lines described in (1) or (2) above happening at the same time.

Perhaps you could share the wording you have in mind for such a note.

I'm still inclined to prioritise unblocking people, by giving them a way
of resolving disputes between versions of the document without asking on
d-policy, but let's see.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#918110: privoxy: conffiles not removed

[Paul Wise]

Package: privoxy
Version: 3.0.28-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=privoxy ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep 
obsolete
privoxy: obsolete-conffile /etc/privoxy/templates/show-version
 /etc/privoxy/templates/show-version 6473201b954d5a4a0ff756a1f6a85224 obsolete

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages privoxy depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.28-2
ii  libpcre3   2:8.39-11
ii  logrotate  3.14.0-4
ii  lsb-base   10.2018112800
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages privoxy recommends:
pn  doc-base  

privoxy suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#886560: CharLS 2.0.0

[Mathieu Malaterre]

On Fri, Dec 21, 2018 at 11:39 AM Andreas Tille  wrote:
>
> Control: tags -1 help
>
> I've commited charls 2.0 to Git[1].  Unfortunately it does not build
> out of the box:

Fixed:

3f15f491eef6 Update to match SOVERSION
d10b1dafe79c Use default c++ standard used by gcc when compiling
4766801f4044 Refresh patch for v2.0.0

There is still something wrong. I see -O0 in compilation log, and
hardening does not pass -D stuff on the command line...

> It would be nice if you could help getting the package you
> injected into Debian upgraded.  Thank you
>
>   Andreas.
>
> [1] https://salsa.debian.org/med-team/charls
>
> --
> http://fam-tille.de

Bug#918096: linux-image-4.19.0-1-amd64: disk and keyboard do not work - unusable even in recovery mode

[Vincent Lefevre]

Note: I have the same issue with the 4.9 kernel from stable, which
I have just installed, so that initrd.img-4.9.0-8-amd64 is recent
(this might matter).

See also bug 917607 (I get the same error), reported against udev.

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

Bug#918111: ITP: luakit -- A webkit2-based web browser extensible by Lua

[Markus Demleitner]

Package: wnpp
Severity: wishlist
Owner: Markus Demleitner 

* Package name: luakit
  Version : 2017-08-10
  Upstream Author : Aidan Holm https://luakit.github.io
* License : GPLv3
  Programming Lang: C, Lua
  Description : A webkit2-based web browser extensible by Lua

Luakit has been part of Debian up to and including stretch.  It was removed
from sid recently because the version in Debian depended on Webkit1.
Upstream, however, had ported the software to Webkit2 by then.
I would like to bring back the modernised luakit to Debian.

The description of the old package by and large still pertains (although
I give you it would be spiced up a bit): Luakit is a highly configurable
browser framework based on WebKit2GTK.  It is very fast and extensible
by Lua.  It is primarily targeted at power users, developers and any
people with too much time on their hands who want to have fine-grained
control over their web browser's behaviour and interface.

Bug#918113: linux-image-4.19.0-1-amd64: Fails to initalize DisplayPort displays with rx560

[Mark Brown]

Package: src:linux
Version: 4.19.13-1
Severity: important

As covered in the kernel log below the amdgpu driver fails to initialize
a multi-monitor DisplayPort chain connected to a and AMD RX560
(Polaris11), rendering the system unusable in desktop configurations.
There is an oops earlier in the kernel output:

Jan  3 12:44:01 debutante kernel: [7.630953] WARNING: CPU: 2 PID: 69 at 
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2293 
core_link_enable_stream+0x4b3/0xb90 [am
dgpu]
Jan  3 12:44:01 debutante kernel: [7.630954] Modules linked in: fuse 
binfmt_misc nls_ascii nls_cp437 vfat fat intel_rapl x86_pkg_temp_thermal 
intel_powerclamp coretemp amdk
fd kvm_intel kvm irqbypass crct10dif_pclmul amdgpu crc32_pclmul 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 chash 
gpu_sched ghash_clmulni_intel snd_hda_
intel ttm snd_hda_codec intel_cstate cp210x mei_me snd_hda_core sr_mod cdrom 
drm_kms_helper snd_hwdep iTCO_wdt efi_pstore intel_uncore snd_pcm usbserial 
intel_rapl_perf cdc_acm
 joydev efivars sg evdev pcspkr mei parport_serial iTCO_vendor_support 
snd_timer drm snd i2c_algo_bit soundcore video pcc_cpufreq button ipmi_devintf 
ipmi_msghandler loop nfsd 
parport_pc auth_rpcgss ppdev nfs_acl lp lockd parport grace sunrpc efivarfs 
ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto btrfs
Jan  3 12:44:01 debutante kernel: [7.630978]  zstd_decompress zstd_compress 
xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor 
async_tx xor usb_storage
 raid6_pq libcrc32c raid1 raid0 multipath linear md_mod hid_generic usbhid hid 
sd_mod crc32c_intel ahci libahci xhci_pci libata aesni_intel xhci_hcd ehci_pci 
realtek ehci_hcd a
es_x86_64 i2c_i801 scsi_mod crypto_simd r8169 cryptd usbcore glue_helper libphy 
natsemi lpc_ich usb_common thermal fan
Jan  3 12:44:01 debutante kernel: [7.630993] CPU: 2 PID: 69 Comm: 
kworker/2:1 Tainted: P   OE 4.19.0-1-amd64 #1 Debian 4.19.12-1
Jan  3 12:44:01 debutante kernel: [7.630994] Hardware name: Gigabyte 
Technology Co., Ltd. H87-HD3/H87-HD3, BIOS F3 05/09/2013
Jan  3 12:44:01 debutante kernel: [7.631002] Workqueue: events_long 
drm_dp_mst_link_probe_work [drm_kms_helper]
Jan  3 12:44:01 debutante kernel: [7.631043] RIP: 
0010:core_link_enable_stream+0x4b3/0xb90 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631044] Code: ff 48 89 ef be 01 00 00 
00 e8 b9 86 00 00 4c 89 ef 48 89 de e8 fe df ff ff bf c8 00 00 00 89 c5 e8 62 
67 26 fb e9 ea fd ff ff <0f> 0b e9 de fe ff ff 48 8b 82 50 02 00 00 48 8b 40 50 
48 8b 40 30
Jan  3 12:44:01 debutante kernel: [7.631045] RSP: 0018:a57081dd7668 
EFLAGS: 00010246
Jan  3 12:44:01 debutante kernel: [7.631046] RAX:  RBX: 
901ca62a4188 RCX: 
Jan  3 12:44:01 debutante kernel: [7.631046] RDX: 0005 RSI: 
c2349588 RDI: 0004
Jan  3 12:44:01 debutante kernel: [7.631047] RBP: 901cb7dede00 R08: 
0005 R09: 
Jan  3 12:44:01 debutante kernel: [7.631047] R10:  R11: 
a57081dd75c0 R12: 901ca89ed000
Jan  3 12:44:01 debutante kernel: [7.631048] R13: 901cb7dedf90 R14: 
901cb77f0400 R15: 0006
Jan  3 12:44:01 debutante kernel: [7.631048] FS:  () 
GS:901cbe08() knlGS:
Jan  3 12:44:01 debutante kernel: [7.631049] CS:  0010 DS:  ES:  
CR0: 80050033
Jan  3 12:44:01 debutante kernel: [7.631050] CR2: 7f586f069e20 CR3: 
4f20a002 CR4: 001606e0
Jan  3 12:44:01 debutante kernel: [7.631050] Call Trace:
Jan  3 12:44:01 debutante kernel: [7.631095]  ? 
dce110_stream_encoder_update_dp_info_packets+0x14c/0x200 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631133]  
dce110_apply_ctx_to_hw+0x63f/0x650 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631171]  dc_commit_state+0x2c6/0x520 
[amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631207]  ? 
set_freesync_on_streams.part.6+0x4d/0x250 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631241]  ? 
mod_freesync_set_user_enable+0x11f/0x150 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631277]  
amdgpu_dm_atomic_commit_tail+0x388/0xdb0 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631280]  ? _cond_resched+0x15/0x30
Jan  3 12:44:01 debutante kernel: [7.631282]  ? 
wait_for_completion_timeout+0x3b/0x1a0
Jan  3 12:44:01 debutante kernel: [7.631318]  ? 
amdgpu_dm_atomic_commit_tail+0xdb0/0xdb0 [amdgpu]
Jan  3 12:44:01 debutante kernel: [7.631325]  commit_tail+0x3d/0x70 
[drm_kms_helper]
Jan  3 12:44:01 debutante kernel: [7.631329]  
drm_atomic_helper_commit+0xb4/0x120 [drm_kms_helper]
Jan  3 12:44:01 debutante kernel: [7.631333]  
restore_fbdev_mode_atomic+0x170/0x1d0 [drm_kms_helper]
Jan  3 12:44:01 debutante kernel: [7.631337]  
drm_fb_helper_restore_fbdev_mode_unlocked+0x45/0x90 [drm_kms_helper]
Jan  3 12:44:01 debutante kernel: 

Bug#918112: openfoam should not massively pollute /usr/{bin,lib} namespaces

[littlejohn75]

Package: openfoam
Version: 4.1+dfsg1-2pre~6.gbpa01bff
Severity: normal

Dear Maintainer,

The libopenfoam package drops 108 libraries (without sonames) in /usr/lib and 
the openfoam package installs 226 programs in /usr/bin.
Moreover following libraries are installed
/usr/lib/openmpi-system/libPstream.so
/usr/lib/openmpi-system/libptscotchDecomp.so
/usr/lib/dummy/libMGridGen.so
/usr/lib/dummy/libPstream.so
/usr/lib/dummy/libmetisDecomp.so
/usr/lib/dummy/libptscotchDecomp.so

In the repository https://salsa.debian.org/littlejohn75-guest/openfoam
you will find patches that remove those extraneous libraries. See bug number
 917985: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917985.

Among the numerous binaries installed by the packages, there are a number of
generic names which may conflict with names from other packages. (see annex )
For example, if you install openfoam (and libopenfoam dependancy ) you cannot 
easily develop a scientific sofware with  'ODE' 'forces', 'engine' or 
'lagrangian'
libraries. And no other package can provide a 'noise', 'objToVTK', 'pdfPlot' or
'postProcess' command.
In the aforementioned repository, libaries are installed in 
/usr/lib/OpenFOAM-4.1/lib
and programs in /usr/lib/OpenFOAM-4.1/bin  so that more than a version of 
openfoam
are coinstallable.  Moreover, this allows to install the software on only one
system in a cluster of machines, and to automount the /usr/lib/OpenFOAM-4.1
directory on the other systems of the cluster.
WARNING: mainterner scripts are not updated in the littlejohn75-guest repo
as I do not have experience with this. Upgrade of an installed package can be
very tricky.

The Debian openfoam package as provided is useless for administrators of high
performance compute systems with more than a few machines in the cluster.
And with only a few systems, the impossibility to install more than a version
of the software is a major hindrance.

For all these reasons, please install in /usr/lib/PREFIX-VERS/{bin,lib}
Stop the /usr/{bin,lib} namespace pollution by specialized leaf package !

Annex  non exhaustive list of binaries which may conflict with other packages
_
/usr/bin/attachMesh
/usr/bin/changeDictionary
/usr/bin/checkMesh
/usr/bin/createPatch
/usr/bin/extrude2DMesh
/usr/bin/extrudeMesh
/usr/bin/mirrorMesh
/usr/bin/modifyMesh
/usr/bin/moveMesh
/usr/bin/noise
/usr/bin/objToVTK
/usr/bin/patchSummary
/usr/bin/pdfPlot
/usr/bin/postChannel
/usr/bin/postProcess
/usr/bin/refineMesh
/usr/bin/refinementLevel
/usr/bin/removeFaces
/usr/bin/rotateMesh
/usr/bin/selectCells
/usr/bin/setFields
/usr/bin/setsToZones
/usr/bin/splitCells
/usr/bin/splitMesh
/usr/bin/streamFunction
/usr/bin/subsetMesh
/usr/bin/surfaceAdd
/usr/bin/surfaceCheck
/usr/bin/surfaceClean
/usr/bin/surfaceFind
/usr/bin/surfaceInertia
/usr/bin/surfaceOrient
/usr/bin/surfaceSubset
/usr/bin/temporalInterpolate
/usr/bin/topoSet
/usr/bin/wdot

/usr/lib/libODE.so
/usr/lib/libconversion.so
/usr/lib/libdecompose.so
/usr/lib/libengine.so
/usr/lib/libextrude2DMesh.so
/usr/lib/libextrudeModel.so
/usr/lib/libfileFormats.so
/usr/lib/libfiniteVolume.so
/usr/lib/libforces.so
/usr/lib/liblagrangian.so
/usr/lib/libliquidProperties.so
/usr/lib/libmeshTools.so
/usr/lib/libmolecule.so
/usr/lib/libpotential.so
/usr/lib/libreconstruct.so
/usr/lib/libregionModels.so
/usr/lib/libsampling.so
/usr/lib/libsolidProperties.so
/usr/lib/libsurfMesh.so
/usr/lib/libturbulenceModels.so


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 openfoam depends on:
ii  libc62.24-11+deb9u3
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libopenfoam  4.1+dfsg1-2pre~6.gbpa01bff
ii  libreadline7 7.0-3
ii  libstdc++6   6.3.0-18+deb9u1
ii  mpi-default-bin  1.8

Versions of packages openfoam recommends:
pn  openfoam-examples  

openfoam suggests no packages.

-- no debconf information

Happy new year to the Debian Science Team !

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع  تحياتي الخالصة  
---
F. Petitjean
Ingénieur civil du Génie Maritime.
littlejoh...@laposte.net

« Il semble que la perfection soit atteinte, non quand il n'y a
  plus rien à ajouter mais quand il n'y a plus rien à retrancher »
  Saint-Exupéry -Terre des hommes , chapitre III , L'avion.

Bug#917854: RFS: pygithub/1.43.3-1

[eamanu15]

Hi Dmitry!

El jue., 3 de ene. de 2019 a la(s) 01:13, Dmitry Bogatov (kact...@debian.org)
escribió:

>
> As other folks already mentioned, you do not use CC: you already use
> X-Debbugs-CC. In this particular case, email with bug number got
> filtered-out as duplicate in my setup.
>
> Ok. The next time I will use just X-Debbugs-CC


> [2018-12-31 00:16] eamanu15 
> > I am looking for a sponsor for my package "pygithub"
> >
> > * Package name: pygithub
> > Version : 1.43.3-1
> > Upstream Author : Adam Dangoor 
> >   Vincent Jacques 
> >   Jeremy Phelps 
> > * URL : https://pypi.python.org/pypi/PyGithub
> > * License : LGPL-3+
> >   Section : python
> >
> > It builds those binary packages:
> >
> > python-github - Access to full Github API v3 from Python2
> > python3-github - Access the full Github API v3 from Python3
>
> Looks fine, but I do not understand following line in `debian/rules':
>
> rm -rfv debian/python3-github/usr/lib/python3.*
>

> What is removed and why same statement it is not needed for python2
> version?  Comment in `debian/rules' would be nice.
>

Really I don't remember and I don't sit down in front of own system right
now.

>
> And some very minor suggestions:
>
>  * Standards-Version slightly outdated
>  * debhelper-compat style reduces redundancy
>  * Probably F-variables could be used to avoid repetition in
>binary package descriptions? (See dpkg-substvars(5))
>

Thanks for your suggestions I will work in it.

>
> I do not know habits of Python Modules Team, but would not it be more
> apporiate for this packages to be sponsored by DD from team? I can check
> basic things, but I do not know whole picture, like transitions or
> reverse dependencies.
>

Yes, I'll keep looking.

>
> PS. I am glad to see that pygithub finally moved under aegis of
> Python Modules Team.
>

Regards!


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#917789: Wrong tarball id (pristine-tar) when import-orig with --components

[Mo Zhou]

On Thu, Jan 03, 2019 at 10:45:12AM +0100, Guido Günther wrote:
> What's your checkout command on the other machine? Did you specify the
> components. Please don't omit the commands you're using for import and
> export

import:

gbp import-orig --pristine-tar ../opencv_3.4.5+dfsg.orig.tar.xz --component 
contrib

export (where the tarball is imported):

~/D/o/opencv ❯❯❯ git st
HEAD detached at 922bf8f32
nothing to commit, working tree clean
~/D/o/opencv ❯❯❯ pristine-tar checkout opencv_3.4.5+dfsg.orig-contrib.tar.xz
pristine-tar: successfully generated opencv_3.4.5+dfsg.orig-contrib.tar.xz
~/D/o/opencv ❯❯❯ pristine-tar checkout opencv_3.4.5+dfsg.orig.tar.xz
pristine-tar: successfully generated opencv_3.4.5+dfsg.orig.tar.xz

export (remote):

It's quite strange that I cannot reproduce this problem anymore
on the commit in question.

@Mattia: Are you able to reproduce this problem?

I can checkout the tarball from both
  git: a0bd84b30b388b9811bc300e9a62801cf89c8966
  git: 922bf8f325761abecfcd8171ab490fba4e821c58
which yield the same tarball
  c41c9e5892e3d1fa15c0a8016cd5e84c  1.xz
  c41c9e5892e3d1fa15c0a8016cd5e84c  2.xz
even if they points to different id:
  --- a/opencv_3.4.5+dfsg.orig.tar.xz.id
  +++ b/opencv_3.4.5+dfsg.orig.tar.xz.id
  @@ -1 +1 @@
  -a67d0acc9952eb94c9dc0f50eb1f73777695418e
  +a18a03170473e1773e1f571e561441bc83a3861e

Bug#918114: linux-image-armmp: please add CONFIG_SENSORS_LM75=m

[Reco]

Package: linux-image-armmp
Version: 4.18+100~bpo9+1
Severity: wishlist

Dear Maintainer,

Please enable building lm75.ko as a module, there's a hardware (Helios4 NAS), 
which runs Debian kernel and userland without a hitch, but lm75 is required for 
monitoring CPU temperature.

Sincerely yours, Reco


-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.18.0-0.bpo.3-armmp (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 linux-image-armmp depends on:
ii  linux-image-4.18.0-0.bpo.3-armmp  4.18.20-2~bpo9+1

linux-image-armmp recommends no packages.

linux-image-armmp suggests no packages.

-- no debconf information

Bug#918046: RFS: ebtables/2.0.10.4+snapshot20181205-1 - Ethernet bridge frame table administration

[Arturo Borrero Gonzalez]

On Wed, 02 Jan 2019 20:06:47 +0100 Alberto Molina Coballes
 wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> I am looking for a sponsor for my package "ebtables"
> 

Done! :-)

Bug#918116: intel-gpu-tools: Unable to read its own config files due to use-after-free

[Matthew Gabeler-Lee]

Package: intel-gpu-tools
Version: 1.22-1
Severity: normal

With a recent libc update, the register access tools all fail like this:

Error: /usr/share/intel-gpu-tools/registers/common_display.txt:1: 
('CPU_VGACNTRL', '0x00041000', '')
Error: /usr/share/intel-gpu-tools/registers/haswell:1: common_display.txt
Warning: reading '/usr/share/intel-gpu-tools/registers/haswell' failed. Using 
builtin register spec.

Some gdb work tracked this down to a use-after free in the parsing code
(tools/intel_reg_spec.c)

} else if (i == 2) {
reg->addr = strtoul(p, &e, 16);
free(p);
if (*e)
ret = -1;

It seems that it "got away" with this with older libc versions, but
something changed between the libc in stretch and that in buster and now
this use-after-free reliably fails every time for me.

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

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

Versions of packages intel-gpu-tools depends on:
ii  libc6  2.28-2
ii  libcairo2  1.16.0-2
ii  libdrm-intel1  2.4.74-1
ii  libdrm22.4.95-1
ii  libkmod2   23-2
ii  libpciaccess0  0.13.4-1+b2
ii  libprocps6 2:3.3.12-3+deb9u1
ii  libudev1   232-25+deb9u6
ii  libunwind8 1.1-4.1
ii  libx11-6   2:1.6.4-3+deb9u1
ii  libxext6   2:1.3.3-1+b2
ii  libxrandr2 2:1.5.1-1
ii  libxv1 2:1.0.11-1
ii  zlib1g 1:1.2.11.dfsg-1

intel-gpu-tools recommends no packages.

intel-gpu-tools suggests no packages.

-- no debconf information

Bug#918117: RM: python-htseq-doc/0.6.1p1-4

[Michael R. Crusoe]

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

Hello,

Please remove python-htseq-doc from the testing distribution. It is no
longer build by the source package and its presence is blocking a migration
from unstable.

Thanks!

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

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

Bug#918118: tracker-extract killed by seccomp sandbox on i386

[Roderich Schupp]

Package: tracker-extract
Version: 2.1.5-4
Severity: important
Tags: patch

On my i386 based NAS tracker-extract repeatedly is killed via SIGSYS by the
seccomp sandbox.
Excerpt from strace:

17167 execve("/usr/lib/tracker/tracker-extract", ["/usr/lib/tracker/tracker-
extract"], ["HOME=/home/roderich", "LANG=en_US.UTF-8", "LANGUAGE=en_US:en",
"LOGNAME=roderich", "PATH=/usr/local/sbin:/usr/local/"..., "SHELL=/bin/bash",
"USER=roderich", "XDG_RUNTIME_DIR=/run/user/2000",
"DBUS_SESSION_BUS_ADDRESS=unix:pa"..., "MANAGERPID=312",
"INVOCATION_ID=22e8f9cf5d124c59bb"..., "JOURNAL_STREAM=9:104103"]) = 0
...
17167 clone(child_stack=0xab1ad324,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xab1adba8, tls={entry_number=6, base_addr=0xab1adb40,
limit=0x0f, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1,
seg_not_present=0, useable=1}0xbf9039bc, child_tidptr=0xab1adba8) = 17188
17167 poll([{fd=4, events=POLLIN}], 1, -1 
17188 set_robust_list(0xab1adbb0, 12)   = 0
17188 prctl(PR_SET_NAME, "single")  = 0
17188 mprotect(0xb3321000, 4096, PROT_READ|PROT_WRITE) = 0
17188 mprotect(0xb3322000, 4096, PROT_READ|PROT_WRITE) = 0
17188 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0
17188 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument)
17188 seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=135,
filter=[BPF_STMT(BPF_LD|BPF_W|BPF_ABS, 0x4), BPF_JUMP(BPF_JMP|BPF_K|BPF_JEQ,
0x4003, 0, 0x84), BPF_STMT(BPF_LD|BPF_W|BPF_ABS, 0),...
17188 lstat64("/home/roderich/Music/Jeff Beck with Terry Bozzio and Tony
Hymas/Jeff Beck's Guitar Shop/album.jpg", {st_dev=makedev(9, 1),
st_ino=159253366, st_mode=S_IFREG|0644, st_nlink=1, st_uid=2000, st_gid=2000,
st_blksize=4096, st_blocks=112, st_size=56447, st_atime=1460929067 /*
2016-04-17T23:37:47.747261334+0200 */, st_atime_nsec=747261334,
st_mtime=1460501084 /* 2016-04-13T00:44:44.971829499+0200 */,
st_mtime_nsec=971829499, st_ctime=1460929067 /*
2016-04-17T23:37:47.807259666+0200 */, st_ctime_nsec=807259666}) = 0
17188 openat(AT_FDCWD, "/home/roderich/Music/Jeff Beck with Terry Bozzio and
Tony Hymas/Jeff Beck's Guitar Shop/album.jpg", O_RDONLY|O_LARGEFILE|O_NOATIME)
= 14
17188 fcntl64(14, F_GETFL)  = 0x48000 (flags
O_RDONLY|O_LARGEFILE|O_NOATIME)
17188 futex(0xb7cb69c8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
17188 futex(0xb7cb69c8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
17188 fstat64(14, {st_dev=makedev(9, 1), st_ino=159253366,
st_mode=S_IFREG|0644, st_nlink=1, st_uid=2000, st_gid=2000, st_blksize=4096,
st_blocks=112, st_size=56447, st_atime=1460929067 /*
2016-04-17T23:37:47.747261334+0200 */, st_atime_nsec=747261334,
st_mtime=1460501084 /* 2016-04-13T00:44:44.971829499+0200 */,
st_mtime_nsec=971829499, st_ctime=1460929067 /*
2016-04-17T23:37:47.807259666+0200 */, st_ctime_nsec=807259666}) = 0
17188 mprotect(0xb3323000, 4096, PROT_READ|PROT_WRITE) = 0
17188 read(14,
"\377\330\377\340\0\20JFIF\0\1\1\0\0\1\0\1\0\0\377\333\0C\0\5\3\4\4\4\3\5"...,
4096) = 4096
17188 mprotect(0xb3324000, 16384, PROT_READ|PROT_WRITE) = 0
17188 lstat64("/home/roderich/Music/Jeff Beck with Terry Bozzio and Tony
Hymas/Jeff Beck's Guitar Shop/album.jpg", {st_dev=makedev(9, 1),
st_ino=159253366, st_mode=S_IFREG|0644, st_nlink=1, st_uid=2000, st_gid=2000,
st_blksize=4096, st_blocks=112, st_size=56447, st_atime=1460929067 /*
2016-04-17T23:37:47.747261334+0200 */, st_atime_nsec=747261334,
st_mtime=1460501084 /* 2016-04-13T00:44:44.971829499+0200 */,
st_mtime_nsec=971829499, st_ctime=1460929067 /*
2016-04-17T23:37:47.807259666+0200 */, st_ctime_nsec=807259666}) = 0
17188 openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 17
17188 fstat64(17, {st_dev=makedev(9, 1), st_ino=74977878, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=2335,
st_atime=1546448825 /* 2019-01-02T18:07:05+0100 */, st_atime_nsec=0,
st_mtime=1546221724 /* 2018-12-31T03:02:04+0100 */, st_mtime_nsec=0,
st_ctime=1546448827 /* 2019-01-02T18:07:07.614374895+0100 */,
st_ctime_nsec=614374895}) = 0
17188 fstat64(17, {st_dev=makedev(9, 1), st_ino=74977878, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=2335,
st_atime=1546448825 /* 2019-01-02T18:07:05+0100 */, st_atime_nsec=0,
st_mtime=1546221724 /* 2018-12-31T03:02:04+0100 */, st_mtime_nsec=0,
st_ctime=1546448827 /* 2019-01-02T18:07:07.614374895+0100 */,
st_ctime_nsec=614374895}) = 0
17188 mprotect(0xb3328000, 4096, PROT_READ|PROT_WRITE) = 0
17188 read(17,
"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\t\0\0\0\0"..., 4096) = 2335
17188 _llseek(17, -1476, [859], SEEK_CUR) = 0
17188 read(17,
"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\t\0\0\0\0"..., 4096) = 1476
17188 close(17) = 0
17188 fadvise64_64(14, 0, 0, POSIX_FADV_DONTNEED) = 272
17188 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP,
si_call_addr=0xb7fbdd41, si_syscall=__NR_fadvise64_64, si_arch=AUDIT

Bug#909612: fakechroot: does not support renameat2

[Daniel Kahn Gillmor]

On Tue 2019-01-01 08:24:51 +0100, Johannes Schauer wrote:
> I uploaded a NMU to DELAYED/10. Debdiff attached. Please cancel this upload in
> case you don't like it. :)

thank you for taking care of this, Johannes!

  --dkg


signature.asc
Description: PGP signature

Bug#918119: bugwarrior: Python 3.7: configparser: TypeError: option values must be strings

[Marco Solieri]

Package: bugwarrior
Version: 1.5.1-2
Severity: grave
Tags: upstream patch
Justification: renders package unusable

As reported [1] upstream, the bug makes bugwarrior crash at the very beginning
with an error in 'configparser' used to parse the application configuration
file because of empty values. See also trace below.

A patch is already available [2] and included in version 1.6.0 released last
August.

~~

1. https://github.com/ralphbean/bugwarrior/issues/597
2. 
https://github.com/ralphbean/bugwarrior/pull/600/commits/da9221ea673b32fe3f9732b13c818604cf657230

-- Trace:
Traceback (most recent call last):
  File "/usr/bin/bugwarrior-pull", line 11, in 
load_entry_point('bugwarrior==1.5.1', 'console_scripts', 
'bugwarrior-pull')()
  File "/usr/lib/python3/dist-packages/click/core.py", line 759, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 714, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 951, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 552, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/bugwarrior/command.py", line 62, in pull
config = _try_load_config(main_section, interactive)
  File "/usr/lib/python3/dist-packages/bugwarrior/command.py", line 35, in 
_try_load_config
return load_config(main_section, interactive)
  File "/usr/lib/python3/dist-packages/bugwarrior/config.py", line 207, in 
load_config
config = BugwarriorConfigParser({'log.level': "INFO", 'log.file': None})
  File "/usr/lib/python3.7/configparser.py", line 638, in __init__
self._read_defaults(defaults)
  File "/usr/lib/python3.7/configparser.py", line 1216, in _read_defaults
self.read_dict({self.default_section: defaults})
  File "/usr/lib/python3.7/configparser.py", line 753, in read_dict
self.set(section, key, value)
  File "/usr/lib/python3.7/configparser.py", line 1197, in set
self._validate_value_types(option=option, value=value)
  File "/usr/lib/python3.7/configparser.py", line 1182, in _validate_value_types
raise TypeError("option values must be strings")
TypeError: option values must be string

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

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

Versions of packages bugwarrior depends on:
ii  libjs-sphinxdoc1.7.9-1
ii  python33.7.1-3
ii  python3-click  6.7+git20180829-1
ii  python3-dateutil   2.7.3-1
ii  python3-dogpile.cache  0.6.2-6
ii  python3-future 0.15.2-5
ii  python3-jinja2 2.10-1
ii  python3-lockfile   1:0.12.2-2
ii  python3-requests   2.20.0-2
ii  python3-six1.12.0-1
ii  python3-taskw  1.2.0-2
ii  python3-tz 2018.7-1

Versions of packages bugwarrior recommends:
ii  python3-keyring  17.1.1-1
ii  python3-phabricator  0.7.0-1

bugwarrior suggests no packages.

-- debconf-show failed

Bug#909612: fakechroot: does not support renameat2

[Johannes Schauer]

Hi dkg,

Quoting Daniel Kahn Gillmor (2019-01-03 15:01:24)
> On Tue 2019-01-01 08:24:51 +0100, Johannes Schauer wrote:
> > I uploaded a NMU to DELAYED/10. Debdiff attached. Please cancel this upload 
> > in
> > case you don't like it. :)
> 
> thank you for taking care of this, Johannes!

:)

Unfortunately, even after this upload gets ACCEPTED into unstable, we still
need #915559 in coreutils to be fixed before fakechroot is usable again.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#918120: ITP: bpftrace -- high-level tracing language for Linux eBPF

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: bpftrace
  Version : git
  Upstream Author : IO Visor Project
* URL : https://github.com/iovisor/bpftrace
* License : Apache 2
  Programming Lang: C++
  Description : high-level tracing language for Linux eBPF

BPFtrace is a high-level tracing language for Linux enhanced Berkeley
Packet Filter (eBPF) available in recent Linux kernels (4.x). BPFtrace
uses LLVM as a backend to compile scripts to BPF-bytecode and makes
use of BCC for interacting with the Linux BPF system, as well as
existing Linux tracing capabilities: kernel dynamic tracing (kprobes),
user-level dynamic tracing (uprobes), and tracepoints. The BPFtrace
language is inspired by awk and C, and predecessor tracers such as
DTrace and SystemTap.

The copyright assignment is currently not precise enough. Original
author is Previously, Alastair Robertson.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlwuIvwSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5wFsP+wQh9RbS9wCku2k+QcUyyVMimnSZJURp
l2wJoH3VVAL9AfAYeKB7FYbmapykuripk+XKPRLjGPAxdaNObIid69kTHaa7HyyO
HncqsJECxBRobcy+x8HV4jcaSHTeWqhpHncV3FWLGaF/wMEHfze2dWZPSwCafocB
kXDG5HnaV/1MvpWchOMzHT/wcxy5a7cTksqSgKxB+ssu3AdQNerB6RAxPhCGzVIP
C9DnFAVx8JDq5qsX27V/5pJScZmk6915fsmQPmaOqEKPQx8ZR3OUjZacwsWphZ2v
IKw2RKhr5P5pkj0IRrFvJpHyXqsFu/xW1AD7x2C2XkljhlkyXMMC1aN/rDtG0A7j
HToZeyxS8G9TPEraORmsVtt3+CCuE9hzi8/IDBdv07/TJWrOWhEgg9zuxEEb5YQ/
qq4CMDJlJU8Tv6uu3ojKTPsbHwqTCo1T4nZgQR3Hfq7KB2LkBqq8c04Fe9D7Vufy
O8ZB9w9wH3vsEF90Yz3qbJCYoemNinzhJJsvnWAd9JpYjA3R2y0h7OiF4EeY3kVC
09kPibZaQjPgiaep2x/jFXYb5gTFhL8JWUuvUP9FFo8dpMKD45tgKSTRBOpBa/qy
8uJ+wklHIZWBiHyg0NCIEsnTE1drO3IXEQnv47HfHAnPOTndLBkuil3SRFrQ1NJr
VfEzHG4G734Q
=IGQI
-END PGP SIGNATURE-

Bug#918121: libgazebo9-dev: gazebo.pc has broken link flags

[Emilio Pozuelo Monfort]

Package: libgazebo9-dev
Version: 9.4.1+dfsg-1
Severity: serious

Hi,

libgazebo9-dev 9.4.1+dfsg-1+b2 (rebuilt for the gdal transition, though this
breakage may or may not be related to gdal) ships a broken gazebo.pc:

Libs: -Wl,-rpath,${prefix}/lib/x86_64-linux-gnu/gazebo-9/plugins -L${libdir} 
-L${prefix}/lib/x86_64-linux-gnu/gazebo-9/plugins -lgazebo_transport 
-lgazebo_physics -lgazebo_sensors -lgazebo_rendering -lgazebo_gui 
-lgazebo_client -lgazebo_msgs -lgazebo_common -lgazebo 
-L/usr/lib/x86_64-linux-gnu -lboost_thread -l-lpthread -lboost_signals 
-lboost_system -lboost_filesystem -lboost_program_options -lboost_regex 
-lboost_iostreams -lboost_date_time -lboost_chrono -lboost_atomic 

Observe the flag -l-lpthread, which is bogus, and may be the result of two
different flags, with the first one containing an empty substitution.

This causes the autopkgtest failure found in:

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gazebo/1633147/log.gz
https://ci.debian.net/packages/g/gazebo/testing/amd64/

Which is triggered by gdal update only because that causes the gazebo/sid
package to be installed, which fails. However this may be the result of
another package, more investigation is needed.

Cheers,
Emilio

Bug#917060: [Pkg-rust-maintainers] Bug#917060: rust-nix: Please update to latest upstream version for sparc64 fixes

[Paride Legovini]

John Paul Adrian Glaubitz wrote on 22/12/2018:
> The latest upstream version of rust-nix, 0.12.0, contains build
> fixes for sparc64 [1]. Since rust-nix is required for several
> other Rust packages, it would be nice if the package could get
> updated and therefore fixed for sparc64.

Hello Adrian,

The packaging is ready, but nix 0.12 build-depends on rust-libc >=
0.2.44, so that package needs to be updated first.

Paride

Bug#918122: gsettings schema files contain translations, causes summary and description shown in Chinese

[Roderich Schupp]

Package: tracker-extract
Version: 2.1.5-4
Severity: minor

This shows the problem:

:; LANG=de_DE.UTF-8 gsettings describe org.freedesktop.Tracker.Miner.Files
ignored-files
要避免的檔案樣式列表
:; LANG=en_US.UTF-8 gsettings describe org.freedesktop.Tracker.Miner.Files
ignored-files
要避免的檔案樣式列表

The description is always in Chinese. dconf-editor is similarly affected.

The rason is that the gschema files for tracker-extract:

/usr/share/glib-2.0/schemas/org.freedesktop.Tracker.Miner.Files.gschema.xml
/usr/share/glib-2.0/schemas/org.freedesktop.Tracker.Extract.gschema.xml
/usr/share/glib-2.0/schemas/org.freedesktop.Tracker.Writeback.gschema.xml

contain translations, e.g.

  List of file patterns to avoid
  উপেক্ষা কৰিবলে ফাইল বিন্যাসমূহৰ
তালিকা
  Списък с шаблони за имена на файловете, които
да не бъдат индексирани
  Lista datotečnih uzoraka za
izbječi
...
  Danh sách các mẫu tập tin để tránh
xa
  要忽略的文件模式列表
  要避免的檔案樣式清單
  要避免的檔案樣式列表


Of all the 163 .gschema.xml files on my machine these are the only ones that
contain translations.
Apparently the glib functions to handle .gschmema.xml file don't expect
translations and look
only for tags like  (with no regard for xml:lang), hence the last
 "wins" -
which is typically the Chinese (TW) one.

The meson build of tracker-extract merges translations into the .gschema.xml
files, but
the obsolete autotools build - if I interprete the Makefiles correctly -
wouldn't have done this
(i.e. is calls intltool-merge with --no-translations).

Cheers, Roderich






-- 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.20.0 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tracker-extract depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libc62.28-4
ii  libcue2  2.2.1-2
ii  libexempi3   2.4.5-2
ii  libexif120.6.21-5
ii  libflac8 1.3.2-3
ii  libgexiv2-2  0.10.9-1
ii  libgif7  5.1.4-3
ii  libglib2.0-0 2.58.2-1
ii  libgsf-1-114 1.14.44-1
ii  libgstreamer-plugins-base1.0-0   1.14.4-1
ii  libgstreamer1.0-01.14.4-1
ii  libgxps2 0.3.0-4
ii  libicu63 63.1-5
ii  libiptcdata0 1.0.5-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libosinfo-1.0-0  1.2.0-1
ii  libpng16-16  1.6.36-2
ii  libpoppler-glib8 0.69.0-2
ii  libseccomp2  2.3.3-3
ii  libtagc0 1.11.1+dfsg.1-0.2+b2
ii  libtiff5 4.0.10-3
ii  libtotem-plparser18  3.26.1-2
ii  libtracker-miner-2.0-0   2.1.6-5
ii  libtracker-sparql-2.0-0  2.1.6-5
ii  libvorbisfile3   1.3.6-1
ii  libxml2  2.9.8+dfsg-1
ii  tracker  2.1.6-5

tracker-extract recommends no packages.

tracker-extract suggests no packages.

-- no debconf information

Bug#918117: RM: python-htseq-doc/0.6.1p1-4

[Adam D. Barratt]

Control: reassign -1 ftp.debian.org

On 2019-01-03 14:45, Michael R. Crusoe wrote:

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

Hello,

Please remove python-htseq-doc from the testing distribution. It is no
longer build by the source package and its presence is blocking a 
migration

from unstable.


Individual binary packages aren't removed from testing in that way. You 
need the package removing from unstable, which is ftp-master territory; 
re-assigning.


Regards,

Adam

Bug#918078: procmeter3: no longer has lm-sensors support

[Aurelien Jarno]

Dear maintainer,

On 2019-01-02 21:33, Jeremy Bicha wrote:
> Source: procmeter3
> Version: 3.6.1-1.1
> Severity: important
> X-Debbugs-CC: aure...@debian.org
> 
> procmeter3 no longer builds with lm-sensors support.
> 
> See modules/check-no-libsensors.sh
> 
> Build log excerpt
> ---
> libsensors does not appear to be installed - skipping compilation.
> 
> Full build logs
> ---
> https://buildd.debian.org/status/package.php?p=procmeter3

Unfortunately this has been broken by my recent binNMU fixing the build
with glibc 2.28 (bug #916054). Sorry about that. I have therefore just
done another NMU which adds support for libsensors5 by updating the
checks. You will find the corresponding debdiff attached.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru procmeter3-3.6/debian/changelog procmeter3-3.6/debian/changelog
--- procmeter3-3.6/debian/changelog 2018-12-26 00:22:40.0 +0100
+++ procmeter3-3.6/debian/changelog 2019-01-03 16:06:56.0 +0100
@@ -1,3 +1,14 @@
+procmeter3 (3.6-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/libsensors5.patch
+   + Update checks for libsensors5 Closes: #918078.
+  * debian/control
+   + Replace libsensors4-dev build-depends by libsensors-dev Closes:
+ #917446.
+
+ -- Aurelien Jarno   Thu, 03 Jan 2019 16:06:56 +0100
+
 procmeter3 (3.6-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru procmeter3-3.6/debian/control procmeter3-3.6/debian/control
--- procmeter3-3.6/debian/control   2014-03-22 16:38:22.0 +0100
+++ procmeter3-3.6/debian/control   2019-01-03 13:26:29.0 +0100
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Build-Depends: debhelper (>= 9), libgtk2.0-dev, libx11-dev, libxt-dev,
-  x11proto-core-dev, libsensors4-dev, libxaw7-dev, 
+  x11proto-core-dev, libsensors-dev, libxaw7-dev, 
   dpkg-dev (>= 1.17.0), libgtk-3-dev
 Maintainer: Wences Arana 
 Standards-Version: 3.9.5
diff -Nru procmeter3-3.6/debian/patches/libsensors5.patch 
procmeter3-3.6/debian/patches/libsensors5.patch
--- procmeter3-3.6/debian/patches/libsensors5.patch 1970-01-01 
01:00:00.0 +0100
+++ procmeter3-3.6/debian/patches/libsensors5.patch 2019-01-03 
13:27:45.0 +0100
@@ -0,0 +1,27 @@
+Add support for the libsensors5 API. In practice it's just a matter of
+updating the version checks.
+
+--- procmeter3-3.6.orig/modules/check-no-libsensors.sh
 procmeter3-3.6/modules/check-no-libsensors.sh
+@@ -5,7 +5,7 @@ CFLAGS=$2
+ 
+ cat < libsensors-test.c
+ #include 
+-#if (SENSORS_API_VERSION & 0xf00) != 0x400
++#if (SENSORS_API_VERSION & 0xf00) != 0x500
+ #error
+ #endif
+ EOF
+--- procmeter3-3.6.orig/modules/libsensors-fan.c
 procmeter3-3.6/modules/libsensors-fan.c
+@@ -27,8 +27,8 @@ const char *FILE__=__FILE__;
+ 
+ #include "procmeter.h"
+ 
+-#if !defined(SENSORS_API_VERSION) || (SENSORS_API_VERSION & 0xf00) != 0x400
+-#error "This module requires libsensors version 3"
++#if !defined(SENSORS_API_VERSION) || (SENSORS_API_VERSION & 0xf00) != 0x500
++#error "This module requires libsensors version 5"
+ #else
+ 
+ /* The interface information.  */
diff -Nru procmeter3-3.6/debian/patches/series 
procmeter3-3.6/debian/patches/series
--- procmeter3-3.6/debian/patches/series2018-12-21 22:51:43.0 
+0100
+++ procmeter3-3.6/debian/patches/series2019-01-03 13:28:08.0 
+0100
@@ -7,3 +7,4 @@
 dont-override-flags.patch
 libX11.patch
 loff_t.patch
+libsensors5.patch


signature.asc
Description: PGP signature

Bug#825501: CVE-2016-4434

[Cyril Brulebois]

Hi everyone,

Security team: thanks for your input.
PuppetDB/Clojure maintainers: draft plan in this mail, feedback welcome.

Moritz Mühlenhoff  (2018-12-31):
> On Mon, Dec 31, 2018 at 08:04:18AM +0100, Salvatore Bonaccorso wrote:
> > Furthermore if we only update to 1.13 there are likely some of the
> > currently  CVEs which will make tika affected, because
> > the issue was introduced post 1.5. One example of this is for
> > instance CVE-2016-6809, where the Matlab file parser was only
> > introduced in 1.6 and the issue fixed in 1.14. Or CVE-2018-17197
> > which affects 1.8 to 1.19.1. CVE-2018-1338, which was introduced in
> > 1.7. CVE-2018-1335, present from 1.7 to 1.17.
> > 
> > There might be others, so I think the new upstream version fixing all
> > known current CVE is actually needed.

There goes my vague idea of trying to handle a small(er) diff; of course
that makes a lot of sense…

> Agreed. Also 1.13 was released in May 2016, so by the time buster gets
> released it would be ~ 5 years old.

s/buster/bookworm/ I suppose but I see your point.


So, looking at current upstreams:
 - 4.4.x branch of puppetdb seems a bit inactive (since 2018-02), even
   if it has a few commits on top of the version currently sitting in
   unstable; it still documents a dependency on pantomime(-clojure)
   2.1.0, which itself documents a dependency on tika 1.5.
 - pantomime upstream is at 2.10.0, released early 2018; it documents
   a dependency on tika 1.19.1
 - tika upstream is at 1.20

Keeping in mind my knowledge of Clojure, Java, and their respective
ecosystems is rather limited, I'd like to share some initial hunches
anyway.

puppetdb seems to only reference pantomime once (outside top-level
project.clj), in src/puppetlabs/puppetdb/middleware.clj:
| […] :require […] [pantomime.media :as media]
^
| […]
| (defn verify-content-type
|   "Verification for the specified list of content-types."
|   [app content-types]
|   {:pre [(coll? content-types)
|  (every? string? content-types)]}
|   (fn [{:keys [headers] :as req}]
| (if (= (:request-method req) :post)
|   (let [content-type (headers "content-type")
| mediatype (if (nil? content-type) nil
|   (str (media/base-type content-type)))]
  ^^^
| (if (or (nil? mediatype) (some #{mediatype} content-types))
|   (app req)
|   (http/error-response (tru "content type {0} not supported" 
mediatype)
|http/status-unsupported-type)))
|   (app req

and hopefully that didn't change too much between pantomime 2.1.0 and
2.10.0 as that is likely the crux of pantomime?

With that in mind, but without having checked code changes in pantomime,
I hope it should be possible to bump the pantomime dependency from 2.1.0
to 2.10.0 on the puppetdb side (better catch up with upstream?).


On the pantomime side, it seems it should work fine with tika 1.19.1, as
documented in dependencies in the master branch (3 commits on top of the
v2.10.0 tag). That should help us consider tika 1.20, as possible
breaking changes should be manageable between those two versions?

Changes in dependencies in pantomime (project.clj) seem rather limited
here's an excerpt between the v2.1.0 and v2.10.0 tags (excluding changes
in :profiles and :aliases):
| -  :dependencies [[org.clojure/clojure "1.5.1"]
| - [org.apache.tika/tika-core "1.5"]]
| +  :dependencies [[org.clojure/clojure "1.9.0"]
| + [org.apache.tika/tika-parsers "1.17"]
| + [org.apache.commons/commons-compress "1.15"]]

This should be OK? We have clojure 1.9 in unstable, tika-parsers even
becomes 1.19.1 (as mentioned above, in the master branch), and we have
those versions for commons-compress:
| libcommons-compress-java | 1.13-1| stable | source, all
| libcommons-compress-java | 1.18-1| testing| source, all
| libcommons-compress-java | 1.18-1| unstable   | source, all


So maybe a way forward would be:
 - keep puppetdb at the current version (or maybe taking an upstream
   snapshot or suggesting a new upstream release with those few commits),
   and leave switching to 5.x or 6.x branches for later
 - bump pantomime-clojure to latest upstream (2.10)
 - bump tika to latest upstream (1.20)

I doubt I would be able to deal with tika 1.20 alone (see the issues I
had to deal with when trying my luck with 1.15 in my previous mail),
even if we were to try and trim it down to the bare set of features that
pantomime needs.


Thoughts about the plan? If that doesn't look too crazy, anyone with
some availability to help me get tika 1.20 in shape?


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


signature.asc
Description: PGP signature

Bug#917323: transition: gdal

[Emilio Pozuelo Monfort]

On 02/01/2019 21:10, Sebastiaan Couwenberg wrote:
> On 1/2/19 12:55 PM, Emilio Pozuelo Monfort wrote:
>> On 26/12/2018 08:46, Bas Couwenberg wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>>
>>> For the Debian GIS team I'd like to transition to GDAL 2.4.0.
>>>
>>> Like the previous transition to GDAL 2.3.0 (#898566), there is no SONAME
>>> bump, only the virtual ABI package changed to account for the C++ symbol
>>> changes.
>>>
>>> All reverse dependencies rebuilt successfully with GDAL 2.4.0 from
>>> experimental as summarized below, except mysql-workbench due to an
>>> unrelated issue (#914761).
>>>
>>> libgdal-grass doesn't need a binNMU as the 2.4.0 version will be
>>> uploaded to unstable instead. liblas likewise doesn't need a binNMU,
>>> the version is experimental will be moved to unstable instead.
>>
>> Go ahead.
> 
> Thanks.
> 
> gdal (2.4.0+dfsg-1), liblas (1.8.1-9) & libgdal-grass (2.4.0-1) have
> been uploaded to unstable, and gdal (2.4.0+dfsg-1) is now installed on
> all release architectures.

Looks like the rebuilt gazebo fails its autopkgtest due to a broken gazebo.pc,
see #918121. That causes migration delays for gdal. No idea where the broken
flag is coming from, I haven't investigated that deep.

Cheers,
Emilio

Bug#917247: udev: Many modules are no longer automatically loaded at boot

[gregor herrmann]

On Thu, 03 Jan 2019 00:53:08 +0100, gregor herrmann wrote:

> So it looks like the udev upgrade is reponsible for both the modules
> and the lvm troubles (although the latter still has to be confirmed
> in actual use over time).
> 
> After each boot I saved parts of /var/log away.
> Find attached dmesg and kern.log for the above mentioned 3 scenarios.

As discussed over at https://github.com/systemd/systemd/issues/11314
I've rebuilt src:systemd 240-2 with b261494 added as a quilt patch,
and this time I added "log_buf_len=1M" to the boot options.

Result: still the same (i.e. lots of modules not loaded, and lvm
warnings/timeouts).

I'm attaching dmesg and kern.log from this attempt (and will mention
them in the gh issue once the BTS has recorded this message).


Cheers,
gregor

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


udev-240-2+b261494.tar.gz
Description: application/gzip


signature.asc
Description: Digital Signature

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Andreas Maus]

Maybe the backtrace with libkrb5-dbg installed may provider more clues:

root@dagon:~# gdb /usr/sbin/automount /core 
GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/automount...(no debugging symbols found)...done.
[New LWP 9037]
[New LWP 9011]
[New LWP 9012]
[New LWP 9013]
[New LWP 9016]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/automount -d -f'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f8753fff700 (LWP 9037))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f875be80535 in __GI_abort () at abort.c:79
#2  0x7f875be8040f in __assert_fail_base (fmt=0x7f875bfe2ee8 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=0x7f8758f04029 "r == 0", 
file=0x7f8758f03f58 "../../../../src/include/k5-thread.h", line=376, 
function=) at assert.c:92
#3  0x7f875be8e0a2 in __GI___assert_fail 
(assertion=assertion@entry=0x7f8758f04029 "r == 0", 
file=file@entry=0x7f8758f03f58 "../../../../src/include/k5-thread.h", 
line=line@entry=376, function=function@entry=0x7f8758f04040 
<__PRETTY_FUNCTION__.5585> "k5_mutex_lock") at assert.c:101
#4  0x7f8758ea8ea3 in k5_mutex_lock (m=0x7f8754040498) at 
../../../../src/include/k5-thread.h:376
#5  0x7f8758ea9677 in k5_mutex_lock (m=0x7f8754040498) at 
../../../../src/include/k5-thread.h:376
#6  k5_cc_mutex_lock (context=context@entry=0x7f874c014ed0, 
m=m@entry=0x7f8754040498) at ../../../../src/lib/krb5/ccache/ccbase.c:460
#7  0x7f8758eb1776 in krb5_mcc_start_seq_get (context=0x7f874c014ed0, 
id=, cursor=0x7f8753ff7e48) at 
../../../../src/lib/krb5/ccache/cc_memory.c:357
#8  0x7f8758eaa2bd in has_content (cache=0x7f874c00b910, 
context=0x7f874c014ed0) at ../../../../src/lib/krb5/ccache/cccursor.c:278
#9  krb5_cccol_have_content (context=context@entry=0x7f874c014ed0) at 
../../../../src/lib/krb5/ccache/cccursor.c:278
#10 0x7f8758c6eb63 in acquire_init_cred (cred=0x7f874c0150d0, 
client_keytab=0x0, password=0x0, req_ccache=0x0, minor_status=0x7f8753ff85a4, 
context=0x7f874c014ed0) at ../../../../src/lib/gssapi/krb5/acquire_cred.c:735
#11 acquire_cred_context (context=0x7f874c014ed0, 
minor_status=minor_status@entry=0x7f8753ff85a4, 
desired_name=desired_name@entry=0x0, password=password@entry=0x0, 
cred_usage=cred_usage@entry=1, ccache=ccache@entry=0x0, client_keytab=0x0, 
keytab=0x0, rcname=0x0, iakerb=0, output_cred_handle=0x7f8753ff8178, 
time_rec=0x0, time_req=4294967295) at 
../../../../src/lib/gssapi/krb5/acquire_cred.c:827
#12 0x7f8758c6ee18 in acquire_cred 
(minor_status=minor_status@entry=0x7f8753ff85a4, 
desired_name=desired_name@entry=0x0, password=password@entry=0x0, 
cred_usage=cred_usage@entry=1, ccache=ccache@entry=0x0, 
keytab=keytab@entry=0x0, iakerb=0, output_cred_handle=0x7f8753ff8178, 
time_rec=0x0, time_req=4294967295) at 
../../../../src/lib/gssapi/krb5/acquire_cred.c:920
#13 0x7f8758c6ef4c in krb5_gss_acquire_cred 
(minor_status=minor_status@entry=0x7f8753ff85a4, 
desired_name=desired_name@entry=0x0, time_req=time_req@entry=4294967295, 
desired_mechs=desired_mechs@entry=0x0, cred_usage=cred_usage@entry=1, 
output_cred_handle=output_cred_handle@entry=0x7f8753ff8178, actual_mechs=0x0, 
time_rec=0x0) at ../../../../src/lib/gssapi/krb5/acquire_cred.c:1079
#14 0x7f8758c71d9f in kg_get_defcred 
(minor_status=minor_status@entry=0x7f8753ff85a4, 
cred=cred@entry=0x7f8753ff8178) at 
../../../../src/lib/gssapi/krb5/gssapi_krb5.c:202
#15 0x7f8758c76a08 in krb5_gss_init_sec_context_ext 
(minor_status=minor_status@entry=0x7f8753ff85a4, 
claimant_cred_handle=claimant_cred_handle@entry=0x0, 
context_handle=context_handle@entry=0x7f874c01b490, target_name=0x7f874c01c550, 
mech_type=0x7f8758c975a0 , req_flags=req_flags@entry=10, 
time_req=0, input_chan_bindings=0x0, input_token=0x0, actual_mech_type=0x0, 
output_token=0x7f8753ff85c0, 
ret_flags=0x7f8753ff85a8, time_rec=0x0, exts=0x7f8753ff8420) at 
../../../../src/lib/gssapi/krb5/init_sec_context.c:967
#16 0x7f8758c77702 in krb5_gss_init_sec_context 
(mino

Bug#917323: transition: gdal

[Sebastiaan Couwenberg]

On 1/3/19 4:23 PM, Emilio Pozuelo Monfort wrote:
> On 02/01/2019 21:10, Sebastiaan Couwenberg wrote:
>> On 1/2/19 12:55 PM, Emilio Pozuelo Monfort wrote:
>>> On 26/12/2018 08:46, Bas Couwenberg wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition

 For the Debian GIS team I'd like to transition to GDAL 2.4.0.

 Like the previous transition to GDAL 2.3.0 (#898566), there is no SONAME
 bump, only the virtual ABI package changed to account for the C++ symbol
 changes.

 All reverse dependencies rebuilt successfully with GDAL 2.4.0 from
 experimental as summarized below, except mysql-workbench due to an
 unrelated issue (#914761).

 libgdal-grass doesn't need a binNMU as the 2.4.0 version will be
 uploaded to unstable instead. liblas likewise doesn't need a binNMU,
 the version is experimental will be moved to unstable instead.
>>>
>>> Go ahead.
>>
>> Thanks.
>>
>> gdal (2.4.0+dfsg-1), liblas (1.8.1-9) & libgdal-grass (2.4.0-1) have
>> been uploaded to unstable, and gdal (2.4.0+dfsg-1) is now installed on
>> all release architectures.
> 
> Looks like the rebuilt gazebo fails its autopkgtest due to a broken gazebo.pc,
> see #918121. That causes migration delays for gdal. No idea where the broken
> flag is coming from, I haven't investigated that deep.

That looks like @Boost_PKGCONFIG_LIBS@ which is constructed in
CMakeLists.txt with:

  foreach (b ${Boost_LIBRARIES})
get_filename_component(bname ${b} NAME_WE)
# Prefix always -l
set (bname "-l${bname}")
# Remove the prefix lib (not always present, like in pthread)
string (REPLACE "lib" "" bname "${bname}")
set (Boost_PKGCONFIG_LIBS "${Boost_PKGCONFIG_LIBS} ${bname}")
  endforeach(b)

get_filename_component() seems to return an empty string for one of the
boost libraries.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#918009: firmware-amd-graphics: please add amdgpu firmware for kaveri

[Trek]

Version: 20180825+dfsg-1

I confirm the problem, it leads to a crash of the amdgpu module if the
4.19 kernel is booted with amdgpu.cik_support=1 radeon.cik_support=0

for further informations see

https://bugs.freedesktop.org/show_bug.cgi?id=107855

comment 2 for the kernel messages and comment 4 for a simple workaround

however the correct solution is to include the amdgpu firmware, as the
radeon firmware seems to be no more updated

ciao!

Bug#917989: LD_DEBUG messages

[Bernhard Schmidt]

Am 2019-01-02 02:54, schrieb Troy Telford:

Dear Troy,


Below is the bottom stanza from LD_DEBUG, showing the linker error.  I
hope it’s helpful.


Thanks for your debugging.

I tried to reproduce this in a Buster container, but Asterisk started 
fine for me with the latest GnuTLS installed. Also the autopkgtests 
don't show up anything in the logs. Note that the overall state of debci 
failed due to an unrelated bug.


I have just uploaded -2 to unstable to fix autopkgtest. As a side 
benefit this compiles asterisk against the current GnuTLS version. Could 
you please test this version and report back?


Based on your LD_DEBUG messages the problem could also be in 
libgpgme.so.11


---
  7105: file=libgpgme.so.11 [0];  needed by 
/lib/x86_64-linux-gnu/libgmime-3.0.so.0 [0]

  7105: find library=libgpgme.so.11 [0]; searching
  7105:  search cache=/etc/ld.so.cache
  7105:   trying file=/lib/x86_64-linux-gnu/libgpgme.so.11
  7105:
  7105: file=libgpgme.so.11 [0];  generating link map
Inconsistency detected by ld.so: ../elf/dl-tls.c: 73: 
_dl_next_tls_modid: Assertion `result <= GL(dl_tls_max_dtv_idx) + 1' 
failed!

---

Best Regards,
Bernhard

Bug#918124: Not starting sync daemons with init script

[Peter Viskup]

Package: ipvsadm
Version: 1:1.28-3+b1

When invoking /etc/init.d/ipvsadm with appropriate
/etc/default/ipvsadm configuration, the sync daemons are not started.
Following errors are printed
Jan 03 16:07:24 server ipvsadm[31118]: Starting IPVS Connection
Synchronization Daemon: masterTry `/sbin/ipvsadm -h' or '/sbin/ipvsadm
--help' for more information.
Jan 03 16:07:24 server ipvsadm[31118]:  backupTry `/sbin/ipvsadm -h'
or '/sbin/ipvsadm --help' for more information.
Jan 03 16:07:24 server ipvsadm[31118]:  failed!

They are caused by the errors in init script.

Lines
$IPVSADM --syncid $SYNCID --start-daemon $DAEMON --mcast-interface \
$IFACE --syncid $SYNCID || log_end_msg 1
should be changed to
$IPVSADM --start-daemon $DAEMON --mcast-interface \
$IFACE --syncid $SYNCID || log_end_msg 1

The another error is related to not processed IPVSADM_CONFIG file. It
is defined, but not executed and thus not effective.
Line
[ -f "${IPVSADM_CONFIG}" ] && . "${IPVSADM_CONFIG}"
should be put after variable initializations.

Also rewrite to systemd service file will be useful.

Peter

Bug#820911: Accessibility for visual impaired is broken,, High-Contrast Theme is no longer activated by shortcut

[Holger Wansing]

Hi,

Samuel Thibault  wrote:
> Also, we need to document it in the installation manual and the
> wiki.debian.org/accessibility page.

Sure. For the installation-guide, that could be something like


diff --git a/en/boot-installer/accessibility.xml 
b/en/boot-installer/accessibility.xml
index 52853a9d8..f792a4852 100644
--- a/en/boot-installer/accessibility.xml
+++ b/en/boot-installer/accessibility.xml
@@ -168,8 +168,11 @@ the boot parameter by typing h 
&enterkey;.
 
 
 For users with low vision, the installer can use a high-contrast
-color theme that makes it more readable. To enable it, append the
-theme=dark boot parameter.
+color theme that makes it more readable. To enable it, you can use the
+corresponding entries from the boot screen (on BIOS systems: in the submenu
+Advanced options for visual impaired; on UEFI systems:
+Graphical install with dark theme for visual impaired)
+or append the theme=dark boot parameter.
 
 
   



Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#871835: speed up for debootstrap

[Roger Shimizu]

Dear Thomas,

On Wed, Jan 2, 2019 at 7:51 PM Thomas Lange
 wrote:
>
> > On Sun, 23 Dec 2018 22:52:36 +0900, Roger Shimizu 
> >  said:
>
> > On Sat, Aug 12, 2017 at 1:54 PM Thomas Lange
> >  wrote:
> >>
> >> old version 1.0.89
> >> real1m26.940s
> >> user1m24.180s
> >> sys 0m2.420s
> >>
> >>
> >> including the patches
> >> real0m39.481s
> >> user0m50.444s
> >> sys 0m2.748s
>
> > have you compared with cdebootstrap?
> > - https://tracker.debian.org/pkg/cdebootstrap
> cdebootstrap takes about 30 sec real time and 40 sec user time.

Really thanks for your test result, and the patches!

Since cdebootstrap usually install smaller set of packages, I think
they're now pretty close at speed.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#918125: pxlib: Please package new upstream version 0.6.8

[Boyuan Yang]

Source: pxlib
Version: 0.6.7-1
Severity: normal
X-Debbugs-CC: ste...@debian.org

Dear pxlib maintainer,

Upstream has released a new version 0.6.8.
Please consider providing it in Debian.

--
Regards,
Boyuan Yang


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

Bug#918124: This error is duplicate of 649106

[Peter Viskup]

Please close it.
Users reporting the same under
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649106

Peter

Bug#918126: roundcube-plugins: missing attachment_reminder plugin from upstream

[Rob]

Package: roundcube
Version: 1.2.3+dfsg.1-4+deb9u3
Severity: normal

Dear Maintainer,

The attachment_reminder plugin is in the sid source 1.3.8, but does not get 
installed
by roundcube-plugins. It is a small relatively simple plugin that I didn't see 
a 
reason for leaving it out.

I have manually installed it since 1.1.5/jessie-backports with no issues 
apparent.

When the plugin is enabled it checks for keywords in the email body such as 
"attachment" and
when you click send it will prompt if you forgot to attach a file if no 
attachent is present.

Please consider adding it back to the roundcube-plugins.

Thank you for the continued work on this package!

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

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

Versions of packages roundcube depends on:
ii  dpkg1.18.25
ii  roundcube-core  1.2.3+dfsg.1-4+deb9u3

roundcube recommends no packages.

roundcube suggests no packages.

Versions of packages roundcube-core depends on:
ii  dbconfig-common 2.0.8
ii  debconf [debconf-2.0]   1.5.61
ii  dpkg1.18.25
ii  libapache2-mod-php  1:7.0+49
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.33-0+deb9u1
ii  libmagic1   1:5.30-1+deb9u2
ii  php 1:7.0+49
ii  php-auth-sasl   1.0.6-3
ii  php-common  1:49
ii  php-intl1:7.0+49
ii  php-mail-mime   1.10.0-2
ii  php-mcrypt  1:7.0+49
ii  php-net-smtp1.7.1-2
ii  php-net-socket  1.0.14-2
ii  php-pear1:1.10.1+submodules+notgz-9
ii  php7.0 [php]7.0.33-0+deb9u1
ii  php7.0-cli [php-cli]7.0.33-0+deb9u1
ii  php7.0-intl [php-intl]  7.0.33-0+deb9u1
ii  php7.0-json [php-json]  7.0.33-0+deb9u1
ii  php7.0-mcrypt [php-mcrypt]  7.0.33-0+deb9u1
ii  roundcube-mysql 1.2.3+dfsg.1-4+deb9u3
ii  ucf 3.0036

Versions of packages roundcube-core recommends:
ii  apache2 [httpd-cgi] 2.4.25-3+deb9u6
ii  php-gd  1:7.0+49
ii  php-pspell  1:7.0+49
ii  php7.0-gd [php-gd]  7.0.33-0+deb9u1
ii  php7.0-pspell [php-pspell]  7.0.33-0+deb9u1

Versions of packages roundcube-core suggests:
pn  php-crypt-gpg  
ii  php-net-ldap2  2.2.0-3
ii  php-net-ldap3  1.0.4-1
ii  roundcube-plugins  1.2.3+dfsg.1-4+deb9u3

-- debconf information excluded

Bug#918127: [debian-refcard] improve layout for Greek

[Holger Wansing]

Package: refcard
Tags: patch


For Greek, the copyright notice is currently not visible, due to missing space
on the sheet.

The following patch uses a smaller font size, which would give more free
space, so that the copyright notice gets displayed.

I have double-checked with Greek translator, that the content is still well
readable even with the smaller font.

Patch is attached.


Holger




-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/preproc.xsl b/preproc.xsl
index 2565066..9453b40 100644
--- a/preproc.xsl
+++ b/preproc.xsl
@@ -20,7 +20,7 @@
   
   
 	
-	  footnotesize
 	  small
 	

Bug#917941: Installation Buster on HP 17-by Notebook

[Cyril Brulebois]

Hi Bernhard,

Bernhard  (2019-01-03):
> Thanks for your response.
> In my installer image, the firmware-realtek.deb is available.
> 
> I'm not sure, if the WLAN ethernet adapter is supported from current kernel 
> 4.19.
> It would be great, if the WLAN ethernet adapter can be supported in Debian 10 
> "buster".
> 
> Attached, there is the syslog.

[This mail didn't reach debian-boot@ due to the attachment's size, sorry
for not having suggested compression in the first place.]

Looking at the syslog, the nic-wireless udeb is loaded successfully and
no interfaces show up, so I've spent some more time digging around, and
found that some linux forks have merged out of tree drivers, including
the separate rtl8821ce module, e.g. at [1], which isn't in mainline yet
as of v4.20+):
| kibi@armor:~/hack/linux.git$ git log endless/master -- 
drivers/net/wireless/rtl8821ce
| commit 3966567041ddd2d355a28ad980a3b5d68b36f975
| Author: Daniel Drake 
| Date:   Tue Nov 6 11:34:48 2018 +0800
| 
| rtl8821ce: fix build for Linux-4.19
| 
| commit 856fff46ec4d60c2c3e4c6aba3c6442fd703e948
| Author: Chris Chiu 
| Date:   Mon Aug 28 13:21:22 2017 +0800
| 
| rtl8821ce: integrate and fix build
| 
| https://phabricator.endlessm.com/T18646
| 
| commit 2102de7420ecb9136471cd5bf29ad7165a560614
| Author: Chris Chiu 
| Date:   Mon Aug 28 13:14:23 2017 +0800
| 
| Import rtl8821ce wifi driver
| 
| From Realtek official release 
rtl8821CE_WiFi_linux_v5.2.5_23431.20170824_COEX20170310-1212.tar.gz
| 
| https://phabricator.endlessm.com/T18646

 1. https://github.com/endlessm/linux/tree/master/drivers/net/wireless/rtl8821ce

So I guess there's not much we can do on the debian-installer side, we
would need to get this module merged into our linux source package to
make use of it, and I don't think the kernel team would add random out
of tree modules. ISTR backporting drivers is something that happens, so
we might get this module supported in a later 4.19.x release, once it
reaches mainline and someone backports it?

Cc'ing kernel team to make sure I'm not entirely wrong here. Maybe also
steal this bug away from installation-reports and have it retitled “no
support for rtl8821ce” or something similar?


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


signature.asc
Description: PGP signature

Bug#918128: gazebo: autopkgtest fails due to invalid gazebo.pc

[Bas Couwenberg]

Source: gazebo
Version: 9.4.1+dfsg-1
Severity: serious
Tags: patch
Justification: makes the package in question unusable or mostly so
Control: block 917323 by -1

Dear Maintainer,

The autopkgtest for gazebo is failing due to an invalid gazebo.pc:

 autopkgtest [12:48:58]: test build: [---
 /usr/bin/ld: cannot find -l-lpthread
 collect2: error: ld returned 1 exit status
 autopkgtest [12:48:59]: test build: ---]
 autopkgtest [12:48:59]: test build:  - - - - - - - - - - results - - - - - - - 
- - -
 buildFAIL non-zero exit status 1
 autopkgtest [12:49:00]: test build:  - - - - - - - - - - stderr - - - - - - - 
- - -
 /usr/bin/ld: cannot find -l-lpthread
 collect2: error: ld returned 1 exit status
 autopkgtest [12:49:00]:  summary
 buildFAIL non-zero exit status 1

See: 
https://ci.debian.net/data/packages/unstable/amd64/g/gazebo/latest-autopkgtest/log.gz

This is caused by ${Boost_LIBRARIES} containing:

 
/usr/lib/x86_64-linux-gnu/libboost_thread.so;-lpthread;/usr/lib/x86_64-linux-gnu/libboost_signals.so;[...]

Which results in:

 [...]-L/usr/lib/x86_64-linux-gnu -lboost_thread -l-lpthread 
-lboost_signals[...]

The attached patch fixes the issue by prefixing -l only when it is not
already present.

Kind Regards,

Bas
Description: Don't prefix -l if already present.
 An invalid gazebo.pc is generated when ${Boost_LIBRARIES} contains:
 .
 
/usr/lib/x86_64-linux-gnu/libboost_thread.so;-lpthread;/usr/lib/x86_64-linux-gnu/libboost_signals.so;[...]
 .
 This resulted in gazebo.pc containing:
 .
 [...]-L/usr/lib/x86_64-linux-gnu -lboost_thread -l-lpthread 
-lboost_signals[...]
 .
 Which in turn caused the autopkgtests to fail:
 .
 /usr/bin/ld: cannot find -l-lpthread
Author: Bas Couwenberg 

Index: gazebo-9.4.1+dfsg/CMakeLists.txt
===
--- gazebo-9.4.1+dfsg.orig/CMakeLists.txt
+++ gazebo-9.4.1+dfsg/CMakeLists.txt
@@ -371,8 +371,10 @@ else (build_errors)
 
   foreach (b ${Boost_LIBRARIES})
 get_filename_component(bname ${b} NAME_WE)
-# Prefix always -l
-set (bname "-l${bname}")
+# Prefix -l if not already present
+if(NOT ${bname} MATCHES "^-l")
+  set (bname "-l${bname}")
+endif()
 # Remove the prefix lib (not always present, like in pthread)
 string (REPLACE "lib" "" bname "${bname}")
 set (Boost_PKGCONFIG_LIBS "${Boost_PKGCONFIG_LIBS} ${bname}")

Bug#918129: pg_buildext: Bug in man page sample control.in

[James Coleman]

Package: postgresql-server-dev-all
Version: 197.pgdg90+1
Severity: normal

Dear Maintainer,


I was implementing a new postgres extension package, and following
the examples in the pg_buildext man page.

Specifically I copied the control.in sample, and along with a project
Makefile (commands for which unfortunately are not detailed in the man
page) I found that running "pg_buildext controlcheck" (or updatecontrol)
fails with the example control.in file because there is not a newline
after the "Build-Depends:" line (so there is only one "paragraph" in
the file). The error results because of the first grep-dctrl the
gencontrol() function returns exit code 1 since it finds no results
without the package info in a separate paragraph. This combined with the
"set -e" at the top of the file results in pg_buildext failing but
without any error logging whatsoever.

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages postgresql-server-dev-all depends on:
ii  dctrl-tools2.24-2+b1
ii  lsb-release9.20161125
ii  make   4.1-9.1
ii  postgresql-common  197.pgdg90+1
ii  postgresql-server-dev-10   2:10.4r2ndq1.4-1.stretch+1
ii  postgresql-server-dev-11   2:11.1r2ndq1.4-1.stretch+1
ii  postgresql-server-dev-9.3  9.3.25-1.pgdg90+1
ii  postgresql-server-dev-9.4  9.4.20-1.pgdg90+1
ii  postgresql-server-dev-9.5  9.5.15-1.pgdg90+1
ii  postgresql-server-dev-9.6  2:9.6.6r2ndq1.4-1.stretch+1

postgresql-server-dev-all recommends no packages.

postgresql-server-dev-all suggests no packages.

-- no debconf information

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

* Thomas Dickey  [2018-12-31 20:32]:

> On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
>> * Thomas Dickey  [2018-12-31 00:51]:
>> 
>>> Can you make a backtrace for #341, please?
>> 
>> Here it is:

[...]

Thanks a lot for taking the time to investigate the issue and for
providing the fontconfig patch! I've been away from home and couldn't
reply earlier.

As the issue has now been solved xterm-wise, just a few remarks:

>> Reading symbols from /usr/bin/xterm...Reading symbols from 
>> /usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done.
>> done.
>> (gdb) run -fa 'Noto Mono'
> 
> fwiw, my Debian/testing machine has these fonts (with "noto" in their names):
> 
> ii  fonts-noto20181130-1  
>   all  metapackage to pull in all Noto fonts
> ii  fonts-noto-cjk1:20170601+repack1-3
>   all  "No Tofu" font families with large Unicode coverage 
> (CJK regular and bold)
> ii  fonts-noto-color-emoji0~20180810-1
>   all  color emoji font from Google
> ii  fonts-noto-hinted 20181130-1  
>   all  "No Tofu" font families with large Unicode coverage 
> (hinted)
> ii  fonts-noto-mono   20181130-1  
>   all  "No Tofu" monospaced font family with large Unicode 
> coverage
> ii  fonts-noto-unhinted   20181130-1  
>   all  "No Tofu" font families with large Unicode coverage 
> (unhinted)

Exactly the same on my system. fonts-noto-color-emoji was only recently
installed via a dependency at the same time as xterm was upgraded from
337 to 338.

It turns out that simply removing the package fonts-noto-color-emoji
eliminates the issue! So that's probably the best workaround right now
for anyone with the same problem, until your patch is incorporated into
fontconfig.

[...]

> This part is in the newer function which handles fallback fonts.
> Since your trace shows line-numbers, I'm assuming it's not the Debian package.
> (Actually the trace seems to show that you've compiled fontconfig -- turning
> off the optimization might help pinpoint the details).

For the record, no, the trace had been made with the provided
xterm-dbgsym and libfontconfig1-dbgsym packages.

Best
Alex

Bug#917323: transition: gdal

[Sebastiaan Couwenberg]

On 1/3/19 4:39 PM, Sebastiaan Couwenberg wrote:
> On 1/3/19 4:23 PM, Emilio Pozuelo Monfort wrote:
>> On 02/01/2019 21:10, Sebastiaan Couwenberg wrote:
>>> On 1/2/19 12:55 PM, Emilio Pozuelo Monfort wrote:
 On 26/12/2018 08:46, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> For the Debian GIS team I'd like to transition to GDAL 2.4.0.
>
> Like the previous transition to GDAL 2.3.0 (#898566), there is no SONAME
> bump, only the virtual ABI package changed to account for the C++ symbol
> changes.
>
> All reverse dependencies rebuilt successfully with GDAL 2.4.0 from
> experimental as summarized below, except mysql-workbench due to an
> unrelated issue (#914761).
>
> libgdal-grass doesn't need a binNMU as the 2.4.0 version will be
> uploaded to unstable instead. liblas likewise doesn't need a binNMU,
> the version is experimental will be moved to unstable instead.

 Go ahead.
>>>
>>> Thanks.
>>>
>>> gdal (2.4.0+dfsg-1), liblas (1.8.1-9) & libgdal-grass (2.4.0-1) have
>>> been uploaded to unstable, and gdal (2.4.0+dfsg-1) is now installed on
>>> all release architectures.
>>
>> Looks like the rebuilt gazebo fails its autopkgtest due to a broken 
>> gazebo.pc,
>> see #918121. That causes migration delays for gdal. No idea where the broken
>> flag is coming from, I haven't investigated that deep.
> 
> That looks like @Boost_PKGCONFIG_LIBS@ which is constructed in
> CMakeLists.txt with:
> 
>   foreach (b ${Boost_LIBRARIES})
> get_filename_component(bname ${b} NAME_WE)
> # Prefix always -l
> set (bname "-l${bname}")
> # Remove the prefix lib (not always present, like in pthread)
> string (REPLACE "lib" "" bname "${bname}")
> set (Boost_PKGCONFIG_LIBS "${Boost_PKGCONFIG_LIBS} ${bname}")
>   endforeach(b)
> 
> get_filename_component() seems to return an empty string for one of the
> boost libraries.

Patch submitted in #918128.

That just leaves python-numpy breaking many autopkgtests, which I'm not
in a position to fix.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#918130: Mail::SpamAssassin::Plugin::ASN reports wrong ASN for IPv6

[Bernhard Schmidt]

Package: spamassassin
Version: 3.4.2-1
Severity: normal
Tags: upstream ipv6

Hi,

the Mail::SpamAssassin::Plugin::ASN reports the wrong source ASN for mails
received over IPv6

X-Spam-ASN: AS3215 2.0.0.0/16
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5])

This is caused by SpamAssassin querying the same zone for both IPv4 and IPv6
remote hosts, and 2.0.0.0/16 translating to 

*.0.2.origin.asn.cymru.com

which of course also matches 2000::/8.

There is a bug/patch proposed in upstream bz,

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7211

I've prodded them to commit it to trunk so it could be cherry-picked for Buster.

Thanks,
Bernhard

Bug#918131: nmu: gnushogi_1.5~git20140725-1

[Sven Joachim]

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

Please rebuild gnushogi in experimental, it still depends on libncurses5
rather than libncurses6.

nmu gnushogi_1.5~git20140725-1 . ANY . experimental . -m "Rebuild against 
libncurses6."

There are two more packages in experimental which depend on libncurses5,
but they cannot be rebuilt due to #832330 and #915072.

Please see #894049 for the libncurses6 transition.

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

* Thomas Dickey  [2019-01-02 10:46]:

> I verified that the same issue exists in current code, and submitted an
> 
>   https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/140
> 
> with the attached fix.

As a side note, visiting that particular page causes both Chromium and
Firefox to crash in a manner that looks similar to what I reported for
xterm. Chromium crashes completely, in Firefox it's just a tab crash.

As with the xterm issue, this doesn't occur when I remove either my
fonts.conf file or the package fonts-noto-color-emoji.

These two characters appear on the page:

U+1F44D THUMBS UP SIGN
U+1F44E THUMBS DOWN SIGN

And the CSS stylesheet seems to load the "Noto Color Emoji" font.

In Firefox, the crash doesn't happen when I remove the two offending
characters from the page source /or/ when I remove the CSS file. In
Chromium, only removing the CSS file helps.

So it seems that more packages might be affected? But it's probably best
to wait for the provided patch to make it into fontconfig before taking
more time to look into this?

For the record, here's the crash report from Firefox (probably not
particularly useful due to missing symbols):
https://crash-stats.mozilla.com/report/index/afb14dec-e1f6-43dd-8852-d80670190103

And this is what Chromium outputs on the terminal:

Received signal 11 SEGV_MAPERR 
#0 0x55ed814cc9d1 
#1 0x55ed814cb413 
#2 0x55ed814cc945 
#3 0x7f59461f86b0 
#4 0x7f5942b5c2d1 
#5 0x7f5942b5c418 
#6 0x7f5942b5d55f FcConfigSubstituteWithPat
#7 0x7f5942b6d9bd FcFontRenderPrepare
#8 0x7f5942b6de44 FcFontMatch
#9 0x55ed81b8ec63 
#10 0x55ed8032726f 
#11 0x55ed7f794bdc 
#12 0x55ed80326c5c 
#13 0x55ed8151395b 
#14 0x55ed81516204 
#15 0x55ed81517363 
#16 0x55ed81511ba0 
#17 0x55ed81511e8a 
#18 0x55ed8152177f 
#19 0x55ed8141925d 
#20 0x55ed81496f61 
#21 0x55ed814e1e57 
#22 0x55ed814994c3 
#23 0x55ed814908b6 
#24 0x55ed81490d84 
#25 0x55ed814dcec5 
#26 0x7f59461edfa3 start_thread
#27 0x7f593def988f clone
  r8: 7f5900177110  r9: 7f5900177110 r10: 0003 r11: 
0020
 r12: 55ed88462528 r13: 7f590002cad0 r14: 7f59000690a0 r15: 
0001
  di: 7f590002cad0  si: 7f59000690a0  bp: 55ed88312ba0  bx: 
0003
  dx: 0001  ax: 55ed88312b70  cx:   sp: 
7f590f7fbb40
  ip: 7f5942b5c2d1 efl: 00010202 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: 
[end of stack trace]
Calling _exit(1). Core file will not be generated.

Bug#917789: Wrong tarball id (pristine-tar) when import-orig with --components

[Guido Günther]

Hi,
On Thu, Jan 03, 2019 at 02:22:27PM +, Mo Zhou wrote:
> On Thu, Jan 03, 2019 at 10:45:12AM +0100, Guido Günther wrote:
> > What's your checkout command on the other machine? Did you specify the
> > components. Please don't omit the commands you're using for import and
> > export
> 
> import:
> 
> gbp import-orig --pristine-tar ../opencv_3.4.5+dfsg.orig.tar.xz 
> --component contrib
> 
> export (where the tarball is imported):
> 
> ~/D/o/opencv ❯❯❯ git st
> HEAD detached at 922bf8f32
> nothing to commit, working tree clean
> ~/D/o/opencv ❯❯❯ pristine-tar checkout 
> opencv_3.4.5+dfsg.orig-contrib.tar.xz
> pristine-tar: successfully generated opencv_3.4.5+dfsg.orig-contrib.tar.xz
> ~/D/o/opencv ❯❯❯ pristine-tar checkout opencv_3.4.5+dfsg.orig.tar.xz
> pristine-tar: successfully generated opencv_3.4.5+dfsg.orig.tar.xz
> 
> export (remote):
> 
> It's quite strange that I cannot reproduce this problem anymore
>   on the commit in question.
> 
>   @Mattia: Are you able to reproduce this problem?
> 
>   I can checkout the tarball from both
> git: a0bd84b30b388b9811bc300e9a62801cf89c8966
> git: 922bf8f325761abecfcd8171ab490fba4e821c58
>   which yield the same tarball
> c41c9e5892e3d1fa15c0a8016cd5e84c  1.xz
>   c41c9e5892e3d1fa15c0a8016cd5e84c  2.xz
> even if they points to different id:
>   --- a/opencv_3.4.5+dfsg.orig.tar.xz.id
>   +++ b/opencv_3.4.5+dfsg.orig.tar.xz.id
>   @@ -1 +1 @@
>   -a67d0acc9952eb94c9dc0f50eb1f73777695418e
>   +a18a03170473e1773e1f571e561441bc83a3861e

That does not work you want to use gbp export-orig to export the
tarballs and pass the subtarball names with --component (it's symmetric
to the import) since you otherwise lack the needed trees. Check the tb
package. So far I don't see a bug here.

gbp export-orig --component contrib 

Cheers,
 -- Guido

Bug#851746: Orphaning dh-exec

[Gergely Nagy]

retitle 851746 dh-exec -- Scripts to help with executable debhelper files
thanks

You do not need to contact me if you want to adopt the package, just go
ahead with it.

-- 
|8]

Bug#870126: ecryptfs-utils: The problem is the link from the session ring

[Andrea Borgia]

On Tue, 01 Aug 2017 12:37:49 +0200 =?utf-8?q?Ita=C3=AF_BEN_YAACOV?= 
 wrote:




1. The problem is the user keyring not being linked
to the session keyring.   keyctl link @u @s   is a much easier workaround.


I've got the same issue but this workaround didn't solve the issue.
(testing, package version 111-4 as this report)

The longer solution is a bit tricky to use, since the whole homedir is 
encrypted and I am already logged in. Could I perhaps disable ecryptfs 
and redo it from start? Got backups and all, not an issue.




2. For me this happens only in gnome sessions (not console or ssh)
Is this the same for you?
(see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870335 )


I haven't seen that when running a graphical desktop (xfce, in my case) 
or via ssh, only in console. Also, if I am already logged in, regardless 
of the terminal, it won't happen but I assume this is to be expected.



Andrea.

Bug#918132: O: riemann-c-client -- C language client library for the Riemann event stream processor

[Gergely Nagy]

Package: wnpp
Severity: normal

I'm orphaning riemann-c-client. I still intend to maintain it upstream
(there's not much to maintain there, mind you), but I no longer wish to
maintain the Debian package.

Feel free to pick it up.

The package description is:

Description: C language client library for the Riemann event stream processor
 Riemann is a network event stream processor, intended for analyitics,
 metrics and alerting; and to glue various monitoring systems together.
 .
 This library provides a C language client, with a simple but
 convenient API, to connect to Riemann, send events and run queries
 against it.

(There's also a -dev package, and one with utilities based on the library.)

-- 
|8]

Bug#918133: O: aalib -- ASCII art library

[Gergely Nagy]

Package: wnpp
Severity: normal

I'm orphaning aalib. It's in reasonable state, I believe, but it might
need some updates here and there (mostly to change the Vcs headers to
something that exists... the alioth archives are - I think - up to
date).

Package description is:

Description: ASCII art library
 AAlib is a portable ASCII art graphics library. Internally, it works like
 a graphics display, but the output is rendered into gorgeous platform
 independent ASCII graphics.

-- 
|8]

Bug#918134: O: dpatch -- patch maintenance system for Debian source packages

[Gergely Nagy]

Package: wnpp
Severity: normal

I *think* the Alioth archives are up-to-date. Or at least not too far
behind.

Description: patch maintenance system for Debian source packages
 dpatch is an easy to use patch system for Debian packages, somewhat
 similar to the dbs package, but much simpler to use.
 .
 It lets you store patches and other simple customization templates in
 debian/patches and otherwise does not require much reorganization of
 your source tree. To get the patches applied at build time you simply
 need to include a makefile snippet and then depend on the
 patch/unpatch target in the build or clean stage of debian/rules - or
 you can use the dpatch patching script directly.
 .
 It can easily apply patches only on specific architectures if needed.

-- 
|8]

Bug#917656: Random autopkgtest failures on libnet-server-mail-perl

[Xavier]

After many tests, it seems that (since Perl-5.28) connection on test
server is refused randomly under heavy load before test is run.

Since I'm also upstream, I'll try to build a better test.

Cheers,
Xavier