Bug#831104: xevil: diff for NMU version 2.02r2-10.1

2020-06-06 Thread Joao Eriberto Mota Filho
Control: tags 831104 + pending

Dear maintainer,

I've prepared an NMU for xevil (versioned as 2.02r2-10.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer or cancel the NMU.

Regards,

Eriberto

--- xevil-2.02r2/debian/changelog
+++ xevil-2.02r2/debian/changelog
@@ -1,3 +1,11 @@
+xevil (2.02r2-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixed FTBFS with GCC 6 and higher. Thanks to Javier Serrano
+Polo . (Closes: #831104)
+
+ -- Joao Eriberto Mota Filho   Sun, 07 Jun 2020 02:11:06 
-0300
+
 xevil (2.02r2-10) unstable; urgency=low
 
   * Fixed bug that sometimes prevented X resources from being read properly.
diff -u xevil-2.02r2/cmn/utils.h xevil-2.02r2/cmn/utils.h
--- xevil-2.02r2/cmn/utils.h
+++ xevil-2.02r2/cmn/utils.h
@@ -98,11 +98,11 @@
 #define MSEC_PER_CLOCK (1.0e3 / CLOCKS_PER_SEC) 
 #endif
 
-#ifndef max
-#define max(a,b)   (ab ? b : a)
+#ifndef MIN
+#define MIN(a,b)   (a>b ? b : a)
 #endif
 
 #if X11
diff -u xevil-2.02r2/cmn/game.cpp xevil-2.02r2/cmn/game.cpp
--- xevil-2.02r2/cmn/game.cpp
+++ xevil-2.02r2/cmn/game.cpp
@@ -577,7 +577,7 @@
   assert(maximums[weapons[n]->classId] == 0);
 
   // Don't allow objectWorldPercent values that are too small.
-  float objWPercent = (float)max(weapons[n]->objectWorldPercent,
+  float objWPercent = (float)MAX(weapons[n]->objectWorldPercent,
  OBJECT_WORLD_PERCENT_MIN);
 
   maximums[weapons[n]->classId] = (int)ceil(areaFactor * objWPercent);
@@ -590,7 +590,7 @@
 for (n = 0; n < oItemsNum; n++) {
   // Check not already set.
   assert(maximums[oItems[n]->classId] == 0);
-  float objWPercent = (float)max(oItems[n]->objectWorldPercent,
+  float objWPercent = (float)MAX(oItems[n]->objectWorldPercent,
  OBJECT_WORLD_PERCENT_MIN);
 
   maximums[oItems[n]->classId] = (int)ceil(areaFactor * objWPercent);
diff -u xevil-2.02r2/debian/changelog xevil-2.02r2/debian/changelog



Bug#962377: RFS: mirage/0.11.1-1 [RC] -- fast and simple GTK+ image viewer

2020-06-06 Thread Thomas Ross
Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: mirage
   Version : 0.11.1-1
   Upstream Author : https://gitlab.com/thomasross/mirage/
 * URL : https://gitlab.com/thomasross/mirage
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/thomasross/mirage
   Section : graphics

It builds this binary package:

  mirage - fast and simple GTK+ image viewer

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/m/mirage/mirage_0.11.1-1.dsc

Changes since the last upload:

   * New upstream release:
   - Upgrade to Python3 (Closes: #937052)
   - Upgrade to PyGObject (Closes: #885353)
   - Fix translation initialization (Closes: #612216)
   * debian/control:
   - Update my email address
   - Build-Depends:
   - Require debhelper-compat = 13
   - Replace python-dev with python3-all-dev
   - Remove cdbs, replaced with debhelper
   - Remove quilt, not needed
   - Remove python-gtk2-dev, no longer needed
   - Add dh-sequence-python3
   - Add libx11-dev
   - Add gettext
   - Add libglib2.0-dev
   - Depends:
   - Replace ${python:Depends} with ${python3:Depends}
   - Add python3-gi
   - Replace python-gtk2 with gir1.2-gtk-3.0, python3-cairo and
 python3-gi-cairo
   - Replace python-pyexiv2 with gir1.2-gexiv2-0.10
   - Don't suggest menu (Closes: #647375)
   - Update homepage for new upstream
   - Add Vcs-Browser and Vcs-Git fields
   - Add Rules-Requires-Root: no
   * debian/patches:
   - Remove halfSelected.patch, fixed upstream
   - Remove desktop_entry_issue.patch, fixed upstream
   - Remove remove_gimp_remote.patch, fixed upstream
   - Remove save-exif.patch, fixed upstream
   - Remove add-pixmap.patch, unused
   - Remove empty patches directory
   * debian/changelog:
   - Add Upstream-Contact field
   - Update for new release
   * Remove debian/compat, replaced with debhelper-compat build-dependency
   * Update to policy version 4.5.0
   * Update debian/watch for new upstream
   * Remove debian/menu, package provides a FreeDesktop menu entry
   * Remove debian/mirage.install, no longer used
   * Remove debian/mirage.xpm, no longer used
   * Remove post-install script, obsoleted by desktop-file-utils trigger

Thanks,
Thomas.



Bug#962376: ITP: ruby-console -- Beautiful logging for Ruby

2020-06-06 Thread Hideki Yamane
Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ruby-console
  Version : 1.8.2
  Upstream Author : Samuel Williams 
* URL : https://github.com/socketry/console
* License : MIT
  Programming Lang: Ruby
  Description : Beautiful logging for Ruby

 Provides beautiful console logging for Ruby applications. 
 Implements fast, buffered log output.

 For introduce fluentd, this package is necessary (fluentd->ruby-async-http
 ->ruby-async->ruby-console)



Bug#962375: ITP: ruby-http-2 -- Pure-ruby HTTP 2.0 protocol implementation

2020-06-06 Thread Hideki Yamane
Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ruby-http-2
  Version : 0.10
  Upstream Author : Ilya Grigorik 
* URL : https://github.com/igrigorik/http-2
* License : MIT
  Programming Lang: Ruby
  Description : Pure-ruby HTTP 2.0 protocol implementation

 Pure Ruby, framework and transport agnostic, implementation of HTTP/2 protocol
 and HPACK header compression with support for:
 .
  - Binary framing parsing and encoding
  - Stream multiplexing and prioritization
  - Connection and stream flow control
  - Header compression and server push
  - Connection and stream management
  - And more



Bug#962374: ITP: ruby-protocol-http -- providing abstractions to handle HTTP protocol

2020-06-06 Thread Hideki Yamane
Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ruby-protocol-http
  Version : 0.20.0
  Upstream Author : Samuel G. D. Williams 
* URL : https://github.com/socketry/protocol-http
* License : MIT
  Programming Lang: Ruby
  Description : providing abstractions to handle HTTP protocol

 Protocol::HTTP provides abstractions for working with the HTTP protocol.



Bug#798626: perl: -V lies about -Duseshrplib

2020-06-06 Thread Tom Lane
Hi folks,

I'd just like it to be on the record that this change broke the build
process for PostgreSQL.

The immediate symptom is that "perl -V:useshrplib" no longer reports
true, which causes our configure script to spit up, figuring that it is
not going to be able to find a shared-library libperl to link against.
We have determined after some experimentation that if we drop that
safety check then we will still get a valid build on Debian, but it's
fairly nervous-making that we will no longer be able to have that
sanity check for other platforms.  Also, from what I understand of
what you changed, it seems like there is a nontrivial risk that
"perl -MExtUtils::Embed -e ldopts" would report linker flags that
lead to linking in a static version of libperl.  That is likely
to fail outright on some hardware (depending on how the static
library was built); and if it doesn't fail, it will result in
libperl.a becoming embedded in the calling package, which I surely
hope is against your distribution policies.

So: you can stick with this, or not, but you are risking bad
consequences for Postgres and for other consumers of libperl.so.

You can find the Postgres mailing list discussion about this at

https://www.postgresql.org/message-id/flat/20200606222017.GA2564110%40rfd.leadboat.com

regards, tom lane



Bug#962373: ITP: picopore -- lossless compression of Nanopore files

2020-06-06 Thread Steffen Moeller
Package: wnpp
Severity: wishlist

Subject: ITP: picopore -- lossless compression of Nanopore files
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: picopore
  Version : 1.2.0
  Upstream Author : Copyright: Scott Gigante 
* URL : https://github.com/scottgigante/picopore
* License : GPL-3+
  Programming Lang: Python
  Description : lossless compression of Nanopore files
 The Nanopore is a device to determine the sequences of single moleculres
 of DNA. No amplification. The output is gigantic and tools like this
 one help to reduce it.
 .
 Over time, other means have substitute the need for this one. Upstream
 has halted development. Some tutorials and pipelines of the Nanopore still
 refer to it, though.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/picopore



Bug#962368: frogatto-data: Source-only upload not automatically built for non-free packages

2020-06-06 Thread Boyuan Yang
Hi Martin,

Martin Quinson  于2020年6月6日周六 下午7:11写道:
>
> Hello,
>
> thanks for pointing me to this, I didn't know. And even now, I'm not sure of 
> whether frogatto-data is auto-buildable. The reason why it's non-free is 
> because the licence file states: "The Frogatto game and all content is 
> available for download free of charge from http://www.frogatto.com. The game 
> may be redistributed for non-commercial purposes so long as the entire 
> package is kept in-tact and unmodified. This license must also be included 
> and kept in-tact. It is forbidden to distribute the game, or any portion 
> thereof for any commercial or revenue-generating purpose."
>
> Under this light, should I mark the package as auto-buildable? I tend to 
> think so but would appreciate your guidance.

I don't have a firm answer for this. Maybe you can write an email to
the buildd team (non-f...@buildd.debian.org or other email address)
for answer?

> In the meanwhile, I'll do a source+binary upload of the package.

This should fall back to the old behavior and not introduce new
problems. I have no idea if britney would influence testing migration
though (probably not since this is of non-free).

-- 
Thanks,
Boyuan Yang



Bug#928307: DHCPv6 client is not supposed to set the default route

2020-06-06 Thread Kenyon Ralph
This is correct behavior. The DHCPv6 client does not set the default
route. The default route will typically be set by the kernel when it
receives router advertisements, per the accept_ra sysctl:
https://sysctl-explorer.net/net/ipv6/accept_ra/

-- 
Kenyon Ralph


signature.asc
Description: PGP signature


Bug#962329: cegui-mk2: please mark one symbol as optional

2020-06-06 Thread Olek Wojnar
Hi Gianfranco,

On Sat, Jun 6, 2020 at 7:21 AM Gianfranco Costamagna <
locutusofb...@debian.org> wrote:

> Source: cegui-mk2
> Version: 0.8.7-7
> tags: patch
>
> Hello, there is one symbol disappearing when the package is built with -O3
> optimization level on ppc64el:
>

That looks like a very simple fix, thanks for the patch! I'll try to upload
that later today.

-Olek


Bug#961907: (no subject)

2020-06-06 Thread Axel Beckert
Hi David,

David Rosenstrauch wrote:
> Is this fix for the expired AddTrust cert likely to get backported to older
> versions of Debian?  (E.g., stretch, buster)

Already happened for Buster and Stretch: The packages are already
available in the "buster-proposed-updates" and
"stretch-proposed-updates", see e.g.
https://packages.qa.debian.org/c/ca-certificates.html

They will latest be published in the normal repos with the next minor
updates for the mentioned release (unless other severe bugs show up).

There's though a simple workaround to fix the issues caused with this
quickly:

Run "dpkg-reconfigure ca-certificates" (as root) and then unselect
"mozilla/AddTrust_External_Root.crt". (For all other potential
questions just press Enter to keep the previous values.)

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#962372: linux-image-5.7.0-rc5-amd64: Silead module not installed

2020-06-06 Thread Paul Cercueil
Package: linux-image-5.7.0-rc5-amd64
Severity: wishlist

Dear Maintainer,

The Silead module, present in the upstream kernel for a long time now, adds
support for the Silead touchscreen present notably on some Teclast tablets.

Right now, these tablets require a custom-built kernel just because this module
is absent.

Please consider adding it to the default config.



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

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

Versions of packages linux-image-5.7.0-rc5-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.137
ii  kmod27+20200310-2
ii  linux-base  4.6

Versions of packages linux-image-5.7.0-rc5-amd64 recommends:
ii  apparmor 2.13.4-1+b1
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.7.0-rc5-amd64 suggests:
pn  debian-kernel-handbook   
pn  grub-pc | grub-efi-amd64 | extlinux  
pn  linux-doc-5.7



Bug#962337: RFS: nfoview/1.28-1 -- simple viewer for NFO files

2020-06-06 Thread Adam Borowski
On Sat, Jun 06, 2020 at 02:56:57PM +0200, JCF Ploemen wrote:
>  * Package name: nfoview
>Version : 1.28-1

> Changes since the last upload:
> 
>[ Debian Janitor ]
>* Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
>  Repository-Browse.
>  .
>[ JCF Ploemen (jcfp) ]
>* New upstream release.
>* Control:
>  + replace xfonts-terminus with fonts-cascadia-code, upstream
>changed the default font.
>  + bump compat level to 13 (from 12).
>* Install: remove entry for nfoview.xpm, replaced by new upstream svg
>  application icons.
>* Bump Standards-Version to 4.5.0 (from 4.4.0; no further changes).
>* Copyright: bump years.

= test session starts ==
platform linux -- Python 3.8.3, pytest-4.6.10, py-1.8.1, pluggy-0.13.0
rootdir: /tmp/autopkgtest.Fkyu2m/autopkgtest_tmp
collected 46 items

nfoview/test/test_about.py . [  2%]
nfoview/test/test_config.py  [ 10%]
nfoview/test/test_export.py 
(pytest-3:128560): dconf-CRITICAL **: 23:36:00.767: unable to create directory 
'/home/kilobyte/.cache/dconf': Permission denied.  dconf will not work properly.
.[ 13%]
nfoview/test/test_open.py .  [ 15%]
nfoview/test/test_preferences.py [ 32%]
nfoview/test/test_util.py .  [ 78%]
nfoview/test/test_view.py    [ 86%]
nfoview/test/test_window.py ..   [100%]

=== warnings summary ===
nfoview/test/test_window.py::TestWindow::test_open_file__blank_lines
  /usr/share/nfoview/nfoview/window.py:252: DeprecationWarning: 
Gdk.Screen.width is deprecated
size[0] = min(size[0], int(0.8 * Gdk.Screen.width()))

nfoview/test/test_window.py::TestWindow::test_open_file__blank_lines
  /usr/share/nfoview/nfoview/window.py:253: DeprecationWarning: 
Gdk.Screen.height is deprecated
size[1] = min(size[1], int(0.8 * Gdk.Screen.height()))

-- Docs: https://docs.pytest.org/en/latest/warnings.html
 46 passed, 2 warnings in 0.41 seconds =

(pytest-3:128560): dconf-CRITICAL **: 23:36:00.990: unable to create directory 
'/home/kilobyte/.cache/dconf': Permission denied.  dconf will not work properly.

(pytest-3:128560): dconf-CRITICAL **: 23:36:00.990: unable to create directory 
'/home/kilobyte/.cache/dconf': Permission denied.  dconf will not work properly.

(pytest-3:128560): dconf-CRITICAL **: 23:36:00.995: unable to create directory 
'/home/kilobyte/.cache/dconf': Permission denied.  dconf will not work properly.

(pytest-3:128560): dconf-CRITICAL **: 23:36:00.996: unable to create directory 
'/home/kilobyte/.cache/dconf': Permission denied.  dconf will not work properly.
autopkgtest [01:36:01]: test upstream-pytest: ---]
autopkgtest [01:36:01]: test upstream-pytest:  - - - - - - - - - - results - - 
- - - - - - - -
upstream-pytest  FAIL stderr: 
autopkgtest [01:36:01]: test upstream-pytest:  - - - - - - - - - - stderr - - - 
- - - - - - -

(pytest-3:128560): dconf-CRITICAL **: 23:36:00.767: unable to create directory 
'/home/kilobyte/.cache/dconf': Permission denied.  dconf will not work properly.

(pytest-3:128560): dconf-CRITICAL **: 23:36:00.990: unable to create directory 
'/home/kilobyte/.cache/dconf': Permission denied.  dconf will not work properly.

(pytest-3:128560): dconf-CRITICAL **: 23:36:00.990: unable to create directory 
'/home/kilobyte/.cache/dconf': Permission denied.  dconf will not work properly.

(pytest-3:128560): dconf-CRITICAL **: 23:36:00.995: unable to create directory 
'/home/kilobyte/.cache/dconf': Permission denied.  dconf will not work properly.

(pytest-3:128560): dconf-CRITICAL **: 23:36:00.996: unable to create directory 
'/home/kilobyte/.cache/dconf': Permission denied.  dconf will not work properly.
autopkgtest [01:36:01]:  summary
import-private-module PASS (superficial)
upstream-pytest  FAIL stderr: 

E: Autopkgtest run failed.


Neither package build nor test is allowed to write to $HOME.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄



Bug#921815: debootstrap umount "host" /proc when running in a Docker container

2020-06-06 Thread Kristian Klausen

control: tags -1 -moreinfo

Hi
Sorry for the late response. I wasn't subscribed to the bug (I assume?).

On 23.02.2020 14.01, Hideki Yamane wrote:

When running debootstrap inside a Docker container, debootstrap umount both 
/proc and $TARGET/proc.

  How do I check it?

  - run docker
  - get debootstrap 1.0.110 and install it
  - debootstrap sid sid
  - /proc is there inside docker as below


Did you use a privileged container? /proc can't be unmounted in a 
regular non-privileged container.


I just tried and "/proc" is unmounted:
$ docker run --privileged --rm -t -i debian:stretch-backports bash
$ apt-get update && apt-get install -y -t stretch-backports debootstrap
$ debootstrap stretch chroot
$ ls /proc # it is empty

I also tried the debootstrap version in sid:
$ docker run --privileged --rm -t -i debian:sid bash
$ apt-get update && apt-get install -y debootstrap
$ debootstrap sid chroot
$ ls /proc # it is empty

Also please see the MRs:
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/26
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/27
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/30

I'm not sure which approach is the best, but Eicke did a short analysis:
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/26#note_171042


root@b49ab8b7f3eb:~# ls /proc/
1  crypto   iomemkpageflagspartitions   sysrq-trigger
19486  devices  ioports  loadavg   pressure sysvipc
acpi   diskstatsirq  locks sched_debug  thread-self
asound dma  kallsyms meminfo   schedstattimer_list
buddyinfo  driver   kcoremisc  self tty
busexecdomains  key-usersmodules   slabinfo uptime
cgroupsfb   keys mountssoftirqs version
cmdlinefilesystems  kmsg mtrr  stat vmallocinfo
consoles   fs   kpagecgroup  net   swapsvmstat
cpuinfointerrupts   kpagecount   pagetypeinfo  sys  zoneinfo


---

- Kristian Klausen



Bug#962368: frogatto-data: Source-only upload not automatically built for non-free packages

2020-06-06 Thread Martin Quinson
Hello,

thanks for pointing me to this, I didn't know. And even now, I'm not sure of 
whether frogatto-data is auto-buildable. The reason why it's non-free is 
because the licence file states: "The Frogatto game and all content is 
available for download free of charge from http://www.frogatto.com. The game 
may be redistributed for non-commercial purposes so long as the entire package 
is kept in-tact and unmodified. This license must also be included and kept 
in-tact. It is forbidden to distribute the game, or any portion thereof for any 
commercial or revenue-generating purpose."

Under this light, should I mark the package as auto-buildable? I tend to think 
so but would appreciate your guidance.

In the meanwhile, I'll do a source+binary upload of the package.

Thanks again,
Mt.

- Le 7 Juin 20, à 0:05, Boyuan Yang by...@debian.org a écrit :

> Source: frogatto-data
> Severity: serious
> Version: 1.3.1+dfsg-2
> X-Debbugs-CC: mquin...@debian.org
> 
> Dear Debian frogatto-data maintainers,
> 
> Thanks for updating package frogatto-data in Debian. However, you just
> made a source-only upload against a non-free package, which would cause
> problems.
> 
> By default, Debian's buildd will not build non-free packages due to
> licensing concerns. If your package has no licensing concerns, please
> follow instructions as written in the Developers Reference [1] to mark
> the package as auto-buildable. If not, please make a binary-only upload
> (or a source+binary upload) to actually make sure that the deb package
> exists in the archive.
> 
> --
> Regards,
> Boyuan Yang
> 
> [1]
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable



Bug#937378: purity-ng: Python2 removal in sid/bullseye

2020-06-06 Thread Moritz Mühlenhoff
On Fri, Aug 30, 2019 at 07:32:38AM +, Matthias Klose wrote:
> Package: src:purity-ng
> Version: 0.2.0-2.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

Hi Luke/Simon,
the last commits for purity-ng are from 2011, are you still interested
in this? Let's remove?

Cheers,
Moritz



Bug#961907: (no subject)

2020-06-06 Thread David Rosenstrauch
Is this fix for the expired AddTrust cert likely to get backported to 
older versions of Debian?  (E.g., stretch, buster)




Bug#961795: ITP: eclipse-cdt -- C/C++ Development Tools for Eclipse

2020-06-06 Thread Sudip Mukherjee
On Fri, May 29, 2020 at 12:06:33PM +0100, Sudip Mukherjee wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sudip Mukherjee 
> Control: block 943552 by -1
> 
> * Package name: eclipse-cdt
>   Version : 9.11.0

Correction:
The version needed is 9.9.0

>   Upstream Author : many
> * URL : https://www.eclipse.org/cdt/
> * License : EPL-2.0
>   Programming Lang: Java
>   Description : C/C++ Development Tools for Eclipse
> 

> 
> This is a re-introduction of the package and I will only intend to build
> org.eclipse.cdt.core.* and org.eclipse.cdt.utils.* as I will need them
> for #943552.

org.eclipse.cdt.core and org.eclipse.cdt.core.native is needed and only
those two will be built for now.

--
Regards
Sudip



Bug#962371: RM: python-fcgi -- RoQA; Python 2, dead upstream, no reverse deps

2020-06-06 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove python-fcgi. It's dead upstream, depends on Python 2 and
there are no reverse deps.

Cheers,
Moritz



Bug#937749: python-fcgi: Python2 removal in sid/bullseye

2020-06-06 Thread Moritz Mühlenhoff
On Fri, Apr 24, 2020 at 11:12:26PM +0200, Moritz Mühlenhoff wrote:
> On Fri, Aug 30, 2019 at 07:39:14AM +, Matthias Klose wrote:
> > Package: src:python-fcgi
> > Version: 19980130-1
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> > 
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> > 
> > Your package either build-depends, depends on Python2, or uses Python2
> > in the autopkg tests.  Please stop using Python2, and fix this issue
> > by one of the following actions.
> 
> python-fcgi seems dead upstream and there are no reverse deps. Are you
> planning to port it to Python 3 or should it be removed?

Filed a removal bug now.

Cheers,
Moritz



Bug#962370: RM: python-pysqlite2 -- RoQA; Obsolete Py2 package

2020-06-06 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove python-pysqlite2. It's obsolete with Python 3 (sqlite3
module from the standard lib). There's one remaining reverse dependency
(mysql-workbench), but please force the removal: mysql-workbench is
already affected by a bunch of other uninstallable dependencies (#953138)

Cheers,
Moritz



Bug#962369: ocserv: Please consider packaging new upstream release (1.0.1)

2020-06-06 Thread Boyuan Yang
Source: ocserv
Version: 0.12.6-1
X-Debbugs-CC: mtmil...@debian.org

Dear Debian ocserv maintainers,

The ocserv upstream seems to have released the 1.0.x versions of
ocserv. The latest release is ocserv 1.0.1, tagged back in 2020-04-09.

Please consider packaging the new release. Thanks!

-- 
Regards,
Boyuan Yang


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


Bug#962207: manaplus-data: depends on dummy transitional package ttf-dejavu-core

2020-06-06 Thread Boyuan Yang
X-Debbugs-CC: pmatth...@debian.org
Control: severity -1 grave
Control: tags -1 +patch

Dear Debian manaplus maintainer,

Having a package to depend on a removed package will render the package
uninstallable. The bug severity is thus raised to grave.

The attached patch in the previous email looks okay. As you can see in 
https://codesearch.debian.net/search?q=package%3Amanaplus+ttf-dejavu ,
both debian/control file as well as debian/manaplus-data.links file
will need to be fixed.

-- 
Regards,
Boyuan Yang

On Thu, 04 Jun 2020 16:30:07 +0200 Olivier Tilloy <
olivier.til...@canonical.com> wrote:
> Package: manaplus-data
> Version: 1.9.3.23-4
> Severity: normal
> 
> Dear Maintainer,
> 
> manaplus-data depends on dummy transitional package ttf-dejavu-core,
which was removed in fonts-dejavu 2.37-2 (#872809).
> The dependency name should be updated to fonts-dejavu-core.


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


Bug#962368: frogatto-data: Source-only upload not automatically built for non-free packages

2020-06-06 Thread Boyuan Yang
Source: frogatto-data
Severity: serious
Version: 1.3.1+dfsg-2
X-Debbugs-CC: mquin...@debian.org

Dear Debian frogatto-data maintainers,

Thanks for updating package frogatto-data in Debian. However, you just
made a source-only upload against a non-free package, which would cause
problems.

By default, Debian's buildd will not build non-free packages due to
licensing concerns. If your package has no licensing concerns, please
follow instructions as written in the Developers Reference [1] to mark
the package as auto-buildable. If not, please make a binary-only upload
(or a source+binary upload) to actually make sure that the deb package
exists in the archive.

-- 
Regards,
Boyuan Yang

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable


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


Bug#427521: closed by Niko Tyni (Re: Bug#427521: perlfaq4.1.gz: mention commas separating 1000's)

2020-06-06 Thread 積丹尼 Dan Jacobson
OK. I added
https://github.com/Perl/perl5/issues/17840
to also note about non-3 cultures.



Bug#918375: Docker SIGSEGV

2020-06-06 Thread Pini
Hi,

On Sat, 5 Jan 2019 17:48:31 +0100 Vincent Smeets
 wrote:
> Hallo,
> 
> I want to add that I don't know how to reproduce the SIGSEGV. It
> happends when I am developing containers, but also during my breaks
> (screenlock). Testing a solution will be difficult.
> 
> Here are todays SIGSEGVs:
> 
> vincent@PC-Vincent:~$ sudo journalctl -b0 | grep SIGSEGV
> jan 05 10:36:18 PC-Vincent dockerd[954]: [signal SIGSEGV: segmentation
> violation code=0x1 addr=0x0 pc=0x564a9d3a2158]
> jan 05 11:13:36 PC-Vincent dockerd[18723]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x555897453158]
> jan 05 12:00:59 PC-Vincent dockerd[32147]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x560bac7a1158]
> jan 05 12:42:33 PC-Vincent dockerd[14174]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x559c2e092158]
> jan 05 13:12:36 PC-Vincent dockerd[29099]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x564e8f238158]
> jan 05 13:42:40 PC-Vincent dockerd[4024]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x56084fc6a158]
> jan 05 14:12:43 PC-Vincent dockerd[13242]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x89727158]
> jan 05 14:42:46 PC-Vincent dockerd[23871]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x55acb4c17158]
> jan 05 15:12:50 PC-Vincent dockerd[30296]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x5599f09e7158]
> jan 05 15:42:53 PC-Vincent dockerd[4545]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x55593e7e2158]
> jan 05 16:12:56 PC-Vincent dockerd[9021]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x5630b39d9158]
> jan 05 16:43:00 PC-Vincent dockerd[13117]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x55f1fe291158]
> jan 05 17:13:03 PC-Vincent dockerd[17369]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x556626f84158]
> jan 05 17:43:06 PC-Vincent dockerd[22316]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x55bc4ddbc158]
> vincent@PC-Vincent:~$

