Bug#898202: ITP: mp3gain

[Scott Hardin]

Hey Stefan,

Perfect. Within the last month (or three ), I got something working, 
although I could use some experienced guidance. For example, the linter 
recently started complaining about testing for packages? I didn't even 
know that was a thing, and I'm pretty sure it wasn't when I started this. 


To be frank, most of the patches that used to be a part of this package 
were merged upstream. The fork of mpglib that used to be a part of this 
project was also removed, so there really wasn't a whole lot of obvious 
work to do besides moving to newer formats and ditching those patches. 
I've been reading the documentation when I have time. There's just quite 
a bit of it, so pointers are helpful.


Take a look at what I've done here: 
https://salsa.debian.org/snhardin-guest/mp3gain. It's not a lot, but I 
think I'm almost there.


Thanks,
Scott

On 6/14/2020 5:40 AM, Stefan Fritsch wrote:

Hi,

I used to maintain mp3gain a long time ago. I have still use for it for
the player in my car and would support you if you want to maintain it. I
am still Debian developer and could sponsor your uploads.

If you are no longer interested, it may make sense to rename the bug
back to RFP.

Cheers,
Stefan

Bug#962933: ITP: Beanvalidation-api - Jakarta Bean Validation API

[Mechtilde Stehmann]

To: sub...@bugs.debian.org
Subject: ITP: Beanvalidation-api - Jakarta Bean Validation API
Package: wnpp
Severity: wishlist

* Package name : libbeanvalidation-api-java
  Version : 3.0.0-M1
  Upstream Author : Emmanuel Bernard  et al.
* URL : http://beanvalidation.org/
* License : Apache-2.0
  Programming Lang: Java
  Description :  Jakarta Bean Validation API

Jakarta Bean Validation is a Java specification which provides the APIs
to validate objects and object graphs. It also provides the APIs to
validate parameters and return values of methods and constructors




* Why is this package useful/relevant?
* Is it a dependency for another package?

It is a dependency for jcabi-aspects, which is a dependency of jcabi-ssh
which is a dependency of JLawyer-Client

* Do you use it yourself?
* If there are other packages providing similar functionality,
  how does it compare?
* How do you plan to maintain it? Do you plan to maintain it
  inside a packaging team?

I want to maintain it in the java-team
  (check list at https://wiki.debian.org/Teams)
* Are you looking for co-maintainers? Do you need a sponsor?

Kind regards

...--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#908533: compton: Change compton sources

[GSR]

Hi all:

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

If I understood correctly, migration will be manual. It would be nicer
if automatic (fake compton that depends on real picom?), or at least
some kind of notification beyond emails like this one.

Cheers,
GSR
 

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[Salvatore Bonaccorso]

On Mon, Jun 15, 2020 at 10:42:12PM -0400, J. Bruce Fields wrote:
> On Mon, Jun 15, 2020 at 10:38:20PM -0400, J. Bruce Fields wrote:
> > Thanks for the detailed reproducer.
> > 
> > It's weird, as the server is basically just setting the transmitted
> > umask and then calling into the vfs to handle the rest, so it's not much
> > different from any other user.  But the same reproducer run just on the
> > ext4 filesystem does give the right permissions
> > 
> > Oh, but looking at the system call, fs_namei.c:do_mkdirat(), it does:
> > 
> > if (!IS_POSIXACL(path.dentry->d_inode))
> > mode &= ~current_umask();
> > error = security_path_mkdir(, dentry, mode);
> > if (!error)
> > error = vfs_mkdir(path.dentry->d_inode, dentry, mode);
> > 
> > whereas nfsd just calls into vfs_mkdir().
> > 
> > And that IS_POSIXACL() check is exactly a check whether the filesystem
> > supports ACLs.  So I guess it's the responsibility of the caller of
> > vfs_mkdir() to handle that case.
> 
> But, that's unsatisfying: why isn't vfs_mkdir() taking care of this
> itself?  And what about that security_path_mkdir() call?  And are the
> other cases of that switch in fs/nfsd/vfs.c:nfsd_create_locked()
> correct?  I think there may be some more cleanup here called for, I'll
> poke around tomorrow.

Yes agreed and can confirm: The other cases in
fs/nfsd/vfs.c:nfsd_create_locked() seem to have the problem as well.

Regards,
Salvatore

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[Salvatore Bonaccorso]

Hi Bruce,

On Mon, Jun 15, 2020 at 10:38:20PM -0400, J. Bruce Fields wrote:
> Thanks for the detailed reproducer.
> 
> It's weird, as the server is basically just setting the transmitted
> umask and then calling into the vfs to handle the rest, so it's not much
> different from any other user.  But the same reproducer run just on the
> ext4 filesystem does give the right permissions
> 
> Oh, but looking at the system call, fs_namei.c:do_mkdirat(), it does:
> 
>   if (!IS_POSIXACL(path.dentry->d_inode))
>   mode &= ~current_umask();
>   error = security_path_mkdir(, dentry, mode);
>   if (!error)
>   error = vfs_mkdir(path.dentry->d_inode, dentry, mode);
> 
> whereas nfsd just calls into vfs_mkdir().
> 
> And that IS_POSIXACL() check is exactly a check whether the filesystem
> supports ACLs.  So I guess it's the responsibility of the caller of
> vfs_mkdir() to handle that case.
> 
> So the obvious fix is something like (untested!)
> 
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 0aa02eb18bd3..dabdcca58969 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -1234,6 +1234,8 @@ nfsd_create_locked(struct svc_rqst *rqstp, struct 
> svc_fh *fhp,
>   nfsd_check_ignore_resizing(iap);
>   break;
>   case S_IFDIR:
> + if (!IS_POSIXACL(dirp))
> + iap->ia_mode &= ~current_umask();
>   host_err = vfs_mkdir(dirp, dchild, iap->ia_mode);
>   if (!host_err && unlikely(d_unhashed(dchild))) {
>   struct dentry *d;

Thank you!

Tested your patch on top, and it would solve the directory case, but
the underlying problem is more general (and as you said proably needs
further checking in other places):

root@nfs-test:~# mount -t nfs 192.168.122.150:/srv/data /mnt
root@nfs-test:~# mkdir /mnt/foo && ls -ld /mnt/foo && rmdir /mnt/foo
drwxr-xr-x 2 root root 4096 Jun 16 07:24 /mnt/foo
root@nfs-test:~# touch /mnt/foo && ls -ld /mnt/foo && rm /mnt/foo
-rw-rw-rw- 1 root root 0 Jun 16 07:25 /mnt/foo
root@nfs-test:~# umount /mnt
root@nfs-test:~#

So when creating files the umask is still ignored in the noacl mounted
case.

Regards,
Salvatore

Bug#908533: compton: Change compton sources

[GSR]

*blush* Copy paste error, missed the 2 at the end.

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

Sorry for the noise.
GSR
 

Bug#962932: ITP: plumpy -- Python workflows library

[merkys]

Package: wnpp
Severity: wishlist
Owner: Andrius Merkys 
Control: block 901392 by -1

* Package name    : plumpy
  Version : 0.14.5
  Upstream Author : Martin Uhrin
* URL : https://github.com/aiidateam/plumpy
* License : GPLv3 and Expat
  Programming Lang: Python
  Description : Python workflows library

A python workflows library that supports writing Processes with a well defined 
set of inputs and outputs that can be strung together. RabbitMQ is used to 
queue up, control and monitor running processes via the kiwipy library.

plumpy is required by aiida-core (ITP #901392). However, packaging of plumpy is 
currently blocked by its incompatibility with python3-tornado >= 5 [1].

I plan to maintain plumpy together with the DPMT.

[1] https://github.com/aiidateam/plumpy/issues/72

Bug#962819: RFP: foliate -- simple and modern GTK eBook reader

[Lev Lamberov]

Hi Jonathan,

Пн 15 июн 2020 @ 21:20 Jonathan Carter :

> On 2020/06/14 18:17, Lev Lamberov wrote:
>> * Package name: foliate
>
> An ITP for this package already exists:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945270

Yep, I saw merge request by Sean Whitton.

> Some initial work:
> https://salsa.debian.org/debian/foliate

Thanks for your work on it!

> I've been meaning to get to it, but have been really busy recently, if
> you'd like to finish it up please go ahead.

Unfortunately, I don't feel competent to mess with Javascript. Sorry. I
sent my RFP request as a possible user of Foliate, not maintainer.

Cheers!
Lev

Bug#962931: Please enable support for Banana Pi M2 Ultra

[Bernhard Wörner]

Source: u-boot
Severity: wishlist

Hello,

Please enable support for the Banana Pi M2 Ultra.
This board has the same SoC as the already enabled M2 Berry.

I can do the test and update the u-boot status page.

Best regards and thank you for the great support.

Bernhard

Bug#962930: kodi-eventclients-ps3: exception in extracting key codes

[Ritesh Raj Sarraf]

Package: kodi-eventclients-ps3
Version: 2:18.7+dfsg1-1
Severity: normal

When trying to use the tool to detect key codes, it runs into the
following exception.


rrs@lenovo:/etc/bluetooth$ kodi-ps3remote localhost
/usr/share/pixmaps/kodi//bluetooth.png
Searching for BD Remote Control
(Hold Start + Enter on remote to make it discoverable)
Redmi (E8:5A:8B:73:57:44) in range
Living Room TV (E4:DB:6D:24:23:E9) in range
Could not find BD Remote Control. Trying again...
Searching for BD Remote Control
(Hold Start + Enter on remote to make it discoverable)
Living Room TV (E4:DB:6D:24:23:E9) in range
Redmi (E8:5A:8B:73:57:44) in range
Could not find BD Remote Control. Trying again...
Searching for BD Remote Control
(Hold Start + Enter on remote to make it discoverable)
BD Remote Control (00:1E:3D:10:29:0F) in range
Found BD Remote Control with address 00:1E:3D:10:29:0F
Attempting to pair with remote
Remote Paired.
Traceback (most recent call last):
  File "/usr/bin/kodi-ps3remote", line 221, in 
main()
  File "/usr/bin/kodi-ps3remote", line 212, in main
if process_keys(remote, xbmc):
  File "/usr/bin/kodi-ps3remote", line 164, in process_keys
keycode = data.encode("hex")[10:12]
AttributeError: 'bytes' object has no attribute 'encode'
11:24 ♒♒♒☹ => 1  

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

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

Versions of packages kodi-eventclients-ps3 depends on:
ii  kodi-eventclients-common  2:18.7+dfsg1-1
ii  python3   3.8.2-3
ii  python3-bluez 0.23-1+b1

kodi-eventclients-ps3 recommends no packages.

kodi-eventclients-ps3 suggests no packages.

-- no debconf information

Bug#962929: kodi-eventclients-ps3: exception when trying to open system icon

[Ritesh Raj Sarraf]

Package: kodi-eventclients-ps3
Version: 2:18.7+dfsg1-1
Severity: normal

The tool fails to run because the path that it forms is not absolute.


rrs@lenovo:~/ps3pair$ kodi-ps3remote localhost 9777
usr/share/pixmaps/kodi//bluetooth.png
Traceback (most recent call last):
  File "/usr/bin/kodi-ps3remote", line 220, in 
  File "/usr/bin/kodi-ps3remote", line 208, in main
xbmc.connect(host, port)
packet = PacketHELO(self.name, self.icon_type, self.icon_file)
  File "/usr/lib/python3/dist-packages/kodi/xbmcclient.py", line 285, in 
__init__
with open(icon_file, 'rb') as f:
11:16 ♒♒♒☹ => 1  

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

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

Versions of packages kodi-eventclients-ps3 depends on:
ii  kodi-eventclients-common  2:18.7+dfsg1-1
ii  python3   3.8.2-3
ii  python3-bluez 0.23-1+b1

kodi-eventclients-ps3 recommends no packages.

kodi-eventclients-ps3 suggests no packages.

-- no debconf information

Bug#962928: python-pymzml FTBFS: LaTeX Error: Unknown graphics extension: .svg

[Adrian Bunk]

Source: python-pymzml
Version: 2.4.7-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=python-pymzml=all=2.4.7-1=1592254701=0

...
Running 'pdflatex   -recorder  "pymzML.tex"'

Latexmk: applying rule 'pdflatex'...
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./pymzML.tex
LaTeX2e <2020-02-02> patch level 5
L3 programming layer <2020-05-15> (./sphinxmanual.cls
Document Class: sphinxmanual 2019/12/01 v2.3.0 Document class (Sphinx manual)
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2019/12/20 v1.4l Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))
(/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty)
(/usr/share/texlive/texmf-dist/tex/latex/cmap/cmap.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty<>)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty))
(/usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
(/usr/share/texlive/texmf-dist/tex/generic/babel/babel.def
(/usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def))
(/usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf))
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/times.sty)
(/usr/share/texlive/texmf-dist/tex/latex/fncychap/fncychap.sty) (./sphinx.sty
(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def)))
(/usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty)
(/usr/share/texlive/texmf-dist/tex/latex/titlesec/titlesec.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tabulary/tabulary.sty
(/usr/share/texlive/texmf-dist/tex/latex/tools/array.sty))
(/usr/share/texlive/texmf-dist/tex/latex/tools/longtable.sty)
(/usr/share/texlive/texmf-dist/tex/latex/varwidth/varwidth.sty)
(./sphinxmulticell.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/makeidx.sty)
(/usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty)
(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg))
(/usr/share/texlive/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty)
(./footnotehyper-sphinx.sty)
(/usr/share/texlive/texmf-dist/tex/latex/float/float.sty)
(/usr/share/texlive/texmf-dist/tex/latex/wrapfig/wrapfig.sty)
(/usr/share/texlive/texmf-dist/tex/latex/parskip/parskip.sty
(/usr/share/texlive/texmf-dist/tex/latex/parskip/parskip-2001-04-09.sty))
(/usr/share/texlive/texmf-dist/tex/latex/base/alltt.sty)
(/usr/share/texlive/texmf-dist/tex/latex/upquote/upquote.sty)
(/usr/share/texlive/texmf-dist/tex/latex/capt-of/capt-of.sty)
(/usr/share/texlive/texmf-dist/tex/latex/needspace/needspace.sty)
(./sphinxhighlight.sty)
(/usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
(/usr/share/texlive/texmf-dist/tex/generic/kvsetkeys/kvsetkeys.sty)))
(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
(/usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
(/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty)))
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
(/usr/share/texlive/texmf-dist/tex/latex/pdftexcmds/pdftexcmds.sty
(/usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty))
(/usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty)
(/usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty)
(/usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty)
(/usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty)
(/usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty)
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def)
(/usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty)
(/usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty)
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def)
(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty)
(/usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
(/usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty))
(/usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty))

Bug#962927: lintian: detect when a package will be uploaded with a new maintainer but without any changes

[Paul Wise]

Package: lintian
Severity: wishlist

Recently I noticed a package enter Debian with a changelog something like 
below. The only other change to the package was in the Maintainer
field in debian/control. Rebuilds that only change the maintainer are a waste 
of buildd time, mirror sync bandwith and snapshot.d.o disk space and should be 
discouraged. It would be nice if lintian could detect these sort of uploads and 
have them rejected. Probably the check should work by matching the latest 
Debian changelog entry against the template below, allowing for inclusion or 
not of the bug closing and allowing for varying source package name, version, 
suite (unstable & experimental), uploader and date.

something (1.2.3-4) unstable; urgency=medium

  * New maintainer. (Closes: #123456)

 -- Some One   Sat, 16 Jun 2020 11:51:11 +0800

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962926: Images of aptitude screens are illegible due to being scaled to browser width

[Joshua C. Lackey]

Package: aptitude-doc-en
Version: 0.8.13-1

All of the screenshots are illegible because a width="100%" property
is set in each  tag, causing them to be stretched and introducing
significant aliasing. Resizing the browser window to a smaller size
does not help much. Due to the low resolution of the images (484x316)
and small size of the text, even minimal scaling causes blurring and
aliasing. The text, though small, is completely clear and legible when
the images are rendered at their native resolution.

This is the case in the HTML help installed to
/usr/share/doc/aptitude/html/en by the aptitude-doc-en package, as
well as the online version.

Please view for an example:
https://www.debian.org/doc/manuals/aptitude/ch01s01s01.en.html

I suggest removing the width='100%' property from each of the the
 tags in the DocBook XML source (/doc/en/aptitude.xml) or
adding an img selector in the CSS stylesheet (/doc/aptitude.css) with
a width:auto property, which will override the the HTML  tags.

Bug#960539: RFP: hydrogen -- advanced drum machine/step sequencer repackaging

[Alexandre Lymberopoulos]

Hi there!

I tried my rock band generic drum kit using USB cable, conected to
hydrogen MIDI (via rbdrum2midi) in your version and it worked perfectly! :)

Is there any other test I should perform by now?

Cheers, Alexandre
-- 
===
Alexandre Lymberopoulos - lym...@ime.usp.br - http://www.ime.usp.br/~lymber
Instituto de Matemática e Estatística - Universidade de São Paulo
===

