Bug#958761: src:python-setuptools: fails to migrate to testing for too long

[Paul Gevers]

Source: python-setuptools
Version: 44.0.0-1
Severity: serious
Control: close -1 44.0.0-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:python-setuptools in its current version in unstable has been trying
to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=python-setuptools




signature.asc
Description: OpenPGP digital signature

Bug#958762: src:statsmodels: fails to migrate to testing for too long: FTBFS on armel

[Paul Gevers]

Source: statsmodels
Version: 0.10.2-2
Severity: serious
Control: close -1 0.11.1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 956882

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:statsmodels
in its current version in unstable has been trying to migrate for 60
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=statsmodels




signature.asc
Description: OpenPGP digital signature

Bug#958760: src:ncbi-vdb: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: ncbi-vdb
Version: 2.9.3+dfsg-2
Severity: serious
Control: close -1 2.10.3+dfsg-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 952623

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:ncbi-vdb in
its current version in unstable has been trying to migrate for 60 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=ncbi-vdb




signature.asc
Description: OpenPGP digital signature

Bug#958759: src:gcl: fails to migrate to testing for too long: FTBFS on all/amd64

[Paul Gevers]

Source: gcl
Version: 2.6.12-92
Severity: serious
Control: close -1 2.6.12-94
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 952334

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:gcl in its
current version in unstable has been trying to migrate for 60 days [2].
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=gcl




signature.asc
Description: OpenPGP digital signature

Bug#958758: kmail: Error while trying to identify dbus interface by mailfilter agent

[Jens Radloff]

Package: kmail
Version: 4:18.08.3-1
Severity: normal

Hi,

Once in a while, when I try to send an email from within KMail (being part of
PIM/Kontact), the email is not sent but instead put into the outbox and there
being marked as unread. I cannot send it from there.

To solve this issue I am restarting my machine and then manually send the mail
which is stored in the outbox.

Having logged in again in KDE after a reboot, the following message pops up in
the KDE-GUI:

"Error while trying to identify dbus interface by mailfilter agent" (translated
by myself from German into English)

I am using Debian 10.3 ("Buster")



-- 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)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kmail depends on:
ii  akonadi-server   4:18.08.3-7~deb10u1
ii  kdepim-runtime   4:18.08.3-4
ii  kio  5.54.1-1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgpgmepp6  1.12.0-6
ii  libkf5akonadiagentbase5  4:18.08.3-7~deb10u1
ii  libkf5akonadicontact54:18.08.3-1
ii  libkf5akonadicore5abi2   4:18.08.3-7~deb10u1
ii  libkf5akonadimime5   4:18.08.3-1
ii  libkf5akonadisearch-bin  4:18.08.3-1
ii  libkf5akonadisearch-plugins  4:18.08.3-1
ii  libkf5akonadisearchdebug54:18.08.3-1
ii  libkf5akonadisearchpim5  4:18.08.3-1
ii  libkf5akonadiwidgets5abi14:18.08.3-7~deb10u1
ii  libkf5bookmarks5 5.54.0-1
ii  libkf5calendarcore5abi2  4:18.08.3-1
ii  libkf5calendarutils5 4:18.08.3-2
ii  libkf5codecs55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.54.0-1+deb10u1
ii  libkf5configgui5 5.54.0-1+deb10u1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5contacts5  4:18.08.3-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5followupreminder5  4:18.08.3-2
ii  libkf5grantleetheme-plugins  18.08.3-1
ii  libkf5gravatar5abi2  4:18.08.3-1
ii  libkf5guiaddons5 5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5identitymanagement518.08.3-2
ii  libkf5itemmodels55.54.0-1
ii  libkf5itemviews5 5.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kcmutils5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5kontactinterface5  18.08.3-1
ii  libkf5ksieveui5  4:18.08.3-2
ii  libkf5libkdepim-plugins  4:18.08.3-2
ii  libkf5libkdepim5 4:18.08.3-2
ii  libkf5libkdepimakonadi5  4:18.08.3-2
ii  libkf5libkleo5   4:18.08.3-2
ii  libkf5mailcommon5abi24:18.08.3-2
ii  libkf5mailtransport5 18.08.3-2
ii  libkf5mailtransportakonadi5  18.08.3-2
ii  libkf5messagecomposer5abi1   4:18.08.3-2
ii  libkf5messagecore5abi1   4:18.08.3-2
ii  libkf5messagelist5abi1   4:18.08.3-2
ii  libkf5messageviewer5abi1 4:18.08.3-2
ii  libkf5mime5abi1  18.08.3-1
ii  libkf5mimetreeparser5abi14:18.08.3-2
ii  libkf5notifications5 5.54.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5parts5 5.54.0-1
ii  libkf5pimcommon5abi2 4:18.08.3-2
ii  libkf5pimcommonakonadi5abi1  4:18.08.3-2
ii  libkf5pimtextedit5abi2   18.08.3-1
ii  libkf5sendlater5 4:18.08.3-2
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5sonnetui5  5.54.0-1
ii  libkf5templateparser54:18.08.3-2
ii  libkf5textwidgets5   5.54.0-1
ii  libkf5tnef5  4:18.08.3-1
ii  libkf5wallet-bin 5.54.0-1
ii  libkf5wallet55.54.0-1
ii  libkf5webengineviewer5abi1   4:18.08.3-2
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libqgpgme7   1.12.0-6
ii  libqt5core5a 5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus5  5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5   5.11.3+dfsg1-1+deb10u3
ii  libqt5network5   5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets5   5.11.3+dfsg1-1+deb10u3
ii  libqt5xml5   5.11.3+dfsg1-1+deb10u3
ii  libstdc++6   8.3.0-6

Versions of packages kmail recommends:
ii  accountwizard   4:18.08.3-1
ii  gnupg   2.2.12-1+deb10u1
ii  kdepim-addons   18.08.3-2
ii  kdepim-themeeditors   

Bug#945406: chromium: Widevine content decrytion module no longer working

[Aaron Wyatt]

I was hoping for a long time that this bug would magically resolve 
itself, but decided to take a look into it today and managed to get 
things working. It seems that Widevine support now needs to be manually 
enabled in the build settings for non Chrome branded builds. The 
attached patch fixes that.


Additionally, copying libwidevinecdm.so into the /usr/lib/chromium 
directory is no loner sufficient. You need to mirror the directory 
structure that would exist in a Chrome install of it. (I managed to find 
details of this here: https://github.com/proprietary/chromium-widevine)

Cheers,
Aaron
Index: chromium-81.0.4044.92/third_party/widevine/cdm/widevine.gni
===
--- chromium-81.0.4044.92.orig/third_party/widevine/cdm/widevine.gni
+++ chromium-81.0.4044.92/third_party/widevine/cdm/widevine.gni
@@ -10,7 +10,8 @@ declare_args() {
   # on Android and Fuchsia platforms.
   # Can be optionally enabled in Chromium on non-Android platforms. Please see
   # //src/third_party/widevine/LICENSE file for details.
-  enable_widevine = is_chrome_branded || is_android || is_fuchsia
+  #enable_widevine = is_chrome_branded || is_android || is_fuchsia
+  enable_widevine = 1
 }
 
 # Widevine CDM is available as a library CDM on the following platforms and

Bug#958756: RM: python-torctl

[Ulises Vitulli]

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

Dear FTP master.

Please remove python-torctl from the Debian Archive.

Support has been dropped in favour of a newer alternative that has taken over 
its functionality (under python-stem).

On the same page, it's blocking #933927 and other related py2-3 transition.


Thanks,

Dererk

-- 
BOFH excuse #154:

You can tune a file system, but you can't tune a fish (from most tunefs man 
pages)




signature.asc
Description: OpenPGP digital signature

Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio

[FeRD]

Sorry, I realized I might have sent this reply to the wrong bug.

-- Forwarded message -
From: FeRD 
Date: Tue, Apr 21, 2020 at 5:31 PM
Subject: Re: Fixed in newer release of libopenshot / libopenshot-audio
To: <925...@bugs.debian.org>


On Tue, 21 Apr 2020 15:04:59 -0400 John Scott  wrote:
>
> libopenshot-audio builds with Clang without any modifications. Using this
> OpenShot (again with Clang) gets a bit farther:
>
/usr/include/libopenshot-audio/JuceLibraryCode/modules/juce_audio_basics/../juce_core/unit_tests/juce_UnitTest.h:73:17:
note: candidate found by name lookup is 'juce::UnitTest'
> class JUCE_API  UnitTest
> ^
> /<>/tests/Cache_Tests.cpp:50:2: error: reference to
'UnitTest' is ambiguous
>
> I've seen this is fixed in a commit upstream, and I think cherrypicking it
> helped, but the -audio Debian package uses the Juce embedded code copies
> instead of the ones in juce-modules-source as best as I can tell.

What version of libopenshot is that result from? The Clang namespacing was
fixed
with the merge of 2a1fe80[1] on 2019-10-29, and would be included in both
libopenshot-0.2.4 and libopenshot-0.2.5.

That's a merge commit and it touches a bunch of files, but basically all of
our headers now qualify juce symbols with the juce:: namespace prefix,  and
the test sources now #define DONT_SET_USING_JUCE_NAMESPACE
which prevents JUCE from exporting its symbols into the global namespace.

AFAICT that's the only way to prevent UnitTest++ and JUCE from clashing
over ambiguous 'UnitTest' symbols. But all this should have been solved
months ago.

> I'm uneasy about this and hope that a new release of OpenShot made with
the
> practices described in /usr/share/doc/juce-modules-source/README.Debian
will
> make an elegant solution.

Is there a copy of that file online somewhere? It's not part of the JUCE
distribution as far as I can tell, and it's definitely not located at that
path
on my Fedora machine.

[1]: https://github.com/OpenShot/libopenshot/commit/2a1fe80

Bug#958563: ITP: shellescape -- Escape arbitrary strings for use as command line arguments

[Paul Wise]

On Fri, 2020-04-24 at 10:37 -0700, Bradford Boyle wrote:

> It looks like it currently is using `exec.Command` to call `/bin/sh`
> that is being passed the result of the shellescaped string.

Thanks for providing the details of what is happening.

> Instead of passing through `sh`, just use `exec.Command` on the
> string directly?

I was suggesting that you replace the string with an array of strings
that contains the command being run and the arguments to the command,
then pass that to `exec.Command`, bypassing `sh` entirely.

> Assuming I've understood correctly, would you recommend including
> this change as a patch in the package for now? Or should I try to get
> upstream to incorporate the patch first?

I think it would be best to include potential patches upstream.

After reviewing the code to see why it needs `sh` I see that it loads
the notifycommand parameter from ~/.barnard.yaml, replaces template
parameters with their escaped values and then runs the result in sh.

On reflection I think my suggestion isn't yet worth the time since:

Switching this to not use shell is going to be potentially problematic
for compatibility with existing config files.

The YAML format for lists is quite a bit more verbose than just a
string since it places each argument on one line. You could mitigate
that by continuing to use a string but splitting it on spaces, but then
that introduces further issues with how to add spaces to arguments.
There is also the issue of how to escape the % template character.
The systemd ini files have similar issues, so maybe their approach to
splitting and escaping could be adopted but the approach is complex
and is likely to be confusing to barnard users.

https://manpages.debian.org/buster/systemd/systemd.service.5.en.html#COMMAND_LINES

Right now there is no security issue with executing commands in barnard
because there is no security boundary crossed at this time. If barnard
ever adds support for loading config files from the current directory,
then executing commands in barnard would become a security problem
since someone could check out a potentially untrusted git repository,
not check for a barnard config file and then run barnard, leading to
barnard executing arbitrary commands provided by the git repo. To make
the config file loading safe it could ignore the notify_command setting
in anything other than the user's home dir or in dirs that the config
in the user's home dir indicates are safe. The same issues apply
whether or not shell is used though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#883155: fixed in inkscape 1.0~beta1+ds-1

[Vincent Lefevre]

On 2020-04-13 15:40:01 +0200, Mattia Rizzolo wrote:
> On Sun, Apr 12, 2020 at 07:21:37PM -0400, Sandro Tosi wrote:
> > Can you give us your take on this? tbh i'd like to proceed with the 4
> > packages removal mentioned above rather quickly, as they are blocking
> > several other packages from removal.
> 
> Go and remove those 4 packages!

This is not nice for the end user, as this prevents upgrades without
manual intervention.

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

Bug#848568: Bwbasic-3.2a

[Kenneth Martin]

I am running an updated version of bwbasic from version 2.2 to 3.2a all
patches applied plus code to make it run correctly under Debian 9.x and
10.x plus other flavors of Linux (Ubuntu, Linux Mint, Zorin OS, Linux Lite,
etc.) and DOS.

Version 3.2 as delivered does not compile under Linux. That is why my
version is 3.2a. I have been working on this since 11-2019 with the latest
working on a BeagleBone Black running Debian 10.3.

I have also included all the current documentation where available in the
INFO folder and included several new bwbasic example files in the
BAS-EXAMPLES folder. For setup and running simply see the READMEFIRST file.

I was asked by Robert Nelson if I would be interested in becoming a
maintainer. What does that entail? I have been working with computers since
1974.

I have the code assembled into a tar file. You would simply un-tar the file
then
go to its folder and do a make followed by sudo make install and if you
don't like it do a sudo make remove or to start fresh do make clean

Please get back to me. Thanks.

Bug#958755: ITP: python3-swisseph -- Python extension to the Swiss Ephemeris

[Jaldhar H. Vyas]

On Sat, 25 Apr 2020, Stanislas Marquis wrote:


Package: wnpp
Severity: wishlist
Owner: Stanislas Marquis 

* Package name: python3-swisseph
 Version : 2.08.00
 Upstream Author : Stanislas Marquis 
* URL : https://pypi.org/project/pyswisseph
* License : GPL-2+
 Programming Lang: C
 Description : Python extension to the Swiss Ephemeris

The Swiss Ephemeris is the de-facto standard library for astrological
calculations. This package builds the module for Python 3.

This module has made its way into MX Linux. I think it's time to
integrate it into Debian as well.

We are looking for a sponsor. Thanks ahead.


I'll sponsor it unless it makes more sense for the Debian Python group to 
do it.  (I'm not a member.)


--
Jaldhar H. Vyas 

Bug#955268: udd watch: "429 too many requests" from GitHub

[Paul Wise]

On Fri, Apr 24, 2020 at 2:15 PM Lucas Nussbaum wrote:

> Unfortunately I need to do a manual install anyway, I don't have root
> access on the UDD machine and thus cannot install a .deb.

Another option would be to ask DSA to install the backport once it
reaches buster-backports.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#958755: ITP: python3-swisseph -- Python extension to the Swiss Ephemeris

[Stanislas Marquis]

Package: wnpp
Severity: wishlist
Owner: Stanislas Marquis 

* Package name: python3-swisseph
  Version : 2.08.00
  Upstream Author : Stanislas Marquis 
* URL : https://pypi.org/project/pyswisseph
* License : GPL-2+
  Programming Lang: C
  Description : Python extension to the Swiss Ephemeris

The Swiss Ephemeris is the de-facto standard library for astrological
calculations. This package builds the module for Python 3.

This module has made its way into MX Linux. I think it's time to
integrate it into Debian as well.

We are looking for a sponsor. Thanks ahead.

Bug#765104: Update hfsprogs to 572.1.1

[Rogério Brito]

Dear John Paul,

On Jul 03 2019, John Paul Adrian Glaubitz wrote:
> Are you still interested working on hfsprogs or do you want me to take the
> package over? Updating to a newer version of hfsprogs is surely needed now
> and if you are no longer interested in maintaining the package, it would
> be best to orphan it and me or someone else pick it up for maintenance.

I don't know if you received my last message, but, if not, feel free to
adopt this package.


Thanks,

Rogério Brito.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#942596: [DRE-maint] Bug#942596: jekyll and required bundles

[Daniel Leidert]

Am Samstag, den 25.04.2020, 00:18 +0200 schrieb ydir...@free.fr:
> Hi Daniel,
> 
> - Mail original -
> > 1) Use the Debian package management and don't use bunlder at all
> > (jekyll new
> > --skip-bundle). All the Jekyll plugins have been packaged and most of
> > them can
> > be found in stable-backports. If you are missing some please let me
> > know. Just
> > add the plugins you need to Gemfile and _config.yml, run jekyll, and
> > that
> > should be it. In case of a missing theme (I just packaged the minima
> > theme) one
> > can use the ruby-jekyll-remote-theme package (and the plugin inside)
> > to avoid
> > bundler.
> 
> That one works fine indeed, both with ruby 2.5 and 2.7 (2.7 issues
> language warnings that were apparently handled in 4.0.0, but they're
> just warnings).

Jekyll 4 will unlikely go to unstable soon. But I already have a patch for
Jekyll to fix the Ruby warnings.

> I finally understood what confused me at first: even with --skip-bundle,
> "jekyll new" creates a Gemfile.  And until this Gemfile is removed,
> "jekyll build" will try to go the bundle way all by itself.

That is not true. As I explained earlier I'm using jekyll myself and bundler
doesn't run at all. And you need Gemfile to list and load the plugins you need.

