Bug#952587: FTBFS with Ruby2.7: CSV.parse() doesn't parse CVS source file as expected

[Andrei POPESCU]

Control: reassign -1 ruby-espeak 1.0.4-1

On Mi, 26 feb 20, 14:17:36, Daniel Leidert wrote:
> Source: ruby-rspeak
> Version: 1.0.4-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: sid
> Usertags: ruby2.7-transition
> 
> Hi there,
> 
> the newly accepted ruby-espeak fails to test successfully with Ruby2.7. The
> reason seems that CSV.parse() has a behavior change. It does not parse the 
> file
> test/fixtures/voices.txt anymore as it did. It seems using 
> 
> col_sep: ' '
> 
> is now interpreted literally. So fields separated by more then one space are
> not parsed as columns in a row. To demonstrate consider this line:
> 
> > Pty Language Age/Gender VoiceName   FileOther Langs
> >  5  af M  afrikaans af  
> 
> With ruby2.5 it is parsed like this:
> 
> > # > "VoiceName":"afrikaans"
> > "File":"af" "Other":nil "Langs":nil>
> 
> and with ruby2.7 like this:
> 
> > # > nil:nil
> > nil:nil nil:nil nil:nil nil:nil nil:nil "File":nil nil:nil nil:nil nil:nil
> > nil:nil nil:nil nil:"M" nil:nil "Other":"afrikaans" "Langs":nil nil:nil
> > nil:nil nil:nil nil:nil nil:nil nil:nil nil:nil nil:"af" nil:nil nil:nil
> > nil:nil nil:nil nil:nil nil:nil nil:nil nil:nil nil:nil nil:nil>
> 
> This seems intentional:
> https://github.com/ruby/csv/issues/67
> https://github.com/ruby/csv/commit/7798df60fed87251b26c1202eb251a7894b55469#diff-fd263cdff2717a557bddf1592762dba3R16
> 
> The file format is determined by the output of `espeak --voices` and cannot be
> changed.
> 
> Does anybody know, how to easily fix this, or is anybody up to add some magic
> to lib/espeak/voice.rb to deal with this?
> 
> Regards, Daniel



-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#951907: Suggested Stable Fix

[Salvatore Bonaccorso]

Hi Scott,

On Sat, Feb 22, 2020 at 07:20:34PM -0500, Scott Kitterman wrote:
> Debdiff for proposed stable security update attached.
> 
> The first hunk of the patch has the actual fix.  I would prefer to use the 
> new 
> ustream release rather than just patch the one line because of the test 
> improvements, of the explanation of the issue in the upstream changeslog, and 
> using the new upstream makes it clearer to external reviewers we've done the 
> fix.  There are no unrelated changes.

Okay let's fix this via a DSA.
I checked the reverse dependencies and none seem to be particularly
impacted, but given the primary use of the module is to sanitize input
and is generic enough we should update.

Can you set urgency=high for consistency, and add the now assigned CVE
refeence (I did contact Mozilla CNA for it, and they assigned one, it
is CVE-2020-6802).

Many thanks for your work and apologies for the long delay.

Regards,
Salvatore

Bug#952665: debian-edu-config: Don't do unnecessary wget to the internet

[Mike Gabriel]

Hi,

On  Do 27 Feb 2020 08:02:00 CET, Mike Gabriel wrote:


Package: debian-edu-config
Version: 2.11.15

The dc=skole object in LDAP can reference a Firefox/Chromium default  
homepage in its labeledURI field. If this URI points to some school  
homepage on the internet, we observe bad system logon performance in  
computer labs.


While looking into this, I discovered that in such cases the script  
share/debian-edu-config/tools/show-welcome-webpage does unnecessary  
wgets to the internet.


In this code section...

```
GETDEFAULTHOMEPAGE=$(/usr/share/debian-edu-config/tools/get-default-homepage  
|| true)


if [ "$GETDEFAULTHOMEPAGE" ] &&
echo "$PROFILE" | egrep -q  
'Main-Server|Workstation|Roaming-Workstation|LTSP-Server|Minimal' ;  
then

for lang in $(echo $LANGCODE | tr : " "); do
if wget -q -O /dev/null ${GETDEFAULTHOMEPAGE}index.html.$lang ; then
welcomeurl="${GETDEFAULTHOMEPAGE}index.html.$lang"
break
else
welcomeurl=$GETDEFAULTHOMEPAGE || true
fi
done
else
welcomeurl=http://www.skolelinux.org/
fi
```

... the wget to ${GETDEFAULTHOMEPAGE}index.html.$lang only makes  
sense if the queried host is www or www.intern. The LANGCODE based  
query is a very specific semantic provided on Debian Edu's main  
server for delivering localized welcome pages, but it is not at all  
a common thing for other websites.


Furthermore, I wonder if the show-welcome-page script can't be even  
more optimized so that this wget on every login could be avoided  
entirely.


Suggestion: instead of storing the  
:///index.html.LANGCODE URL in  
$HOME/.debian-edu/welcome-page-shown", we could also store the value  
retrieved via get-default-homepage (without appended LANGCODE) and  
be happy with that.


Greets,
Mike


The host check can be done similar to this commit (in a script that  
disables the welcome page on roaming workstations for us):

https://code.it-zukunft-schule.de/cgit/itzks-systems/commit/?id=3f2758333c2085e86622ca145a538cabc34a96d7

With that, the LANGCODE lookups are limited to TJENER. Doing these on  
every login is also questionable, but it fixes the performance drop on  
the remote webserver during computer lab logins, if another labeledURI  
is set in LDAP's dc=skole object.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpvupCS5JWWF.pgp
Description: Digitale PGP-Signatur

Bug#651118: [ftpmas...@ftp-master.debian.org: mlpy_3.5.0+ds-1_amd64.changes is NEW]

[Andreas Tille]

Control: tags -1 pending

- Forwarded message from Debian FTP Masters 
 -

Date: Wed, 26 Feb 2020 21:08:18 +
From: Debian FTP Masters 
To: Debian Science Maintainers 
, Andreas Tille 

Subject: mlpy_3.5.0+ds-1_amd64.changes is NEW

binary:python3-mlpy is NEW.
binary:python3-mlpy-lib is NEW.
binary:python3-mlpy is NEW.
binary:python3-mlpy-lib is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
 or https://ftp-master.debian.org/backports-new.html for *-backports

-- 
debian-science-maintainers mailing list
debian-science-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

- End forwarded message -

-- 
http://fam-tille.de

Bug#952665: debian-edu-config: Don't do unnecessary wget to the internet

[Mike Gabriel]

Package: debian-edu-config
Version: 2.11.15

The dc=skole object in LDAP can reference a Firefox/Chromium default  
homepage in its labeledURI field. If this URI points to some school  
homepage on the internet, we observe bad system logon performance in  
computer labs.


While looking into this, I discovered that in such cases the script  
share/debian-edu-config/tools/show-welcome-webpage does unnecessary  
wgets to the internet.


In this code section...

```
GETDEFAULTHOMEPAGE=$(/usr/share/debian-edu-config/tools/get-default-homepage  
|| true)


if [ "$GETDEFAULTHOMEPAGE" ] &&
echo "$PROFILE" | egrep -q  
'Main-Server|Workstation|Roaming-Workstation|LTSP-Server|Minimal' ; then

for lang in $(echo $LANGCODE | tr : " "); do
if wget -q -O /dev/null ${GETDEFAULTHOMEPAGE}index.html.$lang ; then
welcomeurl="${GETDEFAULTHOMEPAGE}index.html.$lang"
break
else
welcomeurl=$GETDEFAULTHOMEPAGE || true
fi
done
else
welcomeurl=http://www.skolelinux.org/
fi
```

... the wget to ${GETDEFAULTHOMEPAGE}index.html.$lang only makes sense  
if the queried host is www or www.intern. The LANGCODE based query is  
a very specific semantic provided on Debian Edu's main server for  
delivering localized welcome pages, but it is not at all a common  
thing for other websites.


Furthermore, I wonder if the show-welcome-page script can't be even  
more optimized so that this wget on every login could be avoided  
entirely.


Suggestion: instead of storing the  
:///index.html.LANGCODE URL in  
$HOME/.debian-edu/welcome-page-shown", we could also store the value  
retrieved via get-default-homepage (without appended LANGCODE) and be  
happy with that.


Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpRUKf3IxlaT.pgp
Description: Digitale PGP-Signatur

Bug#952589: libx11-dev: trying to overwrite '/usr/include/X11/extensions/XKBgeom.h', which is also in package x11proto-dev 2018.4-4

[Timo Aaltonen]

On 26.2.2020 19.57, Daniel Serpell wrote:
> Hi!
> 
> On Wed, Feb 26, 2020 at 1:27 PM Simon McVittie  wrote:
>>
>> On Wed, 26 Feb 2020 at 17:47:07 +0200, Timo Aaltonen wrote:
> 
>>> bah, I'll release a new xorgproto asap
>>
>> You'll probably need to give x11proto-dev a versioned Breaks on the older
>> libx11-dev versions that expected x11proto-dev to provide that header.
>>
> 
> Also, the headers moved from x11proto to other library packages, see
> https://gitlab.freedesktop.org/xorg/lib/libxvmc/-/commit/0fab90b409a3e4848603bdb6b438523038239f23
> for the corresponding move of vldXvMC.h to libxvmc-dev.

yes, libxvmc 1.0.12-1 fixed that


-- 
t

Bug#951800: CVE-2020-9273: buster affected

[Salvatore Bonaccorso]

Hi Hilmar,

On Wed, Feb 26, 2020 at 06:41:05PM +0100, Salvatore Bonaccorso wrote:
> Hi HIlmar,
> 
> On Tue, Feb 25, 2020 at 06:20:06PM +0100, Hilmar Preuße wrote:
> > On 2/22/20 10:58 PM, Salvatore Bonaccorso wrote:
> > > On Sat, Feb 22, 2020 at 09:29:34PM +0100, Hilmar Preuße wrote:
> > 
> > Hi Salvatore,
> > 
> > >> The fix for this issue (+ patch for two other issues) is already in the
> > >> buster branch on salsa. I planned to upload that ASAP. Not sure if it
> > >> will still happen this week.
> > > 
> > > Yes note I did upload both as (as said had a bit of time to work
> > > acutally on Debian these weekend dedicately). I have not released the
> > > DSA because I really would like to understand if we can verify the
> > > fix. But it his looks unfeasible in reasonable timeframe I will go
> > > ahead with the DSA. 
> > > 
> > Not sure, if I understood you correctly: has 1.3.5b-4+deb9u4 &
> > 1.3.6-4+deb10u4 been released and uploaded by you? I did not see the
> > package yet in the archive.
> > 
> > > That said, I might still miss something.
> 
> First, sorry for late reply, had two quite busy (working) days. I was
> not too clear, sorry about that. Yes, I did work on the update on the
> weekend actually, and was going to push the button, when I noticed
> there was a regression handled upstream. This is the reason I did not
> yet. And I was waiting for upstream to recieve some feedback, but I
> guess here I have to go without because until now I heard not back.
> 
> The upload which will go hit the archive will be both the initial
> commit and the bugfix on top (cf. #952557) so it would be great if you
> can then rebase on top then.
> 
> I realize I very badly communicated in this stance, maybe beeing
> overmotivated at a Debian event.
> 
> Find attached the debdiffs as they are now for release.

The DSA release happened yesterday evening as DSA 4635-1.

Regards,
Salvatore

Bug#898031: tracker.debian.org: display URL problems detected by Repology for debian_* repositories

[Paul Wise]

On Sun, 06 May 2018 12:14:21 +0800 Paul Wise wrote:

> so once Repology pull request #615 (adding per-package problem
> reports) is merged and deployed on the repology website

The PRs haven't been merged but they have been closed and further
discussion has moved to this issue:

https://github.com/repology/repology-webapp/issues/66

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#952664: mark libarchive-zip-perl Multi-Arch: foreign

[Helmut Grohne]

Package: libarchive-zip-perl
Version: 1.67-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:mimedefang