Same pattern here. I've migrated for testing purpose standalone compose
mode containers to a single node swarm, and the docker service now
segfaults every 30 minutes with:

juin 06 21:30:34 serveur dockerd[10190]: panic: runtime error: invalid
memory address or nil pointer dereference
juin 06 21:30:34 serveur dockerd[10190]: [signal SIGSEGV: segmentation
violation code=0x1 addr=0x0 pc=0x55fc93504388]
juin 06 21:30:34 serveur dockerd[10190]: goroutine 1358 [running]:
juin 06 21:30:34 serveur dockerd[10190]:
github.com/armon/go-radix.recursiveWalk(0x0, 0xc003805e08, 0x55fc946a8900)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:519
+0x28
juin 06 21:30:34 serveur dockerd[10190]:
github.com/armon/go-radix.recursiveWalk(0xc004ec8f90, 0xc003805e08,
0xc003805c00)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:525
+0x7a
juin 06 21:30:34 serveur dockerd[10190]:
github.com/armon/go-radix.recursiveWalk(0xc003379e30, 0xc003805e08,
0xc003805c00)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:525
+0x7a
juin 06 21:30:34 serveur dockerd[10190]:
github.com/armon/go-radix.recursiveWalk(0xc004ec8750, 0xc003805e08, 0x19)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:525
+0x7a
juin 06 21:30:34 serveur dockerd[10190]:
github.com/armon/go-radix.(*Tree).WalkPrefix(0xc0055ab620, 0xc0062ebaa0,
0x1a, 0xc003805e08)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:473
+0xdb
juin 06 21:30:34 serveur dockerd[10190]:
github.com/docker/libnetwork/networkdb.(*NetworkDB).reapTableEntries(0xc005308c60)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:396
+0x3c5
juin 06 21:30:34 serveur dockerd[10190]:
github.com/docker/libnetwork/networkdb.(*NetworkDB).reapState(0xc005308c60)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:362
+0x2d
juin 06 21:30:34 serveur dockerd[10190]:
github.com/docker/libnetwork/networkdb.(*NetworkDB).reapState-fm()
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:170
+0x2c
juin 06 21:30:34 serveur dockerd[10190]:
github.com/docker/libnetwork/networkdb.(*NetworkDB).triggerFunc(0xc005308c60,
0x12a05f200, 0xc000cbd1a0, 0xc002703e60)
juin 06 21:30:34 serveur dockerd[10190]:

Bug#947942: Can't reproduce the issues with 2.35.2-2

2020-06-06 Thread Wolfram Sang

Using 2.35.2-2, I can use bash-completion when unmounting a USB drive
which was mounted to a directory containing spaces.

The 'gawk' issues was properly fixed, too, check #933934

Maybe someone wants to verify, yet I think this can be closed.



signature.asc
Description: PGP signature


Bug#938924: zziplib: Python2 removal in sid/bullseye

2020-06-06 Thread Moritz Mühlenhoff
tags 938924 fixed-upstream
thanks

On Fri, Aug 30, 2019 at 08:00:27AM +, Matthias Klose wrote:
> Package: src:zziplib
> Version: 0.13.62-3.2
> 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

This has been fixed in 0.13.71, with that version it's just a matter
of switching the build dep to python3.

Cheers,
Moritz



Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package

2020-06-06 Thread Jonas Smedegaard
Hi Lev,

