Bug#964063: Mention Linux in "Running Mumble" section

2020-06-30 Thread Chris Knadle
積丹尼 Dan Jacobson:
> Package: mumble
> Version: 1.3.0+dfsg-1+b2
> Severity: wishlist
> File: /usr/share/doc/mumble/README
> 
> We read
> 
>Running Mumble
>==
> 
>On Windows, after installation, you should have a new Mumble folder in your
>Start Menu, from which you can start Mumble.
> 
>On Mac OS X, to install Mumble, drag the application from the downloaded
>disk image into your /Applications folder.
> 
> Wait, what about Linux?!
> 
>Once Mumble is launched, you need a server to connect to. Either create 
> your
>own or join a friend's.
> 
>Running Murmur on Unix-like systems
>===
> 
> Oh, there's the Linux section. But wait, now it is talking about Murmur!
> 
> Yes, there is a separate /usr/share/doc/mumble/README.Linux but that is
> besides the point, and a different story.

The README and README.Linux files in the 'mumble' package in Debian come
directly from the upstream Mumble release tarball.  A good way of suggesting
specific changes would be to open an issue upstream:

   https://github.com/mumble-voip/mumble/issues

As best I can tell there is no open issue concerning the README about mentioning
Linux right now.  If you decide to open an issue upstream, please mention Debian
bug #964063 so that the bugs get linked.

Thanks

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us



Bug#964069: transition: adplug

2020-06-30 Thread Yangfl
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

adplug uses a versioned soname. Packages which should only require binNMU:

  adplay
  mpd
  ocp

https://release.debian.org/transitions/html/auto-adplug.html



Bug#883245: Thunderbird: Fail to open URI in configured web browser

2020-06-30 Thread Jesus Eguiluz

Hi,

Me again, this time the result is the same I can't open links from 
thunderbird, but the error is diferent, Here are the log.


-- Logs begin at Wed 2020-04-22 18:47:35 -04. --
jun 30 23:50:00 gsus-solydx audit[59906]: AVC apparmor="DENIED" 
operation="file_mmap" profile="thunderbird//sanitized_helper" 
name="/home/gsus/.nv/.glIPX6D1" pid=59906 comm="firefox-esr" 
requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
jun 30 23:50:00 gsus-solydx kernel: audit: type=1400 
audit(1593575400.077:205): apparmor="DENIED" operation="file_mmap" 
profile="thunderbird//sanitized_helper" name="/tmp/.glqmbpH1" pid=59906 
comm="firefox-esr" requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
jun 30 23:50:00 gsus-solydx kernel: audit: type=1400 
audit(1593575400.077:206): apparmor="DENIED" operation="file_mmap" 
profile="thunderbird//sanitized_helper" name="/tmp/.glqmbpH1" pid=59906 
comm="firefox-esr" requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
jun 30 23:50:00 gsus-solydx kernel: audit: type=1400 
audit(1593575400.077:207): apparmor="DENIED" operation="file_mmap" 
profile="thunderbird//sanitized_helper" name="/home/gsus/.nv/.glIPX6D1" 
pid=59906 comm="firefox-esr" requested_mask="m" denied_mask="m" 
fsuid=1000 ouid=1000
jun 30 23:50:00 gsus-solydx kernel: audit: type=1400 
audit(1593575400.077:208): apparmor="DENIED" operation="file_mmap" 
profile="thunderbird//sanitized_helper" name="/home/gsus/.nv/.glIPX6D1" 
pid=59906 comm="firefox-esr" requested_mask="m" denied_mask="m" 
fsuid=1000 ouid=1000
jun 30 23:50:01 gsus-solydx audit[59903]: AVC apparmor="DENIED" 
operation="capable" profile="thunderbird//sanitized_helper" pid=59903 
comm=495043204C61756E6368202331 capability=21 capname="sys_admin"
jun 30 23:50:01 gsus-solydx kernel: audit: type=1400 
audit(1593575401.367:209): apparmor="DENIED" operation="capable" 
profile="thunderbird//sanitized_helper" pid=59903 
comm=495043204C61756E6368202331 capability=21 capname="sys_admin"


Regards

Jesus Eguiluz



Bug#960974: buster-pu: package postfix/3.4.14-0+deb10u1

2020-06-30 Thread Scott Kitterman
On Tuesday, June 30, 2020 12:26:01 PM EDT Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2020-06-29 at 21:42 -0400, Scott Kitterman wrote:
> > In the 6 weeks since this request was originally filed, there have
> > been two  more postfix bugfix releases.  I'd like to upload 3.4.14
> > instead.  I'm attaching two debdiffs:
> > 
> > stable.debdiff is the diff from what's currently in stable.
> > update.debdiff is the change from the original request in May.
> > 
> > Given the upcoming point release, I really would like to get this in
> > now.
> 
> Sorry for the delay. Please go ahead.

Thanks.  Just did the dput.  Should be available shortly for review/accept.

Scott K

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


Bug#964068: libpocketsphinx3: Recommends: packages that only exist in jessie (old-oldstable)

2020-06-30 Thread Andrei POPESCU
Package: libpocketsphinx3
Version: 0.8+5prealpha+1-11
Severity: normal

Dear Maintainer,

As per below info included by reportbug, libpocketsphinx3 recommends 
several other packages.

According to https://packages.debian.org these only exist in jessie 
(old-oldstable).

Kind regards,
Andrei


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

Kernel: Linux 5.6.0-0.bpo.2-arm64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libpocketsphinx3 depends on:
ii  libc6   2.30-8
ii  libsphinxbase3  0.8+5prealpha+1-10+b1

Versions of packages libpocketsphinx3 recommends:
pn  pocketsphinx-hmm-en-hub4wsj | pocketsphinx-hmm-zh-tdt | pocketsphin  
pn  pocketsphinx-lm-en-hub4 | pocketsphinx-lm-zh-hans-gigatdt | pockets  

libpocketsphinx3 suggests no packages.

-- no debconf information



Bug#964067: date --date='Second xxxxxxxx' logic

2020-06-30 Thread bryan
Package: coreutils

Version: 8.30-3

 

When date with the --date='Second ' argument is invoked it returns
the first occurrence of the day + 1 second.

This is different from the First and Third logic shown in the following
example.

 

$ date

Wed  1 Jul 13:23:09 AEST 2020

 

$ date --date='First Monday'

Mon  6 Jul 00:00:00 AEST 2020

 

$ date --date='Second Monday'

Mon  6 Jul 00:00:01 AEST 2020

 

$ date --date='Third Monday'

Mon 20 Jul 00:00:00 AEST 2020

 

I'd suggest the output should be Mon 13 Jul in this example.

 

$ uname -a

4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64
GNU/Linux

 



Bug#960073: Package:python-pyqt5 Run the example code with Trace and crash (SIGABRT)【请注意,邮件由mity...@gmail.com代发】

2020-06-30 Thread pengzon...@uniontech.com
Hi!

Some information on this, it look like  the same issue as #963709.

(gdb) r PnsAppWebX.py 
Starting program: /usr/bin/python PnsAppWebX.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
[New Thread 0xe6bc41e0 (LWP 21532)]
Could not initialize GLX

Thread 1 "python" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: 没有那个文件或目录.
(gdb) b libglxmapping.c:432
No source file named libglxmapping.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (libglxmapping.c:432) pending.
(gdb) p vendor->dlhandle
No symbol "vendor" in current context.
(gdb) p (char *)dlerror()
$1 = 0xab233500 "/lib/aarch64-linux-gnu/libglapi.so.0: cannot allocate 
memory in static TLS block"
(gdb) 

Now, is this the only  way we can fix this issue?and is there any way to fix 
this issue fundamentally?
Thank you for letting me know.

BRs
//Zongli


Bug#961981: linux-image-5.6.0-2-amd64: BUG: Bad page state in process alsa-sink-ALC89 pfn:816801

2020-06-30 Thread Ryan Thoryk
I actually had a similar crash on my system, and it apparently was due
to bad RAM modules which I've now taken out.  I'll be trying to
stress-test the system to see if it's stable now.

Test yours first with something like memtest86+.  I was able to identify
2 separate bad memory modules with that, which was surprising to me.
The Debian version of memtest86+ didn't work for me (froze during run)
so I had to download from the www.memtest.org website and that one worked.

My system had a kernel panic during a null pointer dereference in
relation to a bad page.

-- 
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net



Bug#964066: aftest: bugs.aff: Invalid argument in hurd-i386

2020-06-30 Thread Joao Eriberto Mota Filho
Source: afflib
Version: 3.7.18-8
Severity: normal
Tags: upstream
Control: forwarded -1 https://github.com/sshock/AFFLIBv3/issues/42

afflib FTBFS in hurd-i386 as shown below:

running all tests with -a option (exception bigfile test)
foo.000=>foo.001
foo.100=>foo.101
bizmark.999=>bizmark.A00
nutter.A99=>nutter.A9A
bizmark.AZZ=>bizmark.B00
glutten.afj=>glutten.afk
aftest: bugs.aff: Invalid argument
FAIL aftest (exit status: 1)


Testsuite summary for AFFLIB 3.7.18

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

Eriberto


afflib_3.7.18-8_hurd-i386.build.gz
Description: application/gzip


Bug#964065: afflib: affsign -k: segmentation fault in s390x, ppc64 and sparc64

2020-06-30 Thread Joao Eriberto Mota Filho
Source: afflib
Version: 3.7.18-8
Severity: normal
Tags: upstream
Control: forwarded -1 https://github.com/sshock/AFFLIBv3/issues/41

afflib FTBFS in s390x, ppc64 and sparc64 with segmentation fault as shown
below:

Signing AFF file...
affsign -k /tmp/basevP50b.agent.pem /tmp/basevP50b.evidence.aff
Segmentation fault
affsign failed
FAIL test_signing.sh (exit status: 1)


Testsuite summary for AFFLIB 3.7.18

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0


Running the command by hand in a s390x, I can see:

./affsign -k /tmp/basevP50b.agent.pem /tmp/basevP50b.evidence.aff
Signing segments...
Calculating BOM for segment badflag...   
Calculating BOM for segment badsectors...   
Calculating BOM for segment afflib_version...   
Calculating BOM for segment aff_file_type...   
Calculating BOM for segment acquisition_commandline...   
Calculating BOM for segment pagesize...   
Calculating BOM for segment sectorsize...   
Calculating BOM for segment page0...   
Calculating BOM for segment page1...   
Segmentation fault

Eriberto


afflib-logs.tar.gz
Description: application/gzip


Bug#964064: python3-pyqt5: ImportError when from PyQt5 import QtGui

2020-06-30 Thread zhaofeng
Package: python3-pyqt5
Version: 5.15.0+dfsg-1
Severity: important

Dear Maintainer,


Running `python3 -c "from PyQt5 import QtGui"` throws importError, says
libQt5Core.so not found.

To reproduce this error:

root@c208a4fd881c:~/ete/ete# python3
Python 3.8.3 (default, May 14 2020, 11:03:12) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from PyQt5 import QtGui
Traceback (most recent call last):
  File "", line 1, in 
ImportError: libQt5Core.so.5: cannot open shared object file: No such file or 
directory


The file `/usr/lib/x86_64-linux-gnu/libQt5Core.so.5` exists on the
system.

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