mimedefang cannot satisfy its cross Build-Depends, because its
dependency on libarchive-zip-perl is not satisfiable. It's an
Architecture: all package without maintainer scripts. The only
dependency on perl will be annotated :any once rebuilding with current
debhelper. That makes it eligible for being marked Multi-Arch: foreign.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru libarchive-zip-perl-1.67/debian/changelog 
libarchive-zip-perl-1.67/debian/changelog
--- libarchive-zip-perl-1.67/debian/changelog   2019-10-10 16:54:50.0 
+0200
+++ libarchive-zip-perl-1.67/debian/changelog   2020-02-27 06:29:15.0 
+0100
@@ -1,3 +1,10 @@
+libarchive-zip-perl (1.67-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libarchive-zip-perl Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 27 Feb 2020 06:29:15 +0100
+
 libarchive-zip-perl (1.67-1) unstable; urgency=medium
 
   * Import upstream version 1.67
diff --minimal -Nru libarchive-zip-perl-1.67/debian/control 
libarchive-zip-perl-1.67/debian/control
--- libarchive-zip-perl-1.67/debian/control 2019-10-10 16:54:50.0 
+0200
+++ libarchive-zip-perl-1.67/debian/control 2020-02-27 06:29:14.0 
+0100
@@ -18,6 +18,7 @@
 
 Package: libarchive-zip-perl
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${perl:Depends}
 Description: Perl module for manipulation of ZIP archives

Bug#937186: Being worked on upstream

[Wouter Verhelst]

control: forwarded 937186 https://github.com/OpenLightingProject/ola/issues/1506
thanks

ola currently doesn't have Python3 support yet. This is being worked on 
upstream.

Once the python3 support is available, I will upload a new package which
drops python2 and replaces it with the python3 equivalents.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Bug#925944: Re: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when reboot

[wglxy]

Hi, I found that the gnome-shell extension can not show the status of laptop 
cell charging. So I reinstalled the laptop-mode-tools, and changed the wired 
interface name from "eth0" to "enp0s31f6" in the file 
/etc/laptop-mode/conf.d/ethernet.conf as advice from Ritesh.

Then, I reboot several times, it seems running OK. I will try more times.



> -原始邮件-
> 发件人: "Ritesh Raj Sarraf" 
> 发送时间: 2020-02-27 01:56:04 (星期四)
> 收件人: wg...@china.com, 952...@bugs.debian.org
> 抄送: 925...@bugs.debian.org
> 主题: Re: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name 
> maybe changed when reboot
> 
> Control: serverity -1 important
> 
> 
> I am lowering the severity as this is common reflection of problems
> elsewhere disguising as a problem with laptop-mode-tools.
> 
> 
> Couple of things to mention:
> 
> * If you know of the persistent name for your interface, can you
> populate that into the /etc/laptop-mode/conf.d/ethernet.conf and see if
> that helps
> 
> * From the logs that you've shared on the bug report, I'm lost. That
> log is huge. laptop-mode-tools will apply power savings to ethernet
> device. On boot, this happens quite early on. And probably that is
> causing the problem. But I'd still like to see what holds the device so
> long that NetworkManager fails to rename it. Does disabling the
> `ethernet` module in laptop-mode-tools solve your problem ? If so, as a
> workaround you can start with disabling it. And then try to investigate
> what may be causing the device to remain busy for so long.
> 
> * There's a valid bug report #925944, where a side-effect of enabling
> power savings on the ethernet device results in NetworkManager not
> considering the device. I am not sure how that should be solved because
> how other tools (like NetworkManager, avahi etc) behave is beyond the
> scope. But, if the integration of these tools do not work proper,
> disabling one of the tools (like laptop-mode-tools) or a particular
> hardware power savings (like ethernet module), could be a viable
> option.
> 
> 
> Coming up with an ideal default is challenging and I struggle to find a
> balance. We do have /etc/laptop-mode/conf.d/board-specific/ . It is
> documented in the manpage.
> 
> 
> For the case of #925944, I think we should remove eth0 from the default
> list. Because most devices these days have a unique persistent name and
> it is best left to the user to find out the name and populate it in the
> configuration file. That is what my upload today, 1.73.1-2 does.
> 
> 
> On Wed, 2020-02-26 at 23:32 +0800, wg...@china.com wrote:
> > OK, thank you very much! I will wait for all things are fine again!
> > Thank you again!
> > 
> > 
> > 
> > > -原始邮件-
> > > 发件人: "Michael Biebl" 
> > > 发送时间: 2020-02-26 23:09:22 (星期三)
> > > 收件人: wg...@china.com, 952...@bugs.debian.org, 
> > > laptop-mode-to...@packages.debian.org
> > > 抄送: 
> > > 主题: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe
> > > changed when reboot
> > > 
> > > Control: reassign -1 laptop-mode-tools
> > > Control: retitle -1 lmt breaks network interface renaming
> > > Control: severity -1 serious
> > > 
> > > Am 26.02.20 um 16:01 schrieb wg...@china.com:
> > > > As your recommendation, I removed the laptop-mode-tools, it seems
> > > > that wired interface' name is correct for several boot. But if
> > > > there is no laptop-mode-tools, how I using its function for
> > > > saving power to laptop?
> > > 
> > > Don't use laptop-mode-tools. The kernel does it sufficiently well
> > > on
> > > it's own these days. I'm not actually sure what business
> > > laptop-mode-tools has with your network interfaces.
> > > 
> > > I'm going to reassign this bug report to laptop-mode-tools and
> > > bumping
> > > the severity to RC.
> > > 
> > > Michael
> > > 
> > > 
> > > 
> > > 
> -- 
> Ritesh Raj Sarraf | http://people.debian.org/~rrs
> Debian - The Universal Operating System

Bug#952622: myproxy: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 VERBOSE=1 returned exit code 2

[Mattias Ellert]

reassign 952622 src:procps 2:3.3.16-2
fixed 952622 procps/2:3.3.16-3
retitle 952622 procps does not provide /bin/kill - violates FHS specification
affects 952622 myproxy
stop

Section 3.4 of the Filesystem Hierarchy Standard (FHS) says:

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s04.html

The following commands, or symbolic links to commands, are
required in /bin:

In this list the command kill appears.



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

Bug#888705: abseil-cpp packaging

[GCS]

On Wed, Feb 26, 2020 at 10:28 PM Benjamin Barenblat  wrote:
> https://github.com/abseil/abseil-cpp/pull/628 will let you test against
> the gtest in Debian simply by passing `-DABSL_RUN_TESTS=ON
> -DABSL_USE_GOOGLETEST_HEAD=OFF` to CMake. It looks like I just missed
> the LTS release of a few hours ago, but just patching this in should be
> fine.
 That's very nice of you.

> I’ll try to have a look at the packaging in Salsa before the end of this
> week.
 Are you going to rename it to abseil-cpp (as Google has abseil-python
as well, make a disparity between the two)?
@Anton: No one would like to step on your toes - definitely not me -
still your last visible activity was two years ago. Please push your
changes if you may any ready.

Thanks,
Laszlo/GCS

Bug#952572: procps: move binaries back to /bin

[Paul Wise]

On Thu, 27 Feb 2020 07:17:39 +1100 Craig Small wrote:

> I think they all should be using a path rather than hard coding where ps
> is. But in any case that's what these other packages do. I'll revert the
> change.

Another option would be a compat symlink.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#938500: smalr: Python2 removal in sid/bullseye

[Scott Kitterman]

No upstream activity in two years.  It seems very unlikely a python3 port will 
appear.  This should probably be removed.

Scott K

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

Bug#937253: pbbarcode: Python2 removal in sid/bullseye

[Scott Kitterman]

This is dead upstream (the GitHub repository listed as the homepage for the 
package is marked "This repository has been archived by the owner. It is now 
read-only."  I think that's a strong sign there won't be a python3 port and 
the package should be removed.

Scott K

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

Bug#952663: lists.debian.org: incorrect encoding of "Québécois" in heading on debian-dug-quebec description page

[Paul Wise]

Package: lists.debian.org
Severity: normal

On the page for the debian-dug-quebec list, the heading contains an
encoding of "Québécois" that is not UTF-8, resulting in mojibake.
The other instance of this word is correctly UTF-8 encoded:

Discussion list for the Qu�b�cois Debian Community

Discussion list for the Québécois community without being tied to ...

https://lists.debian.org/debian-dug-quebec/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#952506: Re: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when reboot

[wglxy]

> -原始邮件-
> 发件人: "Ritesh Raj Sarraf" 
> 发送时间: 2020-02-27 01:56:04 (星期四)
> 收件人: wg...@china.com, 952...@bugs.debian.org
> 抄送: 925...@bugs.debian.org
> 主题: Re: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name 
> maybe changed when reboot
> 
> Control: serverity -1 important
> 
> 
> I am lowering the severity as this is common reflection of problems
> elsewhere disguising as a problem with laptop-mode-tools.
> 
> 
> Couple of things to mention:
> 
> * If you know of the persistent name for your interface, can you
> populate that into the /etc/laptop-mode/conf.d/ethernet.conf and see if
> that helps



I think it is not useful because that the first name of wired interface is 
eth0, and systemd change it to enpXXX soon. So laptop may set the interface by 
eth0 or enpXXX.





> 
> * From the logs that you've shared on the bug report, I'm lost. That
> log is huge. laptop-mode-tools will apply power savings to ethernet
> device. On boot, this happens quite early on. And probably that is
> causing the problem. But I'd still like to see what holds the device so
> long that NetworkManager fails to rename it. Does disabling the
> `ethernet` module in laptop-mode-tools solve your problem ? If so, as a
> workaround you can start with disabling it. And then try to investigate
> what may be causing the device to remain busy for so long.
> 
> * There's a valid bug report #925944, where a side-effect of enabling
> power savings on the ethernet device results in NetworkManager not
> considering the device. I am not sure how that should be solved because
> how other tools (like NetworkManager, avahi etc) behave is beyond the
> scope. But, if the integration of these tools do not work proper,
> disabling one of the tools (like laptop-mode-tools) or a particular
> hardware power savings (like ethernet module), could be a viable
> option.
> 
> 
> Coming up with an ideal default is challenging and I struggle to find a
> balance. We do have /etc/laptop-mode/conf.d/board-specific/ . It is
> documented in the manpage.
> 
> 
> For the case of #925944, I think we should remove eth0 from the default
> list. Because most devices these days have a unique persistent name and
> it is best left to the user to find out the name and populate it in the
> configuration file. That is what my upload today, 1.73.1-2 does.
> 
> 
> On Wed, 2020-02-26 at 23:32 +0800, wg...@china.com wrote:
> > OK, thank you very much! I will wait for all things are fine again!
> > Thank you again!
> > 
> > 
> > 
> > > -原始邮件-
> > > 发件人: "Michael Biebl" 
> > > 发送时间: 2020-02-26 23:09:22 (星期三)
> > > 收件人: wg...@china.com, 952...@bugs.debian.org, 
> > > laptop-mode-to...@packages.debian.org
> > > 抄送: 
> > > 主题: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe
> > > changed when reboot
> > > 
> > > Control: reassign -1 laptop-mode-tools
> > > Control: retitle -1 lmt breaks network interface renaming
> > > Control: severity -1 serious
> > > 
> > > Am 26.02.20 um 16:01 schrieb wg...@china.com:
> > > > As your recommendation, I removed the laptop-mode-tools, it seems
> > > > that wired interface' name is correct for several boot. But if
> > > > there is no laptop-mode-tools, how I using its function for
> > > > saving power to laptop?
> > > 
> > > Don't use laptop-mode-tools. The kernel does it sufficiently well
> > > on
> > > it's own these days. I'm not actually sure what business
> > > laptop-mode-tools has with your network interfaces.
> > > 
> > > I'm going to reassign this bug report to laptop-mode-tools and
> > > bumping
> > > the severity to RC.
> > > 
> > > Michael
> > > 
> > > 
> > > 
> > > 
> -- 
> Ritesh Raj Sarraf | http://people.debian.org/~rrs
> Debian - The Universal Operating System

Bug#941537: Solfege removal

[Anthony Fok]

Hi François,

On Mon, Nov 11, 2019 at 4:51 AM François Mazen  wrote:
> Lilypond and Solfege packages will be removed in about 14 days.
> As maintainer of Solfege, this will affect my work.
>
> Do you plan tu upload a new Lilypond package to avoid the automatic
> removal?
>
> If not, I can prepare a NMU. Just let me know.

Thank you for your message!  I suspect the reason that the patch /
merge request was merged, and yet no upload was made, is because of
yet another build error:

=
Error: /invalidfileaccess in --file--
Operand stack:
   
(/build/lilypond-2.19.81+really-2.18.2/out/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf)
  (r)
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--
--nostringval--   --nostringval--   false   1   %stopped_push   1990
1   3   %oparray_pop   1989   1   3   %oparray_pop   1988   1   3
%oparray_pop   --nostringval--   1977   1   3   %oparray_pop   1833
1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2
--nostringval--   --nostringval--   --nostringval--   2
%stopped_push   --nostringval--
Dictionary stack:
   --dict:734/1123(ro)(G)--   --dict:0/20(G)--   --dict:80/200(L)--
Current allocation mode is local
Last OS error: Permission denied
Current file position is 472


Instead of struggling with the venerable but old 2.18 version, I think
we can start packaging the 2.19.84, i.e. the "final pre-release test
version for the upcoming 2.20 stable release".

So the above is just an update of what is happening, and what is to come.  Fun!

Cheers,
Anthony

Bug#952481: texlive: mktexpk fails to create tcrm1000

[Norbert Preining]

tags 952481 + patch
thanks

Hi Holger,

to sum up several discussions on bugs in the babel greep driver, here is
a for now simple solution that should fix the build:

- add cm-super to the build deps
- patch build/stylesheets/dblatex.xsl to contain the following
  additional switch for Greek:

\setmainfont{FreeSerif}
\setsansfont{FreeSans}
\setmonofont{FreeMono}
\expandafter\def\csname 
v...@tuenc.def\endcsname{}


With this two changes I get a working(*) compilation and output using
buildone.sh.

(*) There is something broken in the xml->TeX conversion that is outside
of TeX. See the last page of the produced document. The xml document
contains stuff like

 some Greek text 

which is translated to the following complete rubbish in TeX:


\begin{lstlisting}[escapeinside={<:}{:>}][firstnumber=1,escapeinside={}{},moredelim={**[is][\bfseries]{}{}},moredelim={**[is][\itshape]{}{}},]
b'<:'Μb':>'b'<:'εb':>' b'<:'τb':>'b'<:'οb':>' 
b'<:'πb':>'b'<:'αb':>'b'<:'ρb':>'b'<:'όb':>'b'<:'νb':>' b'<:'ηb':>' Yoyodyne, 
Inc., b'<:'αb':>'b'<:'πb':>'b'<:'οb':>'


This is of dblatex doing and nothing related to TeX Live.

Best

Norbert

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

Bug#952555: azure-uamqp-python: please make the build reproducible

[Chris Lamb]

Hi Luca,

> > At a glance I cannot. However, I might suggest running it again; do
> > you get the same differences, if you know what I mean?
>
> The details look slightly different (reports are not 1:1 match), albeit
> in the same "areas".

Getcha. Sometimes these intermediate differences or lack thereof (ie.
they are deterministically unreproducible) can be instructive and
spark a clue as to their origin.


Best wishes,

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

Bug#951257: udevadm: please exit nonzero with "Running in chroot, ignoring request." when /proc is not mounted

[Trent W. Buck]

Michael Biebl wrote:
>>> [...] you'd have to convince upstream that this is a good idea [...]
>> Blergh, I'll have to make a github account [...]
> Any updates here?

Sorry, no.
This is relatively low priority for me.

Bug#952662: ITS: passwdqc

[Unit 193]

Source: passwdqc
Severity: important

Dear Maintainer,

I am hereby offering to co-maintain/salvage the package passwdqc, applying the 
following criteria:

 * Package maintainance seems to have been incative for more than a year.
 * There are several new releases available.
   - Most if not all open bugs could be closed with the new versions.
 * Direct emails to the maintainer have gone unanswered for many months.

I intend to maintain it under the pkg-security team.  My latest work is 
available in my git repo[0].


[0]: https://git.unit193.net/cgit/users/unit193/passwdqc.git/

~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

Bug#952661: dtkwm: Update symbols files for optional template symbols going missing

[Steve Langasek]

Package: dtkwm
Version: 2.0.12-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, the current dtkwm has failed to build on ppc64el and s390x
because a variety of template symbols have been optimized away on these
architectures with the current toolchain.

The attached patch marks these template symbols as optional, allowing the
package to build on all architectures in Ubuntu.

Please consider including this patch in Debian, which will make the package
build more portably.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dtkwm-2.0.12/debian/libdtkwm2.symbols 
dtkwm-2.0.12/debian/libdtkwm2.symbols
--- dtkwm-2.0.12/debian/libdtkwm2.symbols   2019-09-23 15:42:44.0 
-0700
+++ dtkwm-2.0.12/debian/libdtkwm2.symbols   2020-02-26 17:11:54.0 
-0800
@@ -44,10 +44,11 @@
  (c++)"Dtk::Wm::screenWindowsUtil@Base" 0.1.0~20170815
  (c++)"QByteArray::~QByteArray()@Base" 0.1.0~20170815
  (c++)"QList::~QList()@Base" 0.1.0~20170815
- (c++)"QList::append(QRect const&)@Base" 0.1.0~20170815
+ (c++|optional=template)"QList::append(QRect const&)@Base" 
0.1.0~20170815
  (c++)"QList::detach_helper_grow(int, int)@Base" 0.1.0~20170815
- (c++)"QList::detach_helper(int)@Base" 2.0.12
- (c++)"QList::~QList()@Base" 0.1.0~20170815
+ (c++|optional=template)"QList::detach_helper(int)@Base" 2.0.12
+ (c++|optional=template)"QList::~QList()@Base" 2.0.12
+ (c++|optional=template)"QList::~QList()@Base" 0.1.0~20170815
  (c++)"QList::append(QString const&)@Base" 0.1.0~20170815
  (c++)"QList::detach_helper_grow(int, int)@Base" 0.1.0~20170815
  (c++)"QList::~QList()@Base" 0.1.0~20170815
@@ -55,7 +56,7 @@
  (c++)"QList::detach_helper_grow(int, int)@Base" 0.1.0~20170815
  (c++)"QList::~QList()@Base" 0.1.0~20170815
  (c++)"QList::append(unsigned int const&)@Base" 0.1.0~20170815
- (c++)"QList::detach_helper(int)@Base" 0.1.0~20170815
+ (c++|optional=template)"QList::detach_helper(int)@Base" 
0.1.0~20170815
  (c++)"QList::detach_helper_grow(int, int)@Base" 0.1.0~20170815
  (c++)"QList::~QList()@Base" 0.1.0~20170815
  (c++)"QString::~QString()@Base" 0.1.0~20170815

Bug#952481: babel greek, MakeUpperCase, and \textalpha

[Norbert Preining]

Hi all,

another babel greek versus TU problem I guess:

\documentclass{article}
\usepackage[greek]{babel}
%\makeatletter
% \renewcommand*{\greekfontencoding}{TU}
%  \renewcommand*{\bbl@greek@fontencdef}{greek-euenc}
%  \renewcommand*{\LastDeclaredEncoding}{TU}
\begin{document}
\MakeUppercase  {\textalpha }
\end{document}


- without the makeatletter part
LGR encoding and "A" shows up
- with the makeatletter part
TU encoding and
! LaTeX Error: Command \textAlpha unavailable in encoding TU.

BTW, this is not only for the textAlpha, but for several others, too.

Is this a bug in th TU encoding?

Best

Norbert

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

Bug#952481: (fwd) Re: babel greep and missing characters in TL2019

[Norbert Preining]

Forward email that was not cced

- Forwarded message from Ulrike Fischer  -

> Date: Thu, 27 Feb 2020 00:33:40 +0100
> From: Ulrike Fischer 
> To: tex-l...@tug.org
> Subject: Re: babel greep and missing characters in TL2019
> 
> Am Thu, 27 Feb 2020 08:15:45 +0900 schrieb Norbert Preining:
> 
> 
> > we found that using babel greek somehow is broken in TL2019 (current
> > state), while in 2018 and 2017 it was working fine.
> 
> See https://github.com/latex3/babel/issues/48
> 
> I guess nobody notified the author ;-(
> 
> -- 
> Ulrike Fischer 
> https://www.troubleshooting-tex.de/
> 

- End forwarded message -

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

Bug#951587: ruby-batch-loader: FTBFS against ruby2.7: cannot load such file -- irb/ruby-token

[Daniel Leidert]

Am Donnerstag, den 27.02.2020, 00:44 +0100 schrieb Daniel Leidert:
> Am Mittwoch, den 26.02.2020, 23:59 +0100 schrieb Daniel Leidert:
> > Package: src:ruby-batch-loader
> > Followup-For: Bug #951587
> > 
> > The issue is in ruby-graphql which requires irb/ruby-token. There is a new
> > upstream version for graphql available. I'll check, if there is a fix for
> > us.
> 
> I can confirm that the latest version does not require it anymore.
> Unfortunately it turns out that getting the github sources and enabling the
> tests is not easy. So the quick way could be to import the gem sources of
> graphql and upload the latest release.

I got the github sources to build and test successfully on both Ruby2.5 and
Ruby2.7. The work is in the debian/experimental branch. I'll check the reverse
dependencies and upload if successfully tested.
https://salsa.debian.org/ruby-team/ruby-graphql/pipelines/112682
https://salsa.debian.org/ruby-team/ruby-graphql/-/tree/debian/experimental
https://salsa.debian.org/ruby-team/ruby-graphql/-/commits/debian/experimental

Regards, Daniel


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

Bug#952660: src:linux: macvlan multicast/broadcast regression in stretch

[Ben Hutchings]

Package: src:linux
Version: 4.9.210-1
Severity: important
Tags: upstream fixed-upstream patch

Linux 4.9.209 included:

commit 9b266c6c12b055d51f5004e9b7285a4c97627311
Author: Eric Dumazet 
Date:   Mon Jan 6 12:30:48 2020 -0800

macvlan: do not assume mac_header is set in macvlan_broadcast()

which fixed some TX cases but broke the RX case.  When handling a
received multicast or broadcast packet, macvlan_broadcast() now reads
the destination address from the wrong place.  The packets may then
fail to match the multicast filters that they should.  This is fixed
in 4.9.211 by:

commit bde7568224a8d1fca99d00ec3f35d9f8fdc50cc6
Author: Eric Dumazet 
Date:   Tue Jan 14 13:00:35 2020 -0800

macvlan: use skb_reset_mac_header() in macvlan_queue_xmit()

This is a major regression for VM hosts using macvlan/macvtap as
ARP and IPv6 neighbour discovery became quite unreliable.

Ben.

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

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

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#951587: [DRE-maint] Bug#951587: ruby-batch-loader: FTBFS against ruby2.7: cannot load such file -- irb/ruby-token

[Daniel Leidert]

Am Mittwoch, den 26.02.2020, 23:59 +0100 schrieb Daniel Leidert:
> Package: src:ruby-batch-loader
> Followup-For: Bug #951587
> 
> The issue is in ruby-graphql which requires irb/ruby-token. There is a new
> upstream version for graphql available. I'll check, if there is a fix for us.

I can confirm that the latest version does not require it anymore.
Unfortunately it turns out that getting the github sources and enabling the
tests is not easy. So the quick way could be to import the gem sources of
graphql and upload the latest release.

Regards, Daniel


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

Bug#952659: crash: cannot match kernel with kaslr enabled

[Jookia]

Package: crash
Version: 7.2.5-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I set up a fresh Debian 10 install on my i686 machine today.
I installed 'kdump-tools' and 'crash'
I added 'kernel.softlockup_panic=1' and 'kernel.hardlockup_panic=1' to
/etc/sysctl.conf
I rebooted so kdump-tools would add the 'crashkernel=384M-:128M'
argument to my kernel command line
I then triggered a crash by running 'sysctl kernel.sysrq=1 && echo c > 
/proc/sysrq-trigger'
It saved a crash to '/var/crash/202002270816/dump.202002270816'

I installed 'linux-image-4.19.0-8-686-pae-dbg'
I ran 'crash /usr/lib/debug/vmlinux-4.19.0-8-686-pae 
/var/crash/202002270816/dump.202002270816'
The following output happened:

 CUT HERE 

crash 7.2.5
Copyright (C) 2002-2019  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
 
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...

crash: page excluded: kernel virtual address: c1948564  type: "possible"
WARNING: cannot read cpu_possible_map
crash: page excluded: kernel virtual address: c194855c  type: "present"
WARNING: cannot read cpu_present_map
crash: page excluded: kernel virtual address: c1948560  type: "online"
WARNING: cannot read cpu_online_map
crash: page excluded: kernel virtual address: c1948558  type: "active"
WARNING: cannot read cpu_active_map
crash: page excluded: kernel virtual address: c18bb79c  type: "pv_init_ops"
crash: page excluded: kernel virtual address: c1a82268  type: 
"shadow_timekeeper xtime_sec"
crash: page excluded: kernel virtual address: c18af1c4  type: "init_uts_ns"
crash: /usr/lib/debug/boot/vmlinux-4.19.0-8-686-pae and 
/var/crash/202002270816/dump.202002270816 do not match!

Usage:

  crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
  crash [OPTION]... [NAMELIST]  (live system form)

Enter "crash -h" for details.

 CUT HERE 

I spent a while trying to figure out what was going on, but eventually I
found that booting with the 'nokaslr' argument fixes this issue.

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages crash depends on:
ii  binutils  2.31.1-16
ii  libc6 2.28-10
ii  liblzo2-2 2.10-0.1
ii  libncurses6   6.1+20181013-2+deb10u2
ii  libsnappy1v5  1.1.7-1
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  zlib1g1:1.2.11.dfsg-1

crash recommends no packages.

Versions of packages crash suggests:
ii  kexec-tools   1:2.0.18-1
ii  makedumpfile  1:1.6.5-1

-- no debconf information

Bug#952481: babel greep and missing characters in TL2019

[Norbert Preining]

Dear all,

(please keep all cc)

we found that using babel greek somehow is broken in TL2019 (current
state), while in 2018 and 2017 it was working fine.

The sample document is (extracted from a dblatex document of the
Debian installation guide in Greek):

\documentclass{article}
\usepackage{fontspec}
\setmainfont{FreeSerif}
\usepackage[greek]{babel}

\begin{document}
Το κείμενο αυτό περιέχει οδηγίες για το σύστημα Debian GNU/Linux 11
για την αρχιτεκτονική  64-{}bit PC (“amd64”). Περιέχει επίσης δείκτες
σε επιπλέον πληροφορίες και πληροφορία σχετικά με το πώς να 
αξιοποιήσετε κατά τον καλύτερο δυνατό τρόπο το καινούριο σας σύστημα Debian.
\end{document}

With TL2017 and 2018, all is fine.
With TL2019 lots of characters are missing:
LaTeX Font Warning: Font shape `LGR/FreeSerif(0)/m/n' undefined
(Font)  using `LGR/cmr/m/n' instead on input line 2.

) (/home/norbert/tl/2019/texmf-dist/tex/latex/base/ts1cmr.fd) [1] (./bla.aux)

LaTeX Font Warning: Some font shapes were not available, defaults substituted.

 )


When removing the 
\usepackager[greek]{babel}
then it works again in TL2019.

Can someone explain me what has changed, and what changes are necessary
to get these kind of documents working again?

Thanks

Norbert

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

Bug#951117: libecore1: .xsession-errors eats all disk space

[sergio]

> Now I can trigger the message

Great.

> but not a nonstop stream

Indeed.

> E prints it while opening and closing tilix, but not otherwise.

If there are no other windows, closing tilix stops this messages, but in
my session with other windows, closing tilix doesn't help, I need to
close other windows, but not all of them


> Moreover, I can only trigger it in the same session where I do all of
> the config.

Sorry, what config?


> After logging out and back in, the message is not printed.

Sure.


> Also, it doesn't happen under Xephyr at all.

I'm not able to reproduce it under Xephyr too.


> Sorry but I don't think I can really help further.  Maybe the upstream
folks
> would be able to track something down.

OK, I'll report this bug on phab.enlightenment.org but really I so tired
of E bugs, that I'm thinking to switch to another WM (possibly tiling
with good float mode support). The only thing stopping me is time I need
for choice and configuration.