I don't really see a nice route with this for packaging: just documenting
> the fact and add a user notice in "jekyll new" that the package won't work
> until the file is removed feels awkward.
>
> OTOH, doesn't it feel awkward as well that just having Gemfile present
> causes the system binary to do what looks like a "bundle exec" ?   Again
> I'm too noob with ruby to say for sure, but that sure confused me.

What you describe really doesn't sound right. I really think the issue is not
jekyll nor bundler but somewhere in your setup.

What I suspect is that you have dependencies in Gemfile which you have not yet
installed via Debian package management. If all dependencies of your site are
installed, then bundler won't do anything.

Oh, I just looked into your project: Please delete Gemfile.lock locally and
remotely (and also add it to .gitignore!). It clearly lists gems your had
installed via bundler on your system. That could already be the cause for your
trouble. Also again remove any directories related to local bundler
installations like ~/.bundle, ~/.gem, vendor/, etc (check bundle env and gem
env for related directories).

Also please move questions about jekyll usage to our mailing list or our IRC
channel. This is really not related to the bug report in question.

-- 
Regards, 
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


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

Bug#958754: gtg: GTG shows an error when I click on Edit - Preferences

[Leandro Ramos]

Package: gtg
Version: 0.3.1-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?
An error ocurred clicking on Edit - Preferences
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The error appearedm but there was a button to ignore the error, so I
did it ant continued using the program.
   * What was the outcome of this action?
The program does not let me configure the settings.
   * What outcome did you expect instead?
I wanted to configure the program.




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

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

Versions of packages gtg depends on:
ii  python2.7.16-1
ii  python-configobj  5.0.6-3
ii  python-dbus   1.2.8-3
ii  python-glade2 2.24.0-5.1+b1
ii  python-gtk2   2.24.0-5.1+b1
ii  python-liblarch   2.1.0-4
ii  python-notify 0.1.1-4
ii  python-xdg0.25-5

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

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




*** /home/leandro/Documentos/gtg-error
Traceback (most recent call last):
  File "/usr/share/gtg/GTG/gtk/browser/browser.py", line 416, in
open_preferences
self.vmanager.open_preferences(self.config)
  File "/usr/share/gtg/GTG/gtk/manager.py", line 239, in open_preferences
self.preferences.activate()
  File "/usr/share/gtg/GTG/gtk/preferences.py", line 144, in activate
self._refresh_preferences_store()
  File "/usr/share/gtg/GTG/gtk/preferences.py", line 129, in
_refresh_preferences_store
self.shortcut.refresh_accel()
  File "/usr/share/gtg/GTG/gtk/preferences.py", line 214, in refresh_accel
self.new_task_binding = get_saved_binding()
  File "/usr/share/gtg/GTG/tools/shortcut.py", line 50, in get_saved_binding
list_keys = call_subprocess(CHECK_VERSION).splitlines()
  File "/usr/share/gtg/GTG/tools/shortcut.py", line 160, in call_subprocess
out = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
  File "/usr/lib/python2.7/subprocess.py", line 394, in __init__
errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1047, in _execute_child

Bug#958753: firejail-profiles: firejailed inkscape cannot import eps files

[afaidk]

Package: firejail-profiles
Version: 0.9.58.2-2
Severity: normal
Tags: upstream

Dear Maintainer,

When a file with .eps extension(Encapsulated PostScript file) is opened, 
inkscape cannot open it when firejailed. A message "Failed to load the 
requested file" is shown.
"Can't Spawn!!! spawn returns: Failed to execute child process “” (No such file 
or directory)" is shown in the terminal if firejail is in debug mode.

The issue does not occur if firejail is disabled for inkscape.

A quick google search returned a similiar 
issue(https://github.com/NixOS/nixpkgs/issues/3449). The issue mentions missing 
python-lxml. 

So I added a few lines in inkscape.local file and it resolved the issue.

/etc/firejail/inkscape.local
-
noblacklist ${PATH}/python2*
noblacklist /usr/include/python2*
noblacklist /usr/lib/python2*
noblacklist /usr/local/lib/python2*
noblacklist /usr/share/python2*

Please do the needful.
Thanks

-- 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)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail-profiles depends on:
ii  firejail  0.9.58.2-2

firejail-profiles recommends no packages.

firejail-profiles suggests no packages.

-- Configuration Files:
/etc/firejail/catfish.profile changed [not included]
/etc/firejail/ffmpeg.profile changed [not included]

-- no debconf information

Bug#958668: u-boot: Please consider enabling rpi4 support

[Vagrant Cascadian]

On 2020-04-24, Andreas Henriksson wrote:
> Please consider building the rpi4 (32 and 64bit) version of u-boot
> for the u-boot-rpi package. Patch attached for your convenience (which
> was only build-tested for arm64 target so far).

If you or someone else can commit to testing updates semi-regularly:

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

Then list the person in the debian/targets files with name and contact
info in an updated patch.


live well,
  vagrant

> diff --git a/debian/targets b/debian/targets
> index b703fb3239..f83bb63685 100644
> --- a/debian/targets
> +++ b/debian/targets
> @@ -90,6 +90,8 @@ armhf   rpi rpi_2   u-boot.bin
>  # Ryan Finnie 
>  armhfrpi rpi_3_32b   u-boot.bin
>  
> +armhfrpi rpi_4_32b   u-boot.bin
> +
>  # Christian Kastner 
>  armhfsunxi   A10-OLinuXino-Lime  
> u-boot-sunxi-with-spl.bin
>  
> @@ -213,6 +215,8 @@ arm64  rockchiprock-pi-4-rk3399 
> /usr/lib/arm-trusted-firmware/rk3399/bl3
>  # Ryan Finnie 
>  arm64rpi rpi_3   u-boot.bin
>  
> +arm64rpi rpi_4   u-boot.bin
> +
>  # Rodrigo Exterckötter Tjäder 
>  arm64sunxi   a64-olinuxino   
> /usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin 
> spl/sunxi-spl.bin u-boot-nodtb.bin arch/arm/dts/sun50i-a64-olinuxino.dtb 
> u-boot.itb
>  


signature.asc
Description: PGP signature

Bug#958752: ITP: puppet-module-tempest -- Puppet module for OpenStack Tempest

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-tempest
  Version : 16.2.1
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/puppet-tempest
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module for OpenStack Tempest

 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
 Tempest.
 .
 Tempest is a set of integration tests to be run against a live Openstack
 cluster in order to make sure that all components are working as expected.
 Tempest will start and stop virtual machine in order to check that your
 cloud is working as expected.

Bug#890343: fq_codel as a default

[Dave Taht]

cake and its default parameters is designed to run just fine as a
default qdisc at whatevr the line rate is in linux. I do it all the
time. I find the per host/per flow fq useful, the sane diffserv
markings helpful, the gso splitting best for low latency apps like
videoconferencing, and the stats often enlightening, and I do wish
more folk ran it by default.

however, cake is far more cpu intensive (and slightly more memory
intensive) than fq_codel is and given the wide range of hardware
debian runs on, I cannot support
the idea of it being the default qdisc. I could put up a benchmark or
three as to the difference in cpu on the raspberry pi 3 and 4 to
illustrate this point.

Certainly pfifo_fast must die! Up until last week I thought fq_codel
WAS the default in debian (in addition to *wrt,ubuntu/fedora/rhel8,
arch and so many others) but hd been fooled by linode supplying their
own kernel for everything.

I'd of course love to see it built by default (along with sch_fq and
fq_codel), and more people just reach for the lovely one liner of

tc qdisc add eth0 root cake bandwidth XXX

whenever they need to shape something, AND use it at line rate
(without the bandwidth param) where they can afford it... but I think
the decision tree for a linux default at this point would be

fq_codel (for generic workloads)
sch fq (for tcp serving workloads)
cake (if you can afford it)
bfifo
pfifo_fast

I had a long and (apology, all, oft testy!) debate on the benefits of
fq_codel vs pfifo_fast vs sch fq over here, with the most relevant
comment here:

https://github.com/systemd/systemd/issues/9725#issuecomment-413369212

-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

Bug#953875: runit - default installation can force init switch

[Lorenzo]

David,

thank you for the detailed explanation and the tip (yes, I'm still
learning how the BTS works ).

On 4/24/20 9:53 PM, David Kalnischkies wrote:
> Anyway, as there is nothing apt can really do about this I have to
> reassign back even if I dislike bug-pingpong. Feel free to ask if you
> have come up with a specific solution for your problem and want some
> feedback from us regarding apt, but be prepared to explain a lot in your
> question as apt developers are "only" (FSVO) experts in apt, not in the
> dependency trees of all of Debian (you may consider us the rubber duck
> debugging of dependency resolution). 
>
>
> Best regards
>
> David Kalnischkies
I have a question:
let's say that I change the recommends, like the following

Recommends: runit-systemd | runit-sysv | runit-init 

What happens in a given system if the "runit-systemd" package is not
in the apt index (the package is not in the repository)?
What happens if the 'runit-systemd' package exists, but one of its
dependency,
like, for instance, 'systemd-sysv' does not exists in the repository?
Is apt able to jump to the next alternative (runit-sysv), or it will
proceed without recommends, or it will give an error?
I'm asking because there are downstreams (like Devuan) that blacklist
systemd packages
in their archive and I would like to understand what will happen there.

Regards,
Lorenzo

Bug#958751: libguestfs-tools: guestfish fails on arm64

[Johannes 'josch' Schauer]

Package: libguestfs-tools
Version: 1:1.40.2-7+b1
Severity: important

Hi,

running guestfish on arm64 fails. See for example the result of my
genext2fs autopkgtest on arm64:

https://ci.debian.net/data/autopkgtest/testing/arm64/g/genext2fs/5128192/log.gz

I was able to reproduce the problem on the arm64 porterbox and re-ran
guestfish with LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1. Probably relevant
output:

/usr/bin/qemu-system-aarch64 \
-global virtio-blk-pci.scsi=off \
-no-user-config \
-enable-fips \
-nodefaults \
-display none \
-machine virt,gic-version=host,accel=kvm:tcg \
-cpu host \
-m 1024 \
-no-reboot \
-rtc driftfix=slew \
-kernel /var/tmp/.guestfs-3341/appliance.d/kernel \
-initrd /var/tmp/.guestfs-3341/appliance.d/initrd \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0 \
-device virtio-scsi-pci,id=scsi \
-drive 
file.file.filename=/tmp/libguestfs6x5WRv/overlay1.qcow2,file.driver=qcow2,file.backing.file.locking=off,cache=unsafe,id=hd0,if=none
 \
-device scsi-hd,drive=hd0 \
-drive 
file=/var/tmp/.guestfs-3341/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none,format=raw
 \
-device scsi-hd,drive=appliance \
-device virtio-serial-pci \
-serial stdio \
-chardev socket,path=/tmp/libguestfs6AGQyv/guestfsd.sock,id=channel0 \
-device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
-append "panic=1 console=ttyAMA0 earlyprintk=pl011,,0x900 
ignore_loglevel efi-rtc=noprobe edd=off udevtimeout=6000 
udev.event-timeout=6000 no_timer_check printk.time=1 cgroup_disable=memory 
usbcore.nousb cryptomgr.notests tsc=reliable 8250.nr_uarts=1 root=/dev/sdb 
selinux=0 guestfs_verbose=1 TERM=linux"
WARNING: Image format was not specified for 
'/tmp/libguestfs6x5WRv/overlay1.qcow2' and probing guessed raw.
 Automatically detecting the format is dangerous for raw images, 
write operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.
Could not access KVM kernel module: No such file or directory
qemu-system-aarch64: failed to initialize KVM: No such file or directory
qemu-system-aarch64: Back to tcg accelerator
qemu-system-aarch64: gic-version=host requires KVM


According to this output, the problem seems to be, that guestfish calls
qemu with -machine virt,gic-version=host,accel=kvm:tcg but without kvm,
the gic-version=host argument seems to be invalid.

This seems to be the relevant part in the source code:

https://sources.debian.org/src/libguestfs/1:1.40.2-7/lib/launch-direct.c/?hl=509#L509

Accordingly, the problem vanishes if I run guestfish with
LIBGUESTFS_BACKEND_SETTINGS=force_tcg.

Thanks!

cheers, josch

Bug#958750: debrebuild: please add --standalone mode or --one-shot-mode

[Holger Levsen]

Package: devscripts
Version: 2.20.2
Severity: wishlist
x-debbugs-cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

debrebuild expects a working sbuild setup, which is a sensible expectation.
It would however also be nice if it had a --standalone mode or --one-shot-mode
which would setup sbuild (or even pbuilder) as needed, use it and destroy
that configuration (the chroot or base.tgz) again.

Besides a nicer user experience for casual or first time users this would
also allow to be re-used for an 'debrebuild --init-setup' switch ;)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


signature.asc
Description: PGP signature

Bug#599146: git-buildpackage: gbp-pq should deal with unknown fields more gracefully

[Ryan Pavlik]

On Sun, 17 Oct 2010 15:08:56 +0200 Guido =?iso-8859-1?Q?G=FCnther?= <
a...@sigxcpu.org> wrote:
> On Sat, Oct 16, 2010 at 07:26:07PM +0200, Guido Günther wrote:
> > Hi David,
> > sorry for the late reply.
> >
> > On Tue, Oct 05, 2010 at 12:12:17AM -0300, David Bremner wrote:
> > > Package: git-buildpackage
> > > Version: 0.5.4
> > > Severity: wishlist
> > >
> > > Currently gbp-import silently drops unknown header fields. This
is
> > > problematic for the proposed DEP3 header, which allows more
fields
> > > than From, Date, and Subject.  Minimally it should complain that
> > Yes, that sucks. It's caused by gbp-pq using "git quilt-import" for
the
> > import. We have to get rid of git-quilt-import due to other bugs
like
> Just as a side note: If you put the header fields after the patch
> description - just like the first example at
> http://dep.debian.net/deps/dep3/ the header fields are preserved by
git
> quilt-import.
> Cheers,
>  -- Guido
>
>
>

Note that while this format (the additional fields after the
description) is left alone by gbp-pq, it is rearranged by edits by cme
(libconfig-model-dpkg-perl) which places all the DEP-3 fields at the top
of the patchfile.

Bug#942596: [DRE-maint] Bug#942596: jekyll and required bundles

[ydirson]

Hi Daniel,

- Mail original -
> 1) Use the Debian package management and don't use bunlder at all
> (jekyll new
> --skip-bundle). All the Jekyll plugins have been packaged and most of
> them can
> be found in stable-backports. If you are missing some please let me
> know. Just
> add the plugins you need to Gemfile and _config.yml, run jekyll, and
> that
> should be it. In case of a missing theme (I just packaged the minima
> theme) one
> can use the ruby-jekyll-remote-theme package (and the plugin inside)
> to avoid
> bundler.

That one works fine indeed, both with ruby 2.5 and 2.7 (2.7 issues
language warnings that were apparently handled in 4.0.0, but they're
just warnings).

I finally understood what confused me at first: even with --skip-bundle,
"jekyll new" creates a Gemfile.  And until this Gemfile is removed,
"jekyll build" will try to go the bundle way all by itself.

I don't really see a nice route with this for packaging: just documenting
the fact and add a user notice in "jekyll new" that the package won't work
until the file is removed feels awkward.

OTOH, doesn't it feel awkward as well that just having Gemfile present
causes the system binary to do what looks like a "bundle exec" ?   Again
I'm too noob with ruby to say for sure, but that sure confused me.

Best regards,
-- 
Yann

Bug#958749: libconfig-model-dpkg-perl: Parsing of wrapped long patch subjects incorrect

[Ryan Pavlik]

Package: libconfig-model-dpkg-perl
Version: 2.132~bpo10+1
Severity: normal
Tags: upstream

Dear Maintainer,

I have packages with patches maintained using gbp-pq, which wraps long
first lines of commits, indenting the subsequent line with a single space,
using that full (wrapped) line as the "Subject:".

When loading a package with such a patch in its series in cme edit dpkg:

- the text before the wrap is loaded as the "Synopsis" field, and the
  wrapped text (as well as some? following lines) is in "Subject".
- Upon editing the metadata (e.g. adding Forwarded: not-needed) and saving 
again,
  the second half of the subject line is now un-indented and placed among the 
other headers
  (see attached before.patch and after.patch)

I would expect the subject to be persisted unmodified if I don't modify it - 
perhaps only
adjusting wrap point or indentation.

Thank you,

Ryan Pavlik

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

Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/16 CPU cores)
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

Versions of packages libconfig-model-dpkg-perl depends on:
ii  debhelper  12.9~bpo10+1
ii  libapt-pkg-perl0.1.34+b1
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-backend-yaml-perl  2.133-2
ii  libconfig-model-perl   2.133-1
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
ii  libmouse-perl  2.5.6-1+b1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.004-1
ii  libsort-versions-perl  1.62-1
ii  libtext-autoformat-perl1.74-2
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.76-1
ii  libwww-perl6.36-2
ii  libyaml-libyaml-perl   0.76+repack-1
ii  licensecheck   3.0.46-1~bpo10+1
ii  lintian2.65.0~bpo10+1
ii  perl [libmodule-corelist-perl] 5.28.1-6

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.369-2

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information
Subject: pretend this is a long subject
 that got wrapped by gbp-pq
