Bug#938550: spyder: Python2 removal in sid/bullseye

[Drew Parsons]

On 2019-10-15 13:19, PICCA Frederic-Emmanuel wrote:
It seems that wurlitzer which is a dependency of spyder-kernel is 
missing.


did you plan to add it ?


I didn't notice it, so wasn't planning to add it.  spyder_kernels 
imports without complaining, and spyder seems to start fine anyway. 
Where does it come to notice?


Drew

Bug#938141: python-requests-toolbelt: diff for NMU version 0.8.0-1.1

[Petter Reinholdtsen]

[Sandro Tosi]
> I've prepared an NMU for python-requests-toolbelt (versioned as
> 0.8.0-1.1) and uploaded it to DELAYED/7. Please feel free to tell me
> if I should delay it longer.

Thank you very much!

Perhaps you could like to become a co-maintainer or take over the
package?  The source git repo should be imported into Salsa and a new
maintainer upload should be done with your fixes.

I uploaded python-requests-toolbelt into Debian to get
https://tracker.debian.org/pkg/creepy > working, but creepy has
since been removed because its upstream no longer maintained it.

-- 
Happy hacking
Petter Reinholdtsen

Bug#938550: spyder: Python2 removal in sid/bullseye

[PICCA Frederic-Emmanuel]

It seems that wurlitzer which is a dependency of spyder-kernel is missing.

did you plan to add it ?

cheers

Bug#942358: RFS: osc2midi/0.2.5-1 Highly flexible and configurable OSC / JACK MIDI bridge

[Fernando Toledo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: osc2midi
   Version : 0.2.5-1
   Upstream Author : ssjackso...@gmail.com
 * URL : https://github.com/ssj71/OSC2MIDI
 * License : GPL-3+
 * Vcs : https://github.com/ftoledo/pkg-osc2midi
   Section : sound

It builds those binary packages:

  osc2midi - Highly flexible and configurable OSC / JACK MIDI bridge

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/o/osc2midi/osc2midi_0.2.5-1.dsc

Changes since the last upload:

   * Initial release (Closes: #942333)

Regards,

-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

Bug#693230: Bug#806572: RFS: multimail/0.50~20150922-1 [ITA]

[Fernando Toledo]

Hi People, i'm back (sorry i very busy with work/study) =|


On Mon, 5 Aug 2019 11:35:05 +0200 Mattia Rizzolo  wrote:
> 
> Bart Martens already changed the metadata of #693230 to match your
> intentions.

very good, thanks!

> 
> The next step for you would be to seek a sponsor to review and upload
> your package.  I'm generally happy to do that, however since this would
> be your first package in Debian I'd like to understand what is your
> knowledge of things like the BTS, what you followed (if anything) to
> work with the packaging, etc.

I'm not DD but i have some skill on packaging for Debian (not all, but
some to help me to work) :)

I was working on several packages (see pkg-* projects on github):

https://github.com/ftoledo

Also, i'm working on Huayra GNU/Linux a Debian derivated distro:

https://wiki.debian.org/Derivatives/Census/Huayra
https://github.com/HuayraLinux/
https://huayra.conectarigualdad.gob.ar

We have several customs packages and repositories too.

> 
> The fact that mentors.d.n is all green on your package is a good sign,
> but also I see you are not closing this bug report (#693230) with your
> upload, so something is missing.

i update the mentors package, now lintian says:

--
 – Package closes a ITA bug

wnpp:
#693230 (normal): ITA: multimail -- Offline reader for BW,
QWK,OMEN and SOUP
--

Is this enough, or should I add something else?

> 
> I'll be happy to review your package once you answer the above; for more
> details on my usual workflow and requirements, see
> https://people.debian.org/~mattia/sponsoring.html

I'm reading your requeriments, i hope to meet them and get the package
upload.

I am very grateful for your help!

Saludos!
-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

Bug#942357: debian-installer: Install and boot fails with... Volume group "-vg" not found

[Kingsley G. Morse Jr.]

Package: debian-installer
Version: AMD64 Testing October 7, 2019
Severity: normal
Tags: d-i

Dear Maintainer,

Thank you very much for your efforts to make
Debian available to so many people.

I've been testing the installer.

The main reason I'm writing is that I seem to have
uncovered a (wait for ...) BUG!

   * What led up to the situation?

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

1.) I burned 3 DVDs of the AMD64 Testing distribution
dated October 7, 2019.

2.) I installed from them, specifying

UEFI,

no network connection,

Xfce instead of Gnome,

No printer and

guided configuration of an encrypted
logical volume. I used the default
configuration of 

all available space,

root encrypted

swap encrypted

boot not encrypted

3.) I rebooted

   * What was the outcome of this action?

Volume group "-vg" not found
Cannot process volume group logger-vg

(The previous 2 lines were repeated about
30 times>)

  Gave up waiting for suspend/resume device
  Gave up waiting for root file system device. Common problems:
   - Boot args (cat /proc/cmdline)
 - Check rootdelay= (did the system wait long enough?)
   - Missing modules (cat /proc/modules; ls /dev)
  ALERT! /dev/mapper/--vg-root does not exist. Dropping to a 
shell!


  BusyBox v1.30.1 (bla bla bla...)

   * What outcome did you expect instead?

Xfce's login 

Thanks,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#940685: buster-pu: libsixel/1.8.2-1+deb10u1

[NOKUBI Takatsugu]

On Sat, 12 Oct 2019 21:47:30 +0900,
Adam D. Barratt wrote:
> I've flagged that for rejection, please re-upload as a source-only
> upload (ensuring that the changes file is _source.changes) so we can
> ensure that all of the binaries are built cleanly.

I had uploaded both stable and oldstable.

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Salvatore Bonaccorso]

Hi,

On Sat, Aug 17, 2019 at 10:37:43AM +0200, Salvatore Bonaccorso wrote:
> Hi Ansgar,
> 
> On Wed, Jun 19, 2019 at 08:39:50AM +0200, Salvatore Bonaccorso wrote:
> > Hi Ansgar,
> > 
> > On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote:
> > [...]
> > > > Sure, I understand that things works like that, I'm just showing a few
> > > > design points that could potentially be done differently.
> > > 
> > > We could also just not accept .buildinfo uploads when they don't contain
> > > useful information about published binaries, that is for source-only
> > > uploads.
> > > 
> > > Maybe I should reenable the check for this at least on security-master?
> > > It was rejecting uploads that are okay for unstable/experimental so I
> > > disabled it again the last time.
> > 
> > Thank you I think that would be a good compromise. Source-only uploads
> > remain possible for security uploads, and ftp-masters and security
> > team members do not need to roundtrip reuploading binary builds
> > (download, rename, resign ... reupload) and instead uploads which
> > contain a buildinfo file rejected giving the uploader a explanation
> > why, and the possiblity to just reupload a "proper" source only one.
> 
> We had a couple of occasions still where we needed to do fetch the
> builds, rename, resign and reupload the packages.
> 
> Any chance to enable the above check again? That would solve most of
> or issues and people which did upload a source only upload but
> containing a ${arch}.buildinfo would get their uploads rejected.

We still have recurring this issue, where people continue to upload
_sources.changes (even more frequently now I would say, given the
workflow for unstable/testing) but which include a _amd64.buildinfo.
The last one was the (not yet released) unbound update.

So if we can have this check enabled again for the security archive
this would help us a lot not having to workaround those rejected
uploads :)

Thanks for all your work!

Regards,
Salvatore

Bug#933426: mediainfo: diff for NMU version 18.12-2.1

[Olly Betts]

Control: tags 933426 + patch

Dear maintainer,

I've uploaded an NMU for mediainfo (versioned as 18.12-2.1).  A debdiff
of the changes is attached.

Cheers,
Olly
diff -Nru mediainfo-18.12/debian/changelog mediainfo-18.12/debian/changelog
--- mediainfo-18.12/debian/changelog	2018-12-27 20:29:43.0 +1300
+++ mediainfo-18.12/debian/changelog	2019-10-15 15:57:11.0 +1300
@@ -1,3 +1,11 @@
+mediainfo (18.12-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Update to build using libwxgtk3.0-gtk3-dev.
+(Closes: #933426)
+
+ -- Olly Betts   Tue, 15 Oct 2019 15:57:11 +1300
+
 mediainfo (18.12-2) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru mediainfo-18.12/debian/control mediainfo-18.12/debian/control
--- mediainfo-18.12/debian/control	2018-12-27 20:29:43.0 +1300
+++ mediainfo-18.12/debian/control	2019-10-15 15:57:08.0 +1300
@@ -6,7 +6,7 @@
dh-autoreconf,
libmediainfo-dev (>= 0.7.61),
libzen-dev (>= 0.4.25),
-   libwxgtk3.0-dev,
+   libwxgtk3.0-gtk3-dev,
zlib1g-dev,
pkg-config,
rename

Bug#942356: buster-pu: package spf-engine/2.9.0-4

[Scott Kitterman]

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

There are a number of important fixes proposed for this upload,
including a new bugfix release from upstream.  The changes are all
already in Testing (spf-engine is currently marked for removal from
Testing, but that's related to the overall bullseye python2 removal
effort - unrelated to these changes - and it should be resolved before
any removal happens).


The most important fix is:

  * Catch pyspf tracebacks so at least we don't die (thanks to Adi Pircalabu
for both the report and the suggested fix) (LP: #1842005)

spf-engine-2.9.1/spf_engine/__init__.py hunk at line 542 and 640

The next most important change is:

  * Correct over-writing of SPF identity by SPF reason for HELO checks and the
reverse for Mail From (LP: #1822685)

Which is the balance of the changes in spf_engine/__init.py.

These are small, low risk changes that will benefit users of both the
postfix policy server and milter variants of the package.

Similar to dkimpy-milter (same upstream made the same mistakes):

packaging and upstream fixes so sysvinit works.

This only affects the milter and it's totally broken now, so there is no
regression risk.

Finally, there are man page cleanups (deletion of obsolete .IX headers
that strictly aren't needed, but they are harmless and it'd be nice to
be able to just ship the new upstream.

Scott K
diff -Nru spf-engine-2.9.0/CHANGES spf-engine-2.9.1/CHANGES
--- spf-engine-2.9.0/CHANGES2019-02-01 18:58:14.0 -0500
+++ spf-engine-2.9.1/CHANGES2019-10-06 20:31:00.0 -0400
@@ -4,6 +4,14 @@
 #   ! = Changed something significant, or removed a feature
 #   * = Fixed a bug, or made a minor improvement
 
+--- 2.9.1 (2019-10-06)
+  * Use /run instead of /var/run
+  * Fix-up sysv init so it works
+  * Catch pyspf tracebacks so at least we don't die (thanks to Adi Pircalabu
+for both the report and the suggested fix) (LP: #1842005)
+  * Correct over-writing of SPF identity by SPF reason for HELO checks and the
+reverse for Mail From (LP: #1822685)
+
 --- 2.9.0 (2019-02-01)
   + Initial alpha release with pyspf-milter added
   * Use HOSTNAME for Authserv_Id lookup function from dkimpy-milter for both
diff -Nru spf-engine-2.9.0/debian/changelog spf-engine-2.9.1/debian/changelog
--- spf-engine-2.9.0/debian/changelog   2019-05-05 18:07:33.0 -0400
+++ spf-engine-2.9.1/debian/changelog   2019-10-14 19:04:55.0 -0400
@@ -1,3 +1,14 @@
+spf-engine (2.9.1-0+deb10u1) buster; urgency=medium
+
+  * New upstream bugfix release
+  * Put upstream provided init file where dh_installinit expects to find it
+so it is properly registered on install
+  * Update debian/watch so limit itself to version 2.9.x updates for buster
+  * Update debian/patches/0001-install-conf-fix.patch for missed change needed
+in sysv init
+
+ -- Scott Kitterman   Mon, 14 Oct 2019 19:04:55 -0400
+
 spf-engine (2.9.0-4) unstable; urgency=medium
 
   * Fix missing depends on python3-pkg-resources:
diff -Nru spf-engine-2.9.0/debian/gbp.conf spf-engine-2.9.1/debian/gbp.conf
--- spf-engine-2.9.0/debian/gbp.conf2019-05-05 18:06:13.0 -0400
+++ spf-engine-2.9.1/debian/gbp.conf2019-10-14 19:02:19.0 -0400
@@ -1,2 +1,2 @@
 [DEFAULT]
-debian-branch=debian/master
+debian-branch=debian/buster
diff -Nru spf-engine-2.9.0/debian/patches/0001-install-conf-fix.patch 
spf-engine-2.9.1/debian/patches/0001-install-conf-fix.patch
--- spf-engine-2.9.0/debian/patches/0001-install-conf-fix.patch 2019-05-05 
18:06:13.0 -0400
+++ spf-engine-2.9.1/debian/patches/0001-install-conf-fix.patch 2019-10-14 
19:04:00.0 -0400
@@ -9,15 +9,15 @@
  policyd-spf.conf.5  |  4 ++--
  setup.py|  9 +
  spf_engine/policyd_spf.py   |  2 +-
- system/pyspf-milter |  2 +-
+ system/pyspf-milter |  4 ++--
  system/pyspf-milter.service |  2 +-
- 6 files changed, 21 insertions(+), 21 deletions(-)
+ 6 files changed, 22 insertions(+), 22 deletions(-)
 
 diff --git a/policyd-spf.1 b/policyd-spf.1
-index 62d5992..0bc8bda 100644
+index e7b43fc..c189543 100644
 --- a/policyd-spf.1
 +++ b/policyd-spf.1
-@@ -147,12 +147,13 @@ $ policyd-spf (Start using installed config file)
+@@ -144,12 +144,13 @@ $ policyd-spf (Start using installed config file)
  
  $ policyd-spf \-h (Display usage message)
  
@@ -36,7 +36,7 @@
  
  Additionally, whitelisting certain IP addresses or IP addresses used by listed
  domains from SPF checks is supported.  Skipping SPF checks for local 
submission
-@@ -256,15 +257,13 @@ followed by a empty line:
+@@ -247,15 +248,13 @@ followed by a empty line:
   1. Add the following to /etc/postfix/master.cf:
  
  policyd-spf  unix  -   n   n   -   0   spawn
@@ -58,19 +58,19 @@
   2. Configure the Postfix policy service in /etc/postfix/main.cf:
  
 diff --git a/policyd-spf.conf.5 b/policyd-spf.conf.5

Bug#938141: python-requests-toolbelt: diff for NMU version 0.8.0-1.1

[Sandro Tosi]

Control: tags 938141 + patch
Control: tags 938141 + pending


Dear maintainer,

I've prepared an NMU for python-requests-toolbelt (versioned as 0.8.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-requests-toolbelt-0.8.0/debian/changelog python-requests-toolbelt-0.8.0/debian/changelog
--- python-requests-toolbelt-0.8.0/debian/changelog	2017-07-16 05:19:44.0 -0400
+++ python-requests-toolbelt-0.8.0/debian/changelog	2019-10-14 23:00:28.0 -0400
@@ -1,3 +1,10 @@
+python-requests-toolbelt (0.8.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938141
+
+ -- Sandro Tosi   Mon, 14 Oct 2019 23:00:28 -0400
+
 python-requests-toolbelt (0.8.0-1) unstable; urgency=medium
 
   * New upstream version 0.8.0.
diff -Nru python-requests-toolbelt-0.8.0/debian/control python-requests-toolbelt-0.8.0/debian/control
--- python-requests-toolbelt-0.8.0/debian/control	2017-07-16 05:18:53.0 -0400
+++ python-requests-toolbelt-0.8.0/debian/control	2019-10-14 23:00:28.0 -0400
@@ -6,12 +6,9 @@
 Build-Depends: debhelper (>= 9~)
 Build-Depends-Indep:
  dh-python,
- python-all (>= 2.6.6-3),
- python-setuptools (>= 0.6b3),
- python-requests,
- python-sphinx,
- python-sphinx-rtd-theme,
- python-doc,
+ python3-sphinx,
+ python3-sphinx-rtd-theme,
+ python3-doc,
  python3-all,
  python3-requests,
  python3-setuptools,
@@ -23,17 +20,6 @@
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/python-requests-toolbelt.git
 Vcs-Git: git://anonscm.debian.org/collab-maint/python-requests-toolbelt.git
 
-Package: python-requests-toolbelt
-Architecture: all
-XB-Python-Version: ${python:Versions}
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Utility belt for advanced users of python-requests
- Collection of utilities for python-requests
- It provides transport adapters: FingerprintAdapter, SSLAdapter,
- SourceAddressAdapter, SocketOptionsAdapter, TCPKeepAliveAdapter
- and authenticators: AuthHandler, GuessAuth, HTTPProxyDigestAuth
- Also a cookiejar, streaming helpers and more.
-
 Package: python3-requests-toolbelt
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
@@ -47,7 +33,7 @@
 Package: python-requests-toolbelt-doc
 Architecture: all
 Section: doc
-Depends: ${misc:Depends}, ${python:Depends}, ${sphinxdoc:Depends}
+Depends: ${misc:Depends}, ${sphinxdoc:Depends}
 Description: Utility belt for python3-requests (documentation)
  Collection of utilities for python3-requests: documentation
  It provides transport adapters: FingerprintAdapter, SSLAdapter,
diff -Nru python-requests-toolbelt-0.8.0/debian/rules python-requests-toolbelt-0.8.0/debian/rules
--- python-requests-toolbelt-0.8.0/debian/rules	2016-01-16 14:30:49.0 -0500
+++ python-requests-toolbelt-0.8.0/debian/rules	2019-10-14 23:00:24.0 -0400
@@ -7,7 +7,7 @@
 export PYBUILD_DISABLE=test
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_installdocs:
 	LC_ALL=C PYTHONPATH=. http_proxy='http://127.0.0.1:9/' sphinx-build -N -bhtml docs debian/html

Bug#934096: codelite: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

Control: tags -1 + pending

On Mon, Oct 14, 2019 at 09:16:36PM +0100, Olly Betts wrote:
> On Mon, Oct 14, 2019 at 09:07:40PM +0100, da...@codelite.co.uk wrote:
> > Yes, I actually uploaded one today (#942313). However that seems to be 
> > broken
> > by libwxsqlite3-3.0-dev, which still Depends on the GTK+2 wx dev package. 
> > As a
> > result both flavours are installed, and Alternatives selects the GTK+2 one.
> > I'll report this bug.
> 
> Oops.  It probably makes more sense for us to just reopen the wx
> transition bug for it (#933470) since that wasn't actually fully
> addressed.  I'll do that.

The libwxsqlite3-3.0-dev has responded quickly and uploaded a fix.

Cheers,
Olly

Bug#835566: please clarify docs regarding mr run

[Paul Wise]

On Tue, 2019-10-15 at 09:59 +0800, Paul Wise wrote:

> Any further thoughts or should I close this bug?

Some further thoughts from me:

If you want to change how the run command works, you can do that in
your mrconfig, the default just runs the args directly:

   [DEFAULT]
   run = "$@"

You could just evaluate it as shell code instead, or run a subshell:

   [DEFAULT]
   run = eval "$*"

   [DEFAULT]
   run = sh -c "$*"

Then you would be able to run something like this:

   $ mr run mr config '$MR_REPO' foo=bar bar=baz

You could create a new configure command to mr config the current repo:

   [DEFAULT]
   configure = mr config "$MR_REPO" "$@"

Then you would be able to run something like this:

   $ mr configure foo=bar bar=baz

myrepos could also change how `mr config` works to make it so that
passing only one argument means that `mr config "$MR_REPO" "$1" gets
run instead of the current action of returning an error. This would
only allow setting one value at a time, make it more convenient to use
when already in a repository but could be a surprising footgun when
used in a directory tree containing many repositories.

   $ mr config foo=bar
   mr config: not enough parameters

Another option would be to create a -r / --recurse option that would
make normally non-recursive commands like config or register process
all repositories instead. The advantage of this would be that it also
allows you to configure repos with multiple key=value items instead of
just one and the footgun would be hidden behind an explicit option.

   $ mr -r config foo=bar bar=baz

I'm inclined to make these changes to myrepos:

 * Make the config section optional when the current dir is a
   registered repos and derive the section from the current dir.
 * Add a recursive option that would apply to the config and register
   commands and cause them to do their jobs recursively.

In the meantime you should define and use a `mr configure` command.

Further thoughts welcome!

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#942355: dumb defaults for LogDir and CacheDir

[Trent W. Buck]

Package: apt-cacher-ng
Version: 3.2-2
Severity: minor

Right now apt-cacher-ng ships with TWO sets of default values:
the ones hard-coded into the binary, and
the ones in the default config file.

They don't match.  This is confusing.
Please make them match, and then (ideally) make the default acng.conf be just 
comments.

# mkdir fnord   # empty directory, i.e. compiled-in config
# /usr/lib/apt-cacher-ng/acngtool printvar -c fnord LogDir
/var/tmp
# /usr/lib/apt-cacher-ng/acngtool printvar -c fnord CacheDir
/var/tmp
# /usr/lib/apt-cacher-ng/acngtool printvar -c fnord SupportDir
/usr/lib/apt-cacher-ng

Those first two defaults are clearly dumb, and should be fixed.
Hopefully this is straightforward to do.

These also don't match the default acnf.conf.

# /usr/lib/apt-cacher-ng/acngtool printvar -c fnord ExThreshold
20
# /usr/lib/apt-cacher-ng/acngtool printvar -c fnord ReportPage

# /usr/lib/apt-cacher-ng/acngtool printvar -c fnord Remap-debrep
#



The reason I want this is because I want apt-cacher-ng to allow *only* these:

http://apt-cacher-ng.example.net:3142/debian
http://apt-cacher-ng.example.net:3142/debian-security

...but AFAICT to achieve that I have to DELETE "Remap"-gentoo  from acng.conf.
I don't think I can do that from a dropin, e.g. this doesn't work:

# cat /etc/apt-cacher-ng/zzz_cyber.conf
Remap-gentoo:

# /usr/sbin/apt-cacher-ng SocketPath=/run/apt-cacher-ng/socket -c 
/etc/apt-cacher-ng ForeGround=1
WARNING: No configuration was read from file:sfnet_mirrors
Invalid entry, no configuration: Remap-gentoo:
Error reading main options, terminating.

So I have to edit acng.conf itself.
augtool doesn't have a lens for acng.conf, because it's a weird "unique 
snowflake" format.
So I have to replace acng.conf entirely.
But LogDir and CacheDir have the wrong "default defaults".
So I have to set those back to the "non-default defaults" explicitly.
But that's ugly.
So I am writing this bug report. :-)


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

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

Bug#936270: Please fix calibre, or get it out of Debian

[Norbert Preining]

Hi Thomas,

On Tue, 15 Oct 2019, Thomas Goirand wrote:
> It's been nearly a month that the calibre package is in this shape, ie
> not converted to Python 3. Besides this:

Wrong. If you could step down from your github hate line, you could
check the experimental branch of the debian calibre package, which 
already is prepared for Python3.
export CALIBRE_PY3_PORT=1
SETUP=python3 setup.py
and it actually works. The only problem (AFAIS) at the moment are
- libqt is too old in Debian (5.12 has been released long ago)
- all the plugins will be broken.

> How is this a lie? There's no FUD either, just facts. There's also this,

Besides, that you never checked the facts, right? Have you build Calibre
once? have you tried to do it with Python3? You just rely on hearsay and
old bug reports. Very impressive.

> I don't see any sign that the upstream author has changed his mind, and
> is willing to do the work of moving to Python 3. Or has this changed? If

Yes it has, and looking (sorry, again your behated) at his github you
would have seen that there is considerable P3 conversion going on for
**months** now.

> so, please point to some upstream commit showing there's ongoing work.
> Then you'll be able to tell me I was *mistaking* (and not lying).

What about looking at
https://github.com/kovidgoyal/calibre/commits/master ??? I assume you
are able to understand commit messages like
py3 compat
Avoid error on python3 about str and bytes
Fix failing test on py3
py3 porting
etc etc etc.

> > Lie:
> >> to, this wont help. Doing BTS ping-pong wont help either.
> 
> I completely fail to see where the lie is... You've downgraded the
> severity for your package to normal, cloned it to cherrypy3 where you've
> set the severity to serious. That's BTS ping-pong to me. Or did I miss
> something?

No. Ping-pong would have been if I have re-downgraded after it was
raised recently. I accept the explanation of the recent raising of
severity, but my initial downgrade is completely in the authority
of the package maintainer.

So if you consider one time adjustment of severity a "ping-pong", then
about every maintainer here in Debian would play your so called
"ping-pong" game.

So please, stop calling out such things without providing reason.

> In any case, CC-ing the community team is a good idea, especially when
> gratuitously calling me a liar publicly.

Not gratuitously, not at all.

So please stop spreading FUD again and again, I am sick of it.
In your email you again spread lies like
It's been nearly a month that the calibre package is in
this shape, ie not converted to Python 3
and
I don't see any sign that the upstream author has changed his mind, and
is willing to do the work of moving to Python 3. Or has this changed? If
These kind of statements are the reason that upstream communication are
getting difficult. I have worked hard to get good communication with
upstream, and your unfounded statements, without even the slightest
trial to verify your statements are painful at best.

Before posting fake statements, please check the facts, they are public
in the git repositories.

Best

Norbert

--
PREINING Norbert   http://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#942354: nmu: nmu: binutils-mipsen_4~c4

[YunQiang Su]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

Hello,
The version 2.33-2 of binutils, has been in sid.
We need to rebuild binutils-mipsen with it.

  nmu binutils-mipsen_4~c4 . i386 amd64 x32 . -m 'Rebuild against
binutils 2.33-2'

Bug#938550: spyder: Python2 removal in sid/bullseye

[Drew Parsons]

On 2019-10-15 03:40, PICCA Frederic-Emmanuel wrote:

Hello

Hi Frédéric, I prepared spyder (and spyder-kernels) for python2 
removal.
 The removal of cloudpickle forces us to do it earlier than we 
otherwise

might have.


no problem for me :), the faster we get rid of Python2, the better.


With spyder, it made sense to me to keep spyder as the main binary
package, relegating spyder3 to a transitional dependency package. I 
set
/usr/bin/spyder as a symlink to spyder3 (manpage likewise). Let me 
know

if you're happy with that and we can go ahead with the upload.
Otherwise I can swap it to keep spyder3 as the binary package.



I think that you should set the section, oldlibs for spyder3 if this
is a transitional package.

then you can upload.



Thanks Fréd, I'll do that.

Drew

Bug#835566: please clarify docs regarding mr run

[Paul Wise]

On Sat, 27 Aug 2016 09:35:01 +0200 Marc Haber wrote:

> I would like to do something like
> 
> mr run mr config $REPOS foo=bar
> 
> This would need a placeholder for the repository name currently acted
> on. I am not sure whether this is supported.

The manual page documents that the MR_REPO environment variable is set
to the path of the top of the repository when running commands.

This command does what you want it to:

mr run sh -c 'mr config "$MR_REPO" foo=bar'

Any further thoughts or should I close this bug?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#936270: Please fix calibre, or get it out of Debian

[Thomas Goirand]

Hi Norbert,

I wrote to you not to be aggressive, because I've seen so many posts of
yours toward everyone. Yet, you still call me a liar. On top of this,
you give yourself the permission to lecture me about the CoC. Well done!

Now, let be still, despite your tone, to go to the bottom of the issue.

On 10/15/19 12:12 AM, Norbert Preining wrote:
> Hi Thomas,
> 
> thanks for your email. 
> In case you decide to return to generally agreed upon community
> standards of communication, including the CoC, and stop spreading
> FUD and lies, I will happily discuss with you the issues at hand.
> 
> FUD and lie:
>> particularly counter-productive, since we're not seeing any progress
>> being done on calibre, neither upstream or in Debian.

It's been nearly a month that the calibre package is in this shape, ie
not converted to Python 3. Besides this:

https://github.com/kovidgoyal/calibre/blob/master/setup.py#L20

How is this a lie? There's no FUD either, just facts. There's also this,
from the author itself:

https://bugs.launchpad.net/calibre/+bug/1714107

I don't see any sign that the upstream author has changed his mind, and
is willing to do the work of moving to Python 3. Or has this changed? If
so, please point to some upstream commit showing there's ongoing work.
Then you'll be able to tell me I was *mistaking* (and not lying).

BTW, if you're not aware, we just discussed, within the Python team,
about raising the severity of packages using Python 2 to serious. That's
regardless of what happened the dependency of the package. So even if I
revert the upload of cherrypy3 (which, again, can only happen if
tumbleweed does it on objgraph), your package will have to continue to
be RC.

I very much have the same opinion as Neil Williams here:
https://lists.debian.org/debian-python/2019/10/msg00043.html

Also, IMO you are mistaking when referring to Doko's mail about keeping
python 2 application. I don't think this would include something like
Calibre, unfortunately, especially it if has many Python 2 dependencies.

> Lie:
>> to, this wont help. Doing BTS ping-pong wont help either.

I completely fail to see where the lie is... You've downgraded the
severity for your package to normal, cloned it to cherrypy3 where you've
set the severity to serious. That's BTS ping-pong to me. Or did I miss
something?

In any case, CC-ing the community team is a good idea, especially when
gratuitously calling me a liar publicly.

Thomas Goirand (zigo)

Bug#942219: systemd-backlight@backlight:dell_backlight.service fails at boot for dell d600, d620, d820

[Rado S]

=- Michael Biebl wrote on Mon 14.Oct'19 at 23:20:57 +0200 -=

> Am 14.10.19 um 23:13 schrieb Rado S:
> > dell_backlight: Failed to write system 'brightness' attribute: No such 
> > device or address
> 
> Looks like a kernel or firmware/bios problem to me.
> 
> Since you didn't use reportbug there is no information about your used
> kernel.

It is in the journalctl output;
Linux version 4.19.0-6-686-pae (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2 (2019-08-28)

The dell d600 (also failing) uses the non-pae version of it.
The functioning vostro uses the same pae-version.

What more information can I provide?

Bug#941060: so what

[Maxime Jean]

Give to the maintainer the respect he deserves. I really think you 
doesn't understand at all how hard it is to build Chromium. How much 
time it requires specialy. Personally I prefer using an awesome version 
of chromium than a brand new one with a lot of bugs. In my case it's 
chromium 73 with vaapi(mojo decoder) working out of the box.

Bug#937634: python-cbor: diff for NMU version 1.0.0-1.1

[Sandro Tosi]

Control: tags 937634 + patch
Control: tags 937634 + pending


Dear maintainer,

I've prepared an NMU for python-cbor (versioned as 1.0.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-cbor-1.0.0/debian/changelog python-cbor-1.0.0/debian/changelog
--- python-cbor-1.0.0/debian/changelog	2017-09-13 17:34:26.0 -0400
+++ python-cbor-1.0.0/debian/changelog	2019-10-14 20:56:11.0 -0400
@@ -1,3 +1,10 @@
+python-cbor (1.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937634
+
+ -- Sandro Tosi   Mon, 14 Oct 2019 20:56:11 -0400
+
 python-cbor (1.0.0-1) unstable; urgency=medium
 
   * New upstream version 1.0.0 (Closes: #875707)
diff -Nru python-cbor-1.0.0/debian/control python-cbor-1.0.0/debian/control
--- python-cbor-1.0.0/debian/control	2017-09-13 17:34:26.0 -0400
+++ python-cbor-1.0.0/debian/control	2019-10-14 20:56:01.0 -0400
@@ -7,9 +7,6 @@
  python3-all,
  python3-setuptools,
  python3-all-dev,
- python-all,
- python-setuptools,
- python-dev,
 Standards-Version: 4.0.0
 X-Python-Version: >= 2.7
 X-Python3-Version: >= 3.3
@@ -24,18 +21,6 @@
  CBOR is comparable to JSON, has a superset of JSON’s ability, but serializes
  to a binary format which is smaller and faster to generate and parse.
  .
- The two primary functions are cbor.loads() and cbor.dumps(). This library
- includes a C implementation which runs 3-5 times faster than the Python
- standard library’s C-accelerated implementanion of JSON. This is also includes
- a 100% Python implementation
-
-Package: python-cbor
-Architecture: any
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
-Description: Python Implementation of RFC 7049. Concise Binary Object Representation (CBOR)
- CBOR is comparable to JSON, has a superset of JSON’s ability, but serializes
- to a binary format which is smaller and faster to generate and parse.
- .
  The two primary functions are cbor.loads() and cbor.dumps(). This library
  includes a C implementation which runs 3-5 times faster than the Python
  standard library’s C-accelerated implementanion of JSON. This is also includes
diff -Nru python-cbor-1.0.0/debian/rules python-cbor-1.0.0/debian/rules
--- python-cbor-1.0.0/debian/rules	2017-09-13 16:42:51.0 -0400
+++ python-cbor-1.0.0/debian/rules	2019-10-14 20:56:07.0 -0400
@@ -8,4 +8,4 @@
 
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#938865: yapsy: diff for NMU version 1.12.0-1.1

[Sandro Tosi]

Control: tags 938865 + patch
Control: tags 938865 + pending


Dear maintainer,

I've prepared an NMU for yapsy (versioned as 1.12.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru yapsy-1.12.0/debian/changelog yapsy-1.12.0/debian/changelog
--- yapsy-1.12.0/debian/changelog	2018-09-29 10:28:36.0 -0400
+++ yapsy-1.12.0/debian/changelog	2019-10-14 20:47:33.0 -0400
@@ -1,3 +1,10 @@
+yapsy (1.12.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938865
+
+ -- Sandro Tosi   Mon, 14 Oct 2019 20:47:33 -0400
+
 yapsy (1.12.0-1) unstable; urgency=medium
 
   * New upstream version 1.12.0 (Closes: #867900)
diff -Nru yapsy-1.12.0/debian/control yapsy-1.12.0/debian/control
--- yapsy-1.12.0/debian/control	2018-09-29 10:28:36.0 -0400
+++ yapsy-1.12.0/debian/control	2019-10-14 20:46:53.0 -0400
@@ -4,10 +4,7 @@
 Maintainer: Agustin Henze 
 Uploaders: Ulises Vitulli 
 Build-Depends: debhelper (>= 9)
-Build-Depends-Indep: python-all,
- python-sphinx,
- python-setuptools,
- python3-all,
+Build-Depends-Indep: python3-all,
  python3-setuptools,
  python-configparser,
  python3-sphinx,
@@ -18,18 +15,6 @@
 Vcs-Git: https://salsa.debian.org/debian/yapsy.git
 Vcs-Browser: https://salsa.debian.org/debian/yapsy
 
-Package: python-yapsy
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}, python-configparser
-Suggests: python-yapsy-doc
-Description: simple plugin system for Python applications
- Yapsy, or Yet Another Plugin SYstem, is a small library implementing the core
- mechanisms needed to build a plugin system into a wider application.
- .
- The main purpose is to depend only on Python's standard libraries (at least
- version 2.3) and to implement only the basic functionalities needed to detect,
- load and keep track of several plugins.
-
 Package: python3-yapsy
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru yapsy-1.12.0/debian/rules yapsy-1.12.0/debian/rules
--- yapsy-1.12.0/debian/rules	2018-09-29 10:28:36.0 -0400
+++ yapsy-1.12.0/debian/rules	2019-10-14 20:47:19.0 -0400
@@ -9,7 +9,7 @@
 export PYBUILD_NAME=$(DEB_SOURCE)
 
 %:
-	dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+	dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_clean:
 	dh_clean

Bug#937696: python-defer: diff for NMU version 1.0.6-2.1

[Sandro Tosi]

Control: tags 937696 + patch
Control: tags 937696 + pending


Dear maintainer,

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

Regards.

diff -Nru python-defer-1.0.6/debian/changelog python-defer-1.0.6/debian/changelog
--- python-defer-1.0.6/debian/changelog	2012-06-11 08:27:58.0 -0400
+++ python-defer-1.0.6/debian/changelog	2019-10-14 20:39:14.0 -0400
@@ -1,3 +1,10 @@
+python-defer (1.0.6-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937696
+
+ -- Sandro Tosi   Mon, 14 Oct 2019 20:39:14 -0400
+
 python-defer (1.0.6-2) unstable; urgency=low
 
   [Sebastian Heinlein]
diff -Nru python-defer-1.0.6/debian/control python-defer-1.0.6/debian/control
--- python-defer-1.0.6/debian/control	2012-06-11 08:27:58.0 -0400
+++ python-defer-1.0.6/debian/control	2019-10-14 20:39:14.0 -0400
@@ -3,9 +3,7 @@
 Priority: extra
 Maintainer: Sebastian Heinlein (devel) 
 Uploaders: Michael Vogt 
-Build-Depends: debhelper (>= 7.3),
-   python,
-   python-setuptools,
+Build-Depends: debhelper (>= 7.3), dh-python, python3-nose,
python3-setuptools,
python3-all,
 Standards-Version: 3.9.2
@@ -14,23 +12,6 @@
 X-Python3-Version: >= 3.2
 Vcs-Bzr: http://bzr.debian.org/collab-maint/python-defer/debian-sid
 
-Package: python-defer
-Architecture: all
-Section: python
-Depends: ${misc:Depends},
- ${python:Depends}
-Suggests: python-dbus
-Description: Small framework for asynchronous programming (Python 2)
- The defer module provides an easy way to write asynchrouns Python programs.
- It is greatly inspired by Twisted's defer, but hasn't got any external
- dependencies.
- .
- Furthermore it features decorators to write asynchronous D-Bus servers and
- clients.
- .
- At first defer was part of aptdaemon, but moved to a separate project in
- August of 2010.
-
 Package: python3-defer
 Architecture: all
 Section: python
diff -Nru python-defer-1.0.6/debian/python3-defer.install python-defer-1.0.6/debian/python3-defer.install
--- python-defer-1.0.6/debian/python3-defer.install	2012-06-11 08:27:58.0 -0400
+++ python-defer-1.0.6/debian/python3-defer.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python3
diff -Nru python-defer-1.0.6/debian/python-defer.install python-defer-1.0.6/debian/python-defer.install
--- python-defer-1.0.6/debian/python-defer.install	2012-06-11 08:27:58.0 -0400
+++ python-defer-1.0.6/debian/python-defer.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2.*
diff -Nru python-defer-1.0.6/debian/rules python-defer-1.0.6/debian/rules
--- python-defer-1.0.6/debian/rules	2012-06-11 08:27:58.0 -0400
+++ python-defer-1.0.6/debian/rules	2019-10-14 20:38:49.0 -0400
@@ -1,21 +1,8 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with=python2,python3
+	dh $@ --with=python3 --buildsystem=pybuild
 
 override_dh_auto_clean:
 	dh_auto_clean
 	rm -rf build *.egg-info po/aptdaemon.pot
-
-override_dh_auto_build:
-	dh_auto_build
-	set -ex; for python in $(shell py3versions -r); do \
-		$$python setup.py build; \
-	done;
-
-override_dh_auto_install:
-	dh_auto_install
-	set -ex; for python in $(shell py3versions -r); do \
-		$$python setup.py install --root=$(CURDIR)/debian/tmp --install-layout=deb; \
-	done;
-

Bug#942353: python-evtx: ImportError: No module named hexdump

[Jonathan Nieder]

Package: python-evtx
Version: 0.6.1-1
Severity: serious
Justification: missing dependency

$ evtx_dump.py
Traceback (most recent call last):
  File "/usr/bin/evtx_dump.py", line 20, in 
import Evtx.Evtx as evtx
  File "/usr/local/buildtools/current/sitecustomize/sitecustomize.py", line 
152, in SetupPathsAndImport
return real_import(name, globals, locals, fromlist, level)
  File "/usr/lib/python2.7/dist-packages/Evtx/Evtx.py", line 28, in 
import Evtx.Views as e_views
  File "/usr/lib/python2.7/dist-packages/Evtx/Views.py", line 25, in 
import Evtx.Nodes as e_nodes
  File "/usr/lib/python2.7/dist-packages/Evtx/Nodes.py", line 25, in 
import hexdump
ImportError: No module named hexdump

Looks similar to https://bugs.debian.org/851056. The fix there doesn't
seem to help here: there is a /usr/lib/python2.7/dist-packages/Evtx/hexdump.py
file, but "import hexdump" doesn't import it (should it be "import
Evtx.hexdump" instead?).

Thanks for packaging the evtx package!

Bug#942352: python3-scales: wrong package name

[Sandro Tosi]

Package: python3-scales
Severity: serious

Hello,
python3-scales installs a module in dist-packages/greplin/scales so it should be
called python3-greplin.scales , please rename it (handling properly the
transition)

Since it violates the policy, severity is set to serious.

Regards,
Sandro

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

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

Versions of packages python3-scales depends on:
ii  python3  3.7.3-1
ii  python3-six  1.12.0-1

python3-scales recommends no packages.

Versions of packages python3-scales suggests:
ii  python3-flask  1.0.2-3

Bug#938155: python-scales: diff for NMU version 1.0.9-2.1

[Sandro Tosi]

Control: tags 938155 + patch
Control: tags 938155 + pending


Dear maintainer,

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

Regards.

diff -Nru python-scales-1.0.9/debian/changelog python-scales-1.0.9/debian/changelog
--- python-scales-1.0.9/debian/changelog	2019-04-05 15:50:34.0 -0400
+++ python-scales-1.0.9/debian/changelog	2019-10-14 20:29:07.0 -0400
@@ -1,3 +1,10 @@
+python-scales (1.0.9-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938155
+
+ -- Sandro Tosi   Mon, 14 Oct 2019 20:29:07 -0400
+
 python-scales (1.0.9-2) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru python-scales-1.0.9/debian/control python-scales-1.0.9/debian/control
--- python-scales-1.0.9/debian/control	2019-04-05 15:50:31.0 -0400
+++ python-scales-1.0.9/debian/control	2019-10-14 20:29:07.0 -0400
@@ -5,10 +5,6 @@
 Build-Depends: debhelper (>= 9~)
 Build-Depends-Indep:
  dh-python,
- python-all (>= 2.7),
- python-nose,
- python-setuptools (>= 0.6b3),
- python-six,
  tox,
  python3-all,
  python3-nose,
@@ -19,17 +15,6 @@
 Vcs-Git: https://salsa.debian.org/debian/python-scales.git
 Vcs-Browser: https://salsa.debian.org/debian/python-scales
 
-Package: python-scales
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Provides: ${python:Provides}
-Suggests: python-bottle | python-flask
-Description: Application metrics for Python
- A library to generate metrics for Python. It provides counters, timers,
- 1/5/15 minute averaged rates, hierarchical metrics.
- It can send metrics to a log file, to Graphite for graphing or serve them
- through an HTTP server.
-
 Package: python3-scales
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru python-scales-1.0.9/debian/python-scales.docs python-scales-1.0.9/debian/python-scales.docs
--- python-scales-1.0.9/debian/python-scales.docs	2019-04-05 15:42:08.0 -0400
+++ python-scales-1.0.9/debian/python-scales.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README.md
diff -Nru python-scales-1.0.9/debian/rules python-scales-1.0.9/debian/rules
--- python-scales-1.0.9/debian/rules	2019-04-05 15:42:08.0 -0400
+++ python-scales-1.0.9/debian/rules	2019-10-14 20:28:59.0 -0400
@@ -4,7 +4,7 @@
 export PYBUILD_TEST_NOSE=1
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_clean:
 	rm -rf src/scales.egg-info

Bug#936702: hidapi-cffi: diff for NMU version 0.2.2-1.1

[Sandro Tosi]

Control: tags 936702 + patch
Control: tags 936702 + pending


Dear maintainer,

I've prepared an NMU for hidapi-cffi (versioned as 0.2.2-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru hidapi-cffi-0.2.2/debian/changelog hidapi-cffi-0.2.2/debian/changelog
--- hidapi-cffi-0.2.2/debian/changelog	2018-10-21 05:47:21.0 -0400
+++ hidapi-cffi-0.2.2/debian/changelog	2019-10-14 20:19:25.0 -0400
@@ -1,3 +1,10 @@
+hidapi-cffi (0.2.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936702
+
+ -- Sandro Tosi   Mon, 14 Oct 2019 20:19:25 -0400
+
 hidapi-cffi (0.2.2-1) unstable; urgency=low
 
   * New upstream release and add watch file (Closes: #910993)
diff -Nru hidapi-cffi-0.2.2/debian/control hidapi-cffi-0.2.2/debian/control
--- hidapi-cffi-0.2.2/debian/control	2018-10-21 05:47:21.0 -0400
+++ hidapi-cffi-0.2.2/debian/control	2019-10-14 20:19:14.0 -0400
@@ -2,16 +2,9 @@
 Maintainer: Aigars Mahinovs 
 Section: python
 Priority: optional
-Build-Depends: python-setuptools (>= 0.6b3), python3-setuptools, python-all (>= 2.6.6-3), python3-all, debhelper (>= 9), dh-python, python-cffi, python3-cffi, python-dev, python3-dev, libhidapi-dev
+Build-Depends: python3-setuptools, python3-all, debhelper (>= 9), dh-python, python3-cffi, python3-dev, libhidapi-dev
 Standards-Version: 4.2.1
 
-Package: python-hidapi
-Architecture: any
-Depends: ${misc:Depends}, ${python:Depends}, libhidapi-hidraw0 | libhidapi-libusb0, python-cffi (>= 0.8)
-Description: Python bindings for the HID API
- Python bindings for libhidapi for working with Human Interface Devices
- such as mouses and keyboards.
-
 Package: python3-hidapi
 Architecture: any
 Depends: ${misc:Depends}, ${python3:Depends}, libhidapi-hidraw0 | libhidapi-libusb0, python3-cffi (>= 0.8)
diff -Nru hidapi-cffi-0.2.2/debian/rules hidapi-cffi-0.2.2/debian/rules
--- hidapi-cffi-0.2.2/debian/rules	2018-10-21 05:47:21.0 -0400
+++ hidapi-cffi-0.2.2/debian/rules	2019-10-14 20:19:22.0 -0400
@@ -3,4 +3,4 @@
 export PYBUILD_NAME=hidapi
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#942351: python3-hidapi: why is arch:any?

[Sandro Tosi]

Package: python3-hidapi
Severity: important

Hello,
the package installs a python file, and so it's not arch:any and should be
marked as arch:all.

Regards,
Sandro

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

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

Versions of packages python3-hidapi depends on:
ii  libhidapi-hidraw0  0.9.0+dfsg-1
ii  libhidapi-libusb0  0.9.0+dfsg-1
ii  python33.7.3-1
ii  python3-cffi   1.12.3-1

python3-hidapi recommends no packages.

python3-hidapi suggests no packages.

Bug#937721: python-ebooklib: diff for NMU version 0.15~ds0-1.1

[Sandro Tosi]

Control: tags 937721 + patch
Control: tags 937721 + pending


Dear maintainer,

I've prepared an NMU for python-ebooklib (versioned as 0.15~ds0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-ebooklib-0.15~ds0/debian/changelog python-ebooklib-0.15~ds0/debian/changelog
--- python-ebooklib-0.15~ds0/debian/changelog	2014-05-01 12:45:46.0 -0400
+++ python-ebooklib-0.15~ds0/debian/changelog	2019-10-14 20:12:51.0 -0400
@@ -1,3 +1,10 @@
+python-ebooklib (0.15~ds0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937721
+
+ -- Sandro Tosi   Mon, 14 Oct 2019 20:12:51 -0400
+
 python-ebooklib (0.15~ds0-1) unstable; urgency=low
 
   * Initial upload to Debian, closes: #745542
diff -Nru python-ebooklib-0.15~ds0/debian/control python-ebooklib-0.15~ds0/debian/control
--- python-ebooklib-0.15~ds0/debian/control	2014-05-01 13:01:58.0 -0400
+++ python-ebooklib-0.15~ds0/debian/control	2019-10-14 20:12:25.0 -0400
@@ -5,11 +5,8 @@
 Build-Depends:
  debhelper (>= 8),
  dh-python,
- python-all (>= 2.7.3-4~),
- python-lxml,
- python-setuptools,
- python-six,
- python-sphinx (>= 1.0.7+dfsg),
+ python3-lxml,
+ python3-six,
  python3-all,
  python3-setuptools,
  python3-sphinx
@@ -20,23 +17,6 @@
 Vcs-Git: https://alioth.debian.org/anonscm/git/collab-maint/python-ebooklib.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/python-ebooklib.git
 
-Package: python-ebooklib
-Architecture: all
-Depends:
- python-lxml,
- python-six,
- ${misc:Depends},
- ${python:Depends}
-Description: Python 2 E-book library for handling EPUB2/EPUB3/Kindle formats
- EbookLib is a Python library for managing EPUB2/EPUB3 and Kindle files. It's
- capable of reading and writing EPUB files programmatically (Kindle support is
- under development).
- .
- The API is designed to be as simple as possible, while at the same time making
- complex things possible too. It has support for covers, table of contents,
- spine, guide, metadata and more. EbookLib works with Python 2.7 and Python
- 3.3, this is the Python 2 version of the package.
-
 Package: python3-ebooklib
 Architecture: all
 Depends:
diff -Nru python-ebooklib-0.15~ds0/debian/python-ebooklib.docs python-ebooklib-0.15~ds0/debian/python-ebooklib.docs
--- python-ebooklib-0.15~ds0/debian/python-ebooklib.docs	2014-05-01 13:34:45.0 -0400
+++ python-ebooklib-0.15~ds0/debian/python-ebooklib.docs	1969-12-31 19:00:00.0 -0500
@@ -1,5 +0,0 @@
-AUTHORS.txt
-CHANGES.TXT
-README.md
-VERSION.txt
-_build/html/
diff -Nru python-ebooklib-0.15~ds0/debian/rules python-ebooklib-0.15~ds0/debian/rules
--- python-ebooklib-0.15~ds0/debian/rules	2014-05-01 13:42:32.0 -0400
+++ python-ebooklib-0.15~ds0/debian/rules	2019-10-14 20:12:40.0 -0400
@@ -6,7 +6,7 @@
 export REPACK_SH=$(CURDIR)/debian/repack.sh
 
 %:
-	dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+	dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_build:
 	dh_auto_build

Bug#937855: python-jsonext: Python2 removal in sid/bullseye

[peter green]

severity 937855 serious
thanks

python-jsonext depends on the python-arrow binary package, which has already 
been dropped by the python-arrow source package.

Bug#936270: Please fix calibre, or get it out of Debian

[John Scott]

On Mon, 14 Oct 2019 16:05:04 +0200 Thomas Goirand  wrote:
>  it wont change the fact that Python2 is being removed from Bullseye 
because it's dead upstream on the 1st of January next year.

That's not a fact, Bullseye can still ship with Python 2 if needed
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931659#17

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

Bug#941703: [Pkg-gtkpod-devel] Bug#941703: libimobiledevice6: Crashes upower with stack smashing when connecting an iPhone

[Diego Escalante Urrelo]

Sorry for the radio silence, I was away for a few days.
Just for reference, I run into the crash after updating my unstable
system on 2019-09-30, and it seems libusbmuxd was updated:
libusbmuxd4:amd64 (1.1.0~git20181007.07a493a-1, 1.1.0~git20190924.b097ea3-2)

I had no idea libusbmuxd behaved like that with its types/API, I got
to that same struct but didn't even consider it had been changed
without notice!

Anyway, thanks for your work on this. Let me know if I can help with
anything else.

On Sat, Oct 5, 2019 at 8:41 AM Yves-Alexis Perez  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Sat, 2019-10-05 at 14:50 +0200, Yves-Alexis Perez wrote:
> > That beeing said, it would be helpful to know when the problem started
> > appearing for you. libimobiledevice wasn't updated recently, but libusbmuxd
> > was, and it seems that there might be a really tight dependency between 
> > both,
> > and the libimobiledevice currently in testing and sid (there's a one sitting
> > in NEW) was built against the previous version of libusbmuxd.
>
> If the crashed appeared recently, I'd guess it's due to the struct change in:
> https://github.com/libimobiledevice/libusbmuxd/commit/f5a7387a54ae08c9cd1d83a415393e0e909dc6e6#diff-038b1c435b1baca0fc7faaf5e375f401L37
>
> Unfortunately, there is no real SONAME tracking in libusbmuxd apparently, and
> I missed it too.
>
> I think a rebuild of libimobiledevice should fix the issue at hand, until the
> new one exits NEWS. Long term a proper solution should be found, I'll try to
> ask upstream about that.
>
> Regards,
> - --
> Yves-Alexis
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2YnXcACgkQ3rYcyPpX
> RFskrggApmspfJRWofKg3JxrG5JSQpgWmNyk4GPqw2lAcMllqYnQZ2Gu7lPlHziN
> JNaADOPxze+frdyapaOHQBoccFT/gTcyyZ+y7nPvM7OiJux8GIENV8fKYV/YBBON
> Y5C8VeOQC080yBfB+V4zJadrLT1AdoOLPuD6ve9CH3UfClIsiHu1bcvIN5B0tAZW
> JKVK/J2kLMtJRLrH2Q9zkXkOrSC9q/Pb+6VkHN75pIbYc9K1YKK0Dim3cT++OXHb
> nqRKXWpX/275BxQpnuQuoXxqLSDsk6jSGEZUx2qikbJgyyBWAeT7iNds15iCu1j/
> nIs8wURnEXWMLDy4M+SMLsy+EcACXA==
> =Lm+g
> -END PGP SIGNATURE-

Bug#936241: broctl: Python2 removal in sid/bullseye

[Scott Kitterman]

It looks like broctl is replaced by zeekctl upstream:

https://github.com/zeek/zeekctl

It does support python3, so it'd be great to see this updated to the newer 
version.

Scott K

Bug#942350: repmgr: autopkgtest fails with postgresql 12 libraries

[peter green]

Package: repmgr
Version: 4.2.0-2
Severity: serious

postgresql-12 recently took over a bunch of library packages from 
postgresql-11. This seems to have caused repmgr's autopkgtest to fail with a 
bunch of undefined symbol errors.

This can be seen with both testings version (tested as part of the testing 
migration checks for postgresql 12) and unstable's version (tested as part of 
regular tests in unstable) of repmgr.

https://ci.debian.net/data/autopkgtest/testing/amd64/r/repmgr/3142337/log.gz
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/repmgr/3156494/log.gz

P.S. You also need to make a source-only upload so your package can migrate to 
testing.

Bug#938692: trace-summary: Python2 removal in sid/bullseye

[Scott Kitterman]

On Fri, 30 Aug 2019 07:56:17 + Matthias Klose  wrote:
> Package: src:trace-summary
> Version: 0.88-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>   
>   This is the preferred option.

Debdiff to switch to python3 attached.  Although I wrote the changelog in the 
style of an NMU, I do not currently plan to NMU the package.  I have verified 
that with the debdiff applied the package builds a correct python3 package in 
unstable (with appropriate depends and shebang).  I have not verified the 
package works as I'm not familiar with it.  Upstream does support python3, so 
in theory it should be fine.

I would like to drop the python-subnettree binary from subnettree sooner 
rather than later and this is one of the two blockers.  I would appreciate it 
if you would take time to address it soon.  If you would prefer that I upload 
the NMU, please let me know and I will do so.

Scott Kdiff -Nru trace-summary-0.88/debian/changelog trace-summary-0.88/debian/changelog
--- trace-summary-0.88/debian/changelog	2018-12-26 10:54:40.0 -0500
+++ trace-summary-0.88/debian/changelog	2019-10-14 18:35:34.0 -0400
@@ -1,3 +1,10 @@
+trace-summary (0.88-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to python3 (Closes: #938692)
+
+ -- Scott Kitterman   Mon, 14 Oct 2019 18:35:34 -0400
+
 trace-summary (0.88-1) unstable; urgency=medium
 
   * New upstream version 0.88
diff -Nru trace-summary-0.88/debian/control trace-summary-0.88/debian/control
--- trace-summary-0.88/debian/control	2018-12-26 10:54:01.0 -0500
+++ trace-summary-0.88/debian/control	2019-10-14 18:35:34.0 -0400
@@ -5,7 +5,7 @@
 Uploaders: Hilko Bengen 
 Build-Depends: debhelper (>= 11),
dh-python,
-   python | python-all | python-dev | python-all-dev
+   python3-all
 Standards-Version: 4.3.0
 Homepage: https://www.bro.org/sphinx/components/trace-summary/README.html
 Vcs-Git: https://salsa.debian.org/bro-team/trace-summary.git
@@ -14,8 +14,8 @@
 Package: trace-summary
 Architecture: all
 Depends: ${misc:Depends},
- ${python:Depends},
- python-subnettree
+ ${python3:Depends},
+ python3-subnettree
 Description: tool for generating break-downs of network traffic
  trace-summary is a Python script that generates break-downs of network
  traffic, including lists of the top hosts, protocols, ports,
diff -Nru trace-summary-0.88/debian/rules trace-summary-0.88/debian/rules
--- trace-summary-0.88/debian/rules	2018-12-21 17:51:02.0 -0500
+++ trace-summary-0.88/debian/rules	2019-10-14 18:35:34.0 -0400
@@ -4,6 +4,9 @@
 include /usr/share/dpkg/default.mk
 
 %:
-	dh $@ --with=python2
+	dh $@ --with=python3
+
+override_dh_python3:
+	dh_python3 --shebang=/usr/bin/python3
 
 override_dh_auto_build override_dh_auto_test:

Bug#942284: [Pkg-net-snmp-devel] Bug#942284: libsnmp-perl: perl module SNMP broken

[Craig Small]

Thanks for the analysis Gregor,
  It explains why when I built it by hand it seemed to work ok. There was a
patch to fix parallel build where something needed to depend on something
else. I suspect that there needs to be another (or more) of these
dependencies.
Odd how if it doesn't find the library it just doesn't abort instead of
merrily making a bad module, but there you go.

Probably also explains why the reproducible build check always fails.

It gives me a place to look, thanks!


 - Craig


On Tue, 15 Oct 2019 at 06:07, gregor herrmann  wrote:

> On Mon, 14 Oct 2019 10:34:41 +1100, Craig Small wrote:
>
> > > libsnmp-perl is broken.
> > Ouch, I don't use the module (or Perl much for that matter) but that's
> very
> > broken. No idea what's going on but it worries me that
> > netsnmp_ds_get_boolean is the first function in that module which means a
> > coincidence or all functions are not available.
>
> Some notes:
>
> % apt-cache --no-all-versions show libsnmp-perl | grep Depends
> Depends: perl (>= 5.30.0-6), perlapi-5.30.0, libc6 (>= 2.15)
>
> So the perl package doesn't depend on any snmp libraries. The
> previous version had
> Depends: perl (>= 5.30.0-5), perlapi-5.30.0, libc6 (>= 2.15),
> libsnmp30 (>= 5.7.3+dfsg)
>
> Digging around in the git repo shows that the perl build system has
> been changed. (No idea if this is related.)
>
> Looking at the (local) build log we see:
>
> … well different things at each build, but once I saw the perl
> modules built first in dh_auto_build with warnings about missing C
> libraries …
>
> Upstream ChangeLog says:
>
> The Perl module build problems were caused by a concurrent build
> (make -j) and not by a problem in any of the Makefile.PL files.
>
> When I try
>
> %:
> dh $@ --no-parallel
>
> I end up with
>
> Depends: perl (>= 5.30.0-6), perlapi-5.30.0, libc6 (>= 2.15),
> libsnmp35 (>= 5.8+dfsg)
>
> and the problem is gone:
>
> % perl -MSNMP -e 1
> %
>
> So it looks like the "whole" problem is that net-snmp is not
> parallel-build safe …
>
> Not sure if --no-parallel is an acceptable solution but at least the
> area of the problem is a bit clearer now. (Fixing the many
> Makefile.*s might be cleaner but that's too much for me now.)
>
>
> Cheers,
> gregor
>
>
> --
>  .''`.  https://info.comodo.priv.at -- Debian Developer
> https://www.debian.org
>  : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649
> AA06
>  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation
> Europe
>`-
>

Bug#931628: lvm2: volumes not activated at boot after upgrade from stretch to buster

[Ben Scott]

I just encountered the same problem on an upgrade from 9.x to 10.1,
when using LABEL= directives in /etc/fstab.  I also had to use
"vgchange -ay" in the boot rescue shell.  Changing fstab to use
/dev/vg*/* paths resulted in a system that boots without intervention.


reportbug --template lvm2 output includes

Package: lvm2
Version: 2.03.02-3

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

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.155-3
ii  dmsetup   2:1.02.155-3
ii  libaio1   0.3.112-3
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-10
ii  libdevmapper-event1.02.1  2:1.02.155-3
ii  libdevmapper1.02.12:1.02.155-3
ii  libreadline5  5.2+dfsg-3+b13
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-7~deb10u1
ii  libudev1  241-7~deb10u1
ii  lsb-base  10.2019051400

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.7.6-2.1

Failing /etc/fstab included these lines

LABEL=DEB_ROOT  /   ext4noatime 0 1
LABEL=DEB_USR   /usrext4noatime 0 2
LABEL=DEB_VAR   /varext4noatime 0 2
LABEL=BOOT  /boot   ext4noatime 0 2
LABEL=TMP   /tmpext4noatime,nodev   0 2
LABEL=HOME  /home   ext4noatime 0 2
LABEL=ALL   /allext4noatime 0 2
LABEL=SWAP  swapswapsw  0 0


Working /etc/fstab includes these lines

/dev/vgfast/deb_root/   ext4noatime
 0 1
/dev/vgfast/deb_usr /usrext4noatime
 0 2
/dev/vgfast/deb_var /varext4noatime
 0 2
/dev/vgfast/tmp /tmpext4noatime,nodev
 0 2
/dev/vgfast/home/home   ext4noatime
 0 2
/dev/vgfast/all /allext4noatime
 0 2
/dev/vgfast/swapswapswapsw
 0 0
LABEL=BOOT  /boot   ext4noatime
 0 2

Bug#891877: Have either synaptic removed or have it rebuilt with libgtk3-perl in it recommends.

[shirish शिरीष]

Reply in-line :-

On 14/10/2019, Michael Vogt  wrote:
> On Sun, Oct 13, 2019 at 05:58:30AM +0200, intrigeri wrote:
>> Hi,
> Hi,
>

Hi,

>> shirish शिरीष:
>> > Dunno if this is the right place to discuss it or not. Integri asked
>> > hence sharing.
> [..]
>> AFAICT:
>>
>>  - The synaptic codebase does not use libgtk2-perl directly.
>>  - This Recommends is historically in place so that the user
>>can benefit from debconf's GNOME frontend.
>>  - debconf's GNOME frontend has been ported to libgtk3-perl 1.5 years
>>ago (first released in 1.5.66):
>>https://salsa.debian.org/pkg-debconf/debconf/commit/0250616b
>>
>> Hence, the current "Recommends: libgtk2-perl" has been useless
>> for a year an a half. With libgtk2-perl being phased out,
>> this Recommends is now a more serious problem. On top of that,
>> a suitable dependency on libgtk3-perl is missing.
>>
>> Jeremy Bicha filed #891877 a while ago, requesting that Synaptic's
>> dependencies are updated accordingly. I believe the actions Jeremy
>> suggested on #891877 will solve the problem shirish is raising here,
>> improve the life of Synaptic's users, and make it clearer what is the
>> status of libgtk2-perl in the archive.
>>
>> Thoughts?
>>
>> (Oh my, so many words for a bug that can be fixed by s/2/3/ in one
>> single place :)
>
> Thanks for looking into this and sorry that this slipped my radar. I
> updated the dependency in git and depending on urgency can do an
> upload very soon - I guess we want one quickly?
>

That will be good, yes :)

> Cheers,
>  Michael
>

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#940266: closed by Fabian Wolff (Re: z3: FTBFS on hppa - objects in shared libraries need to be compiled with -fPIC)

[John David Anglin]

Yes, it does!

Thanks,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#936270: Please fix calibre, or get it out of Debian

[Norbert Preining]

Hi Thomas,

thanks for your email. 
In case you decide to return to generally agreed upon community
standards of communication, including the CoC, and stop spreading
FUD and lies, I will happily discuss with you the issues at hand.

FUD and lie:
> particularly counter-productive, since we're not seeing any progress
> being done on calibre, neither upstream or in Debian.

Lie:
> to, this wont help. Doing BTS ping-pong wont help either.

Best

Norbert

--
PREINING Norbert   http://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#942349: buster-pu: package ublock-origin/1.18.4+dfsg-2

[Markus Koschany]

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

Hello release team,

there will be a new Firefox ESR version in Buster and Stretch soon.
Unfortunately the popular Firefox/Chromium addon ublock-origin in
Buster and Stretch will not work anymore with Firefox 68. Chromium
users are not affected. This is Debian bug

https://bugs.debian.org/925337

I propose to backport the current version in testing to Buster and
Stretch to resolve the issue. This is really straightforward because
ublock-origin is a leaf package that consists mostly of Javascript,
HTML and some CSS files. If you agree with the backport I will upload

1.22.2+dfsg-1~deb10u1 to Buster

and

1.22.2+dfsg-1~deb9u1 to Stretch

Regards,

Markus

Bug#837415: [arm64] segmentation fault

[Fabian Wolff]

Hi Ralf,

since I don't have an arm64 machine available to try this out myself: Could you
check whether this problem still exists in the current version of z3?

Your bug report refers to a quite old version of z3, so I'd say there is a good
chance that the issue has been fixed since then. If not, then at least I know I
need to forward the issue to upstream.

Best regards,
Fabian

On Sun, 11 Sep 2016 14:43:33 +0200 Ralf Treinen 
 wrote:
> Package: z3
> Version: 4.4.1-0.2
> 
> Hello, executing z3 on arm64 on the attached file produces a Segmentation
> fault, while it works fine on amd64. I didn't check any other architectures.
> 
> z3 -smt2 gauss-Gauss-WP_parameter_gauss.smt2 
> Segmentation fault
> 
> -Ralf.

Bug#942347: RM: wifi-radar -- RoQA; orphaned, dead upstream, depends on legacy libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove wifi-radar. It's orphaned since > 2 years without
an adopter. It depends on pygtk2 (which is deprecated) and Python 2,
both of which are not addressed upstream (the project seems stalled/dead)

Cheers,
Moritz

Bug#942348: nginx-common: ftplugin/nginx.vim is not in registry

[sergio]

Package: nginx-common
Version: 1.16.1-2
Severity: normal

Dear Maintainer,

/usr/share/vim/addons/ftplugin/nginx.vim
is not listed in /usr/share/vim/registry/nginx.yaml

Bug#942346: ferm.vim

[sergio]

Package: ferm
Version: 2.4-1
Severity: normal

Dear Maintainer,

please include vim files for ferm
https://github.com/cometsong/ferm.vim

Bug#942342: traitlets: please make the output reproducible

[Chris Lamb]

Chris Lamb wrote:

> Patch attached.

Let's try that again:

--- a/traitlets/traitlets.py
+++ b/traitlets/traitlets.py
@@ -2366,6 +2366,10 @@ class Set(List):
 """
 super(Set, self).__init__(trait, default_value, minlen, maxlen, 
**kwargs)
 
+def make_dynamic_default(self):
+# Ensure default value is sorted for a reproducible build
+return sorted(super(Set, self).make_dynamic_default())
+
 
 class Tuple(Container):
 """An instance of a Python tuple."""


Regards,

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

Bug#942342: traitlets: please make the output reproducible

[Chris Lamb]

forwarded 942342 https://github.com/ipython/traitlets/pull/535
thanks

I've forwarded this upstream here:

  https://github.com/ipython/traitlets/pull/535


Regards,

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

Bug#942345: nginx-common: vim files

[sergio]

Package: nginx-common
Version: 1.16.1-2
Severity: normal

Dear Maintainer,

nginx-common provides vim's ftdetect, ftplugin, indent and syntax files.
But all of them are in the "addons" directory, that is for
vim-addon-manager.

Is there any debian recommendations how to provide vim files and why not
to put them directly into
/usr/share/vim/(ftdetect|ftplugin|indent|syntax)?

If putting them directly is wrong solution vim-addon-manager should
be added in to suggests or recommends.

Bug#942344: why3: does not work with current version of z3

[Fabian Wolff]

Package: why3
Severity: important
X-Debbugs-CC: pkg-llvm-t...@lists.alioth.debian.org

Dear maintainer,

in share/provers-detection-data.conf (in the why3 source tree), only z3 versions
up to 4.8.4 are listed as "version_ok". But the 4.8.4 release of z3 was almost
two years ago and has since been superseded by two later releases, one of which
(4.8.6) is now finally available in Debian unstable.

However, its arrival has caused an autopkgtest regression for why3, which also
blocks z3 from migrating to testing (among other things that I will fix soon):

  https://ci.debian.net/data/autopkgtest/testing/amd64/w/why3/3154338/log.gz

This seems to be caused by why3's version requirement on z3 <= 4.8.4 as
mentioned above.


Please either add a versioned dependency on z3 in debian/control, or add more
acceptable z3 versions to your prover detection system, or, ideally, rewrite
your prover detection system so that this failure won't happen again the next
time a new z3 release is packaged for Debian.

Best regards,
Fabian

Bug#908802: asttest missing from asttest

[Moritz Mühlenhoff]

On Fri, Sep 14, 2018 at 08:05:40AM +0200, Helmut Grohne wrote:
> Package: asttest
> Version: 0.0.0+svn.5781-2
> Severity: grave
> 
> The asttest package lacks the asttest binary mentioned in the package
> description. In fact the asttest package is empty beyond a changelog and
> a copyright file. It doesn't even have dependencies. It's useless as is.

This might be just a case of an outdated package description?

--
asterisk-testsuite (0.0.0+svn.5781-1) unstable; urgency=medium

* New upstream release.
* asttest is now a dummy package (Closes: #764905, #764906, #764907).
--

Although the questions remains what practical value the package offers...

Cheers,
Moritz

Bug#942342: traitlets: please make the output reproducible

[Chris Lamb]

Source: traitlets
Version: 4.3.3-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness toolchian
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that traitlets generates non-reproducible output which is affecting
the reproducibility of other packages. For example, in nbconvert:

  -Default: […] {'image/jpeg', 'image/svg+xml', 'ap
plication/pdf',
  +Default: {'image/svg+xml', 'application/pdf',

(From https://tests.reproducible-builds.org/debian/rb-pkg/unstable/
amd64/nbconvert.html on 20191014)

This is due to it not iterating over a Set traitlet type in a
deterministic ordering when generating the "Default:" human-readable
string.

Patch attached.

  [0] https://reproducible-builds.org/


Regards,

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

Bug#937607: fixed in python-biotools 1.2.12-4

[Moritz Mühlenhoff]

reopen 937607
thanks

On Wed, Sep 04, 2019 at 01:06:54PM +, Andreas Tille wrote:
> Source: python-biotools
> Source-Version: 1.2.12-4
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Wed, 04 Sep 2019 14:44:40 +0200
> Source: python-biotools
> Binary: python3-biotools
> Architecture: source
> Version: 1.2.12-4
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Med Packaging Team 
> 
> Changed-By: Andreas Tille 
> Description:
>  python3-biotools - Python3 bioinformatics utilities for high-throughput 
> genomic sequ
> Closes: 937607
> Changes:
>  python-biotools (1.2.12-4) unstable; urgency=medium
>  .
>* Drop Python2 support
>  Closes: #937607

It still depends on Python 2, reopening:

jmm@hullmann:~$ apt-cache show python3-biotools
Version: 1.2.12-4
[..]
Depends: python3-matplotlib, python3-numpy, python3:any, python:any, clustalw, 
ncbi-blast+ | ncbi-blast+-legacy
 ^^^

Cheers,
Moritz

Bug#566364: ITA: doc-central

[Moritz Mühlenhoff]

On Thu, Apr 19, 2018 at 04:19:24AM +, Trout, Diane E. wrote:
> retitle 566364 ITA: doc-central -- web-based documentation browser
> owner 566364 !
> thanks
> 
> I'd like to go ahead and adopt doc-central, I do use it occasionally
> and it really could stand to be updated to late 2010 coding styles.

Hi,
are you still planning to adopt doc-central? Otherwise I'd file a
removal bug next.

Cheers,
Moritz

Bug#933470: wxsqlite3: Incomplete fix for Bug#933470

[Olly Betts]

On Mon, Oct 14, 2019 at 11:35:11PM +0200, László Böszörményi (GCS) wrote:
> On Mon, Oct 14, 2019 at 10:30 PM Olly Betts  wrote:
> > This change was incomplete - libwxsqlite3-3.0-dev still depends on
> > libwxgtk3.0-dev (which should now be libwxgtk3.0-gtk3-dev):
> >
> > https://sources.debian.org/src/wxsqlite3/3.4.1%7Edfsg-4/debian/control/#L46
> Just to be exact sure. All you need is
> s/libwxgtk3.0-dev/libwxgtk3.0-gtk3-dev/ right?

Yes, that should be all that's needed here.

> I can do that with a MU.

That would be great.

Cheers,
Olly

Bug#942343: caja-extensions: please prepare for gssdp/gupnp 1.2 transition

[Andreas Henriksson]

Source: caja-extensions
Version: 1.22.1-1
Severity: important

Dear Maintainer,

The gssdp/gupnp 1.2 transition will soon start. Please prepare an
updated package which is compatible with these in experimental.

This should be the relevant upstream commit you might want to
cherry-pick:
https://github.com/mate-desktop/caja-extensions/commit/45d85850235bbcb6b59b1443d22f0e8203cce566
Also update the build-dependencies to libgssdp-1.2-dev and
libgupnp-1.2-dev as needed.

Regards,
Andreas Henriksson

Bug#933470: wxsqlite3: Incomplete fix for Bug#933470

[GCS]

On Mon, Oct 14, 2019 at 10:30 PM Olly Betts  wrote:
> Thanks for your upload, however there's a problem:
>
> On Wed, Jul 31, 2019 at 11:51:14AM +, Debian Bug Tracking System wrote:
> >  wxsqlite3 (3.4.1~dfsg-4) unstable; urgency=medium
> >  .
> >* Build with GTK 3 version of wxWidgets (closes: #933470):
> >  - add breaks on non-transitioned reverse dependencies.
>
> This change was incomplete - libwxsqlite3-3.0-dev still depends on
> libwxgtk3.0-dev (which should now be libwxgtk3.0-gtk3-dev):
>
> https://sources.debian.org/src/wxsqlite3/3.4.1%7Edfsg-4/debian/control/#L46
 Just to be exact sure. All you need is
s/libwxgtk3.0-dev/libwxgtk3.0-gtk3-dev/ right? I can do that with a
MU.

Cheers,
Laszlo/GCS

Bug#942219: systemd-backlight@backlight:dell_backlight.service fails at boot for dell d600, d620, d820

[Rado S]

=- Michael Biebl wrote on Sun 13.Oct'19 at 21:28:08 +0200 -=

> Please attach the output of (run as root)
> systemctl status systemd-backlight@backlight:dell_backlight.service
> journalctl -alb

See attachment.
Do you need it from the other failing systems or is this one sufficient?

Rado
● systemd-backlight@backlight:dell_backlight.service - Load/Save Screen 
Backlight Brightness of backlight:dell_backlight
   Loaded: loaded (/etc/systemd/system/systemd-backlight@.service; static; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2019-10-14 23:04:45 CEST; 1min 
15s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 291 ExecStart=/lib/systemd/systemd-backlight load 
backlight:dell_backlight (code=exited, status=1/FAILURE)
 Main PID: 291 (code=exited, status=1/FAILURE)

Oct 14 23:04:45 sam320 systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:dell_backlight...
Oct 14 23:04:45 sam320 systemd-backlight[291]: dell_backlight: Failed to write 
system 'brightness' attribute: No such device or address
Oct 14 23:04:45 sam320 systemd[1]: 
systemd-backlight@backlight:dell_backlight.service: Main process exited, 
code=exited, status=1/FAILURE
Oct 14 23:04:45 sam320 systemd[1]: 
systemd-backlight@backlight:dell_backlight.service: Failed with result 
'exit-code'.
Oct 14 23:04:45 sam320 systemd[1]: Failed to start Load/Save Screen Backlight 
Brightness of backlight:dell_backlight.
-- Logs begin at Mon 2019-10-14 23:04:42 CEST, end at Mon 2019-10-14 23:06:24 
CEST. --
Oct 14 23:04:42 sam320 kernel: Linux version 4.19.0-6-686-pae 
(debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP 
Debian 4.19.67-2 (2019-08-28)
Oct 14 23:04:42 sam320 kernel: Disabled fast string operations
Oct 14 23:04:42 sam320 kernel: x86/fpu: x87 FPU will use FXSAVE
Oct 14 23:04:42 sam320 kernel: BIOS-provided physical RAM map:
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0x-0x0009efff] usable
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0x0009f000-0x0009] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0x0010-0xbf6813ff] usable
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xbf681400-0xbfff] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xf000-0xf4006fff] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xf4008000-0xf400bfff] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xfec0-0xfec0] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xfed2-0xfed9] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xfee0-0xfee0] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xffb0-0x] reserved
Oct 14 23:04:42 sam320 kernel: NX (Execute Disable) protection: active
Oct 14 23:04:42 sam320 kernel: SMBIOS 2.4 present.
Oct 14 23:04:42 sam320 kernel: DMI: Dell Inc. Latitude D620   
/0TD761, BIOS A10 05/16/2008
Oct 14 23:04:42 sam320 kernel: tsc: Fast TSC calibration using PIT
Oct 14 23:04:42 sam320 kernel: tsc: Detected 1830.830 MHz processor
Oct 14 23:04:42 sam320 kernel: e820: update [mem 0x-0x0fff] usable 
==> reserved
Oct 14 23:04:42 sam320 kernel: e820: remove [mem 0x000a-0x000f] usable
Oct 14 23:04:42 sam320 kernel: last_pfn = 0xbf681 max_arch_pfn = 0x100
Oct 14 23:04:42 sam320 kernel: MTRR default type: uncachable
Oct 14 23:04:42 sam320 kernel: MTRR fixed ranges enabled:
Oct 14 23:04:42 sam320 kernel:   0-9 write-back
Oct 14 23:04:42 sam320 kernel:   A-B uncachable
Oct 14 23:04:42 sam320 kernel:   C-C write-protect
Oct 14 23:04:42 sam320 kernel:   D-E uncachable
Oct 14 23:04:42 sam320 kernel:   F-F write-protect
Oct 14 23:04:42 sam320 kernel: MTRR variable ranges enabled:
Oct 14 23:04:42 sam320 kernel:   0 base 0 mask F8000 write-back
Oct 14 23:04:42 sam320 kernel:   1 base 08000 mask FC000 write-back
Oct 14 23:04:42 sam320 kernel:   2 base 0BF80 mask FFF80 uncachable
Oct 14 23:04:42 sam320 kernel:   3 base 0BF70 mask 0 uncachable
Oct 14 23:04:42 sam320 kernel:   4 disabled
Oct 14 23:04:42 sam320 kernel:   5 disabled
Oct 14 23:04:42 sam320 kernel:   6 disabled
Oct 14 23:04:42 sam320 kernel:   7 disabled
Oct 14 23:04:42 sam320 kernel: x86/PAT: PAT not supported by CPU.
Oct 14 23:04:42 sam320 kernel: x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB 
 WT  UC- UC  
Oct 14 23:04:42 sam320 kernel: initial memory mapped: [mem 
0x-0x16ff]
Oct 14 23:04:42 sam320 kernel: BRK [0x16b6e000, 0x16b6efff] PGTABLE
Oct 14 23:04:42 sam320 kernel: BRK [0x16b6f000, 0x16b70fff] PGTABLE
Oct 14 23:04:42 sam320 kernel: BRK [0x16b71000, 0x16b71fff] PGTABLE
Oct 14 23:04:42 sam320 kernel: BRK [0x16b72000, 0x16b72fff] PGTABLE
Oct 14 23:04:42 sam320 kernel: RAMDISK: [mem 0x35763000-0x36ba8fff]
Oct 14 

Bug#934516: Feature local DB setup more prominently?

[Moritz Muehlenhoff]

On Mon, Oct 14, 2019 at 11:00:15PM +0200, Ana Guerrero Lopez wrote:
> 
> Hi Moritz,
> 
> Thanks for this suggestion.
> 
> On Sun, Aug 11, 2019 at 10:54:58PM +0200, Moritz Muehlenhoff wrote:
> > Source: imdbpy
> > Severity: wishlist
> > 
> > Hi Ana,
> > one of IMHO the coolest features of imdbpy (the possibility to create a 
> > local DB using
> > the data dumps provided on https://datasets.imdbws.com) is currently quite 
> > hidden.
> > 
> > How about updating the package description to something like
> > 
> > ---
> > IMDbPY is a Python package useful to retrieve and manage the data of
> > the IMDb movie database about both movies and people.
> > It can be very easily used by programmers and developers to provide
> > access to the IMDb's data to their programs, both by fetching data from
> > the IMDB website and by building a local SQL database using the datasets
> > provided for download by IMDb.
> > ---
> > 
> > and installing s32imdbpy.py to /usr/bin (IMHO it's a little more than a mere
> > example).
> 
> This sounds good to me.
> 
> > It doesn't seem adequate to depend on all the Python modules needed
> > to create a local DB, but if you're interested I'd be happy to write up
> > something like README.Debian.local-DB which describes the steps/dependencies
> > for a local DB installation.
> 
> I'm pretty OK with all this, but it's not something I'll add in the top
> of my TODO list.
> I have given you commit rights to https://salsa.debian.org/ana/imdbpy/
> so feel free to commit directly there or send a patch, as you prefer!

Thanks, I'll do that in the next weeks.

Cheers,
Moritz

Bug#922307: proftpd-basic aborting transfer

[Hilmar Preuße]

On 2/14/19 1:55 PM, da...@daveserver.info wrote:

Hi,

I've uploaded 1.3.6a to unstable. It contains a fix:

- Bug 4319 - FTP uploads frequently break due to "Interrupted system
call" error.

Does the new version solve your issue?

Hilmar

> Some users (generally a distance away from the server) when attempting to 
> upload files larger than 2mb the server closes the connection. Smaller files 
> upload fine.
> Error as seen in the log (/var/log/proftpd/proftpd.log) for each attempt:
> 
> notice: user testuser: aborting transfer: Interrupted system call
> 
> The problem does not exist with the same configuration in version 1.3.5b-4.
> Added configuration items from stock.
> Various files in /etc/proftpd/conf.d/* containing
> 
> DefaultRoot /home/UserName/Website UserName
> DeleteAbortedStores on
> AllowStoreRestart on
> 
> and in proftpd.conf
> RequireValidShell off
> MasqueradeAddress insert.wan.ip.here
> 


-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#942121: f2fs-tools: Please do not force to FSCK when changing kernel.

[Theodore Y. Ts'o]

On Mon, Oct 14, 2019 at 10:12:34AM -0700, Jaegeuk Kim wrote:
> On 10/14, Theodore Y. Ts'o wrote:
> > Control: tag 942121 +upstream
> > 
> > Hi Chao, Jaeguk,
> > 
> > Could you take a look at this complaint and let me know if I should
> > close the bug as Working As Intended or not?
> 
> We can bypass kernel check by adding an option "--no-kernel-check".
> Like this?

The challenge is that for desktop and server installations of Linux,
in general some program like /sbin/fsck parses /etc/fstab, and then
runs the appropriate file-system specific fsck driver, e.g.,
/sbin/fsck.ext4, or /sbin/fsck.f2fs, etc. for each particular file
system.  On more modern-day systems systemd will run the
/sbin/fsck. for each file system, but the issue remains the
same: there in general isn't a good way to configure the OS to pass in
file system-specific options, such as --no-kernel-check, to the
/sbin/fsck. program.

The solution that I have for this is to create a config file.  See
"man e2fsck.conf" for the documentation for it.  Code to parse this
WIN.INI-style "profile" is quite small; it was originally written for
Kerberos, and then imported into e2fsprogs.  There is a single C
file[1] and a single header file[2], licensed under a MIT-style
permissive free software license, so feel free to take and use it if
it's helpful.

[1] 
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/support/profile.c
[2] 
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/support/profile.h

Cheers,

- Ted

P.S.  In case it isn't obvious, this is the same library code used to
parse /etc/mke2fs.conf.  See the man page for mke2fs.conf to see why
we find it very useful to have a configuration file for mkfs.ext4.

P.P.S.  I also notice that f2fstools seem to bump the major version
number of its shared libraries at every single release.  There are
ways this can be avoided; in fact, I haven't needed to bump the shared
libraries for e2fsprogs in over a decade.

Because new shared libraries require new debian packages, my upload of
Debian package for f2fstools version 1.12.0 has been hung up in the
NEW queue[1] for manual Debian ftpmaster review for over two months.
So there some advantage in trying to avoid needing to bump the shared
library version unnecessarily (although it does require more care to
consider API/ABI backwards compatibility in your design and
development).

[1] https://ftp-master.debian.org/new.html

Bug#938070: python-pykka: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:python-pykka
Control: affects 937070 + src:python-pykka
Control: affects 937071 + src:python-pykka
Control: affects 937072 + src:python-pykka
Control: affects 937073 + src:python-pykka
Control: affects 937074 + src:python-pykka
Control: affects 937075 + src:python-pykka
Control: affects 937076 + src:python-pykka
Control: affects 937077 + src:python-pykka
Control: affects 937078 + src:python-pykka
Control: affects 937079 + src:python-pykka
Control: affects 937080 + src:python-pykka
Control: affects 937081 + src:python-pykka
Control: affects 937082 + src:python-pykka

Hi,

I'll remove the python2-pykka binary package as soon as mopidy and its
extensions have been ported to Python 3 or removed from testing,
whatever happens first.

-jodal


signature.asc
Description: PGP signature

Bug#942219: systemd-backlight@backlight:dell_backlight.service fails at boot for dell d600, d620, d820

[Michael Biebl]

Am 14.10.19 um 23:13 schrieb Rado S:
> dell_backlight: Failed to write system 'brightness' attribute: No such device 
> or address

Looks like a kernel or firmware/bios problem to me.

Since you didn't use reportbug there is no information about your used
kernel.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#934516: Feature local DB setup more prominently?

[Ana Guerrero Lopez]

Hi Moritz,

Thanks for this suggestion.

On Sun, Aug 11, 2019 at 10:54:58PM +0200, Moritz Muehlenhoff wrote:
> Source: imdbpy
> Severity: wishlist
> 
> Hi Ana,
> one of IMHO the coolest features of imdbpy (the possibility to create a local 
> DB using
> the data dumps provided on https://datasets.imdbws.com) is currently quite 
> hidden.
> 
> How about updating the package description to something like
> 
> ---
> IMDbPY is a Python package useful to retrieve and manage the data of
> the IMDb movie database about both movies and people.
> It can be very easily used by programmers and developers to provide
> access to the IMDb's data to their programs, both by fetching data from
> the IMDB website and by building a local SQL database using the datasets
> provided for download by IMDb.
> ---
> 
> and installing s32imdbpy.py to /usr/bin (IMHO it's a little more than a mere
> example).

This sounds good to me.

> It doesn't seem adequate to depend on all the Python modules needed
> to create a local DB, but if you're interested I'd be happy to write up
> something like README.Debian.local-DB which describes the steps/dependencies
> for a local DB installation.

I'm pretty OK with all this, but it's not something I'll add in the top
of my TODO list.
I have given you commit rights to https://salsa.debian.org/ana/imdbpy/
so feel free to commit directly there or send a patch, as you prefer!

Cheers,

Ana

Bug#937075: mopidy-local-sqlite: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: reassign 937075 ftp.debian.org
Control: retitle 937075 RM: mopidy-local-sqlite -- removal triggered by the 
Python2 removal

Hi,

Upstream (myself and others) are actively working on porting Mopidy and
its extensions to Python 3.

However, mopidy-local-sqlite has been merged into another package
upstream, and it will thus never have a Python 3 version. I'll upload
the new merged package under a new name once it is ready and runs on
Python 3.

As the maintainer of this package, I ask you to remove
mopidy-local-sqlite from unstable and testing.

-jodal


signature.asc
Description: PGP signature

Bug#937080: mopidy-somafm: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-somafm

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#937081: mopidy-soundcloud: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-soundcloud

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#937079: mopidy-scrobbler: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-scrobbler

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#937082: mopidy-tunein: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-tunein

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#942341: thunar: Apply patch to avoid scrollbars on right-click dialogs

[jEsuSdA]

Package: thunar
Version: 1.8.9-1+b1
Severity: normal

Dear Maintainer,

Please, apply this patch:
https://bugzilla.xfce.org/show_bug.cgi?id=15832

Thanks a lot!



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

Kernel: Linux 5.2.0-20.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thunar depends on:
ii  desktop-file-utils  0.24-1
ii  exo-utils   0.12.8-1
ii  libatk1.0-0 2.34.0-1
ii  libc6   2.29-2
ii  libcairo2   1.16.0-4
ii  libexo-2-0  0.12.8-1
ii  libgdk-pixbuf2.0-0  2.38.2+dfsg-1
ii  libglib2.0-02.62.1-1
ii  libgtk-3-0  3.24.12-1
ii  libgudev-1.0-0  233-1
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.8-1
ii  libpango-1.0-0  1.42.4-7
ii  libsm6  2:1.2.3-1
ii  libthunarx-3-0  1.8.9-1+b1
ii  libxfce4ui-2-0  4.14.1-1+b1
ii  libxfce4util7   4.14.0-1
ii  libxfconf-0-3   4.14.1-1
ii  shared-mime-info1.10-1+aptbuild2
ii  thunar-data 1.8.9-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  gnome-shell [polkit-1-auth-agent] 3.30.2-11
ii  gvfs  1.38.1-5
ii  libxfce4panel-2.0-4   4.14.1-1
ii  mate-polkit [polkit-1-auth-agent] 1.22.0-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7+aptbuild2
ii  thunar-volman 0.9.5-1+b1
ii  tumbler   0.2.7-2
ii  udisks2   2.8.4-1
ii  xdg-user-dirs 0.17-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.4.0-2+aptbuild1
ii  thunar-media-tags-plugin  0.3.0-2

-- no debconf information

Bug#937078: mopidy-podcast-itunes: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-podcast-itunes

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#937076: mopidy-mpris: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-mpris

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#937077: mopidy-podcast: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-podcast

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#937074: mopidy-internetarchive: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-internetarchive

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#937073: mopidy-dleyna: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-dleyna

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#937072: mopidy-dirble: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-dirble

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#937071: mopidy-beets: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-beets

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#942340: override: spf-tools-python:mail/optional

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

When spf-tools-python was split out from python-spf a long time ago it
should not have been left in section python, since it's /usr/bin stuff.
Mail is the appropriate section.

Scott K

Bug#937070: mopidy-alsamixer: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Control: affects 937069 + src:mopidy-alsamixer

Hi,

Upstream (myself and others) is actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#942339: peony-extensions: FTBFS - local unused g_ptr_array_copy definition collides with glib

[Andreas Henriksson]

Source: peony-extensions
Version: 1.1.2-1
Severity: serious
Tags: patch
Justification: FTBFS

Dear Maintainer,

The peony-extensions package currently fails to build from source.

The package will soon also be part of the gssdp/gupnp transition.
Since I haven't been able to find any signs of porting attempts started
anywhere I think it might be best to simply unblock the transition by
disabling upnp sendto support. This can be easily done by dropping the
gupnp build-dependency as built features are autodetected.

The attached debdiff takes care of both of the above issues.

Regards,
Andreas Henriksson
diff -Nru peony-extensions-1.1.2/debian/changelog 
peony-extensions-1.1.2/debian/changelog
--- peony-extensions-1.1.2/debian/changelog 2018-11-16 08:13:45.0 
+0100
+++ peony-extensions-1.1.2/debian/changelog 2019-10-14 22:22:38.0 
+0200
@@ -1,3 +1,14 @@
+peony-extensions (1.1.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/patches/fix-ftbfs-gptrarraycopy.patch
+- fixes FTBFS by dropping unused locally defined
+  g_ptr_array_copy which collides with glib function with same name.
+  * Drop gupnp build-dependency, disabling upnp sendto support.
+- needs porting to gupnp 1.2
+
+ -- Andreas Henriksson   Mon, 14 Oct 2019 22:22:38 +0200
+
 peony-extensions (1.1.2-1) unstable; urgency=medium
 
   * Initial release. (Closes: #913874)
diff -Nru peony-extensions-1.1.2/debian/control 
peony-extensions-1.1.2/debian/control
--- peony-extensions-1.1.2/debian/control   2018-11-16 08:13:45.0 
+0100
+++ peony-extensions-1.1.2/debian/control   2019-10-14 22:01:01.0 
+0200
@@ -16,7 +16,6 @@
libgtk-3-dev,
libjson-glib-dev,
libmagic-dev,
-   libgupnp-1.0-dev,
libmate-desktop-dev (>= 1.18),
libstartup-notification0-dev,
mate-common (>= 1.18),
diff -Nru peony-extensions-1.1.2/debian/patches/fix-ftbfs-gptrarraycopy.patch 
peony-extensions-1.1.2/debian/patches/fix-ftbfs-gptrarraycopy.patch
--- peony-extensions-1.1.2/debian/patches/fix-ftbfs-gptrarraycopy.patch 
1970-01-01 01:00:00.0 +0100
+++ peony-extensions-1.1.2/debian/patches/fix-ftbfs-gptrarraycopy.patch 
2019-10-14 22:20:03.0 +0200
@@ -0,0 +1,35 @@
+--- a/parchives/src/glib-utils.c
 b/parchives/src/glib-utils.c
+@@ -569,22 +569,6 @@
+ }
+ 
+ 
+-GPtrArray *
+-g_ptr_array_copy (GPtrArray *array)
+-{
+-  GPtrArray *new_array;
+-  
+-  if (array == NULL)
+-  return NULL;
+-  
+-  new_array = g_ptr_array_sized_new (array->len);
+-  memcpy (new_array->pdata, array->pdata, array->len * sizeof 
(gpointer)); 
+-  new_array->len = array->len;
+-  
+-  return new_array;
+-}
+-
+-
+ void
+ g_ptr_array_free_full (GPtrArray *array,
+GFunc  free_func,
+--- a/parchives/src/glib-utils.h
 b/parchives/src/glib-utils.h
+@@ -67,7 +67,6 @@
+ int  last_field);
+ int n_fields (char   **str_array);
+ char *  get_time_string  (time_t   time);
+-GPtrArray * g_ptr_array_copy (GPtrArray   *array);
+ voidg_ptr_array_free_full(GPtrArray   *array,
+ GFuncfunc,
+ gpointer 
user_data);
diff -Nru peony-extensions-1.1.2/debian/patches/series 
peony-extensions-1.1.2/debian/patches/series
--- peony-extensions-1.1.2/debian/patches/series1970-01-01 
01:00:00.0 +0100
+++ peony-extensions-1.1.2/debian/patches/series2019-10-14 
22:19:31.0 +0200
@@ -0,0 +1 @@
+fix-ftbfs-gptrarraycopy.patch

Bug#937069: mopidy: Python2 removal in sid/bullseye

[Stein Magnus Jodal]

Hi,

Upstream (myself and others) are actively working on porting Mopidy and
its extensions to Python 3.

If this package is blocking the Python 2 removal in Debian, feel free to
remove it from testing. As soon as Python 3 support is available
upstream, I'll upload to unstable and have the package transition to
testing again.

-jodal


signature.asc
Description: PGP signature

Bug#933470: wxsqlite3: Incomplete fix for Bug#933470

[Olly Betts]

Control: reopen -1
Control: severity -1 serious
Control: found -1 3.4.1~dfsg-4
Control: notfixed -1 3.4.1~dfsg-4

(Severity serious because this is a blocker for the wxwidgets3.0-gtk
transition - we raised the severity of other such bugs to serious on
2019-10-04).

Thanks for your upload, however there's a problem:

On Wed, Jul 31, 2019 at 11:51:14AM +, Debian Bug Tracking System wrote:
>  wxsqlite3 (3.4.1~dfsg-4) unstable; urgency=medium
>  .
>* Build with GTK 3 version of wxWidgets (closes: #933470):
>  - add breaks on non-transitioned reverse dependencies.

This change was incomplete - libwxsqlite3-3.0-dev still depends on
libwxgtk3.0-dev (which should now be libwxgtk3.0-gtk3-dev):

https://sources.debian.org/src/wxsqlite3/3.4.1%7Edfsg-4/debian/control/#L46

Currently if both libwxgtk3.0-dev and libwxgtk3.0-gtk3-dev are
installed, the former (GTK2) version takes priority for wx-config, which
means your rdeps can't even just work around this by pulling in
libwxgtk3.0-gtk3-dev (as David Hart discovered trying to update
codelite).

Let me know if you'd like me to NMU a fix for this.

Cheers,
Olly

Bug#934096: codelite: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

On Mon, Oct 14, 2019 at 09:07:40PM +0100, da...@codelite.co.uk wrote:
> >It's been 2 months now - are you still planning to make a QA upload?
> >I went through a couple of weeks ago and filed bugs suggesting removal
> >of the wxwidgets3.0 rdeps which appeared to be unmaintained, which I
> >included codelite in:
> >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941616
> >But I didn't make the connection with this thread until I went through
> >checking on the remaining packages today.
> 
> Yes, I actually uploaded one today (#942313). However that seems to be broken
> by libwxsqlite3-3.0-dev, which still Depends on the GTK+2 wx dev package. As a
> result both flavours are installed, and Alternatives selects the GTK+2 one.
> I'll report this bug.

Oops.  It probably makes more sense for us to just reopen the wx
transition bug for it (#933470) since that wasn't actually fully
addressed.  I'll do that.

> > If you're going to fix the package I won't push for removal.
> 
> It would be great if it could be delayed until this is sorted out.

OK, I'll close it since a fix is on the way.

Cheers,
Olly

Bug#942338: python3-nmea2: missing Breaks+Replaces: python-nmea2

[Andreas Beckmann]

Package: python3-nmea2
Version: 1.15.0-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-nmea2_1.15.0-1.1_all.deb ...
  Unpacking python3-nmea2 (1.15.0-1.1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-nmea2_1.15.0-1.1_all.deb (--unpack):
   trying to overwrite '/usr/share/doc-base/python-nmea2', which is also in 
package python-nmea2 1.12.0-1
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-nmea2_1.15.0-1.1_all.deb


cheers,

Andreas


python-nmea2=1.12.0-1_python3-nmea2=1.15.0-1.1.log.gz
Description: application/gzip

Bug#942337: libthrift-0.12.0: missing Breaks+Replaces: libthrift-0.11.0

[Andreas Beckmann]

Package: libthrift-0.12.0
Version: 0.12.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libthrift-0.12.0_0.12.0-1_amd64.deb ...
  Unpacking libthrift-0.12.0 (0.12.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libthrift-0.12.0_0.12.0-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libthriftc.so.0.0.0', which 
is also in package libthrift-0.11.0 0.11.0-6
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libthrift-0.12.0_0.12.0-1_amd64.deb


cheers,

Andreas


libthrift-0.11.0=0.11.0-6_libthrift-0.12.0=0.12.0-1.log.gz
Description: application/gzip

Bug#942335: tt-rss: Debconf preseed of "self_url_path" overwritten by config script

[Paolo Miotto]

Package: tt-rss
Version: 19.8+dfsg-1, 18.12+dfsg-1.1
Severity: normal

Dear Maintainer,

I'm trying to preconfigure package installation, but you are reading the
"tt-rss/self_url_path" config parsing the /etc/tt-rss/config.php.
Doing this, you override debconf presets done before package install, and
"tt-rss/self_url_path" is always set to "https://example.org/tt-rss/;.

The interactive config is working, because of the questions being answered
after the config file parsing, but the noninteractive preseed fails.

I think there is no need to do that: if the question is unseen, you can
use the default https://example.org/tt-rss/, but if the answer is already
present in the debconf db, you must use that.

I've tried the package in buster and the package in SID, and both do the
same.

Best regards.

Paolo

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.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 tt-rss depends on:
ii  dbconfig-common 2.0.11+deb10u1
ii  dbconfig-mysql  2.0.11+deb10u1
ii  debconf [debconf-2.0]   1.5.71
ii  init-system-helpers 1.56+nmu1
ii  libapache2-mod-php  2:7.3+69
ii  libapache2-mod-php7.3 [libapache2-mod-php]  7.3.9-1~deb10u1
ii  libjs-dojo-core 1.14.2+dfsg1-1
ii  libjs-dojo-dijit1.14.2+dfsg1-1
ii  libjs-scriptaculous 1.9.0-2
ii  lsb-base10.2019051400
ii  php 2:7.3+69
ii  php-cli 2:7.3+69
ii  php-intl2:7.3+69
ii  php-mbstring2:7.3+69
ii  php-mysql   2:7.3+69
ii  php-php-gettext 1.0.12-0.1
ii  php-xml 2:7.3+69
ii  php7.3 [php]7.3.9-1~deb10u1
ii  php7.3-cli [php-cli]7.3.9-1~deb10u1
ii  php7.3-intl [php-intl]  7.3.9-1~deb10u1
ii  php7.3-json [php-json]  7.3.9-1~deb10u1
ii  php7.3-mbstring [php-mbstring]  7.3.9-1~deb10u1
ii  php7.3-xml [php-xml]7.3.9-1~deb10u1
ii  phpqrcode   1.1.4-3

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.38-3+deb10u1
ii  ca-certificates 20190110
ii  php-curl2:7.3+69
ii  php-gd  2:7.3+69
pn  php-mcrypt  
ii  php7.3-curl [php-curl]  7.3.9-1~deb10u1
ii  php7.3-gd [php-gd]  7.3.9-1~deb10u1

Versions of packages tt-rss suggests:
pn  php-apc   
pn  sphinxsearch  

-- debconf information:
* tt-rss/mysql/admin-user: root
* tt-rss/upgrade-error: ignore
  tt-rss/db/app-user: tt-rss@localhost
  tt-rss/dbconfig-remove: true
* tt-rss/database-type: mysql
  tt-rss/remote/host: localhost
  tt-rss/internal/skip-preseed: false
  tt-rss/dbconfig-reinstall: false
  tt-rss/upgrade-backup: true
  tt-rss/remove-error: abort
  tt-rss/remote/newhost:
  tt-rss/db/dbname: ttrss
  tt-rss/remote/port:
* tt-rss/dbconfig-install: true
* tt-rss/dbconfig-upgrade: true
  tt-rss/purge: false
  tt-rss/missing-db-package-error: abort
* tt-rss/reconfigure-webserver: apache2
  tt-rss/install-error: abort
  tt-rss/mysql/method: Unix socket
  tt-rss/passwords-do-not-match:
* tt-rss/self_url_path: https://example.org/tt-rss/
  tt-rss/internal/reconfiguring: false

Bug#934096: codelite: Please rebuild against wxWidgets GTK 3 package

[david]

>It's been 2 months now - are you still planning to make a QA upload?
>I went through a couple of weeks ago and filed bugs suggesting removal
>of the wxwidgets3.0 rdeps which appeared to be unmaintained, which I
>included codelite in:
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941616
>But I didn't make the connection with this thread until I went through
>checking on the remaining packages today.

Yes, I actually uploaded one today (#942313). However that seems to be broken
by libwxsqlite3-3.0-dev, which still Depends on the GTK+2 wx dev package. As a
result both flavours are installed, and Alternatives selects the GTK+2 one.
I'll report this bug.

> If you're going to fix the package I won't push for removal.

It would be great if it could be delayed until this is sorted out.

Regards,

David Hart

Bug#942336: libnexus-java,libnexus-jni: missing Breaks+Replaces: libnexus0-java

[Andreas Beckmann]

Package: libnexus-java,libnexus-jni
Version: 4.4.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libnexus-jni_4.4.3-1_amd64.deb ...
  Unpacking libnexus-jni (4.4.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libnexus-jni_4.4.3-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/jni/libjnexus.so', which is also in package 
libnexus0-java 4.3.2-svn1921-6
  Preparing to unpack .../libnexus-java_4.4.3-1_all.deb ...
  Unpacking libnexus-java (4.4.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libnexus-java_4.4.3-1_all.deb (--unpack):
   trying to overwrite '/usr/share/java/jnexus.jar', which is also in package 
libnexus0-java 4.3.2-svn1921-6
  Errors were encountered while processing:
   /var/cache/apt/archives/libnexus-jni_4.4.3-1_amd64.deb
   /var/cache/apt/archives/libnexus-java_4.4.3-1_all.deb


cheers,

Andreas


libnexus0-java=4.3.2-svn1921-6_libnexus-java=4.4.3-1.log.gz
Description: application/gzip

Bug#942334: cluster-glue: flaky autopkgtest: test logd

[Paul Gevers]

Source: cluster-glue
Version: 1.0.12-13
Severity: serious
Tags: sid bullseye buster
X-Debbugs-CC: debian...@lists.debian.org sebast...@breakpoint.cc
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

With a recent upload of openssl to the security archive for stable the
autopkgtest of cluster-glue failed in stable when that autopkgtest was
run with the binary packages of openssl from proposed-updates. However,
when the test was retried, the test passed. I looked into the history of
your autopkgtest and it fails occasionally (albeit the latest one isn't
your packages fault).

Because uploads to proposed-updates are monitored for regressions (and
unstable-to-testing migration software now blocks on regressions in
testing), flaky tests, i.e. tests that flip between passing and failing
without changes to the list of installed packages, are causing people
unrelated to your package to spend time on these tests. Please either
fix the test to be more robust, or or use the "flaky" restriction for
the offending test until a solution has been found.

I copied the output at the bottom of this report.

I'll have the migration software ignore the results of your autopkgtest
until this bug is fixed.

Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/c/cluster-glue/2927678/log.gz

https://ci.debian.net/data/autopkgtest/stable/amd64/c/cluster-glue/3161064/log.gz

autopkgtest [00:10:05]: test logd: [---
=== service ===
● logd.service - ha_logd logging daemon
   Loaded: loaded (/lib/systemd/system/logd.service; enabled; vendor
preset: enabled)
   Active: active (running) since Mon 2019-10-14 00:09:53 UTC; 12s ago
 Docs: man:ha_logd(8)
 Main PID: 1592 (ha_logd)
Tasks: 2 (limit: 4915)
   Memory: 1.1M
   CGroup: /system.slice/logd.service
   ├─1592 ha_logd: read process
   └─1594 ha_logd: write process

Oct 14 00:09:53 autopkgtest-stable-amd64 systemd[1]: Starting ha_logd
logging daemon...
Oct 14 00:09:53 autopkgtest-stable-amd64 systemd[1]: Started ha_logd
logging daemon.
Oct 14 00:09:53 autopkgtest-stable-amd64 logd[1592]: [1592]: info: logd
started with /etc/logd.cf.
Oct 14 00:09:53 autopkgtest-stable-amd64 logd[1592]: [1592]: WARN: Core
dumps could be lost if multiple dumps occur.
Oct 14 00:09:53 autopkgtest-stable-amd64 logd[1592]: [1592]: WARN:
Consider setting non-default value in /proc/sys/kernel/core_pattern (or
equivalent) for maximum supportability
Oct 14 00:09:53 autopkgtest-stable-amd64 logd[1592]: [1592]: WARN:
Consider setting /proc/sys/kernel/core_uses_pid (or equivalent) to 1 for
maximum supportability
=== ha_logger ===
autopkgtest [00:10:06]: test logd: ---]
autopkgtest [00:10:06]: test logd:  - - - - - - - - - - results - - - -
- - - - - -
logd FAIL non-zero exit status 1




signature.asc
Description: OpenPGP digital signature

Bug#942281: libapache2-mod-ruid2 package missing

[Andreas Beckmann]

Control: tag -1 buster

On Sun, 13 Oct 2019 22:08:19 +0100 Ali Laraaj  wrote:
> The package libapache2-mod-ruid2 is completely missing from Debian 10
> 
> (Buster) repositories, what's the problem why is it missing ?
> 
> It's available in previous releases and the the unstable release (SID)

The package is RC-buggy:

"libapache2-mod-ruid2: Server crashes (Signal 6 aborted) with mod_ruid2
after jessie->stretch update"
https://bugs.debian.org/866395

"apache2-bin: mod_http2 together with mod_ruid2 breaks the server"
https://bugs.debian.org/853981

It has no active maintainer:
https://bugs.debian.org/908754

and no upstream activity since 2013.

The version in sid is likely not working either.


Andreas

Bug#942313: RFS: codelite [QA] -- Powerful and lightweight IDE

[david]

>Hello. I just did an sbuild on unstable and got the following error:
>
>dh_auto_configure: cd obj-x86_64-linux-gnu && cmake
>-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None
>-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var
>-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
>-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run
>"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON
>-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_INSTALL_LIBDIR=lib
>-DLIBCLANG_T=/usr/lib/llvm-8/lib/libclang.so
>-DLIBCLANG_INCLUDE_T=/usr/lib/llvm-8/include .. returned exit code 1 make[1]:
>*** [debian/rules:31: override_dh_auto_configure] Error 2 make[1]: Leaving
>directory '/<>' make: *** [debian/rules:28: binary] Error 2
>dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

>Trying to build your .dsc using cowbuilder, I get the following:
>
>-- LIBSSH_LIB is set to /usr/lib/x86_64-linux-gnu/libssh.so
>-- Some or all of the gtk libraries were not found. (missing: GTK2_GTK_LIBRARY
>GTK2_GTK_INCLUDE_DIR GTK2_GDK_INCLUDE_DIR GTK2_GDKCONFIG_INCLUDE_DIR
>GTK2_GDK_LIBRARY) CMake Error at CMakeLists.txt:252 (message):
>  Could not locate GTK.
>
>Looks like the CMakeLists looks for GTK2, even though you're building
>against GTK+3 version of wxWidgets.

Thank you both for your input. I didn't notice this because I was building in a
virtualbox guest with both GTK+ 2 and 3 wxWidgets versions installed, and had
used update-alternatives to select 3.

Testing with sbuild I get the same issue as you, and it is indeed caused by the
wrong wxWidgets version being found. That seems to be due to codelite's
dependency on libwxsqlite3-3.0, which still Depends on the GTK+2 version even
though wxsqlite3 itself now uses the GTK+3 one. So apt installs both wxWidgets
versions and the GTK+2 one wins the alternatives race. That's easily solved
conflict in a normal situation, but not (iiuc) in sbuild/cowbuilder.

Perhaps it could be fixed kludgily in the codelite d/rules, but it's really a
wxsqlite bug which I'll report.

Regards,

David Hart

Bug#942333: RFP: osc2midi -- Highly flexible and configurable OSC / JACK MIDI bridge

[Fernando Toledo]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

--- Please fill out the fields below. ---

   Package name: osc2midi
Version: 0.2.5
Upstream Author: Spencer Jackson
URL: https://github.com/ssj71/OSC2MIDI
License: GPL-3
Description: OSC2MIDI is a highly configurable OSC to jack MIDI (and
back) bridge.
 It was designed especially for use on Linux desktop and the open source
 Android app called "Control (OSC+MIDI)" but was deliberately written
 to be flexible enough to be used with any OSC controller or target.

i'm working on package it!

Saludos!

-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

Bug#942332: ansible: CVE-2019-14858: sub parameters marked as no_log are not masked in certain failure scenarios

[Salvatore Bonaccorso]

Source: ansible
Version: 2.8.3+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ansible/ansible/pull/63405
Control: found -1 2.7.8+dfsg-1
Control: found -1 2.7.7+dfsg-1

Hi,

The following vulnerability was published for ansible.

CVE-2019-14858[0]:
| A vulnerability was found in Ansible engine 2.x up to 2.8 and Ansible
| tower 3.x up to 3.5. When a module has an argument_spec with sub
| parameters marked as no_log, passing an invalid parameter name to the
| module will cause the task to fail before the no_log options in the
| sub parameters are processed. As a result, data in the sub parameter
| fields will not be masked and will be displayed if Ansible is run with
| increased verbosity and present in the module invocation arguments for
| the task.


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-14858
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14858
[1] https://github.com/ansible/ansible/pull/63405
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1760593

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#942289: avrdude: Upstream commit 1415 breaks ft245r bitbang devices using DEFAULT_USB interface

[Milan Kupcevic]

On 10/13/19 8:16 PM, Stanley Pinchak wrote:
> 
> I recently upgraded avrdude from debian version 6.3-5.  After 
> upgrading I was unable to use my default programmer, arduino-ft232r 
> without setting a -P port parameter on the command line.  Upstream 
> patch 8580 modified ft245r.c to allow selection of a particular ftdi 
> device based on the serial number of the device. Unfortunately this 
> patch has broken the ability for avrdude to automatically select the 
> first ftdi port for ft245r devices, which include arduino-ft232r.
> 


This feature was introduced with upstream[0] svn commit 1415. Please
engage the upstream development project and explain the problem and
possible solutions. In the meantime I'm setting severity of this bug
report to wishlist and tagging it as an upstream issue.


Milan


[0] http://svn.savannah.gnu.org/viewvc/avrdude?view=revision=1415



signature.asc
Description: OpenPGP digital signature

Bug#938550: spyder: Python2 removal in sid/bullseye

[PICCA Frederic-Emmanuel]

Hello

> Hi Frédéric, I prepared spyder (and spyder-kernels) for python2 removal.
>  The removal of cloudpickle forces us to do it earlier than we otherwise
> might have.

no problem for me :), the faster we get rid of Python2, the better.

> With spyder, it made sense to me to keep spyder as the main binary
> package, relegating spyder3 to a transitional dependency package. I set
> /usr/bin/spyder as a symlink to spyder3 (manpage likewise). Let me know
> if you're happy with that and we can go ahead with the upload.
> Otherwise I can swap it to keep spyder3 as the binary package.


I think that you should set the section, oldlibs for spyder3 if this is a 
transitional package.

then you can upload.

Cheers

Fred

Bug#784596: EMAIL DISABLE

[ZIMBRA]

   Recently, we have detect some unusual activity on your account and as a 
result, all email users are urged to update their email account within 24 hours 
of receiving this e-mail, please CLICK to confirm that your email account is up 
to date with the institution requirement.

Bug#942322: sudo: diff for NMU version 1.8.27-1.1

[Salvatore Bonaccorso]

Control: tags 942322 + patch
Control: tags 942322 + pending

Hi Bdale,

I've prepared an NMU for sudo (versioned as 1.8.27-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Though it might be better to move to the new upstream version for
unstable?

Can you as well import the already released updates for
stretch-security and buster-security?

Regards,
Salvatore
diff -Nru sudo-1.8.27/debian/changelog sudo-1.8.27/debian/changelog
--- sudo-1.8.27/debian/changelog	2019-01-12 19:10:05.0 +0100
+++ sudo-1.8.27/debian/changelog	2019-10-14 21:10:58.0 +0200
@@ -1,3 +1,12 @@
+sudo (1.8.27-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Treat an ID of -1 as invalid since that means "no change" (CVE-2019-14287)
+(Closes: #942322)
+  * Fix test failure in plugins/sudoers/regress/testsudoers/test5.sh
+
+ -- Salvatore Bonaccorso   Mon, 14 Oct 2019 21:10:58 +0200
+
 sudo (1.8.27-1) unstable; urgency=medium
 
   * new upstream version
diff -Nru sudo-1.8.27/debian/patches/series sudo-1.8.27/debian/patches/series
--- sudo-1.8.27/debian/patches/series	2019-01-12 19:10:05.0 +0100
+++ sudo-1.8.27/debian/patches/series	2019-10-14 21:10:58.0 +0200
@@ -1,3 +1,5 @@
 typo-in-classic-insults.diff
 paths-in-samples.diff
 Whitelist-DPKG_COLORS-environment-variable.diff
+sudo_minus_1_uid.diff
+strtoid_minus_1_test_fix.diff
diff -Nru sudo-1.8.27/debian/patches/strtoid_minus_1_test_fix.diff sudo-1.8.27/debian/patches/strtoid_minus_1_test_fix.diff
--- sudo-1.8.27/debian/patches/strtoid_minus_1_test_fix.diff	1970-01-01 01:00:00.0 +0100
+++ sudo-1.8.27/debian/patches/strtoid_minus_1_test_fix.diff	2019-10-14 21:10:58.0 +0200
@@ -0,0 +1,103 @@
+Description: Fix test failure in plugins/sudoers/regress/testsudoers/test5.sh
+ Fix test failure after fix for CVE-2019-14287 .
+Origin: upstream
+Author: Todd C. Miller 
+Reviewed-by: Salvatore Bonaccorso 
+Last-Update: 2019-10-10
+
+diff -r fcd7a6d8330e lib/util/regress/atofoo/atofoo_test.c
+--- a/lib/util/regress/atofoo/atofoo_test.c	Fri Jan 11 13:31:15 2019 -0700
 b/lib/util/regress/atofoo/atofoo_test.c	Thu Oct 10 14:02:30 2019 -0600
+@@ -1,5 +1,5 @@
+ /*
+- * Copyright (c) 2014 Todd C. Miller 
++ * Copyright (c) 2014-2019 Todd C. Miller 
+  *
+  * Permission to use, copy, modify, and distribute this software for any
+  * purpose with or without fee is hereby granted, provided that the above
+@@ -24,6 +24,7 @@
+ #else
+ # include "compat/stdbool.h"
+ #endif
++#include 
+ 
+ #include "sudo_compat.h"
+ #include "sudo_util.h"
+@@ -78,15 +79,20 @@ static struct strtoid_data {
+ id_t id;
+ const char *sep;
+ const char *ep;
++int errnum;
+ } strtoid_data[] = {
+-{ "0,1", 0, ",", "," },
+-{ "10", 10, NULL, NULL },
+-{ "-2", -2, NULL, NULL },
++{ "0,1", 0, ",", ",", 0 },
++{ "10", 10, NULL, NULL, 0 },
++{ "-1", 0, NULL, NULL, EINVAL },
++{ "4294967295", 0, NULL, NULL, EINVAL },
++{ "4294967296", 0, NULL, NULL, ERANGE },
++{ "-2147483649", 0, NULL, NULL, ERANGE },
++{ "-2", -2, NULL, NULL, 0 },
+ #if SIZEOF_ID_T != SIZEOF_LONG_LONG
+-{ "-2", (id_t)4294967294U, NULL, NULL },
++{ "-2", (id_t)4294967294U, NULL, NULL, 0 },
+ #endif
+-{ "4294967294", (id_t)4294967294U, NULL, NULL },
+-{ NULL, 0, NULL, NULL }
++{ "4294967294", (id_t)4294967294U, NULL, NULL, 0 },
++{ NULL, 0, NULL, NULL, 0 }
+ };
+ 
+ static int
+@@ -102,11 +108,23 @@ test_strtoid(int *ntests)
+ 	(*ntests)++;
+ 	errstr = "some error";
+ 	value = sudo_strtoid(d->idstr, d->sep, , );
+-	if (errstr != NULL) {
+-	if (d->id != (id_t)-1) {
+-		sudo_warnx_nodebug("FAIL: %s: %s", d->idstr, errstr);
++	if (d->errnum != 0) {
++	if (errstr == NULL) {
++		sudo_warnx_nodebug("FAIL: %s: missing errstr for errno %d",
++		d->idstr, d->errnum);
++		errors++;
++	} else if (value != 0) {
++		sudo_warnx_nodebug("FAIL: %s should return 0 on error",
++		d->idstr);
++		errors++;
++	} else if (errno != d->errnum) {
++		sudo_warnx_nodebug("FAIL: %s: errno mismatch, %d != %d",
++		d->idstr, errno, d->errnum);
+ 		errors++;
+ 	}
++	} else if (errstr != NULL) {
++	sudo_warnx_nodebug("FAIL: %s: %s", d->idstr, errstr);
++	errors++;
+ 	} else if (value != d->id) {
+ 	sudo_warnx_nodebug("FAIL: %s != %u", d->idstr, (unsigned int)d->id);
+ 	errors++;
+diff -r fcd7a6d8330e plugins/sudoers/regress/testsudoers/test5.out.ok
+--- a/plugins/sudoers/regress/testsudoers/test5.out.ok	Fri Jan 11 13:31:15 2019 -0700
 b/plugins/sudoers/regress/testsudoers/test5.out.ok	Thu Oct 10 14:02:30 2019 -0600
+@@ -4,7 +4,7 @@ Parse error in sudoers near line 1.
+ Entries for user root:
+ 
+ Command unmatched
+-testsudoers: test5.inc should be owned by gid 4294967295
++testsudoers: test5.inc should be owned by gid 4294967294
+ Parse error in sudoers near line 1.
+ 
+ Entries for user root:
+diff -r fcd7a6d8330e plugins/sudoers/regress/testsudoers/test5.sh
+--- 

Bug#916670: cryptsetup doesn't work in buster

[Greg Stark]

I have the same problem (though note that the configure script does in
fact exit without an error despite printing the error to the console.
I have to use dpkg-reconfigure to reproduce the error. I assume my
system isn't bootable but I'm not eager to test this):

root@tweedle:~# dpkg-reconfigure initramfs-tools
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-3.16.0-6-amd64
cryptsetup: ERROR: Couldn't resolve device rootfs

My /etc/mtab is indeed a symlink to /proc/self/mounts

root@tweedle:~# ls -l /etc/mtab
lrwxrwxrwx 1 root root 19 Aug 24  2017 /etc/mtab -> ../proc/self/mounts

root@tweedle:/home/stark# cat /proc/self/mounts
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs
rw,nosuid,relatime,size=1984220k,nr_inodes=496055,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=399172k,mode=755 0 0
/dev/mapper/tweedle--vg-root / ext4
rw,relatime,discard,errors=remount-ro,data=ordered 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup
rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup
rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup
rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/perf_event cgroup
rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs
rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
sunrpc /run/rpc_pipefs rpc_pipefs rw,relatime 0 0
/dev/sda1 /boot ext2 rw,relatime 0 0
tmpfs /run/user/122 tmpfs
rw,nosuid,nodev,relatime,size=399168k,mode=700,uid=122,gid=126 0 0
gvfsd-fuse /run/user/122/gvfs fuse.gvfsd-fuse
rw,nosuid,nodev,relatime,user_id=122,group_id=126 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
tmpfs /run/user/1000 tmpfs
rw,nosuid,nodev,relatime,size=399168k,mode=700,uid=1000,gid=1000 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse
rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0


-- 
greg

Bug#942222: crash at startup, like #734405 (ValueError: numpy.dtype does not appear to be the correct type object)

[Andreas Beckmann]

And in jessie and sid:

# seekwatcher
Traceback (most recent call last):
  File "/usr/bin/seekwatcher", line 888, in 
if not options.trace and not options.file:
AttributeError: Values instance has no attribute 'file'

Andreas

Bug#830726: closed by Chris Lamb (Bug#830726: fixed in xtrlock 2.12)

[Chris Lamb]

Hi Antoine,

?
> I see nothing, unless you mean the source code comment?

Yes, the source code comment. I've expanded the (released) changelog
entry here:

  
https://salsa.debian.org/debian/xtrlock/commit/34e6c7c6c33ce6b7510172a2e05e710a99fdc146

… so this visibility will be in subsequent releases at the very least.


Regards,

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