Bug#956233: lintian: Perl bug triaged

[Felix Lechner]

Hi,

On Wed, Apr 8, 2020 at 10:30 AM Dmitry Shachnev  wrote:
>
>   Can't open 
> '/tmp/lintian-pool-z2LddsoVG9/pool/s/sphinx/sphinx_2.4.3-2+salsaci_source/unpacked/tests/roots/test-images/testimäge.png'
>  with mode '<:raw': 'No such file or directory' at 
> /usr/share/lintian/checks/cruft.pm line 992

The Perl bug that causes the runtime failures in both bugs was triaged
with this commit:


https://salsa.debian.org/lintian/lintian/-/commit/412b592077efdde9609f3fce98493909daa77172

It should make resolution less urgent, although both bugs will be
addressed very soon. Sorry about the inconvenience.

Kind regards
Felix Lechner

Bug#923940: [libtheoraenc] What resolution were you looking for?

[Paul Wise]

On Tue, 2020-04-14 at 22:17 -0700, Ralph Giles wrote:

> Looking at this bug, I don't understand what exactly you're reporting.

I'm reporting underlinking at the ELF file level.

> libtheoraenc does depend on libtheoradec, so applications need to
> link to both. This is declared in the pkg-config file:

Generally one should only link a program with libraries that provide
symbols that are directly used by the program. There are lots of tools
that warn about unused libraries, especially dpkg-shlibdeps/adequate.

> $ pkg-config --libs theoraenc
> -ltheoraenc -ltheoradec -logg

Even when a program is linked using the flags suggested by pkg-config,
IIRC there are some GCC flags that ask the linker to drop dependencies
on unused libs, so a program linking against libtheoraenc.pc libs but
not libtheoradec.pc could have their libtheoradec linkage dropped and
then the program would fail to start because libtheoraenc references
libtheoradec symbols but neither of the the ELF files for the program
nor libtheoraenc depend on libtheoradec so it doesn't get loaded.

> Do you want libtheoraenc.so to declare the dependency internally so
> bare -ltheoraenc works on (some) linkers without bothering with
> pkg-config?

If libtheoraenc uses some functions from libtheoradec then it should
link against libtheoradec.

> Petters patch will remove the dependency entirely,

I'm not sure this is the correct solution, since it duplicates
libtheoradec functions inside libtheoraenc and might also add those
functions to the ABI of libtheoraenc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#923940: libtheoraenc.so: undefined symbols: needs -ltheoradec

[Petter Reinholdtsen]

Control: forwarded -1 https://github.com/xiph/theora/pull/11

I've requested the change upstream.

-- 
Happy hacking
Petter Reinholdtsen

Bug#923940: [libtheoraenc] What resolution were you looking for?

[Ralph Giles]

Paul,

Looking at this bug, I don't understand what exactly you're reporting.
libtheoraenc does depend on libtheoradec, so applications need to link
to both. This is declared in the pkg-config file:

$ pkg-config --libs theoraenc
-ltheoraenc -ltheoradec -logg

Is the issue that this dependency exists at all? Do you want
libtheoraenc.so to declare the dependency internally so bare 
-ltheoraenc works on (some) linkers without bothering with
pkg-config?

Petters patch will remove the dependency entirely,

Apologies if this is just reading comprehension fail on my part!

 -r



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

Bug#956748: ITP: node-pause -- Pause a stream's data events

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name    : node-pause
  Version : 0.1.0
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/stream-utils/pause
* License : Expat
  Programming Lang: JavaScript
  Description : Pause a stream's data events
 Pause the data events on a stream and return a handle to resume or end the
 stream.

node-pause is a dependency of shiny-server.

Remark: This package is to be maintained with Debian Javascript
Maintainers at
   https://salsa.debian.org/js-team/node-pause

Bug#956747: golang-gopkg-readline.v1: Duplicated with src:golang-github-chzyer-readline

[Shengjing Zhu]

Source: golang-gopkg-readline.v1
Severity: normal

Dear Maintainer,

This package src:golang-gopkg-readline.v1 is same as 
src:golang-github-chzyer-readline.

So I'm going to update src:golang-github-chzyer-readline, let it
provides golang-gopkg-readline.v1-dev.

Then request RM this package.

Bug#956746: Perl compatibility error in mummerplot

[Charles Plessy]

Package: mummer
Version: 3.23+dfsg-4
Severity: important

Hello everybody,

the `mummerplot` Perl script in the mummer package is broken because it
contains some deprecated Perl syntax.  The attached patch solves the
problem.

I am not sure if it is enough for a Stable update.  In Sid, maybe it is
a sign that an upgrade to MUMmer4 (where at least this issue is fixed)
would be useful.

Have a nice day,

Charles

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

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

Versions of packages mummer depends on:
ii  gawk1:4.2.1+dfsg-1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6
ii  perl5.28.1-6

mummer recommends no packages.

mummer suggests no packages.

-- no debconf information
--- /usr/bin/mummerplot 2018-06-11 15:38:49.0 +0900
+++ mummerplot.patched  2020-04-15 13:38:35.483544650 +0900
@@ -881,7 +881,7 @@
 my ($refoff, $reflen, $refdir);
 my ($qryoff, $qrylen, $qrydir);
 