Quoting Lev Lamberov (2020-06-03 12:20:14)
> Пн 25 мая 2020 @ 12:32 Jonas Smedegaard :
> 
> > Quoting Lev Lamberov (2020-05-25 12:19:07)
> >> I've just got some news from Jan Wielemaker. The next stable 
> >> release of swi-prolog, branch 8.2, is almost ready. How are your 
> >> experiments with depending on swi-prolog virtual packages going? I 
> >> would like to package the current latest version and upload it into 
> >> unstable for testing it with more installations, just to make sure 
> >> there are no serious bugs and blockers for the release of 8.2 
> >> branch.
> >
> > Sorry, I have not played with it at all, yet.
> >
> > Hope to find/make time for it later today.  Will let you know when I 
> > do!
> 
> A couple days ago I uploaded new stable release of swi-prolog, 8.2.0, 
> into unstable. This branch of swi-prolog will stay for a long period 
> of time. Quite possible that it will be in Debian stable, since I 
> don't think we'll see another stable release of swi-prolog before the 
> coming freeze.
> 
> Could you please upload eye rebuilt against swi-prolog 8.2.0? 
> Currently swi-prolog are going to be removed from testing on June 22 
> because of RC bug in 8.1.29, and there are some other packages 
> depending on swi-prolog which are going to be removed too.
> 
> Also, it would be nice if you can switch dependency on swi-prolog to 
> one of its virtual packages. There are 
> swi-prolog-abi-2-67-4369f15b-de23899e and swi-prolog-abi-foreign-2 
> provided by swi-prolog-core. You may find more information about ABI 
> versions in its NEWS.Debian and mentioned there upstream 
> documentation.

Eye updated now, using the new virtual ABI package, but unfortunately 
couldn't move to lighter dependency than the -nox package as that has a 
needed pcre module.

I hope others will benefit from the package split.  Speaking of which, I 
suggest to have the core packages only suggest (not recommend) the -doc 
package.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#938587: sugar-etoys-activity: Python2 removal in sid/bullseye

2020-06-06 Thread Jonas Smedegaard
[ sent again, with 7bit headers to please Debian MTAs ]

Quoting Moritz Mühlenhoff (2020-06-06 22:16:18)
> On Sat, Jun 06, 2020 at 05:03:08PM +0200, Jonas Smedegaard wrote:
> > Hi Moritz,
> > 
> > Quoting Moritz Mühlenhoff (2020-06-06 16:34:38)
> > > sugar-etoys-activity seems dead upstream the last commit is from 2012, 
> > > shall we remove it?
> > 
> > What a coincidence that you should ask today - same exact day that a new 
> > release of Squeak Etoys was released after 10 years of development: 
> > http://www.squeakland.org/download/
> 
> Haha, I jinxed it :-)

Sorry, no, I was totally fooled: That web page simply shows todays date, 
and the 5.0 release happened about 10 years ago. :-/

That said, The Squeak community is still active, just not issuing 
tarball images: Codebase in now at version 5.3. live-updatable from 
inside a 5.x image.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#962367: libzstd FTCBFS: uses the build architecture compiler

2020-06-06 Thread Helmut Grohne
Source: libzstd
Version: 1.4.5+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libzstd fails to cross build from source, because some parts of it
(including the shared library) are built during dh_auto_install, where
debhelper doesn't pass cross tools. Thus the build architecture compiler
is being used and when examining the binaries an error is produced.
Please perform all build steps via dh_auto_build. I'm attaching a patch
implementing that for your convenience.

Helmut
diff --minimal -Nru libzstd-1.4.5+dfsg/debian/changelog 
libzstd-1.4.5+dfsg/debian/changelog
--- libzstd-1.4.5+dfsg/debian/changelog 2020-06-05 10:47:12.0 +0200
+++ libzstd-1.4.5+dfsg/debian/changelog 2020-06-06 22:43:14.0 +0200
@@ -1,3 +1,11 @@
+libzstd (1.4.5+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Don't build the shared library during dh_auto_install.
+(Closes: #-1)
+
+ -- Helmut Grohne   Sat, 06 Jun 2020 22:43:14 +0200
+
 libzstd (1.4.5+dfsg-1) unstable; urgency=medium
 
   * New upstream version 1.4.5+dfsg
diff --minimal -Nru libzstd-1.4.5+dfsg/debian/rules 
libzstd-1.4.5+dfsg/debian/rules
--- libzstd-1.4.5+dfsg/debian/rules 2020-06-05 10:47:12.0 +0200
+++ libzstd-1.4.5+dfsg/debian/rules 2020-06-06 22:43:11.0 +0200
@@ -26,6 +26,7 @@
 
 override_dh_auto_build:
dh_auto_build -- ZSTD_LEGACY_MULTITHREADED_API=1
+   dh_auto_build --sourcedirectory=lib -- ZSTD_LEGACY_MULTITHREADED_API=1 
all libzstd.pc libzstd
dh_auto_build --sourcedirectory=contrib/pzstd/ -- pzstd
 
 override_dh_install:


Bug#962366: gajim crashes at startup

2020-06-06 Thread Robert Pommrich
Package: gajim
Version: 1.1.2-2~bpo9+1
Severity: normal

Dear Maintainer,

Gajim crashed at startup with:

$ gajim
Found default language: de
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/secretstorage/util.py", line 31, in 
function_out
return function_in(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 145, in __call__
**keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in 
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Keine 
derartige Schnittstelle »org.freedesktop.DBus.Properties« des Objekts im Pfad 
/org/freedesktop/secrets/collection/login

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/secretstorage/collection.py", line 155, 
in get_default_collection
return Collection(bus)
  File "/usr/lib/python3/dist-packages/secretstorage/collection.py", line 43, 
in __init__
signature='ss')
  File "/usr/lib/python3/dist-packages/secretstorage/util.py", line 34, in 
function_out
raise ItemNotFoundException('Item does not exist!')
secretstorage.exceptions.ItemNotFoundException: Item does not exist!

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gajim/application.py", line 220, in 
_activate
self.interface = Interface()
  File "/usr/lib/python3/dist-packages/gajim/gui_interface.py", line 2704, in 
__init__
app.connections[account] = Connection(account)
  File "/usr/lib/python3/dist-packages/gajim/common/connection.py", line 526, 
in __init__
self.password = passwords.get_password(name)
  File "/usr/lib/python3/dist-packages/gajim/common/passwords.py", line 149, in 
get_password
return get_storage().get_password(account_name)
  File "/usr/lib/python3/dist-packages/gajim/common/passwords.py", line 113, in 
get_password
pw = backend.get_password(account_name)
  File "/usr/lib/python3/dist-packages/gajim/common/passwords.py", line 70, in 
get_password
return self.keyring.get_password('gajim', account_name)
  File "/usr/lib/python3/dist-packages/keyring/backends/SecretService.py", line 
57, in get_password
collection = self.get_preferred_collection()
  File "/usr/lib/python3/dist-packages/keyring/backends/SecretService.py", line 
45, in get_preferred_collection
collection = secretstorage.get_default_collection(bus)
  File "/usr/lib/python3/dist-packages/secretstorage/collection.py", line 158, 
in get_default_collection
'default', session)
  File "/usr/lib/python3/dist-packages/secretstorage/collection.py", line 137, 
in create_collection
dismissed, unlocked = exec_prompt_glib(bus, prompt)
  File "/usr/lib/python3/dist-packages/secretstorage/util.py", line 134, in 
exec_prompt_glib
exec_prompt(bus, prompt, callback)
  File "/usr/lib/python3/dist-packages/secretstorage/util.py", line 122, in 
exec_prompt
prompt_iface.connect_to_signal('Completed', new_callback)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 544, in 
connect_to_signal
dbus_interface, **keywords)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 369, in 
connect_to_signal
**keywords)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 148, in 
add_signal_receiver
path, **keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 400, in 
add_signal_receiver
  self._require_main_loop()
RuntimeError: To make asynchronous calls, receive signals or export objects, 
D-Bus connections must be attached to a main loop by passing mainloop=... to 
the constructor or calling dbus.set_default_main_loop(...)

Best regards,
Robert

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

Kernel: Linux 3.16.0-10-amd64 (SMP w/4 CPU cores)
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)

Versions of packages gajim depends on:
ii  gir1.2-gtk-3.0   3.22.11-1
ii  python3  3.5.3-1
ii  python3-cssutils 1.0-4.1
ii  python3-gi   3.22.0-2
ii  python3-gi-cairo 3.22.0-2
ii  python3-idna 2.2-1
ii  python3-keyring  10.1-1
ii  python3-nbxmpp   0.6.10-1~bpo9+1
ii  python3-openssl  16.2.0-1
ii  python3-precis-i18n  1.0.0-1~bpo9+1

Versions of packages gajim recommends:
ii  alsa-utils  1.1.3-1
ii  aspell-de [aspell-dictionary]   20161207-1
ii  aspell-de-1901 [aspell-dictionary]  1:2-31
ii  ca-certificates 20161130+nmu1+deb9u1
ii  dbus1.10.28-0+deb9u1
pn  fonts-noto-color-emoji 

Bug#962365: gnuradio-dev: upgrade to boost 1.71 breaks OOT module building

2020-06-06 Thread Daniel Estévez
Package: gnuradio-dev
Version: 3.8.1.0-1+b3
Severity: important

Hi Maitland,

One of the users of gr-satellites has spotted a problem when building 
gr-satellites
with a recently upgraded Debian testing system. This problem not only affects 
gr-satellites,
but all GNU Radio out-of-tree modules. I have been able to replicate it with an 
empty
out-of-tree module freshly created with gr_modtool.

The particular problem appears when running cmake with the out-of-tree module. 
cmake
will not be able to find a suitable version of boost, reporting:

-- Could NOT find Boost: Found unsuitable version "1.67.0", but required is at 
least "1.71.0" (found /usr/include)
CMake Warning at CMakeLists.txt:88 (find_package):
Found package configuration file: 
/usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake

Then cmake terminates and the module cannot be built.

It seems to me that the probem is that the gnuradio package has been upgraded 
to boost 1.71.0,
while gnuradio-dev still depends on packages from boost 1.67.0. In fact, as you 
can see below,
gnuradio-dev depends on several "generic version" libboost packets such as 
libboost-date-time-dev.
Perhaps it would be enough to make it depend on libboost-date-time1.71-dev, etc.

More information can be found in the bug reported on gr-satellites:
https://github.com/daniestevez/gr-satellites/issues/114

Best regards,

Daniel

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

Kernel: Linux 5.6.13-gentoo (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=es_ES.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default 
locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages gnuradio-dev depends on:
ii  gnuradio  3.8.1.0-1+b3
ii  libboost-date-time-dev1.67.0.2+b1
ii  libboost-filesystem-dev   1.67.0.2+b1
ii  libboost-program-options-dev  1.67.0.2+b1
ii  libboost-regex-dev1.67.0.2+b1
ii  libboost-system-dev   1.67.0.2+b1
ii  libboost-test-dev 1.67.0.2+b1
ii  libboost-thread-dev   1.67.0.2+b1
ii  libcppunit-dev1.15.1-2
ii  libfftw3-dev  3.3.8-2
ii  libgmp-dev2:6.2.0+dfsg-4
ii  libgsm1-dev   1.0.18-2
ii  liblog4cpp5-dev   1.1.3-1
ii  libvolk2-dev  2.3.0-2
ii  python3-dev   3.8.2-3

gnuradio-dev recommends no packages.

Versions of packages gnuradio-dev suggests:
ii  cmake   3.16.3-3
pn  libqwt-qt5-dev  
ii  pkg-config  0.29.2-1
pn  qtbase5-dev 
ii  swig4.0.1-5

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LC_COLLATE = "es_ES.UTF-8",
LANG = "es_ES.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory



Bug#938587: sugar-etoys-activity: Python2 removal in sid/bullseye

2020-06-06 Thread Moritz Mühlenhoff
On Sat, Jun 06, 2020 at 05:03:08PM +0200, Jonas Smedegaard wrote:
> Hi Moritz,
> 
> Quoting Moritz Mühlenhoff (2020-06-06 16:34:38)
> > sugar-etoys-activity seems dead upstream the last commit is from 2012, 
> > shall we remove it?
> 
> What a coincidence that you should ask today - same exact day that a new 
> release of Squeak Etoys was released after 10 years of development: 
> http://www.squeakland.org/download/

Haha, I jinxed it :-)

Cheers,
Moritz



Bug#962364: libgphoto2: please update to 2.5.25

2020-06-06 Thread David Bremner
Source: libgphoto2
Version: 2.5.25-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have forked the repo on salsa and did a quick update to 2.5.25 at

  https://salsa.debian.org/bremner/libgphoto2

Feel free to use that (or change whatever needs to be changed). It has
worked for me for about 10 minutes, but I don't really know if I
duplicated your workflow and checked all the things that need to be
checked.


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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl7b+VQACgkQA0U5G1Wq
FSH21A/9HfxdGZsh3Qrcd+w0pabNFntCQPE56QLNyg6/3U7wR9kin5Pa83NtBYee
vvrgu0CzgKBhdfM0JT5p/PoBfievsFdo/QYNrbcOT3VMSGd6n64unlOr4RUtAvkI
rNB1SLjTfdw9shc1nBK1a2kU/VLZJAgndSwlQdtQwAkoxmDPEp8mEPlQ43tq8kEM
62nyyfxC2jJTCypGaqgO0Hr/TLlKQ4KfurvdOJKyPxeCHEpP+AqZCRNW5Jah9pNQ
gdAjvdQNSlJjXK4OKMC2+LbARl4GpUIkwSJRH1BG2Ui5B9trcAzJi7flz14H47QT
ibZM28mnzgFd9mT5ZYP9cE+RVN2FNfH0an6gh1pQf7cug5WXtBRXhm01dkQlUxet
1CFk8uCdojio5wZteOx1KnqZhgd/5j8tN39wG6jw/oJLe1n5UDsRn5COj3eGx8rb
vsUDn5fWlx31224i8LSI03Zx9DWsFXQBZjAS1vBEZUw1QSdlb1GLkp+lAtDb47f/
Fvrdz8oK9VnkZ4Caivz6Eak7aQkIfEWlT9O0BiQCaI/ntHDiXHtw52bN7yC8c7kT
SnFXS4qiysRPZdR1ktN8KwqeXyiHJxI15ItlDQFcgJxy8f4ALzICNZdFROt3T7nM
ymOzXFXNDsKoHX6eoLeKBBHy2fWqxdLGqzwJB5cKuZy+aZrzAxk=
=J3CW
-END PGP SIGNATURE-



Bug#612216: mirage: Does not follow german locale adjustment

2020-06-06 Thread Thomas Ross
Hi,

This bug is fixed in the new upstream version of Mirage (0.10.0), which
I plan on getting uploaded to the Debian archives soon, however, the
command you are providing will still not work: you need to use
LANG=de_DE.UTF-8 or LANGUAGE=de rather than LANG=DE. For more
information, see [1] and [2].

Thanks,
Thomas.

[1]:
https://www.gnu.org/software/gettext/manual/html_node/Locale-Environment-Variables.html
[2]:
https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html


On Sun, 06 Feb 2011 20:58:37 +0100 Michael Mittler
 wrote:
