Bug#939442: Upstream investigating

[Michael Fincham]

Upstream has advised they're investigating the issue:



Dovecot's reference is DOP-1408.

-- 
Michael

Bug#939537: ITP: vg -- tools for working with genome variation graphs

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: vg -- tools for working with genome variation graphs
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: vg
  Version : 1.18.0+ds
  Upstream Author : Copyright: © 2014 Erik Garrison
* URL : https://github.com/vgteam/vg#vg
* License : MIT
  Programming Lang: C
  Description : tools for working with genome variation graphs
 variation graph data structures, interchange formats, alignment, genotyping,
 and variant calling methods
 .
 Variation graphs provide a succinct encoding of the sequences of many genomes.
 A variation graph (in particular as implemented in vg) is composed of:
 .
 - nodes, which are labeled by sequences and ids
 - edges, which connect two nodes via either of their respective ends
 - paths, describe genomes, sequence alignments, and annotations (such as gene
   models and transcripts) as walks through nodes connected by edges
 .
 This model is similar to a number of sequence graphs that have been used in
 assembly and multiple sequence alignment. Paths provide coordinate systems
 relative to genomes encoded in the graph, allowing stable mappings to be
 produced even if the structure of the graph is changed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/vg

Bug#939044: ocrmypdf: autopkgtest not compatible with new pikepdf, ghostscript and/or pytest

[Sean Whitton]

Hello Jonas,

On Sat 31 Aug 2019 at 03:58PM +02, Jonas Smedegaard wrote:

> Possibly some of the other tools uses undocumented insecure ghostscript
> calls which was recently removed.
>
> To investigate that further, someone needs to extract the actual input
> (probably Postscript or PDF) and the exact command used to call
> ghostscript.

This was indeed a problem and ocrmypdf upstream has fixed it in the
latest release.

However, there are still test failures, and upstream suspects that we
might just need to wait on ghostscript making a full release:


-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected

[Celejar]

Package: firmware-iwlwifi
Version: 20190717-2
Followup-For: Bug #934781

Hi,

I'm also seeing Microcode SW errors on my Sid system (see attached). I'm
not sure when they started, but I do look at my logs fairly often, and
I've never noticed them before. Sometimes performance is not affected,
but sometimes I see throughput drop from about 240-260 Mbps to about
30-40 Mbps.

~$ uname -a
Linux lila 5.2.0-2-amd64 #1 SMP Debian 5.2.9-2 (2019-08-21) x86_64 GNU/Linux

~$ lspci | grep Wireless
03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 99)

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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.135

-- no debconf information
Sep  5 23:42:30 lila kernel: [ 1480.015788] iwlwifi :03:00.0: Microcode SW 
error detected.  Restarting 0x200.
Sep  5 23:42:30 lila kernel: [ 1480.015915] iwlwifi :03:00.0: Start IWL 
Error Log Dump:
Sep  5 23:42:30 lila kernel: [ 1480.015919] iwlwifi :03:00.0: Status: 
0x0080, count: 6
Sep  5 23:42:30 lila kernel: [ 1480.015921] iwlwifi :03:00.0: Loaded 
firmware version: 29.1044073957.0
Sep  5 23:42:30 lila kernel: [ 1480.015924] iwlwifi :03:00.0: 0x105C | 
ADVANCED_SYSASSERT  
Sep  5 23:42:30 lila kernel: [ 1480.015926] iwlwifi :03:00.0: 0x00A00220 | 
trm_hw_status0
Sep  5 23:42:30 lila kernel: [ 1480.015928] iwlwifi :03:00.0: 0x | 
trm_hw_status1
Sep  5 23:42:30 lila kernel: [ 1480.015930] iwlwifi :03:00.0: 0x00043D54 | 
branchlink2
Sep  5 23:42:30 lila kernel: [ 1480.015932] iwlwifi :03:00.0: 0x0004AFDA | 
interruptlink1
Sep  5 23:42:30 lila kernel: [ 1480.015934] iwlwifi :03:00.0: 0x | 
interruptlink2
Sep  5 23:42:30 lila kernel: [ 1480.015936] iwlwifi :03:00.0: 0xDEADBEEF | 
data1
Sep  5 23:42:30 lila kernel: [ 1480.015938] iwlwifi :03:00.0: 0xDEADBEEF | 
data2
Sep  5 23:42:30 lila kernel: [ 1480.015940] iwlwifi :03:00.0: 0xDEADBEEF | 
data3
Sep  5 23:42:30 lila kernel: [ 1480.015942] iwlwifi :03:00.0: 0x8517 | 
beacon time
Sep  5 23:42:30 lila kernel: [ 1480.015944] iwlwifi :03:00.0: 0x30C1A8EB | 
tsf low
Sep  5 23:42:30 lila kernel: [ 1480.015946] iwlwifi :03:00.0: 0x03DA | 
tsf hi
Sep  5 23:42:30 lila kernel: [ 1480.015948] iwlwifi :03:00.0: 0x | 
time gp1
Sep  5 23:42:30 lila kernel: [ 1480.015950] iwlwifi :03:00.0: 0x7931 | 
time gp2
Sep  5 23:42:30 lila kernel: [ 1480.015952] iwlwifi :03:00.0: 0x0001 | 
uCode revision type
Sep  5 23:42:30 lila kernel: [ 1480.015954] iwlwifi :03:00.0: 0x001D | 
uCode version major
Sep  5 23:42:30 lila kernel: [ 1480.015957] iwlwifi :03:00.0: 0x3E3B4DE5 | 
uCode version minor
Sep  5 23:42:30 lila kernel: [ 1480.015959] iwlwifi :03:00.0: 0x0210 | 
hw version
Sep  5 23:42:30 lila kernel: [ 1480.015961] iwlwifi :03:00.0: 0x00489200 | 
board version
Sep  5 23:42:30 lila kernel: [ 1480.015963] iwlwifi :03:00.0: 0x0A44001C | 
hcmd
Sep  5 23:42:30 lila kernel: [ 1480.015965] iwlwifi :03:00.0: 0x2402200A | 
isr0
Sep  5 23:42:30 lila kernel: [ 1480.015967] iwlwifi :03:00.0: 0x | 
isr1
Sep  5 23:42:30 lila kernel: [ 1480.015968] iwlwifi :03:00.0: 0x0002 | 
isr2
Sep  5 23:42:30 lila kernel: [ 1480.015970] iwlwifi :03:00.0: 0x0041A8C1 | 
isr3
Sep  5 23:42:30 lila kernel: [ 1480.015972] iwlwifi :03:00.0: 0x | 
isr4
Sep  5 23:42:30 lila kernel: [ 1480.015974] iwlwifi :03:00.0: 0x0048012C | 
last cmd Id
Sep  5 23:42:30 lila kernel: [ 1480.015976] iwlwifi :03:00.0: 0x | 
wait_event
Sep  5 23:42:30 lila kernel: [ 1480.015978] iwlwifi :03:00.0: 0x0084 | 
l2p_control
Sep  5 23:42:30 lila kernel: [ 1480.015980] iwlwifi :03:00.0: 0x00018030 | 
l2p_duration
Sep  5 23:42:30 lila kernel: [ 1480.015982] iwlwifi :03:00.0: 0x000F | 
l2p_mhvalid
Sep  5 23:42:30 lila kernel: [ 1480.015984] iwlwifi :03:00.0: 0x0085 | 
l2p_addr_match
Sep  5 23:42:30 lila kernel: [ 1480.015986] iwlwifi :03:00.0: 0x0005 | 
lmpm_pmg_sel
Sep  5 23:42:30 lila kernel: [ 1480.015988] iwlwifi :03:00.0: 0x14031202 | 
timestamp
Sep  5 23:42:30 lila kernel: [ 1480.015990] iwlwifi :03:00.0: 0x5860 | 
flow_handler
Sep  5 23:42:30 lila kernel: [ 1480.016016] iwlwifi :03:00.0: Fseq 
Registers:
Sep  5 23:42:30 lila kernel: [ 1480.016033] iwlwifi :03:00.0: 0x | 
FSEQ_ERROR_CODE
Sep  5 23:42:30 lila kernel: [ 1480.016049] iwlwifi :03:00.0: 0x 

Bug#939536: qemu-system-data: qemu.desktop is missing Exec entry

[Shmerl]

Package: qemu-system-data
Version: 1:4.1-1
Severity: normal

Dear Maintainer,

New qemu.desktop file provided by upstream is missing an Exec entry,
which according to the spec should be present.

See: https://specifications.freedesktop.org/desktop-entry-
spec/latest/ar01s06.html

> The Exec key is required if DBusActivatable is not set to true.
> Even if DBusActivatable is true, Exec should be specified for
> compatibility with implementations that do not understand DBusActivatable.

For example, running kbuildsycoca5 which checks desktop files correctness,
produces this warning:

The desktop entry file "/usr/share/applications/qemu.desktop" has Type=
"Application" but no Exec line

I tried to submit the bug upstream, but I can't access launchpad bug tracker
used by Qemu, their log-in system is broken (at least now).

Thanks!



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

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

-- no debconf information

Bug#763579: systemd.exec(5) manpage does not reflect the Debian changes to ProtectSystem

[intrigeri]

Hi Michael,

Michael Biebl:
> I wonder if it wouldn't be a better idea to document such changes (where
> we divert from upstream or make explicit decisions which are not the
> upstream defaults) in systemd's README.Debian.

> This seems like a more maintainable approach then patching man pages.
> Those patches are bound to require on-going maintenance work to keep
> them updated.

First, thanks for caring!

As a user, I'm not sure I would have thought about looking in
README.Debian: I tend to assume the man pages are correct. (IIRC
I eventually understood what was going on by git grep'ing the
Vcs-Git.) I don't know about other users.

This being said, I understand your concerns about the long-term
maintenance overhead cost. It matters a lot to me.

So all things considered, I think that the approach you're suggesting
is a very reasonable trade-off that's good enough to address this
minor issue :)

Cheers,
-- 
intrigeri

Bug#889509: Fix CMake module installation, prepare for DNF support

[Mihai Moldovan]

> With the greatest embarrased... may I ask you to rebase your .debdiff?

Rebased everything and bumped up to 0.6.36, which also fixes the 3 CVE's
attached to this package. Will upload a new debdiff soon, need to build these
packages for sid and test them for a bit, including the updated dnf stuff.
Shouldn't take too long.


> Have your changes been upstream meanwhile?

I've reworked my own patchset, since the previous solution was weird. It should
be a lot cleaner now and not touching the whole pool content, but only RPM 
stuff.

I also decided not to even try to upstream it, because upstream would almost
certainly reject it anyway. It's a workaround for Debian breaking librpm/rpm, so
Debian is responsible for keeping the patch.

With a bit of luck, we will very soon be able to drop those patches completely
though, as I'm trying to get Debian to not apply the patch that breaks rpm in
the first place... see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794495

(Un-?)fortunately the rpm package is up for grabs since the current maintainer
is not interested in maintaining/using it any longer.

I'm very much interesting in having a working and if possible up-to-date rpm
package within Debian as user, but I'm not a DD and I *know* that I won't have
the time for proper maintenance.



Mihai



signature.asc
Description: OpenPGP digital signature

Bug#939535: lvm2: lvmcache(8) advertises writecache support; lvconvert doesn't support it

[Christopher David Howie]

Package: lvm2
Version: 2.03.02-3

The lvmcache(8) manpage claims that writecache support is available (I
believe this was added in the 4.18 kernel) and gives this example to use it:

$ lvconvert --type writecache --cachepool fast vg/main

But this doesn't actually work:

# lvconvert --type writecache --cachepool lv_root_cache vg_test/lv_root
  WARNING: Unrecognised segment type writecache
  Invalid argument for --type: writecache
  Error during parsing of command line.

Either there is a mistake and writecache support should be there, or
lvmcache(8) probably shouldn't mention it.

-- 
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers

If you correspond with me on a regular basis, please read this document:
http://www.chrishowie.com/email-preferences/

PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5


IMPORTANT INFORMATION/DISCLAIMER

This document should be read only by those persons to whom it is
addressed.  If you have received this message it was obviously addressed
to you and therefore you can read it.

Additionally, by sending an email to ANY of my addresses or to ANY
mailing lists to which I am subscribed, whether intentionally or
accidentally, you are agreeing that I am "the intended recipient," and
that I may do whatever I wish with the contents of any message received
from you, unless a pre-existing agreement prohibits me from so doing.

This overrides any disclaimer or statement of confidentiality that may
be included on your message.

Bug#939534: Google Earth on web using WebAssembly (WASM) cannot get location

[積丹尼 Dan Jacobson]

Package: chromium
Version: 76.0.3809.100-1

https://support.google.com/earth/thread/8400016 says to try
https://earth.google.com/web/?beta=1
In it click the (.) location button.
Answer "allow" when asked permission.
But alas, in the end there is just the message that it cannot get your
location.
Tested with
$ chromium --temp-profile https://g.co/earth/beta

Bug#939505: more information

[wglxy]

When I run opengl program with optirun or primusrun, the program can not run 
and I got a error message as below:




$ optirun freecad
[  614.056579] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed 
to load module "mouse" (module does not exist, 0)

[  614.056596] [ERROR]Aborting because fallback start is disabled.





$ primusrun freecad
/usr/bin/primusrun: line 41: warning: command substitution: ignored null byte 
in input
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Failed to load 
module "mouse" (module does not exist, 0)









Best regards,
Gulfstream

Bug#939489: more information

[wglxy]

When I run opengl program with optirun or primusrun, the program can not run 
and I got a error message as below:


$ optirun freecad
[  614.056579] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed 
to load module "mouse" (module does not exist, 0)

[  614.056596] [ERROR]Aborting because fallback start is disabled.


$ primusrun freecad
/usr/bin/primusrun: line 41: warning: command substitution: ignored null byte 
in input
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Failed to load 
module "mouse" (module does not exist, 0)




Best regards,
Gulfstream

Bug#939533: task-xfce-desktop: should use libreoffice-gtk3 instead of -gtk2

[T. Joseph Carter]

Package: task-xfce-desktop
Version: 3.55
Severity: normal

The XFCE task continues to depend on libreoffice-gtk2, but xfce 4.14 is
now fully gtk3-based and has dropped support for gtk2 integration. Time
to update to libreoffice-gtk3 for the task package?

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

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

Versions of packages task-xfce-desktop depends on:
ii  lightdm   1.26.0-5
ii  task-desktop  3.55
ii  tasksel   3.55
ii  xfce4 4.14

Versions of packages task-xfce-desktop recommends:
ii  atril 1.22.1-1
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  hunspell-en-us1:2018.04.16-1
ii  hyphen-en-us  2.8.8-7
ii  libreoffice   1:6.3.1~rc2-3
ii  libreoffice-gtk2  1:6.3.1~rc2-3
ii  libreoffice-help-en-us1:6.3.1~rc2-3
ii  light-locker  1.8.0-3
ii  mousepad  0.4.2-1
ii  mythes-en-us  1:6.3.0-1
ii  network-manager-gnome 1.8.22-2
ii  orca  3.32.0-1
ii  parole1.0.4-1
ii  quodlibet 4.2.1-1
ii  synaptic  0.84.6+b1
ii  system-config-printer 1.5.11-4
ii  tango-icon-theme  0.8.90-7
ii  xfce4-goodies 4.12.6
pn  xfce4-mixer   
ii  xfce4-power-manager   1.6.5-2
ii  xfce4-terminal0.8.8-1+b1
ii  xsane 0.999-7

task-xfce-desktop suggests no packages.

-- no debconf information

Bug#939532: RM: slapos.core -- ROM; python2-only; dead upstream; popcon=2; not in stable

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#939530: ghostscript: 9.28rc1 regression interpreting valid PDFs

[James R Barlow]