Kernel: Linux 3.10.0-957.1.3.el7.x86_64 (SMP w/56 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages python3-pyqt5 depends on:
ii  libc6 2.30-8
ii  libgcc-s1 10.1.0-4
ii  libpython3.8  3.8.3-1
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-10+b1
ii  libqt5dbus5   5.12.5+dfsg-10+b1
ii  libqt5designer5   5.12.5-2+b2
ii  libqt5gui55.12.5+dfsg-10+b1
ii  libqt5help5   5.12.5-2+b2
ii  libqt5network55.12.5+dfsg-10+b1
ii  libqt5printsupport5   5.12.5+dfsg-10+b1
ii  libqt5test5   5.12.5+dfsg-10+b1
ii  libqt5widgets55.12.5+dfsg-10+b1
ii  libqt5xml55.12.5+dfsg-10+b1
ii  libstdc++610.1.0-4
ii  python3   3.8.2-3
ii  python3-sip [sip-py3api-12.7] 4.19.23+dfsg-1

python3-pyqt5 recommends no packages.

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

-- no debconf information



Bug#944829: ITP: materia-kde -- Port of the Materia theme to KDE Plasma 5

2020-06-30 Thread Leandro Cunha
Package: wnpp
Severity: wishlist
Owner: James Lu 

* Package name: materia-kde
  Version : 20200614
  Upstream Author : Alexey Varfolomeev 
* URL : https://github.com/PapirusDevelopmentTeam/materia-kde
* License : GPL-3
  Programming Lang: CSS
  Description : Port of the Materia theme to KDE Plasma 5


I will study to create this package for Plasma and Debian, although
maintainer Sagar Ippalpalli maintains the materia-gtk-theme which can be
accessed at https://tracker.debian.org/pkg/materia-gtk-theme.

Greetings,

Leandro Cunha


Bug#964063: Mention Linux in "Running Mumble" section

2020-06-30 Thread 積丹尼 Dan Jacobson
Package: mumble
Version: 1.3.0+dfsg-1+b2
Severity: wishlist
File: /usr/share/doc/mumble/README

We read

   Running Mumble
   ==

   On Windows, after installation, you should have a new Mumble folder in your
   Start Menu, from which you can start Mumble.

   On Mac OS X, to install Mumble, drag the application from the downloaded
   disk image into your /Applications folder.

Wait, what about Linux?!

   Once Mumble is launched, you need a server to connect to. Either create your
   own or join a friend's.

   Running Murmur on Unix-like systems
   ===

Oh, there's the Linux section. But wait, now it is talking about Murmur!

Yes, there is a separate /usr/share/doc/mumble/README.Linux but that is
besides the point, and a different story.



Bug#956195: buster-pu: package cloud-init/18.3-6+deb10u1

2020-06-30 Thread Noah Meyerhans
On Sun, Apr 12, 2020 at 10:13:34PM +0100, Adam D. Barratt wrote:
> > As discussed in #947351, this is a more targeted fix prepared for
> > buster-pu. The updated debdiff is attached.
> 
> The metadata for #936030 implies that this issue affects the package in
> unstable. Is that correct? If not, please add an appropriate fixed
> version to that bug to more accurately indicate which versions are
> affected.

I just updated the larger cloud-init buster-pu request in #947351.
Let's leave this one alone for now; If we get cloud-init updated to 20.2
in buster then we won't need it.

noah



Bug#963607: [Pkg-xen-devel] Bug#963607: xen-hypervisor-4.11-amd64: Xen Hypervisor kernel fails to load arcmsr module with "arcmsr0: dma_alloc_coherent got error" message.

2020-06-30 Thread Hans van Kranenburg
Hi,

On 6/25/20 1:44 PM, Alex Sanderson wrote:
> 
> Hi Hans,
> 
> Thank you for your assistance with this.  I hesitated to log this with
> xen-dev but thought I should wait for a response here first. 
> 
> 
> On 25/06/2020 01:30, Hans van Kranenburg wrote:
>> Hi Alex,
>>
>> On 6/24/20 12:31 PM, Alex Sanderson wrote:
>>> Package: xen-hypervisor-4.11-amd64
>>> Version: 4.11.3+24-g14b62ab3e5-1~deb10u1
>>> Severity: important
>>>
>>> Dear Maintainer,
>>>
>>> After updating to Buster and Xen 4.11 our machine no longer boots the Xen 
>>> kernel.  The default kernel 4.19.118-2+deb10u1 boots normally.
>> When booting with Xen, the computer first starts the Xen hypervisor
>> code. This is the part where you see all the lines with (XEN) at the
>> beginning appear.
>>
>> Afterwards, it starts the same 4.19.118-2+deb10u1 Linux kernel that is
>> used when running without Xen, but it's started as the first virtual
>> machine, that has extra privileges to access all hardware.
>>
>> So, Linux vs. Xen + Linux.
>>
>>> The machine has an Areca 1882IX-16 card in it when the arcmsr module
>>> tries to load the following error appears. 
>>>
>>> Areca RAID Controller0: Model ARC-1882, F/W V1.56 2019-07-30
>>> arcmsr0: dma_alloc_coherent got error
>>>
>>> No drives are discovered and the initramfs prompt is shown.
>> Ok, so booting the Xen part succeeded, but apparently, when starting the
>> Linux kernel inside, there's apparently a problem with accessing the
>> raid controller hardware. Interesting.
>>
>> This likely means it's not a problem in the Debian packaging part, it's
>> a problem somewhere in the upstream Xen or Linux code. That means that I
>> cannot solve this for you, but I can help with tips to gather the right
>> information, and help finding out what the best place is where we can
>> report the issue.
>>
>>> The machine:
>>>  * Supermicro X9DRW 
>>>  * Dual Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz
>>>  * 128G RAM
>>>  * Areca ARC-1882IX-16 (1G onboard cache)
>>>
>>> Nothing I have tried is effective:
>>>  * Turning on BIOS above 4G decoding stops the Intel 10GBE ixgbe driver 
>>> from functioning and doesn't fix the arcmsr
>>>  * Unloading and reloading the arcmsr module from initramfs prompt
>>>  * Downgrading the Areca 1882 bios to v1.52 as per 
>>> http://faq.areca.com.tw/index.php?action=artikel=7=902=en
>>>  * Kernel parameters
>>>  ** pci=nocrs 
>>>  ** dom0_mem=8G 
>>>  ** mem=3072M
>>>  ** mem2048M cma=1024M
>>>  ** cma=2048
>>>  ** cma=3076@512M
>>>  ** iommu=1 intel_iommu=1 
>>>  ** arcmsr.host_can_queue=64 as per 
>>> http://faq.areca.com.tw/index.php?action=artikel=15=387=en
>>>
>>> I expected the arcmsr module to load and detect disks as it does with
>>> the stock kernel.
>>>
>>> I can provide sysctl and dmesg output if it helps.
>> Yes. The first thing needed is full startup logs, and for the Xen part
>> preferably extra logging. In /etc/default/grub.d/xen.cfg in the
>> GRUB_CMDLINE_XEN_DEFAULT setting, you can add loglvl=all, and then run
>> update-grub and try to boot Xen+Linux again.
>>
>> Do you have a way to capture the logging during boot? Like, a working
>> serial console or something similar?
>>
>> The output of dmesg when starting Linux without Xen is of course also
>> interesting, so we can compare both scenarios.
>>
>> Hans
> 
> I tried using debian's paste https://paste.debian.net but it always
> thought it was spam.
> 
> dmesg output Xen Hypervisor 4.11 https://pastebin.com/3wUyYg0P

This one shows a Linux kernel boot, not the Xen Hypervisor, which should
go first (with all the (XEN) lines). By default the Xen output should
show up on your (serial) console. If you do dmesg after starting Linux
as dom0 after starting Xen, then you just get the Linux part of it.

If it actually boots and it's usable to login and get a shell prompt
etc, then you can immediately use xl dmesg to see the xen part, and if
it doesn't, then you need to make sure you have some sort of serial
console to capture the lines.

To do a bug report upstream, we'll need that information.

> dmesg output Debian Kernel 4.19.118-2+deb10u1 https://pastebin.com/GHzzW3vi

K



Bug#964062: libfplll-dev:amd64: missing static library libfplll.a

2020-06-30 Thread Vincent Lefevre
Package: libfplll-dev
Version: 5.3.2-1
Severity: important

The static library libfplll.a is missing. This makes projects that
require static linking fail to build.

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

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

Versions of packages libfplll-dev:amd64 depends on:
ii  libfplll65.3.2-1
ii  libgmp-dev   2:6.2.0+dfsg-6
ii  libmpfr-dev  4.0.2-1

libfplll-dev:amd64 recommends no packages.

libfplll-dev:amd64 suggests no packages.

-- no debconf information

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



Bug#954872: buildd.debian.org: Legends for the graphs on https://buildd.debian.org/stats/ half-gone

2020-06-30 Thread Manuel A. Fernandez Montecelo

Hi,

2020-03-24 19:04 Aurelien Jarno:

On 2020-03-24 18:47, nabijaczleweli wrote:

Package: buildd.debian.org
Severity: normal

Hello,

The legends for the graphs on https://buildd.debian.org/stats/ seem to
be partway gone, mostly affecting the colour and start of the
architecture name.

See the attached graph.png, taken from the site as I write this.



This is a know issue, due to a change in the R packages in Debian
Buster. If someone has good knowledge of R, patches are welcome.


I tried to create a merge request in salsa but could not, for some reason.

I attach a patch that fixes this, at least when downloading the data and
generating the files locally with recent versions of the packages from
unstable.

But if not, it's easy to see how to further tweak the values, based on
the patch.

Hope that helps.


Cheers.
--
Manuel A. Fernandez Montecelo 

diff -ur a/graph-ports.R b/graph-ports.R
--- a/graph-ports.R	2020-07-01 01:01:59.514162160 +0200
+++ b/graph-ports.R	2020-07-01 01:02:18.706266654 +0200
@@ -19,7 +19,7 @@
 
 plotwb <- function (file,title,p,linept=85,height=7.5,width=10,pch=1:18) {
 	bitmap(file=file,type="png16m",width=width,height=height,res=64)
-	layout(matrix(c(1,1,2,2),2,2),widths=c(0.85,0.15))
+	layout(matrix(c(1,1,2,2),2,2),widths=c(0.80,0.20))
 	par(mar=c(5,4,4,2)+0.1) 
 	par(lab=c(10,10,7))
 	plot(p,type="o",plot.type="single",col=1:18,pch=pch,xlab="date",
@@ -29,7 +29,7 @@
 	axis(4)
 	plot.new()
 	par(plt=c(0,1,0,1))
-	legend(-1.2,1, arch, col=1:18, pch=pch, lwd=2, bg='gray90', cex=1.5)  
+	legend('topright', arch, col=1:18, pch=pch, lwd=2, bg='gray90', cex=1.5)  
 }
 v <- readdata("/srv/wanna-build/etc/graph-ports-data",1)
 plotwb("/srv/buildd.debian.org/web/stats/graph-ports.png","What percent is built for each architecture",v,85,7.5,10,".")
diff -ur a/graph.R b/graph.R
--- a/graph.R	2020-07-01 01:01:38.710048877 +0200
+++ b/graph.R	2020-07-01 01:03:00.938496574 +0200
@@ -35,7 +35,7 @@
 
 plotwb <- function (file,title,p,linept=85,height=7.5,width=10,pch=1:18) {
 	bitmap(file=file,type="png16m",width=width,height=height,res=64)
-	layout(matrix(c(1,1,2,2),2,2),widths=c(0.85,0.15))
+	layout(matrix(c(1,1,2,2),2,2),widths=c(0.715,0.285))
 	par(mar=c(5,4,4,2)+0.1) 
 	par(lab=c(10,10,7))
 	plot(p,type="o",plot.type="single",col=1:18,pch=pch,xlab="date",
@@ -45,7 +45,7 @@
 	axis(4)
 	plot.new()
 	par(plt=c(0,1,0,1))
-	legend(-1.2,1, arch, col=1:18, pch=pch, lwd=2, bg='gray90', cex=1.5)  
+	legend('topright', arch, col=1:18, pch=pch, lwd=2, bg='gray90', cex=1.5)  
 }
 v <- readdata("/srv/wanna-build/etc/graph-data",164)
 plotwb("/srv/buildd.debian.org/web/stats/graph.png","What percent is built for each architecture",v,85,7.5,10,".")


signature.asc
Description: PGP signature


Bug#964060: Homepage: link in d/control points to dead www.spamassassin.org

2020-06-30 Thread Noah Meyerhans
On Wed, Jul 01, 2020 at 12:43:27AM +0200, наб wrote:
> {www.,}spamassassin.org is dead with a broken certificate for
> {*.,}openoffice.org and shows openoffice.org when
> the broken certificate is ignored.

Thanks.  I wonder how long it's been broken.  www.spamassassin.org
should redirect to the canonical location, and indeed does if you access
via http.  I suspect that the certificate issue may be an accidental
server configuration error.  Will follow up with upstream about this
before merging your change.

noah



signature.asc
Description: PGP signature


Bug#964061: apt: bash-completions doesn't complete 'apt info'

2020-06-30 Thread Calum McConnell
Package: apt
Version: 2.1.6
Severity: minor
Tags: patch

Hey, so "apt info" is a perfectly valid use of apt AFAIK, but
bash doesnt autoclomplete package names if you use it.  I attached
a patch to fix this (at least I think I did: I might have screwed up
my reportbug usage)
It's minor, but a bit of a bother: for whatever reason, I like using
"apt info" rather than "apt show": it just makes more sense to me.

Thanks!
Calum


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-.*-4\.19\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-.*-5\.6\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-4\.19\.0-9-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-5\.6\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-4\.19\.0-9-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-5\.6\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-9-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.6\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-9-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.6\.0-2-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null || true; 
fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";

Bug#963784: qxw: New upstream release

2020-06-30 Thread calumlikesapplepie
> > There has been a new upstream release of qxw, which adds a host of
> > new features,
> > including unicode support and hex grids.  Please update the package
> > to provide it!
> 
> Hello Calum, thanks for the bug report.

No problem!

> As you will have seen, there is a Debian package for release 20190909
> available from my website. Unfortunately I was not able to find a
> sponsor to upload it to Debian, and the sponsor for the previous
> version is not replying to my e-mails.

If you haven't already, try emailing debian-devel/debian-mentor: I bet
in our current situation, there is some DD who is bored out of their
mind and willing to do an update

> If you know a DD who might be willing to act as a sponsor let me
> know.
> There is a new release imminent, just fixing a couple of bugs in
> 20190909 that people have found since its release. When the new
> release is ready - it takes a while as getting the Windows version
> ready takes some to-ing and fro-ing with the chap who does the
> port - I will reply to your message on the bug tracker.

Did you intentionnaly PM me, rather than cc bugs.debian.org? I cc'ed it
back on; hope you don't mind

> Mark.

Thanks
Calum



Bug#963995: uget: Crashes under XFCE when trying to sort on column "Added on"

2020-06-30 Thread Elías Alejandro
Hello,
Firstly thanks for your report.
I wasn't able to reproduce your bug. Could you please reproduce once again
but this time running Uget from the command line with uget-gtk and paste
the output from the terminal?

Thanks.

On Mon, Jun 29, 2020 at 5:57 PM waxhead  wrote:
>
> Package: uget
> Version: 2.2.3-1
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
>Tried to download some files..
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
>I clicked the "added on" column to sort my downloads. uGet just "exits" 
> without warning.
>My added downloads are not saved, and not resumable so the URL's have to 
> be added again.
>
>* What was the outcome of this action?
>
>I "lost data" e.g. I lost my added URL's.
>
>* What outcome did you expect instead?
>
>First of all that uGet should not crash, second that my URL's remains 
> saved so it would be resumeable.
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages uget depends on:
> ii  libc62.30-8
> ii  libcairo21.16.0-4
> ii  libcurl4 7.68.0-1
> ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
> ii  libglib2.0-0 2.64.3-1
> ii  libgstreamer1.0-01.16.2-2
> ii  libgtk-3-0   3.24.20-1
> ii  libnotify4   0.7.9-1
> ii  libpango-1.0-0   1.44.7-4
> ii  libpangocairo-1.0-0  1.44.7-4
> ii  libssl1.11.1.1g-1
>
> uget recommends no packages.
>
> uget suggests no packages.
>
> -- no debconf information



Bug#964054: [Pkg-net-snmp-devel] Bug#964054: net-snmp: Add (D)TLS support by default

2020-06-30 Thread Krishna Chaitanya
On Wed, 1 Jul, 2020, 3:57 am Craig Small,  wrote:

> On Wed, 1 Jul 2020 at 07:21, Krishna Chaitanya 
> wrote:
>
>> Default config of net-snmp already enable openSSL, so, it is just a
>> matter of adding
>> DTLS options to it for the latest version of 5.8 (5.7.3 version needs
>> a few patches).
>>
>
> Hi Krishna,
>   My understanding of the quick reading of the net-snmp setup is all we
> need to do to make this happen is to add
>   --with-transports="TLSTCP DTLSUDP" --with-security-modules="tsm"
>
> The default transports are UDP TCP Alias Unix and Callback while the
> default security modules are usm only.
>
> Does that sound right to you?
>
Yes, Craig. That is right, just having those enabled should work. And these
are in addition to the defaults.


Bug#964054: [Pkg-net-snmp-devel] Bug#964054: net-snmp: Add (D)TLS support by default

2020-06-30 Thread Craig Small
On Wed, 1 Jul 2020 at 07:21, Krishna Chaitanya 
wrote:

> Default config of net-snmp already enable openSSL, so, it is just a
> matter of adding
> DTLS options to it for the latest version of 5.8 (5.7.3 version needs
> a few patches).
>

Hi Krishna,
  My understanding of the quick reading of the net-snmp setup is all we
need to do to make this happen is to add
  --with-transports="TLSTCP DTLSUDP" --with-security-modules="tsm"

The default transports are UDP TCP Alias Unix and Callback while the
default security modules are usm only.

Does that sound right to you?

 - Craig


Bug#962223: affects and found fixed 962223 

2020-06-30 Thread Kramarenko A . Maksim
control: affects 962223 chrony
control: fixed 962223 refpolicy/2:2.20180701
thanks



Bug#962007: affects 962007

2020-06-30 Thread Kramarenko A . Maksim
control: affects 962007 openvpn
thanks



Bug#964059: RFS: streamlink/1.4.1+dfsg-2 -- CLI for extracting video streams from various websites to a video player

2020-06-30 Thread Alexis Murzeau
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "streamlink" to fix the bug
#963757.

 * Package name: streamlink
   Version : 1.4.1+dfsg-2
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.4.1+dfsg-2.dsc

Changes since the last upload to unstable:
streamlink (1.4.1+dfsg-2) unstable; urgency=medium

  [ Lukas Märdian ]
  * doc: adopt link target of font-awesome files (Closes: #963757)
- fonts-font-awesome 5.0.10+really4.7.0~dfsg-2 provides only OpenType
  and TrueType under /usr/share/fonts/

 -- Alexis Murzeau   Tue, 30 Jun 2020 23:55:57 +0200



Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F







signature.asc
Description: OpenPGP digital signature


Bug#964029: openvswitch-switch: ifupdown.sh logic error causes interfaces to be started whenever script is called

2020-06-30 Thread Michael Brown
Package: openvswitch-switch
Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2
Severity: important
Tags: patch

Dear Maintainer,

After upgrading from stretch to buster we noticed that our
previously-working openvswitch configurations would get stuck when
bringing up interfaces.

We discovered that attempting to manipulate an interface would cause an
inappropriate ifup command to be run and deadlock (since the child
process would wait for an interface state lock):

12938  \_ /bin/bash
13262  \_ sudo ifdown ovs1
13263  \_ ifdown ovs1
13293  \_ /bin/sh -c /bin/run-parts /etc/network/if-post-down.d
13294  \_ /bin/run-parts /etc/network/if-post-down.d
13297  \_ /bin/sh /etc/network/if-post-down.d/openvswitch
13318  \_ /bin/sh /etc/init.d/openvswitch-switch start
13365  \_ ifup --allow=ovs ovs1 ovs2

We tracked down the problem to the /usr/share/openvswitch/scripts/ifupdown.sh
script, specifically:


if [ -f $SERVICE_UNIT ] && [ -x /usr/bin/systemctl ]; then
if ! systemctl --quiet is-active openvswitch-nonetwork.service; then
systemctl start openvswitch-nonetwork.service
fi
else
if service openvswitch-switch status > /dev/null 2>&1; then
service openvswitch-switch start
fi
fi

the corresponding logic in the stretch package has the correct logic for the
"service openvswitch-switch start" line:

if /etc/init.d/openvswitch-switch status > /dev/null 2>&1; then :; else
/etc/init.d/openvswitch-switch start
fi

With this change, everything functions correctly:

--- /usr/share/openvswitch/scripts/ifupdown.sh.orig 2020-06-30 
17:51:41.033873946 +
+++ /usr/share/openvswitch/scripts/ifupdown.sh  2020-06-30 17:52:43.581180302 
+
@@ -35,7 +35,7 @@
 systemctl start openvswitch-nonetwork.service
 fi
 else
-if service openvswitch-switch status > /dev/null 2>&1; then
+if ! service openvswitch-switch status > /dev/null 2>&1; then
 service openvswitch-switch start
 fi
 fi


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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages openvswitch-switch depends on:
ii  kmod26-1
ii  lsb-base10.2019051400
ii  netbase 5.6
ii  openvswitch-common  2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2
ii  procps  2:3.3.15-2
ii  python  2.7.16-1
ii  uuid-runtime2.33.1-0.1

openvswitch-switch recommends no packages.

openvswitch-switch suggests no packages.

-- no debconf information



Bug#963560: main.pdf: openBinaryFile: does not exist

2020-06-30 Thread ael
On Tue, Jun 30, 2020 at 08:41:17PM +0200, Dirk Hünniger wrote:
> Hi,
> 
> I got something that looks Ok to me using
> 
> mediawiki2latex -u https://en.wikibooks.org/wiki/Haskell/Print_version -o
> Haskell.pdf -i

As I said, that seems to work. But I also tried for an epub version
adding the -b flag, and hit the 
   "openBinaryFile: does not exist"
problem again.

I can probably live without an epub version, but as a Debian package,
there are obviously problems.

ael



Bug#964056: Should ksh93 be removed?

2020-06-30 Thread Anuradha Weeraman
On Wed, Jul 01, 2020 at 12:40:17AM +0300, Adrian Bunk wrote:
> Package: ksh93
> Severity: serious
> 
> ksh (2020.0.0+really93u+20120801-6) unstable; urgency=high
> 
>   * v2020 of ksh is no longer being maintained and upstream repository has
> been reverted back to the last stable version of 93u+. This update
> reverts back the ksh2020 changes back to the original ksh93 from AT
> ...
>  -- Anuradha Weeraman   Sat, 27 Jun 2020 21:17:32 -0400
> 
> 
> The 2020 version of ksh was never part of any Debian distribution
> other than unstable, and this seems to make it obsolete.

#963858 is open with the ftp-master to have ksh93 removed.

-- 
Regards
Anuradha



Bug#937645: [Python-modules-team] Bug#937645: python-cjson: Python2 removal in sid/bullseye

2020-06-30 Thread Emmanuel Arias
Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El mar., 30 de jun. de 2020 a la(s) 17:51, Bernd Zeimetz
(b...@debian.org) escribió:
>
>
>
> On 6/30/20 10:41 PM, Moritz Mühlenhoff wrote:
> > There's no movement on https://github.com/AGProjects/python-cjson/issues/6
> > and at this point there are no reverse dependencies left, let's remove it?
+1 :)
>
> yes, good plan - I've filed a ROM removal bug.
>
>
> Bernd
>
>
> --
>  Bernd ZeimetzDebian GNU/Linux Developer
>  http://bzed.dehttp://www.debian.org
>  GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team



Bug#964058: ksh: Please drop debian/NEWS

2020-06-30 Thread Adrian Bunk
Package: ksh
Version: 2020.0.0+really93u+20120801-6
Severity: normal

Some users will actually be reading debian/NEWS on buster->bullseye
upgrades, these are supposed to be rare enought that this is possible.

Please drop these entries for a change and its revert that were never
in a stable release.



Bug#964057: ITP: readerwriterqueue -- single-producer, single-consumer lock-free queue for C++

2020-06-30 Thread Steffen Moeller
Package: wnpp
Severity: wishlist

Subject: ITP: readerwriterqueue -- single-producer, single-consumer lock-free 
queue for C++
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: readerwriterqueue
  Version : 1.0.2
  Upstream Author : Cameron Desrochers  
* URL : https://github.com/cameron314/readerwriterqueue
* License : BSD
  Programming Lang: C
  Description : single-producer, single-consumer lock-free queue for C++
 This package provides a lock-free queue  for C++.  It only supports
 a two-thread use case (one consuming, and one producing). The threads
 can't switch roles, though you could use this queue completely from a
 single thread if you wish (but that would sort of defeat the purpose!).
 .
 Features:
  * Blazing fast
  * Compatible with C++11 (supports moving objects instead of making
  copies)
  * Fully generic (templated container of any type) -- just like
std::queue, you never need to allocate memory for elements yourself
(which saves you the hassle of writing a lock-free memory manager
to hold the elements you're queueing)
  * Allocates memory up front, in contiguous blocks
  * Provides a try_enqueue method which is guaranteed never to allocate
memory (the queue starts with an initial capacity)
  * Also provides an enqueue method which can dynamically grow the size
of the queue as needed
  * Also provides try_emplace/emplace convenience methods
  * Has a blocking version with wait_dequeue
  * Completely "wait-free" (no compare-and-swap loop). Enqueue and
dequeue are always O(1) (not counting memory allocation)
  * On x86, the memory barriers compile down to no-ops, meaning enqueue
and dequeue are just a simple series of loads and stores (and
branches)

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/readerwriterqueue



Bug#964056: Should ksh93 be removed?

2020-06-30 Thread Adrian Bunk
Package: ksh93
Severity: serious

ksh (2020.0.0+really93u+20120801-6) unstable; urgency=high

  * v2020 of ksh is no longer being maintained and upstream repository has
been reverted back to the last stable version of 93u+. This update
reverts back the ksh2020 changes back to the original ksh93 from AT
...
 -- Anuradha Weeraman   Sat, 27 Jun 2020 21:17:32 -0400


The 2020 version of ksh was never part of any Debian distribution
other than unstable, and this seems to make it obsolete.



Bug#964054: net-snmp: Add (D)TLS support by default

2020-06-30 Thread Krishna Chaitanya
Package: net-snmp
Severity: wishlist

I have filed a bug against Ubuntu to add support for (D)TLS in the net-snmp
package, but they have asked me to file a bug in Debian first, I don't
have access
to the Debian system, so just sending an e-mail. (not sure

https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1880724

Default config of net-snmp already enable openSSL, so, it is just a
matter of adding
DTLS options to it for the latest version of 5.8 (5.7.3 version needs
a few patches).
-- 
Thanks,
Regards,
Chaitanya T K.



Bug#964055: hddemux: FTBFS: failed to query server

2020-06-30 Thread Niko Tyni
Source: hddemux
Version: 0.4-7
Severity: serious
Tags: ftbfs

This package fails to build on current sid.

>From my build log:


  Signing certificate...
  
  make knot-resolver configuration on 127.64.173.140:8853
  ---
  
  make hddeumx configuration on 127.64.173.140:2000
  -
  
  set up nginx on 127.64.173.140:4433
  ---
  
  test with kdig
  --
  [tls] RFC 7858 OOB key-pin (0): pin-sha256=""
  ;; WARNING: TLS, handshake failed (The TLS connection was non-properly 
terminated.)
  ;; ERROR: failed to query server 127.64.173.140@2000(TCP)
[...]
  ==> /tmp/tmp.M18miQDa2Y/hddemux.err <==
  Listening on 127.64.173.140:2000 as 3.
  Communication attempt on fd 3.
  Execing ./hddemux (./hddemux)
  [0] closing due to outbound read error: (-104): connection reset by peer
  
  ==> /tmp/tmp.M18miQDa2Y/kresd.err <==
  Listening on 127.64.173.140:8853 as 3.
  Communication attempt on fd 3.
  Execing /usr/sbin/kresd (/usr/sbin/kresd -c /tmp/tmp.M18miQDa2Y/kresd.conf 
/tmp/tmp.M18miQDa2Y)
  [system] bind to '127.0.0.1@53' (UDP): Permission denied
  [system] error while loading config: 
/usr/lib/x86_64-linux-gnu/knot-resolver/postconfig.lua:34: bind to 127.0.0.1@53 
error occured here (config filename:lineno is at the bottom, if config is 
involved):
  stack traceback:
[C]: at 0x0040cdf0
[C]: in function 'pcall'
/usr/lib/x86_64-linux-gnu/knot-resolver/postconfig.lua:32: in main chunk
  ERROR: net.listen() failed to bind (workdir '/tmp/tmp.M18miQDa2Y')
  
  ==> /tmp/tmp.M18miQDa2Y/nginx.err <==
  nginx: [alert] could not open error log file: open() 
"/var/log/nginx/error.log" failed (13: Permission denied)
  ./testsuite: line 56: kill: (4020973) - No such process
  cleaning up working directory /tmp/tmp.M18miQDa2Y
  make[1]: *** [Makefile:13: check] Error 1
  make[1]: Leaving directory '/<>'
  dh_auto_test: error: make -j4 check returned exit code 2
  make: *** [debian/rules:10: binary] Error 25
  
-- 
Niko Tyni   nt...@debian.org



Bug#963560: main.pdf: openBinaryFile: does not exist

2020-06-30 Thread ael
On Tue, Jun 30, 2020 at 08:41:17PM +0200, Dirk Hünniger wrote:
> Hi,
> 
> I got something that looks Ok to me using
> 
> mediawiki2latex -u https://en.wikibooks.org/wiki/Haskell/Print_version -o
> Haskell.pdf -i

Indeed: that seems to give a good copy. Thanks.

ael



Bug#964053: haskell-diagrams-gtk: FTBFS: Encountered missing or private dependencies

2020-06-30 Thread Niko Tyni
Source: haskell-diagrams-gtk
Version: 1.4-6
Severity: serious
Tags: ftbfs

This package fails to build on current sid.

>From my build log:

  Configuring diagrams-gtk-1.4...
  CallStack (from HasCallStack):
die', called at 
libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:1022:20 in 
Cabal-3.0.1.0:Distribution.Simple.Configure
configureFinalizedPackage, called at 
libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:475:12 in 
Cabal-3.0.1.0:Distribution.Simple.Configure
configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:625:20 in 
Cabal-3.0.1.0:Distribution.Simple
confHook, called at 
libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:65:5 in 
Cabal-3.0.1.0:Distribution.Simple.UserHooks
configureAction, called at 
libraries/Cabal/Cabal/Distribution/Simple.hs:180:19 in 
Cabal-3.0.1.0:Distribution.Simple
defaultMainHelper, called at 
libraries/Cabal/Cabal/Distribution/Simple.hs:116:27 in 
Cabal-3.0.1.0:Distribution.Simple
defaultMain, called at Setup.hs:2:8 in main:Main
  hlibrary.setup: Encountered missing or private dependencies:
  base >=4.2 && <4.13
  
  make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
Error 1
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2
 
-- 
Niko Tyni   nt...@debian.org



Bug#964042: [pkg-go] Bug#964042: gitaly: FTBFS: 'go install' fails

2020-06-30 Thread Pirate Praveen



On 2020, ജൂലൈ 1 1:57:21 AM IST, Niko Tyni  wrote:
>Source: gitaly
>Version: 1.78.0+dfsg-2
>Severity: serious
>Tags: ftbfs
>
>This package fails to build on current sid.

The version in experimental works, but it is blocked by rails 6 transition.

Around first week of August, we plan to upload rails 6 to unstable and gitaly 
in experimental will be reuploaded to unstable at that time.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Bug#938314: qpid-python: Python2 removal in sid/bullseye

2020-06-30 Thread Moritz Mühlenhoff
On Sun, Jun 28, 2020 at 08:35:14AM +0200, László Böszörményi (GCS) wrote:
> Control: severity -1 normal
> Control: reassign -1 ftp.debian.org
> Control: retitle -1 RM: qpid-python -- RoM; deprecated upstream, no
> reverse-dependencies
> 
> On Tue, Jun 9, 2020 at 8:00 PM Moritz Mühlenhoff  wrote:
> > On Fri, Aug 30, 2019 at 07:49:29AM +, Matthias Klose wrote:
> > http://qpid.apache.org/releases/qpid-python-1.37.0/index.html states
> > that qpid python only supports Python 2 and
> >
> > "NOTE: Look to Qpid Proton for Python 3 and AMQP 1.0 support."
> >
> > Given that src:qpid-proton is packaged separately and that no
> > reverse deps exist for python-qpid, let's remove? (Along with
> > python-qpid-extras-qmf)
>  Indeed, it should have been removed already.

I've also just filed an RM bug for python-qpid-extras-qmf.

Cheers,
Moritz



Bug#964051: RM: python-cjson -- ROM; python3 support missing, upstream MIA since a long time

2020-06-30 Thread Bernd Zeimetz
Package: ftp.debian.org
Severity: normal


Thanks,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Bug#964052: RM: qpid-qmf -- RoQA; Obsolete, depends on Python 2

2020-06-30 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove qpid-qmf. It depends on Python 2 and there are no reverse
deps (related to 938314).

Cheers,
Moritz



Bug#964031: src:viking: New version 1.8 available; offer to help maintain viking

2020-06-30 Thread Bernd Zeimetz
Hi Paul,

> I'm a user of viking and today I learned viking is no longer in bullseye
> due to build dependency issues. However, a new upstream version is
> available and bug #947541 points at a patch (that seems to be applied on
> top of 1.8 by the looks of the date).
> 
> Is there anything blocking updating viking such that it can be part of
> bullseye again? If it's merrily time, I am willing to help maintain viking.

basically: missing time is blocking it.

Packaging is in the Debian group on Salsa:

https://salsa.debian.org/debian/viking

so you should have access - please just do whatever is necessary if you
have the time.

Thanks,

Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Bug#964050: lsof.8: fix some formatting and typographic issues

2020-06-30 Thread Bjarni Ingi Gislason
Package: lsof
Version: 4.93.2+dfsg-1
Severity: minor
Tags: patch

Dear Maintainer,

  fixes for some formatting and typographic issues.

  Input file is "Lsof.8" (from the git repository on
"github.com/lsof-org/lsof.git").

###

  Output from "mandoc -Tlint":

mandoc: Lsof.8:704:2: ERROR: skipping unknown macro: ...`` -> 
\fIPID,cmd,FDmode\fP'' ..., where

mandoc: Lsof.8:944:5: ERROR: skipping all arguments: br or 
\fBUDPLITE\fP.

mandoc: Lsof.8:945:2: WARNING: skipping paragraph macro: br after br
mandoc: Lsof.8:3454:2: WARNING: skipping paragraph macro: PP after SH
mandoc: Lsof.8:3623:2: WARNING: skipping paragraph macro: PP empty
mandoc: Lsof.8:3525:2: WARNING: skipping paragraph macro: PP after SH
mandoc: Lsof.8:3630:2: WARNING: skipping paragraph macro: PP after SH
mandoc: Lsof.8:3702:2: WARNING: skipping paragraph macro: PP after SH
mandoc: Lsof.8:3797:2: WARNING: skipping paragraph macro: PP after SH
mandoc: Lsof.8:3870:2: WARNING: skipping paragraph macro: PP after SH
mandoc: Lsof.8:3964:2: WARNING: skipping paragraph macro: PP after SH
mandoc: Lsof.8:3990:2: WARNING: skipping paragraph macro: PP after SH
mandoc: Lsof.8:4022:2: WARNING: skipping paragraph macro: PP after SH
mandoc: Lsof.8:4091:2: WARNING: skipping paragraph macro: PP after SH
mandoc: Lsof.8:4162:2: WARNING: skipping paragraph macro: PP empty
mandoc: Lsof.8:4480:2: WARNING: skipping paragraph macro: PP after SH

###

Test nr. 2:

Enable and fix warnings from 'test-groff'.


Output is from: test-groff -b -mandoc -T utf8 -rF0 -t -w w -z

  [ "test-groff" is a developmental version of "groff" ]

:609 (macro IR): only 1 argument, but more are expected
troff: :704: warning: macro '..``' not defined
troff: :926: warning: trailing space
:995 (macro BR): only 1 argument, but more are expected
:996 (macro BR): only 1 argument, but more are expected
:1275 (macro BI): only 1 argument, but more are expected
:1838 (macro BR): only 1 argument, but more are expected


Test nr. 5:

Change '-' (\-) to '\(en' (en-dash) for a numeric range.

Lsof.8:416:member is larger than the starting one \- e.g., ``0-7'' or ``3-10''.
Lsof.8:418:e.g., ``^0-7'' excludes all file descriptors 0 through 7.
Lsof.8:1051:tcp@foo:1-10,smtp,99 \- TCP, ports 1 through 10,

#

Test nr. 8:

Mark a full stop (.) with "\&",
if it does not mean an end of a sentence.

2336:lsof FAQ (The \fBFAQ\fP section gives its location.) for more information.

#


Test nr. 12:

Reduce space between words.

1638:TCP_  and TF_ in the dialect's header files \-
3110:or ``(socketpair: n)'' for a Solaris 2.6, 8, 9  or 10
4183:options \-  with the message:

#

Test nr. 16:

Use the correct macro for the font change of a single argument.

1275:.BI \-o

#

Test nr. 17:

Add a backslash, if it is missing after \{ at the end of a line.

921:.ie !\n(.g \{
924:.el \{

#

Test nr. 20:

Use "\e" to print the escape character instead of "\\" (which gets
interpreted in copy mode).

2292:the C ``\\[bfrnt]'' form;
2294:or hexadecimal leading ``\\x'' form (e.g., ``\\xab'').
2295:Space is non\-printable in the COMMAND column (``\\x20'')

#

Test nr. 25:

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

15:.BI -A " A"
231:Thus, for example, ``+M -i'' may be stated as ``+Mi'' and the group
485:.B -D
722:.B -E
778:$ lsof -f -- /file/name
1323:   -o -o 10
1524:   \-iUDP -sUDP:^Idle
1631:.BR -Ts .)
1743:For example, ``lsof -V -iTCP@foobar -a -d 999'' may not report a
1780:.B -x
1786:is specified without a parameter, the next argument must begin with '-'
2418:.B -Z
2421:.B -Z
3625:lsof -b
4217:lsof -i -U
4222:lsof -i 4 -a -p 1234
4227:lsof -i 6
4232:lsof -i @wonderland.cc.purdue.edu:513-515
4237:lsof -i @mace
4242:lsof -p 456,123,789 -u 1234,abe
4254:kill -HUP `lsof -t /u/abe/bar`
4270:lsof -b /nfs/mount/point
4274:lsof -bw /nfs/mount/point
4278:lsof -Di
4284:lsof -FpcfDi
4290:lsof -c lsof -a -d 1 -d 3 -u abe -r10
4298:lsof -c /^..o.$/i -a -d cwd
4303:lsof -i@128.210.15.17
4308:lsof -i@[0:1:2:3:4:5:6:7]
4314:lsof -i@[::1]
4318:lsof -rm%T
4322:lsof -r "m %T "

#

Test nr. 27:

Find a repeated word

! 935 --> be
! 2064 --> is

#

Test nr. 36:

Wrong distance between sentences or protect the indicator.

a) Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) and "info groff".

 The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

681:output contains HASPTYEPT. In addition, this feature works on Linux kernels 
above 4.13.0.
708:are the same as with pipe endpoint information. The endpoint
716:the same form as that of 

Bug#937645: python-cjson: Python2 removal in sid/bullseye

2020-06-30 Thread Bernd Zeimetz



On 6/30/20 10:41 PM, Moritz Mühlenhoff wrote:
> There's no movement on https://github.com/AGProjects/python-cjson/issues/6
> and at this point there are no reverse dependencies left, let's remove it?

yes, good plan - I've filed a ROM removal bug.


Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Bug#964049: RM: python-pychart -- RoQA; Depends on Python 2, dead upstream, unmaintained

2020-06-30 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove python-pychart. It depends on Python 2, there are no reverse deps,
it's dead upstream and the last maintainer upload was in 2009.

Cheers,
Moritz



Bug#937645: python-cjson: Python2 removal in sid/bullseye

2020-06-30 Thread Moritz Mühlenhoff
On Fri, Aug 30, 2019 at 07:37:25AM +, Matthias Klose wrote:
> Package: src:python-cjson
> Version: 1.2.1-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

There's no movement on https://github.com/AGProjects/python-cjson/issues/6
and at this point there are no reverse dependencies left, let's remove it?

Cheers,
Moritz



Bug#964046: python3-skimage: missing (unversioned) Breaks+Replaces: python-skimage

2020-06-30 Thread Andreas Beckmann
Package: python3-skimage
Version: 0.17.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

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

  Preparing to unpack .../python3-skimage_0.17.2-1_all.deb ...
  Unpacking python3-skimage (0.17.2-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-skimage_0.17.2-1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/skivi.1.gz', which is also in 
package python-skimage 0.14.2-2
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-skimage_0.17.2-1_all.deb

Since python-skimage no longer exists, the B+R can be unversioned.


cheers,

Andreas


python-skimage=0.14.2-2_python3-skimage=0.17.2-1.log.gz
Description: application/gzip


Bug#964048: golang-github-tsenart-tb: FTBFS: TestThrottler_Wait failure

2020-06-30 Thread Niko Tyni
Source: golang-github-tsenart-tb
Version: 0.0~git20151208.0.19f4c3d-2
Severity: serious
Tags: ftbfs

This package fails to build on current sid.

>From my build log:

  --- PASS: TestBucket_Take_throughput (1.70s)
  TestBucket_Wait: bucket_test.go:178: bucket.Wait(2000) with cap=1000, 
freq=1ms: Want: 1s, Got 2.035s
  TestBucket_Wait: bucket_test.go:178: bucket.Wait(2000) with cap=1000, 
freq=1ms: Want: 1s, Got 2.029s
  TestThrottler_Wait: throttler_test.go:64: Expected wait of 2s. Got: 3.116s
  --- FAIL: TestThrottler_Wait (3.12s)
  --- FAIL: TestBucket_Wait (7.01s)
  FAIL
  FAIL  github.com/tsenart/tb   7.035s
  ? github.com/tsenart/tb/examples  [no test files]
  ? github.com/tsenart/tb/http  [no test files]
  ? github.com/tsenart/tb/io[no test files]
  FAIL
  dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 
github.com/tsenart/tb github.com/tsenart/tb/examples github.com/tsenart/tb/http 
github.com/tsenart/tb/io returned exit code 1
  make: *** [debian/rules:4: build] Error 25
 

-- 
Niko Tyni   nt...@debian.org



Bug#964047: golang-github-src-d-gcfg: FTBFS: TestScanFully failure

2020-06-30 Thread Niko Tyni
Source: golang-github-src-d-gcfg
Version: 1.4.0-1
Severity: serious
Tags: ftbfs

This package fails to build on current sid.

>From my build log:

  === RUN   TestEnumParserBool
  TestEnumParserBool: enum_test.go:26: "tRuE": got true, 
  TestEnumParserBool: enum_test.go:26: "False": got false, 
  TestEnumParserBool: enum_test.go:26: "t": got false, failed to parse bool 
`t`
  --- PASS: TestEnumParserBool (0.00s)
  === RUN   TestParseInt
  TestParseInt: int_test.go:63: ParseInt(int, "0", IntMode(Dec)): pass; got 
0, error 
  TestParseInt: int_test.go:63: ParseInt(int, "10", IntMode(Dec)): pass; 
got 10, error 
  TestParseInt: int_test.go:63: ParseInt(int, "-10", IntMode(Dec)): pass; 
got -10, error 
  TestParseInt: int_test.go:63: ParseInt(int, "x", IntMode(Dec)): pass; got 
0, error failed to parse "x" as int: expected integer
  TestParseInt: int_test.go:63: ParseInt(int, "0xa", IntMode(Hex)): pass; 
got 10, error 
  TestParseInt: int_test.go:63: ParseInt(int, "a", IntMode(Hex)): pass; got 
10, error 
  TestParseInt: int_test.go:63: ParseInt(int, "10", IntMode(Hex)): pass; 
got 16, error 
  TestParseInt: int_test.go:63: ParseInt(int, "-0xa", IntMode(Hex)): pass; 
got -10, error 
  TestParseInt: int_test.go:54: ParseInt(int, "0x", IntMode(Hex)): fail; 
got error failed to parse "0x" as int: strconv.ParseInt: parsing "0x": invalid 
syntax, want ok
  TestParseInt: int_test.go:54: ParseInt(int, "-0x", IntMode(Hex)): fail; 
got error failed to parse "-0x" as int: strconv.ParseInt: parsing "-0x": 
invalid syntax, want ok
  TestParseInt: int_test.go:63: ParseInt(int, "-a", IntMode(Hex)): pass; 
got -10, error 
  TestParseInt: int_test.go:63: ParseInt(int, "-10", IntMode(Hex)): pass; 
got -16, error 
  TestParseInt: int_test.go:63: ParseInt(int, "x", IntMode(Hex)): pass; got 
0, error failed to parse "x" as int: expected integer
  TestParseInt: int_test.go:63: ParseInt(int, "10", IntMode(Oct)): pass; 
got 8, error 
  TestParseInt: int_test.go:63: ParseInt(int, "010", IntMode(Oct)): pass; 
got 8, error 
  TestParseInt: int_test.go:63: ParseInt(int, "-10", IntMode(Oct)): pass; 
got -8, error 
  TestParseInt: int_test.go:63: ParseInt(int, "-010", IntMode(Oct)): pass; 
got -8, error 
  TestParseInt: int_test.go:63: ParseInt(int, "10", IntMode(Dec|Hex)): 
pass; got 10, error 
  TestParseInt: int_test.go:63: ParseInt(int, "010", IntMode(Dec|Hex)): 
pass; got 10, error 
  TestParseInt: int_test.go:63: ParseInt(int, "0x10", IntMode(Dec|Hex)): 
pass; got 16, error 
  TestParseInt: int_test.go:63: ParseInt(int, "10", IntMode(Dec|Oct)): 
pass; got 10, error 
  TestParseInt: int_test.go:63: ParseInt(int, "010", IntMode(Dec|Oct)): 
pass; got 8, error 
  TestParseInt: int_test.go:63: ParseInt(int, "0x10", IntMode(Dec|Oct)): 
pass; got 0, error failed to parse "0x10" as int: extra characters "x10"
  TestParseInt: int_test.go:63: ParseInt(int, "10", IntMode(Hex|Oct)): 
pass; got 0, error ambiguous integer value; must include '0' prefix
  TestParseInt: int_test.go:63: ParseInt(int, "010", IntMode(Hex|Oct)): 
pass; got 8, error 
  TestParseInt: int_test.go:63: ParseInt(int, "0x10", IntMode(Hex|Oct)): 
pass; got 16, error 
  TestParseInt: int_test.go:63: ParseInt(int, "10", IntMode(Dec|Hex|Oct)): 
pass; got 10, error 
  TestParseInt: int_test.go:63: ParseInt(int, "010", IntMode(Dec|Hex|Oct)): 
pass; got 8, error 
  TestParseInt: int_test.go:63: ParseInt(int, "0x10", 
IntMode(Dec|Hex|Oct)): pass; got 16, error 
  --- FAIL: TestParseInt (0.00s)
  === RUN   TestScanFully
  TestScanFully: scan_test.go:32: ScanFully(*int, "a", 'v') = failed to 
parse "a" as int: expected integer; *ptr==0
  TestScanFully: scan_test.go:23: ScanFully(*int, "0x", 'v'): want ok, got 
error failed to parse "0x" as int: strconv.ParseInt: parsing "0x": invalid 
syntax
  TestScanFully: scan_test.go:32: ScanFully(*int, "0x", 'd') = failed to 
parse "0x" as int: extra characters "x"; *ptr==0
  --- FAIL: TestScanFully (0.00s)
  FAIL
  FAIL  github.com/src-d/gcfg/types 0.016s
  FAIL
  dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 
github.com/src-d/gcfg github.com/src-d/gcfg/scanner github.com/src-d/gcfg/token 
github.com/src-d/gcfg/types returned exit code 1
  make: *** [debian/rules:4: build] Error 25
 
-- 
Niko Tyni   nt...@debian.org



Bug#964045: golang-github-shirou-gopsutil: FTBFS: Test_Process_memory_maps failure

2020-06-30 Thread Niko Tyni
Source: golang-github-shirou-gopsutil
Version: 2.19.11-1
Severity: serious
Tags: ftbfs

This package fails to build from source on current sid.

>From my build log:

   === RUN   Test_SendSignal
   --- PASS: Test_SendSignal (0.00s)
   === RUN   Test_Pids
   --- PASS: Test_Pids (0.00s)
   === RUN   Test_Pids_Fail
   Test_Pids_Fail: process_test.go:48: darwin only
   --- SKIP: Test_Pids_Fail (0.00s)
   === RUN   Test_Pid_exists
   --- PASS: Test_Pid_exists (0.00s)
   === RUN   Test_NewProcess
   --- PASS: Test_NewProcess (0.00s)
   === RUN   Test_Process_memory_maps
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 
{"path":"","rss":0,"size":0,"pss":0,"sharedClean":0,"sharedDirty":0,"privateClean":0,"privateDirty":0,"referenced":0,"anonymous":0,"swap":0}
   Test_Process_memory_maps: process_test.go:114: memory map get error 

Bug#964043: golang-github-caarlos0-env: FTBFS: TestParseInvalidURL fails

2020-06-30 Thread Niko Tyni
Source: golang-github-caarlos0-env
Version: 6.0.0-1
Severity: serious
Tags: ftbfs

This package fails to build on current sid.

>From my build log:

 dh_auto_test -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 
github.com/caarlos0/env
  === RUN   TestParsesEnv
[...]
  --- PASS: TestParseURL (0.00s)
  === RUN   TestParseInvalidURL
  TestParseInvalidURL: env_test.go:953: 
Error Trace:env_test.go:953
Error:  Error message not equal:
expected: "env: parse error on field 
\"ExampleURL\" of type \"url.URL\": unable parse URL: parse nope://s s/: 
invalid character \" \" in host name"
actual  : "env: parse error on field 
\"ExampleURL\" of type \"url.URL\": unable parse URL: parse \"nope://s s/\": 
invalid character \" \" in host name"
Test:   TestParseInvalidURL
  --- FAIL: TestParseInvalidURL (0.00s)
  === RUN   TestIgnoresUnexported
  --- PASS: TestIgnoresUnexported (0.00s)
  === RUN   TestPrecedenceUnmarshalText
  --- PASS: TestPrecedenceUnmarshalText (0.00s)
  === RUN   ExampleParse
  --- PASS: ExampleParse (0.00s)
  === RUN   ExampleParseWithFuncs
  --- PASS: ExampleParseWithFuncs (0.00s)
  FAIL
  FAIL  github.com/caarlos0/env 0.030s
  FAIL
  dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 
github.com/caarlos0/env returned exit code 1
  make: *** [debian/rules:4: build] Error 25
 
-- 
Niko Tyni   nt...@debian.org



Bug#964044: mrpt: FTBFS: test failure

2020-06-30 Thread Sebastian Ramacher
Source: mrpt
Version: 1:2.0.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

binNMUs of mrpt failed to build:
| [--] 1 test from RawlogGrabberApp
| [ RUN  ] RawlogGrabberApp.CGenericCamera_AVI
| [CCameraSensor::initialize] Opening camera...
| [CCameraSensor::initialize] FFmpeg stream: 
/<>/share/mrpt/datasets/dummy_video.avi...
| [CCameraSensor::initialize] Done!
| Rawlog grabbed objects: 1
| /<>/libs/apps/src/RawlogGrabberApp_unittest.cpp:94: Failure
| Expected: (app.rawlog_saved_objects) >= (REQUIRED_GRAB_OBS), actual: 1 vs 3
| [  FAILED  ] RawlogGrabberApp.CGenericCamera_AVI (1511 ms)
| [--] 1 test from RawlogGrabberApp (1511 ms total)

See
https://buildd.debian.org/status/fetch.php?pkg=mrpt=amd64=1%3A2.0.4-1%2Bb1=1593549279=0
for example

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#964042: gitaly: FTBFS: 'go install' fails

2020-06-30 Thread Niko Tyni
Source: gitaly
Version: 1.78.0+dfsg-2
Severity: serious
Tags: ftbfs

This package fails to build on current sid.

>From my build log:

  dh_auto_build: error: cd obj-x86_64-linux-gnu && go install -trimpath -v -p 
16 -ldflags "-X gitlab.com/gitlab-org/gitaly/internal/version.version=1.78.0" 
gitlab.com/gitlab-org/gitaly/auth [...] 
gitlab.com/gitlab-org/gitaly/proto/go/internal/linter 
gitlab.com/gitlab-org/gitaly/streamio returned exit code 2
make[1]: *** [debian/rules:28: override_dh_auto_build] Error 25
make[1]: Leaving directory '/build/1st/gitaly-1.78.0+dfsg'
make: *** [debian/rules:18: build] Error 2

-- 
Niko Tyni   nt...@debian.org



Bug#964041: git-repair: FTBFS: duration parse error

2020-06-30 Thread Niko Tyni
Source: git-repair
Version: 1.20200102-1
Severity: serious
Tags: ftbfs

This package fails to build on current sid.

>From my build log:

  [21 of 69] Compiling Utility.HumanTime ( Utility/HumanTime.hs, 
dist/build/git-repair/git-repair-tmp/Utility/HumanTime.o )
  
  Utility/HumanTime.hs:58:21: error:
  • Could not deduce (MonadFail m) arising from a use of ‘fail’
from the context: Monad m
  bound by the type signature for:
 parseDuration :: forall (m :: * -> *).
  Monad m =>
  String -> m Duration
  at Utility/HumanTime.hs:47:1-48
Possible fix:
  add (MonadFail m) to the context of
the inferred type of parsefail :: m a
or the type signature for:
 parseDuration :: forall (m :: * -> *).
  Monad m =>
  String -> m Duration
  • In the expression:
  fail "duration parse error; expected eg \"5m\" or \"1h5m\""
In an equation for ‘parsefail’:
parsefail
  = fail "duration parse error; expected eg \"5m\" or \"1h5m\""
In an equation for ‘parseDuration’:
parseDuration
  = maybe parsefail (return . Duration) . go 0
  where
  go n [] = return n
  go n s
= do num <- ...
 
  parsefail
= fail "duration parse error; expected eg \"5m\" or 
\"1h5m\""
 |
  58 | parsefail = fail "duration parse error; expected eg \"5m\" or 
\"1h5m\""
 | 
^^^
  make[1]: *** [Makefile:8: build] Error 1
  make[1]: Leaving directory '/<>'
  dh_auto_build: error: make -j1 returned exit code 2
  make: *** [debian/rules:10: binary] Error 25
 

-- 
Niko Tyni   nt...@debian.org



Bug#963699: PostgreSQL: WolfSSL support

2020-06-30 Thread Felix Lechner
Hi Florian,

On Tue, Jun 30, 2020 at 12:15 PM Florian Weimer  wrote:
>
> >> The other issue (WolfSSL GPL violation due to linking against
> >> GPL-incompatible applications via libpq) unfortunately remains.

Can we figure out which packages in Debian are so affected?

Could the use of the GPL for libraries really create a lot of issues? Even the
FSF does not universally advocate using a lesser license for libraries. From
Wikipedia's entry on the LGPL:

> In February 1999, GNU Project leader Richard Stallman wrote the essay "Why
> you shouldn't use the Lesser GPL for your next library" explaining that the 
> LGPL
> had not been deprecated, but that one should not necessarily use the LGPL for
> all libraries:
>
> "Which license is best for a given library is a matter of strategy ... Using 
> the
> ordinary GPL for a library gives free software developers an advantage over
> proprietary developers: a library that they can use, while proprietary
> developers cannot use it" (quote partially reproduced)

Kind regards
Felix Lechner



Bug#964028: raspi-firmware: please include wifi nvram file for the pi 4

2020-06-30 Thread Andres Salomon
retitle 964028 firmware-brcm80211: please include wifi nvram file for 
the pi 4

reassign 964028 firmware-brcm80211 20190717-2
thanks

Romain suggested I reassign this bug, as the nvram file is in 
linux-firmware upstream and should be included in the debian package. 
There's actually bunch of different nvram files for different boards, 
and they should probably also be included. At the very least, please 
include the Pi board configs:


brcmfmac43430-sdio.raspberrypi,3-model-b.txt
brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
brcmfmac43455-sdio.raspberrypi,4-model-b.txt

This could probably allow the raspi-firmware package to remove the 
brcmfmac43455-sdio.txt file, but someone with access to the earlier Pi 
boards (like 0w) would need to verify that.




Bug#964040: git-buildpackage: FTBFS: E741 ambiguous variable name 'l'

2020-06-30 Thread Niko Tyni
Source: git-buildpackage
Version: 0.9.19
Severity: serious
Tags: ftbfs

This package fails to build on current sid.

>From my build log:

  make[2]: Entering directory '/<>'
  flake8 
  ./.pybuild/cpython3_3.8/build/gbp/patch_series.py:108:81: E741 ambiguous 
variable name 'l'
  ./.pybuild/cpython3_3.8/build/gbp/scripts/pq.py:123:22: E741 ambiguous 
variable name 'l'
  ./.pybuild/cpython3_3.8/build/gbp/git/repository.py:518:37: E741 ambiguous 
variable name 'l'
  ./.pybuild/cpython3_3.8/build/gbp/git/repository.py:600:37: E741 ambiguous 
variable name 'l'
  ./gbp/patch_series.py:108:81: E741 ambiguous variable name 'l'
  ./gbp/scripts/pq.py:123:22: E741 ambiguous variable name 'l'
  ./gbp/git/repository.py:518:37: E741 ambiguous variable name 'l'
  ./gbp/git/repository.py:600:37: E741 ambiguous variable name 'l'
  make[2]: *** [Makefile:20: syntax-check] Error 1
  make[2]: Leaving directory '/<>'
  make[1]: *** [debian/rules:22: override_dh_auto_test] Error 2
 
-- 
Niko Tyni   nt...@debian.org



Bug#964039: vg: FTBFS on mips64el

2020-06-30 Thread Sebastian Ramacher
Source: vg
Version: 1.25.0+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

vg failed to build on mips64el:
| Test Summary Report
| ---
| t/34_vg_pack.t  (Wstat: 0 Tests: 18 Failed: 2)
|   Failed tests:  16-17
| t/48_vg_convert.t   (Wstat: 0 Tests: 26 Failed: 2)
|   Failed tests:  15, 19
| Files=50, Tests=672, 2446 wallclock secs ( 3.33 usr  0.48 sys + 3450.18 cusr 
398.58 csys = 3852.57 CPU)
| Result: FAIL
| make[1]: *** [debian/rules:70: override_dh_auto_test-arch] Error 1

See 
https://buildd.debian.org/status/fetch.php?pkg=vg=mips64el=1.25.0%2Bds-1=1593113654=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#964037: src:quickfix: fails to migrate to testing for too long: FTBFS on i386

2020-06-30 Thread Paul Gevers
Source: quickfix
Version: 1.15.1+dfsg-3
Severity: serious
Control: close -1 1.15.1+dfsg-4
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:quickfix in
its current version in unstable has been trying to migrate for 62 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=quickfix




signature.asc
Description: OpenPGP digital signature


Bug#964038: rabbitmq-server: Prometheus plugin doesn't support Erlang v23

2020-06-30 Thread Vladislav Tomenko
Package: rabbitmq-server
Version: 3.8.3-1
Severity: normal
Tags: upstream

Prometheus plugin (which is shipped with rabbitmq-server package)
doesn't support Erlang v23. It seems like a known problem and it's fixed
in the newer versions.
https://github.com/rabbitmq/rabbitmq-prometheus/issues/42



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages rabbitmq-server depends on:
ii  adduser   3.118
ii  erlang-base   1:23.0.2+dfsg-2
ii  erlang-crypto 1:23.0.2+dfsg-2
ii  erlang-eldap  1:23.0.2+dfsg-2
ii  erlang-inets  1:23.0.2+dfsg-2
ii  erlang-mnesia 1:23.0.2+dfsg-2
ii  erlang-os-mon 1:23.0.2+dfsg-2
ii  erlang-parsetools 1:23.0.2+dfsg-2
ii  erlang-public-key 1:23.0.2+dfsg-2
ii  erlang-runtime-tools  1:23.0.2+dfsg-2
ii  erlang-ssl1:23.0.2+dfsg-2
ii  erlang-syntax-tools   1:23.0.2+dfsg-2
ii  erlang-tools  1:23.0.2+dfsg-2
ii  erlang-xmerl  1:23.0.2+dfsg-2
ii  locales-all   2.30-8
ii  logrotate 3.16.0-3
ii  lsb-base  11.1.0
ii  python3   3.8.2-3
ii  socat 1.7.3.4-1

rabbitmq-server recommends no packages.

rabbitmq-server suggests no packages.

-- Configuration Files:
/etc/default/rabbitmq-server changed [not included]

-- no debconf information



Bug#924143: www.debian.org: debian.org metapackage: add dependency for Locale::Codes

2020-06-30 Thread Adam D. Barratt
On Sat, 2019-03-09 at 22:09 +0100, Cyril Brulebois wrote:
> When building on buster, the Perl upgrade changes at least one thing:
> one needs to install an extra package to get the Locale::Codes
> module.
> It used to be shipped under perl-modules, but now has its own
> separate package.
> 
> In stretch, it's provided by:
>   perl-modules
>   perl-modules-5.24
> 
> In testing/sid, it's shipped in:
>   liblocale-codes-perl | 3.59-1| testing| source, all
>   liblocale-codes-perl | 3.60-1| unstable   | source, all
> 
> so it looks to me the debian.org metapackage could gain a dependency
> like the following, to ensure the extra package gets installed when
> moving to buster?
> 
>   liblocale-codes-perl | perl-modules-5.24
> 
> which should be installable in stretch and allowing a transition to
> the real package (liblocale-codes-perl) when the host gets dist
> upgraded to buster?

FWIW, perl-modules-5.24 Provides: liblocale-codes-perl, so unless
anything requires a versioned dependency during the upgrade process a
simple dependency on libl-c-p should be sufficient.

Regards,

Adam



Bug#964036: linux: Please set CONFIG_HWLAT_TRACER=y

2020-06-30 Thread Christopher Obbard
Source: linux
Severity: wishlist

Dear Maintainer,

Setting CONFIG_HWLAT_TRACER=y enables a tracer to detect hardware latencies
with no overhead when not used. It is not designed to be run on a production
system, but is a useful tracer to use in embedded systems.

Other distros enable this configuration option, I see no security issues or
performance issues for users since this is by-default turned off so has to be
enabled at runtime.

Thanks,
Chris

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



Bug#919320: nginx-extras: Would you please consider replacing Gzip module with Brotli for compression?

2020-06-30 Thread Thomas Ward
Notes: rejected downstream in Ubuntu for Security concerns (BREACH, etc.)Sent 
from my Sprint Samsung Galaxy Note10+.
 Original message From: Jérémy Lal  Date: 
6/30/20  15:36  (GMT-05:00) To: Debian Bug Tracking System 
<919...@bugs.debian.org> Subject: Bug#919320: nginx-extras: Would you please 
consider replacing Gzip module with Brotli for compression? Package: 
nginx-extrasVersion: 1.18.0-3Followup-For: Bug #919320Just to 
mentionhttps://github.com/google/ngx_brotlihas been forked then merged back and 
revived.The current 1.0.0rc seems to be working.Jérémy-- System 
Information:Debian Release: bullseye/sid  APT prefers unstable  APT policy: 
(500, 'unstable'), (500, 'testing')Architecture: amd64 (x86_64)Kernel: Linux 
5.7.0-1-amd64 (SMP w/4 CPU cores)Kernel taint flags: TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULELocale: 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/dashInit: systemd (via /run/systemd/system)LSM: AppArmor: 
enabledVersions of packages nginx-extras depends on:ii  iproute2
   5.7.0-1ii  libc6  2.30-8ii  
libcrypt1  1:4.4.16-1pn  libnginx-mod-http-auth-pam 
    pn  libnginx-mod-http-cache-purge  pn  
libnginx-mod-http-dav-ext  ii  libnginx-mod-http-echo 
    1.18.0-a3pn  libnginx-mod-http-fancyindex   pn  
libnginx-mod-http-geoip    pn  libnginx-mod-http-geoip2   
    ii  libnginx-mod-http-headers-more-filter  1.18.0-a3pn  
libnginx-mod-http-image-filter ii  libnginx-mod-http-lua  
    1.18.0-a3pn  libnginx-mod-http-perl pn  
libnginx-mod-http-subs-filter  pn  
libnginx-mod-http-uploadprogress   pn  
libnginx-mod-http-upstream-fair    pn  libnginx-mod-http-xslt-filter  
    pn  libnginx-mod-mail  pn  
libnginx-mod-nchan pn  libnginx-mod-stream
    pn  libnginx-mod-stream-geoip  pn  
libnginx-mod-stream-geoip2 ii  libpcre3   
    2:8.39-13ii  libssl1.1  1.1.1g-1ii  
nginx-common   1.18.0-a3ii  zlib1g  
   1:1.2.11.dfsg-2nginx-extras recommends no packages.Versions of 
packages nginx-extras suggests:ii  nginx-doc  1.18.0-a3

Bug#963254: gcc-10: d/rules.def, set AQ to :all for cross build

2020-06-30 Thread Helmut Grohne
On Tue, Jun 30, 2020 at 02:34:35PM +0800, YunQiang Su wrote:
> No clear sense.
> I just wonder that will conficts happen for native gcc:i686 conflict with
> gcc-i686-linux-gnu:amd64?
> if gcc-i686-linux-gnu:amd64 is marked as Multi-Arch:foreign.

Well yes, there will be conflicts. Those conflicts are entirely
independent of the M-A value though. You see gcc-i686-linux-gnu:amd64
will contain /usr/bin/i686-linux-gnu-gcc. gcc:i686 presently contains
the same file. You cannot coinstall gcc-i686-linux-gnu:amd64 and
gcc:i386 in any case.

> And how about if multi foreign architecutures are added, for example:
> i686> dpkg --add-architecutre amd64 arm64 ppc64el
> ?

Well, you install only one compiler targeting i386. You get to choose
from which of these architectures you want to install the compiler.

You can only install one package owning /usr/bin/i686-linux-gnu-gcc at a
time. This seems pretty normal to me. What's the issue?

Helmut



Bug#963699: PostgreSQL: WolfSSL support

2020-06-30 Thread Felix Lechner
Hi,

> we could ship a libpq5-nossl.deb

Don't users of libpq5 generally rely on the SSL features being present there?

Kind regards
Felix Lechner



Bug#964035: ITP: golang-github-ajstarks-svgo -- generating online histograms and plotting them with golang

2020-06-30 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: golang-github-ajstarks-svgo -- generating online histograms and 
plotting them with golang
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: golang-github-ajstarks-svgo
  Version : 2012
  Upstream Author : Anthony Starks ,
* URL : https://github.com/ajstarks/svgo
* License : CC-BY-3.0
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : generating online histograms and plotting them with golang
 Thist is a go library for calculating online histograms
 with plotting to the terminal and images.

Remark: This package is maintained by Debian Go Packaging Team at
   https://salsa.debian.org/go-team/packages/golang-github-ajstarks-svgo



Bug#919320: nginx-extras: Would you please consider replacing Gzip module with Brotli for compression?

2020-06-30 Thread Jérémy Lal
Package: nginx-extras
Version: 1.18.0-3
Followup-For: Bug #919320

Just to mention
https://github.com/google/ngx_brotli
has been forked then merged back and revived.
The current 1.0.0rc seems to be working.

Jérémy

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

Kernel: Linux 5.7.0-1-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 nginx-extras depends on:
ii  iproute2   5.7.0-1
ii  libc6  2.30-8
ii  libcrypt1  1:4.4.16-1
pn  libnginx-mod-http-auth-pam 
pn  libnginx-mod-http-cache-purge  
pn  libnginx-mod-http-dav-ext  
ii  libnginx-mod-http-echo 1.18.0-a3
pn  libnginx-mod-http-fancyindex   
pn  libnginx-mod-http-geoip
pn  libnginx-mod-http-geoip2   
ii  libnginx-mod-http-headers-more-filter  1.18.0-a3
pn  libnginx-mod-http-image-filter 
ii  libnginx-mod-http-lua  1.18.0-a3
pn  libnginx-mod-http-perl 
pn  libnginx-mod-http-subs-filter  
pn  libnginx-mod-http-uploadprogress   
pn  libnginx-mod-http-upstream-fair
pn  libnginx-mod-http-xslt-filter  
pn  libnginx-mod-mail  
pn  libnginx-mod-nchan 
pn  libnginx-mod-stream
pn  libnginx-mod-stream-geoip  
pn  libnginx-mod-stream-geoip2 
ii  libpcre3   2:8.39-13
ii  libssl1.1  1.1.1g-1
ii  nginx-common   1.18.0-a3
ii  zlib1g 1:1.2.11.dfsg-2

nginx-extras recommends no packages.

Versions of packages nginx-extras suggests:
ii  nginx-doc  1.18.0-a3


Bug#963958: Please backport imlib2 to buster

2020-06-30 Thread Markus Koschany
Hi,

Am 29.06.20 um 11:37 schrieb Enrico Zini:
[...]
> Could you please do a backport upload of imlib2?

I have uploaded a backport of imlib2 to buster-backports a few minutes
ago. It is usually just fine for me if someone else takes care of
backports if they are need. You don't need to file a bug report for
that, at least for my packages.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#964022: ITP: libdata-password-zxcvbn-perl -- Perl port of Dropbox's password strength estimation library, zxcvbn

2020-06-30 Thread tous
Package: wnpp
Severity: wishlist
Owner: Tous Azzi 

* Package name: libdata-password-zxcvbn-perl
  Version : 1.0.4
  Upstream Author : Gianni Ceccarelli 
* URL : https://metacpan.org/pod/Data::Password::zxcvbn
* License : Perl
  Programming Lang: Perl
  Description : Perl port of Dropbox's password strength estimation 
library, zxcvbn

zxcvbn is a password strength estimator inspired by password crackers. Through 
pattern matching and conservative estimation, it recognizes and weighs 30k 
common passwords,common names and surnames according to
US census data, popular English words from Wikipedia and US television and 
movies, and other common patterns like dates, repeats (aaa), sequences (abcd), 
keyboard patterns (qwertyuiop), and l33t speak.



Bug#960762: libvirt: random (?) test hangs

2020-06-30 Thread Andrea Bolognani
On Sat, May 16, 2020 at 03:00:46PM +0300, Adrian Bunk wrote:
> Source: libvirt
> Version: 6.0.0-7
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=libvirt=all=6.0.0-7=1589452859=0
> https://buildd.debian.org/status/fetch.php?pkg=libvirt=i386=6.0.0-7=1589494701=0
> 
> ...
> make  check-TESTS
> make[4]: Entering directory '/<>/debian/build/tests'
> make[5]: Entering directory '/<>/debian/build/tests'
> PASS: sockettest
> PASS: virbuftest
> PASS: virhostcputest
[...]
> PASS: virsh-vcpupin
> PASS: virsh-optparse
> PASS: virt-aa-helper-test
> E: Build killed with signal TERM after 150 minutes of inactivity

Has anyone managed to reproduce this? I've built 6.0.0-7 from source
in a tight loop 100 times, both in a sid:i386 chroot via cowbuilder
and in a sid:i386 VM, without encountering a single failure.

The latest build attempt on i386 also failed:

  
https://buildd.debian.org/status/fetch.php?pkg=libvirt=i386=6.4.0-1=1593097042=0

However, the failure in this case was not limited to i386 and the
error was completely different, caused this time by

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

All I can think of at this point is a temporary glitch of the
buildd. In a couple of weeks, when we upload 6.5.0, we'll hopefully
see that build fine on all architectures, i386 included...

Does anyone have any better theories? Or a way to dig further?

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature


Bug#963699: PostgreSQL: WolfSSL support

2020-06-30 Thread Florian Weimer
* Felix Lechner:

> On Tue, Jun 30, 2020 at 11:38 AM Florian Weimer  wrote:
>>
>> The other issue (WolfSSL GPL violation due to linking against
>> GPL-incompatible applications via libpq) unfortunately remains.
>
> Could that be remedied with a special grant from wolfSSL exempting
> such uses,

I suppose so.  It depends on the details.



Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

2020-06-30 Thread Thorsten Glaser
Russ Allbery dixit:

>local-options means that the maintainer sees a very different view of the
>package than any other consumer on the package via the archive.  Not only

Right, but the packaging workflow is the same (and since there is only
one quilt patch, the view other developers have pretty much matches).
It even has a benefit: NMUs can be added as extra quilt patches, and
the maintainer can just commit them.

>is this philosophically a bit weird, it also breaks tools that try to keep
>the repository and maintainer view consistent (such as dgit).  I suspect
>it is therefore not the solution Ian is looking for.

Ah right, there’s that. OK.

Hope the method I’ve suggested helps someone reading the archives anyway,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)



Bug#964033: /usr/bin/dirmngr: dane key location doesn't validate DNSSEC

2020-06-30 Thread Uwe Kleine-König
Package: dirmngr
Version: 2.2.20-1
Severity: normal
File: /usr/bin/dirmngr

Hello,

user@host:~$ rm -rf .gnupg/
user@host:~$ gpg --locate-keys --auto-key-locate clear,dane 
u...@kleine-koenig.org
gpg: directory '/home/test/.gnupg' created
gpg: keybox '/home/test/.gnupg/pubring.kbx' created
gpg: /home/test/.gnupg/trustdb.gpg: trustdb created
gpg: key E2DCDD9132669BD6: public key "Uwe Kleine-König 
" imported
gpg: Total number processed: 1
gpg:   imported: 1
pub   rsa4096 2010-06-15 [SC] [expires: 2024-06-21]
  0D2511F322BFAB1C1580266BE2DCDD9132669BD6
uid   [ unknown] Uwe Kleine-König 
sub   rsa2048 2015-01-11 [S] [expires: 2022-01-09]
sub   rsa2048 2015-01-11 [E] [expires: 2022-01-09]
sub   rsa2048 2015-01-11 [A] [expires: 2022-01-09]

My expectation is that a key retrieval method called "dane" verifies
DNSSEC, but that is not the case here. See
https://dnsviz.net/d/kleine-koenig.org/dnssec/, the zone has a key, but
it is not anchored in .org.

According to
https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-05#section-5 "The
lookup result MUST pass DNSSEC validation". (Thanks to Jakub Wilk for
finding the relevant documentation.)

Best regards
Uwe

-- System Information:
Debian Release: 10.4
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (500, 'unstable-debug'), 
(500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'testing'), (500, 'oldstable'), (499, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dirmngr depends on:
ii  adduser  3.118
ii  gpgconf  2.2.20-1
ii  init-system-helpers  1.56+nmu1
ii  libassuan0   2.5.2-1
ii  libc62.30-4
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.14-2
ii  libgpg-error01.35-1
ii  libksba8 1.3.5-2
ii  libldap-2.4-22.4.47+dfsg-3+deb10u2
ii  libnpth0 1.6-1
ii  lsb-base 10.2019051400

Versions of packages dirmngr recommends:
ii  gnupg  2.2.20-1

Versions of packages dirmngr suggests:
ii  dbus-user-session  1.12.16-1
ii  libpam-systemd 241-7~deb10u4
ii  pinentry-gnome31.1.0-2
ii  tor0.3.5.10-1

-- no debconf information


Bug#963699: PostgreSQL: WolfSSL support

2020-06-30 Thread Felix Lechner
Hi Florian

On Tue, Jun 30, 2020 at 11:38 AM Florian Weimer  wrote:
>
> The other issue (WolfSSL GPL violation due to linking against
> GPL-incompatible applications via libpq) unfortunately remains.

Could that be remedied with a special grant from wolfSSL exempting
such uses, or would they have to switch to the LGPL?

Kind regards
Felix Lechner



Bug#964032: smartmontools: Samsung S1 Mini 200GB: Unknown USB bridge [0x04e8:0x2f06 (0x000)]

2020-06-30 Thread Jakub Wilk

Package: smartmontools
Version: 7.1-1
Severity: minor

smartctl doesn't work out of the box on my Samsung S1 Mini 200GB disk:

  # smartctl -i /dev/sde
  smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.7.0-1-amd64] (local build)
  Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

  /dev/sde: Unknown USB bridge [0x04e8:0x2f06 (0x000)]
  Please specify device type with the -d option.

  Use smartctl -h to get a usage summary

I had to use "-d usbjmicron" to make it work:

  # smartctl -d usbjmicron -q noserial -i /dev/sde
  smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.7.0-1-amd64] (local build)
  Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

  === START OF INFORMATION SECTION ===
  Model Family: SAMSUNG SpinPoint N3U-3 (USB, 4KiB LLS)
  Device Model: SAMSUNG HS20YJZ
  Firmware Version: 3AU10-01
  User Capacity:200,049,647,616 bytes [200 GB]
  Sector Size:  512 bytes logical/physical
  Device is:In smartctl database [for details use: -P show]
  ATA Version is:   ATA/ATAPI-7, ATA/ATAPI-6 T13/1410D revision 1
  Local Time is:Tue Jun 30 19:12:19 2020 CEST
  SMART support is: Available - device has SMART capability.
  SMART support is: Enabled

--
Jakub Wilk



Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

2020-06-30 Thread Russ Allbery
Thorsten Glaser  writes:
> Ian Jackson dixit:

>> The problem is that `3.0 (quilt)' has both advantages (eg that
>> `nativeness' is declared explicitly) and disadvantages (patches stored

> Not necessarily:

> | $ cat rs/debian/source/local-options
> |single-debian-patch
> | $ cat rs/debian/source/local-patch-header
> |Please review changes against upstream code using SCM,
> |see the Vcs-* tags in debian/control for its location.
> |

> (empty line at the end)

> This allows working with 3.0 (quilt) packages precisely the same way
> (well plus a “git clean -dfx” after building) than with 1.0 packages.

local-options means that the maintainer sees a very different view of the
package than any other consumer on the package via the archive.  Not only
is this philosophically a bit weird, it also breaks tools that try to keep
the repository and maintainer view consistent (such as dgit).  I suspect
it is therefore not the solution Ian is looking for.

-- 
Russ Allbery (r...@debian.org)  



Bug#963960: dbus-java-bin: CreateInterface fails with XML parsing errors

2020-06-30 Thread Markus Koschany
Hello,

Am 29.06.20 um 11:51 schrieb Ronny Standtke:
> Package: dbus-java-bin
> Version: 2.8-9
> Severity: important
> 
> Whatever I try, CreateInterface always fails with XML parsing errors, e.g.:

[...]

> This package, including it's upstream on freedesktop.org, seems to be
> completely broken and out-of-date. There is an updated and improved
> version on github:
> https://github.com/hypfvieh/dbus-java.
> Maybe it's a good idea to switch to this version?

Thanks for bringing this issue to our attention. The former Debian
maintainer of dbus-java was also the upstream maintainer of the code and
since he left development has basically stalled.
I'm not sure if we should switch to the new version though. According to
upstream the changes may break existing code. Quote:

"Please note this version is not compatible with 2.7.x versions as
classes have been moved in other packages or were completly removed.
Most import issues should be easily fixable by using 'Organize Imports'.
Using this version as replacement for 2.7.x however, will not work
without changing your code as well."

We only need dbus-java for three reverse-dependencies: jajuk,
zemberek-server and mauve-aligner and I don't have any personal interest
in this piece of software.

As long as these packages work as intended I would rather not try to
invest time to upgrade dbus-java. However I completely agree that
dbus-java-bin is probably broken and of little value. If nobody else
wants to work on it, I can at least drop the dbus-java-bin binary
package to avoid confusion and disappointment.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature


Bug#963560: main.pdf: openBinaryFile: does not exist

2020-06-30 Thread Dirk Hünniger

Hi,

I got something that looks Ok to me using

mediawiki2latex -u https://en.wikibooks.org/wiki/Haskell/Print_version 
-o Haskell.pdf -i


Yours Dirk

On 6/30/20 4:08 PM, ael wrote:

On Tue, Jun 30, 2020 at 03:28:41PM +0200, Dirk Hünniger wrote:

Hi,

I never looked at main.log. So there may be lots of errors in it. I just
looked at the PDF and that looked Ok to me.

How does the PDF look to you?

It has many problems. I would attach a copy but it is 1.8M compressed.
Something seems to go wrong after Chapter 2. It seems to recover around
Chapter 14.

Chapter 19 seems to have font/language issues: I will attach a screen
shot of that, but that probably is irrelevant - no doubt a consequense
of much earlier errors.

Come to think of it, I will include a screen shot of the start of
"Chapter 3" where things are alraedy broken.

I can't find an example just now, but the old "greybox" backgrounds are
also broken.

And I am sure that there is much more.

ael






Bug#963699: PostgreSQL: WolfSSL support

2020-06-30 Thread Florian Weimer
* Felix Lechner:

> Hi Florian
>
> On Sat, Jun 27, 2020 at 6:22 AM Florian Weimer  wrote:
>>
>>  says this:
>
> Kaleb from wolfSSL followed up today:
>
>> After going over with our management we see what the concerns are with
>> this file: https://github.com/wolfSSL/wolfssl/blob/master/LICENSING
>>
>> We'll update that to include the verb-age "or any later version". I'll also 
>> work
>> with our website maintainer to get the verb-age on the website update. It
>> should always be v2 "or any later version" or in some cases
>> v3 "or any later version" but we want to be explicit!

This is great news.  Thanks for working with upstream to address the
licensing ambiguity.

The other issue (WolfSSL GPL violation due to linking against
GPL-incompatible applications via libpq) unfortunately remains.



Bug#964031: src:viking: New version 1.8 available; offer to help maintain viking

2020-06-30 Thread Paul Gevers
Source: viking
Version: 1.7-2
Severity: normal

Dear Bernd,

I'm a user of viking and today I learned viking is no longer in bullseye
due to build dependency issues. However, a new upstream version is
available and bug #947541 points at a patch (that seems to be applied on
top of 1.8 by the looks of the date).

Is there anything blocking updating viking such that it can be part of
bullseye again? If it's merrily time, I am willing to help maintain viking.

Paul

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

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



signature.asc
Description: OpenPGP digital signature


Bug#964025: berusky2: New upstream release

2020-06-30 Thread Markus Koschany
Hi!

Am 30.06.20 um 18:18 schrieb Asher Gordon:
> Package: berusky2
> Version: 0.10+git20170630-5
> Severity: normal
> 
> Dear Maintainer,
> 
> I have been doing some work on Berusky 2 and I am pleased to announce
> that we have released a new version, 0.12

[...]

Thank you very much for all your work on berusky2! I take a look at the
new version as soon as possible and intend to make a new Debian release
soon.

Best,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#937090: mrtrix: Python2 removal in sid/bullseye

2020-06-30 Thread Moritz Mühlenhoff
On Fri, Aug 30, 2019 at 07:27:24AM +, Matthias Klose wrote:
> Package: src:mrtrix
> Version: 0.2.13-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

Given that there's a separate mrtrix3 source package which is ported to
Python 3, should src:mrtrix simply be removed now?

Cheers,
Moritz




Bug#963699: PostgreSQL: WolfSSL support

2020-06-30 Thread Felix Lechner
Hi Florian

On Sat, Jun 27, 2020 at 6:22 AM Florian Weimer  wrote:
>
>  says this:

Kaleb from wolfSSL followed up today:

> After going over with our management we see what the concerns are with
> this file: https://github.com/wolfSSL/wolfssl/blob/master/LICENSING
>
> We'll update that to include the verb-age "or any later version". I'll also 
> work
> with our website maintainer to get the verb-age on the website update. It
> should always be v2 "or any later version" or in some cases
> v3 "or any later version" but we want to be explicit!

Kind regards
Felix Lechner



Bug#964030: RM: pynifti -- RoQA; Depends on Python 2, replaced by nibabel

2020-06-30 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove pynifti. It depends on Python 2 and has been replaced
by nibabel. Acked by one of the maintainers in #937490

Cheers,
Moritz



Bug#937490: pynifti: Python2 removal in sid/bullseye

2020-06-30 Thread Moritz Mühlenhoff
On Mon, Jun 29, 2020 at 08:41:26PM +0200, Michael Hanke wrote:
> Hi,
> 
> yes, that sounds like to best course of action to me.

Ack, I've filed an RM bug.

Cheers,
Moritz



Bug#962384: Support for systemd-sysusers

2020-06-30 Thread Moritz Muehlenhoff
On Tue, Jun 30, 2020 at 07:07:50PM +0200, Michael Biebl wrote:
> Am 30.06.20 um 11:20 schrieb Niels Thykier:
> > What about removal; is there any
> > action to be done for locking the users?
> 
> Good question. Afaics there are no provisions in systemd-sysusers to
> remove users again.

Indeed.

> It's my understanding, that there is no clear consensus what should
> happen on package purge. Some packages do manually remove system users
> and go to some length to find files/directories owned by a system
> user/group and remove them.
> Some maintainers are of the opinion, that a system user once created
> should not be removed again.
> I think both viewpoints are valid, but the never-remove-a-system-user is
> probably the safer approach.

Agreed. system users are essentially "free" and if system users are removed,
there's always a risk of UID reuse if a service owns a file, then the service
is removed and the UID reclaimed by a different service, so retaining the
UID of a gone service (until the server is reinstalled or decommisioned is
definitely the safer route).

Also, given that systemd-sysusers relies on declarative configuration of
system users, at future time where all system users are created with it,
this also allows tooling to detect unused system users.

Cheers,
Moritz



Bug#964028: raspi-firmware: please include wifi nvram file for the pi 4

2020-06-30 Thread Andres Salomon

Package: raspi-firmware
Version: 1.20200212-1
Severity: wishlist

The raspberry pi 4 won't load the brcm43455 wireless driver without the 
proper nvram file in place. Currently there's a 
/lib/firmware/brcm/brcmfmac43455-sdio.txt nvram file, but I think 
that's for earlier pi versions. Upstream has a file specifically for 
the pi 4:


https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt

Including that nvram file in the raspi-firmware package would allow 
wifi to work on the pi 4, and probably makes more sense than trying to 
get it included in the firmware-brcm80211 package.




Bug#954442: RFP: pulseaudio-module-bluetooth-nonfree -- Sony LDAC, aptX, aptX HD, AAC codecs (A2DP Audio) support to PulseAudio on Linux

2020-06-30 Thread Nicholas D Steeves
> and pali writes
> 
> This merge request does not support ldac codec.
> 
> And libldac (in Debian or Ubuntu) is irrelevant here as its
> license is incompatible with pulseaudio. So it cannot be used in
> pulseaudio for ldac support.
> 
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227#note_550634
> 
> If this is true, then ftpmaster would reject an upload of
> pulseaudio-module-bluetooth-nonfree, because non-free is one thing,
> while breach-of-license is another.
> 
> 
> Regards,
> Nicholas

Ah, I found clarification from pali here

About LDAC in pulseaudio, there is open question about
licensing. LGPLv2 is not compatible with Apache License under
which is LDAC encoder released. Until this issue is resolved I
guess that LDAC codec support would not appear in distributed
version of pulseaudio.

https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality-on-linux/#comment-10714

and a possible workaround

GPLv2+ and LGPLv2+ code can be (optionally) upgraded to GPLv3 and
Apache License, under which is LDAC, is compatible with GPLv3. I’m
not lawyer but maybe some build option “–compile-as-gplv3” could
generate GPLv3 binary of pulseaudio and then it could use LDAC
encoder.

https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality-on-linux/#comment-10726



signature.asc
Description: PGP signature


Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)