Last-Update: 2020-04-24
Date: Thu, 9 Apr 2020 17:57:07 -0500

Not sure what's going on, this looks
constexpr to me. Raised issue in upstream instead of
forwarding this workaround-resembling patch.
---
 src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp 
b/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
index 191d6ea..de32c83 100644
--- a/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
+++ b/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
@@ -148,7 +148,7 @@ namespace {
reset_filter_and_imu();
}
// 7200 deg/sec
-   constexpr double max_rad_per_sec = 20 * EIGEN_PI * 2;
+   double max_rad_per_sec = 20 * EIGEN_PI * 2;
if (filter_state.angularVelocity().squaredNorm() >
max_rad_per_sec * max_rad_per_sec) {
fprintf(stderr,
Subject: pretend this is a long subject
Forwarded: not-needed
Last-Update: 2020-04-24
that got wrapped by gbp-pq
Date: Thu, 9 Apr 2020 17:57:07 -0500

Not sure what's going on, this looks
constexpr to me. Raised issue in upstream instead of
forwarding this workaround-resembling patch.
---
 src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp 
b/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
index 191d6ea..de32c83 100644
--- a/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
+++ b/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
@@ -148,7 +148,7 @@ namespace {
reset_filter_and_imu();
}
// 7200 deg/sec
-   constexpr double max_rad_per_sec = 20 * EIGEN_PI * 2;
+   double max_rad_per_sec = 20 * EIGEN_PI * 2;
if (filter_state.angularVelocity().squaredNorm() >
max_rad_per_sec * max_rad_per_sec) {
fprintf(stderr,

Bug#958748: lilv: liblilv-dev could be marked Multi-Arch: same

[João Ricardo Sares Teles de Matos]

Source: lilv
Severity: important

Dear Maintainer,

The package tracker page for lilv notes that liblilv-dev could be marked Multi-
Arch: same

I'm encountered this because I'm trying to cross-build ffmpeg for i386 on amd64
and it requires livlilv-dev:i386 but I already had liblilv-dev:amd64 installed.

I'll be working around this by removing the amd64 version for now.



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

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

Bug#958747: libqt5texttospeech5 might should depend or recommend a speech plugin

[John Scott]

Package: libqt5texttospeech5
Version: 5.12.5-1
Severity: normal
Tags: a11y
Control: block 955762 by -1
Control: tags 955762 - patch

Hi,

I filed #955762 on Okular because if one doesn't have at least one of
qtspeech5-flite-plugin or qtspeech5-speechd-plugin installed, the only error
it prints is to the CLI doing TTS. These plugins have no reverse dependencies.

It appears this isn't specific to Okular. KMouth also doesn't work unless
one types the path to a binary to a preferred engine. KAnagram's settings
are to speak the words by default but it hadn't been doing this without
a plugin. Knights (which doesn't have rdeps either) tries to use speech out
of the box though there is no mention in the program.

I'm not familiar with Qt and don't know whether this library has an actual
dependency on a plugin, or if the dep duty lies elsewhere. Or which engine
should be preferred, assuming all programs can use either.

Please point me in the right direction. It was this blog post [1] that had
shown me that the dependency is needed, and hopefully no one else will miss
out on such nifty features or feel frustration.

[1] 
https://www.ubuntubuzz.com/2018/12/text-to-speech-on-gnulinux-part-2-okular-to-speech.html

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

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

Versions of packages libqt5texttospeech5 depends on:
ii  libc6 2.30-4
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-9
ii  libstdc++610-20200411-1

libqt5texttospeech5 recommends no packages.

libqt5texttospeech5 suggests no packages.

- -- no debconf information

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

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

[Ryan Pavlik]

Package: libconfig-model-dpkg-perl
Version: 2.132~bpo10+1
Severity: normal
Tags: upstream

Dear Maintainer,

I have used cme edit dpkg to modify metadata on some patches (which were 
produced with
gbp pq). The description of one of those patches (deriving from the commit 
message)
has a (final) line that starts with a url.

After modifying that patch, the description is mangled:
the URL is moved above the rest of the description and separated by blank lines,
and there is a space inserted after https:

I expected that only my manual changes, plus any re-ordering due to differing 
opinions
between gbp-pq and cme, would have been made, not modifying the line
with the URL.

(My suspicion is that it parsed the https: as a RFC882 header name, so it 
formatted
that "field" with a space between the header/field name and the "contents".)

Thank you,

Ryan Pavlik


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

Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/16 CPU cores)
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

Versions of packages libconfig-model-dpkg-perl depends on:
ii  debhelper  12.9~bpo10+1
ii  libapt-pkg-perl0.1.34+b1
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-backend-yaml-perl  2.133-2
ii  libconfig-model-perl   2.133-1
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
ii  libmouse-perl  2.5.6-1+b1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.004-1
ii  libsort-versions-perl  1.62-1
ii  libtext-autoformat-perl1.74-2
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.76-1
ii  libwww-perl6.36-2
ii  libyaml-libyaml-perl   0.76+repack-1
ii  licensecheck   3.0.46-1~bpo10+1
ii  lintian2.65.0~bpo10+1
ii  perl [libmodule-corelist-perl] 5.28.1-6

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.369-2

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information

Bug#958745: ITP: barbican-tempest-plugin -- OpenStack Integration Test Suite - Barbican plugin

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: barbican-tempest-plugin
  Version : 1.0.0
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/openstack/barbican-tempest-plugin
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack Integration Test Suite - Barbican plugin

 Tempest is a set of integration tests to be run against a live Openstack
 cluster in order to make sure that all components are working as expected.
 Tempest will start and stop virtual machine in order to check that your
 cloud is working as expected.
 .
 This package contains the Barbican plugin.

Bug#958728: dvi2tty.1: Correct some mistakes and typographic issues in the manual

[Hilmar Preuße]

Control: tags -1 + pending

Am 24.04.2020 um 20:33 teilte Bjarni Ingi Gislason mit:

>   Patch is in the attachment.
> 
Fix is on github, tag pending. Thanks for report and patch.

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



signature.asc
Description: OpenPGP digital signature

Bug#958744: Expired certificates in /etc/refind.d/keys/

[Topi Miettinen]

Package: refind
Version: 0.11.4-1
Severity: normal
Tags: upstream

Hi,

CentOS keys are expired:
$ openssl x509 -noout -enddate -in /etc/refind.d/keys/centos.crt 
notAfter=Jun  7 12:00:00 2017 GMT
$ openssl x509 -noout -enddate -inform der -in /etc/refind.d/keys/centos.cer 
notAfter=Jun  7 12:00:00 2017 GMT

Found with Lynis.

-Topi

Bug#958742: RM: python-gd -- RoQA; Dead upstream, depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove python-gd. It depends on Python 2, is dead upstream and
there are no reverse dependencies left.

Cheers,
Moritz

Bug#958743: RM: synopsis -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove synopsis. It depends on Python 2 and is dead upstream (last
release from 2010).

Cheers,
Moritz

Bug#918526: mtail: FTBFS randomly

[Antoine Beaupre]

Control: tags -1 +moreinfo

I have done some work on updating this package to latest upstream and
tweaking the tests a little. Could you see if this can be reproduced
again?

Thanks!

a.


signature.asc
Description: PGP signature

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

[Moritz Mühlenhoff]

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

python-fcgi seems dead upstream and there are no reverse deps. Are you
planning to port it to Python 3 or should it be removed?

Cheers,
Moritz

Bug#851771: 24/04/2020 - #851771 update

[William Desportes]

Hi,


> Only phpmyadmin is a key package.

phpMyAdmin no longer depends on php-gettext.

phpMyAdmin is absent from buster but present in buster-backports and
does not depend on php-gettext.


(+ buster-backports in sources.list)

# apt-rdepends -r php-php-gettext
Reading package lists... Done
Building dependency tree  
Reading state information... Done
php-php-gettext
  Reverse Depends: cacti (1.2.2+ds1-2+deb10u2)
  Reverse Depends: nagvis (1:1.9.11-1)
  Reverse Depends: php-gettext (1.0.12-0.1)
  Reverse Depends: tt-rss (>= 18.12+dfsg-1.1)
cacti
  Reverse Depends: cacti-spine (>= 1.2.2-1)
cacti-spine
nagvis
  Reverse Depends: nagvis-demos (= 1:1.9.11-1)
nagvis-demos
php-gettext
  Reverse Depends: kopano-webapp-common (3.5.2+dfsg1-1)


I hope my update is useful.


Regards,

William




signature.asc
Description: OpenPGP digital signature

Bug#946716: AW: Bug#946716: mirror submission for debian.apt-mirror.de

[Kevin L .]

Hi Julien,

sources should be now available on the mirror. 

Kind Regards
Kevin

> Am 24.04.2020 um 16:36 schrieb Julien Cristau :
> 
> Thanks Kevin.  Things look better now, however:
> 
> o Your mirror appears not to carry source packages.
> 
>  To comply with the licenses of various pieces of software that you
>  distribute on that mirror, you will probably need to also include
>  sources.
> 
>  To be listed as a Debian mirror in our mirror-list you MUST include
>  sources, e.g. by adding "source" as an included architecture in ftpsync.conf.
> 
> Cheers,
> Julien
> 
>> On Tue, Apr 21, 2020 at 15:05:04 +, Kevin L. wrote:
>> 
>> Hello,
>> 
>> thanks for your message.
>> 
>> i've updated the requested infos.
>> Mirror is now synced with ftpsync.
>> 
>> 
>> Maintainer: Kevin Linnartz 
>> Country: FR
>> Location: Gravelines (OVH)
>> 
>> Kind Regards,
>> 
>> Kevin
>> 
>> 
>> Von: Julien Cristau 
>> Gesendet: Montag, 20. April 2020 16:39
>> An: Kevin Linnartz ; 946...@bugs.debian.org 
>> <946...@bugs.debian.org>
>> Betreff: Re: Bug#946716: mirror submission for debian.apt-mirror.de
>> 
>> Control: tag -1 moreinfo
>> 
>> Hi,
>> 
>>> On Sat, Dec 14, 2019 at 01:16:14PM +, Kevin Linnartz wrote:
>>> Submission-Type: new
>>> Site: debian.apt-mirror.de
>>> Type: leaf
>>> Archive-architecture: amd64 armhf i386
>>> Archive-http: /debian/
>>> Maintainer: Kevin Linnartz 
>>> Country: DE Germany
>>> Location: France (OVH)
>>> 
>> The country and location seem to contradict each other :)
>> 
>> Also, our mirror check script found the following issues:
>> 
>> o The tracefile at
>>  http://debian.apt-mirror.de/debian/project/trace/debian.apt-mirror.de
>>  is missing some required information.
>> 
>>  We expect at least the Maintainer and Upstream-mirror values to be filled 
>> in,
>>  and your tracefile is missing one or both of them.
>> 
>> o The tracefile
>>  http://debian.apt-mirror.de/debian/project/trace/debian.apt-mirror.de
>>  suggests that you are not using ftpsync.
>> 
>>  Please use our ftpsync script to mirror Debian.
>> 
>>  It should produce better trace files, and do the mirroring in a way that
>>  ensures the mirror is in a consistent state even during updates.
>> 
>>  http://debian.apt-mirror.de/debian/project/ftpsync/ftpsync-current.tar.gz
>> 
>> Cheers,
>> Julien

Bug#958741: RM: pyeos -- ROM; dead upstream, superseded

[Vincent Bernat]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The package is dead upstream and is superseded by pyeapi which is
present in Debian. It is not compatible with Python 3. Please, remove.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl6jUioSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5q9wP/jpZT2uCDvRAd/3LORsGaIXNOSvXp7/L
YdajhSEpYhTbbg7P+lYGnWew5mbwSIAH4/cPLhBjEsPTvSF8rOPTm1yuKSa1rQqc
827WbVGiOYt4sz0d+PzGGzat8Odq6KrnpoIP8Btr5gBFoTeLsiUZg0Mlxjwl4r2M
pOZP6F8zHWRfWIOy1tj1fH9IPUwqetz/lSL1+4Knyz7FdWDs1OqYI156fPaf13G6
Ryrm+iVcv+6zFX6C+EVenu6pnCS4iInxS8EMIkFapzQmgTgb0d+ojzxdY2pnI19+
hIX1jQVXJJW1uC20dynvUvm7ndVhUz85hX4zIrQHwak8x6IFjIcAVT5u+9N6/KWu
yWTkL38JknfHT9baNTLXdB6wZRVtJCKbHvU/1+cNDQORT/XZReC0sYeq2U2uJJsv
bG5F9PhDnx57QbWolIB7FE9XORg4qdwX9UUrq2NB7ydq0nDkxE7ziwmPVY4lodce
10vSg+M9P5PcdFclaUSb+YNAyafuZ0/WLgV0fh6Xq0bq7acGqYXV1YLQxruCFqO2
H0pMnIF4vlsj92Ip4mfSnXB/QJbThknI805OVO0iqt/fTpglRRjwtBFamGnVF6gq
rby98zt5Mk32b8/htyQyLMMFq0Uxg/cJNFGIvPT0BX1KDJ0fzy9BoIwlR8G+QMah
DgmQr7XkX+X2
=WoHJ
-END PGP SIGNATURE-

Bug#958740: ITP: heat-tempest-plugin -- OpenStack Integration Test Suite - Heat plugin

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: heat-tempest-plugin
  Version : 1.0.0
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/openstack/heat-tempest-plugin
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack Integration Test Suite - Heat plugin

 Tempest is a set of integration tests to be run against a live Openstack
 cluster in order to make sure that all components are working as expected.
 Tempest will start and stop virtual machine in order to check that your
 cloud is working as expected.
 .
 This package contains the Heat plugin.

Bug#958739: RM: python-kid -- RoQA; Depends on Python 2, dead upstream, no reverse deps

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove python-kid. It depends on Python 2, is dead upstream and there
are no remaining rdeps.

Cheers,
Moritz

Bug#955268: udd watch: "429 too many requests" from GitHub

[Mattia Rizzolo]

On Fri, Apr 24, 2020 at 03:57:18PM +0200, Lucas Nussbaum wrote:
> > > Done: https://salsa.debian.org/debian/devscripts/-/merge_requests/181
> > 
> > since there is only little progress on that merge request, could we have an
> > intermediate solution? For example by severely reducing the rate with which
> > uscan is run on github.com? Even if this means that there is only a check 
> > done
> > once a week, that's better than the current situation which already persists
> > for over a month.
> 
> I think that a suitable workaround would be to have a local uscan copy
> in UDD that can add the header, and then modify UDD to use it for
> github.
> 
> Anybody with access to UDD can do it. If nobody does, I'll try to do it
> when I run into Debian time, which is scarse those days.

I did a review yesterday, and I saw yadd provided the changes I
required.  I'll try to do a release tomorrow, so I think it would be
best if you just hold on a bit more.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#937429: pyeos: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Apr 24, 2020 at 09:13:37PM +0200, Vincent Bernat wrote:
>  ❦ 24 avril 2020 20:54 +02, Moritz Mühlenhoff:
> 
> >> Tags: sid bullseye
> >> User: debian-pyt...@lists.debian.org
> >> Usertags: py2removal
> >> 
> >> Python2 becomes end-of-live upstream, and Debian aims to remove
> >> Python2 from the distribution, as discussed in
> >> https://lists.debian.org/debian-python/2019/07/msg00080.html
> >> 
> >> Your package either build-depends, depends on Python2, or uses Python2
> >> in the autopkg tests.  Please stop using Python2, and fix this issue
> >> by one of the following actions.
> >
> > Hi Vincent,
> > https://github.com/spotify/pyeos/ has been archived (and prior to that not 
> > seen
> > an update for five years), let's remove it from the archive or are you 
> > planning
> > to port it to Python 3 yourself?
> 
> Hello Moritz,
> 
> Yes, we can remove it from the archive. It has been superseded by
> pyeapi. Do you want me to file a bug for removal?

Please go ahead!

Cheers,
Moritz

Bug#948673: swupdate: version 2020.04

[Bastian Germann]

I created https://salsa.debian.org/debian/swupdate/-/merge_requests/7
with the necessary changes for upstream version 2020.04.

Bug#958738: fiat: autopkgtest needs-internet

[Paul Gevers]

Source: fiat
Version: 2019.1.0-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: important
User: debian...@lists.debian.org
Usertags: needs-internet

Dear maintainer(s),

With a recent upload of numpy I noticed your autopkgtest fails on arm64.
Because of that I noticed that your test requires unlimited internet
access. We recently added the needs-internet restriction to the
autopkgtest definition [1], you should add it to your autopkgtest
declaration.

I copied some of the output at the bottom of this report.

Paul

[1]
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

https://ci.debian.net/data/autopkgtest/testing/arm64/f/fiat/5141002/log.gz


 ERRORS

 ERROR collecting test session
_
/usr/lib/python3/dist-packages/_pytest/config/__init__.py:440: in
_importconftest
return self._conftestpath2mod[conftestpath]
E   KeyError:
local('/tmp/autopkgtest-lxc.9ep66_0h/downtmp/build.kyr/src/test/regression/conftest.py')

During handling of the above exception, another exception occurred:
/usr/lib/python3/dist-packages/py/_path/common.py:383: in visit
for x in Visitor(fil, rec, ignore, bf, sort).gen(self):
/usr/lib/python3/dist-packages/py/_path/common.py:424: in gen
dirs = self.optsort([p for p in entries
/usr/lib/python3/dist-packages/py/_path/common.py:425: in 
if p.check(dir=1) and (rec is None or rec(p))])
/usr/lib/python3/dist-packages/_pytest/main.py:667: in _recurse
ihook = self.gethookproxy(dirpath)
/usr/lib/python3/dist-packages/_pytest/main.py:482: in gethookproxy
my_conftestmodules = pm._getconftestmodules(fspath)
/usr/lib/python3/dist-packages/_pytest/config/__init__.py:424: in
_getconftestmodules
mod = self._importconftest(conftestpath.realpath())
/usr/lib/python3/dist-packages/_pytest/config/__init__.py:474: in
_importconftest
self.consider_conftest(mod)
/usr/lib/python3/dist-packages/_pytest/config/__init__.py:527: in
consider_conftest
self.register(conftestmodule, name=conftestmodule.__file__)
/usr/lib/python3/dist-packages/_pytest/config/__init__.py:321: in register
ret = super(PytestPluginManager, self).register(plugin, name)
/usr/lib/python3/dist-packages/pluggy/manager.py:126: in register
hook._maybe_apply_history(hookimpl)
/usr/lib/python3/dist-packages/pluggy/hooks.py:333: in _maybe_apply_history
res = self._hookexec(self, [method], kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:83: in 
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
test/regression/conftest.py:32: in pytest_configure
raise RuntimeError("Download reference data failed")
E   RuntimeError: Download reference data failed



signature.asc
Description: OpenPGP digital signature

Bug#952544: driver 340.108 kernel crash at boot

[Andreas Beckmann]

Control: tag -1 moreinfo unreproducible

On 25/02/2020 16.08, Frédéric Lamorce wrote:
> Package:  nvidia-legacy-340xx-driver
> Version: 340.108-3~deb9u1
> 
> I am using MX Linux 18 on a Atom N270, with a nvidia GPU ION
> 
> kernel version 4.19.0-1-686 #1 SMP Debian 4.19.5-2~mx17+1 (2018-12-12) i686

I'm sorry, but we can support only Debian systems running stock Debian
kernels. Please check your distribution's support channels.

> It has worked for years using the nvidia legacy driver 340.xxx, but lastly
> I got an update for 340.108-3~deb9u1, it updates, compiles in kernel, etc.
> When I reboot I have a kernel crash, so my system does not boot anymore.

The screen(s) above with the error message and traceback would have been
more interesting.

Andreas

Bug#958737: linux-image-5.5.0-2-amd64: Intel Cannon Point-LP audio controller no longer works

[brian m. carlson]

Package: src:linux
Version: 5.5.17-1
Severity: normal

I have a ThinkPad X1 Carbon 7th Gen with an Intel Corporation Cannon
Point-LP High Definition Audio Controller as the built-in sound card.
With Linux 5.4, this sound card worked fine[0] without any firmware
necessary.  With Linux 5.5, it no longer does, and I can only get sound
to work if I use an external sound card (in my case, Thunderbolt).

In Linux 5.5, it claims it wants firmware, but this firmware is not
packaged for Debian.  It is unclear to me whether the card would work
if said firmware were provided, but it should not require it in any
event, since the card used to work fine without it.

The linux-image-5.6.0-trunk-amd64 works the same way as this package;
that is, the sound card fails to work while requesting firmware.

Please restore the functionality of this sound card such that it works
properly without firmware.  If the firmware is required for additional
functionality (e.g., the microphone), that's great, but it should at
least play audio like it did before if the firmware is missing.

[0] Playing audio, that is.  I've never tested the microphone.
-- Package-specific info:
** Version:
Linux version 5.5.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-10)) #1 SMP Debian 5.5.17-1 (2020-04-15)

** Command line:
BOOT_IMAGE=/vmlinuz-5.5.0-2-amd64 root=/dev/mapper/camp-root ro 
sysrq_always_enabled=1 processor.ignore_ppc=1 processor.ignore_tpc=1 quiet 
sysrq_always_enabled=1

** Not tainted

** Kernel log:
[   31.700544] usbcore: registered new interface driver snd-usb-audio
[   31.868906] intel_rapl_common: Found RAPL domain package
[   31.868907] intel_rapl_common: Found RAPL domain core
[   31.868908] intel_rapl_common: Found RAPL domain uncore
[   31.868909] intel_rapl_common: Found RAPL domain dram
[   31.904125] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0
[   31.927909] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   31.927916] Bluetooth: BNEP filters: protocol multicast
[   31.927923] Bluetooth: BNEP socket layer initialized
[   32.081931] snd_soc_skl :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040380
[   32.082079] snd_soc_skl :00:1f.3: Digital mics found on Skylake+ 
platform, using SOF driver
[   32.098179] sof-audio-pci :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040380
[   32.098571] sof-audio-pci :00:1f.3: Digital mics found on Skylake+ 
platform, using SOF driver
[   32.098893] sof-audio-pci :00:1f.3: warning: No matching ASoC machine 
driver found
[   32.098904] sof-audio-pci :00:1f.3: DSP detected with PCI 
class/subclass/prog-if 0x040380
[   32.099106] sof-audio-pci :00:1f.3: use msi interrupt mode
[   32.099215] sof-audio-pci :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   32.108030] sof-audio-pci :00:1f.3: hda codecs found, mask 5
[   32.108031] sof-audio-pci :00:1f.3: using HDA machine driver 
skl_hda_dsp_generic now
[   32.154837] sof-audio-pci :00:1f.3: firmware: failed to load 
intel/sof/sof-cnl.ri (-2)
[   32.154860] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   32.154879] sof-audio-pci :00:1f.3: Direct firmware load for 
intel/sof/sof-cnl.ri failed with error -2
[   32.154881] sof-audio-pci :00:1f.3: error: request firmware 
intel/sof/sof-cnl.ri failed err: -2
[   32.154899] sof-audio-pci :00:1f.3: error: failed to load DSP firmware -2
[   32.155181] sof-audio-pci :00:1f.3: error: sof_probe_work failed err: -2
[   32.477571] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM
[   32.591639] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM
[   32.655672] iwlwifi :00:14.3: FW already configured (0) - re-configuring
[   32.690414] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM
[   32.803672] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM
[   32.839473] irq 31: nobody cared (try booting with the "irqpoll" option)
[   32.839476] CPU: 6 PID: 0 Comm: swapper/6 Not tainted 5.5.0-2-amd64 #1 
Debian 5.5.17-1
[   32.839477] Hardware name: LENOVO 20QDCT01WW/20QDCT01WW, BIOS N2HET30W (1.13 
) 07/04/2019
[   32.839477] Call Trace:
[   32.839479]  
[   32.839484]  dump_stack+0x66/0x90
[   32.839486]  __report_bad_irq+0x38/0xad
[   32.839488]  note_interrupt.cold+0xb/0x6e
[   32.839489]  handle_irq_event_percpu+0x72/0x80
[   32.839490]  handle_irq_event+0x3c/0x5c
[   32.839491]  handle_fasteoi_irq+0xa3/0x160
[   32.839493]  do_IRQ+0x53/0xe0
[   32.839494]  common_interrupt+0xf/0xf
[   32.839495]  
[   32.839497] RIP: 0010:cpuidle_enter_state+0xc9/0x3e0
[   32.839498] Code: e8 ac 8d ab ff 80 7c 24 0f 00 74 17 9c 58 0f 1f 44 00 00 
f6 c4 02 0f 85 ea 02 00 00 31 ff e8 2e c0 b1 ff fb 66 0f 1f 44 00 00 <45> 85 ed 
0f 88 40 02 00 00 49 63 d5 4c 2b 64 24 10 48 8d 04 52 48
[   32.839499] RSP: 0018:ad76c0117e68 EFLAGS: 0246 ORIG_RAX: 
ffd7
[   

Bug#958343: /usr/bin/dh_installman: dh_installman doesn't fall back to using file extension when .TH line is incorrect

[Niels Thykier]

Paul Gevers:
> Hi Niels,
> 
> On 24-04-2020 20:23, Niels Thykier wrote:> Devil is in the detail.  The
> .TH/.Dt line is incorrect but not
>> "incorrect enough" for dh_installman to ignore it.  The version number
>> is treated as a section "0.15.0" which the "real" section (the X in
>> /usr/share/man/manX/foo.X.gz) as 0.
>>
>> I have added some code to catch obvious version numbers and ignore those
>> as well as out of bounds sections.  That said, there is limits to how
>> much brokenness this can recover from (a disclaimer for future reference).
> 
> Thanks for looking into it. I haven't checked your fix (if it's already
> available) but I noted in the man page that the .TH line should have an
> exact amount on entries. I trust you know this and count the number of
> entries now, no? I mean, the pasdoc man page had more entries than allowed.
> 
> Paul
> 

I just pushed it.

It is nothing fancy and debhelper never fully validated the .TH (or the
.Dt) line.  Patches welcome for that (provided it doable in a
"reasonable" size) but I have not written it.

~Niels

Bug#953875: runit - default installation can force init switch

[David Kalnischkies]

Control: reassign -1 runit 2.1.2-35

Hi,

On Fri, Apr 24, 2020 at 01:54:42PM +0200, Lorenzo Puliti wrote:
> Control: reassign -1 apt 2.0.2
> 
> Dear apt maintainers,

Tipp: Your message does not automatically reach the maintainers of
a package you reassign a bug to, only the 'Processed' notification
might which is easy to miss, so you should CC them manually e.g.
with packagen...@packages.debian.org, see also dev-ref §5.8.3 (2).


> Please implement a logic where apt parse the alternative recommends in order 
> and pick up
> the first that does not require a removal of any installed package in the 
> system. If none
> of the listed recommends can be installed without removing any packages, then 
> I think it's
> ok to pick the first listed.

Such heuristic ideas come up every once in a while, but sadly they do
not work in generic case. Your specific heuristic would currently be near
impossible to implement in apt and it isn't easy to answer who it is that
"requires a removal": If A conflicts with B and you want to install A,
A seems to be the culprit, right? Well, what if you wanna install B? Is
it Bs fault A has a conflict on it? What if C is a M-A:same package
where i386 wasn't built yet but amd64 is and B depends on >= newer. We
will need to remove C:i386 if we want B, but that isn't Bs fault, is it?

A fan favourite is the heuristic "needs the least new packages". Seems
reasonable, right? Yes, until you consider that near no-op packages like
discarding MTAs or memory-only settings managers are the best choice
then.

Apart from these, the general problem with these is that we get more
"magic" meaning that you need to understand and keep a lot more state in
your head to understand what is going on. Many people don't understand
what apt is doing now, what happens if we make it even harder…


What you want to express here is a conditional dependency:
if A is installed: install B (else C).

We don't have these kind of expressions and I highly doubt we ever will
as that gets funny rather quickly as well (if A is later installed, do
we need to install B now? Of course not you might think, but look at the
recommends discussed here: It could make sense…).


That said, we might eventually solve certain sub-cases (think: language
packs, virtual package provider choice, …) but that is a LONG way off,
certainly nothing you could wait for and put this issue on hold for the
time being. Also: Even if we had it tomorrow, there would still be the
issue of apt/stable not supporting it, so we still have the exact
problem in stable→stable upgrades. So, you have to resolve this one way
or the other and I am therefore handing this bug back to you.


> Note that this bug is not easy to fix on runit side:
> * changing the order of the recommends will cause the same issue for sysvinit 
> users

Note that I have *NO IDEA* about runit, init systems or the various
dependencies surrounding it, so I have no idea if runit is a package
a user is expected to install (in which case choosing the right is
relatively easy) or if it is e.g. a common dependency of other packages
in which case that seems less okay.

I am probably stepping on a few landmines now, but the first choice in
an or-group should be the least surprising option for the most users.
If you aren't sure, that usually achieved by going the route of "default
install" needs this one simply because everyone who isn't on the default
is more experienced and can deal with choosing non-default options in
related cases as well.

Also, if there is a reasonable way of making use of runit without either
of these recommends installed, then the recommends is indeed wrong.
Debian policy is quite clear that Recommends isn't a "just in case", but
"for everyone, expect unusual".

It MIGHT (remember, I have no idea) also makes sense to integrate into
all init systems by default instead of asking the user to pick one via
the recommends and do something about it at runtime.


Anyway, as there is nothing apt can really do about this I have to
reassign back even if I dislike bug-pingpong. Feel free to ask if you
have come up with a specific solution for your problem and want some
feedback from us regarding apt, but be prepared to explain a lot in your
question as apt developers are "only" (FSVO) experts in apt, not in the
dependency trees of all of Debian (you may consider us the rubber duck
debugging of dependency resolution). 


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#931299: nvidia-legacy-340xx-kernel-dkms: Don't really work in boot

[Andreas Beckmann]

Control: tag -1 moreinfo

On 01/07/2019 08.55, Ilari Halminen wrote:
> Package: nvidia-legacy-340xx-kernel-dkms
> Version: 340.106-2~deb9u1

> Those dkms modules do not really work in boot, but their nouveu counterpart 
> could.
> 
> This comes visible if you use like Plymounth boot. With that you will lose 
> the graphical boot and fallback to text box.
> 
> There is also some other things like different text size in text console. In 
> boot and after it.

Is this issue still reproducible with the updated
340.108-3~deb9u1/340.108-3~deb10u1 legacy driver packages in (old)stable?

Andreas

Bug#958736: supertux: Segfault in Ghouls' lair

[Nicola Chiapolini]

Package: supertux
Version: 0.6.1.1-2
Severity: important

Dear Maintainer,

While playing level "Ghouls' Lair", supertux segfaults after a few minutes. The 
segfaults are not triggered by any obvious user action
or map location.

To try and collect some data I did run `time supertux2` several times,
generating backtraces after each segfault. The result are attached.

Just let me know if I should investigate anything else or should report this 
upstream (to supertux or mesa).

thanks
Nicola


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

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

Versions of packages supertux depends on:
ii  libboost-filesystem1.67.0  1.67.0-17
ii  libboost-locale1.67.0  1.67.0-17
ii  libboost-system1.67.0  1.67.0-17
ii  libc6  2.30-4
ii  libcurl3-gnutls7.68.0-1
ii  libfreetype6   2.10.1-2
ii  libgcc-s1 [libgcc1]10-20200418-1
ii  libgcc11:10-20200418-1
ii  libgl1 1.3.1-1
ii  libglew2.1 2.1.0-4+b1
ii  libopenal1 1:1.19.1-1+b1
ii  libphysfs1 3.0.2-4
ii  libpng16-161.6.37-2
ii  libraqm0   0.7.0-4
ii  libsdl2-2.0-0  2.0.10+dfsg1-3
ii  libsdl2-image-2.0-02.0.5+dfsg1-2
ii  libstdc++6 10-20200418-1
ii  libvorbisfile3 1.3.6-2
ii  supertux-data  0.6.1.1-2

supertux recommends no packages.

supertux suggests no packages.

-- no debconf information
real2m21.836s
user1m32.959s
sys 0m43.507s
#0  0x7f46dba25bfb in GEN9_PIPE_CONTROL_pack (values=, 
dst=0x18, data=0x559017238d90) at src/intel/genxml/gen9_pack.h:9868
#1  gen9_emit_raw_pipe_control (brw=0x559017238d90, flags=flags@entry=0, 
bo=bo@entry=0x0, offset=offset@entry=0, imm=imm@entry=0) at 
../src/mesa/drivers/dri/i965/genX_pipe_control.c:461
#2  0x7f46dba25d4e in gen9_emit_raw_pipe_control (brw=0x559017238d90, 
flags=3194880, bo=0x0, offset=0, imm=0) at 
../src/mesa/drivers/dri/i965/genX_pipe_control.c:119
#3  0x7f46db50ddc9 in brw_fence_insert_locked (brw=0x559017238d90, 
fence=0x55901b572c90) at ../src/mesa/drivers/dri/i965/brw_sync.c:142
#4  0x7f46db6341a9 in fence_sync (ctx=0x559017238d90, condition=37143, 
flags=0) at ../src/mesa/main/syncobj.c:292
#5  0x55901648bdac in GLPixelRequest::request (this=0x7ffd36944750, x=199, 
y=50) at ./src/video/gl/gl_pixel_request.cpp:56
#6  0x559016488db4 in GLPainter::get_pixel (this=0x559017dea810, 
request=...) at ./src/video/gl/gl_painter.cpp:486
#7  0x55901629bb33 in Canvas::render (this=, renderer=..., 
filter=filter@entry=Canvas::ALL) at ./src/video/canvas.cpp:99
#8  0x55901629cf70 in Compositor::render (this=0x7ffd36944950) at 
./src/video/drawing_context.hpp:52
#9  0x559016274afd in ScreenManager::run() () at 
./src/supertux/screen_manager.cpp:511
#10 0x559016262e94 in Main::launch_game(CommandLineArguments const&) () at 
./src/supertux/main.cpp:525
#11 0x559016263d62 in Main::run(int, char**) () at 
./src/supertux/main.cpp:595
#12 0x55901625cad8 in main (argc=1, argv=0x7ffd36945688) at 
./src/main.cpp:23



real3m7.551s
user2m5.498s
sys 0m54.926s
#0  0x7fe0c277ebfb in GEN9_PIPE_CONTROL_pack (values=, 
dst=0x18, data=0x55b39ed38270) at src/intel/genxml/gen9_pack.h:9868
#1  gen9_emit_raw_pipe_control (brw=0x55b39ed38270, flags=17310224, 
bo=0x55b39ece5cd0, offset=0, imm=0) at 
../src/mesa/drivers/dri/i965/genX_pipe_control.c:461
#2  0x7fe0c226130e in brw_emit_pipe_control_write (imm=0, offset=0, 
bo=, flags=, brw=0x55b39ed38270) at 
../src/mesa/drivers/dri/i965/brw_pipe_control.c:298
#3  brw_emit_end_of_pipe_sync (brw=0x55b39ed38270, flags=) at 
../src/mesa/drivers/dri/i965/brw_pipe_control.c:298
#4  0x7fe0c225e57f in brw_upload_state_base_address 
(brw=brw@entry=0x55b39ed38270) at 
../src/mesa/drivers/dri/i965/brw_misc_state.c:782
#5  0x7fe0c277d889 in gen9_blorp_exec (batch=, 
params=) at ../src/mesa/drivers/dri/i965/genX_blorp_exec.c:332
#6  0x7fe0c28e90df in blorp_fast_clear (batch=batch@entry=0x7ffd087ad650, 
surf=surf@entry=0x7ffd087ad670, format=ISL_FORMAT_R8G8B8A8_UNORM, 
level=level@entry=0, start_layer=start_layer@entry=0, 
num_layers=num_layers@entry=1, x0=0, y0=0, x1=273, y1=153) at 
../src/intel/blorp/blorp_clear.c:358
#7  0x7fe0c2249141 in do_single_blorp_clear (brw=0x55b39ed38270, 
fb=, rb=0x55b3a1c9b590, buf=, 
partial_clear=, encode_srgb=) at 
../src/mesa/drivers/dri/i965/brw_blorp.c:1294
#8  0x7fe0c224b170 in 

Bug#958343: /usr/bin/dh_installman: dh_installman doesn't fall back to using file extension when .TH line is incorrect

[Paul Gevers]

Hi Niels,

On 24-04-2020 20:23, Niels Thykier wrote:> Devil is in the detail.  The
.TH/.Dt line is incorrect but not
> "incorrect enough" for dh_installman to ignore it.  The version number
> is treated as a section "0.15.0" which the "real" section (the X in
> /usr/share/man/manX/foo.X.gz) as 0.
> 
> I have added some code to catch obvious version numbers and ignore those
> as well as out of bounds sections.  That said, there is limits to how
> much brokenness this can recover from (a disclaimer for future reference).

Thanks for looking into it. I haven't checked your fix (if it's already
available) but I noted in the man page that the .TH line should have an
exact amount on entries. I trust you know this and count the number of
entries now, no? I mean, the pasdoc man page had more entries than allowed.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#958734: [Pkg-javascript-devel] Bug#958734: npm2deb: Man-pages don't document subcommands

[Xavier]

Le 24/04/2020 à 21:22, Calum McConnell a écrit :
> Package: npm2deb
> Version: 0.3.0-3
> Severity: important
> 
> I am trying to use npm2deb to package bitwarden, and I cant find the 
> documentation
> for the subcommands.  'man npm2deb' yields the manpage for npm, which states 
> the
> subcommands (ie, create, itp, license), but doesnt give the flags they take.
> I can tell the subcommands take flags, but I can't find any manpages on
> what those flags do.  Calls to 'man npm2deb create' tell me that no manpage
> exists for create: 'man -aw npm2deb' shows only one manpage, the (rather
> short) one for npm2deb.
> 
> If you need someone to transfer the docs from another location to manpage
> format, I can do that: just point me to where it is documented and I'll form
> a patch.

Hi,

thanks for your help, the only doc I know is npm2deb -h:

usage: npm2deb [-h] [-D DEBUG] [-v]
{create,view,depends,rdepends,search,itp,license} ...

optional arguments:
  -h, --helpshow this help message and exit
  -D DEBUG, --debug DEBUG
set debug level
  -v, --version show program's version number and exit

commands:
  {create,view,depends,rdepends,search,itp,license}
create  create the debian files
viewa summary view of a node module
depends show module dependencies in npm and debian
rdependsshow the reverse dependencies for module
search  look for module in debian project
itp print a itp bug template
license print license template and exit

Cheers,
Xavier

Bug#958735: dnstwist: autopkgtest needs-internet

[Paul Gevers]

Source: dnstwist
Version: 0~20190706+ds1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: important
User: debian...@lists.debian.org
Usertags: needs-internet

Dear maintainer(s),

With a recent upload of dnstwist you added an autopkgtest, great.
However, because of the failure on arm64 I noticed that your test
requires unlimited internet access. We recently added the needs-internet
restriction to the autopkgtest definition [1], you should add it to your
autopkgtest declaration.

I copied some of the output at the bottom of this report.

Paul

[1] https://qa.debian.org/excuses.php?package=dnstwist

https://ci.debian.net/data/autopkgtest/testing/arm64/d/dnstwist/4884265/log.gz

autopkgtest [21:14:52]: test testdebiandomain: [---
Found problems in the following lines:


Line 12: Bitsquatting   dabian.org   NS:dns27.hichina.com
MX:mxdomain.qq.com SMTP:"newxmmxsza53.qq.com MX QQ Mail Server."
Line 19: Insertion  derbian.org  NS:ns-108-c.gandi.net
MX:ALT1.ASPMX.L.GOOGLE.COM SMTP:"mx.google.com ESMTP g9si4331087plq.234
- gsmtp"


Dumping full output for further debugging purposes:


$ dnstwist --ssdeep --registered --mxcheck --geoip --banners debian.org
 _   __ _
  __| |_ __  ___| |___  _(_)___| |_
 / _` | '_ \/ __| __\ \ /\ / / / __| __|
| (_| | | | \__ \ |_ \ V  V /| \__ \ |_
 \__,_|_| |_|___/\__| \_/\_/ |_|___/\__| {20190706}

Fetching content from: http://debian.org ... 200 OK (14.4 Kbytes)
Processing 2489 domain variants ..16%.35%.54%..81%.99%.. 22 hits (0%)

Original*  debian.org   128.31.0.62/United States 2001:4f8:1:c::15
NS:dns4.easydns.info MX:mailly.debian.org HTTP:"Apache"
SMTP:"mailly.debian.org ESMTP Exim 4.92 Wed, 08 Apr 2020 21:14:54 +"
SSDEEP:100%
Bitsquatting   febian.org   184.168.131.241/United States
NS:ns75.domaincontrol.com HTTP:"nginx/1.12.2"
Bitsquatting   dabian.org   NS:dns27.hichina.com MX:mxdomain.qq.com
SMTP:"newxmmxsza53.qq.com MX QQ Mail Server."
Bitsquatting   dubian.org   119.146.223.181/China NS:dns7.hichina.com
MX:mxn.mxhichina.com SMTP:"mx1.aliyun-inc.com MX AliMail Server"
Bitsquatting   debaan.org   185.135.241.4/Netherlands
NS:ns1.hosting2go.nl SPYING-MX:debaan.orgHTTP:"Apache"
SMTP:"server4.hosting2go.nl ESMTP"
Homoglyph  diebian.org  119.28.189.104/Hong Kong NS:dns10.hichina.com
Homoglyph  deblan.org   82.237.165.150/France NS:ns-154-c.gandi.net
MX:mail.deblan.org HTTP:"nginx" SMTP:"deblan.fr ESMTP mail.deblan.org"
Homoglyph  deb1an.org   107.181.167.155/United States
NS:ns1.shellhosts.com HTTP:"Apache"
Homoglyph  debiam.org   217.70.184.50/France NS:a.dns.gandi.net
HTTP:"nginx"
Insertion  derbian.org  NS:ns-108-c.gandi.net
MX:ALT1.ASPMX.L.GOOGLE.COM SMTP:"mx.google.com ESMTP g9si4331087plq.234
- gsmtp"
Omission   debin.org104.27.160.17/United States
2606:4700:3030::681b:a011 NS:ajay.ns.cloudflare.com
SPYING-MX:mxa.mailgun.orgHTTP:"cloudflare" SMTP:"ak47 ESMTP ready"
Omission   deian.org75.126.100.29/United States
NS:ns1dhl.name.com MX:mx3.name.com HTTP:"nginx"
Omission   debia.org3.234.181.234/United States
NS:ns1.namebrightdns.com HTTP:"Microsoft-IIS/8.5"
Replacementdevian.org   64.98.145.30/Canada NS:ns1.hover.com
MX:mx.hover.com.cust.hostedemail.com HTTP:"nginx/1.6.2 + Phusion
Passenger 4.0.53" SMTP:"450 4.7.1 Client host rejected: cannot f"
Replacementdebuan.org   146.148.34.125/United States
NS:ns4.dnsauthority.com SPYING-MX:mail.hope-mail.comHTTP:"Apache"
SMTP:"ip-10-130-0-34 ESMTP Haraka/2.8.20 ready"
Replacementdegian.org   3.112.75.141/Japan NS:ns7.alidns.com
Replacementdenian.org   139.224.7.30/China NS:n3381.ns.yunjiasu.com
SPYING-MX:mxbiz1.qq.comHTTP:"Beaver" SMTP:"bizmx5.qq.com MX QQ Mail Server"
Replacementxebian.org   51.77.251.195/France NS:ns-211-b.gandi.net
MX:fb.mail.gandi.net HTTP:"Cherokee/1.2.104 (Debian)"
SMTP:"fb.mail.gandi.net ESMTP Postfix"
Subdomain  de.bian.org  176.221.45.101/Germany 2a00:1158:300::612
HTTP:"Apache/2.4.41"
Transposition  edbian.org   142.3.19.228/Canada
NS:ns15.domaincontrol.com MX:edbian.org HTTP:"Apache/2.4.25 (Debian)"
Transposition  debain.org   95.211.117.215/Netherlands
NS:ns1.hastydns.com HTTP:"HTTP 302"
Vowel-swap debion.org   81.169.145.161/Germany
2a01:238:20a:202:1161:: NS:docks08.rzone.de MX:smtpin.rzone.de
HTTP:"Apache/2.4.41 (Unix)" SMTP:"smtpin.rzone.de ESMTP RZmta 46.2.1
ready (mi6)"
autopkgtest [21:15:14]: test testdebiandomain: ---]



signature.asc
Description: OpenPGP digital signature

Bug#887534: plume-creator FTBFS with libquazip5-headers 0.7.3-3

[Sudip Mukherjee]

This error is not reproducible any more and imho, it has been fixed
when libquazip5-1 updated to depend on libquazip5-headers via #884800.

But, it now fails with the error:
src/newProjectWizard/selectpage.cpp: In constructor 
‘SelectPage::SelectPage(QWidget*)’:
src/newProjectWizard/selectpage.cpp:11:52: error: expected type-specifier 
before ‘QRegExpValidator’



--
Regards
Sudip

Bug#958734: npm2deb: Man-pages don't document subcommands

[Calum McConnell]

Package: npm2deb
Version: 0.3.0-3
Severity: important

I am trying to use npm2deb to package bitwarden, and I cant find the 
documentation
for the subcommands.  'man npm2deb' yields the manpage for npm, which states the
subcommands (ie, create, itp, license), but doesnt give the flags they take.
I can tell the subcommands take flags, but I can't find any manpages on
what those flags do.  Calls to 'man npm2deb create' tell me that no manpage
exists for create: 'man -aw npm2deb' shows only one manpage, the (rather
short) one for npm2deb.

If you need someone to transfer the docs from another location to manpage
format, I can do that: just point me to where it is documented and I'll form
a patch.

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

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

Versions of packages npm2deb depends on:
ii  devscripts2.20.2
ii  node-github-url-from-git  1.5.0-1
ii  npm   6.14.4+ds-1
ii  python3   3.8.2-3
ii  python3-apt   2.1.2
ii  python3-dateutil  2.8.1-4

npm2deb recommends no packages.

npm2deb suggests no packages.

-- no debconf information

Bug#937429: pyeos: Python2 removal in sid/bullseye

[Vincent Bernat]

 ❦ 24 avril 2020 20:54 +02, Moritz Mühlenhoff:

>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
>> 
>> Python2 becomes end-of-live upstream, and Debian aims to remove
>> Python2 from the distribution, as discussed in
>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>> 
>> Your package either build-depends, depends on Python2, or uses Python2
>> in the autopkg tests.  Please stop using Python2, and fix this issue
>> by one of the following actions.
>
> Hi Vincent,
> https://github.com/spotify/pyeos/ has been archived (and prior to that not 
> seen
> an update for five years), let's remove it from the archive or are you 
> planning
> to port it to Python 3 yourself?

Hello Moritz,

Yes, we can remove it from the archive. It has been superseded by
pyeapi. Do you want me to file a bug for removal?
-- 
The smallest worm will turn being trodden on.
-- William Shakespeare, "Henry VI"


signature.asc
Description: PGP signature

Bug#958733: genext2fs: autopkgtest failure on arm64: libguestfs: error: appliance closed the connection unexpectedly.

[Paul Gevers]

Source: genext2fs
Version: 1.4.2-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

With a recent upload of genext2fs you added an autopkgtest, great.
However, it fails on arm64.

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=genext2fs

https://ci.debian.net/data/autopkgtest/testing/arm64/g/genext2fs/5128192/log.gz

I: Unpacking the base system...
I: Base system installed successfully.
+ tar --numeric-owner --sort=name -C rootfs.in -cf rootfs.in.tar .
+ du --apparent-size --block-size 1024 --summarize rootfs.in
+ cut -f 1
+ numblocks=184608
+ numblocks=203068
+ genext2fs -B 1024 -b 203068 -d rootfs.in rootfs.dir.img
+ rm -rf rootfs.in
+ genext2fs -B 1024 -b 203068 -N 0 rootfs.tar.img
+ genext2fs -B 1024 -b 203068 -N 0 rootfs2.tar.img
+ cmp rootfs.tar.img rootfs2.tar.img
+ rm rootfs2.tar.img
+ guestfish add-ro rootfs.dir.img : run : mount /dev/sda / : tar-out /
rootfs.tar
*stdin*:0: libguestfs: error: appliance closed the connection unexpectedly.
This usually means the libguestfs appliance crashed.
Do:
  export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
and run the command again.  For further information, read:
  http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
You can also run 'libguestfs-test-tool' and post the *complete* output
into a bug report or message to the libguestfs mailing list.
*stdin*:0: libguestfs: error: /usr/bin/qemu-system-aarch64 exited with
error status 1.
To see full error messages you may need to enable debugging.
Do:
  export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
and run the command again.  For further information, read:
  http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
You can also run 'libguestfs-test-tool' and post the *complete* output
into a bug report or message to the libguestfs mailing list.
*stdin*:0: libguestfs: error: guestfs_launch failed.
This usually means the libguestfs appliance failed to start or crashed.
Do:
  export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
and run the command again.  For further information, read:
  http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
You can also run 'libguestfs-test-tool' and post the *complete* output
into a bug report or message to the libguestfs mailing list.
autopkgtest [16:59:46]: test general: ---]



signature.asc
Description: OpenPGP digital signature

Bug#949228: python{,3}-mox: Missing dependency on python{,3}-six

[Iustin Pop]

On 2020-01-18 15:38:18, Adrian Bunk wrote:
> Package: python3-mox
> Version: 0.7.8-3
> Severity: serious
> Control: affects -1 python-mox
> 
> ? python3
> Python 3.7.6 (default, Dec 19 2019, 09:25:23)
> [GCC 9.2.1 20191130] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import mox
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/tmp/python-mox-0.7.8/mox.py", line 72, in 
> import six
> ModuleNotFoundError: No module named 'six'
> >>>
> $ python
> Python 2.7.17 (default, Oct 19 2019, 23:36:22)
> [GCC 9.2.1 20191008] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import mox
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "mox.py", line 72, in 
> import six
> ImportError: No module named six
> >>>
> $
> 
> 
> Adding "python-six, python3-six" to the test dependencies fixed the tests,
> but didn't address the actual problem that the packages need these
> dependencies (which caused the test failure).

… and this is what hid this problem from the autopkgtest - the tests
have the dependencies, so nothing showed that the package itself is
broken.

Thanks, will fix.

iustin

Bug#957957: wmweather+: ftbfs with GCC-10

[Brad Jorsch]

Should be fixed in version 2.18 that I just uploaded upstream.

I also went ahead and removed the auto-dating of the manpage upstream,
as I recall that has been a problem for some of my other programs that
are packaged in Debian.

Bug#958446: nvidia-legacy-340xx-driver: Fails to build with kernel 5.6

[Andreas Beckmann]

On 22/04/2020 10.32, jim_p wrote:
> Here is the patch, again from aur
> https://aur.archlinux.org/cgit/aur.git/plain/05-unfuck-for-
> kernel-5.6.x.patch?h=nvidia-340xx

Now that we have 5.6 in experimental, I could test it ...

> Unlike last time with 5.5, it seems that it patches a number of files and I do
> not know how to do it myself, so I can't test it.

something like

cd /usr/src/something
patch -p1 < the.patch


That patch breaks on 4.19 (buster's kernel):

In file included from 
/usr/src/modules/nvidia-legacy-340xx-kernel/uvm/nvidia_uvm_lite.c:33:
/usr/src/modules/nvidia-legacy-340xx-kernel/uvm/../nv-time.h: In function 
'nv_gettimeofday':
/usr/src/modules/nvidia-legacy-340xx-kernel/uvm/../nv-time.h:38:21: error: 
passing argument 1 of 'do_gettimeofday' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 do_gettimeofday(tv);
 ^~
In file included from 
/usr/src/linux-headers-4.19.0-8-common/include/linux/ktime.h:276,
 from 
/usr/src/linux-headers-4.19.0-8-common/include/linux/timer.h:6,
 from 
/usr/src/linux-headers-4.19.0-8-common/include/linux/workqueue.h:9,
 from 
/usr/src/linux-headers-4.19.0-8-common/include/linux/rhashtable-types.h:15,
 from 
/usr/src/linux-headers-4.19.0-8-common/include/linux/ipc.h:7,
 from 
/usr/src/linux-headers-4.19.0-8-common/include/uapi/linux/sem.h:5,
 from 
/usr/src/linux-headers-4.19.0-8-common/include/linux/sem.h:5,
 from 
/usr/src/linux-headers-4.19.0-8-common/include/linux/sched.h:15,
 from 
/usr/src/linux-headers-4.19.0-8-common/include/linux/utsname.h:6,
 from 
/usr/src/modules/nvidia-legacy-340xx-kernel/uvm/nvidia_uvm_linux.h:62,
 from 
/usr/src/modules/nvidia-legacy-340xx-kernel/uvm/nvidia_uvm_common.h:49,
 from 
/usr/src/modules/nvidia-legacy-340xx-kernel/uvm/nvidia_uvm_lite.c:26:
/usr/src/linux-headers-4.19.0-8-common/include/linux/timekeeping32.h:9:52: 
note: expected 'struct timeval *' but argument is of type 'struct 
__kernel_old_timeval *'
 static inline void do_gettimeofday(struct timeval *tv)
^~

It's probably something trivial (I suspect the conftest.sh timeval test),
but I'm too lazy to dig into this for an EoL driver :-P

(I'm not going to apply any patches to the nvidia driver packages
that break backwards compatibility with any old kernel.)


Andreas

Bug#958732: linux-image-5.5.0-2-amd64: invalid opcode: 0000 [#1] SMP PTI kernel crash (stilll called an Oops?)

[ael]

Package: src:linux
Version: 5.5.17-1
Severity: normal

Kernel crash:


Apr 24 12:58:24 shelf kernel: [ 8109.802668] [ cut here 
]
Apr 24 12:58:24 shelf kernel: [ 8109.802673] invalid opcode:  [#1] SMP PTI
Apr 24 12:58:24 shelf kernel: [ 8109.802676] CPU: 4 PID: 5665 Comm: Xorg Not 
tainted 5.5.0-2-amd64 #1 Debian 5.5.17-1
Apr 24 12:58:24 shelf kernel: [ 8109.802677] Hardware name: Notebook
 W54_55SU1,SUW/W54_55SU1,SUW, BIOS 4.6.5 05/29/2014
Apr 24 12:58:24 shelf kernel: [ 8109.802681] RIP: 
0010:__list_del_entry_valid.cold+0x1d/0x55
Apr 24 12:58:24 shelf kernel: [ 8109.802683] Code: c7 c7 98 b0 31 b5 e8 65 a5 
cc ff 0f 0b 48 89 fe 48 c7 c7 28 b1 31 b5 e8 54 a5 cc ff 0f 0b 48 c7 c7 d8 b1 
31 b5 e8 46 a5 cc ff <0f> 0b 48 89 f2 48 89 fe 48 c7 c7 98 b1 31 b5 e8 32 a5 cc 
ff 0f 0b
Apr 24 12:58:24 shelf kernel: [ 8109.802684] RSP: 0018:bd3ec0d47a18 EFLAGS: 
00010046
Apr 24 12:58:24 shelf kernel: [ 8109.802686] RAX: 0054 RBX: 
99851d93c900 RCX: 
Apr 24 12:58:24 shelf kernel: [ 8109.802687] RDX:  RSI: 
9985cfb19a48 RDI: 9985cfb19a48
Apr 24 12:58:24 shelf kernel: [ 8109.802688] RBP: 9985a97ef700 R08: 
0383 R09: 0001
Apr 24 12:58:24 shelf kernel: [ 8109.802689] R10:  R11: 
0001 R12: 99851d93d200
Apr 24 12:58:24 shelf kernel: [ 8109.802690] R13: 0282 R14: 
9985a97ef708 R15: 99859d458b00
Apr 24 12:58:24 shelf kernel: [ 8109.802691] FS:  7f0f70440f00() 
GS:9985cfb0() knlGS:
Apr 24 12:58:24 shelf kernel: [ 8109.802692] CS:  0010 DS:  ES:  CR0: 
80050033
Apr 24 12:58:24 shelf kernel: [ 8109.802693] CR2: 7f0f5c53a00c CR3: 
0003dff38001 CR4: 001606e0
Apr 24 12:58:24 shelf kernel: [ 8109.802694] Call Trace:
Apr 24 12:58:24 shelf kernel: [ 8109.802735]  __i915_active_fence_set+0x42/0xc0 
[i915]
Apr 24 12:58:24 shelf kernel: [ 8109.802761]  i915_active_ref+0x135/0x180 [i915]
Apr 24 12:58:24 shelf kernel: [ 8109.802786]  
i915_vma_move_to_active+0x24/0x150 [i915]
Apr 24 12:58:24 shelf kernel: [ 8109.802809]  
i915_gem_do_execbuffer+0xd75/0x18f0 [i915]
Apr 24 12:58:24 shelf kernel: [ 8109.802813]  ? _cond_resched+0x15/0x30
Apr 24 12:58:24 shelf kernel: [ 8109.802815]  ? mutex_lock+0xe/0x30
Apr 24 12:58:24 shelf kernel: [ 8109.802818]  ? 
unix_stream_read_generic+0x1f7/0x990
Apr 24 12:58:24 shelf kernel: [ 8109.802820]  ? __switch_to_asm+0x34/0x70
Apr 24 12:58:24 shelf kernel: [ 8109.802823]  ? aa_sk_perm+0x3e/0x1a0
Apr 24 12:58:24 shelf kernel: [ 8109.802827]  ? __kmalloc_node+0x1fe/0x310
Apr 24 12:58:24 shelf kernel: [ 8109.802850]  
i915_gem_execbuffer2_ioctl+0x1df/0x3d0 [i915]
Apr 24 12:58:24 shelf kernel: [ 8109.802872]  ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
Apr 24 12:58:24 shelf kernel: [ 8109.802890]  drm_ioctl_kernel+0xaa/0xf0 [drm]
Apr 24 12:58:24 shelf kernel: [ 8109.802900]  drm_ioctl+0x208/0x390 [drm]
Apr 24 12:58:24 shelf kernel: [ 8109.802922]  ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
Apr 24 12:58:24 shelf kernel: [ 8109.802924]  do_vfs_ioctl+0x461/0x6d0
Apr 24 12:58:24 shelf kernel: [ 8109.802927]  ? do_setitimer+0xad/0x1f0
Apr 24 12:58:24 shelf kernel: [ 8109.802929]  ksys_ioctl+0x5e/0x90
Apr 24 12:58:24 shelf kernel: [ 8109.802931]  __x64_sys_ioctl+0x16/0x20
Apr 24 12:58:24 shelf kernel: [ 8109.802933]  do_syscall_64+0x52/0x180
Apr 24 12:58:24 shelf kernel: [ 8109.802935]  
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Apr 24 12:58:24 shelf kernel: [ 8109.802937] RIP: 0033:0x7f0f70997427
Apr 24 12:58:24 shelf kernel: [ 8109.802938] Code: 00 00 90 48 8b 05 69 7a 0c 
00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 
b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 7a 0c 00 f7 d8 64 
89 01 48
Apr 24 12:58:24 shelf kernel: [ 8109.802939] RSP: 002b:7ffdf888fe38 EFLAGS: 
0246 ORIG_RAX: 0010
Apr 24 12:58:24 shelf kernel: [ 8109.802941] RAX: ffda RBX: 
7ffdf888fe80 RCX: 7f0f70997427
Apr 24 12:58:24 shelf kernel: [ 8109.802942] RDX: 7ffdf888fe80 RSI: 
40406469 RDI: 000e
Apr 24 12:58:24 shelf kernel: [ 8109.802942] RBP: 40406469 R08: 
564981207f20 R09: 0010
Apr 24 12:58:24 shelf kernel: [ 8109.802943] R10:  R11: 
0246 R12: 5649811c56c0
Apr 24 12:58:24 shelf kernel: [ 8109.802944] R13: 000e R14: 
 R15: 7f0f6fb93e08
Apr 24 12:58:24 shelf kernel: [ 8109.802946] Modules linked in: essiv authenc 
dm_crypt dm_mod uas usb_storage cpuid snd_hrtimer snd_seq snd_seq_device bnep 
uinput binfmt_misc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 
videobuf2_common videodev mc btusb btrtl btbcm btintel bluetooth drbg 
ansi_cprng ecdh_generic ecc intel_rapl_msr intel_rapl_common 
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass 
crct10dif_pclmul 

Bug#958731: mr: Using sr.ht repo URLs results in "illegal checkout command"

[Daniel Gröber]

Package: myrepos
Version: 1.20180726
Severity: normal

Dear Maintainer,

when the .mrconfig file contains a URL from the
[sr.ht](https://sourcehut.org) forge it doesn't recognise it as
trusted.

For example, if I have this in .mrconfig:

[builds.sr.ht]
checkout = git clone 'https://git.sr.ht/~sircmpwn/core.sr.ht' 'core.sr.ht'

and run the `mr update` command, I get:

mr: illegal checkout command "git clone 
'https://git.sr.ht/~sircmpwn/core.sr.ht' 'core.sr.ht'" in untrusted 
/.mrconfig line 3
(To trust this file, list it in ~/.mrtrust.)

It seems this is because of the "unusual" tilde character in the URL.
The mr source has the following regex in `is_trusted_checkout`:

# Match all the typical characters found in
# urls, plus @ which svn can use. Note
# that the "url" might also be a local
# directory.
$match=(
defined $words[$c] &&
$words[$c] =~ /^[-_.+:@\/A-Za-z0-9]+$/
);
$url=$words[$c];

My guess is adding "~" to the character class would fix the issue.

Thanks,
--Daniel

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

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

Versions of packages myrepos depends on:
ii  perl  5.28.1-6

Versions of packages myrepos recommends:
ii  libfile-homedir-perl  1.004-1
ii  libhtml-parser-perl   3.72-3+b3
ii  libio-pty-easy-perl   0.10-1
ii  libwww-perl   6.36-2

Versions of packages myrepos suggests:
pn  ack | ack-grep
ii  bzr   2.7.0+bzr6622-15
ii  curl  7.64.0-4+deb10u1
ii  cvs   2:1.12.13+real-27
ii  darcs 2.14.1-3
pn  dgit  
pn  fossil
ii  git [git-core]1:2.20.1-2+deb10u3
ii  git-annex 7.20190129-3
pn  git-big-picture   
ii  git-svn   1:2.20.1-2+deb10u3
pn  kdesdk-scripts
ii  liburi-perl   1.76-1
ii  mercurial 4.9-2
ii  perl-doc  5.28.1-6
ii  stow  2.2.2-1
ii  subversion1.10.4-1+deb10u1
pn  subversion-tools  
ii  tig   2.4.1-1
ii  unison2.48.4-1+b1
ii  vcsh  1.20151229-1
ii  xdg-utils 1.1.3-1

-- no debconf information

Bug#958451: ausweisapp2: gets stuck when using service "Arbeitnehmer online"

[John Paul Adrian Glaubitz]

Hi Juergen!

On 4/24/20 7:48 PM, Jürgen Bausa wrote:
> ok, I understand. I will try to find out which version of the QML platform 
> module is offered by Buster. And then try to change the requirement in 
> Ausweisapp2.

I'm not sure whether overriding the version requirement will fix the problem,
normally the minimum version for a dependency is set for a reason. The software
might behave erratically.

> However, I am wondering why the second bug report on this problem 
> disappeared. 
> I think it would be good to keep at least one of this two bug reports (or 
> merge them) with an explanation. This would help all people who try to use 
> the 
> backport.
I merged both bug reports into one because these are reporting the same issue.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#937429: pyeos: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

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

Hi Vincent,
https://github.com/spotify/pyeos/ has been archived (and prior to that not seen
an update for five years), let's remove it from the archive or are you planning
to port it to Python 3 yourself?

Cheers,
Moritz

Bug#958343: /usr/bin/dh_installman: dh_installman doesn't fall back to using file extension when .TH line is incorrect

[Niels Thykier]

Paul Gevers:
> Package: debhelper
> Version: 12.10
> Severity: normal
> File: /usr/bin/dh_installman
> 
> Dear Maintainers, Niels,
> 
> Recently pasdoc started to FTBFS (bug #954676) for what is apparently a
> change in the output of help2man. However, I think it shouldn't FTBFS on
> that, as the documentation of dh_installman reads:
> """
> If your .TH or .Dt line is incorrect or missing, the program may guess
> wrong based on the file extension.
> """
> 
> I have attached the output of $(help2man pasdc) on my system. The .TH
> line doesn't obey the definition I found in man(7).
> 
> Paul
> 
> 
> [...]


Hi Paul,

Devil is in the detail.  The .TH/.Dt line is incorrect but not
"incorrect enough" for dh_installman to ignore it.  The version number
is treated as a section "0.15.0" which the "real" section (the X in
/usr/share/man/manX/foo.X.gz) as 0.

I have added some code to catch obvious version numbers and ignore those
as well as out of bounds sections.  That said, there is limits to how
much brokenness this can recover from (a disclaimer for future reference).

~Niels

Bug#958730: src:drf-extensions: fails to migrate to testing for too long

[Paul Gevers]

Source: drf-extensions
Version: 0.4.0-1.1
Severity: serious
Control: close -1 0.6.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 953751

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:drf-extensions in its current version in unstable has been trying to
migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=drf-extensions




signature.asc
Description: OpenPGP digital signature

Bug#958729: testdisk: Please consider migrating away from old -dbg debug packages

[Boyuan Yang]

Source: testdisk
Version: 7.1-5
Severity: minor
X-Debbugs-CC: kelb...@debian.org

Dear Debian testdisk maintainer,

I noticed that your package is still shipping a testdisk-dbg package, which is
the old-style debug package. Please consider migrating to the new automatic
-dbgsym package.

The detail about this migration can be found at 
https://wiki.debian.org/AutomaticDebugPackages .

-- 
Regards,
Boyuan Yang


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

Bug#958728: dvi2tty.1: Correct some mistakes and typographic issues in the manual

[Bjarni Ingi Gislason]

Package: texlive-binaries
Version: 2019.20190605.51237-3
Severity: minor
Tags: patch

Dear Maintainer,

  Summary:

Fix spelling of

  cahracters

  powerfull

  Scandinavion

Delete repeated words.

Change '-' to '\-', if it is a minus.

Change "c.f." to "cf.", as this is one word.

Mark periods ('. ' or '.\n') with '\&', if they do not mean an end of a
sentence.

Add a comma after "e.g." and "i.e.", or use English words.

Change \\ to \e to print the escape character.

Remove space at end of lines.

Fix warnings from test-groff.

Change [\]- to \(en if it is
a numeric range.

Use the word 'valid' instead of "legal" (GNU coding standard).

Change a HYPHEN-MINUS (code 0x55, 2D) to a dash
(minus) if it matches " -[:alpha:]" or \[aq]-[:alpha:] (for options).

  Use horizontal move function (\h'...') instead of a series of spaces.



  Details:

Input file is dvi2tty.1

chk_man: Next line: execute mandoc -T lint dvi2tty.1
mandoc: dvi2tty.1:86:43: STYLE: whitespace at end of input line
mandoc: dvi2tty.1:1:15: WARNING: cannot parse date, using it verbatim: 13 
November 1990
mandoc: dvi2tty.1:48:2: WARNING: skipping paragraph macro: PP empty

###

Remove space characters at the end of lines.

Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".

86:With a negative value the number of spaces 

#

Test nr. 2:

Enable and fix warnings from 'test-groff'.


Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z

  [ "test-groff" is a developmental version of "groff" ]

Input file is ./dvi2tty.1

troff: backtrace: file '':86
troff: :86: warning: trailing space


 End of tempfile -

#

Test nr. 5:

Change '-' (\-) to '\(en' (en-dash) for a numeric range.

dvi2tty.1:69:Legal range 16\-132.

#


Test nr. 20:

Use "\e" to print the escape character instead of "\\" (which gets
interpreted in copy mode).

55:Numbers refer to TeX\-page numbers (known as \\count0).
128:terminals in Scandinavia are mapped to ``{|}[\\]''.

#

Test nr. 22:

Use the word 'valid' instead of "legal" if not related to legal matters.
See "www.gnu.org/prep/standards".
Think about translations into other languages!

69:Legal range 16\-132.

#

Test nr. 25:

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

29:ordinary ascii terminal, such as the '+' and '-' symbol.
110:Dvi2tty normally tries to output accented characters. With the -a option,
124:Note this may interfere with -s. Best not to use -u and -s together.
129:Note this may interfere with -u. Best not to use -u and -s together.

#

Test nr. 27:

Find a repeated word

! 28 --> be
! 40 --> a

#

Test nr. 35:

Add a comma after "e.g." and "i.e.", or use English words
(man-pages(7).
Abbreviation points should be protected against being interpreted as
an end of sentence, if they are not, and that independent of the
current place on the line.

35:devices (e.g. laser printers). To show that a broken line is really

#

  Patch is in the attachment.


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

Kernel: Linux 5.4.19-1 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages texlive-binaries depends on:
ii  dpkg 1.19.7
ii  install-info 6.7.0.dfsg.2-5
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgcc-s1 [libgcc1]  10-20200418-1
ii  libgcc1  1:10-20200418-1
ii  libgraphite2-3   1.3.14-1
ii  libharfbuzz-icu0 2.6.4-1
ii  libharfbuzz0b2.6.4-1
ii  libicu63 63.2-3
ii  libkpathsea6 2019.20190605.51237-3
ii  libmpfr6 4.0.2-1
ii  libpaper11.1.28+b1
ii  libpixman-1-00.36.0-1
ii  libpng16-16  1.6.37-2
ii  libptexenc1  2019.20190605.51237-3
ii  libstdc++6   10-20200418-1
ii  libsynctex2  2019.20190605.51237-3
ii  libteckit0   2.5.8+ds2-5
ii  libtexlua53  2019.20190605.51237-3
ii  libtexluajit22019.20190605.51237-3
ii  libx11-6 2:1.6.9-2
ii  libxaw7  2:1.0.13-1+b2
ii  libxi6   2:1.7.9-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  libxt6   1:1.1.5-1+b3
ii  libzzip-0-13 0.13.62-3.2
ii  perl 5.30.0-10
ii  t1utils  1.41-3
ii  tex-common   6.14
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages texlive-binaries recommends:
pn  dvisvgm   
ii  texlive-base  2019.20200302-1

texlive-binaries suggests no packages.

-- no debconf information

-- 

Bug#958727: autopkgtest-virt-ssh: support root-on-testbed when logging in as root

[Ivo De Decker]

package: autopkgtest
version: 5.10
tags: patch

Hi,

When logging in as root, autopkgtest-virt-ssh should assume that
root-on-testbed is available. The current code doesn't do that.

If autopkgtest-virt-ssh is started with '--capability root-on-testbed', but
sudo fails, the 'root-on-testbed' capability is assumed to be absent and
removed. This should (at least) result in a warning, to allow easier
debugging.

The attached patch fixes both issues.

Thanks!

Ivo

--- /usr/bin/autopkgtest-virt-ssh	2020-04-24 18:20:34.417318935 +
+++ /usr/bin/autopkgtest-virt-ssh.root	2020-04-24 18:20:26.637316737 +
@@ -326,16 +326,18 @@
 
 global sshconfig, sshcmd, capabilities, workdir
 
-if sshconfig['login'] != 'root':
-(sudocmd, askpass) = can_sudo(sshcmd)
-else:
+if sshconfig['login'] == 'root':
 (sudocmd, askpass) = (None, None)
-if sudocmd:
-if 'root-on-testbed' not in capabilities:
-capabilities.append('root-on-testbed')
+capabilities.append('root-on-testbed')
 else:
-if 'root-on-testbed' in capabilities:
-capabilities.remove('root-on-testbed')
+(sudocmd, askpass) = can_sudo(sshcmd)
+if sudocmd:
+if 'root-on-testbed' not in capabilities:
+capabilities.append('root-on-testbed')
+else:
+if 'root-on-testbed' in capabilities:
+adtlog.warning('sudo command failed: removing root-on-testbed capability')
+capabilities.remove('root-on-testbed')
 
 extra_cmd = ''
 if askpass:

Bug#958726: RM: anything-el -- RoQA; Broken; Unmaintained; Upstream Dead; Alternative Available

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: tak...@debian.or.jp

Dear FTP Masters,

Please remove package anything-el from Debian archive. According to 
https://bugs.debian.org/873372 , this package has an inactive upstream with no
releases for 8 years. Besides, it saw no maintainer upload in the last 9
years. A forked alternative (elpa-helm) is already available in Debian and
being actively maintained.

-- 
Regards,
Boyuan Yang


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

Bug#873372: anything-el: package is outdated and obsolete, removal required

[Boyuan Yang]

X-Debbugs-CC: tak...@debian.or.jp

Since this package hasn't been taken care of for at least 4 years (actually 9
years), I will submit the removal bug now.

Takaya: If you have any thoughts or doubts, please let me know *immediately*.

-- 
Best Regards,
Boyuan Yang

On Sun, 27 Aug 2017 11:13:31 +0500 Lev Lamberov  wrote:
> Package: anything-el
> Severity: grave
> 
> Dear Maintainer,
> 
> the last upload of the package in question was in Nov 2014 (version
> 1.287-2.1), which was a NMU upload, but the last maintainer's upload was
> in Mar 2011 (version 1.287-2). Since then upstream renamed anything-el
> [0] to helm and released 2.8.2 in Aug 2017 [1]. Moreover, since
> anything-el was not maintained for a long time, helm was packaged
> separately in Feb 2016 using new dh-elpa infrastructure, and currently
> is team-maintained by pkg-emacsen [2].
> 
> The anything-el package is heavily outdated (as the indication in its
> source code says it is tested only with Emacs 22/23, where there's Emacs
> 25 in stretch, and Emacs 24 will be removed from the archive soon),
> don't use the modern Emacs addons infrastructure. Since according to
> popcon there are some (47) users of the package [3], it should become a
> transitional dummy package, which should depend on elpa-helm, and after
> some time should be removed from Debian. Alternative approach would be
> to remove anything-el, and build transitional dummy package from helm
> source package to allow migrations.
> 
> Cheers!
> Lev Lamberov
> 
> [0] https://www.emacswiki.org/emacs/Anything
> 
> [1] https://github.com/emacs-helm/helm
> 
> [2] https://tracker.debian.org/pkg/helm
> 
> [3] https://qa.debian.org/popcon.php?package=anything-el
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8),
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> 


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

Bug#958723: ninja-build: ninja -t browse broken due to upstream bug; patch available

[luke]

Package: ninja-build
Version: 1.10.0-1
Severity: important
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

   `ninja -t browse` fails with a python backtrace due to a python2/3 bug
   upstream whereby `cgi.quote` was removed from python3.8 and causes
   downstreams using 3.8 to crash.

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

 I rebuilt ninja from source after applying the recent upstream fix, and
 ninja now appears to work correctly.

I suspect that backporting the upstream patch in 4d744de should be sufficient
without needing to wait for the upstream stable release which includes it.

All the Best

Luke


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

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

Versions of packages ninja-build depends on:
ii  libc6   2.30-4
ii  libstdc++6  10-20200418-1

ninja-build recommends no packages.

Versions of packages ninja-build suggests:
ii  python3  3.8.2-3

-- no debconf information

Bug#943287: tcpwatch-httpproxy: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Wed, Oct 23, 2019 at 02:33:34AM +, mo...@debian.org wrote:
> Source: tcpwatch-httpproxy
> Version: 1.3.1-3
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests (the specific reason can be found searching this
> source package in
> https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ).
> Please stop using Python2, and fix this issue by one of the following
> actions.

tcpwatch seems dead upstream, are you planning to port it to Python 3
yourself or should it be removed?

Cheers,
Moritz

Bug#958722: grub-efi-amd64-signed - Uninstallable

[Steve McIntyre]

Hey Bastian,

This is already fixed in the latest 2.04-7 grub2 upload. I'll mark
this closed when the signing service pulls stuff through.

On Fri, Apr 24, 2020 at 07:58:26PM +0200, Bastian Blank wrote:
>Package: grub-efi-amd64-signed
>Version: 1+2.04+5
>Severity: grave
>
>grub-efi-amd64-signed got a strict = dependency on grub-common, but
>those packages are from different source packages.  This makes this
>package uninstallable.
>
>| The following information may help to resolve the situation:
>| 
>| The following packages have unmet dependencies:
>|  grub-efi-amd64-signed : Depends: grub-common (= 2.04-6) but it is not going 
>to be installed
>| E: Unable to correct problems, you have held broken packages.
>
>Please fix this by removing those strict dependency or move both
>packages into a single source package.

You know we can't have it all in a single source package, right?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead

Bug#958725: Suggests python-nautilus

[Moritz Muehlenhoff]

Source: tilix
Severity: normal

tilix suggests python-nautilus for the shipped Nautilus extension.
The python-nautilus source package dropped the Python 2 package, so
either the Suggests: should point to python3-nautilus (if the extension
is Py3 compatible) or the Suggests: and the extension removed.

Cheers,
Moritz

Bug#958698: geary: Erratic high CPU load

[Alberto Garcia]

On Fri, Apr 24, 2020 at 08:00:03PM +0200, Matthias Brennwald wrote:
> >> I am observing periods of high CPU loads with Geary. The computer
> >> runs hot, with high fan noise. This seems to occurr erratically;
> >> I could not figure out how to trigger this.
> >
> >Hello, this might be bug #956837.
> >
> >I just uploaded webkit2gtk 2.28.2-1, which should hopefully fix it.
> >
> >Please give it a try and tell me if the problem goes away.
> >
> I don't understand... what exactly do you want me to do?

Install libwebkit2gtk-4.0-37 2.28.2-1 and see if it fixes the Geary
problem.

Berto

Bug#873057: Still not fixed !

[Jean Tourrilhes]

It's really annoying to have to remember to restart manually ntpd after
each reboot. timesyncd is 5 seconds off for me, so ntpd is the only option.
Obviously half the time I forget to restart ntpd and things get out of sync
across my servers.
I obviously can reproduce this systematically on many servers.

This is how it looks after startup :
$ systemctl status ntp.service systemd-timesyncd.service
● ntp.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset:
enab
   Active: inactive (dead)
 Docs: man:ntpd(8)

● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled;
vendo
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
   └─disable-with-time-daemon.conf
   Active: inactive (dead)
Condition: start condition failed at Fri 2020-04-24 10:57:43 PDT; 2min 19s
ago
   └─ ConditionFileIsExecutable=!/usr/sbin/ntpd was not met
 Docs: man:systemd-timesyncd.service(8)

What extra info is needed for this bug ?

Jean

Bug#958724: Suggests python-nautilus

[Moritz Muehlenhoff]

Package: kdeconnect
Severity: normal

kdeconnect suggests python-nautilus for the shipped Nautilus extension.
The python-nautilus source package dropped the Python 2 package, so
either the Suggests: should point to python3-nautilus (if the extension
is Py3 compatible) or the Suggests: and the extension removed.

Cheers,
Moritz

Bug#958550: ispell-fo: non utf-8 filename in source

[Agustin Martin]

El vie., 24 abr. 2020 a las 15:51, Ivo De Decker () escribió:
>  From /srv/upload.debian.org/queued/run/log on usper.debian.org:
>
> Apr 23 23:12:22 processing /ispell-fo_0.4.2+repack1-1_source.changes
> Apr 23 23:12:22 GnuPG signature check failed on
> ispell-fo_0.4.2+repack1-1_source.changes
> Apr 23 23:12:22 /ispell-fo_0.4.2+repack1-1_source.changes has bad
> PGP/GnuPG signature!
> Apr 23 23:12:22 Removing /ispell-fo_0.4.2+repack1-1_source.changes, but
> keeping its associated files for now.
> Apr 24 13:37:42 processing /ispell-fo_0.4.2+repack1-1_source.changes
> Apr 24 13:37:42 GnuPG signature check failed on
> ispell-fo_0.4.2+repack1-1_source.changes
> Apr 24 13:37:42 /ispell-fo_0.4.2+repack1-1_source.changes has bad
> PGP/GnuPG signature!
> Apr 24 13:37:42 Removing /ispell-fo_0.4.2+repack1-1_source.changes, but
> keeping its associated files for now.
>
> So something must have gone wrong with the signature.

Thanks for the info, not having received a mail about that still surprises me.

Seems I was hit by debsign using first available key instead of using
gpg default setting. And in this box I had an outdated signature,
which was used . Updated from keyrings so it is set as expired as it
should.

R4egards,

-- 
Agustin

Bug#958719: RFS: libcyaml/1.0.2-2 -- library to read and write YAML documents (shared library)

[Andrej Shadura]

Hi,

On Fri, 24 Apr 2020, 19:21 Sudip Mukherjee, 
wrote:

> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-CC: andre...@debian.org
>
> Dear mentors,
>
> I am looking for a sponsor for my package "libcyaml"
>
>  * Package name: libcyaml
>Version : 1.0.2-2
>Upstream Author : Michael Drake 
>  * URL : https://github.com/tlsa/libcyaml
>  * License : ISC
>  * Vcs : https://github.com/sudipm-mukherjee/libcyaml
>Section : libs
>
> It builds those binary packages:
>
>   libcyaml1 - library to read and write YAML documents (shared library)
>   libcyaml-dev - library to read and write YAML documents (development
> files)
>   libcyaml-doc - documentation for libcyaml1
>
> To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/libcyaml
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x
> https://mentors.debian.net/debian/pool/main/libc/libcyaml/libcyaml_1.0.2-2.dsc
>
> Changes since the last upload:
>
>* Fix copyright year.
>* Add debian/watch file.
>

I will sponsor it.

-- 
Cheers,
  Andrej

>

Bug#958698: geary: Erratic high CPU load

[Matthias Brennwald]

On Fr, 24 Apr, 2020 at 16:16, Alberto Garcia  wrote:

On Fri, Apr 24, 2020 at 02:38:53PM +0200, Matthias Brennwald wrote:

 I am observing periods of high CPU loads with Geary. The computer
 runs hot, with high fan noise. This seems to occurr erratically; I
 could not figure out how to trigger this.


Hello, this might be bug #956837.

I just uploaded webkit2gtk 2.28.2-1, which should hopefully fix it.

Please give it a try and tell me if the problem goes away.

Berto


I don't understand... what exactly do you want me to do?

Bug#958722: grub-efi-amd64-signed - Uninstallable

[Bastian Blank]

Package: grub-efi-amd64-signed
Version: 1+2.04+5
Severity: grave

grub-efi-amd64-signed got a strict = dependency on grub-common, but
those packages are from different source packages.  This makes this
package uninstallable.

| The following information may help to resolve the situation:
| 
| The following packages have unmet dependencies:
|  grub-efi-amd64-signed : Depends: grub-common (= 2.04-6) but it is not going 
to be installed
| E: Unable to correct problems, you have held broken packages.

Please fix this by removing those strict dependency or move both
packages into a single source package.

Bastian


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

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

Bug#871312: dh-systemd: please drop transitional package dh-systemd

[Holger Levsen]

On Fri, Apr 24, 2020 at 07:49:36PM +0200, Niels Thykier wrote:
> Excellent! Thanks for doing this. :)

indeed so! :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#958451: ausweisapp2: gets stuck when using service "Arbeitnehmer online"

[Jürgen Bausa]

Dear Adrian,

ok, I understand. I will try to find out which version of the QML platform 
module is offered by Buster. And then try to change the requirement in 
Ausweisapp2.

However, I am wondering why the second bug report on this problem disappeared. 
I think it would be good to keep at least one of this two bug reports (or 
merge them) with an explanation. This would help all people who try to use the 
backport.

Jürgen

Am Freitag, 24. April 2020, 09:09:01 CEST schrieb John Paul Adrian Glaubitz:
> Control: forcemerge -1 958190
> Control: found -1 1.20.0-2~bpo10+1
> Control: notfound -1  1.20.0-2
> Control: retitle -1 ausweisapp2: Fails to start because QML platform module
> is too old
> On 4/24/20 8:50 AM, Jürgen Bausa wrote:
> > Maybe its a problem with the version? Ausweisapp2 asks for 1.1. But how do
> > I know, which version is provided by the debian package? qt version is
> > 5.12.5 but I thinks that doesnt help.
> 
> I assume that the QML platform module on stable is simply too old and I'm
> afraid there is not much we can do about this as updating the platform
> module would involve updating all of Qt.
> 
> You could ask the Qt maintainers if they have an idea how to address this
> but I don't think there is. The only possible solution I see is when
> upstream reduces their version requirement from 1.1 to 1.0.
> 
> Please note, while I gladly try to support the package on stable, backports
> packages are not officially supported, so we can't take the full extent of
> measures to address this problem.
> 
> Adrian

Bug#871312: dh-systemd: please drop transitional package dh-systemd

[Niels Thykier]

Michael Biebl:
> Am 23.04.20 um 16:22 schrieb Niels Thykier:
>> Michael Biebl:
> 
>>> Wdyt, should I do a MBF (severity important, properly usertagged)?
>>> This list looks rather manageable to me that we might even get rid of it
>>> for bullseye. I'd review the list in a couple of months and possibly
>>> raise the bugs to RC once the package is dropped (or would you consider
>>> that too "pushy"?)
> 
>> That would be fine with me if you are up for a MBF. :)
> 
> I've done this now, see
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=dh-systemd-removal
> 
> I decided to start with severity normal, intend to bump that to
> important in 2 months and after that we'll see how many packages are left.
> 
> Regards,
> Michael
> 

Excellent! Thanks for doing this. :)

~Niels

Bug#958721: perlbug and github

[Niko Tyni]

Package: perl
Version: 5.28.1-6
Severity: normal
Tags: buster fixed-upstream
Forwarded: https://github.com/Perl/perl5/issues/17197
Control: found -1 5.30.0-10

The upstream tool to submit bug reports, /usr/bin/perlbug, does not
currently work as advertised since upstream has moved from rt.perl.org
to github.com/Perl/perl5 . It send the report to the old bug submission
address perl...@perl.org, which (I believe) nowadays gives an autoresponse
suggesting to file a GitHub issue instead.

Upstream has recently addressed this: 5.30.2 has

 https://github.com/Perl/perl5/commit/b9e2183386fadc0979b46e024365ceab56a369aa

removing references to perlbug, and upcoming 5.31.11 will have

 https://github.com/Perl/perl5/commit/31fa749cfc50ff7f2bde2237bf6da5547efd53d4

which modifies the perlbug tool to save its output to a file and direct
users to the GitHub issue tracker. The upstream issue at

 https://github.com/Perl/perl5/issues/17197

has the full discussion.

While I expect this will be fixed in Debian bullseye by upgrading to 5.32,
we should probably do something about stable too.
-- 
Niko Tyni   nt...@debian.org

Bug#958720: [Pkg-phototools-devel] Bug#958720: darktable: Error at start - free(): invalid next size (fast)

[David Bremner]

Ronny Bachmann  writes:

> Package: darktable
> Version: 3.0.2-1
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
> The problem exists since the update to the version 3.0.2-1
>

What version are you updating from?

d

Bug#958563: ITP: shellescape -- Escape arbitrary strings for use as command line arguments

[Bradford Boyle]

On Fri, Apr 24, 2020 at 4:55 AM Paul Wise  wrote:
>
> On Thu, Apr 23, 2020 at 6:54 PM Bradford D. Boyle wrote:
>
> > This package is needed for barnard
>
> It would be a lot better to make barnard use the Go exec functions
> instead of using this module:
>
> https://golang.org/pkg/os/exec/
>

Thanks for taking a look at this so quickly. I am not overly familiar
with the upstream package (barnard), but I think I understand your
comment, but I wanted to check first: It looks like it currently is
using `exec.Command` to call `/bin/sh` that is being passed the result
of the shellescaped string. Instead of passing through `sh`, just use
`exec.Command` on the string directly?

Assuming I've understood correctly, would you recommend including this
change as a patch in the package for now? Or should I try to get
upstream to incorporate the patch first?

Thanks,

-- Bradford

Bug#958666: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team

[Felix Lechner]

Hi,

On Fri, Apr 24, 2020 at 10:24 AM Chris Lamb  wrote:
>
> in order to spare this boilerplate within the Med team.

Wouldn't it be better to lower the severity for scripts shipped by
upstream (vs the maintainer)?

Kind regards
Felix Lechner

Bug#958666: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team

[Chris Lamb]

[replacing lintian-ma...@debian.org → 958...@bugs.debian.org]

Andreas Tille wrote:

> > This was already done in:
[…]
> Not really (as Gregor pointed out since Info is also on the radar).

I've just marked the tag as "experimental". This has the same
practical effect of it being removed.

> To give another example where we are using a "team wide"
> lintian-override:
[…]
> I admit I *personally* *really* hate this since I think I perfectly
> subscribe all those good reasons to not add language extensions. 

I share your dislike. Please file a separate wishlist bug for this — I
would certainly entertain arguments to add logic to Lintian in order
to spare this boilerplate within the Med team.


Regards,

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

Bug#958720: darktable: Error at start - free(): invalid next size (fast)

[Ronny Bachmann]

Package: darktable
Version: 3.0.2-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

The problem exists since the update to the version 3.0.2-1

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

Darktable aborts at startup with the following error message:

[defaults] found a 64-bit system with 16363216 kb ram and 4 cores (0 atom
based)
[defaults] setting high quality defaults
free(): invalid next size (fast)
Aborted

If I delete the old configuration, the program can be started:

[defaults] found a 64-bit system with 16363216 kb ram and 4 cores (0 atom
based)
[defaults] setting high quality defaults

Then I select a directory with .raw images. Loading on the light table aborts
Darktable with the following error message:

* On-the-fly history V[1]->V[2], imageid: 9 
   0 flip multi  0 :: iop 20,001 -> 20,000
   1basecurve multi  0 :: iop 23,001 -> 23,000
   2  temperature multi  0 :: iop  3,001 ->  3,000
   3   highlights multi  0 :: iop  4,001 ->  4,000
   4 demosaic multi  0 :: iop  8,001 ->  8,000
   5   denoiseprofile multi  0 :: iop 10,001 -> 10,000
   6 exposure multi  0 :: iop 12,001 -> 12,000
   7 lens multi  0 :: iop 15,001 -> 15,000
   8 flip multi  0 :: iop 20,001 -> 20,000
   9 clipping multi  0 :: iop 21,001 -> 21,000
  10basecurve multi  0 :: iop 23,001 -> 23,000
  11 colorreconstruct multi  0 :: iop 28,001 -> 28,000
  12 defringe multi  0 :: iop 30,001 -> 30,000
  13   shadhi multi  0 :: iop 40,001 -> 40,000
  14bilat multi  0 :: iop 42,001 -> 42,000
  15   colisa multi  0 :: iop 47,001 -> 47,000
  16  sharpen multi  0 :: iop 53,001 -> 53,000
  17   velvia multi  0 :: iop 63,001 -> 63,000
free(): invalid next size (fast)
Aborted

I use a current Debian testing
uname -r
5.5.0-2-amd64

Graphics Processor: GeForce GTX 1070

What other information is required?

Regards, Ronny



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

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

Versions of packages darktable depends on:
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libcolord-gtk1   0.1.26-2
ii  libcolord2   1.4.4-2
ii  libcups2 2.3.1-11
ii  libcurl3-gnutls  7.68.0-1
ii  libexiv2-27  0.27.2-8
ii  libgcc-s110-20200418-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libglib2.0-0 2.64.2-1
ii  libgomp1 10-20200418-1
ii  libgphoto2-6 2.5.24-1
ii  libgphoto2-port122.5.24-1
ii  libgraphicsmagick-q16-3  1.4+really1.3.35-1
ii  libgtk-3-0   3.24.18-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjs-prototype  1.7.1-3
ii  libjs-scriptaculous  1.9.0-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  liblcms2-2   2.9-4+b1
ii  liblensfun1  20190119-1
ii  liblua5.3-0  5.3.3-1.1+b1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.1-1
ii  libosmgpsmap-1.0-1   1.1.0-6
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpng16-16  1.6.37-2
ii  libpugixml1v51.10-1
ii  librsvg2-2   2.48.2-1
ii  libsecret-1-00.20.2-1
ii  libsoup2.4-1 2.70.0-1
ii  libsqlite3-0 3.31.1-4
ii  libstdc++6   10-20200418-1
ii  libtiff5 4.1.0+git191117-2
ii  libwebp6 0.6.1-2+b1
ii  libx11-6 2:1.6.9-2
ii  libxml2  2.9.10+dfsg-5
ii  libxrandr2   2:1.5.1-1
ii  zlib1g   1:1.2.11.dfsg-2

darktable recommends no packages.

darktable suggests no packages.

-- no debconf information

Bug#958719: RFS: libcyaml/1.0.2-2 -- library to read and write YAML documents (shared library)

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: andre...@debian.org

Dear mentors,

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

 * Package name: libcyaml
   Version : 1.0.2-2
   Upstream Author : Michael Drake 
 * URL : https://github.com/tlsa/libcyaml
 * License : ISC
 * Vcs : https://github.com/sudipm-mukherjee/libcyaml
   Section : libs

It builds those binary packages:

  libcyaml1 - library to read and write YAML documents (shared library)
  libcyaml-dev - library to read and write YAML documents (development files)
  libcyaml-doc - documentation for libcyaml1

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libc/libcyaml/libcyaml_1.0.2-2.dsc

Changes since the last upload:

   * Fix copyright year.
   * Add debian/watch file.


-- 
Regards
Sudip

Bug#729851: ITP: ibus-typing-booster -- A completion input method

[Gunnar Hjalmarsson]

Being unaware of this bug, I submitted  
and proposed this package:


https://mentors.debian.net/package/ibus-typing-booster

It's in the NEW queue now.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#940833: ssh-audit: Project seems to be dead upstream but forked at https://github.com/jtesta/ssh-audit

[Joseph S. Testa II]

I'm the maintainer of the new fork 
(https://github.com/jtesta/ssh-audit/).  I would very much like for 
Debian to switch away from the dead original project and move to my 
updated version.


Since taking over development in August 2019, I've made 139 commits 
across 4 releases, including on PyPI, Snap, Arch Linux, and Homebrew. 
Some highlights of new features include: RSA host key checking, RSA 
certificate key checking, Diffie-Hellman modulus checking, fingerprint 
enumeration, JSON output, client security testing, and support for 83(!) 
new algorithms.


If you try running the original v1.7.0 against modern SSH servers 
(including OpenSSH 8.2), you'll get incomplete results due to missing 
algorithms.  My v2.2.0 is fully current, however.


I've tried reaching out to the official maintainer, ChangZhuo Chen, a 
couple times over the last 7 months but have not received a response. 
How can we move forward on our own?


   Thanks!
   - Joe

--
Joseph S. Testa II
Founder & Principal Security Consultant
Positron Security

Bug#958718: lightdm: tight loop trying to start greeter about 85 hours after starting lightdm

[Greg Klanderman]

Package: lightdm
Version: 1.26.0-7
Severity: important

Dear Maintainer,

Around 85 hours after restarting the lightdm service, it goes into a very tight
loop creating greeter sessions which fail immediately.  It is attempting to
start a greeter session 30-50 times per second, filling up
/var/log/lightdm/lightdm.log with Gb of log lines and using significant CPU.

Bugs 895983 and 910050 seem related but not exactly the same.

I have 2 seats configured.

Here is a log excerpt of the first time this happened after the most recent
restart; this sequence then repeats 30-50 times per second:

[+308685.52s] DEBUG: Seat seat-1: Creating greeter session
[+308685.56s] DEBUG: Seat seat-1: Creating display server of type x
[+308685.58s] DEBUG: Seat seat-1: Starting local X display
[+308685.58s] DEBUG: XServer 3: Logging to /var/log/lightdm/x-3.log
[+308685.58s] DEBUG: XServer 3: Writing X server authority to 
/var/run/lightdm/root/:3
[+308685.58s] DEBUG: XServer 3: Launching X Server
[+308685.59s] DEBUG: Launching process 1548921: /usr/bin/X :3 -seat seat-1 
-auth /var/run/lightdm/root/:3 -nolisten tcp
[+308685.59s] DEBUG: XServer 3: Waiting for ready signal from X server :3
[+308685.73s] DEBUG: Seat seat-1: Switching to existing greeter
[+308685.73s] DEBUG: Locking login1 session 2548
[+308685.96s] DEBUG: Process 1548921 exited with return value 1
[+308685.96s] DEBUG: XServer 3: X server stopped
[+308685.96s] DEBUG: XServer 3: Removing X server authority 
/var/run/lightdm/root/:3
[+308685.96s] DEBUG: Seat seat-1: Display server stopped
[+308685.96s] DEBUG: Seat seat-1: Stopping session
[+308685.96s] DEBUG: Seat seat-1: Session stopped
[+308685.96s] DEBUG: Seat seat-1: Stopping display server, no sessions require 
it
[+308685.98s] DEBUG: Seat seat-1: Active display server stopped, starting 
greeter

Errors shown in /var/log/Xorg.3.log:

[111628.803] (EE) systemd-logind: failed to get session: PID 2119345 does not 
belong to any known session
[111628.808] (II) xfree86: Adding drm device (/dev/dri/card0)
[111628.809] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: 
Permission denied
...
[111628.818] (EE) AMDGPU(0): [drm] failed to set drm interface version.
...
[111628.818] (EE) Screen 0 deleted because of no matching config section.
[111628.818] (II) UnloadModule: "amdgpu"
[111628.818] (EE) Screen 0 deleted because of no matching config section.
[111628.818] (II) UnloadModule: "modesetting"
[111628.818] (EE) Fatal server error:
[111628.818] (EE) Cannot run in framebuffer mode. Please specify busIDs
for all framebuffer devices
[111628.818] (EE)
[111628.818] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[111628.818] (EE) Please also check the log file at "/var/log/Xorg.3.log" for 
additional information.
[111628.818] (EE)
[111628.819] (EE) Server terminated with error (1). Closing log file.


I have attached a longer sample of /var/log/lightdm/lightdm.log, starting from
lightdm being restarted through the beginning of the tight loop trying to start
greeter sessions.  I have also attached a complete /var/log/Xorg.3.log.

I am having to restart lightdm every few days to keep this under control: it is
creating Gb of log, and using a lot of CPU so I have rated severity important.

thank you,
Greg




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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.16-2
ii  debconf [debconf-2.0]  1.5.74
ii  libaudit1  1:2.8.5-3+b1
ii  libc6  2.30-4
ii  libgcrypt201.8.5-5
ii  libglib2.0-0   2.64.2-1
ii  libpam-systemd [logind]245.4-3
ii  libpam0g   1.3.1-5
ii  libxcb11.14-2
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.7-1
ii  lsb-base   11.1.0

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+20

Versions of packages lightdm suggests:
ii  accountsservice  0.6.55-1
ii  upower   0.99.11-1
ii  xserver-xephyr   2:1.20.8-2

-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm
[+0.48s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.48s] DEBUG: Starting Light Display Manager 1.26.0, UID=0 PID=1451096

Bug#958666: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning

[Scott Kitterman]

On Friday, April 24, 2020 12:08:46 PM EDT Shengjing Zhu wrote:
> On Fri, Apr 24, 2020 at 11:44 PM gregor herrmann  wrote:
> [...]
> 
> > > Could this wiki page be more useful?
> > > https://wiki.debian.org/Salsa/AliothMigration#Import_mailing_list
> > 
> > Not really; the lists we are talking about _are_ migrated to
> > alioth-lists.debian.net which will continue to accept mail for
> > @lists.alioth.debian.org.
> > And like Andreas, I see no point in changing the mail addresses in
> > thousands of packages and various tools and parts of infrastructure.
> 
> So your expectation is alioth-lists.d.n will become a long term service.
> 
> However I read  the announcement[1] 2 years ago differently.
> 
> [1] https://lists.debian.org/debian-devel-announce/2018/01/msg3.html
> 
> > This is not intended to supercede the advice to make use of other
> 
> services where appropriate, such as lists.debian.org for eligible
> lists, tracker.debian.org or salsa, but does enable other lists
> such as package team maintenance lists, to have a home in _the
> short term_
> 
> Also it writes,
> 
> > The service will be reviewed for viability and
> 
> usefulness after one release cycle
> 
> I'm not sure how the one release cycle is counted.
> We have released buster since then. And we are close to bullseye now.
> 
> Probably it's time to start thinking about this.

True, but this is useless as a lintian check.  Packaging teams need to decide 
what they are going to do and then migrate.  There's nothing individual 
packages (or package maintainers) can do except decide to remove their package 
from team maintenance to 'fix' this issue.  That's not what we want.

In the Python Applications Packaging Team we've already had multiple package 
uploaded with the wrong address that have had to be fixed in new uploads.  This 
test is not just pointless, it's actively harmful.

Lintian checks need to be actionable by the package maintainer and this one is 
not.

Scott K


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

Bug#958666: known bad addresses Re: lintian

[Rebecca N. Palmer]

gregor herrmann wrote:

This link and the whole check would be helpful only for not-migrated
alioth lists which don't work anymore but I guess lintian has no
chance to make this discrimination.


Lintian already has a list of individual known-bad addresses 
(data/fields/bounce-addresses, tags *-causes-mail-loops-or-bounces), 
though it doesn't seem to be much used (it currently contains only one 
address).

Bug#958717: ITP: designate-tempest-plugin -- OpenStack Integration Test Suite - Designate plugin

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: designate-tempest-plugin
  Version : 0.8.0
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/openstack/designate-tempest-plugin
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack Integration Test Suite - Designate plugin

 Tempest is a set of integration tests to be run against a live Openstack
 cluster in order to make sure that all components are working as expected.
 Tempest will start and stop virtual machine in order to check that your
 cloud is working as expected.
 .
 This package contains the Designate plugin.