Bug#899687: marked as done (ruby-haikunator: Invalid maintainer address pkg-azure-t...@lists.alioth.debian.org)

[Debian Bug Tracking System]

Your message dated Sat, 21 Sep 2019 05:05:29 +
with message-id 
and subject line Bug#940721: Removed package(s) from unstable
has caused the Debian Bug report #899687,
regarding ruby-haikunator: Invalid maintainer address 
pkg-azure-t...@lists.alioth.debian.org
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
899687: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899687
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:ruby-haikunator
Version: 1.1.0-2
Severity: serious
User: ad...@alioth-lists.debian.net
Usertag: alioth-lists-maintainer

Dear uploader of ruby-haikunator,

as you've probably heard, Debian's alioth services are shutting down.
This affects your package ruby-haikunator since the list address
pkg-azure-t...@lists.alioth.debian.org used in the Maintainer: field
was not transferred to the alioth-lists service that provides a
continuation for the lists in the @lists.alioth.debian.org domain.

Addresses that were not migrated have been disabled some time  ago. As
a result your package is now in violation of a "must" in the Debian
policy (3.3, working email address), making it unfit for release.

Please fix this before long. Among other reasons, keep in mind bug
reports and important notifications about your package might not reach
you.

Your options:

* Upload another version with a new maintainer address of your choice,

* Migrate the list to the new system. This is still possible,
  please appoint a Debian developer as a list owner first, then
  contact the alioth lists migration team 
  and provide all the necessary information.

  More information about the new service can be found here:
  

* More options, even if imperfect, can be found at
  


The first option is probably suitable only if the address was used just
in a small number of packages since this requires an upload for each of
them. To our knowledge, the usage count of
pkg-azure-t...@lists.alioth.debian.org is 9.

The second option is available for a limited time only, by end of
May 2018 the most. So if you're interested in going this way, start the
process as soon as possible.

Note, as mails to the maintainer address will not get through, this
bugreport is Cc'ed (X-Debbugs-CC:) to all uploaders of the package.

Regards,

Christoph and some alioth-lists maintainers


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Version: 1.1.0-2+rm

Dear submitter,

as the package ruby-haikunator has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/940721

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)--- End Message ---

Bug#899686: marked as done (ruby-timeliness: Invalid maintainer address pkg-azure-t...@lists.alioth.debian.org)

[Debian Bug Tracking System]

Your message dated Sat, 21 Sep 2019 05:06:36 +
with message-id 
and subject line Bug#940722: Removed package(s) from unstable
has caused the Debian Bug report #899686,
regarding ruby-timeliness: Invalid maintainer address 
pkg-azure-t...@lists.alioth.debian.org
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
899686: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899686
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:ruby-timeliness
Version: 0.3.8-1
Severity: serious
User: ad...@alioth-lists.debian.net
Usertag: alioth-lists-maintainer

Dear uploader of ruby-timeliness,

as you've probably heard, Debian's alioth services are shutting down.
This affects your package ruby-timeliness since the list address
pkg-azure-t...@lists.alioth.debian.org used in the Maintainer: field
was not transferred to the alioth-lists service that provides a
continuation for the lists in the @lists.alioth.debian.org domain.

Addresses that were not migrated have been disabled some time  ago. As
a result your package is now in violation of a "must" in the Debian
policy (3.3, working email address), making it unfit for release.

Please fix this before long. Among other reasons, keep in mind bug
reports and important notifications about your package might not reach
you.

Your options:

* Upload another version with a new maintainer address of your choice,

* Migrate the list to the new system. This is still possible,
  please appoint a Debian developer as a list owner first, then
  contact the alioth lists migration team 
  and provide all the necessary information.

  More information about the new service can be found here:
  

* More options, even if imperfect, can be found at
  


The first option is probably suitable only if the address was used just
in a small number of packages since this requires an upload for each of
them. To our knowledge, the usage count of
pkg-azure-t...@lists.alioth.debian.org is 9.

The second option is available for a limited time only, by end of
May 2018 the most. So if you're interested in going this way, start the
process as soon as possible.

Note, as mails to the maintainer address will not get through, this
bugreport is Cc'ed (X-Debbugs-CC:) to all uploaders of the package.

Regards,

Christoph and some alioth-lists maintainers


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Version: 0.3.8-1+rm

Dear submitter,

as the package ruby-timeliness has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/940722

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)--- End Message ---

Processed (with 1 error): guile-2.0 will be removed from bullseye

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # These bugs have been open for years.  While I may not, I may try to
> # get guile-2.0 removed as soon as a month or two from now -- it's
> # unfortunate that we had to keep it in buster.  Please do something
> # soon if you can.
> # Broken Depends:
> # autogen: autogen
> severity 885189 serious
Bug #885189 [src:autogen] autogen: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> # denemo: denemo
> severity 885190 serious
Bug #885190 [src:denemo] denemo: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> # geda-gaf: geda-gattrib
> #   geda-gnetlist
> #   geda-gschem
> #   geda-gsymcheck
> #   geda-utils
> #   libgeda-dev
> #   libgeda42
> severity 885195 serious
Bug #885195 [src:geda-gaf] geda-gaf: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> # graphviz: libgv-guile
> severity 885198 serious
Failed to set severity of Bug 885198 to serious: Not altering archived bugs; 
see unarchive.

> # make-dfsg: make-guile
> severity 885213 serious
Bug #885213 [src:make-dfsg] make-dfsg: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> # mcron: mcron
> severity 885215 serious
Bug #885215 [src:mcron] mcron: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> # remake: remake
> severity 885237 serious
Bug #885237 [src:remake] remake: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> # rumor: rumor
> severity 885238 serious
Bug #885238 [src:rumor] rumor: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> # weechat: weechat-guile
> severity 885235 serious
Bug #885235 [src:weechat] weechat: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> # xbindkeys: xbindkeys
> severity 885239 serious
Bug #885239 [src:xbindkeys] xbindkeys: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> # Broken Build-Depends:
> # freehdl: guile-2.0
> severity 885188 serious
Bug #885188 [src:freehdl] freehdl: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> # libmatheval: guile-2.0-dev
> severity 885212 serious
Bug #885212 [src:libmatheval] libmatheval: please migrate to guile-2.2
Severity set to 'serious' from 'normal'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
885188: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885188
885189: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885189
885190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885190
885195: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885195
885212: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885212
885213: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885213
885215: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885215
885235: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885235
885237: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885237
885238: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885238
885239: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885239
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#880154: python-turbogears2: please provide Python3 module

[Sandro Tosi]

Hello Laszlo,
what should we do here? tg2 depends on python-repoze.tm2 which is no
longer installable due to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938133#10 (probably
the binary package is still around as cruft, but could be removed
anytime).

I'm still slightly in favor of removing tg2, but i want to check back
with you before taking any step further.

I'd like to get started on a solution within a week.

Regards,
Sandro

On Sat, Sep 7, 2019 at 12:05 AM Sandro Tosi  wrote:
>
> control: severity -1 serious
>
> On Mon, 30 Oct 2017 10:46:21 +0800 Drew Parsons  wrote:
> > python-turbogears2 is currently only provided as a python2 module.
> >
> > Could you please also package the python3 version?
> > i.e. provide python3-turbogears2
>
> Raising severity as we need to assess and draw a path forward for tg
>
> currently:
> * upstream claims https://github.com/TurboGears/tg2/ compatibility
> with python3.7
> * python-turbogears2 has no reverse dependencies
> * it has quite low popcon of 16
> * we are actually shipping version 2.3.7, that was released in October 2015 
> (!)
>
> Here i see only 2 ways:
>
> * remove turbogears2 (let's face it, it _lost_ the web frameworks
> battle; back in the days you could hear people talking about tg,
> nowadays, iet's either django or flask..)
> * move tg to python3.
>
> given the relative low interest for tg in debian (see popcon) it's
> probably easier to just remove it, but i would not be against
> upgrading it to the latest version and provide *only* the python3
> package, if this is done in the next few weeks.
>
> I'll follow up in a week if i dont hear anything back.
>
> Thanks,
> Sandro



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#858774: modes_rx: ImportError: cannot import name QtWebKit

[A. Maitland Bottoms]

Moritz Mühlenhoff  writes:

> Hi Maitland,
> per upstream issue 98 it doesn't sound as if it's going to be fixed,
> should be remove it or are you planning to port it yourself?

I was just talking to the upstream author at the gnuradio conference.
Our plan going forward is to just remove the GUI elements of the
package, but keep all the signal processing code and provide gnuradio
blocks.

I am travelling and away from my Debian keys. I'll upload a Qt4 free
version fixing this bug in the coming week..

>
> (We're closing in on the Qt4 removal)
>
> Cheers,
> Moritz

Maybe someday someone will use the gr-air-modes package to feed data to
a newer better map display.

Thanks for looking into this,
-Maitland

Bug#933057: csh: bsd-csh eval command always dies with segmentation fault

[Keith Thompson]

Yes, that's one possible fix.

But if you grab a newer version from upstream, pointer_deref_comparison.patch
isn't necessary at all. The change from '\0' to NULL was already made 2018-09-19
as I described above in message #5 on this report.

I suppose grabbing the newer version make sense in the long term,
but fixing pointer_deref_comparison.patch makes sense as a quick
fix for current releases.

(Sorry if I'm stating the obvious.)


On Fri, Sep 20, 2019 at 6:51 PM Graham Inggs  wrote:
>
> Modifying pointer_deref_comparison.patch as follows works for me.
>
>
> --- a/debian/patches/pointer_deref_comparison.patch
> +++ b/debian/patches/pointer_deref_comparison.patch
> @@ -5,7 +5,7 @@
>   }
>   if (alvec) {
>  -if ((alvecp = *alvec) != '\0') {
> -+if (*(alvecp = *alvec) != '\0') {
> ++if ((alvecp = *alvec) != NULL) {
>   alvec++;
>   goto top;
>   }
> @@ -14,7 +14,7 @@
>   reset();
>   }
>  -if ((evalp = *evalvec) != '\0') {
> -+if (*(evalp = *evalvec) != '\0') {
> ++if ((evalp = *evalvec) != NULL) {
>   evalvec++;
>   goto top;
>   }
>
> --
> To unsubscribe, send mail to 933057-unsubscr...@bugs.debian.org.

Bug#933057: csh: bsd-csh eval command always dies with segmentation fault

[Graham Inggs]

Modifying pointer_deref_comparison.patch as follows works for me.


--- a/debian/patches/pointer_deref_comparison.patch
+++ b/debian/patches/pointer_deref_comparison.patch
@@ -5,7 +5,7 @@
  }
  if (alvec) {
 -if ((alvecp = *alvec) != '\0') {
-+if (*(alvecp = *alvec) != '\0') {
++if ((alvecp = *alvec) != NULL) {
  alvec++;
  goto top;
  }
@@ -14,7 +14,7 @@
  reset();
  }
 -if ((evalp = *evalvec) != '\0') {
-+if (*(evalp = *evalvec) != '\0') {
++if ((evalp = *evalvec) != NULL) {
  evalvec++;
  goto top;
  }

Processed: csh: bsd-csh eval command always dies with segmentation fault

[Debian Bug Tracking System]

Processing control commands:

> severity -1 serious
Bug #933057 [csh] csh: bsd-csh eval command always dies with segmentation fault
Severity set to 'serious' from 'important'
> found -1 csh/20110502-3
Bug #933057 [csh] csh: bsd-csh eval command always dies with segmentation fault
Marked as found in versions csh/20110502-3.
> tags -1 + patch
Bug #933057 [csh] csh: bsd-csh eval command always dies with segmentation fault
Added tag(s) patch.

-- 
933057: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933057
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: [tipp10] Future Qt4 removal from Buster

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + patch
Bug #875207 [src:tipp10] [tipp10] Future Qt4 removal from Buster
Added tag(s) patch.

-- 
875207: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875207
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#875207: [tipp10] Future Qt4 removal from Buster

[Reiner Herrmann]

Control: tags -1 + patch

Hi Christoph,

I attached a patch that builds tipp10 with Qt5.
I tested building with pbuilder and did a few tests of the program,
and it looks to me like everything is working.

As porting the download modules would have been a bit more effort,
as QHttp is no longer available in Qt5 (replaced by QNetworkAccessManager),
I had a look what they are actually used for.
It turned out that two of them were currently not used at all
(updatedialog, downloaddialog), as their actions have not been
associated with any menu. And the third one (checkversion, which checks on a
remote server if the version is up-to-date) has no real use in a Debian
package and there seems to be no upstream development anyway. It's also
not nice to let it "phone home" regularly.
So I decided to drop them, which simplified the porting effort.
I hope you are fine with this change.

Kind regards,
  Reiner
From 03bfa696455efad18984fab80bee00e2d4d57cdd Mon Sep 17 00:00:00 2001
From: Reiner Herrmann 
Date: Sat, 21 Sep 2019 00:04:31 +0200
Subject: [PATCH] Port to Qt5

Closes: #875207
---
 debian/control   |   4 +-
 debian/patches/disable_downloaders.patch | 163 +++
 debian/patches/qt5.patch |  67 ++
 debian/patches/series|   2 +
 debian/rules |   2 +-
 5 files changed, 235 insertions(+), 3 deletions(-)
 create mode 100644 debian/patches/disable_downloaders.patch
 create mode 100644 debian/patches/qt5.patch

diff --git a/debian/control b/debian/control
index e20a052..3ab3edb 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: tipp10
 Section: education
 Priority: optional
 Maintainer: Christoph Martin 
-Build-Depends: debhelper (>= 9), qt4-qmake, libqt4-dev
+Build-Depends: debhelper (>= 9), qt5-qmake, qtbase5-dev, qtmultimedia5-dev
 Standards-Version: 3.9.5
 Homepage: https://www.tipp10.com/
 #Vcs-Git: git://anonscm.debian.org/collab-maint/tipp10.git
@@ -10,7 +10,7 @@ Homepage: https://www.tipp10.com/
 
 Package: tipp10
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libqt4-sql-sqlite
+Depends: ${shlibs:Depends}, ${misc:Depends}, libqt5sql5-sqlite
 Description: free open source touch typing software
  TIPP10 is a free touch typing tutor for Windows, Mac OS and Linux. The
  ingenious thing about the software is its intelligence feature.
diff --git a/debian/patches/disable_downloaders.patch b/debian/patches/disable_downloaders.patch
new file mode 100644
index 000..ac172a1
--- /dev/null
+++ b/debian/patches/disable_downloaders.patch
@@ -0,0 +1,163 @@
+Author: Reiner Herrmann 
+Description: Disable downloaders
+ This makes porting to Qt5 much easier, as QHttp is no longer available.
+ But the functionality was not enabled anyway or is no longer useful.
+ .
+ - checkversion.h/.cpp:
+   At startup (while loading settings), Tipp10 "phones home" to do an
+   update check (www.tipp10.com/update/version.tipp10v210).
+   For a packaged software and one that is no longer being developed,
+   this does not make much sense.
+ - updatedialog.h/.cpp:
+   Can download newer sqlite database (www.tipp10.com/update/sql.tipp10v210.utf),
+   but this file is no longer available on the server (404).
+   The update action has also not been enabled in the menu, so the update
+   functionality was currently not active:
+ widget/mainwindow.cpp:143:  //fileMenu->addAction(updateAction);
+ - downloaddialog.h/.cpp:
+   Allows downloading lessons from user-specified location.
+   But the action (widget/startwidget.cpp -> lessonDownload) has not been part
+   of any menu, so it was also not in use.
+
+--- a/tipp10.pro
 b/tipp10.pro
+@@ -15,7 +15,6 @@
+ INCLUDEPATH += 	.
+ CONFIG  += 	qt
+ QT  += 	sql
+-QT  += 	network
+ RC_FILE += 	tipp10.rc
+ RESOURCES   += 	tipp10.qrc
+ HEADERS += 	def/defines.h \
+@@ -36,15 +35,12 @@
+ widget/settingspages.h \
+ widget/lessondialog.h \
+ widget/regexpdialog.h \
+-widget/downloaddialog.h \
+ widget/lessonprintdialog.h \
+ widget/lessonresult.h \
+-widget/updatedialog.h \
+ widget/helpbrowser.h \
+ widget/companylogo.h \
+ widget/errormessage.h \
+ widget/txtmessagedialog.h \
+-widget/checkversion.h \
+ sql/connection.h \
+ sql/lessontablesql.h \
+ sql/chartablesql.h \
+@@ -70,15 +66,12 @@
+ widget/settingspages.cpp \
+ widget/lessondialog.cpp \
+ widget/regexpdialog.cpp \
+-widget/downloaddialog.cpp \
+ widget/lessonprintdialog.cpp \
+ widget/lessonresult.cpp \
+-

Processed: block 937893 with 915895

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 937893 with 915895
Bug #937893 [src:python-limits] python-limits: Python2 removal in sid/bullseye
937893 was not blocked by any bugs.
937893 was not blocking any bugs.
Added blocking bug(s) of 937893: 915895
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
937893: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937893
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#915895: python-limits FTBFS: ERROR: Failure: ImportError (cannot import name b)

[Andrey Rahmatullin]

On Thu, Aug 15, 2019 at 11:10:37PM +0500, Andrey Rahmatullin wrote:
> Control: reassign -1 src:redis-py-cluster/1.3.3-1
> Control: severity -1 grave
> Control: forwarded -1 https://github.com/Grokzen/redis-py-cluster/issues/295
> Control: affects -1 src:python-limits
> 
> On Sat, Feb 09, 2019 at 06:57:54PM +0100, Slavko wrote:
> > while this of course affects the python-limits build, it is not its
> > bug. As one can see, it is caused in test by importing rediscluster:
> Exactly. Fixing the bug metadata accordingly.
> Work in progress is at
> https://github.com/Grokzen/redis-py-cluster/pull/296 and looks promising.
This is fixed in the 2.0 release.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#939868: marked as done (slirp4netns: CVE-2019-15890)

[Debian Bug Tracking System]

Your message dated Fri, 20 Sep 2019 22:19:48 +
with message-id 
and subject line Bug#939868: fixed in slirp4netns 0.4.1-1
has caused the Debian Bug report #939868,
regarding slirp4netns: CVE-2019-15890
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
939868: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939868
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: slirp4netns
Version: 0.3.2-1
Severity: grave
Tags: security upstream
Justification: user security hole
Control: clone -1 -2
Control: reassign -2 src:qemu 1:4.1-1
Control: retitle -2 qemu: CVE-2019-15890

Hi,

The following vulnerability was published for slirp4netns.

CVE-2019-15890[0]:
| libslirp 4.0.0, as used in QEMU 4.1.0, has a use-after-free in
| ip_reass in ip_input.c.

I'm filling this with higher serverity as you proably would have
expected, but for buster and older I guess we can follow this as
no-dsa and schedule fixes via point releases or include in future
DSAs. As unprivileged user namespaces are not enabled by default the
former holds surely for slirp4netns itself. The bug is cloned as well
for qemu.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-15890
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15890
[1] https://www.openwall.com/lists/oss-security/2019/09/06/3
[2] 
https://gitlab.freedesktop.org/slirp/libslirp/commit/c59279437eda91841b9d26079c70b8a540d41204

Please adjust the affected versions in the BTS as needed, only looked
at the respective unstable versions.

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: slirp4netns
Source-Version: 0.4.1-1

We believe that the bug you reported is fixed in the latest version of
slirp4netns, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 939...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Reinhard Tartler  (supplier of updated slirp4netns package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 20 Sep 2019 07:58:27 -0400
Source: slirp4netns
Architecture: source
Version: 0.4.1-1
Distribution: unstable
Urgency: medium
Maintainer: Reinhard Tartler 
Changed-By: Reinhard Tartler 
Closes: 939868
Changes:
 slirp4netns (0.4.1-1) unstable; urgency=medium
 .
   * New upstream version 0.4.1
 - Support specifying netns path (slirp4netns --netns-type=path PATH 
TAPNAME)
 - Support specifying --userns-path
 - Vendor https://gitlab.freedesktop.org/slirp/libslirp (QEMU v4.1+)
 - Bring up loopback device when --configure is specified
 - Support sandboxing by creating a mount namespace (--enable-sandbox)
 - libslirp: Fix heap overflow (Fixes: CVE-2019-14378)
 - Support seccomp (--enable-seccomp)
 - libslirp: Fix use-after-free (Fixes CVE-2019-15890, Closes: #939868)
Checksums-Sha1:
 0568720c7b7a444500227147d14a9a5a5d0feba7 2014 slirp4netns_0.4.1-1.dsc
 02c890bc45bc3662d5f05a2f31e3ecedb03997e1 168785 slirp4netns_0.4.1.orig.tar.gz
 f67a2d9c86ec2f4dd071b82e7d237df96e4475a3 4808 slirp4netns_0.4.1-1.debian.tar.xz
Checksums-Sha256:
 848f486d9e1ac03106df04f9a500a11b0337774368ff93aec10cb73c95b724bb 2014 
slirp4netns_0.4.1-1.dsc
 75d2a7411cc2b3e341d8530228750bb1db06077b349d10fbdddbb582c27f8cfc 168785 
slirp4netns_0.4.1.orig.tar.gz
 76f246c836b4d3304512a834c0ad386523323898e61cae9238c53db769d2bd76 4808 
slirp4netns_0.4.1-1.debian.tar.xz
Files:
 d92ac459f597c3ad29ed7631da11f51d 2014 misc optional slirp4netns_0.4.1-1.dsc
 2511da14fcacff3a4c5d6c501f04e20b 168785 misc optional 
slirp4netns_0.4.1.orig.tar.gz
 4e4b207f1301a78dd0e470effd53a4d3 4808 misc optional 
slirp4netns_0.4.1-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAl2FTJsUHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJsuc4Q/+PVTePj/FiD84KG7BKwbghHY3Ikt5
dLIf1Ue07YYM4i/B4oGU6JjsfWCH78fR26fgTgUqtooSjNtX3zsSRPEfiX3/gfQG
f6+DkwLEVvB+a9/2g3Y1iNiVarAbvd04mEQh8iGhyfWiYJLNC/ZHlF3x7Nl5Vj30
kKC9qGFnS7UYhbECgJ/jKtrP1agaFT7PWdemalYOIAM3lY0UkRVo1Ee0q6mP8p/A

Bug#858774: modes_rx: ImportError: cannot import name QtWebKit

[Moritz Mühlenhoff]

On Wed, Aug 21, 2019 at 11:38:18PM +0300, Dmitry Shachnev wrote:
> Control: severity -1 serious
> 
> On Sun, Mar 26, 2017 at 04:05:54PM +0200, Sebastian Niehaus wrote:
> > when I call modes_gui it fails:
> >
> > users@liquid:~$ modes_gui 
> > Traceback (most recent call last):
> >   File "/usr/bin/modes_gui", line 24, in 
> > from PyQt4 import QtCore,QtGui,QtWebKit
> > ImportError: cannot import name QtWebKit
> 
> I am bumping the severity to release-critical because QtWebKit is no
> longer available, and moreover, we are going to remove the whole
> Qt4 from Bullseye: https://wiki.debian.org/Qt4Removal.
> 
> This package should be ported to PyQt5, or otherwise it will be
> removed from Debian testing.

Hi Maitland,
per upstream issue 98 it doesn't sound as if it's going to be fixed,
should be remove it or are you planning to port it yourself?

(We're closing in on the Qt4 removal)

Cheers,
Moritz

Bug#875184: Help needed for medical imaging framework sofa (Was: Bug#875184: [sofa-framework] Future Qt4 removal from Buster)

[Moritz Mühlenhoff]

On Fri, Sep 20, 2019 at 06:41:05PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> I've created a WIP merge request at
> 
>   https://salsa.debian.org/med-team/sofa-framework/merge_requests/1
> 
> I could solve TinyXML (at least in the aspect of finding it, I might need to
> adjust something else later on) but came across libgtest-dev... It ships 
> static
> libraries!
> 
> I would have to check how to use them within CMake, but I do wonder if it's 
> not
> better to just keep the embedded version. After all it's only used for testing
> C++ classes, so build time...

Agreed, that seems preferable here.

Cheers,
Moritz

Bug#875184: Help needed for medical imaging framework sofa (Was: Bug#875184: [sofa-framework] Future Qt4 removal from Buster)

[Lisandro Damián Nicanor Pérez Meyer]

I've created a WIP merge request at

  https://salsa.debian.org/med-team/sofa-framework/merge_requests/1

I could solve TinyXML (at least in the aspect of finding it, I might need to
adjust something else later on) but came across libgtest-dev... It ships static
libraries!

I would have to check how to use them within CMake, but I do wonder if it's not
better to just keep the embedded version. After all it's only used for testing
C++ classes, so build time...

If we still decide to go with the packaged version then I wonder what extra
field we should add in debian/control to express this (I think there was a field
for that, but I can't remember that, Build-Using maybe?).

Cheers, Lisandro.

Bug#940679: pandas: random test crashes

[Rebecca N. Palmer]

Control: tags -1 unreproducible

Running just the affected test files (in installed -6) produced no 
failures in ~350 attempts.  The build of -7 succeeded on amd64; it 
failed on ppc64, but as the log isn't available yet, I don't know if 
it's this bug.


While both tests involve time-related dtypes, the test data is a fixed 
set not the current time, so the time of build probably isn't what 
decides which runs fail.


Does anyone have a reproducible way to trigger this error?

Processed: Re: Bug#940679: pandas: random test crashes

[Debian Bug Tracking System]

Processing control commands:

> tags -1 unreproducible
Bug #940679 [src:pandas] pandas: random test crashes
Added tag(s) unreproducible.

-- 
940679: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940679
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: limit source to linux, tagging 940105, tagging 939853

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> limit source linux
Limiting to bugs with field 'source' containing at least one of 'linux'
Limit currently set to 'source':'linux'

> tags 940105 + pending
Bug #940105 [src:linux] linux: serious corruption issue with btrfs
Added tag(s) pending.
> tags 939853 + pending
Bug #939853 [src:linux] iwlwifi: ASSERT 0xEDC with A-MSDU
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
939853: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939853
940105: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940105
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 940105

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 940105 + fixed-upstream
Bug #940105 [src:linux] linux: serious corruption issue with btrfs
Added tag(s) fixed-upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
940105: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940105
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#940316: marked as done (zope.testing autopkgtest failure.)

[Debian Bug Tracking System]

Your message dated Fri, 20 Sep 2019 20:43:11 +
with message-id 
and subject line Bug#940316: fixed in zope.testing 4.6.2-3
has caused the Debian Bug report #940316,
regarding zope.testing autopkgtest failure.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
940316: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940316
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: zope.testing
Version: 4.6.2-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/z/zope.testing/2966135/log.gz


autopkgtest [06:13:32]: test all: [---
Traceback (most recent call last):
   File "/usr/bin/zope-testrunner", line 9, in 
 load_entry_point('zope.testrunner==4.4.9', 'console_scripts', 
'zope-testrunner')()
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/__init__.py", line 
27, in run
 failed = run_internal(defaults, args, script_parts=script_parts, cwd=cwd)
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/__init__.py", line 
44, in run_internal
 runner.run()
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/runner.py", line 159, 
in run
 feature.global_setup()
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 479, 
in global_setup
 tests = find_tests(self.runner.options, self.runner.found_suites)
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 168, 
in find_tests
 for suite in found_suites:
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 179, 
in find_suites
 for fpath, package in find_test_files(options):
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 238, 
in find_test_files
 for f, package in find_test_files_(options):
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 266, 
in find_test_files_
 for (p, package) in test_dirs(options, {}):
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 321, 
in test_dirs
 p = import_name(p)
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 395, 
in import_name
 __import__(name)
ImportError: No module named testing



It looks like while the package has dropped python2 support, some of the 
autopkgtest stuff is still trying to use it.

--- End Message ---
--- Begin Message ---
Source: zope.testing
Source-Version: 4.6.2-3

We believe that the bug you reported is fixed in the latest version of
zope.testing, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 940...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Paul Gevers  (supplier of updated zope.testing package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 20 Sep 2019 22:21:00 +0200
Source: zope.testing
Architecture: source
Version: 4.6.2-3
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Paul Gevers 
Closes: 940316
Changes:
 zope.testing (4.6.2-3) unstable; urgency=medium
 .
   * QA upload.
   * Drop Python 2 tests (Closes: #940316)
   * Increase verbosity of Python 3 tests
Checksums-Sha1:
 a8d91547b59da689261be3a0b7a115a92718cd05 1685 zope.testing_4.6.2-3.dsc
 9335bbe1b96f25f45cc8a452283512caa016f8e3 5036 
zope.testing_4.6.2-3.debian.tar.xz
Checksums-Sha256:
 1fba699bf4f222c7812c3c2a483e8cdd58a9ad340159ef6177c4fe7bbcb79d33 1685 
zope.testing_4.6.2-3.dsc
 e76b404c3416c520e7b7300f47c1053b48afa0a4b7f004cb1d83430a8ee3c733 5036 
zope.testing_4.6.2-3.debian.tar.xz
Files:
 73d224c179eff66a5a8c387f6e02113d 1685 zope optional zope.testing_4.6.2-3.dsc
 6467bcc8b7df424ace00b7dcf640cefe 5036 zope optional 
zope.testing_4.6.2-3.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl2FNW8ACgkQnFyZ6wW9
dQrRowf/Zm/JTT/ciOXQQjtLSFWBzSSr+P5A9UmAAfQS3orfEBOYozYetWNrWi2c
YfekNYfFRVsBKZWQGtbdd43kZsuvb0eWdU4z4hprFKydzoXjVZjGhZ+iqB9TOuPb
c7u8sdeO4StV79GkHCezcHWOr8Luac6Gmmp1CSb9FB55tYv06iyFQlX6oNbrDp/g
Mn250CVU4VaqKlbar3eGoHiOGxIBeob/TYQqHNOUWmZgg8GbD3PNn6N+CI7AkszU
uYILciqboZ8H07Be/jWuSojDQOGGQCXNjbjE/BGP7N06Rb+p8fJ+aS2r9dvT3VIm
6v5lmEXsyQj8f45RPmsIE7dqaK7Fcg==
=6LhY
-END PGP SIGNATURE 

Bug#940315: marked as done (zope.testrunner autopkgtest failure.)

[Debian Bug Tracking System]

Your message dated Fri, 20 Sep 2019 20:43:17 +
with message-id 
and subject line Bug#940315: fixed in zope.testrunner 4.4.9-4
has caused the Debian Bug report #940315,
regarding zope.testrunner autopkgtest failure.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
940315: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940315
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: zope.testrunner
Version: 4.4.9-3
Severity: serious


autopkgtest [06:13:47]: test all-2: [---
bash: /tmp/autopkgtest-lxc.v65a_j_9/downtmp/build.cMu/src/debian/tests/all-2: 
/usr/bin/python: bad interpreter: No such file or directory
autopkgtest [06:13:47]: test all-2: ---]
autopkgtest [06:13:47]: test all-2:  - - - - - - - - - - results - - - - - - - 
- - -
all-2FAIL non-zero exit status 126
autopkgtest [06:13:47]: test all-2:  - - - - - - - - - - stderr - - - - - - - - 
- -
bash: /tmp/autopkgtest-lxc.v65a_j_9/downtmp/build.cMu/src/debian/tests/all-2: 
/usr/bin/python: bad interpreter: No such file or directory

It looks like while the package has dropped python2 support, some of the 
autopkgtest stuff is still trying to use it.

--- End Message ---
--- Begin Message ---
Source: zope.testrunner
Source-Version: 4.4.9-4

We believe that the bug you reported is fixed in the latest version of
zope.testrunner, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 940...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Paul Gevers  (supplier of updated zope.testrunner package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 20 Sep 2019 21:56:25 +0200
Source: zope.testrunner
Architecture: source
Version: 4.4.9-4
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Paul Gevers 
Closes: 940315
Changes:
 zope.testrunner (4.4.9-4) unstable; urgency=medium
 .
   * QA upload.
   * Drop custom autopkgtest and use autopkgtest-pkg-python (Closes:
 #940315)
Checksums-Sha1:
 b1e0e11559769f45004621088596c057612990db 1655 zope.testrunner_4.4.9-4.dsc
 1e045544e4c5151e64916d0619ff220d6ae39cfe 5992 
zope.testrunner_4.4.9-4.debian.tar.xz
Checksums-Sha256:
 fba0244ba4908ea63e0efb2733671395810a5aad74068f982b4b61559c4c469b 1655 
zope.testrunner_4.4.9-4.dsc
 69f614a6eb6f4892d8bce05aeb71422d602f4fd9e643c11274cfb77d7db816ca 5992 
zope.testrunner_4.4.9-4.debian.tar.xz
Files:
 c7d73a706cad0013758bfec938dad1c4 1655 zope optional zope.testrunner_4.4.9-4.dsc
 4f311ff35cc561c01f2daac3c990d9e6 5992 zope optional 
zope.testrunner_4.4.9-4.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl2FMWQACgkQnFyZ6wW9
dQqUywgAxHbdHvmlTFQJJYSRA270SKrJyd4IxIx20BBFZafgumQXBmw6dx3D94FE
tadgU+0WLw91kvD7GZBW1Nz1IxvSTjldYawn7M+2CqzKNGGFOYLyu4DT5juZJmJ3
ugv3NICWGGo1f9/LYFRY3GawoXr5uTxc8m32zv2+snCLNdGlIkBC79EvGdLrxsPf
hr8dQhJXcW0Qkuypbs1LIKU+fzWQLirJrG1+U/HBoMSqyNoTtivT2nmtgMaPKVPA
0roe/GRcvmBteaqHD44OfvIRQFIFosjJkXYI8/AWBHLT1CRv/fFxcIPvUNZ6My8g
6ZcKlqECr0qKUd5zuno5yHnd2tdmAg==
=RbT8
-END PGP SIGNATURE End Message ---

Bug#928526: linux-image-4.19.0-4-amd64: data corruption when swapping to encrypted SSD with LVM and TRIM enabled

[Salvatore Bonaccorso]

Hi Simon,

On Mon, May 06, 2019 at 10:28:09PM +0200, Simon Richter wrote:
> Hi,
> 
> On 06.05.19 21:35, Simon Richter wrote:
> 
> > I can probably test intermediate versions and/or changes in setup, but this
> > is difficult to automate because "bad" runs require manual file system
> > repairs and every run requires LUKS setup to be repeated.
> 
> FWIW, using a separate LV and swapon --discard=pages seems to work, so
> this is likely to be specific to swap files (which normally shouldn't be
> affected by discards, as their allocation doesn't change, but the kernel
> might have some default behaviour here that I'm not aware of).

Possible for you to directly report that upstream, keeping the bug in
the loop? (is it still an issue with 5.2.x and 5.3)?

Regards,
Salvatore

Bug#907637: bonding with virtio NICs does not work any more

[Salvatore Bonaccorso]

Hi Robert,

On Mon, Nov 12, 2018 at 05:08:56PM +0100, Salvatore Bonaccorso wrote:
> hi Robert,
> 
> On Sun, Sep 09, 2018 at 03:38:53PM +0200, Salvatore Bonaccorso wrote:
> > Control: tags -1 + moreinfo
> > 
> > Hi Robert,
> > 
> > If you downgrate to 4.9.107-1 (which was only in
> > stretch-proposed-updates and then superseeded by 4.9.110-1), does you
> > problem disapear?
> > 
> > In 4.9.110-1 I see the change backported from
> > https://git.kernel.org/linus/b5bf0f5b16b9c316c34df9f31d4be8729eb86845
> > 
> > In mainline there was a followup, to ratelimit the warning:
> > https://git.kernel.org/linus/11e9d7829dd08dbafb24517fe922f11c3a8a9dc2
> 
> Did you got a chance to check this? Does cherry picking the above
> commit solves the issue?

We did not see a followup on #907637. Did you had a chance to verify
on the above?

Regards,
Salvatore

Bug#940802: linux-image-4.19.0-5-amd64: Build of xt_ACCOUNT.ko failed for: 4.19.0-5-amd64 (x86_64)

[Salvatore Bonaccorso]

Hi,

On Thu, Sep 19, 2019 at 09:15:30PM +, Sophie Loewenthal wrote:
> Package: src:linux
> Version: 4.19.37-5+deb10u2
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- Package-specific info:
> ** Kernel log: boot messages should be attached
> 
> Setting up linux-image-4.19.0-5-amd64 (4.19.37-5+deb10u2) ...
> /etc/kernel/postinst.d/dkms:
> Error!  Build of xt_ACCOUNT.ko failed for: 4.19.0-5-amd64 (x86_64)
> Consult the make.log in the build directory
> /var/lib/dkms/xtables-addons/2.12/build/ for more information.
> /etc/kernel/postinst.d/initramfs-tools:

Your issue seem to be the same as #939801. Please note that
xtables-addons is actually not in buster, as it was removed before the
release
(https://tracker.debian.org/news/1033154/xtables-addons-removed-from-testing/).

Regards,
Salvatore

Processed: reassign 940802 to xtables-addons-source, forcibly merging 939801 940802

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 940802 xtables-addons-source
Bug #940802 [src:linux] linux-image-4.19.0-5-amd64: Build of xt_ACCOUNT.ko 
failed for: 4.19.0-5-amd64 (x86_64)
Bug reassigned from package 'src:linux' to 'xtables-addons-source'.
No longer marked as found in versions linux/4.19.37-5+deb10u2.
Ignoring request to alter fixed versions of bug #940802 to the same values 
previously set
> forcemerge 939801 940802
Bug #939801 [xtables-addons-source] xtables-addons-source: 
xtables-addons-2.12.0 fails to compile (kernel 5.2.0-0.bpo.2-amd64)
Bug #940802 [xtables-addons-source] linux-image-4.19.0-5-amd64: Build of 
xt_ACCOUNT.ko failed for: 4.19.0-5-amd64 (x86_64)
Severity set to 'serious' from 'normal'
Marked as found in versions xtables-addons/2.12-0.1.
Added tag(s) sid and bullseye.
Merged 939801 940802
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
939801: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939801
940802: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940802
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#875207: [tipp10] Future Qt4 removal from Buster

[Reiner Herrmann]

Hi Christoph,

I will try to port it in the next few days.
I had a short look and noticed that it uses QHttp,
which might be a bit trickier to port, but it should
be doable.

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Processed: python3-webpy: Does not work with static content

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 940106 normal
Bug #940106 [python3-webpy] python3-webpy: Does not work with static content
Severity set to 'normal' from 'grave'
> merge 940106 940107
Bug #940106 [python3-webpy] python3-webpy: Does not work with static content
Bug #940107 [python3-webpy] python3-webpy: Does not work with static content
Merged 940106 940107
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
940106: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940106
940107: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940107
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Thorsten Glaser]

On Thu, 19 Sep 2019, Mark Hindley wrote:

> On irc he also said there was little point in adding the Breaks: as apt 
> doesn't
> rexec itself.

Yes, even a Pre-Depends would not achieve anything TTBOMK.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#934269: marked as done (lavacli: default_flow_style changed in newer pyyaml)

[Debian Bug Tracking System]

Your message dated Fri, 20 Sep 2019 14:39:23 +
with message-id 
and subject line Bug#934269: fixed in lavacli 0.9.8-1
has caused the Debian Bug report #934269,
regarding lavacli: default_flow_style changed in newer pyyaml
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
934269: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934269
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lavacli
Version: 0.9.7-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

pyyaml 5.2.1 appears to have some changes in the default flow style used.
Rather than representing sequences and dicts similary to python, it now
defaults to printing them in longform [1]:

 - item 1
 - item 2

etc.

I've written a quick and heavyhanded patch to add default_flow_style=None
to all of the calls to yaml.dump() that otherwise don't include options, but
that might not be the best solution. Maybe upstream would rather fix the tests?

[1] https://github.com/yaml/pyyaml/issues/265


*** /tmp/tmpton7Uz/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/fix_pyyaml_default_flow_style.patch: Make sure all calls
to yaml.dump() include default_flow_style=None, to retain previous behavior
that is checked for in tests, unless it's already otherwise specified.


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers eoan
  APT policy: (500, 'eoan')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-8-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch 
lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch
--- lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch
1969-12-31 19:00:00.0 -0500
+++ lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch
2019-08-08 16:56:08.0 -0400
@@ -0,0 +1,185 @@
+Index: lavacli-0.9.7/lavacli/commands/aliases.py
+===
+--- lavacli-0.9.7.orig/lavacli/commands/aliases.py
 lavacli-0.9.7/lavacli/commands/aliases.py
+@@ -99,7 +99,7 @@ def handle_list(proxy, options, _):
+ if options.output_format == "json":
+ print(json.dumps(aliases))
+ elif options.output_format == "yaml":
+-print(yaml.dump(aliases).rstrip("\n"))
++print(yaml.dump(aliases, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Aliases:")
+ for alias in aliases:
+@@ -112,7 +112,7 @@ def handle_show(proxy, options, config):
+ if options.output_format == "json":
+ print(json.dumps(alias))
+ elif options.output_format == "yaml":
+-print(yaml.dump(alias).rstrip("\n"))
++print(yaml.dump(alias, default_flow_style=None).rstrip("\n"))
+ else:
+ if config["version"] >= (2019, 5):
+ print("name   : %s" % alias["name"])
+Index: lavacli-0.9.7/lavacli/commands/device_types.py
+===
+--- lavacli-0.9.7.orig/lavacli/commands/device_types.py
 lavacli-0.9.7/lavacli/commands/device_types.py
+@@ -260,7 +260,7 @@ def handle_aliases(proxy, options):
+ if options.output_format == "json":
+ print(json.dumps(aliases))
+ elif options.output_format == "yaml":
+-print(yaml.dump(aliases).rstrip("\n"))
++print(yaml.dump(aliases, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Aliases:")
+ for alias in aliases:
+@@ -287,7 +287,7 @@ def handle_list(proxy, options):
+ if options.output_format == "json":
+ print(json.dumps(device_types))
+ elif options.output_format == "yaml":
+-print(yaml.dump(device_types).rstrip("\n"))
++print(yaml.dump(device_types, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Device-Types:")
+ for dt in device_types:
+@@ -301,7 +301,7 @@ def handle_show(proxy, options):
+ if options.output_format == "json":
+ print(json.dumps(dt))
+ elif options.output_format == "yaml":
+-print(yaml.dump(dt).rstrip("\n"))
++print(yaml.dump(dt, 

Bug#933919: closing 933919

[Antonio Terceiro]

close 933919 
thanks

As per the discussion above, this bug is a false positive. I will also mark
#934269 as RC.

Processed: severity of 934269 is serious

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 934269 serious
Bug #934269 [lavacli] lavacli: default_flow_style changed in newer pyyaml
Severity set to 'serious' from 'normal'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
934269: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934269
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: closing 933919

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> close 933919
Bug #933919 [src:lavacli] src:lavacli: Unsafe use of yaml.load()
Marked Bug as done
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
933919: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933919
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#940220: marked as done (postgresql-common: pg_ctlcluster segfault)

[Debian Bug Tracking System]

Your message dated Fri, 20 Sep 2019 13:05:20 +
with message-id 
and subject line Bug#940220: fixed in postgresql-common 207
has caused the Debian Bug report #940220,
regarding postgresql-common: pg_ctlcluster segfault
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
940220: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940220
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: postgresql-common
Version: 206
Severity: important

Dear Maintainer,


Updates package take a long time with errors


Setting up postgresql-common (206) ...
Deep recursion on subroutine "PgCommon::get_versions" at 
/usr/share/perl5/PgCommon.pm line 706.
Deep recursion on subroutine "PgCommon::get_program_path" at 
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_newest_version" at 
/usr/share/perl5/PgCommon.pm line 473.
/var/lib/dpkg/info/postgresql-common.postinst: line 119:  5462 Segmentation 
fault  /usr/share/postgresql-common/pg_checksystem

After update package pg_ctlcluster segfault


Sep 14 08:26:12  kernel: [ 3568.336669] pg_ctlcluster[11631]: segfault at 
7f337617a5d8 ip 564511296591 sp 7fffe5789940 error 6 in 
perl[5645111ff000+15d000]
Sep 14 08:26:12  kernel: [ 3568.336675] Code: c0 74 0c 83 c0 01 41 be 01 00 00 
00 89 42 08 48 63 de 4c 89 ef 48 8d 35 ed 01 00 00 f7 d5 48 89 da e8 23 84 05 
00 49 03 5d 28 <4c> 89 23 41 8b 44 24 0c 25 00 00 e1 08 89 43 0c 41 8b 45 30 44 
88



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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=lt_LT.utf8, LC_CTYPE=lt_LT.utf8 (charmap=UTF-8), 
LANGUAGE=lt_LT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages postgresql-common depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.73
ii  lsb-base  11.1.0
ii  postgresql-client-common  206
ii  procps2:3.3.15-2+b1
ii  ssl-cert  1.0.39
ii  ucf   3.0038+nmu1

Versions of packages postgresql-common recommends:
ii  e2fsprogs  1.45.3-4
ii  logrotate  3.15.1-1

Versions of packages postgresql-common suggests:
ii  libjson-perl  4.02000-1

-- Configuration Files:
/etc/postgresql-common/createcluster.conf changed:
ssl = on
cluster_name = '%v/%c'
stats_temp_directory = '/var/run/postgresql/%v-%c.pg_stat_tmp'
log_line_prefix = '%%m [%%p] %%q%%u@%%d '
add_include_dir = 'conf.d'
include_dir '/etc/postgresql-common/createcluster.d'


-- debconf information excluded
--- End Message ---
--- Begin Message ---
Source: postgresql-common
Source-Version: 207

We believe that the bug you reported is fixed in the latest version of
postgresql-common, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 940...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christoph Berg  (supplier of updated postgresql-common package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 20 Sep 2019 14:24:23 +0200
Source: postgresql-common
Architecture: source
Version: 207
Distribution: unstable
Urgency: medium
Maintainer: Debian PostgreSQL Maintainers 
Changed-By: Christoph Berg 
Closes: 940220
Changes:
 postgresql-common (207) unstable; urgency=medium
 .
   * PgCommon.pm: Fix infinite recursion in get_program_path if
 /usr/lib/postgresql/ contains a non-version directory.
 Patch by ITANI Eiichiro, thanks! (Closes: #940220)
Checksums-Sha1:
 048b7be5aaab1f667cd78d1de4e289ccdefb0733 2411 postgresql-common_207.dsc
 a2204cae9f4db8d57b6f4cc5aa66d9d7c3d201bc 215268 postgresql-common_207.tar.xz
Checksums-Sha256:
 4ccc7914a508747d8af43e9e8fd4fb06e3f514db9e4f850669af2137f5226fe2 2411 
postgresql-common_207.dsc
 280f3566aa288871a03740da82a615e5c8fad1c790b2cd63756e257f13b40563 215268 
postgresql-common_207.tar.xz
Files:
 1e35c844588e350e426a37dbd12fb06f 2411 

Bug#940276: marked as done (postgresql-client-common: infinite recusion in installed versions search)

[Debian Bug Tracking System]

Your message dated Fri, 20 Sep 2019 13:05:20 +
with message-id 
and subject line Bug#940220: fixed in postgresql-common 207
has caused the Debian Bug report #940220,
regarding postgresql-client-common: infinite recusion in installed versions 
search
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
940220: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940220
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: postgresql-client-common
Version: 206
Severity: important

Dear Maintainer,

after upgrading postgresql-client-common/postgresql-common
process is stopped an configuration of postgresql-common with errors

Deep recursion on subroutine "PgCommon::get_versions" at
/usr/share/perl5/PgCommon.pm line 706.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_newest_version" at
/usr/share/perl5/PgCommon.pm line 473.

if wait some time, system freezes

if interrupt process, postgres can't start anymore with same error

downgrading to version 205 solves problem



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

Kernel: Linux 5.2.0-1-amd64 (SMP w/3 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8),
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages postgresql-client-common depends on:
ii  netbase  5.6

Versions of packages postgresql-client-common recommends:
ii  libreadline8  8.0-3

postgresql-client-common suggests no packages.

-- no debconf information

-- 
Homo Homini Dominus est
--- End Message ---
--- Begin Message ---
Source: postgresql-common
Source-Version: 207

We believe that the bug you reported is fixed in the latest version of
postgresql-common, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 940...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christoph Berg  (supplier of updated postgresql-common package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 20 Sep 2019 14:24:23 +0200
Source: postgresql-common
Architecture: source
Version: 207
Distribution: unstable
Urgency: medium
Maintainer: Debian PostgreSQL Maintainers 
Changed-By: Christoph Berg 
Closes: 940220
Changes:
 postgresql-common (207) unstable; urgency=medium
 .
   * PgCommon.pm: Fix infinite recursion in get_program_path if
 /usr/lib/postgresql/ contains a non-version directory.
 Patch by ITANI Eiichiro, thanks! (Closes: #940220)
Checksums-Sha1:
 048b7be5aaab1f667cd78d1de4e289ccdefb0733 2411 postgresql-common_207.dsc
 a2204cae9f4db8d57b6f4cc5aa66d9d7c3d201bc 215268 postgresql-common_207.tar.xz
Checksums-Sha256:
 4ccc7914a508747d8af43e9e8fd4fb06e3f514db9e4f850669af2137f5226fe2 2411 
postgresql-common_207.dsc
 280f3566aa288871a03740da82a615e5c8fad1c790b2cd63756e257f13b40563 215268 
postgresql-common_207.tar.xz
Files:
 1e35c844588e350e426a37dbd12fb06f 2411 database optional 
postgresql-common_207.dsc
 528fa4c267b148558f3c2dbc1660f893 215268 database optional 
postgresql-common_207.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEXEj+YVf0kXlZcIfGTFprqxLSp64FAl2EzDAACgkQTFprqxLS
p67jTw//TgoZgdDGQ/8uWyudflPHsSWv9uqP+339bMdQrmRQGcBl44inOTnKk3Rj
4HsJI4l9sj0sxxfpiNWfa6GXG2JgC0Yi9VbAL0xugiEBM7pAhfnOMGng2Nh3+BrU

Processed: reassign 940220 to postgresql-client-common, forcibly merging 940220 940276

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 940220 postgresql-client-common
Bug #940220 [postgresql-common] postgresql-common: pg_ctlcluster segfault
Bug reassigned from package 'postgresql-common' to 'postgresql-client-common'.
No longer marked as found in versions postgresql-common/206.
Ignoring request to alter fixed versions of bug #940220 to the same values 
previously set
> forcemerge 940220 940276
Bug #940220 [postgresql-client-common] postgresql-common: pg_ctlcluster segfault
Bug #940220 [postgresql-client-common] postgresql-common: pg_ctlcluster segfault
Marked as found in versions postgresql-common/206.
Bug #940276 [postgresql-client-common] postgresql-client-common: infinite 
recusion in installed versions search
Severity set to 'serious' from 'important'
Added tag(s) pending.
Merged 940220 940276
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
940220: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940220
940276: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940276
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Mark Hindley]

Laurent,

On Fri, Sep 20, 2019 at 01:29:43PM +0200, Laurent Bigonville wrote:
> Can't this be stubbed or mocked on the elogind side?

I presume you mean slices here? (I am not sure that slices are the only
difference in implementation, but let's ignore that for now).

To be honest, I am not sure. Possibly, but I have my doubts that upstream would
be interested in doing it: elogind has no use for them. Although they have
already been very accommodating by stubbing out all the APIs in libelogind0 to
be binary compatible with libsystemd0.

As I see it, if you want slices and all of the other features that systemd
provides, use systemd. If you want a slimmed down implementation of DBus login1
and sd-login(3) to use when systemd is not PID1, then elogind might be useful.

Mark

Processed: Bug#940220 marked as pending in postgresql-common

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #940220 [postgresql-common] postgresql-common: pg_ctlcluster segfault
Added tag(s) pending.

-- 
940220: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940220
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#940220: marked as pending in postgresql-common

[Christoph Berg]

Control: tag -1 pending

Hello,

Bug #940220 in postgresql-common reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/postgresql/postgresql-common/commit/6b6490447bf7e8c29a2a11df17d777dbc32cbd19


PgCommon.pm: Fix infinite recursion in get_program_path if /usr/lib/postgresql/ 
contains a non-version directory. Patch by ITANI Eiichiro, thanks! (Closes: 
#940220)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/940220

Processed (with 1 error): forcibly merging 940220 940276

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forcemerge 940220 940276
Bug #940220 [postgresql-common] postgresql-common: pg_ctlcluster segfault
Unable to merge bugs because:
package of #940276 is 'postgresql-client-common' not 'postgresql-common'
Failed to forcibly merge 940220: Did not alter merged bugs.

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
940220: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940220
940276: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940276
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#940808: gimp: File Open Image immediately crashes

[Debian Bug Tracking System]

Processing control commands:

> forcemerge 939754 940808
Bug #939754 {Done: Jeremy Bicha } [gimp] gimp: Crashes when 
I try to open an image or create a new one
Bug #939768 {Done: Jeremy Bicha } [gimp] gimp: After the 
last upgrade, GIMP crashes when creating a new image or opening an existing one.
Bug #939876 {Done: Jeremy Bicha } [gimp] gimp: segmentation 
fault on open
Bug #939977 {Done: Jeremy Bicha } [gimp] gimp: Crashes on 
Create with segmentation fault
Bug #939985 {Done: Jeremy Bicha } [gimp] Gimp: crashes when 
I try open or create an image
Bug #940008 {Done: Jeremy Bicha } [gimp] gimp: GIMP crashed 
with a fatal error: fatal error: Speicherzugriffsfehler
Bug #940011 {Done: Jeremy Bicha } [gimp] gimp: GIMP crashed 
with a fatal error: fatal error: Segmentation fault
Bug #940042 {Done: Jeremy Bicha } [gimp] gimp: GIMP crashed 
with a fatal error: fatal error: Speicherzugriffsfehler when opening a picture
Bug #940044 {Done: Jeremy Bicha } [gimp] gimp: fails to open 
file
Bug #940088 {Done: Jeremy Bicha } [gimp] gimp: crashes on 
opening exsisting or creating new image
Bug #940174 {Done: Jeremy Bicha } [gimp] gimp: GIMP crashed 
with a fatal error: fatal error: Segmentation fault
Bug #940177 {Done: Jeremy Bicha } [gimp] gimp: GIMP crashes 
when opening an image
Bug #940285 {Done: Jeremy Bicha } [gimp] segmentation fault 
at start
Bug #940472 {Done: Jeremy Bicha } [gimp] gimp: Gimp crashed 
with SIGSEGV
Bug #940525 {Done: Jeremy Bicha } [gimp] gimp: segfault on 
start
Bug #940561 {Done: Jeremy Bicha } [gimp] Gimp 2.8 crashes
Bug #940610 {Done: Jeremy Bicha } [gimp] gimp: segmentation 
fault
Bug #940808 [gimp] gimp: File Open Image immediately crashes
Severity set to 'grave' from 'important'
Marked Bug as done
Added tag(s) bullseye and sid.
Bug #939768 {Done: Jeremy Bicha } [gimp] gimp: After the 
last upgrade, GIMP crashes when creating a new image or opening an existing one.
Bug #939876 {Done: Jeremy Bicha } [gimp] gimp: segmentation 
fault on open
Bug #939977 {Done: Jeremy Bicha } [gimp] gimp: Crashes on 
Create with segmentation fault
Bug #939985 {Done: Jeremy Bicha } [gimp] Gimp: crashes when 
I try open or create an image
Bug #940008 {Done: Jeremy Bicha } [gimp] gimp: GIMP crashed 
with a fatal error: fatal error: Speicherzugriffsfehler
Bug #940011 {Done: Jeremy Bicha } [gimp] gimp: GIMP crashed 
with a fatal error: fatal error: Segmentation fault
Bug #940042 {Done: Jeremy Bicha } [gimp] gimp: GIMP crashed 
with a fatal error: fatal error: Speicherzugriffsfehler when opening a picture
Bug #940044 {Done: Jeremy Bicha } [gimp] gimp: fails to open 
file
Bug #940088 {Done: Jeremy Bicha } [gimp] gimp: crashes on 
opening exsisting or creating new image
Bug #940174 {Done: Jeremy Bicha } [gimp] gimp: GIMP crashed 
with a fatal error: fatal error: Segmentation fault
Bug #940177 {Done: Jeremy Bicha } [gimp] gimp: GIMP crashes 
when opening an image
Bug #940285 {Done: Jeremy Bicha } [gimp] segmentation fault 
at start
Bug #940472 {Done: Jeremy Bicha } [gimp] gimp: Gimp crashed 
with SIGSEGV
Bug #940525 {Done: Jeremy Bicha } [gimp] gimp: segfault on 
start
Bug #940561 {Done: Jeremy Bicha } [gimp] Gimp 2.8 crashes
Bug #940610 {Done: Jeremy Bicha } [gimp] gimp: segmentation 
fault
Merged 939754 939768 939876 939977 939985 940008 940011 940042 940044 940088 
940174 940177 940285 940472 940525 940561 940610 940808

-- 
939754: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939754
939768: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939768
939876: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939876
939977: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939977
939985: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939985
940008: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940008
940011: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940011
940042: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940042
940044: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940044
940088: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940088
940174: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940174
940177: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940177
940285: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940285
940472: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940472
940525: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940525
940561: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940561
940610: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940610
940808: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940808
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Laurent Bigonville]

On 20/09/19 11:16, Mark Hindley wrote:

On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
[...]

Bottom line, is libelogind even needed in the archive to achieve your goal
of having an implementation of the login1 D-Bus API not requiring systemd as
PID1?

Thanks.

I think you are correct that the login1 DBus API doesn't require libsystemd0 or
libelogind0. However some packages, notably policykit use the sd-login(3) API
which is part of libsystemd0 or libelogind0. Whilst the APIs, and symbol ABIs
are the same between the two libraries (with the caveats noted in the
libelogind0 package description) the implementations differ. I have been tolkd
int he past by elogind upstream that it is not possible for elogind to use
libsystemd0. For example libsystemd0 requires the concept of slices which
elogind doesn't have.

The only way I have got all of these components to work together on an elogind
systemd is to ensure everything uses libelogind0.


Can't this be stubbed or mocked on the elogind side?

Processed: tagging 940821

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 940821 + upstream
Bug #940821 [src:linux] linux-image-5.2.0-2-amd64: file cache corruption with 
nfs4
Added tag(s) upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
940821: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940821
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: bug 940821 is forwarded to https://lore.kernel.org/linux-nfs/ce4e1e84-50a1-c40b-a0bc-fa8ac4d76...@kot-begemot.co.uk/

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 940821 
> https://lore.kernel.org/linux-nfs/ce4e1e84-50a1-c40b-a0bc-fa8ac4d76...@kot-begemot.co.uk/
Bug #940821 [src:linux] linux-image-5.2.0-2-amd64: file cache corruption with 
nfs4
Set Bug forwarded-to-address to 
'https://lore.kernel.org/linux-nfs/ce4e1e84-50a1-c40b-a0bc-fa8ac4d76...@kot-begemot.co.uk/'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
940821: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940821
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#940821: linux-image-5.2.0-2-amd64: file cache corruption with nfs4

[Anton Ivanov]

Package: src:linux
Version: 5.2.9-2
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

NFSv4 caching is completely broken on SMP.

How to reproduce:

Option 1. clone openwrt, run while make clean && make -j `nproc` ; do true ; 
done

It will break depending on number of CPUs within several runs. 

Symptoms of breakage. A directory on the client looks empty. Example (mnt is an 
NFSv4 mount):

ls -laF 
/mnt/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
total 8
drwxr-xr-x 2 anivanov anivanov 4096 Sep 20 10:51 ./
drwxr-xr-x 3 anivanov anivanov 4096 Sep 20 10:51 ../

While it actually has a file in it (same on server):

ls -laF 
/exports/work/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
total 12
drwxr-xr-x 2 anivanov anivanov 4096 Sep 20 10:51 ./
drwxr-xr-x 3 anivanov anivanov 4096 Sep 20 10:51 ../
-rw-r--r-- 1 anivanov anivanov   32 Sep 20 10:51 ipcbuf.h

This cache entry on the client does not expire as it should per the NFSv4 
caching documentation - the only way of dealing with it is reboot, unmount or 
caches drop.

Option 2. Have your $HOME on nfsv4 and use thunderbird. Move mails between 
folders. Sooner or later (usually sooner) you will lose an email.

So this is both "breaks unrelated software" and "data loss" depending on what 
you are doing.

Tested on:

AMD Ryzen 5 2400G, AMD Ryzen 5 1600X, AMD Ryzen 5 1600, AMD A8-6500

Shows up on all. Fastest on the 6 core 12 thread ryzens, slowest on the AMD A8 
(takes up to 3 iterations of make there).

Brgds,

A.

-- Package-specific info:
** Version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.2.0-2-amd64 
root=UUID=8eb17efb-6574-42d0-885e-487b98364059 ro mitigations=off noht quiet

** Not tainted

** Kernel log:
[3.684402] input: HD-Audio Generic Front Mic as 
/devices/pci:00/:00:08.1/:09:00.3/sound/card0/input8
[3.684490] input: HD-Audio Generic Rear Mic as 
/devices/pci:00/:00:08.1/:09:00.3/sound/card0/input9
[3.684555] input: HD-Audio Generic Line as 
/devices/pci:00/:00:08.1/:09:00.3/sound/card0/input10
[3.685553] input: HD-Audio Generic Line Out as 
/devices/pci:00/:00:08.1/:09:00.3/sound/card0/input11
[3.685627] input: HD-Audio Generic Front Headphone as 
/devices/pci:00/:00:08.1/:09:00.3/sound/card0/input12
[3.806626] kvm: Nested Virtualization enabled
[3.806636] kvm: Nested Paging enabled
[3.806637] SVM: Virtual VMLOAD VMSAVE supported
[3.806637] SVM: Virtual GIF supported
[3.820371] MCE: In-kernel MCE decoding enabled.
[3.824533] EDAC amd64: Node 0: DRAM ECC disabled.
[3.824536] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[3.872569] pktcdvd: pktcdvd0: writer mapped to sr0
[3.900858] EDAC amd64: Node 0: DRAM ECC disabled.
[3.900860] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[3.948661] EDAC amd64: Node 0: DRAM ECC disabled.
[3.948662] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[3.996651] EDAC amd64: Node 0: DRAM ECC disabled.
[3.996652] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[4.002382] audit: type=1400 audit(1568973482.655:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=706 comm="apparmor_parser"
[4.002712] audit: type=1400 audit(1568973482.655:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=701 comm="apparmor_parser"
[4.005254] audit: type=1400 audit(1568973482.659:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=699 comm="apparmor_parser"
[4.007555] audit: type=1400 audit(1568973482.659:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=702 
comm="apparmor_parser"
[4.007558] audit: type=1400 audit(1568973482.659:6): 

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Mark Hindley]

On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
> Hello,
> 
> When I looked I elogind a while back I was able to build a package without
> having a public libelogind0, I basically had that in my debian/rules file:
> 
> # We only build the libelogind0 and libelogind-dev if we are building for
> # Devuan or its derivatives
> ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes)
> export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev
> endif
> 
> libelogind library is only needed for applications that want to interact
> with the daemon, in the ITP (#905388) bug I also noted that.
> 
> If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to
> communicate with the daemon part, was it checked that the API used is
> compatible? Is there documentation of the differences, if any?

Yes, the APIs are the same (deliberately so).

> Bottom line, is libelogind even needed in the archive to achieve your goal
> of having an implementation of the login1 D-Bus API not requiring systemd as
> PID1?

Thanks.

I think you are correct that the login1 DBus API doesn't require libsystemd0 or
libelogind0. However some packages, notably policykit use the sd-login(3) API
which is part of libsystemd0 or libelogind0. Whilst the APIs, and symbol ABIs
are the same between the two libraries (with the caveats noted in the
libelogind0 package description) the implementations differ. I have been tolkd
int he past by elogind upstream that it is not possible for elogind to use
libsystemd0. For example libsystemd0 requires the concept of slices which
elogind doesn't have.

The only way I have got all of these components to work together on an elogind
systemd is to ensure everything uses libelogind0.

Mark

Bug#925624: Bug#925624: abinit: ftbfs with GCC-9

[Matthias Klose]

Control: reassign -1 src:abinit

> or do you want to reassign it back?

yes

Processed: Re: Bug#925624: Bug#925624: abinit: ftbfs with GCC-9

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:abinit
Bug #925624 [gfortran-9] abinit: ftbfs with GCC-9
Bug reassigned from package 'gfortran-9' to 'src:abinit'.
Ignoring request to alter found versions of bug #925624 to the same values 
previously set
Ignoring request to alter fixed versions of bug #925624 to the same values 
previously set

-- 
925624: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925624
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#940703: [Debian-med-packaging] Bug#940703: augustus_3.3.3+dfsg-1_mips64el.changes REJECTED

[Sascha Steinbiss]

Hi Aurelien,

thanks for the quick reply!

>> 7.8 of the policy requires that I have an ‘=‘ version relation on the 
>> package listed in ‘Built-Using' — I am not even sure how I would determine 
>> that for the source package since it’s not even used in the build?
> 
> Quoting the corresponding sentence:
> 
> "the Built-Using field must list the corresponding source package for
> any affected binary package incorporated during the build."
> 
> So you definitely need to use the source version, that's why the package
> has been rejected by dak.


Okay. So to be precise: To satisfy the exact '=' relation I need to
determine at build time what version of libbam-dev is used in the build,
and then use that version number to declare a Built-Using on the source
package (samtools-legacy) with that version number?

Thanks
Sascha

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Adam Borowski]

On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
> When I looked I elogind a while back I was able to build a package without
> having a public libelogind0, I basically had that in my debian/rules file:
> 
> # We only build the libelogind0 and libelogind-dev if we are building for
> # Devuan or its derivatives
> ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes)
> export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev
> endif

That was the case initially, yes.  It might be worth going back to.

> libelogind library is only needed for applications that want to interact
> with the daemon, in the ITP (#905388) bug I also noted that.
> 
> If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to
> communicate with the daemon part, was it checked that the API used is
> compatible? Is there documentation of the differences, if any?

The API and dbus protocol are compatible (or at least are supposed to be).
However, per the request of policykit's maintainer, libelogind was instead
made ABI-compatible with libsystemd, and was made to replace it.

> Bottom line, is libelogind even needed in the archive to achieve your goal
> of having an implementation of the login1 D-Bus API not requiring systemd as
> PID1?

This approach was used until February, and did work well.  I'm a mere
user/sponsor thus I don't fully understand the reasons for switching.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#940703: [Debian-med-packaging] Bug#940703: augustus_3.3.3+dfsg-1_mips64el.changes REJECTED

[Aurelien Jarno]

On 2019-09-19 22:56, Sascha Steinbiss wrote:
> 
> 
> > On 19. Sep 2019, at 11:29, Aurelien Jarno  wrote:
> > 
> > Package: augustus
> > Version: 3.3.3+dfsg-1
> > Severity: serious
> > 
> > On 2019-09-18 23:34, Debian FTP Masters wrote:
> >> augustus_3.3.3+dfsg-1_mips64el.deb: Built-Using refers to non-existing 
> >> source package libbam-dev (= 0.1.19-4)
> >> 
> >> 
> >> Mapping sid to unstable.
> >> 
> >> ===
> >> 
> >> Please feel free to respond to this email if you don't understand why
> >> your files were rejected, or if you upload new files which address our
> >> concerns.
> >> 
> >> 
> >> 
> > 
> > The Built-Using field should use the source package (i.e.
> > samtools-legacy), not the binary package.
> 
> 
> Why? In the build am only using the static library from libbam-dev, not 
> compiling source code from the samtools-legacy source package. Sorry, but 
> this is a serious question as I am not sure what do do here.

The static library from libbam-dev is built using the source code from
samtools-legacy, so this code ends-up in the augustus package. It's not
the case of a shared library.

> 7.8 of the policy requires that I have an ‘=‘ version relation on the package 
> listed in ‘Built-Using' — I am not even sure how I would determine that for 
> the source package since it’s not even used in the build?

Quoting the corresponding sentence:

"the Built-Using field must list the corresponding source package for
any affected binary package incorporated during the build."

So you definitely need to use the source version, that's why the package
has been rejected by dak.

> Do I even need to provide a Built-Using here? Searching on code search for 
> libbam-dev and samtools-legacy did not turn up a single case where a 
> Built-Using was set.

If you package is statically against libbam-dev, yes you need to provide
a Built-Using field.

Aurelien

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


signature.asc
Description: PGP signature

Bug#918572: check FTBFS on ppc*: test failure

[Thierry fa...@linux.ibm.com]

On Mon, 07 Jan 2019 15:54:46 +0200 Adrian Bunk  wrote:

Source: check
Version: 0.12.0-0.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=check

...
FAIL: check_check_export
FAIL: check_check
PASS: test_output.sh
PASS: test_check_nofork.sh
PASS: test_check_nofork_teardown.sh
PASS: test_xml_output.sh
PASS: test_log_output.sh
PASS: test_set_max_msg_size.sh
PASS: test_tap_output.sh

   Check 0.12.0: tests/test-suite.log


# TOTAL: 9
# PASS:  7
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0



(powerpcspe builds with nocheck)



Could you recheck compilation as my last test with gcc-9 on SID passes. Thx
--
Thierry Fauck @ fr.ibm.com

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Laurent Bigonville]

Hello,

When I looked I elogind a while back I was able to build a package 
without having a public libelogind0, I basically had that in my 
debian/rules file:


# We only build the libelogind0 and libelogind-dev if we are building for
# Devuan or its derivatives
ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes)
export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev
endif

libelogind library is only needed for applications that want to interact 
with the daemon, in the ITP (#905388) bug I also noted that.


If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to 
communicate with the daemon part, was it checked that the API used is 
compatible? Is there documentation of the differences, if any?


Bottom line, is libelogind even needed in the archive to achieve your 
goal of having an implementation of the login1 D-Bus API not requiring 
systemd as PID1?


my 2¢