2020-06-30 Thread Ansgar
On Tue, 2020-06-30 at 17:45 +0100, Mark Hindley wrote:
> I am struggling to understand how libelogind0 came to be installed in the 
> build
> in the first place. Can you help me understand that?

No idea; apt's resolver is sometimes creative.  Other examples include
[1], [2], [3].

  [1]: 
https://buildd.debian.org/status/logs.php?pkg=hplip=3.20.6%2Bdfsg0-1=amd64
  [2]: 
https://buildd.debian.org/status/logs.php?pkg=gnome-applets=3.37.2-1=amd64
  [3]: 
https://buildd.debian.org/status/logs.php?pkg=kopete=4%3A20.04.1-1=amd64

> Presumably there is a build dependency on libsystemd-dev, but I don't see it 
> in
> the log.

That's probably not required for apt to find the unwanted solution.

Ansgar



Bug#954434: pulseaudio-module-bluetooth: Adds Sony LDAC, aptX, aptX HD, AAC codecs (A2DP Audio) support to PulseAudio on Linux

2020-06-30 Thread Nicholas D Steeves
Hello Stefano, Felipe, and anyone else reading this,

On Sat, Mar 21, 2020 at 06:45:01PM +0100, Stefano F. wrote:
>
> Il giorno sab 21 mar 2020 alle ore 17:17 Felipe Sateler
>  ha scritto:
> > On Sat, Mar 21, 2020 at 12:33 PM Stefano F.  wrote:
> >>
> >> Package: pulseaudio-module-bluetooth
> >> Version: 13.99.1-1
> >> Severity: wishlist
> >> Tags: upstream
> >>
> >> Dear Maintainer,
> >>
> >> it would be nice to have non-free alternative package for A2DP codecs for
> >> modern true wireless earbuds supporte codecs with the packaging of[1].
> >>
> >> See also[2][3][4]
> >>
> >> [1]https://github.com/EHfive/pulseaudio-modules-bt
> >> [2]https://github.com/EHfive/pulseaudio-modules-bt/wiki#are-there-any-plans-to-
> >> upstream-this-into-pulseaudio
> >> [3]https://github.com/EHfive/pulseaudio-modules-bt/issues/3
> >> [4]https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality-
> >> on-linux/
> >
> >
> > I'm not sure what you are proposing. If you want these modules to be 
> > packaged, please help with getting #794692 resolved and then file a RFP for 
> > the modules.
>
> If we need a new alternative package the RFC is at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954442
>