> Package: mirage
> Version: 0.9.5.1-1
> Severity: normal
> 
> Mirage does not follow german locale adjustment. The command 'LANG=DE mirage'
> shows a "(process:7632): Gtk-WARNING **: Locale not supported by C library.
> Using the fallback 'C' locale."
> 
> Kind regards
> 
> Michael
> 
> 
> 
> -- System Information:
> Debian Release: 6.0
>   APT prefers squeeze-updates
>   APT policy: (500, 'squeeze-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages mirage depends on:
> ii  libc6   2.11.2-10Embedded GNU C Library: Shared 
> lib
> ii  libx11-62:1.3.3-4X11 client-side library
> ii  python  2.6.6-3+squeeze5 interactive high-level 
> object-orie
> ii  python-gtk2 2.17.0-4 Python bindings for the GTK+ 
> widge
> ii  python-support  1.0.10   automated rebuilding support for 
> P
> 
> mirage recommends no packages.
> 
> Versions of packages mirage suggests:
> ii  gimp 2.6.10-1The GNU Image Manipulation 
> Program
> ii  imagemagick  8:6.6.0.4-3 image manipulation programs
> ii  menu 2.1.44  generates programs menu for all 
> me
> 
> -- no debconf information
> 
> 
> 



Bug#653361: mirage: chokes on PBM/PGM/PPM without comments

2020-06-06 Thread Thomas Ross
Hi,

I cannot reproduce this bug with the given image files on Mirage
0.9.5.1, 0.9.5.2 (the version currently in Debian archives for stretch,
buster, and sid), or Mirage master.

Please let me know if you are still able to reproduce this bug.

Thanks,
Thomas.

On Tue, 27 Dec 2011 12:55:37 +0100 Andre Majorel 
wrote:
> Package: mirage
> Version: 0.9.5.1-1
> Severity: normal
> 
> Dear Mirage maintainer,
> 
> Mirage does not show PBM, PGM or PPM files if they don't have a
> comment. This is wrong. Comments are not mandatory according to
> pbm(5), pgm(5) and ppm(5) and Netpbm programs like pnmdepth or
> pnmflip neither require nor produce any.
> 
> Sample PNM files along with the shell script to create them are
> available from :
> 
>   http://www.teaser.fr/~amajorel/bugs/pnm-comments/
> 
> Thanks in advance.
> 
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.0.13 (SMP w/2 CPU cores; PREEMPT)
> Locale: LANG=C, LC_CTYPE=en_US (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages mirage depends on:
> ii  libc6 2.13-16Embedded GNU C Library: Shared 
> lib
> ii  libx11-6  2:1.4.4-4  X11 client-side library
> ii  python2.6.6-14   interactive high-level 
> object-orie
> ii  python-gtk2   2.24.0-2   Python bindings for the GTK+ 
> widge
> ii  python-support1.0.13 automated rebuilding support for 
> P
> 
> mirage recommends no packages.
> 
> Versions of packages mirage suggests:
> ii  gimp  2.6.11-1   The GNU Image Manipulation 
> Program
> ii  imagemagick   8:6.6.9.7-5+b2 image manipulation programs
> ii  menu  2.1.43 generates programs menu for all 
> me
> 
> -- no debconf information
> 
> -- 
> André Majorel 
> The Debian project must be praised for their efforts in fighting spam by
> flooding spammers with email addresses, some of which are even bogus.
> 
> 
> 



Bug#790362: mirage: Uses too much memory

2020-06-06 Thread Thomas Ross
Hi,

I cannot reproduce this bug with the given image file on Mirage
0.9.5.1, 0.9.5.2 (the version currently in Debian archives for stretch,
buster, and sid), or Mirage master. It is possible the bug was fixed in
a later version of GTK.

Please let me know if you are still able to reproduce this bug.

Thanks,
Thomas.

On Sun, 28 Jun 2015 16:12:56 +0200 Manuel Bilderbeek
 wrote:
> Package: mirage
> Version: 0.9.5.1-3
> Severity: normal
> 
> Dear Maintainer,
> 
> I was trying to view a PNG with the following properties:
> 05_Xak_2_-_Het_Kasteel.png: PNG image data, 6000 x 26000, 8-bit/color RGB, 
> non-interlaced
> (it can be downloaded here: http://www.msx.org/downloads/xak-ii-map )
> 
> It works, but it's using over 1GB of RAM:
> 
>   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
>  6305 manuel20   0 1534,5m 1,048g  24,0m S 100,1 13,4   1:12.75 mirage
> 
> One would expect a RAM usage of about 6000 x 26000 x 3 bytes, so about 468MB.
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages mirage depends on:
> ii  libc62.19-18
> ii  libx11-6 2:1.6.3-1
> ii  python   2.7.9-1
> ii  python-gtk2  2.24.0-4
> 
> mirage recommends no packages.
> 
> Versions of packages mirage suggests:
> ii  gimp 2.8.14-1+b1
> ii  imagemagick  8:6.8.9.9-5
> ii  menu 2.1.47
> 
> -- no debconf information
> 
> 



Bug#954125: querybts: Add option to directly read mbox using MUA/mutt

2020-06-06 Thread Nis Martensen
On 17 Mar 2020 Josh Triplett wrote:
> 
> https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/55
> 
> querybts supports a -m/--mbox option to dump an mbox directly to stdout,
> and an --mbox-reader-cmd option to specify a MUA to read an mbox when
> using the option from the query UI to open the mbox via a mail reader,
> but does not have any option to directly open the mbox without going
> through the query UI first.
> 
> Add a new option -M/--mua/--mutt, which directly opens the mbox in an
> MUA (default mutt), exiting when done.
> 
> Refactor utils.launch_mbox_reader to separate out URL downloading from
> reader launching, putting the latter in a new
> utils.launch_mbox_reader_str.

Thank you for this bug and patch. However, I'm unsure about this. Is it
really worth improving querybts? What does it provide that reportbug
does not? Shouldn't we better drop querybts?

Not only is reportbug designed to be able to send followup information
to bugs, it also does a better job querying the BTS than querybts does.
In the default query for bugs on a package, querybts retrieves the bug
list only for the binary package, while reportbug retrieves the much
more comprehensive bug list for the corresponding source package. I
intend to merge a patch soon that will make reportbug also consider
"submit-as" information for the query, which cannot be done easily with
querybts.

If you already know the bug number and want to open a bug mbox in your
MUA, you can use `bts show --mbox $bugno` (from the devscripts package)
and don't need yet another tool/option to just do the same thing?



Bug#961374: usbguard: please provide the libusbguard public development files

2020-06-06 Thread Pino Toscano
Hi,

In data sabato 23 maggio 2020 21:05:13 CEST, Birger Schacht ha scritto:
> On 5/23/20 8:12 PM, Pino Toscano wrote:
> > Hi,
> > 
> > it would be nice to have a libusbguard-dev package providing the
> > development files for libusbguard0. Upstream already installs them,
> > so it is matter of shipping them in a new libusbguard-dev package.
> > This way 3rd party applications can be built using the shared
> > libusbguard library.
> 
> Upstream does not consider the API to be stable, thats why we're
> installing to a private location for now and therefore not shipping
> development files.

Hmm interesting, as on other distributions (Fedora, openSUSE, Gentoo
and Arch Linux, I checked) they are available.

> Also I'm not aware of any other projects besides
> upstream using the usbguard library. Are there any 3rd party
> applications? That might change things...

I revived the Qt applet [1] that upstream removed, since there is no
other GUI equivalent other than GNOME Shell (so not an option for
whoever does not use it).

An item in my TODO list is get rid of the library, which I already
started to do (i.e. the communication is done via usbguard-dbus instead
of the IPC). The other usages of the library are:
- logging (should be easy)
- parsing the rules, which is a non-trivial task (given their syntax)

[1] https://github.com/pinotree/usbguard-applet-qt/

So up to you: I can live with a locally built src:usbguard that
provides libusbguard-dev until I need it.

-- 
Pino Toscano

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


Bug#962363: openjpeg2: Static library missing in openjpeg2 dev package

2020-06-06 Thread Tom Hughes
Package: openjpeg2
Version: 2.3.0-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Dear Maintainer,

The openjpeg2 dev package is missing the static library.

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

  * Add static library to libopenjp2-7-dev (Closes: #1794194). 

Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-99-generic (SMP w/8 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru openjpeg2-2.3.0/debian/rules openjpeg2-2.3.0/debian/rules
--- openjpeg2-2.3.0/debian/rules2017-10-15 22:43:41.0 -0700
+++ openjpeg2-2.3.0/debian/rules2020-06-06 11:06:16.0 -0700
@@ -20,6 +20,7 @@
   -DBUILD_MJ2:BOOL=OFF \
   -DBUILD_JP3D:BOOL=ON \
   -DBUILD_SHARED_LIBS:BOOL=ON \
+  -DBUILD_STATIC_LIBS:BOOL=ON \
   -DBUILD_TESTING:BOOL=OFF \
   -DBUILD_DOC:BOOL=ON \
   -DBUILD_THIRDPARTY:BOOL=OFF
@@ -47,6 +48,7 @@
# lib
dh_install -p$(pkg_lib) --autodest 
usr/lib/$(DEB_HOST_MULTIARCH)/libopenjp2.so.*
# dev:
+   dh_install -p$(pkg_dev) --autodest 
usr/lib/$(DEB_HOST_MULTIARCH)/libopenjp2.a
dh_install -p$(pkg_dev) --autodest 
usr/lib/$(DEB_HOST_MULTIARCH)/libopenjp2.so
dh_install -p$(pkg_dev) --autodest 
usr/lib/$(DEB_HOST_MULTIARCH)/openjpeg-2.3/*.cmake
dh_install -p$(pkg_dev) --autodest 
usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig/*.pc


Bug#962362: cyrus-admin: sieveshell segfaults after quit command

2020-06-06 Thread Valentin Vidic
Package: cyrus-admin
Version: 3.0.8-6+deb10u4
Severity: normal

Dear Maintainer,

The sieveshell command does not work correctly after the quit command:

$ sieveshell localhost
connecting to localhost
Please enter your password:
> list
main  <- active script
> quit
> list
Segmentation fault

Rather than accepting further commands after quit, sieveshell should just exit
as $obj becomes NULL and is not usable anymore:

} elsif (($words[0] eq "quit") || ($words[0] eq "q")) {
sieve_logout($obj);
+   last;
}

This is a Debian specific problem, as the upstream version already has
exit 0 in place of last.

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

Kernel: Linux 4.19.0-9-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cyrus-admin depends on:
ii  cyrus-common3.0.8-6+deb10u4
ii  dpkg1.19.7
ii  libcyrus-imap-perl  3.0.8-6+deb10u4
ii  perl5.28.1-6

cyrus-admin recommends no packages.

Versions of packages cyrus-admin suggests:
ii  sasl2-bin  2.1.27+dfsg-1+deb10u1

-- no debconf information



Bug#962310: chmod 0700 warning messages appears to be incorrect

2020-06-06 Thread Wakko Warner
David Kalnischkies wrote:
> On Fri, Jun 05, 2020 at 09:15:56PM -0400, Wakko Warner wrote:
> > I noticed, due to the way I have apt setup, that it complains about chmoding
> > some files.  I was looking in the source for a way to bypass this message
> > and noticed that 0700 is hard coded in the warning.
> 
> Can you describe your setup some more so that we can perhaps make apt
> deal with that setup better? It is a bit on the backburner ATM, but
> isolating the methods more from the system and each other is always on
> the TODO list and that tends to involve more directories with more
> permissions and stuff.

I keep a mirror of debian in /debian.  I usually only get dists/sid
(amd64/i386 and source only), zz-dists and pool (again, amd64/i386/source).

In apt/, I have amd64, amd64+i386 and i386.

Under those, I have 2 apt config snippets to use the local mirror (one keeps
cache on local system, other keeps it centralized).  I have a sources.list
that points to this location.  Then I have cache and lists.  These are the
same as /var/cache/apt and /var/lib/apt/lists.

After my mirror finishes, the following is ran:
unset clean
for dir in apt/*;do
 [ "$dir" = "apt/*" ] && break
 [ -e "$dir/00mirror" ] || continue
 rm -f "$dir/cache/pkgcache.bin" "$dir/cache/srcpkgcache.bin"
 apt-get ${clean+-o} $clean -o Debug::NoLocking=yes -c "$dir/00mirror" update
 clean="APT::Get::List-Cleanup=no"
done

This is not ran as root, the reason for NoLocking.  Currently, my server's
apt version is quite old and I have been reluctant to upgrade it due to this
setup and the fact that apt-file changed.  apt currenlty 1.0.7 and apt-file
2.5.1 on the server.  Clients with 2.1.6 works just fine but not apt-file

00mirror is for trusted clients (Normally part of my network) and have full
write access to the mirror.  The other part of this is to keep the .bin files
off the local machine.  This file also describes my directory layout too.
I'm only using sid for this setup.  00mirror (for my amd64+i386) contains:
Apt::Architecture "amd64";
Apt::Architectures {"amd64"; "i386";};
Dir "/debian/"
{
 State "apt/amd64+i386/"
 {
  Lists "lists/";
  extended_states "/var/lib/apt/extended_states";
  status "/var/lib/dpkg/status";
 };
 Cache "apt/amd64+i386/cache/"
 {
  Archives "/var/cache/apt/archives/";
  srcpkgcache "srcpkgcache.bin";
  pkgcache "pkgcache.bin";
 };
 Etc "/etc/apt/"
 {
  SourceList "/debian/apt/amd64+i386/sources.list";
 };
 Log "/var/log/apt";
};

The amd64 only and i386 only have that specific arch on line 1, they do not
have the 2nd line and the paths are changed respectively.

00mirror-localcache is the same, just replacing the Cache section with
Cache "/var/cache/apt/";
It's used on clients where the mirror is read only.

For the client side, all that has to be done is
1) create /debian
2) mount via nfs
3) link either 00mirror or 00mirror-localcache to /etc/apt/apt.conf.d

apt-get update is never ran on client side, it's always up to date.  I
noticed that if packagecache.bin is out of date, an apt-get install will fix
it.  I also know that the .bin files are not the same between apt versions,
however I never install packages on 2 different machines concurrently (For
the ones that use 00mirror)

> > In apt-pkg/acquire.cc:SetupAPTPartialDirectory() on lines 112 and 119 is
> > where I noticed the message.  The chown in the if statement shows it using a
> > variable named mode.  The warning message should reflect the mode it was
> > trying to set.
> 
> Indeed, thanks for reporting!
> 
> I will see how to change that string (and the one assuming root-group to
> be root even through we have a compile-time variable for that) without
> creating busywork for our translations.

Y/W.  I received another email that stated this was fixed in git already.

-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.



Bug#962348: kig: boost1.67 is being removed from testing

2020-06-06 Thread Pino Toscano
severity 962348 important
thanks

In data sabato 6 giugno 2020 16:26:34 CEST, Dimitri John Ledkov ha scritto:
> Package: kig
> Version: 4:20.04.1-1
> Severity: serious
> 
> Hi,
> 
> boost1.67 is being removed from testing and is transitioning to boost1.71.

Yes, I know about the boost transition to 1.71.0, that the new boost
does not provide Python 2 support, and that it is expected to not ship
boost 1.67.0 in bullseye.

> kig has just now switched from boost1.71 to boost1.67.

Quoting what I wrote in the changelog entry of 4:20.04.1-1:

  * Temporarily switch from libboost-python-dev to libboost-python1.67-dev,
as boost 1.67 is the latest version of boost in Debian that supports
Python 2: kig < 20.08 is not ready for Python 3, so stil with Python 2
for now.

As the version number hints, the new stable version will be released
in (late) August; the development version already switched to Python 3
only, and it contains few Python 3 fixes. The current version does
*not* work properly with Python 3, that is why I had to rollback to
boost 1.67.0 (since boost 1.71.0 has no Python 2 bindings, sigh).

> Thus I am opening this bug report to prevent kig from migrating.

First of all, please do not abuse severities for things that are not
critical yet. There is a catch here: the version in testing is the
binNMU for the boost 1.71.0 rebuild, and apparently (to my surprise)
it was detected and switched to Python 3. This is buggy though, so
not letting this version migrate means having a buggy version in
testing.

> boost1.71 does not offer python2 bindings, as python2 is being removed to.

Sure, I know this too.

> I understand that kig is using boost-python2. Either please disable
> python bindings usage at build time, or try to port to boost-python3?

As I said, in ~3 months there will be a new upstream release fully
supporting Python 3, and I will switch it when it is released.

In the meanwhile, please:
a) open a RM bug for boost 1.67.0, so it is clear that it will be
removed
b) make this bug block the RM bug

I'm pretty sure boost 1.67.0 can stay 3 months more around, especially
since I see it is still not the only package using the old boost.

-- 
Pino Toscano

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


Bug#962349: RFS: git-subrepo/0.4.1~2 -- GIT Submodule alternative

2020-06-06 Thread Samo Pogačnik
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "git-subrepo"

 * Package name: git-subrepo
   Version : 0.4.1~2
   Upstream Author : Ingy döt Net 
 * URL : https://github.com/ingydotnet/git-subrepo
 * License : MIT
 * Vcs : https://github.com/spog/git-subrepo-debian
   Section : vcs

It builds those binary packages:

  git-subrepo - GIT Submodule alternative

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-subrepo/git-subrepo_0.4.1~2.dsc

Changes since the last upload:

   [ spog ]
   * Fixed reading installed subrepo command info.
   * Added subrepo to git completion commands
 .
   [ admorgan ]
   * Fix Bash version error messages and add to .rc
   * Nicer YAML formatting in .travis.yml
   * Wrap a long line
   * Update the docs
   * Force `make update` to always update docs
   * Don't use XXX in perl stuff
   * Add testing on MacOS
   * Remove conflicting -C from install -d commands.
   * Update version requirement documentation
   * Correct error message in branch
   * Use topo-order in subrepo branch
   * Make “git subrepo clean -f ...” delete refs correctly
   * Fix #410 Push empty repositories with recent git versions
   * Make subrepo work when run in a worktree
   * Simplify finding subrepos
   * Ask git to find the .gitrepo files
   * Doc: fix sentence repetition
   * Fix typos
   * Fixed typo
   * Travis CI not checking out a branch.

Regards,

--
  Samo Pogačnik



Bug#961972: [Pkg-kde-extras] Bug#961972: kile: Kile crashes with "Segmentation fault" error

2020-06-06 Thread Pino Toscano
tag 961972 + moreinfo
thanks

Hi,

In data lunedì 1 giugno 2020 11:25:16 CEST, decadenza via pkg-kde-extras ha 
scritto:
> Package: kile
> Version: 4:2.9.93-1
> Severity: important
> 
> Dear Maintainer,
> 
> * What led up to the situation?
> 
> Simply opening Kile

Kile opens fine (and seems to work fine too) here.

> Versions of packages kile depends on:
> ii  kinit  5.62.0-1+b1
> ii  kio5.62.1-2+b1
> ii  konsole-kpart  4:19.08.1-2+b1
> ii  libc6  2.30-8
> ii  libgcc-s1 [libgcc1]10-20200324-1
> ii  libgcc11:10-20200324-1
> ii  libkf5codecs5  5.70.0-1
> ii  libkf5completion5  5.70.0-1
> ii  libkf5configcore5  5.70.0-1
> ii  libkf5configgui5   5.70.0-1
> ii  libkf5configwidgets5   5.62.0-1+b1
> ii  libkf5coreaddons5  5.70.0-1
> ii  libkf5crash5   5.70.0-1
> ii  libkf5dbusaddons5  5.70.0-1
> ii  libkf5guiaddons5   5.62.0-2
> ii  libkf5i18n55.70.0-1
> ii  libkf5iconthemes5  5.62.0-1+b1
> ii  libkf5jobwidgets5  5.70.0-1
> ii  libkf5khtml5   5.62.0-1+b1
> ii  libkf5kiocore5 5.62.1-2+b1
> ii  libkf5kiofilewidgets5  5.62.1-2+b1
> ii  libkf5kiowidgets5  5.62.1-2+b1
> ii  libkf5parts5   5.62.0-1+b1
> ii  libkf5service-bin  5.70.0-1
> ii  libkf5service5 5.70.0-1
> ii  libkf5texteditor5  5.62.0-1+b1
> ii  libkf5textwidgets5 5.62.0-1+b1
> ii  libkf5widgetsaddons5   5.70.0-1
> ii  libkf5windowsystem55.70.0-1
> ii  libkf5xmlgui5  5.62.0-1+b1
> ii  libpoppler-qt5-1   0.71.0-6
> ii  libqt5core5a   5.12.5+dfsg-10
> ii  libqt5dbus55.12.5+dfsg-10
> ii  libqt5gui5 5.12.5+dfsg-10
> ii  libqt5script5  5.12.5+dfsg-2
> ii  libqt5widgets5 5.12.5+dfsg-10
> ii  libqt5xml5 5.12.5+dfsg-10
> ii  libstdc++6 10-20200324-1
> ii  okular 4:20.04.0-1
> ii  perl   5.30.2-1
> ii  texlive-latex-base 2020.20200522-1

Most probably this is due to the mixup of Frameworks packages (the
various libkf5* packages) in testing for few days; now everything is
at the same version, 5.70.0, in testing, so can you please try again?

Thanks,
-- 
Pino Toscano

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


Bug#932943: hex or base64

2020-06-06 Thread Thomas Lange
> On Sat, 6 Jun 2020 19:35:45 +0200, Bastian Blank  said:

> Now the remaining question is: GNU or BSD style checksum files?
Let's use the same as our installer images use. This is GNU style.
We should keep a common style on our Debian ISO images both for
install and cloud images.

-- 
regards Thomas



Bug#962361: ITP: r-cran-tmvnsim -- GNU R package for truncated multivariate normal simulation

2020-06-06 Thread Dirk Eddelbuettel


Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-tmvnsim
  Version : 1.0-2
  Upstream Author : Samsiddhi Bhattacjarjee
* URL or Web page : https://cran.r-project.org/package=tmvnsim
* License : GPL-2
  Description : GNU R package for truncated multivariate normal simulation

This package is now a build-depends of package r-cran-mnormt which has been
in Debian since 2007.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#932943: hex or base64

2020-06-06 Thread Bastian Blank
On Sat, Jun 06, 2020 at 07:16:59PM +0200, Bastian Blank wrote:
> That's exactly what this change does:
> https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/203

Now the remaining question is: GNU or BSD style checksum files?

GNU: "checksum  filename"
- No information which type, so filename need to show.
- Different types in different files.

BSD: "type (file) = checksum"
- Can contain different checksums for the same file.
- The *sum tools from coreutils read only the one exact variant.

Regards,
Bastian

-- 
You canna change the laws of physics, Captain; I've got to have thirty minutes!



Bug#932943: hex or base64

2020-06-06 Thread Bastian Blank
On Mon, May 18, 2020 at 11:56:15AM +0200, Thomas Lange wrote:
> I've checked some other distributions in may 2020. They all use hex.

Well, they ship a single file for consumption by "sha512sum", which we
currently don't.

> Maybe provide base64 and hex in our manifest but also sha{265,512}sum
> hex files in the download directory on our server (petterson).

That's exactly what this change does:

https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/203

Regards,
Bastian

-- 
I've already got a female to worry about.  Her name is the Enterprise.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0



Bug#962360: RM: olive-editor [i386 mipsel] -- NBS; no longer built for 32bit architectures

2020-06-06 Thread Adrian Bunk
Package: ftp.debian.org
Severity: normal

olive-editor (20200528-1) unstable; urgency=medium
...
- don't build on 32-bit architectures. (Closes: #950564)
...
 -- Gürkan Myczko   Tue, 02 Jun 2020 08:32:58 +0200


Bug#962336: RFS: cheetah/3.2.5-1 -- text-based template engine and Python code generator (Python 3)

2020-06-06 Thread JCF Ploemen
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-pyt...@lists.debian.org

Dear mentors,

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

 * Package name: cheetah
   Version : 3.2.5-1
   Upstream Author : https://github.com/CheetahTemplate3/cheetah3/issues
 * URL : http://www.cheetahtemplate.org/
 * License : MIT
 * Vcs : https://salsa.debian.org/python-team/modules/cheetah
   Section : python

It builds those binary packages:

  python3-cheetah - text-based template engine and Python code generator 
(Python 3)
  python-cheetah-doc - documentation for the Cheetah template engine

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cheetah/cheetah_3.2.5-1.dsc

Changes since the last upload:

   [ Sandro Tosi ]
   * debian/python-cheetah-doc.doc-base
 - fix doc-base-file-references-missing-file lintian error
 .
   [ JCF Ploemen (jcfp) ]
   * New upstream release.
   * Bump Standards-Version to 4.5.0 (from 4.4.1; no further changes).


Thanks!


pgpIkv3dtdWoH.pgp
Description: OpenPGP digital signature


Bug#962337: RFS: nfoview/1.28-1 -- simple viewer for NFO files

2020-06-06 Thread JCF Ploemen
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-pyt...@lists.debian.org

Dear mentors,

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

 * Package name: nfoview
   Version : 1.28-1
   Upstream Author : Osmo Salomaa 
 * URL : https://otsaloma.io/nfoview/
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/python-team/applications/nfoview
   Section : utils

It builds those binary packages:

  nfoview - simple viewer for NFO files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nfoview/nfoview_1.28-1.dsc

Changes since the last upload:

   [ Debian Janitor ]
   * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
 Repository-Browse.
 .
   [ JCF Ploemen (jcfp) ]
   * New upstream release.
   * Control:
 + replace xfonts-terminus with fonts-cascadia-code, upstream
   changed the default font.
 + bump compat level to 13 (from 12).
   * Install: remove entry for nfoview.xpm, replaced by new upstream svg
 application icons.
   * Bump Standards-Version to 4.5.0 (from 4.4.0; no further changes).
   * Copyright: bump years.


Thanks!


pgpNDPmrOQIGH.pgp
Description: OpenPGP digital signature


Bug#962359: uswsusp: hybernate to file impossible without uswsusp

2020-06-06 Thread Francesco Potortì
Package: uswsusp
Severity: important

In March the uswsusp was removed from testing because it is unmaintained
upstream and its functionality is now useless (see bug #954061).

Unfortunately this is not true in all cases.

Specifically, hybernating to a swap file while using initramfs boot is
only possible through uswsusp (or similar userland utilities), see the
last three paragraphs of swsusp-and-swap-files in kernel docs.

Please re-add uswsusp to testing.

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

Kernel: Linux 5.3.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=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=C:en_GB:en:en_US:it:fr:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#962358: RFS: flam3/3.1.1-2 [RC, ITA] -- render and animate FLAM3s and manipulate their genomes

2020-06-06 Thread Peter


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: important


Dear mentors,

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

 * Package name    : flam3
   Version : 3.1.1-2
   Upstream Author : Scott Draves 
 * URL : https://github.com/scottdraves/flam3
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/flam3
   Section : graphics

It builds those binary packages:

  flam3 - render and animate FLAM3s and manipulate their genomes

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/f/flam3/flam3_3.1.1-2.dsc

Changes since the last upload:

   * Adopt package  (Closes: #711285)
   * Fix FTBFS from xml2-config removal (Closes: #949143)
   * Remove broken 'compile' symlink
   * Remove unused entry ljpeg in .pc file
   * Fix buffer overflow in flam.c
   * Include test.flam3 & vidres.flam3
   * Include rendering fixes from upstream issue tracker
   * Standards now 4.5.0  rules-require-root & compat
   * Fix broken links in the README
   * Fix qosmic FTBFS with ICU 67   (Closes: #962095)

Regards,

- --
  Peter Blackman
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE33HzyvBUkEl4+kj4tty6Zj6hsVAFAl7byB0ACgkQtty6Zj6h
sVAZlBAAqpdX6cww7jn80yNRBiMoU8DkFTHJr3r5ltRDxuaXFdutmdXECQyMT5PV
nW0YP7eUcqzyEIsrdObeb6eHY8vIGyJUhHIyYhno8h6tu7yj7w/NNeJ7eL8bRwim
4JA9/OcK6HegUkOSppsmz3uLVSFnwFUxEfJ3Ks/gL+ivLVSQa8E/fhX4ZighRmsW
dAzopfSjCMTRryou/Be1T5ZUwH3QMcByIYYZmmCdzN5WreVTHxj7DejnCHp1Jlex
Cspf5wXoX1g4BcAjnPKaKsvdbh19uNvkTfwflUMXg2megsFS7NPc5hNbP0+X+NBr
28BsuUd35+9U0ywzoCiqy1ZQfF1cmLYX6WGROSRwplZRoqPHC1jNh6yHrA8MMZBA
ppHD4u6PVwKsl2qtnPVbJsxbb7nv5Cy//KypbHdY1feyygNthPcIhjV6ftudBKQR
tqUO/KKXX0Wo5Bar+QN+PmZnKGqz1xJFPkyULBAXgB3F9jr9QnGaJRR2rdo6Gcbm
feTiJ06+EWwh7I4VjJ5zvy58zd3V9nS8KIqoCRVOx5AWV/Mc/Reum1wH+hSe98bT
gOAYADLeQS5GEV4YLNspMQiX0Co4io9Q0NuFdEUPvp5gZUa5tnruTvKtXhBw/8IC
y2oj6TRWw7cjtha12+ywcZegK+6v9chTeA/HOQkXf9DHwKP90NI=
=Yeq7
-END PGP SIGNATURE-



Bug#962328: gettext-base: The gettext(1) man page is obsolete

2020-06-06 Thread Vincent Lefevre
On 2020-06-06 13:11:01 +0200, Vincent Lefevre wrote:
> The gettext(1) man page is obsolete: incorrect address for upstream
> bug reports, http URL.

bug-gnu-gettext is actually OK, but bug-gettext should now be used
for consistency (to avoid confusion):

https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=085776b376e35e5d1957cdf96527381b28602c63

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



Bug#938587: sugar-etoys-activity: Python2 removal in sid/bullseye

2020-06-06 Thread Jonas Smedegaard
[ sent again, also to bugreport ]

Quoting Jonas Smedegaard (2020-06-06 17:03:08)
> Hi Moritz,
> 
> Quoting Moritz Mühlenhoff (2020-06-06 16:34:38)
> > sugar-etoys-activity seems dead upstream the last commit is from 2012, 
> > shall we remove it?
> 
> What a coincidence that you should ask today - same exact day that a new 
> release of Squeak Etoys was released after 10 years of development: 
> http://www.squeakland.org/download/
> 
> So no, I think the package should not be removed but upgraded :-)
> 
> Thanks for asking, though - it is tricky to keep track of the Etoys and 
> Squeak and Sugarlabs and OLPC resources, it is as if each fraction 
> considers itself the center piece and does not reference activities 
> happening at the other parts.  I could easily have missed this 
> announcement if you hadn't asked about it.

...also, I see now that sugar-etoys-activity specifically (i.e. a thin 
wrapper to load Squeak Etoys itself) is just 2 lines of python.  I think 
even I can manage to migrate that to Python3 ;-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#938587: sugar-etoys-activity: Python2 removal in sid/bullseye

2020-06-06 Thread Jonas Smedegaard
[ sent again, with 7bit headers to please Debian MTAs ]

Hi Moritz,

Quoting Moritz Mühlenhoff (2020-06-06 16:34:38)
> sugar-etoys-activity seems dead upstream the last commit is from 2012, 
> shall we remove it?

What a coincidence that you should ask today - same exact day that a new 
release of Squeak Etoys was released after 10 years of development: 
http://www.squeakland.org/download/

So no, I think the package should not be removed but upgraded :-)

Thanks for asking, though - it is tricky to keep track of the Etoys and 
Squeak and Sugarlabs and OLPC resources, it is as if each fraction 
considers itself the center piece and does not reference activities 
happening at the other parts.  I could easily have missed this 
announcement if you hadn't asked about it.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#962356: RM: ovirt-guest-agent -- RoM; abandoned upstream and Python 2 only

2020-06-06 Thread GCS
Package: ftp.debian.org
Severity: normal
Usertags: rm

Hi,

ovirt-guest-agent is superseded by qemu-guest-agent and Python 2 only.
No reason to keep it in the archives any more.

Regards,
Laszlo/GCS



Bug#962355: RM: cvs2svn -- RoM; abandoned upstream and Python 2 only

2020-06-06 Thread GCS
Package: ftp.debian.org
Severity: normal
Usertags: rm

Hi,

cvs2svn was to convert CVS repositories to Subversion or Git. Upstream
no longer develops it unfortunately. It also remained Python 2 only. I
don't see it moving forward and anyone wanted to switch to a modern
SCM could do it for years.
Please remove it from the archives.

Regards,
Laszlo/GCS



Bug#942980: cvs2svn: Python2 removal in sid/bullseye

2020-06-06 Thread GCS
Hi Moritz,

On Sat, Jun 6, 2020 at 4:33 PM Moritz Mühlenhoff  wrote:
> On Wed, Oct 23, 2019 at 02:33:21AM +, mo...@debian.org wrote:
> > Source: cvs2svn
> > Usertags: py2removal
[...]
> http://cvs2svn.tigris.org/ vanished off the net and 
> https://pypi.org/project/cvs2svn
> shows the last release from 2009.
 Indeed, the official page is taken down.

> Let's remove? If there's really anyone who wants to migrate an old CVS repo 
> to SVN,
> they can still do it in a VM using an older release.
 I got a promise from one of its developers that development will
continue and it will be Python 3-ified. Its source was moved
(mirrored) to GitHub [1] and it might have unreleased changes already.
Still, I don't see any attempt to make it work with Python 3 so you
are probably correct. If anyone wanted to migrate their CVS tree to
Subversion or Git already had years for that.
Going to ask for its removal.

Regards,
Laszlo/GCS
[1] https://github.com/mhagger/cvs2svn



Bug#906765: libxsmm: baseline violation on amd64 and FTBFS everywhere else

2020-06-06 Thread Moritz Mühlenhoff
On Mon, Aug 20, 2018 at 10:26:03PM +0300, Adrian Bunk wrote:
> Source: libxsmm
> Version: 1.9-1
> Severity: serious
> Tags: ftbfs patch
> 
> libxsmm builds with -msse4.2 on amd64 and FTBFS everywhere else:
> https://buildd.debian.org/status/package.php?p=libxsmm=sid
> 
> Fix for the baseline violation:
> 
> --- debian/rules.old  2018-08-19 15:06:38.277886761 +
> +++ debian/rules  2018-08-19 15:08:40.141885599 +
> @@ -3,6 +3,8 @@
>  
>  export PREFIX=/usr
>  
> +export TARGET=-""
> +
>  %:
>   dh $@
>  
> 
> 
> The FTBFS problems on !amd64 don't seem easily fixable,
> and it is unclear whether this would be worth the effort.
> If fixing is not easily possible, an option would be
>   Architecture: any-amd64

There was no followup to this since almost two years or any of the other bugs,
should libxsmm be removed?

Cheers,
Moritz



Bug#890538: I seem to have stolen your package name

2020-06-06 Thread Gard Spreemann
Hello,

When I filed #961784 I did not notice this RFP. This resulted in me
accidentally stealing the package name "hera" for an entirely unrelated
package [1]. Sorry about this!

[1] https://tracker.debian.org/pkg/hera

 Best,
 Gard
 


signature.asc
Description: PGP signature


Bug#962324: gettext-el: confused with comment line containing 2 double-quote characters

2020-06-06 Thread Vincent Lefevre
Control: tags -1 fixed-upstream

On 2020-06-06 12:13:17 +0200, Vincent Lefevre wrote:
> In a .po file, a line starting with # and containing (at least)
> 2 double-quote characters is not regarded as a comment.

It has just been fixed:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=71021c8633b276772cb75ec7705ddb2845df1ff9

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



Bug#962354: pristine-tar: pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz

2020-06-06 Thread Andrea Bolognani
Package: pristine-tar
Version: 1.47
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

I ran into this issue while trying to import the latest upstream
version for libvirt:

  $ gbp import-orig --verbose --no-rollback --debian-branch debian/experimental 
../libvirt_6.4.0.orig.tar.xz
  gbp:debug: ['git', 'rev-parse', '--show-cdup']
  gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
  gbp:debug: ['git', 'rev-parse', '--git-dir']
  gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
  gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream/latest']
  gbp:debug: ['git', 'status', '--porcelain']
  gbp:debug: Signature ../libvirt_6.4.0.orig.tar.xz found for 
../libvirt_6.4.0.orig.tar.xz.asc
  What is the upstream version? [6.4.0] 
  gbp:debug: ['git', 'tag', '-l', 'upstream/6.4.0']
  gbp:debug: tar ['-C', '../tmp8pliau55', '-a', '-xf', 
'../libvirt_6.4.0.orig.tar.xz'] []
  gbp:debug: Unpacked '../libvirt_6.4.0.orig.tar.xz' to 
'../tmp8pliau55/libvirt-6.4.0'
  gbp:info: Importing '../libvirt_6.4.0.orig.tar.xz' to branch 
'upstream/latest'...
  gbp:info: Source package is libvirt
  gbp:info: Upstream version is 6.4.0
  gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream/latest']
  gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream/latest']
  gbp:debug: ['git', 'add', '-f', '.']
  gbp:debug: ['git', 'write-tree']
  gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream/latest']
  gbp:debug: ['git', 'commit-tree', '5d1f17e4035e01548d006d598922650408f56703', 
'-p', '1b6982f1b5d95a81eef1a112d0b1b228d7f910b2']
  gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 6.4.0', 
'refs/heads/upstream/latest', '46f45a63850c420af231a5c4186c5f9187c6b9b4', 
'1b6982f1b5d95a81eef1a112d0b1b228d7f910b2']
  gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
  gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar']
  gbp:debug: ['git', 'ls-tree', '-z', 'upstream/latest', '--']
  gbp:debug: ['git', 'mktree', '-z']
  gbp:debug: pristine-tar [] ['--help']
  gbp:debug: pristine-tar [] ['commit', '../libvirt_6.4.0.orig.tar.xz', 
'5d1f17e4035e01548d006d598922650408f56703', '-s', 
'../libvirt_6.4.0.orig.tar.xz.asc']
  gbp:error: Import of ../libvirt_6.4.0.orig.tar.xz failed: Couldn't commit to 
'pristine-tar' with upstream '5d1f17e4035e01548d006d598922650408f56703': 
pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz
  (Please file a bug report.)
  pristine-tar: failed to generate delta
  gbp:debug: rm ['-rf', '../tmp8pliau55'] []

Running pristine-tar again manually, to gather more information:

  $ pristine-tar --verbose --debug commit ../libvirt_6.4.0.orig.tar.xz 
5d1f17e4035e01548d006d598922650408f56703 -s ../libvirt_6.4.0.orig.tar.xz.asc
  pristine-tar: git archive --format=tar 
5d1f17e4035e01548d006d598922650408f56703 | (cd '/tmp/pristine-tar.zknL0MQpcM' 
&& tar x)
  pristine-tar: set subdir to libvirt-6.4.0
  pristine-tar: subdir is libvirt-6.4.0
  pristine-tar: mkdir /tmp/pristine-tar.R46gh49xSl/workdir
  pristine-tar: mv /tmp/pristine-tar.zknL0MQpcM 
/tmp/pristine-tar.R46gh49xSl/workdir/libvirt-6.4.0
  pristine-tar: tar cf /tmp/pristine-tar.R46gh49xSl/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.R46gh49xSl/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.R46gh49xSl/manifest
  pristine-tar: pristine-xz -v -d --no-keep gendelta 
../libvirt_6.4.0.orig.tar.xz /tmp/pristine-tar.bXsstH80WF/wrapper
  pristine-xz: pixz -d < ../libvirt_6.4.0.orig.tar.xz > 
/tmp/pristine-tar.ULPnMKQoAx/test
  pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz
  (Please file a bug report.)
  pristine-tar: failed to generate delta

Downgrading pristine-tar to 1.46 from buster makes it possible to run
gbp import-orig successfully, at which point both 1.46 and 1.47 are
able to regenerate the tarball from the git branch.

The Debian repository for libvirt is

  https://salsa.debian.org/libvirt-team/libvirt/

and the commits the various branches were pointing to when I
encountered the issue are

  pristine-tar9964e57257 pristine-tar data for libvirt_6.2.0.orig.tar.xz
  upstream/latest 1b6982f1b5 New upstream version 6.2.0
  debian/experimental 51d88f1e6f Document changes and release 6.2.0-1

The tarball I was trying to import is

  https://libvirt.org/sources/libvirt-6.4.0.tar.xz

but I tried libvirt 6.3.0 as well and got the same results. A couple
of months ago, when I imported libvirt 6.2.0, and indeed all the many
times I used gbp import-orig before now, everything worked smoothly.

In fact, I might 

Bug#936503: Anybody volunteering to try to save falcon in Debian (Was: Bug#936503: falcon: Python2 removal in sid/bullseye)

2020-06-06 Thread Andreas Tille
Hi,

On Sat, Jun 06, 2020 at 04:31:38PM +0200, Moritz Mühlenhoff wrote:
> > 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.
> 
> It appears this was turned non-free, they only distribute binaries and even 
> those are still dependant
> on Python 2: https://github.com/PacificBiosciences/FALCON_unzip/wiki/Binaries

Argh.
 
> | Which binary do I need?
> | 
> | That depends on your python2.7 Unicode size. Almost certainly, you want 
> "ucs4", but you can check this way:
> | 
> | python2.7 -c 'import sysconfig,pprint; 
> pprint.pprint(sysconfig.get_config_vars()["Py_UNICODE_SIZE"])'
> | 
> | (We do not support python3.)
> 
> So let's remove it from the archive?

Any reader of the Debian Med list who wants to spent time to discuss this
with upstream to save falcon in Debian?

Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#962353: Build-depends on phantom, which is being removed

2020-06-06 Thread Moritz Muehlenhoff
Source: django-js-reverse
Severity: serious

phantomjs is being removed (962061), but django-js-reverse currently 
build-depends
on it.

It doesn't actually appear to be used anyway:

| override_dh_auto_test:
|echo "tests require phantomjs harness which setup.py does not start"

Cheers,
Moritz



Bug#962268: [Debichem-devel] Bug#962268: ITP: pymatgen -- Python Materials Genomics for materials analysis

2020-06-06 Thread Drew Parsons

On 2020-06-06 17:27, Drew Parsons wrote:


Feel free to get the dependencies in place if there are any!




monty and palettable marked as Needed.

Some existing packages need upgrades. Versioned Build-Deps in place,
https://salsa.debian.org/debichem-team/pymatgen


Beyond that, there are a handful of optional Dependencies not yet 
packaged:

  chemview
  fdint
  phonopy
  BoltzTraP2
  f90nml
  hiphive
  seekpath



Bug#938587: sugar-etoys-activity: Python2 removal in sid/bullseye

2020-06-06 Thread Moritz Mühlenhoff
On Fri, Aug 30, 2019 at 07:54:24AM +, Matthias Klose wrote:
> Package: src:sugar-etoys-activity
> Version: 116-7
> 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

Hi,
sugar-etoys-activity seems dead upstream the last commit is from 2012, shall we 
remove it?

Cheers,
Moritz



Bug#962352: libmodbus5: when compile, complier said the library version was wrong and deny link.

2020-06-06 Thread Michael Fang
Package: libmodbus5
Version: 3.1.4-2
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
when I try to compile example programs in the package.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
compile stop
   * What outcome did you expect instead?
I try to get newest version 3.1.6 and make install then it can work.
*** End of the template - remove these template lines ***


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

Kernel: Linux 4.19.0-8-rt-amd64 (SMP w/2 CPU cores; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to zh_TW.UTF8), LANGUAGE=zh_TW:zh (charmap=UTF-8) (ignored: LC_ALL set to 
zh_TW.UTF8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmodbus5 depends on:
ii  libc6  2.28-10

libmodbus5 recommends no packages.

libmodbus5 suggests no packages.



Bug#942980: cvs2svn: Python2 removal in sid/bullseye

2020-06-06 Thread Moritz Mühlenhoff
On Wed, Oct 23, 2019 at 02:33:21AM +, mo...@debian.org wrote:
> Source: cvs2svn
> Version: 2.5.0-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

Hi,
http://cvs2svn.tigris.org/ vanished off the net and 
https://pypi.org/project/cvs2svn
shows the last release from 2009.

Let's remove? If there's really anyone who wants to migrate an old CVS repo to 
SVN,
they can still do it in a VM using an older release.

Cheers,
Moritz



Bug#936503: falcon: Python2 removal in sid/bullseye

2020-06-06 Thread Moritz Mühlenhoff
On Fri, Aug 30, 2019 at 07:16:54AM +, Matthias Klose wrote:
> Package: src:falcon
> Version: 1.8.8-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

It appears this was turned non-free, they only distribute binaries and even 
those are still dependant
on Python 2: https://github.com/PacificBiosciences/FALCON_unzip/wiki/Binaries

| Which binary do I need?
| 
| That depends on your python2.7 Unicode size. Almost certainly, you want 
"ucs4", but you can check this way:
| 
| python2.7 -c 'import sysconfig,pprint; 
pprint.pprint(sysconfig.get_config_vars()["Py_UNICODE_SIZE"])'
| 
| (We do not support python3.)

So let's remove it from the archive?

Cheers,
Moritz




Bug#962350: /etc/init.d/checkfs.sh is not very robust, and fails on missing filesystems.

2020-06-06 Thread Brad Lanam
Package: bugs.debian.org
Severity: normal

/etc/init.d/checkfs.sh is failing on boot and stopping the boot
process.

/etc/init.d/checkfs.sh fails when trying to check a non-existent
filesystem.  Apparently it is trying to run a fsck on a filesystem that was
removed.

As I recall, it fails even when the VFAT filesystem
was present.   I will have to re-create the VFAT filesystem
and see what the log says.


/var/log/fsck/checkfs:

Log of fsck -C -M -A -a
Sat Jun  6 06:51:27 2020

fsck from util-linux 2.33.1
homeMX has been mounted 1 times without being checked, check forced.
homeMX: 131136/41476096 files (7.2% non-contiguous), 39715768/165877760 blocks
open: No such file or directory
fsck.fat 4.1 (2017-01-24)
fsck exited with status code 6

Sat Jun  6 06:51:37 2020



/etc/fstab:
- xfer currently does not exist

# Pluggable devices are handled by uDev, they are not in fstab
UUID=a6b5153a-b005-4ba0-b881-7a03100f80f2 / ext4 defaults,noatime 1 1
UUID=4655-C743 /boot/efi vfat defaults,noatime,dmask=0002,fmask=0113 0 0
UUID=475970aa-a5cf-497d-bfc6-b819830ae21e /home ext4 defaults,noatime 1 2
UUID=415e668d-761b-447b-b3ca-fda9c200cbb6 swap swap defaults 0 0
UUID=149C-3ABF /xfer vfat rw,users,umask=000,noatime 1 2

/ramdisk   /ramdisktmpfs   defaults,size=256m  0 1




[code]

System:
  Host: bll-g7 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0
  parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64
  root=UUID=a6b5153a-b005-4ba0-b881-7a03100f80f2 ro quiet nosplash
  mem_sleep_default=deep
  Desktop: Xfce 4.14.2 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm4
  dm: LightDM 1.26.0 Distro: MX-19.2_x64 patito feo October 21  2019
  base: Debian GNU/Linux 10 (buster)
Machine:
  Type: Laptop System: Dell product: G7 7590 v: N/A serial: 
  Chassis: type: 10 serial: 
  Mobo: Dell model: 0CNDTP v: A01 serial:  UEFI: Dell v: 1.12.0
  date: 02/07/2020
Battery:
  ID-1: BAT0 charge: 58.0 Wh condition: 58.0/60.0 Wh (97%) volts: 16.8/15.2
  model: BYD DELL HYWXJ99 type: Li-poly serial:  status: Full
CPU:
  Topology: 6-Core model: Intel Core i7-9750H bits: 64 type: MT MCP
  arch: Kaby Lake family: 6 model-id: 9E (158) stepping: A (10)
  microcode: CA L2 cache: 12.0 MiB
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  bogomips: 62208
  Speed: 900 MHz min/max: 800/4500 MHz Core speeds (MHz): 1: 900 2: 900
  3: 900 4: 900 5: 900 6: 900 7: 900 8: 900 9: 900 10: 900 11: 900 12: 900
  Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages
  Type: l1tf
  mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable
  Type: meltdown mitigation: PTI
  Type: spec_store_bypass
  mitigation: Speculative Store Bypass disabled via prctl and seccomp
  Type: spectre_v1
  mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional,
  IBRS_FW, STIBP: conditional, RSB filling
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel UHD Graphics 630 vendor: Dell driver: i915 v: kernel
  bus ID: 00:02.0 chip ID: 8086:3e9b
  Device-2: NVIDIA TU106M [GeForce RTX 2060 Mobile] vendor: Dell
  driver: nvidia v: 440.36 bus ID: 01:00.0 chip ID: 10de:1f11
  Display: x11 server: X.Org 1.20.4 driver: modesetting,nvidia
  resolution: 1920x1080~144Hz
  OpenGL: renderer: GeForce RTX 2060/PCIe/SSE2 v: 4.6.0 NVIDIA 440.36
  direct render: Yes
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: Dell driver: snd_hda_intel
  v: kernel bus ID: 00:1f.3 chip ID: 8086:a348
  Device-2: Logitech type: USB driver: hid-generic,snd-usb-audio,usbhid
  bus ID: 1-4.2:7 chip ID: 046d:0a8f
  Sound Server: ALSA v: k4.19.0-6-amd64
Network:
  Device-1: Realtek vendor: Dell driver: r8169 v: kernel port: 3000
  bus ID: 3c:00.0 chip ID: 10ec:2502
  IF: eth0 state: up speed: 1000 Mbps duplex: full mac: 
  Device-2: Intel Wireless-AC 9260 vendor: Bigfoot Networks driver: iwlwifi
  v: kernel port: 3000 bus ID: 3d:00.0 chip ID: 8086:2526
  IF: wlan0 state: up mac: 
Drives:
  Local Storage: total: 1.14 TiB used: 148.92 GiB (12.7%)
  ID-1: /dev/nvme0n1 vendor: SK Hynix model: BC501 NVMe 256GB
  size: 238.47 GiB block size: physical: 512 B logical: 512 B
  speed: 15.8 Gb/s lanes: 2 serial:  rev: 80002C00 scheme: GPT
  ID-2: /dev/sda vendor: Toshiba model: MQ04ABF100 size: 931.51 GiB
  block size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s
  rotation: 5400 rpm serial:  rev: 0D temp: 34 C scheme: GPT
Partition:
  ID-1: / raw size: 19.53 GiB size: 19.10 GiB (97.79%)
  used: 8.28 GiB (43.3%) fs: ext4 dev: /dev/nvme0n1p7
  ID-2: /home raw size: 632.77 GiB size: 621.84 GiB (98.27%)
  used: 140.58 GiB (22.6%) fs: ext4 dev: /dev/sda4
  ID-3: swap-1 size: 20.00 GiB used: 0 KiB (0.0%) fs: swap
  swappiness: 15 (default 60) cache pressure: 100 (default)
  dev: /dev/nvme0n1p9
Sensors:
  System Temperatures: cpu: 59.0 C mobo: N/A gpu: nvidia temp: 46 C
  Fan Speeds 

Bug#962351: RM: nfqueue-bindings -- RoQA; RC-buggy, unmaintained

2020-06-06 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove nfqueue-bindings. Upstream has vanished, it FTBFSes for almost
two years, there was no reaction to any of the RC bugs and the last maintainer
upload was in 2016.

Cheers,
Moritz



Bug#962348: kig: boost1.67 is being removed from testing

2020-06-06 Thread Dimitri John Ledkov
Package: kig
Version: 4:20.04.1-1
Severity: serious

Hi,

boost1.67 is being removed from testing and is transitioning to boost1.71.
kig has just now switched from boost1.71 to boost1.67.
boost1.67 must not be shipped in testing.
Thus I am opening this bug report to prevent kig from migrating.

boost1.71 does not offer python2 bindings, as python2 is being removed to.

I understand that kig is using boost-python2. Either please disable python 
bindings usage at build time, or try to port to boost-python3?

Either way, introducing python2 & boost1.67 usage in testing is working against 
release goals of not shipping python2 or boost1.67.

Also in Ubuntu, kig is the only package using boost1.67

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

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

Versions of packages kig depends on:
ii  libboost-python1.67.0 [libboost-python1.67.0-py27]  1.67.0-17ubuntu8
ii  libc6   2.31-0ubuntu9
ii  libgcc-s1   10.1.0-3ubuntu1
ii  libkf5archive5  5.70.0-0ubuntu1
pn  libkf5completion5   
ii  libkf5configcore5   5.70.0-0ubuntu1
ii  libkf5configwidgets55.70.0-0ubuntu1
ii  libkf5coreaddons5   5.70.0-0ubuntu1
ii  libkf5crash55.70.0-0ubuntu1
ii  libkf5i18n5 5.70.0-0ubuntu1
ii  libkf5iconthemes5   5.70.0-0ubuntu1
pn  libkf5parts5
pn  libkf5service-bin   
pn  libkf5service5  
pn  libkf5texteditor5   
ii  libkf5widgetsaddons55.70.0-0ubuntu1
pn  libkf5xmlgui-bin
pn  libkf5xmlgui5   
ii  libpython2.72.7.18-1
ii  libqt5core5a5.14.2+dfsg-2ubuntu1
ii  libqt5gui5  5.14.2+dfsg-2ubuntu1
ii  libqt5printsupport5 5.14.2+dfsg-2ubuntu1
ii  libqt5svg5  5.14.2-1
ii  libqt5widgets5  5.14.2+dfsg-2ubuntu1
ii  libqt5xml5  5.14.2+dfsg-2ubuntu1
ii  libqt5xmlpatterns5  5.14.2-1
ii  libstdc++6  10.1.0-3ubuntu1
ii  python3 3.8.2-0ubuntu2

kig recommends no packages.

Versions of packages kig suggests:
pn  khelpcenter  



Bug#960539: RFP: hydrogen -- advanced drum machine/step sequencer repackaging

2020-06-06 Thread Alexandre Lymberopoulos
On Jun 04 2020, Nicholas D Steeves wrote:
> Hi Alexandre,

Hi Nicholas!

I was able to compile the package here, and the sample files played
perfectly. I tested both jack and alsa driver with good results!The only
downside was that I got a segfault, while trying to export the song as
an ogg file (as flac eveything was ok).

Next step is to find my Rock band generic drumpads to test MIDI input.

> https://salsa.debian.org/multimedia-team/hydrogen.git
> https://salsa.debian.org/multimedia-team/hydrogen

Sorry again for the naive comments, but I cloned the project above and
followed the steps there to build the package, purged all the hydrogen
and qt4 old packages, installed the new one with dpkg and it worked as I
said above.

> https://drive.google.com/drive/folders/1j506Sn2Ur1_Cue1WTJUKgYmPcQW6qZsh?usp=sharing
 
> Of the debs you'll need libhydrogen-core-1.0.0, hydrogen-data, and of
> course hydrogen.  I've provided the source package .build and .buildinfo
> as well for the sake of transparency.

Should I install those debs instead the one I build here? "Mine"
building process resulted in just 2 debs (hydrogen_1.0.0-beta_amd64.deb
and hydrogen-dbgsym_1.0.0-beta_amd64.deb). I installed the first the one
(that is much bigger in disk size than yours).

> You're welcome :-)  'hope those patches were truly no longer necessary
> and that this beta2 release is already functional.

Probably, since my "just pushing buttons" compilation/building
process here produced a functional binary. :)

Please let me know if I should remove my packages and test your from
Google Drive.

> Cheers,
> Nicholas

Cheers!
-- 
===
Alexandre Lymberopoulos - lym...@ime.usp.br - http://www.ime.usp.br/~lymber
Instituto de Matemática e Estatística - Universidade de São Paulo
===



Bug#962347: RFS: austin/1.0.1-2 [RC] -- Frame stack sampler for CPython

2020-06-06 Thread Gabriele
Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: austin
   Version : 1.0.1-2
   Upstream Author : Gabriele N. Tornetta 
 * URL : https://github.com/P403n1x87/austin
 * License : GPL-3+
 * Vcs : https://github.com/P403n1x87/austin
   Section : devel

It builds those binary packages:

  austin - Frame stack sampler for CPython

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/austin/austin_1.0.1-2.dsc

Changes since the last upload:

   Enhanced test sources. Closes: #962001.

Regards,

--
  Gabriele N. Tornetta



Bug#962346: CVE-2020-0181

2020-06-06 Thread Moritz Muehlenhoff
Source: libexif
Severity: important
Tags: security

Similar to CVE-2020-0198, another issue reported/fixed in Android, but not
applied upstream:
https://android.googlesource.com/platform/external/libexif/+/f6c54954cbfc25eb73d2d2902f0597c0220174a4

Cheers,
Moritz



Bug#962341: Acknowledgement (ITP: ruamel.yaml.clib -- C based reader/scanner and emitter for ruamel.yaml)

2020-06-06 Thread Drew Parsons

Control: merge 955282 962341
thanks

Sorry, didn't check soon enough, Michael Crusoe is already working on 
ruamel.yaml.clib.


Drew



Bug#962345: CVE-2020-0198

2020-06-06 Thread Moritz Muehlenhoff
Source: libexif
Severity: important

The latest Android security bulletin for Pixel phones included a patch for 
libexif,
which was assigned CVE-2020-0198:
https://android.googlesource.com/platform/external/libexif/+/1e187b62682ffab5003c702657d6d725b4278f16

The patch in their repo is from March, but doesn't appear to have been merged
into the libexif tree yet (not sure if it was actually submitted or not).

Cheers,
Moritz



Bug#962344: gimp: resynthesizer depends on gimp-python which is not available

2020-06-06 Thread william
Package: gimp
Version: 2.10.18-1
Severity: minor

Dear Maintainer,

Similar to #907178, the "Heal" filter cannot be accessed since gimp-python is
not available.



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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.18-1
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.74-1
ii  libbz2-1.0   1.0.8-3
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libgcc-s110.1.0-3
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libgegl-0.4-00.4.22-3
ii  libgexiv2-2  0.12.0-2
ii  libgimp2.0   2.10.18-1
ii  libglib2.0-0 2.64.3-1
ii  libgs9   9.52~dfsg-1
ii  libgtk2.0-0  2.24.32-4
ii  libgudev-1.0-0   233-1
ii  libharfbuzz0b2.6.4-1+b1
ii  libheif1 1.6.1-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjson-glib-1.0-0   1.4.4-2
ii  liblcms2-2   2.9-4+b1
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.1-1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpangoft2-1.0-01.44.7-4
ii  libpng16-16  1.6.37-2
ii  libpoppler-glib8 0.71.0-6
ii  librsvg2-2   2.48.4+dfsg-1
ii  libstdc++6   10.1.0-3
ii  libtiff5 4.1.0+git191117-2
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-17
ii  libx11-6 2:1.6.9-2+b1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-2
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-2
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages gimp recommends:
ii  ghostscript  9.52~dfsg-1

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
ii  gvfs-backends 1.44.1-1
ii  libasound21.2.2-2.1

-- no debconf information



Bug#953637: debootstrap remove /proc when ran under docker

2020-06-06 Thread Eicke Herbertz
I assume you used a privileged container, I can't reproduce this with an
unprivileged one with only CAP_SYS_ADMIN added.

After some digging, the issue appears to come from here:
https://salsa.debian.org/installer-team/debootstrap/-/blob/master/functions#L1179

> umount "$TARGET/proc" 2>/dev/null || true

As far as git can tell, this is an ancient line. As $TARGET/proc is a
symlink to /proc, the umount usually fails with a "target is busy"
error, which is ignored. In a privileged container however, one can
umount /proc and render the system unusable.

Is this line even needed in the first place? If it can't be removed, it
should at least only be executed if $TARGET/proc isn't a symlink to
/proc. I don't see a scenario where unmounting hosts /proc would be valid.



signature.asc
Description: OpenPGP digital signature


Bug#962343: colord: incompatibility between 'colord' and 'VNC'?

2020-06-06 Thread clohr
Package: colord
Version: 1.4.4-2
Severity: minor
Tags: upstream

Dear Maintainer,
  Each time I open my MATE session remotely (via VNC), I get two popup asking
me to re-enter my password for colord
System Color Manager
org.freedesktop.color-manager-create-profile
org.freedesktop.color-manager.create-device

When I googling this bug I can see workarounds proposing to trick policykit.
So, I wonder if this is the right way to fix it.
Is it just the matter of a misconfigured policykit file in the package, or
something more complicated such as a lacking profile for the vnc display?

Best regards
Christophe



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

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

Versions of packages colord depends on:
ii  acl  2.2.53-8
ii  adduser  3.118
ii  colord-data  1.4.4-2
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libc62.30-8
ii  libcolord2   1.4.4-2
ii  libcolorhug2 1.4.4-2
ii  libdbus-1-3  1.12.16-2
ii  libglib2.0-0 2.64.2-1
ii  libgudev-1.0-0   233-1
ii  libgusb2 0.3.4-0.2
ii  liblcms2-2   2.9-4+b1
ii  libpolkit-gobject-1-00.105-26
ii  libsane  1.0.27-3.2+b1
ii  libsqlite3-0 3.31.1-5
ii  libsystemd0  245.5-3
ii  policykit-1  0.105-26

colord recommends no packages.

Versions of packages colord suggests:
pn  colord-sensor-argyll  

-- no debconf information



Bug#962341: ITP: ruamel.yaml.clib -- C based reader/scanner and emitter for ruamel.yaml

2020-06-06 Thread Drew Parsons
Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: ruamel.yaml.clib
  Version : 0.2.0
  Upstream Author : Anthon van der Neut 
* URL : https://sourceforge.net/projects/ruamel-yaml-clib/
* License : MIT
  Programming Lang: Python/C
  Description : C based reader/scanner and emitter for ruamel.yaml

This package was split of from ruamel.yaml, so that ruamel.yaml can be
build as a universal wheel. Apart from the C code seldom changing, and
taking a long time to compile for all platforms, this allows
installation of the .so on Linux systems under /usr/lib64/pythonX.Y
(without a .pth file or a ruamel directory) and the Python code for
ruamel.yaml under /usr/lib/pythonX.Y.

Required by ruamel.yaml >= 0.16.8.

To be maintained by the Python Modules Team.



Bug#953637: debootstrap remove /proc when ran under docker

2020-06-06 Thread Eicke Herbertz
I assume you used a privileged container, I can't reproduce this with an
unprivileged one with only CAP_SYS_ADMIN added.

After some digging, the issue appears to come from here:
https://salsa.debian.org/installer-team/debootstrap/-/blob/master/functions#L1179

> umount "$TARGET/proc" 2>/dev/null || true

As far as git can tell, this is an ancient line. As $TARGET/proc is a
symlink to /proc, the umount usually fails with a "target is busy"
error, which is ignored. In a privileged container however, one can
umount /proc and render the system unusable.

Is this line even needed in the first place? If it can't be removed, it
should at least only be executed if $TARGET/proc isn't a symlink to
/proc. I don't see a scenario where unmounting hosts /proc would be valid.



signature.asc
Description: OpenPGP digital signature


Bug#962342: libexplain-dev: missing dependency on libacl1-dev

2020-06-06 Thread Lars Stoltenow
Package: libexplain-dev
Version: 1.4.D001-10
Severity: normal

Dear Maintainer,

the libexplain-dev package should possibly have a dependency on libacl1-dev,
as its headers use the sys/acl.h header that is provided by it.

More specifically, compiling a program with (not much more than)
  #include 
fails with
  In file included from /usr/include/libexplain/libexplain.h:38,
   from expl.c:12:
  /usr/include/libexplain/acl_from_text.h:33:10: fatal error: sys/acl.h: No 
such file or directory
   #include 
^~~

By installing libacl1-dev, the error is resolved and the package can be used
as expected.


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

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
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 libexplain-dev depends on:
ii  libexplain51  1.4.D001-10
ii  lsof  4.91+dfsg-1

libexplain-dev recommends no packages.

libexplain-dev suggests no packages.

-- no debconf information



Bug#958746: libconfig-model-dpkg-perl: URLs in patch descriptions mangled (treated as fields?)

2020-06-06 Thread Dominique Dumont
On Fri, 24 Apr 2020 17:05:50 -0500 Ryan Pavlik  wrote:
> After modifying that patch, the description is mangled:
> the URL is moved above the rest of the description and separated by blank 
lines,
> and there is a space inserted after https:

Even though mulit lines subjects are not allowed, I'm going to update cme so 
that subject lines are concatenated back together. That's better than shuffling 
lines around.

All the best

Dod



Bug#962332: ansible: needs python3-distutils, at least for the chroot connection module

2020-06-06 Thread Andrei POPESCU
Control: fixed -1 2.9.6+dfsg-1

On Sb, 06 iun 20, 14:32:17, Andrei POPESCU wrote:
> 
> In case I got the BTS syntax wrong I will fix the versioning info after 
> receiving the acknowledgement mail.

Doing so now (really).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Bug#962340: RFP: python3-palettable -- a library of color palettes for Python

2020-06-06 Thread Drew Parsons
Package: wnpp
Severity: wishlist
Control: block 962268 by -1

* Package name: python3-palettable
  Version : 3.3.0
  Upstream Author : Matt Davis
* URL : https://jiffyclub.github.io/palettable/
* License : MIT-like
  Programming Lang: Python
  Description : a library of color palettes for Python

Palettable (formerly brewer2mpl) is a library of color palettes for
Python. It's written in pure Python with no dependencies, but it can
supply color maps for matplotlib. You can use Palettable to customize
matplotlib plots or supply colors for a web application.

Required by pymatgen.

To be team maintained under the Python Modules Team.



Bug#962339: decopy: breaks when DEP5 copyright file is incomplete

2020-06-06 Thread Jelmer Vernooij
Package: decopy
Version: 0.2.4.3-0.1
Severity: normal

decopy currently breaks when trying to parse any copyright file
that uses the DEP5 format but is incomplete. For example, this copyright
file:

``
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Files: *
License: Unknown

License: Unknown
``

results in:

Traceback (most recent call last):
  File "/usr/bin/decopy", line 11, in 
load_entry_point('Decopy==0.2.4.3', 'console_scripts', 'decopy')()
  File "/usr/lib/python3/dist-packages/decopy/decopy.py", line 57, in main
copyright_ = Copyright.build(filetree, options)
  File "/usr/lib/python3/dist-packages/decopy/dep5.py", line 62, in build
copyright_ = Copyright(c)
  File "/usr/lib/python3/dist-packages/debian/copyright.py", line 155, in 
__init__
pf = FilesParagraph(p, strict)
  File "/usr/lib/python3/dist-packages/debian/copyright.py", line 510, in 
__init__
_complain('Files paragraph missing Copyright field', strict)
  File "/usr/lib/python3/dist-packages/debian/copyright.py", line 84, in 
_complain
raise MachineReadableFormatError(msg)
debian.copyright.MachineReadableFormatError: Files paragraph missing Copyright 
field

Merge proposal in https://salsa.debian.org/debian/decopy/-/merge_requests/2 to 
address this.

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

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

Versions of packages decopy depends on:
ii  bzip2   1.0.8-3
ii  libimage-exiftool-perl  11.99-1
ii  python3 3.8.2-3
ii  python3-debian  0.1.37
ii  python3-xdg 0.26-3
ii  xz-utils5.2.4-1+b1

Versions of packages decopy recommends:
ii  python3-regex  0.1.20190819-2+b1
ii  python3-tqdm   4.43.0-1

decopy suggests no packages.

-- debconf-show failed

-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/decopy/dep5.py (from 
decopy package)



Bug#962338: RFP: monty -- the missing complement to Python

2020-06-06 Thread Drew Parsons
Package: wnpp
Severity: wishlist
Control: block 962268 by -1

* Package name: monty
  Version : 3.0.2
  Upstream Author : Materials Virtual Lab
* URL : https://github.com/materialsvirtuallab/monty
* License : MIT
  Programming Lang: Python
  Description : the missing complement to Python

Monty is the missing complement to Python. Monty implements
supplementary useful functions for Python that are not part of the
standard library. Examples include useful utilities like transparent
support for zipped files, useful design patterns such as singleton and
cached_class, and many more.

Python is a great programming language and comes with “batteries
included”. However, even Python has missing functionality and/or
quirks that make it more difficult to do many simple tasks. In the
process of creating several large scientific frameworks based on
Python, my co-developers and I have found that it is often useful to
create reusable utility functions to supplement the Python standard
library. Our forays in various developer sites and forums also found
that many developers are looking for solutions to the same problems.

Monty is created to serve as a complement to the Python standard
library. It provides suite of tools to solve many common problems, and
hopefully, be a resource to collect the best solutions.


Required dependency for pymatgen.

To be maintained under the Python Modules Team 
on behalf of the Debichem Team.


Bug#746415: Changing LANG is not a solution

2020-06-06 Thread graeme vetterlein

Is this defect being addressed, It seems to have been important for 6 years?

I am just hitting it in Debian buster (gdm3, gnome3) . I cannot set 
LANG= I must use LANG=C because it affects such things 
as sort order and only the C local has the semantic I need.


$ dpkg -l gnome-terminal
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---===
ii  gnome-terminal 3.30.2-2 amd64    GNOME terminal emulator 
application


I actually hit a different (gnome-terminal) bug, but then hit this one 
while debugging that:



$ env | grep LANG
LANGUAGE=en_GB:en
GDM_LANG=en_GB.UTF-8
LANG=en_GB.UTF-8



guest@real:~$ gnome-terminal
# watch_fast: "/org/gnome/desktop/interface/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/settings-daemon/peripherals/mouse/" 
(establishing: 0, active: 0)

# watch_fast: "/org/gnome/desktop/sound/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/desktop/privacy/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/desktop/wm/preferences/" (establishing: 0, 
active: 0)
# watch_fast: "/org/gnome/settings-daemon/plugins/xsettings/" 
(establishing: 0, active: 0)

# watch_fast: "/org/gnome/desktop/a11y/" (establishing: 0, active: 0)
# watch_established: "/org/gnome/desktop/interface/" (establishing: 1)
# watch_established: "/org/gnome/settings-daemon/peripherals/mouse/" 
(establishing: 1)

# watch_established: "/org/gnome/desktop/sound/" (establishing: 1)
# watch_established: "/org/gnome/desktop/privacy/" (establishing: 1)
# watch_established: "/org/gnome/desktop/wm/preferences/" (establishing: 1)
# watch_established: "/org/gnome/settings-daemon/plugins/xsettings/" 
(establishing: 1)

# watch_established: "/org/gnome/desktop/a11y/" (establishing: 1)
# watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)
# unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1)
# watch_established: "/org/gnome/terminal/legacy/" (establishing: 0)


... then terminal starts

root@real:~# cat /home/guest/set-C-locale
update-locale  LANG=C LANGUAGE

root@real:~# . /home/guest/set-C-locale

root@real:~# cat /etc/default/locale
#  File generated by update-locale
LANG=C
#LANGUAGE=en_GB:en


logoff , logon again (gdm3 + gnome3)

$ env | grep LANG
LANGUAGE=en_GB:en
GDM_LANG=C
LANG=C
$ gnome-terminal
# watch_fast: "/org/gnome/desktop/interface/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/settings-daemon/peripherals/mouse/" 
(establishing: 0, active: 0)

# watch_fast: "/org/gnome/desktop/sound/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/desktop/privacy/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/desktop/wm/preferences/" (establishing: 0, 
active: 0)
# watch_fast: "/org/gnome/settings-daemon/plugins/xsettings/" 
(establishing: 0, active: 0)

# watch_fast: "/org/gnome/desktop/a11y/" (establishing: 0, active: 0)
# watch_established: "/org/gnome/desktop/interface/" (establishing: 1)
# watch_established: "/org/gnome/settings-daemon/peripherals/mouse/" 
(establishing: 1)

# watch_established: "/org/gnome/desktop/sound/" (establishing: 1)
# watch_established: "/org/gnome/desktop/privacy/" (establishing: 1)
# watch_established: "/org/gnome/desktop/wm/preferences/" (establishing: 1)
# watch_established: "/org/gnome/settings-daemon/plugins/xsettings/" 
(establishing: 1)

# watch_established: "/org/gnome/desktop/a11y/" (establishing: 1)
# Error constructing proxy for 
org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling 
StartServiceByName for org.gnome.Terminal: Timeout was reached

$

Setting LANG=C is required to work by various standards, many other 
programs in order to get valid support data require to be run in C locale.


In my case I need emacs to be running under C locale ... so I cannot set 
it later e.g. in .bashrc






--


Graeme



Bug#962335: FTBFS: new upstream version available with bug fixes

2020-06-06 Thread Drew Parsons
Source: pandas
Version: 1.0.3+dfsg2-1
Severity: serious
Justification: FTBFS

pandas 1.0.3+dfsg2-1 fails to build from source, evidently due to new
DeprecationWarnings from jedi 1.17.0 interfering with
test_tab_complete_warning (tests/frame/test_api.py)

Upstream has patched it with #8af5625
https://github.com/pandas-dev/pandas/commit/8af5625bbd69e0fd1d3e9ca7b23267aababdee94

but probably better to apply the whole new upstream release (1.0.4)
than the individual patch.



Bug#962332: ansible: needs python3-distutils, at least for the chroot connection module

2020-06-06 Thread Andrei POPESCU
Control: fixed 2.9.6+dfsg-1

On Sb, 06 iun 20, 14:32:17, Andrei POPESCU wrote:
> 
> In case I got the BTS syntax wrong I will fix the versioning info after 
> receiving the acknowledgement mail.

Doing so now.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Bug#711285: 711285 ITA: flam3

2020-06-06 Thread Peter
Package: flam3
Retitle: 711285 ITA: flam3 -- render and animate FLAM3s and manipulate their 
genomes
Owner: 711285 !



Bug#962334: .key files not handled correctly in TSIG.pm in version 1.24

2020-06-06 Thread Wolfgang Walter
Package: libnet-dns-perl
Version: 1.24-1


Hello,

after upgrading from 1.23 to 1.24 I get the following error:

Use of uninitialized value $_[0] in join or string at 
/usr/share/perl5/Net/DNS/RR/TSIG.pm line 182.

when I call sign_tsig() with a .key file.

I think the reason is that .key files are now handled as .private file due to 
the new code in TSIG.pm, line 384:

 $filename =~ m/^K([^+]+)\+\d+\+\d+\./;  # BIND 
dnssec-keygen
my $key = $1;

if ( $key && $filename =~ /\.key$/ ) { 
  
If it is a .key file, $key will usually be undefined and the code path for 
handling .key files will therefore not be entered.

If I change the condition to

 if ( ! $key || $filename =~ /\.key$/ ) { 

sign_tsig() works fine again.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts



Bug#962321: RFS: git-subrepo/0.4.1~2 -- GIT Submodule alternative

2020-06-06 Thread Samo Pogačnik
Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "git-subrepo"

 * Package name: git-subrepo
   Version : 0.4.1~2
   Upstream Author : [Ingy dot Net ]
 * URL : [https://github.com/ingydotnet/git-subrepo]
 * License : [MIT]
 * Vcs : None
   Section : vcs

It builds those binary packages:

  git-subrepo - GIT Submodule alternative

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-subrepo/git-subrepo_0.4.1~2.dsc

Changes since the last upload:

   [ spog ]
   * Fixed reading installed subrepo command info.
   * Added subrepo to git completion commands
 .
   [ admorgan ]
   * Fix Bash version error messages and add to .rc
   * Nicer YAML formatting in .travis.yml
   * Wrap a long line
   * Update the docs
   * Force `make update` to always update docs
   * Don't use XXX in perl stuff
   * Add testing on MacOS
   * Remove conflicting -C from install -d commands.
   * Update version requirement documentation
   * Correct error message in branch
   * Use topo-order in subrepo branch
   * Make “git subrepo clean -f ...” delete refs correctly
   * Fix #410 Push empty repositories with recent git versions
   * Make subrepo work when run in a worktree
   * Simplify finding subrepos
   * Ask git to find the .gitrepo files
   * Doc: fix sentence repetition
   * Fix typos
   * Fixed typo
   * Travis CI not checking out a branch.

Regards,

--
  Samo Pogačnik



Bug#962091: RFS: xine-ui/0.99.12-1 [QA] -- xine video player, user interface

2020-06-06 Thread Adrian Bunk
Control: tags -1 moreinfo

On Wed, Jun 03, 2020 at 08:04:45AM +, Håvard Flaget Aasen wrote:
>...
> Changes since the last upload:
>...
>* d/rules
>  - Change to dh-sequence
>...
>* d/control
>...
>  - Remove unnecessary Depends field
>...

This was necessary, it was just broken by your debian/rules rewrite.
This RC regression can easily be reproduced with aaxine.

For the debian/rules change, please verify that the changed package
does not contain any unexpected changes from the original one.
This means first understanding what the old debian/rules did.
I can immediately find two things that were done in the old debian/rules
but are missing in the new one.

>* Add fix_spelling_error.patch
>...

This is a translated string, such a change breaks all translations of 
this string.

> Regards,
> Håvard

cu
Adrian



Bug#961442: libclamunrar 0.102.3-0+deb9u1 flagged for acceptance

2020-06-06 Thread Adam D Barratt
package release.debian.org
tags 961442 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libclamunrar
Version: 0.102.3-0+deb9u1

Explanation: new upstream stable release; add an unversioned meta-package



Bug#962155: ca-certificates 20200601~deb9u1 flagged for acceptance

2020-06-06 Thread Adam D Barratt
package release.debian.org
tags 962155 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: ca-certificates
Version: 20200601~deb9u1

Explanation: update Mozilla CA bundle to 2.40, blacklist distrusted Symantec 
roots and expired "AddTrust External Root"; remove e-mail only certificates



  1   2   >