Bug#962919: RFS: spyne/2.13.15-0.1 [NMU, RC] -- Python library for writing and calling soap web service

[Adam Borowski]

On Tue, Jun 16, 2020 at 12:58:10AM +0200, Bastian Germann wrote:
> I am looking for a sponsor for the package "spyne" which has a
> py2removal RC and a grave bug and was autoremoved from testing. The
> package is Python 2 only but the current upstream version has Python 3
> support. I converted it to build a binary python3-spyne package. The
> bugs are open long enough for a NMU.

Note that today there was a discussion with the maintainer, on #938554. 
While I completely agree with Bastian, and think that having a package
RC-buggy for 10 months and gone from testing for 7 is grounds for a 0-day
NMU, not merely one announced half a year in advance, is no good just
because upstream hasn't tagged the new version yet -- let's see what
the maintainer will do.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#960901: Buffer is a built-in node function

[Ben Finney]

On 18-May-2020, Pirate Praveen wrote:
> https://salsa.debian.org/js-team/node-clone/-/blob/master/clone.js#L109
> I think we may need to embed older version of buffer module in 
> node-libs-browser

Okay. I assume that is information for the ‘node-libs-browser’
maintainer, I think as a user I can't affect that.

> For this particular case you can try embedding buffer module version
> 4.x as browsers need an equivalent module to features present only
> in node.

This looks like advice for me to work around the problem. What do I
need to do? How do I (as a user of Webpack) “embed buffer module
version 4.x”?

-- 
 \   “It is forbidden to steal hotel towels. Please if you are not |
  `\  person to do such is please not to read notice.” —hotel, |
_o__)   Kowloon, Hong Kong |
Ben Finney 

signature.asc
Description: PGP signature

Bug#962916: import-ref --upstream-version: manpage/code discrepancy

[Paride Legovini]

Package: git-buildpackage
Version: 0.9.19
Severity: normal

Hi,

The gbp-import-ref manpage says that the default value for --upstream-tree
is BRANCH ("BRANCH (the default) merges from the upstream branch."),
while the actual default in the code is VERSION.

I think VERSION is what we want.

Cheers,

Paride

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.20.3
ii  git1:2.27.0-1
ii  man-db 2.9.2-1
ii  python33.8.2-3
ii  python3-dateutil   2.8.1-4
ii  python3-pkg-resources  46.1.3-1
ii  sensible-utils 0.0.12+nmu1

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.47
ii  python3-requests  2.23.0+dfsg-2
ii  sbuild0.79.1-1

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.0-1
ii  unzip6.0-25

-- no debconf information

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[J. Bruce Fields]

On Mon, Jun 15, 2020 at 10:38:20PM -0400, J. Bruce Fields wrote:
> Thanks for the detailed reproducer.
> 
> It's weird, as the server is basically just setting the transmitted
> umask and then calling into the vfs to handle the rest, so it's not much
> different from any other user.  But the same reproducer run just on the
> ext4 filesystem does give the right permissions
> 
> Oh, but looking at the system call, fs_namei.c:do_mkdirat(), it does:
> 
>   if (!IS_POSIXACL(path.dentry->d_inode))
>   mode &= ~current_umask();
>   error = security_path_mkdir(, dentry, mode);
>   if (!error)
>   error = vfs_mkdir(path.dentry->d_inode, dentry, mode);
> 
> whereas nfsd just calls into vfs_mkdir().
> 
> And that IS_POSIXACL() check is exactly a check whether the filesystem
> supports ACLs.  So I guess it's the responsibility of the caller of
> vfs_mkdir() to handle that case.

But, that's unsatisfying: why isn't vfs_mkdir() taking care of this
itself?  And what about that security_path_mkdir() call?  And are the
other cases of that switch in fs/nfsd/vfs.c:nfsd_create_locked()
correct?  I think there may be some more cleanup here called for, I'll
poke around tomorrow.

--b.

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[J. Bruce Fields]

Thanks for the detailed reproducer.

It's weird, as the server is basically just setting the transmitted
umask and then calling into the vfs to handle the rest, so it's not much
different from any other user.  But the same reproducer run just on the
ext4 filesystem does give the right permissions

Oh, but looking at the system call, fs_namei.c:do_mkdirat(), it does:

if (!IS_POSIXACL(path.dentry->d_inode))
mode &= ~current_umask();
error = security_path_mkdir(, dentry, mode);
if (!error)
error = vfs_mkdir(path.dentry->d_inode, dentry, mode);

whereas nfsd just calls into vfs_mkdir().

And that IS_POSIXACL() check is exactly a check whether the filesystem
supports ACLs.  So I guess it's the responsibility of the caller of
vfs_mkdir() to handle that case.

So the obvious fix is something like (untested!)

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 0aa02eb18bd3..dabdcca58969 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1234,6 +1234,8 @@ nfsd_create_locked(struct svc_rqst *rqstp, struct svc_fh 
*fhp,
nfsd_check_ignore_resizing(iap);
break;
case S_IFDIR:
+   if (!IS_POSIXACL(dirp))
+   iap->ia_mode &= ~current_umask();
host_err = vfs_mkdir(dirp, dchild, iap->ia_mode);
if (!host_err && unlikely(d_unhashed(dchild))) {
struct dentry *d;

--b.

Bug#961850: dpkg: autopkgtest needs update for new version of make-dfsg: fails on warning

[Guillem Jover]

Hi!

On Sat, 2020-05-30 at 14:58:50 +0200, Paul Gevers wrote:
> Source: dpkg
> Version: 1.19.7
> Severity: serious
> X-Debbugs-CC: debian...@lists.debian.org, make-d...@packages.debian.org
> Tags: sid bullseye
> User: debian...@lists.debian.org
> Usertags: needs-update
> Control: affects -1 src:make-dfsg

> With a recent upload of make-dfsg the autopkgtest of dpkg fails in
> testing when that autopkgtest is run with the binary packages of
> make-dfsg from unstable. It passes when run with only packages from
> testing. In tabular form:
> 
>passfail
> make-dfsg  from testing4.3-1
> dpkg   from testing1.19.7
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. Please fix the
> warning, silence the warning or add the allow-stderr restriction.
> 
> Currently this regression is blocking the migration of make-dfsg to
> testing [1].

Ahm, sorry it seems I got confused when seeing the experimental tag by
Andreas and had forgotten completely about the content above and the
already present tags, so in my mind this didn't look urgent as not
affecting sid. :/ In any case I've been finishing the release during
the weekend and hope to upload tomorrow or so.

Thanks,
Guillem

Bug#962925: partman-efi: improve non_efi_system question

[McIntyre, Vincent (CASS, Marsfield)]

Package: partman-efi
Version: 84
Severity: minor

If find the partman-efi/non_efi_system question somewhat confusing.

If one sets it to 'false' that means the installer will configure
the system for BIOS mode booting, even if the installer is running
in EFI mode.
If one sets it 'true', then even if there are partitions that look
like they require non-EFI booting, the system will be set up to
boot in EFI mode.
The default is not indicated in the template but seems to be 'false'.

I feel this could be improved by either inverting the logic of the
setting or changing the question name.

If we think how 'non_efi_system: false' reads (to a nonspecialist)
it suggests we have an EFI(-only) system, does it not?
But in fact it is intended to mean the opposite case.

A better question name might be: partman-efi/efi_boot_only.
This would work with the existing logic settings and I think
conveys the intent of the question more clearly.
I'm not sure how name changes like this are effected in d-i,
presumably one adds the new one and starts a deprecation of
the old one?

Kind regards
Vince

tiny patch to show what the default setting is:

diff --git a/debian/partman-efi.templates b/debian/partman-efi.templates
index af3f8e4..cf766da 100644
--- a/debian/partman-efi.templates
+++ b/debian/partman-efi.templates
@@ -44,6 +44,7 @@ _Description: EFI partition too small
 
 Template: partman-efi/non_efi_system
 Type: boolean
+Default: false
 # :sl2:
 _Description: Force UEFI installation?
  This machine's firmware has started the installer in UEFI mode but

Bug#924290: [rfc] information about EFI partitions

[McIntyre, Vincent (CASS, Marsfield)]

On Mon, Jun 01, 2020 at 02:34:40PM +1000, Vincent McIntyre wrote:
>
>Revised patch below. I'll test it on amd64 and let you know
>if it works.

This has now been tested on a number of installs and works ok.
I think it's good to go now.

The partman-efi/non_efi_system question is somewhat confusing,
but setting it to 'true' is what one wants if you want to be sure
the system boots in EFI mode.

Regards
Vince

>diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
>index d7570d6b3..9757883b3 100644
>--- a/en/appendix/preseed.xml
>+++ b/en/appendix/preseed.xml
>@@ -1206,6 +1211,20 @@ d-i partman-auto/choose_recipe select atomic
># system labels, volume group names and which physical devices to include
># in a volume group.
>
>+## Partitioning for EFI
>+# If your system needs an EFI partition you could add something like
>+# this to the recipe above, as the first element in the recipe:
>+#   538 538 1075 free  \
>+#  $iflabel{ gpt } \
>+#  $reusemethod{ } \
>+#  method{ efi }   \
>+#  format{ }   \
>+#   .  \
>+#
>+# The fragment above is for the amd64 architecture; the details may be
>+# different on other architectures. The 'partman-auto' package in the
>+# D-I source repository may have an example you can follow.
>+
># This makes partman automatically partition without confirmation, provided
># that you told it what to do using one of the methods above.
>d-i partman-partitioning/confirm_write_new_label boolean true
>@@ -1213,6 +1232,12 @@ d-i partman/choose_partition select finish
>d-i partman/confirm boolean true
>d-i partman/confirm_nooverwrite boolean true
>
>+# Force UEFI booting ('BIOS compatibility' will be lost). Default: false.
>+#d-i partman-efi/non_efi_system boolean true
>+# Ensure the partition table is GPT - this is required for EFI
>+#d-i partman-partitioning/choose_label string gpt
>+#d-i partman-partitioning/default_label string gpt
>+
># When disk encryption is enabled, skip wiping the partitions beforehand.
>#d-i partman-auto-crypto/erase_disks boolean false
>
>

-- 

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported ZFS (with acltype=off) (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[Elliott Mitchell]

On Mon, Jun 15, 2020 at 10:50:35AM -0400, J. Bruce Fields wrote:
> Honestly I don't think I currently have a regression test for this so
> it's possible I could have missed something upstream.  I haven't seen
> any reports, though
> 
> ZFS's ACL implementation is very different from any in-tree
> filesystem's, and given limited time, a filesystem with no prospect of
> going upstream isn't going to get much attention, so, yes, I'd need to
> see a reproducer on xfs or ext4 or something.

Salvatore managing to reproduce it with ext4 yet all prior reports with
the filesystem used being known was ZFS seems to suggest one of two
things.

First, could be enabling POSIX ACLs has been very strongly pushed by
other filesystems, while ZFS hasn't pushed them as strongly.

Second, could be a substantial majority of users of NFS are using ZFS.

If the former, this simply means an additional test case is needed.  If
the latter, then any testing of NFS which excludes ZFS is going to have
underwhelming coverage.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#956452: dpkg: Support for parallel decompression

[Guillem Jover]

Hi!

On Sat, 2020-04-11 at 14:44:32 +0200, Sebastian Andrzej Siewior wrote:
> Package: dpkg
> Version: 1.19.7
> Severity: wishlist

> I've been thinking about parallel decompression for dpkg/xz. Is there
> any interest in doing this? I hacked parallel-unxz [0] in the meantime
> to see what is missing from the API point of view (query block offsets
> is missing).

I'm interested, but mainly if this is provided transparently by
liblzma, in a similar way as it is currently provided for compression.

> My idea of accomplishing this is roughly the following:
> During archive creation the output of tar is also analysed (like via
> libarchive) in order to gain the start position of the files within the
> uncompressed archive (which is something pixz does).

When I checked the implementation in pixz it looked not very efficient
in terms of memory, AFAIR.

> Once we have those, we can reduce the list to the files which spread
> accross a block within the stream and those which are the first files
> within a block.
> Then on the decompression side, each thread could focus on an
> independent block. It starts decompressing the block and throws away
> data until it reaches the start of a file. Then it continues to
> decompress as many files as it can until it reaches the end of the block
> and finishes the file crossing the block boudary.
> 
> So is this something that sounds worth doing or does it sound too
> complex / hacky in general?

The biggest issue is that the dpkg codebase is very much not
thread-safe, so implementing this would imply either duplicating much
of the existing infrastructure, such as using different error handling
stuff, or to bolt this on top, which seems rather unappealing.

I've seen the discussion in the upstream list, and I'd really like to
get this supported there, also because it would benefit many other
projects. :)

Thanks,
Guillem

Bug#962924: meanwhile: Please switch to new upstream (on GitHub)

[Boyuan Yang]

Source: meanwhile
Version: 1.0.2-9
Severity: important
Tags: sid  bullseye

The new upstream is at https://github.com/obriencj/meanwhile with some new
releases.

-- 
Regards,
Boyuan Yang


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

Bug#962923: konsole: ctrl+l behaviour changed, now deletes the text

[Ismael]

Package: konsole
Version: 4:19.08.1-2+b1
Severity: normal

Dear Maintainer,

After an update around March, every time I press ctrl+l to clear the
scrollback buffer, instead of moving the text upwards out of sight,
but keeping it there for further consulting, it just clears everything
in the screen, but still leaves older output text that's outside the
current view.

I verified it does the same when executing directly "clear -x"

I verified it's a konsole problem, as xfce4-terminal and gnome-terminal
stil maintain the previous behaviour.

Just this weekend I did a fresh install of Debian/testing and verified
that the problem is not about my configuration, used standar US/english
and UTF-8 encoding for the installation.

Pressing ctrl+l should just "move" everything on the screen upwards
but keep it there, it the scrollback buffer.



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

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

Versions of packages konsole depends on:
ii  kio5.70.1-1
ii  konsole-kpart  4:19.08.1-2+b1
ii  libc6  2.30-8
ii  libkf5configcore5  5.70.0-1
ii  libkf5configwidgets5   5.70.0-1
ii  libkf5coreaddons5  5.70.0-1
ii  libkf5crash5   5.70.0-1
ii  libkf5dbusaddons5  5.70.0-1
ii  libkf5globalaccel-bin  5.70.0-1
ii  libkf5globalaccel5 5.70.0-1
ii  libkf5i18n55.70.0-1
ii  libkf5iconthemes5  5.70.0-1
ii  libkf5kiowidgets5  5.70.1-1
ii  libkf5notifyconfig55.70.0-1
ii  libkf5widgetsaddons5   5.70.0-1
ii  libkf5windowsystem55.70.0-1
ii  libkf5xmlgui5  5.70.0-1
ii  libqt5core5a   5.12.5+dfsg-10+b1
ii  libqt5gui5 5.12.5+dfsg-10+b1
ii  libqt5widgets5 5.12.5+dfsg-10+b1
ii  libstdc++6 10.1.0-3

konsole recommends no packages.

Versions of packages konsole suggests:
pn  lrzsz  

-- no debconf information

Bug#958437: dpkg: [INTL:zh_CN] Simplified Chinese translation update (rebased)

[Boyuan Yang]

Hi,

在 2020-06-15星期一的 05:08 +0200，Guillem Jover写道：
> Hi!
> 
> On Sun, 2020-06-14 at 21:51:46 -0400, Boyuan Yang wrote:
> > On Tue, 21 Apr 2020 21:44:40 -0400 Boyuan Yang wrote:
> > > (With my Debian Chinese Team member hat on) Please find the updated
> > Simplified
> > > Chinese translation for dpkg in the attachment. This updated PO file
> > should be
> > > applied in the "master" branch (i.e. the trunk development branch
> > following
> > > 1.20.0 tag).
> > 
> > In 
> > https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=23aea35bc12fbfe3cf49057c7fc4f942fc355708
> >  I found that the PO files in dpkg master branch has been refreshed
> > again. As a result, I'm preparing a rebased PO file against current
> > dpkg HEAD. Please find the updated file in the attachment.
> 
> Oh sorry about that! I had lost track of this one I'm afraid. :`(
> (Even though I then tend to check for any such l10n bug just before a
> release.) I've merged this now locally, will be included in my next push.

Thanks for the quick response!

> > Could this file be merged in dpkg repo soon? If the POT/PO files get
> > updated again, I will have to rebase all my previous work against the
> > new PO file again, which is quite troublesome.
> 
> Please let me know in the future if I ever miss something like this
> again, and I'll gladly do the merge myself. I do hope you didn't do the
> bulk of the merge manually though and used something like msgmerge to
> do that (at least that's what I'd have used)?

I used msgmerge but also manually diff-ed and reviewed again. A double review
would always be good :) Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#953629: Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]

[Felix Lechner]

Hi Sean,

On Mon, Jun 15, 2020 at 5:18 PM Sean Whitton  wrote:
>
> As
> discussion is ongoing in the context of Lintian, that seems premature,
> however.

The Lintian discussion was merged into a bug Guillem had filed to
further enshrine the division between native and non-native packages
Bug#944155 was about reminding maintainers to use a hyphen, or not.

Based on your note, however, Lintian will stop warning about such
version mismatches. Perhaps it will gradually pave the way for a
constructive policy debate. Thanks!

> So I think we can close the clone of this bug against Policy for now.

Totally agree, for now.

Kind regards
Felix Lechner

Bug#962664: python3-distro: Please mark as Multi-Arch: foreign

[Guillem Jover]

Control: reassign -1 python3-distro
Control: retitle -1 python3-distro: Please mark as Multi-Arch: foreign

On Thu, 2020-06-11 at 15:14:20 +0100, Mike wrote:
> Package: dpkg
> Version: 1.19.7
> Severity: important

> I am trying to cross-grade at least some of my system from i386 to amd64.
> In particular I'm trying to swtich dpkg so that the default arch for
> anything new is amd64.
> 
> I followed the instructions here:
> https://wiki.debian.org/CrossGrading
> but after installing tar, dpkg and apt amd64 versions there are a lot
> of broken packages, and apt isn't able to resolve it, so
> I switched them back and did some more investigation.
> 
> There are several packages that cannot be installed, but they all seem
> to be the same root cause.  The simplest example is yelp:am64
> 
>  apt install yelp:amd64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  yelp:amd64 : Depends: python3-distro:amd64 but it is not installable
> E: Unable to correct problems, you have held broken packages.
> 
>  dpkg -l python3-distro
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   Version  Architecture Description
> +++-==---=
> ii  python3-distro 1.3.0-1  all  Linux OS platform information API
> 
> 
> There is no way to install yelp:amd64.
> 
> Installing via dpkg -i gives the same dependency error.
> 
> It depends on python3-distro:amd64, but python3-distro is architecture
> independent, and already installed.

An arch:all package by default is considered to be of the same
architecture as the native one. So yelp:amd64 depending on python3-distro
implies it wants python3-distro:amd64 which is not satisfied as it is
only evaluated as python3-distro:i386.

To tell the packaging system that this dependency is safe and truly
architecture independent, it needs to be marked as Multi-Arch: foreign.

Thanks,
Guillem

Bug#962912: glib2.0: g_file_copy_attributes() chokes on binary xattr values

[Sergio Gelato]

control: tags -1 + patch

* Philip Withnall [2020-06-15 23:25:18 +0200]:
> https://gitlab.gnome.org/GNOME/glib/-/issues/422
> 
> Nobody has yet found time to work on it; merge requests are welcome!

Here is a patch that works for me.
Handle arbitrary binary data in extended attribute values.

It's safe to assume an escaped string doesn't contain embedded null bytes,
but raw memory buffers (as returned by getxattr()) require more care.

If the length of the data to be escaped is known, use that knowledge instead
of invoking strlen().

Also correct an off-by-one error in hex_unescape_string()'s computation of
the output string length.
--- a/gio/glocalfileinfo.c
+++ b/gio/glocalfileinfo.c
@@ -293,17 +293,15 @@
 }
 
 static char *
-hex_escape_string (const char *str, 
+hex_escape_buffer (const char *str, 
+   size_t  len,
gboolean   *free_return)
 {
-  int num_invalid, i;
+  size_t num_invalid, i;
   char *escaped_str, *p;
   unsigned char c;
   static char *hex_digits = "0123456789abcdef";
-  int len;
 
-  len = strlen (str);
-  
   num_invalid = 0;
   for (i = 0; i < len; i++)
 {
@@ -340,6 +338,13 @@
 }
 
 static char *
+hex_escape_string (const char *str, 
+   gboolean   *free_return)
+{
+  return hex_escape_buffer (str, strlen(str), free_return);
+}
+
+static char *
 hex_unescape_string (const char *str, 
  int*out_len, 
  gboolean   *free_return)
@@ -377,10 +382,10 @@
   else
 	*p++ = str[i];
 }
-  *p++ = 0;
-
   if (out_len)
 *out_len = p - unescaped_str;
+  *p++ = 0;
+
   *free_return = TRUE;
   return unescaped_str;
 }
@@ -394,7 +399,7 @@
   char *escaped_val;
   gboolean free_escaped_val;
   
-  escaped_val = hex_escape_string (value, _escaped_val);
+  escaped_val = hex_escape_buffer (value, len, _escaped_val);
   
   g_file_info_set_attribute_string (info, gio_attr, escaped_val);
   

Bug#938554: RFS: spyne/2.13.15-0.1 [NMU, RC] -- Python library for writing and calling soap web service

[Bastian Germann]

Am 16.06.20 um 02:17 schrieb Russell Stuart:
> On Tue, 2020-06-16 at 02:00 +0200, Bastian Germann wrote:
>> It is no longer marked as alpha; version 2.13.15 > 2.13.4-alpha.
>> Please check the RFS again.
> 
> Apologies Bastian, I was looking at spyne's home page.  The non-alpha
> version has indeed been released today.
> 
> How "released today" translates to "plenty of notice for an NMU" is
> puzzling.  Why you are asking for mentors to package it given I [0]
> said this is also puzzling:
> 
>But it does seem like Spyne for Python 3 will be stable before the
>bullseye deadlines hit. And I will upload it as soon as an I am
>aware it has been released.
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938554#39
> 

You did not answer to grave bug #960662 in a month so this seemed to be
the best way forward. This could have been resolved by another Python 2
only upload (from a stable version) but it seemed to me you did not care.

Bug#961723:

[Felix-Etienne Gauthier]

I agree! It would be nice to have a package for nftables.


[image: Mailtrack]

Sender
notified by
Mailtrack

15/06/20
à 20:36:49

Bug#938554: RFS: spyne/2.13.15-0.1 [NMU, RC] -- Python library for writing and calling soap web service

[Russell Stuart]

On Tue, 2020-06-16 at 02:00 +0200, Bastian Germann wrote:
> It is no longer marked as alpha; version 2.13.15 > 2.13.4-alpha.
> Please check the RFS again.

Apologies Bastian, I was looking at spyne's home page.  The non-alpha
version has indeed been released today.

How "released today" translates to "plenty of notice for an NMU" is
puzzling.  Why you are asking for mentors to package it given I [0]
said this is also puzzling:

   But it does seem like Spyne for Python 3 will be stable before the
   bullseye deadlines hit. And I will upload it as soon as an I am
   aware it has been released.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938554#39


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

Bug#938554: RFS: spyne/2.13.15-0.1 [NMU, RC] -- Python library for writing and calling soap web service

[Bastian Germann]

Am 16.06.20 um 01:39 schrieb Russell Stuart:
> On Tue, 2020-06-16 at 00:58 +0200, Bastian Germann wrote:
>> Dear mentors,
>>
>> I am looking for a sponsor for the package "spyne" which has a
>> py2removal RC and a grave bug and was autoremoved from testing.
>> The package is Python 2 only but the current upstream version has
>> Python 3 support. I converted it to build a binary python3-spyne
>> package. The bugs are open long enough for a NMU.
>
> Dear mentors,
>
> Beware if you do NMU this it will be against the wishes of the
> Debian maintainer for spyne - which is me.
>
> The issue is the current stable upstream is does _not_ have Python
> 3 support.  The version of spyne that does have Python3 support
> "2.13.4- alpha".
>
> I personally use spyne in production (which is why I now maintain
> it). I do my best to avoid running code on my systems that upstream
> has marked as an alpha release.
>
> I plan to package and upload the Python3 version once it is no
> longer marked as alpha code.

It is no longer marked as alpha; version 2.13.15 > 2.13.4-alpha.
Please check the RFS again.

Bug#962922: invada-studio-plugin-lv2 edit dialog suil error

[Paulo S. Pinheiro]

Package: invada-studio-plugin-lv2

Version: 1.2.0+repack0-8

Uname: Linux 5.4.0-37-lowlatency x86_64

DistroRelease: Ubuntu 20.04

Description:

Since I upgraded to Ubuntustudio 20.04 (Intel 64-bit) I can't open the 
INVADA plugins edit dialog on Ardour5 (rev 1:5.12.0-3ubuntu4). No error 
message dialog.
Running Ardour5 on terminal and trying again I get the following message 
line (example: Invada Early Reflection Reverb):


   *"suil error: Unable to open UI library
   /usr/lib/lv2/invada.lv2/inv_erreverb_gui.so
   (/usr/lib/lv2/invada.lv2/inv_erreverb_gui.so: undefined symbol:
   __sinh_finite)"*.

The *inv_erreverb_gui.so* is correctly in */usr/lib/liv2/invada.lv2* 
directory.


The Ardour native generic control editor dialog works fine for the plugins.

I noticed some LV2 plugins editors open correctly, some others don't. 
Here are the ones with the problem:

. Invada Compressor
. Invada Early Reflection Reverb
. Invada High Pass Filter
. Invada Input Module
. Invada Low Pass Filter
. Invada Meter
. Invada Stereo Phaser
. Invada Tube Distortion

The "good" ones:
. Invada Delay Munge
. Invada Test Tones

The error messages for the other problematic plugins are similar to the 
one above. The files are all there on the expected directory.

Haven't find any workaround by Ubuntu Studio or Ardour.

When I tried to compile the Ubuntu package 
(invada-studio-plugins-lv2_1.2.0+repack0) from source I got the error:


"dpkg-checkbuilddeps: erro: Unmet build dependencies: debhelper (>= 11) 
libgtk2.0-dev lv2-dev"


In my system I have:
debhelper: 12.10ubuntu1
libgtk2.0-dev: 2.24.32-4ubuntu4
lv2-dev: 1.16.0-1

So, it seems to me that the plugin is not compatible with the new 
libgtk2.0-dev library, and/or lv2-dev.


But I'm very newbie.


Any other information you need to solve the problem, please let me know.


Thank you in Advance


Paulo S. Pinheiro

Bug#938554: RFS: spyne/2.13.15-0.1 [NMU, RC] -- Python library for writing and calling soap web service

[Russell Stuart]

On Tue, 2020-06-16 at 00:58 +0200, Bastian Germann wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the package "spyne" which has a
> py2removal RC and a grave bug and was autoremoved from testing. The
> package is Python 2 only but the current upstream version has Python
> 3 support. I converted it to build a binary python3-spyne package.
> The bugs are open long enough for a NMU.

Dear mentors,

Beware if you do NMU this it will be against the wishes of the Debian
maintainer for spyne - which is me.

The issue is the current stable upstream is does _not_ have Python 3
support.  The version of spyne that does have Python3 support "2.13.4-
alpha".

I personally use spyne in production (which is why I now maintain it). 
I do my best to avoid running code on my systems that upstream has
marked as an alpha release.

I plan to package and upload the Python3 version once it is no longer
marked as alpha code.


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

Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]

[Sean Whitton]

Hello,

On Wed 11 Mar 2020 at 12:30PM GMT, Ian Jackson wrote:

> Felix Lechner writes ("Re: Bug#953554: Please permit Debian revisions with 
> 1.0 native packages [and 1 more messages]"):
>> On Wed, Mar 11, 2020 at 4:58 AM Ian Jackson
>>  wrote:
>> >
>> > It works today.  The only problem is the lintian warning.
>>
>> Doesn't policy stand in the way too?
> ...
>> Is it permitted now? Policy 3.2.1 states "hyphen (-) cannot be used in
>> native package versions."

I believe that the relevant sentence of Policy, added in policy.git
commit eee39aecef3a6a5f9927211b5c847e645e927cbd, was intended to be
informative, not normative.  It does not use one of the Policy normative
magic words, is not in the subsection in which it would be natural to
place such a restriction, and occurs in a "hey, don't forget that ..."
clause.

Thus the only Policy issue here could be the addition of an explicit
permission to use Debian revisions with 1.0 native packages.  As
discussion is ongoing in the context of Lintian, that seems premature,
however.

So I think we can close the clone of this bug against Policy for now.

-- 
Sean Whitton

Bug#962920: mhonarc: Links that include a message ID are mangled

[наб]

Package: mhonarc
Version: 2.6.19-2
Severity: normal

Dear Maintainer,

Any link that includes a message ID is mangled.

I'm attaching the original message that exhibited this,
and two screenshots, one from lists.d.o[1], and one from a clean
unconfigured "mhonarc patches.mbox" run.

The resulting HTML fragment is
-- >8 --
Ref: https://lists.debian.org/msgid-search/3ff43fa102094f36688749bb866ad72d9580d47a.1592257217.git.nabijaczlew...@gmail.com">https://lists.debian.org/msgid-search/3ff43fa102094f36688749bb866ad72d9580d47a.1592257217.git.nabijaczlew...@gmail.com
-- >8 --
As you can see, the search link was insered directly into the href of
the  that contained the message ID. This results in the first link
(loupe on lists.d.o) being broken entirely,
and the other one linking directly to the message,
neither of which is what I indended.

Best,
наб

[1]: https://lists.debian.org/debian-boot/2020/06/msg00048.html

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

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

Versions of packages mhonarc depends on:
ii  perl  5.28.1-6

Versions of packages mhonarc recommends:
ii  perl [libdigest-md5-perl]  5.28.1-6

mhonarc suggests no packages.

-- no debconf information
--- Begin Message ---
The hard versioned dependency is required since that function will have
just moved in in 1.195 and we didn't depend on base-installer before

This shouldn't affect users, since apt-mirror-setup is likely pulled in
by apt-setup-udeb, which depends on installed-base,
provided by bootstrap-base and live-installer,
both of which depend on base-installer

Ref: 
https://lists.debian.org/msgid-search/3ff43fa102094f36688749bb866ad72d9580d47a.1592257217.git.nabijaczlew...@gmail.com
---
 debian/changelog|  8 
 debian/control  |  2 +-
 generators/50mirror | 16 +++-
 3 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index b434904..61ad8de 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+apt-setup (1:0.158) unstable; urgency=medium
+
+  [ наб ]
+  * apt-mirror-setup: Depend on base-installer (>= 1.195)
+  * generators/50mirror: Use is_ports_architecture from base-installer
+
+ -- Holger Wansing   Mon, 15 Jun 2020 23:42:43 +0200
+
 apt-setup (1:0.157) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 1707e06..4e46e44 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Description: Configure apt
 Package: apt-mirror-setup
 Package-Type: udeb
 Architecture: all
-Depends: choose-mirror-bin, ${misc:Depends}
+Depends: choose-mirror-bin, base-installer (>= 1.195), ${misc:Depends}
 Description: set up a mirror in sources.list
 
 Package: apt-cdrom-setup
diff --git a/generators/50mirror b/generators/50mirror
index 42e62ac..e8c60a1 100755
--- a/generators/50mirror
+++ b/generators/50mirror
@@ -2,6 +2,7 @@
 set -e
 
 . /usr/share/debconf/confmodule
+. /usr/lib/base-installer/library.sh
 
 file="$1"
 
@@ -25,22 +26,11 @@ ask_no_mirror() {
fi
 }
 
-is_ports_architecture() {
-   case "$(chroot /target /usr/bin/dpkg --print-architecture)" in
-   
alpha|hppa|hurd-i386|ia64|kfreebsd-amd64|kfreebsd-i386|m68k|powerpc|ppc64|riscv64|sh4|sparc64|x32)
-   log "Debian-Ports architecture detected"
-   return 0
-   ;;
-   *)
-   return 1
-   ;;
-   esac
-}
-
 # For architectures in the Debian-Ports archive, sources.list has to include
 # an additional entry for the "unreleased" suite.
 unset use_unreleased
-if is_ports_architecture; then
+if is_ports_architecture "$(chroot /target /usr/bin/dpkg 
--print-architecture)"; then
+   log "Debian-Ports architecture detected"
use_unreleased=yes
 fi
 
-- 
2.20.1


signature.asc
Description: PGP signature
--- End Message ---


signature.asc
Description: PGP signature

Bug#962921: apticron: Use of tempfile(1) produces a warning message

[Aaron Schrab]

Package: apticron
Version: 1.2.3+nmu1
Severity: normal
Tags: patch

Dear Maintainer,

Starting with debianutils version 4.10 the tempfile(1) program displays
a run-time deprecation warning; this causes cron to send the output via
email separate from any message that would be sent by apticron.

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

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

Versions of packages apticron depends on:
ii  apt 2.1.6
ii  bsd-mailx [mailx]   8.1.2-0.20180807cvs-1+b1
ii  bzip2   1.0.8-3
ii  cron [cron-daemon]  3.0pl1-136
ii  dpkg1.19.7
ii  mailutils [mailx]   1:3.9-2
ii  ucf 3.0042

Versions of packages apticron recommends:
ii  apt-listchanges  3.22
ii  gpg  2.2.20-1
ii  iproute2 5.7.0-1

apticron suggests no packages.

-- debconf information:
  apticron/notification: root
From 8f1206539aa08487c5729830e7c7da17f0fb8bb3 Mon Sep 17 00:00:00 2001
From: Aaron Schrab 
Date: Mon, 15 Jun 2020 19:52:18 -0400
Subject: [PATCH] Use mktemp(1) rather than tempfile(1)

Starting with debianutils version 4.10 the tempfile(1) program displays
a run-time deprecation warning; this causes cron to send the output via
email separate from any message that would be sent by apticron. Switch
to using mktemp(1) instead.
---
 apticron | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/apticron b/apticron