I think Stefano is asking for two different things.  The primary one
appears to be for a nonfree pulseaudio-module-bluetooth alternative
package that supports a variety of non-free codecs, and he filed an
RFP for that.

That said,

libldac passed RedHat legal review
  https://bugzilla.redhat.com/show_bug.cgi?id=1671064

and is in sid, and I would have liked to propose that we build
pulseaudio with libldac support (and not AptX and other
patent-encumbered Qualcomm technologies), but then I read that libldac
allegedly has a license that in incompatible with pulseaudio's?!

  
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227#note_550634

If that's the case, how can both pulseaudio and libldac be in main?

If it's not the case, then I think this bug should be retitled and
focused as a wishlist bug to build pulseaudio-module-bluetooth (in
main) with support for LDAC via libldac.

Thanks,
Nicholas


signature.asc
Description: PGP signature


Bug#954442: RFP: pulseaudio-module-bluetooth-nonfree -- Sony LDAC, aptX, aptX HD, AAC codecs (A2DP Audio) support to PulseAudio on Linux

2020-06-30 Thread Nicholas D Steeves
On Sat, Mar 21, 2020 at 06:38:10PM +0100, Stefano F. wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: pulseaudio-module-bluetooth-nonfree
>   Version : x.y.z

Please include a Version in future RFP/ITP/RFSs.