-if ( defined (%$rref) ) {
+if ( %$rref ) {
 #-- skip reference sequence or set atts from hash
 if ( !exists ($rref->{$idR}) ) { next; }
 else { ($refoff, $reflen, $refdir) = @{$rref->{$idR}}; }
@@ -891,7 +891,7 @@
 ($refoff, $reflen, $refdir) = (0, $lenR, 1);
 }
 
-if ( defined (%$qref) ) {
+if ( %$qref ) {
 #-- skip query sequence or set atts from hash
 if ( !exists ($qref->{$idQ}) ) { next; }
 else { ($qryoff, $qrylen, $qrydir) = @{$qref->{$idQ}}; }
@@ -978,7 +978,7 @@
 my ($refoff, $reflen, $refdir);
 my ($qryoff, $qrylen, $qrydir);
 
-if ( defined (%$rref) ) {
+if ( %$rref ) {
 #-- skip reference sequence or set atts from hash
 if ( !exists ($rref->{$idR}) ) { next; }
 else { ($refoff, $reflen, $refdir) = @{$rref->{$idR}}; }
@@ -988,7 +988,7 @@
 ($refoff, $reflen, $refdir) = (0, $lenR, 1);
 }
 
-if ( defined (%$qref) ) {
+if ( %$qref ) {
 #-- skip query sequence or set atts from hash
 if ( !exists ($qref->{$idQ}) ) { next; }
 else { ($qryoff, $qrylen, $qrydir) = @{$qref->{$idQ}}; }
@@ -1031,7 +1031,7 @@
 }
 
 
-if ( !defined (%$rref) ) {
+if ( !%$rref ) {
 if ( $ismultiref ) {
 print STDERR
 "WARNING: Multiple ref sequences overlaid, try -R or -r\n";
@@ -1041,7 +1041,7 @@
 }
 }
 
-if ( !defined (%$qref) ) {
+if ( !%$qref ) {
 if ( $ismultiqry && !$OPT_coverage ) {
 print STDERR
 "WARNING: Multiple qry sequences overlaid, try -Q, -q or -c\n";

Bug#902180: RM: golang-github-docker-engine-api -- ROM; obsolete

[Juhani Numminen]

Control: tags -1 -moreinfo

The new version of kubernetes is not a reverse build-dependency anymore.
There are individual RM requests for the remaining blockers: #956741 and 
#956743.
I removed the moreinfo tag to signal that the FTP masters can go ahead and 
remove
golang-github-docker-engine-api in the same batch with those two.


--
Juhani

Bug#956177: fail2ban: daemon startup should not access /root/.local

[Russell Coker]

On Wednesday, 15 April 2020 2:36:43 AM AEST Sylvestre Ledru wrote:
> Could you please reply to
> https://github.com/fail2ban/fail2ban/issues/2688#issuecomment-613543589 ?
> 
> (I also looked at the code and could not find where /root/.local would be
> loaded)

Done.  strace revealed the following:

stat("/root/.local/lib/python3.8/site-packages", 0x7ffe878316d0) = -1 ENOENT 
(No such file or directory)


-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#944913: [Python-modules-team] Bug#944913: Bug#944913: Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1

[Sandro Tosi]

> Unfortunately, today sphinx dependencies are uninstallable because of #956625.
> So if I upload sphinx now it will most probably FTBFS.
>
> I will wait until that bug is fixed.

looks like that bug has been fixed, wanna give this another try? thanks!

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

Bug#956745: xonsh autopkgtest fails: out of pty devices

[Jonathan Nieder]

Source: xonsh
Version: 0.9.15+dfsg-1
Severity: important
Justification: blocking git security fix from migrating to testing

The xonsh autopkgtest is failing on arm64:

https://ci.debian.net/data/autopkgtest/testing/arm64/x/xonsh/4989133/log.gz
 xonsh test: test_indir 
xonsh execution failed
  File 
"/tmp/autopkgtest-lxc.hzugiy0a/downtmp/autopkgtest_tmp/tests/test_lib/test_os.xsh",
 line 15, in test_indir
assert ![pwd].output.strip() != tmpdir
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 22621, in 
subproc_captured_hiddenobject
return run_subproc(cmds, captured="hiddenobject")
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 22546, in 
run_subproc
specs = cmds_to_specs(cmds, captured=captured)
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 22516, in 
cmds_to_specs
_update_last_spec(specs[-1])
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 22450, in 
_update_last_spec
r, w = pty.openpty() if use_tty else os.pipe()
  File "/usr/lib/python3.8/pty.py", line 30, in openpty
master_fd, slave_name = _open_terminal()
  File "/usr/lib/python3.8/pty.py", line 60, in _open_terminal
raise OSError('out of pty devices')
OSError: out of pty devices
___ xonsh test: test_rmtree 
xonsh execution failed
  File 
"/tmp/autopkgtest-lxc.hzugiy0a/downtmp/autopkgtest_tmp/tests/test_lib/test_os.xsh",
 line 29, in test_rmtree
mkdir rmtree_test
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 22621, in 
subproc_captured_hiddenobject
return run_subproc(cmds, captured="hiddenobject")
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 22546, in 
run_subproc
specs = cmds_to_specs(cmds, captured=captured)
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 22516, in 
cmds_to_specs
_update_last_spec(specs[-1])
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 22450, in 
_update_last_spec
r, w = pty.openpty() if use_tty else os.pipe()
  File "/usr/lib/python3.8/pty.py", line 30, in openpty
master_fd, slave_name = _open_terminal()
  File "/usr/lib/python3.8/pty.py", line 60, in _open_terminal
raise OSError('out of pty devices')
OSError: out of pty devices
[etc]

pytest   FAIL non-zero exit status 1

Bug#956516: ImportError: cannot import name '_coin' from 'pivy'

[Petr Vanek]

Package: freecad
Version: 0.18.4+dfsg2-1
Followup-For: Bug #956516

It seems that as 0.18.4+dfsg2-1 is built against python3.7, and Debian now 
uses python3.8, that is the cause for the module import error.

This bug is preventing for example export of models from .stp into .obj,
making Freecad unusable, because you cannot export your work anymore.

Thank you

Petr

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

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

Versions of packages freecad depends on:
ii  freecad-python3  0.18.4+dfsg2-1

Versions of packages freecad recommends:
ii  calculix-ccx  2.11-1+b3
ii  graphviz  2.42.2-3+b3

Versions of packages freecad suggests:
pn  povray  

-- debconf-show failed

Bug#956744: RM: golang-github-rsc-letsencrypt -- ROM; obsolete

[Dmitry Smirnov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org
Control: affects -1 src:golang-github-rsc-letsencrypt

Please remove "golang-github-rsc-letsencrypt" from "unstable".

The package is obsolete and no longer maintained upstream.

Thanks.

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

Bug#955549: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults

[Chao Yu]

On 2020/4/10 7:32, Adam Borowski wrote:
> On Tue, Apr 07, 2020 at 06:22:19PM +0800, Chao Yu wrote:
>> I figured out two patches to fix segfault issues, could you please have
>> a try:
>>
>>  fsck.f2fs: fix to check validation of i_xattr_nid
>>  fsck.f2fs: fix to check validation of block address
>>
>> In addition, I found that fsck main flow failed because it can not load root
>> inode based on wrong block address in nat, so I wrote another patch to enable
>> fsck to lookup root inode by traversing all nodes in f2fs main area, and 
>> relink
>> nat to root inode correctly.
>>
>>  fsck.f2fs: lookup and relink root inode
> 
> I still get a segfault:

Oops..

> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x5556 in print_inode_info (sbi=0x55584ca0 , 
> node=0x5558f170, name=) at mount.c:240
> 240   block_t blkaddr = le32_to_cpu(inode->i_addr[i + ofs]);
> (gdb) bt
> #0  0x5556 in print_inode_info (sbi=0x55584ca0 , 
> node=0x5558f170, name=) at mount.c:240
> #1  0x55564c4e in print_node_info (sbi=, 
> node_block=, verbose=) at mount.c:278
> #2  0x5556317f in dump_node (sbi=sbi@entry=0x55584ca0 , 
> nid=nid@entry=2861, force=force@entry=1) at dump.c:511
> #3  0x55561060 in fsck_verify (sbi=0x55584ca0 ) at 
> fsck.c:3259
> #4  0x799a in do_fsck (sbi=0x55584ca0 ) at main.c:698
> #5  main (argc=, argv=) at main.c:864

Fixed with

[PATCH] fsck.f2fs: fix to avoid overflow during print_inode_info()

Thanks,

> 
>> With this patch, image can be fixed and mounted later, although, most of 
>> files
>> were deleted due to seriously damaged f2fs metadata
> 
> Yeah, I've later tested the hardware -- writes to it are borked, so no
> complaint against the filesystem failing.  I got backups. :)
> 
>> The patches were made on top of dev-test branch of Jaegeuk's tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test
> 
>> #0  0x93ec in memcpy (__len=18446744073323892736, 
>> __src=0x5560760c, __dest=0x7fffe000) at 
>> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
>>>
>>> At a glance, immediate reason of this issue is we didn't check 
>>> inode.i_namelen's
>>> validation.
>>>
>> #1  convert_encrypted_name (name=name@entry=0x5560760c " ", 
>> len=-385658880, new=new@entry=0x7fffe000 " ", enc_name=> out>) at fsck.c:1132
>> #2  0x55562286 in print_inode_info (sbi=0x5557db20 , 
>> node=0x556075b0, name=1) at mount.c:183
>> #3  0x55562a46 in print_node_info (sbi=, 
>> node_block=, verbose=) at mount.c:277
>> #4  0x55560d3f in dump_node (sbi=sbi@entry=0x5557db20 
>> , nid=nid@entry=24274, force=force@entry=1) at dump.c:520
>> #5  0xe94c in fsck_verify (sbi=0x5557db20 ) at 
>> fsck.c:2568
>> #6  0x699b in do_fsck (sbi=0x5557db20 ) at 
>> main.c:569
> 
> 
> Meow!
> 

Bug#956597: I even stared at the units file for a half an hour

[Adrian Mariano]

> Anyway in conclusion yes you are right. I'm just documenting here "how I
> ended up thinking it was a bug." So no fixing needed... (I just hope
> this doesn't one day cause some million dollar accident.)

In scientific and engineering applications I think you're either going
to want absolute temperature in kelvin or temperature difference.  

> 
> Yes, now reading the man page we see the reasoning. OK.
> P.S., it says
> 
>   You have: tempC(-275)
>   ^
>   Argument of function outside domain
>   ^
> 
> well that second "^" needs to be removed.

Fixed this.

Bug#956743: RM: docker-swarm -- ROM; FTBFS; orphaned; superseded by docker swarmkit

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove docker-swarm from archive. It currently FTBFS and
orphaned.

And this is the legacy version of docker swarm. Users should use the
swarmkit which is built-in docker.io package.

Thanks

Bug#956742: RM: skydns -- ROM; FTBFS; orphaned

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove skydns from archive. It currently FTBFS and orphaned.
And there's no reverse build-depends.

Thanks

Bug#956741: RM: golang-github-aanand-compose-file -- ROM; FTBFS; orphaned

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove golang-github-aanand-compose-file from archive. It
currently FTBFS, and no longer used by any other packages.

Thanks

Bug#948576: Update - tested with 5.5.4

[Ben Hutchings]

On Tue, 2020-02-18 at 23:45 +0100, Josua Mayer wrote:
> Hi everybody,
> 
> I have rebased my patch on 5.5.4-1~exp1 from the packaging master branch.
> While at it I have also cleaned it up removing any options that were
> implicitly selected, leaving only those that really need to be enabled
> manually.
> 
> Boot tested, everything that worked before still does, namely the
> standalone ethernet port, USB, microSD and eMMC.
> 
> Please consider enabling these config options - The device-tree for the
> Honeycomb Workstation has been merged with 5.6-rc1 and it would be great
> to have Debian work as pieces start landing upstream.

I've applied these changes with some minor fix-ups:

- CONFIG_FSL_GUTS is automatic, so don't specify it
- COFNIG_DPAA2_CONSOLE was not given a value; make it modular

I also noticed that the qoriq-cpufreq driver won't automatically get
loaded when it's built as a module.  This can probably be fixed by
adding the line:

MODULE_DEVICE_TABLE(of, node_matches);

but I'll leave it to you to test that and send a patch upstream. :-)

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education.
  - Albert Einstein



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

Bug#898446: Please reconsider enabling the user namespaces by default

[Ben Hutchings]

On Mon, 2020-03-30 at 10:56 +0100, Simon McVittie wrote:
> On Fri, 11 May 2018 at 20:44:50 +0200, Laurent Bigonville wrote:
> > Firefox (and probably other applications) are using user namespaces these
> > days to enhance the security.
> > 
> > Debian is disabling these since 2013, the original patch states it's a
> > short term solution, but we are here 5 years later and they are still
> > disabled.
> > 
> > Apparently debian (and ubuntu) and arch are the only distributions
> > disabling the user namespaces.
> 
> A cross-distro status update:
> 
> - Debian still disables user namespaces by default with our
>   /proc/sys/kernel/unprivileged_userns_clone patch.
> 
> - Ubuntu now enables user namespaces by default. I think they still apply
>   the /proc/sys/kernel/unprivileged_userns_clone patch, but with the
>   default flipped?
> 
> - Arch Linux now enables user namespaces in their default kernel. There
>   is a non-default kernel, "linux-hardened", which applies the same patch
>   as Debian.
> 
> - Apparently RHEL 7 also disables user namespaces, although instead of
>   patching in a new sysctl, they set /proc/sys/user/max_user_namespaces
>   to 0 (which is an upstream thing since Linux 4.9).

And CentOS 8 appears to enable user namespaces by default.  So at this
point I think we probably need to follow suit, if only because users
and developers will expect it to be enabled.

> On Sun, 13 May 2018 at 22:57:56 +0200, Moritz Mühlenhoff wrote:
> > Ben Hutchings wrote:
> > > And this still mitigates a significant fraction of the security issues
> > > found in the kernel.
> > 
> > A quite significant fraction; on average this neutralises a root privilege
> > escalation every month or so. This is really not something that we should
> > re-enable any time soon.
> 
> Is this still the case, or has the status of user namespaces settled down?

I certinaly have the impression that things have settled down.  I'd
need to spend some time reviewing recent security issues, to be sure of
that.

> bubblewrap works around the restriction by being setuid root (and
> imposing restrictions in user-space that are intended to be more
> restrictive than those imposed by upstream kernels), but this makes
> bubblewrap bugs into potential root privilege escalations, so I would love
> to see bubblewrap no longer need to be setuid (like in Ubuntu).
[...]
> In
> Firefox, if I understand correctly, the fallback path is to not sandbox
> in this way at all; in Chrome/Chromium, there is a setuid fallback
> (which is enabled by the Debian chromium package), but it does not
> receive new upstream development, and it seems to be ambiguous whether
> its use is discouraged.
[...]

I think you've made a good case that user namespaces are likely to be a
net positive for security on Debian desktop systems.

This might not be true yet for servers that aren't container hosts.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education.
  - Albert Einstein




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

Bug#792580: Chromium calls home , confirmed for

[Erich Minderlein]

Hi
I can confirm for chromium 80.0.3987.149-1~deb10u1
calling the fastlycloud in usa via IPv4

I blocked "151.101.0.0/16" in my router , 
https://api.fastly.com/public-ip-list

which also terminated gockel.com

--
mit freundlichen Grüßen
with the beste regards

cordialement

Erich |\/|inderlei|\|
--

Bug#956597: I even stared at the units file for a half an hour

[積丹尼 Dan Jacobson]

OK, here is how I missed all the warnings.

Sensing something was wrong, my eyeballs did the equivalent of

$ units -U|xargs grep -A 2 -m 3 degC
xunit_mo 1.00209952e-13 m # degC.  It was intended to be exactly
  # 1e-13 m, but was later found to be
  # slightly off.  Current usage is with
--
degCK

# Fahrenheit defined his temperature scale by setting 0 to the coldest
--
degfahrenheit   5|9 degC
degF5|9 degC


My brain thought: "That first match is some gobbledygook. Ah. The second
match sounds familiar. And that 5|9 stuff sounds like something I
learned in school. So no bug in the units file."

And then I asked Google, and I guarantee you, no matter how you ask
Google, Google knows you want the homeowner's answer, not the chemical
engineer answer.

Anyway in conclusion yes you are right. I'm just documenting here "how I
ended up thinking it was a bug." So no fixing needed... (I just hope
this doesn't one day cause some million dollar accident.)

Yes, now reading the man page we see the reasoning. OK.
P.S., it says

  You have: tempC(-275)
  ^
  Argument of function outside domain
  ^

well that second "^" needs to be removed.

Bug#933302: RTL8723DE not working

[Ben Hutchings]

On Sun, 2020-04-12 at 15:38 -0600, Jesse Rhodes wrote:
[...]
> - Ubuntu's 5.4 kernel *does* have support, but it's via the RTW88
> driver that should be unrelated aiui because the 8723DE nic is 802.11n
> and RTW88 is specifically 802.11ac, and yet:
>
> jesse@bivouac:~/temp/ubuntu$ grep -i rtw88 boot/config-5.4.0-21-generic
> CONFIG_RTW88=m
> CONFIG_RTW88_CORE=m
> CONFIG_RTW88_PCI=m
> CONFIG_RTW88_8822BE=y
> CONFIG_RTW88_8822CE=y
> CONFIG_RTW88_8723DE=y 
[...]

I'm afraid that option doesn't exist in the upstream Linux version of
rtw88 (not even in 5.7-rc1).  Until it is added, we can't enable it in
Debian.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education.
  - Albert Einstein




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

Bug#955668: libgaminggear: FTBFS: pango-coverage.h:28:10: fatal error: hb.h: No such file or directory

[Laurent Bigonville]

reassign 955668 src:libgaminggear 0.15.1-9
tag 955668 + ftbfs patch
thanks

On Sat, 11 Apr 2020 18:30:19 +0200 Pierre-Elliott =?utf-8?B?QsOpY3Vl?= 
 wrote:


> Le vendredi 03 avril 2020 à 21:37:34+0200, Lucas Nussbaum a écrit :
> > [snip]
>
> libpango1.0-dev should depend on libharfbuzz-dev, but it doesn't. This
> bug seems to be in src:pango1.0, and therefore I reassign it.
>
> Dear pango1.0 maintainers, please fix the dependencies of
> libpango1.0-dev.
>

Well actually no, libpango1.0-dev already depends on libharfbuzz-dev

The problem seems to be that libgaminggear build-system does not rely on 
the information coming from pkg-config (it doesn't use the variables 
starting with PKG_) and instead guessing the path for the include 
directory itself.


My knowledge of CMake is really low, but the attached patch seems to fix 
the FTBFS


Kind regards,

Laurent Bigonville

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -76,6 +76,7 @@ INCLUDE_DIRECTORIES(
   ${GTK_INCLUDE_DIRS}
   ${M_INCLUDE_DIR}
   ${NOTIFY_INCLUDE_DIRS}
+  ${PKG_PANGO_INCLUDE_DIRS}
 )
 
 ADD_SUBDIRECTORY(configuration)

Bug#956740: Incomplete contextual menu in dash for Gufw : no "Add to Favorites" nor "Show Details"

[antistress]

Package: gufw
Version: 20.04.1-1

Hi,

When I launch Gufw on my GNOME system, Gufw starts and its icon is 
displayed in the dash, which is correct.


But then when I right click on its icon in the dash, instead of having 
the expected contextual menu which should display "Add to Favorites" 
(see 
https://help.gnome.org/users/gnome-help/stable/shell-apps-favorites.html.en) 
and "Show Details" entries, I get a very incomplete contextual menu 
without said entries.


See screenshot here of my french system :
https://pix.toile-libre.org/upload/original/1586908358.png
- On the left side : Gufw contextual menu
- on the right side, for comparison : Gedit contextual menu with 
expected entries.


Note that, as a workaround, Gufw can still be added to favorites from 
the grid either from contextual menu or by drag'n dropping the icon onto 
the dash.


Thanks

--

I am using Debian GNU/Linux Testing with GNOME-Wayland
Linux HAL 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux

libc6 2.30-4
mutter 3.34.4-1

gnome-shell 3.34.4-1

Bug#956736: python3-pbr: Uninstallable because of broken alternative

[Sandro Tosi]

On Tue, 14 Apr 2020 19:05:25 -0400 Sandro Tosi  wrote:
> > Updating python3-pbr (or installing it) fails with:
> >
> > update-alternatives: error: alternative path /usr/bin/python3-pbr doesn't
> > exist
> >
> > I suppose it's a left over of the alternative configuration when there was
> > Python 2 version. Now the Python 3 package directly provides /usr/bin/pbr.
>
> this is my fault, i'll take a look

I see zigo already fixed it in experimental with
https://salsa.debian.org/openstack-team/libs/python-pbr/-/commit/59c12ab553f08494e89642ecd368c6777df64057
-- wanna upload that package to sid, Thomas?

Bug#956736: python3-pbr: Uninstallable because of broken alternative

[Sandro Tosi]

> Updating python3-pbr (or installing it) fails with:
>
> update-alternatives: error: alternative path /usr/bin/python3-pbr doesn't
> exist
>
> I suppose it's a left over of the alternative configuration when there was
> Python 2 version. Now the Python 3 package directly provides /usr/bin/pbr.

this is my fault, i'll take a look

Bug#945875: openmw: Crash when saving

[Manuel A. Fernandez Montecelo]

2020-03-27 09:29 Alberto Luaces:

On 27/3/20 8:26, Bret Curtis wrote:

The best way forward in resolving this bug is to get OpenSceneGraph
package bumped to 3.6.5 right away. This requires the help of Alberto
Fernández, it's package maintainer.
https://tracker.debian.org/pkg/openscenegraph


Him, OSG 3.6.5 is ready
(https://salsa.debian.org/openscenegraph-team/openscenegraph-3.2/-/blob/master/debian/changelog),
I'm just waiting for Manuel to upload it.


Yep, sorry for the delay, I had told Alberto that I would be available
in late March, but...

Anyway, uploading to experimental now, so if everything goes well
Alberto can move it to unstable in the next days.


Cheers!
--
Manuel A. Fernandez Montecelo 

Bug#956553:

[jnqnfe]

apparently fixed in upstream master now, just needs packaging :)

Bug#956739: util-linux: PID persistent namespace broken

[Michael Braun]

Package: util-linux
Version: 2.33.1-0.1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I tried using unshare and nsenter with the pid (and mount) persistent 
namespaces.
So I created new namespaces using unshare and tried to enter them using nsenter.

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

Providing nsenter with the same persistent PID namespace file did not result in 
entering the same PID namespace.

console #1

 ~ # mount --make-private /
 ~ # touch /tmp/test-{pid,mnt}
 ~ # unshare --pid=/tmp/test-pid --mount=/tmp/test-mnt --fork --mount-proc
 ~ # ps faxu
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root 1  1.0  0.0   9652  4876 pts/7S23:22   0:00 -bash
root 8  0.0  0.0  12156  3144 pts/7R+   23:22   0:00 ps faxu
 ~ # mount
[all host mounts repeated here]
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
 ~ #

   * What was the outcome of this action?

console #2 (with console #1 still open)

 ~ # nsenter --mount=/tmp/test-mnt --pid=/tmp/test-pid
 / # ps faxu
Error, do this: mount -t proc proc /proc
 / # mount
  mount: failed to read mtab: Datei oder Verzeichnis nicht gefunden

console #3 (with console #1 + #2 still open)

~ # lsns --output-all -u
NS TYPE   PATH   NPROCS   PID  PPID COMMAND 
   UID USER 
NETNSID NSFS
4026531835 cgroup /proc/1/ns/cgroup 420 1 0 /sbin/init noibrs 
noibpb nopti nospectre_v2 nospec_store_bypass_disable no_stf_barrier   0 root   
  
4026531836 pid/proc/1/ns/pid419 1 0 /sbin/init noibrs 
noibpb nopti nospectre_v2 nospec_store_bypass_disable no_stf_barrier   0 root   
  /tmp/test-pid
4026531837 user   /proc/1/ns/user   420 1 0 /sbin/init noibrs 
noibpb nopti nospectre_v2 nospec_store_bypass_disable no_stf_barrier   0 root   
  
4026531838 uts/proc/1/ns/uts420 1 0 /sbin/init noibrs 
noibpb nopti nospectre_v2 nospec_store_bypass_disable no_stf_barrier   0 root   
  
4026531839 ipc/proc/1/ns/ipc420 1 0 /sbin/init noibrs 
noibpb nopti nospectre_v2 nospec_store_bypass_disable no_stf_barrier   0 root   
  
4026531840 mnt/proc/1/ns/mnt395 1 0 /sbin/init noibrs 
noibpb nopti nospectre_v2 nospec_store_bypass_disable no_stf_barrier   0 root   
  
4026531860 mnt/proc/50/ns/mnt 150 2 kdevtmpfs   
 0 root 

4026532000 net/proc/1/ns/net420 1 0 /sbin/init noibrs 
noibpb nopti nospectre_v2 nospec_store_bypass_disable no_stf_barrier   0 root   
   unassigned 
4026532199 mnt/proc/436/ns/mnt1   436 1 
/lib/systemd/systemd-udevd  
 0 root 
4026532209 mnt/proc/718/ns/mnt1   718 1 /usr/sbin/irqbalance 
--foreground0 root  
   
4026532361 mnt/proc/17407/ns/mnt  4 17407 15596 unshare 
--pid=/tmp/test-pid --mount=/tmp/test-mnt --fork --mount-proc   
 0 root /tmp/test-mnt
4026532362 pid/proc/17409/ns/pid  1 17409 17407 -bash   
 0 root 


~ # ps faxu
[excerpt]
root 17407  0.0  0.0   6772   756 pts/7S23:22   0:00  |   
\_ unshare --pid=/tmp/test-pid --mount=/tmp/test-mnt --fork --mount-proc
root 17409  0.0  0.0   9652  4876 pts/7S+   23:22   0:00  | 
  \_ -bash

   * What outcome did you expect instead?

I expected nsenter to join the pid namespace given.
I expected /tmp/test-pid to not shared PID namespace with /init but instead 
with PID 17409.

This is probably due to the PID namespace not affecting the unshare main 
process after the unshare syscall, but only its child processes.
Therefore bind_ns_files_from_child should probably call bind_ns_files not with 
the parent (unshare process) process id but its child process id.
To fix it, instead of ns/pid, ns/pid_for_children could be used. Though, 
ns/pid_for_children is empty before the first child has been created, so 
unshare.c needs some more work than just replacing ns/pid with 
ns/pid_for_children.

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

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

Versions of 

Bug#956738: Review the Debian patches when the next release come out

[Petter Reinholdtsen]

Package: libtheora
Version: 1.1.1+dfsg.1-15

I poked the upstream developers on #xiph, and got the following review
of the Debian patches currently in use:

 pere: 0001 is obsolete, I'm pretty sure (autogen.sh just calls
   autoreconf -isf now). 
 0002 we can't take.
 TD-Linux: ok.  if that is the best way to spend the time, I'll do
   it.
 0005 looks to have been addressed by fbb275803696?
 Similarly 0006 looks to have been addressed by 7288b539c52e.
 derf: why do the theora tarball need to contain the RFCs?
 0003 got applied sometime before 2010. Can't tell exactly where
   because of the way the git import from subversion was done.
 pere: Oh, I guess I should have looked at the patch. I thought it
   was removing the actual documents from the repository.
 Yeah, I'll let others give opinions on whether they need to be in
   the tarball.
 derf: thank you very much for having a look.  I'll pass it on to
   the maintainer group.
 0004 looks like it was addressed in b07a1d2ddfe8.
 So I think 0002 is the only one outstanding.

Based on this, I believe we should have a closer look at the Debian
patches when a new version of libtheora is released.

-- 
Happy hacking
Petter Reinholdtsen

Bug#908155: Bug #908155 in developers-reference marked as pending

[Holger Levsen]

Hi Moritz,

On Thu, Apr 09, 2020 at 08:32:58AM +0200, Moritz Mühlenhoff wrote:
> The current version in unstable (11.0.10) again reads:
> | If it's an upstream problem, you have to forward it to the upstream author.
> | Forwarding a bug is not enough, you have to check at each release if the
> | bug has been fixed or not.

where exactly do you see this? I don't see it on 
https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#coordination-with-upstream-developers
nor in source/developer-duties.rst in the source git repo.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of 
their very eyes...


signature.asc
Description: PGP signature

Bug#923940: libtheoraenc.so: undefined symbols: needs -ltheoradec

[Petter Reinholdtsen]

Control: tags -1 +patch

I suspect this patch will solve the problem:

Index: libtheora/lib/Makefile.am
===
--- libtheora.orig/lib/Makefile.am  2020-04-14 23:43:02.0 +0200
+++ libtheora/lib/Makefile.am   2020-04-14 23:46:58.799385927 +0200
@@ -79,6 +79,7 @@
apiwrapper.c \
fragment.c \
idct.c \
+   info.c \
internal.c \
state.c \
quant.c \

-- 
Happy hacking
Petter Reinholdtsen

Bug#922732: [Pkg-openssl-devel] Bug#922732: openssl: ~/.rnd (RANDFILE) ignored

[Thorsten Glaser]

Sebastian Andrzej Siewior dixit:

>On 2019-02-19 23:10:40 [+], Thorsten Glaser wrote:
>> When I do “openssl rand 4 | hd”, the file ~/.rnd is ignored
>> (judging from its tiestamp and md5sum, it’s not rewritten,
>> and probably not read either) despite me adding the line
>> 
>>  RANDFILE= $ENV::HOME/.rnd
>> 
>> to openssl.cnf as described in config(5).
>
>So what do we do here? The file, that is specified as RANDFILE here, was
>used more often in earlier releases. Currently it is seeded via
>getrandom() and the file is hardly used. Therefore it is mostly ignored.
>
>Can this be closed or do you expect something else?

I’d expect the content of the file to be mixed in at startup
and updated from the OpenSSL-internal pool, like in earlier
versions.

bye,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#956737: mbpoll: please backport to Debian 10 stable (buster)

[Martin]

Package: mbpoll
Version: 1.4.11+dfsg-1
Severity: wishlist

This is a tracking bug. I'll do the backport soon.

Bug#918727: [Pkg-openssl-devel] Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Sebastian Andrzej Siewior]

On 2019-01-08 20:17:42 [+], Simon McVittie wrote:
> It should probably at least have a Breaks on libssl1.0.2, to protect
> partial upgrades from stretch. Some release notes for users of
> third-party software might also be useful. I realise it probably isn't
> feasible to keep openssl.cnf compatible with all past and future versions.

I think that we are a little late for that.

> It would perhaps be a good idea for future OpenSSL branches to
> use a configuration file that's tied to the major version in their SONAME,
> or otherwise parallel-installable? (openssl1.1.0.cnf, etc.)

I don't remember having a problem in Stretch where we had two libs but
one file. However there the environment variable OPENSSL_CONF which can
be set to a specific configuration file. Wouldn't that work if you
bundle a specific library?

…
> Workaround: use OPENSSL_CONF=/dev/null when running software that depends
> on an older libssl.

Right.

> For context, libssl_conf.so never actually existed on disk, and
> isn't really meant to. In OpenSSL's approach to configuration,
> /etc/ssl/openssl.cnf configuration parameters cause loading of
> native-code modules, which can either be built-in to libcrypto or
> libssl, or real files on disk to be dlopen()ed (like the way Python's
> sys module is built-in to the interpreter, but its readline module is
> external). libssl_conf.so in the default library search path (!) is one
> of several names OpenSSL would try for the ssl_conf module - I think
> the reason it appears in the error message is that it's the last one to
> be tried.
> 
> Since 1.1.0 (commit 59b1696c), there is a ssl_conf module built-in to
> libssl. It moved into libcrypto in 1.1.1 (commit d8f031e8).
> 
> In Debian, since 1.1.1 (August 2018, if we don't count experimental),
> /etc/ssl/openssl.cnf has made use of the ssl_conf mechanism to enforce
> TLS1.2 as the minimum protocol, and 112-bit security (level 2) as
> the minimum security level. This file is only installed if the openssl
> package (containing the openssl command-line tool) is installed. However,
> ca-certificates depends on openssl, so in practice basically all users
> will have it.

exactly.

> This affects libssl1.0.0 in the Steam Runtime installed by the non-free
> steam package, and possibly other third-party software bundles.
> ()

It appears to be fixed in Steam. Do you see the need any kind of an
action here?

> smcv

Sebastian

Bug#956535: buster-pu: package php-horde-data/2.1.4-5+deb10u1

[Roberto C . Sánchez]

On Tue, Apr 14, 2020 at 10:04:00PM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 - moreinfo
> 
> Hi Adam,
> 
> On Sun, Apr 12, 2020 at 10:05:55PM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Sun, 2020-04-12 at 09:23 -0400, Roberto C. Sanchez wrote:
> > > Please find attached a proposed debdiff for php-horde-data.  The
> > > change fixes CVE-2020-8518, which the security team has classified as
> > > , deeming it a minor issue which can be fixed via a point
> > > release.
> > 
> > The Security Tracker indicates that this issue affects the package in
> > unstable and is not yet fixed there; is that correct?
> 
> This is correct, the issue has not been fixed in unstable "yet". The
> horde ecosystem is currently unmaintained, and previous maintainer
> indicated to ask actually for removal if nobody steps up. See #942282
> for context.
> 
> That said, it's possible to either wait for a fix in unstable or the
> removal of the php-horde* packages first before accepting the upload
> for a buster point release (same for the other updates proposed by
> Roberto).
> 
> Does this make sense?
> 
Hi Salvatore,

I've communicated with Mathieu Parent (the php-horde-* maintainer)
regarding his intentions for unstable uploads of these three packages.
He has asked that I go ahead and perform the uploads.  However, if you
think that a removal request is forthcoming in the very near future, I
will wait and not make those uploads.

My intent was to have them done in the next 24 hours.  Please advise if
I should proceed or if I should wait for removal.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#956311: libsqlite3-dev: length(BLOB) should not convert to unicode

[GCS]

On Tue, Apr 14, 2020 at 4:16 PM Troy  wrote:
> The data in question was binary data, not unicode. It just happened to
> contain some valid UTF-8 sequences. I am communicating with the db
> through ODBC (64-bit), so I will have to look and see what is happening
> exactly. I will have to add some workaround to make sure that the data
> is added as a BLOB.
 Feel free to consult with the SQLite developers on the provided
forum. There are several helpful people out there.

Laszlo/GCS

Bug#956625: texlive-luatex fails to install: running `luatex -ini -jobname=optex -progname=optex optex.ini

[Norbert Preining]

On Tue, 14 Apr 2020, Hilmar Preuße wrote:
> commit. Do I have to upload -extra & -lang too? Else the tag
> all_2020.20200329-3 would not be correct.

THe tags are somehow arbitrary, but in this case
git tag debian/base_2020.20200329-3
that is what I am always doing!

Thanks!

Norbert

--
PREINING Norbert  https://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#922732: [Pkg-openssl-devel] Bug#922732: openssl: ~/.rnd (RANDFILE) ignored

[Sebastian Andrzej Siewior]

On 2019-02-19 23:10:40 [+], Thorsten Glaser wrote:
> When I do “openssl rand 4 | hd”, the file ~/.rnd is ignored
> (judging from its tiestamp and md5sum, it’s not rewritten,
> and probably not read either) despite me adding the line
> 
>   RANDFILE= $ENV::HOME/.rnd
> 
> to openssl.cnf as described in config(5).

So what do we do here? The file, that is specified as RANDFILE here, was
used more often in earlier releases. Currently it is seeded via
getrandom() and the file is hardly used. Therefore it is mostly ignored.

Can this be closed or do you expect something else?

Sebastian

Bug#956736: python3-pbr: Uninstallable because of broken alternative

[Yannick Roehlly]

Package: python3-pbr
Version: 5.4.3-3
Severity: grave
Justification: renders package unusable

Hi,

Updating python3-pbr (or installing it) fails with:

update-alternatives: error: alternative path /usr/bin/python3-pbr doesn't 
exist

I suppose it's a left over of the alternative configuration when there was
Python 2 version. Now the Python 3 package directly provides /usr/bin/pbr.

Regards,

Yannick

-- 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.6.4 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pbr depends on:
ii  python33.8.2-3
ii  python3-pkg-resources  44.0.0-1
ii  python3-setuptools 44.0.0-1
ii  python3-six1.14.0-3

python3-pbr recommends no packages.

python3-pbr suggests no packages.

-- no debconf information

Bug#956735: qv4l2: No sound when capture a video VHS.

[Jean Pierre Hoareau]

Package: qv4l2
Version: 1.16.3-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When i do a video capture which qv4l2 I do not the sound of the video. The
device is EM2860/SAA711x, driver em28xx. Same problem when using ffmpeg and
mencoder. The sound system is "pulseaudio" Using all other video capture the
problem is the same.Using jessy, stretch, and bullseye i get the same fail.
Here under somes messages from dmesg and others:

dmesg | tail -30
em28xx 2-10.1.4:1.0: Remote control support is not available for this card.
[   11.774061] em28xx: Registered (Em28xx Input Extension) extension
[   11.946320] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control:
Rx/Tx
[   11.946349] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[   15.710318] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control:
Rx/Tx
[   39.739228] do_trap: 21 callbacks suppressed
[   39.739230] traps: light-locker[2619] trap int3 ip:7fa936d84c75
sp:7fff3d59c5d0 error:0 in libglib-2.0.so.0.5800.3[7fa936d4c000+7e000]
[   41.494844] snd_hda_intel :00:1b.0: IRQ timing workaround is activated
for card #1. Suggest a bigger bdl_pos_adj.
[  113.152706] usb 4-3.2: new SuperSpeed Gen 1 USB device number 5 using
xhci_hcd
[  113.173134] usb 4-3.2: New USB device found, idVendor=2537, idProduct=1068,
bcdDevice= 1.00
[  113.173135] usb 4-3.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[  113.173136] usb 4-3.2: Product: NS106X
[  113.173136] usb 4-3.2: Manufacturer: Norelsys
[  113.173137] usb 4-3.2: SerialNumber: 0123456789ABCDE
[  113.175201] usb 4-3.2: UAS is blacklisted for this device, using usb-storage
instead
[  113.175202] usb-storage 4-3.2:1.0: USB Mass Storage device detected
[  113.175285] usb-storage 4-3.2:1.0: Quirks match for vid 2537 pid 1068:
80
[  113.175319] scsi host10: usb-storage 4-3.2:1.0
[  115.697991] scsi 10:0:0:0: Direct-Access ATA  SanDisk SDSSDP12 0
PQ: 0 ANSI: 6
[  115.698147] sd 10:0:0:0: Attached scsi generic sg11 type 0
[  115.698324] sd 10:0:0:0: [sdk] 246162672 512-byte logical blocks: (126
GB/117 GiB)
[  115.698518] sd 10:0:0:0: [sdk] Write Protect is off
[  115.698519] sd 10:0:0:0: [sdk] Mode Sense: 43 00 00 00
[  115.698718] sd 10:0:0:0: [sdk] Write cache: disabled, read cache: enabled,
doesn't support DPO or FUA
[  115.716632]  sdk: sdk1 sdk2
[  115.717508] sd 10:0:0:0: [sdk] Attached SCSI disk
[  125.965208] EXT4-fs (sdk1): recovery complete
[  125.965489] EXT4-fs (sdk1): mounted filesystem with ordered data mode. Opts:
(null)
[  136.782553] usb 4-3.2: USB disconnect, device number 5
[  791.949656] snd_hda_intel :01:00.1: IRQ timing workaround is activated
for card #2. Suggest a bigger bdl_pos_adj

root@buster:~# aplay -l
 Liste des Périphériques Matériels PLAYBACK 
carte 0: HDMI [HDA Intel HDMI], périphérique 3: HDMI 0 [HDMI 0]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 0: HDMI [HDA Intel HDMI], périphérique 7: HDMI 1 [HDMI 1]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 0: HDMI [HDA Intel HDMI], périphérique 8: HDMI 2 [HDMI 2]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 0: HDMI [HDA Intel HDMI], périphérique 9: HDMI 3 [HDMI 3]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 0: HDMI [HDA Intel HDMI], périphérique 10: HDMI 4 [HDMI 4]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: PCH [HDA Intel PCH], périphérique 0: ALC1150 Analog [ALC1150 Analog]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: PCH [HDA Intel PCH], périphérique 1: ALC1150 Digital [ALC1150 Digital]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 2: NVidia [HDA NVidia], périphérique 3: HDMI 0 [HDMI 0]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 2: NVidia [HDA NVidia], périphérique 7: HDMI 1 [HDMI 1]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 2: NVidia [HDA NVidia], périphérique 8: HDMI 2 [HDMI 2]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 2: NVidia [HDA NVidia], périphérique 9: HDMI 3 [HDMI 3]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0

root@buster:~# cat /proc/asound/cards
 0 [HDMI   ]: HDA-Intel - HDA Intel HDMI
  HDA Intel HDMI at 0xf7b34000 irq 29
 1 [PCH]: HDA-Intel - HDA Intel PCH
  HDA Intel PCH at 0xf7b3 irq 30
 2 [NVidia ]: HDA-Intel - HDA NVidia
  HDA NVidia at 0xf708 irq 17
 3 [U0xeb1a0x2861  ]: USB-Audio - USB Device 0xeb1a:0x2861
  USB Device 0xeb1a:0x2861 at usb-:00:14.0-10.1.4, high
speed

root@buster:~# arecord -l
 Liste des Périphériques Matériels CAPTURE 
carte 1: PCH [HDA Intel PCH], périphérique 0: ALC1150 Analog [ALC1150 Analog]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: PCH [HDA Intel PCH], périphérique 2: ALC1150 Alt 

Bug#956703: linux-image-5.5: 5.5 kernel seems to break pulseaudio HDMI detection

[Noah Meyerhans]

On Tue, Apr 14, 2020 at 02:06:30PM +0100, Simon John wrote:
> Booting into 5.5 on Sid gives me no audio out via HDMI.

I can confirm similar HDMI audio breakage with 5.5.13 on a Thinkpad X1
Carbon (gen2) with the following audio devices:

00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)
Subsystem: Lenovo Haswell-ULT HD Audio Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)
Subsystem: Lenovo 8 Series HD Audio Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