-- 
sergio.

Bug#952481: texlive: mktexpk fails to create tcrm1000

[Norbert Preining]

One more thing:

On Wed, 26 Feb 2020, Holger Wansing wrote:
> When it comes to the build environment: the build also fails when trying to
> build the document in a plain unstable chroot with sbuild. So there is no

Not a sbuild guy here, but I tried in a clean chroot (cowbuilder) and
first it tried to create tcrm1000.600pk, but after adding
cm-super
to the installed packages it run through on the first run (the problems
I mentioned before are still present, though).

Did you add cm-super?

Best

Norbert

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

Bug#951587: ruby-batch-loader: FTBFS against ruby2.7: cannot load such file -- irb/ruby-token

[Daniel Leidert]

Package: src:ruby-batch-loader
Followup-For: Bug #951587

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The issue is in ruby-graphql which requires irb/ruby-token. There is a new
upstream version for graphql available. I'll check, if there is a fix for us.

Regards, Daniel


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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl5W+GkACgkQS80FZ8KW
0F047RAAxMQC8cNwUGg62cmsGn5MH2Dg9NHkEWoT3GCJLnlbr4/HQ/7x3C+uONHa
KpbasttE0R/uoeDiWl4A+VWBPLeAoNyTJBuIQmqCt/80yaVCRouGMVgGNepFBEu2
ReV/FXnFimo0BVH3kBIdwtdMbOatzH0vUIp7TyNzNV7DyadBOy++hXku5SKP14I3
cV9SmuBxEMNLAdIZ9UbG1laEzOeCGDpHTv+7V7SZQSXxauOgCNMOrnrL9f4ELDMF
7rkuhpuR8/la9TgQfv59o7xOmJfjD/U3k1IL9P+bZGnyPjfTgUYblvK7rWv1TxR/
3APWnYSzeu/ibu7WLhcNKTyE45BxefLV/cd8JOT3W8cKPOoOiUaO+R62sKbZSMv8
xvJpLUuSDTKyOP1Hh8fc2xJkGt2fMN9OltNvBBNOrUUujZEmmn5pld/DbMCtIHKv
T/R0NDQeqRdmvw4TRuhkEBotHyGZRPrXlTYwHsyM50ARzsZdbPyt55dVdppLcroN
Vwl6YskL0psVQ6DDhE6bfQQ0HpEHcuZ2Id9n8phXDnDNsMINlvo5kxxwMgedCU2m
jJy8UCfWNNhh8v0p7jgrif3mckTJtiBNOOO1LYCo43b7WTTR7NzkMGzyilxdK9Sw
jJn401fMWI2xwVOkv031Rcvao97Y8ldNr574yZwJV/aJvJKeZKw=
=luNq
-END PGP SIGNATURE-

Bug#952658: ITP: bustools -- tools for BUS single-cell RNAseq format

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: bustools -- tools for BUS single-cell RNAseq format
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: bustools
  Version : 0.39.3
  Upstream Author : , BUStools
* URL : https://bustools.github.io/
* License : BSD-2-Clause
  Programming Lang: C
  Description : tools for BUS single-cell RNAseq format
 RNAseq determines the number and the sequences of RNA in
 cellular tissue, and single-cell RNAseq (scRNAseq) does
 the same for individual cells.
 .
 The bustools have emerged as a central collection of
 tools that one applies to this kind of data.

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

Bug#952538: libwolfssl-dev: user_settings.h missing

[Otto Kekäläinen]

Hello!

Thanks for the patch! Now s390x fails with:

/<>/libmariadb/libmariadb/secure/openssl_crypt.c: At top level:
/<>/libmariadb/libmariadb/secure/openssl_crypt.c:21:10:
fatal error: openssl/evp.h: No such file or directory

https://launchpadlibrarian.net/466744534/buildlog_ubuntu-focal-s390x.mariadb-10.4_1%3A10.4.12-1~ubuntu20.04.1~1582756041.38e09b762_BUILDING.txt.gz

The original problem I am trying to solve is actually that the s390x
build fails even with the embedded WolfSSL:
https://jira.mariadb.org/browse/MDEV-21705

- Otto

Bug#952657: Document OpenSSL linking exception

[Bastian Germann]

Package: libqt5network5
Severity: normal

This package links to libssl. An OpenSSL linking exception is included
in src/network/doc/src/qtnetwork.qdoc and files in src/network/ssl but
it is not documented in debian/copyright. Please include it there.

Please also have a look at #924937. libqt5network5 has many GPL licensed
reverse dependencies, similar to libpq5, some of which do not have this
exception. Please consider configuring with -openssl-runtime because
that would make this issue less important for these reverse dependencies
Then one could install them without libssl, which would not make them a
derivative work of OpenSSL.

Bug#952609: libc6: pthread_rwlock_trywrlock hangs

[Aurelien Jarno]

On 2020-02-26 17:07, Ondřej Surý wrote:
> Package: libc6
> Version: 2.28-10
> Severity: important
> Tags: upstream patch
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Maintainer,
> 
> glibc after 2.26 (included) and before 2.30 hangs in pthread_rwlock_tryrwlock
> and pthread_rwlock_tryrdlock, the details and test cases can be found in
> https://sourceware.org/bugzilla/show_bug.cgi?id=23844#c14
> 
> This especially hits BIND 9.16 when using pthread_rwlock (instead of custom 
> ISC
> rwlock).
> 
> So, could you please fix this in buster?  For sid, this will get fixed as part
> of regular updated to 2.30,

This patch is already included since glibc 2.28-8 as part of pulling the
upstream stable branch. So it should already be fixed in buster, bullseye
and sid.

At least I confirm that the bug23844.wr.c testcase from the upstream bug
report sometimes fail with glibc 2.28-7, but never fails with glibc
2.28-8.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#952481: texlive: mktexpk fails to create tcrm1000

