Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Otto Kekäläinen]

Hello!

Can you please provide an actual pbuilder command or something I can
copy-paste to reproduce the actual problem (and not just the aptitude
symptom)?

Bug#917266: default-libmysqlclient-dev: Uninstallable - depends on no longer built libmariadbclient-dev-compat

[Scott Kitterman]

Package: default-libmysqlclient-dev
Version: 1.0.4
Severity: grave
Justification: renders package unusable

 no longer found.

Since mariadb10.3 became the default this no longer works:

#include 

It has to be changed to:

#include 

You can experience this for yourself by rebuilding postfix, seeing it fail:

gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE -DHAS_LDAP -DUSE_LDAP_SASL 
-DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB -DHAS_MYSQL 
-I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql -DHAS_SQLITE 
-I/usr/include -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH 
-I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS -I/usr/include -DHAS_DEV_URANDOM 
-DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\" 
-DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" 
-DDEF_MANPAGE_DIR=\"/usr/share/man\" 
-DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS 
-DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g -O2 -I. 
-I../../include -DLINUX3 -c dict_ldap.c
gcc -shared -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib/postfix -o 
postfix-ldap.so dict_ldap.o -lldap -llber -L../../lib -L. -lpostfix-util 
-lpostfix-global
gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE -DHAS_LDAP -DUSE_LDAP_SASL 
-DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB -DHAS_MYSQL 
-I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql -DHAS_SQLITE 
-I/usr/include -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH 
-I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS -I/usr/include -DHAS_DEV_URANDOM 
-DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\" 
-DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" 
-DDEF_MANPAGE_DIR=\"/usr/share/man\" 
-DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS 
-DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g -O2 -I. 
-I../../include -DLINUX3 -c dict_mysql.c
dict_mysql.c:171:10: fatal error: mysql.h: No such file or directory
 #include 
  ^
compilation terminated.

And then changing src/global/dict_mysql.c line 171

Alternately, I could update the include path, I guess, but isn't approximately
the whol point of providing a generic default so that every package in
Debian doesn't have to change when the default changes?

Scott K

Bug#917268: supertux: new upstream 0.6.0

[Jonatan Nyberg]

package: supertux
severity: normal

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

Regards,
Jonatan

Bug#917267: glx-diversions cannot be uninstalled

[Norbert Preining]

Package: glx-diversions
Version: 0.9.0
Severity: serious
Justification: maintainer scripts should not error

Hi all

I recently purged all kind of nvidia* packages from my computer, and now
none of them is actually there, but I still cannot uninstall
glx-diversions:
$ aptitute 
...
Performing actions...
(Reading database ... 961080 files and directories currently installed.)
Removing glx-diversions (0.9.0) ...
dpkg-divert: error: rename involves overwriting 
'/usr/lib/i386-linux-gnu/libGL.so.1' with
  different file '/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1', not allowed
dpkg: error processing package glx-diversions (--remove):
 installed glx-diversions package post-removal script subprocess returned error 
exit status 2
Removing glx-alternative-mesa (0.9.0) ...
Errors were encountered while processing:
 glx-diversions
E: Sub-process /usr/bin/dpkg returned an error code (1)
..

Same with dpkg --purge ...

Best

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

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

Versions of packages glx-diversions depends on:
ii  dpkg  1.19.2
pn  glx-alternative-mesa  
ii  nvidia-installer-cleanup  20151021+8

glx-diversions recommends no packages.

glx-diversions suggests no packages.

-- no debconf information

Bug#917266: Acknowledgement (default-libmysqlclient-dev: Uninstallable - depends on no longer built libmariadbclient-dev-compat)

[Scott Kitterman]

I quick look at codesearch.d.o suggests this will break 4 - 5 dozen packages.  

Scott K

Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Sebastiaan Couwenberg]

On 12/25/18 8:57 AM, Otto Kekäläinen wrote:
> Can you please provide an actual pbuilder command or something I can
> copy-paste to reproduce the actual problem (and not just the aptitude
> symptom)?

Sure:

 sudo cowbuilder --create \
 --distribution=sid \
 --basepath=/var/cache/pbuilder/base-sid.cow
 dget -u \
  http://deb.debian.org/debian/pool/main/g/gdal/gdal_2.3.3+dfsg-1.dsc
 cd gdal-2.3.3/
 dch -nm "Test rebuild"
 pdebuild --pbuilder cowbuilder -- \
  --basepath /var/cache/pbuilder/base-sid.cow/

pbuilder will be unstable to install the build dependencies, causing the
configure target to disable MySQL support despite using the --with-mysql
option:

   MySQL support: no


Please also answer my questions:

> Isn't the appropriate fix to build libmariadbclient-dev-compat from
> the mariadb-10.3 instead of 10.1? Aren't you now transitioning from
> 10.1 to 10.3? And shouldn't mysql-defaults be updated for that too?

default-libmysqlclient-dev depends on libmariadbclient-dev-compat which
is built from the mariadb-10.1 source package.

libmariadbclient-dev-compat depends on libmariadbclient-dev (also built
from the mariadb-10.1 source package), which in turn depends on
libmariadbclient18 (= 1:10.1.37-3).

As long as the 10.3 packages Conflict or Break 10.1 packages, the
default-* packages cannot be installed along with the 10.3 packages, as
the default packages are depending on the 10.1 packages.

Kind Regards,

Bas

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

Bug#917018: wget: Unusable - permanent segmentation fault

[rwpenney]

Hello Bernhard,

I do indeed have a ~/.wget-hsts file, and it has permissions and 
contents that seem suspiciously linked with setup of unprivileged LXC 
containers. If I remove that file, wget seems to work fine. Obviously, 
wget shouldn't just be crashing when it fails to open this file, but at 
least you've given us a good work-around.


Thanks for finding the source of the problem.

Kind regards,

RW Penney

Bug#917269: kinit: Crashes when navigating to home directory in dolphin

[Braun Gábor]

Package: kinit
Version: 5.51.0-1
Severity: normal

Dear Maintainer,

Navigating to my home directory in Dolphin, a drkonqi message appears
"A(z) kdeinit5 váratlanul bezárult"
(meaning: kdeinit5 unexpectedly stopped) with buttons to report the bug and
restart the application.  Clicking on the button for reporting the bug,
a window with two tabs appears, and in th active tab the following message:
"Sajnáljuk, de a(z) kdeinit5 váratlanul eállt.
Nem jelentheti a hibát, mivel kdeinit5 nem adott meg gibajelentési címet."
Translated: Sorry, kdeiinit5 stopped unexpectedly.
The bug cannot be reported as kdeinit5 does not provide an address for it.

Selecting the other tab, a backtrace appears, see below, with the remark that 
it is not useful.
Clicking on the appropriate link, a window appears claiming that the debugging 
information for
the following files are missing:

/usr/bin/kdeinit5
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
/usr/lib/x86_64-linux-gnu/qt5/plugins/ffmpegthumbs.so
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5

I was unable to find the packages with the debugging symbols, e.g.,
I have not found a package named kinit-dbg or kinit-dbgsym.

This whole thing happens only with my home directory, and besides the drkonqi 
message
everything else seems to function correctly.

To summarize the problems:
1) There is a spurious drkonqi crash message.
2) Drkonqi claims that there is no address to report bugs of kdeinit5.
3) I haven't found the packages with debugging symbols.

Best wishes,

Gábor

Backtrace:

Application: kdeinit5 (kdeinit5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fc5760d3780 (LWP 4547))]

Thread 3 (Thread 0x7fc56a1dc700 (LWP 4550)):
#0  0x7fc579ebdbd9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fc5783a5e46 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fc5783a5f6c in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fc57a24cd2b in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fc57a1f9d0b in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fc57a0490c6 in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7fc575690545 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7fc57a052c97 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7fc579db0fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#9  0x7fc579ec888f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7fc571856700 (LWP 4548)):
#0  0x7fc579ebdbd9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fc57aa6fcf7 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7fc57aa7191a in xcb_wait_for_event () from 
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7fc5721a1519 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7fc57a052c97 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fc579db0fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7fc579ec888f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7fc5760d3780 (LWP 4547)):
[KCrash Handler]
#6  0x7fc5632d44f4 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/ffmpegthumbs.so
#7  0x7fc5632d620a in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/ffmpegthumbs.so
#8  0x7fc5632d6359 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/ffmpegthumbs.so
#9  0x7fc5632d3793 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/ffmpegthumbs.so
#10 0x7fc57ae53e80 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
#11 0x7fc57ae54458 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
#12 0x7fc57ae54b30 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
#13 0x7fc57ae56041 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
#14 0x7fc575cdedf6 in KIO::SlaveBase::dispatch(int, QByteArray const&) () 
from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#15 0x7fc575cda196 in KIO::SlaveBase::dispatchLoop() () from 
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#16 0x7fc57ae5308d in kdemain () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
#17 0x56107a404e1c in ?? ()
#18 0x56107a405eea in ?? ()
#19 0x56107a4068fb in ?? ()
#20 0x56107a401645 in ?? ()
#21 0x7fc579df309b in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6
#22 0x56107a4022ca in _start ()
[Inferior 1 (process 4547) detached]


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

Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=hu:en_US:

Bug#917270: texlive-latex-extra-doc: Please add dtx files for dtxgallery

[Braun Gábor]

Package: texlive-latex-extra-doc
Version: 2018.20181214-1
Severity: normal

Dear Maintainer,

Open the dtxgallery document with 'texdoc dtxgallery'.
A PDF file opens, and on the very first page prominently lists four example dtx 
files
without any information how to open them:

single-source.dtx
conditional-code.dtx
rearrange.dtx
dtxgallery.dtx

Note that on the top of the second page, the document explicitly recommends
examining these dtx files directly, but the lack of any information where these 
are make it
very hard.  They don't seem to be included in the package, at least not in an 
obvious location:

$ dpkg -L texlive-latex-extra-doc | grep dtxgallery
/usr/share/doc/texlive-doc/latex/dtxgallery
/usr/share/doc/texlive-doc/latex/dtxgallery/README
/usr/share/doc/texlive-doc/latex/dtxgallery/conditional-code.pdf
/usr/share/doc/texlive-doc/latex/dtxgallery/dtxgallery.pdf
/usr/share/doc/texlive-doc/latex/dtxgallery/rearrange.pdf
/usr/share/doc/texlive-doc/latex/dtxgallery/single-source.pdf

To make dtxgallery useful please put the dtx files in the same directory as 
dtxgallery.pdf,
and make the names of the dtx files in dtxgallery.pdf a hyperlink to these 
files,
so that they can be easily opened by clicking on their names.

Best wishes,

Gábor

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

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

Versions of packages texlive-latex-extra-doc depends on:
ii  tex-common6.10
ii  texlive-base  2018.20181214-1

texlive-latex-extra-doc recommends no packages.

texlive-latex-extra-doc suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.19.2
ii  ucf   3.0038

Versions of packages tex-common suggests:
pn  debhelper  

Versions of packages texlive-latex-extra-doc is related to:
ii  tex-common6.10
ii  texlive-binaries  2018.20181104.49075-2

-- no debconf information

Bug#917167: systemd: 240 breaks kde (rakes ages to launch)

[Vincas Dargis]

On Sun, 23 Dec 2018 19:15:27 +0100 Michael Biebl  wrote:

For a (temporary) workaround you can create a file
/etc/security/limits.d/systemd.conf containing:

* hard nofile 524288


That did the trick, thanks!

Bug#917271: yamllint: requires module pkg_resources but does not depend on it

[Jack Henschel]

Package: yamllint
Version: 1.5.0-1
Severity: important
Tags: patch

Dear maintainer,

I just installed the `yamllint` package on a pretty fresh Debian Stretch
system. When running it for the first time the following error occured:

> yamllint etc/hiera.yaml
> Traceback (most recent call last):
>   File "/usr/bin/yamllint", line 6, in 
> from pkg_resources import load_entry_point
> ImportError: No module named 'pkg_resources'

Apparently the package requires the `pkg_resources` module, but the
package is missing the appropriate dependency.
From `/usr/bin/yamllint`:
> from pkg_resources import load_entry_point

The error was resolved after manually installing the
`python3-pkg-resources` package.

Please add the package `python3-pkg-resources` to the Depends-field of
`yamllint`.

Thanks!

Greetings
Jack



signature.asc
Description: OpenPGP digital signature

Bug#917261: linux-image-4.19.0-1-amd64: /dev/mapper symlink for dm-crypt volume containing / not created on system startup

[Tiziano Zito]

Hi!

I have the same issue. Not sure the problem is with the kernel package though, 
because even purging and/or reinstalling linux-image-4.18.0-3 fails (see 
below). Any suggestion which package may be responsible? The problem started 
after a dist-upgrade on Dec 24...

Thanks!
Tiziano

# aptitude purge linux-image-4.18.0-3-amd64
The following packages will be REMOVED:
 linux-image-4.18.0-3-amd64{p}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 258 MB will be freed.
Do you want to continue? [Y/n/?] Y
(Reading database ... 420270 files and directories currently installed.)
Removing linux-image-4.18.0-3-amd64 (4.18.20-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.19.0-1-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.19.0-1-amd64
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-4.18.0-3-amd64
/etc/kernel/postrm.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/CRYPT-ROOT'.
run-parts: /etc/kernel/postrm.d/zz-update-grub exited with return code 1
dpkg: error processing package linux-image-4.18.0-3-amd64 (--remove):
installed linux-image-4.18.0-3-amd64 package post-removal script subprocess 
returned error exit status 1
Errors were encountered while processing:
linux-image-4.18.0-3-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

# aptitude reinstall linux-image-4.18.0-3-amd64
The following packages will be REINSTALLED:
 linux-image-4.18.0-3-amd64
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
upgraded.
Need to get 0 B/45.7 MB of archives. After unpacking 0 B will be used.
(Reading database ... 416025 files and directories currently installed.)
Preparing to unpack .../linux-image-4.18.0-3-amd64_4.18.20-2_amd64.deb ...
Unpacking linux-image-4.18.0-3-amd64 (4.18.20-2) over (4.18.20-2) ...
Setting up linux-image-4.18.0-3-amd64 (4.18.20-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.18.0-3-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.18.0-3-amd64
/etc/kernel/postinst.d/dkms:
Error! Your kernel headers for kernel 4.18.0-3-amd64 cannot be found.
Please install the linux-headers-4.18.0-3-amd64 package,
or use the --kernelsourcedir option to tell DKMS where it's located
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.18.0-3-amd64
cryptsetup: ERROR: Couldn't resolve device /dev/mapper/CRYPT-ROOT
cryptsetup: WARNING: Couldn't determine root device
Warning: couldn't identify filesystem type for fsck hook, ignoring.
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/CRYPT-ROOT'.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
dpkg: error processing package linux-image-4.18.0-3-amd64 (--configure):
installed linux-image-4.18.0-3-amd64 package post-installation script 
subprocess returned error exit status 1
Errors were encountered while processing:
linux-image-4.18.0-3-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#917266: [debian-mysql] Bug#917266: default-libmysqlclient-dev: Uninstallable - depends on no longer built libmariadbclient-dev-compat

[Otto Kekäläinen]

Hello!

ti 25. jouluk. 2018 klo 10.06 Scott Kitterman (deb...@kitterman.com) kirjoitti:
> Severity: grave
> Justification: renders package unusable
>
>  no longer found.
>
> Since mariadb10.3 became the default this no longer works:
>
> #include 
>
> It has to be changed to:
>
> #include 
>
> You can experience this for yourself by rebuilding postfix, seeing it fail:
>
> gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE -DHAS_LDAP -DUSE_LDAP_SASL 
> -DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB -DHAS_MYSQL 
> -I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql -DHAS_SQLITE 
> -I/usr/include -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH 
> -I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS -I/usr/include 
> -DHAS_DEV_URANDOM -DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\" 
> -DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" 
> -DDEF_MANPAGE_DIR=\"/usr/share/man\" 
> -DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS 
> -DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g -O2 
> -I. -I../../include -DLINUX3 -c dict_ldap.c
> gcc -shared -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib/postfix -o 
> postfix-ldap.so dict_ldap.o -lldap -llber -L../../lib -L. -lpostfix-util 
> -lpostfix-global
> gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE -DHAS_LDAP -DUSE_LDAP_SASL 
> -DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB -DHAS_MYSQL 
> -I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql -DHAS_SQLITE 
> -I/usr/include -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH 
> -I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS -I/usr/include 
> -DHAS_DEV_URANDOM -DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\" 
> -DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" 
> -DDEF_MANPAGE_DIR=\"/usr/share/man\" 
> -DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS 
> -DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g -O2 
> -I. -I../../include -DLINUX3 -c dict_mysql.c
> dict_mysql.c:171:10: fatal error: mysql.h: No such file or directory
>  #include 
>   ^
> compilation terminated.
>
> And then changing src/global/dict_mysql.c line 171
>
> Alternately, I could update the include path, I guess, but isn't approximately
> the whol point of providing a generic default so that every package in
> Debian doesn't have to change when the default changes?

Yes, these #include mysql.h in Debian can be found via
https://codesearch.debian.net/search?q=%22mysql.h%22&perpkg=1

In mariadb-10.1 the mysql.h was shipped in package
libmariadbclient-dev at path /usr/include/mysql/mysql.h. The package
libmariadbclient-dev-compat does not provide any symlinks or anything
related to /usr/include

In mariadb-connector-c mysql.h was shipped in package libmariadb-dev
at path /usr/include/mariadb/mysql.h

In mariadb-10.3, which now includes libmariadb3 (and no
libmariadbclient18 anymore), so basically same as mariadb-connector-c,
and ships mysql.h in package libmariadb-dev at path
/usr/include/mariadb/mysql.h.

I've attached file listing from the relevant libmariadb* packages
across mariadb-10.1, -10.3 and mariadb-connector-c so it is easier for
you to review and suggest how to proceed.

I tested the cmake flags used in mariadb-connector-c to modify the
file layout (DINSTALL_LAYOUT:STRING=DEB -DPLUGINDIR_DEB=mariadb3
-DWITH_MYSQLCOMPAT=ON)
[1] but they did not have any effect.

I don't think there is anything I can do. Feel free to open a merge
request[2] on mariadb-10.3 if you have a vision how to add symlinks or
something to solve this.

I've CC'd a few upstream developers in case they care about how
existing programs using mysql.h can build using MariaDB in the future
and if they want to suggest what to do here. The upstream Debian
packages don't currently support being used as a drop-in replacement
for libmysqlclient18 and I don't think anybody ever actually tested
using libmariadb3 for it, nor is there hardly any documentation at
mariadb.com/kb/ about libmariadb3 usage and compilation examples.


[1] 
https://salsa.debian.org/mariadb-team/mariadb-connector-c/blob/master/debian/rules#L14-16
[2] https://wiki.debian.org/Teams/MySQL/patches
libmariadb3
drwxr-xr-x ./
drwxr-xr-x ./usr/
drwxr-xr-x ./usr/lib/
drwxr-xr-x ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- ./usr/lib/x86_64-linux-gnu/libmariadb.so.3
drwxr-xr-x ./usr/lib/x86_64-linux-gnu/mariadb19/
drwxr-xr-x ./usr/lib/x86_64-linux-gnu/mariadb19/plugin/
-rw-r--r-- ./usr/lib/x86_64-linux-gnu/mariadb19/plugin/client_ed25519.so
-rw-r--r-- ./usr/lib/x86_64-linux-gnu/mariadb19/plugin/dialog.so
-rw-r--r-- ./usr/lib/x86_64-linux-gnu/mariadb19/plugin/mysql_clear_password.so
-rw-r--r-- ./usr/lib/x86_64-linux-gnu/mariadb19/plugin/sha256_password.so
drwxr-xr-x ./usr/share/
drwxr-xr-x ./usr/share/doc/
drwxr-xr-x ./usr/share/doc/libmariadb3/
-rw-r--r-- ./usr/share/doc/libmariadb3/changelog.Debian.gz
-rw-r--r-- ./usr/share/doc/libmariadb3/copyright

libmariadbclient18
drwxr-xr-x ./
drwxr-xr-x ./usr/

Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Luca Boccassi]

On Tue, 25 Dec 2018 09:16:57 +0100 Sebastiaan Couwenberg  wrote:
> On 12/25/18 8:57 AM, Otto Kekäläinen wrote:
> > Can you please provide an actual pbuilder command or something I
can
> > copy-paste to reproduce the actual problem (and not just the
aptitude
> > symptom)?
> 
> Sure:
> 
>  sudo cowbuilder --create \
>  --distribution=sid \
>  --basepath=/var/cache/pbuilder/base-sid.cow
>  dget -u \
>   http://deb.debian.org/debian/pool/main/g/gdal/gdal_2.3.3+dfsg-1.dsc
>  cd gdal-2.3.3/
>  dch -nm "Test rebuild"
>  pdebuild --pbuilder cowbuilder -- \
>   --basepath /var/cache/pbuilder/base-sid.cow/
> 
> pbuilder will be unstable to install the build dependencies, causing
the
> configure target to disable MySQL support despite using the --with-
mysql
> option:
> 
>MySQL support: no
> 
> 
> Please also answer my questions:
> 
> > Isn't the appropriate fix to build libmariadbclient-dev-compat from
> > the mariadb-10.3 instead of 10.1? Aren't you now transitioning from
> > 10.1 to 10.3? And shouldn't mysql-defaults be updated for that too?
> 
> default-libmysqlclient-dev depends on libmariadbclient-dev-compat
which
> is built from the mariadb-10.1 source package.
> 
> libmariadbclient-dev-compat depends on libmariadbclient-dev (also
built
> from the mariadb-10.1 source package), which in turn depends on
> libmariadbclient18 (= 1:10.1.37-3).
> 
> As long as the 10.3 packages Conflict or Break 10.1 packages, the
> default-* packages cannot be installed along with the 10.3 packages,
as
> the default packages are depending on the 10.1 packages.
> 
> Kind Regards,
> 
> Bas

Hi,

I just encountered a similar issue, causes a build regression in
collectd [1].

The issue is that build-depending on default-libmysqlclient-dev causes
libmariadbclient-dev-compat from 10.1 to be installed instead of
libmariadb-dev-compat from 10.3, which means the mysql_config binary is
missing and the configure step of collectd thus fails.
Manually installing libmariadb-dev-compat, which causes
libmariadbclient-dev-compat to be removed, fixes the issue.

-- 
Kind regards,
Luca Boccassi

[1] 
https://buildd.debian.org/status/fetch.php?pkg=collectd&arch=amd64&ver=5.8.1-1.1&stamp=1545690583&raw=0

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

Bug#917241: libnss-unknown: Please provide more elaborate description in long description

[Petter Reinholdtsen]

[Ritesh Raj Sarraf]
> + .
> + This library is very useful in host <=> guest container build
> + environments, where shifting UIDs/GIDs result in a mismatch in
> + between

Did something fall out of this patch?  Could you perhaps also explain
_how_ it is very useful, in addition to explaining in what context it is
useful.

-- 
Happy hacking
Petter Reinholdtsen

Bug#915419: debdiff for 915692, 915419

[Luca Boccassi]

On Sat, 2018-12-22 at 22:34 +0100, Luca Boccassi wrote:
> Control: tags -1 pending
> 
> On Wed, 19 Dec 2018 16:39:17 +0100 Luca Boccassi 
> wrote:
> > Dear Maintainer,
> >  
> > In order to allow the DPDK 17.11 -> 18.11 transition to happen [1],
> > I
> > intend to upload a source NMU fixing 915692 and 915419 (debdiff
> > attached) either at the end of this week or at the beginning of the
> > next to DELAYED/1.
> >  
> > I hope this does not cause any troubles, and please let me know if
> 
> this
> > would be an issue, and/or if you prefer an alternative solution.
> >  
> > Thank you!
> >  
> > -- 
> > Kind regards,
> > Luca Boccassi
> >  
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916351
> 
> Dear Maintainers,
> 
> I have uploaded the aforementioned NMU to DELAYED/2 to allow for the
> DPDK transition to start on Monday. Please let me know if this is an
> issue and would like me to cancel it.
> 
> Thanks!

Hi,

Unfortunately a new version of mariadb was uploaded to unstable after
my last build test but before the upload got through DELAYED, so the
package does not build in unstable :-(

I have reported the issue with more details on the appropriate mariadb
bug [1]. I do not believe there is any action that should be taken on
collectd at the moment.

-- 
Kind regards,
Luca Boccassi

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

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

Bug#917075: [debian-mysql] Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Otto Kekäläinen]

I did this change yesterday but have not uploaded yet as I'd like to first
write an automated gitlab-ci.yml test in mariadb-10.3 to detect the problem
first.

https://salsa.debian.org/mariadb-team/mysql/commit/41b7e55f1c5a3cb93da2e2407230542cc9284222

Bug#880393: nmuing cyrus-sasl2

[Helmut Grohne]

Hi Ryan,

On Mon, Dec 24, 2018 at 03:48:19PM -0800, Ryan Tandy wrote:
> I don't see any conversation about it in the bugs, but that NMU doesn't seem
> to have happened, was there a reason?

The NMU went to delayed, but then Ondřej Surý did a maintainer upload
without including the fixes nor explaining why they shouldn't be used.
Since his (MU) version was higher than my (NMU) version, my upload was
rejected once it departed from delayed. Therefore this bug still affects
unstable despite having a solution. I'm unsure on how to best deal with
this non-communication and figured that I'd simply give up.

I'd appreciate if someone else could handle this. At least I dissected
the cause and provided a simple and backportable solution. Could you
move this forward?

Also given the simplicity of the fix, adding it to a stretch point
release would make a lot of sense.

Helmut

Bug#917242: libreoffice-common: ships svg files in folder for png files

[Rene Engelhard]

Hi,

On Mon, Dec 24, 2018 at 04:50:51PM +0100, Jonas Smedegaard wrote:
> I noticed /usr/share/icons/hicolor/512x512/apps contains svg files,
> seemingly all belonging to libreoffice.
> 
> Example: /usr/share/icons/hicolor/512x512/apps/libreoffice-calc.svg
>
> That directory is meant only for bitmap graphics.
> 
> Perhaps they were intended for /usr/share/icons/hicolor/scalable?

Those exist there, too. With differing md5sums

$ find /usr/share/icons/hicolor/ -name "libreoffice-calc.svg" | xargs md5sum
c0f1c7eeb64645c34c869c39c177ed80 
/usr/share/icons/hicolor/128x128/apps/libreoffice-calc.svg
e3d76d0f7a24929f0fe1b841079148af 
/usr/share/icons/hicolor/16x16/apps/libreoffice-calc.svg 
c0f1c7eeb64645c34c869c39c177ed80 
/usr/share/icons/hicolor/scalable/apps/libreoffice-calc.svg

599700e319c5ffbc84652f625eee4686 
/usr/share/icons/hicolor/512x512/apps/libreoffice-calc.svg
^^^
7a97cada5c70fb9e00529f355f699060 
/usr/share/icons/hicolor/64x64/apps/libreoffice-calc.svg
df5ad249017d59b8d2f687b97734c7af 
/usr/share/icons/hicolor/24x24/apps/libreoffice-calc.svg
d31e64c26e7ed0d5bc0942fe8c5e0de0 
/usr/share/icons/hicolor/22x22/apps/libreoffice-calc.svg
cea352b03f1121c92734741761c39a98 
/usr/share/icons/hicolor/48x48/apps/libreoffice-calc.svg
257b05b635fda23468a8b8d569b25b99 
/usr/share/icons/hicolor/256x256/apps/libreoffice-calc.svg
4ce0a74376d62a4cd4c857d3882bcac3 
/usr/share/icons/hicolor/32x32/apps/libreoffice-calc.svg

Regards,

Rene

Bug#917202: lm-sensors: Ability to install both libsensors4 and libsensors5?

[Luca Boccassi]

On Mon, 24 Dec 2018 01:33:08 +0100 Aurelien Jarno  wrote:
> control: reassign -1 collectd
> control: retitle -1 collectd should be updated for libsensors5
> control: severity -1 serious
> 
> On 2018-12-24 01:11, Xavier Guerrin wrote:
> > Package: lm-sensors
> > Version: 1:3.5.0-3
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > It does not seem possible to install both libsensors4 and
libsensors5 as
> > "apt install libsensors5" will remove libsensors4. This is
apparently due to
> > libsensors-config, which is marked as breaking and replacing
libsensors4.
> 
> True.
> 
> > Alas, this package does not effectively replace libsensors4 since
it no longer
> > provides libsensors.so.4. This has the side-effect of breaking
collectd's
> > "sensors" plugin, which relies on libsensors.so.4:
> >   $ dpkg -L collectd-core | grep sensors
> >   /usr/lib/collectd/sensors.so
> >   $ ldd /usr/lib/collectd/sensors.so
> >   linux-vdso.so.1 (0x7ffe949f2000)
> >   libsensors.so.4 => not found
> >   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
(0x7fc8b4c44000)
> >   /lib64/ld-linux-x86-64.so.2 (0x7fc8b4e21000)
> 
> This is clearly a bug of collectd which should be updated to use
> libsensors5. I am therefore reassigning the bug to this package.

Dear Maintainer,

collectd 5.8 fails to build with libsensors5 due to unnecessary checks
that have been removed in the upstream 5.8 branch [1].
Backporting that single patch fixes the build.

Given this will block the DPDK transition I'm looking after [2], unless
it's an issue I'll do a source NMU to DELAYED/1 once the other bug
affecting collectd from mariadb [3] is fixed. Let me know if this is an
issue. The debdiff is attached.

Thank you!

-- 
Kind regards,
Luca Boccassi

[1] https://github.com/collectd/collectd/pull/3013
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916351
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917075diff -Nru collectd-5.8.1/debian/changelog collectd-5.8.1/debian/changelog
--- collectd-5.8.1/debian/changelog	2018-12-19 15:52:36.0 +0100
+++ collectd-5.8.1/debian/changelog	2018-12-25 12:08:23.0 +0100
@@ -1,3 +1,12 @@
+collectd (5.8.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport removed_checks_for_upper_limit_of_SENSORS_API.patch from
+the upstream 5.8 release branch to fix build with libsensors5.
+(Closes: #917202)
+
+ -- Luca Boccassi   Tue, 25 Dec 2018 12:08:23 +0100
+
 collectd (5.8.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru collectd-5.8.1/debian/patches/removed_checks_for_upper_limit_of_SENSORS_API.patch collectd-5.8.1/debian/patches/removed_checks_for_upper_limit_of_SENSORS_API.patch
--- collectd-5.8.1/debian/patches/removed_checks_for_upper_limit_of_SENSORS_API.patch	1970-01-01 01:00:00.0 +0100
+++ collectd-5.8.1/debian/patches/removed_checks_for_upper_limit_of_SENSORS_API.patch	2018-12-25 12:07:43.0 +0100
@@ -0,0 +1,73 @@
+Author: Pavel Rochnyack 
+Origin: https://github.com/collectd/collectd/commit/d5a3c020d33cc33ee8049f54c7b4dffcd123bf83
+Forwarded: https://github.com/collectd/collectd/pull/3013
+Description: sensors: Removed checks for upper limit of SENSORS_API_VERSION
+ That makes no more sense after lm-sensors got new maintainers.
+--- a/src/sensors.c
 b/src/sensors.c
+@@ -149,7 +149,7 @@ typedef struct featurelist {
+ static char *conffile = SENSORS_CONF_PATH;
+ /* #endif SENSORS_API_VERSION < 0x400 */
+ 
+-#elif (SENSORS_API_VERSION >= 0x400) && (SENSORS_API_VERSION < 0x500)
++#elif (SENSORS_API_VERSION >= 0x400)
+ typedef struct featurelist {
+   const sensors_chip_name *chip;
+   const sensors_feature *feature;
+@@ -159,11 +159,6 @@ typedef struct featurelist {
+ 
+ static char *conffile = NULL;
+ static _Bool use_labels = 0;
+-/* #endif (SENSORS_API_VERSION >= 0x400) && (SENSORS_API_VERSION < 0x500) */
+-
+-#else /* if SENSORS_API_VERSION >= 0x500 */
+-#error "This version of libsensors is not supported yet. Please report this " \
+-	"as bug."
+ #endif
+ 
+ static featurelist_t *first_feature = NULL;
+@@ -223,7 +218,7 @@ static int sensors_config(const char *ke
+ if (IS_TRUE(value))
+   ignorelist_set_invert(sensor_list, 0);
+   }
+-#if (SENSORS_API_VERSION >= 0x400) && (SENSORS_API_VERSION < 0x500)
++#if (SENSORS_API_VERSION >= 0x400)
+   else if (strcasecmp(key, "UseLabels") == 0) {
+ use_labels = IS_TRUE(value) ? 1 : 0;
+   }
+@@ -353,7 +348,7 @@ static int sensors_load_conf(void) {
+   }   /* while sensors_get_detected_chips */
+ /* #endif SENSORS_API_VERSION < 0x400 */
+ 
+-#elif (SENSORS_API_VERSION >= 0x400) && (SENSORS_API_VERSION < 0x500)
++#elif (SENSORS_API_VERSION >= 0x400)
+   chip_num = 0;
+   while ((chip = sensors_get_detected_chips(NULL, &chip_num)) != NULL) {
+ const sensors_feature *feature;
+@@ -410,7 +405,7 @@ static int sensors_load_conf(void) {
+   } /* while (subfeature) */
+ }   /* while (feature) */
+   } /* while (chip) */

Bug#917270: texlive-latex-extra-doc: Please add dtx files for dtxgallery

[Hilmar Preuße]

On 25.12.18 10:38, Braun Gábor wrote:

Hi Norbert,

> Open the dtxgallery document with 'texdoc dtxgallery'.
> A PDF file opens, and on the very first page prominently lists four
> example dtx files without any information how to open them:
> 
> single-source.dtx
> conditional-code.dtx
> rearrange.dtx
> dtxgallery.dtx
> 
> Note that on the top of the second page, the document explicitly
> recommends examining these dtx files directly, but the lack of any
> information where these are make it very hard.  They don't seem to be
> included in the package, at least not in an obvious location:
> 
This is clearly an upstream bug (packager of TeX Live). Norbert: would
you be so kind to have a look at this?

Hilmar
-- 
#206401 http://counter.li.org

Bug#916745: web2py2po and po2web2py fail to work ("convertpy() got an unexpected keyword argument 'duplicatestyle'" and "'ascii' codec can't encode character")

[Petter Reinholdtsen]

I pulled the patch from the upstream pull request and created a
d/patches/ entry for it.  Please included in Debian to fix the web2py
support.  The test code can be skipped if you want to limit the size of
the patch.

-- 
Happy hacking
Petter Reinholdtsen
diff --git a/debian/patches/series b/debian/patches/series
index 290858707..9fee92537 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@ storage_bzr
 poterminology_defaultstopfile
 sphinx-intersphinx.patch
 af-pootle.patch
+web2py-fixes.patch
diff --git a/debian/patches/web2py-fixes.patch b/debian/patches/web2py-fixes.patch
new file mode 100644
index 0..7e5a51547
--- /dev/null
+++ b/debian/patches/web2py-fixes.patch
@@ -0,0 +1,231 @@
+Description: Fix web2py support
+Author: Vinyl Darkscratch
+Origin: https://github.com/translate/translate/pull/3838
+Bug: https://github.com/translate/translate/issues/3254
+Bug-Debian: https://bugs.debian.org/916745
+Forwarded: not-needed
+Reviewed-By: 
+Last-Update: 2018-12-18
+
+diff --git a/translate/convert/po2web2py.py b/translate/convert/po2web2py.py
+index 07d61b358..c31f57fde 100755
+--- a/translate/convert/po2web2py.py
 b/translate/convert/po2web2py.py
+@@ -1,3 +1,4 @@
++#!/usr/bin/env python
+ # -*- coding: utf-8 -*-
+ #
+ # Copyright 2009-2010 Zuza Software Foundation
+@@ -24,7 +25,9 @@ See: http://docs.translatehouse.org/projects/translate-toolkit/en/latest/command
+ for examples and usage instructions.
+ """
+ 
+-from io import BytesIO
++import sys
++
++from io import StringIO
+ 
+ from translate.convert import convert
+ from translate.storage import factory
+@@ -36,7 +39,7 @@ class po2pydict(object):
+ return
+ 
+ def convertstore(self, inputstore, includefuzzy):
+-str_obj = BytesIO()
++str_obj = StringIO()
+ 
+ mydict = dict()
+ for unit in inputstore.units:
+@@ -49,29 +52,40 @@ class po2pydict(object):
+ # The older convention is to prefix with "*** ":
+ #mydict[unit.source] = '*** ' + unit.source
+ 
+-str_obj.write('{\n')
+-for source_str in mydict:
+-str_obj.write("%s:%s,\n" % (repr(str(source_str)), repr(str(mydict[source_str]
+-str_obj.write('}\n')
++str_obj.write(u'# -*- coding: utf-8 -*-\n')
++str_obj.write(u'{\n')
++for source_str, trans_str in sorted(mydict.items()):
++if sys.version_info[0] == 2:
++source_str = source_str.encode('utf-8')
++trans_str = trans_str.encode('utf-8')
++str_obj.write(u"%s: %s,\n" % (repr(source_str), repr(trans_str)))
++str_obj.write(u'}\n')
+ str_obj.seek(0)
+ return str_obj
+ 
+ 
+ def convertpy(inputfile, outputfile, templatefile=None, includefuzzy=False,
+-  outputthreshold=None):
++  outputthreshold=None, **kwargs):
+ inputstore = factory.getobject(inputfile)
+ 
+ if not convert.should_output_store(inputstore, outputthreshold):
+-return False
++return 0
+ 
+ convertor = po2pydict()
+ outputstring = convertor.convertstore(inputstore, includefuzzy)
+-outputfile.write(outputstring.read())
++
++if sys.version_info[0] == 2:
++outputfile.write(outputstring.read())
++elif sys.version_info[0] > 2:
++outputfile.write(bytes(outputstring.read(), 'utf-8'))
+ return 1
+ 
+ 
+ def main(argv=None):
+-formats = {("po", "py"): ("py", convertpy), ("po"): ("py", convertpy)}
++formats = {
++("po", "py"): ("py", convertpy),
++("po", None): ("py", convertpy)
++}
+ parser = convert.ConvertOptionParser(formats, usetemplates=False, description=__doc__)
+ parser.add_threshold_option()
+ parser.add_fuzzy_option()
+diff --git a/translate/convert/test_po2web2py.py b/translate/convert/test_po2web2py.py
+new file mode 100644
+index 0..7906a1230
+--- /dev/null
 b/translate/convert/test_po2web2py.py
+@@ -0,0 +1,55 @@
++# -*- coding: utf-8 -*-
++import sys
++
++from translate.convert import po2web2py
++from translate.misc import wStringIO
++from translate.storage import po
++
++
++class TestPO2WEB2PY(object):
++
++def po2web2py(self, po_source):
++"""helper that converts po source to web2py source without requiring files"""
++input_file = wStringIO.StringIO(po_source)
++input_po = po.pofile(input_file)
++convertor = po2web2py.po2pydict()
++output_web2py = convertor.convertstore(input_po, False)
++return output_web2py.read()
++
++def test_basic(self):
++"""test a basic po to web2py conversion"""
++input_po = '''#: .text
++msgid "A simple string"
++msgstr "Du texte simple"
++'''
++expected_web2py = '''# -*- coding: utf-8 -*-
++{
++'A simple string': 'Du texte simple',
++}
++'''
++web2py_out = self.po2web2py(input_po)
++assert web2py_out == expected_web2py
++
++def test_ordering_serialize(self):
++input_p

Bug#916796: IEEEfull.bib: cannot be read in encoding 'utf8' by biber

[Hilmar Preuße]

On 25.12.18 03:00, Damir Islamov wrote:

Hi Damir,

> IEEEfull.bib wirks fine with bibtex.
> I will try to contact TeX group.
> 
So, I'll mark that bug for me as "submitter cares about the issue".
Please be so kind to call back, once you get an answer.

Many thanks!
  Hilmar
-- 
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#917272: Kernel module failed to load on 4.19 kernel.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: firmware-amd-graphics
Version: 20180825+dfsg-1

For some reason, from 4.19.0 onward, the kernel refuses to load the AMD 
modules. The screen defaults to 80*25 text mode and "startx" does not work.
Here is what I have tried:
linux-image-4.19.0-trunk-amd64-unsigned/now 4.19.5-1~exp1 amd64: WORKS
linux-image-4.19.0-1-amd64-unsigned/unstable 4.19.12-1 amd64: DOES NOT WORK
linux-image-4.20.0-trunk-amd64-unsigned/experimental 4.20-1~exp1 amd64: DOES 
NOT WORK ("dmesg" log attached)
It does not look like the kernel itself is the problem (as 4.19-trunk works but 
4.19 does not), so the problem is the firmware.
--
"And in the naked light, I saw ten thousand people, maybe more. People \
talking without speaking, people hearing without listening. People writ\
ing songs that voices never shared, no one dared disturb the sound of s\
ilence." --MA Bo'yong
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAGBQJcIg5HAAoJENi1YDlFXXQfqRAH/3NGXqLXLCWWOEAkRkHn
RXCYbILbBYqY9G1PTadc4ycce828Z9uwRytKkQ3C7rvulIjcYA6SD5Zv7Yl6
g9yhb0+ZW6gedIV86bGvQpwgY2NWyvDtm1FL+GUrEcrNMT9qJD1W4uQ2s+P9
YZCdEWcvBaj/mYuqLzHG9yA/2Kfv7BFjULbhq3+PDfBKiOGZdG3ufHd6NEP5
m7QN/PXV2F6K6BPQ/uGragb0/QHFUE6pyeCynh4rbDixMwe5Fb2mfRcDNTDg
J8GUH8J0CkLaqADVZK6zzrDiAy+MqlVK3zTSx3EBK6bDc8S9CNOgvXt34XRh
KwceEhcEsZpqKguUw3qlsQg=
=cy56
-END PGP SIGNATURE-



dmesg.0
Description: Binary data


dmesg.0.sig
Description: PGP signature


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#917273: overwritting files from libservlet2.5-java

[Eduard Bloch]

Package: libel-api-java
Version: 3.0.0-1
Severity: grave

The usual story, not installable, breaks upgrade.
Please resolve this conflict:

Unpacking libel-api-java (3.0.0-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libel-api-java_3.0.0-1_all.deb (--unpack):
 trying to overwrite 
'/usr/share/maven-repo/javax/el/el-api/debian/el-api-debian.pom', which is also 
in package libservlet2.5-java 6.0.45+dfsg-1
Errors were encountered while processing:
 /var/cache/apt/archives/libel-api-java_3.0.0-1_all.deb

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

-- 
"Lassen Sie sich 'Sklaventreiber' auf die Stirn tätowieren. Das ist
ehrlich, da wissen wir alle woran wir sind".
-- Volker Pispers

Bug#916231: Including sys/ioctl.h helps

[Sergei Golovan]

Hey Ralf,

Including sys/ioctl.h into ossp.h doesn't help as it is included into
osspd.c too late (sys/socket.h already did harm by undefining IOC_IN
and IOC_OUT).

But including sys/ioctl.h directly into osspd.c before sys/socket.h
works. Here is a possible patch:

--- a/osspd.c
+++ b/osspd.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Hopefully, it won't cause damage for other architectures.

Cheers!
-- 
Sergei Golovan

Bug#917075: [debian-mysql] Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Luca Boccassi]

On Tue, 25 Dec 2018 12:51:40 +0200 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
 wrote:
> I did this change yesterday but have not uploaded yet as I'd like to
first
> write an automated gitlab-ci.yml test in mariadb-10.3 to detect the
problem
> first.
> 
> https://salsa.debian.org/mariadb-team/mysql/commit/41b7e55f1c5a3cb93d
a2e2407230542cc9284222

Hi,

Thanks for the update. Do you happen to have a rough ETA? Rebuilding
collectd is required for the DPDK transition [1] that I'm looking after
to progress.

Thank you!

-- 
Kind regards,
Luca Boccassi

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

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

Bug#917274: task-german: depends on transitional dummy package aspell-de-alt (should be aspell-de-1901)

[Jonas Smedegaard]

Package: task-german
Version: 1:2-31
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package task-german depends on aspell-de-alt, which describes itself as
a "dummy transitional package" which can be safely removed.

task-german should instead depend (directly) on aspell-de-1901.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwiFykACgkQLHwxRsGg
ASEYuRAArc4n/jFb525qH2mqu8Q8zbIZt323/jW7kkRuWz2OmXv8ZLuSuNXg+vLK
K8M+HLi3UQB54v9Wh7JgQ1QWFRo/jobgwRmBWT+l+Jv2HAfwrKFABkjvcEBE70VG
Ggo7Fi0I++y1BD37FQudiWviTdqLuYnfxCLWCM0EaTkhxpREiIe5pNfspuu1n9mU
fwvTdVhUAB2aGXXjVlx97tsOZSx3FrqIm3W3fbIJF/gE+Nl52ceNsC5BmoJaPYbJ
HWgwruWKqa7+kBcUs0+FMCHLqLAluJPVnUdViRWTUHdeMnTs6wqIZXt6mbX56rjD
TKcLu1VLjUHmxWKdmi3Py8lsV/2nLajvDncWdaLQN6UEwGhuxk4+9DbOjP65vtEv
Rnvv0ufb3zwmg9gnagfXDU1KxFpK//rCtj33aLVK2ttyESKy8x4ufyonPYXHQsdt
7t0606H7QQBytzun8fmdmoqx8SaNcYLDtytL7A8BI+alhejKUZW/+d8v1NyQ8W7z
RrUInUe1bWjzfpcy2HXewZevFpFbI6VIjiFCv0opKOJmKPabnsrAH192sz0cWJhO
bC0E1iBW/EkFf6Zghs/KUR90w0PplAfkk+XGDbzX2CWPvGdW6OADvA8AUdTMl1Fx
kOaBV8k6zMTn3sSdkfom0KCafKSH46NVVgXsuMBm/XFFQuGNyDA=
=JVoX
-END PGP SIGNATURE-

Bug#917250: RFS: dwarves/1.12-1

[Adam Borowski]

On Mon, Dec 24, 2018 at 06:49:34PM +0100, Domenico Andreoli wrote:
> I'm looking for a sponsor for this package:

Hi!  I assume you have a problem with your gpg key.

> * Package name: dwarves-dfsg
>   Version : 1.12-1

> dwarves-dfsg (1.12-1) unstable; urgency=medium
> 
>   [ Domenico Andreoli ]
>   * New upstram release. Closes: #908563, #779809, #693096,
>   * Migrate to salsa.d.o and enable CI. Closes: #908564.
>   * Migrate to DEP-14.
>   * Drop patch DW_TAG_mutable_type (merged upstream).
>   * Refresh patch no_shared_no_ebl.
>   * Improve package description. Closes: #914527.
>   * Add test executing pahole on itself.
>   * Set debhelper compatibility level to 10.
>   * Start using dh_strip_nondeterminism.
> 
>   [ Helmut Grohne ]
>   * Let dh_auto_configure pass cross flags to cmake. Closes: #903506.

I have no complaints other than what lintian says (yet?), but with so many
warnings that are trivially fixable it'd be better to give it at least some
heed.  Improper debhelper versioning hurts backports, using a ssh URL for
VCS- breaks QA pages, etc.

On the other hand, if you insist because of wanting the new release in while
you're not capable of caring for less important matters, please say so --
these are only warnings rather than show-stoppers.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#917275: RM: racket [s390x] -- NBS; broken for 9 months

[David Bremner]

Package: ftp.debian.org
Severity: normal

Despite upstream's best efforts, we've not been able to get racket
working again on s390x after 6.12 broke it. At this point buster will
most likely have to release without s390x support for racket.

Bug#917276: mysql-defaults and MariaDB 10.3

[Otto Kekäläinen]

Source: mysql-defaults
Version: 1.0.5
Severity: serious
Justification: makes the package in question unusable or mostly so

The package has been updated to depend on Mariadb 10.3, which is
currently available only in Debian unstable. This serious bug report
is done to prevent mysql-defaults from entering Debian testing before
mariadb-10.3 has done so.

Bug#917277: epstool: incorrect bounding box calculated

[David Bremner]

Package: epstool
Version: 3.09-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

epstool calculates a very wide bounding box for the attached eps
file. The result is so wide that TeX cannot include it, which breaks
the sketch build. It would be great if epstool could be fixed so that
I can unbreak sketch.


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

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

Versions of packages epstool depends on:
ii  ghostscript  9.26~dfsg-1
ii  libc62.28-2

epstool recommends no packages.

epstool suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlwiJQcACgkQ8gKXHaSn
nizRvwv+IsSn/eyBudkFuL0UNsAz6l1lq69IZePHjIOEeJJNpdgsed/I31uduBGk
q/pvIBhcgSjwuIdBZJMz6iUc2s+6hBNSf5dHuykrNxrRRdANg2g8Iacy1nv6OmxA
qNtfcgple5juCAM9vc8LyEX5DIwVBoeFIIL+fdeG/OdQsaLecQ7+b5hs9gM9A0e7
wAmXj8QuCkBftpoL49EfPPWjL/QC6G3bWaO8BiUXS5gOavsj793dOkYt/+jIrH/E
Toc4zHJsl5vK4gl7MApSs/G/5ETKtGblY0m/50dykW258ThbISNZRqdxiN4d4mj2
yjqz84mYc6u7AjntshyruSH0xy2lBSxJCyuzYLYXt83+dNTludHrVkgs3ezxg/LK
GzJBP3xyWRUafte1NShXpS8BGp62+kHH+jB8235FHYPM3xilLG1PoN1PJ19xptF4
ir5MwlE8NYd4KgD1Mrdg5/qJeuMEvSoliVEXIriIgoYnE0bkNSNL3gX0yY8FH5L8
s3fLs8VY
=8EgG
-END PGP SIGNATURE-


input.eps.xz
Description: application/xz

Bug#917250: RFS: dwarves/1.12-1

[Domenico Andreoli]

On Tue, Dec 25, 2018 at 12:59:20PM +0100, Adam Borowski wrote:
> On Mon, Dec 24, 2018 at 06:49:34PM +0100, Domenico Andreoli wrote:
> > I'm looking for a sponsor for this package:
> 
> Hi!  I assume you have a problem with your gpg key.

Hi Adam, Merry Christmas!

Indeed my old 1024 bit key has been dropped some time ago and the new
one has not enough signatures. And I've been very busy elsewhere in
the meanwhile :)

> > * Package name: dwarves-dfsg
> >   Version : 1.12-1
> 
> > dwarves-dfsg (1.12-1) unstable; urgency=medium
> > 
> >   [ Domenico Andreoli ]
> >   * New upstram release. Closes: #908563, #779809, #693096,
> >   * Migrate to salsa.d.o and enable CI. Closes: #908564.
> >   * Migrate to DEP-14.
> >   * Drop patch DW_TAG_mutable_type (merged upstream).
> >   * Refresh patch no_shared_no_ebl.
> >   * Improve package description. Closes: #914527.
> >   * Add test executing pahole on itself.
> >   * Set debhelper compatibility level to 10.
> >   * Start using dh_strip_nondeterminism.
> > 
> >   [ Helmut Grohne ]
> >   * Let dh_auto_configure pass cross flags to cmake. Closes: #903506.
> 
> I have no complaints other than what lintian says (yet?), but with so many
> warnings that are trivially fixable it'd be better to give it at least some
> heed.  Improper debhelper versioning hurts backports, using a ssh URL for
> VCS- breaks QA pages, etc.

my intention is to address as many as possible but I am not the fastest
bullet on the market and it may take some more time.

> On the other hand, if you insist because of wanting the new release in while
> you're not capable of caring for less important matters, please say so --
> these are only warnings rather than show-stoppers.

OTOH we are not far from the freeze and would not dislike to have a
first push, just to be sure Buster get a [dr]ecent version or that we
catch any real blocker earlier.

Thanks for your support.

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#917241: libnss-unknown: Please provide more elaborate description in long description

[Ritesh Raj Sarraf]

On Tue, 2018-12-25 at 11:37 +0100, Petter Reinholdtsen wrote:
> [Ritesh Raj Sarraf]
> > + .
> > + This library is very useful in host <=> guest container build
> > + environments, where shifting UIDs/GIDs result in a mismatch in
> > + between
> 
> Did something fall out of this patch?  Could you perhaps also explain
> _how_ it is very useful, in addition to explaining in what context it
> is
> useful.

As I mentioned earlier, it is useful in an environment where you are
building packages in a containerized environment. In my case, the guest
environment is Docker. The host environment has Jenkins.

The library is useful if an admin shifts uid/gid ranges on the host,
resulting in a mismatch between the uids on the host and the guest.

AFAICS, this is mostly a problem with packages which are picky about
the uid mappings. Like, dbus, glib, systemd. If you are not building
such packages in a container environment (and your home/container
uids/gids are not shifted), you will not usually see this problem.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#863675: [debian-mysql] Bug#863675: libmariadbd-dev: fails to upgrade from 'sid' - trying to overwrite /usr/bin/mysql_config

[Otto Kekäläinen]

I made this extension to the gitlab-ci.yml file to be able to
automatically test for issues like this in the future:
https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/0ec004b4e4fc7c98a7b16cbe1a821be12ace1110

Ideally it would actually also attempt to build something first with
MySQL and then with MariaDB and verify it actually works, but I don't
know any good example to do it with.

Bug#917143: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: COREDUMP

[Bernhard Übelacker]

Dear Maintainer,
just tried to get some more information out of the crash.

It was not showing up with t-coffee 12 compiled in testing.
Just with switching to unstable and recompiling t-coffee
the crash manifested when
building libbio-tools-run-alignment-tcoffee-perl-1.7.4.

Unfortunately the signal is 'eaten' and therefore no
core file is generated.
With a modification adding a call to gdb I was able to get one.

Below is the backtrace of the first failing pid.
Some more information is in the attached file describing how
the information was collected.

It looks like the static array name_list is accessed beyond the
initilialized memory.

Kind regards,
Bernhard


$ gdb -q -ex 'set pagination off' -ex 'set width 0' -ex 'directory 
/home/benutzer/source/t-coffee/try2/t-coffee-12.00.7fb08c2/t_coffee_source' 
/usr/bin/t_coffee --core ./core.3995
Reading symbols from /usr/bin/t_coffee...Reading symbols from 
/usr/lib/debug/.build-id/26/7314cbd87aae405b78889c1e3af85806aea901.debug...done.
done.
[New LWP 3995]
Core was generated by `/usr/bin/t_coffee'.
#0  0x7fe6b33eb7f7 in __GI___waitpid (pid=4065, 
stat_loc=stat_loc@entry=0x7ffe74a7b488, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:30
30  ../sysdeps/unix/sysv/linux/waitpid.c: Datei oder Verzeichnis nicht 
gefunden.
Source directories searched: 
/home/benutzer/source/t-coffee/try2/t-coffee-12.00.7fb08c2/t_coffee_source:$cdir:$cwd
(gdb) bt
#0  0x7fe6b33eb7f7 in __GI___waitpid (pid=4065, 
stat_loc=stat_loc@entry=0x7ffe74a7b488, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x7fe6b336980f in do_system (line=) at 
../sysdeps/posix/system.c:149
#2  0x55f262eef2b0 in error_exit (exit_code=11) at util_lib/util.c:10008
#3  
#4  0x55f262ebb84d in decode_name (name=name@entry=0x55f26537f1f0 
"TCTAG_53775_4", mode=mode@entry=2) at util_lib/reformat.c:14644
#5  0x55f262ebbbdd in translate_name (name=0x55f26537f1f0 "TCTAG_53775_4") 
at util_lib/reformat.c:14575
#6  0x55f262ebd1da in get_fasta_sequence (fname=, 
comment_out=0x0) at util_lib/reformat.c:5304
#7  0x55f262ebe7b7 in main_read_aln (name=name@entry=0x55f265366250 
"/var/tmp/tco/tcoifo4u0ng3972//11383988396", A=0x55f26538bf90, A@entry=0x0) at 
util_lib/reformat.c:1532
#8  0x55f262f28db1 in aln_file2constraint_list 
(alname=alname@entry=0x55f265366250 
"/var/tmp/tco/tcoifo4u0ng3972//11383988396", CL=CL@entry=0x55f2652de520, 
weight_mode=weight_mode@entry=0x55f265363858 "sim") at 
util_lib/util_constraints_list.c:4304
#9  0x55f262f3decf in read_constraint_list (CL=0x55f2652de520, 
in_fname=, in_mode=in_mode@entry=0x55f262f582fc "aln", 
mem_mode=mem_mode@entry=0x55f262f6702f "disk", 
weight_mode=weight_mode@entry=0x55f265363858 "sim") at 
util_lib/util_constraints_list.c:2368
#10 0x55f262f3dfaa in retrieve_lib_job (job=0x55f2635cb990) at 
util_lib/util_constraints_list.c:473
#11 0x55f262f20bb5 in fork_subset_produce_list (CL=CL@entry=0x55f2652de520, 
method=method@entry=0x55f263617d71 "clustalw_pair", job=0x55f2635cb990, 
job@entry=0x55f263ab2f00, nproc=, local_stderr=0x55f2634f9bd0, 
mem_mode=0x55f2634f9bd0 "\204,\255", , 
weight=, S=0x55f263617d71) at 
util_lib/util_constraints_list.c:177
#12 0x55f262f3d1bf in produce_list (CL=CL@entry=0x55f2652de520, 
S=, method=method@entry=0x55f263617d71 "clustalw_pair", 
weight=weight@entry=0x55f2639d4020 "default", 
mem_mode=mem_mode@entry=0x55f2635cfbc0 "mem") at 
util_lib/util_constraints_list.c:94
#13 0x55f262f3dc70 in read_constraint_list (CL=CL@entry=0x55f2652de520, 
in_fname=, in_mode=in_mode@entry=0x0, 
mem_mode=mem_mode@entry=0x55f2635cfbc0 "mem", 
weight_mode=weight_mode@entry=0x55f2639d4020 "default") at 
util_lib/util_constraints_list.c:2332
#14 0x55f262f3e253 in fork_read_n_constraint_list (fname=0x55f2636139e0, 
n_list=, in_mode=0x0, mem_mode=0x55f2635cfbc0 "mem", 
weight_mode=0x55f2639d4020 "default", type=, 
local_stderr=0x55f2634f9bd0, CL=0x55f2652de520, seq_source=0x55f2639a9560 
"ANY", nproc=8) at util_lib/util_constraints_list.c:2218
#15 0x55f262f3e812 in read_n_constraint_list (fname=0x55f2636139e0, 
n_list=4, in_mode=0x0, mem_mode=0x55f2635cfbc0 "mem", 
weight_mode=0x55f2639d4020 "default", type=0x55f2635c74a0 "", 
local_stderr=0x55f2634f9bd0, CL=0x55f2652de520, seq_source=0x55f2639a9560 
"ANY") at util_lib/util_constraints_list.c:2141
#16 0x55f262e697f0 in batch_main (argc=, argv=) at t_coffee_lib/t_coffee.c:4942
#17 0x55f262d905ad in main (argc=, argv=) at 
t_coffee_lib/t_coffee.c:179


#4  0x55f262ebb84d in decode_name (name=name@entry=0x55f26537f1f0 
"TCTAG_53775_4", mode=mode@entry=2) at util_lib/reformat.c:14644
14644 return name_list[i-1][0];

Bug#917143: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: COREDUMP

[Bernhard Übelacker]

Sorry, missed the file.

# buster amd64 qemu VM

apt update
apt dist-upgrade


apt install systemd-coredump fakeroot mc gdb htop dpkg-dev devscripts quilt
apt build-dep libbio-tools-run-alignment-tcoffee-perl
apt build-dep t-coffee


wget 
http://ftp.de.debian.org/debian/pool/main/t/t-coffee/t-coffee_12.00.7fb08c2-1_amd64.deb
dpkg -i t-coffee_12.00.7fb08c2-1_amd64.deb


mkdir source/libbio-tools-run-alignment-tcoffee-perl/orig -p
cdsource/libbio-tools-run-alignment-tcoffee-perl/orig
apt source libbio-tools-run-alignment-tcoffee-perl
cd


mkdir source/t-coffee/orig -p
cdsource/t-coffee/orig
dget 
http://deb.debian.org/debian/pool/main/t/t-coffee/t-coffee_12.00.7fb08c2-1.dsc
cd



cd source/t-coffee
cp orig try1 -a
cd try1/t-coffee-12.00.7fb08c2
# add gdb call
dpkg-buildpackage

dpkg -i /home/benutzer/source/t-coffee/try1/t-coffee_12.00.7fb08c2-1_amd64.deb
dpkg -i 
/home/benutzer/source/t-coffee/try1/t-coffee-dbgsym_12.00.7fb08c2-1_amd64.deb




cd source/libbio-tools-run-alignment-tcoffee-perl
cp orig try1 -a
cd try1/libbio-tools-run-alignment-tcoffee-perl-1.7.4/
dpkg-buildpackage -b

-> No crash




##


# switch to unstable



apt update
apt dist-upgrade



cd source/t-coffee
cp orig try2 -a
cd try2/t-coffee-12.00.7fb08c2

cat < debian/patches/-call-gdb-on-signal.patch
Description: -call-gdb-on-signal.patch

Index: t-coffee-12.00.7fb08c2/t_coffee_source/util_lib/util.c
===
--- t-coffee-12.00.7fb08c2.orig/t_coffee_source/util_lib/util.c
+++ t-coffee-12.00.7fb08c2/t_coffee_source/util_lib/util.c
@@ -10002,6 +10002,11 @@ void error_exit (int exit_code)
  {
lock (getpid(), LERROR, LSET, "%d -- ERROR: COREDUMP: %s %s 
(%s)\n",getpid(), PROGRAM, VERSION, BUILD_INFO );
global_exit_signal=exit_code;
+   {
+  char buf[200];
+  sprintf(buf, "gdb -q -n -batch -ex 'generate-core-file' -ex 'info 
thread' -ex 'info reg' -ex 'thread apply all bt full' -ex 'info share' -ex 
'detach' -ex 'quit' --pid %d", getpid());
+  system(buf);
+   }
myexit (exit_code);
  }
 
EOF

echo -call-gdb-on-signal.patch >> debian/patches/series


dpkg-buildpackage

dpkg -i /home/benutzer/source/t-coffee/try2/t-coffee_12.00.7fb08c2-1_amd64.deb
dpkg -i 
/home/benutzer/source/t-coffee/try2/t-coffee-dbgsym_12.00.7fb08c2-1_amd64.deb




cd source/libbio-tools-run-alignment-tcoffee-perl
cp orig try2 -a
cd try2/libbio-tools-run-alignment-tcoffee-perl-1.7.4/
dpkg-buildpackage -b


$ find -iname "*core*"
./core.3995
./core.3996
./core.3994
./core.4000




$ gdb -q -ex 'set pagination off' -ex 'set width 0' -ex 'directory 
/home/benutzer/source/t-coffee/try2/t-coffee-12.00.7fb08c2/t_coffee_source' 
/usr/bin/t_coffee --core ./core.3995
Reading symbols from /usr/bin/t_coffee...Reading symbols from 
/usr/lib/debug/.build-id/26/7314cbd87aae405b78889c1e3af85806aea901.debug...done.
done.
[New LWP 3995]
Core was generated by `/usr/bin/t_coffee'.
#0  0x7fe6b33eb7f7 in __GI___waitpid (pid=4065, 
stat_loc=stat_loc@entry=0x7ffe74a7b488, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:30
30  ../sysdeps/unix/sysv/linux/waitpid.c: Datei oder Verzeichnis nicht 
gefunden.
Source directories searched: 
/home/benutzer/source/t-coffee/try2/t-coffee-12.00.7fb08c2/t_coffee_source:$cdir:$cwd
(gdb) bt
#0  0x7fe6b33eb7f7 in __GI___waitpid (pid=4065, 
stat_loc=stat_loc@entry=0x7ffe74a7b488, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x7fe6b336980f in do_system (line=) at 
../sysdeps/posix/system.c:149
#2  0x55f262eef2b0 in error_exit (exit_code=11) at util_lib/util.c:10008
#3  
#4  0x55f262ebb84d in decode_name (name=name@entry=0x55f26537f1f0 
"TCTAG_53775_4", mode=mode@entry=2) at util_lib/reformat.c:14644
#5  0x55f262ebbbdd in translate_name (name=0x55f26537f1f0 "TCTAG_53775_4") 
at util_lib/reformat.c:14575
#6  0x55f262ebd1da in get_fasta_sequence (fname=, 
comment_out=0x0) at util_lib/reformat.c:5304
#7  0x55f262ebe7b7 in main_read_aln (name=name@entry=0x55f265366250 
"/var/tmp/tco/tcoifo4u0ng3972//11383988396", A=0x55f26538bf90, A@entry=0x0) at 
util_lib/reformat.c:1532
#8  0x55f262f28db1 in aln_file2constraint_list 
(alname=alname@entry=0x55f265366250 
"/var/tmp/tco/tcoifo4u0ng3972//11383988396", CL=CL@entry=0x55f2652de520, 
weight_mode=weight_mode@entry=0x55f265363858 "sim") at 
util_lib/util_constraints_list.c:4304
#9  0x55f262f3decf in read_constraint_list (CL=0x55f2652de520, 
in_fname=, in_mode=in_mode@entry=0x55f262f582fc "aln", 
mem_mode=mem_mode@entry=0x55f262f6702f "disk", 
weight_mode=weight_mode@entry=0x55f265363858 "sim") at 
util_lib/util_constraints_list.c:2368
#10 0x55f262f3dfaa in retrieve_lib_job (job=0x55f2635cb990) at 
util_lib/util_constraints_list.c:473
#11 0x55f262f20bb5 in fork_subset_produce_list (CL=CL@entry=0x55f2652de520, 
method=method@entry=0x55f263617d71 "clustalw_pair", job=0x55f2635cb990, 
job@entry=0x55f263ab2f00, nproc=, lo

Bug#917278: bitlbee-plugin-mastodon: Not installable with bitlbee-libpurple

[Mykola Nikishov]

Package: bitlbee-plugin-mastodon
Severity: normal

$ sudo apt install bitlbee-plugin-mastodon bitlbee-libpurple
The following packages have unmet dependencies:
 bitlbee-libpurple : Depends: libpurple0 (>= 2.6.0) but it is not going to 
be installed
  bitlbee-plugin-mastodon : Depends: bitlbee but it is not going to be 
installed
  E: Unable to correct problems, you have held broken packages.

-- System Information:
Debian Release: buster/sid
  APT prefers stable
  APT policy: (900, 'stable'), (190, 'testing'), (180, 'unstable'), (170, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages bitlbee-plugin-mastodon depends on:
pn  bitlbee   
ii  libc6 2.28-2
ii  libglib2.0-0  2.58.1-6

bitlbee-plugin-mastodon recommends no packages.

bitlbee-plugin-mastodon suggests no packages.

Bug#917267: glx-diversions cannot be uninstalled

[Andreas Beckmann]

On 2018-12-25 09:04, Norbert Preining wrote:
> I recently purged all kind of nvidia* packages from my computer, and now
> none of them is actually there, but I still cannot uninstall
> glx-diversions:
> $ aptitute 
> ...
> Performing actions...
> (Reading database ... 961080 files and directories currently installed.)
> Removing glx-diversions (0.9.0) ...
> dpkg-divert: error: rename involves overwriting 
> '/usr/lib/i386-linux-gnu/libGL.so.1' with
>   different file '/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1', not 
> allowed

You shouldn't have /usr/lib/i386-linux-gnu/libGL.so.1 at this point ...
Where does it come from? Did you try to "fix" some things manually?
Is it a file or symlink?
ls -la, md5sum, timestamp, link target?

Any ideas how you got into this configuration? Didn't encounter
something like this in my tests.


Happy Holidays!


Andreas

Bug#901289: breaks boot in containers

[Dmitry Bogatov]

control: severity -1 important

[2018-12-23 22:58] Adam Borowski 
> Uh oh...  looks like the logsave issue suddenly became RCish: it
> prevents lxc containers from booting unattended:
> [...]

I can propose following ad-hoc solution. Objections? Better suggestions?

diff --git a/debian/src/initscripts/etc/init.d/checkfs.sh 
b/debian/src/initscripts/etc/init.d/checkfs.sh
index 44ac67f3..13a10d10 100755
--- a/debian/src/initscripts/etc/init.d/checkfs.sh
+++ b/debian/src/initscripts/etc/init.d/checkfs.sh
@@ -91,7 +91,7 @@ Continuing with system boot in 5 seconds."
if [ "$VERBOSE" = no ]
then
log_action_begin_msg "Checking file systems"
-   logsave -s $FSCK_LOGFILE fsck $spinner -M -A $fix 
$force $FSCKTYPES_OPT
+   logsave_best_effort fsck $spinner -M -A $fix $force 
$FSCKTYPES_OPT
FSCKCODE=$?
 
if [ "$FSCKCODE" -eq 32 ]
@@ -112,7 +112,7 @@ Continuing with system boot in 5 seconds."
else
log_action_msg "Will now check all file systems"
fi
-   logsave -s $FSCK_LOGFILE fsck $spinner -V -M -A $fix 
$force $FSCKTYPES_OPT
+   logsave_best_effort fsck $spinner -V -M -A $fix $force 
$FSCKTYPES_OPT
FSCKCODE=$?
if [ "$FSCKCODE" -eq 32 ]
then
diff --git a/debian/src/initscripts/etc/init.d/checkroot.sh 
b/debian/src/initscripts/etc/init.d/checkroot.sh
index ba35e439..b29ac72d 100755
--- a/debian/src/initscripts/etc/init.d/checkroot.sh
+++ b/debian/src/initscripts/etc/init.d/checkroot.sh
@@ -231,7 +231,7 @@ Will restart in 5 seconds."
if [ "$VERBOSE" = no ]
then
log_action_begin_msg "Checking root file system"
-   logsave -s $FSCK_LOGFILE fsck $spinner $force $fix -t 
$roottype $rootdev
+   logsave_best_effort fsck $spinner $force $fix -t 
$roottype $rootdev
FSCKCODE=$?
if [ "$FSCKCODE" = 0 ]
then
@@ -241,7 +241,7 @@ Will restart in 5 seconds."
fi
else
log_daemon_msg "Will now check root file system"
-   logsave -s $FSCK_LOGFILE fsck $spinner $force $fix -V 
-t $roottype $rootdev
+   logsave_best_effort fsck $spinner $force $fix -V -t 
$roottype $rootdev
FSCKCODE=$?
log_end_msg $FSCKCODE
fi
diff --git a/debian/src/initscripts/lib/init/mount-functions.sh 
b/debian/src/initscripts/lib/init/mount-functions.sh
index e453f6a8..7511761c 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -706,3 +706,13 @@ is_fastboot_active() {
done
return 1
 }
+
+# This function does not actually belong here; it is duct-tape solution
+# for #901289.
+logsave_best_effort () {
+   if [ -x /sbin/logsave ] ; then
+   logsave -s "${FSCK_LOGFILE}" "$@"
+   else
+   "$@"
+   fi
+}

Bug#915354: ITA: sent -- simple plaintext presentation tool

[Dmitry Bogatov]

[2018-12-24 02:48] eamanu15 
> Sorry for the delay (holidays issues :-) )
>
> I've just upload `sent` to mentors
>
> https://mentors.debian.net/package/sent
>
> Please, when you have time review it.

 * Since version 1-2 was rejected and I did not re-uploaded it, your
   version will become 1-2, not 1-3.

 * Why do you replace debhelper-compat with debhelper? It is step
   backward.

 * There must be newline after signature line in `debian/changelog'.

All-in-all, I see little improvement in your revision.

Probably, we could just leave things as-is, and make new revision when
need arise (bugs reported/new upstream version released).  I am sorry,
if it feels as wasted time.

Bug#917279: openjdk-8-jre: Netbeans 8.2 crashes at startup with 'library initialization failed...'

[Tim Rühsen]

Package: openjdk-8-jre
Version: 8u191-b12-2
Severity: important

Dear Maintainer,

since yesterday I experience a crash when starting upstream Netbeans 8.2.

$ netbeans-8.2/bin/netbeans 

library initialization failed - unable to allocate file descriptor table - out 
of memory/home/tim/netbeans-8.2/platform/lib/nbexec: Zeile 470: 11277 
Abgebrochen "/usr/lib/jvm/java-8-openjdk-amd64/bin/java" 
-Djdk.home="/usr/lib/jvm/java-8-openjdk-amd64" -classpath 
"/home/tim/netbeans-8.2/platform/lib/boot.jar:/home/tim/netbeans-8.2/platform/lib/org-openide-modules.jar:/home/tim/netbeans-8.2/platform/lib/org-openide-util.jar:/home/tim/netbeans-8.2/platform/lib/org-openide-util-lookup.jar:/home/tim/netbeans-8.2/platform/lib/org-openide-util-ui.jar:/home/tim/netbeans-8.2/platform/lib/locale/boot_ja.jar:/home/tim/netbeans-8.2/platform/lib/locale/boot_pt_BR.jar:/home/tim/netbeans-8.2/platform/lib/locale/boot_ru.jar:/home/tim/netbeans-8.2/platform/lib/locale/boot_zh_CN.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-modules_ja.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-modules_pt_BR.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-modules_ru.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-modules_zh_CN.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util_ja.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-lookup_ja.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-lookup_pt_BR.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-lookup_ru.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-lookup_zh_CN.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util_pt_BR.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util_ru.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-ui_ja.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-ui_pt_BR.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-ui_ru.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-ui_zh_CN.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util_zh_CN.jar:/usr/lib/jvm/java-8-openjdk-amd64/lib/dt.jar:/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar"
 -Dnetbeans.default_userdir_root="/home/tim/.netbeans" 
-Dnetbeans.running.environment=kde 
-Dnetbeans.dirs="/home/tim/netbeans-8.2/nb:/home/tim/netbeans-8.2/ergonomics:/home/tim/netbeans-8.2/ide:/home/tim/netbeans-8.2/extide:/home/tim/netbeans-8.2/java:/home/tim/netbeans-8.2/apisupport:/home/tim/netbeans-8.2/webcommon:/home/tim/netbeans-8.2/websvccommon:/home/tim/netbeans-8.2/enterprise:/home/tim/netbeans-8.2/mobility:/home/tim/netbeans-8.2/profiler:/home/tim/netbeans-8.2/python:/home/tim/netbeans-8.2/php:/home/tim/netbeans-8.2/identity:/home/tim/netbeans-8.2/harness:/home/tim/netbeans-8.2/cnd:/home/tim/netbeans-8.2/cndext:/home/tim/netbeans-8.2/dlight:/home/tim/netbeans-8.2/groovy:/home/tim/netbeans-8.2/extra:/home/tim/netbeans-8.2/javacard:/home/tim/netbeans-8.2/javafx:"
 -Dnetbeans.home="/home/tim/netbeans-8.2/platform" 
'-Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade' 
'-Dnetbeans.accept_license_class=org.netbeans.license.AcceptLicense' '-client' 
'-Xmx4096m' '-Xss2m' '-Xms32m' '-Dapple.laf.useScreenMenuBar=true' 
'-Dapple.awt.graphics.UseQuartz=true' '-Dsun.java2d.noddraw=true' 
'-Dsun.java2d.dpiaware=true' '-Dsun.zip.disableMemoryMapping=true' 
'-Dswing.aatext=true' '-Dawt.useSystemAAFontSettings=lcd' 
-DaddExports:java.desktop/sun.awt=ALL-UNNAMED 
-DaddExports:java.base/jdk.internal.jrtfs=ALL-UNNAMED 
-DaddExports:java.desktop/java.awt.peer=ALL-UNNAMED 
-DaddExports:java.desktop/com.sun.beans.editors=ALL-UNNAMED 
-DaddExports:java.desktop/sun.awt.im=ALL-UNNAMED 
-DaddExports:java.desktop/com.sun.java.swing.plaf.gtk=ALL-UNNAMED 
-DaddExports:java.management/sun.management=ALL-UNNAMED 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath="/home/tim/.netbeans/8.2/var/log/heapdump.hprof" 
org.netbeans.Main --cachedir "/home/tim/.cache/netbeans/8.2" --userdir 
"/home/tim/.netbeans/8.2" "--branding" "nb" "--laf" "Nimbus" 0<&0

I tried removing cache and userdir with no difference. Didn't find a 
work-around so far.

Netbeans definitely worked correctly a few days ago (I regularly upgrade my 
system).

$ dpkg -l '*openjdk*'

un  openjdk-11-demo   (keine Beschreibung 
vorhanden)
ii  openjdk-11-jdk:amd64  11.0.1+13-3  amd64OpenJDK Development 
Kit (JDK)
ii  openjdk-11-jdk-headless:amd64 11.0.1+13-3  amd64OpenJDK Development 
Kit (JDK) (headless)
ii  openjdk-11-jre:amd64  11.0.1+13-3  amd64OpenJDK Java 
runtime, using Hotspot JIT
ii  openjdk-11-jre-headless:amd64 11.0.1+13-3  amd64OpenJDK Java 
runtime, using Hotspot JIT (headless)
un  openjdk-11-source (keine Beschreibung 
vorhanden)
un  openjdk-6-jre (keine Beschreibung 
vorhanden)
un  openjdk-6-jre-headless(keine Beschreibung 
v

Bug#916818: rustc: Compiler regression results in generated code with unaligned access

[John Paul Adrian Glaubitz]

Hi!

Additional note: Since this bug is considered rather serious, the fix for
it has been nominated as a backport for the beta. Thus, the bug should be
fixed in Rust 1.32 as well and it shouldn't be necessary to include the patch
there.

Adrian

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

Bug#909142: wicd-curses: Right-arrow on first wlan errors wicd-curses.py

[Harald Geyer]

Package: wicd-curses
Version: 1.7.4+tb2-6
Followup-For: Bug #909142

Dear Maintainer,

I ran into this issue too. (The same backtrace)

I'm not sure at which exact step caused the problem, but what I did 
was:

1) Try to connect to an encrypted (WPA2) network - the only network
listed, ie the first one
2) Notice that wicd doesn't prompt me for the passphrase.
3) Entering the config screen with right arrow and setting the
passphrase
4) Trying to connect again
5) Turning the maschine off (got distracted)
6) Realize that I actually used the wrong passphrase
7) Turning the maschine on again
8) start wicd-curses
9) Trying to enter the setting screen again -> crash

In this state the crash was reproducible across reboots whenever I 
tried

to enter the setting screen.

To fix this issue (for now) I did:
sudo service wicd stop
sudo rm /etc/wicd/wireless-settings.conf
sudo rm /var/lib/wicd/configurations/${offending network}
sudo service wicd start

It now works for me. Since the configuration files belong to the daemon
rather then the UI my best guess is that misconfiguration of encrypted
networks puts the daemon into some odd state where it sends garbage to
the UI, which the UI can't handle.

HTH,
Harald

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

Kernel: Linux 4.18.0-3-arm64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT.UTF-8 (charmap=UTF-8)

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

Versions of packages wicd-curses depends on:
ii  python2.7.15-3
ii  python-urwid  2.0.1-2+b1
ii  wicd-daemon   1.7.4+tb2-6

Versions of packages wicd-curses recommends:
ii  sudo  1.8.26-2

wicd-curses suggests no packages.

Versions of packages wicd-daemon depends on:
ii  adduser   3.118
ii  dbus  1.12.10-1
ii  debconf   1.5.69
ii  iputils-ping  3:20180629-2
ii  isc-dhcp-client   4.3.5-4+b1
ii  lsb-base  10.2018112800
ii  psmisc23.2-1
ii  python2.7.15-3
ii  python-dbus   1.2.8-2+b1
ii  python-gobject-2  2.28.6-13+b1
ii  python-wicd   1.7.4+tb2-6
ii  udhcpc1:1.27.2-3
ii  wireless-tools30~pre9-13
ii  wpasupplicant 2:2.6-18

Versions of packages wicd-daemon recommends:
ii  rfkill  2.32.1-0.1

Versions of packages wicd-daemon suggests:
pn  pm-utils  

Versions of packages python-wicd depends on:
ii  net-tools  1.60+git20180626.aebd88e-1
ii  python 2.7.15-3

Versions of packages python-wicd suggests:
pn  ethtool   
ii  iproute2  4.18.0-2

-- debconf information:
* wicd/users: harald, olimex


--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w
or CLAM xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN

Bug#895478: gnome-screensaver: package Description should mention that it is not part of GNOME 3

[Jeremy Bicha]

On Wed, Apr 11, 2018 at 7:24 PM Justin B Rye  wrote:
> Simon McVittie wrote:
> > Here is an attempt at a more current description:
> >
> >  Screensaver and screen lock formerly used in GNOME
> >
> >  gnome-screensaver is a simple screen saver and screen lock, used in older
> >  versions of the GNOME desktop environment.
> >  .
> >  It is designed to support, among other things:
> >  .
> >   * the ability to lock down configuration settings
> >   * translation into other languages
> >   * user switching
> >  .
> >  This package is not necessary in the GNOME desktop environment, because
> >  GNOME Shell contains its own screen lock implementation. It is
> >  used by lighter-weight desktop environments such as GNOME Flashback.
>
> For me (and most of the people I see considering this question on the
> net) that has to be "more lightweight", not "lighter-weight"...

Thanks. I ended up using "alternative" instead of "lighter-weight". I
believe Debian's Budgie currently uses gnome-screensaver too, which
may or may not be lighter weight depending on your perspective.

> And is it a matter of "It is used" or "It can be used"?

Oh, I missed this comment but I at least made the change in git for Bullseye.

Thanks,
Jeremy Bicha

Bug#915354: ITA: sent -- simple plaintext presentation tool

[eamanu15]

Hi!

El mar., 25 de dic. de 2018 a la(s) 10:39, Dmitry Bogatov <
kact...@debian.org> escribió:

>
> [2018-12-24 02:48] eamanu15 
> > Sorry for the delay (holidays issues :-) )
> >
> > I've just upload `sent` to mentors
> >
> > https://mentors.debian.net/package/sent
> >
> > Please, when you have time review it.
>
>  * Since version 1-2 was rejected and I did not re-uploaded it, your

   version will become 1-2, not 1-3.
>

okas!

>
>  * Why do you replace debhelper-compat with debhelper? It is step
>backward.
>

To avoid this Litian warning: " Buildsystem: Package uses debhelper with an
old compatibility level" I try to use debhelper-compat (>= 11) ont
d/control, but I have error on packaging

>
>  * There must be newline after signature line in `debian/changelog'.
>
Okas thanks!

>
> All-in-all, I see little improvement in your revision.
>
> Probably, we could just leave things as-is, and make new revision when
> need arise (bugs reported/new upstream version released).


So, do you consider better waiting for a bug report or new upstream to
upload this version with the "intent to adopt"?

What do you think about upload sent 1-2 to close #915354?


> I am sorry, if it feels as wasted time.
>
No :-) I am learning and this reviews are  good for me.

Regards!

Bug#917280: Linux-4.18.20 fail to boot on old intel gfx card

[? ?]

Package: Linux-image-amd64
Version: 4.18+100~bpo9+1

Linux-4.18.20 fail to boot on old intel gfx card.
I also tried a fresh installed Debian testing with same kernel version,
still can't boot, even to command line interface.

after blacklisting i915, Debian testing can boot to command line
interface. but when I tried to modprobe i915, screen blanks, shows
nothing.

while Linux-4.18.6 is good to boot to UI.

here is my hardware information:
Machine: Thinkpad X200
output of lspci for gfx card:

00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem:
Lenovo Mobile 4 Series Chipset Integrated Graphics Controller
[17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF-
FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

Bug#917281: ITP: ruby-kitchen-salt -- salt provisioner for test-kitchen

[Mathieu Parent]

Package: wnpp
Severity: wishlist
Owner: Mathieu Parent 

* Package name: ruby-kitchen-salt
  Version : 0.4.0
  Upstream Author :  SaltStack Inc
* URL : https://github.com/saltstack/kitchen-salt
* License : MIT
  Programming Lang: Ruby
  Description : salt provisioner for test-kitchen

salt provisioner for test-kitchen so that you can test all the things

(under the ruby-extras team)

Bug#917266: [debian-mysql] Bug#917266: default-libmysqlclient-dev: Uninstallable - depends on no longer built libmariadbclient-dev-compat

[Scott Kitterman]

On December 25, 2018 10:28:50 AM UTC, "Otto Kekäläinen"  wrote:
>Hello!
>
>ti 25. jouluk. 2018 klo 10.06 Scott Kitterman (deb...@kitterman.com)
>kirjoitti:
>> Severity: grave
>> Justification: renders package unusable
>>
>>  no longer found.
>>
>> Since mariadb10.3 became the default this no longer works:
>>
>> #include 
>>
>> It has to be changed to:
>>
>> #include 
>>
>> You can experience this for yourself by rebuilding postfix, seeing it
>fail:
>>
>> gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE -DHAS_LDAP
>-DUSE_LDAP_SASL -DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB
>-DHAS_MYSQL -I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql
>-DHAS_SQLITE -I/usr/include -DHAS_SSL -I/usr/include/openssl
>-DUSE_SASL_AUTH -I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS
>-I/usr/include -DHAS_DEV_URANDOM
>-DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\"
>-DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\"
>-DDEF_MANPAGE_DIR=\"/usr/share/man\"
>-DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS
>-DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g
>-O2 -I. -I../../include -DLINUX3 -c dict_ldap.c
>> gcc -shared -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib/postfix -o
>postfix-ldap.so dict_ldap.o -lldap -llber -L../../lib -L.
>-lpostfix-util -lpostfix-global
>> gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE -DHAS_LDAP
>-DUSE_LDAP_SASL -DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB
>-DHAS_MYSQL -I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql
>-DHAS_SQLITE -I/usr/include -DHAS_SSL -I/usr/include/openssl
>-DUSE_SASL_AUTH -I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS
>-I/usr/include -DHAS_DEV_URANDOM
>-DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\"
>-DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\"
>-DDEF_MANPAGE_DIR=\"/usr/share/man\"
>-DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS
>-DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g
>-O2 -I. -I../../include -DLINUX3 -c dict_mysql.c
>> dict_mysql.c:171:10: fatal error: mysql.h: No such file or directory
>>  #include 
>>   ^
>> compilation terminated.
>>
>> And then changing src/global/dict_mysql.c line 171
>>
>> Alternately, I could update the include path, I guess, but isn't
>approximately
>> the whol point of providing a generic default so that every package
>in
>> Debian doesn't have to change when the default changes?
>
>Yes, these #include mysql.h in Debian can be found via
>https://codesearch.debian.net/search?q=%22mysql.h%22&perpkg=1
>
>In mariadb-10.1 the mysql.h was shipped in package
>libmariadbclient-dev at path /usr/include/mysql/mysql.h. The package
>libmariadbclient-dev-compat does not provide any symlinks or anything
>related to /usr/include
>
>In mariadb-connector-c mysql.h was shipped in package libmariadb-dev
>at path /usr/include/mariadb/mysql.h
>
>In mariadb-10.3, which now includes libmariadb3 (and no
>libmariadbclient18 anymore), so basically same as mariadb-connector-c,
>and ships mysql.h in package libmariadb-dev at path
>/usr/include/mariadb/mysql.h.
>
>I've attached file listing from the relevant libmariadb* packages
>across mariadb-10.1, -10.3 and mariadb-connector-c so it is easier for
>you to review and suggest how to proceed.
>
>I tested the cmake flags used in mariadb-connector-c to modify the
>file layout (DINSTALL_LAYOUT:STRING=DEB -DPLUGINDIR_DEB=mariadb3
>-DWITH_MYSQLCOMPAT=ON)
>[1] but they did not have any effect.
>
>I don't think there is anything I can do. Feel free to open a merge
>request[2] on mariadb-10.3 if you have a vision how to add symlinks or
>something to solve this.

Can't you just use dh_link to add a symlink?

Scott K

Bug#917267: glx-diversions cannot be uninstalled

[Norbert Preining]

Hi Andreas,

> You shouldn't have /usr/lib/i386-linux-gnu/libGL.so.1 at this point ...
> Where does it come from? Did you try to "fix" some things manually?

No, I just de-selected all the relevant packages in aptitude, and then
pressed g ;-)

> Is it a file or symlink?
> ls -la, md5sum, timestamp, link target?

Sorry, since I need to use this computer I ended up doing
dpkg --force-depends --purge libgl1:amd64 libgl1:i386
dpkg --purge glx-diversions
apt install libgl1:amd64 libgl1:i386

> Any ideas how you got into this configuration? Didn't encounter
> something like this in my tests.

It is a bit special configuration: It is a laptop with Intel GPU, which
is synced to my main computer having an nvidia gpu. I install TensorFlow
with GPU support on the nvidia/main machine. I sync the stuff in
/usr/local with unison. 

I want to be able to run tensorflow on my laptop, too, but with the
installation from the nvidia machine it does not work due to missing
libraries. So installed the missing libraries from nvidia, but use the
intel driver.

Now, on the main desktop I can run tensorflow with GPU support, and on
the laptop I run the same, but due to missing nvidia card it falls back
to using CPU only.

I admit this is a special setup, but apt allowed me to install the
nvidia libraries in parallel to the intel driver and mesa gl stuff.

I tried to revert the whole bunch due to strange problems on my desktop
(Cinnamon) which does not properly show notifications, some programs
don't start with very strange exception related to X. So I thought that
the nvidia libs might be a problem and reverted ...

Happy and peaceful holidays, and a great start into the new year!

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#917270: texlive-latex-extra-doc: Please add dtx files for dtxgallery

[Norbert Preining]

Hi Karl,

On Tue, 25 Dec 2018, Braun Gábor wrote:
> Open the dtxgallery document with 'texdoc dtxgallery'.
> A PDF file opens, and on the very first page prominently lists four example 
> dtx files
> without any information how to open them:
> 
> single-source.dtx
> conditional-code.dtx
> rearrange.dtx
> dtxgallery.dtx
> 
> Note that on the top of the second page, the document explicitly recommends
> examining these dtx files directly, but the lack of any information where 
> these are make it
> very hard.  They don't seem to be included in the package, at least not in an 
> obvious location:

These files are in the source files part of dtxgallery:
**
name dtxgallery
category Package
revision 15878
shortdesc A small collection of minimal DTX examples
longdesc A collection of files that demonstrate simple things that are
longdesc possible with the flexible and under-appreciated docstrip file
longdesc format. Each file of the collection is provided as a .dtx file
longdesc and as the corresponding .pdf. The set is intended as a
longdesc companion to Scott Pakin's excellent and influential dtxtut
longdesc example of producing LaTeX packages in this way.
containersize 584
containerchecksum 
2c73069596d5c99c6f9f9ea9f9e65f5f731854068d1b56a6317e5966a023ad057c81d8c62ef38fc3af962b7307cbff45dbcd3867fdb4caf7bcd3a2c83a722674
doccontainersize 349372
doccontainerchecksum 
31e82752179fb78fd8db1871eee1b3c254e78f4254540c43d63a4243f59a0ec5efcfef6211c0d9012e2dc336164ad65e1ec38d9a1f0274208600b188ff86bdfa
docfiles size=95
 texmf-dist/doc/latex/dtxgallery/README details="Readme"
 texmf-dist/doc/latex/dtxgallery/conditional-code.pdf
 texmf-dist/doc/latex/dtxgallery/dtxgallery.pdf
 texmf-dist/doc/latex/dtxgallery/rearrange.pdf
 texmf-dist/doc/latex/dtxgallery/single-source.pdf
srccontainersize 3972
srccontainerchecksum 
60b1bd74afa60c36d7ebd522157a594cb62298c3638b28d589a84f8df08e37dfc923c063663b9a7202481bf8d80970d873b2cb055c8fbcaba71d55c109e8a89d
srcfiles size=5
 texmf-dist/source/latex/dtxgallery/conditional-code.dtx
 texmf-dist/source/latex/dtxgallery/dtxgallery.dtx
 texmf-dist/source/latex/dtxgallery/rearrange.dtx
 texmf-dist/source/latex/dtxgallery/single-source.dtx
**

I think in this particular case it would be better to move them to the
docfiles?

WDYT?

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#917196: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

We are ready to go.


-- 
¿Qué vamos a hacer esta noche Cerebro?
-Lo mismo que todas las noches Pinky...
¡¡¡tratar de conquistar el mundo!!!
  Pinky y Cerebro. Narf.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#917282: ITP: lz4json -- unpack lz4json files, usually generated by Mozilla programs

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: lz4json
  Version : ?
  Upstream Author : Andi Kleen
* URL : https://github.com/andikleen/lz4json
* License : BSD-2 ish
  Programming Lang: C
  Description : unpack lz4json files, usually generated by Mozilla programs
 Instead of a standard .json.lz4, Firefox uses its own format to compress
 its bookmarks and session restore files.  This tool lets you read them,
 converting to json.  Going from json to a human-readable format is then
 up to you.

Bug#917283: llvm-toolchain-6.0: external function __aeabi_unwind_cpp_pr0 missing [armhf]

[Daniel Stender]

Package: llvm-toolchain-6.0
Version: 1:6.0.1-9.2
Severity: important
Control: block 917252 by -1

Hi,

LLVMlite 0.26.0-1 [1] has a test failure with LLVM 6.0 on armhf [2]:


test_global_ctors_dtors (llvmlite.tests.test_binding.TestGlobalConstructors) 
... LLVM ERROR: Program used external function '__aeabi_unwind_cpp_pr0' which 
could not be resolved!
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython2_2.7_llvmlite/build; python2.7 -m unittest 
discover -v


Unfortunately the upstream code isn't ready for LLVM 7 yet [3].

Best,
Daniel Stender

[1] https://tracker.debian.org/pkg/llvmlite

[2] 
https://buildd.debian.org/status/fetch.php?pkg=llvmlite&arch=armhf&ver=0.26.0-1&stamp=1543651733&raw=0

[3] https://bugs.debian.org/912790 llvmlite: Please switch to llvm-toolchain-7

-- 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/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)

Bug#917284: opendmarc: [INTL:de] Initial German debconf translation

[Chris Leick]

Package: opendmarc
Version: 1.3.2-5
Severity: wishlist
Tags: l10n patch



Hi,

please find attached the initial German debconf translation.

Kind regards,
Chris


de.po.gz
Description: application/gzip

Bug#917285: [chai] Please split libjs-chai

[Bastien Roucariès]

Package: chai
Version: 4.2.0+ds-1
Severity: important

A remainder to split package to libjs-chai and follow policy

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

Bug#917287: failure to install x32 port from iso netboot image: gpgv unknown digest algorithm

[Shawn Rutledge]

Package: gpgv
Version: 1.4.18

I’m trying to run the installer from http://debian-x32.org/d-i/netboot.iso .  
The mirror is set by default to ftp.debian-x32.org, directory /debian/.   It 
says “downloading a file failed”.  I hit alt-F4 to get to the error console to 
investigate, and the last few lines are (omitting timestamps)

choose-mirror: DEBUG: command: wget -q 
http://ftp.debian-x32.org/debian//dists/jessie/main/binary-x32/Release -O - | 
grep ^Architecture:
anna: WARNING **: bad d-i Packages file
net-retriever: gpgv: md_enable: algorithm 10 not available
net-retriever: gpgv: Signature made Sat Aug 25 17:05:17 2018 UTC using RSA key 
ID BED007F9
net-retriever: gpgv: Can’t check signature: unknown digest algorithm
net-retriever: error: Bad signature on /tmp/net-retriever-2779-Release

So maybe the signatures are done with a newer digest algorithm and therefore 
gpgv on the ISO image needs to be updated?

Bug#917286: [src:chai] Use browserify

[Bastien Roucariès]

Package: src:chai
Version: 4.2.0+ds-1
Severity: wishlist
control: block -1 by 780357

We should use browserify instead of webpack like upstream

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

Bug#917288: tidy reports "not a file" for existing file

[Thomas Dickey]

Package: tidy
Version: 2:5.6.0-9
Severity: important

Dear Maintainer,

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

I use a script that calls "tidy" for cleanup of format.
That does something like

tidy -ascii -i foo.html

The latest version says

Document: "foo.html" is not a file!

which is unexpected behavior.   This works:

tidy -ascii -i < foo.html

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


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

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

Versions of packages tidy depends on:
ii  libc6 2.28-2
ii  libtidy5deb1  2:5.6.0-9

tidy recommends no packages.

tidy suggests no packages.

-- no debconf information

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#913864: kicad: Backtraces on opening cvpcb

[Carsten Schoenert]

Control: tags -1 wontfix

Hello Julien, happy Xmas!

Am 22.12.18 um 07:58 schrieb Julien Goodwin:
> On 15/12/18 5:34 pm, Carsten Schoenert wrote:
>> I tried to reproduce this issue on several machines in preparation for
>> 5.0.2. But I'm unable to get catched by your reported issue on any of my
>> machines. Even if I forced the install the packages python-wxgtk3.0 and
>> libwxgtk3.0-gtk3-0v5!
> 
> For me forcing python-wxgtk3.0_3.0.2.0+dfsg-4 is the way I make things work.

Reading your answer completely it's quite obvious why.

...
>> Are you really sure you are using a binary from the Debian archive? Can
> Yes.
> 
> I just upgraded to 5.0.2+dfsg1-1 last night, and before that played around.
> 
> Having a python plugin (in .kicad/scripting/plugins, and specifically
> InteractiveHtmlBom[1]) seems to be what triggers this.

I've looked into the symbol table while KiCad is running and there are
no GTK+3 related symbols loaded. So the clashing mus come from elsewhere.

Starting KiCad, open EEschema with some ordinary schematic and open
Cvpcb ...

> $ grep libwx /proc/$(pidof kicad)/maps
> 7fea4d7d7000-7fea4d802000 r--p  103:01 1057723   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0
> 7fea4d802000-7fea4d9e1000 r-xp 0002b000 103:01 1057723   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0
> 7fea4d9e1000-7fea4da17000 r--p 0020a000 103:01 1057723   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0
> 7fea4da17000-7fea4da1e000 r--p 0023f000 103:01 1057723   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0
> 7fea4da1e000-7fea4da1f000 rw-p 00246000 103:01 1057723   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0
> 7fea4da22000-7fea4da26000 r--p  103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da26000-7fea4da2e000 r-xp 4000 103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da2e000-7fea4da31000 r--p c000 103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da31000-7fea4da32000 ---p f000 103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da32000-7fea4da33000 r--p f000 103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da33000-7fea4da34000 rw-p 0001 103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da34000-7fea4da96000 r--p  103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4da96000-7fea4dc38000 r-xp 00062000 103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4dc38000-7fea4dcc3000 r--p 00204000 103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4dcc3000-7fea4dcc4000 ---p 0028f000 103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4dcc4000-7fea4dccf000 r--p 0028f000 103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4dccf000-7fea4dcd3000 rw-p 0029a000 103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4dce-7fea4dcf1000 r--p  103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dcf1000-7fea4dd18000 r-xp 00011000 103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dd18000-7fea4dd25000 r--p 00038000 103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dd25000-7fea4dd26000 ---p 00045000 103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dd26000-7fea4dd28000 r--p 00045000 103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dd28000-7fea4dd29000 rw-p 00047000 103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dd2a000-7fea4df3d000 r--p  103:01 1057066   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0
> 7fea4df3d000-7fea4e20e000 r-xp 00213000 103:01 1057066   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0
> 7fea4e20e000-7fea4e30f000 r--p 004e4000 103:01 1057066   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0
> 7fea4e30f000-7fea4e381000 r--p 005e4000 103:01 1057066   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0
> 7fea4e381000-7fea4e389000 rw-p 00656000 103:01 1057066   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0
> 7fea4e395000-7fea4e3d5000 r--p  103:01 1057407   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0.4.0
> 7fea4e3d5000-7fea4e43e000 r-xp 0004 103:01 1057407   

Bug#917289: transition: ntfs-3g

[GCS]

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

Hi RMs,

Small transition of ntfs-3g from 2017.3.23 to 2017.3.23AR.3 and
involves the following packages: partclone, testdisk and wimlib.
All three build fine with this ntfs-3g version as well.

Thanks,
Laszlo/GCS

Bug#907632: [ppc64-el] Breaks building aspectc++

[Steve Langasek]

Package: aspectc++
Version: 1:2.2+git20170823-7
Followup-For: Bug #907632
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Hello,

Based on the bug history, I don't think this is a bug in gcc-8 but in
aspectc++ (or in llvm), so I have reassigned.

I have also refined the patch provided by Frédéric, to avoid repetition in
the code; please find it attached.

I have uploaded this patch to Ubuntu, where I confirm it fixes the build
failure on ppc64el.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru aspectc++-2.2+git20170823/debian/control 
aspectc++-2.2+git20170823/debian/control
--- aspectc++-2.2+git20170823/debian/control2018-08-24 23:29:52.0 
-0500
+++ aspectc++-2.2+git20170823/debian/control2018-12-25 10:15:09.0 
-0600
@@ -1,8 +1,7 @@
 Source: aspectc++
 Section: devel
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Reinhard Tartler 
+Maintainer: Reinhard Tartler 
 Build-Depends: debhelper (>= 9), libxml2-dev, docbook-to-man, zlib1g-dev, 
libedit-dev, llvm-4.0-dev, libclang-4.0-dev
 Build-Depends-Indep: doxygen, graphviz, gsfonts
 Standards-Version: 4.0.0
diff -Nru aspectc++-2.2+git20170823/debian/patches/ppc64el-no-float128.patch 
aspectc++-2.2+git20170823/debian/patches/ppc64el-no-float128.patch
--- aspectc++-2.2+git20170823/debian/patches/ppc64el-no-float128.patch  
1969-12-31 18:00:00.0 -0600
+++ aspectc++-2.2+git20170823/debian/patches/ppc64el-no-float128.patch  
2018-12-25 10:15:01.0 -0600
@@ -0,0 +1,23 @@
+Description: adjust ppc64el compiler options for compatibility with gcc-8
+ gcc-8 now uses -mfloat128 by default on ppc64el, which results in
+ incompatible type definitions being passed in to llvm.  Override this by
+ explicitly passing -mno-float128 on ppc64el.
+Author: Frédéric Bonnard 
+Bug-Debian: https://bugs.debian.org/907632
+Last-Modified: 2018-12-25
+
+Index: aspectc++-2.2+git20170823/Ag++/PumaConfigFile.cc
+===
+--- aspectc++-2.2+git20170823.orig/Ag++/PumaConfigFile.cc
 aspectc++-2.2+git20170823/Ag++/PumaConfigFile.cc
+@@ -118,7 +118,10 @@
+ config_command_str = "\"" + _config.cc_bin() + "\" "
+ + _config.optvec().getString(
+ (OptionItem::OPT_GCC | OptionItem::OPT_CONFIG))
++#ifdef __powerpc__ && __powerpc64__ && __LITTLE_ENDIAN__
+++ " -mno-float128 "
++#endif
+ + " -E -dM -v -x c++ \"" + empty_file_name + "\"";
+   }
+ 
+   // get c compiler output
diff -Nru aspectc++-2.2+git20170823/debian/patches/series 
aspectc++-2.2+git20170823/debian/patches/series
--- aspectc++-2.2+git20170823/debian/patches/series 2018-06-25 
09:59:10.0 -0500
+++ aspectc++-2.2+git20170823/debian/patches/series 2018-12-25 
10:12:04.0 -0600
@@ -1,2 +1,3 @@
 0001-lexertl-Fix-FTBFS-with-gcc-8.patch
 auto-gitignore
+ppc64el-no-float128.patch

Bug#917291: libharfbuzz0b: wrong glyph for chinese word 小 (U+5C0F)

[Tommy Wu]

Package: libharfbuzz0b
Version: 2.3.0-1
Severity: normal

Dear Maintainer,

U+5C0F (小) is not render correctly after version 2.0.0.
It work fine for version under 1.9.0.

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_TW.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 libharfbuzz0b depends on:
ii  libc6   2.28-2
ii  libfreetype62.9.1-3
ii  libglib2.0-02.58.1-2
ii  libgraphite2-3  1.3.12-1

libharfbuzz0b recommends no packages.

libharfbuzz0b suggests no packages.

-- no debconf information

Bug#917292: ffmpeg: linking with libcrystalhd3 seem of no use at all

[Jonas Smedegaard]

Package: ffmpeg
Version: 7:4.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

ffmpeg currently links with libcrystalhd3.

It seems, however, that libcrystalhd3 is only really useful together
with firmware-crystalhd, which was never really usable in Debian,
leading to that package being dropped: https://bugs.debian.org/865978

If someone wants to revive CrystalHD in Debian, it seems a good place to
start is https://www.mythtv.org/wiki/Broadcom_Crystal_HD#Feb._2014_Update

I suggest to simply stop link with libcrystalhd3 until firmware-crystalhd
reappear in Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwiZxoACgkQLHwxRsGg
ASFQrw//Wd0qLAUdH0nd8fx+PNVu5LtkXz5rBPjO2KaLHpaTQjQfVhgAbjaIaGrs
AgH7GBqg28gEkhyj85kDrXUAgg2BKMlWhTePUhi2QVxcXSjMUciL8susz5dO75Ye
Q+HJ0kFZ4V8O0fohGYUdukktKf+aES/mChO4U/GXJQfyE9c49HzCLgm7FHg7SN2D
mpG84rj+0pX9HEBCLjYGAtUChqd8ugyHD8PfRaIkH4i1+M1W4Zyt+oeicg1D1D4R
h1LAMRI7+GXtTv64OZ3/rnwe2YYPSALbK3mqB1aTD6wiYjw0aEL7hw05wQidupQ+
NV2XtRnsQ0UqZaSijyzxl708Yy8sxPGi97HxnnbgZjdhOQins/Tcvh/2/qwFenXE
3TykXcYMQ3YZx1v5Jq1wILG8OKnRyKPxpDtxN9ogXPLgVLn4JnAygEVthdzOw/93
1ewbJT3M3xcfXDGBQU2mJMZ4bRzz7M6tui1Q+L19zkm4P/4OcqDuRuVLV9/wmfCj
SWpGmDVSIiXRUH+qUGOtSGkno5OouFDTsirB2Zw+2QQTPboEcK3PXXhpWs19S+Ah
WdJpK0/F+9QdlGfy03iBAQ5ICbuoCcHO9YUBtaGkwWXhLGuaz58GtxQm/szLdzMH
1+lYuFUvcFm7FhlZfQxTN+Za/80pNuODzxB1uToLJrFeAk0MdoY=
=M67y
-END PGP SIGNATURE-

Bug#917278: bitlbee-plugin-mastodon: Not installable with bitlbee-libpurple

[Antoine Beaupré]

Control: reassign -1 bitlbee-libpurple

bitlbee-libpurple has a versionned dependency against a bitlbee release
that is not in Debian unstable.

anarcat@curie:~(master)$ apt show bitlbee-libpurple | grep Depends
[...]
Depends: libc6 (>= 2.14), libgcrypt20 (>= 1.7.0), libglib2.0-0 (>= 2.24.0), 
libgnutls30 (>= 3.5.6), libpurple0 (>= 2.6.0), debianutils (>= 1.16), 
bitlbee-common (= 3.5.1-1)
anarcat@curie:~(master)$ rmadison bitlbee | grep unstable
bitlbee| 3.4.2-1| unstable| source, 
kfreebsd-amd64, kfreebsd-i386
[...]

Therefore the bug is not, as far as I understand this, in
bitlbee-mastodon, so reassigning.

A.

On 2018-12-25 15:21:57, Mykola Nikishov wrote:
> Package: bitlbee-plugin-mastodon
> Severity: normal
>
> $ sudo apt install bitlbee-plugin-mastodon bitlbee-libpurple
> The following packages have unmet dependencies:
>  bitlbee-libpurple : Depends: libpurple0 (>= 2.6.0) but it is not going 
> to be installed
>   bitlbee-plugin-mastodon : Depends: bitlbee but it is not going to be 
> installed
>   E: Unable to correct problems, you have held broken packages.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers stable
>   APT policy: (900, 'stable'), (190, 'testing'), (180, 'unstable'), (170, 
> 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages bitlbee-plugin-mastodon depends on:
> pn  bitlbee   
> ii  libc6 2.28-2
> ii  libglib2.0-0  2.58.1-6
>
> bitlbee-plugin-mastodon recommends no packages.
>
> bitlbee-plugin-mastodon suggests no packages.

-- 
Secrecy is the keystone to all tyranny. Not force, but secrecy and
censorship.
   -  Robert A. Heinlein

Bug#917075: [debian-mysql] Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Luca Boccassi]

On Tue, 25 Dec 2018 12:38:34 +0100 Luca Boccassi 
wrote:
> On Tue, 25 Dec 2018 12:51:40 +0200 =?UTF-
8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
>  wrote:
> > I did this change yesterday but have not uploaded yet as I'd like
to
> first
> > write an automated gitlab-ci.yml test in mariadb-10.3 to detect the
> problem
> > first.
> > 
> > https://salsa.debian.org/mariadb-team/mysql/commit/41b7e55f1c5a3cb9
3d
> a2e2407230542cc9284222
> 
> Hi,
> 
> Thanks for the update. Do you happen to have a rough ETA? Rebuilding
> collectd is required for the DPDK transition [1] that I'm looking
after
> to progress.
> 
> Thank you!
> 
> -- 
> Kind regards,
> Luca Boccassi
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916351

Never mind, the last update of default-libmysqlclient-dev fixed the
issue, sorry for the noise.

-- 
Kind regards,
Luca Boccassi

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

Bug#915419: debdiff for 915692, 915419

[Luca Boccassi]

On Tue, 2018-12-25 at 11:41 +0100, Luca Boccassi wrote:
> On Sat, 2018-12-22 at 22:34 +0100, Luca Boccassi wrote:
> > Control: tags -1 pending
> > 
> > On Wed, 19 Dec 2018 16:39:17 +0100 Luca Boccassi 
> > wrote:
> > > Dear Maintainer,
> > >  
> > > In order to allow the DPDK 17.11 -> 18.11 transition to happen
> > > [1],
> > > I
> > > intend to upload a source NMU fixing 915692 and 915419 (debdiff
> > > attached) either at the end of this week or at the beginning of
> > > the
> > > next to DELAYED/1.
> > >  
> > > I hope this does not cause any troubles, and please let me know
> > > if
> > 
> > this
> > > would be an issue, and/or if you prefer an alternative solution.
> > >  
> > > Thank you!
> > >  
> > > -- 
> > > Kind regards,
> > > Luca Boccassi
> > >  
> > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916351
> > 
> > Dear Maintainers,
> > 
> > I have uploaded the aforementioned NMU to DELAYED/2 to allow for
> > the
> > DPDK transition to start on Monday. Please let me know if this is
> > an
> > issue and would like me to cancel it.
> > 
> > Thanks!
> 
> Hi,
> 
> Unfortunately a new version of mariadb was uploaded to unstable after
> my last build test but before the upload got through DELAYED, so the
> package does not build in unstable :-(
> 
> I have reported the issue with more details on the appropriate
> mariadb
> bug [1]. I do not believe there is any action that should be taken on
> collectd at the moment.

The above issue has been fixed in unstable, so I've uploaded another
NMU to fix 917202 to DELAYED/1.

-- 
Kind regards,
Luca Boccassi

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

Bug#917202: lm-sensors: Ability to install both libsensors4 and libsensors5?

[Luca Boccassi]

On Tue, 2018-12-25 at 12:14 +0100, Luca Boccassi wrote:
> On Mon, 24 Dec 2018 01:33:08 +0100 Aurelien Jarno  et
> > wrote:
> > control: reassign -1 collectd
> > control: retitle -1 collectd should be updated for libsensors5
> > control: severity -1 serious
> >  
> > On 2018-12-24 01:11, Xavier Guerrin wrote:
> > > Package: lm-sensors
> > > Version: 1:3.5.0-3
> > > Severity: normal
> > >  
> > > Dear Maintainer,
> > >  
> > > It does not seem possible to install both libsensors4 and
> 
> libsensors5 as
> > > "apt install libsensors5" will remove libsensors4. This is
> 
> apparently due to
> > > libsensors-config, which is marked as breaking and replacing
> 
> libsensors4.
> >  
> > True.
> >  
> > > Alas, this package does not effectively replace libsensors4 since
> 
> it no longer
> > > provides libsensors.so.4. This has the side-effect of breaking
> 
> collectd's
> > > "sensors" plugin, which relies on libsensors.so.4:
> > >    $ dpkg -L collectd-core | grep sensors
> > >    /usr/lib/collectd/sensors.so
> > >    $ ldd /usr/lib/collectd/sensors.so
> > >    linux-vdso.so.1 (0x7ffe949f2000)
> > >    libsensors.so.4 => not found
> > >    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> 
> (0x7fc8b4c44000)
> > >    /lib64/ld-linux-x86-64.so.2 (0x7fc8b4e21000)
> > 
> >  
> > This is clearly a bug of collectd which should be updated to use
> > libsensors5. I am therefore reassigning the bug to this package.
> 
> Dear Maintainer,
> 
> collectd 5.8 fails to build with libsensors5 due to unnecessary
> checks
> that have been removed in the upstream 5.8 branch [1].
> Backporting that single patch fixes the build.
> 
> Given this will block the DPDK transition I'm looking after [2],
> unless
> it's an issue I'll do a source NMU to DELAYED/1 once the other bug
> affecting collectd from mariadb [3] is fixed. Let me know if this is
> an
> issue. The debdiff is attached.
> 
> Thank you!

Dear Maintainers,

The issue with mysql/mariad has been fixed in unstable so I've uploaded
the mentioned NMU to DELAYED/1. Please let me know if this is an issue
and would like it cancelled.

Thank you!

-- 
Kind regards,
Luca Boccassi

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

Bug#917293: kinit: The kdeinit5 consumes and takes about 3 ~ 5 minutes to give me control of the environment.

[Santiago José López Borrazás]

Package: kinit
Version: 5.51.0-1
Severity: important

Dear Maintainer,

When I want to enter the KDE, it takes me a lot to finish the session. It 
consumes CPU and it takes, like an average of between 3 and 5 minutes to give 
me session control.

I have tried creating another user and do the same.

This bug has been playing for a week now. And it's pretty weird What I 
consider, that is a BUG, for that reason, and it is of great importance.

With htop I checked what it consumes, with this command when starting the 
graphical environment:

kdeinit5 --oom-pipe 4 --kded +kcminit_startup

I thought there was a package missing, but no. I do not miss any package in 
important dependencies.

This has never happened to me. In my life.

Thank you very much for your help.

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

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

Versions of packages kinit depends on:
ii  kio  5.51.0-1
ii  libc62.28-3
ii  libcap2  1:2.25-1.2
ii  libcap2-bin  1:2.25-1.2
ii  libkf5configcore55.51.0-1
ii  libkf5coreaddons55.51.0-1
ii  libkf5crash5 5.51.0-1
ii  libkf5i18n5  5.51.0-1
ii  libkf5kiocore5   5.51.0-1
ii  libkf5kiowidgets55.51.0-1
ii  libkf5service-bin5.51.0-1
ii  libkf5service5   5.51.0-1
ii  libkf5windowsystem5  5.51.0-1
ii  libqt5core5a 5.11.2+dfsg-7
ii  libqt5dbus5  5.11.2+dfsg-7
ii  libqt5gui5   5.11.2+dfsg-7
ii  libstdc++6   8.2.0-13
ii  libx11-6 2:1.6.7-1
ii  libxcb1  1.13.1-2

kinit recommends no packages.

kinit suggests no packages.

-- no debconf information

Bug#917243: ghostwriter: Please suggest optional export tools: pandoc discount cmark

[Sebastien Chavaux]

Hello,
Oki I take care of it with the upgrade to version 1.7.4.

Sincerely.

Le lun. 24 déc. 2018 17:03, Jonas Smedegaard  a écrit :

> Package: ghostwriter
> Version: 1.7.3-1
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Ghostwriter supports optional alternative exporters, as documented at
> <
> https://github.com/wereturtle/ghostwriter/wiki/How-to-Add-Extra-Export-Formats
> >
>
> Please suggest all such helper tools.
>
> Seems at least the following: pandoc discount cmark
>
>
>  - Jonas
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwhAuMACgkQLHwxRsGg
> ASFk9RAAoxH2AZ3ViyKnl2upaBV5BB1bIl5e454eeMV6OPbtlZTiH4Bnqq3DHxd0
> NtCPXlEh/SDb89YY0yCj9I7D4UJt22WyMG+0Bdzq9Kb5sEWmJXJ5PUapMDmwRhO7
> pKVgP70fPc6+laTGnpXt31rusPy5G+RNsTCbwbWQ8eD2vyv8Ce2DCysou0fb6dIS
> RbXwoqaInt30LhWuEBL9MmseQuZi4lpM2R8+xedvqn4hoCxrEIjTQJxijqe2bcBa
> 7DjxjEvGInrqHsKMir4N0A3TnqJ5X0fLLPzD8IafdA05Q+4Y0nfQ6PCP1c+Sz0fe
> 7pQLz/ZgCfuu/6/kSCEDL0QMS26gTHkJ8X57JncyXjbkGdC4S2JjWAPKHlzo5nme
> sGk9SvoTTaarEJwNmhL6NsK01bXGSd1cJH3jmgj8giqPSiLHYCTOh4qbeOte570/
> I4KDUfrK96EBjKh0HsarhdVylRR6CIYZA7nOzHo0eTHfQXaBzWch6HHzLdszLug/
> HngRqIiJJABFMujipQlQvfniewxLfKmjV+EuTJm+wAFDST4KcioJHrrdnxwLhXj6
> GmWWg8kbYEWUf9TUjUQfACBQfVxyLXYZUGZ7E8l4o5Or1ohU3JdkSVC9iTjWzcW+
> wec1px8VarEebYc+uVW5tDQrl9n96EeWsCA8mZY71nVGJjKANgc=
> =nax3
> -END PGP SIGNATURE-
>

Bug#917294: [libjs-mocha] Does not build like upstream

[Bastien Roucariès]

Package: libjs-mocha
Version: 4.1.0+ds2-2
Severity: grave
control: block 887583 by -1

The libjs-mocha is unusable as is due to be build as udd not as a classical 
module.

Will fix ASAP

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

Bug#901438: bash: enable compile-time syslog shopt

[Luca Boccassi]

On Wed, 2018-11-28 at 17:56 +, Luca Boccassi wrote:
> On Wed, 2018-09-19 at 18:01 +0100, Luca Boccassi wrote:
> > On Wed, 13 Jun 2018 11:40:57 +0100 Luca Boccassi 
> > wrote:
> > > Package: bash
> > > Version: 5.0~alpha1-1
> > > Severity: wishlist
> > > Tags: patch
> > >  
> > > Dear Maintainer,
> > >  
> > > bash 5.0 introduced a new build-time config-top.h option to allow
> > 
> > users
> > > to optionally enable sending the bash history to syslog via a new
> > 
> > shopt
> > > variable.
> > > Given it's generally undesirable on user's machines, even if
> > > compiled
> > > in the feature is off by default at runtime. It can be checked
> > > trivially with "shopt -p | grep syslog".
> > >  
> > > But this feature is often necessary and required on mission
> > > critical
> > > equipment due to auditing rules®ulations. For example in my
> > > case,
> > 
> > to
> > > use vanilla Debian on servers inside a large ISP we need this
> > > option.
> > > Given Debian aims to be a Universal Operating System, it would be
> > > really great if such option were available without having to
> > > rebuild
> > > bash manually. :-)
> > >  
> > > Please consider the inlined diff for the deb-bash-config.diff
> > > patch,
> > > that will build the support but of course will leave it disabled
> > > by
> > > default. I have tested it and it works as expected.
> > >  
> > > Thank you!
> > >  
> > > -- 
> > > Kind regards,
> > > Luca Boccassi
> > >  
> > > --- debian/patches/deb-bash-config.diff
> > > +++ debian/patches/deb-bash-config.diff
> > > @@ -14,6 +14,10 @@
> > >   # DP: 
> > >   # DP: - don't define a default DEFAULT_MAIL_DIRECTORY, because
> > > it
> > >   # DP:   can cause a timeout on NFS mounts.
> > > +# DP: 
> > > +# DP: - build with runtime option to enable sending history to
> > 
> > syslog
> > > +# DP:   and disable it by default. Can be enabled by a user with
> > > +# DP:   shopt -s syslog_history
> > >   
> > >   Index: b/config-bot.h
> > >   ===
> > > ==
> > > ==
> > > @@ -54,3 +58,21 @@
> > >    
> > >    /* Define if you want the case-capitalizing operators (~[~])
> > > and
> > 
> > the
> > >   `capcase' variable attribute (declare -c). */
> > > +@@ -117,7 +117,7 @@
> > > + 
> > > + /* Define if you want each line saved to the history list in
> > 
> > bashhist.c:
> > > +bash_add_history() to be sent to syslog(). */
> > > +-/* #define SYSLOG_HISTORY */
> > > ++#define SYSLOG_HISTORY
> > > + #if defined (SYSLOG_HISTORY)
> > > + #  define SYSLOG_FACILITY LOG_USER
> > > + #  define SYSLOG_LEVEL LOG_INFO
> > > +@@ -128,7 +128,7 @@
> > > +shell option; if defined, the value is the default for the
> > 
> > syslog_history
> > > +shopt option */
> > 
> > Dear Maintainer,
> > 
> > Bash 5.0-beta is out - I've just tested it to make sure this patch
> > still applies and works, and it does.
> > 
> > Would be fantastic if it could be considered for the eventual
> > upload
> > of
> > 5.0-beta.
> > 
> > Thank you!
> 
> Dear Maintainer,
> 
> bash 5.0-beta2 is out, I've tested the above small patch with it and
> I
> can confirm again that it works as expected. It would be great if it
> could be included in the next upload to experimental.
> 
> Thank you!

Dear Maintainer,

Just tested with 5.0-rc1 and it works fine as well. rc1 also fixes the
build failures on armhf/armel BTW.

Thanks and happy holidays!

-- 
Kind regards,
Luca Boccassi

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

Bug#917295: [libjs-mocha] Use browserify

[Bastien Roucariès]

Package: libjs-mocha
Version: 4.1.0+ds2-2
Severity: wishlist
control: block -1 by 780357

Use browserify like upstream please

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

Bug#917243: ghostwriter: Please suggest optional export tools: pandoc discount cmark

[Jonas Smedegaard]

Quoting Sebastien Chavaux (2018-12-25 19:15:57)
> Oki I take care of it with the upgrade to version 1.7.4.

Excellent!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#917296: emacs-gtk: Emacs GNUS can no longer use movemail

[Ronan KERYELL]

Package: emacs-gtk
Version: 1:26.1+1-2
Severity: normal

Dear Maintainer,

Emacs 26.1 just landed into Debian/unstable and it breaks GNUS reading
local e-mail with the '(file)' method because the movemail configuration
changed in 26.1 as explained in the NEWS:

> ** The new option 'configure --with-mailutils' causes Emacs to rely on
> GNU Mailutils to retrieve email.  It is recommended, and is the
> default if GNU Mailutils is installed

This problem seems to have been already discussed last June in
http://permalink.gmane.org/gmane.emacs.gnus.general/88065
but it seems difficult to access this information right now in Gmane.

Since emacs-bin-common depends already on mailutils, configure Emacs
with
'configure --with-mailutils'
should probably fix the problem.

In the meantime, a workaround is to custom-set-variables with
'(mail-source-movemail-program "movemail.mailutils")


Thank you.

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

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common   1:26.1+1-2
ii  emacs-common   1:26.1+1-2
ii  libacl12.2.52-3+b1
ii  libasound2 1.1.7-2
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-3
ii  libcairo-gobject2  1.16.0-2
ii  libcairo2  1.16.0-2
ii  libdbus-1-31.12.12-1
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3
ii  libgdk-pixbuf2.0-0 2.38.0+dfsg-7
ii  libgif75.1.4-3
ii  libglib2.0-0   2.58.1-2
ii  libgnutls303.6.5-2
ii  libgomp1   8.2.0-13
ii  libgpm21.20.7-5
ii  libgtk-3-0 3.24.2-3
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblcms2-2 2.9-3
ii  libm17n-0  1.8.0-2
ii  libmagickcore-6.q16-6  8:6.9.10.14+dfsg-7
ii  libmagickwand-6.q16-6  8:6.9.10.14+dfsg-7
ii  libotf00.9.13-4
ii  libpango-1.0-0 1.42.4-5
ii  libpangocairo-1.0-01.42.4-5
ii  libpng16-161.6.34-2
ii  librsvg2-2 2.44.10-1
ii  libselinux12.8-1+b1
ii  libsm6 2:1.2.2-1+b3
ii  libsystemd0240-1
ii  libtiff5   4.0.10-3
ii  libtinfo6  6.1+20181013-1
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb11.13.1-2
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-2
ii  libxinerama1   2:1.1.4-1
ii  libxml22.9.4+dfsg1-7+b3
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-1

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
pn  emacs-common-non-dfsg  

-- no debconf information

Bug#917297: debhelper: please use version numbers with at least a dot

[Thorsten Glaser]

Package: debhelper
Version: 12
Severity: wishlist

Please release the first version of each major debhelper
not as “12” but as, for example, “12.0”.

Rationale: backporting.

When backporting 12.0 it will be versioned 12.0~bpo9+1,
when backporting 12   it will be versioned 12~bpo9+1.

Version constraints normally read like: debhelper (>= 12~)

Only 12.0~bpo9+1 fulfills this criterium, 12~bpo9+1 doesn’t.
This was a _real_ problem when debhelper 11 first entered
stretch-backports.

Thanks in advance!

Bug#917298: trollsift: Incomplete debian/copyright?

[Chris Lamb]

Source: trollsift
Version: 0.3.1-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Antonio Valentino , 
ftpmas...@debian.org

Hi,

I just ACCEPTed trollsift from NEW but noticed it was missing 
attribution in debian/copyright for at least Martin Raspaud.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#917299: centreon-broker: Incomplete debian/copyright?

[Chris Lamb]

Source: centreon-broker
Version: 18.10.0-3
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Sebastien Delafond , 
ftpmas...@debian.org

Hi,

I just ACCEPTed centreon-broker from NEW but noticed it was missing 
attribution in debian/copyright for at least Andreas Ericsson and Max
Schubert.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#917300: olive: Incomplete debian/copyright?

[Chris Lamb]

Source: olive
Version: 20181130-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: Gürkan Myczko , 
ftpmas...@debian.org

Hi,

I just ACCEPTed olive from NEW but noticed it was missing attribution 
in debian/copyright for at least io/crc32.h.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#799626: RFP: beancount -- command line double-entry bookkeeping system

[Stefano Zacchiroli]

On Mon, Dec 24, 2018 at 07:30:31PM +0200, Martin Michlmayr wrote:
> So this issue was reported and fixed already upstream:
> 
> Here's the original bug report:
> 
> https://bitbucket.org/blais/beancount/issues/341/test_utilsfind_repository_root-doesnt-work

Thanks Martin for finding this, and thanks James for raising it upstream
after last time I tried it out.

I've updated the package to a hg snapshot of today (which includes the
commits with the fix, and more). The source package as it is on salsa
now builds fine on a fresh unstable chroot.

Testing welcome.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Otto Kekäläinen]

ti 25. jouluk. 2018 klo 10.17 Sebastiaan Couwenberg
(sebas...@xs4all.nl) kirjoitti:
>
> On 12/25/18 8:57 AM, Otto Kekäläinen wrote:
> > Can you please provide an actual pbuilder command or something I can
> > copy-paste to reproduce the actual problem (and not just the aptitude
> > symptom)?
>
> Sure:
>
>  sudo cowbuilder --create \
>  --distribution=sid \
>  --basepath=/var/cache/pbuilder/base-sid.cow
>  dget -u \
>   http://deb.debian.org/debian/pool/main/g/gdal/gdal_2.3.3+dfsg-1.dsc
>  cd gdal-2.3.3/
>  dch -nm "Test rebuild"
>  pdebuild --pbuilder cowbuilder -- \
>   --basepath /var/cache/pbuilder/base-sid.cow/
>
> pbuilder will be unstable to install the build dependencies, causing the
> configure target to disable MySQL support despite using the --with-mysql
> option:
>
>MySQL support: no

I cannot reproduce this inside a Docker image (e.g. via Salsa
gitlab-ci.yml) because the operation is too heavy, but basically this
bug report is about how aptitude resolves build dependencies and that
specific part can be reproduced with:

aptitude -y build-dep gdal

This, however, does not result in any problems either.

> Please also answer my questions:
>
> > Isn't the appropriate fix to build libmariadbclient-dev-compat from
> > the mariadb-10.3 instead of 10.1? Aren't you now transitioning from
> > 10.1 to 10.3? And shouldn't mysql-defaults be updated for that too?

Of course, in due time, say 2-3 days after mariadb-10.3 is in unstable.

Bug#917296: emacs-gtk: Emacs GNUS can no longer use movemail

[Sven Joachim]

Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31737
Control: tags -1 + patch

On 2018-12-25 19:43 +0100, Ronan KERYELL wrote:

> Package: emacs-gtk
> Version: 1:26.1+1-2
> Severity: normal
>
> Dear Maintainer,
>
> Emacs 26.1 just landed into Debian/unstable and it breaks GNUS reading
> local e-mail with the '(file)' method because the movemail configuration
> changed in 26.1 as explained in the NEWS:
>
>> ** The new option 'configure --with-mailutils' causes Emacs to rely on
>> GNU Mailutils to retrieve email.  It is recommended, and is the
>> default if GNU Mailutils is installed
>
> This problem seems to have been already discussed last June in
> http://permalink.gmane.org/gmane.emacs.gnus.general/88065
> but it seems difficult to access this information right now in Gmane.
>
> Since emacs-bin-common depends already on mailutils, configure Emacs
> with
> 'configure --with-mailutils'
> should probably fix the problem.

It does not, since Emacs is already configured that way.  In Emacs 26.2,
the issue will be fixed by the patch at[1] which should probably be
cherry-picked for the Debian package.

Cheers,
   Sven


1. 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-26&id=63f1dc4f7c33cc7cc738dbfae3d8192ae448b2f6

Bug#916877: lintian: check that 1.2-3~debXuY changelog stanza follows a 1.2-3 changelog stanza

[Chris Lamb]

Hi Salvatore,

> IIRC this particular change was actually not based on a rebuild of the
> unstable's one but an import of 3.4.2 on top of the previous stretch
> packaging.

Getcha. This sounds like a case that is special enough that it is fine
for Lintian to warn about normally, no?

(I mean, IMHO it's actually sometimes nice to see a Lintian warning
when you are know you are doing something slightly out of the
ordinary, if only for the confirmation that you are doing it as you
intend.)


Regards,

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

Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Sebastiaan Couwenberg]

On 12/25/18 8:12 PM, Otto Kekäläinen wrote:
> ti 25. jouluk. 2018 klo 10.17 Sebastiaan Couwenberg
> (sebas...@xs4all.nl) kirjoitti:
>>
>> On 12/25/18 8:57 AM, Otto Kekäläinen wrote:
>>> Can you please provide an actual pbuilder command or something I can
>>> copy-paste to reproduce the actual problem (and not just the aptitude
>>> symptom)?
>>
>> Sure:
>>
>>  sudo cowbuilder --create \
>>  --distribution=sid \
>>  --basepath=/var/cache/pbuilder/base-sid.cow
>>  dget -u \
>>   http://deb.debian.org/debian/pool/main/g/gdal/gdal_2.3.3+dfsg-1.dsc
>>  cd gdal-2.3.3/
>>  dch -nm "Test rebuild"
>>  pdebuild --pbuilder cowbuilder -- \
>>   --basepath /var/cache/pbuilder/base-sid.cow/
>>
>> pbuilder will be unstable to install the build dependencies, causing the
>> configure target to disable MySQL support despite using the --with-mysql
>> option:
>>
>>MySQL support: no
> 
> I cannot reproduce this inside a Docker image (e.g. via Salsa
> gitlab-ci.yml) because the operation is too heavy, but basically this
> bug report is about how aptitude resolves build dependencies and that
> specific part can be reproduced with:
> 
> aptitude -y build-dep gdal
> 
> This, however, does not result in any problems either.

Have you checked the buildlog to see whether MySQL support is enabled or
not?

Also try building grass, vtk7, or any of the other affected packages.
Both grass & vtk7 FTBFS in my sid pbuilder chroots.

>> Please also answer my questions:
>>
>>> Isn't the appropriate fix to build libmariadbclient-dev-compat from
>>> the mariadb-10.3 instead of 10.1? Aren't you now transitioning from
>>> 10.1 to 10.3? And shouldn't mysql-defaults be updated for that too?
> 
> Of course, in due time, say 2-3 days after mariadb-10.3 is in unstable.

For the record, mysql-defaults (1.0.5) has been uploaded to unstable and
updated to depend on the mariadb-10.3 packages.
default-libmysqlclient-dev now depends on libmariadb-dev-compat instead
of libmariadbclient-dev.

Kind Regards,

Bas

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

Bug#895743: php-elisp package too old

[Ola Lundqvist]

Hi

I thought I had already filed an RFA for this package.

You are most welcome to take it over.

I have too little time to spend on this unfortunately.

But I should really try as the release is closing.

If you have the possibility to take it over I would be grateful.

/ Ola

Sent from a phone

Den sön 23 dec. 2018 10:45Eugen Dedu  skrev:

> Hi Ola,
>
> I use PHP within Emacs.  As far as I know, php-mode (php-elisp) is the
> only Emacs package to provide a PHP mode.  The current version of
> php-elisp in Debian does not even start in Emacs (I use 26.1).  This
> means that currently Emacs in Debian does not support PHP language.
>
> Would it be possible to update the php-elisp package in Debian?
>
> Alternatively, package another recent package providing PHP mode?
>
> Finally, if you do not have time to maintain this Debian package, can
> you orphan it or fill an RFA, cf. https://wiki.debian.org/Orphaning?
>
> Best regards,
> --
> Eugen Dedu
> Associate Professor / Maître de conférences HDR
> OMNI team leader
> FEMTO-ST Institute, Univ. Bourgogne Franche-Comté, CNRS
> Montbéliard, France
> tel. +33 3 81 99 47 75
> http://eugen.dedu.free.fr
>

Bug#917274: task-german: depends on transitional dummy package aspell-de-alt (should be aspell-de-1901)

[Holger Wansing]

Control: tags -1 + pending

Jonas Smedegaard  wrote:
> Package: task-german
> Version: 1:2-31
> Severity: minor
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Package task-german depends on aspell-de-alt, which describes itself as
> a "dummy transitional package" which can be safely removed.
> 
> task-german should instead depend (directly) on aspell-de-1901.

I have removed aspell-de-alt completely.
We don't need such a dictionary for the old orthography in default installations
anymore (it's obsolete for more than 20 years). Thanks for noticing!

Tagging this bug as pending.



Holger


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

Bug#915950: workaround (dconf-service: /var/run/user//dconf/user switches ownership to root:root)

[Dr. A. Stammler]

Problems can be reduced by running a script to check and reset file ownerships 
every minute (/etc/crontab). Some processes (like ‘mate-panel’, 
‘mate-settings-demon’) still need to be killed, though.
#!/bin/bash

LOGTAG="$(basename $0)"

RUN_USER_DIR="/var/run/user"

#PROCESSES_TO_RESTART='mate-panel'

EXITVALUE=0

function test_D_Conf_user_file_permissions {
 DUFLISTING=$(ls -n "$DCONF_USER_FILE")

 #echo "$DUFLISTING"
 read DUFPERMISSIONS DUFLINKS DUFUID DUFGID DUFDETAILS <<<$(echo "$DUFLISTING")
 #echo "user & group: $RUN_UID:$RUN_GID; D Conf file: $DUFUID:$DUFGID"
 logger --tag "$LOGTAG" -p 'user.debug' "user & group: $RUN_UID:$RUN_GID; D 
Conf file: $DUFUID:$DUFGID"

 test "$DUFUID" == "$RUN_UID" -a "$DUFGID" == "$RUN_GID"
} # function test_D_Conf_user_file_permissions

function show_situation {
 top -b -n 1 | sed -e '12,$d'
 free
} # function show_situation

cd "$RUN_USER_DIR"
for RUN_UID in *
do
 if
  #test "$RUN_UID" != '0'
  test $RUN_UID -ge 1000
 then
  RUN_GID="$(id -g $RUN_UID)"
  DCONF_USER_DIR="$RUN_USER_DIR/$RUN_UID/dconf"
  DCONF_USER_FILE="$DCONF_USER_DIR/user"
  
  #ls -al "$DCONF_USER_DIR"

  if
   ! test_D_Conf_user_file_permissions
  then
   #echo -n "→ Permissions seem wrong. "
   #echo "→ Permissions seem wrong; processes accessing $DCONF_USER_DIR:"
   #fuser -v "$DCONF_USER_DIR"

   #echo "→ Trying to reset ownership of $DCONF_USER_FILE…"
   logger --tag "$LOGTAG" -p 'user.notice' "→ Trying to reset ownership of 
$DCONF_USER_FILE…"
   #chown -v "$RUN_UID:$RUN_GID" "$DCONF_USER_FILE"
   chown "$RUN_UID:$RUN_GID" "$DCONF_USER_FILE"

   #echo '→'
   #killall -v -SIGHUP $PROCESSES_TO_RESTART

   if
! test_D_Conf_user_file_permissions
   then
#echo '* ERROR: could not reset ownership.'
logger --tag "$LOGTAG" -p 'user.crit' '* could not reset ownership.'
EXITVALUE=1
   fi
  #else
   #echo '→ Permissions seem fine; no action taken.'
  fi
 #else
  ##echo "Super user (UID $RUN_UID) ignored."
  #echo "System user (UID $RUN_UID) ignored."
 fi
 #echo
done

#echo '⇒'
#show_situation
#echo

exit $EXITVALUE


signature.asc
Description: PGP signature

Bug#916834: freshplayerplugin: FTBFS on big-endian architectures: test fails

[Rinat Ibragimov]

I believe that the issue is addressed in the attached patch.
(Already applied in the upstream repository).

--
Rinat
From 58596f4745190654cff4a5ad6a2bd4ac37b74800 Mon Sep 17 00:00:00 2001
From: Rinat Ibragimov 
Date: Tue, 25 Dec 2018 22:22:41 +0300
Subject: [PATCH] tests: use uint16_t for UTF-16 code points in charset test

Charset-related APIs are using 16-bit uint16_t when referring to UTF-16,
and are not obligated to have any particular byte layout in memory. Those
are different for little- and big-endian machines, which caused test to
fail when compiling on mips and s390x.
---
 tests/test_ppb_char_set.c | 40 ++-
 1 file changed, 18 insertions(+), 22 deletions(-)

diff --git a/tests/test_ppb_char_set.c b/tests/test_ppb_char_set.c
index 8163b2dc..bb25d3f6 100644
--- a/tests/test_ppb_char_set.c
+++ b/tests/test_ppb_char_set.c
@@ -43,8 +43,8 @@ TEST(ppb_char_set, extract_relevant_part_from_locale_name)
 TEST(ppb_char_set, to_utf16_all_ASCII)
 {
 const char *in = "Hello, world!";
-const uint8_t out[] = {'H', 0, 'e', 0, 'l', 0, 'l', 0, 'o', 0, ',', 0, ' ', 0, 'w', 0,
-   'o', 0, 'r', 0, 'l', 0, 'd', 0, '!', 0};
+const uint16_t out[] = {'H', 'e', 'l', 'l', 'o', ',', ' ',
+'w', 'o', 'r', 'l', 'd', '!'};
 uint32_t res_len = ;
 uint16_t *res = ppb_char_set_char_set_to_utf16(0, in, strlen(in), "UTF-8",
PP_CHARSET_CONVERSIONERROR_FAIL, &res_len);
@@ -56,9 +56,8 @@ TEST(ppb_char_set, to_utf16_all_ASCII)
 TEST(ppb_char_set, to_utf16_basic_UTF_8)
 {
 const char *in = "Привет, мир!";
-const uint8_t out[] = {0x1f, 0x04, 0x40, 0x04, 0x38, 0x04, 0x32, 0x04, 0x35, 0x04,
-   0x42, 0x04, 0x2c, 0x00, 0x20, 0x00, 0x3c, 0x04, 0x38, 0x04,
-   0x40, 0x04, 0x21, 0x00};
+const uint16_t out[] = {0x41f, 0x440, 0x438, 0x432, 0x435, 0x442,
+0x2c,  0x20,  0x43c, 0x438, 0x440, 0x21};
 uint32_t res_len = ;
 uint16_t *res = ppb_char_set_char_set_to_utf16(0, in, strlen(in), "UTF-8",
PP_CHARSET_CONVERSIONERROR_FAIL, &res_len);
@@ -83,8 +82,7 @@ TEST(ppb_char_set, to_utf16_wrong_UTF_8_with_error)
 
 TEST(ppb_char_set, from_utf16_all_ASCII)
 {
-const uint8_t in[] = {'H', 0, 'e', 0, 'l', 0, 'l', 0, 'o', 0, ',', 0, ' ', 0, 'w', 0,
-  'o', 0, 'r', 0, 'l', 0, 'd', 0, '!', 0};
+const uint16_t in[] = {'H', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o', 'r', 'l', 'd', '!'};
 const char *out = "Hello, world!";
 uint32_t res_len = ;
 char *res = ppb_char_set_utf16_to_char_set(0, (const uint16_t *)in,
@@ -97,9 +95,8 @@ TEST(ppb_char_set, from_utf16_all_ASCII)
 
 TEST(ppb_char_set, to_utf16_non_ASCII_all_correct)
 {
-const uint8_t in[] = {0x1f, 0x04, 0x40, 0x04, 0x38, 0x04, 0x32, 0x04, 0x35, 0x04,
-  0x42, 0x04, 0x2c, 0x00, 0x20, 0x00, 0x3c, 0x04, 0x38, 0x04,
-  0x40, 0x04, 0x21, 0x00}; // "Привет, мир!"
+const uint16_t in[] = {0x41f, 0x440, 0x438, 0x432, 0x435, 0x442, 0x2c,
+   0x20,  0x43c, 0x438, 0x440, 0x21};  // "Привет, мир!"
 const char *out = "\xcf\xf0\xe8\xe2\xe5\xf2\x2c\x20\xec\xe8\xf0\x21"; // "Привет, мир!"
 uint32_t res_len = ;
 char *res = ppb_char_set_utf16_to_char_set(0, (const uint16_t *)in,
@@ -112,9 +109,9 @@ TEST(ppb_char_set, to_utf16_non_ASCII_all_correct)
 
 TEST(ppb_char_set, to_utf16_non_ASCII_PP_CHARSET_CONVERSIONERROR_FAIL)
 {
-const uint8_t in[] = {0x1f, 0x04, 0x40, 0x04, 0x38, 0x04, 0x32, 0x04, 0x35, 0x04,
-  0x42, 0x04, 0x2c, 0x00, 0x20, 0x00, 0x6b, 0x26, 0x3c, 0x04,
-  0x38, 0x04, 0x40, 0x04, 0x21, 0x00}; // "Привет, ♫мир!"
+const uint16_t in[] = {0x41f, 0x440,  0x438, 0x432, 0x435, 0x442, 0x2c,
+   0x20,  0x266b, 0x43c, 0x438, 0x440, 0x21};
+// "♫" in "Привет, ♫мир!" cannot be represented in cp1251.
 // const char *out = "\xcf\xf0\xe8\xe2\xe5\xf2\x2c\x20\xec\xe8\xf0\x21"; // "Привет, мир!"
 uint32_t res_len = ;
 char *res = ppb_char_set_utf16_to_char_set(0, (const uint16_t *)in,
@@ -127,9 +124,9 @@ TEST(ppb_char_set, to_utf16_non_ASCII_PP_CHARSET_CONVERSIONERROR_FAIL)
 
 TEST(ppb_char_set, to_utf16_non_ASCII_PP_CHARSET_CONVERSIONERROR_SKIP)
 {
-const uint8_t in[] = {0x1f, 0x04, 0x40, 0x04, 0x38, 0x04, 0x32, 0x04, 0x35, 0x04,
-  0x42, 0x04, 0x2c, 0x00, 0x20, 0x00, 0x6b, 0x26, 0x3c, 0x04,
-  0x38, 0x04, 0x40, 0x04, 0x21, 0x00}; // "Привет, ♫мир!"
+const uint16_t in[] = {
+0x41f, 0x440,  0x438, 0x432, 0x435, 0x442, 0x2c,
+0x20,  0x266b, 0x43c, 0x438, 0x440, 0x21};  // "Привет, ♫мир!"
 const char *out = "\xcf\xf0\xe8\xe2\xe5\xf2\x2c\x20\xec\xe8\xf0\x21"; // "Привет, мир!"
 uint32_t res_len = ;
 ch

Bug#917193: wpasupplicant: missing newline character in error message

[Vincent Lefevre]

On 2018-12-24 09:52:58 +0100, Andrej Shadura wrote:
> On Sun, 23 Dec 2018 at 23:54, Vincent Lefevre  wrote:
> > I got the following error (via wicd logs):
> >
> > 2018/12/23 22:11:27 :: wpa_cli -i wlp61s0 terminate
> > Failed to connect to non-global ctrl_ifname: wlp61s0  error: No such file 
> > or directory
> >
> > This should have been:
> >
> > Failed to connect to non-global ctrl_ifname: wlp61s0
> > error: No such file or directory
> 
> Thanks for reporting this and the other bug. Could you please try 2.7
> from experimental?

I still get the error message in bad format, but the error message
now appears only in the system logs (journalctl).

For the connection failure itself, I don't know yet. This may be a bug
in wpasupplicant as I have no issue with Android.

Here are the full logs:

Dec 25 20:39:44 zira kernel: IPv6: ADDRCONF(NETDEV_UP): wlp61s0: link is not 
ready
Dec 25 20:39:44 zira wicd[779]: Failed to connect to non-global ctrl_ifname: 
wlp61s0  error: No such file or directory
Dec 25 20:39:44 zira wicd[779]: Error for wireless request "Set Bit Rate" 
(8B20) :
Dec 25 20:39:44 zira wicd[779]: invalid argument "NoneM".
Dec 25 20:39:47 zira kernel: wlp61s0: authenticate with 00:1f:33:89:73:4e
Dec 25 20:39:47 zira kernel: wlp61s0: send auth to 00:1f:33:89:73:4e (try 1/3)
Dec 25 20:39:47 zira kernel: wlp61s0: authenticated
Dec 25 20:39:47 zira kernel: wlp61s0: aborting association with 
00:1f:33:89:73:4e by local choice (Reason: 3=DEAUTH_LEAVING)
Dec 25 20:39:47 zira kernel: wlp61s0: authenticate with 00:1f:33:89:73:4e
Dec 25 20:39:47 zira kernel: wlp61s0: send auth to 00:1f:33:89:73:4e (try 1/3)
Dec 25 20:39:47 zira kernel: wlp61s0: aborting authentication with 
00:1f:33:89:73:4e by local choice (Reason: 3=DEAUTH_LEAVING)
Dec 25 20:39:47 zira kernel: wlp61s0: authenticate with 00:1f:33:89:73:4e
Dec 25 20:39:47 zira kernel: wlp61s0: send auth to 00:1f:33:89:73:4e (try 1/3)
Dec 25 20:39:47 zira kernel: wlp61s0: send auth to 00:1f:33:89:73:4e (try 2/3)
Dec 25 20:39:47 zira kernel: wlp61s0: authenticated
Dec 25 20:39:47 zira kernel: wlp61s0: associate with 00:1f:33:89:73:4e (try 1/3)
Dec 25 20:39:47 zira kernel: wlp61s0: RX AssocResp from 00:1f:33:89:73:4e 
(capab=0x401 status=0 aid=5)
Dec 25 20:39:47 zira kernel: wlp61s0: associated
Dec 25 20:39:57 zira kernel: wlp61s0: deauthenticating from 00:1f:33:89:73:4e 
by local choice (Reason: 3=DEAUTH_LEAVING)

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

Bug#917293: kinit: The kdeinit5 consumes and takes about 3 ~ 5 minutes to give me control of the environment.

[Lisandro Damián Nicanor Pérez Meyer]

El mar., 25 dic. 2018 14:51, Santiago José López Borrazás 
escribió:

> Package: kinit
> Version: 5.51.0-1
> Severity: important
>
> Dear Maintainer,
>
> When I want to enter the KDE, it takes me a lot to finish the session. It
> consumes CPU and it takes, like an average of between 3 and 5 minutes to
> give me session control.
>
> I have tried creating another user and do the same.



Just a wild guess: is your loopback interface working?

Bug#917280: kernel panic on intel gen4 gfx card

[Ben Hutchings]

On Tue, 2018-12-25 at 15:45 +, ? ? wrote:
> Hi, Greg
> 
> I found on Debian testing with kernel 4.18.20 fail boot, kernel panic
> on i915. and reported it to Debian bug 917280 [0], with panic log[1].
> 
> after revert:
> 
> commit 06e562e7f515292ea7721475950f23554214adde
> Author: Chris Wilson 
> Date:   Mon Nov 5 09:43:05 2018 +
> 
> drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5
> 
> System boots to desktop.
> 
> [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917280
> [1]:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=917280;filename=dmesg.txt;msg=10

The 4.18 stable branch is no longer maintained.

I suspect this is the same as  and
, which is fixed
in 4.19 (currently in unstable).

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.



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

Bug#917234: [initramfs-tools] Unable to detect root device

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2018-12-24 at 15:05 +0100, Paul Menzel wrote:
> Package: initramfs-tools
> Version: 0.132
> Severity: normal
> 
> Dear Debian folks,
> 
> 
> Updating the Linux kernel package fails with the error below.
[...]

I think this is bug #917124.  Try downgrading udev to version 239-15
(still in testing).

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.



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

Bug#917261: linux-image-4.19.0-1-amd64: /dev/mapper symlink for dm-crypt volume containing / not created on system startup

[Ben Hutchings]

Control: reassign -1 udev 240-1
Control: forcemerge 917124 -1

This seems to be a bug in udev, not the kernel.  You will only have
noticed it once you rebooted for the kernel upgrade.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.



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

Bug#916899: linux-image-4.18.0-0.bpo.3-amd64: NULL pointer dereference in i915

[Ben Hutchings]

Control: forcemerge 914495 -1

This is fixed in Linux 4.19, currently available in unstable.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.



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

Bug#917301: [src:node-timers-browserify] use browserify

[Bastien Roucariès]

Package: src:node-timers-browserify
Version: 2.0.6+dfsg-1
Severity: normal
control: block -1 by 780357

Like upstream we should use browserify instead of browserify-lite


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

Bug#901289: breaks boot in containers

[Adam Borowski]

On Tue, Dec 25, 2018 at 01:39:22PM +, Dmitry Bogatov wrote:
> [2018-12-23 22:58] Adam Borowski 
> > Uh oh...  looks like the logsave issue suddenly became RCish: it
> > prevents lxc containers from booting unattended:

> I can propose following ad-hoc solution. Objections? Better suggestions?

> +++ b/debian/src/initscripts/etc/init.d/checkfs.sh

> +# This function does not actually belong here; it is duct-tape solution
> +# for #901289.
> +logsave_best_effort () {
> + if [ -x /sbin/logsave ] ; then
> + logsave -s "${FSCK_LOGFILE}" "$@"
> + else
> + "$@"
> + fi
> +}

The other option is to ship our own implementation of logsave -- it's a
single-C-file tool, and initscripts is already arch:any.  On the other hand,
it would add some bloat to a mandatory package, and make it harder to
convert to arch:all later.

So I'm not objecting to your solution.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#917297: debhelper: please use version numbers with at least a dot

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Tue, Dec 25, 2018 at 06:50:08PM +, Thorsten Glaser wrote:
> Please release the first version of each major debhelper
> not as “12” but as, for example, “12.0”.
> 
> Rationale: backporting.
> 
> When backporting 12.0 it will be versioned 12.0~bpo9+1,
> when backporting 12   it will be versioned 12~bpo9+1.
> 
> Version constraints normally read like: debhelper (>= 12~)
> 
> Only 12.0~bpo9+1 fulfills this criterium, 12~bpo9+1 doesn’t.

That's not true:

mattia@warren ~ % dpkg --compare-versions 12~bpo9+1 gt 12~ && echo true
true


> This was a _real_ problem when debhelper 11 first entered
> stretch-backports.

The issue back then was because people used "debhelper (>= 11)" without
the trailing ~ (I know I didn't as well, and I keep not using it tbh).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#917293: kinit: The kdeinit5 consumes and takes about 3 ~ 5 minutes to give me control of the environment.

[Santiago José López Borrazás]

El 25/12/18 a las 21:07, Lisandro Damián Nicanor Pérez Meyer escribió:
>
> Just a wild guess: is your loopback interface working?

No. I am using XDM, to enter directly to KDE.

-- 
Saludos de Santiago José López borrazás.

Bug#917277: epstool: incorrect bounding box calculated

[Russell Lang]

David,

The input file has
  %%BoundingBox: 71 540 176 721
epstool 3.09 calculates this
  %%BoundingBox: 71 541 172 721

This looks like the correct bounding box.

Russell

On Wed, 26 Dec 2018 at 00:09, David Bremner  wrote:

> Package: epstool
> Version: 3.09-1
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> epstool calculates a very wide bounding box for the attached eps
> file. The result is so wide that TeX cannot include it, which breaks
> the sketch build. It would be great if epstool could be fixed so that
> I can unbreak sketch.
>
>
> - -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_CA:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages epstool depends on:
> ii  ghostscript  9.26~dfsg-1
> ii  libc62.28-2
>
> epstool recommends no packages.
>
> epstool suggests no packages.
>
> - -- no debconf information
>
> -BEGIN PGP SIGNATURE-
>
> iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlwiJQcACgkQ8gKXHaSn
> nizRvwv+IsSn/eyBudkFuL0UNsAz6l1lq69IZePHjIOEeJJNpdgsed/I31uduBGk
> q/pvIBhcgSjwuIdBZJMz6iUc2s+6hBNSf5dHuykrNxrRRdANg2g8Iacy1nv6OmxA
> qNtfcgple5juCAM9vc8LyEX5DIwVBoeFIIL+fdeG/OdQsaLecQ7+b5hs9gM9A0e7
> wAmXj8QuCkBftpoL49EfPPWjL/QC6G3bWaO8BiUXS5gOavsj793dOkYt/+jIrH/E
> Toc4zHJsl5vK4gl7MApSs/G/5ETKtGblY0m/50dykW258ThbISNZRqdxiN4d4mj2
> yjqz84mYc6u7AjntshyruSH0xy2lBSxJCyuzYLYXt83+dNTludHrVkgs3ezxg/LK
> GzJBP3xyWRUafte1NShXpS8BGp62+kHH+jB8235FHYPM3xilLG1PoN1PJ19xptF4
> ir5MwlE8NYd4KgD1Mrdg5/qJeuMEvSoliVEXIriIgoYnE0bkNSNL3gX0yY8FH5L8
> s3fLs8VY
> =8EgG
> -END PGP SIGNATURE-
>

Bug#917302: java common creates a hidden etc/.java directory

[shirish शिरीष]

Package: java-common
Version: 0.70
Severity: normal

Dear Maintainer,
According to cruft/cruft-ng java-common creates a hidden /etc/.java
directory. I came to know about it using rkhunter where it showed up
as a suspicious package. Asking on the debian-java ML came to know it
is due to java-common package
https://lists.debian.org/debian-java/2018/12/msg00010.html

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

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

java-common depends on no packages.

java-common recommends no packages.

Versions of packages java-common suggests:
ii  default-jre  2:1.11-70

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8