Bug#972073: RFS: cool-retro-term/1.1.1+git20200723-1 [RC] -- terminal emulator which mimics old screens

[Gürkan Myczko]

Hi Tobias

The BTS will probably not get a copy as it was closed, i'd need to bts 
reopen 972073 (and unarchive when it was archived),

but I'll skip that for now.

On 13.10.2020 21:26, Tobias Frost wrote:

On Mon, Oct 12, 2020 at 09:44:17AM +0200, Gürkan Myczko wrote:


 * Package name: cool-retro-term
   Version : 1.1.1+git20200723-1
   Upstream Author : Filippo Scognamiglio 
 * URL : https://github.com/Swordfish90/cool-retro-term
 * License : GPL-3, MIT, OFL-1.1, dfsg-compliant-text, 
BSD-3-clause
 * Vcs : 
https://salsa.debian.org/myczko-guest/cool-retro-term

   Section : x11


Uploaded, but a question:

README.source says it is repackaged, due to dfsg topics. However, I'm
missing the dfsg suffix and also a Files-Excluded section in 
d/copyright.

How is the repacking done?


The qmltermwidget part is +ds, and the fonts +dfsg, sorry I completely 
forgot
to add +dfsg, will do so with the next update. (I had forgotten to 
reflect the
repackaging with +dfsg/+ds for a long time, but recently re-added it to 
later
sponsored uploads). And I'm aware of Files-Excluded section as well, 
have it
at some places, will need to add for all others where README.source 
documents

removals)


Other nitpicks:

(Though, it is strange that dh_missing fails on you; not sure how 
dh_missing

can cause a file to be overwritten.)


Very strange indeed, I did not investigate, just override it for now, to 
get

rid of the RC bug.


Something for subsequent uploads (not checked if legit)
X: fonts-hermit: package-contains-no-arch-dependent-files
X: fonts-proggy: package-contains-no-arch-dependent-files
X: fonts-terminus: package-contains-no-arch-dependent-files


Having seen that of course I tried to change it to Arch: all, however 
that would fail with:

http://phd-sid.ethz.ch/debian/cool-retro-term/2323/cool-retro-term_1.1.1%2Bgit20200723-1_amd64.build

Even more strange, if you have a tip/pointer/hint/idea, I'd be glad to 
get rid of those.


P: cool-retro-term source: maintainer-manual-page 
debian/cool-retro-term.1

manpage forwarded?


Good point, let me check:
Well, no, yes, upstream hasn't done a release for some time, and he 
ships his own packaging/debian directory
with a manpage there, which is slightly different. I will need to think 
about what to do here. I believe his
is better, but will need to compare/diff and update accordingly. 
Something for a future/next upload.



the patches need dep3 headers.


Ok two small patches of me, I can fill the dep3 headers I guess, also 
with next upload.




override_dh_auto_configure is a NOP.


ACK, to be fixed with next upload.



Cheers,
--
tobi

Bug#970259: Weather API update

[W3Host Bt.]

On Wed, 16 Sep 2020 08:20:59 +0300 "Pavel R."  wrote:
> Hello, I've fixed the plugin by bumping weather API version to 2.0
> 
> Patch is attached
> 

Thanks the patch, it is working...

NOT official deb package:
https://deb.w3host.hu/xfce4-weather-plugin_0.8.10-1.1_amd64.deb

Regards,

Krisztian

Bug#971889: RFS: colmap/3.6+really3.6-1 [RC] -- Structure-from-Motion and Multi-View Stereo

[Gürkan Myczko]

Hi Tobias,

Meanwhile the package builds again, tested locally, mind retrying?
00:08 < jochensp> tarzeau: I uploaded a new ceres-solver, hopefully 
fixing your issue


Here's my build logs (sbuild):
http://phd-sid.ethz.ch/debian/colmap/2020c/

Thank you,

Bug#960742: RFS: lazpaint/7.1.3 ITP -- add LazPaint to Debian

[Tobias Frost]

On Tue, Oct 13, 2020 at 10:08:53PM +0200, Johann ELSASS wrote:
> I don't understand. In a previous message you said you tried it and got an 
> error with "lazarus-project" dependency. Do you still get this error?

(It a while, but IIRC I didn't build the package. I just reviewed it on source 
level)

 
> About the DSC file, someone else mentioned it. I don't know about this format 
> but this has been mentioned to me by someone. May be that's something done by 
> a package maintainer or something?

dsc(5) (also https://wiki.debian.org/dsc) describes a source package.
debuild should create one for you. (As well as a pdebuild). Dput that to
mentors, as described here under Publish Package
https://mentors.debian.net/intro-maintainers/.  Send the RFS template on your
personal mentors package page to this bug. (do _NOT_ open a new bug)

With the help of a dsc someone can get the source / debian part exactly as you
have intended it, with a simple dget(1).

I'm currently having quitemuch on my plate, so I'm not giving guarantees that 
someone
will be me.

Cheers,
--
tobi

PS: Please do not use top-posting when replying.

> -- 
>   Johann ELSASS
>   circu...@operamail.com
> 
> On Tue, Oct 13, 2020, at 8:27 PM, Tobias Frost wrote:
> > On Tue, Oct 13, 2020 at 07:27:19PM +0200, Johann ELSASS wrote:
> > > Interesting. I will consider using it.
> > > 
> > > So have you tried with the dependency change?
> > 
> > I'll need a .dsc file for that.

Bug#972188: add libnsl-dev to Build-Depends for bootstrapping

[Helmut Grohne]

Source: tcp-wrappers
Version: 7.6.q-30
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

glibc split out libnsl-dev and tcp-wrappers uses it. This puts
bootstrappers in a difficult situation. The unstaged glibc packages have
a transitional dependency libc6-dev -> libnsl-dev to make this
transparent to downstreams. Quite obviously, this dependency cannot work
in staged builds as there would be no way to build libnsl or libtirpc or
krb5 or anything in their dependency chains. Therefore the staged glibc
builds don't depend on libnsl-dev. When building tcp-wrappers with such
a staged build, it fails finding libnsl as it is one of the few packages
actually using libnsl. So what we need here is that this dependency of
tcp-wrappers becomes explicit for bootstrapping. Please add it now. I'm
attaching a patch for your convenience and it also documents the
relevant glibc version in a dependency alternative for backporters.

Helmut
diff --minimal -Nru tcp-wrappers-7.6.q/debian/changelog 
tcp-wrappers-7.6.q/debian/changelog
--- tcp-wrappers-7.6.q/debian/changelog 2019-11-27 15:06:53.0 +0100
+++ tcp-wrappers-7.6.q/debian/changelog 2020-10-14 06:11:52.0 +0200
@@ -1,3 +1,10 @@
+tcp-wrappers (7.6.q-30.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing build dependency on libnsl-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 14 Oct 2020 06:11:52 +0200
+
 tcp-wrappers (7.6.q-30) unstable; urgency=medium
 
   * Restored the support for cross building, thanks to Helmut Grohne.
diff --minimal -Nru tcp-wrappers-7.6.q/debian/control 
tcp-wrappers-7.6.q/debian/control
--- tcp-wrappers-7.6.q/debian/control   2019-11-24 23:24:56.0 +0100
+++ tcp-wrappers-7.6.q/debian/control   2020-10-14 06:11:36.0 +0200
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Marco d'Itri 
-Build-Depends: debhelper-compat (= 12)
+Build-Depends: debhelper-compat (= 12), libnsl-dev | libc6-dev (<< 2.31-4)
 Standards-Version: 4.4.1.1
 Rules-Requires-Root: no
 Vcs-Git: https://salsa.debian.org/md/tcp-wrappers.git

Bug#972187: undeclarable haskell-devscripts-minimal dependency is now declarable for cross compilation

[Helmut Grohne]

Source: ghc
Version: 8.8.4-1
Severity: minor
Tags: patch

Hi,

a while ago, Adrian made ghc barely cross buildable. It still builds
something quite different from the regular ghc package, but it crosses
and the crossed thing seems to be able to build a native ghc.

One aspect that didnd't work out at all back then was the dependency on
haskell-devscripts-minimal. We told him, that no, we cannot mark it
Multi-Arch: foreign and we haven't moved forward on that aspect yet.
Therefore Adrian annotatd it "". cross builds now need to supply
some haskell-devscripts-minimal to work. What changed since then is that
the apt and dpkg now allow annotating Architecture: all packages with
":native". I think doing so is a better workaround than "".

It's a drop in the bucket. Can you apply it anyway?

Helmut
diff --minimal -Nru ghc-8.8.4/debian/changelog ghc-8.8.4/debian/changelog
--- ghc-8.8.4/debian/changelog  2020-08-11 16:12:43.0 +0200
+++ ghc-8.8.4/debian/changelog  2020-10-13 21:38:13.0 +0200
@@ -1,3 +1,10 @@
+ghc (8.8.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Simplify cross compilation workaround. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 13 Oct 2020 21:38:13 +0200
+
 ghc (8.8.4-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru ghc-8.8.4/debian/control ghc-8.8.4/debian/control
--- ghc-8.8.4/debian/control2020-05-28 16:01:41.0 +0200
+++ ghc-8.8.4/debian/control2020-10-13 21:38:08.0 +0200
@@ -7,7 +7,7 @@
 Rules-Requires-Root: no
 Build-Depends:
   debhelper-compat (= 12),
-  haskell-devscripts-minimal ,
+  haskell-devscripts-minimal:native,
   devscripts,
   grep-dctrl,
   pkg-config,

Bug#972100: CVE-2019-15547 CVE-2019-15548 (rust-ncurses)

[peter green]

I just looked at this issue.

rust-ncurses is a thin wrapper around ncurses. It exposes unsafe (in the rust 
sense) C
APIs to safe rust code. The rust security team consider this to be a 
vulnerability.

There is more discussion of this issue at 
https://github.com/jeaye/ncurses-rs/issues/188
the fix would be to mark most if not all of the functions exposed by the 
library as
unsafe and release a new major version of the library. Any reverse dependencies 
would
then need to be adapted to work with the new unsafe functions. The upstream 
maintainer
has indicated they would be accepting of a pull request but is not interested 
in doing
the work themselves.

There is also another wrapper called ncursesw which seems to be better 
maintained
and offers both low-level wrappers (correctly marked as unsafe) and higher-level
wrappers (some of which are safe). It is not packaged in Debian.

I looked to see what if-any packages in Debian use rust-ncurses and I did not 
find
any in either buster, bullseye or sid. Is there a reason to keep this package 
around?

Bug#826050: Hallo Schatz

[Advocate Djogbe]

Guten Morgen!

Antworte jetzt,

Ich habe Ihnen diesen Brief vor einigen Monaten geschickt, aber ich bin mir
nicht sicher, ob Sie ihn erhalten haben, weil ich nichts von Ihnen gehört
habe und deshalb ihn erneut sende. Ich bin Rechtsanwalt Hermann Djogbe, ein
persönlicher Anwalt meines verstorbenen Mandanten, der bei einem tödlichen
Autounfall mit seiner Familie ums Leben kam. Ich erhielt von seiner
Finanzgesellschaft das Mandat, seinen nächsten Verwandten die Möglichkeit
zu geben, seinen Fonds im Wert von (US $) in Anspruch zu nehmen
10.316.000,03 Millionen Dollar). Aus diesem Grund habe ich Sie nach meinen
erfolglosen Versuchen, einen seiner Verwandten zu finden, kontaktiert. Und
wieder gibt es keinen registrierten Erben in seiner Kontodatei bei der
Finanzgesellschaft. Ich habe mich entschlossen, Sie zu kontaktieren, da Sie
denselben Nachnamen wie mein verstorbener Kunde haben und er aus Ihrem Land
stammt. Bei Interesse wenden Sie sich bitte an mich, um weitere
Informationen und Erläuterungen zu dieser Transaktion zu erhalten.


Hochachtungsvoll,
Barr. Hermann Djogbe, ESQ.

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

[Samuel Thibault]

Hello,

Svante Signell, le lun. 14 sept. 2020 17:44:24 +0200, a ecrit:
> +#elif defined(__GNU__)
> +#include 
> +#include 
> +#define DRM_IOCTL_NR(n) ((n) & 0xff)

Rather use _IOC_COMMAND, that'll fix it into taking 7 bits only, not 8.

Samuel

Bug#959136: close this bug?

[Rebecca N. Palmer]

The linked upstream report says this went away in numpy 1.18.4, and the 
tests in question now pass on debci.

Bug#972183: buster-pu: package libjpeg-turbo/1:1.5.2-2+deb10u1

[Mike Gabriel]

Hi Moritz,

On  Di 13 Okt 2020 22:39:53 CEST, Moritz Muehlenhoff wrote:


Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ond...@debian.org, sunwea...@debian.org

This fixes a number of security issues in libjpeg,
which don't warrant a DSA. Package has been tested on
a buster system.

Cheers,
Moritz


Will you do the upload onced ACK'ed by the RT (I guess ACK'ing  
pre-upload is not required for the .debdiff you prepared)? Or have you  
already uploaded that version (I am currently on VAC and not following  
all mail channels...)? Or shall I upload?


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



pgpg6efonrpSC.pgp
Description: Digitale PGP-Signatur

Bug#971410: not caused by openshot-qt

[Lazy Tinker]

Hi, this bug has no business with openshot-qt, it is caused by QGIS, and 
it has been fixed , link 

https://tracker.debian.org/news/1180785/accepted-qgis-31010dfsg-2-source-into-unstable/
 

So this thread could be closed.

Bug#971972: vde-switch,vde-wirefilter,vdeplug: Missing Breaks + Replaces headers: "trying to overwrite '/usr/bin/…', which is also in package vde2 2.3.2+r586-2.2+b1"

[Andreas Beckmann]

Followup-For: Bug #971972
Control: found -1 2.3.2+r586-6

Hi,

the solution in the last upload is incorrect:
* the Breaks is incorrectly versioned (e.g. does not catch binNMUs)
* the matching Replaces is missing

Please add this to the three packages in question:

Breaks:   vde2 (<< 2.3.2+r586-3)
Replaces: vde2 (<< 2.3.2+r586-3)


Andreas

Bug#972186: systemd-analyze

[Andrew Savchenko]

Package: systemd
Version: 241-7~deb10u4
Tags: security, buster, bullseye
Severity: wishlist


Dear Maintainers,

Among others, /usr/bin/systemd-analyze can be called with "security" parameter 
which shows sandboxing settings of the loaded units on the scale from 0 to 10.

On Debian v10.6 vast majority of the services are reported as "unsafe" with 
exposure score >9. This includes sshd, unattended-upgrades and others.

Is there a plan to improve situation for Bullseye? I think maintainers of
Whonix project, which is based on Debian, are using it for some services they 
ship in addition to base (sdwdate, onion-grater, etc).

References:
[1] https://forums.whonix.org/t/systemd-analyze-security/10395
[2] https://www.ctrl.blog/entry/systemd-opensmtpd-hardening.html
[3] 
https://forums.whonix.org/t/system-wide-sandboxing-framework-sandbox-app-launcher/9008


-- 
With regards,
A

Bug#961076: NXNS Attack (CVE-2020-12667)

[Andrew Savchenko]

Dear Maintainers,

Is there still a plan to backport a fix for CVE-2020-12667 into Buster?

Looking at the changelog [1], there is nothing that indicates it is already 
fixed.

[1] 
https://metadata.ftp-master.debian.org/changelogs//main/k/knot-resolver/knot-resolver_3.2.1-3_changelog


-- 
With regards,
A

Bug#972135:

[Pat Coulthard]

Thank you for the suggestions!

I can now confirm (as you stated) that this is not an issue on ext4 mounted
"-o noacl", and is, in fact, only an issue on NFS when a) the server
filesystem doesn't support ACLs (ZFS in my case, but I verified the same
with ext4 mounted "noacl") and b) the client mounts the NFS filesystem
without specifying the "noacl" mount option. If either condition is unmet
(i.e. the server filesystem does support ACLs, or the client mounts
"noacl") the systemd-tmpfile command succeeds.

So, for me, adding "noacl" to the NFS client mount options allows the
upgrade to proceed as expected.