[Norbert Preining]

Hi Holger,

> I can build the exaxt same document in the same version without problems, 
> when 
> building on a Debian buster (stable) machine.

Yes, that is puzzling.

> > inject the argument
> > -recorder
> > to the xelatex call, and then send me also the file
> > install.el.profiled.fls
> 
> I fear this is rather complex for me, and since I am not a texlive expert,

Nothing to do with texlive, just with dblatex - which , and I think this
is the biggest problem, is unmaintained (QA) ..

> When it comes to the build environment: the build also fails when trying to
> build the document in a plain unstable chroot with sbuild. So there is no

Do you mean the manual build, or the build of the whole package?
That is, does the
buildone.sh ...
succeed/not succeed, or the direct call to
xelatex ...
What I want to say, maybe it is dblatex that is messing things up.

Best

Norbert

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

Bug#952655: debian-ports-archive-keyring: Expired Debian Ports Archive Automatic Signing Key (2020)

[Aurelien Jarno]

control: found -1 2018.12.27
control: notfound -1 2019.11.05
control: fixed -1 2019.11.05

On 2020-02-26 22:33, Przemyslaw Buczkowski wrote:
> Package: debian-ports-archive-keyring
> Version: 2019.11.05
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Debian Ports Archive Automatic Signing Key (2020) seems to have expired on 
> the 31st of January,

This is correct there was an issue with this key, its expiration date
was off by one year in version 2018.12.27 of the package. This has
already been fixed in version 2019.11.05 of the package, the expiration
date has been extended by one year.

> according to 
> http://gozer.rediris.es:11371/pks/lookup?search=0x84C573CD4E1AFD6C=vindex

This is clearly out of date. OTOH most keyservers stopped propagating
keys due to all the issue with the protocol, so it's kind of expected.

Alternatively the key can be downloaded from there:
https://www.ports.debian.org/archive_2020.key

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#952656: yarnpkg: should depend on ca-certificates

[Paolo Greppi]

Package: yarnpkg
Version: 1.21.1-1
Severity: normal

if ca-certificates is not installed, yarnpkg will hang or quit abruptly without
any error message / error status.

To reproduce:
sudo apt install yarnpkg
sudo apt remove ca-certificates
cd $(mktemp -d)
cat > package.json
{
  "dependencies": {
"highlight.js": "^9.17.1",
"reveal.js": "^3.8.0"
  }
}
^d
yarnpkg install --verbose
[crash]

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

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

Versions of packages yarnpkg depends on:
ii  node-asap  2.0.6-1
ii  node-babel-runtime 6.26.0+dfsg-3
ii  node-bytes 3.0.0-1
ii  node-camelcase 5.0.0-1
ii  node-chalk 2.3.0-2
ii  node-chownr1.1.1-1
ii  node-ci-info   1.1.2-1
ii  node-cli-table 0.3.1-1
ii  node-commander 2.12.2-3
ii  node-death 1.0.0-1
ii  node-debug 3.1.0-2
ii  node-deep-equal1.0.1-1
ii  node-detect-indent 5.0.0-1
ii  node-duplexify 3.6.1-1
ii  node-emoji 1.8.1-1
ii  node-fast-levenshtein  2.0.5-1
ii  node-glob  7.1.3-2
ii  node-imports-loader0.7.1-1
ii  node-ini   1.3.5-1
ii  node-inquirer  3.3.0-2
ii  node-invariant 2.2.2-1
ii  node-is-builtin-module 2.0.0-1
ii  node-js-yaml   3.13.1+dfsg-2~bpo10+1
ii  node-loud-rejection1.6.0-1
ii  node-micromatch2.3.11-1
ii  node-minimatch 3.0.4-3
ii  node-mkdirp0.5.1-1
ii  node-node-uuid 3.3.2-2
ii  node-object-path   0.11.4-2
ii  node-path-root 0.1.1-1
ii  node-proper-lockfile   2.0.1-1
ii  node-puka  1.0.0+dfsg-1
ii  node-pump  3.0.0-1
ii  node-pumpify   1.5.1-1
ii  node-read  1.0.7-1
ii  node-request   2.88.1-2
ii  node-request-capture-har   1.2.2-1
ii  node-resolve   1.5.0-1
ii  node-rimraf2.6.2-1
ii  node-semver5.5.1-1
ii  node-ssri  5.2.4-2
ii  node-strict-uri-encode 2.0.0-1
ii  node-strip-ansi4.0.0-1
ii  node-strip-bom 3.0.0-1
ii  node-tar-stream1.5.2-1
ii  node-validate-npm-package-license  3.0.1-1
ii  node-yn3.0.0-1
ii  nodejs 10.15.2~dfsg-2

yarnpkg recommends no packages.

yarnpkg suggests no packages.

-- no debconf information

Bug#459889: Re : Vorstellungsgespräch

[Mikhail M. Fridman]

 

-- 
Ich, Mikhail Fridman, habe Sie für eine Spende in Höhe von 5.000.000 USD
ausgewählt. Antworten Sie für weitere Details

Freundliche Grüße

Mikhail M. Fridman
 

Bug#952655: debian-ports-archive-keyring: Expired Debian Ports Archive Automatic Signing Key (2020)

[Przemyslaw Buczkowski]

Package: debian-ports-archive-keyring
Version: 2019.11.05
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Debian Ports Archive Automatic Signing Key (2020) seems to have expired on the 
31st of January,
according to 
http://gozer.rediris.es:11371/pks/lookup?search=0x84C573CD4E1AFD6C=vindex

Therefore, running apt-get update results in an error:
Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB]
Err:1 http://ftp.ports.debian.org/debian-ports sid InRelease
  The following signatures were invalid: EXPKEYSIG 84C573CD4E1AFD6C Debian 
Ports Archive Automatic Signing Key (2020) 

So I am unable to update my system.

Best wishes,
Prem

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 5.4.0-1-powerpc
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#952481: texlive: mktexpk fails to create tcrm1000

[Holger Wansing]

Hi,

Norbert Preining  wrote:
> Hi Holger,
> 
> On Wed, 26 Feb 2020, Norbert Preining wrote:
> > ~/DebInstaller/installation-guide/build] ./buildone.sh amd64 el pdf
> > Info: creating temporary profiled .xml file...
> > Info: creating .pdf file...
> > xelatex failed
> > install.el.profiled.tex:3389: Command \textBeta unavailable in encoding TU.
> 
> Actually, removing the -q, adding --debug to dblatex call, and not
> removing the temp dir in buildone.sh, I can see the code now.
> 
> It compiles here without any problems on the first run, but the second
> run brings the errors I mentioned, which come from
>   install.el.profiled.aux:\newlabel{preseed-bootparms}{{\MakeUppercase  
> {\textbeta \anw@true  \anw@print  \relax }.2.2}{52}{Χρήση παραμέτρων 
> εκκίνησης για την προρύθμιση ερωτήσεων}{subsection.alph1.Alph2.2.2}{}}
> Which means that \textbeta is uppercased to \textBeta.
> This seems to be some code that formats references.
> 
> But, the document is considerably broken, with lots of glyphs missing.
> 
> I see ***lots*** of warnings
>   Package Listings Warning: Text dropped after begin of listing on input 
> line 403
>   9.
> and also
>   No file LGRFreeMono(0).fd.
> 
> Has this all been working before, and was the output of the run actually
> showing a proper document?

I can build the exaxt same document in the same version without problems, when 
building on a Debian buster (stable) machine.
The results can also be found here:
https://d-i.debian.org/manual/
and there choose the Greek pdf from
https://d-i.debian.org/manual/el.amd64/install.el.pdf
The chapter which corresponds to the error you show above is "appendix b 2.2"
at page 85 of the PDF.
There, everything looks fine.
So, yes, this has worked before, when building with Debian buster, which has
texlive-* version 2018.20190227-2.


> Anyway, as I said, I cannot reproduce the error you have, so something
> is either missing, or strange. It would be great if you can somehow
> inject the argument
>   -recorder
> to the xelatex call, and then send me also the file
>   install.el.profiled.fls

I fear this is rather complex for me, and since I am not a texlive expert,
I cannot see how to inject this "-recorder" argument into xelatex's call,
sadly. Sorry. But see below...

> I attach the one I generated my manually calling
>   xelatex -recorder install.el.profiled.tex
> It gives the full list of files loaded during the TeX run (not the xdv
> => pdf conversion using dvipdfmx). There you see that
>   /usr/share/texlive/texmf-dist/fonts/tfm/jknappen/ec/tcrm1000.tfm
> is loaded, and this is the only one, and that is available in
>   texlive-base
> So if anything else is going on on your side, this is a serious
> misconfiguration of either the build system, or the environment in which
> dblatex calls xelatex.

When it comes to the build environment: the build also fails when trying to
build the document in a plain unstable chroot with sbuild. So there is no
special setting I have here on my machine, which is causing the problem.
It's default, plain unstable environment.
And the texlive-base package is installed, the font file
/usr/share/texlive/texmf-dist/fonts/tfm/jknappen/ec/tcrm1000.tfm
is existing.


Greetings
Holger

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

Bug#952654: ITP: golang-github-google-renameio -- provides a way to atomically create or replace a file or symbolic link

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-google-renameio
  Version : 0.1.0-1
  Upstream Author : Michael Stapelberg
  Copyright Owner : Google Inc.
* URL : https://github.com/google/renameio
* License : Apache-2.0
  Programming Lang: Go
  Description : provides a way to atomically create or replace a file or 
symbolic link

 The renameio Go package provides a way to atomically create or replace a
 file or symbolic link.
 .
 Atomicity vs durability
 ---
 .
 renameio concerns itself only with atomicity, i.e. making sure
 applications never see unexpected file content (a half-written file,
 or a 0-byte file).
 .
 As a practical example, consider https://manpages.debian.org/: if there
 is a power outage while the site is updating, we are okay with losing the
 manpages which were being rendered at the time of the power outage. They
 will be added in a later run of the software. We are not okay with having
 a manpage replaced by a 0-byte file under any circumstances, though.


Reason for packaging:
 * Required by honnef.co/go/tools,
   which in turn is required by golang-google-api v0.16.0 and above

Bug#952399: OpenSSL linking without license exception

[Steve McIntyre]

Marco...

On Tue, Feb 25, 2020 at 11:38:53PM +0100, Marco d'Itri wrote:
>
>For these reasons I have no interest and no plans to do anything about 
>this, and I am quite annoyed that I had to spend my time researching 
>these details and then explaining them to you.

Regardless of the technical details of the bug report here, what on
earth makes you think this text is reasonable when responding?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Bug#952653: hunspell-en-us: please replace "reprized" by "reprised"

[Vincent Lefevre]

Package: hunspell-en-us
Version: 1:2018.04.16-1
Severity: normal

According to various sources, including

  https://whichiscorrect.com/reprize-or-reprise/
  https://en.wiktionary.org/wiki/reprize

"reprize" is incorrect (obsolete), the correct spelling is "reprise".
This seems already known by hunspell-en-us:

zira:~> hunspell
Hunspell 1.7.0
reprise
*

reprize
& reprize 6 0: reprized, reprise, reprice, re prize, re-prize, prize

but for the simple past and past participle, this is the opposite:

zira:~> hunspell
Hunspell 1.7.0
reprised
& reprised 9 0: reprises, reprise, repriced, reprized, reprise d, reprieved, 
surprised, apprised, premised

reprized
+ prized

-- 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.4.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.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 hunspell-en-us depends on:
ii  dictionaries-common  1.28.1

hunspell-en-us recommends no packages.

Versions of packages hunspell-en-us suggests:
ii  hunspell   1.7.0-2+b1
pn  openoffice.org-hunspell | openoffice.org-core  

-- no debconf information

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

Bug#888705: abseil-cpp packaging

[Benjamin Barenblat]

On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) wrote:
> @Benjamin: may you ask its developers to use the system gtest libraries
> if only ABSL_RUN_TESTS set to ON?

On Tuesday, February 18, 2020, at  6:02 PM -0500, Benjamin Barenblat wrote:
> I have a preliminary version of such a patch, and I’ll try to get it
> finished and sent in the next day or two; that way, even if upstream
> lags taking it, we can import it and get the support we need.

It took me a bit longer than I’d hoped, but
https://github.com/abseil/abseil-cpp/pull/628 will let you test against
the gtest in Debian simply by passing `-DABSL_RUN_TESTS=ON
-DABSL_USE_GOOGLETEST_HEAD=OFF` to CMake. It looks like I just missed
the LTS release of a few hours ago, but just patching this in should be
fine.

I’ll try to have a look at the packaging in Salsa before the end of this
week.

Bug#952652: qiv won't open wmf files

[John]

Package: qiv
Version: 2.3.1-1+b1
Severity: normal
Tags: patch

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

Kernel: Linux 4.19
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-- End System Information

This bug applies to Debian 10, all architectures and probably applies to other
packages that should read windows metafiles, but certainly to qiv.

qiv --help says Valid image extensions:  ... .wmf ...
However  qiv file.wmf gives an error
"Unable to read file: Couldn't recognize the image file format ... "
This is because qiv uses libgdk-pixbuf2.0-0 for image loading.
However  libgdk-pixbuf2.0-0 needs file io-wmf.so in order to load wmf files.
In Debian 10 this file is part of the package libwmf0.2-7-gtk
Once this package is installed, qiv opens .wmf files.

Thus, qiv ought to depend on libwmf0.2-7-gtk, or else, arguably,
libgdk-pixbuf2.0-0 ought to depend on libwmf0.2-7-gtk.
I think the bug was caused by libwmf0.2-7-gtk being separated from
libwmf0.2-7 in Debian 10.

This is my first Debian bug report so I'm not familiar with how things are
done.  I'm reporting the bug using reportbug on Debian8 but I found & fixed the
bug on a Debian 10 system without internet access.  I've tried to make the
system info correct, although, since this is a package dependence problem,
I think it is almost all irrelevant.

I hope this is useful to others.

John Payne

Bug#951935: ufw: FTBFS: ERROR: test_get_iptables_version (tests.unit.test_util.UtilTestCase)

[Jamie Strandboge]

On Sun, 23 Feb 2020, Lucas Nussbaum wrote:

> Source: ufw
> Version: 0.36-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: buster sid
> Usertags: ftbfs-20200222 ftbfs-buster
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks for the report! Yes, this is known and the fix queued. I was
recently approved for Debian Maintainer and will do this as soon as I'm
given upload permissions (key added, in process of getting someone to
run dcut for me).

-- 
Jamie Strandboge | http://www.canonical.com

Bug#801509: Extra data before HTTP response data in uwsgi 2.0.7-1 in stable

[Azoo Almgatrb]

On Sun, 11 Oct 2015 15:53:56 +0200 Tom van Dijk wrote:
> Package: libapache2-mod-proxy-uwsgi
> Version: 2.0.7-1
> Severity: important
> 
> 
> 
> -- System Information:
> Debian Release: 8.2
> APT prefers stable
> APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.18.12 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages libapache2-mod-proxy-uwsgi depends on:
> ii apache2-bin [apache2-api-20120211] 2.4.10-10+deb8u3
> ii libapr1 1.5.1-3
> ii libaprutil1 1.5.4-1
> ii libc6 2.19-18+deb8u1
> 
> Versions of packages libapache2-mod-proxy-uwsgi recommends:
> ii uwsgi-core 2.0.7-1
> 
> Versions of packages libapache2-mod-proxy-uwsgi suggests:
> pn uwsgi 
> 
> -- no debconf information
> 
> This issue is solved by version above 2.0.9. Using version 2.0.11 from debian 
> unstable solves the issue.
> 
> 


أُرسلت من الـ iPhone

Bug#952651: mark libb-debug-perl Multi-Arch: foreign

[Helmut Grohne]

Package: libb-debug-perl
Version: 1.26-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:libdevel-cover-perl

libdevel-cover-perl cannot be cross built from source, because its
transitive dependency on libb-debug-perl is not satisfiable. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign. In this case such a marking seems mostly
warranted. libb-debug-perl has a perl dependency which is not yet
annotated :any, but I think it should as it is a pure perl module. It
doesn't have any maintainer scripts. As such the marking makes sense.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru libb-debug-perl-1.26/debian/changelog 
libb-debug-perl-1.26/debian/changelog
--- libb-debug-perl-1.26/debian/changelog   2018-05-17 16:34:26.0 
+0200
+++ libb-debug-perl-1.26/debian/changelog   2020-02-26 21:44:38.0 
+0100
@@ -1,3 +1,10 @@
+libb-debug-perl (1.26-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libb-debug-perl Multi-Arch: foreign. (closes: #-1)
+
+ -- Helmut Grohne   Wed, 26 Feb 2020 21:44:38 +0100
+
 libb-debug-perl (1.26-1) unstable; urgency=medium
 
   * Initial release (closes: #898932).
diff --minimal -Nru libb-debug-perl-1.26/debian/control 
libb-debug-perl-1.26/debian/control
--- libb-debug-perl-1.26/debian/control 2018-05-17 16:34:26.0 +0200
+++ libb-debug-perl-1.26/debian/control 2020-02-26 21:44:37.0 +0100
@@ -14,10 +14,11 @@
 
 Package: libb-debug-perl
 Architecture: all
+Multi-Arch: foreign
 # deprecate >= 0.03 is in core since 5.19.2
 Depends: ${misc:Depends},
  ${perl:Depends},
- perl (>= 5.19.2)
+ perl:any (>= 5.19.2)
 Description: module to print debug info about perl ops
  The B::Debug module walks the Perl syntax tree, printing debug info about
  ops.

Bug#952650: update symbols for nios2

[Helmut Grohne]

Source: libxcrypt
Version: 1:4.4.10-10
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libxcrypt fails to build for nios2 due to symbol errors. Please consider
including the following symbols file:

$ cat debian/libcrypt1.symbols.nios2
libcrypt.so.1 libcrypt1 #MINVER#
#include "libcrypt1.symbols.common"
 GLIBC_2.21@GLIBC_2.21 1:4.1.0
 crypt@GLIBC_2.21 1:4.1.0
 crypt_r@GLIBC_2.21 1:4.1.0
 encrypt@GLIBC_2.21 1:4.1.0
 encrypt_r@GLIBC_2.21 1:4.1.0
 fcrypt@GLIBC_2.21 1:4.1.0
 setkey@GLIBC_2.21 1:4.1.0
 setkey_r@GLIBC_2.21 1:4.1.0
$

Helmut

Bug#949763: python-azure: please consider uploading a new version

[Luca Boccassi]

Control: tags -1 pending

On Wed, 2020-02-12 at 17:41 +0100, Nicolas Dandrimont wrote:
> * Luca Boccassi <
> bl...@debian.org
> > [2020-01-30 23:04:29 +]:
> 
> > control: tags -1 patch
> > 
> > On Fri, 24 Jan 2020 17:04:36 + Luca Boccassi <
> > bl...@debian.org
> > >
> > wrote:
> > > Source: python-azure
> > > Version: 20181112+git-3
> > > Severity: wishlist
> > > Blocks: 930413
> > > 
> > > Dear Maintainer(s),
> > > 
> > > Please consider uploading the latest version of python-azure. It
> > > is
> > > needed for the upload of azure-cli.
> > > 
> > > If time is lacking, I'm happy to do an NMU.
> > > 
> > > Thank you!
> > 
> > Dear Maintainer(s),
> > 
> > I have opened MRs on Salsa to update the package:
> > 
> > https://salsa.debian.org/python-team/modules/python-azure/merge_requests/1
> > 
> > https://salsa.debian.org/python-team/modules/python-azure/merge_requests/2
> > 
> > https://salsa.debian.org/python-team/modules/python-azure/merge_requests/3
> > 
> > 
> > At the same time the MR also fixes build reproducibility.
> > 
> > dh_python indicates some missing dependencies, I'll check if they
> > are
> > mandatory or optional.
> > 
> > Unless there are any objections and/or plans to update the package
> > by
> > the maintainers, I plan to do a delayed NMU with these changes
> > later
> > next week once the deps are sorted. I'll send another notice with a
> > debdiff if/when I do so.
> 
> Hi,
> 
> Sorry for the delay responding! Please feel free to upload without
> (more)
> delay! I also suggest that you join the team so you can commit
> directly to the
> VCS (and add yourself as Uploader? *cough*).
> 
> If you really don't feel like it then I'll look at merging your stuff
> in.
> 
> Thanks for your work!

Hi,

All the new dependencies have just been accepted, so I'll upload
shortly without delay. I added myself to the uploaders list as
suggested, so I can help in the future.

I checked the group on Salsa but it looks like one cannot request to
join - could you please add me when you have a moment? I'll then merge
the MRs and push the tags.

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#952649: -uap-core: CVE-2020-5243

[Salvatore Bonaccorso]

Source: uap-core
Version: 20190213-2
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for uap-core.

CVE-2020-5243[0]:
| uap-core before 0.7.3 is vulnerable to a denial of service attack when
| processing crafted User-Agent strings. Some regexes are vulnerable to
| regular expression denial of service (REDoS) due to overlapping
| capture groups. This allows remote attackers to overload a server by
| setting the User-Agent header in an HTTP(S) request to maliciously
| crafted long strings. This has been patched in uap-core 0.7.3.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-5243
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5243
[1] 
https://github.com/ua-parser/uap-core/security/advisories/GHSA-cmcx-xhr8-3w9p

Regards,
Salvatore

Bug#952112: Fix in the future manpages-l10n package

[Jean-Philippe MENGUAL]

Hi,

Thanks for the report and the patch. I close the bug because:
- your patch was applied successfully
- it will be available in the next manpages-l10n package, merging 
manpages-fr and other packages, for French, German, and Polish.


We will take the opportunity to update the manpage too. So it will not 
be available immediately after the release of the new packages, but will 
be in some weeks in unstable.


Best regards

--
Jean-Philippe MENGUAL

Bug#952648: RM: firefox-esr/52.9.0esr-1~deb9u1 [mips mipsel mips64el] -- RoQA; missing B-D/FTBFS

[Andreas Beckmann]

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

firefox-esr 60+ has not been built on mips* for stretch due to lack of
the required rustc version (mipsel, mips64el) or a FTBFS (mips).
It seems to build fine in buster. 
Please remove the stale mips* binaries from stretch.

Andreas

Bug#952645: webext-ublock-origin: please consider packaging ublock origin 1.25 or later

[Martin Steigerwald]

Martin Steigerwald - 26.02.20, 21:06:50 CET:
> Package: webext-ublock-origin
> Version: 1.22.2+dfsg-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Please consider packaging uBlock Origin 1.25 or later for its
> protection against using CNAME's to bypass ad blockers:
> 
> https://www.ghacks.net/2020/02/26/if-you-run-ublock-origin-use-the-fir
> efox-version-as-it-offers-better-protection/

I am a bit confused about the right minimum version number. The ghacks 
article mentions 1.25. However on Github I find it in 1.41 beta release 
(which would likely not yet suitable for being packaged just yet).

https://github.com/gorhill/uMatrix/releases

Thanks,
Martin

> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200,
> 'experimental') Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.5.6-tp520 (SMP w/4 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
> 
> webext-ublock-origin depends on no packages.
> 
> Versions of packages webext-ublock-origin recommends:
> ii  chromium 80.0.3987.116-1
> ii  firefox  73.0.1-1+b1
> ii  firefox-esr  68.5.0esr-1+b1
> 
> Versions of packages webext-ublock-origin suggests:
> ii  ublock-origin-doc  1.22.2+dfsg-1
> 
> -- no debconf information


-- 
Martin

Bug#952645: webext-ublock-origin: please consider packaging ublock origin 1.25 or later

[Martin Steigerwald]

Martin Steigerwald - 26.02.20, 21:19:33 CET:
> Martin Steigerwald - 26.02.20, 21:06:50 CET:
> > Package: webext-ublock-origin
> > Version: 1.22.2+dfsg-1
> > Severity: wishlist
> > 
> > Dear Maintainer,
> > 
> > Please consider packaging uBlock Origin 1.25 or later for its
> > protection against using CNAME's to bypass ad blockers:
> > 
> > https://www.ghacks.net/2020/02/26/if-you-run-ublock-origin-use-the-f
> > ir efox-version-as-it-offers-better-protection/
> 
> I am a bit confused about the right minimum version number. The ghacks
> article mentions 1.25. However on Github I find it in 1.41 beta
> release (which would likely not yet suitable for being packaged just
> yet).
> 
> https://github.com/gorhill/uMatrix/releases

Scratch that, this was uMatrix. For uBlock Origin 1.25 seems to be 
right:

https://github.com/gorhill/uBlock/releases

Sorry for the noise.
-- 
Martin

Bug#952647: RM: firefox-esr/60.9.0esr-1~deb9u1 [armel] -- RoQA; version 68+ no longer supported on armel

[Andreas Beckmann]

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

firefox-esr 68+ is no longer supported on armel due to lack of the
required nodejs 8.11.
Please remove the stale binaries from stretch.


Andreas

Bug#919557: webext-umatrix: garbled display of toolbar menu in Firefox 64.0-1

[Martin Steigerwald]

Hi!

Is there any update regarding this?

I ponder to switch all web extensions to browser installed ones as I am 
not sure whether it is feasible to expect Debian web extension packages 
to be up-to-date and in a working condition. I'd love to have these 
centrally updated by apt, but it seems it is challenging to get this 
right and there I bet there are only a few people volunteering to 
maintain those Debian packages.

Ciao,
-- 
Martin

Bug#952572: procps: move binaries back to /bin

[Craig Small]

I think they all should be using a path rather than hard coding where ps
is. But in any case that's what these other packages do. I'll revert the
change.

 - Craig


On Wed, 26 Feb. 2020, 7:45 pm Thorsten Glaser,  wrote:

> Package: procps
> Version: 2:3.3.16-2
> Severity: important
>
> I just upgraded procps from 2:3.3.16-1+b1 to 2:3.3.16-2 and noticed
> the following regression — only the first, of many to probably come:
>
> tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/postgresql stop
> Can't exec "/bin/ps": No such file or directory at
> /usr/share/perl5/PgCommon.pm line 613.
> Error: Could not exec /bin/ps
> No PostgreSQL clusters exist; see "man pg_createcluster" ... (warning).
> tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/postgresql start
> Can't exec "/bin/ps": No such file or directory at
> /usr/share/perl5/PgCommon.pm line 613.
> Error: Could not exec /bin/ps
> No PostgreSQL clusters exist; see "man pg_createcluster" ... (warning).
>
> There’s a TC decision to keep supporting not-usrmerged systems, so
> please DON’T⚠ just randomly move binaries around. In particular, some
> binaries like /bin/ed are required by POSIX to live in /bin if they
> are at all installed and others are most likely expected there.
>
> I’d even consider this RC (breaks unrelated software)…
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
>
> Versions of packages procps depends on:
> ii  init-system-helpers  1.57
> ii  libc62.29-10
> ii  libncurses6  6.1+20191019-1
> ii  libncursesw6 6.1+20191019-1
> ii  libprocps8   2:3.3.16-1+b1
> ii  libtinfo66.1+20191019-1
> ii  lsb-base 11.1.0
>
> Versions of packages procps recommends:
> ii  psmisc  23.3-1
>
> procps suggests no packages.
>
> -- no debconf information
>

Bug#952646: RFS: bwbasic/2.20pl2-12 -- Bywater BASIC Interpreter

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: bwbasic
   Version : 2.20pl2-12
   Upstream Author : Ted A. Campbell 
 * URL : http://sourceforge.net/projects/bwbasic/
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/bwbasic
   Section : interpreters

It builds those binary packages:

  bwbasic - Bywater BASIC Interpreter

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bwbasic/bwbasic_2.20pl2-12.dsc

Changes since the last upload:

   * QA upload.
   * Import diff in quilt format.
   * Update source format to 3.0.
   * Orphan the package. (See: #848568)
   * Update Standards-Version to 4.5.0.
   * Update compat level to 12.
 - Disable autoreconf with updated compat level.
   * Add Vcs link to salsa.
   * Fix FTBFS with clang. (Closes: #686542)
   * Enable debug for debug package.


-- 
Regards
Sudip

Bug#952645: webext-ublock-origin: please consider packaging ublock origin 1.25 or later

[Martin Steigerwald]

Package: webext-ublock-origin
Version: 1.22.2+dfsg-1
Severity: wishlist

Dear Maintainer,

Please consider packaging uBlock Origin 1.25 or later for its protection
against using CNAME's to bypass ad blockers:

https://www.ghacks.net/2020/02/26/if-you-run-ublock-origin-use-the-firefox-version-as-it-offers-better-protection/

Thanks,
Martin

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

Kernel: Linux 5.5.6-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

webext-ublock-origin depends on no packages.

Versions of packages webext-ublock-origin recommends:
ii  chromium 80.0.3987.116-1
ii  firefox  73.0.1-1+b1
ii  firefox-esr  68.5.0esr-1+b1

Versions of packages webext-ublock-origin suggests:
ii  ublock-origin-doc  1.22.2+dfsg-1

-- no debconf information

Bug#952625: libixion: FTBFS: configure: error: Package requirements (spdlog >= 0.16.0) were not met

[Rene Engelhard]

retitle 952625 libspdlog-dev: needs to Depend on libfmt-dev (>= 6.1.2+ds-1) 
(Requires: fmt)
thanks

Hi,

On Wed, Feb 26, 2020 at 08:30:29PM +0100, Eugene V. Lyubimkin wrote:
> [...]
> > Or fmt gets a .pc file (Cced.)
> 
> Thanks for the message. Upstream started to provide .pc-file in relatively 
> recent versions.

Good.

> With libfmt-dev from experimental (and soon in unstable), [...]

Thanks for the upload.

So libspdlog-dev needs to Depend on this version.

Regards,

Rene

Bug#952625: libixion: FTBFS: configure: error: Package requirements (spdlog >= 0.16.0) were not met

[Eugene V. Lyubimkin]

Hi,

Rene Engelhard kirjoitti 26.2.2020 klo 18.49:
[...]
>> libfmt-dev does not have a .pc file. Thus this isn't resolvable.
>>
>> root@frodo:/# pkg-config --cflags fmt
>> Package fmt was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `fmt.pc'
>> to the PKG_CONFIG_PATH environment variable
>> No package 'fmt' found
>>
>> -> bug in spdlog
> 
> Commenting out the above line of course works.
> 
> It seems to me that libfmt-dev is header-only or static? (-dev doesn't
> depend on a fmt shared library). So that means that it could safely be
> removed for the header-only usecase.

It is correct that as of moment libfmt-dev provides a static library only, due 
to
a small library size plus still somewhat frequent API changes.

[...]
> Or fmt gets a .pc file (Cced.)

Thanks for the message. Upstream started to provide .pc-file in relatively 
recent versions.
With libfmt-dev from experimental (and soon in unstable), "pkg-config --cflags 
fmt" works.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#952572: procps: move binaries back to /bin

[Patrice Duroux]

Hi,
Or do not hesitate to use Debian Code Search[1] for more occurrences! ;-)
In my case it breaks at least the following script:
environment-modules: /etc/profile.d/modules.sh

Thanks,
Patrice

[1] https://codesearch.debian.net/

Bug#927145: digikam: Digikam should depend on libhdf5-100

[Andreas Beckmann]

Followup-For: Bug #927145
Control: reassign -1 src:hdf5 1.10.5+repack-1~exp1
Control: affects -1 + src:digikam
Control: close -1 1.10.5+repack-1~exp6

> digikam: error while loading shared libraries:
> libhdf5_serial_hl.so.100: cannot open shared object file: No such file
> or directory

libhdf5-103 was split in 1.10.5+repack-1~exp1 and the "crippled" package
was renamed to libhdf5-103-1 in 1.10.5+repack-1~exp6 to force a transition.

Andreas

Bug#952644: ludevit: out-of-sync versions between testing and unstable

[Boyuan Yang]

Source: ludevit
Version: 9-1
Severity: serious
Justification: out-of-sync unstable-to-testing
X-Debbugs-CC: gara...@debian.org

Dear package ludevit maintainer,

Thanks for converting your package from python2 to python3. However, the
latest upload of package ludevit was not a source-only upload. As a result, it
did not migrate to Testing.

According to
https://lists.debian.org/debian-devel-announce/2020/02/msg5.html ,
packages that are out-of-sync between testing and unstable for more than 60
days are considered as having a Release Critical bug. Your package has been
out-of-sync for 176 days thus the bug severity has been set to "serious".

Please consider making another source-only upload to allow testing migration
according to https://wiki.debian.org/SourceOnlyUpload . Feel free to let me
know if you need any help (including NMU). Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#952643: purple-rocketchat: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: purple-rocketchat
Severity: important
Version: 0.1~git20190218.826990b48f41-1
X-Debbugs-CC: naturesha...@debian.org

Dear package purple-rocketchat maintainer,

The latest upload of your package was not a source-only upload. As a
result, it did not migrate to Testing.

Please consider making another source-only upload to allow testing migration
according to https://wiki.debian.org/SourceOnlyUpload . Feel free to let me
know if you need any help. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#952603: python-tinyalign: license of buildwheels.sh is CC0

[Sean Whitton]

Hello Andreas,

On Wed 26 Feb 2020 at 05:00PM +01, Andreas Tille wrote:

> Hi Sean,
>
> On Wed, Feb 26, 2020 at 08:18:54AM -0700, Sean Whitton wrote:
>> Following the GitHub trail suggests that buildwheels.sh has license CC0
>> not Expat.
>
> Do you have a link where we can get Copyright and license from?

https://github.com/pypa/python-manylinux-demo is the repo mentioned in
the script; that's where I looked.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#952642: libgdiplus: out-of-sync versions between testing and unstable

[Boyuan Yang]

Source: libgdiplus
Version: 6.0.4+dfsg-1
Severity: serious
Justification: out-of-sync unstable-to-testing
X-Debbugs-CC: mee...@debian.org direct...@debian.org sl...@debian.org

Dear Mono Team,

The latest upload of package libgdiplus was not a source-only upload. As a
result, it did not migrate to Testing.

According to
https://lists.debian.org/debian-devel-announce/2020/02/msg5.html ,
packages that are out-of-sync between testing and unstable for more than 60
days are considered as having a Release Critical bug. Your package has been
out-of-sync for 134 days thus the bug severity has been set to "serious".

Please consider making another source-only upload to allow testing migration
according to https://wiki.debian.org/SourceOnlyUpload . Feel free to let me
know if you need any help (including NMU). Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#950684: Debian Bug #950684

[Johannes Schauer]

Hi,

On Sat, 22 Feb 2020 17:45:36 +0100 Johannes Schauer  wrote:
> Quoting Jörg Frings-Fürst (2020-02-22 17:36:10)
> > Am Samstag, den 22.02.2020, 17:17 +0100 schrieb Johannes Schauer:
> > > Control: severity -1 important
> > > 
> > > Quoting Johannes Schauer (2020-02-22 17:05:47)
> > > > Quoting Jörg Frings-Fürst (2020-02-22 16:48:52)
> > > > > > please show me evidence of that.
> > > > > > 
> > > > > > Setting a bug severity to serious means that sbuild will be
> > > > > > removed from
> > > > > > testing in March. You should have evidence before such a
> > > > > > drastic measure is
> > > > > > taken.
> > > > > All packages that directly or indirectly have systemd as build
> > > > > depend can no
> > > > > longer be compiled. I think that is reason enough.
> > > > 
> > > > Indeed I now see the problem myself.
> > > > 
> > > > Can you confirm something for me?
> > > > 
> > > > Above you quote an sbuild-createchroot command. Could you run the
> > > > same command
> > > > on your machine again but with --debootstrap=mmdebstrap in it?
> > > > 
> > > > Because for me, that fixes the problem. This suggests that the
> > > > problem is not
> > > > with sbuild but with the program that creates the chroot:
> > > > debootstrap
> > > 
> > > something else you can try: Instead of adding --
> > > debootstrap=mmdebstrap try
> > > adding --no-merged-usr to your sbuild-createchroot invocation. This
> > > also fixed
> > > the problem for me.
> > > 
> > > So it seems whatever it is, and whoever is at fault, this problem is
> > > not
> > > severity "serious", thus lowering severity accordingly.
> > > 
> > 
> > No. Also with a schroot build with --no-merged-usr I get:
> 
> did you also try with --debootstrap=mmdebstrap instead of --no-merged-usr?

could you follow up on this?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#952617: haskell-cmdargs: FTBFS: ln: extra operand 'debian/libghc-cmdargs-doc/usr/lib/ghc-doc/hoogle/libghc-cmdargs-doc.txt'

[Ilias Tsitsimpis]

Control: tags -1 + pending

On Wed, Feb 26, 2020 at 06:11PM, Lucas Nussbaum wrote:
> Other packages failed to build with a similar error, FYI:
> 
> [...]

Thanks, this is really helpful!

Testing a fix[1] right now, and if everything goes well, I will push it
to unstable.

[1] https://salsa.debian.org/haskell-team/haskell-devscripts/-/commit/57fe76632d

-- 
Ilias

Bug#952572: procps: move binaries back to /bin

[Christoph Berg]

Another place where things must be called with absolute path:

/lib/systemd/system $ grep bin/kill *
gdm3.service:ExecReload=/bin/kill -SIGHUP $MAINPID
gdm.service:ExecReload=/bin/kill -SIGHUP $MAINPID
network-manager.service:#ExecReload=/bin/kill -HUP $MAINPID
NetworkManager.service:#ExecReload=/bin/kill -HUP $MAINPID
openvpn@.service:ExecReload=/bin/kill -HUP $MAINPID
prometheus-node-exporter.service:ExecReload=/bin/kill -HUP $MAINPID
smartmontools.service:ExecReload=/bin/kill -HUP $MAINPID
ssh.service:ExecReload=/bin/kill -HUP $MAINPID
thinkfan.service:ExecReload=/bin/kill -HUP $MAINPID
tor@default.service:ExecReload=/bin/kill -HUP ${MAINPID}
tor@.service:ExecReload=/bin/kill -HUP ${MAINPID}
unbound.service:ExecReload=+/bin/kill -HUP $MAINPID

Please revert this change, or at least put a compat symlink in /bin in
place.

Christoph

Bug#952641: scipy: What is the license of scipy/stats/stats.py?

[Diane Trout]

Source: scipy
Severity: serious
Tags: upstream
Justification: Debian policy 2.1 "Debian Freee Software Guidelines"

Dear Maintainer,

While reviewing the dask source (which is also affected by this bug) I noticed
this header in scipy/stats/stats.py

# Copyright 2002 Gary Strangman.  All rights reserved
# Copyright 2002-2016 The SciPy Developers
#
# The original code from Gary Strangman was heavily adapted for
# use in SciPy by Travis Oliphant.  The original code came with the
# following disclaimer:
#
# This software is provided "as-is".  There are no expressed or implied
# warranties of any kind, including, but not limited to, the warranties
# of merchantability and fitness for a given application.  In no event
# shall Gary Strangman be liable for any direct, indirect, incidental,
# special, exemplary or consequential damages (including, but not limited
# to, loss of use, data or profits, or business interruption) however
# caused and on any theory of liability, whether in contract, strict
# liability or tort (including negligence or otherwise) arising in any way
# out of the use of this software, even if advised of the possibility of
# such damage.

Viewable at
https://salsa.debian.org/python-
team/modules/scipy/-/blob/master/scipy/stats/stats.py

The initial copyright as written says "all rights reserved" and the disclaimer
does not seem to include any rights to redistribute, which would be a violation
of the DFSG.

I decided to go look up the original stats.py module by Gary Strangman, and the
original site no longer exists.
http://www.nmr.mgh.harvard.edu/Neural_Systems_Group/gary/python/stats.py

I picked a random version of it from archive.org which lists a GPL-2 license
and has the same disclaimer.
https://web.archive.org/web/20051224003609/http://www.nmr.mgh.harvard.edu/Neural_Systems_Group/gary/python/stats.py

# Copyright (c) 1999-2002 Gary Strangman; All Rights Reserved.
#
# This software is distributable under the terms of the GNU
# General Public License (GPL) v2, the text of which can be found at
# http://www.gnu.org/copyleft/gpl.html. Installing, importing or otherwise
# using this module constitutes acceptance of the terms of this License.
#
# Disclaimer
#
# This software is provided "as-is".  There are no expressed or implied
# warranties of any kind, including, but not limited to, the warranties
# of merchantability and fittness for a given application.  In no event
# shall Gary Strangman be liable for any direct, indirect, incidental,
# special, exemplary or consequential damages (including, but not limited
# to, loss of use, data or profits, or business interruption) however
# caused and on any theory of liability, whether in contract, strict
# liability or tort (including negligence or otherwise) arising in any way
# out of the use of this software, even if advised of the possibility of
# such damage.
#
# Comments and/or additions are welcome (send e-mail to:
# str...@nmr.mgh.harvard.edu).
#
"""

I didn't find a specific license statement about stats.py in scipy's
LICENSES.txt,

After digging I did find a mention that stats.py was relicensed as MIT as part
of statslib in 2007.
https://code.google.com/archive/p/python-statlib/

So I think everything is fine, but I think there should be a better record of
everything being fine.

Diane



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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#952639: src:budgie-desktop: Compile using mutter-6

[Marco Trevisan]

Il 26/02/20 19:13, David Mohammed ha scritto:
> Thx. Has mutter 6 been uploaded yet? If so... experimental or unstable?

Yes, it's in experimental so far.

mutter (3.35.91-1) experimental

Bug#952640: ITP: armnn -- Arm NN is an inference engine for CPUs, GPUs and NPUs

[Wookey]

Package: wnpp
Severity: wishlist
Owner: Wookey 

* Package name: armnn
  Version : 19.11
  Upstream Author : ARM Ltd
* URL : https://github.com/ARM-software/armnn
* License : MIT
  Programming Lang: C++
  Description : Arm NN is an inference engine for CPUs, GPUs and NPUs

 Arm NN is a set of tools that enables machine learning workloads on
 Arm hardware. It provides a bridge between existing neural network
 frameworks and whatever hardware is available: Cortex-A CPUs, Mali
 GPUs and Ethos NPUs. It utilizes the Arm Compute Library to target
 these programmable cores, as efficiently as possible. Arm NN does
 not provide support for Cortex-M CPUs.
 .
 The package is only available for arm64 and armhf architectures.

 This release supports Caffe, TensorFlow, TensorFlow Lite, and ONNX.
 Arm NN takes networks from these frameworks, translates them
 to the internal Arm NN format and then, through the Arm Compute Library,
 deploys them efficiently on Cortex-A CPUs, and, if present, Mali GPUs
 such as the Mali-G71 and Mali-G72. 

This package is part of the machine learning stack (on arm).
arm-compute-library, armnn, tvm, onnx etc.

It is developed under the Linaro Machine Intelligence Initiative 
(see mlplatform.org).

Bug#952639: src:budgie-desktop: Compile using mutter-6

[David Mohammed]

Thx. Has mutter 6 been uploaded yet? If so... experimental or unstable?

On Wed, 26 Feb 2020, 18:06 Marco Trevisan,  wrote:

> Source: budgie-desktop
> Severity: important
> Tags: patch
>
> Dear Maintainer,
>
> I'm attaching the debdiff to get budgie-desktop to compile with mutter-6
>

Bug#952559: RFS: telegram-desktop/1.9.14+ds-2 -- fast and secure messaging application

[Nicholas Guriev]

On Wed, 2020-02-26 at 10:37 -0500, Boyuan Yang wrote:
> I'm not sure how much of Debian's modifications can be merged back to upstream
> but hopefully upstream may get those patches.

Ilya Fedin already sent his patch[1] to upstream. At the time, they have still
not merged the pull request, and there is no any response from them.

I mentioned this pull request in a commit message in the Git repository for the
package. But unfortunately, it has not reflected in the .debian.tar.xz archive.

 [1]: 
https://github.com/lxqt/lxqt-qtplugin/pull/52/commits/74b869accd73bd6eac5985b523d0e9ad050fa332

Bug#952589: libx11-dev: trying to overwrite '/usr/include/X11/extensions/XKBgeom.h', which is also in package x11proto-dev 2018.4-4

[Daniel Serpell]

Hi!

On Wed, Feb 26, 2020 at 1:27 PM Simon McVittie  wrote:
>
> On Wed, 26 Feb 2020 at 17:47:07 +0200, Timo Aaltonen wrote:

> > bah, I'll release a new xorgproto asap
>
> You'll probably need to give x11proto-dev a versioned Breaks on the older
> libx11-dev versions that expected x11proto-dev to provide that header.
>

Also, the headers moved from x11proto to other library packages, see
https://gitlab.freedesktop.org/xorg/lib/libxvmc/-/commit/0fab90b409a3e4848603bdb6b438523038239f23
for the corresponding move of vldXvMC.h to libxvmc-dev.

Regards,
Daniel.

Bug#925944: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when reboot

[Ritesh Raj Sarraf]

Control: serverity -1 important


I am lowering the severity as this is common reflection of problems
elsewhere disguising as a problem with laptop-mode-tools.


Couple of things to mention:

* If you know of the persistent name for your interface, can you
populate that into the /etc/laptop-mode/conf.d/ethernet.conf and see if
that helps

* From the logs that you've shared on the bug report, I'm lost. That
log is huge. laptop-mode-tools will apply power savings to ethernet
device. On boot, this happens quite early on. And probably that is
causing the problem. But I'd still like to see what holds the device so
long that NetworkManager fails to rename it. Does disabling the
`ethernet` module in laptop-mode-tools solve your problem ? If so, as a
workaround you can start with disabling it. And then try to investigate
what may be causing the device to remain busy for so long.

* There's a valid bug report #925944, where a side-effect of enabling
power savings on the ethernet device results in NetworkManager not
considering the device. I am not sure how that should be solved because
how other tools (like NetworkManager, avahi etc) behave is beyond the
scope. But, if the integration of these tools do not work proper,
disabling one of the tools (like laptop-mode-tools) or a particular
hardware power savings (like ethernet module), could be a viable
option.


Coming up with an ideal default is challenging and I struggle to find a
balance. We do have /etc/laptop-mode/conf.d/board-specific/ . It is
documented in the manpage.


For the case of #925944, I think we should remove eth0 from the default
list. Because most devices these days have a unique persistent name and
it is best left to the user to find out the name and populate it in the
configuration file. That is what my upload today, 1.73.1-2 does.


On Wed, 2020-02-26 at 23:32 +0800, wg...@china.com wrote:
> OK, thank you very much! I will wait for all things are fine again!
> Thank you again!
> 
> 
> 
> > -原始邮件-
> > 发件人: "Michael Biebl" 
> > 发送时间: 2020-02-26 23:09:22 (星期三)
> > 收件人: wg...@china.com, 952...@bugs.debian.org, 
> > laptop-mode-to...@packages.debian.org
> > 抄送: 
> > 主题: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe
> > changed when reboot
> > 
> > Control: reassign -1 laptop-mode-tools
> > Control: retitle -1 lmt breaks network interface renaming
> > Control: severity -1 serious
> > 
> > Am 26.02.20 um 16:01 schrieb wg...@china.com:
> > > As your recommendation, I removed the laptop-mode-tools, it seems
> > > that wired interface' name is correct for several boot. But if
> > > there is no laptop-mode-tools, how I using its function for
> > > saving power to laptop?
> > 
> > Don't use laptop-mode-tools. The kernel does it sufficiently well
> > on
> > it's own these days. I'm not actually sure what business
> > laptop-mode-tools has with your network interfaces.
> > 
> > I'm going to reassign this bug report to laptop-mode-tools and
> > bumping
> > the severity to RC.
> > 
> > Michael
> > 
> > 
> > 
> > 
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#952335: uglify-js: FTBFS: ERROR: `m` is not a supported option

[Xavier]

Le 25/02/2020 à 22:15, Xavier a écrit :
> Le 25/02/2020 à 19:15, Jonas Smedegaard a écrit :
>> control: reassign -1 node-commander
>> control: affects -1 uglify-js
>>
>> Quoting Xavier (2020-02-25 18:43:53)
>>> Le 23/02/2020 à 14:31, Lucas Nussbaum a écrit :
 During a rebuild of all packages in sid, your package failed to 
 build on amd64.
>>>
>>> At least uglify-js (https://salsa.debian.org/js-team/uglifyjs) is 
>>> incompatible with node-commander 4
>>
>> Then it seems node-commander upgrade (done by you, Xavier) was badly 
>> coordinated and should be reverted.
>>
>>  - Jonas
> 
> debci did not report this because package was already broken. Rolling
> back does not fix all (that's why I wrote "at least").
> Reverting node-commander update may break a lot of packages:
> 
> node-commander
> Reverse Depends:
>   mocha
>   uglifyjs
>   yarnpkg
>   node-ws
>   uglifyjs.terser
>   node-d3-dsv
>   node-jade
>   node-express-generator
>   node-babel-cli
>   cleancss

I proposed a fix here:
https://salsa.debian.org/js-team/uglifyjs/-/merge_requests/2

Cheers,
Xavier

Bug#952638: libx11-dev: Uninstallable due to conflict of installed files

[Jean-Philippe MENGUAL]

Package: libx11-dev
Version: 2:1.6.9-1
Severity: important

Dear Maintainer,

Hi

Sorry for the noise, the problem may be due to my suystem, but I really dont
understand

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

   * What led up to the situation?

I try to install build-deo orca
This package depends on x11proto-dev

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

apt build-dep orca

   * What was the outcome of this action?

libx1-dev does not install.
"Attemting to replace /usr/include/X11/extensions/XKBgeom.h which lelongs to
x11proto-dev too"

Strangely, apt-file search XKBgeom.h only reports it as being in x1proto-dev.

   * What outcome did you expect instead?

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

Is that my status file broken? Or a bug here?

Thanks for your feedback 

Best regards


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

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

Versions of packages libx11-dev depends on:
ii  libx11-62:1.6.9-1
pn  libxau-dev  
pn  libxcb1-dev 
pn  libxdmcp-dev
pn  x11proto-core-dev   
pn  x11proto-input-dev  
pn  x11proto-kb-dev 
pn  xtrans-dev  

libx11-dev recommends no packages.

Versions of packages libx11-dev suggests:
pn  libx11-doc  

Bug#932939: Reproduced bug 932939

[Mariusz Gronczewski]

Hi,

We've got similar issue, altho setup is VM + virt-install + static
IP/DNS/Route config

What's different is that it does not always happen, re-trying few
times usually finally gets it to work.
In every case the device (virtio network adapter) is detected and
working from installer's shell.

As with other examples,  setting a single console makes it reliable
-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64

Bug#952625: libixion: FTBFS: configure: error: Package requirements (spdlog >= 0.16.0) were not met

[Rene Engelhard]

Hi,

On Wed, Feb 26, 2020 at 06:06:57PM +0100, Rene Engelhard wrote:
> root@frodo:/# pkg-config --cflags spdlog
> Package fmt was not found in the pkg-config search path.
> Perhaps you should add the directory containing `fmt.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'fmt', required by 'spdlog', not found
> 
> But:
> 
> # cat /usr/lib/x86_64-linux-gnu/pkgconfig/spdlog.pc
> prefix=/usr
> exec_prefix=${prefix}
> includedir=${prefix}/include
> libdir=${exec_prefix}/lib/x86_64-linux-gnu
> 
> Name: libspdlog
> Description: Fast C++ logging library.
> URL: https://github.com/gabime/spdlog
> Version: 1.5.0
> CFlags: -I${includedir} -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL
> Libs: -L${libdir} -lspdlog -pthread
> Requires: fmt
> ^
> 
> libfmt-dev does not have a .pc file. Thus this isn't resolvable.
> 
> root@frodo:/# pkg-config --cflags fmt
> Package fmt was not found in the pkg-config search path.
> Perhaps you should add the directory containing `fmt.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'fmt' found
> 
> -> bug in spdlog

Commenting out the above line of course works.

It seems to me that libfmt-dev is header-only or static? (-dev doesn't
depend on a fmt shared library). So that means that it could safely be
removed for the header-only usecase.

For the static lib use case this might break stuff unless external stuff
needs -lfmt to link, though (no idea whether they would, or if it is
just a internal, but
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952543
suggests that it does.)

Or fmt gets a .pc file (Cced.)

Regards,

Rene

Bug#952404: scanbd: crash on startup: kernel internal error: Oops 206 with current raspbian buster on rpi4 4g

[Sudip Mukherjee]

I tried it on a qemu image for aarch64 and could not reproduce the probem,
and there was no error in dmesg.

root@debian-arm64:/home/sudip# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 10 (buster)
Release:10
Codename:   buster

root@debian-arm64:/home/sudip# lscpu | grep Arch
Architecture:aarch64

root@debian-arm64:/home/sudip# uname -r
4.19.0-8-arm64

root@debian-arm64:/home/sudip# export SANE_CONFIG_DIR=/etc/scanbd
root@debian-arm64:/home/sudip# /usr/sbin/scanbd -f -c /etc/scanbd/scanbd.conf
/usr/sbin/scanbd: dbus match 
type='signal',interface='org.freedesktop.Hal.Manager'
/usr/sbin/scanbd: no devices, not starting any polling thread
/usr/sbin/scanbd: Not Primary Owner (2)


--
Regards
Sudip

Bug#951800: CVE-2020-9273: buster affected

[Salvatore Bonaccorso]

Hi HIlmar,

On Tue, Feb 25, 2020 at 06:20:06PM +0100, Hilmar Preuße wrote:
> On 2/22/20 10:58 PM, Salvatore Bonaccorso wrote:
> > On Sat, Feb 22, 2020 at 09:29:34PM +0100, Hilmar Preuße wrote:
> 
> Hi Salvatore,
> 
> >> The fix for this issue (+ patch for two other issues) is already in the
> >> buster branch on salsa. I planned to upload that ASAP. Not sure if it
> >> will still happen this week.
> > 
> > Yes note I did upload both as (as said had a bit of time to work
> > acutally on Debian these weekend dedicately). I have not released the
> > DSA because I really would like to understand if we can verify the
> > fix. But it his looks unfeasible in reasonable timeframe I will go
> > ahead with the DSA. 
> > 
> Not sure, if I understood you correctly: has 1.3.5b-4+deb9u4 &
> 1.3.6-4+deb10u4 been released and uploaded by you? I did not see the
> package yet in the archive.
> 
> > That said, I might still miss something.

First, sorry for late reply, had two quite busy (working) days. I was
not too clear, sorry about that. Yes, I did work on the update on the
weekend actually, and was going to push the button, when I noticed
there was a regression handled upstream. This is the reason I did not
yet. And I was waiting for upstream to recieve some feedback, but I
guess here I have to go without because until now I heard not back.

The upload which will go hit the archive will be both the initial
commit and the bugfix on top (cf. #952557) so it would be great if you
can then rebase on top then.

I realize I very badly communicated in this stance, maybe beeing
overmotivated at a Debian event.

Find attached the debdiffs as they are now for release.

Regards,
Salvatore
diff -Nru proftpd-dfsg-1.3.5b/debian/changelog 
proftpd-dfsg-1.3.5b/debian/changelog
--- proftpd-dfsg-1.3.5b/debian/changelog2019-12-31 11:06:16.0 
+0100
+++ proftpd-dfsg-1.3.5b/debian/changelog2020-02-25 22:43:05.0 
+0100
@@ -1,3 +1,13 @@
+proftpd-dfsg (1.3.5b-4+deb9u4) stretch-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Ensure that we do not reuse already-destroyed memory pools during data
+transfers (CVE-2020-9273) (Closes: #951800)
+  * Clear the data-transfer instigating command pool but keep a memory pool.
+Fixes regression in the %{transfer-status} LogFormat functionality.
+
+ -- Salvatore Bonaccorso   Tue, 25 Feb 2020 22:43:05 +0100
+
 proftpd-dfsg (1.3.5b-4+deb9u3) stretch; urgency=medium
 
   *  Cherry pick patch from upstream:
diff -Nru 
proftpd-dfsg-1.3.5b/debian/patches/Issue-903-Ensure-that-we-do-not-reuse-already-destro.patch
 
proftpd-dfsg-1.3.5b/debian/patches/Issue-903-Ensure-that-we-do-not-reuse-already-destro.patch
--- 
proftpd-dfsg-1.3.5b/debian/patches/Issue-903-Ensure-that-we-do-not-reuse-already-destro.patch
   1970-01-01 01:00:00.0 +0100
+++ 
proftpd-dfsg-1.3.5b/debian/patches/Issue-903-Ensure-that-we-do-not-reuse-already-destro.patch
   2020-02-25 22:43:05.0 +0100
@@ -0,0 +1,183 @@
+From: TJ Saunders 
+Date: Tue, 18 Feb 2020 09:48:18 -0800
+Subject: Issue #903: Ensure that we do not reuse already-destroyed memory
+ pools during data transfers.
+Origin: 
https://github.com/proftpd/proftpd/commit/e845abc1bd86eebec7a0342fded908a1b0f1996b
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-9273
+Bug-Debian: https://bugs.debian.org/951800
+Bug: https://github.com/proftpd/proftpd/issues/903
+
+[Salvatore Bonaccorso: Drop copyright header year update changes hunks, refresh
+for context changes for backport to 1.3.5b]
+---
+ src/data.c   | 27 ---
+ src/main.c   |  6 --
+ src/response.c   | 12 
+ tests/api/data.c |  2 +-
+ tests/api/response.c | 10 ++
+ 5 files changed, 47 insertions(+), 10 deletions(-)
+
+--- a/src/data.c
 b/src/data.c
+@@ -747,7 +747,7 @@ void pr_data_close(int quiet) {
+  */
+ void pr_data_cleanup(void) {
+   /* sanity check */
+-  if (session.d) {
++  if (session.d != NULL) {
+ pr_inet_lingering_close(session.pool, session.d, timeout_linger);
+ session.d = NULL;
+   }
+@@ -769,7 +769,7 @@ void pr_data_abort(int err, int quiet) {
+   int true_abort = XFER_ABORTED;
+   nstrm = NULL;
+ 
+-  if (session.d) {
++  if (session.d != NULL) {
+ if (true_abort == FALSE) {
+   pr_inet_lingering_close(session.pool, session.d, timeout_linger);
+ 
+@@ -951,6 +951,11 @@ void pr_data_abort(int err, int quiet) {
+ if (true_abort == FALSE) {
+   pr_response_add_err(respcode, _("Transfer aborted. %s"), msg ? msg : 
"");
+ }
++
++/* Forcibly clear the data-transfer instigating command pool from the
++ * Response API.
++ */
++pr_response_set_pool(NULL);
+   }
+ 
+   if (true_abort) {
+@@ -991,6 +996,7 @@ int pr_data_xfer(char *cl_buf, size_t cl
+ res = pr_cmd_read();
+ if (res < 0) {
+   int xerrno;
++
+ #if defined(ECONNABORTED)
+   xerrno = ECONNABORTED;
+ #elif 

Bug#952617: haskell-cmdargs: FTBFS: ln: extra operand 'debian/libghc-cmdargs-doc/usr/lib/ghc-doc/hoogle/libghc-cmdargs-doc.txt'

[Lucas Nussbaum]

On 26/02/20 at 18:57 +0200, Ilias Tsitsimpis wrote:
> Control: reassign -1 haskell-devscripts 0.15.2
> 
> On Wed, Feb 26, 2020 at 05:13PM, Lucas Nussbaum wrote:
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> 
> Hey Lucas, 
> 
> Thanks for reporting this. The latest version of haskell-devscripts now
> ensures that the build will fail when a command fails, and that's what
> we are seeing here. Up until now, this error has been going unnoticed.
> 
> I am reassigning this to haskell-devscripts and will try to solve it.

Hi,

Other packages failed to build with a similar error, FYI:

haskell-decimal 0.5.1-2 
haskell-derive 2.6.5-1 
haskell-extra 1.6.17-1 
haskell-filepattern 0.1.1-2 
haskell-hoogle 5.0.17.3+dfsg1-5 
haskell-js-jquery 3.3.1-2 
haskell-safe 0.3.17-2 
haskell-shake 0.16.4+dfsg-4 
haskell-tagsoup 0.14.8-1 

(at least)

Lucas

Bug#951257: udevadm: please exit nonzero with "Running in chroot, ignoring request." when /proc is not mounted

[Michael Biebl]

Am 13.02.20 um 14:03 schrieb Trent W. Buck:
> Michael Biebl wrote:
>> Am 13.02.20 um 13:29 schrieb Trent W. Buck:

>> I guess you'd have to convince upstream that this is a good idea to add
>> such a check.
>>
>> Once upstream has such a patch, we can cherry-pick it.
> 
> Blergh, I guess I'll have to make a github account and install a GUI
> browser so I can interact with upstream directly.
> 


Any updates here?



signature.asc
Description: OpenPGP digital signature

Bug#951724: systemd-networkd: bridge losing IPv4 address

[Michael Biebl]

Am 20.02.20 um 18:21 schrieb Tomas Barton:
> Package: systemd
> Version: 232-25+deb9u12
> Severity: important
> 
> Dear Maintainer,
> 
> I'm having problem with systemd-networkd.service that are likely linked
> to latest stretch patch 232-25+deb9u12.

Can you reproduce the problem with systemd from buster or unstable/testing?




signature.asc
Description: OpenPGP digital signature

Bug#952637: ruby-asciidoctor-pdf: FTBFS: Could not find 'concurrent-ruby' (~> 1.0.5) - did find: [concurrent-ruby-1.1.6]

[Pirate Praveen]

Package: ruby-asciidoctor-pdf
Version: 1.5.0~alpha.17.dev-6.1
Severity: serious
Control: tags -1 patch

With recent upload to ruby-concurrent to 1.1.6, ruby-asciidoctor-pdf 
started FTBFS because the dependency declared in gemspec is too strict.


┌──┐
│ Checking Rubygems dependency resolution on ruby2.5  
│

└──┘

GEM_PATH=/<>/debian/ruby-asciidoctor-pdf/usr/share/rubygems-integration/all:/var/lib/gems/2.5.0:/usr/lib/ruby/gems/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0 
ruby2.5 -e gem\ \"asciidoctor-pdf\"
/usr/lib/ruby/2.5.0/rubygems/dependency.rb:312:in `to_specs': Could not 
find 'concurrent-ruby' (~> 1.0.5) - did find: [concurrent-ruby-1.1.6] 
(Gem::MissingSpecVersionError)


It can be fixed easily with  a patch,

commit 0a0cd710110b8445fc5ea5abeb809c97b40b0518
Author: Pirate Praveen 
Date:   Wed Feb 26 22:58:15 2020 +0530

   Relax dependencies of stable libraries

diff --git a/asciidoctor-pdf.gemspec b/asciidoctor-pdf.gemspec
index b66e4ba..8ec4524 100644
--- a/asciidoctor-pdf.gemspec
+++ b/asciidoctor-pdf.gemspec
@@ -47,9 +47,9 @@ An extension for Asciidoctor that converts AsciiDoc 
documents to PDF using the P
  # prawn-svg >= 0.22.1 requires Ruby >= 2.0.0, so we must cast a 
wider net to support Ruby 1.9.3

  s.add_runtime_dependency 'prawn-svg', '>= 0.28.0'
  s.add_runtime_dependency 'prawn-icon', '>= 1.4.0'
-  s.add_runtime_dependency 'safe_yaml', '~> 1.0.4'
+  s.add_runtime_dependency 'safe_yaml', '~> 1.0', '>= 1.0.4'
  s.add_runtime_dependency 'thread_safe', '~> 0.3.6'
-  s.add_runtime_dependency 'concurrent-ruby', '~> 1.0.5'
+  s.add_runtime_dependency 'concurrent-ruby', '~> 1.0', '>= 1.0.5'
  # For our usage, treetop 1.6.2 is slower than 1.5.3
  s.add_runtime_dependency 'treetop', '>= 1.5.3'
end

I have also sent a merge request 

Bug#952612: libmemcached-libmemcached-perl: FTBFS: /bin/sh: 1: /bin/kill: not found

[gregor herrmann]

On Wed, 26 Feb 2020 18:07:21 +0100, Lucas Nussbaum wrote:

> On 26/02/20 at 18:03 +0100, gregor herrmann wrote:
> > Control: reassign -1 procps
> > Control: forcemerge 952612 -1
> > Control: affects -1 src:libmemcached-libmemcached-perl
> 
> You mean #952572 ?

Yes, sorry, copypaste error; I already fixed it via `bts'.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#952612: libmemcached-libmemcached-perl: FTBFS: /bin/sh: 1: /bin/kill: not found

[Lucas Nussbaum]

On 26/02/20 at 18:03 +0100, gregor herrmann wrote:
> Control: reassign -1 procps
> Control: forcemerge 952612 -1
> Control: affects -1 src:libmemcached-libmemcached-perl

You mean #952572 ?

- Lucas


signature.asc
Description: PGP signature

Bug#952610: meson: autopkgtests regressions

[Jussi Pakkanen]

On Wed, Feb 26, 2020 at 6:12 PM Gianfranco Costamagna
 wrote:

> +-self._simple_test('python', 'python')
> ++self._simple_test('python', 'python2')

This fix is not correct, because it breaks the test suite in master:

https://github.com/mesonbuild/meson/pull/6700

> meson.build:1:0: ERROR: Unknown compiler(s): ['cc', 'gcc', 'clang', 'pgcc', 
> 'icc']
> The follow exceptions were encountered:
> Running "cc --version" gave "[Errno 2] No such file or directory: 'cc': 'cc'"
> Running "gcc --version" gave "[Errno 2] No such file or directory: 'gcc': 
> 'gcc'"
> Running "clang --version" gave "[Errno 2] No such file or directory: 'clang': 
> 'clang'"
> Running "pgcc --version" gave "[Errno 2] No such file or directory: 'pgcc': 
> 'pgcc'"
> Running "icc --version" gave "[Errno 2] No such file or directory: 'icc': 
> 'icc'"

This should be fixed by changing debian/tests/control's deps for the
crossbuild test to be these:

Depends: meson, g++, g++-arm-linux-gnueabihf

Would it be possible for you to test this fix?

Bug#951276: default webinterface non-functional

[Bálint Réczey]

Control: tags -1 help
Control: block -1 by 851663

Hi Gilles,

Bálint Réczey  ezt írta (időpont: 2020. febr.
25., K, 23:32):
>
> Hi,
>
> Gilles Filippini  ezt írta (időpont: 2020. febr. 25.,
> K, 23:12):
> >
> > Hi,
> >
> > On Thu, 13 Feb 2020 17:48:57 +0100 Roderich Schupp
> >  wrote:
> > > Package: kodi-data
> > > Version: 2:18.5+dfsg1-1~exp0
> > > Severity: normal
> > >
> > > The default webinterface shows just a header bar,
> > > see attached screenshot.
> > >
> > > The webinterface.default included in the Debian package is
> > > seriously outdated, the current Kodi v18 webinterface
> > > is here: https://github.com/xbmc/chorus2/releases/tag/18.x-2.4.6
> >
> > d/README.source says:
> > > Kodi replaced the default webinterface in 17.0 beta6 but the new 
> > > interface contains
> > > many generated files without providing the source for them. The web 
> > > interface
> > > is temporarily reverted to the one included in beta5 to restore GPL 
> > > compliance.
> >
> > And Balint filed a related upstream issue:
> > https://github.com/xbmc/chorus2/issues/179
> >
> > @Balint, from your last comment on this issue it seems the only
> > litigious material left is the screenshots. Are these images requested
> > for running the chorus2 web interface? Couldn't they be removed from the
> > upstream source package until they are fixed?
>
> The upstream source needs a new review to see which files should be dropped.
> If those are just a few images like the screenshots I'm ready to
> create a new +dfsg2 source and ship the new web interface.
>
> Help is very welcome here, since I'm currently busy with other
> packages, but otherwise the kodi 18 packages are close to ready for
> upload to unstable.

I took a look and the situation did improve license-wise, but Kodi ships
addons/webinterface.default/js/kodi-webinterface.js which is a
minimized version of
https://github.com/xbmc/chorus2 . It needs to be packages separately,
see, the linked RFP bug.

When Chorus2 is  shipped in Debian properly rebuilding it from source
then the kodi package can switch to using it.

Cheers,
Balint

Bug#952632: mark libtest-harness-perl Multi-Arch: foreign

[gregor herrmann]

On Wed, 26 Feb 2020 17:50:54 +0100, Helmut Grohne wrote:

> Many packages cannot be cross built, because their transitive dependency
> on libtest-harness-perl (often via libmodule-build-perl) is not cross
> satisfiable. On the next rebuild of libtest-harness-perl, the perl
> dependency will be annotated :any due to a recent debhelper change. Once
> that happens, the multiarch hinter will ask marking it Multi-Arch:
> foreign. I ask now. Please consider applying the attached patch.

Done.

Please note that the modules in this package are also included in
src:perl:

libtest-harness-perl: /usr/share/perl5/TAP/Harness.pm
perl-modules: /usr/share/perl/5.20.2/TAP/Harness.pm
perl-modules-5.24: /usr/share/perl/5.24.1/TAP/Harness.pm
perl-modules-5.28: /usr/share/perl/5.28.1/TAP/Harness.pm
perl-modules-5.30: /usr/share/perl/5.30.0/TAP/Harness.pm
perl-modules-5.30: /usr/share/perl/5.30.1/TAP/Harness.pm

and

Provided by: perl (5.28.1-6), perl (5.30.0-9), perl (5.30.1~rc1-1), 
perl-modules (5.20.2-3+deb8u11), perl-modules-5.24
 (5.24.1-3+deb9u6)

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#952625: libixion: FTBFS: configure: error: Package requirements (spdlog >= 0.16.0) were not met

[Rene Engelhard]

retitle 952625 libspdlog-dev: .pc Requires: fmt which doesn't have a .pc file, 
breaking pkg-config on spdlog.pc
reassign 952625 libspdlog-dev
affects 952625 src:libixion
found 952625 1:1.5.0+ds-2
thanks

Hi,

On Wed, Feb 26, 2020 at 05:15:19PM +0100, Lucas Nussbaum wrote:
> Source: libixion
> Version: 0.15.0-3
> Severity: serious
> Justification: FTBFS on amd64

No, spdlog broke, see below.

> Relevant part (hopefully):
> > checking for the Boost filesystem library... (cached) yes
> > checking for pkg-config... /usr/bin/pkg-config
> > checking pkg-config is at least version 0.9.0... yes
> > checking for MDDS... yes
> > checking for SPDLOG... no
> > configure: error: Package requirements (spdlog >= 0.16.0) were not met
> > 
> > Package 'fmt', required by 'spdlog', not found
> > 
> > Consider adjusting the PKG_CONFIG_PATH environment variable if you
> > installed software in a non-standard prefix.
> > 
> > Alternatively, you may set the environment variables SPDLOG_CFLAGS
> > and SPDLOG_LIBS to avoid the need to call pkg-config.
> > See the pkg-config man page for more details.
> > tail -v -n \+0 config.log

This looks related to the recent spdlog fmt changes, where spdlog
removed the internal fmt?

Thus (clean sid chroot):

# apt install libspdlog-dev
Reading package lists... Done
Building dependency tree... Done
The following additional packages will be installed:
  libfmt-dev libspdlog1
Suggested packages:
  libfmt-doc
The following NEW packages will be installed:
  libfmt-dev libspdlog-dev libspdlog1
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 449 kB of archives.
After this operation, 1869 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://deb.debian.org/debian sid/main amd64 libfmt-dev amd64 5.3.0+ds-2 
[141 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 libspdlog1 amd64 1:1.5.0+ds-2 
[143 kB]
Get:3 http://deb.debian.org/debian sid/main amd64 libspdlog-dev amd64 
1:1.5.0+ds-2 [166 kB]
Fetched 449 kB in 0s (1233 kB/s) 
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
Selecting previously unselected package libfmt-dev.
(Reading database ... 9296 files and directories currently installed.)
Preparing to unpack .../libfmt-dev_5.3.0+ds-2_amd64.deb ...
Unpacking libfmt-dev (5.3.0+ds-2) ...
Selecting previously unselected package libspdlog1:amd64.
Preparing to unpack .../libspdlog1_1%3a1.5.0+ds-2_amd64.deb ...
Unpacking libspdlog1:amd64 (1:1.5.0+ds-2) ...
Selecting previously unselected package libspdlog-dev.
Preparing to unpack .../libspdlog-dev_1%3a1.5.0+ds-2_amd64.deb ...
Unpacking libspdlog-dev (1:1.5.0+ds-2) ...
Setting up libfmt-dev (5.3.0+ds-2) ...
Setting up libspdlog1:amd64 (1:1.5.0+ds-2) ...
Setting up libspdlog-dev (1:1.5.0+ds-2) ...
Processing triggers for libc-bin (2.29-10) ...
root@frodo:/# pkg-config --cflags fmt
bash: pkg-config: command not found
root@frodo:/# apt install pkg-config
Reading package lists... Done
Building dependency tree... 50%
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  bzip2 libdpkg-perl libfile-fcntllock-perl libgdbm-compat4 libgdbm6 
libglib2.0-0 libglib2.0-data libicu63 libperl5.30 libxml2 perl
  perl-modules-5.30 shared-mime-info xdg-user-dirs xz-utils
Suggested packages:
  bzip2-doc debian-keyring gnupg | gnupg2 gcc | c-compiler binutils patch git 
bzr gdbm-l10n perl-doc libterm-readline-gnu-perl
  | libterm-readline-perl-perl make libb-debug-perl liblocale-codes-perl 
dpkg-dev
The following NEW packages will be installed:
  bzip2 libdpkg-perl libfile-fcntllock-perl libgdbm-compat4 libgdbm6 
libglib2.0-0 libglib2.0-data libicu63 libperl5.30 libxml2 perl
  perl-modules-5.30 pkg-config shared-mime-info xdg-user-dirs xz-utils
0 upgraded, 16 newly installed, 0 to remove and 0 not upgraded.
Need to get 21.2 MB of archives.
After this operation, 102 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian sid/main amd64 perl-modules-5.30 all 
5.30.0-9 [2803 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 libgdbm6 amd64 1.18.1-5 [64.5 
kB]
Get:3 http://deb.debian.org/debian sid/main amd64 libgdbm-compat4 amd64 
1.18.1-5 [44.2 kB]
Get:4 http://deb.debian.org/debian sid/main amd64 libperl5.30 amd64 5.30.0-9 
[4008 kB]
Get:5 http://deb.debian.org/debian sid/main amd64 perl amd64 5.30.0-9 [290 kB]
Get:6 http://deb.debian.org/debian sid/main amd64 bzip2 amd64 1.0.8-2 [49.0 kB]

Bug#952636: grdesktop: calls rdesktop with wrong -k option if no kbd layout is selected

[Frank Doepper]

Package: grdesktop
Version: 0.23+d040330-3.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
using grdesktop to connect to another host on Debian Buster
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
grdesktop
enter a Computer hostname
click Execute
   * What was the outcome of this action?
A warning message with the usage of rdesktop
   * What outcome did you expect instead?
open a rdesktop session to the named host

Apparently rdesktop is called with option "-k" without required argument
if no keyboard layout is selected explicitely.

Maybe both grdesktop and rdesktop should be removed from Debian in favor
of xfreerdp and another GUI.

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

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

Versions of packages grdesktop depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk2.0-0  2.24.32-3
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  rdesktop 1.8.6-2

Versions of packages grdesktop recommends:
ii  gconf2  3.2.6-5

grdesktop suggests no packages.

-- no debconf information

Bug#952635: phpldapadmin: New major upstream version on GitHub

[Frederic MASSOT]

Package: phpldapadmin
Version: 1.2.2-5
Severity: wishlist

Dear Maintainer,

There has been no further development on SourceForge for several years.

The development of phpLDAPadmin continues on GitHub.

New versions have been released with bug fixes and compatibility with PHP 7.

https://github.com/leenooks/phpLDAPadmin

Can you update the package, please?


Regards.



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

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

Versions of packages phpldapadmin depends on:
ii  debconf [debconf-2.0]  1.5.73
pn  php
pn  php-ldap   
pn  php-xml
ii  ucf3.0038+nmu1

phpldapadmin recommends no packages.

phpldapadmin suggests no packages.