Bug#956734: gnucobol FTCBFS: lots of AC_RUN_IFELSE

[Helmut Grohne]

Source: gnucobol
Version: 2.2-5
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gnucobol fails to cross build from source, because it uses AC_RUN_IFELSE
a lot. Running a compiled program is what doesn't work during cross
compilation, so the use of this macro needs to be minimized and the
remaining uses need workarounds. In many occasions (checking macro
existence, computing sizeof something, calculating integer values), one
doesn't actually need AC_RUN_IFELSE (AC_COMPILE_IFELSE, AC_CHECK_SIZEOF,
and AC_COMPUTE_INT may suffice). The attached patch replaced a large
chunk of AC_RUN_IFELSE with alternatives that better support cross
compilation. It doesn't make gnucobol cross buildable just yet. Please
consider applying it and close this bug when doing so. Even partially
applying the patch helps a little. You'll also notice that it poses a
noticeable reduction in complexity.

Helmut
--- gnucobol-2.2.orig/configure.ac
+++ gnucobol-2.2/configure.ac
@@ -248,12 +248,11 @@
 # Checks for UTC offset (init)
 COB_HAS_UTC_OFFSET="no"
 
-AC_RUN_IFELSE([AC_LANG_PROGRAM([[]], [[
-	#ifdef _BSD_SOURCE
-	return 0;
-	#else
-	return 1;
-	#endif]])],
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[
+	#ifndef _BSD_SOURCE
+	#error _BSD_SOURCE is not defined
+	#endif
+	return 0;]])],
 	[COB_HAS_UTC_OFFSET="yes"],
 	[],
 	[])
@@ -286,62 +285,52 @@
 COB_USES_XLC_ONLY=no
 COB_USES_WATCOMC_ONLY=no
 
-AC_RUN_IFELSE([AC_LANG_PROGRAM([[]], [[
-	#ifdef __GNUC__
-	return 0;
-	#else
-	return 1;
-	#endif]])],
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[
+	#ifndef __GNUC__
+	#error __GNUC__ is not defined
+	#endif
+	return 0;]])],
 	[COB_USES_GCC=yes],
 	[],
 	[])
 
-AC_RUN_IFELSE([AC_LANG_PROGRAM([[]], [[
-	#if	defined(__GNUC__) && !defined(__INTEL_COMPILER)
-	return 0;
-	#else
-	return 1;
-	#endif]])],
-	[COB_USES_GCC_NO_ICC=yes],
-	[],
-	[])
-
-AC_RUN_IFELSE([AC_LANG_PROGRAM([[]], [[
-	#ifdef __INTEL_COMPILER
-	return 0;
-	#else
-	return 1;
-	#endif]])],
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[
+	#ifndef __INTEL_COMPILER
+	#error __INTEL_COMPILER not defined
+	#endif
+	return 0;]])],
 	[COB_USES_ICC_ONLY=yes],
 	[],
 	[])
 
-AC_RUN_IFELSE([AC_LANG_PROGRAM([[]], [[
-	#ifdef __clang__
-	return 0;
-	#else
-	return 1;
-	#endif]])],
+AS_IF([test "x$COB_USES_GCC" = xyes -a "x$COB_USES_ICC_ONLY" != xyes],[
+	COB_USES_GCC_NO_ICC=yes
+])
+
+
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[
+	#ifndef __clang__
+	#error __clang__ not defined
+	#endif
+	return 0;]])],
 	[COB_USES_CLANG_ONLY=yes],
 	[],
 	[])
 
-AC_RUN_IFELSE([AC_LANG_PROGRAM([[]], [[
-	#ifdef __xlc__
-	return 0;
-	#else
-	return 1;
-	#endif]])],
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[
+	#ifndef __xlc__
+	#error __xlc__ not defined
+	#endif
+	return 0;]])],
 	[COB_USES_XLC_ONLY=yes],
 	[],
 	[])
 
-AC_RUN_IFELSE([AC_LANG_PROGRAM([[]], [[
-	#ifdef __WATCOMC__
-	return 0;
-	#else
-	return 1;
-	#endif]])],
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[
+	#ifndef __WATCOMC__
+	#error __WATCOMC__ not defined
+	#endif
+	return 0;]])],
 	[COB_USES_WATCOMC_ONLY=yes],
 	[],
 	[])
@@ -501,23 +490,13 @@
 
 # Check just major/minor levels between header and library
 # get GMP version from header
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
-	#include 
-	#include 
-	int main (int argc, char **argv)
-	{
-		(void)argv;
-		if (argc > 1)
-			printf ("%d.%d\n", __GNU_MP_VERSION, __GNU_MP_VERSION_MINOR);
-		return 0;
-	}
-	]])],
-	[COB_GMP_HEADER=`./conftest$ac_exeext x`],
-	[AC_MSG_ERROR([Unable to extract GMP version information from gmp.h])],
-	[])
-if test "x$COB_GMP_HEADER" = "x"; then
+AC_COMPUTE_INT(COB_GMP_HEADER_MAJOR,__GNU_MP_VERSION,[#include ],[
 	AC_MSG_ERROR([Unable to extract GMP version information (header)])
-fi
+])
+AC_COMPUTE_INT(COB_GMP_HEADER_MINOR,__GNU_MP_VERSION_MINOR,[#include ],[
+	AC_MSG_ERROR([Unable to extract GMP version information (header)])
+])
+COB_GMP_HEADER="$COB_GMP_HEADER_MAJOR.$COB_GMP_HEADER_MINOR"
 
 MYOLDLIBS=$LIBS
 LIBS="$MYOLDLIBS -lgmp"
@@ -535,21 +514,25 @@
 	]])],
 	[COB_GMP_LIB=`./conftest$ac_exeext x`],
 	[AC_MSG_ERROR([Unable to extract GMP version information from gmp_version])],
-	[])
+	[COB_GMP_LIB=cross])
 if test "x$COB_GMP_LIB" = "x"; then
 	AC_MSG_ERROR([Unable to extract GMP version information (library)])
 fi
 
 AC_MSG_CHECKING([matching GMP version])