I've found that systemd-tmpfiles has code [1] that attempts to account for
a lack of filesystem ACL support, but there's a hole in this specific case
that leads to it being skipped unexpectedly. I'll take those details
upstream after a bit more investigation.

[1]
https://github.com/systemd/systemd/blob/7fe7547ba3b953c142f41a9931dba7b6ff78fe0b/src/tmpfiles/tmpfiles.c#L1160

Bug#972185: libre0: stack smashing detected in v1.1.0

[Kevin Otte]

Package: libre0
Version: 1.1.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I went ahead and installed version 1.1.0-1 from unstable to go ahead and
test the fix for #971980.

---
kjotte@daedalus:~$ baresip
baresip v1.0.0 Copyright (C) 2010 - 2020 Alfred E. Heggestad et al.
Local network address:
IPv6=enp0s25|2606:a000:a442:9800:efae:2f59:1855:7d4f
...
baresip is ready.
>  142
ua: using best effort AF: af=AF_INET6
call: connecting to 'sip:1...@pbx-int.home.nivex.net'..
*** stack smashing detected ***: terminated
Aborted (core dumped)
---

Not sure if this is a problem in the libre0 build or if baresip needs to
be rebuilt against the new library version.

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=UTF-8) (ignored: LC_ALL set
to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libre0 depends on:
ii  libc6  2.31-3
ii  libssl1.1  1.1.1g-1
ii  zlib1g 1:1.2.11.dfsg-2

libre0 recommends no packages.

libre0 suggests no packages.

-- no debconf information

Bug#972184: python-crypto: do not release with bullseye

[Sebastian Ramacher]

Source: python-crypto
Version: 2.6.1-13.1
Severity: serious
Tags: sid bullseye
Control: block -1 by 971289 971290 971291 971292 971293 971294 971296 971297 
971298 971299 971300 971301 971302 971304 971307 971308 971309 971310 971311 
971313 971315 971316 971317

python-crypto is no longer maintained and has ben replaced by
pycryptodome. Let's remove it.
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#959136: close this bug?

[Diane Trout]

On Tue, 2020-10-13 at 22:10 +0100, Rebecca N. Palmer wrote:
> The linked upstream report says this went away in numpy 1.18.4, and
> the 
> tests in question now pass on debci.
> 

Thank you for checking.

That does sound like it's been resolved.

It's at least passing on amd and arm 64

Bug#969362: python-flask-cors: CVE-2020-25032

[Bastian Germann]

Hi Salvatore,

Thanks for your hints.

Am 10.10.20 um 23:02 schrieb Salvatore Bonaccorso:
> Hi Bastian,
> 
> [Please do send such requests always to team@s.d.o, dev-ref gives as
> well some further hints at
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#handling-security-related-bugs]
> 
> On Thu, Oct 08, 2020 at 04:25:55PM +0200, Bastian Germann wrote:
>> On Tue, 01 Sep 2020 10:51:48 +0200 Salvatore Bonaccorso
>>  wrote:
>>> The following vulnerability was published for python-flask-cors.
>>>
>>> CVE-2020-25032[0]:
>>> | An issue was discovered in Flask-CORS (aka CORS Middleware for Flask)
>>> | before 3.0.9. It allows ../ directory traversal to access private
>>> | resources because resource matching does not ensure that pathnames are
>>> | in a canonical format.
>>>
>>>
>>> If you fix the vulnerability please also make sure to include the
>>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>>>
>>> For further information see:
>>>
>>> [0] https://security-tracker.debian.org/tracker/CVE-2020-25032
>>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25032
>>> [1] 
>>> https://github.com/corydolphin/flask-cors/commit/67c4b2cc98ae87cf1fa7df4f97fd81b40c79b895
>>
>> I have prepared a buster-security release at
>>
>> https://salsa.debian.org/python-team/packages/python-flask-cors/-/tags/debian%2F3.0.7-2
> 
> As for the update, please do send always as a debdiff from a built
> (and tested) package (this request is similarly to what stable release
> managers would expect for point release updates, it helps us as well
> to archive discussion and debdiffs to review).

The debdiff is enclosed. Also available at:
https://salsa.debian.org/python-team/packages/python-flask-cors/-/tags/debian%2F3.0.7-1+deb10u1
> 
> But I can give already a first feedback: debian/changelog uses 3.0.7-2
> as version. Even though 3.0.7-2 might never have been seen in the
> archive, please do use 3.0.7-1+deb10u1 instead following the usual
> convention. While at it use urgency=high (for consistency in security
> updates).
> 
> For the bug closer I think you will need to use "Closes: #969362)".

I applied all suggestions.

> Furthermore: what kind of testing did the update recieve, were you
> able to test the update in production environments, are there any
> problems spotted? I'm asking in particular as the modfied tests seem
> to pass ok as well without the patch (but I only quickly gave it a
> test from the git repository, might be something else strange here).

I ran the built package on buster but did not try to confirm that the
security issue is closed as claimed by upstream. No problems spotted.

>> The new upstream release is waiting in the master branch to be published
>> in sid.
> 
> Ok, although not required, if you have that already ok to be uploaded
> I would say to go ahead with the unstable upload and have the fixes
> exposed there already.

I cannot upload because I am not a DD. It would be nice if someone could
sponsor the new version. It also closes a FTBFS, which got me interested
in the package in the first place.

Regards,
Bastian
diff -Nru python-flask-cors-3.0.7/debian/changelog 
python-flask-cors-3.0.7/debian/changelog
--- python-flask-cors-3.0.7/debian/changelog2018-12-05 21:51:05.0 
+0100
+++ python-flask-cors-3.0.7/debian/changelog2020-10-08 21:40:11.0 
+0200
@@ -1,3 +1,10 @@
+python-flask-cors (3.0.7-1+deb10u1) buster-security; urgency=high
+
+  * Team upload.
+  * Fix CVE-2020-25032 (Closes: #969362) with upstream patch
+
+ -- Bastian Germann   Thu, 08 Oct 2020 21:40:11 
+0200
+
 python-flask-cors (3.0.7-1) unstable; urgency=medium
 
   * Initial release (Closes: #915789)
diff -Nru python-flask-cors-3.0.7/debian/patches/cve-2020-25032 
python-flask-cors-3.0.7/debian/patches/cve-2020-25032
--- python-flask-cors-3.0.7/debian/patches/cve-2020-25032   1970-01-01 
01:00:00.0 +0100
+++ python-flask-cors-3.0.7/debian/patches/cve-2020-25032   2020-10-08 
21:40:11.0 +0200
@@ -0,0 +1,34 @@
+Origin: 
https://github.com/corydolphin/flask-cors/commit/67c4b2cc98ae87cf1fa7df4f97fd81b40c79b895
+From: Cory Dolphin 
+Date: Sun, 30 Aug 2020 15:32:54 -0600
+Subject: Fix request path normalization (#272)
+
+* Normalize path before evaluating resource rules
+---
+diff --git a/flask_cors/extension.py b/flask_cors/extension.py
+index 6a585aa..466869e 100644
+--- a/flask_cors/extension.py
 b/flask_cors/extension.py
+@@ -10,6 +10,10 @@
+ """
+ from flask import request
+ from .core import *
++try:
++from urllib.parse import unquote_plus
++except ImportError:
++from urllib import unquote_plus
+ 
+ LOG = logging.getLogger(__name__)
+ 
+@@ -173,9 +177,9 @@ def cors_after_request(resp):
+ if resp.headers is not None and resp.headers.get(ACL_ORIGIN):
+ LOG.debug('CORS have been already evaluated, skipping')
+ return resp
+-
++normalized_path = unquote_plus(request.path)
+ for 

Bug#969546: freecad: Freecad crashes when placing beam in Arch workbench

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this crash and first lines of the backtrace
with full debug symbols shows like in [1],
while trying to dereference a null pointer.

This might be a use after free because when trying to reverse execute
to the point where the memory holding the null pointer is last written,
we end in [2], which seems destroying the container pyObj=0x7f987942c7c0.

Full backtraces and starting from a minimal VM in attached file.

Kind regards,
Bernhard


[1]
(rr) bt
#0  0x7f98dcb21a5f in Shiboken::Object::cppPointers (pyObj=0x7f987942c7c0) 
at /usr/include/c++/9/bits/stl_vector.h:1040
#1  0x7f98dcc0f73a in Sbkshiboken2Module_getCppPointer (self=, pyArg=0x7f987942c7c0) at 
./pyside3_build/py3.8-qt5.14.2-64bit-relwithdebinfo/shiboken2/shibokenmodule/shiboken2/shiboken2_module_wrapper.cpp:278
#2  0x7f98e5fc1f06 in cfunction_vectorcall_O 
(func=func@entry=0x7f98dcba1450, args=0x7f9879a6bbc8, nargsf=nargsf@entry=1, 
kwnames=) at ../Objects/methodobject.c:482
#3  0x7f98e5f7e0bc in PyVectorcall_Call (callable=0x7f98dcba1450, 
tuple=, kwargs=) at ../Objects/call.c:199
#4  0x7f98e5f7e26f in PyObject_Call (callable=, 
args=, kwargs=) at ../Objects/call.c:227
#5  0x7f98e5f7edf1 in PyEval_CallObjectWithKeywords (callable=, args=, kwargs=kwargs@entry=0x0) at ../Objects/call.c:809
#6  0x7f98e5f7ee67 in PyObject_CallObject (callable=, 
args=) at ../Objects/call.c:817
#7  0x7f98e7041d07 in Py::Callable::apply (args=..., this=0x7ffdc1b3a8f0) 
at ./src/CXX/Python3/Objects.hxx:3156
#8  Gui::qt_getCppPointer (pyobject=..., shiboken=, 
unwrap=) at ./src/Gui/WidgetFactory.cpp:273
#9  0x7f98e6f72950 in Gui::TaskView::TaskDialogPython::TaskDialogPython 
(this=0x55dcb312bd10, o=...) at ./src/CXX/Python3/Objects.hxx:185
#10 0x7f98e6f72d0d in Gui::TaskView::ControlPy::showDialog (this=, args=...) at ./src/CXX/Python3/Objects.hxx:177
#11 0x7f98e6f736b1 in 
Py::PythonExtension::method_varargs_call_handler 
(_self_and_name_tuple=, _args=) at 
./src/CXX/Python3/Objects.hxx:177
#12 0x7f98e5f7d947 in cfunction_call_varargs (func=0x7f987943c590, 
args=, kwargs=) at ../Objects/call.c:757
#13 0x7f98e5f7e797 in _PyObject_MakeTpCall (callable=0x7f987943c590, 
args=, nargs=, keywords=0x0) at 
../Objects/call.c:159
#14 0x7f98e5f59cd3 in _PyObject_Vectorcall (kwnames=0x0, nargsf=, args=, callable=0x7f987943c590) at 
../Include/cpython/abstract.h:125
...


[2]
(rr) bt
#0  Shiboken::Object::destroy (self=0x7f987942c7c0, cppData=0x55dcaf4f8900) at 
./sources/shiboken2/libshiboken/basewrapper.cpp:1479
#1  0x7f98d4b17403 in QWidgetWrapper::~QWidgetWrapper (this=0x55dcaf4f8900, 
__in_chrg=) at 
./pyside3_build/py3.8-qt5.14.2-64bit-relwithdebinfo/pyside2/PySide2/QtWidgets/PySide2/QtWidgets/qwidget_wrapper.cpp:1794
#2  0x7f98d4b17429 in QWidgetWrapper::~QWidgetWrapper (this=0x55dcaf4f8900, 
__in_chrg=) at 
./pyside3_build/py3.8-qt5.14.2-64bit-relwithdebinfo/pyside2/PySide2/QtWidgets/PySide2/QtWidgets/qwidget_wrapper.cpp:1791
#3  0x7f98e55efb0e in QObjectPrivate::deleteChildren 
(this=this@entry=0x55dcaf320a10) at kernel/qobject.cpp:2123
#4  0x7f98e59f4ce6 in QWidget::~QWidget (this=0x55dcaf31d800, 
__in_chrg=) at kernel/qwidget.cpp:1530
#5  0x7f98e6f7da71 in QSint::TaskGroup::~TaskGroup (this=0x55dcaf31d800, 
__in_chrg=) at ./src/Gui/QSint/actionpanel/taskgroup_p.h:22
#6  QSint::TaskGroup::~TaskGroup (this=0x55dcaf31d800, __in_chrg=) at ./src/Gui/QSint/actionpanel/taskgroup_p.h:22
#7  0x7f98e55efb0e in QObjectPrivate::deleteChildren 
(this=this@entry=0x55dcaf312a30) at kernel/qobject.cpp:2123
#8  0x7f98e59f4ce6 in QWidget::~QWidget (this=0x55dcaf312980, 
__in_chrg=) at kernel/qwidget.cpp:1530
#9  0x7f98e6f6c8d9 in Gui::TaskView::TaskBox::~TaskBox 
(this=0x55dcaf312980, __in_chrg=) at 
./src/Gui/TaskView/TaskView.cpp:241
#10 0x7f98e6f6dab6 in Gui::TaskView::TaskDialog::~TaskDialog 
(this=0x55dcaf516440, __in_chrg=) at 
/usr/include/c++/9/bits/stl_iterator.h:819
#11 0x7f98e6f6eed4 in Gui::TaskView::TaskDialogPython::~TaskDialogPython 
(this=0x55dcaf516440, __in_chrg=) at 
./src/CXX/Python3/Objects.hxx:163
#12 0x7f98e6f6ef09 in Gui::TaskView::TaskDialogPython::~TaskDialogPython 
(this=0x55dcaf516440, __in_chrg=) at 
./src/Gui/TaskView/TaskDialogPython.cpp:314
#13 0x7f98e6f6a48b in Gui::TaskView::TaskView::removeDialog 
(this=0x55dcacf00840) at ./src/Gui/TaskView/TaskView.cpp:649
#14 0x7f98e6f6dfb2 in Gui::TaskView::ControlPy::closeDialog 
(this=) at ./src/Gui/Control.h:133
#15 0x7f98e6f736b1 in 
Py::PythonExtension::method_varargs_call_handler 
(_self_and_name_tuple=, _args=) at 
./src/CXX/Python3/Objects.hxx:177
#16 0x7f98e5f7d947 in cfunction_call_varargs (func=0x7f9879427900, 
args=, kwargs=) at ../Objects/call.c:757
#17 0x7f98e5f7e797 in _PyObject_MakeTpCall (callable=0x7f9879427900, 
args=, nargs=, keywords=0x0) at 
../Objects/call.c:159
#18 0x7f98e5f59cd3 in _PyObject_Vectorcall (kwnames=0x0, nargsf=, 

Bug#972181: possible-gpl-code-linked-with-openssl tag/test can be retired

[Moritz Mühlenhoff]

On Tue, Oct 13, 2020 at 01:56:40PM -0700, Felix Lechner wrote:
> Hi Moritz,
> 
> On Tue, Oct 13, 2020 at 1:33 PM Moritz Muehlenhoff  wrote:
> >
> > FTP masters are now treating OpenSSL as a system library, which makes
> > it GPL compatible
> 
> According to the OpenSSL website, the new license applies from 3.0.0
> onward [1], but unstable still ships 1.1.1h (with 3.0.0 in
> experimental). You probably waited five years for this, but is this
> removal request still a tiny bit premature?
> 
> [1] https://www.openssl.org/source/license.html

The decision by FTP masters is totally independent of the license change
for OpenSSL 3.0. In fact the same policy has been applied by Red Hat/Fedora 
basically
since forever, see 
http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html

And even with the license change in OpenSSL 3 to the Apache license 2, this
would still be an "issue" for any code base which is GPL-2 only.

Cheers,
Moritz

Bug#972181: possible-gpl-code-linked-with-openssl tag/test can be retired

[Felix Lechner]

Hi Moritz,

On Tue, Oct 13, 2020 at 1:33 PM Moritz Muehlenhoff  wrote:
>
> FTP masters are now treating OpenSSL as a system library, which makes
> it GPL compatible

According to the OpenSSL website, the new license applies from 3.0.0
onward [1], but unstable still ships 1.1.1h (with 3.0.0 in
experimental). You probably waited five years for this, but is this
removal request still a tiny bit premature?

[1] https://www.openssl.org/source/license.html

Kind regards

Felix Lechner

Bug#971683: postgresql-common: obsolete-conffile (apt.conf.d, createcluster.conf)

[Christoph Berg]

Control: tags -1 - moreinfo

Re: Thorsten Glaser
> Oh, interesting. Yes, I see that in
> /var/lib/dpkg/info/postgresql-common.postinst
> but while /var/lib/dpkg/info/postgresql-common.conffiles
> indeed does not list it any more,
> /var/lib/dpkg/info/postgresql-common.list still lists it.

Oh, I only checked postgresql-common.conffiles in my testing today,
not postgresql-common.list. Maybe dpkg-maintscript-helper doesn't
update the .list file... Need to repeat the tests (but not tonight).

Thanks for the feedback,
Christoph

Bug#966395: Please support SSL bumping with '--with-openssl' configure option

[Moritz Mühlenhoff]

On Wed, Jul 29, 2020 at 10:09:45AM +1200, Amos Jeffries wrote:
> On Mon, 27 Jul 2020 17:54:01 -0400 Simon Deziel wrote:
> > 
> > Now that OpenSSL is available under the Apache License v. 2.0, there
> > should no longer be any incompatibility with Debian.
> 
> 
> Apache is not yet available with the new License and will likely not be
> until the next Debian major release after it becomes available.

You don't need to wait for OpenSSL 3; FTP masters have decided to treat
OpenSSL as a system library like glibc, which makes it compatible, see
http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html

Cheers,
Moritz

Bug#972115: buster-pu: package sqlite3/3.27.2-3+deb10u1

[GCS]

On Mon, Oct 12, 2020 at 10:54 PM Moritz Muehlenhoff  wrote:
> A number of security fixes in sqlite, which don't warrant a DSA.
> This has been tested on a Buster system (along with validating
> included test cases that issues are correctly fixed).
 I don't know if it counts, but being the original maintainer and I do
second the work of Moritz.
My time is limited nowadays, but I did a quick check and the proposed
update is correct. Please let it enter Buster.

Thanks Moritz,
Laszlo/GCS

Bug#972183: buster-pu: package libjpeg-turbo/1:1.5.2-2+deb10u1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ond...@debian.org, sunwea...@debian.org

This fixes a number of security issues in libjpeg,
which don't warrant a DSA. Package has been tested on
a buster system.

Cheers,
Moritz
diff -Nru libjpeg-turbo-1.5.2/debian/changelog 
libjpeg-turbo-1.5.2/debian/changelog
--- libjpeg-turbo-1.5.2/debian/changelog2017-08-25 10:27:48.0 
+0200
+++ libjpeg-turbo-1.5.2/debian/changelog2020-10-07 22:25:43.0 
+0200
@@ -1,3 +1,12 @@
+libjpeg-turbo (1:1.5.2-2+deb10u1) buster; urgency=medium
+
+  * CVE-2018-1152  (Closes: #902950)
+  * CVE-2018-14498 (Closes: #924678)
+  * CVE-2019-2201
+  * CVE-2020-13790 (Closes: #962829)
+
+ -- Moritz Mühlenhoff   Wed, 07 Oct 2020 22:25:43 +0200
+
 libjpeg-turbo (1:1.5.2-2) unstable; urgency=medium
 
   * Drop env declaration patch on mips to fix FTBFS on mips
diff -Nru libjpeg-turbo-1.5.2/debian/patches/CVE-2018-1152.patch 
libjpeg-turbo-1.5.2/debian/patches/CVE-2018-1152.patch
--- libjpeg-turbo-1.5.2/debian/patches/CVE-2018-1152.patch  1970-01-01 
01:00:00.0 +0100
+++ libjpeg-turbo-1.5.2/debian/patches/CVE-2018-1152.patch  2020-10-07 
22:25:25.0 +0200
@@ -0,0 +1,19 @@
+https://github.com/libjpeg-turbo/libjpeg-turbo/commit/43e84cff1bb2bd8293066f6ac4eb0df61bc6
+
+Index: libjpeg-turbo-1.5.2/rdbmp.c
+===
+--- libjpeg-turbo-1.5.2.orig/rdbmp.c   2018-07-05 14:47:54.525745754 -0400
 libjpeg-turbo-1.5.2/rdbmp.c2018-07-05 14:47:54.521745700 -0400
+@@ -434,6 +434,12 @@ start_input_bmp (j_compress_ptr cinfo, c
+ progress->total_extra_passes++; /* count file input as separate pass */
+   }
+ 
++  /* Ensure that biWidth * cinfo->input_components doesn't exceed the maximum
++ value of the JDIMENSION type.  This is only a danger with BMP files, 
since
++ their width and height fields are 32-bit integers. */
++  if ((unsigned long long)biWidth *
++  (unsigned long long)cinfo->input_components > 0xULL)
++ERREXIT(cinfo, JERR_WIDTH_OVERFLOW);
+   /* Allocate one-row buffer for returned data */
+   source->pub.buffer = (*cinfo->mem->alloc_sarray)
+ ((j_common_ptr) cinfo, JPOOL_IMAGE,
diff -Nru libjpeg-turbo-1.5.2/debian/patches/CVE-2018-14498.patch 
libjpeg-turbo-1.5.2/debian/patches/CVE-2018-14498.patch
--- libjpeg-turbo-1.5.2/debian/patches/CVE-2018-14498.patch 1970-01-01 
01:00:00.0 +0100
+++ libjpeg-turbo-1.5.2/debian/patches/CVE-2018-14498.patch 2020-10-07 
22:25:25.0 +0200
@@ -0,0 +1,117 @@
+https://github.com/libjpeg-turbo/libjpeg-turbo/commit/9c78a04df4e44ef6487eee99c4258397f4fdca55
+
+diff --git a/cderror.h b/cderror.h
+index 63de498..bb093b8 100644
+--- a/cderror.h
 b/cderror.h
+@@ -49,6 +49,8 @@ JMESSAGE(JERR_BMP_COLORSPACE, "BMP output must be grayscale 
or RGB")
+ JMESSAGE(JERR_BMP_COMPRESSED, "Sorry, compressed BMPs not yet supported")
+ JMESSAGE(JERR_BMP_EMPTY, "Empty BMP image")
+ JMESSAGE(JERR_BMP_NOT, "Not a BMP file - does not start with BM")
++JMESSAGE(JERR_BMP_TOOLARGE, "Integer value too large in BMP file")
++JMESSAGE(JERR_BMP_OUTOFRANGE, "Numeric value out of range in BMP file")
+ JMESSAGE(JTRC_BMP, "%ux%u 24-bit BMP image")
+ JMESSAGE(JTRC_BMP_MAPPED, "%ux%u 8-bit colormapped BMP image")
+ JMESSAGE(JTRC_BMP_OS2, "%ux%u 24-bit OS2 BMP image")
+@@ -75,8 +77,8 @@ JMESSAGE(JWRN_GIF_NOMOREDATA, "Ran out of GIF bits")
+ #ifdef PPM_SUPPORTED
+ JMESSAGE(JERR_PPM_COLORSPACE, "PPM output must be grayscale or RGB")
+ JMESSAGE(JERR_PPM_NONNUMERIC, "Nonnumeric data in PPM file")
+-JMESSAGE(JERR_PPM_TOOLARGE, "Integer value too large in PPM file")
+ JMESSAGE(JERR_PPM_NOT, "Not a PPM/PGM file")
++JMESSAGE(JERR_PPM_OUTOFRANGE, "Numeric value out of range in PPM file")
+ JMESSAGE(JTRC_PGM, "%ux%u PGM image")
+ JMESSAGE(JTRC_PGM_TEXT, "%ux%u text PGM image")
+ JMESSAGE(JTRC_PPM, "%ux%u PPM image")
+diff --git a/rdbmp.c b/rdbmp.c
+index 4104b68..9ca4a26 100644
+--- a/rdbmp.c
 b/rdbmp.c
+@@ -66,6 +66,7 @@ typedef struct _bmp_source_struct {
+   JDIMENSION row_width; /* Physical width of scanlines in file */
+ 
+   int bits_per_pixel;   /* remembers 8- or 24-bit format */
++  int cmap_length;  /* colormap length */
+ } bmp_source_struct;
+ 
+ 
+@@ -126,6 +127,7 @@ get_8bit_row (j_compress_ptr cinfo, cjpeg_source_ptr sinfo)
+ {
+   bmp_source_ptr source = (bmp_source_ptr) sinfo;
+   register JSAMPARRAY colormap = source->colormap;
++  int cmaplen = source->cmap_length;
+   JSAMPARRAY image_ptr;
+   register int t;
+   register JSAMPROW inptr, outptr;
+@@ -142,6 +144,8 @@ get_8bit_row (j_compress_ptr cinfo, cjpeg_source_ptr sinfo)
+   outptr = source->pub.buffer[0];
+   for (col = cinfo->image_width; col > 0; col--) {
+ t = GETJSAMPLE(*inptr++);
++if ( t >= cmaplen)
++  ERREXIT(cinfo, JERR_BMP_TOOLARGE);
+ *outptr++ = 

Bug#972182: RM: lout -- RoQA; unmaintained, dead upstream, open security issues

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove lout. It's orphaned without an adopter since 2013, has open
security issues for almost a year and is dead upstream.

Cheers,
Moritz

Bug#971683: postgresql-common: obsolete-conffile (apt.conf.d, createcluster.conf)

[Thorsten Glaser]

Control: tags -1 - moreinfo

>I've had a closer look now. The cited commit does correctly remove the
>conffile:

>+rm_conffile /etc/apt/apt.conf.d/01autoremove 215~ postgresql-common

Oh, interesting. Yes, I see that in
/var/lib/dpkg/info/postgresql-common.postinst
but while /var/lib/dpkg/info/postgresql-common.conffiles
indeed does not list it any more,
/var/lib/dpkg/info/postgresql-common.list still lists it.

Checking the apt term.log archives, I have:

[…]
Preparing to unpack .../091-postgresql-common_215_all.deb ...
Leaving 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by 
postgresql-common'
Unpacking postgresql-common (215) over (214) ...
[…]
Setting up postgresql-common (215) ...
Starting PostgreSQL 12 database server: main.
[…]

So I assume this has somehow run, but perhaps silently?

I’ve got no idea, I never used dpkg-maintscripthelper yet.


The call to dpkg-maintscript-helper rm_conffile is even
in preinst of the 215 version, so it ought to have caught
that file… does dpkg-maintscript-helper log anywhere?

My best guess is that something modified that file before
the upgrade to 215, relative to… whatever dpkg-maintscript-helper
considered as “unmodified”. While this is my work laptop, not
the desktop (which I crossgraded way too much…) it’s been running
sid for many years now.


bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#972181: possible-gpl-code-linked-with-openssl tag/test can be retired

[Moritz Muehlenhoff]

Package: lintian
Severity: normal
X-Debbugs-Cc: mbi...@debian.org

The possible-gpl-code-linked-with-openssl test is no longer needed,
FTP masters are now treating OpenSSL as a system library, which makes
it GPL compatible: 
http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html

Cheers,
Moritz

Bug#972180: libdbi-perl: CVE-2014-10402

[Salvatore Bonaccorso]

Source: libdbi-perl
Version: 1.643-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libdbi-perl, this is
mainly to have tracking bug in Debian as well. There is at this point
not been a fix upstream, there is a proposed fix in [2].

CVE-2014-10402[0]:
| An issue was discovered in the DBI module through 1.643 for Perl.
| DBD::File drivers can open files from folders other than those
| specifically passed via the f_dir attribute in the data source name
| (DSN). NOTE: this issue exists because of an incomplete fix for
| CVE-2014-10401.


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-2014-10402
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-10402
[1] https://rt.cpan.org/Public/Bug/Display.html?id=99508#txn-1911590
[2] https://github.com/perl5-dbi/dbi/pull/93 

Regards,
Salvatore

Bug#960742: RFS: lazpaint/7.1.3 ITP -- add LazPaint to Debian

[Johann ELSASS]

I don't understand. In a previous message you said you tried it and got an 
error with "lazarus-project" dependency. Do you still get this error?

About the DSC file, someone else mentioned it. I don't know about this format 
but this has been mentioned to me by someone. May be that's something done by a 
package maintainer or something?

-- 
  Johann ELSASS
  circu...@operamail.com

On Tue, Oct 13, 2020, at 8:27 PM, Tobias Frost wrote:
> On Tue, Oct 13, 2020 at 07:27:19PM +0200, Johann ELSASS wrote:
> > Interesting. I will consider using it.
> > 
> > So have you tried with the dependency change?
> 
> I'll need a .dsc file for that.

Bug#959238: yowsup-cli: requires python3-consonance

[Antonio Terceiro]

Control: severity -1 serious

On Fri, 01 May 2020 14:55:28 +0200 Nicola  wrote:
> Package: yowsup-cli
> Version: 3.2.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> it's an error in dependecies. python3-consonance is required, otherwise
> 
> Traceback (most recent call last):
>   File "/usr/bin/yowsup-cli", line 6, in 
> from yowsup.config.manager import ConfigManager
>   File "/usr/lib/python3/dist-packages/yowsup/config/manager.py", line 4, in
> 
> from yowsup.config.v1.serialize import ConfigSerialize
>   File "/usr/lib/python3/dist-packages/yowsup/config/v1/serialize.py", line 8,
> in 
> from consonance.structs.keypair import KeyPair
> ModuleNotFoundError: No module named 'consonance'

Packages must declare all their dependencies. I'm upgrading this to
severity serious.


signature.asc
Description: PGP signature

Bug#971683: postgresql-common: obsolete-conffile (apt.conf.d, createcluster.conf)

[Christoph Berg]

Control: tags -1 moreinfo

Re: Thorsten Glaser
> https://salsa.debian.org/postgresql/postgresql-common/-/commit/e87adade0349a757fd0827a80cc14814487a4d30.patch
> 
> I believe this is a genuine packaging (especially upgrade) bug
> introduced with that commit: the commit removed the file
> /etc/apt/apt.conf.d/01autoremove-postgresql from the package
> but did not unregister it as conffile.

I've had a closer look now. The cited commit does correctly remove the
conffile:

diff --git a/debian/postgresql-common.maintscript 
b/debian/postgresql-common.maintscript
new file mode 100644
index 000..5849b7a
--- /dev/null
+++ b/debian/postgresql-common.maintscript
@@ -0,0 +1,2 @@
+# file is now managed by pg_updateaptconfig
+rm_conffile /etc/apt/apt.conf.d/01autoremove 215~ postgresql-common

Upgrading across that version correctly removes the conffile here.

Is there anything wrong with that?

> I’ve not looked at createcluster.conf but it will, most likely, also
> be caused by a similar packaging fault.

That one is indeed not handled. The conffile was converted to ucf in
version 155 in May 2014. Before I fix that (if that even makes sense
now), I'd like to understand if there is anything wrong with the
other file.

Christoph

Bug#971683: postgresql-common: obsolete-conffile (apt.conf.d, createcluster.conf)

[Thorsten Glaser]

Christoph Berg dixit:

>Re: Thorsten Glaser
>> I’ve not looked at createcluster.conf but it will, most likely, also
>> be caused by a similar packaging fault.
>
>Yes, but renaming is not an option there.

Right.

>I'll look into fixing this properly.

Thanks!

>Thanks for spotting,

I’ve just got adequate installed and look at its output occasionally.

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy

Bug#972178: openorienteering-mapper: FTBFS with Qt 5.15: error: aggregate 'QPainterPath outside_path' has incomplete type and cannot be defined

[Kai Pastor, DG0YT]

Am 13.10.20 um 20:05 schrieb Dmitry Shachnev:

Source: openorienteering-mapper
Version: 0.9.3-1
Severity: important
Tags: ftbfs
User: debian-qt-...@lists.debian.org
Usertags: qt5.15

Dear Maintainer,

openorienteering-mapper fails to build with Qt 5.15, currently available in
experimental:

   /build/openorienteering-mapper-0.9.3/src/gui/print_tool.cpp: In member 
function 'virtual void OpenOrienteering::PrintTool::draw(QPainter*, 
OpenOrienteering::MapWidget*)':
   /build/openorienteering-mapper-0.9.3/src/gui/print_tool.cpp:144:15: error: 
aggregate 'QPainterPath outside_path' has incomplete type and cannot be defined
 144 |  QPainterPath outside_path;
 |   ^~~~

The full build log is attached.

--
Dmitry Shachnev


Fixed in 0.9.4, already released. Cf.

https://build.opensuse.org/package/show/home:dg0yt/openorienteering-mapper

Regards,
Kai

Bug#972151: glib2.0: gdbus-server-auth test consistently fails on arm-conova-03 but nowhere else

[Simon McVittie]

On Tue, 13 Oct 2020 at 13:10:46 +, Paul Wise wrote:
> On Tue, Oct 13, 2020 at 11:12 AM Simon McVittie wrote:
> > Or is there anything odd about arm-conova-03's TCP or other networking
> > setup?
> 
> arm-conova-03 does not have an IPv4 address/route except on the
> loopback device but amdahl, arm-conova-01 and arm-conova-02 do.

Thanks, that could well be it. libdbus resolves the host part of a TCP
address using getaddrinfo() with AI_ADDRCONFIG, but AI_ADDRCONFIG has
troublesome behaviour on systems where the only IPv4 address is loopback
(reported years ago as , for example).

The intended behaviour of AI_ADDRCONFIG (I think) is to make, for example,
example.com resolve to an IPv6 address if you only have external IPv6
connectivity, an IPv4 address if you only have external IPv4 connectivity,
or both if you have both.

This makes complete sense if you are connecting to arbitrary Internet
hosts, or even to LAN hosts, but is actively hostile if you happen to be
"talking to yourself" in a unit test by connecting to ::1, 127.x.x.x or
localhost, which (as in this case) are very likely to be reachable via
IPv4 or IPv6 even if nothing else is.

Recent versions of GLib implement
https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02,
and also implement a special case that attempts to parse hostnames as
IPv4 or IPv6 addresses before trying name resolution; but libdbus doesn't
have either of those yet (partly because D-Bus over TCP is insecure and
discouraged, so I don't want to spend time improving it).

See also ,
.

smcv

Bug#960742: RFS: lazpaint/7.1.3 ITP -- add LazPaint to Debian

[Tobias Frost]

On Tue, Oct 13, 2020 at 07:27:19PM +0200, Johann ELSASS wrote:
> Interesting. I will consider using it.
> 
> So have you tried with the dependency change?

I'll need a .dsc file for that.
 
> -- 
>   Johann ELSASS
>   circu...@operamail.com
> 
> On Tue, Oct 13, 2020, at 4:23 PM, Tobias Frost wrote:
> > https://pbuilder-team.pages.debian.net/pbuilder/
> > 
> > TL;DR: debuilder builds your package, but in a possibly dirty environment
> > (as it uses your system and everything which is installed). pbuilder uses
> > a chroot which is always up-to-date, avoiding there are not-declared Build-
> > Dependencies or not updated packages. If it builds there, is is likely that
> > it will also build on the official buildds.
> > 
> > (Some alternative is sbuild, which behaviour is even closer to the buildds:
> > https://wiki.debian.org/sbuild).
> > 
> > -- 
> > tobi
> >

Bug#966087: LO saving failure

[Rene Engelhard]

[ also sending to the bug ]

Hi,

Am 13.10.20 um 19:41 schrieb Sulyok Attila:
> I prepared a bug report see below. I did not submit it, because I
> found the same bug reported under #966087.
>
> Have you any idea how to get free from this bug ?
>
As said already, I need info.


It works in a i386 test VM (on a amd64 host with KVM of course, so if
it's something only exhibiting on real (ld?) i386 hardware) I am not
able to test this.


Note also the buildlog
(https://buildd.debian.org/status/fetch.php?pkg=libreoffice=i386=1%3A7.0.2-2=1602499300=1)
doesn't show a test failure for saving stuff if I didn't overlook anything.

(Yes, it fails due to some numeric thingies. As upstream doesn't care
about 32bit at all... Thus also the failure is not deemed fatal,
otherwise we never would get a updated version into anything...)

Regards,


Rene

Bug#970810: python3-venv is gone

[Jyrki Pulliainen]

Hello,

A week to removal and I’m still looking for clarification to this issue

On Tue 6. Oct 2020 at 12.32, Jyrki Pulliainen  wrote:

> Hi,
>
> This needs some additional clarification, I'm not entirely sure what's
> going to happen. If I now tinker around with sid, the case is following:
>
> python3.8 does not install ensurepip, however it installs the venv module
> (which dh-virtualenv requires). However, command "python -m venv /tmp/foo"
> fails as expected, since ensurepip is missing.
>
> Now, python3.8-venv contains the ensurepip module. But to me it is very
> unclear if python3.8-venv is going to disappear? It also makes depending on
> these packages generally a lot more brittle: I'd rather depend on
> python3-venv than python3.8-venv. We are not depending on the
> /usr/bin/pyvenv binary, but executing the module with "python -m venv", so
> it does not matter if the python3-venv just drops the binary.
>
> Could you please clarify what is going to be removed, which packages are
> going to stay?
>
> On Thu, Sep 24, 2020 at 4:31 PM Jyrki Pulliainen  wrote:
>
>> On Thu 24. Sep 2020 at 16.02, Matthias Klose  wrote:
>>
>>> On 9/24/20 9:51 AM, Jyrki Pulliainen wrote:
>>>
>>> > Thanks for the bug report.
>>>
>>> >
>>>
>>> > Is pyvenv included in 3.8 in sid now? Package repository still lists
>>>
>>> > python3-venv as an available package in Sid
>>
>>
>>>
>>>
>>> it's still there, but will be gone for bullseye.
>>>
>>>
>> Ok thanks for the clarification!
>>
>> Is it included by default in python3? I tried eyeballing experimental
>> packages but failed miserably there to figure it out
>> --
>> - Jyrki
>>
>
>
> --
> - Jyrki
>
-- 
- Jyrki

Bug#942884: Bug#971395: RFS: zipios++/2.2.5.0-1 -- small C++ library for reading zip files (documents)

[Tobias Frost]

On Mon, Oct 12, 2020 at 06:06:58PM +0200, Tobias Frost wrote:
> 
> > > d/rules + d/control:
> > > - It looks like as your rules already supports building docs in
> > > build-indep.
> > >   Please see if you can move doxygen / graphviz B-D to Build-Depends-
> > > Indep.
> > 
> > Done
> 
> I have problems building only the arch:all packages, but I will
> need to investigate first if the problem is on my side.
> (Running out of time right now)

Following up on that one:
No, it was not on my side… It was a combination of limited build system support
for building only the documentation and more targets needs to be overriden in
d/rules for -arch and -indep.

It unearthed also a bug in the override for dh_auto_install-indep: The
generated makefile does not have a doc target…

I sent a MR towards you, which fixes this. The changes for this are:
- include /usr/share/dpkg/architecture.mk to get DEB_HOST_GNU_TYPE
- override override_dh_auto_configure-arch to only enable tests there.
- override_dh_auto_build-indep: use DEB_HOST_GNU_TYPE to enter build dir
  and use $(MAKE) zipios_Documentation to create docs. (make docs wont work)
- as make install is not working for docs only builds, 
override_dh_auto_install-indep
  simulating this.

In the same MR, I remove the manpages: I just saw (when debugging above)
that those are doxygen generated manpages and, franky, not very useful.
(on top, they are leaking build paths)

Another small fix:
d/copyright does not needed to be mentioned in libzipios++-doc.install.
Its picked up automatically. (so deleted the file)

d/dirs is not needed, and can be deleted.

I left it up to you to make nice d/changlog entries for those changes…
Afterwards I guess we are ready to upload it.

For subsequent uploads, you might want to take a look at:
usr/share/doc/libzipios-dev/html/classzipios_1_1VirtualSeeker.html,
why it has the buildpath in it. (lintian I-type tag)
(This possibly fixes also the reproducible build issue)

Cheers,
-- 
tobi
 

Bug#960742: RFS: lazpaint/7.1.3 ITP -- add LazPaint to Debian

[Johann ELSASS]

Interesting. I will consider using it.

So have you tried with the dependency change?

-- 
  Johann ELSASS
  circu...@operamail.com

On Tue, Oct 13, 2020, at 4:23 PM, Tobias Frost wrote:
> https://pbuilder-team.pages.debian.net/pbuilder/
> 
> TL;DR: debuilder builds your package, but in a possibly dirty environment
> (as it uses your system and everything which is installed). pbuilder uses
> a chroot which is always up-to-date, avoiding there are not-declared Build-
> Dependencies or not updated packages. If it builds there, is is likely that
> it will also build on the official buildds.
> 
> (Some alternative is sbuild, which behaviour is even closer to the buildds:
> https://wiki.debian.org/sbuild).
> 
> -- 
> tobi
>

Bug#970407: Update appreciated

[Martin Dosch]

Hi,

as the latest master of profanity requires libstrophe 0.10 I'd 
appreciate if it would be packaged for sid or at least experimental.


Best regards,
Martin


signature.asc
Description: PGP signature

Bug#763609: gnome-shell: keyboard layout switching ignored after unplug/plug USB keyboard

[Dmitry Borodaenko]

[cc to most recent uploaders to flag that this 6 years old bug is back]

This started happening to me after upgrade to gnome-shell 3.38.1. The
behavior I see is that SUPER-space on my laptop's keyboard still works
as expected, at the same time SUPER-space on my USB keyboard (connected
via USB hub in my monitor) works exactly as described by Ondřej:
keyboard switcher appears and they keyboard language indicator changes,
but the keyboard layout remains unchanged.

Mentions of keyboard, warnings, and errors in my journalctl before I
plug in the keyboard:

Oct 13 10:08:03 x1 systemd[1109]: Starting GNOME keyboard configuration 
service...
Oct 13 10:08:03 x1 systemd[1109]: Starting GNOME keyboard shortcuts service...
Oct 13 10:08:03 x1 systemd[1109]: 
app-gnome-user\x2ddirs\x2dupdate\x2dgtk-1422.scope: Failed to add PIDs to 
scope's control group: No such process
Oct 13 10:08:03 x1 systemd[1109]: 
app-gnome-user\x2ddirs\x2dupdate\x2dgtk-1422.scope: Failed with result 
'resources'.
Oct 13 10:08:03 x1 systemd[1109]: Failed to start Application launched by 
gnome-session-binary.
Oct 13 10:08:03 x1 gsd-usb-protect[1411]: Failed to fetch USBGuard parameters: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.usbguard1 
was not provided by any .service files
Oct 13 10:08:03 x1 systemd[1109]: Started GNOME keyboard shortcuts service.
Oct 13 10:08:03 x1 systemd[1109]: Reached target GNOME keyboard shortcuts 
target.
Oct 13 10:08:03 x1 systemd[1109]: Started GNOME keyboard configuration service.
Oct 13 10:08:03 x1 systemd[1109]: Reached target GNOME keyboard configuration 
target.
Oct 13 10:08:03 x1 gnome-shell[826]: Failed to set CRTC gamma: 
drmModeCrtcSetGamma on CRTC 51 failed: Permission denied
Oct 13 10:08:03 x1 gsd-media-keys[1400]: Failed to grab accelerator for 
keybinding settings:rfkill
Oct 13 10:08:03 x1 gsd-media-keys[1400]: Failed to grab accelerator for 
keybinding settings:playback-repeat
Oct 13 10:08:03 x1 gsd-media-keys[1400]: Failed to grab accelerator for 
keybinding settings:rotate-video-lock
Oct 13 10:08:03 x1 gsd-media-keys[1400]: Failed to grab accelerator for 
keybinding settings:playback-random
Oct 13 10:08:03 x1 gsd-media-keys[1400]: Failed to grab accelerator for 
keybinding settings:hibernate
Oct 13 10:08:03 x1 colord[742]: failed to get session [pid 1393]: No data 
available
Oct 13 10:08:03 x1 gnome-shell[826]: Failed to set CRTC gamma: 
drmModeCrtcSetGamma on CRTC 51 failed: Permission denied
Oct 13 10:08:04 x1 gnome-shell[826]: Connection to xwayland lost
Oct 13 10:08:04 x1 gdm-launch-environment][768]: 
pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm
Oct 13 10:08:04 x1 gdm-launch-environment][768]: 
pam_systemd(gdm-launch-environment:session): Failed to release session: 
Interrupted system call
Oct 13 10:08:04 x1 systemd-logind[710]: Session c1 logged out. Waiting for 
processes to exit.
Oct 13 10:08:04 x1 gsd-color[1393]: failed to connect to device: Failed to 
connect to missing device 
/org/freedesktop/ColorManager/devices/xrandr_LG_Display_Debian_gdm_117
Oct 13 10:08:10 x1 gnome-shell[1298]: Could not create transient scope for PID 
1553: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with 
ID 1553 does not exist.
Oct 13 10:08:10 x1 gnome-shell[1298]: Could not create transient scope for PID 
1554: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with 
ID 1554 does not exist.
Oct 13 10:08:16 x1 gnome-shell[1298]: Could not create transient scope for PID 
1558: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with 
ID 1558 does not exist.

Log of all journalctl messages after turning on my monitor is attached,
too long to include inline.

-- 
Dmitry Borodaenko
Oct 13 10:08:29 x1 kernel: usb 2-4: new SuperSpeed Gen 1 USB device number 2 
using xhci_hcd
Oct 13 10:08:29 x1 kernel: usb 2-4: New USB device found, idVendor=0451, 
idProduct=8140, bcdDevice= 1.00
Oct 13 10:08:29 x1 kernel: usb 2-4: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
Oct 13 10:08:29 x1 kernel: hub 2-4:1.0: USB hub found
Oct 13 10:08:29 x1 kernel: hub 2-4:1.0: 4 ports detected
Oct 13 10:08:30 x1 kernel: usb 1-4: new high-speed USB device number 10 using 
xhci_hcd
Oct 13 10:08:30 x1 kernel: usb 1-4: New USB device found, idVendor=0451, 
idProduct=8142, bcdDevice= 1.00
Oct 13 10:08:30 x1 kernel: usb 1-4: New USB device strings: Mfr=0, Product=0, 
SerialNumber=1
Oct 13 10:08:30 x1 kernel: usb 1-4: SerialNumber: CF010879D867
Oct 13 10:08:30 x1 kernel: hub 1-4:1.0: USB hub found
Oct 13 10:08:30 x1 kernel: hub 1-4:1.0: 4 ports detected
Oct 13 10:08:30 x1 kernel: usb 2-4.4: new SuperSpeed Gen 1 USB device number 3 
using xhci_hcd
Oct 13 10:08:30 x1 kernel: usb 2-4.4: New USB device found, idVendor=0451, 
idProduct=8140, bcdDevice= 1.00
Oct 13 10:08:30 x1 kernel: usb 2-4.4: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
Oct 13 10:08:30 x1 kernel: hub 2-4.4:1.0: USB hub found
Oct 13 10:08:30 x1 

Bug#971594: RFS: asciidoc/9.0.2-1 [ITA] -- Highly configurable text format for writing documentation

[Leon Marz]

The bug in nanoc has been fixed. I uploaded a new version of the package 
that doesn't include asciidoc-base.


- Leon

Bug#972174: s3fs segfault

[Noah Meyerhans]

Package: s3fs
Version: 1.84-1
Severity: important

I'm not sure yet what's leading to the problem, but I have observed
multiple segfaults of s3fs on buster.

I am starting it with the following options:

s3fs -o uid=33 -o gid=33 -o allow_other -o default_permissions -o umask=0007 -o 
iam_role=auto BUCKET /srv/mnt/s3fs

The corresponding dmesg output is:
Oct 13 03:24:29 ip-10-0-0-245 kernel: s3fs[22452]: segfault at 7f5c0002 ip 
7f5cca9194a6 sp 7f5cb6ffc690 error 4 in 
libc-2.28.so[7f5cca8b7000+148000]
Oct 13 03:24:29 ip-10-0-0-245 kernel: Code: 84 42 ff ff ff 0f 1f 80 00 00 00 00 
4a 8d 0c e0 48 8b 51 40 48 85 d2 0f 84 2a ff ff ff 48 81 fb ff 03 00 00 0f 87 
ba 01 00 00 <48> 8b 32 48 89 71 40 42 80 2c 20 01 48 c

There's nothing notable in the logs around the time of the crash, but
there are logs that might suggest issues with file descriptor management.
They may or may not be related at all:

Oct 12 02:14:00 ip-10-0-0-245 s3fs[9691]: s3fs.cpp:s3fs_read(2131): different 
fd(21 - 23)
Oct 12 16:20:59 ip-10-0-0-245 s3fs[9691]: s3fs.cpp:s3fs_read(2131): different 
fd(23 - 21)
Oct 13 01:29:49 ip-10-0-0-245 s3fs[9691]: s3fs.cpp:s3fs_read(2131): different 
fd(17 - 23)
Oct 13 02:59:36 ip-10-0-0-245 s3fs[9691]: s3fs.cpp:s3fs_read(2131): different 
fd(23 - 26)
Oct 13 02:59:37 ip-10-0-0-245 s3fs[9691]: s3fs.cpp:s3fs_read(2131): different 
fd(23 - 26)

Thanks.
noah

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

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

Versions of packages s3fs depends on:
ii  fuse 2.9.9-1+deb10u1
ii  libc62.28-10
ii  libcurl3-gnutls  7.64.0-4+deb10u1
ii  libfuse2 2.9.9-1+deb10u1
ii  libgcc1  1:8.3.0-6
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4+deb10u5
ii  libstdc++6   8.3.0-6
ii  libxml2  2.9.4+dfsg1-7+b3
ii  mime-support 3.62

s3fs recommends no packages.

s3fs suggests no packages.

-- no debconf information

Bug#972173: llvm-toolchain-10: add arm64 into ARCH_LLVM_TEST_OK, to enable nightly builds

[Sylvestre Ledru]

Le 13/10/2020 à 18:50, Leandro Nunes a écrit :

Source: llvm-toolchain-10
Severity: normal

Dear Maintainer,

In order to enable aarch64 (arm64) into the LLVM debian packages nightly build
we would like to add it to ARCH_LLVM_TEST_OK list, marking it as an architecture
in which tests are already run.

This list is defined in the debian/rules file, line 785:

  # List of the archs we know we have 100 % tests working
  ARCH_LLVM_TEST_OK := i386 amd64

The suggestion here is to add 'arm64' to that list above.

When we try to build is without having arm64 on that list, we see the following 
error:

I am not sure to see how ARCH_LLVM_TEST_OK is unrelated to this error.

If the arch isn't in the ARCH_LLVM_TEST_OK list, it won't fail the build.
See:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/blob/11/debian/rules#L799

"adt-run: not found" means that the autopkgtest package isn't installed

By the way, as part of your work, you should skip the testsuite and autopkgtest 
executions to avoid this pain.
export DEB_BUILD_OPTIONS="nocheck" to disable the local testsuite.

Cheers
S

Bug#949297:

[Archisman Panigrahi]

This bug has been fixed in Launchpad, and the fix has been released to
Ubuntu 20.04 and 20.10.
https://bugs.launchpad.net/ubuntu/+source/cheese/+bug/1879183

Bug#972173: llvm-toolchain-10: add arm64 into ARCH_LLVM_TEST_OK, to enable nightly builds

[Leandro Nunes]

Source: llvm-toolchain-10
Severity: normal

Dear Maintainer,

In order to enable aarch64 (arm64) into the LLVM debian packages nightly build
we would like to add it to ARCH_LLVM_TEST_OK list, marking it as an architecture
in which tests are already run.

This list is defined in the debian/rules file, line 785:

 # List of the archs we know we have 100 % tests working
 ARCH_LLVM_TEST_OK := i386 amd64

The suggestion here is to add 'arm64' to that list above.

When we try to build is without having arm64 on that list, we see the following 
error:

+ adt-run --help
+ grep -q -- --output-dir
/tmp/hooks/B20autopkgtest: 50: /tmp/hooks/B20autopkgtest: adt-run: not found
+ OUTPUT_OPTION=--tmp-dir
+ mkdir -p /tmp/buildd/autopkgtest.out
+ newpid adt-run --tmp-dir /tmp/buildd/autopkgtest.out --summary 
/tmp/buildd/autopkgtest.summary /tmp/buildd/clang-10-doc_10.0.1~++20201012$
+ EXIT=135
+ tar acf /tmp/buildd/autopkgtest.tar.gz /tmp/buildd/autopkgtest.out
tar: Removing leading `/' from member names
+ exit 135
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Bug#972168: pykdtree/kdtree.c ships without the cython source

[Antonio Valentino]

Dear Sebastiaan,
sorry for the late reply

> On 13 Oct 2020, at 17:31, Sebastiaan Couwenberg  wrote:
> 
> Control: tags -1 pending
> 
> On 10/13/20 4:13 PM, Matthias Klose wrote:
>> pykdtree/kdtree.c ships without the cython source.  So you cannot rebuild the
>> file from cython (and fixing the build failure with python 3.9).
> 
> De repo on salsa now uses the git release tags for the source tree, but
> setup.py does not cythonize the sources.
> 
> Antonio, do you think we should fix this upstream or just do it in
> d/rules like we do for _kdtree_core.c (which should also move to
> setup.py then)?
> 
> Kind Regards,
> 
> Bas

My idea is to fix it in the fastest possible way to unlock python 3.9 on debian.
I plan to work on it tonight.
Then I will send a couple of patches to pytroll to make the pykdtree a little 
bit more “packaging friendly”.


PS: probably also python-geotiepoints has a “cythonizaion” problem but in that 
case the fix should be easier.

--
Antonio Valentino

Bug#971683: postgresql-common: obsolete-conffile (apt.conf.d, createcluster.conf)

[Christoph Berg]

Re: Thorsten Glaser
> I’ve not looked at createcluster.conf but it will, most likely, also
> be caused by a similar packaging fault.

Yes, but renaming is not an option there.

I'll look into fixing this properly.

Thanks for spotting,
Christoph

Bug#968001: tightvnc-java: Invalid module description, or, may java module be mixed with other JARs in /usr/share/java?

[Sven Geuer]

Hi Giuseppe,

thank you for testing and giving your prompt reply.

I saw the same problem with jurt.jar like you now encountered with
jdom1.jar. I am afraid you have to open a bug against the appropriate
package.

Regarding tighvnc-java, it still will take me some time to get the new
package version ready for release. I hope it will not stretch your
patience to much.

Sven

Am Dienstag, den 13.10.2020, 08:09 +0200 schrieb Giuseppe Sacco:
> Hello Sven,
> 
> Il giorno lun, 12/10/2020 alle 23.09 +0200, Sven Geuer ha scritto:
> > Hello Guiseppe,
> > 
> > I believe I solved the issue. I'll send you another unreleased
> > version
> > of tighvnc-java in a separate email for you to test it.
> 
> Indeed the problem seems to be solved, in fact, now a different
> problem appears on a package :-)
> 
> $ java --module-path /usr/share/java \
>   --add-modules javafx.controls \
>   -Djavafx.preloader=lu.nowina.nexu.NexUPreLoader \
>   -Dglass.accessible.force=false -jar Neos.jar
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Two versions of module jdom1 found in
> /usr/share/java (jdom1-1.1.3.jar and jdom1.jar)
> 
> $ ls -l /usr/share/java/jdom*
> -rw-r--r-- 1 root root 156912  2 nov  2018 /usr/share/java/jdom1-
> 1.1.3.jar
> lrwxrwxrwx 1 root root 15  2 nov  2018 /usr/share/java/jdom1.jar
> -> jdom1-1.1.3.jar
> 
> Thanks,
> Giuseppe


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

Bug#972172: RM: netbeans -- NBS; no longer viable to maintain in Debian

[Markus Koschany]

Package: ftp.debian.org
Severity: normal

Dear ftp team,

please remove the following binary packages from unstable which were
built by src:netbeans.

libnb-apisupport3-java
libnb-ide14-java
libnb-java5-java
netbeans

They all belong to the Netbeans IDE which is no longer viable to
maintain in Debian.

Regards,

Markus

Bug#963269: Debian#963269 rdiff-backup 2.0 backport to Buster?

[Otto Kekäläinen]

Control: tags -1 confirmed, moreinfo

Hello!

Yes, technically I could do a backport for Buster. Note however that
doing so would create a package that replaces rdiff-backup 1.0 on the
next 'apt upgrade' and there might be some backwards incompatible
changes.

I'd like to have more people voice in here if there is really demand for this.

You could perhaps also installing a backport from the Ubuntu
backports: 
https://github.com/rdiff-backup/rdiff-backup#ubuntu-backports-for-older-versions-needs-a-backported-20

Bug#972168: pykdtree/kdtree.c ships without the cython source

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 10/13/20 4:13 PM, Matthias Klose wrote:
> pykdtree/kdtree.c ships without the cython source.  So you cannot rebuild the
> file from cython (and fixing the build failure with python 3.9).

De repo on salsa now uses the git release tags for the source tree, but
setup.py does not cythonize the sources.

Antonio, do you think we should fix this upstream or just do it in
d/rules like we do for _kdtree_core.c (which should also move to
setup.py then)?

Kind Regards,

Bas

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

Bug#970623: (no subject)

[Sudip Mukherjee]

Control: retitle -1 ITA: offlineimap -- IMAP/Maildir synchronization and reader 
support
owner -1 !
--

I will update the package to python3 port after testing it in my setup.


-- 
Regards
Sudip

Bug#972123: Please enable CONFIG_VIDEO_SUNXI_CEDRUS for Allwinner/sunxi

[Uwe Kleine-König]

Control: tag -1 + pending

Hello,

On Mon, Oct 12, 2020 at 03:06:50PM -0700, Damon Tarry wrote:
> Please enable CONFIG_VIDEO_SUNXI_CEDRUS to enable video decoding
> hardware on Allwinner/sunxi devices. This includes both arm64 and
> armhf (armmp) kernels.

I enabled this in both variants, see https://deb.li/ub2g . I don't know
the plans to upload 5.9 to sid, but eventually it will land there.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#970234: consider dropping "No hard links in source packages"

[Sam Hartman]

> "Bill" == Bill Allombert  writes:


Bill> I am pretty sure we were concerned about source packages being
Bill> unpackable on non Debian systems, though.

And I think we probably still are.  I was trying to capture the concerns
there in the part of my message you trimmed.


My rationale is that I don't think we want to work around an upstream
build system or repack sources just because it has hard links.  On the
other hand I also don't think we want to depend on hard links being
preserved.

Bug#972135: systemd: Fails to upgrade on NFS root filesystem (without ACL support)

[Michael Biebl]

Control: tags -1 + upstream

Am 13.10.20 um 05:52 schrieb Pat Coulthard:
> Package: systemd
> Version: 246.6-1
> Severity: normal
> 
> Systemd fails during an upgrade from buster to testing with an NFS mounted
> root filesystem. The issue appears to be that this filesystem doesn't support
> POSIX ACLs, which causes the postinst script to fail.
> 
> In this case, the NFS server is a Debian buster server running the standard
> Debian kernel.

[...]

> Setting access ACL "u::rwx,g::r-x,g:adm:r-x,m::r-x,o::r-x" on 
> /var/log/journal failed: Operation not supported

I'm not entirely sure, if it's the missing ACL support or some other
missing feature in NFS (at least on an ext4 file system where acl and
user_xattr support has been disabled via tune2fs -o ^acl I do not get
such a failure).

It's probably best if you file this upstream at
https://github.com/systemd/systemd.
I don't really have the necessary setup to be able to reproduce this myself.

The command in question is
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal

It's probably a good idea, if you run systemd-tmpfiles under strace and
attach the strace log to the upstream bug report.

Michael



signature.asc
Description: OpenPGP digital signature

Bug#960742: RFS: lazpaint/7.1.3 ITP -- add LazPaint to Debian

[Tobias Frost]

On Mon, Oct 12, 2020 at 09:00:21PM +0200, Johann ELSASS wrote:
> Hello,
> 
> I don't know if using pbuilder matters nor what pbuilder is.

https://pbuilder-team.pages.debian.net/pbuilder/

TL;DR: debuilder builds your package, but in a possibly dirty environment
(as it uses your system and everything which is installed). pbuilder uses
a chroot which is always up-to-date, avoiding there are not-declared Build-
Dependencies or not updated packages. If it builds there, is is likely that
it will also build on the official buildds.

(Some alternative is sbuild, which behaviour is even closer to the buildds:
https://wiki.debian.org/sbuild).

-- 
tobi

Bug#972171: turing: Depends on package qt5-default which is about to be removed

[Lisandro Damián Nicanor Pérez Meyer]

Source: turing
Version: 0.11~beta-2
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt5-default-removal
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Hi! Your package currently depends upon qt5-default. This package was not
intended to be used neither as a build dpeendency nor as a package dependency.

Moreover it has created more issues that it solved, so now that Qt 4 is gone
and Qt 5 is the default we are retiring it.

Anyways you can always check 
https://qt-kde-team.pages.debian.net/packagingqtbasedstuff.html
for more information.

Feel free to ping me if you need help.

Kinds regards, Lisandro.


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#972169: pykdtree points to the wrong upstream page

[Matthias Klose]

On 10/13/20 4:27 PM, Sebastiaan Couwenberg wrote:
> On 10/13/20 4:18 PM, Matthias Klose wrote:
>> debian/control and debian/copyright refer to:
>>
>> Homepage: https://github.com/pytroll/pykdtree
>>
>> which doesn't have any 1.3.x releases. Where does this package come from?
> 
> d/watch answers your question:
> 
>  https://pypi.debian.net/pykdtree/
> 
>> Setting this to serious, because the pykdtree.pxd file is missing in the 
>> Debian
>> source tarball, and there's no way to download it with the current 
>> information.
> 
> The upstream repo has the .pyx file:
> 
>  https://github.com/pytroll/pykdtree/blob/master/pykdtree/kdtree.pyx
> 
> It's not included in the PyPI sources because it's not included in
> MANIFEST.in.
> 
> If the repo tagged its releases to PyPI the git tags could be unused
> instead to have the complete source tree.

https://github.com/storpipfugl/pykdtree/pull/55

anyway, please add it and make sure it's rebuilt during the package build.

Bug#971786: [Pkg-javascript-devel] Bug#971786: Bug#971786: src:pdf.js: please package new upstream version

[Xavier]

Le 07/10/2020 à 17:13, Xavier a écrit :
> Le 07/10/2020 à 17:03, Carsten Schoenert a écrit :
>> Hello Xavier,
>>
>> Am 07.10.20 um 16:29 schrieb Xavier:
>>> Le 07/10/2020 à 10:29, Carsten Schoenert a écrit :
>>> this modules looks useless in Debian:
>>>  * no reverse-dependencies
>>
>> well, might simply because the version in Debian is far to old for all
>> possibly other packages. ;)
>> I haven't looked at packages that using now preshipped pdf.js.
>>
>>>  * one binary mas to be removed (xul component, #906835)
>>
>> Yes, obviously.
>>
>>>  * you're the first person who looks to it for a while ;-)
>>>
>>> Then do you need its update ? I can do it but it requires some work
>>> (zelenka.debian.org is working on it :-D).
>>
>> No hurry, I was today looking into upgrading kopano-webapp to 4.3 and
>> the Kopano is using pdf.js since version 4.0 here.
>>
>> There are other issues to solve, but using pdf.js from Debian would
>> prevent the requirement to use the embedded version.
> 
> OK, I'll update it

Hi,

I pushed my work to https://salsa.debian.org/js-team/pdf.js
Could you verify that this package is OK for you ?

Cheers,
Xavier

Bug#972167: texlive-lang: changed the pdftexconfig.tex file to /var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex, breaking paper size config

[Norbert Preining]

Hi

thanks for the report, indeed, indeed. That is btw a problem also
upstream. The problem is that the previous file under
TEXMFVAR/tex/generic/config/pdftexconfig.tex
is still present but changes are done in
TEXMFVAR/tex/generic/tex-ini-files/pdftexconfig.tex

Searching for all of these files with
kpsewhich -all pdftexconfig.tex
gives three hits.

Thanks, I will look into it (upstream and in Debian)!

Best

Norbert

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

Bug#972092: gnocchi-common: Creation of default gnocchi.conf should set resource_id

[Russell Coker]

On Tuesday, 13 October 2020 8:50:29 PM AEDT Thomas Goirand wrote:
> Instead, we could imagine prompting for a UUID if none is set, though
> I'm not really convince that this would be the correct thing to do.

Why not change the package description to indicate that it's not designed for 
any purpose other than OpenStack and should not be used as a separate thing?

Attempts to use it in other ways fail, the upstream documentation is no good, 
and there isn't Debian specific documentation for it.

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

Bug#972089: Backport hplip 3.20.5 to buster-backports

[Brian Potkin]

On Tue 13 Oct 2020 at 10:07:10 +0200, Alex ARNAUD wrote:

> Hello Didier,
> 
> Thanks for your quick answer.
> 
> There are multiple reasons why I use hplip:
> 
>  * First of all, I'm a visual-impaired guy and I help many other
>visual-impaired people using Debian, so the consequence we couldn't
>use the printer screen, we rely exclusively on HP Toolbox to get
>informations such as the status, the cartridge level, etc.
>  * To configure our printer to work on WIFI, we use hp-setup
> 
> Can I do the same with DriverlessPrinting?

As someone who has given a fair bit of help to other users I have
abandoned advising any use of vendor solutions (free or non-free) for
setting up a print queue with a modern printer. To my knowledge the
number of dissatisfied customers is zero :).

Alex, I would urge you to trial setting up queues for the printers you
have available. Personally, I always use lpadmin; two commands and this
fundamental job is done for a network connection. An alternative is to
rely on the auto-setup feature of cups-browsed.

  https://wiki.debian.org/DriverlessPrinting#shortlpadmin

There is also a big advantage in not having to deal with HP non-free
plugins. The amount of trouble they can give during an installation
is a pain.

Ink levels are generally shown in the Embedded Web Interface (EWS). I
do not comment on "status" because I am unsure what it involves.

> It seems sane-airscan is not available on Debian 10, only on Debian 11.

Alex Pevzner provides packages for Debian 10. I use one very successfully.

  https://download.opensuse.org/repositories/home:/pzz/Debian_10/

Cheers,

Brian.

Bug#972170: python3-bottle: Digestmod fix from v0.12.18 (Dec 2019) seems to be missing

[Ryan Esty]

Package: python3-bottle
Version: 0.12.15-2.1
Severity: normal
Tags: d-i

Dear Maintainer,

The upstream maintainer put in a fix
https://github.com/bottlepy/bottle/issues/1181 for hmac.new requiring a
digestmod.
This prevents anyone using set get cookies with the current version of
bottle at least on Ubuntu.
The bottle.py version from pip3 works but I just want to pass it along that
it seems to be missing from the Debian and Ubuntu packages.
The Ubuntu Package maintainers suggest I create a bug
https://answers.launchpad.net/ubuntu/+source/python-bottle/+question/693424.



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

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

Versions of packages python3-bottle depends on:
ii  python3  3.8.2-0ubuntu2

python3-bottle recommends no packages.

python3-bottle suggests no packages.

-- no debconf information

Bug#972169: pykdtree points to the wrong upstream page

[Sebastiaan Couwenberg]

On 10/13/20 4:18 PM, Matthias Klose wrote:
> debian/control and debian/copyright refer to:
> 
> Homepage: https://github.com/pytroll/pykdtree
> 
> which doesn't have any 1.3.x releases. Where does this package come from?

d/watch answers your question:

 https://pypi.debian.net/pykdtree/

> Setting this to serious, because the pykdtree.pxd file is missing in the 
> Debian
> source tarball, and there's no way to download it with the current 
> information.

The upstream repo has the .pyx file:

 https://github.com/pytroll/pykdtree/blob/master/pykdtree/kdtree.pyx

It's not included in the PyPI sources because it's not included in
MANIFEST.in.

If the repo tagged its releases to PyPI the git tags could be unused
instead to have the complete source tree.

Kind Regards,

Bas

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

Bug#972169: Acknowledgement (pykdtree points to the wrong upstream page)

[Matthias Klose]

looks like https://github.com/storpipfugl/pykdtree is the current page

Bug#972169: pykdtree points to the wrong upstream page

[Matthias Klose]

Package: src:pykdtree
Version: 1.3.1-4
Severity: serious
Tags: sid bullseye

debian/control and debian/copyright refer to:

Homepage: https://github.com/pytroll/pykdtree

which doesn't have any 1.3.x releases. Where does this package come from?

Setting this to serious, because the pykdtree.pxd file is missing in the Debian
source tarball, and there's no way to download it with the current information.

Bug#970234: consider dropping "No hard links in source packages"

[Bill Allombert]

On Tue, Oct 13, 2020 at 09:44:42AM -0400, Sam Hartman wrote:
> > "Giacomo" == Giacomo Catenazzi  writes:
> 
> Giacomo> The rationale was probably similar so symlinks: they may
> Giacomo> fail across different filesystems, and we supported to have
> Giacomo> e.g. / /usr /usr/share /usr/local /var (and various /var/*)
> Giacomo> /home /tmp /boot etc on different file systems. Now we are
> Giacomo> more strict on where we can split filesystems (and disk are
> Giacomo> larger, and LVM simplified much of filesystem handling).
> 
> But I think even in 1996, we anticipated a single source package
> (*source package*) being unpacked on a single filesystem.
> Perhaps we were worried about filesystems like umsdos?

It is good to see I am not the only one left who remember about umsdos!

I am pretty sure we were concerned about source packages being
unpackable on non Debian systems, though.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#972167: texlive-lang: changed the pdftexconfig.tex file to /var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex, breaking paper size config

[Vincent Lefevre]

Source: texlive-lang
Version: 2020.20200925-2
Severity: important

I've noticed that the upgrade to the texlive-lang packages changed
the pdftexconfig.tex file from

  /var/lib/texmf/tex/generic/config/pdftexconfig.tex

to

  /var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex

(as seen in "tl-paper status" output).

This apparently breaks paper size configuration: after setting the
papersize to letter with "dpkg-reconfigure libpaper1", I now get:

cventin:~> tl-paper status
Current context paper size (from 
/var/lib/texmf/tex/context/user/cont-sys-paper.tex): letter
Current dvipdfmx paper size (from /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): 
letter
Current dvips paper size (from /var/lib/texmf/dvips/config/config-paper.ps): 
letter
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/config/pdftexconfig.tex): a4
Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): letter

i.e. the pdftex paper size has not been affected. And now,

cventin:~> diff -u /var/lib/texmf/tex/generic/*/pdftexconfig.tex
--- /var/lib/texmf/tex/generic/config/pdftexconfig.tex  2020-09-21 
13:11:04.265767145 +0200
+++ /var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex   2020-10-13 
15:57:44.109817024 +0200
@@ -6,8 +6,8 @@
 \pdfoutput   = 1
 
 % Paper size: dimensions given in absolute terms
-\pdfpageheight   = 297 true mm
-\pdfpagewidth= 210 true mm
+\pdfpageheight   = 11 true in
+\pdfpagewidth= 8.5 true in
 
 % Enable PDF 1.5 output and thus more compression
 \pdfminorversion = 5

Note: before the "dpkg-reconfigure libpaper1", I got

cventin:~> kpsewhich --progname=pdftex --format=tex pdftexconfig.tex
/var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex

and now I get

cventin:~> kpsewhich --progname=pdftex --format=tex pdftexconfig.tex
/var/lib/texmf/tex/generic/config/pdftexconfig.tex

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

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

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

Bug#972168: pykdtree/kdtree.c ships without the cython source

[Matthias Klose]

Package: src:pykdtree
Version: 1.3.1-4
Severity: serious
Tags: sid bullseye

pykdtree/kdtree.c ships without the cython source.  So you cannot rebuild the
file from cython (and fixing the build failure with python 3.9).

Bug#971669: libopenmpi3: armel mipsel: mca_pmix_pmix3x.so: undefined symbol: OPAL_MCA_PMIX3X_PMIx_Get_version

[Alastair McKinstry]

On 13/10/2020 14:21, Drew Parsons wrote:

Source: openmpi
Version: 4.0.5-6
Followup-For: Bug #971669

mca_pmix_pmix3x.so and the undefined symbol are still showing in mumps builds 
with openmpi
4.0.5-6.


I did a test build on abel and mca_pmix_ext3x.so (matching other archs) 
is built instead of *_pmix3x.so. Need to figure out whats different 
between the sid schroot on abel


and the buildds.


--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

Bug#970234: consider dropping "No hard links in source packages"

[Sam Hartman]

> "Giacomo" == Giacomo Catenazzi  writes:

Giacomo> The rationale was probably similar so symlinks: they may
Giacomo> fail across different filesystems, and we supported to have
Giacomo> e.g. / /usr /usr/share /usr/local /var (and various /var/*)
Giacomo> /home /tmp /boot etc on different file systems. Now we are
Giacomo> more strict on where we can split filesystems (and disk are
Giacomo> larger, and LVM simplified much of filesystem handling).

But I think even in 1996, we anticipated a single source package
(*source package*) being unpacked on a single filesystem.
Perhaps we were worried about filesystems like umsdos?


I think that hard links in a source package are fine provided that
breaking the hard links would not either break the build or provide an
unreasonable space multiplier.

Bug#960132: Extra fixes neeeded in mdadm package

[Felix Lechner]

Hi Eric,

On Mon, Sep 28, 2020 at 10:00 AM Eric Desrochers
 wrote:
>

You commented on a bug that was closed. (Plus, I am not sure how your
five requests relate.) Please open a new bug.

> 3b7aae9 mdcheck: Log when done
> 6636788 mdcheck: when mdcheck_start is enabled, enable mdcheck_continue too.

I have no issue with backporting commits from upstream, and have in
fact been leaning on them for a new release.

> [PATCH 1/2] mdcheck: Prefix pause message with mdcheck
> [PATCH 2/2] mdcheck: Set a tag of mdcheck
> [PATCH] mdcheck: Remove extra spaces in systemd timer directives (Regression 
> fix for commit '6636788')

What is the status of these proposals, please? Are you asking me to
deploy them in Debian before they are accepted upstream? If so, please
explain why Debian should diverge from upstream. Thank you!

Kind regards
Felix Lechner

Bug#960132: mdadm: mdcheck_start.service trying to start unexisting file

[Felix Lechner]

Hi Richard,

On Fri, Sep 18, 2020 at 12:21 AM Richard Laager  wrote:
>
> found 960132 4.1-1
> severity 960132 serious

You commented on a bug that was closed. I believe those settings had no effect.

> This bug causes a shipped service (mdcheck_start.service) to completely
> fail to start, due to the fact that its script
> (/usr/share/mdadm/mdcheck) does not exist. A package should not release
> in that state.

Due to other comments this bug has become too long and too confusing.
Please open another bug if your issue still exists. Thank you!

Kind regards
Felix Lechner

Bug#972166: odin: Depends on package qt5-default which is about to be removed

[Lisandro Damián Nicanor Pérez Meyer]

Source: odin
Version: 2.0.4-0.1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt5-default-removal
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Hi! Your package currently depends upon qt5-default. This package was not
intended to be used neither as a build dpeendency nor as a package dependency.

Moreover it has created more issues that it solved, so now that Qt 4 is gone
and Qt 5 is the default we are retiring it.

Anyways you can always check 
https://qt-kde-team.pages.debian.net/packagingqtbasedstuff.html
for more information.

Feel free to ping me if you need help.

Kinds regards, Lisandro.


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#972164: gpsbabel: Depends on package qt5-default which is about to be removed

[Lisandro Damián Nicanor Pérez Meyer]

Source: gpsbabel
Version: 1.7.0+ds-5
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt5-default-removal
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Hi! Your package currently depends upon qt5-default. This package was not 
intended to be used neither as a build dpeendency nor as a package dependency.

Moreover it has created more issues that it solved, so now that Qt 4 is gone 
and Qt 5 is the default we are retiring it.

Anyways you can always check 
https://qt-kde-team.pages.debian.net/packagingqtbasedstuff.html
for more information.

Feel free to ping me if you need help.

Kinds regards, Lisandro.


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#972165: mkvtoolnix: Depends on package qt5-default which is about to be removed

[Lisandro Damián Nicanor Pérez Meyer]

Source: mkvtoolnix
Version: 51.0.0-1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt5-default-removal
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Hi! Your package currently depends upon qt5-default. This package was not
intended to be used neither as a build dpeendency nor as a package dependency.

Moreover it has created more issues that it solved, so now that Qt 4 is gone
and Qt 5 is the default we are retiring it.

Anyways you can always check 
https://qt-kde-team.pages.debian.net/packagingqtbasedstuff.html
for more information.

Feel free to ping me if you need help.

Kinds regards, Lisandro.


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#972163: fwbuilder: Depends on package qt5-default which is about to be removed

[Lisandro Damián Nicanor Pérez Meyer]

Source: fwbuilder
Version: 5.3.7-4
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt5-default-removal
X-Debbugs-Cc: pkg-kde-t...@alioth-lists.debian.net

Hi! Your package currently depends upon qt5-default. This package was not 
intended to be used neither as a build dpeendency nor as a package dependency.

Moreover it has created more issues that it solved, so now that Qt 4 is gone 
and Qt 5 is the default we are retiring it.

Anyways you can always check 
https://qt-kde-team.pages.debian.net/packagingqtbasedstuff.html
for more information.

Feel free to ping me if you need help.

Kinds regards, Lisandro.


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#972162: enki-aseba: Depends on package qt5-default which is about to be removed

[Lisandro Damián Nicanor Pérez Meyer]

Source: enki-aseba
Version: 1:1.6.99-1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt5-default-removal
X-Debbugs-Cc: pkg-kde-t...@alioth-lists.debian.net

Hi! Your package currently depends upon qt5-default. This package was not
intended to be used neither as a build dpeendency nor as a package dependency.

Moreover it has created more issues that it solved, so now that Qt 4 is gone
and Qt 5 is the default we are retiring it.

Anyways you can always check 
https://qt-kde-team.pages.debian.net/packagingqtbasedstuff.html
for more information.

In your specific case you only need to remove the package from build 
dependencies.
Your package uses CMake so it should just work or require a very easy fix. Feel
free to ping me if you need help.

Kinds regards, Lisandro.

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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971669: libopenmpi3: armel mipsel: mca_pmix_pmix3x.so: undefined symbol: OPAL_MCA_PMIX3X_PMIx_Get_version

[Drew Parsons]

Source: openmpi
Version: 4.0.5-6
Followup-For: Bug #971669

mca_pmix_pmix3x.so and the undefined symbol are still showing in mumps builds 
with openmpi
4.0.5-6.

Bug#972161: buster-pu: package ruby2.5/2.5.5-3+deb10u3

[Utkarsh Gupta]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
X-Debbugs-CC: debian-r...@lists.debian.org
Severity: normal

Hello,

ruby2.5 was affected by CVE-2020-25613, where WEBrick, a simple HTTP
server bundled with Ruby, had not checked the transfer-encoding header
value rigorously.

This has been fixed in Sid, Bullseye, and Stretch.
Here's the debdiff for buster-pu:

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<

diff -Nru ruby2.5-2.5.5/debian/changelog ruby2.5-2.5.5/debian/changelog
--- ruby2.5-2.5.5/debian/changelog2020-07-04 00:07:58.0 +0530
+++ ruby2.5-2.5.5/debian/changelog2020-10-13 18:32:32.0 +0530
@@ -1,3 +1,10 @@
+ruby2.5 (2.5.5-3+deb10u3) buster; urgency=high
+
+  * Add patch to fix a potential HTTP request smuggling
+vulnerability in WEBrick. (Fixes: CVE-2020-25613)
+
+ -- Utkarsh Gupta   Tue, 13 Oct 2020 18:32:32 +0530
+
 ruby2.5 (2.5.5-3+deb10u2) buster-security; urgency=high

   * Non-maintainer upload by the Security Team.
diff -Nru ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch
ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch
--- ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch1970-01-01
05:30:00.0 +0530
+++ ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch2020-10-13
18:31:51.0 +0530
@@ -0,0 +1,30 @@
+From 8946bb38b4d87549f0d99ed73c62c41933f97cc7 Mon Sep 17 00:00:00 2001
+From: Yusuke Endoh 
+Date: Tue, 29 Sep 2020 13:15:58 +0900
+Subject: [PATCH] Make it more strict to interpret some headers
+
+Some regexps were too tolerant.
+
+--- a/lib/webrick/httprequest.rb
 b/lib/webrick/httprequest.rb
+@@ -226,9 +226,9 @@
+ raise HTTPStatus::BadRequest, "bad URI `#{@unparsed_uri}'."
+   end
+
+-  if /close/io =~ self["connection"]
++  if /\Aclose\z/io =~ self["connection"]
+ @keep_alive = false
+-  elsif /keep-alive/io =~ self["connection"]
++  elsif /\Akeep-alive\z/io =~ self["connection"]
+ @keep_alive = true
+   elsif @http_version < "1.1"
+ @keep_alive = false
+@@ -475,7 +475,7 @@
+   return unless socket
+   if tc = self['transfer-encoding']
+ case tc
+-when /chunked/io then read_chunked(socket, block)
++when /\Achunked\z/io then read_chunked(socket, block)
+ else raise HTTPStatus::NotImplemented, "Transfer-Encoding: #{tc}."
+ end
+   elsif self['content-length'] || @remaining_size
diff -Nru ruby2.5-2.5.5/debian/patches/series
ruby2.5-2.5.5/debian/patches/series
--- ruby2.5-2.5.5/debian/patches/series2020-07-04 00:06:34.0 +0530
+++ ruby2.5-2.5.5/debian/patches/series2020-10-13 18:32:04.0 +0530
@@ -15,3 +15,4 @@
 0015-lib-shell-command-processor.rb-Shell-prevent-unknown.patch
 CVE-2020-10933.patch
 CVE-2020-10663.patch
+CVE-2020-25613.patch

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<

- u
---

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

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

Bug#972151: glib2.0: gdbus-server-auth test consistently fails on arm-conova-03 but nowhere else

[Paul Wise]

On Tue, Oct 13, 2020 at 11:12 AM Simon McVittie wrote:

> What hardware is arm-conova-03 running on? Is it the same as amdahl, which
> has a similar description on db.debian.org?

Both are running on the ganeti cluster at Conova, made up of
conova-node01 and conova-node02. Looks like amdahl is currently
running on the other node than arm-conova-03 but arm-conova-02
currently runs on the same node as arm-conova-03. I'm not sure what
hardware the nodes are but they appear to be identical.

pabs@conova-node01:~$ sudo gnt-instance  list
Instance Hypervisor OS   Primary_node Status  Memory
amdahl.debian.orgkvmnoop conova-node01.debian.org running  12.0G
arm-conova-01.debian.org kvmnoop conova-node01.debian.org running  12.0G
arm-conova-02.debian.org kvmnoop conova-node02.debian.org running  12.0G
arm-conova-03.debian.org kvmnoop conova-node02.debian.org running  12.0G

> Is there anything odd about how arm-conova-03's filesystem or /tmp works,
> perhaps using tmpfs or NFS where other buildds don't, or not using tmpfs
> where other buildds do, or an unusual level of load?

There is no tmpfs mounted on /tmp, that is part of the ext4 from /

> Or is there anything odd about arm-conova-03's TCP or other networking
> setup?

arm-conova-03 does not have an IPv4 address/route except on the
loopback device but amdahl, arm-conova-01 and arm-conova-02 do.

I would bet on the test not working on IPv6-only systems.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#952724: "warning: ICC support is not available" warnings

[debian]

Hi,

I've traced the error to the mupdf source. In mupdf-1.18

In source/fitz/colorspace.c:

#if FZ_ENABLE_ICC

[..]

#else

[..]

void fz_enable_icc(fz_context *ctx)
{
fz_warn(ctx, "ICC support is not available");
}

[..]

#endif

I have no idea of mupdf packaging, but it seems that we could either
compile mupdf with ICC or disable the warning using a patch.

Anybody wants to chip in on this?

Cheers,
Ben

Bug#972106: setzer: Never migrated to Debian Testing (non-source-only upload)

[Stephan Lachnit]

Hi Boyuan,

> I noticed that the package setzer in Debian ( 
> https://tracker.debian.org/pkg/setzer ) never migrated to Debian Testing 
> because all uploads are not source-only upload. This prevents the package 
> from appearing in future Debian Stable releases (prospective Debian 11). 
> Please make another source-only upload to fix this problem.

I was already aware of that, but just didn't have the time to do it / search 
for a sponsor. I'm currently applying for a DM status (already approved, just 
waiting for my key to be uploaded), so I figured I rather wait until that is 
done and upload the latest version myself.

Cheers,
Stephan

Bug#972160: deepin-qt5dxcb-plugin: FTBFS with Qt 5.15: Project ERROR: Could not find feature xcb-xinput.

[Dmitry Shachnev]

Source: deepin-qt5dxcb-plugin
Version: 5.0.1-3.1
Severity: important
Tags: ftbfs
User: debian-qt-...@lists.debian.org
Usertags: qt5.15

Dear Maintainer,

deepin-qt5dxcb-plugin fails to build with Qt 5.15, currently available in
experimental:

  make -j1
  make[1]: Entering directory '/build/deepin-qt5dxcb-plugin-5.0.1'
  cd platformplugin/ && ( test -e Makefile.qt5platform-plugin || 
/usr/lib/qt5/bin/qmake [...] ) && make -f Makefile.qt5platform-plugin 
  sh: 1: git: not found
  Project ERROR: Could not find feature xcb-xinput.
  make[1]: *** [Makefile:47: 
sub-platformplugin-qt5platform-plugin-pro-make_first] Error 3

The full build log is attached.

--
Dmitry Shachnev
I: pbuilder: network access will be disabled during build
I: Current time: Tue Oct 13 15:27:21 MSK 2020
I: pbuilder-time-stamp: 1602592041
I: Building the build Environment
I: extracting base tarball [/home/dmitry/pbuilder/experimental-base.tgz]
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage 
for details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [deepin-qt5dxcb-plugin_5.0.1-3.1.dsc]
I: copying [./deepin-qt5dxcb-plugin_5.0.1.orig.tar.gz]
I: copying [./deepin-qt5dxcb-plugin_5.0.1-3.1.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/tmp/dpkg-verify-sig.c7BTpKrT/trustedkeys.kbx': 
General error
gpgv: Signature made Tue Oct 13 12:26:43 2020 UTC
gpgv:using RSA key E7AF3C82A7B83D2BAC51970B6646265B586B83CB
gpgv:issuer "mity...@debian.org"
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on 
./deepin-qt5dxcb-plugin_5.0.1-3.1.dsc
dpkg-source: info: extracting deepin-qt5dxcb-plugin in 
deepin-qt5dxcb-plugin-5.0.1
dpkg-source: info: unpacking deepin-qt5dxcb-plugin_5.0.1.orig.tar.gz
dpkg-source: info: unpacking deepin-qt5dxcb-plugin_5.0.1-3.1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 
0001-libqt5xcbqpa-dev-Add-support-for-Qt-5.12.5.patch
dpkg-source: info: applying 
0002-libqt5xcbqpa-dev-Add-support-for-Qt-5.14.2.patch
I: Not using root during the build.
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper-compat (= 12), libcairo2-dev, libdbus-1-dev, libdtkcore-dev 
(>= 2.0.5.2-2~), libegl1-mesa-dev, libfontconfig1-dev, libfreetype6-dev, 
libglib2.0-dev, libmtdev-dev, libqt5opengl5-dev, libqt5x11extras5-dev, 
libsm-dev, libudev-dev, libx11-xcb-dev, libxcb-composite0-dev, 
libxcb-damage0-dev, libxcb-icccm4-dev, libxcb-image0-dev, libxcb-keysyms1-dev, 
libxcb-randr0-dev, libxcb-render-util0-dev, libxcb-sync-dev, 
libxcb-xinerama0-dev, libxcb-xinput-dev, libxcb-xkb-dev, libxi-dev, 
libxkbcommon-x11-dev, libxrender-dev, pkg-config, qtbase5-dev, 
qtbase5-private-dev (>= 5.15)
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 15351 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on debhelper-compat (= 12); however:
  Package debhelper-compat is not installed.
 pbuilder-satisfydepends-dummy depends on libcairo2-dev; however:
  Package libcairo2-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libdbus-1-dev; however:
  Package libdbus-1-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libdtkcore-dev (>= 2.0.5.2-2~); 
however:
  Package libdtkcore-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libegl1-mesa-dev; however:
  Package libegl1-mesa-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libfontconfig1-dev; however:
  Package libfontconfig1-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libfreetype6-dev; however:
  Package libfreetype6-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libglib2.0-dev; however:
  Package libglib2.0-dev is 

Bug#972159: pdns-recursor: CVE-2020-25829: cache pollution issue

[Salvatore Bonaccorso]

Source: pdns-recursor
Version: 4.3.4-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for pdns-recursor.

CVE-2020-25829[0]:
| cache pollution issue

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-25829
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25829
[1] 
https://docs.powerdns.com/recursor/security-advisories/powerdns-advisory-2020-07.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#970234: consider dropping "No hard links in source packages"

[Giacomo Catenazzi]

Hello Helmut

On 12.10.2020 19:30, Helmut Grohne wrote:


You appear to be talking about binary packages. This bug is about source
packages. When you unpack a source package, you are creating a directory
hiearchy rooted at the point where you start unpacking. There is not
possibly any reasonable way to split your source package into multiple
file systems. This is very different from binary packages where the
underlying hiearchy is shared with other packages and directories
frequently already exist.


Your are totally right. And it is also on the subject line.

So: I have not reasonable explanation.

ciao
cate

Bug#972158: falkon: FTBFS with Qt 5.15: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

[Dmitry Shachnev]

Source: falkon
Version: 3.1.0+dfsg1-8
Severity: important
Tags: ftbfs fixed-upstream
User: debian-qt-...@lists.debian.org
Usertags: qt5.15
Forwarded: https://invent.kde.org/network/falkon/-/merge_requests/3

Dear Maintainer,

falkon fails to build with Qt 5.15, currently available in experimental.

After successfully rebuilding kguiaddons and kxmlgui, I get this error:

  /<>/src/lib/tools/qztools.cpp:413:18: error: aggregate 
‘QPainterPath path’ has incomplete type and cannot be defined
413 | QPainterPath path;
|  ^~~~

This is fixed upstream, see the linked merge request.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#971789: FTBFS: Could not determine section for ./.gopath/src/github.com/docker/cli/man/man1/docker-attach.1

[Sascha Steinbiss]

Hi,

has anyone taken any action here already? Some of my packages are
affected by this as well.

Cheers
Sascha

Bug#972154: qtcurve: FTBFS with Qt 5.15: error: field ‘path’ has incomplete type ‘QPainterPath’

[Dmitry Shachnev]

Source: qtcurve
Version: 1.9-6
Severity: important
Tags: ftbfs fixed-upstream
User: debian-qt-...@lists.debian.org
Usertags: qt5.15
Forwarded: https://invent.kde.org/system/qtcurve/-/merge_requests/1

Dear Maintainer,

qtcurve fails to build with Qt 5.15, currently available in experimental.

After successfully rebuilding frameworkintegration, kguiaddons and kxmlgui,
I get this error:

  In file included from /<>/qt5/config/qtcurveconfig.cpp:35:
  /<>/qt5/style/qtcurve.h:103:22: error: field ‘path’ has 
incomplete type ‘QPainterPath’
103 | QPainterPath path;
|  ^~~~
  In file included from /usr/include/x86_64-linux-gnu/qt5/QtGui/QFont:1,
   from /<>/qt5/common/common.h:47,
   from /<>/qt5/config/qtcurveconfig.h:26,
   from /<>/qt5/config/qtcurveconfig.cpp:26:
  /usr/include/x86_64-linux-gnu/qt5/QtGui/qfont.h:327:18: note: forward 
declaration of ‘class QPainterPath’
327 | friend class QPainterPath;
|  ^~~~

This is fixed upstream, see the linked merge request.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#972152: nextcloud-desktop: segfault with libQt5Core.so.5.11.3 after resuming from hibernate

[alain]

Package: nextcloud-desktop
Version: 2.5.1-3+deb10u1
Severity: important

Dear Maintainer,

Nextcloud-desktop crashed with this log :
kernel: [ 6526.266755] nextcloud[3314]: segfault at 7fffe97b0fe8 ip 
7f646a4174c0 sp 7fffe97b0ff0 error 6 in 
libQt5Core.so.5.11.3[7f646a3d1000+2a4000]
kernel: [ 6526.266780] Code: d1 89 f2 55 53 89 f3 48 83 ec 10 48 8b 3f 8b 07 83 
f8 01 77 0b 48 83 7f 10 18 0f 84 92 00 00 00 be 08 00 00 00 bf 01 00 00 00  
eb df ff ff 48 89 c5 48 85 c0 0f 84 5d e2 fb ff 49 8b 34 24 83


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

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

Versions of packages nextcloud-desktop depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libnextcloudsync0 2.5.1-3+deb10u1
ii  libqt5concurrent5 5.11.3+dfsg1-1+deb10u4
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u4
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u4
ii  libqt5gui55.11.3+dfsg1-1+deb10u4
ii  libqt5keychain1   0.9.1-2
ii  libqt5network55.11.3+dfsg1-1+deb10u4
ii  libqt5positioning55.11.3+dfsg-2
ii  libqt5printsupport5   5.11.3+dfsg1-1+deb10u4
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u4
ii  libqt5webchannel5 5.11.3-2
ii  libqt5webenginecore5  5.11.3+dfsg-2+deb10u1
ii  libqt5webenginewidgets5   5.11.3+dfsg-2+deb10u1
ii  libqt5webkit5 5.212.0~alpha2-21
ii  libqt5widgets55.11.3+dfsg1-1+deb10u4
ii  libqt5xml55.11.3+dfsg1-1+deb10u4
ii  libsqlite3-0  3.27.2-3
ii  libssl1.1 1.1.1d-0+deb10u3
ii  libstdc++68.3.0-6
ii  nextcloud-desktop-common  2.5.1-3+deb10u1
ii  nextcloud-desktop-l10n2.5.1-3+deb10u1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  2.5.1-3+deb10u1

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#972153: python-fakeredis autopkg test fails

[Matthias Klose]

Package: src:python-fakeredis
Version: 1.4.3-1
Severity: serious
Tags: sid bullseye

python-fakeredis autopkg test fails. missing test dependency?


[...]
test/test_fakeredis.py::test_lastsave[FakeStrictRedis] PASSED[ 67%]
test/test_fakeredis.py::test_time[FakeStrictRedis] ERROR [ 67%]

 ERRORS 
_ ERROR at setup of test_time[FakeStrictRedis] _
file /tmp/autopkgtest-lxc.tksev830/downtmp/build.Tqp/src/test/test_fakeredis.py,
line 3361
  @fake_only
  def test_time(r, mocker):
E   fixture 'mocker' not found
>   available fixtures: cache, capfd, capfdbinary, caplog, capsys,
capsysbinary, cov, create_redis, doctest_namespace, fake_server,
is_redis_running, monkeypatch, no_cover, pytestconfig, r, record_property,
record_testsuite_property, record_xml_attribute, recwarn, tmp_path,
tmp_path_factory, tmpdir, tmpdir_factory
>   use 'pytest --fixtures [testpath]' for help on them.

/tmp/autopkgtest-lxc.tksev830/downtmp/build.Tqp/src/test/test_fakeredis.py:3361
=== 760 passed, 26 skipped, 1 error in 23.98 seconds ===
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:9:
DeprecationWarning: the imp module is deprecated in favour of importlib; see the
module's documentation for alternative uses
  import imp
autopkgtest [20:17:10]: test command1: ---]
autopkgtest [20:17:10]: test command1:  - - - - - - - - - - results - - - - - -
- - - -
command1 FAIL non-zero exit status 1

Bug#972150: [Pkg-javascript-devel] Bug#972150: node-debbundle-acorn: lack versions for provided virtual packages

[Xavier]

Le 13/10/2020 à 13:03, Jonas Smedegaard a écrit :
> Package: node-debbundle-acorn
> Version: 8.0.4+ds+~cs13.19.27-3
> Severity: important
>
> acorn and related packages are now provided by a bundle package.
> 
> That's fine.
> 
> Problematic, however, that virtual packages are provided without version,
> making it hard to handle versioned relationships.
> 
> it seems no packages are directly affected by this
> (becuase node-debbundle-insert-module-globals is consumed by the bundle)
> but that is because package relations for emscripten is sloppy.
> 
> Please declare the version for each of the bundled modules.
> 
> See source package jsbundle-web-interfaces for a way to do it.
> What is done there is to _first_ use the module version
> and then _append_ the version of the bundle package -
> to ensure that binary package gets updated whenever bundle source is changed.
> 
>  - Jonas

Hi,

a `dpkg --control` shows this (automatically provided by ${nodejs:Provides}:

  Provides: acorn (= 8.0.4+ds+~cs13.19.27-2),
node-acorn (= 8.0.4+ds+~cs13.19.27-2),
node-acorn-bigint (= 1.0.0),
node-acorn-class-fields (= 0.3.7),
node-acorn-dynamic-import (= 4.0.0),
node-acorn-export-ns-from (= 0.2.0),
node-acorn-import-meta (= 1.1.0),
node-acorn-jsx (= 5.3.1),
node-acorn-loose (= 8.0.0),
node-acorn-node (= 2.0.1),
node-acorn-numeric-separator (= 0.3.4),
node-acorn-private-class-elements (= 0.2.7),
node-acorn-private-methods (= 0.3.3),
node-acorn-static-class-features (= 0.2.4),
node-acorn-walk (= 8.0.0)

So what can I do to resolve this bug ? Split acorn into multiple
packages (and then go back to NEW queue for some months) ?

Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary

[John Lines]

On Mon, 15 Sep 2008 11:22:41 +0200 Erik Rossen 
wrote:
> On Tue, Sep 02, 2008 at 10:48:30AM -0400, Michael Stone wrote:
> > On Tue, Sep 02, 2008 at 03:50:16PM +0200, Erik Rossen wrote:
> > >But it would be so much more elegant if chmod just Did The Right
Thing.
> > 
> > It's certainly arguable whether adding another non-standard flag is
the 
> > Right Thing when it's fairly trivial to get the result in a more 
> > portable fashion using find(1).
> 
> It seems that the FreeBSD people think that making a change to the
> filesystem only when necessary is The Right Thing.  But I guess that
> argument carries no weight in GNU. ;-)
> 
> > >Can I ask you to pass along this wishlist item to upstream and
maybe ask
> > >them why ctime must be modified even when the permissions are
not?  I
> > >would really like to know why.
> > 
> > Upstream monitors the debian bug logs and will presumably chime in
if 
> > interested. I vaguely recall that people want these utilities to
act 
> > even if not strictly necessary because of possible side effects
for 
> > extended attributes.
> > 
> > Mike Stone
> 
> I took your advice (paraphrased: "try another tool") and I now have
> three options for fixing file permissions without disturbing the file
> system too much:
> 
> 1.  find + chmod : classic but ugly
> 
> 2.  cfengine : Does The Right Thing, but difficult to do as a one-
liner
> unless you are already using cfengine for other stuff
> 
> 3.  setfacl -R : nice.  Does The Right Thing as a fairly simple one-
liner
> 
> setfacl is kind of interesting.  Even if the filesystem is mounted
> without extended ACLs enabled, it works for setting the POSIX ACLs
and
> it Does The Right Thing.  For example, I can do
> 
>   setfacl -R -m u::rwX,g::rwX,o:rX shares/
> 
> to fix every file and directory in "shares" to be readable, and
writable
> only by the owner and group of shares.  And if I run the same command
> again, stat shows that the ctime has not changed unless it was
necessary
> to modify the permissions of a file or directory.
> 
> I am pretty happy about this solution and I intend to use it in cases
> where there is a integrity-checker in place and no cfengine.
> 
> But while doing my tests, I noticed something strange about setfacl:
if
> the filesystem is mounted with extended ACLs enabled (on a ext3 fs),
it
> is possible to use setfacl to make changes to file permissions and
CTIME
> IS NEVER MODIFIED EVEN IF PERMISSIONS ARE MODIFIED.  I thought that
this
> was supposed to be impossible, but perhaps this is a known side-
effect
> ("feature") of activating extended ACLs on ext3.
> 
> Can anyone else confirm this?  I am running etch with an ext3
filesystem
> that was created in June 2008. This is my "uname -a":
> 
>   Linux mango 2.6.18-6-vserver-686 #1 SMP Mon Aug 18 11:11:15 UTC
2008 i686 GNU/Linux
> 

I have another use-case for only attempting to make a change with chmod
if it is really necessary.

In a Debian postinst script (for VDR in this particular case) the
ownership of a directory (/var/lib/video) is changed - however I have
moved /var/lib/video to be a symlink to an NFS server. The permissions
are already set correctly, but as root can not (in this case) change an
NFS mounted file system, the chmod fails, even though it wanted to
change the owner to be the same as it already was.

A switch for chmod to say --only-if-needed or some such would avoid
this being an issue

John

Bug#960304: snapshot.debian.org: Snapshot repo repeatedly cutting off connection, returning partial content

[Björn Stenberg]

Severity: serious

This problem is still present, and is making the snapshot service unusable
for many people.

At the time of writing, this is the status:

$ wget
https://snapshot.debian.org/archive/debian/20200917T084540Z/pool/main/libr/libreoffice/libreoffice-dbg_4.3.3-2%2Bdeb8u11_amd64.deb
--2020-10-13 12:50:28--
https://snapshot.debian.org/archive/debian/20200917T084540Z/pool/main/libr/libreoffice/libreoffice-dbg_4.3.3-2%2Bdeb8u11_amd64.deb
Resolving snapshot.debian.org (snapshot.debian.org)... 193.62.202.27,
185.17.185.185, 2001:630:206:4000:1a1a:0:c13e:ca1b, ...
Connecting to snapshot.debian.org (snapshot.debian.org)|193.62.202.27|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 739029194 (705M)
Saving to: ‘libreoffice-dbg_4.3.3-2+deb8u11_amd64.deb.4’

libreoffice-dbg_4.3.3-2+deb8   3%[>
   ]  25,03M  11,1MB/sin 2,3s

2020-10-13 12:50:31 (11,1 MB/s) - Connection closed at byte 26247168.
Retrying.

--2020-10-13 12:50:32--  (try: 2)
https://snapshot.debian.org/archive/debian/20200917T084540Z/pool/main/libr/libreoffice/libreoffice-dbg_4.3.3-2%2Bdeb8u11_amd64.deb
Connecting to snapshot.debian.org (snapshot.debian.org)|193.62.202.27|:443...
connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 739029194 (705M), 712782026 (680M) remaining
Saving to: ‘libreoffice-dbg_4.3.3-2+deb8u11_amd64.deb.4’

libreoffice-dbg_4.3.3-2+deb8   7%[+=>
   ]  52,22M  10,9MB/sin 2,5s

2020-10-13 12:50:34 (10,9 MB/s) - Connection closed at byte 54755328.
Retrying.

--2020-10-13 12:50:36--  (try: 3)
https://snapshot.debian.org/archive/debian/20200917T084540Z/pool/main/libr/libreoffice/libreoffice-dbg_4.3.3-2%2Bdeb8u11_amd64.deb
Connecting to snapshot.debian.org (snapshot.debian.org)|193.62.202.27|:443...
connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 739029194 (705M), 684273866 (653M) remaining
Saving to: ‘libreoffice-dbg_4.3.3-2+deb8u11_amd64.deb.4’

libreoffice-dbg_4.3.3-2+deb8   9%[+++>
]  66,02M  9,89MB/sin 1,4s

2020-10-13 12:50:38 (9,89 MB/s) - Connection closed at byte 69222400.
Retrying.

--2020-10-13 12:50:41--  (try: 4)
https://snapshot.debian.org/archive/debian/20200917T084540Z/pool/main/libr/libreoffice/libreoffice-dbg_4.3.3-2%2Bdeb8u11_amd64.deb
Connecting to snapshot.debian.org (snapshot.debian.org)|193.62.202.27|:443...
connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 739029194 (705M), 669806794 (639M) remaining
Saving to: ‘libreoffice-dbg_4.3.3-2+deb8u11_amd64.deb.4’

libreoffice-dbg_4.3.3-2+deb8  12%[>
   ]  88,97M  10,5MB/sin 2,2s

2020-10-13 12:50:44 (10,5 MB/s) - Connection closed at byte 93290496.
Retrying.

^C
$

As you can see, the connection is forcibly closed by the server and wget
has to retry repeatedly. Apt does not retry connections by default, instead
it fails completely. You have to rerun the apt command again and again
until all packages are successfully downloaded, which can require a large
number of retries and a very long time.

It is not always trivial to trigger this bug. It comes and goes with time,
perhaps due to general network load. One rather reliable way of triggering
it seems to be to install buster on a machine and then dist-upgrade to a
recent snapshot. This results in a large number of downloads, which
snapshot eventually starts to abort. Once it has started
aborting downloads, the bug can be triggered by plain wget or curl calls.

The source of the problem is unidentified, but one guess is that Varnish
somehow erroneously interprets the rapid file accesses as a
denial-of-service attack and applies restrictions.

/Björn

Bug#972076: tasksel suggests the use of mktemp instead of tempfile

[Holger Wansing]

Hi,

Sven Joachim  wrote:
> >         ends successfully, but with a warning:
> >     WARNING: tempfile is deprecated; consider using mktemp instead.
> 
> The warning comes from tempfile itself, added in debianutils 4.10.  The
> obvious, but untested attached patch fixes that, although it might be
> better to use File::Temp instead (in perl-base since version 5.20.1-3).

tasksel builds fine with Sven's "tempfile -> mktemp" patch applied, so any 
objections against this?

Holger


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

Bug#972151: glib2.0: gdbus-server-auth test consistently fails on arm-conova-03 but nowhere else

[Simon McVittie]

Source: glib2.0
Version: 2.66.1-1
Severity: important
Tags: ftbfs help
X-Debbugs-Cc: debian-...@lists.debian.org

One of the tests in GLib's test suite is gdbus-server-auth, which tests
the GDBusServer IPC server, among other things verifying that a libdbus
client can interoperate with the GDBusServer.

It appears this test consistently fails on arm-conova-03 (with either
its armel or armhf hat), but not on other buildds (!), when it exercises
a TCP connection with the DBUS_COOKIE_SHA1 authentication mechanism. I
don't know why. It might be something timing-related (the test was intended
to reproduce a timing problem in DBUS_COOKIE_SHA1 where GDBus and libdbus
failed to interoperate).

I've tried running the same test in a loop on porterboxes in the past,
without being able to reproduce the problem in 2000 consecutive runs.

What hardware is arm-conova-03 running on? Is it the same as amdahl, which
has a similar description on db.debian.org?

Is there anything odd about how arm-conova-03's filesystem or /tmp works,
perhaps using tmpfs or NFS where other buildds don't, or not using tmpfs
where other buildds do, or an unusual level of load?

Or is there anything odd about arm-conova-03's TCP or other networking
setup?

Is there anything else special about arm-conova-03 that would make it have
unusual timing more often, perhaps pausing execution for a significant
time and then resuming?

If I upload a version to experimental with extra debug logging, is it
possible for porters or buildd admins to force it to be scheduled on
arm-conova-03 or a similar machine?

Thanks,
smcv

# random seed: R02S6c2bc7bff771d54ff46a2e943ffa793a
1..8
# Start of gdbus tests
# GLib-DEBUG: g_set_user_dirs: Setting HOME to 
/tmp/test_gdbus-server-auth_SYU9R0/gdbus/server-auth/.dirs/home
# GLib-DEBUG: g_set_user_dirs: Setting XDG_CACHE_HOME to 
/tmp/test_gdbus-server-auth_SYU9R0/gdbus/server-auth/.dirs/cache
# GLib-DEBUG: g_set_user_dirs: Setting XDG_CONFIG_DIRS to 
/tmp/test_gdbus-server-auth_SYU9R0/gdbus/server-auth/.dirs/system-config1:/tmp/test_gdbus-server-auth_SYU9R0/gdbus/server-auth/.dirs/system-config2
# GLib-DEBUG: g_set_user_dirs: Setting XDG_CONFIG_HOME to 
/tmp/test_gdbus-server-auth_SYU9R0/gdbus/server-auth/.dirs/config
# GLib-DEBUG: g_set_user_dirs: Setting XDG_DATA_DIRS to 
/tmp/test_gdbus-server-auth_SYU9R0/gdbus/server-auth/.dirs/system-data1:/tmp/test_gdbus-server-auth_SYU9R0/gdbus/server-auth/.dirs/system-data2
# GLib-DEBUG: g_set_user_dirs: Setting XDG_DATA_HOME to 
/tmp/test_gdbus-server-auth_SYU9R0/gdbus/server-auth/.dirs/data
# GLib-DEBUG: g_set_user_dirs: Setting XDG_RUNTIME_DIR to 
/tmp/test_gdbus-server-auth_SYU9R0/gdbus/server-auth/.dirs/runtime
# Testing GDBus server at unix:dir=/tmp/gdbus-server-auth-TEU9R0 / libdbus 
client, with flags: external:false anonymous:false sha1:false abstract:false 
tcp:false
# Connectable address: unix:path=/tmp/gdbus-server-auth-TEU9R0/dbus-LvKVVgBn
# GLib-GIO-DEBUG: Accepting "ANONYMOUS" authentication
# GLib-GIO-DEBUG: Accepting "DBUS_COOKIE_SHA1" authentication
# GLib-GIO-DEBUG: Accepting "EXTERNAL" authentication
# GLib-GIO-DEBUG: Authorizing peer with credentials: 
GCredentials:linux-ucred:pid=25936,uid=2952,gid=1009
# GLib-GIO-DEBUG: New connection from peer with credentials: 
GCredentials:linux-ucred:pid=25936,uid=2952,gid=1009
# GLib-GIO-DEBUG: Server says GDBus client is uid 2952, pid 25936
# GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
# GLib-GIO-DEBUG: Accepting "ANONYMOUS" authentication
# GLib-GIO-DEBUG: Accepting "DBUS_COOKIE_SHA1" authentication
# GLib-GIO-DEBUG: Accepting "EXTERNAL" authentication
# GLib-GIO-DEBUG: Authorizing peer with credentials: 
GCredentials:linux-ucred:pid=25936,uid=2952,gid=1009
# GLib-GIO-DEBUG: New connection from peer with credentials: 
GCredentials:linux-ucred:pid=25936,uid=2952,gid=1009
# GLib-GIO-DEBUG: Server says libdbus client 0 is uid 2952, pid 25936
# GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
# GLib-GIO-DEBUG: Accepting "ANONYMOUS" authentication
# GLib-GIO-DEBUG: Accepting "DBUS_COOKIE_SHA1" authentication
# GLib-GIO-DEBUG: Accepting "EXTERNAL" authentication
# GLib-GIO-DEBUG: Authorizing peer with credentials: 
GCredentials:linux-ucred:pid=25936,uid=2952,gid=1009
# GLib-GIO-DEBUG: New connection from peer with credentials: 
GCredentials:linux-ucred:pid=25936,uid=2952,gid=1009
# GLib-GIO-DEBUG: Server says libdbus client 1 is uid 2952, pid 25936
# GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
# GLib-GIO-DEBUG: Accepting "ANONYMOUS" authentication
# GLib-GIO-DEBUG: Accepting "DBUS_COOKIE_SHA1" authentication
# GLib-GIO-DEBUG: Accepting "EXTERNAL" authentication
# GLib-GIO-DEBUG: Authorizing peer with credentials: 
GCredentials:linux-ucred:pid=25936,uid=2952,gid=1009
# GLib-GIO-DEBUG: New connection from peer with credentials: