Bug#959507: dub: diff for NMU version 1.19.0-1.1

[Adrian Bunk]

Control: tags 959507 + patch
Control: tags 959507 + pending

Dear maintainer,

I've prepared an NMU for dub (versioned as 1.19.0-1.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru dub-1.19.0/debian/changelog dub-1.19.0/debian/changelog
--- dub-1.19.0/debian/changelog	2020-01-12 02:04:18.0 +0200
+++ dub-1.19.0/debian/changelog	2020-06-16 09:55:55.0 +0300
@@ -1,3 +1,11 @@
+dub (1.19.0-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Add a needs-internet restriction to the autopkgtest.
+(Closes: #959507)
+
+ -- Adrian Bunk   Tue, 16 Jun 2020 09:55:55 +0300
+
 dub (1.19.0-1) unstable; urgency=medium
 
   [ Matthias Klumpp ]
diff -Nru dub-1.19.0/debian/tests/control dub-1.19.0/debian/tests/control
--- dub-1.19.0/debian/tests/control	2019-08-31 21:47:11.0 +0300
+++ dub-1.19.0/debian/tests/control	2020-06-16 09:55:52.0 +0300
@@ -1,2 +1,3 @@
 Tests: run
 Depends: dub
+Restrictions: needs-internet

Bug#962664: python3-distro: Please mark as Multi-Arch: foreign

[Mike Ricketts]

On Tue, 16 Jun 2020, Guillem Jover wrote:


An arch:all package by default is considered to be of the same
architecture as the native one. So yelp:amd64 depending on python3-distro
implies it wants python3-distro:amd64 which is not satisfied as it is
only evaluated as python3-distro:i386.

To tell the packaging system that this dependency is safe and truly
architecture independent, it needs to be marked as Multi-Arch: foreign.

OK I understand - thanks for explaining, and having read 
https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages

I can see the logic behind it (although it does feel counter intuitive).

Unfortunately python3-distro is by no means the only arch:all package that 
this affects - for example debconf also seems to be affected.


Is there any way to determine what the MultiArch: setting on an existing 
package is?


--
Mike Ricketts 

Q:  Why was Stonehenge abandoned?
A:  It wasn't IBM compatible.

Bug#956452: dpkg: Support for parallel decompression

[Sebastian Andrzej Siewior]

On 2020-06-16 03:36:22 [+0200], Guillem Jover wrote:
> Hi!
Hi,

> > I've been thinking about parallel decompression for dpkg/xz. Is there
> > any interest in doing this? I hacked parallel-unxz [0] in the meantime
> > to see what is missing from the API point of view (query block offsets
> > is missing).
> 
> I'm interested, but mainly if this is provided transparently by
> liblzma, in a similar way as it is currently provided for compression.

I dropped that idea because it was very complex.

> > My idea of accomplishing this is roughly the following:
> > During archive creation the output of tar is also analysed (like via
> > libarchive) in order to gain the start position of the files within the
> > uncompressed archive (which is something pixz does).
> 
> When I checked the implementation in pixz it looked not very efficient
> in terms of memory, AFAIR.

…

> The biggest issue is that the dpkg codebase is very much not
> thread-safe, so implementing this would imply either duplicating much
> of the existing infrastructure, such as using different error handling
> stuff, or to bolt this on top, which seems rather unappealing.
> 
> I've seen the discussion in the upstream list, and I'd really like to
> get this supported there, also because it would benefit many other
> projects. :)

Oki. I started looking into this but other things popped up. Lets see…

> Thanks,
> Guillem

Sebastian

Bug#962935: budgie-extras: autopkgtest fails with newer pycodestyle

[Ondřej Nový]

Source: budgie-extras
Version: 1.0.2-1
Severity: serious

budgie-extras autopkgtest fails when run with newest pycodestyle 2.6.0:

./budgie-wswitcher/wswitcher_run:51:34: E741 ambiguous variable name 'l'

Thanks for fixing.

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

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

Bug#962692: puppet: Crashes due to "missing" facts.d directories

[Wilmer van der Gaast]

>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962320 I guess
swapping libboost library versions may be a more proper fix. Though I
haven't tried this myself yet.

Bug#962748: Add support for X11 backend

[Guido Günther]

Hi,
On Sat, Jun 13, 2020 at 02:38:41PM +0200, Vincent Bernat wrote:
>  ❦ 13 juin 2020 13:48 +02, Guido Günther:
> 
> >> running Sway over X11 for testing purposes by running it with
> >> WLR_BACKENDS=x11. Currently, X11 support is not compiled in due to
> >> missing dependencies, notably libx11-xcb-dev.
> >
> > Sure, that's actually an omission. Care enough to send a patch?
> 
> Yes. Here it is!

Applied, thanks! I'll do an upload one my key in the keyring got
refreshed.
Cheers,
 -- Guido

Bug#962936: sane-backends: please still keep libsane transitional package around

[Gianfranco Costamagna]

Source: sane-backends
Version: 1.0.30-1~experimental2
Severity: serious

Hello, I tried to upgrade from the old sane-backends to the new one, and 
libsane in some condition
was not removed, and sane-utils were removed as result.

I don't know how and why, but adding back libsane as transitional package 
helped in doing the upgrade in a smooth
way.

The trivial patch uploaded in Ubuntu is here:

diff -Nru sane-backends-1.0.30/debian/changelog 
sane-backends-1.0.30/debian/changelog
--- sane-backends-1.0.30/debian/changelog   2020-05-31 07:23:01.0 
+
+++ sane-backends-1.0.30/debian/changelog   2020-06-14 11:36:40.0 
+
@@ -1,3 +1,11 @@
+sane-backends (1.0.30-1~experimental2ubuntu1) groovy; urgency=medium
+
+  * Sync from debian experimental, Remaining changes:
+- add back libsane transitional package, to ease upgrades.
+  (this can be dropped after 22.04)
+
+ -- Gianfranco Costamagna   Sun, 14 Jun 2020 
13:36:40 +0200
+
 sane-backends (1.0.30-1~experimental2) experimental; urgency=medium
 
   * debian/not-installed:
diff -Nru sane-backends-1.0.30/debian/control 
sane-backends-1.0.30/debian/control
--- sane-backends-1.0.30/debian/control 2020-05-26 10:15:40.0 +
+++ sane-backends-1.0.30/debian/control 2020-06-14 11:36:38.0 +
@@ -131,3 +131,24 @@
  .
  This package contains the files needed to build your applications
  using SANE.
+
+Package: libsane
+Architecture: any
+Multi-Arch: same
+Section: oldlibs
+Depends:
+ libsane1 (>= ${source:Version}),
+ ${misc:Depends}
+Description: API library for scanners [transitional package]
+ SANE stands for "Scanner Access Now Easy" and is an application
+ programming interface (API) that provides standardized access to any
+ raster image scanner hardware (flatbed scanner, hand-held scanner,
+ video- and still-cameras, frame-grabbers, etc.). The SANE standard is
+ free and its discussion and development are open to everybody. The
+ current source code is written to support several operating systems,
+ including GNU/Linux, OS/2, Win32 and various Unices and is available
+ under the GNU General Public License (commercial applications and
+ backends are welcome, too, however).
+ .
+ This package is here to ensure smooth upgrades. It can be removed when
+ you see fit.

thanks for considering it!

Gianfranco

Bug#962916: [git-buildpackage/master] docs: import-ref: Fix wrong --upstream-tree default

[Guido Günther]

tag 962916 pending
thanks

Date:   Tue Jun 16 08:52:59 2020 +0200
Author: Guido Günther 
Commit ID: a3d9c9824ddef3837b3740e1a9bc66438c72bc54
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=a3d9c9824ddef3837b3740e1a9bc66438c72bc54
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=a3d9c9824ddef3837b3740e1a9bc66438c72bc54

docs: import-ref: Fix wrong --upstream-tree default

Closes: #962916

  

Bug#913346: libsane1: Cannot update libsane1

[Gianfranco Costamagna]

control: close -1

Hello, at the end the rename has been renamed again in experimental so this bug 
can be closed.

However, since many packages outside Debian might need libsane and not libsane1 
I opened a new bug report to track this:

https://bugs.debian.org/962936

G.

On Mon, 21 Jan 2019 09:47:49 -0500 Jeremy Bicha  wrote:
> On Mon, Jan 21, 2019 at 9:23 AM John Paul Adrian Glaubitz
>  wrote:
> > Well, I have a different opinion on that. I do not consider a temporary
> > issue in unstable a bug affecting anything but developers.
> 
> 3 months isn't temporary. While I think Testing is a better fit for
> users than Unstable (maybe we agree there), there are huge numbers of
> people and writings that argue that users should use Unstable instead
> because "Testing has no security guarantees".
> 
> > I'm not sure why you are resorting to the Release Team here? What does the
> > Release Team have to do with unstable which isn't even a release?
> 
> Because you're "appealing to authority" by asking me to prove that
> there is a bug here. I think we all agree that the Debian Release Team
> can decide what is an RC bug. But I guess you're going to nitpick and
> argue that the Release Team has no authority over Unstable and we
> shouldn't even consider their opinion then…
> 
> > Why is Ubuntu importing packages with RC bugs open? Shouldn't that
> > be blocked?
> 
> I did block it: Ubuntu itself never had this bug because it was
> blocked in the "devel-proposed" section which even developers aren't
> supposed to be using.
> 
> Let me be more direct here: I don't understand why you are blocking
> this bug fix. You don't even have to do the upload yourself: just
> apply the patch that has been given and allow Gianfranco to do the
> NMU. How does accepting this bugfix hurt anybody?
> 
> Thanks,
> Jeremy Bicha
> 
> 

Bug#962936: sane-backends: please still keep libsane transitional package around

[Gianfranco Costamagna]

Hello,

after thinking a little bit more, a Provides might even be enough to satisfy 
the dependency.

To reproduce this issue:
pbuilder-dist sid login
apt-get install sane-utils
add experimental repo:

apt-get dist-upgrade -t experimental
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  acl cpp-9 fontconfig-config fonts-dejavu-core g++-9 gcc-9 libavahi-client3 
libavahi-common-data libavahi-common3 libbsd0 libdbus-1-3 libexif12 libexpat1 
libfontconfig1 libfreetype6 libgcc-9-dev libgd3
  libgphoto2-6 libgphoto2-port12 libicu67 libieee1284-3 libjbig0 
libjpeg62-turbo libkmod2 libpci3 libpng16-16 libsane-common libsensors-config 
libsensors5 libsnmp-base libsnmp35 libssl1.1
  libstdc++-9-dev libtiff5 libusb-1.0-0 libwebp6 libwrap0 libx11-6 libx11-data 
libxau6 libxcb1 libxdmcp6 libxml2 libxpm4 pci.ids sensible-utils ucf udev 
update-inetd
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  libsane sane-utils
The following NEW packages will be installed:
  cpp-10 g++-10 gcc-10 libasan6 libgcc-10-dev libstdc++-10-dev
The following packages will be upgraded:
  binutils binutils-common binutils-x86-64-linux-gnu cpp dpkg dpkg-dev 
e2fsprogs g++ gcc libaudit-common libaudit1 libbinutils libc-bin libc-dev-bin 
libc6 libc6-dev libcom-err2 libctf-nobfd0 libctf0
  libdbus-1-3 libdpkg-perl libext2fs2 libjpeg62-turbo libsane-common 
libselinux1 libsepol1 libss2 linux-libc-dev logsave
29 upgraded, 6 newly installed, 2 to remove and 0 not upgraded.
Need to get 57.3 MB/57.3 MB of archives.
After this operation, 140 MB of additional disk space will be used.
Do you want to continue? [Y/n] 


Looks like it is trying to remove libsane and sane-utils instead of upgrading 
the latter

G.

Bug#962919: RFS: spyne/2.13.15-0.1 [NMU, RC] -- Python library for writing and calling soap web service

[Bastian Germann]

While the website http://spyne.io has an old alpha version listed as new
version, the 2.13.15 version is actually tagged on GitHub and available
on PyPI.

Bug#962937: python-oauthlib: FTBFS with newer python-mock

[Ondřej Nový]

Source: python-oauthlib
Version: 3.1.0-1
Severity: serious
Tags: ftbfs

python-oauthlib 3.1.0-1 FTBFS and autopkgtest fails with newer python-mock 
4.0.2-1.

Thanks for fixing.

__ AuthorizationCodeGrantTest.test_invalid_request_duplicates __

self = 


def test_invalid_request_duplicates(self):
request = mock.MagicMock(wraps=self.request)
request.grant_type = 'authorization_code'
request.duplicate_params = ['client_id']
>   self.assertRaises(errors.InvalidRequestError, 
> self.auth.validate_token_request,
  request)

tests/oauth2/rfc6749/grant_types/test_authorization_code.py:159: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py:453:
 in validate_token_request
raise errors.InvalidRequestError(description='Duplicate %s parameter.' % 
param,
/usr/lib/python3/dist-packages/oauthlib/oauth2/rfc6749/errors.py:49: in __init__
if request:
/usr/lib/python3/dist-packages/mock/mock.py:2160: in __get__
return self.create_mock()
/usr/lib/python3/dist-packages/mock/mock.py:2156: in create_mock
_set_return_value(parent, m, entry)
/usr/lib/python3/dist-packages/mock/mock.py:2053: in _set_return_value
method._mock_wraps = getattr(mock._mock_wraps, name)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

def __getattr__(self, name):
if name in self._params:
return self._params[name]
else:
>   raise AttributeError(name)
E   AttributeError: __bool__

/usr/lib/python3/dist-packages/oauthlib/common.py:436: AttributeError

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

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

Bug#954711: sight: diff for NMU version 19.0.0-6.1

[Flavien Bridault]

Hi Andreas and Adrian,

We are polishing Sight 20.0 and we should release by the end of the week
or maybe next week, with the included fix (or somehow, because we simply
stopped using ::boost::regex). However I can not ensure the update of
the package will be smooth, so having a working package based 19.0.0 in
the meantime is probably safer.

Thanks for your work !

Le 15/06/2020 à 21:36, Andreas Tille a écrit :
> Hi Adrian,
>
> thanks a lot for your effort.  I've injected the diff into Git.
>
> Flavien, it would be great if you could integrate this upstream
> and issue a new release.
>
> Kind regards
>
>Andreas.
>
> On Mon, Jun 15, 2020 at 06:35:02PM +0300, Adrian Bunk wrote:
>> Control: tags 954711 + pending
>>
>> Dear maintainer,
>>
>> I've prepared an NMU for sight (versioned as 19.0.0-6.1) and uploaded
>> it to DELAYED/2. Please feel free to tell me if I should cancel it.
>>
>> cu
>> Adrian
>> diff -Nru sight-19.0.0/debian/changelog sight-19.0.0/debian/changelog
>> --- sight-19.0.0/debian/changelog2020-04-25 15:47:51.0 +0300
>> +++ sight-19.0.0/debian/changelog2020-06-15 18:20:23.0 +0300
>> @@ -1,3 +1,11 @@
>> +sight (19.0.0-6.1) unstable; urgency=high
>> +
>> +  * Non-maintainer upload.
>> +  * Add patch from Giovanni Mascellani for FTBFS with Boost 1.71.
>> +(Closes: #954711)
>> +
>> + -- Adrian Bunk   Mon, 15 Jun 2020 18:20:23 +0300
>> +
>>  sight (19.0.0-6) unstable; urgency=medium
>>  
>>[ Etienne Mollier ]
>> diff -Nru sight-19.0.0/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch 
>> sight-19.0.0/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch
>> --- sight-19.0.0/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch 
>> 1970-01-01 02:00:00.0 +0200
>> +++ sight-19.0.0/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch 
>> 2020-06-15 18:20:20.0 +0300
>> @@ -0,0 +1,34 @@
>> +From: Giovanni Mascellani 
>> +Date: Sun, 22 Mar 2020 14:34:26 +0100
>> +Subject: Fix FTBFS with Boost 1.71.
>> +
>> +Apparently CMake expects library names to be lowercase.
>> +---
>> + Bundles/ui/guiQml/CMakeLists.txt | 2 +-
>> + Bundles/ui/guiQt/CMakeLists.txt  | 2 +-
>> + 2 files changed, 2 insertions(+), 2 deletions(-)
>> +
>> +diff --git a/Bundles/ui/guiQml/CMakeLists.txt 
>> b/Bundles/ui/guiQml/CMakeLists.txt
>> +index 42c008e..7f9c228 100644
>> +--- a/Bundles/ui/guiQml/CMakeLists.txt
>>  b/Bundles/ui/guiQml/CMakeLists.txt
>> +@@ -1,6 +1,6 @@
>> + fwLoadProperties()
>> + 
>> +-find_package(Boost QUIET COMPONENTS Regex REQUIRED)
>> ++find_package(Boost QUIET COMPONENTS regex REQUIRED)
>> + find_package(Qt5 QUIET COMPONENTS Core Gui Quick Qml QuickControls2 
>> REQUIRED)
>> + 
>> + 
>> +diff --git a/Bundles/ui/guiQt/CMakeLists.txt 
>> b/Bundles/ui/guiQt/CMakeLists.txt
>> +index 3aff5d1..ff52b89 100644
>> +--- a/Bundles/ui/guiQt/CMakeLists.txt
>>  b/Bundles/ui/guiQt/CMakeLists.txt
>> +@@ -1,6 +1,6 @@
>> + fwLoadProperties()
>> + 
>> +-find_package(Boost QUIET COMPONENTS Regex REQUIRED)
>> ++find_package(Boost QUIET COMPONENTS regex REQUIRED)
>> + find_package(Qt5 QUIET COMPONENTS Core Gui Widgets REQUIRED)
>> + 
>> + 
>> diff -Nru sight-19.0.0/debian/patches/series 
>> sight-19.0.0/debian/patches/series
>> --- sight-19.0.0/debian/patches/series   2020-04-25 15:47:51.0 
>> +0300
>> +++ sight-19.0.0/debian/patches/series   2020-06-15 18:20:20.0 
>> +0300
>> @@ -4,3 +4,4 @@
>>  fix_launcher_library_path.patch
>>  fix_dcmtk_scp_cfg.patch
>>  revert_qVTK_widget.patch
>> +0007-Fix-FTBFS-with-Boost-1.71.patch
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>
-- 
*Flavien BRIDAULT*
Software Development Director

flavien.brida...@ircad.fr
+33 (0)3 88 119 201

*IRCAD France*
1, place de l'Hôpital - 67091 Strasbourg Cedex - FRANCE

http://www.ircad.fr/ 




signature.asc
Description: OpenPGP digital signature

Bug#962938: lasagne: autopkgtest fails with newer python-mock

[Ondřej Nový]

Source: lasagne
Version: 0.1+git20200419.5d3c63c+ds-1
Severity: serious

lasagne's autopkgtest fails with newer python-mock 4.0.2-1.

Fails are in layers/test_helper.py, see:
https://ci.debian.net/data/autopkgtest/testing/amd64/l/lasagne/5909523/log.gz

Thanks for fixing.

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

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

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[Andreas Tille]

Hi,

I have injected some preliminary packaging for google-api-client-java
into salsa[1].  When trying to build I get:


...
   dh_auto_build
/usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/build/google-api-client-java-1.30.9 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml 
-Ddebian.dir=/build/google-api-client-java-1.30.9/debian 
-Dmaven.repo.local=/build/google-api-client-java-1.30.9/debian/maven-repo 
package -DskipTests -Dnotimestamp=true -Dlocale=en_US
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
com.google.inject.internal.cglib.core.$ReflectUtils$1 
(file:/usr/share/maven/lib/guice.jar) to method 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of 
com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Non-resolvable import POM: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
com.google.http-client:google-http-client-bom:pom:debian has not been 
downloaded from it before. @ line 105, column 16
[ERROR] Non-resolvable import POM: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
com.google.oauth-client:google-oauth-client-bom:pom:debian has not been 
downloaded from it before. @ line 112, column 16
 @ 
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project com.google.api-client:google-api-client-parent:1.30.9 
(/build/google-api-client-java-1.30.9/pom.xml) has 2 errors
[ERROR] Non-resolvable import POM: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
com.google.http-client:google-http-client-bom:pom:debian has not been 
downloaded from it before. @ line 105, column 16 -> [Help 2]
[ERROR] Non-resolvable import POM: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
com.google.oauth-client:google-oauth-client-bom:pom:debian has not been 
downloaded from it before. @ line 112, column 16 -> [Help 2]


I have added libgoogle-http-client-java that is carrying the classes in
question but it seems I need to do some more magic to make maven finding
it.  It would be great if somebody would refresh my mind how to do this.

Kind regards

Andreas.

[1] https://salsa.debian.org/java-team/google-api-client-java

-- 
http://fam-tille.de

Bug#881871: stretch-pu: package bacula/7.4.4+dfsg-6

[Carsten Leonhardt]

Julien Cristau  writes:

> Control: tag -1 confirmed

> Sorry for the delay, please go ahead.

For information, I've uploaded the package some time ago and it's
waiting in the NEW queue for FTP master review.

Regards,

Carsten

Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.

[Adrian Bunk]

On Mon, Jun 15, 2020 at 12:17:39AM +0200, Vctl Piotr Kolasinski wrote:
>...
> In my opinion the big problem may be w ith access to the real platform
> (currently I have access and possibilities but I don't know how long).
> Of course we have emulators like hercules (which I use from very long
> time) and know qemu s390 port (only with virtio, not tested by me),
> but it is probably not enough in power (as long as yo don't have very
> powerful emulation platform or use cross-compile). Anyway if Debian
> maintainers have access to valid build environment, I think you should
> not remove the architecture.

Hardware is not the problem.
Forcing 1000 volunteers in Debian to support a port that has no porters 
and no users is the problem.

Debian has an s390x porterbox that is available to all Debian developers.
For normal package development this is sufficient.

The s390x port has some unique problems.
And with a390x as release architecture package maintainers in Debian are 
supposed to fix these problems in their packages if they want their 
packages in the next Debian release.

Forcing volunteers to do unpleasant work like porting to s390x is making 
it a more attractive choice to stop contributing to Debian.

s390x is the only big endian release architecture.
Big endian hardware has become exotic, and some of the younger 
maintainers in Debian might have never seen big endian hardware.
Endian problems are common problems in packages,
and porting software to support big endian can be a real pain.

s390x is the only headless release architecture.
This was a real pain for the Debian GNOME maintainers already before
the last release, without any support from s390x porters on fixing
this issue.[1]

A port like s390x with unique problems is only sustainable when several 
people with good knowledge of Debian, s390x hardware and the Linux 
kernel have a long-term commitment of swiftly supporting everyone in 
Debian with s390x problems.

IMHO it would be best if s390x would become a non-release architecture 
in ports.

Architectures in ports are autobuilt like release architectures,
but there is no pressure on the volunteers maintaining packages
in Debian to spend their time on supporting these architectures.
Other architectures like m68k, big endian powerpc, alpha, hppa
and ia64 that also tend to have one dedicated porter each but
not many users left are also in ports.

> Kind Regards
> Piotr (aka nome)

cu
Adrian

[1] https://lists.debian.org/debian-s390/2018/12/msg00010.html

Bug#953636: debhelper: Something to overwrite dh_fixperms default behavior in a "auto" plugin

[Xavier]

Le 10/06/2020 à 14:21, Xavier a écrit :
> Xavier Guimard:
>> Niels Thykier:
>>> Xavier Guimard:
 Package: debhelper
 Version: 12.9
 Severity: wishlist

 Hi,

 I'm maintaining pkg-js-tools which provides a nodejs-module
 auto-installer. I'd like to automatically `chmod +x` files declared as
 "bin" in package.json.
  * I don't want to automatically install them to /usr/bin because:
* `require` command is related to current directory, then nodejs
  binaries must be installed in nodejs dirs and linked to /usr/bin
* I don't want to automatically link them all to /usr/bin since this
  will change packages during rebuild and can create conflicts (same
  binary names)
  * I don't want to "remove_command" dh_fixperms since it is not safe
  * I don't want to "insert_after" dh_fixperms since it will be launched
even if maintainer sets a "overrides_dh_fixperms'

 For now, maintainers are using "override_dh_fixperms" but I think we can
 use more automatisation. Is it possible to write a dh_auto_fixperms
 target or giving values using environment variables ?

 Cheers,
 Xavier

 NB: sorry for my poor English, tell me if my query is not clear ;-)

>>>
>>> Would it be solved by dh_fixperms leaving the exec bit alone in some
>>> directory and rely on pkg-js-tools's auto-installer to set that correctly?
>>>
>>> If not, is there a trivial way to determine which file should have exec
>>> bit and which should not (as a "new" general rule to replace #953638)?
>>> Or will this require nodejs knowledge (like parsing an upstream file)?
>>>
>>>
>>> ~Niels
>> Hi,
>>
>> sorry for the delay (I lost previous message). Generally Node.js
>> binaries can be found in package.json ("bin" field). Usually they are
>> in /node/path/foo/bin where node-path is one of:
>> * /usr/share/nodejs
>> * /usr/lib//nodejs
>> * /usr/lib/nodejs (deprecated)
>>
>> But it's not always so...
> 
> Hi,
> 
> For a better answer:
> 
>>> Would it be solved by dh_fixperms leaving the exec bit alone in some
>>> directory and rely on pkg-js-tools's auto-installer to set that
>>> correctly?
> 
> Generally, these files are installed in bin/, lib/ or dist/ (and
> translated to /usr/share/nodejs/ or /usr/lib/
>  during auto install).
> 
> When bin/ is used, it contains generally only executable files but when
> upstream uses dist/ or lib/, the executable file is installed between
> other js files. Leaving +x might be bad since not all nodejs packages
> are managed by pkg-js-tools (DD choice).
> I think dh_fixperms should remove +x bit anywhere except bin/
> 
>>> If not, is there a trivial way to determine which file should have
>>> exec bit and which should not (as a "new" general rule to replace
>>> #953638)?
> 
> No, this require to parse package.json
> 
>>> Or will this require nodejs knowledge (like parsing an upstream
>>> file)?
> 
> Yes, +x bit has to be set to all files mentioned in "bin" field and no
> other files. Like other package.json fields, it can be an expression (or
> an array of expressions) which is different than shell expressions. You
> can take a look at this test file ([1]) to see some expressions used in
> package.json ("/**/" is the main difference).
> 
> That's why I suggested a sort of dh_auto_fixperms (but which overrides
> dh_fixperms because of dh_fixperms specificities)
> 
> Cheers,
> Xavier
> 
> [1]: https://salsa.debian.org/js-team/pkg-js-tools/-/blob/master/t/pattern.t

Hi,

in the same idea, a "dh_auto_installdocs" could be interesting:
pkg-js-tools could install automatically readme.md, contributing.md,...

Bug#962939: RFS: pipewalker/1.0-3 [QA] -- combination puzzle game

[David da Silva Polverari]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: pipewalker
   Version : 0.9.4-3
   Upstream Author : Artem Senichev 
 * URL : http://pipewalker.sourceforge.net/
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/pipewalker
   Section : games

It builds those binary packages:

  pipewalker - combination puzzle game

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pipewalker/pipewalker_0.9.4-3.dsc

Changes since the last upload:

   * QA upload.
   * Ran wrap-and-sort.
   * Set Debian QA Group as maintainer. (See #826925)
   * Using new DH level format. Consequently:
   - debian/compat: removed.
   - debian/control: changed from 'debhelper' to 'debhelper-compat' in
 Build-Depends field and bumped level to 13.
   * debian/control:
   - Added 'Rules-Requires-Root: no' to source stanza.
   - Added the Vcs-* fields.
   - Bumped Standards-Version to 4.5.0.
   - Changed package synopsis and long description.
   - Removed redundant build dependencies since DH compatibility level 10.
   * debian/copyright:
   - Added new rights in debian/* paragraph.
   - Migrated to 1.0 format.
   * debian/manpages: added to install a maintainer-provided manpage.
   * debian/menu: replaced a relative path reference to an icon with an absolute
 one, according to the "Debian Menu System" manual, section 3.2 (Syntax).
 Thanks to Markus Koschany . (Closes: #738006)
   * debian/patches/*:
   - 020_fix-fmt-string-vuln.patch: added to fix a format string
 vulnerability on upstream code.
   - 030_fix-xdg-dot-desktop.patch: added to make upstream provided .desktop
 file conform to XDG Desktop Entry Specification.
   - 040_fix-build-fhs-games.patch: added to make the build system conform 
to
 FHS regarding static data files for /usr/games.
   - datadir.diff: removed due to build system adjustments by other patches.
   - no-werror.diff: renamed to 010-configure-no-werror.patch and added
 DEP-3 header.
   * debian/pipewalker.1: added to provide a manpage to the game binary.
   * debian/rules:
   - Added DEB_BUILD_MAINT_OPTIONS variable to provide full GCC hardening.
   - Changed the '--data-dir' value to suit the modifications made to the
 build system.
   - Removed '--with autoreconf' because it is default since DH 10.
   * debian/salsa-ci.yml: added to provide CI tests for Salsa.
   * debian/tests/control: created to provide trivial CI tests.
   * debian/watch: bumped to version 4.

Regards,

--
  David da Silva Polverari

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[Olek Wojnar]

Hi Andreas,

On Tue, Jun 16, 2020 at 4:15 AM Andreas Tille  wrote:

> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Non-resolvable import POM: Cannot access central (
> https://repo.maven.apache.org/maven2) in offline mode and the artifact
> com.google.http-client:google-http-client-bom:pom:debian has not been
> downloaded from it before. @ line 105, column 16
> [ERROR] Non-resolvable import POM: Cannot access central (
> https://repo.maven.apache.org/maven2) in offline mode and the artifact
> com.google.oauth-client:google-oauth-client-bom:pom:debian has not been
> downloaded from it before. @ line 112, column 16
>
> I have added libgoogle-http-client-java that is carrying the classes in
> question but it seems I need to do some more magic to make maven finding
> it.  It would be great if somebody would refresh my mind how to do this.
>

Good question! Due to some dependency issues, the bom artifacts are not
packaged. But you should be able to just depend on the non-bom pom files.

-Olek

Bug#905385: stretch-pu: package weboob/1.2-1

[duck]

Quack,

On 2020-06-16 04:37, Adam D. Barratt wrote:


We're now planning for the final point release for stretch before it
moves to LTS support. Is this still something that you're (either of
you) interested in fixing for stretch?


Thanks for reaching out.

Since a removal request was pushed forcefully I assumed it would affect 
all suites.


Anyway I see no point in fixing the package instead of removal at this 
stage, unless this is impossible to undesirable for the release of 
course.


Regards.
\_o<

--
Marc Dequènes

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[Andreas Tille]

Hi Olek,

On Tue, Jun 16, 2020 at 05:01:37AM -0400, Olek Wojnar wrote:
> 
> Good question! Due to some dependency issues, the bom artifacts are not
> packaged.

OK, that explains the issue ...

> But you should be able to just depend on the non-bom pom files.

... but I'm to uneducated to implement your suggested solution.
(Feel free to push and I keep on testing).

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#954144: key-mon: Relatively high CPU use on idle machine

[Lawrence D'Oliveiro]

Philipp Marek  wrote:

> I'd have expected it to be event-triggered, so that no polling
> would be necessary - seems I'm wrong.

I don’t know enough about X11 programming to be sure, but it probably
needs to do this in order to catch modifier key state in events sent to
other windows.

Still, it is ridiculous to poll for events a thousand times a second. I
think 10 times a second would be a more reasonable match for normal
human response times.

Turns out key-mon was written for Python 2 and GTK 2, and has not been
maintained in a long time. I did some work on it as of today to update
it to Python 3 and GTK 3, and the current state of my version is
here . Almost certainly needs a bit more
testing. At some point I might suggest replacing the Debian package
with my version, if no-one else can offer anything better.

Bug#962902: [debian-mysql] Bug#962902: server does not start

[Otto Kekäläinen]

Thanks for reporting!

Can you provide us enough information about your environment so we
could try to reproduce this error?
Or can you reproduce it yourself in a Docker, LXC or other container
with a clean Debian environment?

Bug#962940: mirror submission for mirror.linux.ro

[Daniel Petre]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.linux.ro
Type: leaf
Archive-architecture: amd64
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Daniel Petre 
Country: RO Romania
Location: Bucharest
Sponsor: RCS&RDS https://www.digiromania.ro/




Trace Url: http://mirror.linux.ro/debian/project/trace/
Trace Url: http://mirror.linux.ro/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.linux.ro/debian/project/trace/mirror.linux.ro

Bug#962941: ITP: streamz: Helps build pipelines to manage continuous streams of data

[Nilesh Patra]

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

* Package name: streamz
  Version : 0.5.3
  Upstream Author : Continuum Analytics, Inc. and contributors
* URL : https://github.com/python-streamz/streamz

* License : BSD-3-Clause
  Programming Lang: Python
  Description : Helps build pipelines to manage continuous streams of
data

 It is simple to use in simple cases, but also supports complex pipelines
that
 involve branching, joining, flow control, feedback, back pressure, and so
on.
 Optionally, Streamz can also work with both Pandas and cuDF dataframes,
 to provide sensible streaming operations on continuous tabular data.

I take the responsibility to maintain this package.

Bug#943692: Info received (reopened for stable)

[Matus UHLAR - fantomas]

Hello,

as new point release is planned, is it possible to try pushing fixed squid
version (applied proposed patch) to buster?

Thank you.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)

Bug#962942: ITP: seirsplus -- Models of SEIRS epidemic dynamics with extensions

[Sao I Kuan]

Package: wnpp
Severity: wishlist
Owner: Sao I Kuan 

* Package name: seirsplus
  Version : 0.0~git20200528.5c04080
  Upstream Author : Ryan Seamus McGee
* URL : https://github.com/ryansmcgee/seirsplus
* License : Expat
  Programming Lang: Python
  Description : Models of SEIRS epidemic dynamics with extensions

 This package implements generalized SEIRS infectious disease
 dynamics models with extensions that model the effect of factors
 including population structure, social distancing, testing, contact
 tracing, and quarantining detected cases.
 .
 Notably, this package includes stochastic implementations of these
 models on dynamic networks.

This package is a work which is part of COVID-19 hackathon [1].
The package will be team maintained (med-team).

[1] https://lists.debian.org/debian-med/2020/06/msg00071.html

Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]

[Ian Jackson]

Felix Lechner writes ("Re: Bug#953554: Please permit Debian revisions with 1.0 
native packages [and 1 more messages]"):
> Hi Sean,
...
> Based on your note, however, Lintian will stop warning about such
> version mismatches. Perhaps it will gradually pave the way for a
> constructive policy debate. Thanks!

This may seem strange and like I'm changing sides, but:

I was convinced by the argument that people might do this by mistake,
especially with format 1.0 source packages, where you can get a native
package by accident simply by failing to have the orig tarball in the
right place.

So I think it would be best if lintian would warn about 1.0 format
native source packages with non-native versions, with a suitable
explantion which will encourage the maintainer to override the
warning if they did this on purpose.

Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#962943: libssh-4: unable to parse negative syntax in ssh_config

[Maurizio Avogadro]

Package: libssh-4
Version: 0.9.4-1
Severity: normal


Dear Maintainer,

it seems that libssh is unable to correctly parse /etc/ssh/ssh_config when 
using the officially supported negative syntax (prepending a dash to the 
algorithm list) at least for KexAlgorithms.

The first algo, the one prefixed with the dash, gets totally ignored, and the 
following algos are interpreted as the assertive syntax was used: the outcome 
is that only excluded algos are tried.

I ran into this issue by trying to connect to a remote host using KDE Plasma's 
SFTP kioslave (/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/sftp.so), which 
depends on libssh.so.4:

"kex error : no match for method kex algos: server 
[curve25519-sha256,curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256],
 client [ecdh-sha2-nistp384,ecdh-sha2-nistp521]"

The 'client' kexes appearing in the error message were explicitly excluded 
along with ecdh-sha2-nistp256 (first in the list, with dash prepended) in 
/etc/ssh/ssh_config.

Changing the config file to assertive syntax solved the issue.


Thanks


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

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

Versions of packages libssh-4 depends on:
ii  libc6 2.30-8
ii  libgssapi-krb5-2  1.17-7
ii  libssl1.1 1.1.1g-1
ii  zlib1g1:1.2.11.dfsg-2

libssh-4 recommends no packages.

libssh-4 suggests no packages.

-- no debconf information

Bug#961331: RFS: insilicoseq [ITP]

[Sao I Kuan]

Hi, Andreas,

Thanks for your careful review.

On Thu, Jun 11, 2020 at 2:16 AM Andreas Tille  wrote:
>
> Ahhh and please check calling /usr/bin/iss without any
> argument throws a strange warning...

I patched argument error and forwarded the bug to upstream[1].
[1] https://github.com/HadrienG/InSilicoSeq/issues/177

> On Wed, Jun 10, 2020 at 07:11:54PM +0200, Andreas Tille wrote:
> > Hi,
> > Very short notice since I'm busy with real life:
> > I've added a primitive manpage.  Would you be able to
> > check whether you can write a simple autopkgtest using
> > the provided data?  I browsed the README quickly and
> > it should be possible (at least at first sight)

Thanks a lot :) and I have added autopkgtest and it worked.

Sincerely,

Sao I Kuan
saoik...@gmail.com

Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]

[Ian Jackson]

Sean Whitton writes ("Re: Bug#953554: Please permit Debian revisions with 1.0 
native packages [and 1 more messages]"):
> I believe that the relevant sentence of Policy, added in policy.git
> commit eee39aecef3a6a5f9927211b5c847e645e927cbd, was intended to be
> informative, not normative.  It does not use one of the Policy normative
> magic words, is not in the subsection in which it would be natural to
> place such a restriction, and occurs in a "hey, don't forget that ..."
> clause.

Oh yes.  I hadn't read this sentence from 3.2.1 in context.

I think "native package versions" refers to "versionn numbers which
are supposed to be Debian-native", not "the version numbers of
native-format packages".

Can I suggest that this sentence might be clarified as follows

  remember that hyphen (-) cannot be used in
  native {-package versions-}{+version numbers+}

?

> Thus the only Policy issue here could be the addition of an explicit
> permission to use Debian revisions with 1.0 native packages.  As
> discussion is ongoing in the context of Lintian, that seems premature,
> however.

Ideally I would like to see such an explicit permission.  It ought to
go into the section on source packages.  But it ought to have some
caveats (eg about size, perhaps, and about tracking changes to
upstream parts some other way eg via git).  I suspect that discussion
would be dispropornately long and fractious and inconclusive, compared
to the value to be gained.

> So I think we can close the clone of this bug against Policy for now.

The bugs seem very confusing to me.  A sprawling mass of
partially-duplicated stuff.  See my comment above for a suggested
wording clarification.

Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#962942: RFS: seirsplus [ITP]

[Sao I Kuan]

Hi,

I'm looking for a sponsor for the package:
  * seirsplus (#962942)

The package is on:
https://salsa.debian.org/med-team/seirsplus

The package is lintian-clean.

Please consider reviewing and sponsoring this. Any kind of suggestions
are appreciated.

Thank you!

Sincerely,

Sao I Kuan
saoik...@gmail.com

Bug#962846: Bug#962811: calibre: ebook-viewer crash on start

[Dmitry Shachnev]

Hi Davide!

On Mon, Jun 15, 2020 at 05:52:37PM +0200, Davide Prina wrote:
> I try to make a full debug. I never done that with a Python program, so I
> have searched on internet

Thanks!

> #3  0x0049d912 in Py_FatalError (msg=) at 
> ../Python/pylifecycle.c:2197
> #4  0x004b73b3 in PyEval_SaveThread () at ../Python/ceval.c:380
> #5  0x743ac549 in  () at 
> /usr/lib/python3/dist-packages/PyQt5/QtCore.cpython-38-x86_64-linux-gnu.so
> #6  0x73f0c44c in QMetaObject::activate(QObject*, int, int, void**) 
> () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> #7  0x743a643e in  () at 
> /usr/lib/python3/dist-packages/PyQt5/QtCore.cpython-38-x86_64-linux-gnu.so
> #8  0x005f1fca in cfunction_call_varargs (kwargs=, 
> args=,
> func= remote 0x7fffbc357cf0>)
> at ../Include/internal/pycore_pyerrors.h:13

So this seems to be the relevant part here.

I managed to reproduce this issue locally with some dbg packages installed,
and this part of stacktrace is as follows:

#9  0x0051cb0a in Py_FatalError (msg=msg@entry=0x6d9a88 
"PyEval_SaveThread: NULL tstate") at ../Python/pylifecycle.c:2197
#10 0x004db7d7 in PyEval_SaveThread () at ../Python/ceval.c:380
#11 0x745f105c in qt_metacall_worker(sipSimpleWrapper*, PyTypeObject*, 
sipTypeDef*, QMetaObject::Call, int, void**)
(pySelf=0x7fffc0522c30, pytype=, base=, 
_c=QMetaObject::InvokeMetaMethod, _id=19, _a=0x27ac0e0)
at ../../qpy/QtCore/qpycore_qobject_helpers.cpp:106
#12 0x7413944c in QMetaObject::activate(QObject*, int, int, void**)
(sender=0x20249a0, signalOffset=, 
local_signal_index=, argv=)
at kernel/qobject.cpp:3821
#13 0x745e9a9e in do_emit (sigargs=, 
docstring=, parsed_signature=0x144cb30,
signal_index=, qtx=)
at ../../qpy/QtCore/qpycore_pyqtboundsignal.cpp:801
#14 pyqtBoundSignal_emit(PyObject*, PyObject*) (self=, 
args=)
at ../../qpy/QtCore/qpycore_pyqtboundsignal.cpp:742
#15 0x004344fb in cfunction_call_varargs (func=0x7fffc20b5530, 
args=0x74923b40, kwargs=0x0) at ../Objects/call.c:757

It looks like a change in qpycore_qobject_helpers.cpp in PyQt 5.15 needed
a corresponding change in sip [1] that is part of sip 4.19.23, and all
dependent packages need to be rebuilt against that sip.

[1]: https://riverbankcomputing.com/hg/sip/rev/812b5e26df96

I will add a Breaks: against old pyqt5webengine to new pyqt5. Now that new
pyqt5webengine is already in testing, this is not urgent, but it will be
part of the next upload.

There is nothing I can do about this in pyqt5webengine, so I am closing the
bug filed against it.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#939297: breezy: Please provide git-remote-bzr program

[Dagfinn Ilmari Mannsåker]

On Wed, 23 Oct 2019 22:24:51 + Jelmer =?utf-8?Q?Vernoo=C4=B3?= 
 wrote:
> On Wed, Oct 23, 2019 at 06:41:11PM +0200, Sven Joachim wrote:
> > On 2019-09-03 03:01 +0200, Guillem Jover wrote:
> >
> > Unfortunately, at least with breezy 3.0.1 it does not actually work. :-(
> > Here is what I got trying to clone a random repository:
> 
> I don't think I'd really want to ship it in its current form. It works
> better in Breezy 3.1, but the performs is pretty terrible since it
> processes each revision multiple times.

Now that 3.1 is in testing, could this be included in the package that
users at least have the option, even if it doesn't perform great?

Personally I only use git-remote-bzr on small repos, and is the only
thing that's keeping Python 2 on my machines.

- ilmari
-- 
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen

Bug#949440: chromium: Blank window when used over ssh tunnel

[Michael Firth]

On Wed, 22 Jan 2020 21:18:08 + Paul Szabo  wrote:
> It now seems to me that the issue is with MIT-SHM, that the code to
> detect whether MIT-SHM is working (so whether to enable) is "broken".
> Using the workaround below, fudging MIT-SHM to report as not present:
>
>   cc -shared -o XlibNoSHM.so XlibNoSHM.c
>   LD_PRELOAD='libdl.so ./XlibNoSHM.so' chromium
>
> solves the issue for me. (That code is "ancient", with comments about
> some old Firefox; the Firefox issue was fixed some time ago.)
>
> Cheers, Paul
> --
> Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics   University of SydneyAustralia
>
> I support NTEU members taking a stand for workplace rights in the face of
> poorly-run change management. Visit www.nteu.org.au/sydney to learn more.

For anyone else trying to get this to compile, it was necessary for me to 
'apt-get install libxext-dev'
to get the necessary headers installed.
On my machine, it was also necessary to add '-fPIC' to the compile line - not 
sure if that is because
I am running Ubuntu 16.04, or because it is an 64-bit install

Once I got the code to compile, this did resolve the issue for me, though I do 
get some errors like:

ERROR: ld.so: object './XlibNoSHM.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.

I don't know if this is because sub-processes are trying to start from a 
different directory and can't find the SHM disabling .so file

>From looking at the code, it might be a good idea to change the line:
#define LIBXLIB "libXext.so"
to:
#define LIBXLIB "libXext.so.6"

So that the disabling .so will work if copied to a machine that doesn't have 
the development libraries present

Regards

Michael

Bug#962902: [debian-mysql] Bug#962902: server does not start

[Toni Mueller]

Hi Otto,

On Tue, Jun 16, 2020 at 12:27:53PM +0300, Otto Kekäläinen wrote:
> Can you provide us enough information about your environment so we
> could try to reproduce this error?

I'm not sure what you are after. The machine in question is a laptop
with Buster (latest), and all sorts of stiff.

I have other machines, also VMs (KVM), where this problem does not
occur. Eg. I have just 'apt dist-upgraded' a KVM VM on the same laptop,
which also has this software, and there, it just runs as expected. On
the host, which has very similar software, just much, much more, the
same thing fails. :(

My question is: Why does the server sometimes require this file to be
present, and where? I mean, this software has imho no business asking
for that file, to begin with.


Thanks,
Toni

Bug#962944: python3-biopython needs Breaks: cnvkit (<< 0.9.7-1~)

[Adrian Bunk]

Package: python3-biopython
Version: 1.77+dfsg-1
Severity: serious
Control: block 959587 by -1

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cnvkit/5912015/log.gz

...
Unpacking python3-biopython (1.77+dfsg-1) ...
...
Unpacking cnvkit (0.9.6-3) ...
...
Traceback (most recent call last):
  File "/usr/bin/cnvkit", line 8, in 
from cnvlib import commands
  File "/usr/lib/python3/dist-packages/cnvlib/__init__.py", line 5, in 
from .commands import *
  File "/usr/lib/python3/dist-packages/cnvlib/commands.py", line 32, in 
from . import (access, antitarget, autobin, batch, call, core, coverage,
  File "/usr/lib/python3/dist-packages/cnvlib/autobin.py", line 11, in 
from . import coverage, samutil
  File "/usr/lib/python3/dist-packages/cnvlib/coverage.py", line 15, in 
from Bio._py3k import StringIO
ModuleNotFoundError: No module named 'Bio._py3k'
make: *** [Makefile:51: build/reference-picard.cnn] Error 1

Bug#959623: ppl: diff for NMU version 1:1.2-8.1

[Adrian Bunk]

Control: tags 959623 + patch
Control: tags 959623 + pending

Dear maintainer,

I've prepared an NMU for ppl (versioned as 1:1.2-8.1) and uploaded
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru ppl-1.2/debian/changelog ppl-1.2/debian/changelog
--- ppl-1.2/debian/changelog	2020-03-04 09:08:43.0 +0200
+++ ppl-1.2/debian/changelog	2020-06-16 12:46:14.0 +0300
@@ -1,3 +1,10 @@
+ppl (1:1.2-8.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix FTBFS with swi-prolog 8.2. (Closes: #959623)
+
+ -- Adrian Bunk   Tue, 16 Jun 2020 12:46:14 +0300
+
 ppl (1:1.2-8) unstable; urgency=medium
 
   * Add latex_include_ifthen_package.patch. (Closes: #943451)
diff -Nru ppl-1.2/debian/patches/series ppl-1.2/debian/patches/series
--- ppl-1.2/debian/patches/series	2020-02-22 13:52:51.0 +0200
+++ ppl-1.2/debian/patches/series	2020-06-16 12:46:14.0 +0300
@@ -4,3 +4,4 @@
 fix_latex_build.patch
 fix_AC_CHECK_SWI_PROLOG.patch
 latex_include_ifthen_package.patch
+swi82.patch
diff -Nru ppl-1.2/debian/patches/swi82.patch ppl-1.2/debian/patches/swi82.patch
--- ppl-1.2/debian/patches/swi82.patch	1970-01-01 02:00:00.0 +0200
+++ ppl-1.2/debian/patches/swi82.patch	2020-06-16 12:46:14.0 +0300
@@ -0,0 +1,166 @@
+Description: Fix FTBFS with swi-prolog 8.2
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/959623
+
+--- ppl-1.2.orig/interfaces/Prolog/Ciao/ciao_cfli.hh
 ppl-1.2/interfaces/Prolog/Ciao/ciao_cfli.hh
+@@ -296,7 +296,7 @@ Prolog_get_atom_name(Prolog_term_ref t,
+   The behavior is undefined if \p t is not a Prolog compound term.
+ */
+ inline int
+-Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, int* ip) {
++Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, size_t* ip) {
+   assert(Prolog_is_compound(t));
+   *ap = ciao_structure_name(t);
+   *ip = ciao_structure_arity(t);
+--- ppl-1.2.orig/interfaces/Prolog/GNU/gprolog_cfli.hh
 ppl-1.2/interfaces/Prolog/GNU/gprolog_cfli.hh
+@@ -420,7 +420,7 @@ Prolog_get_atom_name(Prolog_term_ref t,
+   The behavior is undefined if \p t is not a Prolog compound term.
+ */
+ inline int
+-Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, int* ip) {
++Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, size_t* ip) {
+   assert(Prolog_is_compound(t));
+   Rd_Compound_Check(t, ap, ip);
+   return 1;
+--- ppl-1.2.orig/interfaces/Prolog/SICStus/sicstus_cfli.h
 ppl-1.2/interfaces/Prolog/SICStus/sicstus_cfli.h
+@@ -134,7 +134,7 @@ Prolog_get_atom_name(Prolog_term_ref t,
+ 
+ PCFLI_DECLSPEC int
+ Prolog_get_compound_name_arity(Prolog_term_ref t,
+-   Prolog_atom& name, int& arity);
++   Prolog_atom& name, size_t& arity);
+ 
+ PCFLI_DECLSPEC int
+ Prolog_get_arg(int i, Prolog_term_ref t, Prolog_term_ref a);
+--- ppl-1.2.orig/interfaces/Prolog/SICStus/sicstus_cfli.ic
 ppl-1.2/interfaces/Prolog/SICStus/sicstus_cfli.ic
+@@ -262,7 +262,7 @@ Prolog_get_atom_name(Prolog_term_ref t,
+   The behavior is undefined if \p t is not a Prolog compound term.
+ */
+ PCFLI_EXTERN_INLINE int
+-Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, int* ip) {
++Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, size_t* ip) {
+   assert(Prolog_is_compound(t));
+   return SP_get_functor(t, ap, ip);
+ }
+--- ppl-1.2.orig/interfaces/Prolog/SWI/swi_cfli.hh
 ppl-1.2/interfaces/Prolog/SWI/swi_cfli.hh
+@@ -346,7 +346,7 @@ Prolog_get_atom_name(Prolog_term_ref t,
+   The behavior is undefined if \p t is not a Prolog compound term.
+ */
+ inline int
+-Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, int* ip) {
++Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, size_t* ip) {
+   assert(Prolog_is_compound(t));
+   return PL_get_name_arity(t, ap, ip);
+ }
+--- ppl-1.2.orig/interfaces/Prolog/XSB/xsb_cfli.hh
 ppl-1.2/interfaces/Prolog/XSB/xsb_cfli.hh
+@@ -314,7 +314,7 @@ Prolog_get_atom_name(Prolog_term_ref t,
+   The behavior is undefined if \p t is not a Prolog compound term.
+ */
+ inline int
+-Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, int* ip) {
++Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, size_t* ip) {
+   assert(Prolog_is_compound(t));
+   *ap = p2c_functor(t);
+   *ip = p2c_arity(t);
+--- ppl-1.2.orig/interfaces/Prolog/YAP/yap_cfli.hh
 ppl-1.2/interfaces/Prolog/YAP/yap_cfli.hh
+@@ -313,7 +313,7 @@ Prolog_get_atom_name(Prolog_term_ref t,
+   The behavior is undefined if \p t is not a Prolog compound term.
+ */
+ inline int
+-Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, int* ip) {
++Prolog_get_compound_name_arity(Prolog_term_ref t, Prolog_atom* ap, size_t* ip) {
+   assert(Prolog_is_compound(t));
+   YAP_Functor f = YAP_FunctorOfTerm(t);
+   *ap = YAP_NameOfFunctor(f);
+--- ppl-1.2.orig/interfaces/Prolog/ppl_interface_generator_prolog_cc_code.m4
 pp

Bug#962926: [Aptitude-devel] Bug#962926: Images of aptitude screens are illegible due to being scaled to browser width

[Axel Beckert]

Control: tag -1 + unreproducible moreinfo patch

Hi Joshua,

thanks for the bug report.

Joshua C. Lackey wrote:
> All of the screenshots are illegible because a width="100%" property
> is set in each  tag, causing them to be stretched and introducing
> significant aliasing.

I can confirm that they are stretch to full width.

> Resizing the browser window to a smaller size
> does not help much. Due to the low resolution of the images (484x316)
> and small size of the text, even minimal scaling causes blurring and
> aliasing.

I though unfortunately (or luckily, depending on the point of view ;-)
can't reproduce this in Chromium from unstable. Even in fullscreen
mode on a 1900x1200 screen, they're crisp, sharp and very readable for
me, but of course also very pixely.

Sounds like a potential browser bug to me. Scaled images should never
be more blurry than unscaled images. They just should be more pixely.

In which browser did you have that effect? Maybe you can make a
screenshot of the issue, too.

> The text, though small, is completely clear and legible when
> the images are rendered at their native resolution.

Same for me in any scaling, i.e. I can't reproduce this. :-/

> I suggest removing the width='100%' property from each of the the
>  tags in the DocBook XML source (/doc/en/aptitude.xml) or
> adding an img selector in the CSS stylesheet (/doc/aptitude.css) with
> a width:auto property, which will override the the HTML  tags.

While I do see that this at least would solve the issue described
above, I'm reluctant to actually do this as it would introduce
legibility issues on big screens with high resolutions for some people
due to the (as you noted) rather small resolutions of the pictures.

The only clean solution for this which comes to my mind, is to redo
all the screenshots in some terminal with scalable fonts and do
vectorised SVG screenshots, e.g. with gtk-vector-screenshot.

Just tried this, but defacto, there's a PNG inside the SVG, at least
when trying inside lxterminal or gnome-terminal. :-(

Another idea is to use aha (https://github.com/theZiz/aha), but this
is non-trivial with a TUI application and only usable in HTML, not in
PDF, etc. We though could let them render in a browser and take a
vector screenshot of that.

If I do a "hardcopy" in screen and pipe that file through aha, the
layout is fine, but it doesn't catch the ANSI colors.

Piping the saved transcript of "script -c aptitude" through aha messes
with the indentation, but keeps the colors.

Best result (but still unusable) so far was with:

$ printf '[qy\n' | aptitude | aha > aptitude.html

But actually the "[" had no effect.

asciinema might also be an option, too, but that's usually for videos
not for pictures. But we could freeze a frame and take a vector
screenshot then.

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#962945: RFS: simgear/1:2019.1.1+dfsg-3.1 [NMU, RC] -- Simulator Construction Gear -- development files

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: simgear
   Version : 1:2019.1.1+dfsg-3.1
   Upstream Author : Curtis L. Olson 
 * URL : https://home.flightgear.org/
 * License : LGPL-2+
 * Vcs : https://salsa.debian.org/debian/simgear
   Section : libs

It builds those binary packages:

  libsimgear-dev - Simulator Construction Gear -- development files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/simgear/simgear_2019.1.1+dfsg-3.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix FTBFS with boost 1.71. (Closes: #960424)
 - Fix breaking change with osgText.


-- 
Regards
Sudip

Bug#960424: simgear: diff for NMU version 1:2019.1.1+dfsg-3.1

[Sudip Mukherjee]

Control: tags 960424 + patch
Control: tags 960424 + pending

Dear maintainer,

I've prepared an NMU for simgear (versioned as 1:2019.1.1+dfsg-3.1) and
uploaded it to mentors for sponsoring. Please feel free to tell me if I
should remove it.

--
Regards
Sudip

diff -Nru simgear-2019.1.1+dfsg/debian/changelog 
simgear-2019.1.1+dfsg/debian/changelog
--- simgear-2019.1.1+dfsg/debian/changelog  2019-11-14 08:01:57.0 
+
+++ simgear-2019.1.1+dfsg/debian/changelog  2020-06-16 12:29:15.0 
+0100
@@ -1,3 +1,11 @@
+simgear (1:2019.1.1+dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with boost 1.71. (Closes: #960424)
+- Fix breaking change with osgText.
+
+ -- Sudip Mukherjee   Tue, 16 Jun 2020 12:29:15 
+0100
+
 simgear (1:2019.1.1+dfsg-3) unstable; urgency=medium
 
   * Team upload
diff -Nru 
simgear-2019.1.1+dfsg/debian/patches/0001-osgText.getActiveFont-Breaking-change-within-OSG.patch
 
simgear-2019.1.1+dfsg/debian/patches/0001-osgText.getActiveFont-Breaking-change-within-OSG.patch
--- 
simgear-2019.1.1+dfsg/debian/patches/0001-osgText.getActiveFont-Breaking-change-within-OSG.patch
1970-01-01 01:00:00.0 +0100
+++ 
simgear-2019.1.1+dfsg/debian/patches/0001-osgText.getActiveFont-Breaking-change-within-OSG.patch
2020-06-16 12:29:15.0 +0100
@@ -0,0 +1,79 @@
+From d883ab278d10c89580d5bbc4473d2e9fc375b7b9 Mon Sep 17 00:00:00 2001
+From: Scott Giese 
+Date: Sun, 4 Aug 2019 02:27:57 -0500
+Subject: [PATCH] [osgText.getActiveFont] Breaking change within OSG
+
+---
+
+upstream link: 
https://github.com/FlightGear/simgear/commit/d883ab278d10c89580d5bbc4473d2e9fc375b7b9
+issue link: 
https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/d3396d2b-0ce6-490e-b32f-42174895b...@flightgear.org/
+
+ simgear/canvas/elements/CanvasText.cxx | 22 +-
+ 1 file changed, 17 insertions(+), 5 deletions(-)
+
+diff --git a/simgear/canvas/elements/CanvasText.cxx 
b/simgear/canvas/elements/CanvasText.cxx
+index 3051045f..060436e1 100644
+--- a/simgear/canvas/elements/CanvasText.cxx
 b/simgear/canvas/elements/CanvasText.cxx
+@@ -53,10 +53,13 @@ namespace canvas
+   TextLine lineAt(size_t i) const;
+ 
+   /// Get nearest line to given y-coordinate
++#if OSG_VERSION_LESS_THAN(3,6,5)
+   TextLine nearestLine(float pos_y) const;
+-
+-
+   SGVec2i sizeForWidth(int w) const;
++#else
++  TextLine nearestLine(float pos_y);
++  SGVec2i sizeForWidth(int w);
++#endif
+ 
+   osg::BoundingBox
+ #if OSG_VERSION_LESS_THAN(3,3,2)
+@@ -319,9 +322,14 @@ namespace canvas
+   }
+ 
+   
//
++#if OSG_VERSION_LESS_THAN(3,6,5)
+   TextLine Text::TextOSG::nearestLine(float pos_y) const
++#else
++  TextLine Text::TextOSG::nearestLine(float pos_y)
++#endif
+   {
+-osgText::Font const* font = getActiveFont();
++auto font = getActiveFont();
++
+ if( !font || lineCount() <= 0 )
+   return TextLine(0, this);
+ 
+@@ -343,12 +351,16 @@ namespace canvas
+   // simplified version of osgText::Text::computeGlyphRepresentation() to
+   // just calculate the size for a given weight. Glpyh calculations/creating
+   // is not necessary for this...
++#if OSG_VERSION_LESS_THAN(3,6,5)
+   SGVec2i Text::TextOSG::sizeForWidth(int w) const
++#else
++  SGVec2i Text::TextOSG::sizeForWidth(int w)
++#endif
+   {
+ if( _text.empty() )
+   return SGVec2i(0, 0);
+ 
+-osgText::Font* activefont = const_cast(getActiveFont());
++auto activefont = getActiveFont();
+ if( !activefont )
+   return SGVec2i(-1, -1);
+ 
+@@ -727,7 +739,7 @@ namespace canvas
+   }
+ 
+ #else
+-  void Text::TextOSG::computePositionsImplementation() 
++  void Text::TextOSG::computePositionsImplementation()
+   {
+   TextBase::computePositionsImplementation();
+   }
+-- 
+2.11.0
+
diff -Nru simgear-2019.1.1+dfsg/debian/patches/fix_boost.patch 
simgear-2019.1.1+dfsg/debian/patches/fix_boost.patch
--- simgear-2019.1.1+dfsg/debian/patches/fix_boost.patch1970-01-01 
01:00:00.0 +0100
+++ simgear-2019.1.1+dfsg/debian/patches/fix_boost.patch2020-06-16 
12:12:52.0 +0100
@@ -0,0 +1,34 @@
+Description: Fix FTBFS with boost 1.71
+ The macro Boost_VERSION returned 1.71.0. Based on: 
https://cmake.org/cmake/help/v3.15/module/FindBoost.html
+ we should use Boost_VERSION_MACRO to get the version in the form of 107100.
+ Fixing boost dependency brought out the problem with include folder.
+ The header files were created in build/simgear folder and the source files
+ included 'simgear/simgear_config.h' which was not found as 'build' was
+ not in the include path.
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/960424
+
+---
+
+--- simgear-2019.1.1+dfsg.orig/CMakeLists.txt
 simgear-2019.1.1+dfsg/CMakeLists.txt
+@@ -519,6 +519,7 @@ include(CheckCXXFeatures)
+ # use BEFORE to ensure local directories are used first,
+ # ahead

Bug#962039: [Pkg-javascript-devel] Bug#962037: Plan B for not being able to replicate upstream exports exactly

[Pirate Praveen]

On 2020, ജൂൺ 16 7:46:01 AM IST, Daniel Ring  wrote:
>Control: reopen 962037
>Control: reopen 962039
>
>Sorry about closing the bugs early, I'm used to close-on-commit instead 
>of close-on-release and I forgot Debian handles things differently. I 
>updated Rainloop's changelog on Salsa to indicate that these are fixed.

Uploaded.

>I didn't realize that this bug was due to Rainloop blocking the 
>migration of node-less to unstable; my comment about testing 
>experimental versions was because this started off as a node-less bug, 
>and it looked like most of the issues weren't related to Rainloop. I'm 
>happy to help with transitions from the Rainloop side but it may take me 
>up to a few weeks to respond to non-security issues.

OK, no worries. I initially thought it was a rainloop bug, then I had to make 
more changes to less.js build and then confirmed rainloop needs fixing as well.

>Is pkg-js-tools stable, and is there good documentation for it? I took a 
>quick look but only found a README with a list of debhelper hooks. My 
>main argument for using flat files for Rainloop's bundled dependencies 
>is that I only look at this package once or twice a year when upstream 
>releases a new version, and I don't want to relearn the tooling each 
>time. (That's also why I replaced my custom Makefile with upstream's 
>build system.) I agree that Quilt is a better way to handle the patches 
>to the bundled libraries though.

The thing is, other people in the team can help fix things when required and 
using standard tools and processes helps.

See https://wiki.debian.org/Javascript/GroupSourcesTutorial and you can ask in 
pkg-javascript-devel for help.

>By "broken in unstable" I just meant Rainloop's code in Salsa, which now 
>depends on experimental node-less to build; the compiled package is fine 
>either way. (Also, it looks like updated node-less is now in unstable, 
>so it's not broken anymore.)

I uploaded fixed rainloop, so we are good now.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#931930: Workaround ? [Re: firmware-misc-nonfree: Please, include i915/icl_dmc_ver1_07.bin]

[Gregor Riepl]

> Does someone has a woraround ? The Debian source package doesn't have
> the right version of the files.

You can pull the current version from Salsa and build the .deb yourself:
https://salsa.debian.org/kernel-team/firmware-nonfree

Just be aware that you have to manually replace your locally built
package when the package is uploaded to the Debian servers, as it will
have the same version.

> BTW, do the maintainer(s) have acknowledged the problem ?

I'm not sure...
Maybe raise the severity of the issue a bit?

Bug#962838: Apparmor profile for syslog-ng assumes trivial config

[intrigeri]

Control: severity -1 minor
Control: tag -1 + upstream

Hi,

Elliott Mitchell (2020-06-14):
> [##.##] audit: type=1400 audit(): 
> apparmor="ALLOWED" operation="open" profile="syslog-ng" 
> name="/proc//cmdline" pid= comm="syslog-ng" 
> requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> [##.##] audit: type=1400 audit(): 
> apparmor="ALLOWED" operation="open" profile="syslog-ng" 
> name="/proc//loginuid" pid= comm="syslog-ng" 
> requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> [##.##] audit: type=1400 audit(): 
> apparmor="ALLOWED" operation="open" profile="syslog-ng" 
> name="/proc//sessionid" pid= comm="syslog-ng" 
> requested_mask="r" denied_mask="r" fsuid=0 ouid=0
>
> I'm cautiously optimistic this is due to the AppArmor profile for
> syslog-ng being incomplete and not someone having broken into this
> machine and done something to syslog-ng.

It looks like it, indeed.

Please report upstream any problem with an AppArmor profile that is
included in the apparmor-profiles package:

  https://gitlab.com/apparmor/apparmor/-/issues

The apparmor-profiles package exists solely to provide a way for users
to test these experimental profiles and help improve them upstream
if needed. Do not expect these profiles to work out-of-the-box.

Bug#962405: /proc/sys/kernel/random/boot_id DENIED

[intrigeri]

Control: tag -1 + pending

Hi,

Alan Sermons (2020-06-10):
> Complete apparmor novice here, so I'm not the best person to troubleshoot
> things (but I'm willing to learn)...

Actually, your investigation did save me much time. Thanks! :)

The fix will be part of the next upload of src:apparmor.

Bug#957875: Fix build error with GCC 10 due to multiple definition of `toplevel'

[Salvatore Bonaccorso]

Hi

When building with GCC 10, gcc is stricter in handling handling of
symbol clashes.

Fedora, has fixed this with a patch from Dominik Mierzejewski:
https://src.fedoraproject.org/rpms/tftp/c/5e2aa55b6802a52ef480d688b3ae4751220f20e0.patch

Attaching the corresponding patch for git am.

Regards,
Salvatore

>From 9e7641bf58df9dda3bc51f381f371fa7cbce47af Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Tue, 16 Jun 2020 14:06:14 +0200
Subject: [PATCH] Fix build error with GCC 10 due to multiple definition of
 `toplevel'

GCC is stricter in handling of symbol clashes and throws:

gcc-10  tftp.o main.o ../common/libcommon.a  
/build/tftp-hpa/lib/libxtra.a  -o tftp
/usr/bin/ld: main.o:/build/tftp-hpa/tftp/main.c:98: multiple definition 
of `toplevel'; tftp.o:/build/tftp-hpa/tftp/tftp.c:51: first defined here

CC: Dominik 'Rathann' Mierzejewski 
Link: https://bugs.debian.org/957875
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1800195
Signed-off-by: Salvatore Bonaccorso 
---
 tftp/tftp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tftp/tftp.c b/tftp/tftp.c
index d15da2200ef8..d067f9699778 100644
--- a/tftp/tftp.c
+++ b/tftp/tftp.c
@@ -48,7 +48,7 @@ extern int maxtimeout;
 #define PKTSIZESEGSIZE+4
 char ackbuf[PKTSIZE];
 int timeout;
-sigjmp_buf toplevel;
+extern sigjmp_buf toplevel;
 sigjmp_buf timeoutbuf;
 
 static void nak(int, const char *);
-- 
2.20.1

Bug#962530: Tor service won't start when apparmor is active and "/" is on an overlayfs

[intrigeri]

Control: reassign -1 apparmor
Control: tag -1 + moreinfo

Hi,

Stefan Baur (2020-06-09):
> As stated in the subject: The tor service won't start when apparmor is
> active and the root filesystem is stored on an overlayfs.

Right, AppArmor does not play well with overlayfs out of the box.
Making that combination work requires lots of customization,
that's specific to the exact filesystem mount stack layout.

Due to that limitation, apparmor.service is supposed to *not* start in
the context of a Debian Live system. Quoting apparmor.service:

  # Don't start this unit on the Debian Live CD when using overlayfs
  ConditionPathExists=!/run/live/overlay/work

So, I have a question:

> 4. run the following commands:
>apt update
>apt install apparmor -y
>service apparmor start

Did the apparmor service start before you started it manually?
I suppose it did not start, hence the need to start it manually,
right?

> I believe tails (The Amnesic Incognito Live System) uses tor and
> apparmor for their live cd, which, as far as I know, is Debian-based as
> well, so it would be interesting to see how they solved this issue.
> Maybe intrigeri (https://people.debian.org/~intrigeri / intrigeri at
> debian dot org) can provide some insight?

Sure. Tails' customization that makes it work with overlayfs
lives in files that should be linked from:
https://tails.boum.org/contribute/design/application_isolation/

> As apparmor is causing the issue, but the corresponding "system_tor"
> config file is part of the tor package, I figured I should file this
> against the tor package.  Feel free to reassign the bug to the apparmor
> package if bugs about broken/incomplete apparmor profiles should be
> filed against that one.

I'm reassigning to apparmor: if apparmor.service starts automatically
in a Debian Live environment, that's a bug in that service.

Cheers!

Bug#960424: simgear: diff for NMU version 1:2019.1.1+dfsg-3.1

[Dr. Tobias Quathamer]

Am 16.06.20 um 13:57 schrieb Sudip Mukherjee:
> Control: tags 960424 + patch
> Control: tags 960424 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for simgear (versioned as 1:2019.1.1+dfsg-3.1) and
> uploaded it to mentors for sponsoring. Please feel free to tell me if I
> should remove it.

Hi Sudip,

thanks a lot for your patch! However, I did not use it, because it
finally motivated me to update the package to the latest upstream
version. With that update, the FTBFS is also fixed.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#962946: mdadm: --name not valid in grow mode

[Marc Lehmann]

Package: mdadm
Version: 4.1-1
Severity: normal

Dear Maintainer,

The mdadm manpage lists --name under "For create, build, or grow". But
mdadm disagrees:

   # mdadm --grow /dev/md127 --name raid1
   mdadm: :option --name not valid in grow mode

-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST 
MAILADDR root

--- /etc/default/mdadm
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] 
[raid10] 
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

   80 1953514584 sda
   81 262144 sda1
   82 1782579200 sda2
   83  170672199 sda3
   8   16  117220824 sdb
   8   17 102400 sdb1
   8   18  117117383 sdb2
   8   32  488386584 sdc
   8   48 2930266582 sdd
   8   49   1007 sdd1
   8   50 262143 sdd2
   8   51 2930002944 sdd3
   8   64 58595475456 sde
   8   65 58595474415 sde1
 2530  838860800 dm-0
 2531  536870912 dm-1
 2532 262144 dm-2
 2533 57756610560 dm-3
 2534 57756610560 dm-4
 2535  536870912 dm-5
 2536  536854528 dm-6
 2537  838844416 dm-7
 2538   25165824 dm-8
 25391048576 dm-9
 253   10  209715200 dm-10
 253   11   25165824 dm-11
 253   12 57756610560 dm-12
 253   13  209715200 dm-13

--- LVM physical volumes:
  PV VG Fmt  Attr PSize  PFree   
  /dev/sda2  vg_cerebro lvm2 a--   1.66t <450.50g
  /dev/sde1  vg_cerebro lvm2 a--  54.57t   0 
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=8143448k,nr_inodes=2035862,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1633596k,mode=755)
/dev/mapper/cryptroot on / type btrfs 
(rw,noatime,nossd,space_cache,subvolid=257,subvol=/rootfs)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/hugetlb type cgroup 
(rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup 
(rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=44,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21807)
mqueue on /dev/mqueue type mqueue (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/mapper/cryptroot on /cryptroot type btrfs 
(rw,noatime,nossd,space_cache,subvolid=5,subvol=/)
/dev/mapper/vg_cerebro-boot on /boot type ext4 (rw,noatime)
/dev/sda1 on /boot/efi type vfat 
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mapper/cryptlocalvol on /cryptlocalvol type btrfs 
(rw,relatime,nossd,discard,space_cache,subvolid=5,subvol=/)
/dev/mapper/cryptlocalvol on /localvol type btrfs 
(rw,relatime,nossd,discard,space_cache,subvolid=257,subvol=/rootfs)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime)
/etc/auto.

Bug#962947: ITP: shovill: Assemble bacterial isolate genomes from Illumina paired-end reads

[Nilesh Patra]

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

* Package name: shovill
  Version : 1.1.0
  Upstream Author : Torsten Seemann
* URL : https://github.com/tseemann/shovill

* License : GPL-3+
  Programming Lang: Perl
  Description : Assemble bacterial isolate genomes from Illumina
paired-end reads

 Shovill is a pipeline which uses SPAdes at its core,
 but alters the steps before and after the primary
 assembly step to get similar results in less time.
 Shovill also supports other assemblers like SKESA,
 Velvet and Megahit, so you can take advantage of the
 pre- and post-processing the Shovill provides
 with those too.

I take the responsibility to maintain this package.

Bug#962948: ITP: vsmartcard -- A virtual smartcard toolkit

[Philippe Thierry]

Package: wnpp
Severity: wishlist
Owner: phi...@debian.org


* Package name: vsmartcard
  Version : 3.3
  Upstream Author : Frank Morgner
* URL : https://frankmorgner.github.io/vsmartcard/
* License : GPL3+
  Programming Lang: C
  Section : utils
  Description : A complete toolkit for virtual smartcards
emulation and interaction

thanks,
-- 
Philippe THIERRY


signature.asc
Description: PGP signature

Bug#962949: ITS: libxsmm

[Boyuan Yang]

Source: libxsmm
Version: 1.9-1
Tags: sid
X-Debbugs-CC: mba...@debian.org
Severity: important

Dear Debian libxsmm package maintainer,

After looking into the package you maintain (libxsmm, 
https://tracker.debian.org/pkg/libxsmm), I found that this package
received no updates since its initial release in 2018 and is not in
good shape (with RC bugs). As a result, I am filing an ITS (Intent to
Salvage) request against your package according to section 5.12 of
Debian's Developers' Reference [1].

Please let me know if you are still willing to maintain this package.
According to the criteria listed at [2], I am supposed to upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(July 7, 2020) to continue with package salvaging. Since this package
is also team-maintained under Debian Science Team, I will be uploading
team upload to fix release-critical bugs first and make another upload
onto DELAYED/0 after 28 days (July 14, 2020) to take over package
maintenance.


My current plan is to fix those RC bugs first. The detailed plan is:

* (Build-)depend on sse4.2-support to ensure SSE4.2 support
* Disallow packaging building on non-x86 non-64bit architectures
* Drop python2
* Package new upstream release, if feasible


If you find it necessary to pause the ITS process at any time, please
let me know *immediately* by replying this bug report.

Thank you for your previous work in Debian and looking forward to your
reply.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging


-- 
Regards,
Boyuan Yang


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

Bug#946308: freespace2: diff for NMU version 3.7.4+repack-1.1

[Adrian Bunk]

Control: tags 946308 + pending

Dear maintainer,

I've prepared an NMU for freespace2 (versioned as 3.7.4+repack-1.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru freespace2-3.7.4+repack/debian/changelog freespace2-3.7.4+repack/debian/changelog
--- freespace2-3.7.4+repack/debian/changelog	2018-07-12 11:57:59.0 +0300
+++ freespace2-3.7.4+repack/debian/changelog	2020-06-16 16:22:34.0 +0300
@@ -1,3 +1,10 @@
+freespace2 (3.7.4+repack-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove -march=native usage. (Closes: #946308)
+
+ -- Adrian Bunk   Tue, 16 Jun 2020 16:22:34 +0300
+
 freespace2 (3.7.4+repack-1) unstable; urgency=medium
 
   * New upstream release [July 2016].
diff -Nru freespace2-3.7.4+repack/debian/patches/i386-baseline.patch freespace2-3.7.4+repack/debian/patches/i386-baseline.patch
--- freespace2-3.7.4+repack/debian/patches/i386-baseline.patch	1970-01-01 02:00:00.0 +0200
+++ freespace2-3.7.4+repack/debian/patches/i386-baseline.patch	2020-06-16 16:22:31.0 +0300
@@ -0,0 +1,15 @@
+Description: SSE is not part of the i386 baseline
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/946308
+
+--- freespace2-3.7.4+repack.orig/configure.ac
 freespace2-3.7.4+repack/configure.ac
+@@ -158,7 +158,7 @@ case "$target" in
+ 		fs2_os_linux="yes"
+ 
+ 		if test "$fs2_generic_architecture" = "yes" ; then
+-			D_CFLAGS="$D_CFLAGS -mtune=generic -mfpmath=sse -msse -msse2"
++			D_CFLAGS="$D_CFLAGS -mtune=generic"
+ 		else
+ 			D_CFLAGS="$D_CFLAGS -march=native"
+ 		fi
diff -Nru freespace2-3.7.4+repack/debian/patches/series freespace2-3.7.4+repack/debian/patches/series
--- freespace2-3.7.4+repack/debian/patches/series	2015-04-16 04:46:03.0 +0300
+++ freespace2-3.7.4+repack/debian/patches/series	2020-06-16 16:22:31.0 +0300
@@ -0,0 +1 @@
+i386-baseline.patch
diff -Nru freespace2-3.7.4+repack/debian/rules freespace2-3.7.4+repack/debian/rules
--- freespace2-3.7.4+repack/debian/rules	2018-07-12 11:47:25.0 +0300
+++ freespace2-3.7.4+repack/debian/rules	2020-06-16 16:22:31.0 +0300
@@ -15,7 +15,7 @@
 $(info DEB_BUILD_MAINT_OPTIONS:$(origin DEB_BUILD_MAINT_OPTIONS)=$(DEB_BUILD_MAINT_OPTIONS))
 
 #LDFLAGS+= -Wl,--as-needed
-CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech
+CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech --enable-generic-architecture
 
 %:
 	dh $@

Bug#962950: RM: boost1.67 -- ROM; forc-removal, buggy, impossible to rebuild, should not be released

[Dimitri John Ledkov]

Package: ftp.debian.org
Severity: normal

boost1.67 is buggy, it cannot be rebuild against new icu abi, as that
would break dist-upgrades from stable->testing; it uses python2 which
must be removed; and it cannot be used together with current icu from
testing/unstable.

All of the reverse-dependencies are RC buggy, scheduled to be
autoremoved and/or should be made uninstallable.

Please force-remove boost1.67 from unstable, and if any
reverse-dependencies / reverse-build-dependencies are left, make them
uninstallable.

Once dogecoin/leatherman/facter are removed or resolved in testing,
boost1.67 can be removed from testing too.

kig maintianer downgraded RC bugs against kig package, and forces to
use buggy boost1.67 with unreleasable python2 bindings, which are
optional in kig.

Regards,

Dimitri.

Bug#962951: aptitude: missing command 'status'

[Michael Becker]

Package: aptitude
Version: 0.8.13-1+b1
Severity: wishlist

I would like to have a command 'aptitude status' which shows the last line 
displayed by 'aptitude -v update':

Current status: 0 (+0) broken, 0 (+0) upgradable, 0 (+0) new.

without having to actually check for an update.
This command should be available for non root users.

Bug#962952: azure-cli: exception when connecting to azure services

[Ritesh Raj Sarraf]

Package: azure-cli
Version: 2.6.0-1
Severity: important

rrs@priyasi:~/NoBackup$ az vm user update --resource-group 
lab40-obs-ubuntu-docker-494104 --name obs-ubuntu-docker --username rrs 
--password 

The command failed with an unexpected error. Here is the traceback:

No module named 'antlr4'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/knack/cli.py", line 215, in invoke
cmd_result = self.invocation.execute(args)
  File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", 
line 553, in execute
self.commands_loader.load_arguments(command)
  File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 345, 
in load_arguments
loader.load_arguments(command)  # this adds entries to the argument 
registries
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/vm/__init__.py", line 
31, in load_arguments
from azure.cli.command_modules.vm._params import load_arguments
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/vm/_params.py", line 
31, in 
from azure.cli.command_modules.monitor.actions import get_period_type
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/monitor/actions.py", 
line 7, in 
import antlr4
ModuleNotFoundError: No module named 'antlr4'

To open an issue, please run: 'az feedback'
19:37 ♒ ॐ ♅ ⛢   ☹ 😟=> 1  


I couldn't find any antlr4 named python module in Debian.

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

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

Versions of packages azure-cli depends on:
ii  python33.8.2-3
ii  python3-azure-cli  2.6.0-1

azure-cli recommends no packages.

azure-cli suggests no packages.

-- no debconf information

Bug#962953: ITP: wahay -- Easy-to-use, secure and decentralized conference call

[Clement Hermann]

Package: wnpp
Severity: wishlist
Owner: Clement Hermann 

* Package name: wahay
  Version : 0.0~git20200606.4f8e43a-1
  Upstream Author : Centro de Autonomía Digital (https://autonomia.digital)
* URL : https://wahay.org
* License : GPLv3
  Programming Lang: Go
  Description : Easy-to-use, secure and decentralized conference call
 Wahay is voice call application that allows you to easily host and participate
 in conference calls, without the need for any centralized servers or services.
 It is meant to be as easy-to-use as possible, while still providing extremely
 high security and privacy out of the box.
 .
 In order to do this, it uses Tor (https://torproject.org) Onion Services
 in order to communicate between the end-points, and the Mumble
 (https://www.mumble.info) protocol for the actual voice communication.

Bug#962954: RM: fever [mipsel] -- ICE; FTBFS; Go compiler is broken on mipsel

[Sascha Steinbiss]

Package: ftp.debian.org
Severity: normal

Please remove the old version of the fever binary package from testing
for the mipsel architecture.
Due to #960674, it currently does not build on mipsel as there is a
deeper problem with the Go compiler on this architecture. Please see the
corresponding bug report for more information [1].

I would like to remove this arch that currently blocks testing migration
for upstream version updates. It is very unlikely that the package will
be used on MIPS systems.

Thanks!
Sascha

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960674

Bug#946308: freespace2: diff for NMU version 3.7.4+repack-1.1

[Dmitry Smirnov]

On Wednesday, 17 June 2020 12:05:19 AM AEST Adrian Bunk wrote:
> I've prepared an NMU for freespace2 (versioned as 3.7.4+repack-1.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I should
> cancel it.

Thank you very much for your help.

-- 
Cheers,
 Dmitry Smirnov.

---

A foolish faith in authority is the worst enemy of truth.
-- Albert Einstein


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

Bug#932296: qa.debian.org: getwatch filling up /tmp

[Julien Cristau]

On Wed, Dec 18, 2019 at 02:03:13PM +0100, Julien Cristau wrote:
> Control: severity -1 serious
> 
> On Thu, Aug 08, 2019 at 01:45:27PM +0200, Julien Cristau wrote:
> > On Wed, Jul 17, 2019 at 10:11:39PM +0200, Lucas Nussbaum wrote:
> > > On 17/07/19 at 14:01 +0200, Julien Cristau wrote:
> > > > something in udd seems to extract entire source packages to
> > > > /tmp/getwatch.*.  This fills up the disk.  Please make it not do that.
> > > 
> > > Hi,
> > > 
> > > Thanks for reporting.
> > > 
> > > It needs to extract the source packages to get the watch file. I don't
> > > think there's a way to ask dpkg-source to only extract a single file,
> > > and I don't want to re-implement dpkg-source.
> > > 
> > It would be a single call to tar or patch though, which doesn't seem
> > like a huge amount of effort.
> > 
> > > Reviewing the code, there was a path where the tmp dir was not removed.
> > > I've fixed that. I'm not 100% sure this fixes everything, but it should
> > > clearly help.
> > > 
> > There were quite a few getwatch temp dirs before I rebooted ullmann just
> > now because it was out of space.
> > 
> > > However, I also note that /tmp is on /, and / is quite small (only 5.3
> > > GB remaining). Would it be possible to add some disk space for /tmp or /
> > > on ullmann?
> > > 
> > I'd dispute the "quite small" bit, extracting watch files shouldn't need
> > more than 5g.  But you could also put your temp files somewhere under
> > /srv?
> > 
> This happened again.  If it won't get fixed I'll go ahead and disable that 
> job.
> 
Done now, removed the "upstream" importer from the config file.

Cheers,
Julien

Bug#962955: haskell-crypto-pubkey-openssh: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Source: haskell-crypto-pubkey-openssh
Version: 0.2.7-9
Severity: grave
Justification: renders package unusable
Forwarded: https://github.com/knsd/crypto-pubkey-openssh/pull/23

This package seems to be unmaintained (last upstream upload in 2015).
Does not build with GHC 8.8, is not part of Stackage and has no rev
dependencies.

I intend to remove this package.

-- 
Ilias

Bug#962956: reniced: reniced logs several syntax errors

[Francesco Potortì]

Package: reniced
Version: 1.21-1
Severity: normal

In daemon.log I read:

Jun 16 15:43:03 tucano reniced[3522]: Starting reniced:
Jun 16 15:43:03 tucano reniced[3552]: Starting reniced:
Jun 16 15:43:03 tucano reniced[3552]: rgument " " isn't numeric in addition 
(+) at /usr/bin/reniced line Argument " " isn't numeric in addition (+) at 
/usr/bin/reniced line 435,  line 3.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 4.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 5.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 6.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 7.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 8.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 9.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 10.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 11.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 12.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 13.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 14.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 15.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 16.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 17.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 18.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 19.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 20.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 21.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 22.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 23.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 24.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 25.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 26.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 27.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 28.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 29.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 30.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 31.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 32.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 33.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 34.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 35.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 36.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 37.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 38.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 39.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) 

Bug#962957: ITP: puppet-module-etcddiscovery -- Puppet module for Etcd-discovery service

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-etcddiscovery
  Version : 0.1.0
  Upstream Author : Thomas Goirand 
* URL : 
https://salsa.debian.org/openstack-team/puppet/puppet-module-etcddiscovery
* License : Apache-2.0
  Programming Lang: Puppet, Ruby
  Description : Puppet module for Etcd-discovery service

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages both the installation and configuration of OpenStack
 Etcd-discovery.

Note: This is part of openstack-cluster-installer, and it's useful for
setting-up magnum without internet connectivity.

Bug#962958: haskell-edison-core: Removal notice: broken and unuseful

[Ilias Tsitsimpis]

Source: haskell-edison-core
Version: 1.3.2.1-3
Severity: grave
Justification: renders package unusable
Forwarded: https://github.com/robdockins/edison/pull/16

This package does not build with GHC 8.8 and is not part of Stackage.
Agda replaced Edison with Data.Sequence in the latest version, so there
are no rev dependencies anymore.

I intend to remove this package.

-- 
Ilias

Bug#962959: haskell-edison-api: Removal notice: broken and unuseful

[Ilias Tsitsimpis]

Source: haskell-edison-api
Version: 1.3.1-5
Severity: grave
Justification: renders package unusable
Forwarded: https://github.com/robdockins/edison/pull/16

This package does not build with GHC 8.8 and is not part of Stackage.
Agda replaced Edison with Data.Sequence in the latest version, so there
are no rev dependencies anymore.

I intend to remove this package.

-- 
Ilias

Bug#962960: kdiff3: Choose X Everywhere / For All Unsolved menu items missing

[Matthew Gabeler-Lee]

Package: kdiff3
Version: 1.8.01-1+b1
Severity: normal

The Merge menu items to Choose A/B/C Everywhere or For All Unsolved
(Whitespace) Conflicts are not showing up in the kdiff3 build in bullseye. 
Downgrading to the version in buster and they show up again.

I also tried 1.8.01-1 from snapshot.debian.org and it has the same issue.

The changelog shows this entry:

  Don't enable "Choose C for Everthing" on two way merge

but this is also seeming to happen on 3 way merge (via git mergetool)

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

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

Versions of packages kdiff3 depends on:
ii  kio   5.70.1-1
ii  libc6 2.30-8
ii  libkf5configcore5 5.70.0-1
ii  libkf5configwidgets5  5.70.0-1
ii  libkf5coreaddons5 5.70.0-1
ii  libkf5crash5  5.70.0-1
ii  libkf5i18n5   5.70.0-1
ii  libkf5iconthemes5 5.70.0-1
ii  libkf5kiocore55.70.1-1
ii  libkf5kiowidgets5 5.70.1-1
ii  libkf5parts5  5.70.0-1
ii  libkf5textwidgets55.70.0-1
ii  libkf5widgetsaddons5  5.70.0-1
ii  libkf5xmlgui5 5.70.0-1
ii  libqt5core5a  5.12.5+dfsg-10+b1
ii  libqt5gui55.12.5+dfsg-10+b1
ii  libqt5printsupport5   5.12.5+dfsg-10+b1
ii  libqt5widgets55.12.5+dfsg-10+b1
ii  libstdc++610.1.0-3

Versions of packages kdiff3 recommends:
ii  kdiff3-doc  1.8.01-1

kdiff3 suggests no packages.

-- no debconf information

Bug#962961: haskell-gnutls: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Source: haskell-gnutls
Version: 0.2-6
Severity: grave
Justification: renders package unusable

This package seems to be unmaintained (homepage returns 404, last upload
from 2015). It does not build with GHC 8.8, is not part of Stackage and
has no rev dependencies.

I intend to remove this package.

-- 
Ilias

Bug#962962: haskell-hstatsd: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Source: haskell-hstatsd
Version: 0.1-7
Severity: grave
Justification: renders package unusable

This package seems to be unmaintained (last upstream upload in 2013).
Does not build with GHC 8.8, is not part of Stackage and has no rev
dependencies.

I intend to remove this package.

-- 
Ilias

Bug#881871: stretch-pu: package bacula/7.4.4+dfsg-6

[Adam D. Barratt]

On Tue, 2020-06-16 at 10:06 +0200, Carsten Leonhardt wrote:
> Julien Cristau  writes:
> 
> > Control: tag -1 confirmed
> > Sorry for the delay, please go ahead.
> 
> For information, I've uploaded the package some time ago and it's
> waiting in the NEW queue for FTP master review.

Thanks for the update.

I've asked on IRC if an ftpmaster can have a look (it needs a master
rather than an assistant, in order to get the package to appear in our
review queue afterwards).

Regards,

Adam

Bug#962875: [Debian-iot-maintainers] Processed: block 962875 with 962876 962877 962878 962879 962880 962881 962882 962883 962884 962885 962886 962887

[Nicolas Mora]

This bug will be resolved when Glewlwyd 2.x will be packaged into unstable.

I'm currently waiting for iddawc in the NEW queue to be accepted in
experimental to move on.



signature.asc
Description: OpenPGP digital signature

Bug#962964: haskell-io-choice: Removal notice: broken and obsolete

[Ilias Tsitsimpis]

Source: haskell-io-choice
Version: 0.0.7-1
Severity: grave
Justification: renders package unusable

Since GHC 8.0, IO is now an instance of Alternative, making this package
obsolete (see https://github.com/kazu-yamamoto/io-choice/issues/6).
Newer versions of mighttpd2 do not depend on it anymore, so there are
no rev dependencies left.

I intend to remove this package.

-- 
Ilias

Bug#962963: RFS: sosreport/3.9.1-1 -- Set of tools to gather troubleshooting data from a system

[Eric Desrochers]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : sosreport
Version : 3.9.1-1
Upstream Author : Bryn M. Reeves
* URL : https://github.com/sosreport/sos
* License : GPL-2+
* Vcs : https://salsa.debian.org/sosreport-team/sosreport
Section : admin

It builds those binary packages:

sosreport - Set of tools to gather troubleshooting data from a system

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/s/sosreport/sosreport_3.9.1-1.dsc

Changes since the last upload:

* New 3.9.1 upstream release.
This maintenance release includes:
- New plugins: sos_extras, ovirt_engine_backup, console,
validation_framework.
- lxd plugin collections have been overhauled.
- Fixed handling of the namespace pattern for the networking
plugin.
- A basic path is now defined in Policy for all subclasses.
.
Plugin API Enhancements:
- Enablement checks have been extended to include architecture
constraints.
- SoSPredicate has been extended to include architecture constraints,
as well as negative constraints for all elements.
- Plugins will now capture service status information for all services
defined in the services class attr.
.
Further release information and tarballs are available at:
- https://github.com/sosreport/sos/releases/tag/3.9.1
.
* Former patches now fixed upstream:
- d/p/0001-unittest-py3-fix.patch
.
* Other specific modifications:
- Include simple.sh, an upstream port of the travis test to bash,
as part of the package autopkgtest.

Regards,

Bug#962861: RFP: drm-info -- Small utility to dump info about DRM devices

[Sudip Mukherjee]

On Mon, Jun 15, 2020 at 09:35:56AM +0200, Guido Günther wrote:
> Package: wnpp
> Severity: wishlist
> 

> 
> drm_info dumps information about available drm device like available
> devices, planes, encoders, crtcs and connectors and their DRM
> properties.

This looks like an useful utility and I did an initial packaging. But
while testing I get a segfault after printing all the information.

$ drm_info 
Node: /dev/dri/card0
├───Driver: bochs-drm (bochs dispi vga interface (qemu stdvga)) version 1.0.0 
(20130925)
│   ├───DRM_CLIENT_CAP_STEREO_3D supported
│   ├───DRM_CLIENT_CAP_UNIVERSAL_PLANES supported
│   ├───DRM_CLIENT_CAP_ATOMIC supported
│   ├───DRM_CLIENT_CAP_ASPECT_RATIO supported
│   ├───DRM_CLIENT_CAP_WRITEBACK_CONNECTORS supported
│   ├───DRM_CAP_DUMB_BUFFER = 1
│   ├───DRM_CAP_VBLANK_HIGH_CRTC = 1
│   ├───DRM_CAP_DUMB_PREFERRED_DEPTH = 24
│   ├───DRM_CAP_DUMB_PREFER_SHADOW = 0
│   ├───DRM_CAP_PRIME = 0
│   ├───DRM_CAP_TIMESTAMP_MONOTONIC = 1
│   ├───DRM_CAP_ASYNC_PAGE_FLIP = 0
│   ├───DRM_CAP_CURSOR_WIDTH = 64
│   ├───DRM_CAP_CURSOR_HEIGHT = 64
│   ├───DRM_CAP_ADDFB2_MODIFIERS = 0
│   ├───DRM_CAP_PAGE_FLIP_TARGET = 0
│   ├───DRM_CAP_CRTC_IN_VBLANK_EVENT = 1
│   ├───DRM_CAP_SYNCOBJ = 0
│   └───DRM_CAP_SYNCOBJ_TIMELINE = 0
Segmentation fault

I also tried with "drm_info -j" and that works pergectly without any error.

Note: I have used Debian packages of json-c, libdrm and libpci. It will
be good to have a manpage along with the fix for segfault.

--
Regards
Sudip

Bug#947803: smartmontools: smartctl -l error causes Micron 2200S NVME to fail

[Michael Becker]

same here – Debian sid

smartctl --version: smartctl 7.1 2019-12-30 r5022
uname -srvmpio: Linux 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64 
unknown unknown GNU/Linux

running smartctl -a /dev/nvme0 results in consecutive messages:

[DRHD]: handling fault status reg 3
[DMA Read]: Request device [71:00.0] PASID  fault addr fd26 [fault 
reason 06] PTE read access is not set

hope this helps a little ...

Bug#947803: smartmontools: smartctl -l error causes Micron 2200S NVME to fail

[Michael Becker]

PS: output of lspci -vvvs 71:00.0

71:00.0 Non-Volatile memory controller: Micron Technology Inc Device 5410 (rev 
01) (prog-if 02 [NVM Express])
Subsystem: Micron Technology Inc Device 0100
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [108 v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Capabilities: [110 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ 
L1_PM_Substates+
  PortCommonModeRestoreTime=32us PortTPowerOnTime=20us
L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+
   T_CommonMode=0us LTR1.2_Threshold=81920ns
L1SubCtl2: T_PwrOn=44us
Capabilities: [200 v1] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- 
AdvNonFatalErr-
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- 
AdvNonFatalErr+
AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- 
ECRCChkCap+ ECRCChkEn-
MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
HeaderLog: 0401 000f 7107 3a74fcf2
Capabilities: [300 v1] Secondary PCI Express
LnkCtl3: LnkEquIntrruptEn-, PerformEqu-
LaneErrStat: 0
Kernel driver in use: nvme
Kernel modules: nvme

Bug#962965: ITP: yanosim:Read simulator nanopore DRS datasets

[Nilesh Patra]

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


* Package name: yanosim
  Version : 0.1
  Upstream Author : Matthew Parker
* URL : https://github.com/bartongroup/yanosim

* License : Expat
  Programming Lang: Python
  Description : Read simulator nanopore DRS datasets

 It has three options:
 1 yanosim model:
 Creates an model of mismatches, insertions and deletions
 based on an alignment of nanopore DRS reads to a
 reference. Reads should be aligned to a transcriptome
 i.e. without spliced alignment, using minimap2. They
 should have the cs tag.
 .
 2 yanosim quantify:
 Quantify the number of reads mapping to each
 transcript in a reference, so that the right number
 of reads can be simulated.
 .
 3 yanosim simulate
 Given a model created using yanosim model, and
 per-transcript read counts created using yanosim
 simulate, simulate error-prone long-reads from the
 given fasta file.

I take the responsibility to maintain this package.

Bug#962966: ITP: scrappie -- basecaller for Nanopore sequencer

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: scrappie -- basecaller for Nanopore sequencer
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: scrappie
  Version : 1.4.2
  Upstream Author : Copyright:  
* URL : https://github.com/nanoporetech/scrappie
* License : https://salsa.debian.org/med-team/scrappie

Bug#858512: xfstt: xset fp+ unix/:7101 -> Incorrect font server address or syntax

[Andrey ``Bass'' Shcheglov]

I confirm this behaviour.

I'm running a Devuan 3 (identical to Debian 10) box.

I've run `xfstt --sync` in order to generate the cache of my TTF font
directories, and configured `xfstt` to also listen at TCP port 7101:

> # cat /etc/default/xfstt 
> LISTEN_TCP='yes'
> ARGS="${ARGS} --port 7101"

This can be confirmed by running `lsof` (despite `aa_DJ.utf8` is *not*
my locale):

> # lsof -p 20380
> COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFFNODE NAME
> xfstt   20380 root  cwdDIR  254,212288 1314666 
> /usr/share/fonts/truetype
> xfstt   20380 root  rtdDIR  254,1 4096   2 /
> xfstt   20380 root  txtREG  254,2   129224  805495 
> /usr/bin/xfstt
> xfstt   20380 root  memREG  254,4   311653  134640 
> /var/cache/xfstt/ttname.dir
> xfstt   20380 root  memREG  254,2   337024 2111564 
> /usr/lib/locale/aa_DJ.utf8/LC_CTYPE
> xfstt   20380 root  memREG  254,2  2586242 2111562 
> /usr/lib/locale/aa_DJ.utf8/LC_COLLATE
> xfstt   20380 root  memREG  254,1  18244962028 
> /lib/x86_64-linux-gnu/libc-2.28.so
> xfstt   20380 root  memREG  254,1   100712 661 
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> xfstt   20380 root  memREG  254,1  15794483929 
> /lib/x86_64-linux-gnu/libm-2.28.so
> xfstt   20380 root  memREG  254,2  1570256 2104093 
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
> xfstt   20380 root  memREG  254,472536  134639 
> /var/cache/xfstt/ttinfo.dir
> xfstt   20380 root  memREG  254,2 3448 2904297 
> /usr/lib/locale/ru_RU.utf8/LC_TIME
> xfstt   20380 root  memREG  254,2  294 2904167 
> /usr/lib/locale/os_RU/LC_MONETARY
> xfstt   20380 root  memREG  254,2   34 2111572 
> /usr/lib/locale/aa_DJ.utf8/LC_PAPER
> xfstt   20380 root  memREG  254,2   62 2111611 
> /usr/lib/locale/agr_PE/LC_NAME
> xfstt   20380 root  memREG  254,2  165 2904294 
> /usr/lib/locale/ru_RU.utf8/LC_ADDRESS
> xfstt   20380 root  memREG  254,2   52 2364393 
> /usr/lib/locale/ce_RU/LC_TELEPHONE
> xfstt   20380 root  memREG  254,2   23 2111567 
> /usr/lib/locale/aa_DJ.utf8/LC_MEASUREMENT
> xfstt   20380 root  memREG  254,226402 2124463 
> /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
> xfstt   20380 root  memREG  254,2  341 2904295 
> /usr/lib/locale/ru_RU.utf8/LC_IDENTIFICATION
> xfstt   20380 root  memREG  254,1   1656321889 
> /lib/x86_64-linux-gnu/ld-2.28.so
> xfstt   20380 root0u  unix 0x88381a63a400  0t0 3349764 
> /tmp/.font-unix/fs7101 type=STREAM
> xfstt   20380 root1u  IPv43344308  0t0 TCP *:7101 
> (LISTEN)
> xfstt   20380 root2u  IPv63344309  0t0 TCP *:7101 
> (LISTEN)


The above can be additionally confirmed by connecting to localhost:7101
with `telnet`.

Still, whenever I'm trying to add an entry to my font path using either
TCP or UNIX sockets, the request fails:

> $ xset fp+ inet/localhost:7101
> xset:  bad font path element (#16), possible causes are:
> Directory does not exist or has wrong permissions
> Directory missing fonts.dir
> Incorrect font server address or syntax
> $ xset fp+ tcp/localhost:7101
> xset:  bad font path element (#16), possible causes are:
> Directory does not exist or has wrong permissions
> Directory missing fonts.dir
> Incorrect font server address or syntax
> $ xset fp+ unix/:7101
> xset:  bad font path element (#16), possible causes are:
> Directory does not exist or has wrong permissions
> Directory missing fonts.dir
> Incorrect font server address or syntax

This problem, until fixed, basically renders the package useless.

-- 
Regards,
Andrey ``Bass'' Shcheglov.



signature.asc
Description: OpenPGP digital signature

Bug#962967: ITP: google-oauth-client-java -- Google OAuth Client Library for Java

[Olek Wojnar]

Package: wnpp
Severity: wishlist
Owner: Olek Wojnar 

* Package name: google-oauth-client-java
  Version : 1.27.0
  Upstream Author : Jeff Ching 
* URL : https://github.com/googleapis/google-oauth-java-client
* License : Apache-2.0
  Programming Lang: Java
  Description : Google OAuth Client Library for Java

Powerful and easy-to-use Java library for the OAuth 1.0a and OAuth 2.0
authorization standards. The Google OAuth Client Library for Java is designed
to work with any OAuth service on the web, not just with Google APIs. It is
built on the Google HTTP Client Library for Java.

Bug#962968: libauthen-sasl-perl: Net::LDAP with GSSAPI SASL bind connecting with wrong sasl_ssf on Debian buster

[Richard Landster]

Package: libauthen-sasl-perl
Version: 2.1600-1
Severity: important

Dear Maintainer,

I have a Perl script to read from an OpenLDAP instance using Net::LDAP
with a GSSAPI bind. The script works fine on Debian stretch but fails on
Debian buster.

Note that on both servers the line at the bottom of the Perl code that
runs ldapsearch produces the same correct results, so I am sure that the
Kerberos ticket cache is correct on both servers.

Looking at the OpenLDAP logs I see that the ldapsearch run shows up with
the strength factors sasl_ssf=256 ssf=256 while the Net::LDAP bind shows
up with the strength factors sasl_ssf=1 ssf=256. Since the Net::LDAP bind
is using Kerberos, the sasl_ssf should be 56, not 1.

###

use strict;
use warnings;
use Authen::SASL;
use Net::LDAP;
use Data::Dumper;

my $server_name = 'ldap.example.com';
$ENV{'KRB5CCNAME'} = '/tmp/krb.tkt';

my $ld = Net::LDAP->new($server_name, version => '3');
$ld->start_tls(verify => 'require');

if (!$ld or $ld == -1) {
die "Could not connect to directory server $server_name";
}

my $SASL = Authen::SASL->new('GSSAPI');
my $status = $ld->bind(sasl => $SASL);

if ($status->code) {
die  'Bind error: (' . $status->error_name . ') ' . $status->error_text;
}

my $base   = 'dc=example,dc=com';
my $filter = '(uid=johndoe)';
my @attrs  = ('uid', 'sn');
$status = $ld->search(
base=> 'dc=example,dc=com',
filter  => $filter,
attrs   => \@attrs,
) ;

my @entries = $status->all_entries;
# This results in nothing (but should result in the same data as the ldapsearch 
below):
warn Dumper @entries ;

my $attrs = join(' ', @attrs) ;
my $cmd = "ldapsearch -LLL -h $server_name -b $base '$filter' $attrs";
# This gives the correct result:
warn `$cmd`;


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

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

Versions of packages libauthen-sasl-perl depends on:
ii  perl  5.28.1-6

libauthen-sasl-perl recommends no packages.

Versions of packages libauthen-sasl-perl suggests:
ii  libdigest-hmac-perl  1.03+dfsg-2
ii  libgssapi-perl   0.28-3+b1

-- no debconf information

Bug#962530: Tor service won't start when apparmor is active and "/" is on an overlayfs

[Stefan Baur]

Am 16.06.20 um 14:48 schrieb intrigeri:

> So, I have a question:
> 
>> 4. run the following commands:
>>apt update
>>apt install apparmor -y
>>service apparmor start
> 
> Did the apparmor service start before you started it manually?
> I suppose it did not start, hence the need to start it manually,
> right?

That is correct. I ran into this issue on a system that isn't a classic
Debian Live system, but is using overlayfs (to minimize actual file
system writes on a type of flash media that doesn't have wear leveling).

I was looking for an easy way for the maintainer/triager to replicate my
issue, so instead of providing the steps needed to recreate my
particular environment, my choice fell on Debian Live.


[...]
> Tails' customization that makes it work with overlayfs
> lives in files that should be linked from:
> https://tails.boum.org/contribute/design/application_isolation/

Thanks for the pointer.


>> As apparmor is causing the issue, but the corresponding "system_tor"
>> config file is part of the tor package, I figured I should file this
>> against the tor package.  Feel free to reassign the bug to the apparmor
>> package if bugs about broken/incomplete apparmor profiles should be
>> filed against that one.
> 
> I'm reassigning to apparmor: if apparmor.service starts automatically
> in a Debian Live environment, that's a bug in that service.

Well, no, it doesn't start automatically in a Debian Live environment,
but it does start automatically in a pretty much regular Debian
environment that does use overlayfs for the root file system.

So if it's hard to get apparmor and overlayfs to play along nicely,
maybe the check shouldn't be for a Debian Live environment but more
generally for an environment that has its root file system mounted via
overlayfs?  To avoid breaking existing installs of that kind, it should
probably print a warning to syslog instead of disabling apparmor completely.

I found that for me, adding

   /upper/var/lib/tor/** r,

underneath

 # During startup, tor (as root) tries to open various things such as
 # directories via check_private_dir().  Let it.
 /var/lib/tor/** r,

allows me to start tor.  I haven't tried if

 /var/lib/tor/** r,

can/should be removed or needs to stay in that case. Someone more
experienced with apparmor than me should have a look at that, I think.

Note that "/upper" is not the path I'm using during the overlayfs mount,
the mountpoint actually looks like this:
overlay on / type overlay
(rw,relatime,lowerdir=/overlay/root-ro,upperdir=/overlay/root-rw/upper,workdir=/overlay/root-rw/work)

So maybe a generic fix (or a hint at how to fix it) is possible?

On apparmor install/startup, check for an overlay mount, and if it is
present, warn the user that they may need to change/add paths in their
apparmor profiles?

For extra fancyness, you could try to parse the

upperdir=/overlay/root-rw/upper

string and add "you may need to prefix /${upperdir##*/} to paths" or
something like that to the syslog message.

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[Salvatore Bonaccorso]

Hi Bruce,

On Mon, Jun 15, 2020 at 10:42:12PM -0400, J. Bruce Fields wrote:
> On Mon, Jun 15, 2020 at 10:38:20PM -0400, J. Bruce Fields wrote:
> > Thanks for the detailed reproducer.
> > 
> > It's weird, as the server is basically just setting the transmitted
> > umask and then calling into the vfs to handle the rest, so it's not much
> > different from any other user.  But the same reproducer run just on the
> > ext4 filesystem does give the right permissions
> > 
> > Oh, but looking at the system call, fs_namei.c:do_mkdirat(), it does:
> > 
> > if (!IS_POSIXACL(path.dentry->d_inode))
> > mode &= ~current_umask();
> > error = security_path_mkdir(&path, dentry, mode);
> > if (!error)
> > error = vfs_mkdir(path.dentry->d_inode, dentry, mode);
> > 
> > whereas nfsd just calls into vfs_mkdir().
> > 
> > And that IS_POSIXACL() check is exactly a check whether the filesystem
> > supports ACLs.  So I guess it's the responsibility of the caller of
> > vfs_mkdir() to handle that case.
> 
> But, that's unsatisfying: why isn't vfs_mkdir() taking care of this
> itself?  And what about that security_path_mkdir() call?  And are the
> other cases of that switch in fs/nfsd/vfs.c:nfsd_create_locked()
> correct?  I think there may be some more cleanup here called for, I'll
> poke around tomorrow.

This might be unneeded to test but as additional datapoint which
confirms the suspect: I tried check the commit around 47057abde515
("nfsd: add support for the umask attribute") in 4.10-rc1

A kernel built with 47057abde515~1, and mounting from an enough recent
client which has at least dff25ddb4808 ("nfs: add support for the
umask attribute") does not show the observed behaviour, the server
built with 47057abde515 does.

Regards,
Salvatore

Bug#816640: ruby-eventmachine: FTBFS under pbuilder with USENETWORK=no: TestResolver fails (no implicit conversion of nil into String)

[duck]

Quack,

Andreas, could you explain to me why you reopened this ticket? Did you 
stumble on another test using the network? I built the package locally 
and on Salsa and it seemed to be fixed.


Also I don't understand why you merged it with #919085 which seem to 
address a broader problem. I see one test failing on mipsel and other 
failures in non-releasing arches, but it seems the situation is 
different from the original report. I'm not sure how to fix this test 
yet.


Regards.
\_o<

--
Marc Dequènes

Bug#962588: linux-image-amd64:amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Ben Hutchings]

Control: found -1 5.3.2-1~exp1

On Wed, 10 Jun 2020 13:55:17 +0200 Thorsten Glaser  wrote:
> Package: linux-image-amd64
> Version: 5.6.14-2
> Severity: serious
> Justification: Policy 2.3
> 
> tglase@tglase:~ $ ll /usr/share/doc/linux-image-amd64/
> total 0
> tglase@tglase:~ $ ll -d /usr/share/doc/linux-image-amd64
> drwxr-xr-x 2 root root 4096 Okt 21  2019 /usr/share/doc/linux-image-amd64/

This is the dpkg bug where it fails to replace a directory with a
symlink.  For some reason that requires workarounds in every other
package instead of being fixed in dpkg.

This instance was introduced by:

commit 70af1a4e805ba7f355fb69b3a041b3fdb9b977dd
Author: Ben Hutchings 
Date:   Tue Oct 1 22:27:29 2019 +0100

Require metapackage dependencies to be the same version, and link doc dirs

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.



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

Bug#962970: haskell-permutation: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Source: haskell-permutation
Version: 0.5.0.5-3
Severity: grave
Justification: renders package unusable

This package seems to be unmaintained (last upstream upload in 2015).
Does not build with GHC 8.8, is not part of Stackage and has no rev
dependencies.

I intend to remove this package.

-- 
Ilias

Bug#962969: lsb-release: lsb_release references non-existent lsb(8)

[Nick Black]

Package: lsb-release
Version: 11.1.0
Severity: minor

Dear Maintainer,

The lsb_release(1) man page contains a SEE ALSO entry for lsb(8). So far as I
can tell, this page does not exist in any Debian package (apt-file search
man8/lsb). The reference ought be removed.



-- Package-specific info:
lsb_release output
-*- -*- -*- -*- -*-
Distributor ID: Debian
Description:Debian GNU/Linux bullseye/sid
Release:unstable
Codename:   sid
-*- -*- -*- -*- -*-
Apt policy
-*- -*- -*- -*- -*-
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 http://packages.microsoft.com/repos/vscode stable/main amd64 Packages
 release o=vscode stable,a=stable,n=stable,l=vscode stable,c=main,b=amd64
 origin packages.microsoft.com
 500 http://dl.google.com/linux/chrome/deb stable/main amd64 Packages
 release v=1.0,o=Google LLC,a=stable,n=stable,l=Google,c=main,b=amd64
 origin dl.google.com
 500 https://www.dsscaw.com/repos/apt/debian unstable/main amd64 Packages
 release o=Dirty South Supercomputing,n=unstable,l=Dirty South 
Supercomputing,c=main,b=amd64
 origin www.dsscaw.com
   1 http://ftp.us.debian.org/debian experimental/contrib amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=contrib,b=amd64
 origin ftp.us.debian.org
   1 http://ftp.us.debian.org/debian experimental/non-free amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
   1 http://ftp.us.debian.org/debian experimental/main amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
 300 http://ftp.us.debian.org/debian unstable/contrib amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=amd64
 origin ftp.us.debian.org
 300 http://ftp.us.debian.org/debian unstable/non-free amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 300 http://ftp.us.debian.org/debian unstable/main amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
Pinned packages:
 libcudf-dev -> 0.8-3+b1 with priority 800
 libnppim10 -> 10.2.89-1 with priority 800
 libcudf-ocaml-dev -> 0.8-3+b1 with priority 800
 libnppicc10 -> 10.2.89-1 with priority 800
 libnvgraph10 -> 10.2.89-1 with priority 800
 libcuinj64-10.2 -> 10.2.89-1 with priority 800
 libnpps10 -> 10.2.89-1 with priority 800
 nvidia-cuda-toolkit-gcc -> 10.2.89-1 with priority 800
 libnppitc10 -> 10.2.89-1 with priority 800
 libnvtt2 -> 2.1.0-git20160229+dfsg-2~exp1+b4 with priority 800
 libcubew-dev -> 4.4~rc2-1 with priority 800
 libcubew-doc -> 4.4~rc2-1 with priority 800
 libcublaslt10 -> 10.2.89-1 with priority 800
 libcupti10.2 -> 10.2.89-1 with priority 800
 libcusparse10 -> 10.2.89-1 with priority 800
 libcublas10 -> 10.2.89-1 with priority 800
 libcusolvermg10 -> 10.2.89-1 with priority 800
 libnppicom10 -> 10.2.89-1 with priority 800
 libnvjpeg10 -> 10.2.89-1 with priority 800
 nvidia-nsight -> 10.2.89-1 with priority 800
 libnvrtc10.2 -> 10.2.89-1 with priority 800
 libcusolver10 -> 10.2.89-1 with priority 800
 nvidia-openjdk-8-jre -> 9.+8u252-b09-1~deb9u1~10.2.89-1 with priority 800
 libnvtt-bin -> 2.1.0-git20160229+dfsg-2~exp1+b4 with priority 800
 nvidia-profiler -> 10.2.89-1 with priority 800
 libnvtoolsext1 -> 10.2.89-1 with priority 800
 libnvtt-dev -> 2.1.0-git20160229+dfsg-2~exp1+b4 with priority 800
 libcupti-dev -> 10.2.89-1 with priority 800
 libcupti-doc -> 10.2.89-1 with priority 800
 libnvblas10 -> 10.2.89-1 with priority 800
 nvidia-cuda-toolkit -> 10.2.89-1 with priority 800
 libnvidia-ml-dev -> 10.2.89-1 with priority 800
 libnppidei10 -> 10.2.89-1 with priority 800
 libcufftw10 -> 10.2.89-1 with priority 800
 nvidia-visual-profiler -> 10.2.89-1 with priority 800
 libnppc10 -> 10.2.89-1 with priority 800
 libcurand10 -> 10.2.89-1 with priority 800
 libnppist10 -> 10.2.89-1 with priority 800
 libnppial10 -> 10.2.89-1 with priority 800
 libnppisu10 -> 10.2.89-1 with priority 800
 libcufft10 -> 10.2.89-1 with priority 800
 libnppif10 -> 10.2.89-1 with priority 800
 nvidia-cuda-dev -> 10.2.89-1 with priority 800
 libcube4w7 -> 4.4~rc2-1 with priority 800
 nvidia-cuda-doc -> 10.2.89-1 with priority 800
 libcudart10.2 -> 10.2.89-1 with priority 800
 libnppig10 -> 10.2.89-1 with priority 800
 nvidia-opencl-dev -> 10.2.89-1 with priority 800
 boinc-client-nvidia-cuda -> 7.16.15+dfsg-1exp1 with priority 800
 nvidia-cuda-gdb -> 10.2.89-1 with priority 800
-*- -*- -*- -*- -*-
   sources.list
-*- -*- -*- -*- -*-
deb http://ftp.us.debian.org/debian/ unstable main non-free contrib
deb-src http://ftp.us.debian.org/debian/ unstable main non-free contrib
deb http://ftp.us.debian.org/d

Bug#962971: python3-ruamel.yaml.clib: overwrites files from python3-ruamel.yaml without Replaces

[Simon McVittie]

Package: python3-ruamel.yaml.clib
Version: 0.2.0-1
Severity: serious
Justification: Policy 7.6.1

Steps to reproduce:
* Have python3-ruamel.yaml from testing
* Upgrade

Expected result: successful upgrade

Actual result:

> Preparing to unpack .../25-python3-ruamel.yaml.clib_0.2.0-1_amd64.deb ...
> Unpacking python3-ruamel.yaml.clib (0.2.0-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-w9QDSF/25-python3-ruamel.yaml.clib_0.2.0-1_amd64.deb 
> (--unpack):
>  trying to overwrite 
> '/usr/lib/python3/dist-packages/_ruamel_yaml.cpython-38-x86_64-linux-gnu.so', 
> which is also in package python3-ruamel.yaml 0.15.89-3+b2
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Preparing to unpack .../26-python3-ruamel.yaml_0.16.10-2_all.deb ...
> Unpacking python3-ruamel.yaml (0.16.10-2) over (0.15.89-3+b2) ...
> Errors were encountered while processing:
>  /tmp/apt-dpkg-install-w9QDSF/25-python3-ruamel.yaml.clib_0.2.0-1_amd64.deb

Workaround: retry the upgrade until apt decides to upgrade
python3-ruamel.yaml before installing python3-ruamel.yaml.clib.

This looks like the "Split, new A always requires new B" case from
. The solution is usually
to have:

Package: python3-ruamel.yaml
Depends: python3-ruamel.yaml.clib (>= some version)

Package: python3-ruamel.yaml.clib
Breaks: python3-ruamel.yaml (<< 0.16.10)
Replaces: python3-ruamel.yaml (<< 0.16.10)

so that they have to be upgraded together, with python3-ruamel.yaml
temporarily broken during the upgrade transaction.

Thanks,
smcv

Bug#962973: haskell-readline: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Source: haskell-readline
Version: 1.0.3.0-9
Severity: grave
Justification: renders package unusable

This package seems to be unmaintained (last upstream upload in 2013).
Does not build with GHC 8.8, is not part of Stackage and has no rev
dependencies.

I intend to remove this package.

-- 
Ilias

Bug#902901: FTBFS: Tests fail

[Ilias Tsitsimpis]

This package is still unbuildable after 2 years, with no response from
upstream. Since there are no rev dependencies for this package, I intend
to remove it from Debian.

-- 
Ilias

Bug#962972: firmware-realtek: unable to load firmware patch rtl_nic/rtl8153a-2.fw (-2)

[Grant Grundler]

Package: firmware-realtek
Version: 20190717-2
Severity: important

TL;DR Please update rtl_nic. This will solve most of the issues reported 
against rtl815x devices.

Linux gggnuc6 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64 GNU/Linux

Errors that an update will fix:
[79912.317675] r8152 2-2.4:1.0: firmware: failed to load rtl_nic/rtl8153a-2.fw 
(-2)
[79912.317683] r8152 2-2.4:1.0: Direct firmware load for rtl_nic/rtl8153a-2.fw 
failed with error -2
  AND
[79912.458292] r8152 2-2.1:1.0: firmware: failed to load rtl_nic/rtl8153b-2.fw 
(-2)
[79912.458296] r8152 2-2.1:1.0: Direct firmware load for rtl_nic/rtl8153b-2.fw 
failed with error -2


"modprobe r8152" results in the following dmesg output:
[78645.896245] r8152 2-2.1:1.0 enx00e04cf007a4: carrier on
[79887.986255] usbcore: deregistering interface driver r8152
[79887.986552] r8152 2-2.1:1.0 enx00e04cf007a4: Stop submitting intr, status 
-108
[79888.042247] r8152 2-2.4:1.0 enx0023568c0143: Stop submitting intr, status 
-108
[79912.294537] usb 2-2.4: reset SuperSpeed Gen 1 USB device number 4 using 
xhci_hcd
[79912.317675] r8152 2-2.4:1.0: firmware: failed to load rtl_nic/rtl8153a-2.fw 
(-2)
[79912.317683] r8152 2-2.4:1.0: Direct firmware load for rtl_nic/rtl8153a-2.fw 
failed with error -2
[79912.317687] r8152 2-2.4:1.0: unable to load firmware patch 
rtl_nic/rtl8153a-2.fw (-2)
[79912.351441] r8152 2-2.4:1.0 eth0: v1.11.11
[79912.354955] r8152 2-2.4:1.0 enx0023568c0143: renamed from eth0
[79912.434704] usb 2-2.1: reset SuperSpeed Gen 1 USB device number 5 using 
xhci_hcd
[79912.458292] r8152 2-2.1:1.0: firmware: failed to load rtl_nic/rtl8153b-2.fw 
(-2)
[79912.458296] r8152 2-2.1:1.0: Direct firmware load for rtl_nic/rtl8153b-2.fw 
failed with error -2
[79912.458298] r8152 2-2.1:1.0: unable to load firmware patch 
rtl_nic/rtl8153b-2.fw (-2)
[79912.491249] r8152 2-2.1:1.0 eth0: v1.11.11
[79912.491294] usbcore: registered new interface driver r8152
[79912.496221] r8152 2-2.1:1.0 enx00e04cf007a4: renamed from eth0
[79915.982266] IPv6: ADDRCONF(NETDEV_CHANGE): enx0023568c0143: link becomes 
ready
[79915.982925] r8152 2-2.4:1.0 enx0023568c0143: carrier on
[79916.304655] IPv6: ADDRCONF(NETDEV_CHANGE): enx00e04cf007a4: link becomes 
ready
[79916.305100] r8152 2-2.1:1.0 enx00e04cf007a4: carrier on


The rtl8153a-2 and rtl8153a-3 devices are widely used and Realtek finally 
upstreamed
the firmware patching mechanism they had in their inhouse driver around Q4 2019:
 
https://lore.kernel.org/netdev/1394712342-15778-335-taiwan-albe...@realtek.com/

These patches helped chrome OS reliably detect and use RTL8153 devices.

However, the rtl8153a-3.fw file Realtek original submitted was broken and was
updated in Feb 2020 and ChromeOS picked up this update in April, 2020:

https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/+log/refs/heads/master/rtl_nic

https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/+/db0430c080d38e3055aec81f44b4c84012dba079

While I'm using a personal email to request this update, I am also 
grund...@chromium.org
and have extensively tested these patches. They work.

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

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.137

-- no debconf information

Bug#962588: linux-image-amd64:amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Ben Hutchings]

Control: notfixed 942861 5.3.9-1
Control: forcemerge 942861 -1

On Tue, 2020-06-16 at 17:44 +0100, Ben Hutchings wrote:
> Control: found -1 5.3.2-1~exp1
> 
> On Wed, 10 Jun 2020 13:55:17 +0200 Thorsten Glaser  wrote:
> > Package: linux-image-amd64
> > Version: 5.6.14-2
> > Severity: serious
> > Justification: Policy 2.3
> > 
> > tglase@tglase:~ $ ll /usr/share/doc/linux-image-amd64/
> > total 0
> > tglase@tglase:~ $ ll -d /usr/share/doc/linux-image-amd64
> > drwxr-xr-x 2 root root 4096 Okt 21  2019 /usr/share/doc/linux-image-amd64/
> 
> This is the dpkg bug where it fails to replace a directory with a
> symlink.  For some reason that requires workarounds in every other
> package instead of being fixed in dpkg.
> 
> This instance was introduced by:
> 
> commit 70af1a4e805ba7f355fb69b3a041b3fdb9b977dd
> Author: Ben Hutchings 
> Date:   Tue Oct 1 22:27:29 2019 +0100
> 
> Require metapackage dependencies to be the same version, and link doc dirs

Actually you already reported this as #942861 and I applied the
workaround, but it looks like I specified the wrong prior-version to
dpkg-maintscript-helper.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.



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

Bug#962974: t-coffee: fills RAM after reporting PID too high

[Étienne Mollier]

Package: t-coffee
Version: 13.41.0.28bdc39+dfsg-3
Severity: normal

Dear Maintainer,

When launching the t_coffee command with a high PID, probably
above the threshold of 26, the program remains stuck in a
loop involving a memory leak.

To reproduce the issue, you need a system with a pid_max way
higher than 26.  For instance I have the new default from
Linux:

$ cat /proc/sys/kernel/pid_max
4194304

and launching the command with the -version flag is sufficient
to trigger the bug (assuming the PID affected was higher than
26):

$ t_coffee -version
PROGRAM: T-COFFEE Version_13.41.0.28bdc39 (2019-11-30 10:21:53 - 
Revision 5d5a1c1 - Build 465)

--ERROR: MAX_N_PID exceded -- Recompile changing the value of MAX_N_PID 
(current: 26 Requested: 374228)
^C** Forced interuption of main parent process 374228
User defined signal 1

(SIGINT is trapped, so sending SIGUSR1 is necessary to stop it.)

Apparently pushing MAX_N_PID to 4194304, if possible, might help
in solving this is issue.

Kind Regards,
Étienne.


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

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

Versions of packages t-coffee depends on:
ii  libc6   2.30-8
ii  libgcc-s1   10.1.0-3
ii  libstdc++6  10.1.0-3

Versions of packages t-coffee recommends:
ii  amap-align  2.2+git20080214.600fc29+dfsg-1
ii  clustalo1.2.4-6
ii  clustalw2.1+lgpl-6
ii  dialign-tx  1.0.2-12
ii  fsa 1.15.9+dfsg-4
ii  kalign  1:3.2.3-3
ii  libsoap-lite-perl   1.27-1
ii  libxml-simple-perl  2.25-1
ii  mafft   7.467-1
ii  muscle  1:3.8.1551-2
ii  mustang 3.2.3-3
ii  ncbi-blast+ 2.10.0-1
ii  poa 2.0+20060928-8
ii  prank   0.0.170427+dfsg-2
ii  probcons1.12-12
ii  proda   1.0-12
ii  tm-align20190822+dfsg-2

Versions of packages t-coffee suggests:
pn  boxshade   
pn  seaview
pn  t-coffee-examples  

-- no debconf information

-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

Bug#946308: freespace2: diff for NMU version 3.7.4+repack-1.1

[Adrian Bunk]

On Wed, Jun 17, 2020 at 12:36:23AM +1000, Dmitry Smirnov wrote:
> On Wednesday, 17 June 2020 12:05:19 AM AEST Adrian Bunk wrote:
> > I've prepared an NMU for freespace2 (versioned as 3.7.4+repack-1.1) and
> > uploaded it to DELAYED/14. Please feel free to tell me if I should
> > cancel it.
> 
> Thank you very much for your help.

Thanks, rescheduled for immediate upload.

> Cheers,
>  Dmitry Smirnov.

cu
Adrian

Bug#962972: workaround until firmware-realtek is updated

[Grant Grundler]

sudo bash
cd /lib/firmware/rtl_nic
wget
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/rtl_nic/rtl8153b-2.fw
wget
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/rtl_nic/rtl8153a-4.fw
wget
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/rtl_nic/rtl8153a-3.fw
wget
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/rtl_nic/rtl8153a-2.fw
^D

Kudos to Sedat Dilek  in comment #30 of bug 947356
for "pointing out the obvious". :)
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947356#30

Bug#962861: RFP: drm-info -- Small utility to dump info about DRM devices

[Sudip Mukherjee]

ooi, I had a look at the coredump.

#0  0x in ?? ()
#1  0x7f43bfe22751 in ?? () from /lib/x86_64-linux-gnu/libpci.so.3
#2  0x7f43bfe2054a in ?? () from /lib/x86_64-linux-gnu/libpci.so.3
#3  0x7f43bfe208b7 in pci_lookup_name () from
/lib/x86_64-linux-gnu/libpci.so.3
#4  0x55f574f94bb2 in print_device (obj=) at ../pretty.c:106
#5  0x55f574f95ac4 in print_node (obj=0x55f57511a9c0,
path=) at ../pretty.c:774
#6  print_drm (obj=) at ../pretty.c:795
#7  0x55f574f8f482 in main (argc=1, argv=) at ../main.c:36


-- 
Regards
Sudip

Bug#962975: tiger: Missing dependency on lsb-release

[Elliott Mitchell]

Package: tiger
Version: 1:3.2.4~rc1-1

The configuration may be unusual, but during the update to the current
stable, I ended up not installing the lsb-release package.  This could
be very unusual, but from tiger's cron script it appears tiger actually
depends upon lsb-release.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#905385: stretch-pu: package weboob/1.2-1

[Adam D. Barratt]

On Tue, 2020-06-16 at 18:05 +0900, Marc Dequènes (duck) wrote:
> Quack,
> 
> On 2020-06-16 04:37, Adam D. Barratt wrote:
> 
> > We're now planning for the final point release for stretch before
> > it moves to LTS support. Is this still something that you're
> > (either of you) interested in fixing for stretch?
> 
> Thanks for reaching out.
> 
> Since a removal request was pushed forcefully I assumed it would
> affect all suites.

No, removal from unstable only affects that suite, and subsequently
testing. For (old)stable, separate removal requests are needed.

The package wasn't in testing at the point of the buster release, so
isn't in stable, but is currently still in oldstable (and jessie, aka
oldoldstable, but that's entirely unchangeable and will be archived
soon).

> Anyway I see no point in fixing the package instead of removal at
> this stage, unless this is impossible to undesirable for the release
> of course.

That's entirely your choice. I'll convert this request to a removal
from oldstable,  but if you do decide that you'd like to update it
instead then please let us know ASAP.

Regards,

Adam

Bug#962902: [debian-mysql] Bug#962902: server does not start

[Otto Kekäläinen]

> My question is: Why does the server sometimes require this file to be
> present, and where? I mean, this software has imho no business asking
> for that file, to begin with.

I have never seen this issue anywhere and I have no clue what that
file is. If you can provide instructions how to reproduce it, I could
try to dig into what it is about.

Bug#962588: linux-image-amd64:amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Thorsten Glaser]

Ben Hutchings dixit:

>This is the dpkg bug where it fails to replace a directory with a
>symlink.  For some reason that requires workarounds in every other
>package instead of being fixed in dpkg.

Yeah, this is annoying, but AIUI they call it a feature; a local
admin can symlink directories around if they suddenly lack space
on a partition (this was before bind mounts existed).

Thanks,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.