-COB_GMP_LIB_MAJOR=$(echo "$COB_GMP_LIB" | cut -d. -f1)
-COB_GMP_LIB_MINOR=$(echo "$COB_GMP_LIB" | cut -d. -f2)
+AS_IF([test "x$COB_GMP_LIB" != xcross],[
+	COB_GMP_LIB_MAJOR=$(echo "$COB_GMP_LIB" | cut -d. -f1)
+	COB_GMP_LIB_MINOR=$(echo "$COB_GMP_LIB" | cut -d. -f2)
 
-if test "$COB_GMP_HEADER" = "$COB_GMP_LIB_MAJOR.$COB_GMP_LIB_MINOR"; then
-	AC_MSG_RESULT([yes ($COB_GMP_HEADER)])
-else
-	AC_MSG_RESULT([no (header: $COB_GMP_HEADER / library: $COB_GMP_LIB)])
-	AC_MSG_ERROR([Unable to use GMP - Please check config.log])
-fi
+	if test "$COB_GMP_HEADER" = "$COB_GMP_LIB_MAJOR.$COB_GMP_LIB_MINOR"; then
+		AC_MSG_RESULT([yes ($COB_GMP_HEADER)])
+	else
+		AC_MSG_RESULT([no (header: 

Bug#956625: texlive-luatex fails to install: running `luatex -ini -jobname=optex -progname=optex optex.ini

[Hilmar Preuße]

Am 14.04.2020 um 21:17 teilte Sandro Tosi mit:

Hi Norbert,

> please release it to unstable ASAP: it is blocking the upload of
> sphinx 2.* to unstable (and consequently the update of numpy to 1.8)
> 
> Let me know if you need help with this.
> 
I just typed "dput ftp-eu texlive-base_2020.20200329-3_source.changes"
so the -3 will go into the archive. Now I'm wondering how to tag the git
commit. Do I have to upload -extra & -lang too? Else the tag
all_2020.20200329-3 would not be correct.

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



signature.asc
Description: OpenPGP digital signature

Bug#956535: buster-pu: package php-horde-data/2.1.4-5+deb10u1

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo

Hi Adam,

On Sun, Apr 12, 2020 at 10:05:55PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sun, 2020-04-12 at 09:23 -0400, Roberto C. Sanchez wrote:
> > Please find attached a proposed debdiff for php-horde-data.  The
> > change fixes CVE-2020-8518, which the security team has classified as
> > , deeming it a minor issue which can be fixed via a point
> > release.
> 
> The Security Tracker indicates that this issue affects the package in
> unstable and is not yet fixed there; is that correct?

This is correct, the issue has not been fixed in unstable "yet". The
horde ecosystem is currently unmaintained, and previous maintainer
indicated to ask actually for removal if nobody steps up. See #942282
for context.

That said, it's possible to either wait for a fix in unstable or the
removal of the php-horde* packages first before accepting the upload
for a buster point release (same for the other updates proposed by
Roberto).

Does this make sense?

Regards,
Salvatore

Bug#956733: kylin-display-switch: deprecated non-integer division in kylin_display_switch.py:183

[Roman Czyborra]

Package: kylin-display-switch
Version: 1.0.4-1
Severity: important

   * What led up to the situation?

i was trying to turn off my laptop screen and switch to an
external hdmi bigscreen and hence i installed the
kylin-display-switch and started it and received a python
deprecation warning when pressing [Super_Left]+[F7] to switch
entirely from xinerama splitscreen to the external hdmi bigscreen:

roman@zfs:~$ kds 
roman@zfs:~$ man kds

roman@zfs:~$ kylin_display_switch.py:151: DeprecationWarning:
an integer is required (got type float).  Implicit conversion
to integers using __int__ is deprecated, and may be removed in
a future version of Python.  self.move((desktop.width() -
self.width()) / 2, (desktop.height() - self.height()) *10 /
21) found monitors : ['LVDS-1', 'HDMI-1'] max display mode :
1366x768 , 1920x1080 best clone mode : 1360x768

   * What exactly did you do that was effective?

sudo vi -c 151s=/=//=g 
/usr/share/kylin-display-switch/kylin_display_switch.py
kds
[Super_Left]+[F7]

   * What was the outcome of this action?

remaining diagnostic gibberish but no more deprecation warning
and hence legal python formulae:

;1~found monitors : ['LVDS-1', 'HDMI-1']
max display mode : 1366x768 , 1920x1080
best clone mode : 1360x768 

   * What outcome did you expect instead?

this being solved centrally for all debianites and upstreamers

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

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

Versions of packages kylin-display-switch depends on:
ii  gir1.2-glib-2.0  1.64.1-1
ii  python3  3.8.2-3
ii  python3-pyqt55.14.2+dfsg-1+b1
ii  python3-xlib 0.27-1

kylin-display-switch recommends no packages.

kylin-display-switch suggests no packages.

-- no debconf information

Bug#945581: vmdb2: grub fails on an LV image

[Sebastian Bachmann]

Hi!

I found out that this helps to work around it:

  - grub: bios
tag: root
console: serial
image-dev: "{{ image }}"

In the documentation it says "device", but seems to be wrong. (Compare
https://vmdb2-manual.liw.fi/#step-grub, lateron image-dev is mentioned)

I could successfully install it on a LV.


hth!
Sebastian


On Wed, 27 Nov 2019 12:55:27 +0100 Josip Rodin  
wrote:
> Package: vmdb2
> Version: 0.13.2+git20190215-1
> 
> Hi,
> 
> I pre-created my LV using the same lvcreate syntax that doesn't work from
> within vmdb2 (see previous bug filed), and used with the invocation:
> 
> % sudo vmdb2 foo-bar-1.vmdb.yml --image /dev/vg0/foo-bar-1-root --verbose 
> --log=foo-bar-1.vmd.log
> 
> The boot loader step in foo-bar-1.vmdb.yml was the default one from the
> manual:
> 
>   - grub: bios
> tag: root
> console: serial

Bug#956731: RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: rober...@semistable.com


Dear mentors,

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

 * Package name: check
   Version : 0.14.0-0.1
   Upstream Author : Branden Archer
https://github.com/libcheck/check/blob/master/AUTHORS
 * URL : https://libcheck.github.io/check/
 * License : LGPL-2.1+
 * Vcs : None
   Section : devel

It builds those binary packages:

  check - unit test framework for C

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/check/check_0.14.0-0.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * New upstream version 0.14.0
   * d/{control,compat}: switch to debhelper v12
   * d/control:
 - bump std-version to 4.5.0 (no further changes)
 - drop dependency fulfilled since jessie
   * d/patches: add patch to correct misspelling
   * d/rules:
 - drop unneeded dh option '--buildsystem=autoconf --with autoreconf'
 - break configure lines
 - add 'dh_missing --fail-missing'
   * debian: cleanup unnecessary .dirs and .files items
   * d/tests: add simple autopkgtest

Best regards,
  Christian Göttsche

Bug#956625: texlive-luatex fails to install: running `luatex -ini -jobname=optex -progname=optex optex.ini

[Sandro Tosi]

Hello Norbert,

On Tue, 14 Apr 2020 07:31:08 +0900 Norbert Preining  wrote:
> tags 956625 + pending
> thanks
>
> > ! Font \_tenrm=ec-lmr10 not loadable: metric data not found or bad.
> > 
> > \_font
> > l.8 \_font
> > \_tenbf=ec-lmbx10  % boldface extended
> > ?
> > ! Emergency stop.
> > 
> > \_font
> > l.8 \_font
> > \_tenbf=ec-lmbx10  % boldface extended
> > !  ==> Fatal error occurred, no output PDF file produced!
> > Transcript written on optex.log.
>
> Fixed in git. Thanks for the report.

please release it to unstable ASAP: it is blocking the upload of
sphinx 2.* to unstable (and consequently the update of numpy to 1.8)

Let me know if you need help with this.

Regards,
Sandro

Bug#956732: gxr: Backends not packaged

[Jesse Pullinen]

Source: gxr
Version: 0.14.0-2
Severity: grave
Justification: renders package unusable

Backends could be packaged in separate packages with the openvr backend in
contrib somehow.



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

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

Bug#956730: RFS: libutempter/1.1.6-5 -- privileged helper for utmp/wtmp updates (development)

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libutempter
   Version : 1.1.6-5
   Upstream Author : Dmitry V. Levin 
 * URL :
http://git.altlinux.org/people/ldv/packages/?p=libutempter.git
 * License : LGPL-2.1
 * Vcs : https://salsa.debian.org/cgzones-guest/libutempter
   Section : libs

It builds those binary packages:

  libutempter-dev - privileged helper for utmp/wtmp updates (development)
  libutempter0 - privileged helper for utmp/wtmp updates (runtime)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libu/libutempter/libutempter_1.1.6-5.dsc

Changes since the last upload:

   * d/rules: fail on compiler warnings
   * d/control: bump to std version 4.5.0 (no further changes)
   * d/patches:
 - resolve/silence compiler warnings
 - cast to unsigned char before character handling function
 - log errors in setgid helper to syslog
   * d/upstream/signing-key.asc: re-export key without extra signatures

Best regards,
  Christian Göttsche

Bug#956728: openjdk-11: Please enablel buildwatch.sh on sh4

[John Paul Adrian Glaubitz]

Source: openjdk-11
Version: 11.0.7+9-1
Severity: normal
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh4

Hello!

I just noticed that sh4 is missing in the list of architectures for which
the buildwatch.sh script is enabled. This explains why the builds on sh4
sometimes time out.

Can you enable the buildwatch.sh script on openjdk-{11,13,14,15} to address
this issue?

This should do it:

--- debian/rules.orig   2020-03-26 08:33:35.0 +0100
+++ debian/rules2020-04-14 20:03:01.302882997 +0200
@@ -993,7 +993,7 @@
 
 stamps/build: stamps/configure
@echo '== $@ =='
-ifneq (,$(filter $(DEB_HOST_ARCH), alpha armel armhf ia64 m68k mips mipsel 
mips64 mips64el powerpc powerpcspe riscv64 s390x sparc sparc64))
+ifneq (,$(filter $(DEB_HOST_ARCH), alpha armel armhf ia64 m68k mips mipsel 
mips64 mips64el powerpc powerpcspe riscv64 s390x sh4 sparc sparc64))
sh -c 'sh debian/buildwatch.sh $(CURDIR)/$(builddir) &'
 endif
if $(EXTRA_BUILD_ENV) $(MAKE) -C $(builddir) $(build_target); then \

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig   2020-03-26 08:33:35.0 +0100
+++ debian/rules2020-04-14 20:03:01.302882997 +0200
@@ -993,7 +993,7 @@
 
 stamps/build: stamps/configure
@echo '== $@ =='
-ifneq (,$(filter $(DEB_HOST_ARCH), alpha armel armhf ia64 m68k mips mipsel 
mips64 mips64el powerpc powerpcspe riscv64 s390x sparc sparc64))
+ifneq (,$(filter $(DEB_HOST_ARCH), alpha armel armhf ia64 m68k mips mipsel 
mips64 mips64el powerpc powerpcspe riscv64 s390x sh4 sparc sparc64))
sh -c 'sh debian/buildwatch.sh $(CURDIR)/$(builddir) &'
 endif
if $(EXTRA_BUILD_ENV) $(MAKE) -C $(builddir) $(build_target); then \

Bug#956729: asciidoc-base: add xsltproc to Depends

[merkys]

Package: asciidoc-base

Hello,

asciidoc-base seems to depend on xsltproc:

andrius@amalas mkdepend $ a2x -d manpage -f manpage
../mkdepend-0.0~svn40/doc/mkcomdepend.txt --verbose
a2x: args: ['-d', 'manpage', '-f', 'manpage',
'../mkdepend-0.0~svn40/doc/mkcomdepend.txt', '--verbose']
a2x: resource files: []
a2x: resource directories: ['/etc/asciidoc/images',
'/etc/asciidoc/stylesheets']
a2x: executing: "/usr/bin/asciidoc" --backend docbook -a
"a2x-format=manpage"  --doctype manpage --verbose  --out-file
"/home/andrius/debian-packages/mkdepend-0.0~svn40/doc/mkcomdepend.xml"
"/home/andrius/debian-packages/mkdepend-0.0~svn40/doc/mkcomdepend.txt"

asciidoc: reading: /etc/asciidoc/asciidoc.conf
asciidoc: reading:
/home/andrius/debian-packages/mkdepend-0.0~svn40/doc/mkcomdepend.txt
asciidoc: reading: /etc/asciidoc/docbook45.conf
asciidoc: reading: /etc/asciidoc/filters/music/music-filter.conf
asciidoc: reading: /etc/asciidoc/filters/source/source-highlight-filter.conf
asciidoc: reading: /etc/asciidoc/filters/graphviz/graphviz-filter.conf
asciidoc: reading: /etc/asciidoc/filters/latex/latex-filter.conf
asciidoc: reading: /etc/asciidoc/filters/code/code-filter.conf
asciidoc: reading: /etc/asciidoc/lang-en.conf
asciidoc: writing:
/home/andrius/debian-packages/mkdepend-0.0~svn40/doc/mkcomdepend.xml

a2x: executing: "xmllint" --nonet --noout --valid
"/home/andrius/debian-packages/mkdepend-0.0~svn40/doc/mkcomdepend.xml"


a2x: chdir /home/andrius/debian-packages/mkdepend-0.0~svn40/doc
a2x: executing: "xsltproc"  --stringparam callout.graphics 0
--stringparam navig.graphics 0 --stringparam admon.textlabel 1
--stringparam admon.graphics 0  "/etc/asciidoc/docbook-xsl/manpage.xsl"
"/home/andrius/debian-packages/mkdepend-0.0~svn40/doc/mkcomdepend.xml"

/bin/sh: 1: xsltproc: not found

a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam
navig.graphics 0 --stringparam admon.textlabel 1 --stringparam
admon.graphics 0  "/etc/asciidoc/docbook-xsl/manpage.xsl"
"/home/andrius/debian-packages/mkdepend-0.0~svn40/doc/mkcomdepend.xml"
returned non-zero exit status 127

a2x: chdir /home/andrius/debian-packages/mkdepend

I think xsltproc should be added to Depends field for asciidoc-base.

Best,
Andrius

Bug#956727: src:vtkplotter: fails to migrate to testing for too long

[Paul Gevers]

Source: vtkplotter
Version: 2020.0.2+dfsg1-1
Severity: serious
Control: close -1 2020.2.0+dfsg1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 953235

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:vtkplotter in
its current version in unstable has been trying to migrate for 60 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=vtkplotter




signature.asc
Description: OpenPGP digital signature

Bug#956726: src:python-cassandra-driver: fails to migrate to testing for too long

[Paul Gevers]

Source: python-cassandra-driver
Version: 3.16.0-2
Severity: serious
Control: close -1 3.20.2-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:python-cassandra-driver in its current version in unstable has been
trying to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=python-cassandra-driver




signature.asc
Description: OpenPGP digital signature

Bug#956723: lintian: add check for invalid UTF8 filenames in source

[Felix Lechner]

Hi Ivo,

On Tue, Apr 14, 2020 at 10:33 AM Ivo De Decker  wrote:
>
> I assumed that those packages would be
> rejected by the archive, but clearly that's not the case.

Is it okay if source packages with non-UTF-8 file names show merely a
warning? The archive should probably tolerate them.

Kind regards
Felix Lechner

Bug#956725: gnome-subtitles build depends on gnome-doc-utils that will be removed soon

[Adrian Bunk]

Source: gnome-subtitles
Version: 1.6-2
Severity: serious
Control: block 889019 by -1
Control: block 936625 by -1

gnome-subtitles build depends on gnome-doc-utils that will be
removed soon, see #889019 and #936625 for background.

The build dependency is most likely stale and can be removed:
https://gitlab.gnome.org/GNOME/gnome-subtitles/-/commit/07532161561942f0dc635950806265e27272180b

Bug#956723: lintian: add check for invalid UTF8 filenames in source

[Ivo De Decker]

Hi Felix,

On Tue, Apr 14, 2020 at 10:17:24AM -0700, Felix Lechner wrote:
> On Tue, Apr 14, 2020 at 10:12 AM Ivo De Decker  wrote:
> >
> > This was inspired by bug #956233
> 
> The solution for that bug will address this one, as well.

Great!

> The
> supysonic case is already mentioned there (perhaps that's what you
> meant by inspiration):
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956233#17

Yes. Due to the supysonic case I noticed that lintian only checks the encoding
for filenames in binary packages. I assumed that those packages would be
rejected by the archive, but clearly that's not the case.

Having a tag for invalid filenames in source packages will makes it easier to
see the extend of the problem.

Thanks,

Ivo

Bug#952200: libvirt-dbus: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Adrian Bunk]

Control: forwarded -1 
https://gitlab.com/libvirt/libvirt-dbus/-/commit/9950c0c46d7eb3f3e7052b34464e8499b67d358a

On Sun, Mar 29, 2020 at 10:18:05PM +0200, Andrea Bolognani wrote:
>...
> Adrian, I see you tagged the bug as fixed-upstream: can you please
> share any additional information you might have and that convinced
> you the bug is no longer present upstream? Thanks in advance!

Sorry for failing to include this information,
please see the commit linked above.

cu
Adrian

Bug#956724: vokoscreen-ng: use high resolution icon

[Ronny Standtke]

Source: vokoscreen-ng
Version: 3.0.3-1
Severity: minor
Tags: patch

vokoscreen-ng uses a low resolution icon that looks bad on desktop
environments with large icons, e.g. GNOME.
The attached patch fixes this (and also adds a German translation of the
GenericName field).

Best regards

Ronny

diff --git a/debian/install b/debian/install
index 1c36955..99fc869 100644
--- a/debian/install
+++ b/debian/install
@@ -1,4 +1,3 @@
+src/applications/vokoscreenNG.png usr/share/icons/hicolor/256x256/apps
 src/vokoscreenNG  usr/bin
 debian/menu/vokoscreenNG.desktop  usr/share/applications
-debian/menu/vokoscreenNG.xpm  usr/share/pixmap
-debian/menu/vokoscreenNG.png  usr/share/pixmap
diff --git a/debian/menu/vokoscreenNG.desktop b/debian/menu/vokoscreenNG.desktop
index a69cf1a..f7adc61 100644
--- a/debian/menu/vokoscreenNG.desktop
+++ b/debian/menu/vokoscreenNG.desktop
@@ -1,9 +1,10 @@
 [Desktop Entry]
 Name=vokoscreenNG
 GenericName=Screencast Creator
+GenericName[de]=Screencast-Erstellung
 Comment=Easy to use desktop recorder
 Exec=/usr/bin/vokoscreenNG
-Icon=/usr/share/pixmap/vokoscreenNG.xpm
+Icon=vokoscreenNG
 Terminal=false
 Type=Application
 Categories=AudioVideo;Player;Recorder;

Bug#956723: lintian: add check for invalid UTF8 filenames in source

[Felix Lechner]

Control: severity -1 important

Hi Ivo,

On Tue, Apr 14, 2020 at 10:12 AM Ivo De Decker  wrote:
>
> This was inspired by bug #956233

The solution for that bug will address this one, as well. The
supysonic case is already mentioned there (perhaps that's what you
meant by inspiration):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956233#17

Kind regards
Felix Lechner

Bug#956723: lintian: add check for invalid UTF8 filenames in source

[Ivo De Decker]

package: lintian

Hi,

There is a tag file-name-is-not-valid-UTF-8 for files with invalid UTF-8 in
binary packages. Please add a similar tag for the files with invalid UTF-8 in
source packages.

This was inspired by bug #956233

Note that this causes errors in certain tools that process data from source
packages, like sources.debian.org:

https://sources.debian.org/src/supysonic/0.5.0+ds-2/tests/assets/ currently
gives "500 Something went wrong."

Thanks!

Ivo

Bug#956722: python-gnatpython: Please consider removing this package

[Boyuan Yang]

Source: python-gnatpython
Version: 54-3
Severity: serious
X-Debbugs-CC: xavier.gr...@ipno.in2p3.fr xavier.gr...@csnsm.in2p3.fr

Dear Debian python-gnatpython maintainer,

As indicated in the package tracker (
https://tracker.debian.org/pkg/python-gnatpython), package python-gnatpython
in Debian received no upload in the last 8 years and its upstream is also
defunct. Besides, it is affected by the current python2 removal. It also has
no reverse dependencies and reverse build-dependencies.

As a result, I believe this package is suitable to be removed from Debian. I
will consider filing the removal request 21 days later (after May 05, 2020).
If you have any thoughts, please let me know *immediately* so that this issue
could be solved properly in time.

Thanks for your past contribution in Debian and looking forward to your reply.

-- 
Regards,
Boyuan Yang


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

Bug#956721: libyubikey-udev: should be in package section admin (not libs)'

[Jonas Smedegaard]

Package: libyubikey-udev
Version: 1.20.0-2
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

the package libyubikey-udev contains (system defaults for) config files,
not (really) libraries.

Package is placed in package section libs which I consider wrong.
Better would be IMO to put it in section admin (similar to PAM modules)
or alternatively in section misc.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6V61EACgkQLHwxRsGg
ASFPpA//VDnbAN0Fzae8MqGOM0v4ln1TC5H/p0sD1PdcpSy1a3iCQPTr0RBArJtE
s0obfMljOA6hlpqbn9r90+iGj8JCEiU1SNTDHtCu9YjFYfKYFyBRGwracA4WkWpX
YaL3KCmQUunQqH2dfHT/Wv+UOdfmoparDWQ3NWnCSbZ1BTSV/XDNiGkRHS39abuK
AS22+Pfjoq3ypboN+XfP/jthZ65bn8/Ik3sVzaCS+ycaV24WEgXQJ7zNsXhEYape
LsjE0gyPQ8I/AL/7eOb3usy+VGbb1Fb0qZRGNH19v+liNSVew53g+rNOt4JjrFQm
f0GjpcicYgrrH7TEPP6KSb8z7kgbWtuoTfnb447RKQi2vWLXq+t7ah95fd+BdtnC
gB4s7N3RU+GQEqyoNM6a96Pt/E61GeffwzP0/kXD0fDBdxEZzaaMOSWyc4C50AfF
sOo3j2yrG6bhbR8IFPnENFa16d4+wd3DG/PA5/L7cCLp1T3W5Njv9rzkUKLLTTQ/
akTlqIvwtb8+HWLSbukFZNcmd5x0dxk9C31LmRUajaR0Vrs00CzEdZkqqv4OWio3
UFGi3ZNi0DnkrLYD9bxGej+qv5KPmrbu6uyFno2cLzJigO2drUAZcaHc6JMpXZgR
GTwzT5WwdPXuCp/uBEFP/jP4OAPa5qY73w60nlIH59T4LQFyTcs=
=6D36
-END PGP SIGNATURE-

Bug#956720: libcamera-tools: should be in package section video (not libs)

[Jonas Smedegaard]

Package: libcamera-tools
Version: 0~git20200116+30f9624-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

libcamera-tools is in package section libs.

As the package contain video tools, not libraries,
it should instead be in package section sound.

Thanks,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6V6jcACgkQLHwxRsGg
ASFfxg//bWFJWsrW96ubwWz+90g1fVK8xVLkEpeT4lvHA9XR7ASD5EiMHququuXJ
9TGlyG/rl9WZFtsYl3HnSd1j1qFtGSQtivFL6/Tzs4u69wrKhqABMPH09cZpMpIo
dUTguon1a41DetqCMa5re00NuuTPVoCEnMd9gLa3cDxED2So9f//6JWAs/PxVsgy
VNE8I+ouTwN3pFEep+da0CiFYVkIzW1OLl2Gks831QQpsiuvFliyOaNJlpggwSR1
TrAB2CfNTKTHpBjqfpNP9Kty80en5BdEiCCQPm7KlAlFhBCLxKrU+SpemGN6Ff5x
GGFCZZ9HYyQOx0d4yUbofdsj43at3/4WBM8kgRMWP7qfKiOb6a07HQIB5elMFl+9
LKRLzRNh/WRf22e2ag6s4J30S0wZwDj8AqxJCYqtimFigbNKxkWl7NwFiUdaV0NU
Y73WXInXm0VzA7eKuTlOYTgd3GFJyMz7EVQiL3Z4aj2vj5f5bdJ6b4s6O/5vNsfL
/pHypvGFk2Xcb6omgCH1sPWPJk3hnV8o3BGHNJ4bM0OH2MUhs/PW77nhHOzsXgk8
Wxvc7iI/F8tEELkr+V/kG8ROc35oS+8YnQI4efBAmUWC1rSSHtyfPSXQ+0n3xQry
OVGaHWeMGdciUmPamV7w/JCrDjXRWWZb2Qtn80iEOXEExQ0KqVs=
=818E
-END PGP SIGNATURE-

Bug#956719: openaptx-utils: should be in package section sound (not libs)

[Jonas Smedegaard]

Package: openaptx-utils
Version: 0.1.0-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

openaptx-utils is in package section libs.

Package contain audio tools, not libraries,
so should instead be in package section sound.

Thanks,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6V6U0ACgkQLHwxRsGg
ASE2bhAAqnGcHZKfgJvqIhphYXAWPadnr8zvTtO4Y8q7sLMMzAFeSb5uACvSKLgL
5wl+oIaEqmmHsfk8sFS2FnrZhsNtEzNkPBRvfmKPS6h4qH/u1sS6ZO2KYbKRuntx
Ff0eyj82DWxa1h+Zucx+un4eqnTSPl/msifwo/UsnDS0cdVYaRsWnz7BYZn3sfaG
7um+B9UUj4mJe9M4yl7p1ZmV50jSebsU4prWOeyzjAE41u4N55xJQqVxMi15
ZMw5jzmE8p21apFZ7co82wptuII7fZxTccLcW3MdqiaGu/urugyWMq1VHIBSKTtu
B2cC/a+uzpHx6Zarji0TDHSOcYcBMf8JmkiZaY902r7Rn9zv+sXyjK1vmmwx99J3
GJqCxDmiGyxiSn96ehMVnSiOBUHrT/6OJP9TuJaePL8ZdRqUQUYiDRXOlhMnWRGm
aP1Q69tcFXVXRgAUNcyh+ZniAZnytfbyLuWphQR5E842S5u6fsuwZBDLPCDxxbK7
aFk0+hymYDpy0FcMDd5hOVYKcrrjsAzrTgPvgBeNxX/+FGChnctgCjSj4pjmbFvP
rb8CYBfhML0ssyuoeWPXEAPxRKrugdsBVVXBTBYBkq+EMsgDB7KMDTblLTqBldqu
AeEixezXDElwmIbQgS5VE/CD+/uZmsckav8CM3sSqpv5oQ0pQPc=
=KLKM
-END PGP SIGNATURE-

Bug#956573: pulseaudio: Pulseaudio crashes when playing stepmania/performous

[Felipe Sateler]

Control: tags -1 moreinfo

On Mon, Apr 13, 2020 at 4:09 AM Bernat Arlandis  wrote:

> Package: pulseaudio
> Version: 12.2-4+deb10u1
> Severity: normal
>
> Dear Maintainer.
>
> These games played fine before updating the kernel. Version 4.19.0-6 works
> well, but 4.19.0-8 crashes pulseaudio.
>
> I've tried the kernel in backports (5.4) and it crashes pulseaudio too.
>

Please provide a backtrace and a verbose log.

-- 

Saludos,
Felipe Sateler

Bug#951964: gkrellm-tz: diff for NMU version 0.8-1.1

[Adrian Bunk]

On Tue, Apr 07, 2020 at 10:04:09PM -0700, Andreas Jimmy Gredler wrote:
> Hi Adrian,

Hi Jimmy,

> Thank you so much for taking care of this. Unfortunately I won’t be able to 
> maintain this package anymore and was looking into the process of handing it 
> over. Please let me know if you would be interested in maintaining it 
> yourself. It did not require a lot of work in the past as there were not many 
> releases. Otherwise I guess will file an RFA or O request.
> Thanks again.

thanks, that's fine for me - I am using it and there is not much work
expected with it in the future. I will adopt it and make a maintainer
upload instead.

What about your other packages?

If you are looking for someone to adopt gkrellshoot,
I can also adopt that one.

For comgt I could only offer to submit an RFA or O bug for you.

> Best,
> Jimmy

cu
Adrian

Bug#956177: fail2ban: daemon startup should not access /root/.local

[Sylvestre Ledru]

Le 08/04/2020 à 04:51, Russell Coker a écrit :

Package: fail2ban
Version: 0.11.1-1
Severity: normal

type=AVC msg=audit(1586313861.749:37): avc:  denied  { search } for  pid=704 comm="fail2ban-server" 
name=".local" dev="sdb2" ino=31516 scontext=system_u:system_r:fail2ban_t:s0 
tcontext=unconfined_u:object_r:xdg_data_t:s0 tclass=dir permissive=0

Above is a SE Linux audit message generated by fail2ban starting on system
boot.  It is trying to access /root/.local which is inappropriate for a daemon.
No system configuration should be under /root/ and any daemon which accesses
that could give unexpected results.

Hello Russell,

Could you please reply to 
https://github.com/fail2ban/fail2ban/issues/2688#issuecomment-613543589 ?

(I also looked at the code and could not find where /root/.local would be 
loaded)

Cheers,
Sylvestre

Bug#956718: Register intetutils-foo commands as foo in architectures where net-tools are not available

[Pirate Praveen]

Package: src:inetutils
Severity: wishlist
Version: 2:1.9.4-11

libnet-dev is not avilable on hurd-i386 and kfreebsd-* architectures
https://buildd.debian.org/status/package.php?p=dnprogs=sid

So it'd be nice if commands like inetutls-ifconfig is available as 
ifconfig at least on these architectures.

Bug#956717: ITP: Mystiq -- Powerful FFmpeg GUI front-end based on Qt5 and writed in C++

[Pablo Mestre]

Package: wnpp
Version: 20.03.23-1; reported 2020-04-14
Severity: wishlist

* Package name: mystiq
Version: 20.03.23
Upstream Author: Maikel Llamaret Heredia 
* URL: https://mystiqapp.com/
* License:  GPL,
Description: Powerful media converter. FFmpeg can read audio and video
files in various
 formats and convert them into other formats. MystiQ features an intuitive
 graphical interface and a rich set of presets to help you convert media
 files within a few clicks. Advanced users can also adjust conversion
 parameters in detail.

-- System Information

Format: 1.8
Date: Mon, 06 Apr 2020 16:34:51 -0300
Source: mystiq
Binary: mystiq mystiq-dbgsym
Architecture: source amd64
Version: 20.03.23-1
Distribution: unstable
Urgency: medium
Maintainer: Pablo Mestre Drake 
Changed-By: Pablo Mestre Drake 
Description:
 mystiq - Powerful FFmpeg GUI front-end based on Qt5 and writed in C++
Changes:
 mystiq (20.03.23-1) unstable; urgency=medium
 .
   * New upstream version 20.03.23
   * Add salsa-ci.yml copied from Debian pipeline for Developers
Checksums-Sha1:
 3dcd45985c5da7d9017d4533e6e3164a9289b9b2 1281 mystiq_20.03.23-1.dsc
 b7a4428bae0a946dfba23d030f47403400615ef2 896299 mystiq_20.03.23.orig.tar.gz
 b315d8e6dfe6d27e77ea90cd068ac3ad31cdaa7f 2624
mystiq_20.03.23-1.debian.tar.xz
 525f6f8107d4aeddf74afbeda13898df0fa728c5 3209308
mystiq-dbgsym_20.03.23-1_amd64.deb
 f2dcd3f2998aa3a60f1e08e6dd3c2ec6e9fefe19 10925
mystiq_20.03.23-1_amd64.buildinfo
 58b746a0c9d8086501bc82099d77f02d27bd3dab 603780 mystiq_20.03.23-1_amd64.deb
Checksums-Sha256:
 dd8106c583a77992aabb2513dea763c7ac711aa3348b4eef3c00660cad204cda 1281
mystiq_20.03.23-1.dsc
 cfb84faebf68876733624e4500d4b6c654bc01cb75fd6eddd9efa8337816d22e 896299
mystiq_20.03.23.orig.tar.gz
 a35f47ac538ae4a2e6a3427e3bc291a5346acb5f28f05739399a4de44811a654 2624
mystiq_20.03.23-1.debian.tar.xz
 6872929df3eae59abad4e37b610d4f8525f174fbd132096df6e2646bdb4f3c8f
3209308 mystiq-dbgsym_20.03.23-1_amd64.deb
 6563fe353ef20dd1697e7ff32b69be48404b35ebfcfadbaa9f07143b65a388f8 10925
mystiq_20.03.23-1_amd64.buildinfo
 44f0809823516910bdf8b175aa4d139012100f273300b4738d50a4fffc6fe4e4 603780
mystiq_20.03.23-1_amd64.deb
Files:
 76411d956ea5237f8a7ed8264b9884b7 1281 video optional mystiq_20.03.23-1.dsc
 d6e3babb0be21ae7592f4c313cc6edac 896299 video optional
mystiq_20.03.23.orig.tar.gz
 00763dac5eba71b1ff115c0d906c9e79 2624 video optional
mystiq_20.03.23-1.debian.tar.xz
 00bd186be6aadf3b36564d7105257f54 3209308 debug optional
mystiq-dbgsym_20.03.23-1_amd64.deb
 e15f6b2d3055cb8b891283a460278e35 10925 video optional
mystiq_20.03.23-1_amd64.buildinfo
 7a2fb34f26ea209c03afa99a8a38c250 603780 video optional
mystiq_20.03.23-1_amd64.deb

Bug#956716: ITP: r-cran-rematch2 -- Tidy Output from Regular Expression Matching

[Dylan Aïssi]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rematch2 -- Tidy Output from Regular Expression Matching
Package: wnpp
Owner: Dylan Aïssi 
Severity: wishlist

* Package name: r-cran-rematch2
  Version : 2.1.1
  Upstream Author : Mango Solutions, Gábor Csárdi, Matthew Lincoln
* URL : https://cran.r-project.org/package=rematch2
* License : MIT
  Programming Lang: GNU R
  Description : Tidy Output from Regular Expression Matching
 Wrappers on 'regexpr' and 'gregexpr' to return the match
 results in tidy data frames.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-rematch2

Bug#956715: openrc FTCBFS: strips with the wrong strip

[Helmut Grohne]

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

openrc fails to cross build from source, because it strips lsb2rcconf
using the build architecture strip. It does so during dh_auto_install,
so it happens to alos break DEB_BUILD_OPTIONS=nostrip as well as
generation of a -dbgsym package. It is best to leave stripping up to
dh_strip. Please consider applying the attached patch.

Helmut
diff --minimal -Nru openrc-0.40.3/debian/changelog 
openrc-0.40.3/debian/changelog
--- openrc-0.40.3/debian/changelog  2019-02-02 16:41:07.0 +0100
+++ openrc-0.40.3/debian/changelog  2020-04-14 17:59:29.0 +0200
@@ -1,3 +1,10 @@
+openrc (0.40.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 14 Apr 2020 17:59:29 +0200
+
 openrc (0.40.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru openrc-0.40.3/debian/rules openrc-0.40.3/debian/rules
--- openrc-0.40.3/debian/rules  2019-02-02 16:41:07.0 +0100
+++ openrc-0.40.3/debian/rules  2020-04-14 17:59:28.0 +0200
@@ -21,6 +21,7 @@
 export SHLIBDIR = /lib/$(DEB_HOST_MULTIARCH)
 export LIBNAME = lib
 export LIBEXECDIR = /lib/rc
+export STRIP_BINARY = no
 
 ifeq (linux,$(DEB_HOST_ARCH_OS))
 export MKAUDIT = yes

Bug#782654: ITP: bazel -- Fast and correct automated build system by Google

[Andreas Tille]

Hi Olek,

On Tue, Apr 14, 2020 at 11:27:45AM -0400, Olek Wojnar wrote:
> To those interested in Bazel in Debian:
> ...
> Looking forward to getting a good group of people together who can
> contribute to this, to whatever extent they are able!

while I doubt that I'll be of technical help to work on this package I'd
like to express that I'm extremely happy.  Your effort for bazel which
will finally a big step to get tensorflow in which is a precondition for
several COVID-19 releavant packages is really welcome.

Thanks a lot

  Andreas.

-- 
http://fam-tille.de

Bug#910685: glibc: please support DPKG_ROOT

[Helmut Grohne]

On Tue, Oct 09, 2018 at 10:09:57PM +0200, Johannes 'josch' Schauer wrote:
> Currently in Debian sid, there are 57 packages that need to be installed
> for the whole Essential:yes set. Most of them Depend (directly or
> indirectly) on libc6. Attached patch adds $DPKG_ROOT to a couple of
> places of the preinst and postinst of libc6 and that will make 37 of
> these 57 install without problems. The patch adds $DPKG_ROOT in more
> places than strictly necessary for just installing packages. For example
> I didn't test the upgrade scenario. If you like, I can prepare a smaller
> patch with only the code paths that I tested.

I think that your approach is not ideal. Much of the code in the libc
scripts is for ensuring that a system is not bricked and that services
continue to work after a libc upgrade. When working with the chrootless
mode, we cannot assume that the running kernel version or other aspects
are relevant to the chroot at hand. In this case, it is much better to
skip the relevant code entirely. Doing so has the additional benefit of
not using debconf at all. When running in chrootless mode, there cannot
be any services running, because they'd have to be chrooted. So we can
simply skip all those checks. The patch becomes quite a bit simpler.

> It would be nice if you could consider applying attached patch because
> it is required for the majority of packages in the Essential:yes set to
> be successfully installed with the --force-script-chrootless mode.
> 
> To test you can run:
> 
> dpkg --root "$target" --log "$target/var/log/dpkg.log" 
> --force-script-chrootless -i libc6_2.27-6.1_amd64.deb

Yes, please. Is there anything blocking this? Without support in glibc,
moving forward is a little difficult. Can you include it soonish?

Helmut
diff --minimal -Nru glibc-2.30/debian/changelog glibc-2.30/debian/changelog
--- glibc-2.30/debian/changelog 2020-03-25 13:56:56.0 +0100
+++ glibc-2.30/debian/changelog 2020-04-14 17:39:34.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.30-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Initial, minimal support for DPKG_ROOT. (Closes: #910685)
+
+ -- Helmut Grohne   Tue, 14 Apr 2020 17:39:34 +0200
+
 glibc (2.30-4) unstable; urgency=medium
 
   [ Aurelien Jarno ]
diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.postinst 
glibc-2.30/debian/debhelper.in/libc.postinst
--- glibc-2.30/debian/debhelper.in/libc.postinst2020-03-25 
13:36:06.0 +0100
+++ glibc-2.30/debian/debhelper.in/libc.postinst2020-04-14 
17:36:49.0 +0200
@@ -17,11 +17,14 @@
 if [ "$type" = "configure" ]
 then
 # We don't use a registry anymore, remove the old file
-rm -f /etc/ld.so.hwcappkgs
+rm -f "$DPKG_ROOT/etc/ld.so.hwcappkgs"
  
 # /etc/ld.so.nohwcap code:
 __NOHWCAP__
+fi
 
+if [ "$type" = configure -a -z "$DPKG_ROOT" ]
+then
 # Load debconf module if available
 if [ -f /usr/share/debconf/confmodule ] ; then
. /usr/share/debconf/confmodule
diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.preinst 
glibc-2.30/debian/debhelper.in/libc.preinst
--- glibc-2.30/debian/debhelper.in/libc.preinst 2020-03-25 13:38:38.0 
+0100
+++ glibc-2.30/debian/debhelper.in/libc.preinst 2020-04-14 17:38:54.0 
+0200
@@ -19,7 +19,7 @@
 test $verA -$2 $verB
 }
 
-if [ "$type" != abort-upgrade ]
+if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
 then
 # Load debconf module if available and usable
 if [ -f /usr/share/debconf/confmodule ] && \
@@ -148,7 +148,7 @@
 fi
 fi
 
-if [ "$type" = upgrade ]
+if [ "$type" = upgrade -a -z "$DPKG_ROOT" ]
 then
 if [ -n "$preversion" ] && [ -x "$(which ischroot)" ] && ! ischroot; then
# NSS authentication trouble guard
@@ -246,8 +246,8 @@
# unconditionally wipe ld.so.cache on major version upgrades; this
# makes those upgrades a bit slower, but is less error-prone than
# hoping we notice every time the cache format is changed upstream
-   rm -f /etc/ld.so.cache
-   rm -f /var/cache/ldconfig/aux-cache
+   rm -f "$DPKG_ROOT/etc/ld.so.cache"
+   rm -f "$DPKG_ROOT/var/cache/ldconfig/aux-cache"
 fi
 fi
 
diff --minimal -Nru glibc-2.30/debian/script.in/nohwcap.sh 
glibc-2.30/debian/script.in/nohwcap.sh
--- glibc-2.30/debian/script.in/nohwcap.sh  2019-08-16 12:57:33.0 
+0200
+++ glibc-2.30/debian/script.in/nohwcap.sh  2020-04-14 17:39:30.0 
+0200
@@ -18,5 +18,5 @@
 # one, we could remove /etc/ld.so.nohwcap. Otherwise, it will be removed
 # when all optimized packages are upgraded or removed.
 if [ "$all_upgraded" = yes ] ; then
-rm -f /etc/ld.so.nohwcap
+rm -f "$DPKG_ROOT/etc/ld.so.nohwcap"
 fi

Bug#956713: autoconf-archive: AX_LUA_HEADERS uses AC_RUN_IFELSE

[Helmut Grohne]

Source: autoconf-archive
Version: 20190106-2.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:telegram-cli

telegram-cli fails to cross build from source, because it uses
AX_LUA_HEADERS, which happens to use AC_RUN_IFELSE to compute the lua
version. As it turns out, the version is also available as an integer,
which allows using the cross-friendly AC_COMPUTE_INT. The attached patch
updates AX_LUA_HEADERS to use AC_COMPUTE_INT. Please consider applying
it to make telegram-cli cross buildable.

Helmut
--- autoconf-archive-20190106.orig/m4/ax_lua.m4
+++ autoconf-archive-20190106/m4/ax_lua.m4
@@ -524,22 +524,17 @@ AC_DEFUN([AX_LUA_HEADERS],
 [ax_cv_lua_header_version],
 [ _ax_lua_saved_cppflags=$CPPFLAGS
   CPPFLAGS="$CPPFLAGS $LUA_INCLUDE"
-  AC_RUN_IFELSE(
-[ AC_LANG_SOURCE([[
+  AC_COMPUTE_INT(ax_cv_lua_header_version_major,[LUA_VERSION_NUM/100],[AC_INCLUDES_DEFAULT
 #include 
-#include 
-#include 
-int main(int argc, char ** argv)
-{
-  if(argc > 1) printf("%s", LUA_VERSION);
-  exit(EXIT_SUCCESS);
-}
-]])
-],
-[ ax_cv_lua_header_version=`./conftest$EXEEXT p | \
-$SED -n "s|^Lua \(@<:@0-9@:>@\{1,\}\.@<:@0-9@:>@\{1,\}\).\{0,\}|\1|p"`
-],
-[ax_cv_lua_header_version='unknown'])
+],[ax_cv_lua_header_version_major=unknown])
+  AC_COMPUTE_INT(ax_cv_lua_header_version_minor,[LUA_VERSION_NUM%100],[AC_INCLUDES_DEFAULT
+#include 
+],[ax_cv_lua_header_version_minor=unknown])
+  AS_IF([test "x$ax_cv_lua_header_version_major" = xunknown || test "x$ax_cv_lua_header_version_minor" = xunknown],[
+ax_cv_lua_header_version=unknown
+  ],[
+ax_cv_lua_header_version="$ax_cv_lua_header_version_major.$ax_cv_lua_header_version_minor"
+  ])
   CPPFLAGS=$_ax_lua_saved_cppflags
 ])
 

Bug#956714: mmdebstrap should skip the emulation check in chrootless mode

[Helmut Grohne]

Package: mmdebstrap
Version: 0.6.1-6
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

Whenever the selected architecture differs from the native architecture
of the system that runs mmdebstrap, mmdebstrap checks whether it can run
the selected architecture. In the majority of cases, this is good and
helps avoid difficult to diagnose issues. However when running in
chrootless mode, we don't actually want to run any binaries from the
target system. For that reason, the emulation check should be skipped in
chrootless mode. Please consider applying the attached patch.

Helmut
--- mmdebstrap-0.6.1.orig/mmdebstrap
+++ mmdebstrap-0.6.1/mmdebstrap
@@ -3095,7 +3095,9 @@ sub main() {
 sparc=> 'sparc',
 sparc64  => 'sparc64',
 };
-if ($hostarch ne $options->{nativearch}) {
+	if ($options->{mode} eq "chrootless") {
+info "skipping emulation check in chrootless mode";
+	} elsif ($hostarch ne $options->{nativearch}) {
 my $withemu = 0;
 my $noemu   = 0;
 {

Bug#801339: fonts-texgyre: missing glyphs when viewing PDFs via poppler

[Jim Paris]

Hilmar Preuße wrote:
> Am 08.10.2015 um 20:52 teilte Jim Paris mit:
> 
> Hi Jim,
> 
> > When viewing PDFs that do not embed Helvetica, the μ (U+03BC) 
> > character does not render correctly when fonts-texgyre is installed. 
> > For example, this PDF: http://jim.sh/~jim/tmp/bugs/tps62120.pdf
> > 
> > With fonts-texgyre (20150923-1) installed, glyphs are missing:
> > 
> For any reason that bug was invisible to us, sorry late response.
> 
> Your example URL is invalid meanwhile: are you able to reproduce the
> issue w/ latest fonts-texgyre installed? If yes, could you provide a new
> example or a TeX source code?

I've restored the link.

I just reinstalled fonts-texgyre and I do not currently see this
problem (xpdf 3.04-13, fonts-texgyre 20180621-3).  However, I think
this may be because some other system configuration has changed,
because "TeXGyreHeros" is no longer the substitute font that poppler
chooses:

  $ pdffonts -subst tps62120.pdf
  name object ID substitute font
  substitute font file
   - 
 
  Arial-BoldMT 81  0 Arial Negreta  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
  ArialMT  83  0 DejaVu Sans
  /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
  Arial-ItalicMT  101  0 Arial Cursiva  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Italic.ttf
  Arial-BoldItalicMT  401  0 Arial Negreta cursiva  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold_Italic.ttf
  Helvetica   889  0 NimbusSans-Regular 
  /usr/share/fonts/opentype/urw-base35/NimbusSans-Regular.otf
  Helvetica-Bold  890  0 NimbusSans-Bold
  /usr/share/fonts/opentype/urw-base35/NimbusSans-Bold.otf
  Helvetica   905  0 NimbusSans-Regular 
  /usr/share/fonts/opentype/urw-base35/NimbusSans-Regular.otf
  Helvetica-Bold  906  0 NimbusSans-Bold
  /usr/share/fonts/opentype/urw-base35/NimbusSans-Bold.otf
  Arial-BoldItalicMT  973  0 Arial Negreta cursiva  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold_Italic.ttf
  ArialMT 975  0 DejaVu Sans
  /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
  Arial-BoldMT977  0 Arial Negreta  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf

Let's see...
If I check "fc-match", it seems "TeX Gyre Heros" is still high up on
the list, but "Nimbus Sans" beat it:

  $ fc-match -s Helvetica | head -8
  NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
  n019003l.pfb: "Nimbus Sans L" "Regular"
  texgyreheros-regular.otf: "TeX Gyre Heros" "Regular"
  Arial.ttf: "Arial" "Regular"
  LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
  DejaVuSans.ttf: "DejaVu Sans" "Book"
  DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
  DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"

Those Nimbus fonts are coming from package fonts-urw-base35.  If I
remove that package[*], then "TeX Gyre Heros" is back as the PDF font
substitution:

  $ pdffonts -subst tps62120.pdf
  name object ID substitute font
  substitute font file
   - 
 
  Arial-BoldMT 81  0 Arial Negreta  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
  ArialMT  83  0 DejaVu Sans
  /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
  Arial-ItalicMT  101  0 Arial Cursiva  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Italic.ttf
  Arial-BoldItalicMT  401  0 Arial Negreta cursiva  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold_Italic.ttf
  Helvetica   889  0 TeXGyreHeros-Regular   
  /usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreheros-regular.otf
  Helvetica-Bold  890  0 TeXGyreHeros-Bold  
  /usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreheros-bold.otf
  Helvetica   905  0 TeXGyreHeros-Regular   
  /usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreheros-regular.otf
  Helvetica-Bold  906  0 TeXGyreHeros-Bold  
  /usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreheros-bold.otf
  Arial-BoldItalicMT  973  0 Arial Negreta cursiva  
 

Bug#956712: emacs: https to plain http downgrade after unhandled GNUTLS_E_AGAIN error in TLS1.3 connection

[Heenec]

Package: emacs
Version: 1:26.1+1-3.2+deb10u1
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

When I have tried to install a package from the GNU ELPA repository, I
received a "Bad Request" error. Searching on the Internet for a solution
of this problem led me to this bugreport at debbugs.gnu.org:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341

I have confirmed, that the bug reported there can be reproduced in my
emacs installation, and that the workaround mentioned there (disabling
TLS1.3) works.

But while playing around with this bug I noticed, that for some reason
after breaking the TLS1.3 connection it makes second connection with
plain http to the port 443 (sic!).

 Steps to reproduce:

1) Run emacs
2) Open scratchpad with "C-x b *scratch*"
3) Write the following snippet and execute it by positioning cursor
after the
last ")" and pressing C-j.
```
(switch-to-buffer (url-retrieve-synchronously "https://duckduckgo.com;)
  (buffer-string))
```

 Results:

A new buffer with following content is opened:
```
HTTP/1.1 400 Bad Request
Server: nginx
Date: Fri, 02 Apr 2020 12:54:12 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 248
Connection: close
X-XSS-Protection: 1;mode=block
X-Content-Type-Options: nosniff
Referrer-Policy: origin
Expect-CT: max-age=0


400 The plain HTTP request was sent to HTTPS
port

400 Bad Request
The plain HTTP request was sent to HTTPS port
nginx


#
```

Also if network traffic was captured with Wireshark, it can be seen,
that breaking of the TLS1.3 connection follows with a plain http request
to port 443 on the same IP address. And the result of this http request
is returned by the url-retrieve-synchronously function.

The same behaviour is seen in network captures of (failing) emacs
package installation process.

Althogh the bug mentioned in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341 seems to be
currently fixed in upstream emacs 26.3 and 27.1, the related patch fixes
wrong handling of GNUTLS_E_AGAIN error, but not this fallback from https
to plain http. It suggests, that this behaviour may be triggered by
other exceptions.

Heenec



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

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

Versions of packages emacs depends on:
ii  emacs-gtk  1:26.1+1-3.2+deb10u1

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#952806: FWIW, cbindgen 0.14.1-1 is already in sid/unstable and perhaps will migrate to testing if tomorrow or day after rust-libc migrates

[shirish शिरीष]

Hi there,

See [1] and [2]

1. https://tracker.debian.org/pkg/rust-libc

2. https://tracker.debian.org/pkg/rust-cbindgen

You can thank Andrej Shadura and Peter Michael Green, while the credit
for the second goes to Sylvestre Ledru.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#956615: RM: gmime2.6 -- ROM; new upstream version (gmime 3.0) has been available for years, no reverse deps

[Daniel Kahn Gillmor]

Control: tags 956615 - moreinfo

On Mon 2020-04-13 22:51:04 -0400, Scott Kitterman wrote:
> Except balsa FTBFS on all archs:
>
> https://buildd.debian.org/status/package.php?p=balsa
>
> Please remove the moreinfo tag once this is resolved.

Sorry, missing build dep, which has since been resolved in balsa
2.6.0-2.

Should be ready to go now.

Thanks for keeping an eye on this.

   --dkg


signature.asc
Description: PGP signature

Bug#956711: munin: permissions of /var/log/munin for html/graph_strategy cgi: www-data user should be in groups munin and adm

[devel]

Hello Marcel,

thank you for your bug report!


Am Tue, 14 Apr 2020 16:40:12 +0200
schrieb Marcel Partap :

> By default, debian's munin is not ready for switching html_strategy and
> graph_strategy to cgi because of a lack of access permission for the (apache2)
> www-data user on folders /var/lib/munin/cgi-tmp and /var/log/munin .
> 
> This can be resolved by allowing the respective owner groups write access
> > chmod g+w /var/lib/munin/cgi-tmp /var/log/munin
> [..]
> gpasswd -a www-data munin
> gpasswd -a www-data adm  

are you really sure, that these steps are necessary?

The munin package uses autopkgtests. One of the tested scenarios is the switch
to the CGI-based rendering. The preparations for this step are quite trivial:
* change the strategies to "cgi"
* toggle the enabled line in the apache configuration (as documented there)

(see
https://salsa.debian.org/debian/munin/-/blob/debian/debian/tests/enable_cgi_strategy.inc)

Afterwards it should work. At least the current tests do not fail ...


The permissions should be handled automatically during package installation:

   touch /var/log/munin/munin-cgi-html.log
   chown www-data:adm /var/log/munin/munin-cgi-html.log
   chmod 640 /var/log/munin/munin-cgi-html.log

   touch /var/log/munin/munin-cgi-graph.log
   chown www-data:adm /var/log/munin/munin-cgi-graph.log
   chmod 640 /var/log/munin/munin-cgi-graph.log

   mkdir -p /var/lib/munin/cgi-tmp
   chown munin:www-data /var/lib/munin/cgi-tmp
   chmod 775 /var/lib/munin/cgi-tmp
(see the postinst script)


Maybe you are cleaning up the log directory (e.g. on a read-only system) during
a reboot?
In this case it would indeed fail. I guess, it would be nice for the package to
also work in such situations (e.g. non-permantent /var/log/).

Or do you have another idea, what could be wrong?

Cheers,
Lars

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Andreas Tille]

Control: reassign -1 clustalo
Control: retitle -1 "clustalo: Bus error on mipsel"
Control: tags -1 upstream
Control: forwarded -1 clust...@ucd.ie

Hi,

I took over the test done by biopython into the clustalo build time and
autopkgtest.  As Peter assumed this is an issue in clustalo as you can
see in the build log on mipsel here:

   
https://buildd.debian.org/status/fetch.php?pkg=clustalo=mipsel=1.2.4-5=1586866059=0

...
# Run additional test from python-biopython package to verify that
# this will work as well
src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out 
temp_test.dnd -o temp_test.aln --outfmt clustal --force
make[1]: *** [debian/rules:25: override_dh_auto_test-arch] Bus error


Any help from the Debian Mips team would be really welcome.  The
covid-19 effort is occupying all hands for lots of things so we
probably have limited time to debug this kind of issues.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#956119: asterisk: segfault in libspandsp.so.2.0.0 when using Set(FAXOPT(gateway)=yes,30) between SIP and iax

[Bernhard Schmidt]

Control: found -1 1:16.2.1~dfsg-1
Control: forwarded -1 https://issues.asterisk.org/jira/browse/ASTERISK-27981

Hi,

> I tried to extract from the submitter's dmesg line the
> source location of the crash.
> 
> I assume it happened here [1], with
> variable s containing an invalid pointer:
> 
> 0x77f5bb90 in update_rx_timing at t38_gateway.c:2244
> 
> 2242 static void update_rx_timing(t38_gateway_state_t *s, int len)
> 2243 {
> 2244 if (s->core.samples_to_timeout > 0)
> 2245 {
> 
> 
> https://sources.debian.org/src/spandsp/0.0.6+dfsg-2/src/t38_gateway.c/#L2244
> 
> 
> Maybe it is of some help.
> But a proper backtrace like described in following link would probably
> be way better: https://wiki.debian.org/HowToGetABacktrace

Thanks a lot. This looks very much like the backtrace in
https://issues.asterisk.org/jira/browse/ASTERISK-28450

---
Core was generated by `/usr/sbin/asterisk -f -U asterisk -G asterisk
-vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  update_rx_timing (s=0x29b28, len=160) at t38_gateway.c:2189
2189if (s->core.samples_to_timeout > 0)
---

The bug itself is marked as duplicate of
https://issues.asterisk.org/jira/browse/ASTERISK-27981, which refers to

https://gerrit.asterisk.org/c/asterisk/+/11434

@Benoit: Can you test with that patch applied?

Bernhard

Bug#782654: ITP: bazel -- Fast and correct automated build system by Google

[Olek Wojnar]

To those interested in Bazel in Debian:

We just had a very positive discussion with upstream and I think that
finally getting Bazel into Debian is on the horizon. This endeavor is going
to be larger than one person, in the long run if not right at this moment.

Therefore, I would like to create a Bazel packaging team in Debian since a
team approach is what will ensure this build system remains viable and
well-supported even after the short-term goal of helping to get software
into Debian to address the COVID-19 pandemic.

If you are subscribed to this bug and are interested (or know someone who
is), please let me know if you would like to be part of that team in some
capacity. I am happy to continue coordinating this team and I am equally
happy to pass that responsibility on if anyone else has a strong desire to
do that. Since Kyle was previously working this project by himself, I
definitely defer to him if he has the time and desire to lead the new team.

Looking forward to getting a good group of people together who can
contribute to this, to whatever extent they are able!

-Olek

Bug#956711: munin: permissions of /var/log/munin for html/graph_strategy cgi: www-data user should be in groups munin and adm

[Marcel Partap]

Package: munin
Version: 2.0.57-1
Severity: normal

By default, debian's munin is not ready for switching html_strategy and
graph_strategy to cgi because of a lack of access permission for the (apache2)
www-data user on folders /var/lib/munin/cgi-tmp and /var/log/munin .

This can be resolved by allowing the respective owner groups write access
> chmod g+w /var/lib/munin/cgi-tmp /var/log/munin

.. and adding the www-data user to the owning groups for both:
> gpasswd -a www-data munin
> gpasswd -a www-data adm

With this, the cgi strategies work beautifully, including dynazoom.



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

Kernel: Linux 5.5.0-1-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_CRAP, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages munin depends on:
ii  cron [cron-daemon]   3.0pl1-135
ii  debconf [debconf-2.0]1.5.73
ii  fonts-dejavu-core2.37-1
ii  init-system-helpers  1.57
ii  libdate-manip-perl   6.78-1
pn  libdigest-md5-perl   
ii  libfile-copy-recursive-perl  0.44-1
ii  libhtml-template-perl2.97-1
ii  libio-socket-inet6-perl  2.72-2
ii  liblog-log4perl-perl 1.49-1
ii  librrds-perl 1.7.2-3
pn  libstorable-perl 
ii  liburi-perl  1.76-1
ii  lsb-base 11.1.0
ii  munin-common 2.0.57-1
ii  netbase  6.1
ii  perl [libtime-hires-perl]5.30.0-9
ii  rrdtool  1.7.2-3+b1
ii  systemd-sysv 245.4-3

Versions of packages munin recommends:
ii  libcgi-fast-perl  1:2.15-1
ii  munin-doc 2.0.51-1
ii  munin-node2.0.57-1

Versions of packages munin suggests:
ii  apache2 [httpd]  2.4.43-1
ii  chromium [www-browser]   80.0.3987.116-1
ii  elinks [www-browser] 0.13.1-1
ii  falkon [www-browser] 3.1.0+dfsg1-6
ii  firefox [www-browser]74.0-1
ii  konqueror [www-browser]  4:19.08.2-2+b1
ii  libapache2-mod-fcgid 1:2.3.9-4
ii  libnet-ssleay-perl   1.88-1+b1
ii  links2 [www-browser] 2.20.2-1+b1
ii  w3m [www-browser]0.5.3-37+b1

-- Configuration Files:
/etc/cron.d/munin changed:
MAILTO=root
*/5 * * * * munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; 
fi
14 10 * * * munin if [ -x /usr/share/munin/munin-limits ]; then 
/usr/share/munin/munin-limits --force --contact nagios --contact old-nagios; fi
27 03 * * * munin htmldir=$({ cat /etc/munin/munin.conf 
/etc/munin/munin-conf.d/* 2>/dev/null || true; } | sed -nE 
's/^\s*htmldir\s+(\S.*)$/\1/p' | tail -1); 
htmldir=${htmldir:-/var/cache/munin/www}; if [ -d "$htmldir" ]; then find 
"$htmldir/" -type f -name "*.html" -mtime +30 -delete; find "$htmldir/" 
-mindepth 1 -type d -empty -delete; fi
32 03 * * * www-data cgitmpdir=$({ cat /etc/munin/munin.conf 
/etc/munin/munin-conf.d/* 2>/dev/null || true; } | sed -nE 
's/^\s*cgitmpdir\s+(\S.*)$/\1/p' | tail -1); 
cgitmpdir=${cgitmpdir:-/var/lib/munin/cgi-tmp}; if [ -d "$cgitmpdir" ]; then 
find "$cgitmpdir/" -type f -mtime +1 -delete; find "$cgitmpdir/" -mindepth 1 
-type d -empty -delete; fi

/etc/munin/apache24.conf changed:
ScriptAlias /munin-cgi/munin-cgi-graph /usr/lib/munin/cgi/munin-cgi-graph
Alias /munin/static/ /var/cache/munin/www/static/

Require local
Options None


Require local

SetHandler fcgid-script


SetHandler cgi-script


ScriptAlias /munin /usr/lib/munin/cgi/munin-cgi-html

/etc/munin/munin.conf changed:
includedir /etc/munin/munin-conf.d
graph_strategy cgi
html_strategy cgi
[base]
address 127.0.0.1
use_node_name yes
[spot]
address 192.168.1.1
use_node_name yes


-- debconf-show failed

Bug#883308: libseccomp2 is missing ia64 support

[Kees Cook]

On Tue, Apr 14, 2020 at 02:02:29PM +0200, Gregor Riepl wrote:
> At least on sparc64 and sh4 we have SECCOMP support in kernel, but not
> HAVE_ARCH_SECCOMP_FILTER. Does libseccomp need HAVE_ARCH_SECCOMP_FILTER?

For nearly everything that it gets used for, libseccomp depends on
CONFIG_SECCOMP_FILTER.

-- 
Kees Cook@debian.org

Bug#956710: abiword: Please witch to enchant-2 instead of enchant(1)

[Laurent Bigonville]

Source: abiword
Version: 3.0.2-10
Severity: important
Tags: patch
Control: block 947979 by -1

Hello,

Could you please switch from enchant(1) to the enchant-2 library?

We are trying to get rid of enchant(1) for the bullseye release.

The attached patch should fix this

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -Nru abiword-3.0.2/debian/control abiword-3.0.2/debian/control
--- abiword-3.0.2/debian/control2020-04-02 14:46:29.0 +0200
+++ abiword-3.0.2/debian/control2020-04-14 15:22:12.0 +0200
@@ -13,7 +13,7 @@
libchamplain-gtk-0.12-dev,
libebook1.2-dev (>= 3.8.5),
libical-dev (>= 3.0),
-   libenchant-dev,
+   libenchant-2-dev,
libfribidi-dev,
libgcrypt20-dev,
libgirepository1.0-dev,
diff -Nru abiword-3.0.2/debian/patches/enchant2.patch 
abiword-3.0.2/debian/patches/enchant2.patch
--- abiword-3.0.2/debian/patches/enchant2.patch 1970-01-01 01:00:00.0 
+0100
+++ abiword-3.0.2/debian/patches/enchant2.patch 2020-04-14 15:24:39.0 
+0200
@@ -0,0 +1,40 @@
+--- a/configure.ac
 b/configure.ac
+@@ -94,7 +94,7 @@ xp_pkgs="
+ "
+ 
+ # optional deps
+-enchant_req='enchant >= 1.2.0'
++enchant_req='enchant-2 >= 1.2.0'
+ gio_req='gio-2.0'
+ goffice_req='libgoffice-0.10 >= 0.10.0'
+ 
+--- a/src/af/xap/xp/enchant_checker.cpp
 b/src/af/xap/xp/enchant_checker.cpp
+@@ -127,7 +127,7 @@ EnchantChecker::_suggestWord (const UT_U
+   pvSugg->addItem (ucszSugg);
+   }
+ 
+-  enchant_dict_free_suggestions (m_dict, suggestions);
++  enchant_dict_free_string_list (m_dict, suggestions);
+   }
+ 
+   return pvSugg;
+@@ -139,7 +139,7 @@ bool EnchantChecker::addToCustomDict (co
+ 
+   if (word && len) {
+   UT_UTF8String utf8 (word, len);
+-  enchant_dict_add_to_personal (m_dict, utf8.utf8_str(), 
utf8.byteLength());
++  enchant_dict_add (m_dict, utf8.utf8_str(), utf8.byteLength());
+   return true;
+   }
+   return false;
+@@ -150,7 +150,7 @@ bool EnchantChecker::isIgnored (const UT
+   UT_return_val_if_fail (m_dict, false);
+ 
+   UT_UTF8String ignore (toCorrect, toCorrectLen);
+-  return enchant_dict_is_in_session (m_dict, ignore.utf8_str(), 
ignore.byteLength()) != 0;
++  return enchant_dict_is_added (m_dict, ignore.utf8_str(), 
ignore.byteLength()) != 0;
+ }
+ 
+ void EnchantChecker::ignoreWord (const UT_UCSChar *toCorrect, size_t 
toCorrectLen)
diff -Nru abiword-3.0.2/debian/patches/series 
abiword-3.0.2/debian/patches/series
--- abiword-3.0.2/debian/patches/series 2020-04-02 14:46:29.0 +0200
+++ abiword-3.0.2/debian/patches/series 2020-04-14 15:21:47.0 +0200
@@ -11,3 +11,4 @@
 libical3.diff
 build-Don-t-check-for-libecal.patch
 git_build_fix.patch
+enchant2.patch

Bug#956709: libglom-1.30-0: upgrade of boost packages makes libglom-1.30-0 uninstallable

[Giacomo Mulas]

Package: libglom-1.30-0
Version: 1.30.4-6
Severity: grave
Justification: renders package unusable

Dear Maintainer,

the upgrade of libboost-python1.67.0 breaks a dependency of libglom-1.30-0,
thereby making it uninstallable.  To fix this, it must be rebuilt with the
new libraries _and_ with python 3.8 instead of 3.7.

Thanks in advance, best regards
Giacomo Mulas


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

Kernel: Linux 5.5.13-jak (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to it_IT.utf8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set 
to it_IT.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libglom-1.30-0 depends on:
ii  libarchive133.4.0-2
ii  libboost-python1.67.0 [libboost-python1.67.0-py37]  1.67.0-17
ii  libc6   2.30-4
ii  libepc-1.0-30.4.6-2
ii  libgcc-s1   10-20200411-1
ii  libgda-5.0-45.2.9-2
ii  libgdamm-5.0-13 4.99.11-3
ii  libgettextpo0   0.19.8.1-10
ii  libglib2.0-02.64.1-1
ii  libglibmm-2.4-1v5   2.64.2-1
ii  libpython3.83.8.2-1+b1
ii  libsigc++-2.0-0v5   2.10.2-1
ii  libstdc++6  10-20200411-1
ii  libxml++2.6-2v5 2.40.1-3
ii  libxml2 2.9.10+dfsg-5
ii  libxslt1.1  1.1.34-4

libglom-1.30-0 recommends no packages.

libglom-1.30-0 suggests no packages.

-- no debconf information

Bug#954922: python-azure: take over python3-azure-storage package from src:python-azure-storage

[Luca Boccassi]

Upload done and RM request file for src:python-azure-storage:

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

-- 
Kind regards,
Luca Boccassi


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

Bug#956311: libsqlite3-dev: length(BLOB) should not convert to unicode

[Troy]

The data in question was binary data, not unicode. It just happened to
contain some valid UTF-8 sequences. I am communicating with the db
through ODBC (64-bit), so I will have to look and see what is happening
exactly. I will have to add some workaround to make sure that the data
is added as a BLOB. 

Troy



On Sat, 2020-04-11 at 14:25 +0200, László Böszörményi (GCS) wrote:
> On Sat, Apr 11, 2020 at 1:56 PM Troy Korjuslommi
>  wrote:
> > Please note that in
> > https://www.sqlite.org/lang_corefunc.html#length
> > 
> > it says that "For a blob value X, length(X) returns the number of
> > bytes
> > in the blob."
>  Indeed, if that's a BLOB value. But as yourself noted: "when data is
> valid UTF-8, it returns the number of characters" which is in sync
> with the datatype notes[1]: "the datatype of a value is associated
> with the value itself, not with its container". It doesn't matter
> that
> you defined the column as BLOB. The mentioned string (type) will be
> passed to the length() function which say[2]: "returns the number of
> characters (not bytes) in X". It works as its documented like you
> confirm that in your original message: "it returns the number of
> characters, not bytes".
> You will get the same answer on the forum, this is how SQLite works
> and it's documented correctly. But you are free to ask there and feel
> free to report back here.
> 
> Regards,
> Laszlo/GCS
> [1] https://www.sqlite.org/datatype3.htm
> [2] https://www.sqlite.org/lang_corefunc.html#length

Bug#956708: New upstream release 1.4.0 available (with security fixes for SASL/SCRAM auth)

[Nicolas Dandrimont]

Package: src:librdkafka
Version: 1.3.0-1
Severity: important
Tags: patch security upstream

Dear maintainers,

Upstream for librdkafka has recently released version 1.4.0 of the library[1].

[1] https://github.com/edenhill/librdkafka/releases/tag/v1.4.0

The release notes mention that two security issues[2,3] in the way SASL/SCRAM
authentication was implemented. SASL/SCRAM was introduced in v0.11.0, and the
offending code was introduced at that point[4], so the security bug affects the
version in stable as well.

[2] 
https://github.com/edenhill/librdkafka/commit/9b468d2fafbdc23f2326e174a6bd92e70457ce6d
[3] 
https://github.com/edenhill/librdkafka/commit/8f7a4c858afc8ff24672426473448c3e0c56cfc3
[4] 
https://github.com/edenhill/librdkafka/blob/v0.11.0/src/rdkafka_sasl_scram.c 
lines 91
(nonce bug) and 340-341 (buffer overflow)

I guess these patches could be uploaded as a stable update (but I haven't looked
at older security fixes if some more would be relevant).

I've prepared the update for sid[5] and I can upload it if you'd like (I'm
currently using a package of a git checkout of a pre-1.4.0 commit in production,
and will update to 1.4.0 there anyway).

[5] https://salsa.debian.org/olasd/librdkafka branches debian/sid and 
pristine-tar

Thanks for your work!
Nicolas

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

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

Bug#956707: python-internetarchive doesn't close https connections

[kpcyrd]

Package: internetarchive
Version: 1.8.1-1+deb10u1
Severity: important

This is a bit of a follow up on #950289, I've retried uploading the folder and
ran out of file descriptors again, this time because the https connections
aren't closed.

The folder I'm testing with has ~10.000 files and fails midway.

Using lsof -nPi shows a large number of open connections in CLOSE_WAIT state:

[...]
ia  20254 user  469u  IPv4 99476489  0t0  TCP 
X.X.X.X:XXX->207.241.239.10:443 (CLOSE_WAIT)
ia  20254 user  470u  IPv4 99476491  0t0  TCP 
X.X.X.X:XXX->207.241.239.10:443 (CLOSE_WAIT)
ia  20254 user  471u  IPv4 99476522  0t0  TCP 
X.X.X.X:XXX->207.241.239.10:443 (CLOSE_WAIT)
ia  20254 user  472u  IPv4 99476528  0t0  TCP 
X.X.X.X:XXX->207.241.239.10:443 (CLOSE_WAIT)
ia  20254 user  473u  IPv4 99476553  0t0  TCP 
X.X.X.X:XXX:40406->207.241.239.10:443 (ESTABLISHED)

It eventually crashes with:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 321, 
in ssl_wrap_socket
OSError: [Errno 24] Too many open files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 
600, in urlopen
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 
343, in _make_request
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 
841, in _validate_conn
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 
344, in connect
  File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 323, 
in ssl_wrap_socket
urllib3.exceptions.SSLError: [Errno 24] Too many open files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 449, 
in send
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 
638, in urlopen
  File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 
398, in increment
urllib3.exceptions.MaxRetryError: 
HTTPSConnectionPool(host='s3.us.archive.org', port=443): Max retries exceeded 
with url: /redacted (Caused by SSLError(OSError(24, 'Too many open files')))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/ia", line 11, in 
  File "/usr/lib/python3/dist-packages/internetarchive/cli/ia.py", line 
159, in main
  File 
"/usr/lib/python3/dist-packages/internetarchive/cli/ia_upload.py", line 225, in 
main
  File 
"/usr/lib/python3/dist-packages/internetarchive/cli/ia_upload.py", line 86, in 
_upload_files
  File "/usr/lib/python3/dist-packages/internetarchive/item.py", line 
828, in upload
  File "/usr/lib/python3/dist-packages/internetarchive/item.py", line 
710, in upload_file
  File "/usr/lib/python3/dist-packages/internetarchive/session.py", 
line 370, in send
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 646, 
in send
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 514, 
in send
requests.exceptions.SSLError: 
HTTPSConnectionPool(host='s3.us.archive.org', port=443): Max retries exceeded 
with url: /redacted (Caused by SSLError(OSError(24, 'Too many open files')))

I'm currently short on time so I'm having trouble fully disecting this bug and
test if sid is also affected. I've reported it upstream to ask for assistance:

https://github.com/jjjake/internetarchive/issues/336

Bug#956706: RM: python-azure-storage -- ROM; binary package taken over by python-azure

[Luca Boccassi]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: python-modules-t...@lists.alioth.debian.org

Dear FTP Team,

As discussed by members of the Python Modules Team in:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954922
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954923
https://salsa.debian.org/python-team/modules/python-azure/-/merge_requests/3#note_144855
https://github.com/Azure/azure-storage-python/issues/655

We want to move the binary python3-azure-storage package from
src:python-azure-storage to src:python-azure.
The latter's version 20200130+git-3 is newer than the former's
20181109+git-2, so we will do a simple upload, no epochs required.

I believe an RM request is still necessary for the old source package,
but I might be wrong - filing one just in case.

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#950150: audacity: Wayland problem confirmed

[Keyikedalube Ndang]

Package: audacity
Followup-For: Bug #950150

Dear Maintainer,

I switched from GNOME to XFCE the other day and I happened to listen to
my old recording using audacity

The timeline cursor works fine under X11
Wayland is the cause...

Regards,
Keyikedalube

-- 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.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IN.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 audacity depends on:
ii  audacity-data 2.3.3-1
ii  libasound21.2.2-2.1
ii  libavcodec58  7:4.2.2-1+b1
ii  libavformat58 7:4.2.2-1+b1
ii  libavutil56   7:4.2.2-1+b1
ii  libc6 2.30-4
ii  libexpat1 2.2.9-1
ii  libflac++6v5  1.3.3-1
ii  libflac8  1.3.3-1
ii  libgcc-s1 [libgcc1]   10-20200324-1
ii  libgcc1   1:10-20200324-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-3
ii  libglib2.0-0  2.64.1-1
ii  libgtk-3-03.24.18-1
ii  libid3tag00.15.1b-14
ii  liblilv-0-0   0.24.6-1
ii  libmad0   0.15.1b-10
ii  libmp3lame0   3.100-3
ii  libogg0   1.3.2-1+b1
ii  libportaudio2 19.6.0-1
ii  libportsmf0   0.1~svn20101010-5
ii  libsndfile1   1.0.28-7
ii  libsoundtouch12.1.2+ds1-1
ii  libsoxr0  0.1.3-2
ii  libstdc++610-20200324-1
ii  libsuil-0-0   0.10.6-1
ii  libtwolame0   0.4.0-2
ii  libvamp-hostsdk3v52.9.0-1
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libvorbisfile31.3.6-2
ii  libwxbase3.0-0v5  3.0.4+dfsg-15
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-15

audacity recommends no packages.

Versions of packages audacity suggests:
ii  swh-plugins [ladspa-plugin]  0.4.17-2

-- no debconf information

Bug#956698: lintian: package-from-other-python-variant exception: python-pip-whl

[Scott Kitterman]

On Tuesday, April 14, 2020 9:22:37 AM EDT Mattia Rizzolo wrote:
> On Tue, Apr 14, 2020 at 08:41:01AM -0400, Scott Kitterman wrote:
> > The package python-pip-whl is a special case of a Python package built
> > to work with either python or python3.  Currently python3-vertualenv
> > gets the following lintian warning:
> > 
> > W: python3-virtualenv:
> > python-package-depends-on-package-from-other-python-variant Depends:
> > python-pip-whl
> > 
> > While this is a great warning in general, in this case it's wrong.
> > Would it be OK to special case python-pip-whl and have it not trigger
> > this check?
> 
> I would wager that this is the exact use case for an override?

I've added on for python3-virtualenv pointing to this bug.  If that's the 
preference of the lintian maintainers, I have no objection, please close the 
bug and we have it documented why it's an override.

Scott K

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

Bug#956705: ITP: python-pydiscourse -- Python library for working with Discourse

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 

* Package name: python-pydiscourse
  Version : v1.0.0
  Upstream Author : Marc Sibson and contributors 

* URL : https://github.com/bennylope/pydiscourse
* License : MIT
  Programming Lang: Python
  Description : Python library for working with Discourse

>From the README:

> A Python library for working with Discourse.
> 
> This is a fork of the original Tindie version. It was forked
> to include fixes, additional functionality, and to distribute
> a package on PyPI.
>
> Goals
>
> * Exceptional documentation
> * Support all supported Python versions
> * Provide functional parity with the Discourse API, for the
>   currently supported version of Discourse (something of a
>   moving target)
>
> The order here is important. The Discourse API is itself
> poorly documented so the level of documentation in the Python
> client is critical.

Bug#837346:

[Đạt Trần]

Bug#956665: libdrm2: Update broke firefox WebGL

[Timo Aaltonen]

Timo Aaltonen kirjoitti 14.4.2020 klo 10.34:
> On 14.4.2020 8.03, Fabian Inostroza wrote:
>> Package: libdrm2
>> Version: 2.4.101-1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> After updating libdrm2 from 2.4.100-4 to 2.4.101-1 WebGL stopped working on
>> firefox (using esr from repos and tar from mozilla).
>>
>> After loading a WebGL sample from webglsamples.org the following is message 
>> is
>> shown in the web console:
>> Error: WebGL warning: : Failed to create WebGL context: WebGL 
>> creation failed: 
>> * tryNativeGL
>> * Exhausted GL driver options.
>>
>> and in the terminal where firefox was launched:
>> libGL error: MESA-LOADER: failed to retrieve device information
>> libGL error: Version 4 or later of flush extension not found
>> libGL error: failed to load driver: i915
>> libGL error: MESA-LOADER: failed to retrieve device information
> 
> Probably the same as this upstream bug
> 
> https://gitlab.freedesktop.org/mesa/drm/-/issues/39
> 
> could you test this patch if it helps:
> 
> https://716574.bugs.gentoo.org/attachment.cgi?id=632372

Nevermind, I've tested it myself and it works.