>   Upstream Author : Bao H.H. 
> * URL : https://github.com/EHfive/pulseaudio-modules-bt
> * License : GPL3
>   Programming Lang: C
>   Description : Sony LDAC, aptX, aptX HD, AAC codecs (A2DP Audio) support
> to PulseAudio on Linux
> 
> Pulseaudio bluetooth modules forks that adds LDAC, APTX, APTX-HD, AAC support,
> extended configuration for SBC
> 
> It is very useful to support codecs for modern true wireless earbuds
> 
> Some interesting links:
> [1]https://github.com/EHfive/pulseaudio-modules-bt
> [2]https://github.com/EHfive/pulseaudio-modules-bt/wiki#are-there-any-plans-to-
> upstream-this-into-pulseaudio
> [3]https://github.com/EHfive/pulseaudio-modules-bt/issues/3
> [4]https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality-
> on-linux/

Pasi Karkkainen writes

 EHfive/pulseaudio-modules-bt is basicly an out-of-tree hack, it's
 not suitable for upstreaming. That's exactly why Pali has been
 working in getting these features developed and the necessary
 APIs implemented, cleaned up properly and upstreamed to
 bluez/pulseaudio/etc.
 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227#note_522808

and pali writes

This merge request does not support ldac codec.

And libldac (in Debian or Ubuntu) is irrelevant here as its
license is incompatible with pulseaudio. So it cannot be used in
pulseaudio for ldac support.

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227#note_550634

If this is true, then ftpmaster would reject an upload of
pulseaudio-module-bluetooth-nonfree, because non-free is one thing,
while breach-of-license is another.


Regards,
Nicholas


signature.asc
Description: PGP signature


Bug#964018: RFS: grap/1.46-1 [QA] -- program for typesetting graphs

2020-06-30 Thread Håvard Flaget Aasen
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: grap
   Version : 1.46-1
   Upstream Author : Ted Faber 
 * URL : https://www.lunabase.org/~faber/Vault/software/grap/
 * License : BSD-like
 * Vcs : None
   Section : text

It builds those binary packages:

  grap - program for typesetting graphs

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/g/grap/grap_1.46-1.dsc

Changes since the last upload:

   * QA upload.
   * New upstream release.
   * d/copyright
 - Add Upstream-Contact
 - Use secure URI
   * d/control
 - Change to debhelper-compat
 - Bump debhelper to 12
 - Update Standards-Version to 4.5.0
 - Use secure URI
 - Add Rules-Requires-Root: no
   * d/watch
 - Use secure URI
   * Add fix_spelling.patch
   * Make the build reproducible closes: #870573
 Thanks to Chris Lamb for patch.

Regards,
Håvard



Bug#963975: blender: Blender crashes on launch (failed assert)

2020-06-30 Thread Alex Andreotti
Package: blender
Version: 2.83.1+dfsg-1
Followup-For: Bug #963975

Dear Maintainer,

I have updated to 2.83.1 + dfsg-1 and have the same problem (I don't remember 
if I used 2.81 or 2.82 previously but it worked)

In my case, however, the fonts in question are not installed by blender-data, 
the fonts directory is missing, if I create it and copy the fonts blender does 
not work anyway, I guess we should run font config, if I copy the fonts in the 
configuration directory of blender, in the user's home, blender works.


dpkg -L blender-data|grep '\.ttf$'
/usr/share/locale/fonts/bmonofont-i18n.ttf
/usr/share/locale/fonts/droidsans.ttf


ls -l /usr/share/locale/fonts/bmonofont-i18n.ttf 
/usr/share/locale/fonts/droidsans.ttf
ls: cannot access '/usr/share/locale/fonts/bmonofont-i18n.ttf': No such file or 
directory
ls: cannot access '/usr/share/locale/fonts/droidsans.ttf': No such file or 
directory


cp blender-2.83.1-linux64/2.83/datafiles/fonts/bmonofont-i18n.ttf 
blender-2.83.1-linux64/2.83/datafiles/fonts/droidsans.ttf 
/home/alex/.config/blender/2.83/datafiles/fonts

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

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

Versions of packages blender depends on:
ii  blender-data   2.83.1+dfsg-1
ii  fonts-dejavu   2.37-2
ii  libavcodec-extra58 [libavcodec58]  7:4.3-2
ii  libavdevice58  7:4.3-2
ii  libavformat58  7:4.3-2
ii  libavutil567:4.3-2
ii  libboost-locale1.71.0  1.71.0-6+b2
ii  libc6  2.30-8
ii  libfftw3-double3   3.3.8-2
ii  libfreetype6   2.10.1-2
ii  libgcc-s1  10.1.0-4
ii  libgl1 1.3.1-1
ii  libglew2.1 2.1.0-4+b1
ii  libgomp1   10.1.0-4
ii  libilmbase24   2.3.0-6
ii  libjack-jackd2-0 [libjack-0.125]   1.9.12~dfsg-2+b1
ii  libjemalloc2   5.2.1-1
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libopenal1 1:1.19.1-1+b1
ii  libopencolorio1v5  1.1.1~dfsg0-6+b1
ii  libopenexr24   2.3.0-6
ii  libopenimageio2.1  2.1.16.0~dfsg0-1
ii  libopenjp2-7   2.3.1-1
ii  libopenvdb7.0  7.0.0-3+b1
ii  libosdcpu3.4.3 3.4.3-3
ii  libosdgpu3.4.3 3.4.3-3
ii  libpcre3   2:8.39-13
ii  libpng16-161.6.37-2
ii  libpython3.8   3.8.3-1
ii  libsdl2-2.0-0  2.0.12+dfsg1-1
ii  libsndfile11.0.28-8
ii  libspnav0  0.2.3-1+b2
ii  libstdc++6 10.1.0-4
ii  libswscale57:4.3-2
ii  libtbb22020.2-2
ii  libtiff5   4.1.0+git191117-2
ii  libx11-6   2:1.6.9-2+b1
ii  libxfixes3 1:5.0.3-2
ii  libxi6 2:1.7.10-1
ii  libxml22.9.10+dfsg-5+b1
ii  libxrender11:0.9.10-1
ii  libxxf86vm11:1.1.4-1+b2
ii  zlib1g 1:1.2.11.dfsg-2