index fceb182..dcce1f6 100755
--- a/apticron
+++ b/apticron
@@ -4,10 +4,10 @@
 # implementations in Debian. Make sure we send proper headers, and a
 # text/plain content type.
 Mailx() {
-MAIL_BODY_FILE=$(tempfile)
+MAIL_BODY_FILE=$(mktemp)
 cat > "$MAIL_BODY_FILE"
 if [ "x$GPG_ENCRYPT" = "x1" ] && gpg --list-public-keys "$EMAIL" > /dev/null 2>&1; then
-MAIL_ENC_FILE=$(tempfile)
+MAIL_ENC_FILE=$(mktemp)
 gpg --trust-model always --batch --armor --encrypt --recipient "$EMAIL" < "$MAIL_BODY_FILE" > "$MAIL_ENC_FILE"
 mv "$MAIL_ENC_FILE" "$MAIL_BODY_FILE"
 fi
-- 
2.27.0

Bug#962919: RFS: spyne/2.13.15-0.1 [NMU, RC] -- Python library for writing and calling soap web service

[Bastian Germann]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the package "spyne" which has a
py2removal RC and a grave bug and was autoremoved from testing. The
package is Python 2 only but the current upstream version has Python 3
support. I converted it to build a binary python3-spyne package. The
bugs are open long enough for a NMU.

 * Package name: spyne
   Version : 2.13.15-0.1
   Upstream Author : Burak Arslan 
 * URL : http://spyne.io/
 * License : LGPL-2.1+
   Section : python

It builds those binary packages:

  python3-spyne - Python library for writing and calling soap web service

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/spyne/spyne_2.13.15-0.1.dsc

Regards,
Bastian

Bug#962918: ITP: bacula-libs3 -- S3 library for Bacula

[Carsten Leonhardt]

Package: wnpp
Severity: wishlist
Owner: Carsten Leonhardt 

* Package name: bacula-libs3
  Version : 0~20200523
  Upstream Author : Bryan Ischo , modified by Bacula Systems
* URL : https://www.bacula.org/downloads/
* License : LGPL 3+
  Programming Lang: C
  Description : S3 library for Bacula
This is a C library to access S3 storage with Bacula. This version
is modified version of libs3 and maintained by Bacula Systems to
work with Bacula.
  

We, the Debian Bacula Packaging Team are packaging and will be
maintaining this as an enhancement for Bacula. The possibility to use
S3 storage is often asked about on the Bacula mailing lists and is also
mentioned in #928343.

To not get in the way of the libs3 package, we plan to use a private
location for the library.

Bug#962917: libatomic-ops: FTBFS in the testsuite on riscv64 due to missing -pthread

[Karsten Merker]

Source: libatomic-ops
Version: 7.6.10-1
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

libatomic-ops FTBFS on riscv64 due to link failures in the
testsuite. The build log is available at

  
https://buildd.debian.org/status/fetch.php?pkg=libatomic-ops=riscv64=7.6.10-1=1588631725=0

The source of the link failures is that the tests aren't built
with the "-pthread" compiler flag.

Some architectures such as risc64 have native atomics support,
but only for word-sized operands and not for smaller entities. 
When called with "-pthread", gcc automatically links in the
necessary wrapper functions to provide the missing atomic
operations on those architectures, but this doesn't happen when
one just links in libpthread with "-lpthread".

Building the tests with "-pthread" in CFLAGS solves the build
failures. It would be great if you could upload a new version
of the package with a corresponding change.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.

Bug#961629: [Python-modules-team] Bug#961629: /usr/bin/virtualenv: Re: python3-virtualenv: Fails to create a Python 3.7 environment

[Scott Kitterman]

On Monday, June 15, 2020 6:06:53 PM EDT ottakar wrote:
> Package: python3-virtualenv
> Version: 20.0.21+ds-2
> Followup-For: Bug #961629
> 
> Dear Maintainer,
> 
> Could someone confirm I encountered the same bug?
> 
> I install a fresh `python3.7.7`, but `pip` fails inside virtual environments
> created with this installation.
> 
> $ virtualenv --clear -p ~/pylocal/bin/python3.7 .venvpylocal37
> created virtual environment CPython3.7.7.final.0-64 in 98ms
>   creator CPython3Posix(dest=/home/user/git/repo/.venvpylocal37, clear=True,
> global=False) seeder FromAppData(download=False, pip=latest,
> setuptools=latest, wheel=latest, pkg_resources=latest, via=copy,
> app_data_dir=/home/user/.local/share/virtualenv/seed-app-data/v1.0.1.debian
> ) activators
> BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActiv
> ator,XonshActivator $ source .venvpylocal37/bin/activate;pip -V
> Traceback (most recent call last):
>   File "/home/user/git/repo/.venvpylocal37/bin/pip", line 5, in 
> from pip._internal.cli.main import main
> File
> "/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_intern
> al/cli/main.py", line 10, in  from pip._internal.cli.autocompletion
> import autocomplete
>   File
> "/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_intern
> al/cli/autocompletion.py", line 9, in  from
> pip._internal.cli.main_parser import create_main_parser
>   File
> "/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_intern
> al/cli/main_parser.py", line 7, in  from pip._internal.cli import
> cmdoptions
>   File
> "/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_intern
> al/cli/cmdoptions.py", line 24, in  from
> pip._internal.cli.progress_bars import BAR_TYPES
>   File
> "/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_intern
> al/cli/progress_bars.py", line 7, in  from pip._vendor import six
> ImportError: cannot import name 'six' from 'pip._vendor'
> (/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_vendor
> /__init__.py) zsh: exit 1 pip -V
> 
> 
> Python3 installation provided by OS : 3.8 is default, 3.7 is still there
> (almost partly) :
> 
> ~$ python3 -m pip -V
> pip 20.1.1 from /usr/lib/python3/dist-packages/pip (python 3.8)
> ~$ python3.7 -V
> Python 3.7.3
> ~$ python3.7 -m pip -V
> Traceback (most recent call last):
>   File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
> "__main__", mod_spec)
>   File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
> exec(code, run_globals)
>   File "/usr/lib/python3/dist-packages/pip/__main__.py", line 23, in
>  from pip._internal.cli.main import main as _main  # isort:skip #
> noqa File "/usr/lib/python3/dist-packages/pip/_internal/cli/main.py", line
> 10, in  from pip._internal.cli.autocompletion import autocomplete
>   File "/usr/lib/python3/dist-packages/pip/_internal/cli/autocompletion.py",
> line 9, in  from pip._internal.cli.main_parser import
> create_main_parser
>   File "/usr/lib/python3/dist-packages/pip/_internal/cli/main_parser.py",
> line 7, in  from pip._internal.cli import cmdoptions
>   File "/usr/lib/python3/dist-packages/pip/_internal/cli/cmdoptions.py",
> line 19, in  from distutils.util import strtobool
> ModuleNotFoundError: No module named 'distutils.util'
> 
> 
> My `python3.7.7` installation in _userland_ follows this way :
> https://unix.stackexchange.com/a/350985/280824. I try a `sudo make
> install`, it do not change situation.
> 
> ~$ ./pylocal/bin/python3.7 -m pip -V
> pip 19.2.3 from /home/user/pylocal/lib/python3.7/site-packages/pip (python
> 3.7) ~$ ./pylocal/bin/python3.7 -c 'from pip._vendor import six'
> ~$ source .venvpylocal37/bin/activate
> (.venvpylocal37) ~$ pip -V
> Traceback (most recent call last):
>   File "/home/user/.venvpylocal37/bin/pip", line 5, in 
> from pip._internal.cli.main import main
>   File
> "/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/ma
> in.py", line 10, in  from pip._internal.cli.autocompletion import
> autocomplete
>   File
> "/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/au
> tocompletion.py", line 9, in  from pip._internal.cli.main_parser
> import create_main_parser
>   File
> "/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/ma
> in_parser.py", line 7, in  from pip._internal.cli import cmdoptions
>   File
> "/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/cm
> doptions.py", line 24, in  from pip._internal.cli.progress_bars
> import BAR_TYPES
>   File
> "/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/pr
> ogress_bars.py", line 7, in  from pip._vendor import six
> ImportError: cannot import name 'six' from 'pip._vendor'
> (/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_vendor/__init__
> .py)
> 
> For memory, I created an issue to `pypa/virtualenv` (they told me this is a
> Debian issue): 

Bug#962915: RM: swt4-gtk [armel armhf i386 mipsel] -- ROM; Upstream no longer supports 32 bits architectures

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the swt4-gtk packages from armel, armhf, i386 and mipsel:
 * libswt-cairo-gtk-4-jni 
 * libswt-glx-gtk-4-jni 
 * libswt-gtk-4-jni 
 * libswt-webkit-gtk-4-jni 

Eclipse has dropped 32 bits support and SWT 4.15 now fails to build
on these architectures.

Thank you,

Emmanuel Bourg

Bug#909267: library-not-linked-against-libc: downgrade from error

[Felix Lechner]

Control: forcemerge 896012 909267

Hi Russ,

> I wonder if we would get all of the utility out of the tag if instead it
> looked for shared libraries with no NEEDED metadata.  I think it's only
> catching libraries that aren't linked with anything else, so maybe just
> check for that explicitly?

That is a super creative suggestion! However, nothing may be wrong
with those libraries. We seem to ship quite a few [1].

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

> My recollection is that Simon is correct and we added this tag to try to
> find shared libraries that weren't linked to any of their dependencies.

I don't believe Lintian can do something like that. As described in
the merged bug [2], I think we need a portfolio-wide dependency
tracker.

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896012#31

This tag will be removed in the near future.

Kind regards
Felix Lechner

Bug#961629: /usr/bin/virtualenv: Re: python3-virtualenv: Fails to create a Python 3.7 environment

[ottakar]

Package: python3-virtualenv
Version: 20.0.21+ds-2
Followup-For: Bug #961629

Dear Maintainer,

Could someone confirm I encountered the same bug?

I install a fresh `python3.7.7`, but `pip` fails inside virtual environments 
created with this installation.

$ virtualenv --clear -p ~/pylocal/bin/python3.7 .venvpylocal37
created virtual environment CPython3.7.7.final.0-64 in 98ms
  creator CPython3Posix(dest=/home/user/git/repo/.venvpylocal37, clear=True, 
global=False)
  seeder FromAppData(download=False, pip=latest, setuptools=latest, 
wheel=latest, pkg_resources=latest, via=copy, 
app_data_dir=/home/user/.local/share/virtualenv/seed-app-data/v1.0.1.debian)
  activators 
BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
$ source .venvpylocal37/bin/activate;pip -V
Traceback (most recent call last):
  File "/home/user/git/repo/.venvpylocal37/bin/pip", line 5, in 
from pip._internal.cli.main import main
File 
"/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/main.py",
 line 10, in 
from pip._internal.cli.autocompletion import autocomplete
  File 
"/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/autocompletion.py",
 line 9, in 
from pip._internal.cli.main_parser import create_main_parser
  File 
"/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/main_parser.py",
 line 7, in 
from pip._internal.cli import cmdoptions
  File 
"/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/cmdoptions.py",
 line 24, in 
from pip._internal.cli.progress_bars import BAR_TYPES
  File 
"/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/progress_bars.py",
 line 7, in 
from pip._vendor import six
ImportError: cannot import name 'six' from 'pip._vendor' 
(/home/user/git/repo/.venvpylocal37/lib/python3.7/site-packages/pip/_vendor/__init__.py)
zsh: exit 1 pip -V


Python3 installation provided by OS : 3.8 is default, 3.7 is still there 
(almost partly) :

~$ python3 -m pip -V
pip 20.1.1 from /usr/lib/python3/dist-packages/pip (python 3.8)
~$ python3.7 -V
Python 3.7.3
~$ python3.7 -m pip -V
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/pip/__main__.py", line 23, in 
from pip._internal.cli.main import main as _main  # isort:skip # noqa
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/main.py", line 10, in 

from pip._internal.cli.autocompletion import autocomplete
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/autocompletion.py", 
line 9, in 
from pip._internal.cli.main_parser import create_main_parser
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/main_parser.py", line 
7, in 
from pip._internal.cli import cmdoptions
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/cmdoptions.py", line 
19, in 
from distutils.util import strtobool
ModuleNotFoundError: No module named 'distutils.util'


My `python3.7.7` installation in _userland_ follows this way : 
https://unix.stackexchange.com/a/350985/280824.
I try a `sudo make install`, it do not change situation.

~$ ./pylocal/bin/python3.7 -m pip -V
pip 19.2.3 from /home/user/pylocal/lib/python3.7/site-packages/pip (python 3.7)
~$ ./pylocal/bin/python3.7 -c 'from pip._vendor import six'
~$ source .venvpylocal37/bin/activate
(.venvpylocal37) ~$ pip -V
Traceback (most recent call last):
  File "/home/user/.venvpylocal37/bin/pip", line 5, in 
from pip._internal.cli.main import main
  File 
"/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/main.py",
 line 10, in 
from pip._internal.cli.autocompletion import autocomplete
  File 
"/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/autocompletion.py",
 line 9, in 
from pip._internal.cli.main_parser import create_main_parser
  File 
"/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/main_parser.py",
 line 7, in 
from pip._internal.cli import cmdoptions
  File 
"/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/cmdoptions.py",
 line 24, in 
from pip._internal.cli.progress_bars import BAR_TYPES
  File 
"/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_internal/cli/progress_bars.py",
 line 7, in 
from pip._vendor import six
ImportError: cannot import name 'six' from 'pip._vendor' 
(/home/user/.venvpylocal37/lib/python3.7/site-packages/pip/_vendor/__init__.py)

For memory, I created an issue to `pypa/virtualenv` (they told me this is a 
Debian issue):
https://github.com/pypa/virtualenv/issues/1860

Thanks you, and apologies if this is no appropriate : this is my first 
contribution to Debian BTS.


-- System Information:
Debian Release: 

Bug#962913: haskell-http-conduit: FTBFS on IPv6-only host

[Sebastian Ramacher]

Source: haskell-http-conduit
Version: 2.3.7.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

haskell-http-conduit failed to build on amd64:
|   27) RequestBodyIO
|uncaught exception: HttpException
|HttpExceptionRequest Request {
|  host = "127.0.0.1"
|  port = 15487
|  secure   = False
|  requestHeaders   = []
|  path = "/"
|  queryString  = ""
|  method   = "POST"
|  proxy= Nothing
|  rawBody  = False
|  redirectCount= 10
|  responseTimeout  = ResponseTimeoutDefault
|  requestVersion   = HTTP/1.1
|}
| (ConnectionFailure Network.Socket.getAddrInfo (called with preferred 
socket type/protocol: AddrInfo {addrFlags = [AI_ADDRCONFIG], addrFamily = 
AF_UNSPEC, addrSocketType = Stream, addrProtocol = 0, addrAddress = , addrCanonName = }, host name: Just 
"127.0.0.1", service name: Just "15487"): does not exist (Address family for 
hostname not supported))
|
|   To rerun use: --match "/RequestBodyIO/"
|
| Randomized with seed 542653933
|
| Finished in 3.5043 seconds

See
https://buildd.debian.org/status/fetch.php?pkg=haskell-http-conduit=amd64=2.3.7.3-1=1591626982=0

This bug looks a lot like #962019. Setting addrFlags to 0 or adding
AI_NUMERICHOST should fix it.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962914: Please consider setting default UPower critical battery action to hibernate rather than hybrid sleep

[thomasw]

Package: upower
Version: 0.99.11-2

I propose setting the critical battery action to hibernate rather than hybrid 
sleep in /etc/UPower/UPower.conf
Reasons:
1. Windows does this by default. By doing what Widnows does in this situation, 
you are more likely to get expected behavior. FWIW: Windows doesn't even expose 
hybrid sleep on laptops by default.
Real life example, my laptop and many others immediately wake when entering s3 
if the battery is below a certain percentage. The thinking from the designers 
is that the laptop will be woken up so that the operating system can hibernate 
it. The problem is that when entering hybrid sleep. UPower saves the hibernate 
disk image and enters s3 and it immediately wakes and runs until a hard 
shutdown.
2. Running lithium based batteries to flat is harmful for their longevity. If a 
machine is put into hybrid sleep at a low percentage and is not turned on for a 
few days, the battery will run completely flat.

Bug#962901: deepin-icon-theme: postinst failure in update-alternatives

[Laurent Bonnaud]

Package: deepin-icon-theme
Version: 2020.06.11-1
Severity: serious


Dear Maintainer,

here is the problem:

Setting up deepin-icon-theme (2020.06.11-1) ...
update-alternatives: error: alternative path 
/usr/share/icons/deepin/cursor.theme doesn't exist
dpkg: error processing package deepin-icon-theme (--configure):
 installed deepin-icon-theme package post-installation script subprocess 
returned error exit status 2


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

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

Versions of packages deepin-icon-theme depends on:
ii  papirus-icon-theme  20200602-1

deepin-icon-theme recommends no packages.

deepin-icon-theme suggests no packages.

-- no debconf information

-- 
Laurent.

Bug#962692: puppet: Crashes due to "missing" facts.d directories

[Gabriel Filion]

Hi,

>> A quick workaround to get facter to run is to create the three
>> directories:
> 
>> /etc/facter/facts.d
>> /etc/puppetlabs/facter/facts.d
>> /opt/puppetlabs/facter/facts.d
> 
> Yup, confirmed that works.  Thank you!

thanks for the workaround.

while it seems to work when running facter as root, I'm still getting
the same crash (back trace seems to be the same) when running facter as
an unprivileged user even though the three directories are world-readable.
I'm reporting this added detail since using puppet/facter as an
unprivileged user can be important for validating syntax, running spec
tests, etc. during development.


$ ls -ld /etc/facter/facts.d/ /etc/puppetlabs/facter/facts.d
/opt/puppetlabs/facter/facts.d
drwxr-xr-x 2 root root 4096 Jun 15 17:10 /etc/facter/facts.d/
drwxr-xr-x 2 root root 4096 Jun 15 17:10 /etc/puppetlabs/facter/facts.d
drwxr-xr-x 2 root root 4096 Jun 15 17:10 /opt/puppetlabs/facter/facts.d

$ facter
free(): invalid size
Aborted

$ gdb facter
[...]
Reading symbols from facter...
(No debugging symbols found in facter)
(gdb) r
Starting program: /usr/bin/facter
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after vfork from child process 1565235]
free(): invalid pointer

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x779bf55b in __GI_abort () at abort.c:79
#2  0x77a18038 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x77b24f3e "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x77a1f3da in malloc_printerr (str=str@entry=0x77b230e0
"free(): invalid pointer") at malloc.c:5339
#4  0x77a20dcc in _int_free (av=, p=, have_lock=0) at malloc.c:4173
#5  0x77e775d4 in ?? () from
/usr/lib/x86_64-linux-gnu/libfacter.so.3.11.0
#6  0x77e77bd8 in
facter::facts::collection::add_external_facts(std::vector, std::allocator >,
std::allocator,
std::allocator > > > const&) () from
/usr/lib/x86_64-linux-gnu/libfacter.so.3.11.0
#7  0x5557154c in main ()



signature.asc
Description: OpenPGP digital signature

Bug#962912: glib2.0: g_file_copy_attributes() chokes on binary xattr values

[Philip Withnall]

On Mon, 2020-06-15 at 23:17 +0200, Sergio Gelato wrote:
> Package: libglib2.0-0
> Version: 2.58.3-2+deb10u2
> Severity: important
> 
> g_file_copy_attributes(), when invoked with G_FILE_COPY_ALL_METADATA
> on
> files in NFS, is prone to truncating the value of extended attribute
> system.nfs4_acl. Here is an excerpt from strace output, showing the
> getxattr() and setxattr() calls:

It’s this issue upstream:
https://gitlab.gnome.org/GNOME/glib/-/issues/422

Nobody has yet found time to work on it; merge requests are welcome!

Philip

Bug#934753: dropbear-initramfs: please add an autopkgtest

[Guilhem Moulin]

Control: tag -1 pending

Hi Johannes,

On Tue, 31 Dec 2019 at 09:19:29 +0100, Johannes Schauer wrote:
> thanks again for all your very helpful comments! I think I now implemented
> everything that you suggested. I created a merge request on salsa containing
> what I think is ready to be merged:
> 
> https://salsa.debian.org/debian/dropbear/merge_requests/3

Sorry, this fell a bit off screen.  Better late than never though, it's
now merged :-)  Many thanks for this patch (incl. the CI tests), much
appreciated!

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#962912: glib2.0: g_file_copy_attributes() chokes on binary xattr values

[Sergio Gelato]

Package: libglib2.0-0
Version: 2.58.3-2+deb10u2
Severity: important

g_file_copy_attributes(), when invoked with G_FILE_COPY_ALL_METADATA on
files in NFS, is prone to truncating the value of extended attribute
system.nfs4_acl. Here is an excerpt from strace output, showing the
getxattr() and setxattr() calls:

getxattr("/home/xxx/a", "system.nfs4_acl", 0x7ffef8b54a20, 63) = -1 ERANGE 
(Numerical result out of range)
getxattr("/home/xxx/a", "system.nfs4_acl", NULL, 0) = 80
getxattr("/home/xxx/a", "system.nfs4_acl", 
"\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0", 80) = 80
setxattr("/home/xxx/b", "system.nfs4_acl", "", 0, 0) = -1 EIO (Input/output 
error)

Note how the attribute value was truncated from 80 bytes to 0. I believe this
is because the value starts with a 0 byte. gio/glocalfileinfo.c:escape_xattr()
does not make use of the len argument when computing escaped_val, but instead
invokes strlen() which is unsuitable for binary strings. A look at the latest
upstream version, 2.64.3, suggests the problem is still there.

This impacts such operations as "Save As" in evince.

Due to an unrelated bug I recommend running a recent kernel (e.g., 5.5 rather
than 4.19) when attempting to reproduce this problem.

Bug#962911: ITP: python-watchgod -- Simple, modern file watching and code reload

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-watchgod
  Version : 0.6
  Upstream Author : Samuel Colvin 
* URL : https://github.com/samuelcolvin/watchgod/
* License : Expat
  Programming Lang: Python
  Description : Simple, modern file watching and code reload


 Simple, modern file watching and code reload in python. It can watch for
 changes in a directory and run a function to restart it when code changes.
 Notifications about change events as well as to restart a process can use
 the callback argument to pass a function which will be called on every file
 change with one argument: the set of file changes.

This is a new dependency for python-uvicorn. I intend to maintain it as part of
the DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl7n3pcRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wod3Af/bA55PpuEyYvpmLwv/fxPHvzcKf01FBCw
sF56ntYZNO+86E92TbLP0U2FIQlKIJAdzj6/3VDYrDlUHpO2ukVLP6HKSxEuH4oY
wXMjXrQuAcOIbpv4NzzNipcaho+Cv9H9MnLwf0xBaJaCa9s0W5terV8PMe4OBbZ9
IbFYl5oQUhFRcsRV8Cpo23RQoYL4aUxY5TBGvDRXyUtEroMYJs7d5HtK1edyWn1K
WmrNu74hlU9Mt6V1SUwWwN00gQVULcr3A0gujDEQvR4cbSWyOiezRG4r9wEZK7OR
ZpieeqcKdwA1gi31laL2VpSdUtUnbQZQfWjhUUQvgfnmCS02u/+s6g==
=Uw5X
-END PGP SIGNATURE-

Bug#962910: Machine always entering hybrid sleep on critical battery, regardless of mate-power-manager preferences

[thomasw]

package: mate-power-manager
Version: 1.24.1-1

Steps to reproduce:
1. Use Debian Mate with a laptop with a low battery.
2. Mate sends the message that the battery is low and it is about to hibernate.
3. The machine actually enters Hybrid Sleep.

This commit gives a clue: 
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/8e6a82c585fe16978f9e1ca3437a4b96dd4e6d34
Another clue is found by running upower -d, which on my machine, says the 
configured action is hybrid sleep.

Apparently now UPower performs the action rather than the power-manager so that 
the action will occur even if a desktop session is not running. I looked at the 
dbus documentation for UPower and it doesn't seem possible to set the hibernate 
action that way. Only way I could find was  editing /etc/UPower/UPower.conf. I 
can't really see a path forward other than removing critical action from 
mate-power-manager preferences. I guess mate-power-manager should also be 
updated to read the critical action configured in UPower over dbus and notify 
the user what action will occur rather than reading its own gsettings key so at 
least it can give accurate information.

Bug#962849: alsa-lib: diff for NMU version 1.2.2-2.3

[Francisco Vilmar Cardoso Ruviaro]

Control: tags 962849 + pending

Dear maintainer,

I've prepared an NMU for alsa-lib (versioned as 1.2.2-2.3) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer or cancel the NMU.

Regards.

diff -Nru alsa-lib-1.2.2/debian/changelog alsa-lib-1.2.2/debian/changelog
--- alsa-lib-1.2.2/debian/changelog 2020-06-10 06:26:40.0 +
+++ alsa-lib-1.2.2/debian/changelog 2020-06-15 04:16:18.0 +
@@ -1,3 +1,12 @@
+alsa-lib (1.2.2-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules:
+  - Added override_dh_auto_clean to allow the package build twice.
+(Closes: #962849)
+
+ -- Francisco Vilmar Cardoso Ruviaro   Mon, 15 
Jun 2020 04:16:18 +
+
 alsa-lib (1.2.2-2.2) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru alsa-lib-1.2.2/debian/rules alsa-lib-1.2.2/debian/rules
--- alsa-lib-1.2.2/debian/rules 2020-02-29 15:51:16.0 +
+++ alsa-lib-1.2.2/debian/rules 2020-06-15 00:23:05.0 +
@@ -38,3 +38,17 @@

 override_dh_makeshlibs:
dh_makeshlibs -- -c4
+
+override_dh_auto_clean:
+   rm -rf doc/doxygen
+   rm -f src/control/ctl_symbols_list.c \
+  src/control/libcontrol.la \
+  src/hwdep/libhwdep.la \
+  src/mixer/libmixer.la \
+  src/pcm/libpcm.la \
+  src/pcm/pcm_symbols_list.c \
+  src/rawmidi/librawmidi.la \
+  src/seq/libseq.la \
+  src/timer/libtimer.la \
+  src/ucm/libucm.la
+   dh_auto_clean

-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00

Bug#962909: 'Error: map definition does not specify mapping data type' with anonymous sets

[Gian Piero Carrubba]

Package: nftables
Version: 0.9.5-1
Severity: normal
Tags: upstream

Dear Maintainer,

since when v0.9.5 has entered sid, I've been experiencing:

---
$ sudo nft -f /etc/nftables.conf
/etc/nftables.conf:45:22-9: Error: map definition does not specify mapping data 
type
iifname vmap {

$ tail -n+45 /etc/nftables.conf | head -n4
iifname vmap {
wlp2s0: jump in_wlan,
enp0s31f6: jump in_eth,
}
---

It should have been fixed in 
http://git.netfilter.org/nftables/commit/?id=54eb1e16cc4787906fe8206858f0ea0bfb9c1209

Thanks,
Gian Piero.

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages nftables depends on:
ii  dpkg  1.19.7
ii  libc6 2.30-8
ii  libnftables1  0.9.5-1
ii  libreadline8  8.0-4

nftables recommends no packages.

Versions of packages nftables suggests:
pn  firewalld  

-- Configuration Files:
/etc/nftables.conf changed [not included]

-- no debconf information

Bug#938423: rust-python27-sys: Python2 removal in sid/bullseye

[Sylvestre Ledru]

Le 15/06/2020 à 22:17, Moritz Mühlenhoff a écrit :

On Fri, Aug 30, 2019 at 07:51:26AM +, Matthias Klose wrote:

Package: src:rust-python27-sys
Version: 0.2.1-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.


Hi Sylvestre,
there are no remaining rdeps of rust-python27-sys in unstable, let's remove?


Yeah, many thanks :)
S

Bug#962908: RM: pymvpa2 -- RoQA; Depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pymvpa2. It depends on Python 2 and the maintainer/upstream
(CCed) agreed to remove it until it's ported at a later point.

Cheers,
Moritz

Bug#962904: libwww-perl breaks libapache2-mod-perl2 autopkgtest: Failed 6/6 subtests

[Niko Tyni]

Control: tag -1 patch
Control: forwarded -1 https://github.com/libwww-perl/libwww-perl/pull/342

On Mon, Jun 15, 2020 at 10:40:48PM +0300, Niko Tyni wrote:
 
> The change in libwww-perl had a side effect of making it
> look at max_redirect only when the Location header is set.

> For the sake of robustness I suppose libwww-perl should be fixed, so
> reassigning.

Here's a fix that I've proposed upstream.
-- 
Niko
>From 3460bfbf463d4c7eb33e956d4710dedfaf0c27d0 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Mon, 15 Jun 2020 23:13:53 +0300
Subject: [PATCH] Fix a looping regression for 303 responses without a Location
 header

The change in 6.45 had a side effect of making it look at max_redirect
only when the Location header is set.

The libapache2-mod-perl2 test suite implements a test server that answers
with HTTP code 303 without including such a header.

RFC 7231 is not very clear on whether Location is required, although
the response doesn't make much sense without it.

Some googling reveals this is not a new question.

  https://stackoverflow.com/questions/16194988/for-which-3xx-http-codes-is-the-location-header-mandatory

For the sake of robustness I suppose libwww-perl needs to be fixed.

Bug-Debian: https://bugs.debian.org/962904
---
 lib/LWP/UserAgent.pm |  8 +---
 t/local/http.t   | 10 +-
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/lib/LWP/UserAgent.pm b/lib/LWP/UserAgent.pm
index 047495fe..4cc1812a 100644
--- a/lib/LWP/UserAgent.pm
+++ b/lib/LWP/UserAgent.pm
@@ -300,10 +300,12 @@ sub request {
 my $response = $self->simple_request($request, $arg, $size);
 $response->previous($previous) if $previous;
 
-if ($response->header('Location') && $response->redirects >= $self->{max_redirect}) {
-$response->header("Client-Warning" =>
+if ($response->redirects >= $self->{max_redirect}) {
+if ($response->header('Location')) {
+$response->header("Client-Warning" =>
 "Redirect loop detected (max_redirect = $self->{max_redirect})"
-);
+);
+}
 return $response;
 }
 
diff --git a/t/local/http.t b/t/local/http.t
index 260f1ec3..0700d8e2 100644
--- a/t/local/http.t
+++ b/t/local/http.t
@@ -63,7 +63,7 @@ sub _test {
 return plan skip_all => 'We could not talk to our daemon' unless $DAEMON;
 return plan skip_all => 'No base URI' unless $base;
 
-plan tests => 125;
+plan tests => 127;
 
 my $ua = LWP::UserAgent->new;
 $ua->agent("Mozilla/0.01 " . $ua->agent);
@@ -221,6 +221,13 @@ sub _test {
 is($res->redirects, 0, 'redirect loop: zero redirects');
 $ua->max_redirect(5);
 is($ua->max_redirect(), 5, 'redirect loop: max redirects set back to 5');
+
+# Test that redirects without a Location header work and don't loop
+$req->uri(url("/redirect4", $base));
+$ua->max_redirect(5);
+is($ua->max_redirect(), 5, 'redirect loop: max redirect 5');
+$res = $ua->request($req);
+isa_ok($res, 'HTTP::Response', 'redirect loop: good response object');
 }
 { # basic auth
 my $req = HTTP::Request->new(GET => url("/basic", $base));
@@ -622,6 +629,7 @@ sub daemonize {
 };
 $router{get_redirect2} = sub { shift->send_redirect("/redirect3/") };
 $router{get_redirect3} = sub { shift->send_redirect("/redirect2/") };
+$router{get_redirect4} = sub { my $r = HTTP::Response->new(303); shift->send_response($r) };
 $router{post_echo} = sub {
 my($c,$r) = @_;
 $c->send_basic_header;
-- 
2.26.1

Bug#937485: pymvpa2: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Sat, Jun 13, 2020 at 01:24:23PM -0400, Yaroslav Halchenko wrote:
> As the upstream and Debian maintainer for it, I am ok with it. It could be 
> easily made to build for python 3 but tests would show that it is not 
> entirely kosher. I better reupload it when it i an sure it is functioning 
> correctly again

Ack, I've just filed a removal bug.

Cheers,
Moritz

Bug#962907: RM: qmail-tools -- RoQA; Obsolete, depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove qmail-tools, qmail was recently removed from the archive, so this
can go as well. Plus, it depends on Python 2.

Cheers,
Moritz

Bug#938423: rust-python27-sys: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:51:26AM +, Matthias Klose wrote:
> Package: src:rust-python27-sys
> Version: 0.2.1-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

Hi Sylvestre,
there are no remaining rdeps of rust-python27-sys in unstable, let's remove?

Cheers,
Moritz

Bug#962645: qbittorrent-nox: Qbittorrent-nox is barely usable after the upgrade to 4.2.4-1+b1

[Adrian Bunk]

On Mon, Jun 15, 2020 at 07:43:18PM +0300, jim_p wrote:
> Package: qbittorrent-nox
> Version: 4.2.4-1+b1
> Followup-For: Bug #962645
> 
> You are right! I have set qbittorrent (gui and -nox) to delete the torrents
> from its list when they are done on the amd64 system.
> I disabled it and it does not crash.

Thanks for confirming.

> If it is fixed on 4.2.5 from upstream, when can we expect an update on the
> debian package?

I've uploaded a fixed package to DELAYED/2, this will be in unstable
in 2 days unless the maintainer objects or makes a maintainer upload.

> Also, if it is not related to tha boost 1.71 update, why didn't it occur on 
> the
> previous version, before the +b1 update?

It seems to be a race condition between one part of the code iterating 
through a list where another part of the code is removing an element.

For such race conditions it is not uncommon that random changes make
the difference whether it breaks or happens to work by chance.

cu
Adrian

Bug#936465: Remove python-ecryptfs?

[Moritz Mühlenhoff]

On Thu, May 14, 2020 at 04:56:01PM -0400, Scott Talbert wrote:
> Does it make sense to just remove the python-ecrpyptfs bindings?  They don't
> seem to have any reverse dependencies and popcon is very low.

Patch attached.

Cheers,
Moritz
diff -Naur ecryptfs-utils-111.orig/debian/control ecryptfs-utils-111/debian/control
--- ecryptfs-utils-111.orig/debian/control	2016-12-07 16:07:48.0 +0100
+++ ecryptfs-utils-111/debian/control	2020-06-15 22:11:52.217938876 +0200
@@ -4,10 +4,9 @@
 Maintainer: Laszlo Boszormenyi (GCS) 
 Uploaders: Filesystems Group 
 Build-Depends:
- debhelper (>= 10), dh-autoreconf, dh-python, distro-info, intltool,
+ debhelper (>= 10), dh-autoreconf, distro-info, intltool,
  libglib2.0-dev, libgpg-error-dev, libgpgme-dev, libkeyutils-dev,
- libnss3-dev, libpam0g-dev, pkg-config, python-dev,
- swig, libtspi-dev
+ libnss3-dev, libpam0g-dev, pkg-config, swig, libtspi-dev
 Standards-Version: 3.9.8
 Homepage: https://launchpad.net/ecryptfs
 
@@ -71,13 +70,3 @@
  filesystem for Linux.
  .
  This package contains the development files.
-
-Package: python-ecryptfs
-Section: python
-Architecture: linux-any
-Depends: ${misc:Depends}, ${shlibs:Depends}, ${python:Depends}
-Description: ecryptfs cryptographic filesystem (python)
- eCryptfs is a POSIX-compliant enterprise-class stacked cryptographic
- filesystem for Linux.
- .
- This package contains the python module.
diff -Naur ecryptfs-utils-111.orig/debian/python-ecryptfs.install ecryptfs-utils-111/debian/python-ecryptfs.install
--- ecryptfs-utils-111.orig/debian/python-ecryptfs.install	2013-02-09 08:06:09.0 +0100
+++ ecryptfs-utils-111/debian/python-ecryptfs.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/python*
diff -Naur ecryptfs-utils-111.orig/debian/python-ecryptfs.lintian-overrides ecryptfs-utils-111/debian/python-ecryptfs.lintian-overrides
--- ecryptfs-utils-111.orig/debian/python-ecryptfs.lintian-overrides	2016-08-18 05:49:05.0 +0200
+++ ecryptfs-utils-111/debian/python-ecryptfs.lintian-overrides	1970-01-01 01:00:00.0 +0100
@@ -1,4 +0,0 @@
-# false positives
-python-ecryptfs: package-has-unnecessary-activation-of-ldconfig-trigger
-python-ecryptfs: postinst-has-useless-call-to-ldconfig
-python-ecryptfs: postrm-has-useless-call-to-ldconfig
diff -Naur ecryptfs-utils-111.orig/debian/rules ecryptfs-utils-111/debian/rules
--- ecryptfs-utils-111.orig/debian/rules	2017-03-18 13:32:08.0 +0100
+++ ecryptfs-utils-111/debian/rules	2020-06-15 22:11:25.025696576 +0200
@@ -12,7 +12,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
-	dh ${@} --with autoreconf,python2
+	dh ${@} --with autoreconf
 
 override_dh_autoreconf:
 	dh_autoreconf ./autogen.sh
@@ -21,6 +21,7 @@
 	dh_auto_configure -- \
 		--enable-gpg --enable-pam --enable-static --enable-tspi \
 		--disable-gui --disable-openssl --disable-pkcs11-helper \
+		--disable-pywrap \
 		CFLAGS="$(CFLAGS)"
 
 override_dh_auto_install:
@@ -32,13 +33,8 @@
 	install -D -m 0644 debian/local/ecryptfs-utils.kmod debian/ecryptfs-utils/lib/modules-load.d/ecryptfs.conf
 
 	# Removing useless files
-	find debian/tmp -name "*.pyc" | xargs rm -f
-
 	rm -f debian/tmp/usr/lib/*/*.la
 
-	rm -f debian/tmp/usr/lib/python*/dist-packages/ecryptfs-utils/*.la
-	rm -f debian/tmp/usr/lib/python*/dist-packages/ecryptfs-utils/*.a
-
 override_dh_builddeb:
 	dh_builddeb -- -Zxz
 
@@ -50,14 +46,6 @@
 override_dh_install:
 	dh_install --fail-missing
 
-override_dh_python2:
-	dh_python2 --no-guessing-versions
-
-	# Adding missing symlinks
-	cd debian/python-ecryptfs/usr/lib/python*/dist-packages/ecryptfs-utils && \
-	ln -s _libecryptfs.${DEB_HOST_MULTIARCH}.so _libecryptfs.so.0.0 && \
-	ln -s _libecryptfs.${DEB_HOST_MULTIARCH}.so _libecryptfs.so.0.0.0
-
 override_dh_strip:
 	dh_strip --dbg-package=ecryptfs-utils-dbg
 

Bug#962141: docker.io: CVE-2020-13401

[Moritz Muehlenhoff]

On Sun, Jun 14, 2020 at 11:23:41PM +0200, Felix Geyer wrote:
> Hi security team / maintainers,
> 
> On Wed, 03 Jun 2020 20:58:53 +0200 Salvatore Bonaccorso  
> wrote:
> > Source: docker.io
> > Version: 19.03.7+dfsg1-3
> > Severity: important
> > Tags: security upstream
> > 
> > Hi,
> > 
> > The following vulnerability was published for docker.io.
> > 
> > CVE-2020-13401[0]:
> > | An issue was discovered in Docker Engine before 19.03.11. An attacker
> > | in a container, with the CAP_NET_RAW capability, can craft IPv6 router
> > | advertisements, and consequently spoof external IPv6 hosts, obtain
> > | sensitive information, or cause a denial of service.
> 
> I've prepared an update for buster-security (debdiff attached).
> With the update accept_ra is correctly set to 0 for bridges Docker creates.

Looks fine, thanks! Please upload to security-master.

Cheers,
Moritz

Bug#912531: stretch-pu: package exiv2/0.25-3.1+deb9u2

[Roberto C . Sánchez]

On Mon, Jun 15, 2020 at 08:28:14PM +0100, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo + confirmed
> 
> On Thu, 2018-11-01 at 21:07 -0400, Roberto C.Sánchez wrote:
> > On Thu, Nov 01, 2018 at 06:50:53PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + moreinfo
> > > 
> > > On Wed, 2018-10-31 at 23:25 -0400, Roberto C. Sanchez wrote:
> > > > I have prepared an update for exiv2 in jessie (0.24-4.1+deb8u2)
> > > > related to CVE-2018-16336 and also including a minor fix to the
> > > > previous patch for CVE-2018-10958 and CVE-2018-10999.
> > > 
> > > The Security Tracker indicates that CVE-2018-16336 is as-yet
> > > unfixed in unstable; is that correct?
> > > 
> > Hi Adam,
> > 
> > That is correct.  I completely overlooked it.  I will check with the
> > maintainers about their plans for unstable.
> > 
> 
> It looks like that eventually happened, early this year(!).
> 
> If this is still something that you're interested in fixing for
> stretch, please go ahead.
> 
The work has already been done, so I will go ahead with an upload
shortly.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Bug#962895: bugs.debian.org: curl https://api.push.apple.com reports problem: unable to get local issuer certificate

[Martin Drlik]

Package: bugs.debian.org
Severity: normal

Dear Maintainer,

"curl https://api.push.apple.com; exited with error
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

Note that certificate is valid.

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

Kernel: Linux 4.19.76-linuxkit (SMP w/2 CPU cores)
Kernel taint flags: TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#959829: ITP: google-api-client-java -- Flexible, efficient, and powerful Java client library for accessing any HTTP-based API on the web

[Andreas Tille]

Control: tags -1  ITP: google-api-client-java -- Flexible, efficient, and 
powerful Java client library for accessing any HTTP-based API on the web
Control: owner -1 ti...@debian.org

I've commited some rough packaging to

   https://salsa.debian.org/java-team/google-api-client-java

The packaging is done in the Debian Java team.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#954711: sight: diff for NMU version 19.0.0-6.1

[Adrian Bunk]

On Mon, Jun 15, 2020 at 09:36:15PM +0200, Andreas Tille wrote:
> Hi Adrian,

Hi Andreas,

> thanks a lot for your effort.  I've injected the diff into Git.

thanks, I've rescheduled it for immediate upload.

> Flavien, it would be great if you could integrate this upstream
> and issue a new release.

The next upstream version no longer uses this Boost library,
the patch can simply be dropped whenever the new upstream is available.

> Kind regards
> 
>Andreas.

cu
Adrian

Bug#962234: stretch-pu: package perl/5.24.1-3+deb9u7

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2020-06-04 at 22:02 +0100, Dominic Hargreaves wrote:
> Upstream released fixes for three regexp-related security issues
> on Monday:
> 
> https://metacpan.org/pod/release/XSAWYERX/perl-5.28.3/pod/perldelta.pod
> 
> The Debian security team would like these as no-dsa, so we would like
> to provide them in a point release. The patches have been trivially
> backported from 5.28. See #962005.
> 

Please go ahead.

Regards,

Adam

Bug#893548: stretch-pu: package python-icalendar/3.8-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2018-03-19 at 22:17 +0200, Adrian Bunk wrote:
> Fix the python3-icalendar dependencies:
> Depends: {+python3-pkg-resources,+} python3-tz, {+python3:any (>=
> 3.3.2-2~),+} python3-dateutil

With apologies for the crazy delay, please go ahead if this is still of
interest.

Regards,

Adam

Bug#958953: stretch-pu: package cups/2.2.1-8+deb9u6

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2020-04-27 at 09:03 +0200, Didier 'OdyX' Raboud wrote:
> CVE-2020-3898 and CVE-2019-8842 got fixed in unstable and pending for
> stable (#958814), after coordinated disclosure.
> 
> I'd like to fix these in an oldstable upload too:
> 
> cups (2.2.1-8+deb9u6) stretch; urgency=medium
> 
>   * Backport upstream security fixes:
> - CVE-2020-3898: heap-buffer-overflow in libcups’s
> ppdFindOption()
>   function in ppd-mark.c
> - CVE-2019-8842: The `ippReadIO` function may under-read an
> extension
>   field
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#962904: libwww-perl breaks libapache2-mod-perl2 autopkgtest: Failed 6/6 subtests

[Niko Tyni]

Control: reassign -1 libwww-perl 6.45-1

On Mon, Jun 15, 2020 at 08:31:45PM +0200, Paul Gevers wrote:

> Deep recursion on subroutine "LWP::UserAgent::request" at
> /usr/share/perl5/LWP/UserAgent.pm line 360.
> t/api/status.t ..
> Failed 6/6 subtests

Thanks for the report.

The change in libwww-perl had a side effect of making it
look at max_redirect only when the Location header is set.

  
https://metacpan.org/diff/file?target=OALDERS/libwww-perl-6.45/=OALDERS%2Flibwww-perl-6.44#lib/LWP/UserAgent.pm

The libapache2-mod-perl2 test suite implements a test server that answers
with HTTP code 303 without including such a header.

  GET /TestAPI__status?303= HTTP/1.1
  TE: deflate,gzip;q=0.3
  Connection: TE, close
  Host: localhost:8529
  User-Agent: libwww-perl/6.45
  
  HTTP/1.1 303 See Other
  Date: Mon, 15 Jun 2020 19:25:13 GMT
  Server: Apache/2.4.43 (Debian) world domination series/2.0 mod_perl/2.0.11 
Perl/v5.30.3
  Content-Length: 0
  Connection: close
  Content-Type: text/plain

RFC 7231 is not very clear on whether Location is required, although
the response doesn't make much sense without it.

  https://tools.ietf.org/html/rfc7231#section-6.4.4

Some googling reveals this is not a new question.

  
https://stackoverflow.com/questions/16194988/for-which-3xx-http-codes-is-the-location-header-mandatory

For the sake of robustness I suppose libwww-perl should be fixed, so
reassigning.
-- 
Niko Tyni   nt...@debian.org

Bug#918744: stretch-pu: package opensc/0.1.9-1~deb9u1

[Adam D. Barratt]

On Sat, 2019-02-09 at 14:13 +, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Tue, 2019-01-08 at 23:59 +0100, Hilko Bengen wrote:
> > I'd like to update opensc in stretch to 0.1.9-1~deb9u1 in order to
> > fix a regression that introduced with the last update, 0.1.6-
> > 3+deb9u1, in an attempt to fix security issues (see #910786 for
> > details).
> > 
> > I am aware that this is by no means a minimal change. I have tried
> > to
> > fix the backported patch that broke Yubikey NEO support for me, but
> > I
> > have not been able to restore functionality without reverting the
> > patch that fixed a CVE-worthy buffer overflow.
> > 
> > Because I own no other smartcard hardware, I cannot tell if the
> > other
> > patches that were introduced with 0.16.0-3+deb9u1 broke any other
> > hardware support.
> 
> Apologies for not getting back to you sooner.
> 
> Reading through the changelog between the two Debian versions, there
> are several changes that we normally would not consider, including a
> switch to Debhelper 11 and a change of supported OpenSSL version.
> 
> In order to try and assess the practical impact, would it be possible
> to have a binary debdiff between the current packages and your
> proposed
> upload.

That was over a year ago now, and there doesn't appear to have been any
further response.

We're now planning for the final point release for stretch before it
moves to LTS status, so it may be too late to handle this in practical
terms.

Regards,

Adam

Bug#954711: sight: diff for NMU version 19.0.0-6.1

[Andreas Tille]

Hi Adrian,

thanks a lot for your effort.  I've injected the diff into Git.

Flavien, it would be great if you could integrate this upstream
and issue a new release.

Kind regards

   Andreas.

On Mon, Jun 15, 2020 at 06:35:02PM +0300, Adrian Bunk wrote:
> Control: tags 954711 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for sight (versioned as 19.0.0-6.1) and uploaded
> it to DELAYED/2. Please feel free to tell me if I should cancel it.
> 
> cu
> Adrian

> diff -Nru sight-19.0.0/debian/changelog sight-19.0.0/debian/changelog
> --- sight-19.0.0/debian/changelog 2020-04-25 15:47:51.0 +0300
> +++ sight-19.0.0/debian/changelog 2020-06-15 18:20:23.0 +0300
> @@ -1,3 +1,11 @@
> +sight (19.0.0-6.1) unstable; urgency=high
> +
> +  * Non-maintainer upload.
> +  * Add patch from Giovanni Mascellani for FTBFS with Boost 1.71.
> +(Closes: #954711)
> +
> + -- Adrian Bunk   Mon, 15 Jun 2020 18:20:23 +0300
> +
>  sight (19.0.0-6) unstable; urgency=medium
>  
>[ Etienne Mollier ]
> diff -Nru sight-19.0.0/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch 
> sight-19.0.0/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch
> --- sight-19.0.0/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch  
> 1970-01-01 02:00:00.0 +0200
> +++ sight-19.0.0/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch  
> 2020-06-15 18:20:20.0 +0300
> @@ -0,0 +1,34 @@
> +From: Giovanni Mascellani 
> +Date: Sun, 22 Mar 2020 14:34:26 +0100
> +Subject: Fix FTBFS with Boost 1.71.
> +
> +Apparently CMake expects library names to be lowercase.
> +---
> + Bundles/ui/guiQml/CMakeLists.txt | 2 +-
> + Bundles/ui/guiQt/CMakeLists.txt  | 2 +-
> + 2 files changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/Bundles/ui/guiQml/CMakeLists.txt 
> b/Bundles/ui/guiQml/CMakeLists.txt
> +index 42c008e..7f9c228 100644
> +--- a/Bundles/ui/guiQml/CMakeLists.txt
>  b/Bundles/ui/guiQml/CMakeLists.txt
> +@@ -1,6 +1,6 @@
> + fwLoadProperties()
> + 
> +-find_package(Boost QUIET COMPONENTS Regex REQUIRED)
> ++find_package(Boost QUIET COMPONENTS regex REQUIRED)
> + find_package(Qt5 QUIET COMPONENTS Core Gui Quick Qml QuickControls2 
> REQUIRED)
> + 
> + 
> +diff --git a/Bundles/ui/guiQt/CMakeLists.txt 
> b/Bundles/ui/guiQt/CMakeLists.txt
> +index 3aff5d1..ff52b89 100644
> +--- a/Bundles/ui/guiQt/CMakeLists.txt
>  b/Bundles/ui/guiQt/CMakeLists.txt
> +@@ -1,6 +1,6 @@
> + fwLoadProperties()
> + 
> +-find_package(Boost QUIET COMPONENTS Regex REQUIRED)
> ++find_package(Boost QUIET COMPONENTS regex REQUIRED)
> + find_package(Qt5 QUIET COMPONENTS Core Gui Widgets REQUIRED)
> + 
> + 
> diff -Nru sight-19.0.0/debian/patches/series 
> sight-19.0.0/debian/patches/series
> --- sight-19.0.0/debian/patches/series2020-04-25 15:47:51.0 
> +0300
> +++ sight-19.0.0/debian/patches/series2020-06-15 18:20:20.0 
> +0300
> @@ -4,3 +4,4 @@
>  fix_launcher_library_path.patch
>  fix_dcmtk_scp_cfg.patch
>  revert_qVTK_widget.patch
> +0007-Fix-FTBFS-with-Boost-1.71.patch

> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#905385: stretch-pu: package weboob/1.2-1

[Adam D. Barratt]

On Wed, 2018-08-29 at 15:25 +0100, Jonathan Dowland wrote:
> Hello,
> 
> On Wed, Aug 15, 2018 at 04:43:41PM +0900, Marc Dequènes wrote:
> > Jonathan, if you still feel like giving a hand, then feel free to 
> > branch on the original repo with all the insult-removal patch
> > needed, and please add the warning message as well.
> 
> I've added the additional patch and disclaimer on top of this branch
> in my fork, which is branched from the stretch version of the
> package, and the changelog is set up ready for stretch-proposed-
> updates:
> 
> https://salsa.debian.org/jmtd/weboob/tree/905299-stretch
> 
> If you are happy with this, can I suggest you create a branch for
> stretch in the main repo and merge this in?
> 

That is the last response in the bug log, which is mostly why this
request has unfortunately sat in moreinfo limbo ever since. :-(

We're now planning for the final point release for stretch before it
moves to LTS support. Is this still something that you're (either of
you) interested in fixing for stretch?

Regards,

Adam

Bug#962633: dnscrypt-proxy: systemd socket file used even when listen_addresses specified in dnscrypt-proxy.toml

[Andrew Duty]

Sharing my current workaround in case it is helpful to anyone. I just
created a hook for apt that runs a script to touch a file and puts a line
in /usr/lib/systemd/system/dnscrypt-proxy.socket so it only runs when that
touched file is not present. Note that this does cause the status of the
socket unit to show as failed.

$ ls -l /usr/local/bin/dnscrypt-proxy-fix.sh
-rwxr--r-- 1 root root 490 Jun  9 18:27 /usr/local/bin/dnscrypt-proxy-fix.sh


$ cat /usr/local/bin/dnscrypt-proxy-fix.sh
#!/usr/bin/env bash

set -o errexit
set -o pipefail
set -o nounset

sockfile='/usr/lib/systemd/system/dnscrypt-proxy.socket'
line='ConditionPathExists=!\/etc\/dnscrypt-proxy\/no_systemd_socket'

[[ ! -f "$sockfile" ]] && exit 0

/usr/bin/touch /etc/dnscrypt-proxy/no_systemd_socket

if ! /usr/bin/grep --quiet "$line" "$sockfile" ; then
  /usr/bin/sed --in-place "/^\[Unit\]$/a $line" "$sockfile"
  /usr/bin/systemctl daemon-reload
  /usr/bin/systemctl restart dnscrypt-proxy.socket
fi


$ cat /etc/apt/apt.conf.d/100dnscrypt-proxy-patch
DPkg::Post-Invoke {"/usr/local/bin/dnscrypt-proxy-fix.sh";};

Bug#917880: stretch-pu: package kamailio/4.4.4-2+deb9u3

[Adam D. Barratt]

On Tue, 2019-08-20 at 23:09 +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Mon, 2018-12-31 at 11:22 +0100, Victor Seva wrote:
> > version in stable can't be used with TLS enabled due to #902452
> > with
> > severity grave. If user enables TLS kamailio fails to start.
> > 
> 
> Apologies for the delay in getting back to you.
> 
> Is the result of the patch that kamaillo assumes that Kerberos is
> always OK with newer OpenSSL versions, or the reverse?
> 

Ping? We're starting to plan for the final point release for stretch.

Regards,

Adam

Bug#933636: CVE-2019-14934

[Adam D. Barratt]

On Mon, 2020-02-10 at 15:59 -0800, Francois Marier wrote:
> On 2020-02-07 at 10:14:24, Salvatore Bonaccorso wrote:
> > > It looks OK to me. Tagging moreinfo until there's a final diff.
> > 
> > Friendly ping, any news? (It's too late now for the upcoming point
> > release though).
> 
> It's still on my list, but not a very high priority. Definitely won't
> happen
> until at least after the Ubuntu 20.04 Debian merge deadline.
> 

For the record, we're now planning for the final stretch point release
before it moves to LTS.

Regards,

Adam

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Adam D. Barratt]

On Mon, 2020-02-10 at 08:56 +0100, Christoph Biedl wrote:
> Salvatore Bonaccorso wrote...
> 
> > Is this still something we should try to get into stretch (now to
> > late
> > for 9.12 but might be possible for 9.13)?
> 
> For me, I would like to, so I'll re-visit the scenary and will try to
> eventually get this done.

For the record, we're now planning for 9.13, which will be the final
point release for stretch before it moves to LTS.

Regards,

Adam

Bug#962819: RFP: foliate -- simple and modern GTK eBook reader

[Jonathan Carter]

Hey Lev

On 2020/06/14 18:17, Lev Lamberov wrote:
> * Package name: foliate

An ITP for this package already exists:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945270

Some initial work:
https://salsa.debian.org/debian/foliate

I've been meaning to get to it, but have been really busy recently, if
you'd like to finish it up please go ahead.

Here's some feedback from ftpmaster after I initially uploaded using the
version in the git repository above, which would have to be fixed for
the next upload (at least minor stuff):

"""
I do not believe that epub.js is in its preferred form of
modification.  Looking online, the presence of `var _createClass`
lines means that the file has been produced from other source files
by the JavaScript transpiler babel.  Maybe epub.js needs to be a
separate source package.  Please upload a version containing all the
source code or explain in debian/copyright why epub.js is in
fact in its preferred form of modification.

Other comments:

Looks like a bug to install to
/usr/bin/com.github.johnfactotum.Foliate rather than
/usr/bin/foliate ?

data\com.github.johnfactotum.Foliate.appdata.xml.in and
src/assets/lookup.html and other files say that project is GPL-3+
not just GPL-3

I am going to reject the package.  At the very least, if epub.js is in
the preferred form of modification, this will need to be explained in
debian/copyright, since it appears not to be the case.
"""

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#912531: stretch-pu: package exiv2/0.25-3.1+deb9u2

[Adam D. Barratt]

Control: tags -1 -moreinfo + confirmed

On Thu, 2018-11-01 at 21:07 -0400, Roberto C.Sánchez wrote:
> On Thu, Nov 01, 2018 at 06:50:53PM +, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Wed, 2018-10-31 at 23:25 -0400, Roberto C. Sanchez wrote:
> > > I have prepared an update for exiv2 in jessie (0.24-4.1+deb8u2)
> > > related to CVE-2018-16336 and also including a minor fix to the
> > > previous patch for CVE-2018-10958 and CVE-2018-10999.
> > 
> > The Security Tracker indicates that CVE-2018-16336 is as-yet
> > unfixed in unstable; is that correct?
> > 
> Hi Adam,
> 
> That is correct.  I completely overlooked it.  I will check with the
> maintainers about their plans for unstable.
> 

It looks like that eventually happened, early this year(!).

If this is still something that you're interested in fixing for
stretch, please go ahead.

(As a side note, it looks like at least one of these issues is also
unfixed in buster now.)

Regards,

Adam

Bug#962897: mutt: CVE-2020-14093

[Antonio Radici]

On Mon, Jun 15, 2020 at 06:38:44PM +0200, Salvatore Bonaccorso wrote:
> Source: mutt
> Version: 1.14.0-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> The following vulnerability was published for mutt.
> 
> CVE-2020-14093[0]:
> | Mutt before 1.14.3 allows an IMAP fcc/postpone man-in-the-middle
> | attack via a PREAUTH response.
> 
> 
> 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-14093
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14093
> [1] 
> https://github.com/muttmua/mutt/commit/3e88866dc60b5fa6aaba6fd7c1710c12c1c3cd01
> 
> Please adjust the affected versions in the BTS as needed.

The updated package will be uploaded between today and tomorrow

Bug#962906: isc-dhcp-client: typographic error in rfc3442-classless-routes examples

[Chad Dougherty]

Package: isc-dhcp-client
Version: 4.4.1-2
Severity: minor

Dear Maintainer,

The file:
/etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes

contains the following leading comments:
# set classless routes based on the format specified in RFC3442
# e.g.:
#   new_rfc3442_classless_static_routes='24 192 168 10 192 168 1 1 8 10 10 17 
66 41'
# specifies the routes:
#   192.168.10.0/24 via 192.168.1.1
#   10.0.0.0/8 via 10.10.17.66.41

The last IP address on the last line has a typographic error and should
instead read:
#   10.0.0.0/8 via 10.17.66.41

(The example assignment to new_rfc3442_classless_static_routes is actually
correct, it's only the commentary that is wrong.)

I believe this change should be applied to the following files in the
source package for isc-dhcp:
rfc3442-classless-routes.linux
rfc3442-classless-routes.linux


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

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

Versions of packages isc-dhcp-client depends on:
ii  debianutils4.8.6.1
ii  iproute2   4.20.0-2
ii  libc6  2.28-10
ii  libdns-export1104  1:9.11.5.P4+dfsg-5.1+deb10u1
ii  libisc-export1100  1:9.11.5.P4+dfsg-5.1+deb10u1

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.4.1-2

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd 
pn  isc-dhcp-client-ddns  
pn  resolvconf

-- no debconf information

Bug#893644: stretch-pu: package leap-archive-keyring/2016.03.08

[Adam D. Barratt]

On Tue, 2018-04-03 at 13:00 -0400, micah anderson wrote:
> "Adam D. Barratt"  writes:
[...]
> An upload to stretch at least needs a new changelog stanza with a
> > different version number - most likely 2016.03.08+deb9u1, but
> > possibly
> > 2017.11.24~deb9u1 if you wish to argue that all of the changes
> > since
> > the current version in stretch are appropriate for a stable
> > update.)
> 
> I went with 2017.11.24~deb9u1 because indeed, the changes since the
> current version in stretch are appropriate for a stable update,
> namely:
> 
> 1. Providing keys in a second location, to aid in the transition from
> jessie->stretch methods for how sources.list [signed-by=] method
> changed
> to allow for both paths and fingerprints
> 
> 2. fix priority to be in-line with debian policy
> 
> 3. add a dependency on gnupg
> 
> 4. update the expirations on the keys themselves

Apologies for letting this sit in "moreinfo" for quite so long without
re-pinging. Is this still something that's of interest? I can see that
there's what I assume is an equivalent package in stretch-backports.

Regards,

Adam

Bug#887736: stretch-pu: package openvswitch/2.6.2~pre+git20161223-3

[Adam D. Barratt]

On Wed, 2019-08-21 at 15:28 -0400, Felipe Sateler wrote:
> 
> 
> On Tue, Aug 20, 2019 at 6:23 PM Adam D. Barratt <
> a...@adam-barratt.org.uk> wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Fri, 2018-01-19 at 15:21 +0100, Thomas Goirand wrote:
> > > I started maintaining OpenVSwitch long after the Stretch release,
> > and
> > > discovered #858418, which is very annoying for OpenVSwitch users.
> > > 
> > > tl;dr: #858418 prevent anyone that has a valid
> > > /etc/network/interfaces
> > > with OpenVSwitch directive from having a working network at boot.
> > The
> > > init script uses a non-documented, not-to-be-used systemd
> > internal,
> > > which is miserably failing.
> > > 
> > > After a long discussion with the bug reporter (which can be read
> > on
> > > the BTS), I came to the conclusion that he's right, and that the
> > most
> > > reasonable and safe way to fix the current situation is to apply
> > the
> > > patch he suggested (and which resulting debdiff I attached to
> > this
> > > bug).
> > 
> > As I understand things, that fix swaps use of one systemd internal
> > for another, which doesn't seem like a great plan.
> > 
> > When this was discussed (some time ago) on IRC, one of the systemd
> > maintainers essentially said "don't do that". With apologies for
> > the delay in doing so, I've CCed the maintainer list to see if we
> > can find a mutually acceptable solution.
> 
> Both `service` and `invoke-rc.d` wrappers have a few safeguards
> against running in unwanted contexts. Have you tried using one of
> them?

Ping? We're heading towards the final point release for stretch before
it moves to LTS, so need to decide what to do with this request.

Regards,

Adam

Bug#929871: RM: simpleid/0.8.1-15

[Adam D. Barratt]

On Fri, 2019-08-16 at 21:01 +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sun, 2019-06-02 at 17:26 +0900, Hideki Yamane wrote:
> >  As Bug#929575, simpleid 0.8.1-15 doesn't work with PHP7.x that is
> > shipped  with Debian9 "stretch" and Debian10 "buster", so I propose
> > we'll remove it.
> >  And, for testing package was removed (#929832) but stable package
> > still  remains.
> 
> This bug was tagged "stretch", but mentions buster and stable. Where
> exactly are you trying to request removal from?
> 
> (If the answer is both stretch and buster, note that that is two
> removals and thus requires two removal request bugs.)

To answer my own question here, the package isn't in buster.

dak says:

# Broken Depends:
dynalogin: simpleid-store-dynalogin
simpleid-ldap: simpleid-ldap

Should those packages also be removed?

Regards,

Adam

Bug#962264: ruby2.3 2.3.3-1+deb9u8 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 962264 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: ruby2.3
Version: 2.3.3-1+deb9u8

Explanation: fix unsafe object creation vulnerability [CVE-2020-10663]

Bug#961937: ssvnc 1.0.29-3+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 961937 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: ssvnc
Version: 1.0.29-3+deb9u1

Explanation: fix out-of-bounds write [CVE-2018-20020], infinite loop 
[CVE-2018-20021], improper initialisation [CVE-2018-20022], potential 
denial-of-service [CVE-2018-20024]

Bug#962256: ruby-json 2.0.1+dfsg-3+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 962256 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: ruby-json
Version: 2.0.1+dfsg-3+deb9u1

Explanation: fix unsafe object creation vulnerability [CVE-2020-10663]

Bug#961922: php-horde-gollem 3.0.10-1+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 961922 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: php-horde-gollem
Version: 3.0.10-1+deb9u1

Explanation: fix cross-site scripting vulnerability in breadcrumb output 
[CVE-2020-8034]

Bug#961945: php-horde 5.2.13+debian0-1+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 961945 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: php-horde
Version: 5.2.13+debian0-1+deb9u2

Explanation: fix cross-site scripting vulnerability [CVE-2020-8035]

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[Salvatore Bonaccorso]

Hi Bruce,

On Mon, Jun 15, 2020 at 10:50:35AM -0400, J. Bruce Fields wrote:
> On Sat, Jun 13, 2020 at 11:45:27AM -0700, Elliott Mitchell wrote:
> > I disagree with this assessment.  All of the reporters have been using
> > ZFS, but this could indicate an absence of testers using other
> > filesystems.  We need someone with a NFS server which has a 4.15+ kernel
> > and uses a different filesystem which supports ACLs.
> 
> Honestly I don't think I currently have a regression test for this so
> it's possible I could have missed something upstream.  I haven't seen
> any reports, though
> 
> ZFS's ACL implementation is very different from any in-tree
> filesystem's, and given limited time, a filesystem with no prospect of
> going upstream isn't going to get much attention, so, yes, I'd need to
> see a reproducer on xfs or ext4 or something.

I think the following is reproducible on a ext4 exported share (with
underlying filesystem mounted with noacl to mimic the suspect from the
reporter). I tested the same with an older kernel from Debian stretch
(running 4.9.210-1+deb9u1) but this does not show the same behaviour.

The current test system is running 5.6.14-2 Debian kernel (so 5.6.14).

1/ Create an ext4 filesystem:

# mkfs.ext4 /dev/vdb1

2/ Mount the filesystem with noacl (to mimic the situation):

/dev/vdb1 /srv/data ext4 defaults,noacl 0 0

root@nfs-test:~# mount | grep vdb1
/dev/vdb1 on /srv/data type ext4 (rw,relatime,noacl)

3/ Export with

/srv/data 192.168.122.1/24(rw,sync,no_subtree_check,no_root_squash)

4/ Reproduce the issue

root@nfs-test:~# mount -t nfs 192.168.122.150:/srv/data /mnt
root@nfs-test:~# mkdir /mnt/foo && ls -ld /mnt/foo && rmdir /mnt/foo
drwxrwxrwx 2 root root 4096 Jun 15 20:24 /mnt/foo
root@nfs-test:~# mount | grep data
/dev/vdb1 on /srv/data type ext4 (rw,relatime,noacl)
192.168.122.150:/srv/data on /mnt type nfs4 
(rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.150,local_lock=none,addr=192.168.122.150)
root@nfs-test:~# umount /mnt

Looking at a wireshark captured sniff, the situation was the same as in the
previous ZFS case, in the gettattr from the client and the server does indicate
support for the new mode_umask. Then later in the CREATE operation, the client
sets the mode_umask attribute, with mode part set to '0777' and umask to '022'.
The mode replied is then as well '0777'.

Notabene: if not mounting the filesystem with noacl, then there is no
observed behaviour change here.

Regards,
Salvatore

Bug#962905: RFP: libstrangle -- Frame rate limiter for Linux

[Axel R.]

Package: wnpp
Severity: wishlist

* Package name: libstrangle
  Version : 0.1.1
  Upstream Author : Björn Spindel 
* URL : https://gitlab.com/torkel104/libstrangle
* License : GPLv3
  Programming Lang: C++
  Description : Frame rate limiter for Linux

libstrangle is a frame rate limiter for Linux which caps the fps (frames per 
second) of a chosen game. It is pretty easy to use and solves some gaming 
problems. E.g. Titan Quest gets desync in multiplayer which results in huge 
lags if I don't limit the fps to 60. Also I found this very usefull in addition 
to freesync to limit the fps below the maximum refresh rate of my monitor.

Bug#766441: RFA: scala-mode-el -- Emacs major mode for editing scala source code

[Nicholas D Steeves]

Hi Sławomir,

Thank you for the updates!  I've elided the resolved issues in this
reply.

Sławomir Wójcik  writes:

> On 29.05.2020 05:22, Nicholas D Steeves wrote:
>> Sławomir Wójcik  writes:
>>> On 22.05.2020 05:14, Nicholas D Steeves wrote:
[snip]

>> Leave the changelog in UNRELEASED state for now.
> Ok

But then you committed ce7b824 knowing the package wasn't ready for
release...

[snip]
>
>> Copyright file issues:
>>* 2 files stanzas are missing
>
> which two? I've browsed all files and I'm not sure. Could you paste some 
> links to locations in the repo?
>

You can find these with:

ag copyright --ignore debian
ag © --ignore debian  # compose that symbol with 'compose_key-o c'
  # or just copy & paste
ag '\(c\)' --ignore debian

>>* 2 people are missing
>
> I've added Merlin Göttlinger as the author of 
> scala-mode-prettify-symbols.el file and Ana Beatriz Guerrero Lopez in 
> debian files dopyright section.
>

I appreciate you took the time for this.  That said, Ana Beatriz
Guerreroo Lopez doesn't need to be (most would say shouldn't be) in the
copyright file, because ~5 lines of small changes (plus two
dch-generated lines) doesn't meet the minimum standards for
copyrightability.  This becomes significant when there are many
contributors who have make small or trivial changes to debian/*, because
were a license change to be required sometime in the future, all
copyright holders would need to affirm the change.

> I could add Sam Halliday(original author of https://ensime.github.io/ , 
> more info below) who contributed some substantial part of scala-mode, 
> however he abandoned the project.
>
> What's the policy here? Should we include him in copyright? For example 
> in elpy package only the original author(Jorgen Schaefer 
> ) is listed in the copyright entry and the 
> person which took over the project(galaunay 
> ) is only listed as upstream contact and not 
> in the copyright section.
>

In Debian our obligation is to 1) accurately reflect upstream copyright
declarations 2) contact upstream when something is not clear, or when
there is a DFSG issue such as bundling software with incompatible
licenses in the same repo or orig.tarball.  In Elpy's case Launay is the
current maintainer, but he not asserting his copyright rights and/or has
attributed copyright of his work to Schaefer.

If you ran the commands suggested above you'll have seen that Sam
Halliday is still a copyright holder.  Knowing scala-mode's history,
this makes it seem like Heikki Vesalainen derived his work from
Halliday's.  As discussed previously I don't think it's fair or just to
cut people from history because they stopped maintaining a project, but
the absence of Halliday's copyright claim is an upstream issue.  Were I
to contact upstream, phrasing it as a request for clarification would be
less confrontational than something along the lines of "hey, you've
omitted someone's copyright", and I'd go with the less confrontational
approach.  By the way, you don't have to contact upstream if you don't
want to, because this issue doesn't strictly block Debian work.

>>* at least 1 license is missing
>
> I've added Scala EPFL license which I missed that is still used in 
> Makefile(which I believe is invoked by debhelper, although I'm not sure 
> it's needed for dh_elpa) but one question here:

License names should be one word (no spaces).

  
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification

> What would be the policy for files that Debian package doesn't use not 
> only in the debian binary package but even in the build process like for 
> example Cask file which would have separate license? In that case this 
> license should also be incorporated in the copyright file?
>

If it's in the orig.tarball and thus the source package it needs to be
documented; this is written in Policy.  If the license is not DFSG free
then the file[s] must be stripped from the orig.tarball, even if they're
not used during the build and even if they don't appear in a binary package.

>>* "updated license and author" is too vague, and isn't entirely
>>accurate (see above).  Also, why did the licenses and authors change?
>>Documenting these facts is part of writing a good changelog entry
>>;-)

This isn't present in ce7b824, please fix it.

>>* Standards-Version needs to be updated.  See Debian Policy and its
>>upgrading checklist.  Start at the version from the last upload and
>>work your way through from there. <- Please defer this until the
>>beginning of our next review cycle unless you run out of things to
>>do.

This is the second most important changelog item, and the most important
from a Policy perspective, so it should go on its own line.  It should
say something like this:

  * Declare Standards-Version 4.5.0
  or
  * Assert compliance with Policy 4.5.0.
  etc

If no changes are required add "(no changes required)" to 

Bug#962047: Bug#962318: libmojolicious-perl: build fails on IPv6-only buildds

[Niko Tyni]

On Fri, Jun 12, 2020 at 06:58:15PM +0300, Niko Tyni wrote:

> I have not had the tuits yet for looking at IO::Socket::IP properly.
> It seems to me that it could look at the address and pass AI_NUMERICHOST
> to getaddrinfo(3) if it looks like an IPv4 address. I guess matching
> against qr/^\d+\.\d+\.\d+\.\d+$/ would suffice.

Here's a first try at such a patch. Something like this might be
a better fix for #962047 in libio-socket-ip-perl than the test suite
change in 0.39-2.

I've only tested that libio-socket-ip-perl and libtest-tcp-perl build
and work with this.
-- 
Niko Tyni   nt...@debian.org
>From cedf885dda8bdb0e1af3a8ab5675a347a5d7c22f Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Mon, 15 Jun 2020 19:31:31 +0100
Subject: [PATCH] Call getaddrinfo(3) with AI_NUMERICHOST for IPv4 numeric
 addresses

AI_ADDRCONFIG can be a bad default for systems with a dual protocol
loopback device but just IPv6 connectivity. In such a case,
getaddrinfo(3) on 127.0.0.1 or 0.0.0.0 will fail with EAI_ADDRFAMILY
even though the loopback device is able to handle them.

Bug: https://rt.cpan.org/Ticket/Display.html?id=132760
Bug-Debian: https://bugs.debian.org/962047
Bug-Debian: https://bugs.debian.org/962318
---
 lib/IO/Socket/IP.pm | 34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/lib/IO/Socket/IP.pm b/lib/IO/Socket/IP.pm
index 4334a66..64f26f6 100755
--- a/lib/IO/Socket/IP.pm
+++ b/lib/IO/Socket/IP.pm
@@ -30,6 +30,7 @@ use Socket 1.97 qw(
 );
 my $AF_INET6 = eval { Socket::AF_INET6() }; # may not be defined
 my $AI_ADDRCONFIG = eval { Socket::AI_ADDRCONFIG() } || 0;
+my $AI_NUMERICHOST = eval { Socket::AI_NUMERICHOST() } || 0;
 use POSIX qw( dup2 );
 use Errno qw( EINVAL EINPROGRESS EISCONN ENOTCONN ETIMEDOUT EWOULDBLOCK EOPNOTSUPP );
 
@@ -409,6 +410,8 @@ sub _io_socket_ip__configure
my ( $arg ) = @_;
 
my %hints;
+   my $localflags;
+   my $peerflags;
my @localinfos;
my @peerinfos;
 
@@ -419,12 +422,23 @@ sub _io_socket_ip__configure
}
 
if( defined $arg->{GetAddrInfoFlags} ) {
-  $hints{flags} = $arg->{GetAddrInfoFlags};
+  $peerflags = $arg->{GetAddrInfoFlags};
+   }
+   elsif (defined $arg->{PeerHost}  and $arg->{PeerHost}  =~ /^\d+\.\d+\.\d+\.\d+$/) {
+  $peerflags = $AI_NUMERICHOST;
+   }
+   else {
+  $peerflags = $AI_ADDRCONFIG;
+   }
+
+   if( defined $arg->{GetAddrInfoFlags} ) {
+  $localflags = $arg->{GetAddrInfoFlags};
+   }
+   elsif (defined $arg->{LocalHost} and $arg->{LocalHost} =~ /^\d+\.\d+\.\d+\.\d+$/) {
+  $localflags = $AI_NUMERICHOST;
}
-   elsif (defined $arg->{PeerHost} and $arg->{PeerHost} =~ /^\d+\.\d+\.\d+\.\d+$/) {
-  $hints{flags} = $AI_NUMERICHOST;
else {
-  $hints{flags} = $AI_ADDRCONFIG;
+  $localflags = $AI_ADDRCONFIG;
}
 
if( defined( my $family = $arg->{Family} ) ) {
@@ -481,6 +495,7 @@ sub _io_socket_ip__configure
  my $fallback_port = $1;
 
   my %localhints = %hints;
+  $localhints{flags} = $localflags;
   $localhints{flags} |= AI_PASSIVE;
   ( my $err, @localinfos ) = getaddrinfo( $host, $service, \%localhints );
 
@@ -509,10 +524,13 @@ sub _io_socket_ip__configure
   defined $service and $service =~ s/\((\d+)\)$// and
  my $fallback_port = $1;
 
-  ( my $err, @peerinfos ) = getaddrinfo( $host, $service, \%hints );
+  my %peerhints = %hints;
+  $peerhints{flags} = $peerflags;
+
+  ( my $err, @peerinfos ) = getaddrinfo( $host, $service, \%peerhints );
 
   if( $err and defined $fallback_port ) {
- ( $err, @peerinfos ) = getaddrinfo( $host, $fallback_port, \%hints );
+ ( $err, @peerinfos ) = getaddrinfo( $host, $fallback_port, \%peerhints );
   }
 
   if( $err ) {
@@ -592,7 +610,9 @@ sub _io_socket_ip__configure
   # If there wasn't, use getaddrinfo()'s AI_ADDRCONFIG side-effect to guess a
   # suitable family first.
   else {
- ( my $err, @infos ) = getaddrinfo( "", "0", \%hints );
+ my %guesshints = %hints;
+ $guesshints{flags} = $AI_ADDRCONFIG;
+ ( my $err, @infos ) = getaddrinfo( "", "0", \%guesshints );
  if( $err ) {
 $@ = "$err";
 $! = EINVAL;
-- 
2.26.2

Bug#954823: hydrogen: Qt5 version available

[Jonas Smedegaard]

[ re-posting, bugreport cc'ed this time ]

Quoting Nicholas D Steeves (2020-05-30 22:34:10)
> Hi Jonas,
> 
> On Sat, May 30, 2020 at 03:57:44PM -0400, Nicholas D Steeves wrote:
> > Hi Jaromír,
> > 
> > On Fri, Apr 03, 2020 at 07:19:06AM +0200, Jaromír Mikeš wrote:
> > >Hi Alexandre,
> > >I am former maintainer of this package but not active any more.
> > >please contact Debian multimedia team to get help with this issue.
> > >https://wiki.debian.org/DebianMultimedia
> > >https://lists.debian.org/debian-multimedia/
> > >Or even join it if you want to work on it.
> > >https://wiki.debian.org/DebianMultimedia/Join
> > >hope this helps
> > >mira
> > 
> > Given that you haven't been active in Debian for a while, and given
> > this message I understood that your intent was to drop yourself from
> > Uploaders, so I went ahead and committed that change.
> > 
> > Please let me know if I was mistaken, and I'll revert that commit asap :-)
> > 
> 
> I've arrived at the stage of work where my options are to 1) convert
> to dh 2) learn about cdbs (specifically why it is overriding
> debhelper-compat 13 with compat 5).  I'd prefer to spend my time on
> #1.
> 
> Do you object to the move to dh?  Also, would you like to remain an
> Uploader or would you like me to remove your name from the list at
> this time?

Please go ahead, and please remove me as uploader (not because of that 
change - I am changing away from cdbs myself as well nowadays - but 
because I no longer have a special interest in that package)


- Jonas

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

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

signature.asc
Description: signature

Bug#962904: libwww-perl breaks libapache2-mod-perl2 autopkgtest: Failed 6/6 subtests

[Paul Gevers]

Source: libwww-perl, libapache2-mod-perl2
Control: found -1 libwww-perl/6.45-1
Control: found -1 libapache2-mod-perl2/2.0.11-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of libwww-perl the autopkgtest of
libapache2-mod-perl2 fails in testing when that autopkgtest is run with
the binary packages of libwww-perl from unstable. It passes when run
with only packages from testing. In tabular form:

   passfail
libwww-perlfrom testing6.45-1
libapache2-mod-perl2   from testing2.0.11-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of libwww-perl to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libwww-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/liba/libapache2-mod-perl2/5906385/log.gz

autopkgtest [11:09:07]: test mysmoke: [---
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl /tmp/tmp.qHXvGv5OR0/t/TEST
-httpd_conf '/tmp/tmp.qHXvGv5OR0/apache2.conf' -apxs '/usr/bin/apxs'
/usr/sbin/apache2  -d /tmp/tmp.qHXvGv5OR0/t -f
/tmp/tmp.qHXvGv5OR0/t/conf/httpd.conf -D APACHE2 -D APACHE2_4 -D
PERL_USEITHREADS
using Apache/2.4.43 (worker MPM)

waiting 300 seconds for server to start: .[Mon Jun 15 11:09:08.743774
2020] [core:trace3] [pid 15891:tid 139632765965568] core.c(3361):
Setting LogLevel for all modules to trace8
[Mon Jun 15 11:09:08.744018 2020] [env:warn] [pid 15891:tid
139632765965568] AH01506: PassEnv variable LD_LIBRARY_PATH was undefined
[Mon Jun 15 11:09:08.765522 2020] [perl:info] [pid 15891:tid
139632765965568] 6 Apache2:: modules loaded
[Mon Jun 15 11:09:08.765561 2020] [perl:info] [pid 15891:tid
139632765965568] 0 APR:: modules loaded
[Mon Jun 15 11:09:08.765601 2020] [perl:info] [pid 15891:tid
139632765965568] base server + 29 vhosts ready to run tests
..
waiting 300 seconds for server to start: ok (waited 1 secs)
server localhost:8529 started
server localhost:8530 listening (filter_out_apache)
server localhost:8531 listening (perlsections)
server localhost:8532 listening (inherit)
server localhost:8533 listening (TestDirective::perlcleanuphandler)
server localhost:8534 listening (TestVhost::log)
server localhost:8535 listening (TestVhost::config)
server localhost:8536 listening (TestModules::proxy)
server localhost:8537 listening (TestModperl::setupenv)
server localhost:8538 listening (TestModperl::perl_options)
server localhost:8539 listening (TestModperl::merge)
server localhost:8540 listening (TestModperl::perl_options2)
server localhost:8541 listening (TestUser::rewrite)
server localhost:8542 listening (TestProtocol::echo_timeout)
server localhost:8543 listening (TestProtocol::echo_bbs2)
server localhost:8544 listening (TestProtocol::echo_nonblock)
server localhost:8545 listening (TestProtocol::pseudo_http)
server localhost:8546 listening (TestProtocol::echo_bbs)
server localhost:8547 listening (TestProtocol::echo_filter)
server localhost:8548 listening (TestProtocol::echo_block)
server localhost:8549 listening (TestPreConnection::note)
server localhost:8550 listening (TestHooks::hookrun)
server localhost:8551 listening (TestHooks::trans)
server localhost:8552 listening (TestHooks::stacked_handlers2)
server localhost:8553 listening (TestHooks::init)
server localhost:8554 listening (TestHooks::startup)
server localhost:8555 listening (TestFilter::in_bbs_inject_header)
server localhost:8556 listening (TestFilter::both_str_con_add)
server localhost:8557 listening (TestFilter::in_str_msg)
server localhost:8558 listening (TestFilter::in_bbs_msg)
server localhost:8559 listening (TestDirective::perlmodule)
server localhost:8560 listening (TestDirective::perlrequire)
server localhost:8561 listening (TestDirective::perlloadmodule3)
server localhost:8562 listening (TestDirective::perlloadmodule5)
server localhost:8563 listening (TestDirective::perlloadmodule4)
server localhost:8564 listening (TestAPI::add_config)
server localhost:8565 listening (TestDirective::perlloadmodule6)
server localhost:8566 listening (TestHooks::push_handlers_anon)
t/apache/add_config.t ... ok
t/apache/cgihandler.t ... ok
t/apache/conftree.t . ok
t/apache/constants.t  ok
t/apache/content_length_header.t  ok
t/apache/daemon.t ... ok
t/apache/discard_rbody.t  ok
t/apache/post.t . ok
t/apache/read.t