Package: ghostscript
Version: 9.28~~rc1~dfsg-1
Severity: important
Tags: upstream

Dear Maintainer,


1. Ghostscript 9.28rc1 reports "Error reading content streams" when
interpreting PDFs considered valid by Acrobat, qpdf, verapdf and
previous versions of Ghostscript.

2. Ghostscript 9.28rc1 reports "Recursive XObjects" on
multiple-referenced images when interpreting PDFs considered valid by
Acrobat, qpdf, verapdf and previous versions of Ghostscript.

This test file demonstrates both issues.

https://github.com/jbarlow83/OCRmyPDF/raw/master/tests/resources/cardinal.pdf

A command such as will display the error messages

```
$ gs -q -sDEVICE=pngmono -o _.png cardinal.pdf

 Error reading a content stream. The page may be incomplete.
Output may be incorrect.
 Error: File did not complete the page properly and may be damaged.
Output may be incorrect.
 Error: Recursive XObject detected, ignoring "Im0", object number 14
Output may be incorrect.
 Error: Recursive XObject detected, ignoring "Im0", object number 14
Output may be incorrect.
 Error: Recursive XObject detected, ignoring "Im0", object number 14
Output may be incorrect.
```

The error messages appear for other values of sDEVICE. The first
problem just displays a spurious error message. The second problem
will cause images or other objects to be suppressed from Ghostscript's
output.


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

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

Versions of packages ghostscript depends on:
ii  libc6   2.28-10
ii  libgs9  9.28~~rc1~dfsg-1

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
pn  ghostscript-x  

-- no debconf information

Bug#939531: medit: should this package be removed?

[Sandro Tosi]

Package: src:medit
Severity: serious

Looking at this package, it appears that:

* the last upstream update uploaded to debian is from 2014
* the last commit on upstream hg repo is from late 2017
* interest in this tool is declining (looking at popcon)
* it's python2-based, which Debian is trying to remove

Should we remove this package? Opening this ticket so that people interested in
medit can voice their opinions; if i dont hear back in a week with a valid
reason to keep this tool around, i'll make this a RM bug.

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

Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3

[Olly Betts]

On Wed, Aug 14, 2019 at 09:10:22PM +0200, Tobias Frost wrote:
> On Wed, Aug 07, 2019 at 07:00:23AM +0100, Olly Betts wrote:
> > Which makes me wonder - can one explicitly set GDK_SCALE=1 to workaround
> > the problem when using a hidpi display?  Presumably that results in any
> > non-OpenGL content in the window being smaller than ideal, but probably
> > it's like that anyway if one sticks with GTK2.
> 
> Indeed, that works. And yes, other stuff gets tiny (e.g. buttons and their
> icons), but this issue is (still but) less painful than the other…

I've backported the change to make wxWindow::GetContentScaleFactor()
return an appropriate value with hidpi, instead of always reporting 1.0.
This has been applied to upstream's WX_3_0_BRANCH and I've uploaded
a new wxwidgets3.0 package containing it.

So applications which have been adjusted to use API method to support
hidpi under wxWidgets 3.1.x should now behave better under 3.0.x too.

There are quite a lot of other changes related to hidpi on upstream git
master which haven't been backported though.  If you hit further
problems under hidpi, please report them and we can investigate and
decide if we should try to find and backport fixes, or go the
GDK_SCALE=1 route for wx 3.0.x and wait for upstream to release 3.2.0 to
get proper hidpi support.

Cheers,
Olly

Bug#939529: gtg: should this package be removed?

[Sandro Tosi]

Package: src:gtg
Severity: serious

By looking at the status of this package, several points are evidend:

* upstream abandoned its development
* its stack is python2-based, which Debian is trying to remove
* nobody is stepping up to keep this tool up to date

So, should we remove gtg from Debian? I'm opening this bug so people interested
in gtg can voice their opinion; if i dont hear back in a week with a valid
reason to keep it around, i'll convert this bug to RM.

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 gtg depends on:
ii  python2.7.16-1
ii  python-configobj  5.0.6-3
ii  python-dbus   1.2.8-3
ii  python-glade2 2.24.0-6
ii  python-gtk2   2.24.0-6
pn  python-liblarch   
pn  python-notify 
ii  python-xdg0.25-5

Versions of packages gtg recommends:
ii  python-simplejson  3.16.0-1
ii  yelp   3.31.90-1

Versions of packages gtg suggests:
pn  bugz 
pn  python-appindicator  
ii  python-cairo 1.16.2-1+b1
pn  python-cheetah   
ii  python-dateutil  2.7.3-3
pn  python-evolution 
pn  python-geoclue   
pn  python-gnomekeyring  
pn  python-launchpadlib  
pn  python-suds  

Bug#939528: signal-desktop: Program fails to start after latest upgrade, worked fine before.

[Alexander]

Package: signal-desktop
Version: 1.27.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   
running apt upgrade

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

After the recent upgrade signal-desktop refuses to start, it immediately 
terminates with the following error:

[13283:0906/015852.140508:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox 
helper binary was found, but is not configured correctly. Rather than run 
without sandboxing I'm aborting now. You need to make sure that 
/opt/Signal/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

This command fixes the problem:

sudo chmod 4755 /opt/Signal/chrome-sandbox

To make sure the error can be reproduced I ran:

apt reinstall signal-desktop

and the error re-appeared. Changing the permissions fixed the problem again.

Thank you very much for maintaining this package.

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/16 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:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages signal-desktop depends on:
ii  libappindicator1  0.4.92-7
ii  libasound21.1.8-1
ii  libnotify40.7.8-1
ii  libnss3   2:3.45-1
ii  libxss1   1:1.2.3-1
ii  libxtst6  2:1.2.3-1

signal-desktop recommends no packages.

signal-desktop suggests no packages.

-- no debconf information

Bug#937436: pyfai: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:33:41 + Matthias Klose  wrote:
> Package: src:pyfai
> Version: 0.17.0+dfsg1-3
> 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.

Hello,
i've pushed to pyfai git repo a few commits, most importantly to drop
the python2 packages; i'm really not familiar with the package (but it
build fine in a pbuilder chroot), so i'm writing to you: could you
have a look at the latest changes and possibly upload the package?
ideally we should target unstable for this upload.

pyfai currently depends on several python2 packages, which cant be
dropped until their reverse-depends count goes to 0.

Thanks!

Bug#918754: bash: $PATH in bash does not include /sbin and /usr/sbin

[Markus Koschany]

This is a new behavior because the util-linux implementation of su is
used now. See also /usr/share/doc/util-linux/NEWS.Debian.gz for more
information.

"If you want to restore behaviour more similar to
  the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs."

Markus



signature.asc
Description: OpenPGP digital signature

Bug#931645: mcomix: Fails to start with python-pil (>= 6.0.0)

[Antoine Amarilli]

Hi,

This bug makes mcomix completely unusable. Would it be possible to
integrate the proposed patch? Many thanks!

PS: Related discussion on an upstream bugtracker:


Best,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#939527: vcdimager contains one file with different license

[bendikker]

Package: vcdimager https://tracker.debian.org/pkg/vcdimager
Version: 0.7.24
Debian copyright notion.
https://metadata.ftp-master.debian.org/changelogs//main/v/vcdimager/vcdimager_2.0.1+dfsg-3_copyright

The file changed on 17-03-2011 from gpl 2 or later to gpl 2
https://cvs.savannah.gnu.org/viewvc/vcdimager/vcdimager/lib/sector.c?view=markup

Already send a message to (not visible at the moment)
https://lists.gnu.org/mailman/listinfo/bug-vcdimager/
also
https://directory.fsf.org/wiki/User_talk:Rockyb
more info
https://directory.fsf.org/wiki/vcdimager


-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Bug#939526: buster-pu: package inn2/2.6.3-1~deb10u1