blender recommends no packages.

blender suggests no packages.

-- no debconf information



Bug#962424: zfsutils-linux: systemd zfs-mount-generator breaks boot if multiple datasets have the same mountpoint

2020-06-30 Thread Wxcafé
Sorry, it's been three weeks and lots of stuff happened since there, I
don't know if I edited that file or not now, but I guess probably yeah.
Here's something pulled from my server right now.

Cheers

On Tue, 2020-06-30 at 06:24 -0600, Antonio Russo wrote:
> Control: tags -1 +moreinfo
> 
> Hello!
> 
> Is that attached file literally what is in /etc/zfs/zfs-list.cache
> ?  How was it generated, and how did it get there?
> 
> Because it's wrong---it's space separated, and must be tab
> separated.  Use -H, per man zfs-mount-generator, if it must be done
> by hand.
> 
> Best,
> Antonio
-- 
Wxcafé 
rpool   /   off on  on  off on  off on  off 
-   none-   -   -   -   -   -   -   -
rpool/ROOT  noneoff on  on  off on  off on  
off -   none-   -   -   -   -   -   -   
-
rpool/ROOT/debian   /   noauto  on  on  off on  off 
on  off -   none-   -   -   -   -   -   
-   -
rpool/backups   /backupsnoauto  on  on  off on  off 
on  off -   none-   -   -   -   -   -   
-   -
rpool/backups/kirby /backups/kirby  noauto  on  on  off on  
off on  off -   none-   -   -   -   -   
-   -   -
rpool/backups/kirby/backups /backups/kirby/backups  on  on  on  
off on  off on  off -   none-   -   -   
-   -   -   -   -
rpool/backups/kirby/backups/cwh /backups/kirby/backups/cwh  noauto  on  
on  off on  off on  off rpool/backups/kirby/backups/cwh 
prompt  -   -   -   -   -   -   -   -
rpool/backups/kirby/backups/link/backups/kirby/backups/link noauto  
on  on  off on  off on  off 
rpool/backups/kirby/backups/linkprompt  -   -   -   -   
-   -   -   -
rpool/backups/kirby/srvpool /backups/kirby/srvpool  noauto  on  on  
off on  off on  off -   none-   -   -   
-   -   -   -   -
rpool/backups/kirby/srvpool/srv /backups/kirby/srvpool/srv  noauto  on  
on  off on  off on  off -   none-   -   
-   -   -   -   -   -
rpool/backups/kirby/srvpool/srv/storage /srv/storagenoauto  on  on  
off on  off on  off rpool/backups/kirby/srvpool/srv/storage 
prompt  -   -   -   -   -   -   -   -
rpool/backups/local /backups/local  on  on  on  off on  
off on  off -   none-   -   -   -   -   
-   -   -
rpool/backups/support   /backups/supportnoauto  on  on  off 
on  off on  off -   none-   -   -   -   
-   -   -   -
rpool/backups/support/bpool /   noauto  on  on  off on  
off on  off -   none-   -   -   -   -   
-   -   -
rpool/backups/support/bpool/BOOTnonenoauto  on  on  off 
on  off on  off -   none-   -   -   -   
-   -   -   -
rpool/backups/support/bpool/BOOT/debian legacy  noauto  on  on  off 
on  off on  off -   none-   -   -   -   
-   -   -   -
rpool/backups/support/rpool /   noauto  on  on  off on  
off on  off -   none-   -   -   -   -   
-   -   -
rpool/backups/support/rpool/ROOTnonenoauto  on  on  off 
on  off on  off -   none-   -   -   -   
-   -   -   -
rpool/backups/support/rpool/ROOT/debian /   noauto  on  on  off 
on  off on  off -   none-   -   -   -   
-   -   -   -
rpool/backups/support/rpool/home/home   noauto  on  on  off 
on  off on  off -   none-   -   -   -   
-   -   -   -
rpool/backups/support/rpool/home/root   /root   noauto  on  on  off 
on  off on  off -   none-   -   -   -   
-   -   -   -
rpool/backups/support/rpool/home/wxcafe /home/wxcafenoauto  on  on  
off on  off on  off -   none-   -   -   
-   -   -   -   -
rpool/backups/support/rpool/srv /srvnoauto  on  on  off on  
off on  off -   none-   -   -   -   -   
-   -   -

Bug#962384: Support for systemd-sysusers

2020-06-30 Thread Michael Biebl
Am 30.06.20 um 11:20 schrieb Niels Thykier:
> What about removal; is there any
> action to be done for locking the users?

Good question. Afaics there are no provisions in systemd-sysusers to
remove users again.

It's my understanding, that there is no clear consensus what should
happen on package purge. Some packages do manually remove system users
and go to some length to find files/directories owned by a system
user/group and remove them.
Some maintainers are of the opinion, that a system user once created
should not be removed again.
I think both viewpoints are valid, but the never-remove-a-system-user is
probably the safer approach.

Regarding locking: Afaik, systemd-sysusers creates locked system users
by default. (From the man page: The account will be created disabled, so
that logins are not allowed.)

Regards,
Michael






signature.asc
Description: OpenPGP digital signature


Bug#964027: incompatible with kernel 5.7.0: ERROR: modpost: "__pagevec_lru_add" [...] undefined!

2020-06-30 Thread Benjamin Kaduk
tags 964027 pending fixed-upstream
thanks

On Tue, Jun 30, 2020 at 12:48:41PM -0400, Ryan Kavanagh wrote:
> Package: openafs-modules-dkms
> Version: 1.8.6~pre1-3
> Severity: grave
> Justification: package is not compatible with the current kernel
> 
> The package cannot successfully be installed under 5.7.0-1-amd64.
> The build fails with:

Upstream 1.8.6, released yesterday, will support the 5.7 kernel.

Thanks for the report,

Ben



Bug#964027: incompatible with kernel 5.7.0: ERROR: modpost: "__pagevec_lru_add" [...] undefined!

2020-06-30 Thread Ryan Kavanagh
Package: openafs-modules-dkms
Version: 1.8.6~pre1-3
Severity: grave
Justification: package is not compatible with the current kernel

The package cannot successfully be installed under 5.7.0-1-amd64.
The build fails with:

  LD [M]  
/var/lib/dkms/openafs/1.8.6pre1/build/src/libafs/MODLOAD-5.7.0-1-amd64-SP/afspag.o
  MODPOST 2 modules
ERROR: modpost: "__pagevec_lru_add" 
[/var/lib/dkms/openafs/1.8.6pre1/build/src/libafs/MODLOAD-5.7.0-1-amd64-SP/openafs.ko]
 undefined!
make[5]: *** 
[/usr/src/linux-headers-5.7.0-1-common/scripts/Makefile.modpost:99: __modpost] 
Error 1
make[4]: *** [/usr/src/linux-headers-5.7.0-1-common/Makefile:1658: modules] 
Error 2
make[3]: *** [/usr/src/linux-headers-5.7.0-1-common/Makefile:180: sub-make] 
Error 2
make[3]: Leaving directory '/usr/src/linux-headers-5.7.0-1-amd64'
FAILURE: make exit code 2
make[2]: *** [Makefile.afs:279: openafs.ko] Error 1
make[2]: Leaving directory 
'/var/lib/dkms/openafs/1.8.6pre1/build/src/libafs/MODLOAD-5.7.0-1-amd64-SP'
make[1]: *** [Makefile:186: linux_compdirs] Error 2
make[1]: Leaving directory '/var/lib/dkms/openafs/1.8.6pre1/build/src/libafs'
make: *** [Makefile:15: all] Error 2

The entire build log, /var/lib/dkms/openafs/1.8.6pre1/build/make.log, is
attached.

-- 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)
Foreign Architectures: i386

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

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.8.2-2
ii  libc6-dev  2.31-0experimental0
ii  perl   5.30.3-4

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.8.6~pre1-3

openafs-modules-dkms suggests no packages.

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
DKMS make.log for openafs-1.8.6pre1 for kernel 5.7.0-1-amd64 (x86_64)
Tue 30 Jun 2020 12:34:56 PM EDT
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for libxslt... no
checking for saxon... no
checking for xalan-j... no
checking for xsltproc... xsltproc
checking for fop... no
checking for dblatex... no
checking for docbook2pdf... no
configure: WARNING: Docbook stylesheets not found; some documentation can't be 
built
checking for kindlegen... no
checking for doxygen... no
checking for dot... dot
checking for library containing strerror... none required
checking for pid_t... yes
checking for size_t... yes
checking whether ln -s works... yes
checking for ranlib... ranlib
checking for bison... bison -y
checking if lex is flex... yes
checking whether byte order is known at compile time... yes
checking whether byte ordering is bigendian... no
checking whether printf understands the %z length modifier... yes
checking your OS... linux
checking for ranlib... (cached) ranlib
checking for as... as
checking for mv... mv
checking for rm... rm
checking for ld... ld
checking for cp... cp
checking for gencat... gencat
checking if gcc accepts -march=pentium... no
checking if gcc needs -fno-strength-reduce... yes
checking if gcc needs -fno-strict-aliasing... yes
checking if gcc supports -fno-common... yes
checking if gcc supports -pipe... yes
checking if linux kbuild requires EXTRA_CFLAGS... no
checking if linux kernel module build works... yes
checking 

Bug#962384: Support for systemd-sysusers

2020-06-30 Thread Michael Biebl
Hi Niels,

Am 30.06.20 um 11:20 schrieb Niels Thykier:
> Hi Michael and Felipe,
> 
> Any news on this? :)  Also, will it only take a postinst script to
> create the user and nothing else?  What about removal; is there any
> action to be done for locking the users?

I'm still contemplating what the benefits and downsides of such a split
are and how to best approach it.

To better understand the debhelper requirements: is splitting out
systemd-sysusers mandatory to get support in debhelper and if so, could
you go into more detail why?

Would it help, if the systemd package had a versioned Provides:
systemd-sysusers?


Michael



signature.asc
Description: OpenPGP digital signature


Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)

2020-06-30 Thread Mark Hindley
Ansgar,

Thanks for this.

On Tue, Jun 30, 2020 at 06:27:20PM +0200, Ansgar wrote:
> Package: libelogind0
> Version: 243.7-1+debian1
> Severity: serious
> 
> libelogind0's `Provides: libsystemd0` causes unrelated packages to
> fail to build due to unmet dependencies.  See [1] for an example.
> 
> The relevant log part is:
> 
> +---
> | The following packages have unmet dependencies:
> |  libelogind0 : Conflicts: libsystemd0
> | E: Broken packages
> | apt-get failed.
> +---

I am struggling to understand how libelogind0 came to be installed in the build
in the first place. Can you help me understand that?

Presumably there is a build dependency on libsystemd-dev, but I don't see it in
the log.

Thanks

Mark



Bug#962237: buster-pu: package perl/5.28.1-6+deb10u1

2020-06-30 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Thu, 2020-06-04 at 22:34 +0100, Dominic Hargreaves wrote:
> As per #962234 for stretch and my remarks on #961443 I'd like to
> uploaded a targeted fix for these no-dsa security issues:
> 
> https://metacpan.org/pod/release/XSAWYERX/perl-5.28.3/pod/perldelta.pod
> 

+perl (5.28.1-6+deb10u1) UNRELEASED; urgency=medium

With that finalised, please go ahead; thanks.

Regards,

Adam



  1   2   >