Bug#946032: buster-pu: package gtk2-engines-murrine/0.98.2-2+deb10u1

[Mike Gabriel]

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

Hi,

+  * debian/control:
++ Downgrade from R to S (gtk2-engine-themes): murrine-themes. (Closes:
+  #838994).

The above issue resolves a long standing dependency relation between
gtk2-themes-murrine, murrine-themes and any other murrine-like theme not
bundled in murrine-themes.

One probably has to go over the discussion backlog of #838994 and #891493
for fully getting the scope of the underlying issue.

This issue was in fact discussed before the buster release but the
original maintainer of gtk2-engines-murrine refused to make the required
dependency downgrade change.

In unstable, the situation has now been settled, the recommendation here
is, to get the situation also solved in Debian buster.

Thanks,
Mike

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gtk2-engines-murrine-0.98.2/debian/changelog 
gtk2-engines-murrine-0.98.2/debian/changelog
--- gtk2-engines-murrine-0.98.2/debian/changelog2017-12-04 
20:54:03.0 +0100
+++ gtk2-engines-murrine-0.98.2/debian/changelog2019-12-03 
08:47:15.0 +0100
@@ -1,3 +1,11 @@
+gtk2-engines-murrine (0.98.2-2+deb10u1) buster; urgency=medium
+
+  * debian/control:
++ Downgrade from R to S (gtk2-engine-themes): murrine-themes. (Closes:
+  #838994).
+
+ -- Mike Gabriel   Tue, 03 Dec 2019 08:47:15 +0100
+
 gtk2-engines-murrine (0.98.2-2) unstable; urgency=medium
 
   [ Jeremy Bicha ]
diff -Nru gtk2-engines-murrine-0.98.2/debian/control 
gtk2-engines-murrine-0.98.2/debian/control
--- gtk2-engines-murrine-0.98.2/debian/control  2017-12-04 20:54:01.0 
+0100
+++ gtk2-engines-murrine-0.98.2/debian/control  2019-12-03 08:46:37.0 
+0100
@@ -12,7 +12,7 @@
 Package: gtk2-engines-murrine
 Architecture: any
 Depends: libgtk2.0-0 (>= 2.24.5-4), ${misc:Depends}, ${shlibs:Depends}
-Recommends: murrine-themes (>= 0.98)
+Suggests: murrine-themes,
 Multi-Arch: same
 Description: cairo-based gtk+-2.0 theme engine
  "Murrine" is an Italian word meaning the glass artworks done by Venicians

Bug#946031: ITP: sgmllib3k -- Python 3 port of Python 2's sgmllib

[Mikhail Gusarov]

Package: wnpp
Severity: wishlist
Owner: Mikhail Gusarov 

* Package name: sgmllib3k
  Version : 1.0.0
  Upstream Author : Virgil Dupras 
* URL : https://pypi.org/project/sgmllib3k/
* License : PSF-2
  Programming Lang: Python
  Description : Python 3 port of Python 2's sgmllib

sgmllib was dropped from the Python standard library in Python 3. This
package provides a port of the library to Python 3.

This package is needed as a new dependency of archmage package version 0.4.0.

archmage < 0.4.0 required Python 2 and used sgmllib package from standard 
library,
archmage 0.4.0 supports Python 3, but requires this out-of-stdlib package.

Bug#944417: transition: cgal

[Joachim Reichel]

Control: tags -1 -moreinfo

Hi Paul,

On 02.12.19 21:34, Paul Gevers wrote:
> Have those patches been submitted to the BTS? Are the maintainers of
> these packages aware of this? Are the changes trivial and are you ready
> to NMU them (except rheolef)?

I've contacted the maintainers on Nov. 11th about the upcoming transition and
included my patches, but did not file bugs so far.

I'm in contact with the openscad maintainer, but did not receive any feedback
from the other maintainers. (The prepair/pprepair maintainer replied in the
FTBFS bug reports to remove those two packages from testing if they block the
transition.)

The changes are trivial (require at least C++14, do not link with CGAL libraries
anymore). I'm ready to NMU the rdeps.

  Joachim

Bug#888140: (no subject)

[gustavo panizzo]

Hello

just to add a piece of information

Since version 1.0.13 netfilter-persistent (aka iptables-persistent)
provides 2 dummy services, iptables.service and ip6tables.service

Both of them are managed as alternatives so other firewall managers can
provide them; fail2ban could `Require` and `After` to this virtual
services instead of list them all in the override.

On the other hand, you could list them all in the service file, systemd
will ignore the inexistant services.


thanks for fail2ban :)

--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#937061: Python3 Port of ModelBuilder

[Andreas Tille]

Hi Scott,

On Mon, Dec 02, 2019 at 12:18:38PM -0500, Scott Talbert wrote:
> On Tue, 8 Oct 2019, Andreas Tille wrote:
> 
> > Hi Flávio,
> > 
> > Varun Hiremath once cared for Debian packages of ModelBuilder[1].  His
> > effort seemed to have been stalled and so Debian remained at version
> > 0.4.1.  In the process of migrating all Debian packages from Python2 to
> > Python3 I stumbled upon this package and moved under Debian Science
> > team maintenance[2].
> > 
> > I realised that version 0.4.6 need a Python module BIP[3].  (BTW, as a
> > general remark: It would be nice if you would keep release tags in sync
> > with PyPI.)  Since BIP is not packaged for Debian I would consider doing
> > so - but only Python3 modules are permitted to go into Debian.  Since
> > I'm not sure whether I will reach my original goal to get ModelBuilder
> > converted to Python3 succesfully I wonder whether you can uncover some
> > plan you might have with ModelBuilder whether you want to port it
> > yourself do Python3.
> 
> Hi Andreas,
> 
> Do you (or Flavio) plan on porting model-builder to Python 3?
> 
> If not, I will probably just convert this to an RM request as it seems
> model-builder is unmaintained upstream (and downstream).

I have no personal interest in ModelBuilder - just spottet it as a
reverse dependency of Python2 scipy and had a look whether we can bump
this to Python3.  The effort seemed to be more than a quick shot,
thought.

Kind regards

Andreas.


-- 
http://fam-tille.de

Bug#946030: xul-ext-firetray classified as a legacy extension by Thunderbird 68.2.2 (Debian Stable AMD64)

[Cae Sium]

Package: xul-ext-firetray
Version: 0.6.1+dfsg-1.2
Maintainer: Debian Mozilla Extension Maintainers <
pkg-mozext-maintain...@lists.alioth.debian.org>
Provides: firetray, icedove-firetray, thunderbird-firetray
Depends: thunderbird (>= 1:57.0) | icedove (>= 1:57.0)
Enhances: icedove, thunderbird
Breaks: icedove (<< 1:57.0), thunderbird (<< 1:57.0)
Description-en: system tray extension for Thunderbird
 FireTray is a system tray extension for Thunderbird.  It supports setting
up a custom icon, hiding to the tray instead of closing, displaying the
number of unread mails, and more. FireFox and versions of Thunderbird prior
to 57 are no longer supported.



Description of the incorrect behavior:

xul-ext-firetray used to work with Thunderbird

However, there is a recent security update to Thunderbird - the updated
Thunderbird classifies the current   xul-ext-firetray   as a legacy
extension and causes it to stop working.

For your review and update please.

Bug#945493: feedback please

[Emfox Zhou]

hello, there is a new version mcomix3+git20191129-1 released which may have
impact to this bug, but since I have not that many comic books to test this
bug,
would you please update the status of testing this bug in new version?

-- 
Emfox Zhou

GnuPG Public Key: 0x1DEB

Bug#946029: espeak: inform that --stdin flag reads multi-line text and then speaks it after EOF

[Usawashi]

Package: espeak
Version: 1.48.04+dfsg-7
Severity: minor


Hello maintainers..!

There's two ways to have espeak read from stdin: 
- running it with no arguments, which makes it speak every line; and
- running it with the --stdin flag, which makes it read a text file (viz.
multi-line text) from stdin until the EOF, and then speak it all at
once.

I found out the difference between the two because, I wanted to 
pipe edbrowse, an interactive program, to espeak 
to make it speak out every new line of output -
so I read the manpage of espeak for flags to use stdin,
since some other programs in Debian require a flag.

I figured out after a while to not use that flag but,
it'd be nice if the manpage added 
a sentence or two in the description for the --stdin flag
mentioning this different behaviour from no-argument espeak.

Thank you! And sorry for my bad writing..


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

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

Versions of packages espeak depends on:
ii  libc6   2.28-10
ii  libespeak1  1.48.04+dfsg-7
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6

espeak recommends no packages.

espeak suggests no packages.

-- no debconf information

Bug#946012: pyosmium unsatisfiable cross Build-Depends

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 12/3/19 6:04 AM, Helmut Grohne wrote:
> On Tue, Dec 03, 2019 at 05:39:44AM +0100, Sebastiaan Couwenberg wrote:
>>> I have less clue about shapely. I couldn't identify the actual use. Is
>>> it really needed?
>>
>> It's used in examples/amenity_list.py which is tested via
>> test/test_examples.py.
> 
> Then it should also be annotated . Thank you.

Fixed in git.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#946012: pyosmium unsatisfiable cross Build-Depends

[Helmut Grohne]

Control: tags -1 - moreinfo

Hi Bas,

On Tue, Dec 03, 2019 at 05:39:44AM +0100, Sebastiaan Couwenberg wrote:
> pyosmium is a leaf package, does it really matter that cannot be cross
> built?

It doesn't matter whether it is a leaf package or not. Whether it
matters is hard to know in advance.

> > I have less clue about shapely. I couldn't identify the actual use. Is
> > it really needed?
> 
> It's used in examples/amenity_list.py which is tested via
> test/test_examples.py.

Then it should also be annotated . Thank you.

> > The attached patch implements the reductions for sphinx and mock. I used
> > reproducible builds and diffoscope to verify that these really are
> > correct. Please consider applying the patch and close this bug when
> > doing so.
> 
> I'll consider it, but it seems to not be worth the effort for this package.

The effort is already done. It's just a matter of applying the patch
now.

Do note that packages tend to become involved in dependency cycles
faster than one expects. Such reductions help breaking cycles before
they pop up. This particular patch is not specific to cross building and
helps with native bootstraps as well. It also lowers the build time on
buildds (by reducing the unpack time). I think it is a clear improvement
with little cost attached.

> What made you decide to work on this package?

Very often, it is the more complex and/or leaf packages that expose bugs
in the lower layers. I'm primarily after these, but report obvious
issues such as this as well. In general, I use popcon as a guide. Do
note that roughly every third Debian package is cross buildable today.
We're also making the whole archive build reproducibly even though you
might not see the benefit of doing so for pyosmium in particular.

Helmut

Bug#946028: fracplanet FTCBFS: runs the build architecture qmake

[Helmut Grohne]

Source: fracplanet
Version: 0.5.1-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

fracplanet fails to cross build from source, because its homegrown
configure script hard codes the build architecture qmake. It seems best
to sidestep this configure script and simply run qmake directly. Once
doing via dh_auto_configure, fracplanet cross builds just fine. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru fracplanet-0.5.1/debian/changelog 
fracplanet-0.5.1/debian/changelog
--- fracplanet-0.5.1/debian/changelog   2019-07-09 11:38:44.0 +0200
+++ fracplanet-0.5.1/debian/changelog   2019-12-03 06:06:26.0 +0100
@@ -1,3 +1,10 @@
+fracplanet (0.5.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure call a host qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 03 Dec 2019 06:06:26 +0100
+
 fracplanet (0.5.1-5) unstable; urgency=medium
 
   * Initial source-only upload
diff --minimal -Nru fracplanet-0.5.1/debian/rules fracplanet-0.5.1/debian/rules
--- fracplanet-0.5.1/debian/rules   2017-12-07 08:22:10.0 +0100
+++ fracplanet-0.5.1/debian/rules   2019-12-03 06:06:26.0 +0100
@@ -30,10 +30,7 @@
 
 configure-stamp: configure
dh_testdir
-   #QTDIR=/usr/lib/qt4 ./configure $(QMAKEOPTIONS)
-   #QTDIR=/usr/lib/x86_64-linux-gnu/qt5 ./configure $(QMAKEOPTIONS)
-   chmod +x configure
-   ./configure $(QMAKEOPTIONS)
+   dh_auto_configure -- VERSION_NUMBER=`./VERSION` fracplanet.pro 
$(QMAKEOPTIONS)
touch $@
 
 build build-arch: build-stamp

Bug#946027: ITP: golang-github-nkovacs-streamquote -- Go package providing a streaming version of strconv.Quote

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-nkovacs-streamquote
  Version : 1.0.0-1
  Upstream Author : Nikola Kovacs; The Go Authors
* URL : https://github.com/nkovacs/streamquote
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go package providing a streaming version of strconv.Quote

 This package provides a streaming version of strconv.Quote.
 .
 It allows you to quote the data in an io.Reader and write it out to an
 io.Writer without having to store the entire input and the entire output
 in memory.
 .
 Its primary use case is go.rice (https://github.com/GeertJohan/go.rice)
 and similar tools, which need to convert lots of files, some of them
 quite large, to go strings.
 .
 converter := streamquote.New()
 converter.Convert(inputfile, outfile)
 .
 Unlike strconv.Quote, it does not add quotes around the output.


Rationale:
 Needed for upgrading golang-github-geertjohan-go.rice to 1.0.0,
 which in turn is needed by golang-github-alecthomas-chroma 0.6.8,
 which in turn is needed by hugo 0.59.0 and up.

Bug#946026: lintian: check for tabs in formatted fields in debian/copyright

[Felix Lechner]

Hi Jelmer,

First of all, thank you for D-Janitor. We look forward to learning
more about it and would like to support your efforts.

On Mon, Dec 2, 2019 at 8:30 PM Jelmer Vernooij  wrote:
>
> It would be great if lintian could check for tab characters in the
> various text paragraphs in debian/copyright.

I have spent some time with that code. It is long and complex. Would
it be acceptable to simply check if the file contains any tabs at all
(=~ /\t/)?

Kind regards,
Felix

Bug#944947: python-uinput: diff for NMU version 0.11.2-2.1

[Boyuan Yang]

Control: tags -1 + patch pending

Dear maintainer,

I've prepared an NMU for python-uinput (versioned as 0.11.2-2.1) and
uploaded it to DELAYED/1. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-uinput-0.11.2/debian/changelog python-uinput-
0.11.2/debian/changelog
--- python-uinput-0.11.2/debian/changelog   2019-08-04 14:51:21.0
-0400
+++ python-uinput-0.11.2/debian/changelog   2019-12-02 23:34:43.0
-0500
@@ -1,3 +1,15 @@
+python-uinput (0.11.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ أحمد المحمودي (Ahmed El-Mahmoudy) ]
+  * Update Standards version to 4.4.1.
+  * Add dh-python to build deps. (Closes: #944947, 945233)
+  * Bumped debhelper compat level to 12.
+  * Add Rules-Requires-Root: no.
+
+ -- Boyuan Yang   Mon, 02 Dec 2019 23:34:43 -0500
+
 python-uinput (0.11.2-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-uinput-0.11.2/debian/control python-uinput-
0.11.2/debian/control
--- python-uinput-0.11.2/debian/control 2019-08-04 14:49:37.0 -0400
+++ python-uinput-0.11.2/debian/control 2019-12-02 23:34:43.0 -0500
@@ -3,10 +3,12 @@
 Priority: optional
 Maintainer: Debian Python Modules Team <
python-modules-t...@lists.alioth.debian.org>
 Uploaders: أحمد المحمودي (Ahmed El-Mahmoudy) <
aelmahmo...@users.sourceforge.net>
-Build-Depends: debhelper-compat (= 11),
+Build-Depends: debhelper-compat (= 12),
pkg-config,
python3-all-dev,
-Standards-Version: 4.1.5
+   dh-python
+Standards-Version: 4.4.1
+Rules-Requires-Root: no
 Homepage: http://tjjr.fi/sw/python-uinput
 Vcs-Git: https://salsa.debian.org/python-team/modules/python-uinput.git
 Vcs-Browser: https://salsa.debian.org/python-team/modules/python-uinput


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

Bug#946012: pyosmium unsatisfiable cross Build-Depends

[Sebastiaan Couwenberg]

Control: tags -1 moreinfo

On 12/2/19 9:38 PM, Helmut Grohne wrote:
> pyosmium cannot satisfy its cross Build-Depends. There are multiple
> reasons for that. The ones reported by botch[1] are mainly sphinx and
> mock, but also shapely.

pyosmium is a leaf package, does it really matter that cannot be cross
built?

> I have less clue about shapely. I couldn't identify the actual use. Is
> it really needed?

It's used in examples/amenity_list.py which is tested via
test/test_examples.py.

> The attached patch implements the reductions for sphinx and mock. I used
> reproducible builds and diffoscope to verify that these really are
> correct. Please consider applying the patch and close this bug when
> doing so.

I'll consider it, but it seems to not be worth the effort for this package.

What made you decide to work on this package?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#946026: lintian: check for tabs in formatted fields in debian/copyright

[Jelmer Vernooij]

Package: lintian
Version: 2.39.0
Severity: wishlist

The debian/copyright machine readable standard mentions that the same
formatting rules for its Formatted Text fields as for the long
"Description" field in packages. 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

https://www.debian.org/doc/debian-policy/ch-controlfields#description
explicitly says not to use tab characters.

It would be great if lintian could check for tab characters in the
various text paragraphs in debian/copyright.

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

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

Versions of packages lintian depends on:
ii  binutils 2.33.1-4
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-6
ii  gettext  0.19.8.1-10
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b2
ii  libarchive-zip-perl  1.67-1
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.80+repack-2+b1
ii  man-db   2.9.0-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b4
pn  libtext-template-perl  

-- no debconf information

Bug#847690: [Pkg-emacsen-addons] Bug#847690: dh-elpa: better handling of `deftheme' themes

[Sean Whitton]

Hello,

On Sat 10 Dec 2016 at 09:40AM -07, Sean Whitton wrote:

> Function autoloads are handled elegantly by dh-elpa.  After installing a
> package, you can just put (turn-on-some-global-minor-mode) in your
> ~/.emacs, and everything works fine.
>
> Themes defined with `deftheme' don't work so well.  After installing a
> theme, a simple call to `load-theme' in your ~/.emacs will fail.
>
> Two possible workarounds are:
>
> (package-initialize)
> (load-theme 'zenburn t)
>
> or
>
> (add-hook 'after-init-hook (lambda () (load-theme 'zenburn)))
>
> but this really shouldn't be necessary.

Hmm, I'm not sure, but perhaps this problem is not actually about
`deftheme' themes.  I think perhaps no dh_elpa package autoloads happen
until `package-initialize' is called.  That would make this a 'wontfix'.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#937476: RM pymappergui

[Scott Talbert]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: pymappergui -- RoQA; dead upstream; unmaintained; low 
popcon; blocking py2 removal

Bug#946025: dh-make-elpa: should not add files containing only tests to debian/elpa

[Sean Whitton]

Package: dh-make-elpa
Version:0.17

Hello,

Files containing only tests should never be installed to the .deb, so
dh-make-elpa shouldn't include them in the d/elpa or d/foo.elpa file it
generates.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#771971: Finanzielle Hilfe (Darlehen @1,3%)

[Banca IMI S.P.A]

--
Grüße Herr / Frau,

Benötigen Sie finanzielle Unterstützung (Darlehen)?
Sprechen Sie mit uns bei Banca IMI S.P.A., wir werden Ihre finanziellen 
Probleme lösen.


Unser Zinssatz beträgt 1,3%  Bitte bewerben Sie sich jetzt und füllen 
Sie die folgenden Bewerbungsdetails aus:


Vollständiger Name:
Darlehensbetrag: ___
Mietzeitraum: ___
Darlehen Zweck: _
Telefon:

Wir warten auf Ihre Bewerbung, damit Ihre Kreditanfrage bearbeitet 
werden kann.


Mit freundlichen Grüßen

Bug#946024: vcswatch: track last commit sha

[Jelmer Vernooij]

Package: qa.debian.org
Severity: wishlist

For tools that rely on vcswatch to know what vcs repository to process,
it would be great if vcswatch could store:

 * the latest revision (e.g. commit SHA for Git, revision number for
   SVN, etc)
 * When that revision was created

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

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

Bug#937321: presage: Python2 removal in sid/bullseye

[Scott Talbert]

On Mon, 2 Dec 2019, Scott Talbert wrote:


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 Matteo,

Do you plan to port presage to Python 3?  If not, I'll probably convert this 
to an RM request as the package seems to be mostly unmaintained and is 
blocking the removal of Python 2.


Alternatively, perhaps just the Python pieces of presage can be removed, 
as those don't seem to have any rdepends?


Scott

Bug#945911: APT leaks repository credentials

[Florian Zumbiehl]

Hi,

> > > > > You didn't explain well, so Julian misunderstood you. I think you 
> > > > > where
> > > > > trying to say that http://foo.example.org is made to redirect to
> > > > > http://bar.example.org which would sent the auth for bar.example.org
> > > > > over the wire unencrypted (and so could be observed by a MITM) even if
> > > > > you usually access via https://bar.example.org (note the s).
> > > > 
> > > > That doesn't require MitM, but other than that, yes.
> > > 
> > > 1) Yes, they do require MitM
> > 
> > No, they don't.
> > 
> > >(1) MITM on the DNS to hihack requests to bar to your own server
> > 
> > Nothing of the sort.
> > 
> > >(2) MITM on the Network routing to directly read requests
> > 
> > 1. Reading requests does not require MitM.
> > 
> > 2. Nothing of that sort either.
> 
> OK, it does not _require_ MitM. It's just substantially more realistic.
> 
> (details:)
> It's highly unlikely that you'll gain control to both a public mirror
> as root / www-data user) _and_ a password-protected one (as any user), hence
> that did not even cross my mind. The MitM attack scenario is substantially
> more realistic, and would have been an easier introduction :)

Except ... this scenario was not about having access to a
password-protected server, but about eavesdropping on the route to it?!

And in any case, I'd be interested to know how you quantify those
probabilities.

> > I really don't see how I could have been any more focused than that.
> 
> I don't know, give some urls and a succinct relevant example:
> 
> "Given two repos http://public.mirror.example/ and 
> https://internal.repo.example/:
> 
> Make http://public.mirror.example/ redirect to 
> http://internal.repo.example:443/,
> and apt is sending auth.conf credentials meant for the encrypted repo in 
> plain text.
> "
> 
> It makes you see immediately that something is wrong vs a wall of prose text
> that you have to parse and make sense of - which I hilariously failed at, but
> then it was 11pm on a Saturday night.

Well, maybe, but then, that is arguably the exact opposite of being more
focused, in that it shows a more or less random example of a possible
attack, rather than pointing out the underlying cause.

> > However, it certainly would not fix the third scenario, and it would also
> > not fix the first scenario in the case where people do explicitly configure
> > credentials for HTTP, such as for internal servers that are accessed
> > through a trusted network where eavesdropping is not a concern.
> 
> (summary: the other scenarios are not relevant)
> 
> The first scenario was for a different port. The port can already be 
> hardcoded, we could default to port 443 for https, rather than any port.

How is it relevant that a user who happens to be aware that APT is
vulnerable, even though even the documentation doesn't say so, can manage
to (partially) work around that vulnerability? Does that make the average
user any more secure?

Defaulting to restricting the port would obviously stop more potential
attacks, as well as just accidental leaks due to the potentially somewhat
surprising (albeit documented) current behaviour, so I'd think it's
probably a good idea. But it's not a complete solution to this
vulnerability either.

> It's also fairly irrelevant, as you still need access to the certificate
> and for all intents and purposes, if you have the certificate you are
> proofing that we are talking to the correct server.

Well, APT does support plain text HTTP with credentials ... so plain text
HTTP with credentials should be implemented securely in APT, shouldn't it?

> Now, if you use credentials on an http repository, you are lost anyway,
> a request with the credentials in plain text will be made whether or not

Which would be a problem on a trusted network how? To take the maybe most
extreme scenario: How is it a security problem to use plain text HTTP
credentials on localhost?

> the redirect exists (and woohoo, that happens in the background automatically,
> at a completely random time). 

Does it? How do you know?

> Having a redirect increases your chances ever so slightly, because you can use
> a redirect for install, rather than the attack only working for update, but 
> that
> is a relatively minor concern.

Erm ... having the redirect is what enables an otherwise impossible
attack!?

Also, I would think that install is the thing that in and of itself is not
vulnerable to this at all, because the contents of the package file are
cryptographically bound to the package lists, so at worst an attacking
server could redirect you to a file that APT will just reject anyway, which
is no increased privilege over just sending you a random wrong file in the
first place, which a server could always do anyway?

> > Ultimately, to solve a confused deputy problem, you have to allow the user
> > to specify who is allowed to use a given set of credentials, which in this
> > case in particular means which server is allowed 

Bug#937321: presage: Python2 removal in sid/bullseye

[Scott Talbert]

On Fri, 30 Aug 2019, Matthias Klose wrote:


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 Matteo,

Do you plan to port presage to Python 3?  If not, I'll probably convert 
this to an RM request as the package seems to be mostly unmaintained and 
is blocking the removal of Python 2.


Thanks,
Scott

Bug#902051: libxslt: generate-id() not returning unique IDs

[ma.jiang]

Dear Maintainer,
We have managed to get a unique IDs (without multi-thread). Hope this could 
help to get a reproducible build.

Now the ID is generated by a ptr diff. 
val = (long)((char *)cur - (char *)_address);
cur is the address of a xmlNsPtr node stored in a hash table(of course, 
eventually it's in the heap), base_address is a static variable(in a data 
section);

After some debug, we found there are two major disturbances that prevent a 
reproducible build.
First, hash functions use a random seed get from time(). So the address of 
nodes in hash tables(related to cur) is not stable across multi-builds.
Second, ASLR (Address Space Layout Randomization) changes the base addresses of 
data section and heap  every time we start a new process.

To fix the first problem, we could fake a fixed time. We currently use 
libfaketime, and of course eventually  something like 
https://gitlab.gnome.org/GNOME/libxslt/commit/e57df303eca25a2a3f9e0625c29f4b20177858cc
   should be applied.

To fix the second problem, we could change the ptr diff algorithm to 
val = (long)((char *)cur -  heapStartAddr);
After this change, ALSR could not disturb ID generation anymore, because we 
have eliminated the base address of heap.
==
We have use the following patch to make the xlstproc produce stable IDs.
--- libxslt-master/libxslt/functions.c  2010-12-24 20:30:00.0 +0800
+++ libxslt-master-new/libxslt/functions.c  2010-12-24 20:30:00.0 
+0800
@@ -14,7 +14,7 @@
 #include "libxslt.h"

 #include 
-
+#include 
 #ifdef HAVE_SYS_TYPES_H
 #include 
 #endif
@@ -671,6 +671,13 @@ xsltFormatNumberFunction(xmlXPathParserC
 xmlXPathFreeObject(decimalObj);
 }

+
+static char *__heapStartAddr;
+static __attribute__((constructor)) void initHeapStart()
+{
+   __heapStartAddr = sbrk(0);
+}
+
 /**
  * xsltGenerateIdFunction:
  * @ctxt:  the XPath Parser context
@@ -681,7 +688,6 @@ xsltFormatNumberFunction(xmlXPathParserC
  */
 void
 xsltGenerateIdFunction(xmlXPathParserContextPtr ctxt, int nargs){
-static char base_address;
 xmlNodePtr cur = NULL;
 xmlXPathObjectPtr obj = NULL;
 long val;
@@ -722,7 +728,8 @@ xsltGenerateIdFunction(xmlXPathParserCon
 if (obj)
 xmlXPathFreeObject(obj);

-val = (long)((char *)cur - (char *)_address);
+val = (long)((char *)cur - __heapStartAddr);
+
 if (val >= 0) {
   snprintf((char *)str, sizeof(str), "idp%ld", val);
 } else {

Bug#945066: buster-pu: package enigmail/2:2.1.3+ds1-4~deb10u1

[D. R. Evans]

Sat, 23 Nov 2019 10:53:52 +0100,  Salvatore Bonaccorso :

> Yes, Moritz (jmm) acked the upload to happen via security.d.o so it is
> currently pending (for buster, the stretch one seem to have some
> issues to be resolved).

Where can I follow the status of this issue for stretch, as that is what I am
running on one of my machines, and I have had to hold back thunderbird updates
on that machine for a month or so now?

  Doc Evans

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

Bug#834026: libghc-yi-rope-dev: links against libicu but doesn't depend on it

[Sean Whitton]

control: severity -1 serious
control: tag -1 - moreinfo

Hello,

On Tue 16 Aug 2016 at 09:55AM -04, Joachim Breitner wrote:

> I believe the problem is the following: When linking libghc-yi-rope-
> dev, ghc (or Caba?) will look at all its dependencies, and their
> "extra-libraries" fields ("icuuc icui18n icudata" for text-icu) and
> pass that to the linker (as "-licuuc -licui18n -licudata"). This is how
> we get this unwanted dependency.
>
> But since yi-rope does itself not actually use any of these symbols,
> this is probably not required! And not passing these libraries here
> should solve the problem.

If this diagnosis of the problem is correct, then I believe that the bug
severity should be set back to 'serious'.

If libicu is not present on the system, attempts to open yi-rope will
crash because the dynamic linker will try and fail to open libicu, even
though no symbols from that library actually get used.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#946023: please update to the most recent release

[Yaroslav Halchenko]

Package: nsntrace
Version: 0~20160806-1+b1
Severity: normal

Although it is not that actively developed indeed, it is a bit freshier and
does have versioned tagged releases:

(git)lena:~/proj/misc/nsntrace[master]git
$> git describe
v3-1-g3c1c651

And here is commits since 20160806

commit 3c1c65148f0609d288303bf1a6a01627e9c56a82 (HEAD -> master, origin/master, 
origin/HEAD)
Author: Jakub Wilk 
Date:   Tue Mar 12 19:10:38 2019 +0100

man: Fix uneven indentation in options list

commit 541063255a754d4721b33ae74bfdc26fe555930a (tag: v3)
Author: Jonas Danielsson 
Date:   Sun Aug 14 19:56:18 2016 +0200

Release 3

commit a749a4c6938bc5ac39ad0fcf088740b0a794e528
Author: Jonas Danielsson 
Date:   Sun Aug 14 19:49:59 2016 +0200

tests: check_return_code.sh: Make sure to clean up

commit 93462dbaee67bfe3900590b1d3b1b7c6cf428564
Author: Logan Rosen 
Date:   Sat Aug 13 14:03:02 2016 -0700

build: Use LDADD instead of LDFLAGS to ensure linking order (#17)

nsntrace currently fails to build in Ubuntu because the linking order
does not meet the requirements for ld --as-needed: http://bit.ly/2aK9Xjs

This commit puts the libs in the correct location, LDADD instead of
LDFLAGS, to fix this failure to build.


so not much...  nevertheless probably would be worth uploading with a
proper version indicator so others didn't have to dive into git history to
figure out how old it is

Cheers!

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

Kernel: Linux 5.4.0-trunk-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=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 nsntrace depends on:
ii  iptables   1.8.3-2
ii  libc6  2.29-3
ii  libnl-3-2003.4.0-1+b1
ii  libnl-route-3-200  3.4.0-1+b1
ii  libpcap0.8 1.9.1-2

nsntrace recommends no packages.

Versions of packages nsntrace suggests:
ii  sudo  1.8.29-1

-- debconf-show failed

Bug#946022: gitlab-workhorse: build-depends on obsolete package.

[peter green]

Package: gitlab-workhorse
Version: 8.8.1+debian-3
Severity: serious
Tags: patch

gitlab-workhorse build-depends on golang-logrus (>= 1.0~), golang-logrus used 
to be a transitional package, but is now (in testing) only an unversioned virtual 
package that does not satisfy your build-dependency.

Please update your build-dependency to golang-github-sirupsen-logrus-dev

Bug#938909: zope.interface: Python2 removal in sid/bullseye

[peter green]

severity 938909 serious
thanks

zope.interface build-depends on python-zope.event which is no longer built by 
the zope.event source package.

Bug#946021: qtpass: Invoking results in SegFault

[scott092707]

Package: qtpass
Version: 1.3.0-2
Severity: grave
Justification: renders package unusable

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Scott Jacobs 
To: Debian Bug Tracking System 
Subject: qtpass: Invoking results in SegFault
Bcc: Scott Jacobs 
Message-ID: 
<157533667450.3876.7878626174146484422.reportbug@ASUS-PRIME-B350M-A-CSM>
X-Mailer: reportbug 7.5.3
Date: Mon, 02 Dec 2019 20:31:14 -0500
X-Debbugs-Cc: scott092...@aol.com

Dear Maintainer,

Invoking qtpass from the menu results in nothing happening.

Invoking from the terminal results in:
~$ qtpass
Segmentation fault

Invoking with gdb does not result in SegFault, but also exits without bringing
up the program.
bt yields nothing except "No stack"

=
~$ gdb qtpass
GNU gdb (Debian 8.3.1-1) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from qtpass...
Reading symbols from /usr/lib/debug/.build-
id/3c/f1d9ba416482bc8a78d951a09d69c5bf14778e.debug...
(gdb) run
Starting program: /usr/bin/qtpass
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x724c6700 (LWP 2904)]
[New Thread 0x715cb700 (LWP 2905)]
[Thread 0x724c6700 (LWP 2904) exited]
[Thread 0x715cb700 (LWP 2905) exited]
[Inferior 1 (process 2900) exited normally]
(gdb) bt
No stack.
(gdb) quit
=



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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
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 qtpass depends on:
ii  libc6   2.29-2
ii  libgcc1 1:8.3.0-6
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-4
ii  libqt5network5  5.11.3+dfsg1-4
ii  libqt5svg5  5.11.3-3
ii  libqt5widgets5  5.11.3+dfsg1-4
ii  libstdc++6  9.2.1-8
ii  pass1.7.3-2

Versions of packages qtpass recommends:
ii  pass-extension-otp  1.2.0-1
ii  pwgen   2.08-2

Versions of packages qtpass suggests:
ii  git  1:2.24.0-1

-- no debconf information

Bug#946020: zeroinstall-injector build-dependencies unsatisfiable in testing.

[peter green]

Package: zeroinstall-injector
Version: 2.14.1-3
Severity: serious

zeroinstall-injector build-depends on libcurl-ocaml-dev which is not currently 
in testing, either libcurl-ocaml-dev needs to be fixed so it can return to 
testing, zeroinstall-injector needs to eliminate the dependency (no idea if 
this is feasible) or zeroinstall-injector needs to leave testing too.

Bug#946019: rust-rusty-tags build-depends on nonexistent virtual package.

[peter green]

Package: rust-rusty-tags
Version: 3.5.1-1
Severity: serious
Tags: bullseye, sid

rust-rusty-tags build-depends on librust-dirs-1+default-dev which is no longer 
provided by rust-dirs. It seems to have been replaced by 
librust-dirs-2+default-dev.

Bug#928442: Same issue

[RattusSolarus]

I'm having what appears to be exactly the same issue running Clonezilla 
in Buster installed to SSD in 2 separate computers.


Clonezilla version: 3.27.16-3

Bug#945978: src:requests: FTBFS against python-urllib3 1.25 and newer

[Daniele Tricoli]

Hello Jonathan,
thanks for this report.

On Sun, Dec 01, 2019 at 05:13:07PM -0800, jrnie...@gmail.com wrote:
> Source: requests
> Version: 2.21.0-1
> Tags: upstream
> 
> debian/control in the requests package contains
> 
>  Build-Depends:
>   python-chardet (>= 3.0.2), python-chardet (<< 3.1.0),
>   python-urllib3 (>= 1.21.1), python-urllib3 (<< 1.25),
>   python3-chardet (>= 3.0.2), python3-chardet (<< 3.1.0),
>   python3-urllib3 (>= 1.21.1), python3-urllib3 (<< 1.25),
> 
> This prevents running test builds against newer versions of these
> libraries.
> 
> Are the newer versions known to break the package?  Are there bugs or
> other information available to help with upgrading?  (I checked for a
> README.source with this kind of information but wasn't able to find it.)
> 
> Upstream bumped its declared maximum version of urllib3 in
> https://github.com/psf/requests/commit/aeda65bbe57ac5edbcc2d80db85d010befb7d419.
> Do we know why upstream supplies these upper bounds on versions of
> dependent packages to build against?  Using < instead of != in
> dependencies makes it harder to find a set of package versions that
> works well together.

I used to not have strict version dependencies until something break (if you
are interested into this story I can search for the details), so I decided to
follow upstream and set the exact versions they are using. Yes, I know that
this make things harder, but I prefer to be cautious since a lot of packages
depends on requests.

I have just uploaded requests 2.22.0-1 into experimental: it bump the urllib3
dependency to << 1.26, as upstream.

My plan is to perform more testing during this week and move both urllib3 and
requests to unstable by the end of the week.
I plan, also, to close this bug with the upload of requests 2.22.0 to unstable
since it can be built using urllib3 1.25.

If something looks not good to you, please ping me.

Kind regards,

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org

Bug#945883: python-urllib3: Update python3-urllib3 on unstable

[Daniele Tricoli]

On Sat, 30 Nov 2019 11:34:20 -0300 Emmanuel Arias  
wrote:
> Package: python-urllib3
> Version: 1.19.1-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I am working on update elasticsearch-curator, and this package need
> urllib3 >= 1.24.2. Currently the version 1.25.6 is on experimental
> is there some  possiblity to move it to unstable, please?
> 
> Thanks!
> Cheers
> 
> 

Bug#943187: qmidiarp: Python2 removal in sid/bullseye

[Peter Green]

severity 943187 serious
thanks

qmidiarp build-depends on python-scour, which is no longer built by the scour 
source package and is no longer in testing or unstable.

Bug#794969: udev: change in network device naming scheme unnecessarily and incorrectly renames WiMAX devices

[brian m. carlson]

On 2019-12-02 at 17:04:29, Michael Biebl wrote:
> Control: tags -1 + moreinfo
> 
> 
> Hi
> 
> On Mon, 10 Aug 2015 23:25:36 + "brian m. carlson"
>  wrote:
> > On Sun, Aug 09, 2015 at 05:54:29PM +0200, Marco d'Itri wrote:
> > > On Aug 08, "brian m. carlson"  wrote:
> > > 
> > > > Previously, my WiMAX device was named something like wmx0.  Now, it
> > > > appears it's been renamed to enx.  First of all, the name
> > > > has changed from what it used to be, and now I have to check that it's
> > > > not broken anything.  There wasn't supposed to be a naming change for
> > > > people with the persistent-net rules in place.
> > > Indeed: what was the content of your 70-persistent-net.rules file?
> > > I suspect that persistent naming just never worked for you for this
> > > interface.
> > 
> > The interface is clearly missing:
> > 
> >   # PCI device 0x8086:/sys/devices/pci:00/:00:19.0 (e1000e)
> >   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
> > ATTR{address}=="f0:de:f1:b8:36:fd", ATTR{dev_id}=="0x0", ATTR{type}=="1", 
> > KERNEL=="eth*", NAME="eth0"
> >   
> >   # PCI device 0x8086:/sys/devices/pci:00/:00:1c.1/:03:00.0 
> > (iwlwifi)
> >   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
> > ATTR{address}=="64:80:99:4f:73:a0", ATTR{dev_id}=="0x0", ATTR{type}=="1", 
> > KERNEL=="wlan*", NAME="wlan0"
> > 
> > I suppose the idea was to skip USB devices, thinking that they were all
> > removable, but I can't be certain without seeing the generator, which
> > has been removed.
> > 
> > > > Secondly, this is not an Ethernet device, so en is not correct (it
> > > > should be ww).  The device is on the USB bus (using the driver
> > > > i2400m-usb).
> > > I do not think that such a distinction is relevant here.
> > 
> > If you're going to autogenerate the name, please autogenerate it such
> > that it's consistent with the naming scheme.  The comment in
> > udev-builtin-net_id.c indicates that ww is appropriate here.  People
> > should be able to predict interface names, such that configuration can
> > be autogenerated (e.g. for puppet).  Naming some WWAN devices as ww but
> > others as en is silly.
> 
> 
> Is this issue still valid?
> I do have an (internal) wimax device which is named wwx02803X, i.e.
> has the ww prefix as one would expect.
> 
> If it's still a problem, please attach the output of
> udevadm info /sys/class/net/$(iface)

I'm unsure.  The issue is now four years old and I'm using a different
laptop without a WiMAX card.  If you're sure that it's been fixed, I'm
fine with you closing it.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#937901: python-lz4: Python2 removal in sid/bullseye

[Peter Green]

severity 937901 serious
thanks

python-lz4 build-depends on the python-pkgconfig binary package, which is no 
longer built by the python-pkgconfig source package and is no longer in testing 
or unstable.

Bug#946018: opencpn: FTBFS due to trying to use removed wx GTK2 flavour

[Olly Betts]

Source: opencpn
Version: 4.8.8+dfsg.2-1
Severity: grave
Justification: renders package unusable

opencpn build-depends on libwxgtk3.0-dev, but that's been dropped
(there are still some crufty remnants in unstable, but libwxgtk3.0-dev
is no longer built by the wxwidgets3.0 source package, and isn't
installable in unstable).

The removal happened while opencpn was in NEW, so it's never built
since being accepted, hence the grace severity - as-is this package is
not usable by anyone simply because there's no build of it to install!

As well as updating libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev, the
B-D on libgtk2.0-dev will need updating to libgtk-3-dev.  I suspect
libgdk-pixbuf2.0-dev will too.  There may also be code changes needed
to update for API changes between GTK2 and GTK3 if opencpn upstream
isn't GTK3 ready.

Sorry to be the bearer of bad news.

Cheers,
Olly

Bug#945161: accountwizard: Broken dependencies (KLineEdit)

[Sandro Knauß]

Hey,
 
I can't reproduce your issue, so I need your input.

First can try to replace KLineEdit with QLineEdit the file (you need root 
permission to do that):
/usr/share/akonadi/accountwizard/kolab/kolabwizard.ui

Does this already fix the issue?

Is kdepim-runtime installed and/or libkf5completion5?

hefee

--

> The accountwizard tries to instantiate widgets that are not installed when I
> try to setup a Kolab client, so this seems to be a dependency issue. The
> output from the program is:
> 
> $ accountwizard
> org.kde.knewstuff.core: Using a deprecated location for the knsrc file
> "accountwizard.knsrc"  - please contact the author of the software which
> provides th "QFormBuilder was unable to create a widget of the class
> 'KLineEdit'." "Empty widget item in QFormLayout 'formLayout'."
> "QFormBuilder was unable to create a widget of the class 'KLineEdit'."
> "Empty widget item in QFormLayout 'formLayout'."
> "QFormBuilder was unable to create a custom widget of the class
> 'KPasswordLineEdit'; defaulting to base class 'QWidget'." Kross: "Error
> error=TypeError: Result of expression 'page.widget().nameEdit' [undefined]
> is not an object. lineno=27 trace=\n() at /usr/share/akona
> 
> This means that I cannot enter the name, nor the password, due to the
> widgets not being properly instantiated.
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (600, 'testing'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
> LC_ALL to default locale: No such file or directory UTF-8),
> LANGUAGE=en_US:en (charmap=locale: Cannot set LC_ALL to default locale: No
> such file or directory UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages accountwizard depends on:
> ii  kio   5.62.1-2
> ii  libc6 2.29-3
> ii  libgcc1   1:9.2.1-19
> ii  libgpgmepp6   1.13.1-1
> ii  libkf5akonadicore5abi2 [libkf5akonadicore5-18.08]
> 4:18.08.3-11 ii  libkf5akonadimime5 [libkf5akonadimime5-18.08] 
>4:18.08.3-3 ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-18.08] 
>  4:18.08.3-11 ii  libkf5codecs5
> 5.62.0-1 ii  libkf5configcore5 
>5.62.0-1 ii  libkf5coreaddons5  
>   5.62.0-1 ii  libkf5crash5
>  5.62.0-1 ii  libkf5dbusaddons5
> 5.62.0-1 ii  libkf5i18n5   
>5.62.0-1 ii  libkf5identitymanagement5 [libkf5identitymanagement5-18.08]
>   18.08.3-4 ii  libkf5itemviews5   
>   5.62.0-1 ii  libkf5kcmutils5 
>  5.62.0-1 ii  libkf5kiocore5   
> 5.62.1-2 ii  libkf5krosscore5 
> 5.62.0-1 ii  libkf5ldap5abi1 [libkf5ldap5-18.08]  
> 18.08.3-3 ii  libkf5libkdepim5 [libkf5libkdepim5-18.08]
> 4:18.08.3-4 ii  libkf5libkleo5 [libkf5libkleo5-18.08]  
>   4:18.08.3-4 ii  libkf5mailtransport5 [libkf5mailtransport5-18.08]
> 18.08.3-4 ii  libkf5mailtransportakonadi5
> [libkf5mailtransportakonadi5-18.  18.08.3-4 ii  libkf5mime5abi1
> [libkf5mime5-18.08]   18.08.3-3 ii 
> libkf5newstuffcore5   5.62.0-1 ii 
> libkf5notifications5  5.62.0-1 ii 
> libkf5pimcommon5abi2 [libkf5pimcommon5-18.08] 4:18.08.3-4
> ii  libkf5wallet-bin  5.62.0-1
> ii  libkf5wallet5 5.62.0-1
> ii  libkf5widgetsaddons5  5.62.0-1
> ii  libkf5xmlgui5
> 5.62.0-1+b1 ii  libqgpgme7 
>   1.13.1-1 ii  libqt5core5a
>  5.12.5+dfsg-2 ii  libqt5dbus5 
>  5.12.5+dfsg-2 ii  libqt5gui5  
>  5.12.5+dfsg-2 ii  libqt5widgets5  
>  5.12.5+dfsg-2 ii  libqt5xml5  
>  5.12.5+dfsg-2 ii  libstdc++6  

Bug#936718: ibus-pinyin: Python2 removal in sid/bullseye

[Changwoo Ryu]

Control: forwarded https://github.com/ibus/ibus-pinyin/pull/5
Control: tags -1 + patch pending
Control: blocks 944387 by -1

I just pushed patch from the upstream push request to salsa. It seems to work.

Bug#944676: patch / intent to QA upload

[Felix Lechner]

Hi Dann,

Thanks and for asking. Please go ahead.

I haven't rebased since before your last QA upload, so it makes no
difference at this point.

Kind regards,
Felix

On Mon, Dec 2, 2019 at 2:48 PM dann frazier  wrote:
>
> tag 944676 + patch
> thanks
>
> hey Felix,
>
>   I've prepared and tested the following debdiff for mdadm. Before I
> do a QA upload, I wanted to check if you have an imminent upload to
> your ITA (#924367) with which it would interfere.
>
>   -dann

Bug#944676: patch / intent to QA upload

[dann frazier]

tag 944676 + patch
thanks

hey Felix,

  I've prepared and tested the following debdiff for mdadm. Before I
do a QA upload, I wanted to check if you have an imminent upload to
your ITA (#924367) with which it would interfere.

  -dann
diff -Nru mdadm-4.1/debian/changelog mdadm-4.1/debian/changelog
--- mdadm-4.1/debian/changelog  2019-08-09 11:19:20.0 -0600
+++ mdadm-4.1/debian/changelog  2019-12-02 14:35:49.0 -0700
@@ -1,3 +1,10 @@
+mdadm (4.1-4) unstable; urgency=medium
+
+  * QA upload.
+  * Add support for RAID0 layouts. (Closes: #944676) (LP: #1850540)
+
+ -- dann frazier   Mon, 02 Dec 2019 14:35:49 -0700
+
 mdadm (4.1-3) unstable; urgency=medium
 
   * QA upload.
diff -Nru 
mdadm-4.1/debian/patches/0001-Create-add-support-for-RAID0-layouts.patch 
mdadm-4.1/debian/patches/0001-Create-add-support-for-RAID0-layouts.patch
--- mdadm-4.1/debian/patches/0001-Create-add-support-for-RAID0-layouts.patch
1969-12-31 17:00:00.0 -0700
+++ mdadm-4.1/debian/patches/0001-Create-add-support-for-RAID0-layouts.patch
2019-12-02 14:35:49.0 -0700
@@ -0,0 +1,335 @@
+From 329dfc28debb58ffe7bd1967cea00fc583139aca Mon Sep 17 00:00:00 2001
+From: NeilBrown 
+Date: Mon, 4 Nov 2019 14:27:49 +1100
+Subject: [PATCH 1/2] Create: add support for RAID0 layouts.
+
+Since Linux 5.4 a layout is needed for RAID0 arrays with
+varying device sizes.
+This patch makes the layout of an array visible (via --examine)
+and sets the layout on newly created arrays.
+--layout=dangerous
+can be used to avoid setting a layout so that they array
+can be used on older kernels.
+
+Tested-by: dann frazier 
+Signed-off-by: NeilBrown 
+Signed-off-by: Jes Sorensen 
+
+Bug-Debian: https://bugs.debian.org/944676
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1850540
+Last-Updated: 2019-12-02
+
+diff --git a/Create.c b/Create.c
+index 292f92a9..6f84e5b0 100644
+--- a/Create.c
 b/Create.c
+@@ -51,6 +51,9 @@ static int default_layout(struct supertype *st, int level, 
int verbose)
+   default: /* no layout */
+   layout = 0;
+   break;
++  case 0:
++  layout = RAID0_ORIG_LAYOUT;
++  break;
+   case 10:
+   layout = 0x102; /* near=2, far=1 */
+   if (verbose > 0)
+@@ -950,6 +953,11 @@ int Create(struct supertype *st, char *mddev,
+   if (rv) {
+   pr_err("ADD_NEW_DISK for %s failed: 
%s\n",
+  dv->devname, strerror(errno));
++  if (errno == EINVAL &&
++  info.array.level == 0) {
++  pr_err("Possibly your kernel 
doesn't support RAID0 layouts.\n");
++  pr_err("Either upgrade, or use 
--layout=dangerous\n");
++  }
+   goto abort_locked;
+   }
+   break;
+@@ -1046,6 +1054,9 @@ int Create(struct supertype *st, char *mddev,
+   if (ioctl(mdfd, RUN_ARRAY, )) {
+   pr_err("RUN_ARRAY failed: %s\n",
+  strerror(errno));
++  if (errno == 524 /* ENOTSUP */ &&
++  info.array.level == 0)
++  cont_err("Please use --layout=original 
or --layout=alternate\n");
+   if (info.array.chunk_size & 
(info.array.chunk_size-1)) {
+   cont_err("Problem may be that chunk 
size is not a power of 2\n");
+   }
+diff --git a/Detail.c b/Detail.c
+index 24fa462e..832485fe 100644
+--- a/Detail.c
 b/Detail.c
+@@ -525,6 +525,11 @@ int Detail(char *dev, struct context *c)
+   printf("Layout : %s\n",
+  str ? str : "-unknown-");
+   }
++  if (array.level == 0 && array.layout) {
++  str = map_num(r0layout, array.layout);
++  printf("Layout : %s\n",
++ str ? str : "-unknown-");
++  }
+   if (array.level == 6) {
+   str = map_num(r6layout, array.layout);
+   printf("Layout : %s\n",
+diff --git a/maps.c b/maps.c
+index 49b7f2c2..a4fd2797 100644
+--- a/maps.c
 b/maps.c
+@@ -73,6 +73,18 @@ mapping_t r6layout[] = {
+   { NULL, UnSet }
+ };
+ 
++/* raid0 layout is only needed because of a bug in 3.14 which changed
++ * the effective layout of raid0 arrays with varying device sizes.
++ */
++mapping_t r0layout[] = {
++  { "original", RAID0_ORIG_LAYOUT},
++  { "alternate", RAID0_ALT_MULTIZONE_LAYOUT},
++  

Bug#946017: gvfs: FTBFS on hurd-i386: Used configuration depends on unavailable libraries

[Paul Sonnenschein]

Source: gvfs
Severity: important
Version: 1.42.1-3
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hello,

with the default build options, gvfs requires systemd, fuse and other
libraries to build successfully.

The applied patch disables systemd support and libraries depending on
udev on non-linux architectures and disables some additional libraries
on the hurd.

The applied patch should not affect linux-any.

Could you take a look?

Thanks.
diff --git a/debian/rules b/debian/rules
index 08b77598..05c6ec87 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,8 +7,22 @@ include /usr/share/dpkg/default.mk
 
 ifneq (,$(filter $(DEB_HOST_ARCH), hurd-i386 kfreebsd-i386 kfreebsd-amd64))
 	ADMIN_BACKEND=-Dadmin=false
+	SYSTEMD_FLAGS= \
+		-Dsystemduserunitdir=no \
+		-Dtmpfilesdir=no \
+		-Dlogind=false \
+		-Dgudev=false \
+		-Dudisks2=false \
+		-Dcdda=false \
+		-Dgphoto2=false \
+		-Dmtp=false
 else
 	ADMIN_BACKEND=
+	SYSTEMD_FLAGS=
+endif
+
+ifeq (hurd-i386, $(DEB_HOST_ARCH))
+	HURD_FLAGS = -Dafc=false -Dfuse=false -Dlibusb=false -Dsmb=false
 endif
 
 ifeq (yes,$(shell dpkg-vendor --derives-from Ubuntu && echo yes))
@@ -23,7 +37,9 @@ override_dh_auto_configure:
 		--libexecdir=/usr/lib/gvfs \
 		-Dman=true \
 		$(ADMIN_BACKEND) \
-		$(BLURAY_BACKEND)
+		$(BLURAY_BACKEND) \
+		$(SYSTEMD_FLAGS) \
+		$(HURD_FLAGS)
 
 override_dh_auto_build:
 	dh_auto_build


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

Bug#945879: linux: slab memory leak around 30MB/hour causing OOM on OVH VPS

[Aurelien Jarno]

control: reassign -1 openssh/1:7.9p1-10+deb10u1
control: retitle -1 openssh-server: cgroup leftovers with socket activation 
when key exchange fails

On 2019-11-30 13:52, Aurelien Jarno wrote:
> Package: src:linux
> Version: 4.19.67-2+deb10u2
> Severity: important
> 
> Dear Maintainer,
> 
> Since the latest Debian stable release, I observe a slab memory leak of
> about 30MB/hour when running the kernel 4.19.67-2+deb10u2 on an OVH VPS,
> which causes an all applications to slowly move to swap after a few days,
> and eventually an OOM. You'll find a typical munin memory plot attached
> to the bug report.

[...]

> The problem has been introduced in Debian in kernel 4.19.67-1. I have
> found that the problem has been introduced upstream in the 4.19.66
> release.

It happens that the original problem is due to SSH, just that this new
kernel version makes things way more visible.

When using systemd socket activation the OpenSSH daemon sometimes does
not remove the cgroup created for the connection after the key exchange
algorithm has failed. This usually happens relatively rarely, less than
1% of the time. However on a single CPU system (e.g. VM with a single
vCPU), the problem happens 100% of the time.

To reproduce the problem using a VM:
- Reduce the number of vCPU to 1
- Switch the OpenSSH daemon to systemd socket activation using systemctl
  enable ssh.socket followed by a reboot
- Try to connect to the system with a key exchange algorithm not
  supported on buster. For example
  ssh -o KexAlgorithms=diffie-hellman-group-exchange-sha1 host
- Look at /sys/fs/cgroup/memory/system.slice/system-ssh.slice. Each
  connection leaves an entry in that directory. Each entry takes some
  kernel memory.
- Depending on the available memory and available swap, after a few
  thousands connections the OOM killer kills all the processes making
  the system unusable.

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

Bug#946016: ITP: golang-github-gorilla-csrf -- provides Cross Site Request Forgery (CSRF) prevention middleware for Go web applications & services

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-gorilla-csrf
  Version : 1.6.2-1
  Upstream Author : Gorilla Web Toolkit
* URL : https://github.com/gorilla/csrf
* License : BSD-3-clause
  Programming Lang: Go
  Description : Cross Site Request Forgery (CSRF) prevention middleware for 
Go
 gorilla/csrf is a HTTP middleware library that provides cross-site request
 forgery (CSRF) protection.  It includes:
 .
  * The csrf.Protect middleware/handler provides CSRF protection on routes
attached to a router or a sub-router.
  * A csrf.Token function that provides the token to pass into your response,
whether that be a HTML form or a JSON response body.
  * ... and a csrf.TemplateField helper that you can pass into your
html/template templates to replace a {{ .csrfField }} template tag
with a hidden input field.
 .
 gorilla/csrf is designed to work with any Go web framework, including:
 .
  * The Gorilla toolkit
  * Go's built-in net/http package
  * Goji - see the tailored fork https://github.com/goji/csrf
  * Gin
  * Echo
  * ... and any other router/framework that rallies around Go's http.Handler
interface.
 .
 gorilla/csrf is also compatible with middleware 'helper' libraries
 like Alice and Negroni.


Rationale: Needed by golang-github-alecthomas-chroma 0.6.8 and up.

Bug#945602: wrong path for constants.xml/presets.xml prevent the program from starting

[Boyuan Yang]

X-Debbugs-CC: Gürkan Myczko 

Dear Gürkan,

On Thu, 28 Nov 2019 20:50:08 + nodiscc  wrote:
> Thqnk you, is there any chance for this fix to land in Debian stable?
> Or do we have to wait for the next release (i believe it will be
> available in stable due to the high severity)

I am proposing to fix this bug in Stable via stable-proposed-updates mechanism
(https://www.debian.org/releases/proposed-updates). The full diff is as
follows. I have tested and this surely fixes Debian Bug 945602.

Please let me know if that works for you. I can help to initiate the pu
process and make upload onto p-u-new queue if everything is okay.

Thanks and looking forward to your reply.

-- 
Best,
Boyuan Yang



diff --git a/debian/changelog b/debian/changelog
index bff76ce..caab792 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qwinff (0.2.1-1+deb10u1) buster; urgency=medium
+
+  * debian/rules: Export DATA_PATH to fix crashing caused by
+incorrect file detection. (Closes: #945602)
+
+ -- Boyuan Yang   Mon, 02 Dec 2019 16:50:26 -0500
+
 qwinff (0.2.1-1) unstable; urgency=medium
 
   * Initial release. (Closes: #731153)
diff --git a/debian/rules b/debian/rules
index fef1c1c..48d906a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,6 +12,7 @@ export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 export QTDIR=/usr/share/qt5
 export QT_SELECT=qt5
+export DATA_PATH=\"/usr/share/qwinff/\"
 
 %:
dh $@


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

Bug#930526: incron creates zombie processes

[Emmanuel Bouthenot]

Hi Michael,

On Thu, Nov 28, 2019 at 12:22:19PM +0100, Michael Prokop wrote:
[...]

> Is there any ETA regarding upload towards unstable and stable from
> your side?

First, I apologize for the late reply.

I've just uploaded incron in unstable with your patch (thanks).

I've also started to prepare an uploaded for the next buster point
release. I will keep you informed.

(As you asked me I've also removed you from the Uploaders)

Regards,

-- 
Emmanuel Bouthenot
  mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
  xmpp: kol...@im.openics.org  irc: kolter@{freenode,oftc}

Bug#946015: RM: blueproximity -- RoQA; Depends on pygtk2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove blueproximity. It depends on pygtk2, which is going away, is dead
upstream and unmaintained (last upload in 2011).

Cheers,
Moritz

Bug#934876: archmage: Please port to Python 3 (and drop python-chm dep)

[Mikhail Gusarov]

Hi.

I have released an upstream 0.4.0 version of Archmage that is Python 
3.5+-compatible.


However I can't upload it to Debian at the moment, as my PGP key has 
expired, so I'm

waiting for a debian-keyring update.

The package is PAPT-maintained, so any help to upload the package is 
very welcome.


Best,
Mikhail.

Bug#882851: [PATCH] introduce LIVE_UTC=auto to auto-detect windows-installations

[Marcel Partap]

This is what I have so far and it seems to work for the limited cases I have it 
tested on.. also submitted this and another patch in the live-config repo as 
https://salsa.debian.org/live-team/live-config/merge_requests/3

Bug#945214: Workaround

[Urs Schroffenegger]

Hi,

thanks, it's exactly that! Adding the version number in the egg file 
fixed my issue also!


Merci!

u


On Mon, 02 Dec 2019 19:38:57 +0100 Patrice Duroux 
 wrote:


>
> Hi,
>
> It is may be the same bug as the one in my bug report here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945887
>
> I found a solution by editing the following file after installation:
> /usr/lib/python3/dist-packages/testpath-.egg-info
> (provided by python3-testpath)
>
> The 'Version:' field should not be an empty string and changing by the
> following:
>
> Version: 0.4.2
>
> solved my issue.
>
> Best,
> Patrice
>
>
>

Bug#882851: [PATCH] introduce LIVE_UTC=auto to auto-detect windows-installations

[Marcel Partap]

... with os-prober, if that is available
---
 components/1120-util-linux | 48 +++---
 1 file changed, 39 insertions(+), 9 deletions(-)

diff --git a/components/1120-util-linux b/components/1120-util-linux
index 8bb45e5..65aa1be 100755
--- a/components/1120-util-linux
+++ b/components/1120-util-linux
@@ -21,13 +21,21 @@ Cmdline ()
;;
esac
done
+
+   # If not explicitly given, auto-detect
+   if [ -n "${LIVE_UTC}" ]
+   then
+   LIVE_UTC="auto"
+   fi
+
 }

 Init ()
 {
# Checking if package is installed
if [ ! -e /var/lib/dpkg/info/util-linux.list ] || \
-  [ -e /var/lib/live/config/util-linux ]
+  # and wether previously configured or auto-detect mode active
+  [ -e /var/lib/live/config/util-linux -a "${LIVE_UTC}" != "auto" ]
then
exit 0
fi
@@ -39,10 +47,20 @@ Config ()
 {
rm -f /etc/rc?.d/*hwclock*

-   if [ -n "${LIVE_UTC}" ]
+   # if os-prober is installed, use it to detect windows installations
+   if [ "${LIVE_UTC}" = "auto" ] && [ -x /usr/bin/os-prober ]
then
-   case "${LIVE_UTC}" in
-   yes)
+   if os-prober | grep -qsi windows
+   then
+   LIVE_UTC=no
+   else
+   LIVE_UTC=yes
+   fi
+
+   fi
+
+   case "${LIVE_UTC}" in
+   yes)

 cat > /etc/adjtime << EOF
 0.0 0 0.0
@@ -50,19 +68,31 @@ cat > /etc/adjtime << EOF
 UTC
 EOF

-   ;;
+   ;;

-   no)
+   no)

 cat > /etc/adjtime << EOF
 0.0 0 0.0
 0
 LOCAL
 EOF
+   # prevent "System clock time unset or jumped
+   # backwards, restoring from recorded timestamp"
+   # oh Lennart
+   pgrep systemd-timesyncd && SYSD=1
+   TIMEFILE=/var/lib/systemd/timesync/clock

-   ;;
-   esac
-   fi
+   [ -e $TIMEFILE ] && rm -v $TIMEFILE
+   [ "$SYSD" = "1" ] && systemctl stop systemd-timesyncd
+
+   # tell kernel to set the timezone and
+   # reset the system clock to local time
+   hwclock --systz --localtime
+
+   [ "$SYSD" = "1" ] && systemctl start systemd-timesyncd
+   ;;
+   esac

# Creating state file
touch /var/lib/live/config/util-linux
--
2.24.0

Bug#545258: heirloom-mailx: fails to set the charset to UTF-8 in From

[Steffen Nurpmeso]

Martin-Éric Racine wrote in :
 |su 1. jouluk. 2019 klo 18.44 Paride Legovini (p...@ninthfloor.org) kirjoitti:
 |> On Sun, 06 Sep 2009  wrote:
 |>> Package: heirloom-mailx
 |>> Version: 12.4-1.1+b1
 |>> Severity: normal
 |>>
 |>> When piping text into heirloom-mailx, it fails to specify the charset \
 |>> used with
 |>> the From: line if the name inherited from /etc/passwd is in UTF-8.
 |>>
 |>> cat file | mail -s "some subject" u...@domain.ltd
 |>>
 |>> q-funk:x:1000:1000:Martin-Éric Racine,,,:/home/q-funk:/bin/bash
 |>
 |> Hello Martin-Éric,
 |>
 |> This bug is now >10 years old, so I somewhat hope it got fixed as the
 |> general adoption of UTF-8 increased in the last years. I tried to
 |> reproduce the issue you described with the latest version of s-nail in
 |> unstable (14.9.15-1), but I'm not sure I'm doing it right. The best
 |> thing would be if you could try to reproduce with a more recent version
 |> on s-nail and report back. Do you think you could give it a shot?
 |
 |All my hosts currently run the traditional bsd-mailx.

Hilko Bengen is possibly sometimes a bit difficult to get on.  If
i read the bugs' thread, he referred to sendcharsets= as the
target character set, and this is correct.  What we need to know
to get your (former) problem right is the input / source character
set.

So as long as your locale (man 7 locale) states the correct
character set (for example doing "export LC_ALL=fr_FR.utf8" in the
shell, before starting this MUA, for example), or you set the
ttycharset variable directly (it is normally derived from the
user's locale), this should just work.  (Iff conversion to
sendcharsets= is possible, iff that is necessary.)
This is true for all programs which adhere to locale(7).

(Note this MUA now supports a mime-force-sendout variable which
can be used to enforce sending out data, even if character set
conversion fails.  For unattended usage on systems which may
generate logs in whatever encoding.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#946014: ITP: pyao -- Python interface to the Audio Output library

[Jamie Wilkinson]

Package: wnpp
Severity: wishlist
Owner: Jamie Wilkinson 

* Package name: pyao
  Version : 0.82
  Upstream Author : Christian Schmitz  
* URL : http://www.xiph.org/ogg/vorbis/download/
* License : GPL-3
  Programming Lang: C
  Description : Python interface to the Audio Output library

 This module makes the libao (Audio Output) functions available
 in Python. With this module you can write Python applications
 that use the cross platform audio output library.
 
pyao was removed from the archive due to python3 incompatibility. I used it, 
and would like it to return to the archive! This upload addressds the pytbon3 
issue as well as updating the package to modern standards.

Packaging will be done on a public git repo just as soon as I have figured that 
out, and will be reflected in the control file.

Bug#945976: octave-dicom: fails to find GDCM on many architectures.

[Gianfranco Costamagna]

control: tags -1 patch


On Mon, 2 Dec 2019 00:58:19 + peter green  wrote:
> Package: octave-dicom
> Version: 0.2.2-4
> Severity: serious
> 
> octave-dicom failed to build on armel, armhf, i386 and mips64el. It seems the 
> problem was a failure to find gdcm.
> 
> > checking for GDCM... CMake Error: Problem processing arguments. Aborting.
> >
> > CMake Error: Problem processing arguments. Aborting.
> >
> > no
> > configure: WARNING: No GDCM detected using cmake - trying fallback detection
> > checking for gdcm headers path... not found
> > configure: error: Unable to find GDCM headers
> 
> This does not seem like it was a transient or random issue as the successes 
> and failures on the reproducible builds site were consistent with those in 
> Debian.
> 


and here the patch

http://launchpadlibrarian.net/453732269/octave-dicom_0.2.2-4_0.2.2-4ubuntu1.diff.gz

G.

Bug#946013: ITS: rss2email

[gustavo panizzo]

Package: rss2email
Severity: important


Hello Etienne

I intend to NMU, co-maintain, or salvage rss2email if
necessary.

My intention is at least to fix #935800 so it can enter testing again,
#944358 which is about an active upstream of rss2email and general
package maintenance (standards version, source in salsa, team
maintenance, etc)

rss2email is eligible to be salvaged due:

- no updates in 2 years besides my NMU
- 1:3.9-4.1 (NMU) was not acknowledged
- #935800 is already open for 4 months
- #944358 is already open for a month (I doesn't meet the criteria for the
  salvage process but helps me think I'm right choosing
  https://github.com/rss2email/rss2email as new upstream)

if you are there and want to keep maintaining rss2email let me know,
I'll be happy to help.

Regardless of your response, thanks for your work on rss2email, it
served me very well for years! :)

cheers

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

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

Versions of packages rss2email depends on:
ii  python3 3.7.3-1
pn  python3-feedparser  
pn  python3-html2text   

Versions of packages rss2email recommends:
ii  python3-bs4  4.7.1-1

Versions of packages rss2email suggests:
pn  esmtp  

Bug#932853: please someone "git checkout -b bullseye && git push"

[Paul Gevers]

Control: tags -1 pending

Hi,

On 24-07-2019 00:33, Tomas Pospisek wrote:
> Package: release-notes
> Severity: wishlist
> 
> I have considered forking and branching via Salsa, and then sending the
> pull request, but that's not less work. So I'm very kindly asking, if
> someone with commit rights could please do a
> 
> git checkout -b bullseye && git push
> 
> So other then can maybe start forking on that branch and sending
> patches/pull requests for already coming in bullseye changes:
> 
> #841666, #931785, #932580

I have requested [1] the webmaster-team to start building the buster
release notes from the buster branch I just created and pushed. Please
wait with making bullseye changes to the master branch until the request
is merged. I intent to upload the first changes with some clean-up,
which is hopefully helpful for the restructuring as there should be less
to restructure.

Paul

[1] https://salsa.debian.org/webmaster-team/cron/merge_requests/4



signature.asc
Description: OpenPGP digital signature

Bug#946011: python-django: CVE-2019-19118

[Salvatore Bonaccorso]

Hi Chris,

On Mon, Dec 02, 2019 at 09:30:49PM +0100, Chris Lamb wrote:
> Chris Lamb wrote:
> 
> > Package: python-django
> > Version: 1.7.11-1+deb8u7
> […]
> > CVE-2019-19118[0]:
> > | Django 2.1 before 2.1.15 and 2.2 before 2.2.8 allows unintended model
> > | editing. A Django model admin displaying inline related models, where
> > | the user has view-only permissions to a parent model but edit
> > | permissions to the inline model, would be presented with an editing
> > | UI, allowing POST requests, for updating the inline model. Directly
> > | editing the view-only parent model was not possible, but the parent
> > | model's save() method was called, triggering potential side effects,
> > | and causing pre and post-save signal handlers to be invoked. (To
> > | resolve this, the Django admin is adjusted to require edit permissions
> > | on the parent model in order for inline models to be editable.)
> 
> Security team, would you like an upload for stable?

As far I can see this issue has been introduced around 2.1 where the
surch support for view permissions and a read-only admin support was
added. Before that the issue does not seem to be present and as such
not affecting buster, nor stretch or older.

I have updated this bug with some metadata with that regard. Can you
confirm this assessment?

Regards,
Salvatore

Bug#941198: please postpone until after the GR

[Russ Allbery]

Ansgar  writes:

> That would make any init system in Debian a wrapper around starting
> sysvinit script which seems a bit boring and blocking any innovation to
> me. Though I think it might be close to what runit or OpenRC support
> currently means in Debian.

I don't believe this is the approach being taken by runit.  They've
introduced a handful of *-run packages to start as daemon with runit
instead, and I think some other packages just ship the runit integration
directly in the package.

If runit works the way that I believe that it does, it will similarly do
much better with dedicated configuration than with trying to run sysvinit
scripts for some of the same reasons as systemd.  For instance, it would
much prefer if services didn't background themselves and instead stayed in
the foreground so that they could be more easily monitored.

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

Bug#945883: python-urllib3: Update python3-urllib3 on unstable

[Daniele Tricoli]

On Sat, Nov 30, 2019 at 11:34:20AM -0300, Emmanuel Arias wrote:
> Package: python-urllib3
> Version: 1.19.1-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I am working on update elasticsearch-curator, and this package need
> urllib3 >= 1.24.2. Currently the version 1.25.6 is on experimental
> is there some  possiblity to move it to unstable, please?

Hello Emmanuel,
yes, I will upload soon (working on urllib3 1.25.7 right now). Thanks for your
patience.

Cheers,

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org

Bug#946012: pyosmium unsatisfiable cross Build-Depends

[Helmut Grohne]

Source: pyosmium
Version: 2.15.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

pyosmium cannot satisfy its cross Build-Depends. There are multiple
reasons for that. The ones reported by botch[1] are mainly sphinx and
mock, but also shapely.

The sphinx dependencies are only required for building the arch:all
documentation package. Thus they can be moved to Build-Depends-Indep and
become irrelevant to cross building.

mock and nose are test dependencies and can be made optional using the
nocheck profile.

I have less clue about shapely. I couldn't identify the actual use. Is
it really needed?

The attached patch implements the reductions for sphinx and mock. I used
reproducible builds and diffoscope to verify that these really are
correct. Please consider applying the patch and close this bug when
doing so.

Helmut

[1] The problem is only visible *before* fixing it at:
https://bootstrap.debian.net/cross_all/pyosmium.html
diff --minimal -Nru pyosmium-2.15.3/debian/changelog 
pyosmium-2.15.3/debian/changelog
--- pyosmium-2.15.3/debian/changelog2019-08-17 08:39:20.0 +0200
+++ pyosmium-2.15.3/debian/changelog2019-12-02 17:00:55.0 +0100
@@ -1,3 +1,12 @@
+pyosmium (2.15.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce build dependencies for cross building. (Closes: #-1)
++ Move sphinx dependencies to Build-Depends-Indep.
++ Annotate test dependencies with .
+
+ -- Helmut Grohne   Mon, 02 Dec 2019 17:00:55 +0100
+
 pyosmium (2.15.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru pyosmium-2.15.3/debian/control 
pyosmium-2.15.3/debian/control
--- pyosmium-2.15.3/debian/control  2019-08-17 08:39:20.0 +0200
+++ pyosmium-2.15.3/debian/control  2019-12-02 17:00:55.0 +0100
@@ -16,9 +16,10 @@
pybind11-dev,
python3-all-dev,
python3-setuptools,
-   python3-mock,
-   python3-nose,
+   python3-mock ,
+   python3-nose ,
python3-shapely,
+Build-Depends-Indep:
python3-sphinx,
python3-sphinxcontrib.autoprogram
 Standards-Version: 4.4.0

Bug#942056: [ovs-dev] [PATCH] debian: Update list of copyright holders.

[Ben Pfaff]

On Wed, Nov 27, 2019 at 10:25:36AM -0800, Yi-Hung Wei wrote:
> On Wed, Oct 9, 2019 at 10:35 AM Ben Pfaff  wrote:
> >
> > The list of copyright holders was incomplete and out of date.  This
> > updates it based on a "grep" for copyright notices, which I reviewed by
> > hand.
> >
> > CC: 942...@bugs.debian.org
> > Reported-by: Chris Lamb 
> > Reported-at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942056
> > Signed-off-by: Ben Pfaff 
> > ---
> 
> LGTM.
> 
> Acked-by: Yi-Hung Wei 

Thanks, applied to master.

Bug#944417: transition: cgal

[Paul Gevers]

Control: tags -1 moreinfo

Hi Joachim,

On 15-11-2019 17:27, Joachim Reichel wrote:
> crrcsimneeds source code changes, patch available
[...]
> k3dneeds source code changes, patch available
[...]
> openscad   needs source code changes, patch available
> pgrouting  needs source code changes, patch available
[...]
> rheolefneeds source code changes, patch available, unrelated FTBFS,
> sfcgal needs source code changes, patch available
> yade   needs source code changes, patch available

Have those patches been submitted to the BTS? Are the maintainers of
these packages aware of this? Are the changes trivial and are you ready
to NMU them (except rheolef)?

Paul

Bug#946011: python-django: CVE-2019-19118

[Chris Lamb]

Chris Lamb wrote:

> Package: python-django
> Version: 1.7.11-1+deb8u7
[…]
> CVE-2019-19118[0]:
> | Django 2.1 before 2.1.15 and 2.2 before 2.2.8 allows unintended model
> | editing. A Django model admin displaying inline related models, where
> | the user has view-only permissions to a parent model but edit
> | permissions to the inline model, would be presented with an editing
> | UI, allowing POST requests, for updating the inline model. Directly
> | editing the view-only parent model was not possible, but the parent
> | model's save() method was called, triggering potential side effects,
> | and causing pre and post-save signal handlers to be invoked. (To
> | resolve this, the Django admin is adjusted to require edit permissions
> | on the parent model in order for inline models to be editable.)

Security team, would you like an upload for stable?


Regards,

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

Bug#946011: python-django: CVE-2019-19118

[Chris Lamb]

Package: python-django
Version: 1.7.11-1+deb8u7
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for python-django.

CVE-2019-19118[0]:
| Django 2.1 before 2.1.15 and 2.2 before 2.2.8 allows unintended model
| editing. A Django model admin displaying inline related models, where
| the user has view-only permissions to a parent model but edit
| permissions to the inline model, would be presented with an editing
| UI, allowing POST requests, for updating the inline model. Directly
| editing the view-only parent model was not possible, but the parent
| model's save() method was called, triggering potential side effects,
| and causing pre and post-save signal handlers to be invoked. (To
| resolve this, the Django admin is adjusted to require edit permissions
| on the parent model in order for inline models to be editable.)


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-2019-19118
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19118


Regards,

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

Bug#945994: dgit-maint-merge(7) should talk about pushing to salsa

[Sean Whitton]

control: tag -1 +patch

Hello Matthew,

On Mon 02 Dec 2019 at 04:50PM +00, Matthew Vernon wrote:

> On 02/12/2019 15:52, Sean Whitton wrote:
>
>>> The various setup sections do describe e.g.
>>>% git push --follow-tags -u origin master
>
>> Actually, the '-u' in that command alters your .git/config such that a
>> subsequent plain `git push` will push master to salsa.
>
> Yes, but unless I am terminally confused about git, if I want to be
> pushing two branches (e.g. upstream and master) then this doesn't DWIW?

Ah, indeed.  In the case where you are forced to maintain an upstream
branch on salsa (the case where upstream releases only tarballs), `git
push` alone will not be sufficient.

If there is a way to configure git to always push both master and
upstream to salsa when you type `git push` from one of those branches,
and not push anything to other remotes, the manpage could document how
to do that.  I'm not sure that it's actually possible to do this.

(I think that setting remote.origin.push so that master and upstream get
pushed to salsa if you type `git push origin` is not much of an
improvement over `git push origin master upstream`?)

However, I don't think this should be recommended strongly by the
manpage.  I think that it would be quite unusual to configure git such
that a plain `git push` would push more than one branch, such that it
would be surprising to most git users for git ever to do that.

We should have mention of pushing 'master' (and 'upstream' if you have
it) to salsa, in the "BUILDING & UPLOADING" section, probably in prose
form.

> Ah, yes, that might be a problem. But, for example, I will always want
> to push these tags to salsa, so maybe something on a per-remote basis?

It doesn't look like it can be set per-remote.

I think that it would be good to mention the push.followTags setting as
something the user might want to set, without strongly recommending it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#943327: mmdebstrap: Please support using pixz

[Johannes Schauer]

Hi,

Quoting Benjamin Drung (2019-12-02 14:59:28)
> > fixed in git:
> > 
> > https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/9f2ea61265c36945b1fbbc27fd70099e58df794d
> 
> That commit does not work for me:
> 
> $ ./mmdebstrap -v buster buster.tar.xz
> I: automatically chosen mode: unshare
> I: chroot architecture amd64 is equal to the host's architecture
> Can't exec "--threads=0": No such file or directory at ./mmdebstrap line 2303.
> E: cannot exec --threads=0: No such file or directory
> E: failed to start --threads=0

wow, the one time that I don't write a test case for a new feature and of
course it keeps failing. I wonder what went wrong. Probably I was accidentally
running my system's installed mmdebstrap instead of the git version when
testing my changes.

I now added a test case to make sure that this cannot break again.

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/d262d678775ec6b270bcffaef4c5d4835ea1cd20

Thanks a lot for testing it!

cheers, josch


signature.asc
Description: signature

Bug#946010: kwartz-client: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: kwartz-client 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of kwartz-client
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#946009: ldh-gui-suite: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: ldh-gui-suite 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of ldh-gui-suite
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#946008: rpki-trust-anchors: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: rpki-trust-anchors 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of rpki-trust-
anchors debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#946007: pwman3: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: pwman3 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of pwman3 debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#946006: mandos: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: mandos 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of mandos debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#945993: diffoscope: FAILED tests/test_source.py::test_code_is_black_clean - assert 228381 == 0

[Julien Cristau]

On Mon, Dec 02, 2019 at 07:37:02PM +, Chris Lamb wrote:
> Hi Julien,
> 
> > It seems to me the test is inherently extremely sensitive to the exact
> > version of black used, so it probably shouldn't be part of autopkgtests?
> 
> Mmm, except I anticipated this at the time with the following
> commit:
> 
>   
> https://salsa.debian.org/reproducible-builds/diffoscope/commit/aefa5a39bb5f86f21cb67f94a013aa2c9bc4b69d
> 
> At a quick guess, I think this is problem caused by the autopkgtests
> being run without the pyproject.toml. As in:
> 
> --- a/debian/tests/pytest
> +++ b/debian/tests/pytest
> @@ -14,7 +14,7 @@ fi
> 
>  for py in $(py3versions -s); do
>  echo " Running against $py"
> -cp -r tests "$AUTOPKGTEST_TMP"
> +cp -r tests pyproject.toml "$AUTOPKGTEST_TMP"
>  (cd "$AUTOPKGTEST_TMP"; "$py" -m pytest -vv -l -r a)
>  rm -rf "${AUTOPKGTEST_TMP:?}"/*
>  done
> 
> … will likely fix this.
> 
> 
Aha.  Thanks for the quick reply and fix!

Cheers,
Julien

Bug#946005: librabbitmq: CVE-2019-18609

[Salvatore Bonaccorso]

Source: librabbitmq
Version: 0.9.0-0.2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for librabbitmq.

CVE-2019-18609[0]:
| An issue was discovered in amqp_handle_input in amqp_connection.c in
| rabbitmq-c 0.9.0. There is an integer overflow that leads to heap
| memory corruption in the handling of CONNECTION_STATE_HEADER. A rogue
| server could return a malicious frame header that leads to a smaller
| target_size value than needed. This condition is then carried on to a
| memcpy function that copies too much data into a heap buffer.


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-2019-18609
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18609
[1] 
https://github.com/alanxz/rabbitmq-c/commit/fc85be7123050b91b054e45b91c78d3241a5047a

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#945993: diffoscope: FAILED tests/test_source.py::test_code_is_black_clean - assert 228381 == 0

[Chris Lamb]

Hi Julien,

> It seems to me the test is inherently extremely sensitive to the exact
> version of black used, so it probably shouldn't be part of autopkgtests?

Mmm, except I anticipated this at the time with the following
commit:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/aefa5a39bb5f86f21cb67f94a013aa2c9bc4b69d

At a quick guess, I think this is problem caused by the autopkgtests
being run without the pyproject.toml. As in:

--- a/debian/tests/pytest
+++ b/debian/tests/pytest
@@ -14,7 +14,7 @@ fi

 for py in $(py3versions -s); do
 echo " Running against $py"
-cp -r tests "$AUTOPKGTEST_TMP"
+cp -r tests pyproject.toml "$AUTOPKGTEST_TMP"
 (cd "$AUTOPKGTEST_TMP"; "$py" -m pytest -vv -l -r a)
 rm -rf "${AUTOPKGTEST_TMP:?}"/*
 done

… will likely fix this.


Regards,

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

Bug#946004: satpy: autopkgtest failures

[Sebastiaan Couwenberg]

Control: tags -1 ftbfs

On 12/2/19 7:36 PM, Bas Couwenberg wrote:
> The autopkgtest for your package are failing which block testing migration of 
> its dependencies.
> 
> The log shows:
> 
>  ==
>  FAIL: test_reflectance_corrector_abi 
> (satpy.tests.compositor_tests.test_viirs.TestVIIRSComposites)
>  --
>  Traceback (most recent call last):
>File 
> "/usr/lib/python3/dist-packages/satpy/tests/compositor_tests/test_viirs.py", 
> line 309, in test_reflectance_corrector_abi
>  self.assertLess(abs(np.mean(data) - 29.907390988422513), 1e-10)
>  AssertionError: nan not less than 1e-10
>  
>  --
> 
> See: 
> https://ci.debian.net/data/autopkgtest/testing/amd64/s/satpy/3561116/log.gz

The same test failure also causes the package to FTBFS in unstable.

Kind Regards,

Bas

Bug#946003: pyresample: autopkgtest failures

[Sebastiaan Couwenberg]

Control: tags -1 ftbfs

On 12/2/19 7:34 PM, Bas Couwenberg wrote:
> The autopkgtest for your package are failing which block testing migration of 
> its dependencies.
> 
> The log shows:
> 
>  ==
>  FAIL: test_custom (pyresample.test.test_kd_tree.Test)
>  --
>  Traceback (most recent call last):
>File "/usr/lib/python3/dist-packages/pyresample/test/test_kd_tree.py", 
> line 427, in test_custom
>  self.assertFalse(len(w) != 1)
>  AssertionError: True is not false
>  
>  --
> 
> See: 
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyresample/3561115/log.gz

The same test failure also causes the package to FTBFS in unstable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#945878: python-pcl: FTBFS on arm64 and ppc64el

[Jochen Sprickerhof]

Control: reassign -1 libopenni2
Control: retitle -1 libopenni2: uses too much TLS memory on arm64 and ppc64el
Control: affects -1 python-pcl

Hi,

* Graham Inggs  [2019-11-30 13:49]:

Recent builds of python-pcl have been failing on arm64 and ppc64el
[1][2], where it built previously.



line 2, in 
   from ._pcl import *
ImportError: /usr/lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate
memory in static TLS block


Looks like one of the linked libraries uses more TLS memory then before. 
It's hard to debug which one changed but libopenni2 uses a lot without 
needing it. As I'm maintaining that one as well, I've added a patch to 
it to use less. Reassigning accordingly and let's hope it solves the 
problem.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#942282: O: php-horde-core -- Core Horde Framework library (AND all php-horde*!)

[Mike Gabriel]

Hi Juri, hi Mathieu,

On  Do 28 Nov 2019 23:18:16 CET, debian wrote:


Hello Mike,

with this manual
https://salsa.debian.org/horde-team/tools/blob/master/README.md

I was successfully building horde packages 6 months ago.
If you want, you can add me to horde team.

Best Regards,
Juri Grabowski


Ah, thanks. Wasn't aware of that README. Will take a look at possibly  
adopt the whole set of horde packages.


Greets,
Mike
--

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

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



pgp_oZckk0Zak.pgp
Description: Digitale PGP-Signatur

Bug#945214: Workaround

[Patrice Duroux]

Hi,

It is may be the same bug as the one in my bug report here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945887

I found a solution by editing the following file after installation:
/usr/lib/python3/dist-packages/testpath-.egg-info
(provided by python3-testpath)

The 'Version:' field should not be an empty string and changing by the
following:

Version: 0.4.2

solved my issue.

Best,
Patrice

Bug#946003: pyresample: autopkgtest failures

[Bas Couwenberg]

Source: pyresample
Version: 1.13.2-1
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The autopkgtest for your package are failing which block testing migration of 
its dependencies.

The log shows:

 ==
 FAIL: test_custom (pyresample.test.test_kd_tree.Test)
 --
 Traceback (most recent call last):
   File "/usr/lib/python3/dist-packages/pyresample/test/test_kd_tree.py", line 
427, in test_custom
 self.assertFalse(len(w) != 1)
 AssertionError: True is not false
 
 --

See: 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyresample/3561115/log.gz

Kind Regards,

Bas

Bug#946004: satpy: autopkgtest failures

[Bas Couwenberg]

Source: satpy
Version: 0.16.1-4
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The autopkgtest for your package are failing which block testing migration of 
its dependencies.

The log shows:

 ==
 FAIL: test_reflectance_corrector_abi 
(satpy.tests.compositor_tests.test_viirs.TestVIIRSComposites)
 --
 Traceback (most recent call last):
   File 
"/usr/lib/python3/dist-packages/satpy/tests/compositor_tests/test_viirs.py", 
line 309, in test_reflectance_corrector_abi
 self.assertLess(abs(np.mean(data) - 29.907390988422513), 1e-10)
 AssertionError: nan not less than 1e-10
 
 --

See: https://ci.debian.net/data/autopkgtest/testing/amd64/s/satpy/3561116/log.gz

Kind Regards,

Bas

Bug#905394: spyder-kernels: Please clarify why you disable the testsuite

[Drew Parsons]

Source: spyder-kernels
Followup-For: Bug #905394


In 1.8.0 build-time tests give an error:

___ ERROR collecting 
projects/python/build/spyder-kernels/.pybuild/cpython3_3.8_spyder-kernels/build/spyder_kernels/utils/test_utils.py
 ___
spyder_kernels/utils/test_utils.py:11: in 
from jupyter_client import session as ss
/usr/lib/python3/dist-packages/jupyter_client/__init__.py:4: in 
from .connect import *
/usr/lib/python3/dist-packages/jupyter_client/connect.py:24: in 
import zmq
/usr/lib/python3/dist-packages/zmq/__init__.py:47: in 
from zmq import backend
/usr/lib/python3/dist-packages/zmq/backend/__init__.py:40: in 
reraise(*exc_info)
/usr/lib/python3/dist-packages/zmq/utils/sixcerpt.py:34: in reraise
raise value
/usr/lib/python3/dist-packages/zmq/backend/__init__.py:27: in 
_ns = select_backend(first)
/usr/lib/python3/dist-packages/zmq/backend/select.py:27: in select_backend
mod = __import__(name, fromlist=public_api)
/usr/lib/python3/dist-packages/zmq/backend/cython/__init__.py:6: in 
from . import (constants, error, message, context,
E   ImportError: cannot import name 'constants' from partially initialized 
module 'zmq.backend.cython' (most likely due to a circular import) 
(/usr/lib/python3/dist-packages/zmq/backend/cython/__init__.py)



Looks like the pyzmq package would need to be upgraded or fixed before
tests can be switched on.



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

Bug#946002: git-buildpackage: import-orig into current branch or warn if current branch is not master

[Drew Parsons]

Package: git-buildpackage
Version: 0.9.17
Severity: normal

A common workflow using gbp is to import-orig into an experimental
branch when upgrading a package to a new version. The upgrade can be
pushed to experimental before releasing to sid.

By default gbp imports into the master branch. Importing elsewhere
needs to be specified explicitly with the --debian-branch option.

However, if you're working in an experimental branch and run gbp
import-orig, it silently imports into the master branch.  This breaks
expectations, you might not realise the import went wrong until you try
to build and wonder why it complains and fails.

import-orig should either import into the current branch
(experimental, master or otherwise),
or else it should refuse to import if the current branch is not master
and provide a warning message (if --debian-branch is not given)



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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.19.7
ii  git1:2.24.0-1
ii  man-db 2.9.0-1
ii  python33.7.5-3
ii  python3-dateutil   2.7.3-3
ii  python3-pkg-resources  41.4.0-1
ii  sensible-utils 0.0.12+nmu1

Versions of packages git-buildpackage recommends:
ii  pbuilder  0.230.4
ii  pristine-tar  1.47
ii  python3-requests  2.21.0-1
ii  sbuild0.78.1-2

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-3
ii  sudo 1.8.29-1
ii  unzip6.0-25

-- no debconf information

Bug#943042: gitso: Python2 removal in sid/bullseye

[Scott Talbert]

On Wed, 23 Oct 2019, mo...@debian.org wrote:


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 (the specific reason can be found searching this
source package in
https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ).
Please stop using Python2, and fix this issue by one of the following
actions.

- Convert your Package to Python3. This is the preferred option.  In
 case you are providing a Python module foo, please consider dropping
 the python-foo package, and only build a python3-foo package.  Please
 don't drop Python2 modules, which still have reverse dependencies,
 just document them.

 This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
 in Debian, it should be removed from the distribution.  If the
 package still has reverse dependencies, raise the severity to
 "serious" and document the reverse dependencies with the BTS affects
 command.  If the package has no reverse dependencies, confirm that
 the package can be removed, reassign this issue to ftp.debian.org,
 make sure that the bug priority is set to normal and retitle the
 issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
 build another package which cannot be removed, document that by
 adding the "py2keep" user tag (not replacing the py2remove tag),
 using the debian-pyt...@lists.debian.org user.  Also any
 dependencies on an unversioned python package (python, python-dev)
 must not be used, same with the python shebang.  These have to be
 replaced by python2/python2.7 dependencies and shebang.

 This is the least preferred option.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.


Hi Florian,

Do you have any plans to port gitso to Python 3?

If not, I will probably just convert this to an RM request as it seems 
gitso is unmaintained upstream for many years.


Thanks,
Scott

Bug#937061: Python3 Port of ModelBuilder

[Scott Talbert]

On Tue, 8 Oct 2019, Andreas Tille wrote:


Hi Flávio,

Varun Hiremath once cared for Debian packages of ModelBuilder[1].  His
effort seemed to have been stalled and so Debian remained at version
0.4.1.  In the process of migrating all Debian packages from Python2 to
Python3 I stumbled upon this package and moved under Debian Science
team maintenance[2].

I realised that version 0.4.6 need a Python module BIP[3].  (BTW, as a
general remark: It would be nice if you would keep release tags in sync
with PyPI.)  Since BIP is not packaged for Debian I would consider doing
so - but only Python3 modules are permitted to go into Debian.  Since
I'm not sure whether I will reach my original goal to get ModelBuilder
converted to Python3 succesfully I wonder whether you can uncover some
plan you might have with ModelBuilder whether you want to port it
yourself do Python3.


Hi Andreas,

Do you (or Flavio) plan on porting model-builder to Python 3?

If not, I will probably just convert this to an RM request as it seems 
model-builder is unmaintained upstream (and downstream).


Thanks,
Scott

Bug#946001: ITP: golang-github-alecthomas-kong-hcl -- A Kong configuration loader for HCL

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-alecthomas-kong-hcl
  Version : 0.2.0-1
  Upstream Author : Alec Thomas
* URL : https://github.com/alecthomas/kong-hcl
* License : Expat
  Programming Lang: Go
  Description : A Kong configuration loader for HCL (Go library)
 github.com/alecthomas/kong-hcl is a Kong configuration loader for HCL
 implemented for the Go programming language.
 .
 It may be used like so:
 .
 var cli struct {
 Config kong.ConfigFlag `help:"Load configuration."`
 }
 parser, err := kong.New(, kong.Configuration(konghcl.Loader,
 "/etc/myapp/config.hcl", "~/.myapp.hcl))

Rationale:
* Needed by golang-github-alecthomas-chroma-dev and chroma 0.6.8,
  and in turn by Hugo 0.59.

Bug#945994: dgit-maint-merge(7) should talk about pushing to salsa [EXT]

[Matthew Vernon]

On 02/12/2019 15:52, Sean Whitton wrote:

>> The various setup sections do describe e.g.
>>% git push --follow-tags -u origin master

> Actually, the '-u' in that command alters your .git/config such that a
> subsequent plain `git push` will push master to salsa.

Yes, but unless I am terminally confused about git, if I want to be
pushing two branches (e.g. upstream and master) then this doesn't DWIW?

> --follow-tags does need a separate git config option, which could be
> added, but it might be too much automation.  The potential problem is
> that you can accidentally push debian/foo tags to a remote other than
> salsa, such as upstream's git repo, if you happen to have push access to
> that (I've managed to do this before, though I think it was with
> --tags).  What do you think about this risk?

Ah, yes, that might be a problem. But, for example, I will always want
to push these tags to salsa, so maybe something on a per-remote basis?

> Were you looking for anything beyond these two things?

No.

Regards,

Matthew




signature.asc
Description: OpenPGP digital signature

Bug#945214: Workaround

[Urs Schroffenegger]

Hi,

I also ran into this bug after updating my machines during the weekend, 
both machines run on Debian Sid.


The issue appeared with some "pip3 install XXX", but is also present on 
simple "pip3 list"


I thought it was an issue with Debian shifting to Python 3.8, so I tried 
to reinstall a whole bunch of packages of Python 3.7, following the 
dependencies. This didn't change anything. After that, I decided to take 
the plunge and actually look at the stack trace. python-wheels wasn't to 
interesting, but then, I thought it looked like an issue of listing the 
version of the package, so it might not be an issue of python or pip, 
but an issue of a package. So I tried to print the package name it was 
working on.


Adding

print(proj.project_name)

in /usr/lib/python3/dist-packages/pip/_internal/commands/list.py, at 
line275 (just before the 'row = [proj.project_name, proj.version]' 
line), printed a whole list of packages.


The last name was testpath. I uninstalled python3-testpath (and 
incidentaly a whole bunch of packages depending on it), and now, I can 
'pip3 list' and 'pip3 install' again.


Now, I have to get my environment to work again after uninstalling all 
jupyter notebook.


So I don't know how pip works internally and this work is some blind 
guessing to get my system to work again, but maybe it can give a clue to 
the maintainer to help debug this, and probably forward the issue to the 
correct package?


Cheers,

u

Bug#794969: udev: change in network device naming scheme unnecessarily and incorrectly renames WiMAX devices

[Michael Biebl]

Control: tags -1 + moreinfo


Hi

On Mon, 10 Aug 2015 23:25:36 + "brian m. carlson"
 wrote:
> On Sun, Aug 09, 2015 at 05:54:29PM +0200, Marco d'Itri wrote:
> > On Aug 08, "brian m. carlson"  wrote:
> > 
> > > Previously, my WiMAX device was named something like wmx0.  Now, it
> > > appears it's been renamed to enx.  First of all, the name
> > > has changed from what it used to be, and now I have to check that it's
> > > not broken anything.  There wasn't supposed to be a naming change for
> > > people with the persistent-net rules in place.
> > Indeed: what was the content of your 70-persistent-net.rules file?
> > I suspect that persistent naming just never worked for you for this
> > interface.
> 
> The interface is clearly missing:
> 
>   # PCI device 0x8086:/sys/devices/pci:00/:00:19.0 (e1000e)
>   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
> ATTR{address}=="f0:de:f1:b8:36:fd", ATTR{dev_id}=="0x0", ATTR{type}=="1", 
> KERNEL=="eth*", NAME="eth0"
>   
>   # PCI device 0x8086:/sys/devices/pci:00/:00:1c.1/:03:00.0 
> (iwlwifi)
>   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
> ATTR{address}=="64:80:99:4f:73:a0", ATTR{dev_id}=="0x0", ATTR{type}=="1", 
> KERNEL=="wlan*", NAME="wlan0"
> 
> I suppose the idea was to skip USB devices, thinking that they were all
> removable, but I can't be certain without seeing the generator, which
> has been removed.
> 
> > > Secondly, this is not an Ethernet device, so en is not correct (it
> > > should be ww).  The device is on the USB bus (using the driver
> > > i2400m-usb).
> > I do not think that such a distinction is relevant here.
> 
> If you're going to autogenerate the name, please autogenerate it such
> that it's consistent with the naming scheme.  The comment in
> udev-builtin-net_id.c indicates that ww is appropriate here.  People
> should be able to predict interface names, such that configuration can
> be autogenerated (e.g. for puppet).  Naming some WWAN devices as ww but
> others as en is silly.


Is this issue still valid?
I do have an (internal) wimax device which is named wwx02803X, i.e.
has the ww prefix as one would expect.

If it's still a problem, please attach the output of
udevadm info /sys/class/net/$(iface)

Thanks,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#946000: slic3r-prusa: New Upstream 2.1.0

[Matthias Urlichs]

Package: slic3r-prusa
Version: 1.x
Severity: normal

Please package 2.1.0. Alternately I'll gladly prepare an NMU or whatever.

Upgrading to 2.1 is not "wishlist" because the newer printers, esp. the MMS
add-on, require a 2.x slicer.

-- 
-- Matthias Urlichs (smurf@debian)

Bug#945999: ITP: regexpp -- regular expression parser for ECMAScript - Node.js library

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : node-regexpp
  Version  : 2.0.1
  Upstream Author  : Toru Nagashima 
* Url  : https://github.com/mysticatea/regexpp
* Licenses : Expat
  Section  : javascript

 regexpp is an ECMAScript (a.k.a. JavaScript) module
 for parsing ECMAScript code using regular expressions.
 .
 This package provides functional-red-black-tree
 for use with Node.js -
 an event-based server-side JavaScript engine.

This package is needed for newer releases of ESLint.

I plan to maintain this package in the JavaScript team, keeping 
debianization in following Git repository:

 https://salsa.debian.org/js-team/node-regexpp.git

 - 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#945998: ITP: golang-github-niklasfasching-go-org -- Org mode parser with HTML & pretty-printed Org rendering

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-niklasfasching-go-org
  Version : 0.1.8-1
  Upstream Author : Niklas Fasching
* URL : https://github.com/niklasfasching/go-org
* License : Expat
  Programming Lang: Go
  Description : Org mode parser with HTML & pretty-printed Org rendering
 github.com/niklasfasching/go-org an Org mode parser written in Go.
 .
 Take a look at https://niklasfasching.github.io/go-org/ for some examples
 and an online Org → HTML demo (Wasm based).
 .
 Please note that the goal for the HTML export is to produce sensible HTML
 output, not to exactly reproduce output the output of org-html-export.

Binary packages:
 * golang-github-niklasfasching-go-org-dev
 * go-org

Rationale:
 * golang-github-niklasfasching-go-org-dev is needed by hugo 0.59 and up.

Bug#945994: dgit-maint-merge(7) should talk about pushing to salsa

[Sean Whitton]

Hello Matthew,

On Mon 02 Dec 2019 at 02:07PM +00, Matthew Vernon wrote:

> It would be nice if dgit-maint-merge(7) provided more advice on
> pushing to salsa, specifically:
>
> The various setup sections do describe e.g.
>% git push --follow-tags -u origin master
>
> ...and while this is nice, it should (I think) be possible to provide
> git config runes so that git push does what you wanted by default -
> git-push(1) alludes to this:
>
> When the command line does not specify what to push with ...
> arguments or --all, --mirror, --tags options, the command finds the
> default  by consulting remote.*.push configuration

Actually, the '-u' in that command alters your .git/config such that a
subsequent plain `git push` will push master to salsa.

--follow-tags does need a separate git config option, which could be
added, but it might be too much automation.  The potential problem is
that you can accidentally push debian/foo tags to a remote other than
salsa, such as upstream's git repo, if you happen to have push access to
that (I've managed to do this before, though I think it was with
--tags).  What do you think about this risk?

Were you looking for anything beyond these two things?

> BUILDING AND UPLOADING should also mention pushing to salsa

Yes.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#925749: Bug#936888: liblemon: ftbfs with GCC-9

[Michael Crusoe]

A future Seqan3 release will need liblemon, so I'll look into it.

On Mon, Dec 2, 2019 at 12:36 PM Andreas Tille  wrote:

> Control: tags -1 help
>
> Hi,
>
> I wonder if there might be some remaining interest in liblemon.  The
> Debian Med team who introduced it into Debian does not need it any more
> for any of its packages.  It seems it us orphaned upstream.  I'd be
> willing to keep the package alive if someone might provide a patch for
>
>/<>/liblemon-1.3.1+dfsg/lemon/maps.h:193:36: error: non-type
> template parameters of class type only available with '-std=c++2a' or
> '-std=gnu++2a'
>
> as reported in bug #925749 but otherwise I'll ask ftpmaster for removal.
>
> Kind regards
>
>Andreas.
>
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe

Bug#944242: Test issues with BioPython 1.75

[Peter Cock]

There are indeed a LOT of errors in there (and a sprinkling of
harmless warnings which ought really to be silenced within the test
framework).

Picking on the very last one as a simple case, you got:

```
==
FAIL: test_ColumnUnit (test_psw.TestPSW)
--
Traceback (most recent call last):
  File "/tmp/python-biopython-test.HGclMQ/Tests/test_psw.py", line 75,
in test_ColumnUnit
"ColumnUnit(unit=0, column=33, SEQUENCE)")
AssertionError: "ColumnUnit(unit=0, column=33, kind='SEQUENCE')" !=
'ColumnUnit(unit=0, column=33, SEQUENCE)'
- ColumnUnit(unit=0, column=33, kind='SEQUENCE')
?   ---
+ ColumnUnit(unit=0, column=33, SEQUENCE)
```

This change relates to adding __repr__ to some of the PSW objects,

https://github.com/biopython/biopython/commit/37f235066616c950a6b4b5544785a5c4a88f1ea1

This was included in Biopython 1.74 and 1.75, yet your copy of Tests/test_psw.py
would seem to date from Biopython 1.73 or older.

I suspect an old cached copy of the test folder is largely to blame?

Peter

On Mon, Dec 2, 2019 at 3:28 PM Andreas Tille  wrote:
>
> Hi Peter,
>
> On Wed, Nov 20, 2019 at 01:36:50PM +0100, Andreas Tille wrote:
> > >
> > > https://github.com/biopython/biopython/issues/2350
>
> Since I urgently need Biopython >= 1.74 to fix some other bugs I decided
> to try to ignore those issues we discussed here and made sure that build
> time tests will not fail.  However the Debian package is also running a
> Continuous Integration test (autopkgtest in Debian terminology).  The
> test for biopython is basically copying the test files to a temporary dir
> and execute the tests[1].
>
> In the attached log I injected a `set -x` and was running:
>
>sh run-unit-test 2>&1 | tee > tes_suite_errors.out
>
> Unfortunately there are more errors than I expected.  Do you have any
> idea why?
>
> Kind regards
>
>  Andreas.
>
>
> [1] 
> https://salsa.debian.org/med-team/python-biopython/blob/master/debian/tests/run-unit-test
>
> --
> http://fam-tille.de

Bug#945997: qemu: Build qemu-utils, qemu-guest-agent and qemu-block-extra on hppa arch

[Helge Deller]

Last patch was buggy.
Attached is an updated patch.
diff -up ./debian/control.org ./debian/control
--- ./debian/control.org	2019-12-02 14:45:49.932801743 +0100
+++ ./debian/control	2019-12-02 16:37:31.023439932 +0100
@@ -166,7 +166,7 @@ Description: QEMU full system emulation
  QEMU supports.
 
 Package: qemu-block-extra
-Architecture: amd64 arm arm64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64 x32
+Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64 x32
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends},
 Enhances: qemu-utils, qemu-system-misc,
@@ -428,7 +428,7 @@ Description: QEMU user mode binfmt regis
  at install and remove times.
 
 Package: qemu-utils
-Architecture: amd64 arm arm64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64 x32
+Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64 x32
 Multi-Arch: foreign
 Breaks: qemu-system-common (<< 1:3.1+dfsg-3~)
 Depends: ${shlibs:Depends}, ${misc:Depends}
diff -up ./debian/rules.org ./debian/rules
--- ./debian/rules.org	2019-12-02 14:45:26.864895280 +0100
+++ ./debian/rules	2019-12-02 16:25:58.014085044 +0100
@@ -53,6 +53,11 @@ ifneq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST
 common_configure_opts  += --cross-prefix=$(DEB_HOST_GNU_TYPE)-
 endif
 
+# allow configure to build native qemu packages like qemu-utils and qemu-block-extra
+ifeq ($(DEB_TARGET_ARCH), hppa)
+common_configure_opts += --enable-tcg-interpreter
+endif
+
 ifeq (${enable_system},enable)
 
 # list of system (softmmu) targets, from ./configure

Bug#944242: Test issues with BioPython 1.75

[Andreas Tille]

Hi Peter,

On Wed, Nov 20, 2019 at 01:36:50PM +0100, Andreas Tille wrote:
> > 
> > https://github.com/biopython/biopython/issues/2350

Since I urgently need Biopython >= 1.74 to fix some other bugs I decided
to try to ignore those issues we discussed here and made sure that build
time tests will not fail.  However the Debian package is also running a
Continuous Integration test (autopkgtest in Debian terminology).  The
test for biopython is basically copying the test files to a temporary dir
and execute the tests[1].

In the attached log I injected a `set -x` and was running:

   sh run-unit-test 2>&1 | tee > tes_suite_errors.out

Unfortunately there are more errors than I expected.  Do you have any
idea why?

Kind regards

 Andreas.


[1] 
https://salsa.debian.org/med-team/python-biopython/blob/master/debian/tests/run-unit-test

-- 
http://fam-tille.de


tes_suite_errors.out.xz
Description: application/xz