[Marco d'Itri]

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

Bug #931256 explains in detail why TLS is broken in inn2 in buster, due 
to the policies of newer openssl versions.

This same patch has been in 2.6.3-2 in unstable/testing for two weeks.

diff -Nru inn2-2.6.3/debian/changelog inn2-2.6.3/debian/changelog
--- inn2-2.6.3/debian/changelog 2019-02-17 17:52:36.0 +0100
+++ inn2-2.6.3/debian/changelog 2019-09-05 23:25:56.0 +0200
@@ -1,3 +1,10 @@
+inn2 (2.6.3-1~deb10u1) buster; urgency=medium
+
+  * Backported upstream changeset 10344 to fix negotiation of DHE
+ciphersuites. (See #931256.)
+
+ -- Marco d'Itri   Thu, 05 Sep 2019 23:25:56 +0200
+
 inn2 (2.6.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru inn2-2.6.3/debian/patches/changeset_10344 
inn2-2.6.3/debian/patches/changeset_10344
--- inn2-2.6.3/debian/patches/changeset_10344   1970-01-01 01:00:00.0 
+0100
+++ inn2-2.6.3/debian/patches/changeset_10344   2019-09-05 22:34:04.0 
+0200
@@ -0,0 +1,202 @@
+Index: a/nnrpd/tls.c
+===
+--- a/nnrpd/tls.c  (revision 10342)
 a/nnrpd/tls.c  (revision 10344)
+@@ -96,45 +96,58 @@
+ 
+ /*
+-**  Hardcoded DH parameter files, from OpenSSL.
+-**  For information on how these files were generated, see
+-**  "Assigned Number for SKIP Protocols" 
+-**  .
+-*/
+-static const char file_dh512[] =
++**  Hardcoded DH parameter files.
++**  These are pre-defined DH groups recommended by RFC 7919 (Appendix A),
++**  that have been audited and therefore supposed to be more
++**  resistant to attacks than ones randomly generated.
++*/
++static const char file_ffdhe2048[] = \
+ "-BEGIN DH PARAMETERS-\n\
+-MEYCQQD1Kv884bEpQBgRjXyEpwpy1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWak\n\
+-XUGfnHy9iUsiGSa6q6Jew1XpKgVfAgEC\n\
++MIIBCAKCAQEA//+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz\n\
+++8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a\n\
++87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7\n\
++YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi\n\
++7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaD\n\
++ssbzSibBsu/6iGtCOGEoXJf//wIBAg==\n\
+ -END DH PARAMETERS-\n";
+ 
+-static const char file_dh1024[] =
++static const char file_ffdhe4096[] = \
+ "-BEGIN DH PARAMETERS-\n\
+-MIGHAoGBAPSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kjwEPwpVsY\n\
+-jY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnIByl6\n\
+-ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpL3jHAgEC\n\
++MIICCAKCAgEA//+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz\n\
+++8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a\n\
++87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7\n\
++YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi\n\
++7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaD\n\
++ssbzSibBsu/6iGtCOGEfz9zeNVs7ZRkDW7w09N75nAI4YbRvydbmyQd62R0mkff3\n\
++7lmMsPrBhtkcrv4TCYUTknC0EwyTvEN5RPT9RFLi103TZPLiHnH1S/9croKrnJ32\n\
++nuhtK8UiNjoNq8Uhl5sN6todv5pC1cRITgq80Gv6U93vPBsg7j/VnXwl5B0rZp4e\n\
++8W5vUsMWTfT7eTDp5OWIV7asfV9C1p9tGHdjzx1VA0AEh/VbpX4xzHpxNciG77Qx\n\
++iu1qHgEtnmgyqQdgCpGBMMRtx3j5ca0AOAkpmaMzy4t6Gh25PXFAADwqTs6p+Y0K\n\
++zAqCkc3OyX3Pjsm1Wn+IpGtNtahR9EGC4caKAH5eZV9q//8CAQI=\n\
+ -END DH PARAMETERS-\n";
+ 
+-static const char file_dh2048[] =
++static const char file_ffdhe8192[] = \
+ "-BEGIN DH PARAMETERS-\n\
+-MIIBCAKCAQEA9kJXtwh/CBdyorrWqULzBej5UxE5T7bxbrlLOCDaAadWoxTpj0BV\n\
+-89AHxstDqZSt90xkhkn4DIO9ZekX1KHTUPj1WV/cdlJPPT2N286Z4VeSWc39uK50\n\
+-T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq01uejaClcjrUGvC/RgBYK+X0iP1YTknb\n\
+-zSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O9vPJI8BD8KVbGI2Ou1WMuF040zT9fBdX\n\
+-Q6MdGGzeMyEstSr/POGxKUAYEY18hKcKctaGxAMZyAcpesqVDNmWn6vQClCbAkbT\n\
+-CD1mpF1Bn5x8vYlLIhkmuquiXsNV6TILOwIBAg==\n\
+--END DH PARAMETERS-\n";
+-
+-static const char file_dh4096[] =
+-"-BEGIN DH PARAMETERS-\n\
+-MIICCAKCAgEA+hRyUsFN4VpJ1O8JLcCo/VWr19k3BCgJ4uk+d+KhehjdRqNDNyOQ\n\
+-l/MOyQNQfWXPeGKmOmIig6Ev/nm6Nf9Z2B1h3R4hExf+zTiHnvVPeRBhjdQi81rt\n\
+-Xeoh6TNrSBIKIHfUJWBh3va0TxxjQIs6IZOLeVNRLMqzeylWqMf49HsIXqbcokUS\n\
+-Vt1BkvLdW48j8PPv5DsKRN3tloTxqDJGo9tKvj1Fuk74A+Xda1kNhB7KFlqMyN98\n\
+-VETEJ6c7KpfOo30mnK30wqw3S8OtaIR/maYX72tGOno2ehFDkq3pnPtEbD2CScxc\n\
+-alJC+EL7RPk5c/tgeTvCngvc1KZn92Y//EI7G9tPZtylj2b56sHtMftIoYJ9+ODM\n\
+-sccD5Piz/rejE3Ome8EOOceUSCYAhXn8b3qvxVI1ddd1pED6FHRhFvLrZxFvBEM9\n\
+-ERRMp5QqOaHJkM+Dxv8Cj6MqrCbfC4u+ZErxodzuusgDgvZiLF22uxMZbobFWyte\n\
+-OvOzKGtwcTqO/1wV5gKkzu1ZVswVUQd5Gg8lJicwqRWyyNRczDDoG9jVDxmogKTH\n\
+-AaqLulO7R8Ifa1SwF2DteSGVtgWEN8gDpN3RBmmPTDngyF2DHb5qmpnznwtFKdTL\n\
+-KWbuHn491xNO25CQWMtem80uKw+pTnisBRF/454n1Jnhub144YRBoN8CAQI=\n\
++MIIECAKCBAEA//+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz\n\

Bug#874880: [freemedforms-project] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Fri, Feb 01, 2019 at 09:36:38AM +0100, Andreas Tille wrote:
> Hi again,
> 
> just for your information:  If freemedforms will not be uploaded until
> end of this weekend I do not see any realistic chance that it will make
> it into the next Debian stable release.

Hi Andreas,
I've downloaded 1.0.0 and the included README.md states "FreeMedForms
and derivatives are coded in C++ / Qt5", so I suppose the latest
version should now support Qt5.

If that works fine, it would be great to have an upload within the next
weeks, as we're trying to finally remove Qt4 for good.

Cheers,
Moritz

Bug#939525: RM: buildnotify -- RoQA; unmaintained, depends on qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove buildnotify. It's unmaintained (this was a one off
upload back in 2014, no followup to any bug since then and the
package is lagging far behind upstream) and depends on Qt4 (and
Python 2).

Cheers,
Moritz

Bug#939524: pylint: Emacs startup file refers to missing files

[Michal Sojka]

Package: pylint
Version: 2.2.2-2
Severity: normal

Dear Maintainer,

the package installs /etc/emacs/site-start.d/50pylint.el, which setups
hooks and autoloads referring to pylint.el, which is not included in
the binary package. This causes Emacs failures when opening any *.py
file. Could you please either remove 50pylint.el or include the
missing *.el files in the package?

Thank you.
-Michal

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
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 pylint depends on:
ii  python3 3.7.3-1
ii  python3-astroid 2.1.0-2
ii  python3-isort   4.3.4+ds1-1.1
ii  python3-logilab-common  1.4.3-2
ii  python3-mccabe  0.6.1-2
ii  python3-setuptools  41.2.0-1

Versions of packages pylint recommends:
ii  python3-tk  3.7.4-3

Versions of packages pylint suggests:
pn  pylint-doc  

-- no debconf information

Bug#939048: Sextractor: improve tests (was: Bug#939048: transition: glibc)

[Aurelien Jarno]

Hi,

On 2019-09-05 13:30, Ole Streicher wrote:
> Package: sextractor
> Version: 2.19.5+dfsg-6
> 
> 
> Hi Paul, Aurelien,
> 
> I maintain both packages (sextractor and iraf-fitsutil).
> 
> 1st, quick answer for sextractor: You don't need to care; this is my
> fault/problem: The test is home-made and directly compares string-wise
> the result with a reference catalog, which fails due to minimal changes
> in the numbers -- from a quick view, that should be neglilible. That

I have just looked at the precision changes in math function in glibc
2.29. No degradation of precision is expected except for ccos, ccosh,
cexp, cos, cosh, cpow, csin, csinh, exp10, sin and sincos when they are
used with the non-default rounding mode (round to nearest). I doubt
sextractor changes the rounding mode, so the changes are probably slight
increase in precision due to the usage of new algorithms.

> also happened in the past, and I solved it by updating the reference
> (which is ofcourse not the smartest solution). If you have a good
> general way to handle this, I am happy to apply this; otherwise I will
> just read+compare the numbers with python3-numpy in future.

You might be able to filter the table with awk or other tool to round
the values a bit. But numpy might even be better in that case.

> For iraf-fitsutil, I still have no glue what happens there. That is also
> a bit painful to debug, since the package is mainly written in a domain
> specific language (IRAF SPP; Aurelien may know it from work). So I am
> afraid it may take a bit of time to analyze.

I have just submitted bug#939523 with a patch to fix the issue. I guess
that technically the next glibc upload should add a Breaks: on versions
lower than the fixed version.

Aurelien

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

Bug#939523: iraf-fitsutil: autopkgtest fail with glibc 2.29 due to missing tm_isdst initialization

[Aurelien Jarno]

Package: iraf-fitsutil
Version: 2018.07.06-3
Severity: normal
Tags: patch upstream

As discussed in bug#939048, the autopkgtest from iraf-fitsutil fail in a
strange way when run with glibc 2.29 instead of glibc 2.28:

| cl> fitsutil
| This is the initial release of the IRAF FITSUTIL package
| to include support for FITS tile compression via 'fpack'.
| Please send comments and questions to sea...@noao.edu.
| 
| cl> copy dev$pix.pix pix.pix
| cl> copy dev$pix.imh pix.imh
| cl> fgwrite "pix.pix pix.imh" pix.fits verb-
| cl> mkdir out
| cl> cd out
| cl> fgread ../pix.fits "" "" verb-
| cl> sum32 *
| ERROR: No write permission on file (String_File)
|   "directory (img, long+) | scan (junk, junk, filsiz)"
|  line 42: fitsutil$src/sum32.cl
|  called as: `sum32 (input=*)'
|  called as: `cl ()'
|   "clbye()"
|  line 41: fitsutil$fitsutil.cl
|  called as: `fitsutil ()'
|  called as: `cl ()'
| Error while reading login.cl file - may need to rebuild with mkiraf
| Fatal startup error.  CL dies.

This happens because the error checking in mktime() have been improved
in case a non-valid date is provided in the tm struct. More precisely
in fgread.c, it should be noted that strptime does NOT setup the
tm_isdst of tm struct, which is instead getting a random value from the
stack. For this field 0 means no DST, positive value means DST and
negative values means that the value should be computed by mktime().

In the iraf-fitsutil, tm_isdst is not known from the file so it should
be set to -1, just like it's done in the POSIX.1-2018 strptime example:

https://pubs.opengroup.org/onlinepubs/9699919799/


Therefore the following patch fixes the issue:

--- iraf-fitsutil-2018.07.06.orig/src/fgread.c
+++ iraf-fitsutil-2018.07.06/src/fgread.c
@@ -469,6 +469,9 @@ char *type; /* Extension type */
 
s = kwdb_GetValue (kwdb, "FG_MTIME");   
 
+   /* Not set by strptime(); tells mktime() to determine whether daylight
+* saving time is in effect */
+   tm.tm_isdst = -1; 
strptime (s, "%Y-%m-%dT%T",);
fh->mtime = mktime() - get_timezone();
 


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

Bug#939522: fetchmail: trying to overwrite '/usr/bin/fetchmailconf', which is also in package fetchmailconf 6.4.0~rc3-1

[Axel Beckert]

Package: fetchmail
Version: 6.4.0~rc3-1
Severity: serious

Hi,

according to the changelog entry, fetchmailconf is removed, but it
actually seems to now being shipped in the fetchmail package without
proper Breaks/Replaces headers.

The upgrade fails for me as follows:

Preparing to unpack .../fetchmail_6.4.0~rc4-1_amd64.deb ...
Not starting fetchmail daemon, disabled via /etc/default/fetchmail.
Unpacking fetchmail (6.4.0~rc4-1) over (6.4.0~rc3-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/fetchmail_6.4.0~rc4-1_amd64.deb (--unpack):
 trying to overwrite '/usr/bin/fetchmailconf', which is also in package 
fetchmailconf 6.4.0~rc3-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Not starting fetchmail daemon, disabled via /etc/default/fetchmail.

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

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

Versions of packages fetchmail depends on:
ii  adduser   3.118
ii  debianutils   4.8.6.3
ii  libc6 2.28-10
ii  libcom-err2   1.45.3-4
ii  libgssapi-krb5-2  1.17-6
ii  libkrb5-3 1.17-6
ii  libssl1.1 1.1.1c-1
ii  lsb-base  11.1.0

Versions of packages fetchmail recommends:
ii  ca-certificates  20190110

Versions of packages fetchmail suggests:
ii  fetchmailconf   6.4.0~rc3-1
ii  postfix [mail-transport-agent]  3.4.5-1+b1
pn  resolvconf  

-- no debconf information

Bug#939519: libthread-pool FTBFS with DEB_BUILD_PROFILES=nocheck

[Helmut Grohne]

Source: libthread-pool
Version: 1.0.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libthread-pool fails to build from source (natively) when building with
the nocheck profile, because running cmake fails when the vendor
googletest symlink is missing. This happens to break cross building as
well. Please turn the relevant dependency unconditional to fix this
FTBFS.

Helmut
diff --minimal -Nru libthread-pool-1.0.0/debian/changelog 
libthread-pool-1.0.0/debian/changelog
--- libthread-pool-1.0.0/debian/changelog   2019-08-21 11:19:44.0 
+0200
+++ libthread-pool-1.0.0/debian/changelog   2019-09-05 22:17:54.0 
+0200
@@ -1,3 +1,11 @@
+libthread-pool (1.0.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with nocheck profile: Unconditionally build-depend on
+googletest. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 05 Sep 2019 22:17:54 +0200
+
 libthread-pool (1.0.0-3) unstable; urgency=medium
 
   [ Michael R. Crusoe ]
diff --minimal -Nru libthread-pool-1.0.0/debian/control 
libthread-pool-1.0.0/debian/control
--- libthread-pool-1.0.0/debian/control 2019-08-21 11:19:44.0 +0200
+++ libthread-pool-1.0.0/debian/control 2019-09-05 22:17:51.0 +0200
@@ -7,7 +7,7 @@
cmake,
d-shlibs,
rename,
-   googletest 
+   googletest
 Standards-Version: 4.4.0
 Vcs-Browser: https://salsa.debian.org/med-team/libthread-pool
 Vcs-Git: https://salsa.debian.org/med-team/libthread-pool.git

Bug#939521: openjdk-11 FTBFS with DEB_BUILD_PROFILES=nocheck

[Helmut Grohne]

Source: openjdk-11
Version: 11.0.5+6-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

openjdk-11 fails to build from source (natively) when built with the
nocheck profile, because debian/rules checks for jtreg even when it is
not installed. The attached patch conditionalizes the sanity check and
makes openjdk-11 buildable without checks again. Please consider
applying it. This happens to also make cross building fail.

Helmut
diff --minimal -Nru openjdk-11-11.0.5+6/debian/changelog 
openjdk-11-11.0.5+6/debian/changelog
--- openjdk-11-11.0.5+6/debian/changelog2019-09-04 16:48:18.0 
+0200
+++ openjdk-11-11.0.5+6/debian/changelog2019-09-05 22:27:37.0 
+0200
@@ -1,3 +1,10 @@
+openjdk-11 (11.0.5+6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with DEB_BUILD_PROFILES=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 05 Sep 2019 22:27:37 +0200
+
 openjdk-11 (11.0.5+6-1) unstable; urgency=medium
 
   * OpenJDK 11.0.5+6 build (early access).
diff --minimal -Nru openjdk-11-11.0.5+6/debian/rules 
openjdk-11-11.0.5+6/debian/rules
--- openjdk-11-11.0.5+6/debian/rules2019-09-04 16:48:18.0 +0200
+++ openjdk-11-11.0.5+6/debian/rules2019-09-05 20:42:18.0 +0200
@@ -958,12 +958,14 @@
 build_stamps +=  stamps/jtreg-check-default
 
 pre-build:
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
jtreg_version="$$(dpkg-query -f '$${Version}\n' -W jtreg)"; \
if ! dpkg --compare-versions $(min_jtreg_version) le $$jtreg_version; 
then \
  echo "Error: testsuite requires jtreg $(min_jtreg_version) but 
$$jtreg_version is installed"; \
  echo "Please update the jtreg dependency and regenerate 
debian/control"; \
  false; \
fi
+endif
 ifneq (,$(filter $(DEB_HOST_ARCH),s390))
@echo explicitely fail the build for $(DEB_HOST_ARCH), patches not 
updated
 #else ifneq (,$(filter $(DEB_HOST_ARCH),armel))

Bug#939518: dpuser FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: dpuser
Version: 4.0+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dpuser fails to cross build from source, because it does not pass cross
tools to make. For the dpuser subdirectory, the easiest way of mostly
fixing this is using dh_auto_build. There are two places where g++ is
hard coded rather than using $(CXX), which also need to be fixed. The
attached patch fixes these issues.

Then it comes to the QFitsView. There a makefile calls qmake without the
appropriate flags. This is more difficult. Usually, we try to call qmake
through dh_auto_configure, but the qmake call is wrapped here
unfortunately. I don't have a simple solution here.

Please consider applying the attached patch anyway as an incremental
step and close this bug when doing so.

Helmut
diff --minimal -Nru dpuser-4.0+dfsg/debian/changelog 
dpuser-4.0+dfsg/debian/changelog
--- dpuser-4.0+dfsg/debian/changelog2019-09-04 20:56:42.0 +0200
+++ dpuser-4.0+dfsg/debian/changelog2019-09-05 21:54:55.0 +0200
@@ -1,3 +1,10 @@
+dpuser (4.0+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Build dpuser with the right compiler. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 05 Sep 2019 21:54:55 +0200
+
 dpuser (4.0+dfsg-1) unstable; urgency=low
 
   * Update VCS fields to use salsa.d.o
diff --minimal -Nru dpuser-4.0+dfsg/debian/patches/cross.patch 
dpuser-4.0+dfsg/debian/patches/cross.patch
--- dpuser-4.0+dfsg/debian/patches/cross.patch  1970-01-01 01:00:00.0 
+0100
+++ dpuser-4.0+dfsg/debian/patches/cross.patch  2019-09-05 21:54:55.0 
+0200
@@ -0,0 +1,20 @@
+--- dpuser-4.0+dfsg.orig/dpuser/Makefile
 dpuser-4.0+dfsg/dpuser/Makefile
+@@ -31,7 +31,7 @@
+ SED = sed
+ CC  = gcc
+ CXX = g++
+-LINK= g++
++LINK= $(CXX)
+ QF  =
+ GDL =
+ PY  =
+@@ -262,7 +262,7 @@
+ endif # end LINUX & MACOSX
+ 
+ $(TARGET_DLL): $(DLL_OBJECTS)
+-  g++ -shared -o $(TARGET_DLL) $(DLL_OBJECTS) $(DLL_LIBS)
++  $(LINK) -shared -o $(TARGET_DLL) $(DLL_OBJECTS) $(DLL_LIBS)
+ 
+ $(TARGET_WIN): $(OBJECTS)
+   $(LINK) $(LDFLAG) -o $(TARGET_WIN) $(OBJECTS) $(LIBS)
diff --minimal -Nru dpuser-4.0+dfsg/debian/patches/series 
dpuser-4.0+dfsg/debian/patches/series
--- dpuser-4.0+dfsg/debian/patches/series   2019-09-04 20:56:42.0 
+0200
+++ dpuser-4.0+dfsg/debian/patches/series   2019-09-05 21:54:55.0 
+0200
@@ -8,3 +8,4 @@
 Don-t-use-SVN-version.patch
 Fix-gcc-optimization-bug-in-ifNode-evaluate.patch
 Fix-test-script.patch
+cross.patch
diff --minimal -Nru dpuser-4.0+dfsg/debian/rules dpuser-4.0+dfsg/debian/rules
--- dpuser-4.0+dfsg/debian/rules2019-09-04 20:56:42.0 +0200
+++ dpuser-4.0+dfsg/debian/rules2019-09-05 21:54:55.0 +0200
@@ -9,7 +9,7 @@
dh  $@
 
 override_dh_auto_build:
-   $(MAKE) -C dpuser
+   dh_auto_build --sourcedirectory=dpuser --no-parallel
$(MAKE) -C QFitsView release_shared
 
 ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)

Bug#939516: patch/merge-request

[Dan Streetman]

On Thu, Sep 5, 2019 at 3:40 PM Sven Joachim  wrote:
>
> On 2019-09-05 15:03 -0400, Dan Streetman wrote:
>
> > I have a commit to fix this here:
> > https://salsa.debian.org/ddstreet-guest/dpkg/commit/dcccd6ed83989d7a2a752d05b1e4c0326c8c8a21
> >
> > however it seems that dpkg in salsa has merge requests disabled, so i
> > can't open a merge request for it.  Can you review that commit please?
>
> It would be best to include the patch in the mail
> (run "git format-patch" and attach the resulting file) so that it can be
> commented here.  Just one remark for now, you should run
> dh_autoreconf_clean in the clean target.

sure, just sent it with git send-email, and updated it to call
dh_autoreconf_clean in clean target.  thanks!

>
> Cheers,
>Sven

Bug#939516: [PATCH] d/rules: replace custom rule for 'configure' with call to dh_autoreconf

[Dan Streetman]

From: Dan Streetman 

Having a custom rule to create 'configure' means that if the file
may not get correctly rebuilt; instead dh_autoreconf should be
called to make sure it is always correctly rebuilt.

Closes: #939516
---
 debian/rules | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/debian/rules b/debian/rules
index a542193fc..006d069ce 100755
--- a/debian/rules
+++ b/debian/rules
@@ -47,15 +47,10 @@ endif
 
 D := $(CURDIR)/debian/tmp
 
-# Create configure script if necessary, automake handles rebuilding it.
-configure:
-   dh_testdir
-
-   ./autogen
-
 # Configure the build tree
-build-tree/config.status: configure
+build-tree/config.status:
dh_testdir
+   dh_autoreconf
 
install -d build-tree
cd build-tree && ../configure $(confflags) \
@@ -164,6 +159,7 @@ clean:
 
[ ! -f Makefile ] || $(MAKE) distclean
rm -rf build-tree
+   dh_autoreconf_clean
dh_clean
 
 
-- 
2.20.1

Bug#939439: closed by Thomas Goirand (Bug#939439: fixed in websockify 0.8.0+dfsg1-15)

[Axel Beckert]

Control: reopen -1
Control: found -1 0.8.0+dfsg1-15

Hi Thomas,

Debian Bug Tracking System wrote:
>  websockify (0.8.0+dfsg1-15) unstable; urgency=medium
>  .
>* Remove duplicate manpage from python3-websocify (Closes: #939439).

I'm sorry to say, but while the fix looked good on a first glance, it
doesn't seem to really fix the issue:

Preparing to unpack .../websockify_0.8.0+dfsg1-15_amd64.deb ...
Unpacking websockify (0.8.0+dfsg1-15) over (0.8.0+dfsg1-10+b1) ...
(Reading database ... 1699913 files and directories currently installed.)
Removing python-websockify (0.8.0+dfsg1-10+b1) ...
(Reading database ... 1699898 files and directories currently installed.)
Preparing to unpack .../websockify-common_0.8.0+dfsg1-15_all.deb ...
Unpacking websockify-common (0.8.0+dfsg1-15) over (0.8.0+dfsg1-10) ...
Selecting previously unselected package python3-websockify.
Preparing to unpack .../python3-websockify_0.8.0+dfsg1-15_amd64.deb ...
Unpacking python3-websockify (0.8.0+dfsg1-15) ...
dpkg: error processing archive 
/var/cache/apt/archives/python3-websockify_0.8.0+dfsg1-15_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/websockify.1.gz', which is also in 
package websockify 0.8.0+dfsg1-15

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#939508: [pkg-gnupg-maint] Bug#939508: scdaemon: scdaemon does not share access with pcscd used by opensc

[Werner Koch]

On Thu,  5 Sep 2019 13:05, robert.grizz...@quoininc.com said:

> I am attempting to use both the gpg and PIV functionaity of a Yubikey 5 
> device, but scdaemon takes exclusive access.  This is the intended behavior 

FWIW: GnuPG master has dedicated support for Yubikeys and since today
allows on-the-fly switching between the PIV and the OpenPGP application
on the Yubikey.  Thus you can use the Yubikey to sign commits with the
OpenPGP key and also use it in Firefox or Thunderbird via the scute.org
(git master) pkcs#11 provider.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#939170: linux-image-5.2.0-2-amd64: does not suspend completely, locks up

[Moritz Schlarb]

Source: linux
Version: 5.2.9-2
Followup-For: Bug #939170

Hi everyone,

I'm seeing the same issue with linux-image-5.2.0-2-amd64=5.2.9-2 on Lenovo
Thinkpad X1 Carbon 4th Gen.

Best regards,
Moritz



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

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

Bug#921559: MTP broken for number of phones with "LIBMTP PANIC: Unable to initialize device"

[Eric Van Buggenhaut]

On Sun, 4 Aug 2019 18:59:34 +0300 Vincas Dargis  wrote:
> On Thu, 11 Apr 2019 09:20:01 +0200 Erwan David
 wrote:
> > Same problem with a Huawei P9 Lite (2017)
>
> My problems are fixed now with libmtp 1.1.16 on Sid. Does it work now
for you too?
>
>

I'm experiencing the same problem with libmtp 1.1.16 on Buster:

$ mtp-detect
libmtp version: 1.1.16

Listing raw device(s)
Device 0 (VID=18d1 and PID=4ee2) is a Google Inc Nexus/Pixel (MTP+ADB).
   Found 1 device(s):
   Google Inc: Nexus/Pixel (MTP+ADB) (18d1:4ee2) @ bus 1, dev 38
Attempting to connect device(s)
error returned by libusb_claim_interface() = -6LIBMTP PANIC: Unable to
initialize device
Unable to open raw device 0
OK.

Bug#939516: patch/merge-request

[Sven Joachim]

On 2019-09-05 15:03 -0400, Dan Streetman wrote:

> I have a commit to fix this here:
> https://salsa.debian.org/ddstreet-guest/dpkg/commit/dcccd6ed83989d7a2a752d05b1e4c0326c8c8a21
>
> however it seems that dpkg in salsa has merge requests disabled, so i
> can't open a merge request for it.  Can you review that commit please?

It would be best to include the patch in the mail
(run "git format-patch" and attach the resulting file) so that it can be
commented here.  Just one remark for now, you should run
dh_autoreconf_clean in the clean target.

Cheers,
   Sven

Bug#939510: [Pkg-utopia-maintainers] Bug#939510: Bug#939510: upower.service: Failed to set up user namespacing: Invalid argument

[Michael Biebl]

Am 05.09.19 um 21:10 schrieb Elimar Riesebieter:
> * Michael Biebl  [2019-09-05 20:41 +0200]:
> 
>> Control: forcemerge -1 939468
>>
>> Am 05.09.19 um 19:48 schrieb Salvo Tomaselli:
>>> Package: upower
>>> Version: 0.99.11-1
>>> Severity: important
>>> Tags: patch
>>>
>>> Dear Maintainer,
>>>
>>> upon reboot I could not access my graphical session because upowerd was 
>>> failing
>>> to be started by systemd.
>>>
>>> And apparently without it running sddm only shows garbage on screen.
>>>
>>> set 05 19:04:52 serenity systemd[1]: Stopped Daemon for power management.
>>> set 05 19:04:52 serenity systemd[1]: Starting Daemon for power management...
>>> set 05 19:04:52 serenity systemd[950]: upower.service: Failed to set up 
>>> user namespacing: Invalid argument
>>> set 05 19:04:52 serenity systemd[950]: upower.service: Failed at step USER 
>>> spawning /usr/lib/upower/upowerd: Invalid argument
>>> set 05 19:04:52 serenity systemd[1]: upower.service: Main process exited, 
>>> code=exited, status=217/USER
>>> set 05 19:04:52 serenity systemd[1]: upower.service: Failed with result 
>>> 'exit-code'.
>>> set 05 19:04:52 serenity systemd[1]: Failed to start Daemon for power 
>>> management.
>>> set 05 19:04:53 serenity systemd[1]: upower.service: Service 
>>> RestartSec=100ms expired, scheduling restart.
>>> set 05 19:04:53 serenity systemd[1]: upower.service: Scheduled restart job, 
>>> restart counter is at 2.
>>>
>>> I have a long list of those.
>>>
>>> Commenting the user namespace directive solves the issue for me.
>>>
>>
>>
>> Duplicate of #939468
>>
>> You are both using a custom kernel.
>> If I had to guess, I'd say that's the culprit.
> 
> 0.99.10-1 runs fine, though. Which kernelconfig is necessary to run
> 0.99.11?

I'd start with what's documented in /usr/share/doc/systemd/README.gz
and if that is not sufficient, diff your config with the one from the
Debian 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#936341: createrepo: Python2 removal in sid/bullseye

[Mike Miller]

Control: block -1 with 912338

The upstream replacement for createrepo is createrepo_c. There is
already an ITP filed, set as blocking for this bug.

The reverse dependencies of createrepo are src:koji, src:mock, and
src:open-build-service. All three packages appear to me to already
prefer createrepo_c over createrepo when it is available. So once
createrepo_c is in Debian and those packages have their dependencies
updated, createrepo can be removed.

-- 
mike

Bug#939516: patch/merge-request

[Dan Streetman]

I have a commit to fix this here:
https://salsa.debian.org/ddstreet-guest/dpkg/commit/dcccd6ed83989d7a2a752d05b1e4c0326c8c8a21

however it seems that dpkg in salsa has merge requests disabled, so i
can't open a merge request for it.  Can you review that commit please?

Bug#939510: [Pkg-utopia-maintainers] Bug#939510: upower.service: Failed to set up user namespacing: Invalid argument

[Elimar Riesebieter]

* Michael Biebl  [2019-09-05 20:41 +0200]:

> Control: forcemerge -1 939468
> 
> Am 05.09.19 um 19:48 schrieb Salvo Tomaselli:
> > Package: upower
> > Version: 0.99.11-1
> > Severity: important
> > Tags: patch
> > 
> > Dear Maintainer,
> > 
> > upon reboot I could not access my graphical session because upowerd was 
> > failing
> > to be started by systemd.
> > 
> > And apparently without it running sddm only shows garbage on screen.
> > 
> > set 05 19:04:52 serenity systemd[1]: Stopped Daemon for power management.
> > set 05 19:04:52 serenity systemd[1]: Starting Daemon for power management...
> > set 05 19:04:52 serenity systemd[950]: upower.service: Failed to set up 
> > user namespacing: Invalid argument
> > set 05 19:04:52 serenity systemd[950]: upower.service: Failed at step USER 
> > spawning /usr/lib/upower/upowerd: Invalid argument
> > set 05 19:04:52 serenity systemd[1]: upower.service: Main process exited, 
> > code=exited, status=217/USER
> > set 05 19:04:52 serenity systemd[1]: upower.service: Failed with result 
> > 'exit-code'.
> > set 05 19:04:52 serenity systemd[1]: Failed to start Daemon for power 
> > management.
> > set 05 19:04:53 serenity systemd[1]: upower.service: Service 
> > RestartSec=100ms expired, scheduling restart.
> > set 05 19:04:53 serenity systemd[1]: upower.service: Scheduled restart job, 
> > restart counter is at 2.
> > 
> > I have a long list of those.
> > 
> > Commenting the user namespace directive solves the issue for me.
> > 
> 
> 
> Duplicate of #939468
> 
> You are both using a custom kernel.
> If I had to guess, I'd say that's the culprit.

0.99.10-1 runs fine, though. Which kernelconfig is necessary to run
0.99.11?

Elimar
-- 
  Experience is something you don't get until
  just after you need it!

Bug#938875: yum-utils: Python2 removal in sid/bullseye

[Mike Miller]

The upstream replacement for the combination of yum + yum-utils (Python
2 only) is dnf (Python 3).

The only reverse dependency of yum-utils is mock. It looks like the
version of mock already in Debian supports either dnf or yum. Once dnf
is in Debian, mock can drop the dependency on yum and yum-utils, and
yum-utils can be removed.

-- 
mike

Bug#939516: dpkg: debian/rules 'configure' rule does not always recreate configure file

[Sven Joachim]

Control: notfound -1 1.20.0
Control: found -1 1.19.7

On 2019-09-05 14:46 -0400, Dan Streetman wrote:

> Package: dpkg
> Version: 1.20.0

That version does not exist in Debian.

> Severity: normal
>
> Dear Maintainer,
>
> The debian/rules file has a manual rule for the 'configure' file, but this
> results in the 'configure' file not always being recreated.
>
> For example:
> $ head -1 debian/changelog
> dpkg (1.20.0) UNRELEASED; urgency=medium
> $ echo hello > configure
> $ chmod 755 configure
> $ dpkg-buildpackage
> ...
> ../configure: 1: hello: not found
>
> While that's a silly example, and unlikely to ever cause real issues for
> Debian since the Debian dpkg source doesn't carry the 'configure' file,
> the Ubuntu dpkg source *does* unfortunately carry the 'configure' file,
> and this caused a real regression:
> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1842947

The Debian dpkg source also includes the 'configure' file, only the git
repository does not have it.  That being said it would make sense to
always run autoreconf at package build time, I think that's considered
best practice these days.

Cheers,
   Sven

Bug#929612: sispmctl: support EG-PMS2 aka usb-id 04b4:fd15

[Frank Heckenbach]

Can confirm. Present version in buster doesn't work,
upstream 4.1 works out of the box.

Bug#938414: rrdtool: Python2 removal in sid/bullseye

[Jean-Michel Vourgère]

Control: tags -1 - pending
Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: python-rrdtool -- ROM; python2 removal

rrdtool no longer builds package python-rrdtool.

Please remove that binary package from the archive.

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

Bug#932637: nmu now in the delayed queue

[gregor herrmann]

On Mon, 22 Jul 2019 18:38:32 +0200, Matthias Klose wrote:

> the nmu is now in the delayed queue.

What happened to this NMU?
I just noticed that the bug ist still open and perl6-readline was
removed from testing …

Cheers,
gregor, interested bystander in perl6 causes

-- 
 .''`.  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
   `-   NP: Soundtrack: Goodnight And Thank You


signature.asc
Description: Digital Signature

Bug#939517: ITP: pkgtop -- Interactive package manager and resource monitor designed for the GNU/Linux.

[keylo99]

Package: wnpp
Severity: wishlist
Owner: keylo99 

* Package name: pkgtop
  Version : 1.8-1
  Upstream Author : k3
* URL : https://github.com/keylo99/pkgtop
* License : GPL-3.0
  Programming Lang: Go
  Description : Interactive package manager and resource monitor designed 
for the GNU/Linux.

 pkgtop
 .
 pkgtop is an interactive package manager & resource monitor tool designed
 for the GNU/Linux.
 .
 Package management (install/upgrade/remove etc.) can be a problem if the
 user is not familiar with the operating system or the required command for
 that operation. So pkgtop tries to solve this problem with an easy-to-use
 terminal interface and shortcut keys. Briefly, pkgtop aims to provide
 a terminal dashboard for managing packages on GNU/Linux systems. Using
 the terminal dashboard, it's possible to list installed packages by size
 (or alphabetically with -a argument), show information about the package,
 install/upgrade/remove packages and search package. Also, there are other
 handy shortcuts for easing the package management process which mentioned
 in the usage information (https://github.com/keylo99/pkgtop#usage).
 .
 License GNU General Public License v3. (see gpl
 (https://www.gnu.org/licenses/gpl.txt)) Credit Copyright (C) 2019 by
 keylo99 (https://www.github.com/keylo99)
 

Bug#939468: [Pkg-utopia-maintainers] Bug#939510: upower.service: Failed to set up user namespacing: Invalid argument

[Michael Biebl]

Control: forcemerge -1 939468

Am 05.09.19 um 19:48 schrieb Salvo Tomaselli:
> Package: upower
> Version: 0.99.11-1
> Severity: important
> Tags: patch
> 
> Dear Maintainer,
> 
> upon reboot I could not access my graphical session because upowerd was 
> failing
> to be started by systemd.
> 
> And apparently without it running sddm only shows garbage on screen.
> 
> set 05 19:04:52 serenity systemd[1]: Stopped Daemon for power management.
> set 05 19:04:52 serenity systemd[1]: Starting Daemon for power management...
> set 05 19:04:52 serenity systemd[950]: upower.service: Failed to set up user 
> namespacing: Invalid argument
> set 05 19:04:52 serenity systemd[950]: upower.service: Failed at step USER 
> spawning /usr/lib/upower/upowerd: Invalid argument
> set 05 19:04:52 serenity systemd[1]: upower.service: Main process exited, 
> code=exited, status=217/USER
> set 05 19:04:52 serenity systemd[1]: upower.service: Failed with result 
> 'exit-code'.
> set 05 19:04:52 serenity systemd[1]: Failed to start Daemon for power 
> management.
> set 05 19:04:53 serenity systemd[1]: upower.service: Service RestartSec=100ms 
> expired, scheduling restart.
> set 05 19:04:53 serenity systemd[1]: upower.service: Scheduled restart job, 
> restart counter is at 2.
> 
> I have a long list of those.
> 
> Commenting the user namespace directive solves the issue for me.
> 


Duplicate of #939468

You are both using a custom kernel.
If I had to guess, I'd say that's the culprit.


-- 
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#939516: dpkg: debian/rules 'configure' rule does not always recreate configure file

[Dan Streetman]

Package: dpkg
Version: 1.20.0
Severity: normal

Dear Maintainer,

The debian/rules file has a manual rule for the 'configure' file, but this
results in the 'configure' file not always being recreated.

For example:
$ head -1 debian/changelog 
dpkg (1.20.0) UNRELEASED; urgency=medium
$ echo hello > configure
$ chmod 755 configure
$ dpkg-buildpackage
...
../configure: 1: hello: not found

While that's a silly example, and unlikely to ever cause real issues for
Debian since the Debian dpkg source doesn't carry the 'configure' file,
the Ubuntu dpkg source *does* unfortunately carry the 'configure' file,
and this caused a real regression:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1842947

Bug#937063: moin: updating py2 removal status

[Steve McIntyre]

# Let's try that again...

user debian-pyt...@lists.debian.org
usertag 937063 + py2keep
thanks

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Arguing that you don't care about the right to privacy because you have
 nothing to hide is no different than saying you don't care about free
 speech because you have nothing to say."
   -- Edward Snowden

Bug#936025: closed by Ximin Luo (Bug#936025: fixed in rust-memoffset 0.5.1-1)

[Salvatore Bonaccorso]

Hey!

On Thu, Sep 05, 2019 at 06:57:09AM +, Debian Bug Tracking System wrote:
>  rust-memoffset (0.5.1-1) unstable; urgency=medium
>  .
>* Team upload.
>* Package memoffset 0.5.1 from crates.io using debcargo 2.4.0
>* Closes: #936025

When CVE fixes are known, please do as well include the CVE id
reference in changelog, that would help the security team work
immensly :)

Thank you for taking care of the update!

Regards,
Salvatore

Bug#939515: wayland-scanner.pc not found

[Helmut Grohne]

Source: libwayland-bin
Version: 1.17.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:weston

weston fails to cross build from source, because meson cannot find
wayland-scanner.pc. It requests wayland-scanner as a native dependency.
weston declares a build dependency on libwayland-dev. It thus receives
the host architecture libwayland-dev. libwayland-dev declares a
depenency on libwayland-bin, which happens to be Multi-Arch: foreign.
Thus it receives the build architecture libwayland-bin. Unfortunately,
wayland-scanner.pc, which describes the location of the wayland-scanner
binary, is shipped in libwayland-dev. So it is only available for the
host architecture, but required for the build architecture. Please move
it to libwayland-bin where the wayland-scanner executable lives.

Helmut
diff -u wayland-1.17.0/debian/changelog wayland-1.17.0/debian/changelog
--- wayland-1.17.0/debian/changelog
+++ wayland-1.17.0/debian/changelog
@@ -1,3 +1,10 @@
+wayland (1.17.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move wayland-scanner.pc to libwayland-bin. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 05 Sep 2019 20:29:13 +0200
+
 wayland (1.17.0-1) unstable; urgency=medium
 
   [ Timo Aaltonen ]
diff -u wayland-1.17.0/debian/control wayland-1.17.0/debian/control
--- wayland-1.17.0/debian/control
+++ wayland-1.17.0/debian/control
@@ -181,7 +181,8 @@
  ${shlibs:Depends},
  ${misc:Depends},
 Conflicts: libwayland-dev (<< 1.11.0-1)
-Replaces: libwayland-dev (<< 1.11.0-1)
+Breaks: libwayland-dev (<< 1.17.0-1.1)
+Replaces: libwayland-dev (<< 1.17.0-1.1)
 Multi-Arch: foreign
 Description: wayland compositor infrastructure - binary utilities
  Wayland is a protocol for a compositor to talk to its clients as well
diff -u wayland-1.17.0/debian/libwayland-bin.install 
wayland-1.17.0/debian/libwayland-bin.install
--- wayland-1.17.0/debian/libwayland-bin.install
+++ wayland-1.17.0/debian/libwayland-bin.install
@@ -4,0 +5 @@
+usr/lib/*/pkgconfig/wayland-scanner.pc
diff -u wayland-1.17.0/debian/libwayland-dev.install 
wayland-1.17.0/debian/libwayland-dev.install
--- wayland-1.17.0/debian/libwayland-dev.install
+++ wayland-1.17.0/debian/libwayland-dev.install
@@ -16,7 +16,6 @@
 usr/lib/*/pkgconfig/wayland-cursor.pc
 usr/lib/*/pkgconfig/wayland-egl.pc
 usr/lib/*/pkgconfig/wayland-server.pc
-usr/lib/*/pkgconfig/wayland-scanner.pc
 
 # Documentation
 usr/share/wayland/wayland.xml

Bug#764658: gdm3: cannot see all session choices on smaller screens

[Laurent Bonnaud]

Hi,

I reported this issue here:

  https://gitlab.gnome.org/GNOME/gdm/issues/513

-- 
Laurent.

Bug#939514: python2.7 FTCBFS: python not found

[Helmut Grohne]

Source: python2.7
Version: 2.7.16-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Version 2.7.16-4 dropped the build dependency on python:any. Now the
cross build fails finding a native python executable. We really need
this dependency for cross building. I suggest using "python2.7:any
" here as configure.ac specifically checks for python2.7.

Helmut
diff -u python2.7-2.7.16/debian/changelog python2.7-2.7.16/debian/changelog
--- python2.7-2.7.16/debian/changelog
+++ python2.7-2.7.16/debian/changelog
@@ -1,3 +1,10 @@
+python2.7 (2.7.16-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add back a dependency on python2.7:any. Closes: #-1.
+
+ -- Helmut Grohne   Thu, 05 Sep 2019 20:02:43 +0200
+
 python2.7 (2.7.16-4) unstable; urgency=medium
 
   * Update to 20190904 from the 2.7 branch.
diff -u python2.7-2.7.16/debian/control python2.7-2.7.16/debian/control
--- python2.7-2.7.16/debian/control
+++ python2.7-2.7.16/debian/control
@@ -15,7 +15,7 @@
   libgpm2 [linux-any],
   mime-support, netbase, net-tools, bzip2, time,
   libdb-dev (<< 1:6.0), libgdbm-dev, help2man,
-  xvfb , xauth 
+  xvfb , xauth , python2.7:any 
 Build-Depends-Indep: python3-sphinx
 Build-Conflicts: tcl8.4-dev, tk8.4-dev,
   python2.7-xml, python-xml,

Bug#938668: [Help] Bug#938668: tifffile: Python2 removal in sid/bullseye

[Scott Talbert]

On Thu, 5 Sep 2019, Andreas Tille wrote:


Control: tags -1 help

Hi,

for some reason I do not understand are the dependencies of the
binary package

Depends: python3-numpy (>= 1:1.16.0~rc1), python3-numpy-abi9, python3:any, 
python:any


How can I get rid of the python:any dependency?


Very good question.  The only thing I can see is debian/tests/control has 
Depends: python, but I don't see how that should end up in the binary 
package's Depends.


Scott

Bug#935329: RFP: git-revise -- handy git tool for doing efficient in-memory commit rebases & fixups

[Antoine Beaupré]

On 2019-09-05 18:38:09, Nicolas Schier wrote:
> Dear Antoine,
>
>> > Antoine, could you create a repository in salsa's 'debian' 
>> > namespace?
>> > (My salsa account is 'nsc-guest').
>> 
>> Done: https://salsa.debian.org/debian/git-revise
>
> thanks for your fast reaction!
> Right now, I do not have any permissions than to create merge requests 
> for debian/git-revise.

Really? You seem to have created one here:

https://salsa.debian.org/debian/git-revise/merge_requests/1

I merged it after review.

> I'd like to have the CI stuff enabled (with 'debian/gitlab.yml'
> instead of '.gitlab.yml'), that the usual test suites can also run on
> the new official repo.  Can you please enable that (or give me the
> permissions for doing that)?

I added you as a developer.

>> > Would you be available as a sponsor (as soon as I have got rid of all
>> > lintian issues)?
>> 
>> Sure!
>
> great!  I uploaded the package to mentors:
>
>   https://mentors.debian.net/package/git-revise
>
> (same state as in the Pull-Request).
>
> Could you have a look at it?
> (I am not sure, if I did the doc-base stuff correctly...)

Could you hook up the test suite in autopkgtest somehow?

The docbase stuff is usually in HTML, and to make it work you'd need to
build it with the Sphinx package, I think. It would be better to split
that out in a separate -doc package.

Why did you mark the FHS patch as not needing forward? It would seem
like a useful contribution for upstream...

All this can be done in a future incantation though.

The stuff on mentors still has an empty postrm script, so it looks like
it's not exactly the same state as the merge request...

python-git-revise-doc.docs refers to two non-existent files, so that
should definitely be fixed. It would be strange to have README.source
shipped, btw. And README.Debian doesn't need to be in the -doc package.

For the (build-)depends, you might want to split lines on commas to make
future diffs smaller. You can also build-dep on debhelper-compat to pin
an exact version, which also removes the need for the extra
debian/compat file.

Did you audit or review the upstream source?

Thanks!

A.

-- 
I've got to design so you can put it together out of garbage cans. In
part because that's what I started from, but mostly because I don’t
trust the industrial structure—they might decide to suppress us
weirdos and try to deny us the parts we need.
   - Lee Felsenstein

Bug#939513: saytime FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: saytime
Version: 1.0-31
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

saytime fails to cross build from source, because it uses the build
architecture compiler as a make default in debian/rules. Please consider
fixing this using dpkg's buildtools.mk.

Helmut
diff --minimal -Nru saytime-1.0/debian/changelog saytime-1.0/debian/changelog
--- saytime-1.0/debian/changelog2019-09-04 13:19:27.0 +0200
+++ saytime-1.0/debian/changelog2019-09-05 19:48:46.0 +0200
@@ -1,3 +1,10 @@
+saytime (1.0-31.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply $(CC). (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 05 Sep 2019 19:48:46 +0200
+
 saytime (1.0-31) unstable; urgency=medium
 
   * Bump standards version to 4.4.0, no changes needed.
diff --minimal -Nru saytime-1.0/debian/rules saytime-1.0/debian/rules
--- saytime-1.0/debian/rules2019-09-04 13:19:22.0 +0200
+++ saytime-1.0/debian/rules2019-09-05 19:48:44.0 +0200
@@ -5,6 +5,8 @@
 ##
 ## Released under the terms of the GNU GPLv2.
 
+-include /usr/share/dpkg/buildtools.mk
+
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 

Bug#939512: libfastahack FTCBFS: confuses build and host

[Helmut Grohne]

Source: libfastahack
Version: 1.0.0+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libfastahack fails to cross build from source, because debian/rules
confuses the terms "build" and "host". Please refer to man
dpkg-architecture for their definition. Please consider applying the
attached patch to make libfastahack cross buildable.

Helmut
diff --minimal -Nru libfastahack-1.0.0+dfsg/debian/changelog 
libfastahack-1.0.0+dfsg/debian/changelog
--- libfastahack-1.0.0+dfsg/debian/changelog2019-09-04 08:37:29.0 
+0200
+++ libfastahack-1.0.0+dfsg/debian/changelog2019-09-05 19:57:53.0 
+0200
@@ -1,3 +1,10 @@
+libfastahack (1.0.0+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Fix build/host confusion. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 05 Sep 2019 19:57:53 +0200
+
 libfastahack (1.0.0+dfsg-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru libfastahack-1.0.0+dfsg/debian/rules 
libfastahack-1.0.0+dfsg/debian/rules
--- libfastahack-1.0.0+dfsg/debian/rules2019-09-04 08:37:29.0 
+0200
+++ libfastahack-1.0.0+dfsg/debian/rules2019-09-05 19:57:51.0 
+0200
@@ -18,16 +18,16 @@
debian/tmp/usr/lib/*/*.so
 
 override_dh_makeshlibs:
-ifeq ($(DEB_BUILD_ARCH),$(filter $(DEB_BUILD_ARCH), amd64 arm64 mips64el 
ppc64el ia64 kfreebsd-amd64 risc64 sparc64))
-   echo "On architecture $(DEB_BUILD_ARCH) symbols file is provided"
+ifeq ($(DEB_HOST_ARCH),$(filter $(DEB_HOST_ARCH), amd64 arm64 mips64el ppc64el 
ia64 kfreebsd-amd64 risc64 sparc64))
+   echo "On architecture $(DEB_HOST_ARCH) symbols file is provided"
 else
-   echo "Symbols file for architecture $(DEB_BUILD_ARCH) is not provided"
+   echo "Symbols file for architecture $(DEB_HOST_ARCH) is not provided"
mkdir -p debian/hidesymbols
mv debian/*.symbols debian/hidesymbols
 endif
dh_makeshlibs
-ifeq ($(DEB_BUILD_ARCH),$(filter $(DEB_BUILD_ARCH), amd64 arm64 mips64el 
ppc64el ia64 kfreebsd-amd64 risc64 sparc64))
-   echo "dh_makeshlibs for architecture $(DEB_BUILD_ARCH) including 
symbols done"
+ifeq ($(DEB_HOST_ARCH),$(filter $(DEB_HOST_ARCH), amd64 arm64 mips64el ppc64el 
ia64 kfreebsd-amd64 risc64 sparc64))
+   echo "dh_makeshlibs for architecture $(DEB_HOST_ARCH) including symbols 
done"
 else
# restore original debian/ dir to enable building twice in a row
mv debian/hidesymbols/*.symbols debian

Bug#939511: /usr/bin/tifffile doesn't work

[Andrey Rahmatullin]

Package: tifffile
Version: 20181128-1+b1
Severity: grave

$ tifffile
Traceback (most recent call last):
  File "/usr/bin/tifffile", line 4, in 
import tifffile
ImportError: No module named tifffile

The package ships a Python 3 module with a Python 2 wrapper script.



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

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

Versions of packages tifffile depends on:
ii  python  2.7.16-1
ii  python3 3.7.3-1
ii  python3-numpy [python3-numpy-abi9]  1:1.16.2-1+b1

Versions of packages tifffile recommends:
pn  python3-matplotlib  

tifffile suggests no packages.

-- no debconf information

Bug#934974: u-boot: usb start fails on sheevaplug in u-boot 2019.01

[Jan Hahne]

Am 05.09.2019 um 18:20 schrieb Vagrant Cascadian:

On 2019-09-04, Martin Michlmayr wrote:

* Jan Hahne  [2019-08-17 16:27]:

But the command "usb start" gave me these errors:
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008c80
  ERROR: NOT USB_CONFIG_DESC 8f
2 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found


You mention USB problems.  We just got a report that said that
MMC and TFTP (network) didn't work either:
https://lists.debian.org/debian-arm/2019/09/msg2.html

Did you try those?  If so, I assume those failed for you as well?


Yes, I also tried TFTP and MMC.
Same behaviour as described by Florian: TFTP and MMC fail.

@Florian:
I don't think that your SheevaPlug is bricked.
I was able to unbrick mine with these instructions:
https://www.newit.co.uk/forum/index.php/topic,2835.0.html
https://tadeubento.com/2018/sheevaplug-2018-unbrick/

Then I followed the instructions by Martin Michlmayr
http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/
to install an older U-Boot Version (2016.11).
The timestamp of this U-Boot-binary was 2018/11/07.
I downloaded it from an older version of Martin's page.

I just saw that Martin already has updated his page so you can
download an older working U-Boot from there - Thanks a lot, Martin!

@Florian: Good look with the unbricking procedure.
It is a bit cumbersome but worked for me.

Greetings to all of you
Jan



Really unfortunate to hear that it's not working in a stable released
version... Thanks for the report.


There are no records of successful u-boot tests on sheevaplug on the
status page:

   https://wiki.debian.org/U-boot/Status

So I have no idea how long any of these features have been broken. I
don't have either the hardware or time to test every "supported" board
in Debian's u-boot packages.

Any chance people could also test the 2019.07 packages in experimental?
I can also try to prepare some 2019.10~rc+ packages which I hope to
upload soon.  Thanks for helping test!


live well,
   vagrant

Bug#939510: upower.service: Failed to set up user namespacing: Invalid argument

[Salvo Tomaselli]

Package: upower
Version: 0.99.11-1
Severity: important
Tags: patch

Dear Maintainer,

upon reboot I could not access my graphical session because upowerd was failing
to be started by systemd.

And apparently without it running sddm only shows garbage on screen.

set 05 19:04:52 serenity systemd[1]: Stopped Daemon for power management.
set 05 19:04:52 serenity systemd[1]: Starting Daemon for power management...
set 05 19:04:52 serenity systemd[950]: upower.service: Failed to set up user 
namespacing: Invalid argument
set 05 19:04:52 serenity systemd[950]: upower.service: Failed at step USER 
spawning /usr/lib/upower/upowerd: Invalid argument
set 05 19:04:52 serenity systemd[1]: upower.service: Main process exited, 
code=exited, status=217/USER
set 05 19:04:52 serenity systemd[1]: upower.service: Failed with result 
'exit-code'.
set 05 19:04:52 serenity systemd[1]: Failed to start Daemon for power 
management.
set 05 19:04:53 serenity systemd[1]: upower.service: Service RestartSec=100ms 
expired, scheduling restart.
set 05 19:04:53 serenity systemd[1]: upower.service: Scheduled restart job, 
restart counter is at 2.

I have a long list of those.

Commenting the user namespace directive solves the issue for me.

Best

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

Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages upower depends on:
ii  dbus   1.12.16-1
ii  libc6  2.28-10
ii  libglib2.0-0   2.60.6-2
ii  libgudev-1.0-0 232-2
ii  libimobiledevice6  1.2.1~git20181030.92c5462-1
ii  libplist3  2.0.1~git20190104.3f96731-1
ii  libupower-glib30.99.11-1
ii  libusb-1.0-0   2:1.0.23-1
ii  udev   242-7

Versions of packages upower recommends:
ii  policykit-1  0.105-26

upower suggests no packages.

-- no debconf information
48c48
< PrivateUsers=yes
---
> #PrivateUsers=yes

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Mark Hindley]

Julien,

On Tue, Sep 03, 2019 at 09:03:42PM +0100, Mark Hindley wrote:
> Control: severity 934491 serious
> 
> On Tue, Sep 03, 2019 at 09:34:51PM +0200, Julien Cristau wrote:
> > Anyway, I guess if #934491 is upgraded to RC then I can drop the block
> > hint.

#934491 is now RC, would you please remove your block hint for elogind.

Thank you.

Mark

Bug#939310: missing systray icon for blueman-applet

[Tom Marble]

On Thursday, September 5, 2019, Christopher Schramm 
wrote:

> Peter, In 2.1 you have to provide --loglevel debug to get a useful output.
>
> Tom, awesomewm with KDE as well?
>

No. i3

Glad to help debug.

--Tom

Bug#939424: O: inspircd -- Modular IRCd written in C++

[Christoph Biedl]

Control: retitle 939424 RFA: inspircd -- Modular IRCd written in C++

> The package description is:
>  InspIRCd is a modular C++ IRC Daemon for several operating systems created
>  to provide a stable, modern, lightweight irc server from scratch and provide
>  a vast number of features in a modularised form using an advanced module API.
>  By keeping the functionality of the main core to a minimum, the server is 
> very
>  stable, fast and customizable.
>  .
>  This package contains the daemon.

Well in fact, in the past two years all uploads for inspircd were done
by yours truly, and you'd also find my name in the uploaders list. Right
now, there are some bugs open that shouldn't be too difficult to handle.

So instead of letting this fall into limbo, I'll better keep it his way,
doing maintenance uploads until some caring hands will show up.

The usual stuff: Maintaining a package requires time and efforts, yada
yada ... Also, any future maintainer should have good knowledge of IRC
and inspircd as well. It's a fairly powerful IRC daemon and I have to
admit I barely touched its surface.

If you think you can handle the task of maintaining this package, get in
touch. I might be willing to sponsor the first uploads if needed.

Cheers,

Christoph


signature.asc
Description: PGP signature

Bug#939509: RFS: lablie/0.6.1-1 -- CLI tool for printable labels generation from SVG templates

[Miroslav Kravec]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: lablie
   Version : 0.6.1-1
 * URL : https://gitlab.com/kravemir/lablie
 * License : Apache-2.0
 * Vcs : https://salsa.debian.org/debian/lablie
   Section : utils

It builds those binary packages:

  lablie - CLI tool for printable labels generation from SVG templates

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/lablie/lablie_0.6.1-1.dsc

Changes since the last upload:

   * New upstream release
   * debian/compat: bump to 12
   * debian/control: update standards to 4.4.0, require debhelper >= 12
   * debian/lablie.poms: Adjust versions in JAR filenames in debian/lablie.poms
   * debian/patches: adjust debian patches for new release

Additionally, changes are pushed to:

  * https://salsa.debian.org/debian/lablie (except package release commit)
  * https://salsa.debian.org/kravemir-guest/lablie (including release commit)

Kind regards,
Miroslav Kravec

Bug#929694: cme update dpkg-copyright removes manually added copyright entries

[Dominique Dumont]

On Fri, 31 May 2019 23:04:58 +0500 Pirate Praveen  
wrote:
> > First problem: LICENSE and README.md do not contain the same copyright
> > owners. By reading the README.md file, I saw that make-iterator is
> > derived from moutjs. Hence debian/copyright entry is accurate.
> > 
> > But how can cme decide if the discrepancy is due to upstream change or
> > upstream inconsistencies ? It cannot.
> > 
> Don't remove anything if cme is not sure. When more than one notice is 
> there, add both, I think that is safer. In this case both notices are 
> still present.

ok, I've found a way to implement this without messing up other packages.

In next release, the information coming from LICENSE and README file is merged 
in the directory entry (make_iterator/*)

All the best.

Dod

Bug#939508: scdaemon: scdaemon does not share access with pcscd used by opensc

[Grizzard, Robert]

Package: scdaemon
Version: 2.2.17-3~bpo10+2
Severity: wishlist
Tags: newcomer patch upstream

Greetings,

I am attempting to use both the gpg and PIV functionaity of a Yubikey 5 
device, but scdaemon takes exclusive access.  This is the intended behavior 
according to the upstream maintainers [1].  A relevant upstream thread is [2], 
specifically the message [3].  

The desired functionality of shared access can be achieved by applying the 
patch used by the GPGTools project [4] (current commit as of this writing was 
5ca182f54b7b6cd635d1c0a4713953834489fdd9), though that patch does not list the 
license in place.

It is worth noting that application of the patch does not immediately override 
the exclusive access behavior of scdaemon, but instead the user must edit 
scdaemon.conf to include the line "shared-access" [5].  I have verified that 
building the debian package, with the patch installed within the debian/
patches/ directory, allows the desired shared access behavior of scdaemon 
after editing scdaemon.conf.

[1] https://dev.gnupg.org/T3267
[2] https://lists.gnupg.org/pipermail/gnupg-devel/2015-August/030242.html
[3] https://lists.gnupg.org/pipermail/gnupg-devel/2015-September/030264.html
[4] https://github.com/GPGTools/MacGPG2/blob/dev/patches/gnupg/
scdaemon_shared-access.patch
[5] https://wiki.archlinux.org/index.php/GnuPG#Shared_access_with_pcscd

Many thanks,
Robert Grizzard

-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'unstable'), 
(10, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages scdaemon depends on:
ii  gpg-agent  2.2.17-3~bpo10+2
ii  libassuan0 2.5.2-1
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libgpg-error0  1.35-1
ii  libksba8   1.3.5-2
ii  libnpth0   1.6-1
ii  libusb-1.0-0   2:1.0.22-2

scdaemon recommends no packages.e

scdaemon suggests no packages.

-- no debconf information

Bug#882159: thomas, your recent order 215833 Tf

[thomas hudson]

jhudson...@gmail.com

On Mon, 27 Nov 2017 at 21:16, Amazon FinalNotice  wrote:

> Notice for thomas
>
>
> 
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hello, Joachim Wiedorn schrob: > Hello Jan, FYI: >  original message
>  > From: e...@users.sourceforge.net > Date: Sun, 26 Nov 2017 21:55:28
> +0100 > To: Joachim Wiedorn , cont...@bugs.debian.org, >
> 882...@bugs.debian.org > > can the reporter maybe test the current
> snapshot? it should fix the issue. >
> http://duply.net/wiki/index.php/Duply-code#Latest_Development_Snapshot
> The "2.0.4dev" version I downloaded just now from
> http://duply.net/tmp/duply.sh works for me, outputs times like | ---
> Finished state OK at 19:34:48.724 - Runtime 00:00:00.075 --- and takes the
> "date_fix %s%N" branch (verified via debug printf). The diff looks good to
> me as well. Thanks a lot for the quick fix! I noticed two unrelated minor
> oddities: 1) On the first run (per profile) with the new version, duply
> would re-sync all the metadata. That's because of the bugfix for #117,
> which moved the metadata location from "$ARCH_DIR/duply_$profile" to
> "$ARCH_DIR/$profile". That leaves around the old, now-useless metadata
> folder. Not a big deal, but maybe it would have been better to adjust the
> comment to match the code instead of the other way around? 2) In line 2172,
> | # for sec�rity reasons, we url_encode username to protect special chars
> there's some (for me undisplayable) unicode (%EF%BF%BD) instead of the 'u'
> in "security". Funny, given the context. :D HTH and thanks again, Jan

Bug#939504: dgit-maint-{merge,debrebase}(7): Use git fetch --all --tags

[Ian Jackson]

Sean Whitton writes ("Bug#939504: dgit-maint-{merge,debrebase}(7): Use git 
fetch --all --tags"):
> `git remote update` doesn't fetch tags unless remote branches include
> the commits at which those tags point.  Thus, if upstream pushes their
> release tag but fails to push their master branch, `git remote update`
> will not fetch the release tag.
> 
> I've been in this situation more than once when following the
> workflows detailed in these manpages, so let's just recommend a
> command which will definitely try to fetch the latest release tag.

This patch LGTM and I have put it on my own branch and will push it in
due course.

But, now that we are not using
  git remote update
which scans all remotes (and can therefore be slow or annoying or
may need extra config) why not suggest
  git fetch --tags upstream
?  That's not much more typing than --all.

If you like this idea please send another patch.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#939507: prometheus-postgres-exporter: please consider shipping queries.yaml

[Michael Banck]

Package: prometheus-postgres-exporter
Version: 0.5.1+ds-1
Severity: wishlist

Dear Maintainer,

while the internal metrics are useful, the queries.yaml file shipped in
the source (and usable via the --extend.query-path option) are quite
useful as well. Not sure they should be enabled by default, but shipping
them somewhere (/usr/share/prometheus-postgres-exporter/queries.yaml?)
would be nice.


Michael

Bug#939310: missing systray icon for blueman-applet

[Christopher Schramm]

Peter, In 2.1 you have to provide --loglevel debug to get a useful output.

Tom, awesomewm with KDE as well?

Bug#935329: RFP: git-revise -- handy git tool for doing efficient in-memory commit rebases & fixups

[Nicolas Schier]

Dear Antoine,

> > Antoine, could you create a repository in salsa's 'debian' 
> > namespace?
> > (My salsa account is 'nsc-guest').
> 
> Done: https://salsa.debian.org/debian/git-revise

thanks for your fast reaction!
Right now, I do not have any permissions than to create merge requests 
for debian/git-revise.  I'd like to have the CI stuff enabled (with 
'debian/gitlab.yml' instead of '.gitlab.yml'), that the usual test 
suites can also run on the new official repo.  Can you please enable 
that (or give me the permissions for doing that)?

> > Would you be available as a sponsor (as soon as I have got rid of all
> > lintian issues)?
> 
> Sure!

great!  I uploaded the package to mentors:

https://mentors.debian.net/package/git-revise

(same state as in the Pull-Request).

Could you have a look at it?
(I am not sure, if I did the doc-base stuff correctly...)

Thanks and kind regards,
Nicolas

-- 
epost: nico...@fjasle.eu   irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --


signature.asc
Description: PGP signature

Bug#938414: rrdtool python2 removal

[Jean-Michel Vourgère]

Hi Andreas

On Wednesday, 4 September 2019 22:00:54 CEST Andreas Henriksson wrote:
> Control: tags -1 + pending

Thanks. I should have done that earlier! I hope you did not loose too much 
time because of that. :/

> I noticed two things you might want to adress though:
> - the dh-python build-dependency was removed. This package contains the
>   dh_python3 helper which the package still seems to be using, so
>   removing this build-dependency was likely a mistake.

python3-all-dbg and python3-all-dev both depends on dh-python, so this is no 
big deal.
But it looks cleaner to explicitly require it, thanks.

> - The debian/changelog should be changed from "(See: #938414)" to
>   "(Closes: #938414)" so that this bug report gets closed automatically
>   when the fixed package is uploaded.

That's on purpose.
See https://wiki.debian.org/Python/2Removal

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

Bug#939506: unanimity ftbfs in unstable

[Matthias Klose]

Package: src:unanimity
Version: 3.3.0+dfsg-2.1
Severity: serious
Tags: sid buster

unanimity ftbfs in unstable:

cd /build/1st/unanimity-3.3.0+dfsg/build/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/gcpp.dir/link.txt --verbose=1
/build/1st/unanimity-3.3.0+dfsg/src/main/ccs.cpp: In function ‘int Runner(const 
PacBio::CLI::Results&)’:
/build/1st/unanimity-3.3.0+dfsg/src/main/ccs.cpp:570:38: error: ‘move’ was not 
declared in this scope
  570 | read.Sequence(), move(ipd), move(pw), 
read.LocalContextFlags(),

  |  ^~~~

Bug#875243: [yagf] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Hi Boris!

On Thu, 5 Sep 2019 at 13:17, Boris Pek  wrote:
>
> Hi,
>
> > similar ping as for qpxtool, last upstream commits are from 2015. Are you
> > planning to port it yourself or should it be removed?
>
> Patch for yagf port to Qt5 already exists at least in Mageia GNU/Linux distro.
>
> I may backport this patch to yagf 0.9.3.2 or update yagf package to latest
> release 0.9.5 and prepare patches with fixes for some regressions in this
> version of program. (I have not decided yet.)
>
> Do you have any time schedule for Qt4 removal? At least preliminary.

As soon as possible. There is already an RC bug in qt4-x11 to avoid
shipping it in bullseye and, at the the current bug fixing rate, it is
going to be dropped from testing soon, and it will not return there.
Once that happens we will be asking for removals even more
aggressively.

You can also push yagf with the Qt 5 patch to experimental, in that
way the qt4-based version can be removed from unstable and you will
not have to pass trough NEW once you consider it ready for unstable.

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#912338: ITP: createrepo-c -- tool to create RPM repository metadata (C implementation)

[Mike Miller]

On Tue, Oct 30, 2018 at 16:40:18 +0200, Peter Pentchev wrote:
> I intend to package this tool since it seems to be the preferred
> alternative to the already packaged createrepo Python tool (and many
> thanks to Mike Miller for maintaining that package!) in at least
> the Fedora RPM packaging community.  Thus it might be useful for people
> maintaining their own repositories of RPM-packaged software; there is
> no reason not to be able to do that on a Debian system :)

Hey Peter,

How is your work on this package going? Do you need any help? I am
interested in seeing this completed so that createrepo can be cleanly
removed from the archive.

-- 
mike

Bug#934974: u-boot: usb start fails on sheevaplug in u-boot 2019.01

[Vagrant Cascadian]

On 2019-09-04, Martin Michlmayr wrote:
> * Jan Hahne  [2019-08-17 16:27]:
>> But the command "usb start" gave me these errors:
>> EHCI timed out on TD - token=0x80008d80
>> EHCI timed out on TD - token=0x80008c80
>>  ERROR: NOT USB_CONFIG_DESC 8f
>> 2 USB Device(s) found
>>   scanning usb for storage devices... 0 Storage Device(s) found
>
> You mention USB problems.  We just got a report that said that
> MMC and TFTP (network) didn't work either:
> https://lists.debian.org/debian-arm/2019/09/msg2.html
>
> Did you try those?  If so, I assume those failed for you as well?

Really unfortunate to hear that it's not working in a stable released
version... Thanks for the report.


There are no records of successful u-boot tests on sheevaplug on the
status page:

  https://wiki.debian.org/U-boot/Status

So I have no idea how long any of these features have been broken. I
don't have either the hardware or time to test every "supported" board
in Debian's u-boot packages.

Any chance people could also test the 2019.07 packages in experimental?
I can also try to prepare some 2019.10~rc+ packages which I hope to
upload soon.  Thanks for helping test!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#935443: [PATCH] dgit-maint-bpo(7): Mention occasional need for --new

[Ian Jackson]

Ian Jackson writes ("[PATCH] dgit-maint-bpo(7): Mention occasional need for 
--new"):
> Closes: #935443
> Signed-off-by: Ian Jackson 

Rereading the bug description I thought a 2nd patch was needed.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#935443: [PATCH] dgit-maint-bpo(7): Mention occasional need for --new

[Ian Jackson]

Closes: #935443
Signed-off-by: Ian Jackson 
---
 dgit-maint-bpo.7.pod | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/dgit-maint-bpo.7.pod b/dgit-maint-bpo.7.pod
index e977d258..e776a478 100644
--- a/dgit-maint-bpo.7.pod
+++ b/dgit-maint-bpo.7.pod
@@ -47,6 +47,12 @@ If you use a merging backports workflow, your changelog 
contains
 entries for each previous upload to B; in a rebasing
 workflow, it contains only the latest.
 
+=head1 GENERAL TIPS
+
+The first time a package is backported
+for any particular Debian release,
+you will have to pass the --new option to dgit.
+
 =head1 CHOOSING BETWEEN THE TWO WORKFLOWS
 
 If backporting involves making no (additional) changes to the upstream
@@ -59,8 +65,6 @@ work on machines running Debian stable, it is advisable to 
choose a
 rebasing workflow.  This ensures that dgit can automatically update
 the debian/patches directory without any manual intervention.
 
-=head1 TIPS FOR A MERGING WORKFLOW
-
 =head2 Use dgit's branches
 
 If you do not yourself upload the package to Debian unstable, it is
-- 
2.11.0

Bug#875701: mockchain should depend on createrepo-c

[Mike Miller]

Control: block -1 with 912338

On Mon, Dec 03, 2018 at 17:24:38 +0100, Pierre-Francois CARPENTIER wrote:
> It adds createrepo as a dependency. It also adds python3-requests which is
> also missing.

Note that createrepo is now facing removal from the archive because of
the Python 2 removal effort. It is essentially replaced upstream by
createrepo_c. A far better fix here would be to depend on createrepo-c
after it is packaged.

-- 
mike

Bug#875243: [yagf] Future Qt4 removal from Buster

[Boris Pek]

Hi,

> similar ping as for qpxtool, last upstream commits are from 2015. Are you
> planning to port it yourself or should it be removed?

Patch for yagf port to Qt5 already exists at least in Mageia GNU/Linux distro.

I may backport this patch to yagf 0.9.3.2 or update yagf package to latest
release 0.9.5 and prepare patches with fixes for some regressions in this
version of program. (I have not decided yet.)

Do you have any time schedule for Qt4 removal? At least preliminary.

Best wishes,
Boris

Bug#939504: dgit-maint-{merge,debrebase}(7): Use git fetch --all --tags

[Sean Whitton]

Package: dgit
Version: 9.7
Severity: minor
Tags: patch

Hello,

`git remote update` doesn't fetch tags unless remote branches include
the commits at which those tags point.  Thus, if upstream pushes their
release tag but fails to push their master branch, `git remote update`
will not fetch the release tag.

I've been in this situation more than once when following the
workflows detailed in these manpages, so let's just recommend a
command which will definitely try to fetch the latest release tag.

-- 
Sean Whitton
From 4fa12df4ef3b966a09e36932e76652c6ff0fa7f5 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Thu, 5 Sep 2019 09:08:48 -0700
Subject: [PATCH] dgit-maint-{merge,debrebase}(7): Use git fetch --all --tags

`git remote update` doesn't fetch tags unless remote branches include
the commits at which those tags point.  Thus, if upstream pushes their
release tag but fails to push their master branch, `git remote update`
will not fetch the release tag.

I've been in this situation more than once when following the
workflows detailed in these manpages, so let's just recommend a
command which will definitely try to fetch the latest release tag.

Signed-off-by: Sean Whitton 
---
 dgit-maint-debrebase.7.pod | 2 +-
 dgit-maint-merge.7.pod | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index 9c9598bb..27c97aa3 100644
--- a/dgit-maint-debrebase.7.pod
+++ b/dgit-maint-debrebase.7.pod
@@ -353,7 +353,7 @@ release, and importing that release using git-debrebase(1).
 
 =over 4
 
-% git remote update
+% git fetch --all --tags
 
 =back
 
diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index 0ccd8c7e..37a02613 100644
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -362,7 +362,7 @@ to git), you can just run dpkg-buildpackage(1) or debuild(1) instead.
 
 =over 4
 
-% git remote update
+% git fetch --all --tags
 
 =back
 
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#936531: flowblade: Python2 removal in sid/bullseye

[Gürkan Myczko]

We're waiting for upstream:

https://github.com/jliljebl/flowblade/issues/597

Bug#939428: O: sslh -- Applicative protocol multiplexer

[Don Armstrong]

Control: retitle -1 ITA: sslh -- Applicative protocol multiplexer
Control: owner -1 !

On Wed, 04 Sep 2019, g...@iroqwa.org wrote:
> I intend to orphan the sslh package.

Unless someone else wants to maintain this package, I will adopt it, as
I use it.

-- 
Don Armstrong  https://www.donarmstrong.com

[T]he question of whether Machines Can Think, [...] is about as
relevant as the question of whether Submarines Can Swim.
 -- Edsger W. Dijkstra "The threats to computing science"

Bug#937770: Not to be ported

[thomas . goirand]

This package is a port of Py3 stuff to Py2, so it doesn't need to be ported to 
Py3.
The only thing we need to do, is get rid of the reverse dependencies, then this
package can be removed from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#939503: yakuake: Focus lost when editing tab name

[Philipp Hagemeister]

Package: yakuake
Version: 19.08.0-1
Severity: normal

Dear Maintainer,

since the update to yakuake 19.08, when I rename a tab, the focus is lost.

Steps to reproduce:
1. Open Yakuake. Observe: typing inserts characters into the shell.
2. Press the shortcut to rename a tab. By default, that is Ctrl+Alt+S. I mapped 
it to Shift+F2, and reproduced the problem with either setting. Double-clicking 
the tab name works as well.
3. Press Enter to submit the new tab name (this is sufficient to demonstrate. 
In a realistic example, one likely wants to actually change the name.)
4. Type a character, e.g. x
Expected (and previous) behavior: the character got typed into the shell.
Current behavior: The focus is on some other element; typing does nothing.

Workaround: Press Shift+Tab after renaming.
Alternative workaround: Click into the terminal window after renaming.
This is not a good experience, especially if you rename your tabs quite often, 
as I do.

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

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

Versions of packages yakuake depends on:
ii  kio5.54.1-1
ii  konsole-kpart  4:19.08.0-1
ii  libc6  2.28-10
ii  libkf5archive5 5.54.0-1
ii  libkf5configcore5  5.54.0-2
ii  libkf5configgui5   5.54.0-2
ii  libkf5configwidgets5   5.54.0-1
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5crash5   5.54.0-1
ii  libkf5dbusaddons5  5.54.0-1
ii  libkf5globalaccel-bin  5.54.0-1
ii  libkf5globalaccel5 5.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5iconthemes5  5.54.0-1
ii  libkf5kiocore5 5.54.1-1
ii  libkf5newstuff55.54.0-2
ii  libkf5newstuffcore55.54.0-2
ii  libkf5notifications5   5.54.0-1
ii  libkf5notifyconfig55.54.0-1
ii  libkf5parts5   5.54.0-1
ii  libkf5service-bin  5.54.0-1
ii  libkf5service5 5.54.0-1
ii  libkf5waylandclient5   4:5.54.0-1
ii  libkf5widgetsaddons5   5.54.0-1
ii  libkf5windowsystem55.54.0-1
ii  libkf5xmlgui5  5.54.0-1
ii  libqt5core5a   5.11.3+dfsg1-4
ii  libqt5dbus55.11.3+dfsg1-4
ii  libqt5gui5 5.11.3+dfsg1-4
ii  libqt5widgets5 5.11.3+dfsg1-4
ii  libqt5x11extras5   5.11.3-2
ii  libstdc++6 9.2.1-6
ii  libx11-6   2:1.6.7-1

yakuake recommends no packages.

yakuake suggests no packages.

-- no debconf information

Bug#939501: ITP: r-cran-fastcluster -- Fast Hierarchical Clustering Routines for R and 'Python'

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-fastcluster -- Fast Hierarchical Clustering Routines for R 
and 'Python'
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-fastcluster
  Version : 1.1.25
  Upstream Author : Copyright: 
* URL : https://cran.r-project.org/package=fastcluster
* License : BSD-like
  Programming Lang: GNU R
  Description : Fast Hierarchical Clustering Routines for R and 'Python'
 This is a two-in-one package which provides interfaces to
 both R and 'Python'. It implements fast hierarchical, agglomerative
 clustering routines. Part of the functionality is designed as drop-in
 replacement for existing routines: linkage() in the 'SciPy' package
 'scipy.cluster.hierarchy', hclust() in R's 'stats' package, and the
 'flashClust' package. It provides the same functionality with the
 benefit of a much faster implementation. Moreover, there are
 memory-saving routines for clustering of vector data, which go beyond
 what the existing packages provide. For information on how to install
 the 'Python' files, see the file INSTALL in the source distribution.
 Based on the present package, Christoph Dalitz also wrote a pure 'C++'
 interface to 'fastcluster':
 .

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-fastcluster

Bug#939502: haskell-attoparsec-enumerator: Removal notice: unused Haskell library

[Ilias Tsitsimpis]

Source: haskell-attoparsec-enumerator
Severity: serious

This Haskell library is not part of Buster, has no reverse dependencies,
is not on Stackage and is already ignored on our package-plan.

I intend to remove this package. If there is a good reason to keep it,
please close the bug.

-- 
Ilias

Bug#938944: [Pkg-utopia-maintainers] Bug#938944: network-manager: Python2 removal in sid/bullseye

[Michael Biebl]

Control: block -1 by 939500

On Sat, 31 Aug 2019 11:48:58 +0200 Andreas Henriksson 
wrote:
> Control: forwarded -1 
> https://salsa.debian.org/utopia-team/network-manager/merge_requests/3
> 
> On Fri, Aug 30, 2019 at 10:42:11PM +0200, Michael Biebl wrote:
> > Thanks a lot for your work on this.
> > Can you post the build log somewhere?
> > A MR with your changes would be awesome as well.
> 
> I noticed the newer gtk-doc-tools (using python3) is available in
> experimental. Different error using that one (no test problems, yay!).
> 
> I've posted the WIP as a merge request. All details posted as comments
> on it.
> 
> Help with figuring out the gtk-doc-tools error welcome/needed!

The gtk-doc-tools issue has been fixed by upstream
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/261

Now I'm waiting for gtk-doc-tools 1.32 to enter unstable.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#935890: Rename "dgit push-source" to "dgit push"

[Ian Jackson]

Sean Whitton writes ("Bug#935890: Rename "dgit push-source" to "dgit push""):
> You didn't write much :)  Is the thought that `dgit push-source` is
> analogous with `git push` and so should occupy the name `dgit push`?

And it is more primary, in the sense that users probably want
push-source rather than push-built.

> On Thu 05 Sep 2019 at 09:46AM +01, Ian Jackson wrote:
> > Is this worth the disruption ?
> 
> If what I just wrote is the only reason for doing this, then I'm not
> convinced that it is.

Fair enough.  Maybe we should close this bug then.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#939500: Please upload 1.32 to unstable

[Michael Biebl]

Package: gtk-doc-tools
Version: 1.28-1
Severity: wishlist

Hi,

it would be great if gtk-doc-tools could be updated to 1.32 in unstable.

This is mostly a bug so I can monitor the progress
and mark it blocking
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938944



Regards,
Michael



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

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

Versions of packages gtk-doc-tools depends on:
ii  docbook-to-man  1:2.0.0-42+b1
ii  docbook-xml 4.5-9
ii  docbook-xsl 1.79.1+dfsg-2
ii  highlight   3.41-2+b1
ii  pkg-config  0.29-6
ii  python  2.7.16-1
ii  python-mock 3.0.5-1
ii  python-six  1.12.0-2
ii  xsltproc1.1.32-2.1

gtk-doc-tools recommends no packages.

Versions of packages gtk-doc-tools suggests:
pn  dblatex  

-- no debconf information

Bug#939436: [Pkg-javascript-devel] Bug#939436: node-js-beautify: does not start: 'config-chain' not found

[Xavier]

Control: tags -1 + moreinfo

Le 05/09/2019 à 00:00, Johannes Deutsch a écrit :
> Package: node-js-beautify
> Version: 1.7.5+repack-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> after installing css-beautify refuses to run with the following error:
> 
> 
> internal/modules/cjs/loader.js:670
> throw err;
> ^
> 
> Error: Cannot find module 'config-chain'
> at Function.Module._resolveFilename 
> (internal/modules/cjs/loader.js:668:15)
> at Function.Module._load (internal/modules/cjs/loader.js:591:27)
> at Module.require (internal/modules/cjs/loader.js:723:19)
> at require (internal/modules/cjs/helpers.js:14:16)
> at Object. (/usr/share/nodejs/js-beautify/js/lib/cli.js:40:10)
> at Module._compile (internal/modules/cjs/loader.js:816:30)
> at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
> at Module.load (internal/modules/cjs/loader.js:685:32)
> at Function.Module._load (internal/modules/cjs/loader.js:620:12)
> at Module.require (internal/modules/cjs/loader.js:723:19)
> 
> However 'config-chain' is also installed on the system.

Hi,

I'm not able to reproduce this issue. I'm going to add a autopkgtest
file to checks the 3 binaries usage

Bug#938927: #938927: patch available

[merkys]

control: tags -1 + patch

Hello,

Please find attached a patch to build libthrift-java.

Best wishes,
Andrius

diff --git a/debian/control b/debian/control
index deae009..2232a77 100644
--- a/debian/control
+++ b/debian/control
@@ -16,8 +16,9 @@ Build-Depends: debhelper (>= 9), dh-python,
  golang-go, golang-github-golang-mock-dev,
  pkg-php-tools (>= 1.14~), php-dev, phpunit,
  perl (>= 5.22), libbit-vector-perl, libclass-accessor-perl,
-# openjdk-11-jdk, javahelper, maven-debian-helper (>= 1.5), ant (>= 1.7), ant-optional,
-# libhttpclient-java, libslf4j-java, libservlet3.1-java (>= 8),
+ openjdk-11-jdk, javahelper, maven-debian-helper (>= 1.5), ant (>= 1.7), ant-optional,
+ libhttpclient-java, libslf4j-java, libservlet3.1-java (>= 8),
+ junit4, libgeronimo-annotation-1.3-spec-java, libmockito-java,
 # nodejs, npm,
  ruby-dev (>= 1:2.2), ruby, bundler,
  rake,
@@ -148,20 +149,20 @@ Description: Python library for Thrift (debug symbols)
  .
  This package contains the debugging symbols for Python 3 bindings of Thrift.
 
-#Package: libthrift-java
-#Section: java
-#Architecture: all
-#Depends: ${java:Depends}, ${misc:Depends}
-#Conflicts: libthrift-java (<= 0.9.1-2)
-#Replaces: libthrift-java (<= 0.9.1-2)
-#Description: Java language support for Thrift
-# Thrift is a software framework for the development of reliable and
-# performant communication and data serialization. It combines a software
-# stack with code generation to build services that operate seamlessly
-# across a number of different development languages.
-# .
-# This package provides the Java language support for Thrift.
-#
+Package: libthrift-java
+Section: java
+Architecture: all
+Depends: ${java:Depends}, ${misc:Depends}
+Conflicts: libthrift-java (<= 0.9.1-2)
+Replaces: libthrift-java (<= 0.9.1-2)
+Description: Java language support for Thrift
+ Thrift is a software framework for the development of reliable and
+ performant communication and data serialization. It combines a software
+ stack with code generation to build services that operate seamlessly
+ across a number of different development languages.
+ .
+ This package provides the Java language support for Thrift.
+
 #Package: libthrift-java-doc
 #Architecture: all
 #Section: doc
diff --git a/debian/patches/java_fix.patch b/debian/patches/java_fix.patch
new file mode 100644
index 000..8fd8edd
--- /dev/null
+++ b/debian/patches/java_fix.patch
@@ -0,0 +1,43 @@
+Description: Downloading of remote content has to be replaced with
+ artifacts alread in Debian. Source and target 1.6 are needed to build.
+Author: Andrius Merkys 
+--- a/lib/java/build.xml
 b/lib/java/build.xml
+@@ -70,6 +70,13 @@
+ 
+   
+ 
++
++  
++
++
++  
++
++
+   
+ 
+   
+@@ -78,11 +85,13 @@
+ 
+ 
+ 
++
++
+ 
+   
+ 
+   
+-  
++  
+ 
+   
+ 
+@@ -95,7 +104,7 @@
+   
+ 
+   
+-
+   
+ 
diff --git a/debian/patches/no_json_tests.patch b/debian/patches/no_json_tests.patch
new file mode 100644
index 000..d97628a
--- /dev/null
+++ b/debian/patches/no_json_tests.patch
@@ -0,0 +1,15 @@
+Description: With --with-java, json tests are turned on automatically.
+ As JSON schema validator for Java is not yet packaged, these tests all
+ fail.
+Author: Andrius Merkys 
+--- a/lib/json/test/build.xml
 b/lib/json/test/build.xml
+@@ -80,7 +80,7 @@
+   
+ 
+   
++  />
+ 
+   
+ 

Bug#935890: Rename "dgit push-source" to "dgit push"

[Sean Whitton]

Hello,

On Thu 05 Sep 2019 at 09:46AM +01, Ian Jackson wrote:

>> Probably.  Let's advertise new names and make `dgit push' print a
>> warning, for now.
>
> I was about to implement this and so I reread this bug.  Now I'm
> having second thoughts.  Sean, do you actually agree with what I write
> earlier in this bug ?

You didn't write much :)  Is the thought that `dgit push-source` is
analogous with `git push` and so should occupy the name `dgit push`?

> Is this worth the disruption ?

If what I just wrote is the only reason for doing this, then I'm not
convinced that it is.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#939499: mate-tweak: Panel configuration produces TypeError due to dock absence

[Paul Boddie]

Package: mate-tweak
Version: 16.10.5-1+deb9u1
Severity: normal
Tags: patch

Dear Maintainer,

Running mate-tweak and attempting panel configuration, selecting different
icon sizes, repeatably causes a TypeError in the program. This does not crash
the user interface, however.

  File "/usr/bin/mate-tweak", line 912, in combo_fallback
self.additional_tweaks(schema, key, value[1])
  File "/usr/bin/mate-tweak", line 904, in additional_tweaks
self.replace_panel_layout(self.base_layout)
  File "/usr/bin/mate-tweak", line 748, in replace_panel_layout
self.disable_dock()
  File "/usr/bin/mate-tweak", line 497, in disable_dock
self.remove_dock_autostart()
  File "/usr/bin/mate-tweak", line 461, in remove_dock_autostart
if os.path.exists(os.path.join(config_dir, 'autostart/') + self.dock + 
'.desktop'):
TypeError: Can't convert 'NoneType' object to str implicitly

The problem is caused by an absence of any recognised dock, thus self.dock
being None, and thus the error occurs. As far as I can tell, a simple fix that
short-circuits the test is sufficient, and I can provide a trivial patch for
this purpose.

Sorry if this is already fixed, either upstream or in another version of the
package. I was investigating mate-tweak to see if I could get panel icons to
appear since they appear as dark blue rectangles for me, but that is another
problem.

Regards,

Paul

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: mipsel (mips)

Kernel: Linux 3.18.3 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mate-tweak depends on:
ii  compton0.1~beta2+20150922-1
ii  dconf-cli  0.26.0-2+b1
ii  gir1.2-gtk-3.0 3.22.11-1
ii  gir1.2-notify-0.7  0.7.7-2
ii  mate-desktop-common1.16.2-2
ii  mesa-utils 8.3.0-3
ii  python-gobject-2   2.28.6-13
ii  python33.5.3-1
ii  python3-gi 3.22.0-2
ii  python3-pkg-resources  33.1.1-1
ii  python3-psutil 5.0.1-1
ii  python3-setproctitle   1.1.10-1
ii  x11-xserver-utils  7.7+7+b1
ii  zenity 3.22.0-1+b1

Versions of packages mate-tweak recommends:
ii  mate-indicator-applet  1.16.0-1

Versions of packages mate-tweak suggests:
pn  indicator-application  
pn  indicator-messages 
pn  indicator-sounds   
pn  metacity   
pn  xcompmgr   

-- no debconf information
--- /usr/bin/mate-tweak 2019-09-05 16:48:59.009918490 +0200
+++ /usr/bin/mate-tweak 2019-09-05 16:44:31.597711379 +0200
@@ -458,7 +458,7 @@
 # Old versions of MATE Tweak setup an autostart, these should
 # be removed.
 config_dir = GLib.get_user_config_dir()
-if os.path.exists(os.path.join(config_dir, 'autostart/') + self.dock + 
'.desktop'):
+if self.dock and os.path.exists(os.path.join(config_dir, 'autostart/') 
+ self.dock + '.desktop'):
 os.remove(os.path.join(config_dir, 'autostart/') + self.dock + 
'.desktop')
 
 def enable_hud(self):

Bug#939498: systemd warns about use of /var/run in rpc-statd.service

[Sergio Gelato]

Package: nfs-common
Version: 1:1.3.4-2.5
Severity: minor

After upgrading to buster, systemd issues the following warning:

systemd[1]: /lib/systemd/system/rpc-statd.service:13: PIDFile= references path 
below legacy directory /var/run/, updating /var/run/rpc.statd.pid → 
/run/rpc.statd.pid; please update the unit file accordingly.

Bug#794495: Mock fails to track installed packages

[Michal Čihař]

Hello

Sorry, I didn't read your long email. I just want to point out that rpm
package is available for adoption, see https://bugs.debian.org/923352

-- 
Michal Čihař | https://cihar.com/ | https://weblate.org/


Mihai Moldovan píše v Čt 05. 09. 2019 v 15:55 +0200:
> Hi Michal
> 
> 
> I don't want to be condescending, but can we please, pretty-please
> stop breaking
> rpm in Debian?
> 
> I understand that rpm is not intended to be used as a package manager
> on Debian
> systems, but the rpmdb-in-homedir patch does more harm than good,
> causing
> trouble in totally legitimate use cases as described in this bug
> report.
> 
> Users should be educated and preferably not even try to install RPM
> packages in
> the first place, but putting the rpmdb into a user's home directory
> won't really
> do any good.
> 
> Users wanting to use the rpm package within Debian to install rpm
> packages could
> either just edit the global macro file and reset _dbpath to
> /var/lib/rpm, create
> /var/lib/rpm and symlinks from ~/.rpmdb to that location or do even
> weirder things.
> 
> The point is that even with this patch, rpm won't be unusable in the
> way you'd
> like to make it, even if that requires very minor tweaking.
> 
> 
> However, without tinkering, it breaks other software like mock or
> libsolv's RPM
> backend. One could argue about the latter's use(fulness) on Debian,
> but breaking
> mock is breaking a legitimate use case in which the rpm package
> really NEEDS to
> install software correctly.
> 
> mock is some piece of software for building RPM packages (source or
> binaries) in
> a chroot - quite like sbuild for Debian packages. I do use it a lot,
> but this
> patch breaks mock in a very subtle way.
> 
> Looong explanation coming up: mock creates a new chroot and then uses
> an RPM
> package manager (for instance yum, but potentially also dnf) to
> install a base
> set of packages in there. Again, pretty much like debootstrap. For
> that to work,
> the package manager is executed with the --installroot parameter,
> which
> instructs it to essentially carry out all operations in the chroot -
> including
> using the rpmdb in there. mock also sets HOME to /builddir, hence the
> rpmdb will
> be created in /chroot/builddir/.rpmdb. Everything's fine until then,
> but then
> mock fully deletes the home directory (within the chroot, of course)
> and
> recreates it from scratch/skel. Boom, the rpmdb went bust.
> 
> This wasn't a huge problem per se, since in the worst case the
> package manager
> would just install more packages than necessary when installing a
> source RPM's
> build dependencies. Recently, however, rpm and dnf got support for
> rich
> dependencies, which are also heavily used by Fedora at least (and
> likely will be
> used by RHEL 8 as well). Such "rich dependencies" can be used to pull
> in
> optional dependencies if a different package is already installed,
> for instance,
> to automatically enhance functionality - notably, the "different
> package" need
> not be any any direct or indirect dependency at all.
> 
> A real-world breaking example (with dnf, since yum doesn't support
> rich
> dependencies, but I have dnf packages for Debian and would like to
> introduce
> them at some point):
> 
> redhat-rpm-config has a dependency such as this:
> Requires: (annobin if gcc)
> 
> This will pull in "annobin" as a dependency of redhat-rpm-config if
> the "gcc"
> package is installed, but redhat-rpm-config does not depend upon
> "gcc".
> 
> What now happens is breakage: gcc is part of the base package set, so
> is
> installed when creating the chroot. Since the rpmdb goes bust, the
> package
> manager won't know it's installed and when a build-dependency
> (indirectly) pulls
> in redhat-rpm-config, which is NOT part of base, it won't pull in
> annobin.
> 
> This then leads to build failures, since the annobin plugin is being
> used
> unconditionally at build time. If it's not installed, builds fail.
> 
> 
> Such breakage is subtle, and it's likely not the only thing to go
> haywire with
> the patched rpm binaries.
> 
> Yes, I COULD go ahead and add .rpmdb to mock's config file option
> "exclude_from_homedir_cleanup", but that would likely create even
> more problems.
> Newer mock versions (currently not available in Debian, but I guess
> the mock
> package will be updated eventually) can bootstrap the build system
> using the
> system-provided package manager and then use the chroot-based package
> manager
> for installing build dependencies. With the system rpm library/binary
> patched to
> put the rpmdb in ${HOME}, but Fedoras/CentOS's not, we'd run into a
> very nice
> /builddir/.rpmdb vs. /var/lib/rpm dance yet again.
> 
> 
> Yet another argument: it makes other maintainer's lifes more
> difficult since
> software like yum, dnf or libsolv have to be specifically patched to
> even work.
> 
> 
> I can only re-iterate: Please consider dropping this patch.
> 
> 
> 
> Mihai
> 



signature.asc

Bug#939497: AttributeError: 'method' object has no attribute 'STRONGHOLD_IS_PUBLIC'

[James Valleroy]

Package: python3-django-stronghold
Version: 0.3.0+debian-2
Severity: important
Tags: upstream

Dear Maintainer,

While running FreedomBox on Debian unstable (in vagrant box, and
development mode), I installed the JSXC app and opened it. I got the
following django error page:


AttributeError at /apps/jsxc/jsxc/

'method' object has no attribute 'STRONGHOLD_IS_PUBLIC'


Environment:


Request Method: GET
Request URL: https://localhost:4430/plinth/apps/jsxc/jsxc/

Django Version: 2.2.5
Python Version: 3.7.4
Installed Applications:
['axes',
 'captcha',
 'bootstrapform',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.messages',
 'stronghold',
 'plinth',
 'plinth.modules.minetest',
 'plinth.modules.searx',
 'plinth.modules.ejabberd',
 'plinth.modules.syncthing',
 'plinth.modules.openvpn',
 'plinth.modules.shadowsocks',
 'plinth.modules.monkeysphere',
 'plinth.modules.ttrss',
 'plinth.modules.transmission',
 'plinth.modules.mldonkey',
 'plinth.modules.help',
 'plinth.modules.radicale',
 'plinth.modules.api',
 'plinth.modules.mumble',
 'plinth.modules.mediawiki',
 'plinth.modules.cockpit',
 'plinth.modules.matrixsynapse',
 'plinth.modules.diagnostics',
 'plinth.modules.firewall',
 'plinth.modules.tor',
 'plinth.modules.avahi',
 'plinth.modules.power',
 'plinth.modules.i2p',
 'plinth.modules.quassel',
 'plinth.modules.users',
 'plinth.modules.apache',
 'plinth.modules.sso',
 'plinth.modules.ssh',
 'plinth.modules.sharing',
 'plinth.modules.upgrades',
 'plinth.modules.dynamicdns',
 'plinth.modules.backups',
 'plinth.modules.storage',
 'plinth.modules.tahoe',
 'plinth.modules.snapshot',
 'plinth.modules.roundcube',
 'plinth.modules.config',
 'plinth.modules.ikiwiki',
 'plinth.modules.deluge',
 'plinth.modules.networks',
 'plinth.modules.names',
 'plinth.modules.first_boot',
 'plinth.modules.infinoted',
 'plinth.modules.datetime',
 'plinth.modules.pagekite',
 'plinth.modules.privoxy',
 'plinth.modules.security',
 'plinth.modules.jsxc',
 'plinth.modules.bind',
 'plinth.modules.letsencrypt']
Installed Middleware:
('django.middleware.security.SecurityMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.locale.LocaleMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 'stronghold.middleware.LoginRequiredMiddleware',
 'plinth.middleware.AdminRequiredMiddleware',
 'plinth.middleware.FirstSetupMiddleware',
 'plinth.modules.first_boot.middleware.FirstBootMiddleware',
 'plinth.middleware.SetupMiddleware')



Traceback:

File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner
  34. response = get_response(request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  115. response = self.process_exception_by_middleware(e, 
request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  113. response = wrapped_callback(request, *callback_args, 
**callback_kwargs)

File "/usr/lib/python3/dist-packages/django/views/generic/base.py" in view
  71. return self.dispatch(request, *args, **kwargs)

File "/usr/lib/python3/dist-packages/django/utils/decorators.py" in _wrapper
  44. bound_method = dec(bound_method)

File "/usr/lib/python3/dist-packages/stronghold/decorators.py" in public
  13. set_view_func_public(orig_func)

File "/usr/lib/python3/dist-packages/stronghold/utils.py" in 
set_view_func_public
  13. setattr(func, 'STRONGHOLD_IS_PUBLIC', True)

Exception Type: AttributeError at /apps/jsxc/jsxc/
Exception Value: 'method' object has no attribute 'STRONGHOLD_IS_PUBLIC'


Appears to be the same as the upstream issue for Django 2.1
compatibility, reported here:
https://github.com/mgrouchy/django-stronghold/issues/75


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

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

Versions of packages python3-django-stronghold depends on:
ii  python3 3.7.3-1
ii  python3-django  2:2.2.5-1

python3-django-stronghold recommends no packages.

python3-django-stronghold suggests no packages.

-- no debconf information