Bug#950829: ITP: ansible-runner -- Python Library to interfacing with Ansible

[Sakirnth Nagarasa]

Package: wnpp
Owner: sakir...@gmail.com

* Package name: ansible-runner
  Upstream Author : ansible-runner contributors
* License : Apache License
  Description : Python-Library helps interfacing with Ansible

  Ansible Runner is a tool and python library that helps when
  interfacing with Ansible directly or as part of another system whether
  that be through a container image interface, as a standalone tool, or
  as a Python module that can be imported.

Greetings,
Sakirnth (Saki)

Bug#949665: mtools: please support operating on large files

[Chris Lamb]

Hi all,

> Thank you. I wasn't aware of AC_SYS_LARGEFILE. Thanks to Pali Rohár for
> pointing this out. I confirm that after adding it to configure.in, my
> proposed testcase succeeds on armhf. (It also is nice that I can just
> cross build mtools from amd64 out of the box to test for this.) Please
> add AC_SYS_LARGEFILE to configure.in.

Happy to add this in Debian, just wondering if upstream could bless this
change prior to that?


Best wishes,

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

Bug#950821: RFP: peertube -- decentralized federated video platform

[Dmitry Smirnov]

On Friday, 7 February 2020 5:28:39 PM AEDT Xavier wrote:
> I can help for the node.js part (means replacing `yarn install`)

That would be fantastic. Thanks. Let's see what we can do together?

I've made a repository with a very early draft:

  https://salsa.debian.org/debian/peertube

-- 
Regards,
 Dmitry Smirnov.

---

It is a fine thing to be honest, but it is also very important to be right.
-- Winston Churchill


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

Bug#950516: file: please backport 5.38 to stable for removal of python2

[Christoph Biedl]

Felix Lechner wrote...

> A backport is sufficient. I tried to indicate that in the bug title,
> but perhaps it was not clear.

Yeah, or something else confused me. Sorry if I appeared stubborn, I
just want to understand what I do.

One more idea: After checking the upstream sources: The file package as
in Debian 10 ("buster") is supposed to detect "python 3.7 byte-compiled"
but the magic is plain broen. So I will cherry-pick the fix¹ for the
next stable point release anyway. Out of curiosity, was that sufficient
for your request as well, or will you need support for Python 3.8 as
well², now or at least before the Debian 11 ("bullseye") release?


About a backport:

> > >> About (1), I am be happy to provide and extensively test such a
> > >> backport, but will not upload for non-technical reasons.
>
> Please let me know if the technical reasoning needs further explanation.

The technical part shouldn't be a problem - creating backport-friendly
packages is one of my major objectives in packaging. I just need
someone who is willing to do the upload.

All the best,

Christoph

¹ https://github.com/file/file/commit/ca3bb5a0b1545d7bfe5e38c8b7f0d8975e7ec731
² Which is not available yet but that will certainly change soon.



signature.asc
Description: PGP signature

Bug#950822: systemd-sysusers hangs if nis is enabled in a systemd-nspawn container

[Ryutaroh Matsumoto]

> Do you have nscd installed inside the container (looking at the strace
> it appears you might have not).

I installed "unscd" instead of "nscd", as "unscd" is said to be less buggy.

> Is nscd installed outside of the container where you don't see the problem?

The host running container also uses "unscd".
Its log is as below. Interestingly, I do not find TCP communication to
the Sun RPC port 111... Why???
Some error message is in Japanese as the default locale is ja.

Regarding on NIS configuration, the container and the host running the
container seem almost the same to me...
The host is Ubuntu 19.10, but it may not be related to this issue...

Anyway, I have to leave my office now.
So I cannot provide futher information until Monday morning...

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=10s
Environment=SYSTEMD_LOG_LEVEL=debug
ExecStart=/usr/bin/strace -T -yy -D -f /bin/systemd-sysusers


Feb 07 16:03:39 quadrop5000 strace[418]: /usr/bin/strace: Process 418 attached
Feb 07 16:03:39 quadrop5000 strace[418]: execve("/bin/systemd-sysusers", 
["/bin/systemd-sysusers"], 0x7ffe3b561190 /* 5 vars */) = 0 <0.151095>
Feb 07 16:03:39 quadrop5000 strace[418]: brk(NULL)  
 = 0x557f4a51b000 <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: arch_prctl(0x3001 /* ARCH_??? */, 
0x7fff6e4c41a0) = -1 EINVAL (無効な引数です) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: access("/etc/ld.so.preload", R_OK) 
 = -1 ENOENT (そのようなファイルやディレクトリはありません) <0.09>
Feb 07 16:03:39 quadrop5000 strace[418]: openat(AT_FDCWD, 
"/lib/systemd/tls/haswell/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(そのようなファイルやディレクトリはありません) <0.08>
Feb 07 16:03:39 quadrop5000 strace[418]: 
stat("/lib/systemd/tls/haswell/x86_64", 0x7fff6e4c33f0) = -1 ENOENT 
(そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: openat(AT_FDCWD, 
"/lib/systemd/tls/haswell/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: stat("/lib/systemd/tls/haswell", 
0x7fff6e4c33f0) = -1 ENOENT (そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: openat(AT_FDCWD, 
"/lib/systemd/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: stat("/lib/systemd/tls/x86_64", 
0x7fff6e4c33f0) = -1 ENOENT (そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: openat(AT_FDCWD, 
"/lib/systemd/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: stat("/lib/systemd/tls", 
0x7fff6e4c33f0) = -1 ENOENT (そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: openat(AT_FDCWD, 
"/lib/systemd/haswell/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: stat("/lib/systemd/haswell/x86_64", 
0x7fff6e4c33f0) = -1 ENOENT (そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: openat(AT_FDCWD, 
"/lib/systemd/haswell/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: stat("/lib/systemd/haswell", 
0x7fff6e4c33f0) = -1 ENOENT (そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: openat(AT_FDCWD, 
"/lib/systemd/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: stat("/lib/systemd/x86_64", 
0x7fff6e4c33f0) = -1 ENOENT (そのようなファイルやディレクトリはありません) <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: openat(AT_FDCWD, 
"/lib/systemd/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(そのようなファイルやディレクトリはありません) <0.07>
Feb 07 16:03:39 quadrop5000 strace[418]: stat("/lib/systemd", 
{st_mode=S_IFDIR|0755, st_size=2148, ...}) = 0 <0.06>
Feb 07 16:03:39 quadrop5000 strace[418]: openat(AT_FDCWD, "/etc/ld.so.cache", 
O_RDONLY|O_CLOEXEC) = 3 <0.06>
Feb 07 16:03:39 quadrop5000 strace[418]: fstat(3, 
{st_mode=S_IFREG|0644, st_size=67652, ...}) = 0 <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: mmap(NULL, 67652, PROT_READ, 
MAP_PRIVATE, 3, 0) = 0x7f30e04eb000 <0.06>
Feb 07 16:03:39 quadrop5000 strace[418]: close(3) 
 = 0 <0.04>
Feb 07 16:03:39 quadrop5000 strace[418]: openat(AT_FDCWD, 
"/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 
3 <0.07>
Feb 07 16:03:39 quadrop5000 strace[418]: 
read(3, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360r\2\0\0\0\0\0"..., 832) = 
832 <0.06>
Feb 07 16:03:39 quadrop5000 strace[418]: 
lseek(3, 64, SEEK_SET) = 64 <0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: 
read(3, 
"\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784) = 784 
<0.05>
Feb 07 16:03:39 quadrop5000 strace[418]: 
lseek(3, 848, SEEK_SET) = 848 <0.04>
Feb 07 16:03:39 quadrop5000 strace[418]: 
read(3, 

Bug#950822: systemd-sysusers hangs if nis is enabled in a systemd-nspawn container

[Ryutaroh Matsumoto]

The container is started as
systemd-nspawn -M bullseye --network-macvlan=eno1 -b

The option --network-macvlan=eno1 is necessary so that the container
can talk with the NIS server running on a third computer (not a container
nor the host running the container).

Ryutaroh

From: Ryutaroh Matsumoto 
Subject: Re: Bug#950822: systemd-sysusers hangs if nis is enabled in a 
systemd-nspawn container
Date: Fri, 07 Feb 2020 15:54:54 +0900 (JST)

> Hi Michael,
> Thank you for paying attention to this.

Bug#950822: systemd-sysusers hangs if nis is enabled in a systemd-nspawn container

[Michael Biebl]

Do you have nscd installed inside the container (looking at the strace
it appears you might have not).
Does it help if you install nscd?
Is nscd installed outside of the container where you don't see the problem?



signature.asc
Description: OpenPGP digital signature

Bug#950822: systemd-sysusers hangs if nis is enabled in a systemd-nspawn container

[Ryutaroh Matsumoto]

Hi Michael,
Thank you for paying attention to this.

> Do you have users/groups defined in
> /usr/lib/sysusers.d/ or /etc/sysusers.d which are only resolvable via NIS?

The above directories are untouched. The container was made by
mmdebstrap --variant=debootstrap bullseye.
/etc/passwd nor /etc/group is not modified manually except changing root 
password.
No new user or group is added manually.

> Can you run
> SYSTEMD_LOG_LEVEL=debug /bin/systemd-sysusers
> inside the container
> If that hangs as well, please attach the output.
> An strace might be helpful as well.

I made the following /etc/systemd/system/systemd-sysusers.service

[Unit]
Description=Create System Users
Documentation=man:sysusers.d(5) man:systemd-sysusers.service(8)
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-remount-fs.service
Before=sysinit.target shutdown.target systemd-update-done.service
ConditionNeedsUpdate=/etc

[Service]
Type=oneshot
RemainAfterExit=yes
Environment=SYSTEMD_LOG_LEVEL=debug
ExecStart=/usr/bin/strace -T -yy -D -f /bin/systemd-sysusers
TimeoutSec=10s

/etc/nsswitch.conf is as follows:
passwd: files systemd nis
group:  files systemd nis
shadow: files nis
gshadow:files nis

hosts:  files dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis


After logging in as root, journalctl -u systemd-sysusers shows the following.
It seems that systemd-sysusers tries to write 127.0.0.1:111 (Sun RPC),
and gets stuck. It is clear that no rpcbind.service or nis is running when
systemd-sysusers is called by systemd. I have no idea what is "wrong".

-- Reboot --
Feb 07 15:38:54 bullseye strace[23]: /usr/bin/strace: Process 19 attached
Feb 07 15:38:54 bullseye strace[23]: execve("/bin/systemd-sysusers", 
["/bin/systemd-sysusers"], 0x7ffee6748880 /* 5 vars */) = 0 <0.000155>
Feb 07 15:38:54 bullseye strace[23]: brk(NULL)   = 
0x5574832f <0.08>
Feb 07 15:38:54 bullseye strace[23]: access("/etc/ld.so.preload", R_OK)  = 
-1 ENOENT (No such file or directory) <0.10>
Feb 07 15:38:54 bullseye strace[23]: openat(AT_FDCWD, 
"/lib/systemd/tls/haswell/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory) <0.09>
Feb 07 15:38:54 bullseye strace[23]: stat("/lib/systemd/tls/haswell/x86_64", 
0x7ffc6405e590) = -1 ENOENT (No such file or directory) <0.08>
Feb 07 15:38:54 bullseye strace[23]: openat(AT_FDCWD, 
"/lib/systemd/tls/haswell/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory) <0.08>
Feb 07 15:38:54 bullseye strace[23]: stat("/lib/systemd/tls/haswell", 
0x7ffc6405e590) = -1 ENOENT (No such file or directory) <0.07>
Feb 07 15:38:54 bullseye strace[23]: openat(AT_FDCWD, 
"/lib/systemd/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory) <0.08>
Feb 07 15:38:54 bullseye strace[23]: stat("/lib/systemd/tls/x86_64", 
0x7ffc6405e590) = -1 ENOENT (No such file or directory) <0.07>
Feb 07 15:38:54 bullseye strace[23]: openat(AT_FDCWD, 
"/lib/systemd/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory) <0.08>
Feb 07 15:38:54 bullseye strace[23]: stat("/lib/systemd/tls", 0x7ffc6405e590) = 
-1 ENOENT (No such file or directory) <0.07>
Feb 07 15:38:54 bullseye strace[23]: openat(AT_FDCWD, 
"/lib/systemd/haswell/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory) <0.08>
Feb 07 15:38:54 bullseye strace[23]: stat("/lib/systemd/haswell/x86_64", 
0x7ffc6405e590) = -1 ENOENT (No such file or directory) <0.07>
Feb 07 15:38:54 bullseye strace[23]: openat(AT_FDCWD, 
"/lib/systemd/haswell/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
or directory) <0.08>
Feb 07 15:38:54 bullseye strace[23]: stat("/lib/systemd/haswell", 
0x7ffc6405e590) = -1 ENOENT (No such file or directory) <0.07>
Feb 07 15:38:54 bullseye strace[23]: openat(AT_FDCWD, 
"/lib/systemd/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
or directory) <0.08>
Feb 07 15:38:54 bullseye strace[23]: stat("/lib/systemd/x86_64", 
0x7ffc6405e590) = -1 ENOENT (No such file or directory) <0.07>
Feb 07 15:38:54 bullseye strace[23]: openat(AT_FDCWD, "/lib/systemd/libc.so.6", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.08>
Feb 07 15:38:54 bullseye strace[23]: stat("/lib/systemd", 
{st_mode=S_IFDIR|0755, st_size=1828, ...}) = 0 <0.08>
Feb 07 15:38:54 bullseye strace[23]: openat(AT_FDCWD, "/etc/ld.so.cache", 
O_RDONLY|O_CLOEXEC) = 3 <0.08>
Feb 07 15:38:54 bullseye strace[23]: fstat(3, 
{st_mode=S_IFREG|0644, st_size=12490, ...}) = 0 <0.07>
Feb 07 15:38:54 bullseye strace[23]: mmap(NULL, 12490, PROT_READ, MAP_PRIVATE, 
3, 0) = 0x7fd6e7a7b000 <0.08>
Feb 07 15:38:54 bullseye strace[23]: close(3)  = 
0 <0.07>
Feb 07 15:38:54 bullseye strace[23]: openat(AT_FDCWD, 

Bug#950828: python-xarray: FTBFS (No such kernel named python3)

[Bas Couwenberg]

Source: python-xarray
Version: 0.15.0-1
Severity: serious
Justification: makes the package in question unusable or mostly so
Control: tags -1 ftbfs

Dear Maintainer,

While doing a test rebuild to triage #950743 your package FTBFS:

 building [html]: targets for 36 source files that are out of date
 updating environment: 1088 added, 0 changed, 0 removed
 reading sources... [  0%] README
 reading sources... [  0%] api
 reading sources... [  0%] api-hidden
 reading sources... [  0%] combining
 reading sources... [  0%] computation
 reading sources... [  0%] contributing
 reading sources... [  0%] dask
 reading sources... [  0%] data-structures
 reading sources... [  0%] examples
 reading sources... [  0%] examples/ERA5-GRIB-example
 
 Notebook error:
 NoSuchKernel in examples/ERA5-GRIB-example.ipynb:
 No such kernel named python3
 make[2]: *** [Makefile:57: html] Error 2
 make[2]: Leaving directory '/build/python-xarray-0.15.0/doc'

You can see the same in the reproducible builds logs:

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

There is no buildlog on the buildd for this version which suggests that it was 
not built there.

The git repo has also not been updated with the changes for 0.15.0-1.

Kind Regards,

Bas

Bug#950821: RFP: peertube -- decentralized federated video platform

[Xavier]

Le 07/02/2020 à 01:54, Dmitry Smirnov a écrit :
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org, 
> debian-multime...@lists.debian.org, 
> pkg-javascript-de...@lists.alioth.debian.org
> 
>Package name: peertube
> Version: 2.0.0
> License: AGPL-3+
> URL: https://github.com/Chocobozzz/PeerTube
> Description: decentralized federated video platform
>  PeerTube is a decentralized and federated video platform developed as an
>  alternative to other platforms that centralize our data and attention,
>  such as YouTube, Dailymotion or Vimeo. All servers of PeerTube are
>  interoperable as a federated network, and non-PeerTube servers can be part
>  of the larger Vidiverse (federated video network) by talking our
>  implementation of ActivityPub. Video load is reduced thanks to P2P
>  (BitTorrent) in the web browser via WebTorrent.

Hi,

I can help for the node.js part (means replacing `yarn install`)

Cheers,
Xavier

Bug#860939: [Pkg-javascript-devel] Remove unmaintained package

[Xavier]

Le 14/08/2019 à 11:28, Xavier a écrit :
> Le 14/08/2019 à 07:37, Xavier a écrit :
>> Le 09/08/2019 à 07:22, Xavier a écrit :
>>> Le 08/08/2019 à 18:25, Xavier a écrit :
 Le 08/08/2019 à 09:31, Xavier a écrit :
> Le 08/08/2019 à 08:09, Xavier a écrit :
>> Le 08/08/2019 à 07:24, Xavier a écrit :
>>> Le 08/08/2019 à 07:11, Xavier a écrit :
 Hi,

 looking at UDD, we have a some packages that were not in testing for a
 long time and could be considered as orphaned.
 If nobody disagree, I'll ask their removal:
>>>
>>> Update:
>>

>>> New update:
>>
>> Hi all,
>>
>> I'm going to ask removal of:
> 
> ROM-RM done:
>PACKAGETIME IN QUEUE RDEPS
>  * node-yawl1472 days, no dependencies
>  * jscommunicator   1406 days, no dependencies
>  * libv8-3.14939 days, ROM-RM: uwsgi-plugin-v8
> 
> Seems usable and maintained upstream
>PACKAGETIME IN QUEUE RDEPS
>  * html2canvas   969 days, no dependencies
>  * validator.js  932 days, no dependencies
> 
> Updated:
>  * node-stream-to-observable (missing little dependency added as
>   component)
>  * node-postcss-load-options
>  * node-postcss-load-plugins
>  * node-postcss-load-config
>  * node-cache-loader
>  * node-cosmiconfig
>  * node-worker-loader
> 
> Care list:
>PACKAGETIME IN QUEUE
>  * node-carto   2103 days, needed by openstreetmap-carto
>  * pdf.js   1135 days, buggy, needed by GitLab
>  * node-jsdom   1016 days
>  * node-xterm785 days
>  * node-shell-quote  714 days, => browserify
>  * node-diffie-hellman   586 days, => browserify
>  * node-katex603 days
>  * node-react282 days
>  * node-prismjs  260 days

This old thread mention that node-diffie-hellman wes needed by
browserify. Now `npm2deb depends browserify` shows that it is no more
needed. Then I'm going to ask a ROM-RM against this buggy/useless module
if no one disagree.

Bug#950813: [Pkg-utopia-maintainers] Bug#950813: volume-key FTBFS, missing build-dependency on dh-python

[Michael Biebl]

control: tags -1 + moreinfo

Hi Peter

Am 06.02.20 um 21:22 schrieb peter green:
> Source: volume-key
> Version: 0.3.12-2
> Tags: bullseye, sid, patch
> Severity: serious
> 
> volume-key currently fails to build because of a missing
> build-dependency on dh-python, please add it.

volume-key Build-Depends on python3-dev which in the past made sure
dh-python is installed.

Is this is a deliberate change that the dh-python dependency was dropped
from python3-dev? If so, can I you provide more rationale for this
change? Was this announced somewhere where I can read about this?

If this was a planned change shouldn't there have been bug reports filed
in advance?

Regards,
Michael




signature.asc
Description: OpenPGP digital signature

Bug#950822: systemd-sysusers hangs if nis is enabled in a systemd-nspawn container

[Michael Biebl]

Control: tags -1 + moreinfo

Hi!

Am 07.02.20 um 02:55 schrieb Ryutaroh Matsumoto:
> * the above hang-up does not happen if "nis" is removed from 
> /etc/nsswitch.conf
> * the above hang-up is NOT observed outside a container.
> * I have no idea if it is an upstream issue.
> * Both host and container run only NIS clients, and NIS server is running in 
> another host.
> * NIS related Debian packages are as follows:

Can you run
SYSTEMD_LOG_LEVEL=debug /bin/systemd-sysusers
inside the container
If that hangs as well, please attach the output.
An strace might be helpful as well.




signature.asc
Description: OpenPGP digital signature

Bug#950822: systemd-sysusers hangs if nis is enabled in a systemd-nspawn container

[Michael Biebl]

One more question:
Do you have users/groups defined in
/usr/lib/sysusers.d/ or /etc/sysusers.d which are only resolvable via NIS?



signature.asc
Description: OpenPGP digital signature

Bug#950739: xapian-bindings: Fails to build against ruby2.7

[Olly Betts]

Control: tags -1 +pending

On Wed, Feb 05, 2020 at 12:05:22PM -0300, Lucas Kanashiro wrote:
> We are planning to start the ruby2.7 transition and your package failed
> to build against ruby2.7. Check the full build log here:
> 
> https://people.debian.org/~kanashiro/ruby2.7/builds/5/xapian-bindings/xapian-bindings_1.4.12-3+rebuild1580867044_amd64-2020-02-05T01:44:06Z.build

The problems all look to be in SWIG-generated code.  SWIG was patched
for Ruby 2.7 support last month, but there hasn't been a SWIG release
since 21 Aug 2019 so I'll work on patching the generated code for now.

It looks like the only thing that actually needs fixing right now may
be adding a cast to (rb_gvar_setter_t*) - testing that now.

Cheers,
Olly

Bug#950825: gwyddion FTCBFS: misses ruby components

[Helmut Grohne]

Source: gwyddion
Version: 2.55-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gwyddion fails to cross build from source, because dh_install misses the
ruby components. It turns out that the build disables ruby
functionality, because ruby is not executable. That's understandable
given that gwyddion depends on the host ruby. As it does not build a
ruby extension module, it should be using the build ruby. gwyddion
becomes cross buildable once annotating the ruby dependency with :any
(or :native). Please consider applying the attached patch.

Helmut
diff --minimal -Nru gwyddion-2.55/debian/changelog 
gwyddion-2.55/debian/changelog
--- gwyddion-2.55/debian/changelog  2019-11-21 16:12:00.0 +0100
+++ gwyddion-2.55/debian/changelog  2020-02-07 06:10:29.0 +0100
@@ -1,3 +1,10 @@
+gwyddion (2.55-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate ruby dependency with :any. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 07 Feb 2020 06:10:29 +0100
+
 gwyddion (2.55-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru gwyddion-2.55/debian/control gwyddion-2.55/debian/control
--- gwyddion-2.55/debian/control2019-11-21 14:01:50.0 +0100
+++ gwyddion-2.55/debian/control2020-02-07 06:10:28.0 +0100
@@ -10,7 +10,7 @@
libfftw3-dev,
libminizip-dev,
libxmu6,
-   ruby,
+   ruby:any,
libxml2-dev
 Rules-Requires-Root: no
 Standards-Version: 4.4.1

Bug#950826: aeolus FTCBFS: upstream Makefile hard codes the build architecture pkg-config

[Helmut Grohne]

Source: aeolus
Version: 0.9.7-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

aeolus fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config and thus fails finding
freetype2.pc. Please consider applying the attached patch to make
pkg-config substitutable.

Helmut
--- aeolus-0.9.7.orig/source/Makefile
+++ aeolus-0.9.7/source/Makefile
@@ -24,6 +24,7 @@
 VERSION = 0.9.7
 CPPFLAGS += -MMD -MP -DVERSION=\"$(VERSION)\" -DLIBDIR=\"$(LIBDIR)\"
 CXXFLAGS += -O2 -Wall
+PKG_CONFIG ?= pkg-config
 
 
 all:	aeolus aeolus_x11.so aeolus_txt.so
@@ -43,7 +44,7 @@
 XIFACE_O =	styles.o mainwin.o midiwin.o audiowin.o instrwin.o editwin.o \
 	midimatrix.o multislider.o functionwin.o xiface.o addsynth.o
 aeolus_x11.so:	CPPFLAGS += -D_REENTRANT
-aeolus_x11.so:	CPPFLAGS += $(shell pkg-config --cflags freetype2)
+aeolus_x11.so:	CPPFLAGS += $(shell $(PKG_CONFIG) --cflags freetype2)
 aeolus_x11.so:	CXXFLAGS += -shared -fPIC
 aeolus_x11.so:	LDFLAGS += -shared
 aeolus_x11.so:	LDLIBS += -lclthreads -lclxclient -lpthread -lXft -lX11

Bug#950827: RM: node-simplesmtp -- ROM; Orphaned & unmaintained

[Xavier Guimard]

Package: ftp.debian.org
Severity: normal

Hi,

I propose to remove node-simplesmtp:
 * it looks orphaned upstream (last commit 2015-02-16)
 * it is deprecated in favor of "smtp-server" [1]
 * enabling tests shows that library is buggy
 * popcon rank ~ 14
 * dak reports shows no reverse build deps

[1]: https://www.npmjs.com/package/simplesmtp

Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)

[Steven Robbins]

Hello Christoph,

On Thursday, February 6, 2020 3:43:41 A.M. CST Christoph Berg wrote:
> Re: Steven Robbins 2020-02-06 <4839510.uz11uGdL23@riemann>
> 
> > > the new gmp version makes postgresql-pgmp crash on arm64:
> > > 
> > > https://ci.debian.net/data/autopkgtest/testing/arm64/p/postgresql-pgmp/

> the postgresql-pgmp author found a fix so this isn't an issue anymore:
> 
> https://github.com/dvarrazzo/pgmp/issues/18
> https://github.com/dvarrazzo/pgmp/commit/04274c40b63d3dff758bee47c8525112d64
> d1ab2
> 
> I don't know the gmp internals, but I guess this fix might be
> applicable to other gmp users as well if they have problems.

Thank you!  This is very helpful -- there are three other autopkgtests failing 
with GMP 6.2 (packages in cc).  Maybe these are also triggered by a change in 
GMP: https://gmplib.org/list-archives/gmp-announce/2020-January/48.html

Best,
-Steve


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

Bug#950824: RFS: sayonara/1.5.2-beta3~1 -- Small and lightweight music player

[Ko Ko Ye`]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

Sayonara is a small, clear and fast audio player for Linux written in C++,
supported by the Qt framework.
It uses GStreamer as audio backend. Sayonara is open source and uses the
GPLv3 license.
more at https://sayonara-player.com [1],
https://gitlab.com/luciocarreras/sayonara-player [2]

Many supported music and playlist formats
Media library with fast search function
Show albums in a table or cover view
Multiple library support.
Group different directories in libraries and move or copy tracks from one
to another
Directory view
Genre organization
Playlist view organized by tabs
Dynamic playback

Equalizer
Crossfader
Speed and pitch control
MP3 Converter
Metadata editor (including tags from path)
Cover art
Lyrics
Shutdown function
Customizable spectrum analyzer and level meter
Bookmarking positions in tracks
Remote controllable

 * Package name: sayonara
   Version : 1.5.2-beta3~1
   Upstream Author : sayonara-pla...@posteo.org
 * URL : http://sayonara-player.com
 * License : GPL-3+
 * Vcs : https://gitlab.com/luciocarreras/sayonara-player
   Section : sound

It builds those binary packages:

  sayonara - Small and lightweight music player

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

  https://mentors.debian.net/package/sayonara [3]

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/sayonara/sayonara_1.5.2-beta3~1.dsc
[4]

Changes since the last upload:

   * Initial release (Closes: #854408)

[1] https://sayonara-player.com
[2] https://gitlab.com/luciocarreras/sayonara-player
[3] https://mentors.debian.net/package/sayonara
[4]
https://mentors.debian.net/debian/pool/main/s/sayonara/sayonara_1.5.2-beta3~1.dsc

Regards,

Bug#950342: RM: volatility/2.6.1-1

[Sandro Tosi]

Control: tags -1 -moreinfo

> But it still has a reverse dependency. I think that package should get
> time drop the dependency first, don't you think (it seems to me that
> it's a meta-package that could easily do that)?

`forensics-all` is a metapackage from `src:forensics-all`, and i
thought we could ignore those?

anyhow, with this upload
https://packages.qa.debian.org/f/forensics-all/news/20200205T132048Z.html
volatility was dropped from forensics-all and now dak is clean:

```
$ ssh coccia.debian.org "dak rm -Rn -b volatility"
Will remove the following packages from unstable:

volatility |2.6.1-1 | all

Maintainer: Debian Security Tools 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.
```

can we proceed?

Cheers,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#947744: installation-reports: Debian Live Testing LXQt + nonfree - install fails with: "Bad unsquash configuration" Date: Wed, 1 Jan 2020 04:54:06 +0000 (UTC)

[scott092707]

>What media are you using for the image, out of curiosity?
16GB PNY USB 2.0 Flash drive ("Attache 4"), in a USB 3.0 hub in a USB 3.0 port.

Installed with mkusb 12.3.9-1ubuntu1 with persistence
(I've had very good results getting bootable USB drives with mkusb).

Are you thinking that there may be some sort of media flaw in the drive?

Bug#949887: munin autopkgtest failure for sysvinit based tests

[Andreas Henriksson]

Hello,

While I don't know enough about how all of this works I think
I'd like to claim that this is a bug in munin (testsuite).
More details below.

On Sun, Jan 26, 2020 at 06:26:14PM +0100, Michael Biebl wrote:
> Package: munin,sysvinit-core
> Severity: serious
> 
> Hi,
> 
> the autopkgtest of munin currently fails, the
> master-cron autopkgtest using sysvinit-core fails with:
[...]
> autopkgtest [04:57:05]: test process requested reboot with marker into-sysv
> Failed to create rundir (/var/run/munin): Permission denied at 
> /usr/share/munin/munin-update line 39.
[...]

Apparently the munin package is designed so that there's:
- a tmpfile(s) snippet that creates directories, including /run/munin
- an init script that exits on systemd but otherwise creates the
  directories that the tmpfile(s) snippet was supposed to create.
  (This feels quite WET, a more DRY solution would just be to hook up
  running systemd-tmpfiles which should work on sysvinit[0] as well.)

AFAIK on systemd tmpfiles are processed early and are guaranteed
to be handled by the time (normal) services are started.

When the autopkgtest is booted into sysvinit I assume there's a
race between the munin init script starting and the actual
tests running.

The crash quoted above, as far as I can tell, comes from:

[...]
> debian/tests/munin-master/01.master-components.t ..
> expecting success:
>   setuidgid munin /usr/share/munin/munin-update
>
>   not ok 1 - munin-update
>   #
>   # setuidgid munin /usr/share/munin/munin-update
>   #
[...]

The munin-update[1] program contains:

sub main {
exit_if_run_by_super_user();
[...]
my $update = Munin::Master::Update->new();
$update->run();

return 0;
}

The crash happens at the `$update->run();`[2] function call which
checks if /run/munin exists (which it apparently doesn't) and then
tries to create it[3].

As obvious by both the testsuite and the code, the program is *not*
being executed as root (but as munin user/group) and thus does not
have permission to create anything in (/var)/run.

I guess the problem can be fixed by adding as the first step in the
testsuite (running as root):
systemd-tmpfiles /usr/lib/tmpfiles.d/munin.conf

This should work on both systemd and sysvinit testbeds. It will
already have happened before on the systemd testbed but repeating
it should be harmless. (This however requires the systemd package
to be installed in the sysvinit testbed, so alternatively somehow
invoke the munin "service".)

(An alternative aproach which I don't know if it's possible would be
to investigate if you can somehow specify that the test-suite depends
on a particular init script to make sure things are started in the
right order on sysvinit testbed.)

Regards,
Andreas Henriksson

[0]: https://lists.debian.org/debian-devel/2020/01/msg00233.html
[1]: 
https://sources.debian.org/src/munin/2.0.54-1/master/_bin/munin-update.in/#L30
[2]: 
https://sources.debian.org/src/munin/2.0.54-1/master/lib/Munin/Master/Update.pm/#L45
[3]: 
https://sources.debian.org/src/munin/2.0.54-1/master/lib/Munin/Master/Update.pm/#L98

Bug#950821: [Pkg-javascript-devel] Bug#950821: RFP: peertube -- decentralized federated video platform

[Dmitry Smirnov]

On Friday, 7 February 2020 12:56:32 PM AEDT Jonas Smedegaard wrote:
> Here's an (old!) analysis of the size of the task:
> https://wiki.debian.org/Javascript/Nodejs/Tasks/peertube

Nice, thank you.

-- 
Regards,
 Dmitry Smirnov.

---

If you are out to describe the truth, leave elegance to the tailor.
-- Albert Einstein


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

Bug#930534: Bug#930521: release.debian.org: provide machine-readable information about the freeze period for each release

[Paul Wise]

On Thu, 2020-02-06 at 13:32 +0100, Paul Gevers wrote:

> That is mostly because they have not been settled 100% yet.

Sorry, I meant for the buster release, which is done now. There is
still data for the last wheezy point release but nothing for the freeze
for buster or bullsye; I thought the freeze was initially meant to be
set at 2 years after the release.

> Let me try to come back to this bug when we have communicated the dates
> and provide a prototype so we can see if it works.

Great, no rush. There isn't much activity on tracker.d.o features anyway.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#949312: txsocksx: should this package be removed?

[Sandro Tosi]

On Sun, Feb 2, 2020 at 6:51 AM Adrian Bunk  wrote:
>
> On Tue, Jan 28, 2020 at 04:06:28PM -0500, Sandro Tosi wrote:
> >...
> > python-txsocksx -> foolscap -> tahoe-lafs
> >
> > both foolscap and tahoe-lafs were removed from testing, so to my
> > script python-txsocksx appears as a leaf package (as its removal wont
> > break already broken/RC packages not in testing). not sure what we
> > want to do here, none of the 2 other packages will get fix anytime
> > soon and may get removed from debian entirely at some point.
> >...
>
> The latter statement is not true.
>
> Both tahoe-lafs and foolscap have substantial upstream activities
> towards Python 3 porting,

my statement says "none of the 2 other packages will get fix anytime
soon and may get removed from debian entirely at some point" -- what
do you find un-true about it?

i did not say those projects python3 port is not being worked on, but
i say that they are not close to finishing it, which includes both
porting the code *and* testing it and finally release a version that
has the python3 port.

for tahoe-lafs the effort is tracked at
https://tahoe-lafs.org/trac/tahoe-lafs/milestone/Support%20Python%203
which is currently marked at 89% completed; it was marked to be
completed by Dec 1, 2019, so they are 2 months behind their own
schedule (again, no blaming, just stating facts)

for foolscape the effort is tracked at
https://github.com/warner/foolscap/issues/48 which received some
attention at the beginning on 2020 (holiday break?) and none since Jan
5.

So, can you explain what you find misrepresented in my statement?

> the reasonable way forward would be to close
> this RM bug and watch how it all will get resolved in a few months with
> new upstream versions.

We've been known the end of python2 support would be in 2020 since
years, i'm not sure it's fair for the projects that took the time
earlier and to the debian maintainers to ask to keep supporting
python2 packages for (relatively) old software for additional *few months*.

Please also note that txsocksx is not python3 ready yet, nor there's
any progress in porting it. How keeping the old python2 package in
Debian is gonna help with that port? It would the py2removal effort in
debian by removing an old package with no py3k port available,

Happy to hear what your thoughts are on this.

Regards,

--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#950823: RFS: surgescript/0.5.4.2-1 -- Scripting language for games

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: surgescript
   Version : 0.5.4.2-1
   Upstream Author : Alexandre Martins 
 * URL : https://docs.opensurge2d.org
 * License : Apache-2.0
 * Vcs : https://salsa.debian.org/games-team/surgescript
   Section : graphics

It builds those binary packages:

  surgescript - Scripting language for games

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/surgescript/surgescript_0.5.4.2-1.dsc

Changes since the last upload:

   * New upstream release
   * debian/control:
 + Declare compliance with Debian Policy: 4.5.0.
   * Update debian/copyright years.
   * debian/docs:
 + README.md file included.
   * debian/rules:
 - Reduced command to directory.
 + Added dh_compress so that certain files are not compressed.
   * Update debian/upstream/metadata years.

Regards,

--
  Carlos Donizete Froes [a.k.a coringao]

Bug#947744: installation-reports: Debian Live Testing LXQt + nonfree - install fails with: "Bad unsquash configuration"

[Steve McIntyre]

Hi Scott,

On Mon, Jan 27, 2020 at 09:42:26PM +, scott092...@aol.com wrote:
>Further attempts to install, with images through the current 01/27/2020 .iso,
>continue to fail in exactly the same way.

I've just run a test on the latest version of this image and it seems
to work just fine here. What media are you using for the image, out of
curiosity?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead

Bug#950821: [Pkg-javascript-devel] Bug#950821: RFP: peertube -- decentralized federated video platform

[Dmitry Smirnov]

On Friday, 7 February 2020 12:32:11 PM AEDT Jonas Smedegaard wrote:
> control: forcemerge -1 948374

Wrong.


> I already started working on it

You are working on desktop client.

This ITP is for Server.

Please un-merge.

>  - great if you can help!

How can I help if you are not disclosing (the location of) repository where 
you are staging the package?

-- 
Regards,
 Dmitry Smirnov.

---

Truth never damages a cause that is just.
-- Mahatma Gandhi


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

Bug#950821: [Pkg-javascript-devel] Bug#950821: RFP: peertube -- decentralized federated video platform

[Jonas Smedegaard]

control: unmerge -1

Quoting Jonas Smedegaard (2020-02-07 02:32:11)
> control: forcemerge -1 948374
> 
> Quoting Dmitry Smirnov (2020-02-07 01:54:14)
> > Package: wnpp
> > Severity: wishlist
> > X-Debbugs-CC: debian-de...@lists.debian.org, 
> > debian-multime...@lists.debian.org, 
> > pkg-javascript-de...@lists.alioth.debian.org
> > 
> >Package name: peertube
> > Version: 2.0.0
> > License: AGPL-3+
> > URL: https://github.com/Chocobozzz/PeerTube
> > Description: decentralized federated video platform
> >  PeerTube is a decentralized and federated video platform developed as an
> >  alternative to other platforms that centralize our data and attention,
> >  such as YouTube, Dailymotion or Vimeo. All servers of PeerTube are
> >  interoperable as a federated network, and non-PeerTube servers can be part
> >  of the larger Vidiverse (federated video network) by talking our
> >  implementation of ActivityPub. Video load is reduced thanks to P2P
> >  (BitTorrent) in the web browser via WebTorrent.
> > 
> > ---
> > 
> > Count me in if you are going to package PeerTube. I just don't have
> > enough expertise with nodejs...
> 
> I already started working on it - great if you can help!

Whoops, silly me: There's quite a difference between peertube and 
peertube-desktop.  I will try clean up the mess (and then get some 
sleep!)

I am still interested in helping package peertube, but it is a bigger 
task and lower urgency for me.  Concretely I want to get more ESLint 
into shape before diving into more large JavaScript projects.

Here's an (old!) analysis of the size of the task: 
https://wiki.debian.org/Javascript/Nodejs/Tasks/peertube


 - 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#950821: [Pkg-javascript-devel] Bug#950821: RFP: peertube -- decentralized federated video platform

[Jonas Smedegaard]

control: forcemerge -1 948374

Quoting Dmitry Smirnov (2020-02-07 01:54:14)
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org, 
> debian-multime...@lists.debian.org, 
> pkg-javascript-de...@lists.alioth.debian.org
> 
>Package name: peertube
> Version: 2.0.0
> License: AGPL-3+
> URL: https://github.com/Chocobozzz/PeerTube
> Description: decentralized federated video platform
>  PeerTube is a decentralized and federated video platform developed as an
>  alternative to other platforms that centralize our data and attention,
>  such as YouTube, Dailymotion or Vimeo. All servers of PeerTube are
>  interoperable as a federated network, and non-PeerTube servers can be part
>  of the larger Vidiverse (federated video network) by talking our
>  implementation of ActivityPub. Video load is reduced thanks to P2P
>  (BitTorrent) in the web browser via WebTorrent.
> 
> ---
> 
> Count me in if you are going to package PeerTube. I just don't have
> enough expertise with nodejs...

I already started working on it - great if you can help!

 - 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#950821: RFP: peertube -- decentralized federated video platform

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, 
debian-multime...@lists.debian.org, pkg-javascript-de...@lists.alioth.debian.org

   Package name: peertube
Version: 2.0.0
License: AGPL-3+
URL: https://github.com/Chocobozzz/PeerTube
Description: decentralized federated video platform
 PeerTube is a decentralized and federated video platform developed as an
 alternative to other platforms that centralize our data and attention,
 such as YouTube, Dailymotion or Vimeo. All servers of PeerTube are
 interoperable as a federated network, and non-PeerTube servers can be part
 of the larger Vidiverse (federated video network) by talking our
 implementation of ActivityPub. Video load is reduced thanks to P2P
 (BitTorrent) in the web browser via WebTorrent.

---

Count me in if you are going to package PeerTube. I just don't have
enough expertise with nodejs...


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

Bug#950820: mgba: new upstream release (0.8.0)

[Ryan Tandy]

Source: mgba
Severity: wishlist

Dear Maintainer,

mGBA upstream released 0.8.0 with a number of bug fixes and new 
features.

I started working on packaging the new release. I noticed that it 
includes additional vendored libraries that trigger a Lintian error:

https://github.com/mgba-emu/mgba/commit/9197e5a1fbc8574ca26ce9d73b575cdeaebedccb

E: mgba source: license-problem-json-evil res/licenses/rapidjson.txt
E: mgba source: license-problem-json-evil 
src/third-party/discord-rpc/include/rapidjson/license.txt

On the one hand, I think the error could be overridden, because the text 
states that the JSON license only applies to the "jsonchecker" tool, 
which is not vendored.

On the other hand, rapidjson-dev is available in Debian, so should we 
just exclude it anyway and try to build with the packaged rapidjson? Not 
sure whether that will require patching the CMakeLists of discord-rpc.


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

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

Bug#949282: retroarch: FTBFS: cannot find -lX11-xcb

[Ryan Tandy]

Control: tag -1 patch

Dear maintainer,

It looks trivial to fix this by adding Build-Depends: libx11-xcb-dev.

That package used to be transitive Depends of libgl1-mesa-dev, but no 
longer since libgl-dev was moved to libglvnd.


Patch attached.

thanks,
Ryan
diff -Nru retroarch-1.7.3+dfsg1/debian/changelog 
retroarch-1.7.3+dfsg1/debian/changelog
--- retroarch-1.7.3+dfsg1/debian/changelog  2018-06-06 17:27:00.0 
-0700
+++ retroarch-1.7.3+dfsg1/debian/changelog  2020-02-06 15:31:29.0 
-0800
@@ -1,3 +1,11 @@
+retroarch (1.7.3+dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add libx11-xcb-dev to Build-Depends. (Closes: #949282)
+It used to be pulled in transitively by libgl1-mesa-dev.
+
+ -- Ryan Tandy   Thu, 06 Feb 2020 15:31:29 -0800
+
 retroarch (1.7.3+dfsg1-1) unstable; urgency=low
 
   * New upstream release (Closes: #878252).
diff -Nru retroarch-1.7.3+dfsg1/debian/control 
retroarch-1.7.3+dfsg1/debian/control
--- retroarch-1.7.3+dfsg1/debian/control2018-06-05 20:55:14.0 
-0700
+++ retroarch-1.7.3+dfsg1/debian/control2020-02-06 15:31:29.0 
-0800
@@ -25,6 +25,7 @@
libusb-1.0-0-dev (>= 1.0.16),
libv4l-dev,
libvulkan-dev,
+   libx11-xcb-dev,
libxinerama-dev,
libxml2-dev,
libxv-dev,

Bug#947207: chromium: Video is garbled on twitch.tv, most other video sites

[Thorsten Ehlers]

I can confirm what nurupo stated in message #30 removing

--ignore-gpu-blacklist from /etc/chromium.d/default-flags

helped me to get video playback in Youtube and other web services

back to normal. (AMD Ryzen 3200G APU graphics here)

with all flags in Chromium 79.0.3945.130-2 set back to defaults.

Bug#950819: ITP: h5cpp-compiler -- LLVM based compiler assisted reflection for modern C++

[steven]

Package: wnpp
Severity: wishlist
Owner: ste...@vargaconsulting.ca

* Package name: h5cpp-compiler
  Version : 1.10.4.5
  Upstream Author : Steven Varga 
* URL : http://h5cpp.org
* License : MIT
  Programming Lang: C++
  Description : LLVM based compiler assisted reflection for modern C++

H5CPP-compiler automates the tedious and error prone process of handwriting HDF5
compound type data descriptors providing similar level of data
serialization/persistence experience of popular interpreted languages
but compile time.
This non-intrusive source code transformation tool is a companion to h5cpp
template library it builds the AST of a specified translation unit,
identifies arbitrary deep POD struct variables referenced/used by the
template library operators:
h5::create | h5::read | h5::write | h5::append
h5::acreate | h5::aread | h5::awrite
and generates the necessary HDF5 compound datatype descriptors. In the second
phase, using system compiler gcc,clang,msvc, ... the user compiles this now
complete translation unit into an object file.

The h5cpp compiler assisted reflection and its companion header library
was developed for low latency event stream recording arising in high
frequency trading applications, Real Time Bidding and general machine
learning.

Primary competing idea to compiler assisted reflection is the recently
developed purely template based introspection and reflection for C++
which is not yet available. While there are many related work based on
runtime approach, or templates most of them requiring some modification
to original code making it intrusive, or less performance oriented.

Maintenance and sponsor: the author, steven varga is to maintain the
h5cpp-compiler, and yes looking for sponsor

Bug#894996: [Pkg-shadow-devel] Bug#894996: Bug#894996: Give the path of the directory you are talking about

[Bálint Réczey]

Control: fixed -1 1:4.8-1

積丹尼 Dan Jacobson  ezt írta (időpont: 2018. ápr.
9., H, 16:11):
>
> OK, made
> https://github.com/shadow-maint/shadow/issues/105 ,
> https://github.com/shadow-maint/shadow/issues/106 .
>
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#950533: upgrade fails in a chroot

[Steve McIntyre]

Hey Michael,

Apologies for taking a while to get back to you. Yay conference
week... :-/

On Mon, Feb 03, 2020 at 11:02:13AM +0100, Michael Biebl wrote:
>Am 03.02.20 um 09:59 schrieb Steve McIntyre:
>
>> ACL operation on "/var/log/journal" failed: No such file or directory
>> ACL operation on "/var/log/journal" failed: No such file or directory
>> Failed to re-open '/var/log/journal': No such file or directory
>> fchmod() of /var/log/journal failed: No such file or directory
>> dpkg: error processing package systemd (--configure):
>>  installed systemd package post-installation script subprocess returned 
>> error exit status 73
>> Errors were encountered while processing:
>>  systemd
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>> 
>> I don't have a /var/log/journal in those chroots.
>
>The error message is misleading. postinst does create a /var/log/journal
>directory. From a quick investigation with strace, the following seems
>relevant
>
>> getxattr("/proc/self/fd/4", "system.posix_acl_access", 0x7ffc2fdcc8c0, 132) 
>> = -1 ENOENT (No such file or directory)
>> writev(2, [{iov_base="ACL operation on \"/var/log/journ"..., iov_len=69}, 
>> {iov_base="\n", iov_len=1}], 2ACL operation on "/var/log/journal" failed: No 
>> such file or directory
>
>Mounting a proc fs inside the chroot does fix the failure for me.
>
>We run systemd-tmpfiles --create --prefix /var/log/journal
>after creating the directory to ensure proper permissions and ACLs are
>applied. Apparently this requires a mounted proc fs.
>
>https://salsa.debian.org/systemd-team/systemd/blob/debian/master/src/core/chown-recursive.c#L17
>
>A quick fix could be to guard the systemd-tmpfiles call with a
>
>if mountpoint -q /proc ; then
>...
>fi

ACK, and I see you've added that i git already. Thanks for the quick response!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Bug#950816: Acknowledgement (mpv: unintended code execution vulnerability)

[astian]

astian:
> If Lua scripts are enabled (they are by default) and configured for use
> (Debian doesn't seem to have any active by default)

Correction: mpv as shipped by Debian does have some active Lua scripts
embedded in the ELF binary, but, as the author says in the quoted commit, they
'only "require" preloaded modules':

  $ strings /usr/bin/mpv | grep 'require '
  require '%s'
  local msg = require 'mp.msg'
  local assdraw = require 'mp.assdraw'
  local msg = require 'mp.msg'
  local opt = require 'mp.options'
  local utils = require 'mp.utils'
  local utils = require 'mp.utils'
  local msg = require 'mp.msg'
  local options = require 'mp.options'
  local mp = require 'mp'
  local options = require 'mp.options'
  local utils = require 'mp.utils'
  local utils = require 'mp.utils'
  local options = require 'mp.options'
  local assdraw = require 'mp.assdraw'

That "require '%s'" looks suspicious but it seems to be only called precisely
for those "built-in" Lua modules.

Cheers.

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Christian Barcenas]

I just noticed that your packaging repo is currently empty.
Would you be able to push your current progress to Github
so that it's easier to review the source package?

On Thu, Feb 6, 2020 at 2:34 PM Sudip Mukherjee
 wrote:
> So, do we also use epoch or shall I try the way which Paul suggested
> to add epoch only to the binary package?

My vote is to use libbpf's new versioning scheme and epoch 1 for both
source and binary packages. The primary benefit is simplicity:
IMO it's easier to reason about things that way.

It looks like upstream is trying to separate their own release
schedule from the kernel's. There is now a possibility that some
future libbpf release may contain changes not present in the
upstream kernel tree at all.

In this scenario, it would *only* make sense to use libbpf versioning
for the source package, so we might as well get both epoch adjustments
out of the way right now instead of raising this question again in the future.

Christian

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Sudip Mukherjee]

On Thu, Feb 6, 2020 at 11:07 AM Sudip Mukherjee
 wrote:
>
> On Thu, Feb 6, 2020 at 8:39 AM Michael Biebl  wrote:
> >
> > Am 06.02.20 um 09:22 schrieb Adam D. Barratt:
> > > On 2020-02-06 08:12, Paul Gevers wrote:
> > >> Hi,
> > >>
> > >> On 06-02-2020 00:07, Adam D. Barratt wrote:
> > >>> On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote:
> >  On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas
> >   wrote:
> > > Because this changes the versioning scheme from kernel releases
> > > (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
> > > version numbers (0.0.6-1), the epoch needs to be incremented to 1 I
> > > believe.
> > 
> >  I had this doubt but 5.4.13-1 is the linux source version, and
> >  libbpf0 has the version of 0.0.5. And since there is no separate
> >  source for libbpf so will this not be  considered as a new package
> >  rather than a version change?
> > >>>
> 
> >
> > One other alternative could be, to ask your upstream to change the
> > versioning scheme and instead of using 0.0.6, switch to 6.0.0 as first
> > version number (which would be higher then 5.x)
> > Other distros might have similar problems.
>
> I think other distros already had the package split and are now using
> the source from github. Atleast Fedora and Gentoo have done already.
> Looks like Fedora solved the problem using epoch as can be seen in the
> comment at 
> https://src.fedoraproject.org/rpms/libbpf/blob/f30/f/libbpf.spec#_15

And, I have confirmed from Jiri who is the Fedora maintainer for
libbpf that they have used epoch to solve the version problem.
So, do we also use epoch or shall I try the way which Paul suggested
to add epoch only to the binary package?


-- 
Regards
Sudip

Bug#950402: pinot ftbfs with libexiv2-27

[Olly Betts]

Control: tags -1 +pending

On Thu, Feb 06, 2020 at 05:17:37AM +, peter green wrote:
> This build failure is fixed by upstream commit
> faaa552de9ec099184d131c08b76ae0b1ce4f5ec

Thanks for identifying this - will upload shortly.

I'll also suggest to upstream it's time they made a new release (it's
been more than 4.5 years since the last one).

Cheers,
Olly

Bug#719792: RFA: reconf-inetd & DEP9 -- maintainer script for programmatic updates of inetd.conf

[Moritz Mühlenhoff]

On Thu, Aug 15, 2013 at 01:19:08PM +0100, Serafeim Zanikolas wrote:
> Package: wnpp
> Severity: normal
> 
> I request an adopter for the reconf-inetd package.
> 
> The package description is:
>  reconf-inetd is a dpkg-trigger script that updates the configuration of the
>  internet superserver. It is a replacement for update-inetd, as per DEP9.
>  .
>  If the above does not mean anything to you, then you most certainly do not
>  need this package.
> 
> 
> I do not have the time to be the sole driver of DEP9, and its implementation,
> reconf-inetd. reconf-inetd is pretty much complete, it works, and it comes
> with dozens of system tests. Remaining work includes:
> 
> - port to python 3

Hi Serafeim,
Let's remove reconf-inetd? The lack of a Python 3 port is now a pressing
issue given that Python 2 is removed and It's RFAd since 2013, there are no
rdeps and inetd itself is going away in favour of systemd socket activation
over time.

Cheers,
Moritz

Bug#950818: RM: makejail -- RoQA; unmaintained, dead upstream, depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove makejail, it's unmaintained (last maintainer upload in 2012), 
dead upstream
and depends on Python 3 which is going away. It also seems broken with 64 bits 
for a long
time (680283) and accesses dpkg internals (913692).

Cheers,
Moritz

Bug#950817: archmage: FTBFS: tests fail: ModuleNotFoundError: No module named 'bs4'

[Andreas Beckmann]

Source: archmage
Version: 1:0.4.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

archmage FTBFS in sid:
https://buildd.debian.org/status/fetch.php?pkg=archmage=all=1%3A0.4.1-2=1579977169=0

 ERRORS 
_ ERROR collecting .pybuild/cpython3_3.8/build/tests/test_openclose.py _
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.8/build/tests/test_openclose.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
tests/test_openclose.py:1: in 
import sys, archmage.cli, pathlib, tempfile, errno, shutil, contextlib
archmage/cli.py:57: in 
from archmage.CHM import CHMFile, Action
archmage/CHM.py:34: in 
from archmage.CHMParser import SitemapFile, PageLister, ImageCatcher, 
TOCCounter#, HeadersCounter
archmage/CHMParser.py:26: in 
from bs4 import BeautifulSoup, UnicodeDammit
E   ModuleNotFoundError: No module named 'bs4'


Andreas

Bug#950816: mpv: unintended code execution vulnerability

[astian]

Package: mpv
Version: 0.32.0-1
Severity: grave
Tags: security fixed-upstream
Justification: user security hole

Dear Maintainer,

If Lua scripts are enabled (they are by default) and configured for use
(Debian doesn't seem to have any active by default) mpv could end up
loading unintended code (lua scripts/bytecode and/or shared objects)
from the current working directory.

The following upstream commit supposedly fixes this:
https://github.com/mpv-player/mpv/commit/cce7062a8a6b6a3b3666aea3ff86db879cba67b6

Excerpt from the commit message:

  lua: fix highly security relevant arbitrary code execution bug

  It appears Lua's package paths try to load .lua files from the current
  working directory. Not only that, but also shared libraries.

  [...]

  In mpv's case, this is so security relevant, because mpv is normally
  used from the command line, and you will most likely actually change
  into your media directory or whatever with the shell, and play a file
  from there. No, you don't want to load a (probably downloaded) shared
  library from this directory if a script try to load a system lib with
  the same name or so.

  I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the
  Debian version) put "./?.lua" at the end, but in any case, trying to
  load a module that doesn't exist nicely lists all package paths in
  order, and confirms it tries to load files from the working directory
  first (anyone can try this). Even if it didn't, this would be
  problematic at best.

  Note that scripts are not sandboxed. They're allowed to load system
  libraries, which is also why we want to keep the non-idiotic parts of
  the package paths.

  [...]

  mpv in default configuration (i.e. no external scripts) is probably not
  affected. All builtin scripts only "require" preloaded modules, which,
  in a stroke of genius by the Lua developers, are highest priority in the
  load order. Otherwise, enjoy your semi-remote code execution bug.

  [...]

Cheers.

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

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

Versions of packages mpv depends on:
ii  libarchive13  3.4.0-1+b1
ii  libasound21.2.1.2-2
ii  libass9   1:0.14.0-2
ii  libavcodec58  7:4.2.2-1
ii  libavdevice58 7:4.2.2-1
ii  libavfilter7  7:4.2.2-1
ii  libavformat58 7:4.2.2-1
ii  libavutil56   7:4.2.2-1
ii  libbluray21:1.1.2-2
ii  libc6 2.29-9
ii  libcaca0  0.99.beta19-2.1
ii  libcdio-cdda2 10.2+2.0.0-1+b1
ii  libcdio-paranoia2 10.2+2.0.0-1+b1
ii  libcdio18 2.0.0-2
ii  libdrm2   2.4.100-4
ii  libdvdnav46.0.1-1+b1
ii  libegl1   1.3.0-7
ii  libgbm1   19.3.3-1
ii  libgl11.3.0-7
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-4
ii  liblua5.2-0   5.2.4-1.1+b3
ii  libpulse0 13.0-4
ii  librubberband21.8.2-1
ii  libsdl2-2.0-0 2.0.10+dfsg1-1
ii  libsmbclient  2:4.11.5+dfsg-1
ii  libsndio7.0   1.5.0-3
ii  libswresample37:4.2.2-1
ii  libswscale5   7:4.2.2-1
ii  libuchardet0  0.0.6-3
ii  libva-drm22.6.1-1
ii  libva-wayland22.6.1-1
ii  libva-x11-2   2.6.1-1
ii  libva22.6.1-1
ii  libvdpau1 1.3-1
ii  libwayland-client01.17.0-1+b1
ii  libwayland-cursor01.17.0-1+b1
ii  libwayland-egl1   1.17.0-1+b1
ii  libx11-6  2:1.6.8-1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-2
ii  libxkbcommon0 0.9.1-1
ii  libxrandr22:1.5.1-1
ii  libxss1   1:1.2.3-1
ii  libxv12:1.0.11-1
ii  zlib1g1:1.2.11.dfsg-1.1

Versions of packages mpv recommends:
ii  xdg-utils   1.1.3-1
ii  youtube-dl  2020.01.24-0.1

mpv suggests no packages.

-- no debconf information

Bug#950788: /usr/share/man/man5/sysctl.d.5.gz: sysctl.d.5 man page has confusing directory order

[Craig Small]

Hi Michael,
  I had a look at the systemd source code.  My aim is to make sure the
procps sysctl and the systemd sysctl behave the same way. The first problem
is we have a different order of things (/etc vs /run) so I looked at the
manual page first.

It looks like a lot of systemd programs have a standard set of directories
they check[1] which is different from what sysctl uses[2]. However, the
manual page implies there are two groups of directories and some override
others. From what I can see from the configuration file handling of
systemd[3] there is no "special" set and it is a matter of what directory
comes first. In other words, /usr/local/lib overrides /usr/lib (or /lib
depending) but the manual page doesn't say that.

I must admit I'm not too familiar with the systemd code, but that's how I
read it.

If that's the case, then I think there are three problems here:
* The systemd sysctl.d.6 man page is incorrect and really each previous
directory can override any directory after it (this bug #950788)
* procps sysctl config files shipped by Debian should be in /usr/lib
(procps bug #915797)
* procps sysctl should swap the order of /etc and /run so /etc comes first
and overrides things in /run like systemd sysctl does.

Does that seem right to you? I'll make the necessary changes in procps if
so.

 - Craig

1:
https://salsa.debian.org/systemd-team/systemd/blob/debian/master/src/basic/def.h#L44
2: https://salsa.debian.org/debian/procps/blob/master/sysctl.c#L624
3:
https://salsa.debian.org/systemd-team/systemd/blob/debian/master/src/basic/conf-files.c#L23

On Thu, 6 Feb 2020 at 23:15, Michael Biebl  wrote:

> Hi Craig
>
> Am 06.02.20 um 12:31 schrieb Craig Small:
> > Package: systemd
> > Version: 244-3
> > Severity: minor
> > File: /usr/share/man/man5/sysctl.d.5.gz
> >
> > The sysctl.d.5 man page says this:
> >
> >   Configuration files are read from directories in /etc/, /run/,
> /usr/local/lib/, and /lib/, in order of precedence. Each configuration file
> in these configuration directories shall be named in the
> >   style of filename.conf. Files in /etc/ override files with the
> same name in /run/, /usr/local/lib/, and /lib/. Files in /run/ override
> files with the same name under /usr/.
> >
> > OK, so we have 4 directories.
> > Anything in /etc overrides anything in the other 3.
> >
> > But files in /run? They override.. /usr?
> > Is this supposed to mean /usr/local/lib?
> > Does that mean /run does NOT override files in /lib ?
> >
> > I think the man page used to say /usr/local/lib and /usr/lib and it was
> > (badly) saying both directories under /usr
> >
> > Maybe.. I'm not really sure what way to interpret this.
>
> I suppose this is a result of
>
> https://salsa.debian.org/systemd-team/systemd/blob/debian/master/debian/rules#L200
> doing some incorrect replacements.
>
> Replace /lib with /usr/lib and it will make more sense, I guess.
>
> I guess we have to fine-tune the sed expression.
>
>
>
>

Bug#881098: This is already fixed

[Dima Kogan]

Upstream fixed this in 0.62:

  https://joeyh.name/code/moreutils/news/version_0.62/

Nicolas or Matthew: please close this report if you concur.

Bug#950791: neomutt: missing debian/copyright entries for autosetup/*

[Jonathan Dowland]

Some initial work on this:

Bug#950815: asunder: freedb will be shut down March 31th 2020

[Andreas Ronnquist]

Package: asunder
Version: 2.9.5-1
Severity: normal

Dear Maintainer,

Asunder uses freedb by default to look up CD information using the
internet. This service will be shut down the 31th of March 2020, which
will affect everybody using the default setting in the asunder package.

(See the "urgent notice" on top of http://www.freedb.org).

One solution could be to use the MusicBrainz to FreeDB gateway as
described at

https://mb.videolan.org/doc/FreeDB_Gateway



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=sv_SE.utf8, LC_CTYPE=sv_SE.utf8 (charmap=UTF-8),
LANGUAGE=sv_SE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages asunder depends on:
ii  cdparanoia  3.10.2+debian-13+b1
ii  dpkg1.19.7
ii  libatk1.0-0 2.34.1-1
ii  libc6   2.29-10
ii  libcddb21.3.2-6+b1
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-2
ii  libglib2.0-02.62.4-2
ii  libgtk2.0-0 2.24.32-4
ii  vorbis-tools1.4.0-11

Versions of packages asunder recommends:
pn  flac 
pn  wavpack  

Versions of packages asunder suggests:
pn  lame  

-- debconf-show failed

Bug#950814: RFS: coinutils/2.11.4+repack1-1 [QA] -- Coin-or collection of utility classes (binaries and libraries)

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: coinutils
   Version : 2.11.4+repack1-1
 * URL : https://projects.coin-or.org/CoinUtils
 * License : EPL-1
 * Vcs : https://salsa.debian.org/science-team/coinutils
   Section : science

It builds those binary packages:

  coinor-libcoinutils3v5 - Coin-or collection of utility classes 
(binaries and libraries)
  coinor-libcoinutils-dev - Coin-or collection of utility classes 
(developer files)
  coinor-libcoinutils-doc - Coin-or collection of utility classes 
(documentation)


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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/coinutils/coinutils_2.11.4+repack1-1.dsc


Changes since the last upload:

   * QA upload.
   * New upstream version 2.11.4+repack1
   * Update Standards-Version to 4.5.0
   * Use source created jquery.js in *.doc package
   * Change to usr/share/coin/Data/Sample in 
d/coinor-libcoinutils-dev.install

 and clean up d/rules
   * Set upstream metadata fields: Bug-Database, Repository, 
Repository-Browse

 Update: Bug-Submit.
   * d/copyright Readd BuildTools from upstream source
   * Build using autoreconf, make use of upstream BuildTools.

Regards,

Bug#937009: (no subject)

[Christoph Mathys]

Any idea when this package will switch to python3? I cannot drop python2 
support from mercurial-keyring until mercurial switches to python3.

Bug#931644: Buster kernel entropy pool too low on VM boot

[Salvatore Bonaccorso]

Hi Michael,

On Thu, Feb 06, 2020 at 03:36:49PM -0500, Michael J. Redd wrote:
> Apologies for the late reply. I can certainly test on some of my VMs if
> you're willing to provide packages.

The packages containing the change Noah mentioned will be released in
two days with the 10.3 point release. Right now it's available via
buster-proposed-updates, See
https://www.debian.org/releases/proposed-updates .

Does this helps?

Regards,
Salvatore

Bug#950272: buster-pu: package mariadb-10.3 10.3.22-0+deb10u1

[Bálint Réczey]

Hi All,

Paul Gevers  ezt írta (időpont: 2020. febr. 6., Cs, 20:17):
>
> Hi all,
>
> On 06-02-2020 15:11, Paul Gevers wrote:
> > Yes, and I am worried about that. If the MariaDB upgrade causes kodi to
> > not run, that's a bad regression, don't you think?
> >
> > kodi has a pretty good history in Ubuntu on ppc64el, so I don't expect
> > it to be flaky at first sight.
>
> I'm unhappy with the result, but the reference run with the old MariaDB
> now fails as well, so, no regression.
>
> I'm not sure what this means for kodi on ppc64el though.

Thank you for looking into the regression.
I believe the user-base of Kodi on ppc64el is very small, thus it is
not really worth the effort to fully triage this if this is not a
symptom of a MariaDB regression.

Cheers,
Balint

>
> Paul
>

Bug#931644: Buster kernel entropy pool too low on VM boot

[Michael J. Redd]

Apologies for the late reply. I can certainly test on some of my VMs if
you're willing to provide packages.

Reading over Linus' explanation of deriving jitter from the CPU's cycle
counter, while I'm no cryptographer, I might have some concerns about
the quality of the entropy that will be generated by this patch on
hypervisors that virtualize the time stamp counter. In my environment,
I know I can instruct Xen to never virtualize the TSC (
https://xenbits.xen.org/docs/unstable/man/xen-tscmode.7.html), which
would probably benefit the patch, but AWS and other public cloud users
may not have that option.

-Michael

Bug#950813: volume-key FTBFS, missing build-dependency on dh-python

[peter green]

Source: volume-key
Version: 0.3.12-2
Tags: bullseye, sid, patch
Severity: serious

volume-key currently fails to build because of a missing build-dependency on 
dh-python, please add it.

Bug#950812: pciutils: update-pciids fails because /usr/share/misc/pci.ids.old already exists

[Francois Marier]

Package: pciutils
Version: 1:3.6.4-1
Severity: normal

If I run the `update-pciids` command, it fails:

  $ sudo /usr/sbin/update-pciids
% Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100  255k  100  255k0 0   216k  0  0:00:01  0:00:01 --:--:--  216k
  ln: failed to create hard link '/usr/share/misc/pci.ids.old': File exists

I can only make it work if I delete the backup file first:

  $ sudo rm -f /usr/share/misc/pci.ids.old
  $ sudo /usr/sbin/update-pciids
% Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100  255k  100  255k0 0   216k  0  0:00:01  0:00:01 --:--:--  216k

Francois

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

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

Versions of packages pciutils depends on:
ii  libc6 2.29-10
ii  libkmod2  26+20191223-1
ii  libpci3   1:3.6.4-1

pciutils recommends no packages.

Versions of packages pciutils suggests:
ii  bzip2  1.0.8-2
ii  curl   7.67.0-2
ii  wget   1.20.3-1+b2

-- no debconf information

Bug#950811: python3-pybind11: Wrong path returned by get_include

[Marc Glisse]

Package: python3-pybind11
Version: 2.4.3-2
Severity: minor

Dear Maintainer,

>>> import pybind11
>>> pybind11.get_include(True)
'/home/glisse/.local/include/python3.7m'
>>> pybind11.get_include(False)
'/usr/local/include/python3.7'

$ python3 -m pybind11 --includes
-I/usr/include/python3.7m -I/usr/local/include/python3.7 
-I/home/glisse/.local/include/python3.7m

None of those paths correspond to the place where pybind11 headers are
actually installed (/usr/include). In most cases it won't matter much
because the compiler will look in /usr/include by default. I wonder if
the body of the function should be replaced with print('/usr/include')
on a platform like Debian...

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

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

Versions of packages python3-pybind11 depends on:
ii  pybind11-dev  2.4.3-2
ii  python3   3.7.5-3

Versions of packages python3-pybind11 recommends:
ii  python3-numpy  1:1.17.4-5

python3-pybind11 suggests no packages.

-- no debconf information

Bug#950810: new upstream release(s)

[Antoine Beaupre]

Package: irssi-scripts
Version: 20181120
Severity: wishlist

irssi-scripts in Debian is fairly old. since 2018, a lot of things
happened in that repository, and it seems a *lot* of scripts present
on scripts.irssi.org are not present in the Debian package.

for example, I was particularly looking for the `go2.pl` script and
while it's been on scripts.irssi.org since the beginning (or at least
since the git import in 2014), it's not in the Debian package.

it seems the current debian package is based on the old
scripts.irssi.org website, with only *some* of the scripts from the
website present. but nowadays (since 2014) the upstream site is a
static site generated from a git repository, which the debian package,
in my opinion, should be based on.

would that make sense?

thanks!

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

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

Versions of packages irssi-scripts depends on:
ii  irssi  1.2.0-2
ii  perl   5.28.1-6

Versions of packages irssi-scripts recommends:
ii  libwww-perl 6.36-2
ii  sensible-utils  0.0.12

Versions of packages irssi-scripts suggests:
ii  chromium [www-browser]  79.0.3945.130-1~deb10u1
ii  epiphany-browser [www-browser]  3.32.1.2-3~deb10u1
ii  firefox-esr [www-browser]   68.4.1esr-1~deb10u1
ii  libdbi-perl 1.642-1+b1
ii  lynx [www-browser]  2.8.9rel.1-3
ii  net-tools   1.60+git20180626.aebd88e-1
ii  w3m [www-browser]   0.5.3-37

-- no debconf information

Bug#950809: zita-bls1: FTBFS against zita-convolver 4.0.3

[Sebastian Ramacher]

Source: zita-bls1
Version: 0.3.3-1
Severity: important
Tags: sid bullseye ftbfs

zita-bls1 FTBFS against zita-convolver 4.0.3 currently in NEW:
| shuffler.cc: In member function ‘void Shuffler::init(int, int, int, int)’:
| shuffler.cc:78:62: error: no matching function for call to 
‘Convproc::configure(int, int, int&, int&, int&, int&)’
|78 | _convproc.configure (1, 1, _iplen, _quant, _minpt, _minpt);
|   |  ^
| In file included from shuffler.h:26,
|  from shuffler.cc:26:
| /usr/include/zita-convolver.h:387:9: note: candidate: ‘int 
Convproc::configure(uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, 
float)’
|   387 | int configure (uint32_t  ninp,
|   | ^
| /usr/include/zita-convolver.h:387:9: note:   candidate expects 7 arguments, 6 
provided
| make[1]: *** [: shuffler.o] Error 1

Full log is available at
https://people.debian.org/~sramacher/logs/zita-bls1_amd64-2020-02-06T19:44:42Z.log

Best
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#950224: nano: please by default include /usr/local/share/nano/*.nanorc and /etc/nano/*.nanorc

[Jonas Smedegaard]

Quoting Benno Schulenberg (2020-02-06 20:01:50)
> 
> Op 03-02-2020 om 14:56 schreef Jonas Smedegaard:
> > Quoting Benno Schulenberg (2020-02-03 14:23:38)
> >> I see.  However, the files in include statements can only contain 
> >> color syntaxes, not any option settings.
> > 
> > Oh!  I missed that "minor detail" which changes this issue from a 
> > "please package a slightly different configfile in Debian" to an 
> > upstream issue of "please support a mechanism for including general 
> > config snippets (not only styling snippets)".
> 
> Do you have any setting in mind that you would want to put into such a 
> system-wide config snippet for nano?

One example is the bottom commented out part of upstream sample 
configfile about more "usual" keybindings.


> (But in my opinion, the machine admin should not configure anything in 
> a personal tool like an editor.)

The use case I have in mind is debian-design, a Debian Pure Blend (i.e. 
an "install profile") targeted non-technical users who will dislike the 
default keybindings and will dislike needing to edit a configfile to 
change keybindings.


> However, even with such a config snippet mechanism, the problem that 
> --rcfile can be used to avoid (the main nanorc file including syntaxes 
> that I don't want) cannot be solved.
> 
> Anyway, if you think that an included file should be allowed to 
> contain any setting and option, not just syntax definitions, the place 
> to post such a request is Savannah:
> 
>   https://savannah.gnu.org/bugs/?group=nano

Thanks, I will consider filing a bugreport upstream - but frankly I am 
beginning to find it tiresome to try convince you about functionality 
that seems alien to you but obvious to me.  Not meant as a complaint, I 
do appreciate your patience, just being honest about my own limited 
patience.


Kind regards,

 - 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#950807: move libcmark.pc to a multiarch location

[Helmut Grohne]

Package: libcmark-dev
Version: 0.28.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:mkvtoolnix

mkvtoolnix fails to cross build from source, because it does not find
libcmark.pc using pkg-config. During cross compilation, pkg-config does
not search /usr/lib/pkgconfig. It only searches /usr/share/pkgconfig and
/usr/lib//pkgconfig. Thus we need to move libcmark.pc to the
multiarch location. It doesn't use multiarch, because the CMakelists.txt
uses a custom libdir variable instead of using the standard, working
CMAKE_INSTALL_LIBDIR variable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cmark-0.28.3/debian/changelog cmark-0.28.3/debian/changelog
--- cmark-0.28.3/debian/changelog   2018-05-28 01:55:25.0 +0200
+++ cmark-0.28.3/debian/changelog   2020-02-06 20:42:25.0 +0100
@@ -1,3 +1,10 @@
+cmark (0.28.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move libcmark.pc to a multiarch location. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 06 Feb 2020 20:42:25 +0100
+
 cmark (0.28.3-1) unstable; urgency=low
 
   * New upstream release (closes: #892815)
diff --minimal -Nru cmark-0.28.3/debian/libcmark-dev.install 
cmark-0.28.3/debian/libcmark-dev.install
--- cmark-0.28.3/debian/libcmark-dev.install2018-04-29 02:07:27.0 
+0200
+++ cmark-0.28.3/debian/libcmark-dev.install2020-02-06 20:42:25.0 
+0100
@@ -1,6 +1,6 @@
 usr/include
-usr/lib/*.a
-usr/lib/*.so
+usr/lib/*/*.a
+usr/lib/*/*.so
 usr/lib/*/cmake
-usr/lib/pkgconfig
+usr/lib/*/pkgconfig
 usr/share/man/man3
diff --minimal -Nru cmark-0.28.3/debian/libcmark0.install 
cmark-0.28.3/debian/libcmark0.install
--- cmark-0.28.3/debian/libcmark0.install   2018-03-04 11:47:47.0 
+0100
+++ cmark-0.28.3/debian/libcmark0.install   2020-02-06 20:42:25.0 
+0100
@@ -1 +1 @@
-usr/lib/*.so.*
+usr/lib/*/*.so.*
diff --minimal -Nru cmark-0.28.3/debian/patches/multiarch.patch 
cmark-0.28.3/debian/patches/multiarch.patch
--- cmark-0.28.3/debian/patches/multiarch.patch 1970-01-01 01:00:00.0 
+0100
+++ cmark-0.28.3/debian/patches/multiarch.patch 2020-02-06 20:42:25.0 
+0100
@@ -0,0 +1,27 @@
+--- cmark-0.28.3.orig/src/CMakeLists.txt
 cmark-0.28.3/src/CMakeLists.txt
+@@ -125,21 +125,19 @@
+ 
+ set(CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_NO_WARNINGS ON)
+ 
+-set(libdir lib${LIB_SUFFIX})
+-
+ include (InstallRequiredSystemLibraries)
+ install(TARGETS ${PROGRAM} ${CMARK_INSTALL}
+   EXPORT cmark
+   RUNTIME DESTINATION bin
+-  LIBRARY DESTINATION ${libdir}
+-  ARCHIVE DESTINATION ${libdir}
++  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
++  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
+   )
+ 
+ if(CMARK_SHARED OR CMARK_STATIC)
+   configure_file(${CMAKE_CURRENT_SOURCE_DIR}/libcmark.pc.in
+ ${CMAKE_CURRENT_BINARY_DIR}/libcmark.pc @ONLY)
+   install(FILES ${CMAKE_CURRENT_BINARY_DIR}/libcmark.pc
+-DESTINATION ${libdir}/pkgconfig)
++DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
+ 
+   install(FILES
+ cmark.h
diff --minimal -Nru cmark-0.28.3/debian/patches/series 
cmark-0.28.3/debian/patches/series
--- cmark-0.28.3/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ cmark-0.28.3/debian/patches/series  2020-02-06 20:42:25.0 +0100
@@ -0,0 +1 @@
+multiarch.patch

Bug#950600: moreinfo

[Gordon Ball]

This bug was originally reported (#944743) against 6.0.0-1 and should
have been fixed in 6.0.0-2 (by passing dh_installsystemduser
--no-enable).

Installing 6.0.3 in a VM today appears to install but not auto-enable
the user unit. Can you confirm if this was an upgrade or a clean
install?

Unfortunately, there doesn't appear to be any way to distinguish
retrospectively between automatically-enabled and
retrospectively-enabled units, and I'm somewhat loathe to ship a
maintscript which disables it automatically as a result (like
https://bugs.launchpad.net/ubuntu/+source/rygel/+bug/1848692 ).

You can disable it for all users with

systemctl --user --global disable jupyter-notebook

Bug#950808: jconvolver: FTBFS against zita-convolver 4.0.3

[Sebastian Ramacher]

Source: jconvolver
Version: 0.9.3-2
Severity: important
Tags: bullseye sid

jconvolver FTBFS against the zita-convolver 4.0.3 which is currently in
NEW:
| g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -O3 -Wall -MMD -MP -Wdate-time 
-D_FORTIFY_SOURCE=2 -DVERSION=\"0.9.3\" -ffast-math -funroll-loops  -c -o 
jconfig.o jconfig.cc
| jconfig.cc: In function ‘int convnew(const char*, int)’:
| jconfig.cc:91:15: error: ‘class Convproc’ has no member named ‘set_density’
|91 | convproc->set_density (dens);
|   |   ^~~
| jconfig.cc:92:78: error: no matching function for call to 
‘Convproc::configure(unsigned int&, unsigned int&, unsigned int&, unsigned 
int&, unsigned int&, Convproc::)’
|92 | if (convproc->configure (ninp, nout, size, fragm, part, 
Convproc::MAXPART))
|   |   
   ^
| In file included from jclient.h:27,
|  from jconfig.cc:25:
| /usr/include/zita-convolver.h:387:9: note: candidate: ‘int 
Convproc::configure(uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, 
float)’
|   387 | int configure (uint32_t  ninp,
|   | ^
| /usr/include/zita-convolver.h:387:9: note:   candidate expects 7 arguments, 6 
provided

The full log is available at
https://people.debian.org/~sramacher/logs/jconvolver_amd64-2020-02-06T19:39:29Z.log

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#938656: texlive-extra: Python2 removal in sid/bullseye

[Norbert Preining]

On Thu, 06 Feb 2020, Hilmar Preuße wrote:
> I'm not sure what you mean if you say "all this". Currently I see just
> one python script in texlive-sience

Please see the changes on github, I had to drop
   - ebong
   - de-macro
   - lilyglyphs
   - pygmentex
   - sympytexpackage
and patch several scripts to have the correct shebang (because despite
the purge, /usr/bin/python is still not Python3).

I am currently testing packages and wait for TL upstream to settle down
(recently LaTeX and several core packages got updated, so I expect some
bug fix releases).

Best

Norbert

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

Bug#950806: dh_strip_nondeterminism: breaks Multi-Arch: same on binNMU

[Helmut Grohne]

Package: dh-strip-nondeterminism
Version: 1.6.3-2
Severity: important
Control: affects -1 + libruby2.5

libruby2.5 is marked Multi-Arch: same. However trying to coinstall it
for multiple architectures yields an unpack error:

| Unpacking libruby2.5:ppc64el (2.5.7-1+b1) ...
| dpkg: error processing archive 
/tmp/apt-dpkg-install-ogGPd3/261-libruby2.5_2.5.7-1+b1_ppc64el.deb (--unpack):
|  trying to overwrite shared 
'/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png', 
which is different from other instances of package libruby2.5:ppc64el
| dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

Now looking into the ruby2.5 source package, we see that there is a
macFFBgHack.png:

028ebc15ad448256635073ebedaf1282006227f4cef68a8402c6c4d7001994a8  
lib/rdoc/generator/template/darkfish/images/macFFBgHack.png

However it differs from the one being installed:

5921908de94f1f1c32b39848cab4e01738eead861484034896a5232aba8ae106  
amd64/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
9c9ea17044f29a72ec885908a94e338f478048963b70c2dff1ccba43341f82de  
arm64/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
af77542eac693dea616f874d680cc8060e554fc169ffa5c27f5b9cf7616e4ec7  
ppc64el/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
eba3347383f8247df7f6055dc3144f79313107fc4ad702b13a902d2d9c494344  
s390x/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png

Where does the difference come from?

diffoscope tells us that it likely has to do with some timestamp:

| $ diffoscope 
{amd64,ppc64el}/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
| 2020-02-06 19:27:08 W: diffoscope.main: Fuzzy-matching is currently disabled 
as the "tlsh" module is unavailable.
| --- 
amd64/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
| +++ 
ppc64el/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
| │┄ Command `sng` exited with exit code 1. Standard output:
| │┄ sng: in stdin, 0 sBIT red bits not valid for 8bit/sample image
| @@ -3,13 +3,13 @@
|  0020: 6300  0473 4249 5408 0808 087c 0864  csBIT|.d
|  0030: 8800  0970 4859 7300 000b 1200 000b  .pHYs...
|  0040: 1201 d2dd 7efc  001c 7445 5874 536f  ~.tEXtSo
|  0050: 6674 7761 7265 0041 646f 6265 2046 6972  ftware.Adobe Fir
|  0060: 6577 6f72 6b73 2043 5333 98d6 4603   eworks CS3..F...
|  0070: 0027 7445 5874 4372 6561 7469 6f6e 2054  .'tEXtCreation T
|  0080: 696d 6500 3230 3230 2d30 312d 3139 5431  ime.2020-01-19T1
| -0090: 383a 3036 3a34 362d 3030 3a30 30c9 ea2c  8:06:46-00:00..,
| -00a0: e700  2849 4441 5448 89ed cd41 0100  (IDATH...A..
| +0090: 373a 3438 3a33 372d 3030 3a30 30ec 38b8  7:48:37-00:00.8.
| +00a0: 4e00  2849 4441 5448 89ed cd41 0100  N...(IDATH...A..
|  00b0: 3008 0021 b47f a755 5b0a 7f47 0106 cfb1  0..!...U[..G
|  00c0: bd0e 4a4a 4a4a 4a4a 4a4a 4ac0 0759 d100  ..J..Y..
|  00d0: f11f fc9f 8500  0049 454e 44ae 4260  .IEND.B`
|  00e0: 82   .
| $

But why would anything change the timestamp of a plain png file which
isn't created during build?

A look into the build logs revewals:

https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=amd64=2.5.7-1%2Bb1=1579457813=0
|dh_strip_nondeterminism -a
|   Using 1579457206 as canonical time
|  ...
|   Normalizing 
debian/libruby2.5/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
 using File::StripNondeterminism::handlers::png

https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=ppc64el=2.5.7-1%2Bb1=1579456774=0
|dh_strip_nondeterminism -a
|   Using 1579456117 as canonical time
|  ...
|   Normalizing 
debian/libruby2.5/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
 using File::StripNondeterminism::handlers::png

So what breaks macFFBgHack.png is nothing else than
dh_strip_nondeterminism.

This could affect any Multi-Arch: same package that is being binNMUed. I
think the only sane solution to this problem is having
dh_strip_nondeterminism skip binNMU changelog entries when generating
the timestamp.

Helmut

Bug#950805: ocl-icd FTCBFS: fails running ruby

[Helmut Grohne]

Source: ocl-icd
Version: 2.2.12-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ocl-icd fails to cross build from source, because it fails running ruby
with an Exec format error. ocl-icd build depends on plain ruby, which is
interpreted as a host architecture ruby, which cannot be assumed to be
runnable. ruby is used as a code generator here and thus it should be
installed for the build architecture. Annotating the dependency with
:any (or :native) makes ocl-icd cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru ocl-icd-2.2.12/debian/changelog 
ocl-icd-2.2.12/debian/changelog
--- ocl-icd-2.2.12/debian/changelog 2020-01-30 14:00:41.0 +0100
+++ ocl-icd-2.2.12/debian/changelog 2020-02-06 19:51:48.0 +0100
@@ -1,3 +1,10 @@
+ocl-icd (2.2.12-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate ruby build dependency with :any. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 06 Feb 2020 19:51:48 +0100
+
 ocl-icd (2.2.12-3) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru ocl-icd-2.2.12/debian/control ocl-icd-2.2.12/debian/control
--- ocl-icd-2.2.12/debian/control   2020-01-30 14:00:41.0 +0100
+++ ocl-icd-2.2.12/debian/control   2020-02-06 19:51:47.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Debian OpenCL Maintainers 

 Uploaders: Vincent Danjean ,
 Build-Depends: debhelper-compat (= 12),
-   ruby,
+   ruby:any,
faketime,
autoconf (>= 2.68),
automake,

Bug#950803: shntool: shnsplit refuses to split 24 bits wav and flac files, 16 bit ok

[Richard Lucassen]

Package: shntool
Version: 3.0.10-1+b1
Severity: normal

Dear Maintainer,

$ shnsplit -f test.cue -o flac 16bit.wav 
Splitting [16bit.wav] (42:32.651) --> [split-track01.flac] (12:32.000) : 100% OK
Splitting [16bit.wav] (42:32.651) --> [split-track02.flac] (8:49.000) : 100% OK
Splitting [16bit.wav] (42:32.651) --> [split-track03.flac] (9:33.000) : 100% OK
Splitting [16bit.wav] (42:32.651) --> [split-track04.flac] (11:38.651) : 100% OK

$ shnsplit -f test.cue -o flac 24bit.wav 
shnsplit: warning: unsupported format 0xfffe (Unknown) while processing file: 
[24bit.wav]
shnsplit: warning: none of the builtin format modules handle input file: 
[24bit.wav]
shnsplit: error: cannot continue due to error(s) shown above

A similar problem has been reported before (2014):

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

Richard


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

Kernel: Linux 5.4.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: sysvinit (via /sbin/init)

Versions of packages shntool depends on:
ii  libc6  2.29-9

shntool recommends no packages.

Versions of packages shntool suggests:
ii  cuetools  1.4.1-0.1
ii  flac  1.3.3-1
ii  sox   14.4.2+git20190427-1+b1
pn  wavpack   

-- no debconf information

Bug#950804: shntool: shnsplit does not split at the right split points

[Richard Lucassen]

Package: shntool
Version: 3.0.10-1+b1
Severity: important

Dear Maintainer,

According to the manpage, the split points should have the following syntax:

m:ss
m:ss.f
m:ss.nnn

When applying that to shnsplit, shnsplit will split the file at some point 
arount that time. After some searching I found this page:

https://superuser.com/questions/1243374/shntool-splits-wav-files-at-the-wrong-split-points

When applying m:ss:fff it works.

Richard

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

Kernel: Linux 5.4.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: sysvinit (via /sbin/init)

Versions of packages shntool depends on:
ii  libc6  2.29-9

shntool recommends no packages.

Versions of packages shntool suggests:
ii  cuetools  1.4.1-0.1
ii  flac  1.3.3-1
ii  sox   14.4.2+git20190427-1+b1
pn  wavpack   

-- no debconf information

Bug#950272: buster-pu: package mariadb-10.3 10.3.22-0+deb10u1

[Paul Gevers]

Hi all,

On 06-02-2020 15:11, Paul Gevers wrote:
> Yes, and I am worried about that. If the MariaDB upgrade causes kodi to
> not run, that's a bad regression, don't you think?
> 
> kodi has a pretty good history in Ubuntu on ppc64el, so I don't expect
> it to be flaky at first sight.

I'm unhappy with the result, but the reference run with the old MariaDB
now fails as well, so, no regression.

I'm not sure what this means for kodi on ppc64el though.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#950224: nano: please by default include /usr/local/share/nano/*.nanorc and /etc/nano/*.nanorc

[Benno Schulenberg]

Op 03-02-2020 om 14:56 schreef Jonas Smedegaard:
> Quoting Benno Schulenberg (2020-02-03 14:23:38)
>> I see.  However, the files in include statements can only contain 
>> color syntaxes, not any option settings.
> 
> Oh!  I missed that "minor detail" which changes this issue from a 
> "please package a slightly different configfile in Debian" to an 
> upstream issue of "please support a mechanism for including general 
> config snippets (not only styling snippets)".

Do you have any setting in mind that you would want to put into such
a system-wide config snippet for nano?  (But in my opinion, the machine
admin should not configure anything in a personal tool like an editor.)

However, even with such a config snippet mechanism, the problem that
--rcfile can be used to avoid (the main nanorc file including syntaxes
that I don't want) cannot be solved.

Anyway, if you think that an included file should be allowed to
contain any setting and option, not just syntax definitions, the
place to post such a request is Savannah:

  https://savannah.gnu.org/bugs/?group=nano

Benno



signature.asc
Description: OpenPGP digital signature

Bug#876365:

[aung thee]

Bug#950792: /usr/lib/libreoffice/program/soffice: Opening OpenOffice make Xorg crash

[Rene Engelhard]

tag 950792 + moreinfo
tag 950792 + unreproducible
thanks

Hi,

wrt Subject: You mean LibreOffice, not OpenOffice.

On Thu, Feb 06, 2020 at 04:04:36PM +0100, Nicola wrote:
> Package: libreoffice-core
> Version: 1:6.3.4-2
> Severity: important
> File: /usr/lib/libreoffice/program/soffice

Erm, No. Either File: /usr/lib/libreoffice/program/soffice or some other
package, given /usr/lib/libreoffice/program/soffice is not in -core.

> launching libreoffice make Xorg crash.

Any why do you think it's LibreOffices fault...

> >From /var/log/kern.log :
> 
> Feb  6 15:56:04 Lenovo kernel: [ 7246.351689] nouveau :01:00.0: bus: MMIO
> read of  FAULT at 619444 [ IBUS ]

.. if it's the nouveau driver causing it?

Even if LO was the only software you noticed it in, maybe it also affects
other OpenGL or graphics stuff?

> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (950, 'testing'), (400, 'unstable'), (300, 'experimental'), (10,
> 'stable')

No comment..

> Versions of packages libreoffice-core depends on:
> it  fontconfig  2.13.1-2+b1
   ^
> iu  fonts-opensymbol2:102.11+LibO6.4.0-1
   ^
> ii  libboost-locale1.67.0   1.67.0-17
> ii  libc6   2.29-9
> ii  libcairo2   1.16.0-4
> ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
> ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
> ii  libcmis-0.5-5v5 0.5.2-1
> iu  libcups22.3.1-4
   ^
> ii  libcurl3-gnutls 7.67.0-2
> ii  libdbus-1-3 1.12.16-2
> ii  libdconf1   0.34.0-2
> ii  libeot0 0.01-5+b1
> ii  libepoxy0   1.5.4-1
> ii  libexpat1   2.2.9-1
> ii  libexttextcat-2.0-0 3.4.5-1
> ii  libfontconfig1  2.13.1-2+b1
> ii  libfreetype62.10.1-2
> iu  libgcc-s1 [libgcc1] 10-20200204-1
   ^
> ii  libgcc1 1:9.2.1-25
> iu  libglib2.0-02.62.4-1+b1
   ^
> iu  libgpgmepp6 1.13.1-6
   ^
> ii  libgraphite2-3  1.3.13-11
> iu  libgstreamer-plugins-base1.0-0  1.16.2-dmo3
   ^
> ii  libgstreamer1.0-0   1.16.2-2
> ii  libharfbuzz-icu02.6.4-1
> ii  libharfbuzz0b   2.6.4-1
> ii  libhunspell-1.7-0   1.7.0-2+b1
> ii  libhyphen0  2.8.8-7
> ii  libice6 2:1.0.9-2
> ii  libicu6363.2-2
> ii  libjpeg62-turbo 1:1.5.2-2+b1
> ii  liblcms2-2  2.9-3+b1
> ii  libldap-2.4-2   2.4.48+dfsg-1+b2
> ii  libmythes-1.2-0 2:1.2.4-3+b1
> ii  libneon27-gnutls0.30.2-3
> ii  libnspr42:4.24-1
> iu  libnss3 2:3.49.1-1
   ^
> ii  libnumbertext-1.0-0 1.0.5-3
> ii  liborcus-0.15-0 0.15.3-3
> ii  libpng16-16 1.6.37-1
> ii  libpoppler820.71.0-6
> ii  librdf0 1.0.17-1.1+b1
> it  libreoffice-common  1:6.3.4-2
   ^
[...]

maybe you want to have a sane system where not various packages are
in an inconsistent state (either unpacked only or triggers pending)?

How did you get into this situation? And what did you install from sid that
it pulled the new libgcc-s1 in? And now is that related to LibreOffice?


> Versions of packages libreoffice-core recommends:
> ii  gstreamer1.0-libav 1:1.16.2-dmo2
> ii  gstreamer1.0-plugins-bad   1:1.16.2-dmo2
> iu  gstreamer1.0-plugins-base  1.16.2-dmo3
   ^
> ii  gstreamer1.0-plugins-good  1.16.2-dmo1
> ii  gstreamer1.0-plugins-ugly  1:1.16.2-dmo2


Oh, and dmo. sigh.

> ii  libpaper-utils 1.1.28+b1
> 
> libreoffice-core suggests no packages.
> 
> Versions of packages libreoffice-common depends on:
> ii  libnumbertext-data 1.0.5-3
> iu  libreoffice-style-colibre  1:6.4.0-1
   ^
> ii  libreoffice-style-tango1:6.3.4-2
> ii  ure6.3.4-2

> Versions of packages libreoffice-common suggests:
> iu  libreoffice-style-colibre [libreoffice-style]  1:6.4.0-1
   ^
> ii  libreoffice-style-tango [libreoffice-style]1:6.3.4-2
> 
> Versions of packages libreoffice-java-common depends on:
> ii  dpkg1.19.7
> it  libreoffice-common  1:6.3.4-2
   ^
> 
> Versions of packages fonts-opensymbol recommends:
> it  fontconfig  2.13.1-2+b1
   ^

See above.

And note testing has 6.4.0-1 proper since *Sunday*. So a proper
dist-upgrade should just do the right thing(tm).

That said, my test VM is already upgraded but I tried to replicate this
on buster with buster.backports and the 6.4.0 backport which is in
backports-new:

$ sudo apt -t buster-backports install fonts-opensymbol 
libreoffice-style-colibre
Paketlisten werden gelesen... Fertig

Bug#544812: reportbug: Show bugs which affect the target package in bug list

[Thorsten Glaser]

On Thu, 6 Feb 2020, Nis Martensen wrote:

> hinted at above: By default reportbug shows the list of bugs belonging
> to the source package of the target package, while "affects:" are more
> likely to be set for binary target packages. Really showing a more

Indeed, I set affects to the binary package if they affect its running
and to the source package if they cause an FTBFS.

> complete bug list by default would therefore require a different approach.

:/

But thanks for looking into it…

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

Bug#544812: reportbug: Show bugs which affect the target package in bug list

[Nis Martensen]

control: tags -1 patch

On 3 Sep 2009 James Vega  wrote:
> 
> In doing a little more poking around, I see this is only an issue when
> using querybts on a source package.  This may simply be an artifact of
> screen-scraping the BTS, but I'd have to do some tests with the BTS'
> SOAP interface to verify that.
> 
> It does make sense that the source-based view wouldn't show it since
> affects is usually used against a binary package.  The downside to the
> default source-based view that querybts (used via reportbug) is that the
> user likely misses the bugs affecting the package against which the bug
> is being filed.
> 
> One potential solution is to specifically query the binary package bug
> pages for the "affects" bugs, but that's a potential drastic increase in
> traffic to the BTS per reportbug invocation.  The long-term goal of
> switching to SOAP would likely make this trivial.

There is now a merge request on salsa that will make reportbug/querybts
also list bugs that affect the target package:
https://salsa.debian.org/reportbug-team/reportbug/merge_requests/51

However, this small change does not solve the other problem already
hinted at above: By default reportbug shows the list of bugs belonging
to the source package of the target package, while "affects:" are more
likely to be set for binary target packages. Really showing a more
complete bug list by default would therefore require a different approach.

Bug#950802: squid: CVE-2020-8449 CVE-2020-8450

[Salvatore Bonaccorso]

Source: squid
Version: 4.9-2
Severity: important
Tags: security upstream

Hi,

The following vulnerabilities were published for squid.

CVE-2020-8449[0]:
| An issue was discovered in Squid before 4.10. Due to incorrect input
| validation, it can interpret crafted HTTP requests in unexpected ways
| to access server resources prohibited by earlier security filters.


CVE-2020-8450[1]:
| An issue was discovered in Squid before 4.10. Due to incorrect buffer
| management, a remote client can cause a buffer overflow in a Squid
| instance acting as a reverse proxy.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-8449
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8449
[1] https://security-tracker.debian.org/tracker/CVE-2020-8450
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8450
[2] http://www.squid-cache.org/Advisories/SQUID-2020_1.txt

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#950801: linux-show-player: Does not install due to python error

[François Revol]

Package: linux-show-player
Version: 0.5.1-2
Severity: important

Dear Maintainer,

Trying to install linux-show-player fails:

# apt install linux-show-player
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
  python3-cffi python3-jack-client python3-mido python3-pycparser
python3-rtmidi
Paquets suggérés :
  libportmidi0 libportmidi-dev
Les NOUVEAUX paquets suivants seront installés :
  linux-show-player python3-cffi python3-jack-client python3-mido
python3-pycparser python3-rtmidi
0 mis à jour, 6 nouvellement installés, 0 à enlever et 497 non mis à jour.
Il est nécessaire de prendre 811 ko dans les archives.
Après cette opération, 4 013 ko d'espace disque supplémentaires seront
utilisés.
Souhaitez-vous continuer ? [O/n]
Réception de :1 http://deb.debian.org/debian sid/main amd64
python3-pycparser all 2.19-1 [75,6 kB]
Réception de :2 http://deb.debian.org/debian sid/main amd64 python3-cffi
all 1.13.2-1 [84,7 kB]
Réception de :3 http://deb.debian.org/debian sid/main amd64
python3-jack-client all 0.5.0-1 [36,0 kB]
Réception de :4 http://deb.debian.org/debian sid/main amd64 python3-mido
all 1.2.9-2 [49,6 kB]
Réception de :5 http://deb.debian.org/debian sid/main amd64
python3-rtmidi amd64 1.2.1-1+b2 [238 kB]
Réception de :6 http://deb.debian.org/debian sid/main amd64
linux-show-player all 0.5.1-2 [327 kB]
811 ko réceptionnés en 1s (725 ko/s)
Récupération des rapports de bogue… Fait
Analyse des informations Trouvé/Corrigé… Fait
Sélection du paquet python3-pycparser précédemment désélectionné.
(Lecture de la base de données... 786951 fichiers et répertoires déjà
installés.)
Préparation du dépaquetage de .../0-python3-pycparser_2.19-1_all.deb ...
Dépaquetage de python3-pycparser (2.19-1) ...
Sélection du paquet python3-cffi précédemment désélectionné.
Préparation du dépaquetage de .../1-python3-cffi_1.13.2-1_all.deb ...
Dépaquetage de python3-cffi (1.13.2-1) ...
Sélection du paquet python3-jack-client précédemment désélectionné.
Préparation du dépaquetage de .../2-python3-jack-client_0.5.0-1_all.deb ...
Dépaquetage de python3-jack-client (0.5.0-1) ...
Sélection du paquet python3-mido précédemment désélectionné.
Préparation du dépaquetage de .../3-python3-mido_1.2.9-2_all.deb ...
Dépaquetage de python3-mido (1.2.9-2) ...
Sélection du paquet python3-rtmidi précédemment désélectionné.
Préparation du dépaquetage de .../4-python3-rtmidi_1.2.1-1+b2_amd64.deb ...
Dépaquetage de python3-rtmidi (1.2.1-1+b2) ...
Sélection du paquet linux-show-player précédemment désélectionné.
Préparation du dépaquetage de .../5-linux-show-player_0.5.1-2_all.deb ...
Dépaquetage de linux-show-player (0.5.1-2) ...
Paramétrage de python3-mido (1.2.9-2) ...
Paramétrage de python3-rtmidi (1.2.1-1+b2) ...
Paramétrage de python3-pycparser (2.19-1) ...
Paramétrage de python3-cffi (1.13.2-1) ...
Paramétrage de python3-jack-client (0.5.0-1) ...
Paramétrage de linux-show-player (0.5.1-2) ...
Traceback (most recent call last):
  File "/usr/lib/python3.8/py_compile.py", line 144, in compile
code = loader.source_to_code(source_bytes, dfile or file,
  File "", line 846, in source_to_code
  File "", line 219, in
_call_with_frames_removed
  File "/usr/lib/python3/dist-packages/lisp/ui/ui_utils.py", line 104
return sorted(iterable, key=tr_key, reverse=reverse)\
^
SyntaxError: unexpected EOF while parsing

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/py_compile.py", line 197, in main
compile(filename, doraise=True)
  File "/usr/lib/python3.8/py_compile.py", line 150, in compile
raise py_exc
__main__.PyCompileError:   File
"/usr/lib/python3/dist-packages/lisp/ui/ui_utils.py", line 104
return sorted(iterable, key=tr_key, reverse=reverse)\
^
SyntaxError: unexpected EOF while parsing


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 193, in _run_module_as_main
return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 86, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3.8/py_compile.py", line 218, in 
sys.exit(main())
  File "/usr/lib/python3.8/py_compile.py", line 200, in main
if quiet < 2:
NameError: name 'quiet' is not defined
dpkg: erreur de traitement du paquet linux-show-player (--configure) :
 installed linux-show-player package post-installation script subprocess
returned error exit status 1
Traitement des actions différées (« triggers ») pour mime-support (3.64) ...
Traitement des actions différées (« triggers ») pour gnome-menus
(3.32.0-1) ...
Traitement des actions différées (« triggers ») pour man-db (2.9.0-2) ...
Traitement des actions différées (« triggers ») 

Bug#950714: closed upstream

[g1pi]

tags 950714 + upstream
thanks

Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so

[Thorsten Glaser]

On Thu, 6 Feb 2020, Bernhard Übelacker wrote:

> Hello Thorsten,
> getting the source of such an address is possible, even with ASLR,
> if the library versions are known and dbgsyms are available,
> like in attached file.

This is great. Do you mind writing this up and posting it somewhere
so people can link and bookmark it? Perhaps even in a place aggregated
on Planet Debian?

> It looks like a null pointer is given to strncasecmp_l.
> 
> But you are right, this information might still not be very useful,
> because the location is in libc - if it would be in cups-browsed it
> would be more useful.

Yeah, at least a backtrace… sorry I can’t be more helpful.

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

Bug#950800: ITP: azure-cosmos-table-python -- Azure Cosmos DB services Python SDK

[Luca Boccassi]

Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi" 
X-Debbugs-CC: debian-de...@lists.debian.org
Control: block 949763 by -1

* Package name: azure-cosmos-python
  Version : 1.0.5+git20191025
  Upstream Author : Microsoft Corporation
* URL : https://github.com/Azure/azure-cosmos-table-python
* License : MIT
* Programming Lang: Python
* Description : Azure Cosmos DB services Python SDK

This project provides a client library in Python that makes it easy to
consume Microsoft Azure CosmosDB services.

It is required as a new dependency of the new version of python-azure.

-- 
Kind regards,
Luca Boccassi


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

Bug#950310: re: nomacs ftbfs with libexiv2-27

[Alf Gaida]

https://github.com/nomacs/nomacs/issues/429

BTW - The "solution" you suggest don't work, i'm really not willing to
waste my time and re-invent the wheel for things that are already fixed
upstream.

With your "solution" applied - NO! Please, no - even if that means that
nomacs will disappear from testing.

Cheers Alf


In file included from
/home/agaida/work/code/pkg-main/nomacs/nomacs/src/DkCore/DkBasicLoader.cpp:568:
/home/agaida/work/code/pkg-main/nomacs/nomacs/3rdparty/drif/drif_image.h:
In function 'uint8_t* nmc::drifLoadImg(const char*, uint32_t*,
uint32_t*, uint32_t*)':
/home/agaida/work/code/pkg-main/nomacs/nomacs/3rdparty/drif/drif_image.h:171:10:
warning: ignoring return value of 'size_t fread(void*, size_t, size_t,
FILE*)', declared with attribute warn_unused_result [-Wunused-result]
  171 | fread((void*)buffer, DRIF_FOOTER_SZ, 1, fp);
  | ~^~
[ 42%] Building CXX object CMakeFiles/nomacsCore.dir/src/DkCore/DkMath.cpp.o
/usr/lib/ccache/c++  -DHAVE_EXIV2_HPP -DNDEBUG -DNOMACS_VERSION=\"3.12\"
-DQT5 -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB
-DQT_NO_DEBUG -DQT_NO_DEBUG_OUTPUT -DQT_PRINTSUPPORT_LIB -DQT_SVG_LIB
-DQT_WIDGETS_LIB -DWITH_LIBRAW -DWITH_LIBTIFF -DWITH_OPENCV
-DWITH_QUAZIP -DnomacsCore_EXPORTS
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/obj-x86_64-linux-gnu/nomacsCore_autogen/include
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/obj-x86_64-linux-gnu
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/src
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/src/DkCore
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/src/DkGui
-I/usr/include/quazip5
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/3rdparty/libqpsd
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/3rdparty/drif -isystem
/usr/include/opencv4 -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem
/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -isystem
/usr/include/x86_64-linux-gnu/qt5/QtConcurrent -isystem
/usr/include/x86_64-linux-gnu/qt5/QtSvg  -g -O2
-fdebug-prefix-map=/home/agaida/work/code/pkg-main/nomacs/nomacs=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=c++11 -Wno-unknown-pragmas -O2 -g -DNDEBUG
-fPIC   -DDK_CORE_DLL_EXPORT -DNOMINMAX -fPIC -o
CMakeFiles/nomacsCore.dir/src/DkCore/DkMath.cpp.o -c
/home/agaida/work/code/pkg-main/nomacs/nomacs/src/DkCore/DkMath.cpp
[ 43%] Building CXX object
CMakeFiles/nomacsCore.dir/src/DkCore/DkMessageBox.cpp.o
/usr/lib/ccache/c++  -DHAVE_EXIV2_HPP -DNDEBUG -DNOMACS_VERSION=\"3.12\"
-DQT5 -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB
-DQT_NO_DEBUG -DQT_NO_DEBUG_OUTPUT -DQT_PRINTSUPPORT_LIB -DQT_SVG_LIB
-DQT_WIDGETS_LIB -DWITH_LIBRAW -DWITH_LIBTIFF -DWITH_OPENCV
-DWITH_QUAZIP -DnomacsCore_EXPORTS
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/obj-x86_64-linux-gnu/nomacsCore_autogen/include
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/obj-x86_64-linux-gnu
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/src
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/src/DkCore
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/src/DkGui
-I/usr/include/quazip5
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/3rdparty/libqpsd
-I/home/agaida/work/code/pkg-main/nomacs/nomacs/3rdparty/drif -isystem
/usr/include/opencv4 -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem
/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -isystem
/usr/include/x86_64-linux-gnu/qt5/QtConcurrent -isystem
/usr/include/x86_64-linux-gnu/qt5/QtSvg  -g -O2
-fdebug-prefix-map=/home/agaida/work/code/pkg-main/nomacs/nomacs=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=c++11 -Wno-unknown-pragmas -O2 -g -DNDEBUG
-fPIC   -DDK_CORE_DLL_EXPORT -DNOMINMAX -fPIC -o
CMakeFiles/nomacsCore.dir/src/DkCore/DkMessageBox.cpp.o -c
/home/agaida/work/code/pkg-main/nomacs/nomacs/src/DkCore/DkMessageBox.cpp
/home/agaida/work/code/pkg-main/nomacs/nomacs/src/DkCore/DkImageStorage.cpp:
In static member function 'static void nmc::DkImage::tinyPlanet(QImage&,
double, double, QSize, bool)':
/home/agaida/work/code/pkg-main/nomacs/nomacs/src/DkCore/DkImageStorage.cpp:1508:27:
error: cannot convert 'cv::Point2d' {aka 'cv::Point_'} to
'CvPoint2D32f'
 1508 |  logPolar(mImg, mImg, cv::Point2d(mImg.cols*0.5, mImg.rows*0.5),
scaleLog, angle);
  |   ^
  |   |
  | 

Bug#950799: matplotlib: Autopkgtest depends on nonexistent python3-wxgtk3.0 package

[Dmitry Shachnev]

Source: matplotlib
Version: 3.1.2-1
Severity: important

Dear Maintainer,

matplotlib's debian/tests/control has the following test:

  Tests: wxagg
  Depends: xauth, xvfb, python3-matplotlib, python3-wxgtk3.0, python3-numpy

However there is no package python3-wxgtk3.0 (and never was).

There is python3-wxgtk4.0, I believe it should be used instead.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#888705: ITP: abseil -- Collection of C++ code (compliant to C++11) designed to augment the C++ standard library

[Benjamin Barenblat]

It looks like there hasn’t been any activity on this for a while. I hear
there’s going to be a new Abseil LTS release sometime in the next few
weeks; would it be all right if I took this bug and packaged Abseil once
the LTS hits GitHub?

(Full disclosure: I work at Google and sit near some Abseil developers.
However, I don’t work on Abseil for my day job; packaging it would be a
20% effort. I’d continue maintaining the package even if I left Google.)

Bug#950797: ITP: ruby-jaro-winkler -- Implementation of Jaro-Winkler distance algorithm

[Sebastien Badia]

Package: wnpp
Severity: wishlist
Owner: Sebastien Badia 

* Package name: ruby-jaro-winkler
  Version : 1.5.4
  Upstream Author : Jian Weihang 
* URL : https://github.com/tonytonyjan/jaro_winkler
* License : MIT
  Programming Lang: Ruby, C
  Description : Implementation of Jaro-Winkler distance algorithm

 jaro_winkler is an implementation of Jaro-Winkler distance algorithm which is
 written in C extension and will fallback to pure Ruby version in platforms
 other than MRI/KRI like JRuby or Rubinius. Both of C and Ruby implementation
 support any kind of string encoding, such as UTF-8, EUC-JP, Big5, etc.

This package is a new dependency of rubocop. I will plan to maintain this
package
inside the Debian Ruby Team.

Bug#950798: RM: leap-cli -- ROM; deprecated, no reverse-depends

[Georg Faerber]

Package: ftp.debian.org
Severity: normal
User: pkg-ruby-extras-maintain...@lists.alioth.debian.org
Usertags: ruby2.7-transition
X-Debbugs-CC: mi...@debian.org

Please remove leap-cli from unstable. It's deprecated and never migrated
to testing. Besides, it FTBFS with Ruby 2.7, which we are currently
transitioning to.

Thanks for your work!

Cheers,
Georg

Bug#888705: ITP: abseil -- Collection of C++ code (compliant to C++11) designed to augment the C++ standard library

[Anton Gladky]

Hello Benjamin,

I have already done a basic packaging, it just
need to be updated to a newer version.

I am planning to do it in the near future. Feel free to join
as a maintainer of this package.

Regards

Anton

Am Do., 6. Feb. 2020 um 18:06 Uhr schrieb Benjamin Barenblat
:
>
> It looks like there hasn’t been any activity on this for a while. I hear
> there’s going to be a new Abseil LTS release sometime in the next few
> weeks; would it be all right if I took this bug and packaged Abseil once
> the LTS hits GitHub?
>
> (Full disclosure: I work at Google and sit near some Abseil developers.
> However, I don’t work on Abseil for my day job; packaging it would be a
> 20% effort. I’d continue maintaining the package even if I left Google.)

Bug#950796: ITP: passivedns -- network sniffer that logs all DNS server replies

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: passivedns
  Version : 1.2.1
  Upstream Author : Edward Bjarte Fjellskål 
* URL : https://github.com/gamelinux/passivedns
* License : GPL-2+
  Programming Lang: C
  Description : network sniffer that logs all DNS server replies for use in 
a passive DNS setup

A tool to collect DNS records passively to aid Incident handling, Network
Security Monitoring (NSM) and general digital forensics.

PassiveDNS sniffs traffic from an interface or reads a pcap-file and outputs
the DNS-server answers to a log file. PassiveDNS can cache/aggregate duplicate
DNS answers in-memory, limiting the amount of data in the logfile without
losing the essense in the DNS answer.

PassiveDNS works on IPv4 and IPv6 traffic and parse DNS traffic over TCP and
UDP.

---

I will maintain the package together with Sascha Steinbiss
(X-Debbugs-CC'ed).

Bug#950795: buster-pu: package puma/3.12.0-2

[Daniel Leidert]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The proposed update will fix CVE-2019-16770 (#946312) for Buster users. The
security team marked the issue no-dsa and asked to schedule the fix via the
next point release. The debdiff is attached. The patch to fix the CVE has been
taken from upstream's Git repository.

The debdiff is attached.

Please let me know, how to proceed.

Regards, Daniel


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

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl48P9cACgkQS80FZ8KW
0F2aKQ//VCdYXCl4gK1NSWOH5NtwoyIFoUcC6ofglL+shomnFMbvwr3V7H4rpVta
7oOysLOfGEmsCJXL5kcl0awijAmFz58dmlRmeSAOlirJ+09eyS56v/gSVPODueTA
7UjvjPQV3gJRgA0bsLEjTfIyyE9S17ylxDF9t1FRYGqngkTM3aYaz4NR5WMrFWGs
b0ogyJxjpDW3VHgy2b0smrED5j2/Amo11DIg9CYhNyV5zAoNmH93cMlS+67p7CDK
WIghSH4BoMjv0THRh521HK7hVywKFKhCHhG/fXCAEQnPgfP9umtBaM1eQeItpRRf
A5MGtYBDLrvm8YLbtL0Fl8TsEYjdJmEUoS4Pr1HtVC4TiFLei6QxmriAY2pv+7h0
XtMyZ/L4dCCiilSUd58cnLBSdCm8OTf/NUI7m7zdCBDwG76ewbeuWQ59X6a8j+oH
uOGeOjJJvxKlO1ngyLrPC8jZOcKNwGwdsBpI6YgOvSGWbQU3RWjlzmw+M/YgVaHL
zIg5nEJHnTmdZUr22e4vaQ0kwH73Ggst+hA68LdZ9auDlb+o/37Rp8tz7M966c/x
Tcoduwr5TLDMzLBtDYMpqw+8jakdpwACWGErqR46XcUtUtjQAy0GMQXucgQNwIw/
mZp5UDEsKR7RE6baUPMcQKMcU0W7AIWXGD2LrYMW/WmV9HverYY=
=Fie4
-END PGP SIGNATURE-
diff -Nru puma-3.12.0/debian/changelog puma-3.12.0/debian/changelog
--- puma-3.12.0/debian/changelog2019-02-10 14:26:47.0 +0100
+++ puma-3.12.0/debian/changelog2020-02-06 13:25:24.0 +0100
@@ -1,3 +1,12 @@
+puma (3.12.0-2+deb10u1) buster-security; urgency=medium
+
+  * Team upload.
+  * d/patches/CVE-2019-16770.patch: Add patch.
+- Backport fix for CVE-2019-16770 from upstream (closes: #946312).
+  * d/patches/series: Add patch.
+
+ -- Daniel Leidert   Thu, 06 Feb 2020 13:25:24 +0100
+
 puma (3.12.0-2) unstable; urgency=medium
 
   * Disable tests failing in single cpu (Closes: #921931)
diff -Nru puma-3.12.0/debian/patches/CVE-2019-16770.patch 
puma-3.12.0/debian/patches/CVE-2019-16770.patch
--- puma-3.12.0/debian/patches/CVE-2019-16770.patch 1970-01-01 
01:00:00.0 +0100
+++ puma-3.12.0/debian/patches/CVE-2019-16770.patch 2020-02-06 
13:25:24.0 +0100
@@ -0,0 +1,69 @@
+From: Nate Berkopec 
+Date: Thu, 5 Dec 2019 14:19:32 +0700
+Subject: Merge pull request from GHSA-7xx3-m584-x994
+
+could monopolize a thread. Previously, this could make a DoS attack more
+severe.
+
+Co-authored-by: Evan Phoenix 
+
+Debian-Bug: https://bugs.debian.org/946312
+Acked-By: Daniel Leidert 
+Origin: 
https://github.com/puma/puma/commit/06053e60908074bb38293d4449ea261cb009b53e.patch
+---
+ lib/puma/const.rb  |  7 +++
+ lib/puma/server.rb | 16 +++-
+ 2 files changed, 22 insertions(+), 1 deletion(-)
+
+diff --git a/lib/puma/const.rb b/lib/puma/const.rb
+index f9e0a2a..7fc105c 100644
+--- a/lib/puma/const.rb
 b/lib/puma/const.rb
+@@ -116,6 +116,13 @@ module Puma
+ # sending data back
+ WRITE_TIMEOUT = 10
+ 
++# How many requests to attempt inline before sending a client back to
++# the reactor to be subject to normal ordering. The idea here is that
++# we amortize the cost of going back to the reactor for a well behaved
++# but very "greedy" client across 10 requests. This prevents a not
++# well behaved client from monopolizing the thread forever.
++MAX_FAST_INLINE = 10
++
+ # The original URI requested by the client.
+ REQUEST_URI= 'REQUEST_URI'.freeze
+ REQUEST_PATH = 'REQUEST_PATH'.freeze
+diff --git a/lib/puma/server.rb b/lib/puma/server.rb
+index e2e862f..66a982a 100644
+--- a/lib/puma/server.rb
 b/lib/puma/server.rb
+@@ -468,6 +468,8 @@ module Puma
+ clean_thread_locals = @options[:clean_thread_locals]
+ close_socket = true
+ 
++requests = 0
++
+ while true
+   case handle_request(client, buffer)
+   when false
+@@ -481,7 +483,19 @@ module Puma
+ 
+ ThreadPool.clean_thread_locals if clean_thread_locals
+ 
+-unless client.reset(@status == :run)
++requests += 1
++
++check_for_more_data = @status == :run
++
++if requests >= MAX_FAST_INLINE
++  # This will mean that reset will only try to use the data it 
already
++  # has buffered and won't try to read more data. What this means 
is that
++  # every client, independent of their request speed, gets 
treated like a slow
++  # one once every 

Bug#938656: texlive-extra: Python2 removal in sid/bullseye

[Sandro Tosi]

On Thu, Feb 6, 2020 at 10:23 AM Hilmar Preuße  wrote:
>
> Am 31.01.2020 um 11:21 teilte Norbert Preining mit:
>
> Hi Norbert,
>
> >> could you please have a look at this bug soon? texlive-science is the
> >
> > Well, I will upload some packages at some point in the future, which
> > simply upgrades all py2 to py3 deps, not taking into consideration
> > whether the actual files/scripts support/can be used with Py3.
> >
> > We are talking about 1+ files to be checked, and the gratious
> > deprecation of Py2 creates a bit of problems in TeX, where packages
> > that have been written 20 years ago are **still** in use, despite
> > not having a maintainer.
> >
> > So, let us happily break all this.
> >
> I'm not sure what you mean if you say "all this". Currently I see just
> one python script in texlive-sience
>
> hille@sid:~ $ dpkg -L texlive-science|grep \.py$
> /usr/share/texlive/texmf-dist/scripts/sympytexpackage/sympytex.py
>
> ..and yes it depends on python-sympy. Nevertheless I think we can drop
> the recommendation on python-sympy and the dep on python2: it will just
> break /one/ script.

FYI sympy in debian unstable already dropped python2 support:
https://packages.qa.debian.org/s/sympy/news/20200202T205535Z.html


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#935304: libpam-systemd: Please relax Depends: systemd-sysv

[Sam Hartman]

> "Michael" == Michael Biebl  writes:


Michael> b/ you need a different way to switch
Michael> over. Reboot into an environment for which you have control
Michael> over, then uninstall systemd/systemd-sysv without
Michael> triggering the removal of most packages.


This is fairly close to what Mark and smcv ended up doing: effectively
removing /run/systemd/system, doing the package operations and
immediately rebooting.
They didn't boot into a special environment, so what they did is a bit
more risky.
But as a script explicitly run by a sysadmin on a reasonably quiet
system,
I think that might well be an appropriate answer at least in the scope
of proposal B, where we're trying to enable exploration of new
alternatives.
Such exploration is inherently somewhat experimental in nature.

Bug#949843: Missed part of systemd-nspawn patch

[Daniel Schepler]

I just realized based on some testing that I forgot to send part of
the patch, which is needed for sbuild-update to work with the
systemd-nspawn chroot backend.
-- 
Daniel Schepler
Description: missed part of systemd-nspawn backend patch needed for sbuild-update
Author: Daniel Schepler 

--- sbuild-0.78.1.orig/lib/Sbuild/Utility.pm
+++ sbuild-0.78.1/lib/Sbuild/Utility.pm
@@ -99,6 +99,9 @@ sub setup ($$$) {
 } elsif ($conf->get('CHROOT_MODE') eq 'unshare') {
 	require Sbuild::ChrootInfoUnshare;
 	$chroot_info = Sbuild::ChrootInfoUnshare->new($conf);
+} elsif ($conf->get('CHROOT_MODE') eq 'systemd-nspawn') {
+	require Sbuild::ChrootInfoNspawn;
+	$chroot_info = Sbuild::ChrootInfoNspawn->new($conf);
 } else {
 	require Sbuild::ChrootInfoSudo;
 	$chroot_info = Sbuild::ChrootInfoSudo->new($conf);

Bug#950777: FTBFS on s390x (and others)

[Chris Lamb]

Hi Christian

> I have also filed a salsa MR [2] but it seems the MR was missed when 
> uploading 1.5.22-1 recently (I assume we raced each other working on 
> this).

I think I just didn't see it. Merged and releasing now as 1.5.22-2 :)


Best wishes,

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

Bug#950732: systemd: CVE-2020-1712

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream

Hi,

For completeness the following additional point:

On Wed, Feb 05, 2020 at 02:20:14PM +0100, Salvatore Bonaccorso wrote:
> The following vulnerability was published for systemd, filling bug to
> track the issue in BTS. Raised severity to RC, although the question
> on DSA/no-dsa can be handled ortogonal to it.
> 
> CVE-2020-1712[0]:
> heap use-after-free vulnerability

systemd-machined was one of the target services which could be
exploitable. Red Hat bug vies a hint on which other services are
targets. Vulnerable Dbus methods have:

1) a "find" function for the associated object (e.g. image_object_find)
   that configures a temporary cache and setups a "defer_event" which
   frees the elements in the cache
2) a call to bus_verify_polkit_async() in the handler of the method
   (e.g. bus_image_method_clone)
3) SD_BUS_VTABLE_UNPRIVILEGED as one of the specified flags

https://bugzilla.redhat.com/show_bug.cgi?id=1794578#c10

The upstream fix was merged in v245-rc1.

Regards,
Salvatore

Bug#950794: gem2deb should check if the shipped gemspec's version matches the package version

[Pirate Praveen]

Package: gem2deb
Version: 1.0.4
severity: wishlist

This was noticed in ruby-i18n which takes version of already installed 
package instead of the package we are building. So 1.5.3-1 shipped a 
gemspec with version 0.7 instead of 1.5.3. We should add a test to 
check if verison in changelog matches with the version in gemspec.

Bug#934141: [Pkg-javascript-devel] Bug#934141: jsbeautifier and node-js-beautify should use alternatives

[Xavier]

Le 07/08/2019 à 19:13, Xavier a écrit :
> Le 07/08/2019 à 14:56, Xavier Guimard a écrit :
>> Package: jsbeautifier
>> Version: 1.6.4-7
>> Severity: normal
>>
>> Hi all,
>>
>> both jsbeautifier and node-js-beautify come from the same upstream
>> source, the first provides js-beautify and the second html-beautify and
>> css-beautify. This crazy situation should be solved by an "alternative" to
>> provides the 3 scripts.
>>
>> Cheers,
>> Xavier
> 
> This situation follows https://bugs.debian.org/888903 in which it was
> decided to keep /usr/bin/js-beautify in jsbeautifier (previously
> packaged) even if node-js-beautify provided /usr/bin/html-beautify and
> /usr/bin/css-beautify.
> 
> Upstream source provides both Python and JavaScript code to build these
> binaries, same name, same algorithm, same options but different languages.

I'm expanding this thread to for lack of response

Bug#950762: ksh,ksh93: both ship /etc/skel/.kshrc with insufficient Conflicts/Breaks/Replaces

[Thorsten Glaser]

Hi Andreas,

>  apt-get install ksh
>  # (1)
>  apt-get install ksh93
>  apt-get remove ksh93
>  # (2)
>
>The list of installed files at points (1) and (2) should be identical,
>but the following files have disappeared:
>
>  /etc/skel/.kshrc
>
>(also happens with both packages swapped)

yes, this is documented in NEWS.Debian in both packages.

>Since you obviously want the two packages to be co-installable,
>* either move /etc/skel/.kshrc to a separate packages, and let both depend on 
>it

I had considered that, but creating a ksh-common package for just
one file, which in addition to that is a skeleton file that is not
used during normal operation, just adduser, seems overkill. The
sequence of installing both then removing one is also expected to
occur only rarely, most users would either install one, or both,
and then keep that. I had thought that that with the Replaces on
the other packages would be sufficient.

Is it possible to make an exception here, considering the file in
question and that it is documented?

Thanks in advance,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#950793: blhc: Reports missing -D_FORTIFY_SOURCE=2 for libtool linking

[Thomas Stewart]

Package: blhc
Version: 0.11-1
Severity: normal

Hi,

I've been trying to fix a dpkg-buildflags-missing CPPFLAGS lintian issue
in the w1retap package, the blhc output on the build log is:

CPPFLAGS missing (-D_FORTIFY_SOURCE=2): libtool: link: (cd .libs && gcc -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -c -fno-builtin "w1retapS.c")

However looking at the build log snippet[0] the full command is actually
a call to libtool in link mode. This libtool invocation generates a new
S.c file to generate dlsyms information. Looking at the internals of a
generated libtool[1], it's basing the gcc args on LTCFLAGS.

When libtool is generated it bases its LTCFLAGS from CFLAGS[2]. Looking
at the dpkg-buildflags hardening the -D_FORTIFY_SOURCE=2 flag is for
CPPFLAGS rather than CFLAGS[3].

If I rebuild[4] adding qa=+canary to DEB_BUILD_MAINT_OPTIONS I can see
that the canary CFLAGS get added to the libtool call and to the same gcc
call for w1retapS.c for dlsyms generation.

I suspect that blhc is erroneously reporting this.

Kind Regards
Tom

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (600, 'experimental'), (500, 
'unstable-debug'), (500, 'testing-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: armel, armhf, i386

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

Versions of packages blhc depends on:
ii  libdpkg-perl  1.19.7

blhc recommends no packages.

blhc suggests no packages.

-- debconf-show failed

-- footnotes
[0]
/bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -m
odule -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lxml2 
-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -Wl,--disable-new-dtags -o libw1xml.la 
-rpath /usr/li
b/x86_64-linux-gnu/w1retap libw1xml_la-w1xml.lo  -lxml2 -lrt -lm 
libtool: link: gcc -shared  -fPIC -DPIC  .libs/w1csv.o   -lgmodule-2.0 
-lglib-2.0 -lxml2 -lrt -lm  -g -O2 -fstack-protector-strong 
-Wl,--export-dynamic -pthread 
-Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -Wl,--disable-new-dtags   
-pthread -Wl,-soname -Wl,libw1csv.so.0 -o .libs/libw1csv.so.0.0.0
libtool: link: gcc -shared  -fPIC -DPIC  .libs/w1file.o   -lgmodule-2.0 
-lglib-2.0 -lxml2 -lrt -lm  -g -O2 -fstack-protector-strong 
-Wl,--export-dynamic -pthread
 -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -Wl,--disable-new-dtags   
-pthread -Wl,-soname -Wl,libw1file.so.0 -o .libs/libw1file.so.0.0.0
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libw1xml_la-w1xml.o   
-lgmodule-2.0 -lglib-2.0 -lxml2 -lrt -lm  -g -O2 -fstack-protector-strong 
-Wl,--export-dynam
ic -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed 
-Wl,--disable-new-dtags   -pthread -Wl,-soname -Wl,libw1xml.so.0 -o 
.libs/libw1xml.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libw1file.so.0" && ln -s 
"libw1file.so.0.0.0" "libw1file.so.0")
libtool: link: (cd ".libs" && rm -f "libw1csv.so.0" && ln -s 
"libw1csv.so.0.0.0" "libw1csv.so.0")
libtool: link: (cd ".libs" && rm -f "libw1file.so" && ln -s 
"libw1file.so.0.0.0" "libw1file.so")
libtool: link: (cd ".libs" && rm -f "libw1csv.so" && ln -s "libw1csv.so.0.0.0" 
"libw1csv.so")
libtool: link: ar cru .libs/libw1file.a  w1file.o
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libw1file.a
libtool: link: ar cru .libs/libw1csv.a  w1csv.o
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libw1csv.a
libtool: link: (cd ".libs" && rm -f "libw1xml.so.0" && ln -s 
"libw1xml.so.0.0.0" "libw1xml.so.0")
libtool: link: (cd ".libs" && rm -f "libw1xml.so" && ln -s "libw1xml.so.0.0.0" 
"libw1xml.so")
libtool: link: ( cd ".libs" && rm -f "libw1file.la" && ln -s "../libw1file.la" 
"libw1file.la" )
libtool: link: ( cd ".libs" && rm -f "libw1csv.la" && ln -s "../libw1csv.la" 
"libw1csv.la" )
libtool: link: ar cru .libs/libw1xml.a  libw1xml_la-w1xml.o
/bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -r
dynamic  -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0  -Wl,-z,relro 
-Wl,-z,now -Wl,--as-needed -Wl,--disable-new-dtags -o w1retap w1retap-w1retap.o 
w1r
etap-w1conf.o w1retap-w1util.o w1retap-w1sensors.o "-dlopen" libw1file.la  
-L./libusblinux300/.libs -L./libusblinux300 -lowfat -lw1common -lm -lxml2 -lrt 
-lm 
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libw1xml.a
libtool: link: ( cd ".libs" && rm -f "libw1xml.la" && ln -s "../libw1xml.la" 
"libw1xml.la" )
libtool: link: rm -f .libs/w1retap.nm .libs/w1retap.nmS .libs/w1retap.nmT

Bug#938656: texlive-extra: Python2 removal in sid/bullseye

[Hilmar Preuße]

Am 31.01.2020 um 11:21 teilte Norbert Preining mit:

Hi Norbert,

>> could you please have a look at this bug soon? texlive-science is the
> 
> Well, I will upload some packages at some point in the future, which
> simply upgrades all py2 to py3 deps, not taking into consideration
> whether the actual files/scripts support/can be used with Py3.
> 
> We are talking about 1+ files to be checked, and the gratious 
> deprecation of Py2 creates a bit of problems in TeX, where packages
> that have been written 20 years ago are **still** in use, despite
> not having a maintainer.
> 
> So, let us happily break all this.
> 
I'm not sure what you mean if you say "all this". Currently I see just
one python script in texlive-sience

hille@sid:~ $ dpkg -L texlive-science|grep \.py$
/usr/share/texlive/texmf-dist/scripts/sympytexpackage/sympytex.py

..and yes it depends on python-sympy. Nevertheless I think we can drop
the recommendation on python-sympy and the dep on python2: it will just
break /one/ script.

On github you'll notice that the script author already did some steps to
support python3, but I guess it is not completed yet.

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



signature.asc
Description: OpenPGP digital signature

Bug#383884:

[Maria del carmen Torrado barreales]

Bug report

Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies

[Ansgar]

On Wed, 20 Mar 2019 16:31:25 +0100 Ansgar wrote:
> the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
> than just libpq5

And another one might come up in a few months:

+---
| * unify on openssl:
|   - port sd_id128_get_machine_app_specific() over from khash
|   - port resolved over from libgcrypt (DNSSEC code)
|   - port journald + fsprg over from libgcrypt
|   - port importd over from libgcrypt
|   - when that's done: kill khash.c
|   - when that's done: kill gnutls support in resolved
+---[ systemd/TODO ]

At least `sd_*` should be in libsystemd.

So we should try to really get this off our TODO list soon :-)

Ansgar