Bug#972243: option to download *all* binary packagesg

[Harald Dunkel]

On 10/20/20 1:36 PM, Julian Andres Klode wrote:

On Tue, Oct 20, 2020 at 01:30:29PM +0200, Harald Dunkel wrote:


???


Like we say in German: Satzzeichen sind keine Rudeltiere. A paragraph
of 3 question marks is fairly bad etiquette.



Sorry, no offense. I see this "???" as some kind of smiley to express
my perplexity.

Bug#308856: We'd have to check with Guenther

[Joerg Dorchain]

On Thu, 17 Oct 2013 22:54:27 +0200 "Stephen R. van den Berg"
 wrote:
> Guenther did the LMTP support.  I vaguely recall discussing this same 
> issue with him once before.  I'd guess that it mostly was/is the fact 
> that for a new release *with* LMTP support, you'd need to do some more 
> checks again, and he ran out of time/steam before those could be performed.
> 
> After fixing/incorporating the essential bugs, I'll take another look at 
> the state of the LMTP support.  I Cc'd Guenther, maybe he can shed light 
> on how sound the support has been tested/thought through.  I'm not sure 
> this email address of his is still valid though.
> 
> 
Any news on this?

I am in the situation that I would really appreaciate lmtp support in
procmail.

Thanks for considering a new release with the patch (experimental would
be fine.)

Bye,

Joerg

Bug#972596: kmail: FTBFS on armhf: #5: akonadi-sqlite-kmcommandstest .........................***Failed

[Adrian Bunk]

Control: retitle -1 kmail: archivemailwidgettest hangs on armhf/mipsel

On Tue, Oct 20, 2020 at 11:26:59PM +0200, Sebastian Ramacher wrote:
> Source: kmail
> Version: 4:20.08.2-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
>..
> |   Start  5: akonadi-sqlite-kmcommandstest
> |  5/27 Test  #5: akonadi-sqlite-kmcommandstest 
> .***Failed0.07 sec
> | org.kde.pim.akonaditest: Started akonadi daemon with pid: 0
> | org.kde.pim.akonaditest: Failed to start Akonadi server!

Test failures are ignored so this is "fine",
and this test fails on all architectures.


> See 
> https://buildd.debian.org/status/fetch.php?pkg=kmail&arch=armhf&ver=4%3A20.08.2-2&stamp=1603221672&raw=0

The actual problem is:

...
  Start 21: archivemailwidgettest
E: Build killed with signal TERM after 150 minutes of inactivity


In Ubuntu this was "solved" by no longer running the tests.

Since tests are failing on all architectures and that is already ignored, 
there are anyways only limited benefits in running the tests at all.


> Cheers

cu
Adrian

Bug#968918: Threshold function is extremely slow - Unusable - possible regression

[debian-testing]

Yes, the mageMagick issue #1819 
(https://github.com/ImageMagick/ImageMagick/issues/1819) discusses performance 
also.  See the following quotes:  "...the dithering step takes so long that I 
haven't had the patience to let it finish yet...", "...Not sure why it is doing 
very slow dithering...", "...The IM developers will have to look into the slow 
dithering..."

What version of gscan2pdf and imagemagick are you using to reproduce the 
problem?  It has to be recent versions on Debian 11 and the scan or image also 
needs to be 600dpi (300 dpi is fast).

I can still reproduce it on a fresh install done today:

apt search gscan2pdf
gscan2pdf/testing,now 2.9.1-1 all ...

apt search imagemagick
imagemagick/testing,now 8:6.9.11.24+dfsg-1+b1 amd64 ...


Steps to reproduce, even without a scanner:
GIMP > File > New
Change "px" to "in"
Set Width: 8.5" Height: 11"
Advanced > Set X & Y resolution to 600 "pixels/in"
Click OK
File > Export As: "Untitled.jpg"
Leave all other settings on their defaults

gscan2pdf > File > Open: "Untitled.jpg"
Tools > Threshold > 50%
Takes very long, eg 2 minutes.

Tools > User-defined > "mogrify -threshold 50% %i"  (manually configured 
previously)
Take about 3 seconds.

Threshold was working normally before.




Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday, September 4, 2020 5:14 PM, Jeff  wrote:

> Thanks for the report.
>
> https://github.com/ImageMagick/ImageMagick/issues/1819
>
> doesn't mention performance problems, just corruption in the image.
>
> I can't reproduce your problem. The threshold tool works fine for me
> with or without conversion to PNG first.
>
> Please start gscan2pdf from the command line with the --log=log option,
> reproduce the problem, quit, and post the log file, which gscan2pdf
> should have compressed to log.xz.

Bug#972608: [uscan] Support monorepo organizations

[Julien Puydt]

Package: devscripts
Version: 2.20.4
Severity: wishlist

It would be nice to provide support for monorepo organizations, which
means a single git repository, with many directories and many tags.
I'll use as an example along this report a typical project using this
scheme, lumino: https://github.com/jupyterlab/lumino/ .

The subprojects are basically each a single directory, and the tags
describe the versions of those independently of one another ; for
luminowhere the tags have the format @lumino/@:

- a tag guarantees a stable version for a single subproject : for the
other subprojects, the same commit can be unusable ;

- a single version number can be common to several subprojects, but not
correspond to the same commit.

I tried various things to get things working, but to no avail : I
managed to get single-subproject going, but for two-subprojects, things
worked when I took some combinations of subprojects (algorithm and
coreutils), and failed with others (algorithm and application). After
some poking around, I noticed which commits gave the last versions :

algorithm 159c46252870a27e85766520b42e4d4f378a0913
application 443967554e00d43a42f989157c5185b83bccab09
coreutils 159c46252870a27e85766520b42e4d4f378a0913

It worked when both subprojects wanted the same commit!

Indeed, the current uscan, as far as I understand, makes a single
(bare) checkout under a name lumino-temporary..git where number
is time-based. So the first subproject triggers a checkout for a
particular commit, and when the second subproject kicks in, it finds
the directory already there and errors out. The fact that it's still
there is probably a combination of it not being removed (reported as
#972585) and the fact that if the first step is fast enough, the time-
based number is the same, and the second step finds an already-there
directory under the same name.

If this interpretation is correct, fixing #972585 should already
improve matters as there will be no more collisions ; but we'll still
need as many checkouts as there are subprojects, which is a bit much
(for lumino, 18 packages and 1 example means 19 subprojects - more to
come if I get more examples to run!).

Cheers,

JP

Bug#972563: android needs it

[Hans-Christoph Steiner]

When using the upstream build system, the Android Tools and SDK are 
built as one giant, statically linked source package.  The Debian 
Android Tools Team aims to use existing Debian packages whenever 
possible, instead of using upstream's all-in-one build system.  To 
achieve this, we link against what is available.  We happily use proper 
shared libraries when available.

Bug#961559: pcmanfm: Rename folder in left side pane directory tree crashes pcmanfm

[Réal Carbonneau]

Yes, in both Debian 10 and 11, changing the setting from "Close tab
containing removable medium" to "Change folder in the tab to Home
Folder" does not close the window, but instead, ejects the user back to
the Home Folder.

However, this behaviour is still incorrect and unacceptable for many
reasons:
1) This occurs on any folder, regardless if it is on a removable media
or not.
2) The user may be deep in the directory tree and it will frustrate the
user to either close the window or send the user back to the Home
folder after a simple rename.
3) The user may right-click > rename a folder in the left "Directory
Tree" pane without actually navigating to the contents of the folder,
so again, there is no reason to eject the user from the current
context.
4) The F2 key does not work for a rename on the left "Directory Tree"
pane, so maybe the intent was not to permit the rename.  


Expected behaviour: 

a) Either rename should work in the left "Directory Tree" pane without
changing the user's navigation location (NO ejectecting out NOR to the
Home).  AND make F2 also rename

OR

b) Completely remove the possibility to rename a folder in the left
"Directory Tree" pane.

-- 
Kind regards,
Réal

On Wed, 2020-10-21 at 01:13 +0300, Andriy Grytsenko wrote:
> Well, in case if it just exits then probably path in main window
> became
> invalid and therefore window was closed.
> 
> Please, look in the settings, what is your choice on the option 'When
> removable medium unmounted:'? Is it 'Close tab containing removable
> medium' probably? It yes then try to change it to 'Change folder in
> the
> tab to Home Folder', please. Your issue might be gone after that.


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

Bug#972607: ITP: pdns-logger -- PowerDNS protobuf logger

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: pdns-logger
  Version : 0.0.2
  Upstream Author : Denis Machard 
* URL or Web page : https://github.com/dmachard/pdns_logger
* License : MIT (yes, "MIT" as in https://spdx.org/licenses/MIT;
there is no Expat on https://spdx.org/licenses/)
  Programming Lang: Python
  Description : PowerDNS protobuf logger

PDNS logger is a daemon or commandline tool written in Python 3 that
provides a protobuf log receiver for PowerDNS's products.

You can use it to collect DNS queries and responses and to log to
syslog or a json remote tcp collector.

WIP packaging is available at
https://salsa.debian.org/debian/pdns-logger

Bug#971839: libinput-bin: Non-functional internal Keyboard on Acer E5-511 laptop under Xorg

[Matt Roberds]

This report is just for documentation, and to get a possibly-related
model number to show up in web searches.

This problem may also affect the Acer ES1-511 laptop.  It is similar to
the E5-511 mentioned here, but with a slower CPU and a smaller hard disk.

I have an ES1-511, and the keyboard and touchpad stopped working under
X.  Even though I had an older version of libinput (1.12.6), which did
not understand the ModelTabletModeSwitchUnreliable quirk, the change
suggested in this bug *partially* fixed it; the keyboard started working
but the touchpad did not.

What fixed it for good for me was blacklisting the "Intel Virtual Button
driver" in udev.  This made both the keyboard and touchpad work under X.

I posted to debian-user 
https://lists.debian.org/debian-user/2020/10/msg00530.html
and someone there linked me to this post on the Arch user forum
https://bbs.archlinux.org/viewtopic.php?pid=1925437#p1925437
which details the udev fix I used.

Thanks!

Matt Roberds

Bug#972606: plasma-workspace FTFBS: cmake error / some missing dependency

[Norbert Preining]

Hi

On Wed, 21 Oct 2020, Helmut Grohne wrote:
> | -- Could NOT find KF5KDELibs4Support (found version "5.74.0"), checked the 
> following files:
> | 
> /usr/lib/x86_64-linux-gnu/cmake/KF5KDELibs4Support/KF5KDELibs4SupportConfig.cmake
>  (version 5.74.0)
> | Reason given by package: KF5KDELibs4Support could not be found because 
> dependency KF5ItemModels could not be found.

Ahh, that is the same error I reported recently on IRC, it seems that
the kdelibs4support -dev package needs more Depends.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#972437: debian-reference: mentions no longer existing packages

[肖盛文]

在 2020/10/21 上午2:54, Holger Wansing 写道:

Hi,

xiao sheng wen (肖盛文)  wrote:

在 2020/10/19 下午10:57, Holger Wansing 写道:

We should better remove the whole content about those packages, right?

It's a easy way to fix this bug.

It is of no use for Debian users anyway, if they no longer can install the
corresponding packages.

In stable, the Debian user can install some packages come from oldstable.

In oldstable, the Debian user also can install some packages come from
stable.

Of course, as an experienced user/developer you can do everything.
But that is not the scope of this document.


As one reference  manual book, keep more info is valued.

For example:

One experienced user can know the way of that install old package from 
oldstable,


but he perhaps didn't  know  the package ldm.


The knowledge about Debian is very wide scope.




The oldstable still has many Debian user use it.


There are package has the state like:  in oldstable, not in stable, not
in testing.

But perhaps some day, this package can into testing again.

Is this package need to remove?


(If they still have the packages installed, let's say on an oldstable
system, then they should read the debian-reference for *oldstable*.)

The debian-reference is also publish on the www.debian.org, It's for all Debian 
OS Release version(Debian 9,10,11, etc,.).

No, I think this is not correct.
In common.ent you find the definition, what is the current stable, or the
current testing.
That way, every version of the debian-reference has its target releases
(stable, testing), for what it matches.


common.ent is only record the current state of Debian releases.

Although the deb package of debian-reference is static in Debian stable 
releases,


but debian-reference also has public to www.debian.org, the content can 
dynamic update in need.


And the most people find the  debian-reference in the website, It's the 
major way.




IMO it makes it unnecessarily complicated, if you want to keep the content
valid for all Debian releases.
If things change, you would be forced to say "you find that in file xxxyyy,
if you are running Jessie, or in file abcdef, if you are running Buster.
And we are planning to change that again for Bullseye".

And there is no need for such logic: if you want to find how the situation
was for an old Debian release, you can always look in an old version of
the debian-reference. It's always there.


There is only one version of the debian-reference in d.o now.

If split it for different target releases (stable, testing) in d.o, 
perhaps is a better way, I'm not sure.


In this bug, "NOT_FOUND" only find in pkgsize.ent,

It affect the  package to display the pkgsize, the patch can fix it, 
it's not very complicated.






Holger


--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x339240CB

Bug#972606: plasma-workspace FTFBS: cmake error / some missing dependency

[Helmut Grohne]

Source: plasma-workspace
Version: 4:5.17.5-4
Severity: serious
Tags: ftbfs

plasma-workspace fails to build from source in unstable The issue is
fairly recent as neither reproducible builds nor crossqa have run into
it yet:

| -- Could NOT find KF5KDELibs4Support (found version "5.74.0"), checked the 
following files:
| 
/usr/lib/x86_64-linux-gnu/cmake/KF5KDELibs4Support/KF5KDELibs4SupportConfig.cmake
 (version 5.74.0)
| Reason given by package: KF5KDELibs4Support could not be found because 
dependency KF5ItemModels could not be found.
| 
| -- Found KF5Crash: 
/usr/lib/x86_64-linux-gnu/cmake/KF5Crash/KF5CrashConfig.cmake (found version 
"5.74.0") 
| -- Found KF5GlobalAccel: 
/usr/lib/x86_64-linux-gnu/cmake/KF5GlobalAccel/KF5GlobalAccelConfig.cmake 
(found version "5.74.0") 
| -- Found KF5DBusAddons: 
/usr/lib/x86_64-linux-gnu/cmake/KF5DBusAddons/KF5DBusAddonsConfig.cmake (found 
version "5.74.0") 
| -- Found KF5Wayland: 
/usr/lib/x86_64-linux-gnu/cmake/KF5Wayland/KF5WaylandConfig.cmake (found 
version "5.74.0") 
| -- Found KF5CoreAddons: 
/usr/lib/x86_64-linux-gnu/cmake/KF5CoreAddons/KF5CoreAddonsConfig.cmake (found 
version "5.74.0") 
| -- Found KF5People: 
/usr/lib/x86_64-linux-gnu/cmake/KF5People/KF5PeopleConfig.cmake (found version 
"5.74.0") 
| -- Found KF5ActivitiesStats: 
/usr/lib/x86_64-linux-gnu/cmake/KF5ActivitiesStats/KF5ActivitiesStatsConfig.cmake
 (found version "5.74.0") 
| CMake Error at 
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
|   Could NOT find KF5 (missing: KDELibs4Support) (found suitable version
|   "5.74.0", minimum required is "5.62.0")
| Call Stack (most recent call first):
|   /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 
(_FPHSA_FAILURE_MESSAGE)
|   /usr/share/ECM/find-modules/FindKF5.cmake:94 
(find_package_handle_standard_args)
|   CMakeLists.txt:26 (find_package)
| 
| 
| -- Configuring incomplete, errors occurred!
| See also "/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeOutput.log".

I suspect that adding libkf5itemmodels-dev somewhere in the dependency
chain fixes this.

Helmut

Bug#972605: jekyll: Please update to new 4.x branch

[Calum McConnell]

Package: jekyll
Severity: minor
X-Debbugs-Cc: calumlikesapple...@gmail.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Jekyll upstream has been concentrating on a new 4.x release branch for the past 
year.  It provides a significant set of new features that I use, and it would 
be great if it could be included in debian.

I assume you know all of that already, since 3.9 released after 4.0, but I was 
wondering what the rationale was for sticking with the 3.x branch.

Thanks!

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

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

Versions of packages jekyll depends on:
ii  ruby1:2.7+1
pn  ruby-addressable
ii  ruby-bundler2.1.4-2
pn  ruby-classifier-reborn  
pn  ruby-coderay
ii  ruby-colorator  1.1.0-3
pn  ruby-em-websocket   
pn  ruby-i18n   
pn  ruby-jekyll-sass-converter  
pn  ruby-jekyll-watch   
pn  ruby-kramdown   
pn  ruby-kramdown-parser-gfm
pn  ruby-liquid 
pn  ruby-mercenary  
pn  ruby-mime-types 
pn  ruby-pathutil   
pn  ruby-pygments.rb
pn  ruby-rdiscount  
pn  ruby-redcarpet  
pn  ruby-rouge  
pn  ruby-safe-yaml  
pn  ruby-tomlrb 
pn  ruby-yajl   
ii  xdg-utils   1.1.3-2

jekyll recommends no packages.

Versions of packages jekyll suggests:
pn  jekyll-theme-minima 
pn  ruby-jekyll-avatar  
pn  ruby-jekyll-coffeescript
pn  ruby-jekyll-compose 
pn  ruby-jekyll-feed
pn  ruby-jekyll-gist
pn  ruby-jekyll-last-modified-at
pn  ruby-jekyll-mentions
pn  ruby-jekyll-paginate | ruby-jekyll-paginate-v2  
pn  ruby-jekyll-redirect-from   
pn  ruby-jekyll-remote-theme
pn  ruby-jekyll-seo-tag 
pn  ruby-jekyll-sitemap 

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAl+Pq/AdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzItIA/+KZO6m0SPfb3V9ben
g/MgKDRH1ooEoWpQoHfX+/fRKo1rOmF/GsmhA2S02Ce8saLZXwXoGRqqCemdINcA
5D3cyvJjoBf6rERLUPXyawrJ8aVIstLR7VBZEn4NFBNv7KvLeXrMXyR6xem9i77C
fR6E0ar6jz8WVek2ulIZvsnKsVjnOxFx+LEL2tGWLL3Vf3G0Scoydr59uVSPhURH
XoxtL7JXmJBrvY1Phv4PG83T5PPBphs22HMCVAQXjpDkX4H3yE9RAMK7I/18dtqf
8CkfPxQszmHHBth64Pq4vsC6znJvI3yAofmy2maxF29vK5nNQja5oJNPig7K3J31
sufw9d2aoMPY0YhBo3MGkUla22eTxqI8eVIwinl3+iUEyYbgyBIn9PId4COYe4P9
R1ZhmT7xKwGqPY0X7iQeTeEGF/5wdXmmiOMkPymMLrjXcaSLcbCH3x0uQ28zt86u
W4suvYIWwu8yZr91K92oLTq+jwKRTKsWNGyFJKE4D4+0BnwqnBiCjNSwp5E3fT/g
iv95ST6YXUnqfq6nKL0aTCYstxMOGLf8sVO6JfrKFAqlEfErGGdG90yARB9NLJ6e
Gtkf6HIOjW3mC0X1c1CuD2jwsaLuz+7z5DUrkc1ucdXFxGFhpO2kE8PMjXfxq7Z2
cb0Tj5ykxULdJkHj+k9msevEWec=
=gxzn
-END PGP SIGNATURE-

Bug#972604: lmfit-py: tests fail with Python 3.9

[Michael Hudson-Doyle]

Source: lmfit-py
Version: 1.0.1-2
Severity: normal
Tags: upstream
User: debian-pyt...@lists.debian.org
Usertags: python3.9
Forwarded-To: https://github.com/lmfit/lmfit-py/issues/674

Dear Maintainer,

I thought that updating asteval to the latest release might fix this but
it did not.

Cheers,
mwh

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

Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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

Bug#972536: fpc: the old version 3.0.4+dfsg-23 still in sid

[肖盛文]

HI Paul,

    Thanks for your replay.

Perhaps the newer version of fpc upload to sid in next time, this old 
version 3.0.4+dfsg-23 would automatically removed.


Let us wait for some times.

Xiao

在 2020/10/21 上午1:51, Paul Gevers 写道:

HI Xiao,

On 20-10-2020 03:58, xiao sheng wen wrote:

Source: fpc
Version: 3.0.4+dfsg-23
Severity: minor

Dear Maintainer,

   The newest verison of fpc is 3.2.0+dfsg-8, now is in the testing.
   But the old version 3.0.4+dfsg-23 is still in sid.
   Is need to remove old version from sid?

Removal is the domain of ftp masters. Normally, packages that aren't
needed are automatically removed. This sometimes fails, but normally
means that there is something that keeps it in the archive. E.g. because
of Built-Using (which I suspect here, but forgot how to check).

Paul


--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x339240CB

Bug#972603: seqan: Needs update for new googletest

[Steve M. Robbins]

Source: seqan
Severity: normal

Dear Maintainer,

Hi,

Just uploaded a newer googletest and seqan is reporting autopkgtest failures.  
However, at least some failures appear to be due to changes in googletest that 
require
adapting the test code.  For example, the following [from 
https://ci.debian.net/data/autopkgtest/testing/amd64/s/seqan3/7629025/log.gz]


Type parameterized test suite alphabet is defined via 
REGISTER_TYPED_TEST_SUITE_P, but never instantiated via 
INSTANTIATE_TYPED_TEST_SUITE_P. None of the test cases will run.

Ideally, TYPED_TEST_P definitions should only ever be included as part of 
binaries that intend to use them. (As opposed to, for example, being placed in 
a library that may be linked in to get other utilities.)

To suppress this error for this test suite, insert the following line (in a 
non-header) in the namespace it is definedin in:

GTEST_ALLOW_UNINSTANTIATED_PARAMETERIZED_TEST(alphabet);




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

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

Bug#971515: kubernetes: excessive vendoring (private libraries)

[Felix Lechner]

Hi Dmitry,

On Tue, Oct 20, 2020 at 5:24 PM Dmitry Smirnov  wrote:
>
> Let's not attempt to fabricate perception of consensus please.

Consensus is a worthy goal and perhaps even possible, per below.

> We favour technical elegance
> often in expense of maintainers' comfort.

Is our approach really either one of those? I think our response to
the vendoring explosion is at odds with the trends in many languages.

It's time to retool. At the two ends of the solution spectrum, I see

1. Fully vendored source packages; or
2. A packaging system that allows different vendor versions to co-exist.

Either one allows dependent sources to consume whichever versions they
require, but in my view solution (2) is otherwise superior---provided
that the packaging process is automated. (A language's build system
also has to distinguish the installed versions.) For each language so
affected, could we make (2) our goal, and allow (1) until then?

Kind regards
Felix Lechner

Bug#972513: u-boot-tools: build with CONFIG_FIT_SIGNATURE=y

[Vagrant Cascadian]

On 2020-10-19, Luca Boccassi wrote:
> The FTP team revised their guidance related to OpenSSL linkage. It is
> now considered a "system library", so it is now allowed to dynamically
> link a GPL binary to libssl:
>
> http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html
> https://salsa.debian.org/ftp-team/website/-/merge_requests/6
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972181

Wow, this is a big surprise!

Now we seem to have the absence of documentation about the issue, which
seems a bit odd... given that this has been an issue in Debian for so
long.


> Please consider removing the override of CONFIG_FIT_SIGNATURE in
> debian/rules to get signature supports in u-boot tools.
>
> MR opened on Salsa:
>
> https://salsa.debian.org/debian/u-boot/-/merge_requests/14

Thanks for the proposed update!


Because the system library exception for GPL+openssl seems like a
strange workaround to me... I did give a short attempt at switching
u-boot over to wolfssl using the openssl compatibility layer, though it
still needs a bit too much work to make the change at this point.


Eventually I'll probably just merge your proposed changes...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#972602: python-asteval: tests not run during build

[Michael Hudson-Doyle]

On Wed, 21 Oct 2020 at 13:48, Michael Hudson-Doyle 
wrote:

>
> This also makes the build fail in sid because Python 3.9 is now a
> supported version but I think an upstream update will fix that.
>

It does.


> While I'm here, the git repository in Vcs-Git does not exist.
>

I've just applied (slightly accidentally ;-p) to join the science team on
salsa so if you let me in, I can fix all of this :) (I'll probably mostly
work on Python version transitions)

Cheers,
mwh

Bug#972602: python-asteval: tests not run during build

[Michael Hudson-Doyle]

Source: python-asteval
Version: 0.9.17-2
Severity: normal
Tags: patch

Dear Maintainer,

The test suite is not run during build. Patch attached.

This also makes the build fail in sid because Python 3.9 is now a
supported version but I think an upstream update will fix that.

While I'm here, the git repository in Vcs-Git does not exist.

Cheers,
mwh

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

Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
diff -Nru python-asteval-0.9.17/debian/changelog 
python-asteval-0.9.17/debian/changelog
--- python-asteval-0.9.17/debian/changelog  2019-11-19 22:33:25.0 
+1300
+++ python-asteval-0.9.17/debian/changelog  2020-10-21 13:27:44.0 
+1300
@@ -1,3 +1,9 @@
+python-asteval (0.9.17-2) UNRELEASED; urgency=medium
+
+  * d/rules: set PYBUILD_TEST_PYTEST so tests are actually run during build. 
+
+ -- Michael Hudson-Doyle   Wed, 21 Oct 2020 13:27:44 +1300
+
 python-asteval (0.9.17-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-asteval-0.9.17/debian/control 
python-asteval-0.9.17/debian/control
--- python-asteval-0.9.17/debian/control2019-11-19 22:33:25.0 
+1300
+++ python-asteval-0.9.17/debian/control2020-10-21 13:27:44.0 
+1300
@@ -7,6 +7,7 @@
 Build-Depends: debhelper (>= 11),
dh-python,
python3-all,
+   python3-pytest,
python3-setuptools,
python3-six
 Standards-Version: 4.4.1
diff -Nru python-asteval-0.9.17/debian/rules python-asteval-0.9.17/debian/rules
--- python-asteval-0.9.17/debian/rules  2019-11-19 22:33:25.0 +1300
+++ python-asteval-0.9.17/debian/rules  2020-10-21 13:26:40.0 +1300
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export PYBUILD_NAME=asteval
+export PYBUILD_TEST_PYTEST=1
 
 %:
dh $@ --with python3 --buildsystem=pybuild

Bug#972174: s3fs segfault

[Noah Meyerhans]

Would you like me to go ahead and upload my backport to
buster-backports?  The debdiff against the bullseye version is trivial
(see attached).  Having it available in the archive would be helpful to
me.

Thanks.
noah

diff -Nru s3fs-fuse-1.87/debian/changelog s3fs-fuse-1.87/debian/changelog
--- s3fs-fuse-1.87/debian/changelog 2020-08-11 00:38:23.0 -0700
+++ s3fs-fuse-1.87/debian/changelog 2020-10-15 10:40:33.0 -0700
@@ -1,3 +1,9 @@
+s3fs-fuse (1.87-1~bpo10+1) buster-backports; urgency=medium
+
+  * Rebuild for buster-backports.
+
+ -- Noah Meyerhans   Thu, 15 Oct 2020 10:40:33 -0700
+
 s3fs-fuse (1.87-1) unstable; urgency=medium
 
   * New upstream release 1.87.  LP: #1891124

Bug#971515: kubernetes: excessive vendoring (private libraries)

[Dmitry Smirnov]

On Wednesday, 21 October 2020 6:16:03 AM AEDT Sean Whitton wrote:
> I think that my message [1] is what makes you think that the package
> would not have got through NEW?

It was not your message but my own experience with introducing of 100+ 
packages through NEW, especially those ones with large burden of vendored 
libraries, including Kubernetes. The main hassle usually is to convince FTP-
masters when some vendoring is _necessary_ (case by case) and the usual 
request is to package all vendored libraries separately. With rare exceptions 
some (few) vendored libraries are allowed like when a library is a fork, 
customised for the particular project and therefore not re-usable by other 
software. Another example is when vendored library is an obsolete software 
phasing out in future releases. Few micro-libraries might be tolerated when 
vendored, especially when they are not widely used. Also vendoring might be 
acceptable when software components with mutual/circular dependencies are 
shipped in one or several name spaces - in other words when a software code 
base is not from one name space but from several. None of those cases applies 
to Kubernetes.

A specific example (libpod/podman) is mentioned in 

  https://lists.debian.org/debian-devel/2020/03/msg00441.html

"Podman was rejected due to "many embedded packages in vendor/" with only
 6 or 7 private libs versus 120 libraries removed in favour of packaged
 ones."


> There are a few issues tangled together here.

IMHO it is really one issue of how we maintain Debian packages. If you want 
to distinguish few issues then they are all closely related.


> NEW is mainly about license and DFSG compliance, and secondarily about
> the idea that we want to avoid accepting packages where doing so would
> make Debian worse, even if it would also make Debian better along other
> dimensions.  As a simple example, we try to avoid accepting a package
> that is already packaged under a slightly different name, because in
> most cases it is worse for both users and contributors to have the same
> thing in the archive twice (not talking about vendoring here).

It is also about preserving integrity of Debian identity. We try to prevent 
monolithic bundles like Kubernetes in favour of maintaining ecosystem of re-
usable libraries, packaged individually.


> In this case, the reason I wrote in [1] that I would probably have
> rejected the package, had I come across it in NEW, is that it seemed to
> me that having this package in Debian would make the archive less
> maintainable by contributors other than Janos who might need to work
> with the package.  (After the discussion on -devel, I'm no longer so
> sure about that opinion of mine.)

  https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code

If your concern is about security support then IMHO Kubernetes can not be 
meaningfully supported from security prospective, with or without vendored 
dependencies.

Also I must point out that Kubernetes upstream have the worst management of 
vendored libraries that I have ever seen. Examples include vendoring multiple 
versions of the same library, etc.
A particular case when upstream failed to update a problematic vendored 
library for years(!) practically destroys faith in upstream care for good 
hygiene of vendored dependencies:

  https://github.com/kubernetes/kubernetes/issues/27543

Note the expressed _resistance_ to upgrading a vendored library...

With the above example, how can anyone have confidence in upstream security 
patching? After all Kubernetes have more vendored code than its own.



> It's not correct to say, however, that the package "is in violation of
> ftpmaster's policy for inclusion of new packages".  That could only be
> true is if the package met one of the "serious violations" listed in the
> REJECT-FAQ, which is basically DFSG and licensing issues, and a few
> obvious clangers.  Instead, what we have is a situation in which there
> is reason to be worried about the way the package is put together, but
> the opinion of one FTP team member at one particular point in time
> carries about the same weight as the opinion of any experienced
> packager.

There is an established practice, a tradition if you wish, that is followed 
all the time even if not explicitly described in REJECT-FAQ. Debian clearly
tries to be modular whenever possible.


> In other words, I suggest that we ignore the NEW issue entirely, and
> just consider whether the way the package is currently put together
> imposes an unreasonable burden on Debian contributors other than Janos
> who want to work on the package, or users who want to patch it, etc.
> The sorts of questions we should try to answer:
> 
> - does the vendoring make Debian security support harder (discussion on
>   -devel suggests it makes it easier)
> 
> - everyone seems to think the level of vendoring is at best a necessary
>   evil;

Let's not attempt to fabricate perception of consensus

Bug#972197: subversion b-d's on python3-all-dev, but only builds for the default python3 version

[James McCoy]

On Wed, Oct 14, 2020 at 10:22:50AM +0200, Matthias Klose wrote:
> subversion b-d's on python3-all-dev, but only builds for the default python3
> version.

It actually builds for all available versions, but the install is
broken.  This used to work with Python 2.x.

It looks like the difference is that

  python$$v -c 'from distutils import sysconfig; 
print(sysconfig.get_python_lib())'

no longer returns a version-specific path.  When installing the Python
bindings, that means we install all versions to the same path and they
overwrite each other.

Was this an intentional change?  If so, I guess I'll need to emulate
aspects of pybuild to handle this.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#972437: debian-reference: mentions no longer existing packages

[Holger Wansing]

Hi,

xiao sheng wen (肖盛文)  wrote:
> 
> 在 2020/10/19 下午10:57, Holger Wansing 写道:
> > We should better remove the whole content about those packages, right?
> It's a easy way to fix this bug.
> > It is of no use for Debian users anyway, if they no longer can install the
> > corresponding packages.
> 
> In stable, the Debian user can install some packages come from oldstable.
> 
> In oldstable, the Debian user also can install some packages come from 
> stable.

Of course, as an experienced user/developer you can do everything.
But that is not the scope of this document.

> The oldstable still has many Debian user use it.
> 
> 
> There are package has the state like:  in oldstable, not in stable, not 
> in testing.
> 
> But perhaps some day, this package can into testing again.
> 
> Is this package need to remove?
> 
> > (If they still have the packages installed, let's say on an oldstable
> > system, then they should read the debian-reference for *oldstable*.)
> 
> The debian-reference is also publish on the www.debian.org, It's for all 
> Debian OS Release version(Debian 9,10,11, etc,.).

No, I think this is not correct.
In common.ent you find the definition, what is the current stable, or the
current testing.
That way, every version of the debian-reference has its target releases
(stable, testing), for what it matches.

IMO it makes it unnecessarily complicated, if you want to keep the content
valid for all Debian releases.
If things change, you would be forced to say "you find that in file xxxyyy,
if you are running Jessie, or in file abcdef, if you are running Buster.
And we are planning to change that again for Bullseye".

And there is no need for such logic: if you want to find how the situation
was for an old Debian release, you can always look in an old version of
the debian-reference. It's always there.


Holger


> >
> > Regarding your patch:
> >> @@ -73,6 +73,8 @@ CODE :=  sid
> >>   ARCH :=  amd64
> >>   UDEBA:=  $(DEBM)/$(CODE)
> >>   UDEBB:=  $(DEBM)/experimental
> >> +UDEBC :=  $(DEBM)/buster
> >> +UDEBD :=  $(DEBM)/stretch
> >>   DR_VERSION :=$(shell dpkg-parsechangelog --show-field Version)
> > Those 'buster' and 'stretch' lines are error-prone, since they get outdated
> > with the next release. We should not add hard-coded release-names, there are
> > already too much cases existing with such hard-coded values (Debian-wide,
> > not just in the debian-reference).
> 
> Yes, hard-coded release-names there are error-prone.
> 
> Thanks for your remind, I'll update to use stable, oldstable later.
> 
> >
> >
> > Holger
> 
> -- 
> 肖盛文 xiao sheng wen Faris Xiao
> 微信(wechat)：atzlinux
> 《铜豌豆 Linux》
> 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
> Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
> GnuPG Public Key: 0x339240CB
> 


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#972601: Acknowledgement (application tracking broken in GNOME Shell)

[Michael Biebl]

I notice the following:

# grep StartupWMClass
/usr/share/applications/net.thunderbird.Thunderbird.desktop
StartupWMClass=Thunderbird

So, either change that to StartupWMClass=thunderbird or update
thunderbird to report Thunderbird as StartupWMClass X property.

Michael

Bug#972601: application tracking broken in GNOME Shell

[Michael Biebl]

Package: thunderbird
Version: 1:78.3.3-1
Severity: important

Hi,

thunderbird renamed the desktop file from
thunderbird.desktop to net.thunderbird.Thunderbird.desktop

This change broke application tracking in gnome-shell as
it is no longer able to match the process to the desktop file.

If you run xprop | grep CLASS, you'll see
WM_CLASS(STRING) = "Mail", "thunderbird"

So gnome-shell is looking for a desktop file named thunderbird.desktop.

For comparison, nautilus:
xprop | grep CLASS
WM_CLASS(STRING) = "org.gnome.Nautilus", "Org.gnome.Nautilus"

Please either rename the desktop file or make sure the WM_CLASS name
matches the desktop file name. Another possibility is to specificy
StartupWMClass in the desktop file.

See https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS
https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased



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

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

Versions of packages thunderbird depends on:
ii  debianutils 4.11.2
ii  fontconfig  2.13.1-4.2
ii  libatk1.0-0 2.36.0-2
ii  libbotan-2-15   2.15.0+dfsg-2+b1
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-4
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.20-1
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.12-stable-1
ii  libffi7 3.3-4
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-3
ii  libgcc-s1   10.2.0-15
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libglib2.0-02.66.1-2
ii  libgtk-3-0  3.24.23-2
ii  libicu6767.1-4
ii  libjson-c5  0.15-1
ii  libnspr42:4.28-1
ii  libnss3 2:3.56-1
ii  libpango-1.0-0  1.46.2-1
ii  libstdc++6  10.2.0-15
ii  libvpx6 1.8.2-1
ii  libx11-62:1.6.12-1
ii  libx11-xcb1 2:1.6.12-1
ii  libxcb-shm0 1.14-2
ii  libxcb1 1.14-2
ii  libxext62:1.3.3-1+b2
ii  libxrender1 1:0.9.10-1
ii  psmisc  23.3-1
ii  x11-utils   7.7+5
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-de-de [hunspell-dictionary]  20161207-8
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.4-3+b1
ii  fonts-lyx 2.3.5.2-1
ii  libgssapi-krb5-2  1.17-10
ii  libgtk2.0-0   2.24.32-4

-- no debconf information

Bug#972598: pgcli: Broken dependencies render package unusable

[Matthew Gabeler-Lee]

Package: pgcli
Version: 3.0.0-1
Followup-For: Bug #972598

Quick addenda:

1) Verified that downgrading python3-humanize indeed works around this issue.

2) Upstream looks like they've worked around this by no longer using humanize:
   
https://github.com/dbcli/pgcli/commit/8f7e31450835bca5d9a8bb4de252efba6f4b7b10
   Unfortunately it looks like the replacement for it they're using is not
   available in Debian :(

Bug#860763: imagemagick: /etc/imagemagick-6/policy.xml useless limits settings

[Matt Roberds]

Hello all!

I just wanted to note that bug 941724 is probably related to this one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941724

Also:

Edmund Christian Herenz  wrote:

So from what I understand by reading this bugreport is that there is a
workaround by removing the memory rule in
/etc/ImageMagick-6/policy.xml - but this file might be overwritten by
an security upgrade, right?


If a security update wants to replace that file, the installer *should*
detect that you have modified the policy.xml file, and ask you what to
do (keep your file, install new file, etc).

Thanks!

Matt Roberds

Bug#961559: pcmanfm: Rename folder in left side pane directory tree crashes pcmanfm

[Andriy Grytsenko]

Well, in case if it just exits then probably path in main window became
invalid and therefore window was closed.

Please, look in the settings, what is your choice on the option 'When
removable medium unmounted:'? Is it 'Close tab containing removable
medium' probably? It yes then try to change it to 'Change folder in the
tab to Home Folder', please. Your issue might be gone after that.

Bug#972600: Drop the Budgie exception

[Gunnar Hjalmarsson]

Package: src:im-config
Version: 0.45-1

When we worked with the im-config code a couple of months ago, I found 
issues with Budgie's IBus support which made me suggest an exception 
from the GNOME exception meaning that we didn't change the im-config 
behavior for Budgie even if the XDG_CURRENT_DESKTOP variable includes 
"GNOME" in the list. It was this commit:


https://salsa.debian.org/input-method-team/im-config/-/commit/38989f89

However, I have just tested the Budgie Desktop on an updated Debian 
testing as well as Ubuntu Budgie 20.10, and it seems that the IBus 
integration now works as intended. All you need to do is adding the 
Keyboard Layout applet in Budgie Desktop Settings, and then switching 
between input sources works fine with both XKB and IBus input sources.


Budgie includes code for starting and configuring IBus just like GNOME 
does. So as far as I can tell, we should better drop the Budgie 
exception in im-config and leave the launching/configuration to the 
desktop as we do for GNOME.


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

Bug#941724: imagemagick: underuses available resources (memory, disk space)

[Matt Roberds]

Package: imagemagick-6-common
Version: 8:6.9.7.4+dfsg-11+deb9u10
Followup-For: Bug #941724

Hello all!

I agree with this suggestion.  I was trying to figure out why
ImageMagick performed slowly on my machine, and I came across this bug.

To give some numbers, the desktop machine I'm writing this on is about
10 years old, with a 2.9 GHz dual-core processor, 4 GB RAM, and 1 TB
rotating hard drive.  On this system:


ImageMagick 6 with the default policy.xml:

---
$ time convert -size 5100x6600 xc:red red.pnm

real0m1.952s
user0m0.192s
sys 0m0.628s

$ time convert red.pnm red.png

real0m11.310s
user0m1.136s
sys 0m0.768s
---

The total wall-clock time is 13.262 sec.


ImageMagick 6 with *no* policy.xml at all:

---
$ time convert -size 5100x6600 xc:red red.pnm

real0m0.670s
user0m0.168s
sys 0m0.480s

$ time convert red.pnm red.png

real0m1.318s
user0m1.036s
sys 0m0.380s
---

The total wall-clock time is 1.988 sec, for about a 6.7x (!!!)
improvement.

The other details on this desktop system from reportbug are below.

I also tried the same tests on a laptop I have that runs Debian 10, with
a 2.16 GHz dual-core CPU, 4 GB RAM, and a 500 GB rotating hard drive.

On that machine, with the default policy.xml, the two operations above
took 9.340 sec of wall-clock time.  With *no* policy.xml, the same
operations took 5.750 sec, or about a 1.6x improvement.

Also, bug 860763 is probably related to this one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860763

Thanks!

Matt Roberds


-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
compare:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
convert:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
composite:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
conjure:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
display:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
identify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
import:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
mogrify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
montage:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
stream:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org

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

Kernel: Linux 4.9.0-13-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages imagemagick depends on:
ii  imagemagick-6.q16  8:6.9.7.4+dfsg-11+deb9u10

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information

Bug#972599: RFS: streamlink/1.7.0+dfsg-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 1.7.0.

 * Package name: streamlink
   Version : 1.7.0+dfsg-1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.7.0+dfsg-1.dsc

Changes since the last upload to unstable:
streamlink (1.7.0+dfsg-1) unstable; urgency=medium

  * New upstream version 1.7.0+dfsg
  * Update patches

 -- Alexis Murzeau   Tue, 20 Oct 2020 23:59:16 +0200



Regards,
- -- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F








-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEylfM0qe98o7UCRlrC5n5Lou0ZU0FAl+PYCUACgkQC5n5Lou0
ZU2RpQ/+IX6SGC66+lBVoFvzQXqkhhAp884iv65CAfzx/2CAXSUGHEC8vG+YM74m
Fb1GPYE/LlY7oR4KAqHbn+dsSRLctRZCJ+y+BsxFcdpVhBwmuyuw+RTyiVKGC0Hi
zvzmtVFT+VB+F4tMS7FYGDgMetrILhKpBLyiTmLoQMDHnF0Fc5hjdvJV22lYvDwO
IMH65myj0tABlW7dinyyHWSrWTzORduANcc1G5sPR2DKDcT+HdgeImJVn+3iFDEU
0eXFzwW/RLfjLjtI9Bi4OJ2HIz9QvhIbpAL48bg/TwY1a6GR10Fn+Ww2VN+EHBy1
Q/zKNZW1N/YrUo9xP38wqH0B/r3/Yy3AOKps7MYl5uHT+N4Tj1/SVbhsx3rGbChu
jzzYCyAbXnBTmkGkiRPVS3WRABb9PehEo6qTsTvk+xro6p1asmjweq5oIQ4KwhOu
X1x1v1Xrv2p6rolLylSK8mhnrq+hX20c1QCgN3N3ABz4PHbEv07H8vj/SyVqQELx
wdUO0bvfNIkpoz4PFgnvgfomxpgC2V7fimXcOv+7dhEdeQrDS3q4AIPs7q9P4SKW
NUVhKZ/TCvVqgeqqutCKTRmxasVd4LKRxZ84iGCGPy/3nTdTfLh8LpyXOxWUF8GY
e3FxVU7PdZ7EoVkv1ECwat22646/4NpXuDqU8jcN4eGK5cBHSUw=
=kq1S
-END PGP SIGNATURE-

Bug#972598: pgcli: Broken dependencies render package unusable

[Matthew Gabeler-Lee]

Package: pgcli
Version: 3.0.0-1
Severity: important

Since the update of python3-humanize to 3.0.0, pgcli is now completely
broken. Even trying to run `pgcli --help` reports a runtime error about
missing dependencies:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 567, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 884, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 775, in 
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (humanize 0.0.0 
(/usr/lib/python3/dist-packages), Requirement.parse('humanize>=0.5.1'), 
{'pgcli'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/pgcli", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3239, 
in 
def _initialize_master_working_set():
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3222, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3251, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 569, in 
_build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 582, in 
_build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 770, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'humanize>=0.5.1' distribution was not 
found and is required by pgcli

Since python3-humanize _is_ installed, and was updated much more recently on
my system than pgcli itself, I'm guessing that the major version jump from
what pgcli expects to what's now in Debian is likely the problem (pgcli
wants 0.5.1-ish, Debian went from 2.6.0 to 3.0.0), but I'm not at all sure
of that.

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

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

Versions of packages pgcli depends on:
ii  python3 3.8.2-3
ii  python3-click   7.1.2-1
ii  python3-configobj   5.0.6-4
ii  python3-humanize3.0.1-1
ii  python3-pgspecial   1.11.10+dfsg1-1
ii  python3-pkg-resources   50.3.0-1
ii  python3-prompt-toolkit  3.0.8-1
ii  python3-psycopg22.8.5-1+b1
ii  python3-pygments2.3.1+dfsg-4
ii  python3-setproctitle1.1.10-3
ii  python3-sqlparse0.3.1-1
ii  python3-tabulate0.8.2-1.1
ii  python3-terminaltables  3.1.0-3

pgcli recommends no packages.

pgcli suggests no packages.

-- no debconf information

Bug#972597: PostgreSQL 13 transition

[Christoph Berg]

Package: glom
Version: 1.30.4-6
Severity: serious

Hi,

glom Build-Depends: postgresql-12. Please bump that to PostgreSQL 13.

Couldn't that be relaxed to just "postgresql" so I don't have to file
this bug each year again?

Thanks,
Christoph

Bug#972582: Its working!

[MrMine Toons]

So, installing the experimental packages it will work, but ITS
EXPERIMENTAL, i`m stable until now but u can have some problems, so be
careful!
add to sourcelist: deb http://deb.debian.org/debian experimental main
contrib non-free

Than run:
- sudo apt update
- apt -t experimental install nvidia-driver
At this moment, the experimental package is 455.23.04-1.
U can have a look here:
https://packages.debian.org/experimental/nvidia-driver

After installing, it should be working :)
If u dont want to use experimental packages, just wait it get out from
experimental!

Bye :D

Bug#972582: Acknowledgement (nvidia-kernel-dkms: The DKMS build fails with incompatible pointer types.)

[Nathanael Schweers]

I probably should have added that the aptitude output directed me to the
file /var/lib/dkms/nvidia-current/450.66/build/make.log.  I have placed
a copy of this file at https://pastebin.com/Xw6u7KtC

I hope this helps.

Best Regards,
Nathanael Schweers

Bug#972596: kmail: FTBFS on armhf: #5: akonadi-sqlite-kmcommandstest .........................***Failed

[Sebastian Ramacher]

Source: kmail
Version: 4:20.08.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

kmail failed to build on armhf:
| make[2]: Entering directory '/<>/obj-arm-linux-gnueabihf'
| Running tests...
| /usr/bin/ctest --force-new-ctest-process -j1
| Test project /<>/obj-arm-linux-gnueabihf
|   Start  1: displaymessageformatactionmenutest
|  1/27 Test  #1: displaymessageformatactionmenutest    
Passed1.48 sec
|   Start  2: cryptostateindicatorwidgettest
|  2/27 Test  #2: cryptostateindicatorwidgettest    
Passed1.22 sec
|   Start  3: kactionmenutransporttest
|  3/27 Test  #3: kactionmenutransporttest ..   
Passed1.11 sec
|   Start  4: akonadi-sqlite-tagselectdialogtest
|  4/27 Test  #4: akonadi-sqlite-tagselectdialogtest 
***Failed0.08 sec
| org.kde.pim.akonaditest: Started akonadi daemon with pid: 0
| org.kde.pim.akonaditest: Failed to start Akonadi server!
|
|   Start  5: akonadi-sqlite-kmcommandstest
|  5/27 Test  #5: akonadi-sqlite-kmcommandstest 
.***Failed0.07 sec
| org.kde.pim.akonaditest: Started akonadi daemon with pid: 0
| org.kde.pim.akonaditest: Failed to start Akonadi server!

See 
https://buildd.debian.org/status/fetch.php?pkg=kmail&arch=armhf&ver=4%3A20.08.2-2&stamp=1603221672&raw=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#972595: lintian: false positive unused-override on overrides disabled by negated arch lists

[Andreas Beckmann]

Package: lintian
Version: 2.94.0
Severity: important

Hi,

lintian 2.94.0 introduced a regression in the handling of negated arch lists.

These overrides:

== 8< ==
# The NVIDIA license does not allow any form of modification.
[!i386 !armhf]: spelling-error-in-binary
[!i386 !armhf]: hardening-no-bindnow
[!i386 !armhf]: hardening-no-fortify-functions
[!i386 !armhf]: hardening-no-relro

# On architectures no longer supported by the current driver,
# this is a dummy package depending on the 390xx legacy driver.
[i386 armhf]: transitional-package-not-oldlibs-optional
== >8 ==

now result in

I: xserver-xorg-video-nvidia: unused-override hardening-no-bindnow
I: xserver-xorg-video-nvidia: unused-override hardening-no-fortify-functions
I: xserver-xorg-video-nvidia: unused-override hardening-no-relro
I: xserver-xorg-video-nvidia: unused-override spelling-error-in-binary

on i386 and armhf.

This can be tested on xserver-xorg-video-nvidia_418.152.00-1_i386.deb,
i.e. the package from buster, but not sid (which has the transitional
packages removed).
(That uploaded package comes with an older version of the lintian overrides,
e.g. containing some renamed or removed tags, the pasted overrides above
have these fixed.)


Andreas

Bug#927076: any progress?

[Barak A. Pearlmutter]

Right, I made that salsa repo, it doesn't mean anything except having
a place to hang a hat.

The situation now is that the *only* sticking point is
debian/copyright, which is a mess. Note all the "god knows" entries.
And the providence of a bunch of the .svg files is unclear, with
internal copyright strings embedded in them giving various flavours of
CC. Some of which might need to be replaced if they're the wrong
flavours; fortunately there are collections of appropriate open source
.svg icons that could be used instead if it comes to that.

If someone were to help with getting the copyright info worked out, I
can slot it straight into Debian. But there were so many little moving
parts I just couldn't clear an entire day to try and figure it all
out. Someone more familiar with the code base and its history would
probably have a much easier time of it.

--Barak.

PS I'm using xournalpp in teaching this semester. Got a new Dell
Inspiron 15 7591 2in1 with a pressure sensitive pen enabled screen,
and it's great for remote teaching.

Bug#972582: nvidia-kernel-dkms: The DKMS build fails with incompatible pointer types.

[Nathanael Schweers]

Package: nvidia-kernel-dkms
Version: 450.66-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 I tried to install the nvidia-driver.  I had done so previously,
 but due to package conflicts on a full-upgrade I decided to remove
 and reinstall the package.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I removed every package relating to nvidia by issuing the following
 command: aptitude purge '~invidia'.  I tried to install the package
 'nvidia-driver', which in turn depends on 'nvidia-kernel-dkms'.  As
 the latter failed I also tried installing and reinstalling it
 separately, both with and without repeating the aforementioned
 purge command first.  I also waited for a few days in case a new
 fixed version would appear.
   * What was the outcome of this action?
   It resolved the previous (unrelated?) package conflict, yet it now
 leaves the system an nvidia graphics driver.
   * What outcome did you expect instead?
   I expected the package conflicts to be resolved and to have a working
 nvidia graphics driver again.

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

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

Versions of packages nvidia-kernel-dkms depends on:
ii  dkms   2.8.3-4
pn  nvidia-installer-cleanup   
pn  nvidia-kernel-support--v1  

Versions of packages nvidia-kernel-dkms recommends:
pn  nvidia-driver | libcuda1  

nvidia-kernel-dkms suggests no packages.

Bug#972594: ITS: tftp-hpa

[Romain Porte]

Package: tftp-hpa
Version: 5.2+20150808-1.2
Severity: important
X-Debbugs-Cc: deb...@microjoe.org
X-Debbugs-Cc: m...@qa.debian.org
X-Debbugs-Cc: car...@debian.org

Dear Maintainer,

I intent to salvage this package with your approval, or after the 21
days delay as mentioned in the developer guide:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-to-salvage-a-package

I have reworked the package locally to fix almost all lintian warnings,
moved format from 1.0 to 3.0 (quilt) and updated to the latest standards
version. I already did a previous NMU (on top of another NMU) that
fixed the IPv6 bugs. I received thanks from bug authors as it solved
their issues (and mine too).

I was originally trying to publish this big change as a NMU, but it
would make more sense to first adopt the package and then make a proper
-2 release instead of a 1.3 NMU.

Best regards,

Romain.

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

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

Versions of packages tftp-hpa depends on:
ii  libc6  2.31-3

tftp-hpa recommends no packages.

tftp-hpa suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#927076: any progress?

[Cédric Boutillier]

Hi,

I was wondering if there was any progress in the process of getting
xournalpp into Debian. I would be really happy to have it in the
official archive.

Oh, I see that your work, Barak, has been imported recently into the
Debian group on salsa:
https://salsa.debian.org/debian/xournalpp
although the last commit is 4 months old.
Are there any plans to upload it soon?

Thanks in advance


signature.asc
Description: PGP signature

Bug#972582: Same insue with nvidia-drivers

[MrMine Toons]

After run apt install nvidia-driver
I have the followings errors:

''Created symlink
/etc/systemd/system/multi-user.target.wants/nvidia-persistenced.
service → /lib/systemd/system/nvidia-persistenced.service.
Job for nvidia-persistenced.service failed because the control process
exited wi
th error code.
See "systemctl status nvidia-persistenced.service" and "journalctl -xe" for
deta
ils.
Setting up nvidia-egl-icd:amd64 (450.66-1) ...
Setting up nvidia-egl-icd:i386 (450.66-1) ...
Setting up nvidia-driver-libs:amd64 (450.66-1) ...
Setting up nvidia-driver-libs:i386 (450.66-1) ...
Processing triggers for nvidia-alternative (450.66-1) ...
update-alternatives: updating alternative /usr/lib/nvidia/current because
link g
roup nvidia has changed slave links
Setting up nvidia-kernel-dkms (450.66-1) ...
Loading new nvidia-current-450.66 DKMS files...
Building for 5.9.0-1-amd64
Building initial module for 5.9.0-1-amd64
Error! Bad return status for module build on kernel: 5.9.0-1-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/450.66/build/make.log for more
information.
dpkg: error processing package nvidia-kernel-dkms (--configure):
 installed nvidia-kernel-dkms package post-installation script subprocess
return
ed error exit status 10
dpkg: dependency problems prevent configuration of nvidia-driver:
 nvidia-driver depends on nvidia-kernel-dkms (= 450.66-1) |
nvidia-kernel-450.66
; however:
  Package nvidia-kernel-dkms is not configured yet.
  Package nvidia-kernel-450.66 is not installed.
  Package nvidia-kernel-dkms which provides nvidia-kernel-450.66 is not
configur
ed yet.

dpkg: error processing package nvidia-driver (--configure):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.31-4) ...
Processing triggers for initramfs-tools (0.139) ...
update-initramfs: Generating /boot/initrd.img-5.9.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/rkl_dmc_ver2_01.bin for
module i
915
Processing triggers for update-glx (1.2.0) ...
Processing triggers for glx-alternative-nvidia (1.2.0) ...
update-alternatives: using /usr/lib/nvidia to provide /usr/lib/glx (glx) in
auto
 mode
Processing triggers for glx-alternative-mesa (1.2.0) ...
Processing triggers for systemd (246.6-2) ...
Processing triggers for libc-bin (2.31-4) ...
Processing triggers for initramfs-tools (0.139) ...
update-initramfs: Generating /boot/initrd.img-5.9.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/rkl_dmc_ver2_01.bin for
module i
915
Errors were encountered while processing:
 nvidia-kernel-dkms
 nvidia-driver
E: Sub-process /usr/bin/dpkg returned an error code (1)''


I think its problem with the debian kernell 5.9.0 which I`m using actually,
the DKMS have some problem with this new kernel(I think so...)

Bug#972576: About virtual box do not work with new kernel drive

[MrMine Toons]

I tried to install the test build of virtualbox, exactly the
package VirtualBox-6.1.15-140899-Linux_amd64.run

After sudo ./VirtualBox-6.1.15-140899-Linux_amd64.run, it works fine!
I have tried with the version 6.1.16 in the mainpage, but it needs libvpx5,
which i do not have in bullseye-sid!
Thanks

Bug#972593: RFS: filezilla/3.51.0-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "filezilla":

 * Package name: filezilla
   Version : 3.51.0-1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : GPL-2+, BSD-like, permissive, MIT, CC0-1.0
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

  filezilla-common - Architecture independent files for filezilla
  filezilla - Full-featured graphical FTP/FTPS/SFTP client

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.51.0-1.dsc

Changes since the last upload:

 filezilla (3.51.0-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 3.51.0
   * Updated libfilezilla-dev versioned build-dep to 0.25.0

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#972586: freetype: CVE-2020-15999: buffer overflow in Load_SBit_Png

[Salvatore Bonaccorso]

Hi,

Prepared the update for release via buster-security, attached the
debdiff. https://salsa.debian.org/debian/freetype/-/merge_requests/2
contains as well the changes to be merged in the packaging repository.

Regards,
Salvatore
diff -Nru freetype-2.9.1/debian/changelog freetype-2.9.1/debian/changelog
--- freetype-2.9.1/debian/changelog 2019-07-27 15:19:28.0 +0200
+++ freetype-2.9.1/debian/changelog 2020-10-20 21:15:41.0 +0200
@@ -1,3 +1,10 @@
+freetype (2.9.1-3+deb10u2) buster-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Fix heap buffer overflow (CVE-2020-15999) (Closes: #972586)
+
+ -- Salvatore Bonaccorso   Tue, 20 Oct 2020 21:15:41 +0200
+
 freetype (2.9.1-3+deb10u1) buster; urgency=medium
 
   * debian/control:
diff -Nru freetype-2.9.1/debian/patches/series 
freetype-2.9.1/debian/patches/series
--- freetype-2.9.1/debian/patches/series2019-07-27 15:19:28.0 
+0200
+++ freetype-2.9.1/debian/patches/series2020-10-20 21:15:41.0 
+0200
@@ -8,3 +8,4 @@
 revert-wrong-extern.patch
 no-web-fonts.patch
 hide-donations-information.patch
+sfnt-Fix-heap-buffer-overflow-59308.patch
diff -Nru 
freetype-2.9.1/debian/patches/sfnt-Fix-heap-buffer-overflow-59308.patch 
freetype-2.9.1/debian/patches/sfnt-Fix-heap-buffer-overflow-59308.patch
--- freetype-2.9.1/debian/patches/sfnt-Fix-heap-buffer-overflow-59308.patch 
1970-01-01 01:00:00.0 +0100
+++ freetype-2.9.1/debian/patches/sfnt-Fix-heap-buffer-overflow-59308.patch 
2020-10-20 21:15:41.0 +0200
@@ -0,0 +1,50 @@
+From: Werner Lemberg 
+Date: Mon, 19 Oct 2020 23:45:28 +0200
+Subject: [sfnt] Fix heap buffer overflow (#59308).
+Origin: 
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=a3bab162b2ae616074c8877a04556932998aeacd
+Bug-Debian: https://bugs.debian.org/972586
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-15999
+
+This is CVE-2020-15999.
+
+* src/sfnt/pngshim.c (Load_SBit_Png): Test bitmap size earlier.
+---
+ ChangeLog  |  8 
+ src/sfnt/pngshim.c | 14 +++---
+ 2 files changed, 15 insertions(+), 7 deletions(-)
+
+diff --git a/src/sfnt/pngshim.c b/src/sfnt/pngshim.c
+index 2e64e58463ad..f55016122c1c 100644
+--- a/src/sfnt/pngshim.c
 b/src/sfnt/pngshim.c
+@@ -332,6 +332,13 @@
+ 
+ if ( populate_map_and_metrics )
+ {
++  /* reject too large bitmaps similarly to the rasterizer */
++  if ( imgHeight > 0x7FFF || imgWidth > 0x7FFF )
++  {
++error = FT_THROW( Array_Too_Large );
++goto DestroyExit;
++  }
++
+   metrics->width  = (FT_UShort)imgWidth;
+   metrics->height = (FT_UShort)imgHeight;
+ 
+@@ -340,13 +347,6 @@
+   map->pixel_mode = FT_PIXEL_MODE_BGRA;
+   map->pitch  = (int)( map->width * 4 );
+   map->num_grays  = 256;
+-
+-  /* reject too large bitmaps similarly to the rasterizer */
+-  if ( map->rows > 0x7FFF || map->width > 0x7FFF )
+-  {
+-error = FT_THROW( Array_Too_Large );
+-goto DestroyExit;
+-  }
+ }
+ 
+ /* convert palette/gray image to rgb */
+-- 
+2.28.0
+

Bug#972592: mdtraj should be Architecture: any-amd64 arm64

[Adrian Bunk]

Source: mdtraj
Version: 1.9.4-4
Severity: serious
Tags: ftbfs

mdtraj needs SSE, which is not in the baseline of the i386 port
and not available at all on !x86.

Upstream master additionally contains a NEON port, which is part
of the arm64 baseline (but not the armhf baseline).

mdtraj should should therefore be Architecture: any-amd64 arm64

Upstream is talking about porting to simde [1],
but no recent progress is visible on that.

[1] https://github.com/mdtraj/mdtraj/pull/1562#issuecomment-644056348

Bug#972591: RFS: libfilezilla/0.25.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libfilezilla":

 * Package name: libfilezilla
   Version : 0.25.0-1
   Upstream Author : Tim Kosse 
 * URL : https://lib.filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/libfilezilla
   Section : libs

It builds those binary packages:

  libfilezilla0 - build high-performing platform-independent programs
(runtime lib)
  libfilezilla-dev - build high-performing platform-independent
programs (development)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.25.0-1.dsc

Changes since the last upload:

 libfilezilla (0.25.0-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 0.25.0

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#972590: baresip-core: needs to be rebuilt against libre-1.1.0

[Kevin Otte]

Package: baresip-core
Version: 1.0.0-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Since libre 1.1.0 has migrated to testing, baresip can no longer make calls:

$ baresip
baresip v1.0.0 Copyright (C) 2010 - 2020 Alfred E. Heggestad et al.
Local network address:   IPv6=enp0s25|2606:a000:a442:9800:24ef:2732:9da5:a78d
...
baresip is ready.
>  142
ua: using best effort AF: af=AF_INET6
call: connecting to 'sip:1...@pbx-int.home.nivex.net'..
*** stack smashing detected ***: terminated
Aborted (core dumped)

I originally filed this against libre in #972185 which contains discussion of 
why the rebuild is necessary.

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

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

Versions of packages baresip-core depends on:
ii  libasound21.2.3.2-1
ii  libc6 2.31-4
ii  libcodec2-0.9 0.9.2-3
ii  libdirectfb-1.7-7 1.7.7-9
ii  libgsm1   1.0.18-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.14~dfsg-1
ii  libmosquitto1 1.6.12-1
ii  libmp3lame0   3.100-3
ii  libmpg123-0   1.26.3-1
ii  libopenaptx0  0.2.0-4
ii  libopencore-amrnb00.1.5-1
ii  libopencore-amrwb00.1.5-1
ii  libopus0  1.3.1-0.1
ii  libpng16-16   1.6.37-3
ii  libportaudio2 19.6.0-1.1
ii  libre01.1.0-1
ii  librem0   0.6.0-4
ii  libsndfile1   1.0.28-8
ii  libsndio7.0   1.5.0-3
ii  libspandsp2   0.0.6+dfsg-2
ii  libspeexdsp1  1.2~rc1.2-1.1
ii  libtwolame0   0.4.0-2
ii  libvo-amrwbenc0   0.1.3-2
ii  libvpx6   1.8.2-1

baresip-core recommends no packages.

Versions of packages baresip-core suggests:
ii  baresip-ffmpeg 1.0.0-2
ii  baresip-gstreamer  1.0.0-2
ii  baresip-gtk1.0.0-2
ii  baresip-x111.0.0-2

-- no debconf information

Bug#972589: kitinerary FTBFS on mipsel/mips64el/riscv64: test failures

[Adrian Bunk]

Source: kitinerary
Version: 20.08.2-2
Severity: serious
Tags: ftbfs

It is surprising that even the failing tests that look
like a timezone issue are reproducibly architecture specific.

kitinerary builds for riscv64 on Ubuntu, but they are
just ignoring test results.

https://buildd.debian.org/status/package.php?p=kitinerary

...
 6/29 Test  #6: knowledgedbtest ..***Failed0.45 sec
* Start testing of KnowledgeDbTest *
Config: Using QtTest library 5.14.2, Qt 5.14.2 
(mips64-little_endian-lp64-n64-hardfloat shared (dynamic) release build; by GCC 
10.2.0)
PASS   : KnowledgeDbTest::initTestCase()
PASS   : KnowledgeDbTest::testUnalignedNumber()
QDEBUG : KnowledgeDbTest::testAlphaId() "ABC"
PASS   : KnowledgeDbTest::testAlphaId()
FAIL!  : KnowledgeDbTest::testIBNRLookup() Compared values are not the same
   Loc: [/<>/autotests/knowledgedbtest.cpp(93)]
FAIL!  : KnowledgeDbTest::testUICLookup() Compared values are not the same
   Loc: [/<>/autotests/knowledgedbtest.cpp(120)]
FAIL!  : KnowledgeDbTest::testSncfStationIdLookup() Compared values are not the 
same
   Loc: [/<>/autotests/knowledgedbtest.cpp(136)]
PASS   : KnowledgeDbTest::testCountryDb()
PASS   : KnowledgeDbTest::testPowerPlugCompat(empty)
PASS   : KnowledgeDbTest::testPowerPlugCompat(DE-DE)
PASS   : KnowledgeDbTest::testPowerPlugCompat(DE-CH)
PASS   : KnowledgeDbTest::testPowerPlugCompat(CH-DE)
PASS   : KnowledgeDbTest::testPowerPlugCompat(DE-FR)
PASS   : KnowledgeDbTest::testPowerPlugCompat(DE-GB)
PASS   : KnowledgeDbTest::testPowerPlugCompat(DE-IT)
PASS   : KnowledgeDbTest::testPowerPlugCompat(IT-DE)
PASS   : KnowledgeDbTest::testPowerPlugCompat(DE-IL)
PASS   : KnowledgeDbTest::testPowerPlugCompat(DE-AO)
PASS   : KnowledgeDbTest::testPowerPlugCompat(AO-DE)
PASS   : KnowledgeDbTest::testPowerPlugCompat(DE-DK)
PASS   : KnowledgeDbTest::testPowerPlugCompat(DK-DE)
PASS   : KnowledgeDbTest::testPowerPlugCompat(DE-ZA)
PASS   : KnowledgeDbTest::testPowerPlugCompat(ZA-CH)
PASS   : KnowledgeDbTest::testPowerPlugCompat(ZA-DE)
PASS   : KnowledgeDbTest::testPowerPlugCompat(ZA-IT)
PASS   : KnowledgeDbTest::testTimezoneForCountry()
PASS   : KnowledgeDbTest::testCountryForTimezone()
PASS   : KnowledgeDbTest::testTimezoneForLocation()
PASS   : KnowledgeDbTest::testCountryFromCoordinate()
PASS   : KnowledgeDbTest::testUICCountryCodeLookup()
PASS   : KnowledgeDbTest::testIso3Lookup()
FAIL!  : KnowledgeDbTest::testIndianRailwaysStationCodeLookup() Compared values 
are not the same
   Loc: [/<>/autotests/knowledgedbtest.cpp(339)]
FAIL!  : KnowledgeDbTest::testFinishStationCodeLookup() Compared values are not 
the same
   Loc: [/<>/autotests/knowledgedbtest.cpp(359)]
PASS   : KnowledgeDbTest::cleanupTestCase()
Totals: 28 passed, 5 failed, 0 skipped, 0 blacklisted, 19ms
* Finished testing of KnowledgeDbTest *
...
26/29 Test #26: calendarhandlertest ..***Failed0.54 sec
* Start testing of CalendarHandlerTest *
Config: Using QtTest library 5.14.2, Qt 5.14.2 
(mips64-little_endian-lp64-n64-hardfloat shared (dynamic) release build; by GCC 
10.2.0)
PASS   : CalendarHandlerTest::initTestCase()
PASS   : CalendarHandlerTest::testCreateEvent(canceled.json)
PASS   : CalendarHandlerTest::testCreateEvent(event.json)
PASS   : CalendarHandlerTest::testCreateEvent(eventreservation.json)
QWARN  : CalendarHandlerTest::testCreateEvent(flight.json) org.kde.kitinerary: 
IATA BCBP code too short for unique mandatory section, or invalid mandatory 
section format
PASS   : CalendarHandlerTest::testCreateEvent(flight.json)
QDEBUG : CalendarHandlerTest::testCreateEvent(hotel.json) Actual:  
BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:2.0
X-KDE-ICAL-IMPLEMENTATION-VERSION:1.0
BEGIN:VEVENT
DTSTAMP:20171227T111649Z
X-KDE-KITINERARY-RESERVATION:[{"@context":"http://schema.org"\,"@type":
 "LodgingReservation"\,"checkinTime":"2017-09-19T15:00:00+03:
 00"\,"checkoutTime":"2017-09-20T12:00:00+03:00"\,"potentialAction":
 [{"@type":"CancelAction"\,"target":"https:
 //secure.booking.com/mybooking.en-gb.html?auth_key=magic&source=conf_metad
 ata&pbsource=email_cancel"}\,{"@type":"ViewAction"\,"target":"https:
 //secure.booking.com/mybooking.en-gb.html?aid=123456\;
 auth_key=magic&&source=conf_metadata&pbsource=conf_email_modify"}]\,"reser
 vationFor":{"@type":"LodgingBusiness"\,"address":{"@type":
 "PostalAddress"\,"addressCountry":"FI"\,"addressLocality":
 "Espoo"\,"addressRegion":""\,"postalCode":"02600"\,"streetAddress":
 "Leppävaarankatu 1"}\,"name":"Glo Hotel Sello"\,"telephone":
 "+358101234567"\,"url":"https:
 //www.booking.com/hotel/fi/palace-sello.html?aid=123456&label=postbooking_
 confemail"}\,"reservationNumber":"1234567890"\,"reservationStatus":"http:
 //schema.org/ReservationConfirmed"\,"underName":{"@type":
 "Person"\,"email":"john@email.com"\,"name":"John Doe"}\,"url":"https:
 //secure.booking.com/mybooking.en-gb.html?aid=123456\;
 auth_key=magic&&source=conf_metadata&pbs

Bug#972588: src:netgen: fails to migrate to testing for too long: FTBFS, unresolved RC bug and maintainer built arch:all binaries

[Paul Gevers]

Source: netgen
Version: 6.2.1804+dfsg1-3.1
Severity: serious
Control: close -1 6.2.2006+dfsg-1
Tags: sid bullseye ftbfs
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:netgen 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=netgen




signature.asc
Description: OpenPGP digital signature

Bug#951682:

[Henry-Nicolas Tourneur]

Hello Ralf,

Version 0.25 of this package depends just got it and it depends on librust-
markup5ever-0.10+default-dev which is provided by librust-markup5ever-dev.

I will close this bug accordingly.

Best regards,


-- 
Henry-Nicolas Tourneur
mxid: @hntourne:matrix.nilux.be

Bug#912485: childsplay: Please migrate to python3-pygame

[Markus Koschany]

I have started to port childsplay to python3. There are no estimates
when it's done but I hope I can finish the work before we freeze.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#972587: Provide option to enable OpenPGP signing without attaching the public key

[Michael Biebl]

Package: thunderbird
Version: 1:78.3.3-1
Severity: wishlist

Hi,

atm, if one enables signing of emails via OpenPGP, it automatically
attaches the public key every time. I'd like an option to configure that
behaviour, as I'd like to sign emails without attaching the public key.

Regards,
Michael


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

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

Versions of packages thunderbird depends on:
ii  debianutils 4.11.2
ii  fontconfig  2.13.1-4.2
ii  libatk1.0-0 2.36.0-2
ii  libbotan-2-15   2.15.0+dfsg-2+b1
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-4
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.20-1
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.12-stable-1
ii  libffi7 3.3-4
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-3
ii  libgcc-s1   10.2.0-15
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libglib2.0-02.66.1-2
ii  libgtk-3-0  3.24.23-2
ii  libicu6767.1-4
ii  libjson-c5  0.15-1
ii  libnspr42:4.28-1
ii  libnss3 2:3.56-1
ii  libpango-1.0-0  1.46.2-1
ii  libstdc++6  10.2.0-15
ii  libvpx6 1.8.2-1
ii  libx11-62:1.6.12-1
ii  libx11-xcb1 2:1.6.12-1
ii  libxcb-shm0 1.14-2
ii  libxcb1 1.14-2
ii  libxext62:1.3.3-1+b2
ii  libxrender1 1:0.9.10-1
ii  psmisc  23.3-1
ii  x11-utils   7.7+5
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-de-de [hunspell-dictionary]  20161207-8
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.4-3+b1
ii  fonts-lyx 2.3.5.2-1
ii  libgssapi-krb5-2  1.17-10
ii  libgtk2.0-0   2.24.32-4

-- no debconf information

Bug#972578: Acknowledgement (Broken app favorites in gnome-shell after renaming thunderbird.desktop to net.thunderbird.Thunderbird.desktop)

[Michael Biebl]

Control: severity -1 important

Since this change might break existing mime handler associations in
Cinnamon and MATE, I'm tentatively bumping this to important.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#971515: kubernetes: excessive vendoring (private libraries)

[Sean Whitton]

Hello Dmitry, others,

On Thu 01 Oct 2020 at 11:15am +10, Dmitry Smirnov wrote:

> I seek your judgement regarding excessive, unnecessary and unjustifiable
> vendoring of private libraries in Kubernetes package:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970717
>
> Some relevant argumentation can be found in
>
>   https://lists.debian.org/debian-devel/2020/03/msg00359.html
>   https://lists.debian.org/debian-devel/2020/03/msg00400.html
>   https://lists.debian.org/debian-devel/2020/03/msg00441.html
>
> In short, myself and Golang packaging team spent years on stabilising
> Golang ecosystem of packaged libraries for re-use by Golang software.
>
> To the best of my knowledge, all packaged Golang software, regardless of its 
> sophistication, use some packages libraries.
> Except Kubernetes, that disconnected itself from cooperation by not using any 
> packaged libraries, instead exclusively using only private libraries in 
> numbers greater than any Debian package ever used.
>
> As a former Kubernetes maintainer and a developer who originally introduced
> Kubernetes to Debian, I know that it could be maintained with only few (or 
> several) private libraries at most.
>
> Current state of Kubernetes package is in violation of ftp-master's policy 
> for inclusion of new packages to Debian.

I think that my message [1] is what makes you think that the package
would not have got through NEW?  There are a few issues tangled together
here.

NEW is mainly about license and DFSG compliance, and secondarily about
the idea that we want to avoid accepting packages where doing so would
make Debian worse, even if it would also make Debian better along other
dimensions.  As a simple example, we try to avoid accepting a package
that is already packaged under a slightly different name, because in
most cases it is worse for both users and contributors to have the same
thing in the archive twice (not talking about vendoring here).

In this case, the reason I wrote in [1] that I would probably have
rejected the package, had I come across it in NEW, is that it seemed to
me that having this package in Debian would make the archive less
maintainable by contributors other than Janos who might need to work
with the package.  (After the discussion on -devel, I'm no longer so
sure about that opinion of mine.)

It's not correct to say, however, that the package "is in violation of
ftpmaster's policy for inclusion of new packages".  That could only be
true is if the package met one of the "serious violations" listed in the
REJECT-FAQ, which is basically DFSG and licensing issues, and a few
obvious clangers.  Instead, what we have is a situation in which there
is reason to be worried about the way the package is put together, but
the opinion of one FTP team member at one particular point in time
carries about the same weight as the opinion of any experienced
packager.

In other words, I suggest that we ignore the NEW issue entirely, and
just consider whether the way the package is currently put together
imposes an unreasonable burden on Debian contributors other than Janos
who want to work on the package, or users who want to patch it, etc.
The sorts of questions we should try to answer:

- does the vendoring make Debian security support harder (discussion on
  -devel suggests it makes it easier)

- everyone seems to think the level of vendoring is at best a necessary
  evil; if someone wants to try to reduce the level of vendoring (as
  Dmitry did when he was maintainer), is the current way the package is
  built going to make it harder for people to work on making that sort
  of contribution?

- are people trying to do cross-archive work going to find the packaging
  of kubernetes getting in their way?  (e.g. other Go team members
  trying to update things, improve our binNMU techniques and machinery,
  etc.)

... and this is to be weighed against the negative impact of having
kubernetes in Debian lag so seriously behind upstream such that almost
no-one would want to bother installing it.

Are there issues the TC should think about which do not fall under this
way of looking at things?  I.e., weighing the impact on people other
than Janos who want to work on the package, vs. the impact on people who
want recent kubernetes to be part in the archive at all?

If I'm right about what the question for the TC is, I hope that Janos
and Dmitry can both help us discuss it in a way which sets aside the
heat which characterised the -devel thread.  It is completely
understandable to (a) feel very frustrated at Debian not including
recent versions of a useful piece of free software; and also (b) feel
very frustrated when someone chooses to accept a less-than-ideal
approach as necessary when one has put a lot of time into trying to find
workable alternatives.

The thing is, both (a) and (b) are motivated by the same basic desire to
make Debian better and more useful, so perhaps we can focus on that
point of commonality.

[1]  https://l

Bug#972586: freetype: CVE-2020-15999: buffer overflow in Load_SBit_Png

[Salvatore Bonaccorso]

Source: freetype
Version: 2.10.2+dfsg-3
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://savannah.nongnu.org/bugs/?59308
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for freetype.

CVE-2020-15999[0]:
| heap buffer overflow in Load_SBit_Png

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-15999
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15999
[1] https://savannah.nongnu.org/bugs/?59308

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#972585: [uscan] doesn't delete temporary git checkouts

[Julien Puydt]

Package: devscripts
Version: 2.20.4

In git mode, using as d/watch :

version=4
  
opts=component=algorithm,mode=git,\
uversionmangle=s/(.*)/algorithm-$1/ \
https://github.com/jupyterlab/lumino \
refs/tags/@lumino/algorithm@@ANY_VERSION@ group

uscan makes a (bare) git checkout in a directory lumino-
temporary.305169.git/, which doesn't get deleted at the end.

Notice that the last lines (with -v) are:
uscan info: New orig.tar.* tarball version (after mk-origtargz):
algorithm-1.3.3
uscan warn: rename ../lumino_algorithm-1.3.3.orig-algorithm.tar.xz to
../lumino_algorithm-1.3.3.orig-algorithm.tar.xz
Use of uninitialized value in string eq at
/usr/share/perl5/Devscripts/Uscan/WatchFile.pm line 451.
uscan info: Scan finished

so I don't think that's due to a crash-before-clean.

HTH,

JP

Bug#831835: Earn Revenue with Bing/Yahoo Feeds

[Viky Jude]

I found you on the Mozilla store and wanted to reach out to offer you Bing and 
Yahoo feeds for your addons or websites you may own.

Our Bing hosted lander which is your search can earn up to $50 per 1000 
searches, and our feeds can earn you up to $0.40 a click.   It is a premium 
product by invitation only and can easily be added to your websites or addons.

If this is something you would be interested in, I would be glad to discuss 
this further with you.

I look forward to hearing from you soon.  

Kind Regards
 
Viky Jude

Business Development Manager

Invoke.Vision

Bug#972584: ublock-origin: add-on version differs from the installed version

[Markus Koschany]

Hi,

Am 20.10.20 um 20:39 schrieb seb:
> Package: webext-ublock-origin
> Version: 1.22.2+dfsg-1~deb10u1
> Severity: minor
> File: ublock-origin
> 
> Dear Maintainer,
> 
> I have webext-ublock-origin 1.22.2+dfsg-1~deb10u1 and firefox-esr
> 78.3.0esr-1~deb10u1 installed.
> 
> In firefox, the add-on version is still 1.9.15rc1.

Yes, that's correct. It was already reported and addressed in a newer
version of ublock-origin. I intend to backport this one to stable
releases soon because it contains bug fixes for other issues too.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#972584: ublock-origin: add-on version differs from the installed version

[seb]

Package: webext-ublock-origin
Version: 1.22.2+dfsg-1~deb10u1
Severity: minor
File: ublock-origin

Dear Maintainer,

I have webext-ublock-origin 1.22.2+dfsg-1~deb10u1 and firefox-esr
78.3.0esr-1~deb10u1 installed.

In firefox, the add-on version is still 1.9.15rc1.



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

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

webext-ublock-origin depends on no packages.

Versions of packages webext-ublock-origin recommends:
ii  firefox-esr  78.3.0esr-1~deb10u1

Versions of packages webext-ublock-origin suggests:
pn  ublock-origin-doc  

-- no debconf information

Bug#972548: python-skbio: diff for NMU version 0.5.6-3.1

[Stefano Rivera]

Control: tags 972548 + patch
Control: tags 972548 + pending

Dear maintainer,

The issue seems to be pandas 1.1 more than python 3.9.

I've prepared an NMU for python-skbio (versioned as 0.5.6-3.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.

SR
diff -Nru python-skbio-0.5.6/debian/changelog python-skbio-0.5.6/debian/changelog
--- python-skbio-0.5.6/debian/changelog	2020-09-29 00:20:23.0 -0700
+++ python-skbio-0.5.6/debian/changelog	2020-10-20 11:00:59.0 -0700
@@ -1,3 +1,10 @@
+python-skbio (0.5.6-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patches: Support Pandas 1.1. (Closes: #972548)
+
+ -- Stefano Rivera   Tue, 20 Oct 2020 11:00:59 -0700
+
 python-skbio (0.5.6-3) unstable; urgency=medium
 
   * debhelper-compat 13 (routine-update)
diff -Nru python-skbio-0.5.6/debian/patches/pandas1.1-ordination-fix.patch python-skbio-0.5.6/debian/patches/pandas1.1-ordination-fix.patch
--- python-skbio-0.5.6/debian/patches/pandas1.1-ordination-fix.patch	1969-12-31 16:00:00.0 -0800
+++ python-skbio-0.5.6/debian/patches/pandas1.1-ordination-fix.patch	2020-10-20 10:54:50.0 -0700
@@ -0,0 +1,137 @@
+From: Jamie Morton 
+Date: Wed, 26 Aug 2020 10:37:27 -0600
+Subject: Ordination fix (#1720)
+
+* `skbio.stats.ordination` tests have been relaxed.
+
+* Fixes build errors for newer versions of NumPy, Pandas, and SciPy.
+
+* Corrected a criticial bug in `skbio.alignment.StripedSmithWaterman` /
+  `skbio.alignment.local_pairwise_align_ssw` which would cause the
+  formatting of the aligned sequences to misplace gap characters by the
+  number of gap characters present in the opposing aligned sequence up
+  to that point. This was caused by a faulty implementation of CIGAR
+  string parsing, see
+  [#1679](https://github.com/biocore/scikit-bio/pull/1679) for full
+  details.
+
+Origin: upstream, https://github.com/biocore/scikit-bio/pull/1720
+Bug-Upstream: https://github.com/biocore/scikit-bio/issues/1713
+---
+ CHANGELOG.md   |  5 ++
+ .../ordination/tests/test_redundancy_analysis.py   |  1 -
+ skbio/util/_testing.py | 59 ++
+ 3 files changed, 44 insertions(+), 21 deletions(-)
+
+diff --git a/CHANGELOG.md b/CHANGELOG.md
+index ebdfe7e..61ae9a1 100644
+--- a/CHANGELOG.md
 b/CHANGELOG.md
+@@ -23,6 +23,11 @@
+ ### Performance enhancements
+ 
+ ### Bug fixes
++* * `skbio.stats.ordination` tests have been relaxed. ([#1713](https://github.com/biocore/scikit-bio/issues/1713))
++
++* Fixes build errors for newer versions of NumPy, Pandas, and SciPy.
++
++* Corrected a criticial bug in `skbio.alignment.StripedSmithWaterman`/`skbio.alignment.local_pairwise_align_ssw` which would cause the formatting of the aligned sequences to misplace gap characters by the number of gap characters present in the opposing aligned sequence up to that point. This was caused by a faulty implementation of CIGAR string parsing, see [#1679](https://github.com/biocore/scikit-bio/pull/1679) for full details.
+ 
+ * Fixes build errors for newer versions of NumPy, Pandas, and SciPy.
+ 
+diff --git a/skbio/stats/ordination/tests/test_redundancy_analysis.py b/skbio/stats/ordination/tests/test_redundancy_analysis.py
+index 601832f..a8aefe8 100644
+--- a/skbio/stats/ordination/tests/test_redundancy_analysis.py
 b/skbio/stats/ordination/tests/test_redundancy_analysis.py
+@@ -245,7 +245,6 @@ class TestRDAResults_biplot_score(TestCase):
+ proportion_explained=vegan_propexpl,
+ eigvals=vegan_eigvals)
+ 
+-pdt.assert_frame_equal(res_samples, vegan_samples)
+ # This scaling constant is required to make skbio comparable to vegan.
+ scaling = (rda_.eigvals[0] / rda_.eigvals[:6])
+ exp.biplot_scores *= scaling
+diff --git a/skbio/util/_testing.py b/skbio/util/_testing.py
+index ae6ff1f..0d69fbc 100644
+--- a/skbio/util/_testing.py
 b/skbio/util/_testing.py
+@@ -12,8 +12,8 @@ import sys
+ 
+ import numpy as np
+ import numpy.testing as npt
+-import pandas.testing as pdt
+-
++import pandas.util.testing as pdt
++from scipy.spatial.distance import pdist
+ from ._decorator import experimental
+ 
+ 
+@@ -118,24 +118,25 @@ def assert_ordination_results_equal(left, right, ignore_method_names=False,
+ npt.assert_equal(left.short_method_name, right.short_method_name)
+ npt.assert_equal(left.long_method_name, right.long_method_name)
+ 
+-_assert_frame_equal(left.samples, right.samples,
+-ignore_columns=ignore_axis_labels,
+-ignore_directionality=ignore_directionality,
+-decimal=decimal)
+-
+-_assert_frame_equal(left.features, right.features,
+-ignore_columns=ignore_axis_labels,
+-ignore_directionality=ignore_directionality,
+-decimal=decimal)
+-_assert_frame_equal(left.

Bug#607969: sqlite: removal of sqlite 2 is really overdue

[Moritz Mühlenhoff]

> qsf is not RC-buggy, but has had removal requested already, and I already
> reported an 'important' bug in January (because it was the only one whose
> dependency did not have a sqlite3 alternative).

Status update: qsf has been removed yesterday.

Cheers,
Moritz

Bug#970752: Works OK now with current version of open-vm-tools

[sixerjman]

sctl status vmtoolsd ? vmtoolsd.service - Service for virtual machines
hosted on VMware Loaded: loaded (/usr/lib/systemd/system/vmtoolsd.service;
enabled; vendor preset: enabled) Active: active (running) since Tue
2020-10-20 13:47:58 EDT; 4min 49s ago

open-vm-tools version: 2:11.1.5-1

OK to close.

Bug#972536: fpc: the old version 3.0.4+dfsg-23 still in sid

[Paul Gevers]

HI Xiao,

On 20-10-2020 03:58, xiao sheng wen wrote:
> Source: fpc
> Version: 3.0.4+dfsg-23
> Severity: minor
> 
> Dear Maintainer,
> 
>   The newest verison of fpc is 3.2.0+dfsg-8, now is in the testing.
>   But the old version 3.0.4+dfsg-23 is still in sid.
>   Is need to remove old version from sid?

Removal is the domain of ftp masters. Normally, packages that aren't
needed are automatically removed. This sometimes fails, but normally
means that there is something that keeps it in the archive. E.g. because
of Built-Using (which I suspect here, but forgot how to check).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#972430: nvidia-legacy-340xx-driver: Fails to build with kernel 5.9

[KeyofBlueS]

It seems a working patch is ready for kernel 5.9:
https://aur.archlinux.org/pkgbase/nvidia-340xx/?O=0&PP=10

Bug#972583: conserver-server.service: Failed with result 'protocol'

[dann frazier]

Package: conserver-server
Version: 8.2.4-2+b1
Severity: important

The postinst fails when installing conserver-server:

$ sudo apt install conserver-server
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  libdirectfb-1.7-7
Use 'sudo apt autoremove' to remove it.
The following NEW packages will be installed:
  conserver-server
0 upgraded, 1 newly installed, 0 to remove and 8 not upgraded.
Need to get 0 B/181 kB of archives.
After this operation, 471 kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package conserver-server.
(Reading database ... 438587 files and directories currently installed.)
Preparing to unpack .../conserver-server_8.2.4-2+b1_amd64.deb ...
Unpacking conserver-server (8.2.4-2+b1) ...
Setting up conserver-server (8.2.4-2+b1) ...
Job for conserver-server.service failed because the service did not take the ste
ps required by its unit configuration.
See "systemctl status conserver-server.service" and "journalctl -xe" for details
.
invoke-rc.d: initscript conserver-server, action "start" failed.
● conserver-server.service - Console server
 Loaded: loaded (/lib/systemd/system/conserver-server.service; disabled; ven
dor preset: enabled)
 Active: failed (Result: protocol) since Tue 2020-10-20 11:24:30 MDT; 8ms ag
o
   Docs: man:conserver(8)
Process: 430561 ExecStart=/usr/sbin/conserver -d $OPTS (code=exited, status=
0/SUCCESS)

Oct 20 11:24:30 xps13 systemd[1]: Starting Console server...
Oct 20 11:24:30 xps13 conserver[430561]: [Tue Oct 20 11:24:30 2020] conserver (4
30561): conserver.com version 8.2.4
Oct 20 11:24:30 xps13 conserver[430561]: [Tue Oct 20 11:24:30 2020] conserver (4
30561): started as `conservr' by `conservr'
Oct 20 11:24:30 xps13 conserver[430561]: [Tue Oct 20 11:24:30 2020] conserver (4
30561): ERROR: no consoles found in configuration file
Oct 20 11:24:30 xps13 conserver[430561]: [Tue Oct 20 11:24:30 2020] conserver (4
30561): terminated
Oct 20 11:24:30 xps13 systemd[1]: conserver-server.service: Can't open PID file 
/run/conserver/conserver.pid (yet?) after start: Operation not permitted
Oct 20 11:24:30 xps13 systemd[1]: conserver-server.service: Failed with result '
protocol'.
Oct 20 11:24:30 xps13 systemd[1]: Failed to start Console server.
dpkg: error processing package conserver-server (--configure):
 installed conserver-server package post-installation script subprocess returned
 error exit status 1
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for systemd (246.6-2) ...
Errors were encountered while processing:
 conserver-server
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


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

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

Versions of packages conserver-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-4
ii  libcrypt1  1:4.4.17-1
ii  libpam0g   1.3.1-5
ii  libssl1.1  1.1.1h-1
ii  libwrap0   7.6.q-30
ii  lsb-base   11.1.0

conserver-server recommends no packages.

conserver-server suggests no packages.

-- debconf information:
  conserver-server/run_as_root: false
  conserver-server/port: 3109
  conserver-server/base_port:
  conserver-server/listen_address:

Bug#972581: enabling ipv6 support broke ipv4 CIDR access list

[dann frazier]

Package: conserver-server
Version: 8.2.4-2+b1
Severity: normal
Tags: upstream

I'm using an access list that looks like this:

access * {
   trusted 127.0.0.1,10.2.3.4,10.5.6.0/18,10.6.7.0/18;
   allowed 127.0.0.1,10.2.3.4,10.5.6.0/18,10.6.7.0/18;
}

After upgrading from 8.2.1-1 to 8.2.4-2, conserver began denying access to
clients in these IP ranges:

$ console myhost
10.2.3.4: access from your host refused

I found that the important difference between these two wasn't the source
itself, but rather that --with-ipv6 was enabled for 8.2.4. Rebuilding 8.2.4
w/o --with-ipv6 restored the previous behavior, allowing clients the impacted
clients to connect once again.


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

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

Versions of packages conserver-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-4
ii  libcrypt1  1:4.4.17-1
ii  libpam0g   1.3.1-5
ii  libssl1.1  1.1.1h-1
ii  libwrap0   7.6.q-30
ii  lsb-base   11.1.0

conserver-server recommends no packages.

conserver-server suggests no packages.

-- debconf information:
  conserver-server/port: 3109
  conserver-server/base_port:
  conserver-server/listen_address:
  conserver-server/run_as_root: false

Bug#969588: sqv: Cannot use ASCII armored key as keyring?

[Justus Winter]

Daniel Kahn Gillmor  writes:

> On Fri 2020-10-16 12:05:48 +0200, Justus Winter wrote:
>> And in general, the expectation that you can join two files does not
>> hold.  Concatenating two photos doesn't yield a slideshow, etc.  So my
>> position on the matter is that concatenating two binary certificates
>> yielding a keyring is a happy accident of an implementational detail,
>> but shouldn't be relied upon, and certainly does not extend to other
>> representations of certificates.
>
> I understand your reasoning, but text files *do* concatenate to a longer
> textfile, and textual-representations of a keyring are text files.

I still think that this is an accident, but for the benefit of everyone
coming from GnuPG we implemented it in Sequoia, so the next version of
sqv will support this.

> and, we have (i think) a pretty solid understanding of what a
> concatenated ASCII-armored keyring would look like.  So i'm proposing
> that sop (at least) should be able to handle concatenated ASCII-armored
> certificates:
>
>https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/28
>
> Please weigh in over there!

I did.

Cheers,
Justus


signature.asc
Description: PGP signature

Bug#972580: dpkg-query throw error when asking for field "source:Upstream-Version"

[Brian Wengel]

Package: dpkg
Version: 1.19.7

Command example throwing the error:
dpkg-query --show --showformat '${Package} ${source:Upstream-Version}\n' s*

Error message:
dpkg-query: error: version '' has bad syntax: version string is empty

>From the manual per 1.19.7 / 2019-06-03
"source:Upstream-Version
   It contains the source package upstream version for this binary
package (since dpkg 1.18.16)"

Bug#972579: rust-kmon: wrong section in debian/control

[Aurelien Jarno]

Source: rust-kmon
Version: 1.3.0-1
Severity: serious

rust-kmon contains an invalid Section for the Source package:

| $ head -n 10 debian/control
| Source: rust-kmon
| Section: FIXME-(source.section)
| Priority: optional
| Build-Depends: debhelper (>= 11),
|  dh-cargo (>= 18),
|  cargo:native,
|  rustc:native,
|  libstd-rust-dev,
|  librust-bytesize-1+default-dev,
|  librust-clap-2+default-dev (>= 2.33.0-~~),

This causes many issues with the debian tools (buildds, etc.)

Bug#972578: Broken app favorites in gnome-shell after renaming thunderbird.desktop to net.thunderbird.Thunderbird.desktop

[Michael Biebl]

Package: thunderbird
Version: 1:78.3.3-1
Severity: normal
X-Debbugs-Cc: pkg-gnome-maintain...@lists.alioth.debian.org

Hi,

I had pinned thunderbird to the dash as app favorite/bookmark
https://help.gnome.org/users/gnome-help/stable/shell-apps-favorites.html.en

After the upgrade from Thunderbird 68 to 78, this favorite was gone.
Afaics, the problem is, that the name of the desktop file changed from
/usr/share/applications/thunderbird.desktop to
/usr/share/applications/net.thunderbird.Thunderbird.desktop
so the existing reference was broken.

I see two possible ways to fix this:
a/ Rename the desktop file back to thunderbird.desktop (this is probably
the most suitable action for stable)
b/ Add an explicit mapping to gnome-shell
https://salsa.debian.org/gnome-team/gnome-shell/-/blob/debian/master/js/ui/appFavorites.js#L11

I've CCed the gnome-shell maintainers. Not sure if they are willing to
add non-GNOME apps to that list.

It's likely, that other desktops are affected in a similar way, but I
haven't checked those. I do see a couple of references though at
https://codesearch.debian.net/search?q=thunderbird.desktop&literal=1
possibly affecting MATE, Cinnamon, plank.

Regards,
Michael



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

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

Versions of packages thunderbird depends on:
ii  debianutils 4.11.2
ii  fontconfig  2.13.1-4.2
ii  libatk1.0-0 2.36.0-2
ii  libbotan-2-15   2.15.0+dfsg-2+b1
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-4
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.20-1
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.12-stable-1
ii  libffi7 3.3-4
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-3
ii  libgcc-s1   10.2.0-15
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libglib2.0-02.66.1-2
ii  libgtk-3-0  3.24.23-2
ii  libicu6767.1-4
ii  libjson-c5  0.15-1
ii  libnspr42:4.28-1
ii  libnss3 2:3.56-1
ii  libpango-1.0-0  1.46.2-1
ii  libstdc++6  10.2.0-15
ii  libvpx6 1.8.2-1
ii  libx11-62:1.6.12-1
ii  libx11-xcb1 2:1.6.12-1
ii  libxcb-shm0 1.14-2
ii  libxcb1 1.14-2
ii  libxext62:1.3.3-1+b2
ii  libxrender1 1:0.9.10-1
ii  psmisc  23.3-1
ii  x11-utils   7.7+5
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-de-de [hunspell-dictionary]  20161207-8
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.4-3+b1
ii  fonts-lyx 2.3.5.2-1
ii  libgssapi-krb5-2  1.17-10
ii  libgtk2.0-0   2.24.32-4

-- no debconf information

Bug#972560: qa.debian.org/popcon: "INF%", "NaN%"

[Christoph Berg]

Re: Jakub Wilk
> Package: qa.debian.org
> 
> On , the column "Recent"
> reads:
> 
>   INF%
>   NaN%

And "Recent ()"
"(1st: )"

which is likely the cause of the problem.

Christoph

Bug#898446: Please reconsider enabling the user namespaces by default

[Simon McVittie]

On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote:
> I don't think we should keep patching in
> kernel.unprivileged_userns_clone forever, so the documented way to
> disable user namespaces should be setting user.max_user_namespaces to
> 0.  But then there's no good way to have a drop-in file that changes
> back to the upstream default, because that's dependent on system memory
> size.
> 
> So I think we should do something like this:
> 
> * Document user.max_user_namespaces in procps's shipped
>   /etc/sysctl.conf
> * Set kernel.unprivileged_userns_clone to 1 by default, and deprecate
>   it (log a warning if it's changed)
> * Document the change in bullseye release notes

Is this something you intend to do before bullseye, or is it now going
to be after bullseye?

If this is intended to happen before bullseye, I'd like enough time
before the freeze to put an as-graceful-as-possible transition in place
in the bubblewrap package.

(I'm not sure what form that transition should take - suggestions welcome!
Ideally I'd like bubblewrap to be setuid root if and only if we are still
using a kernel where it needs to be.)

smcv

Bug#972524: [Pkg-nagios-devel] Bug#972524: monitoring-plugins: FTBFS on buster (dh_compress)

[Jakob Bohm]

On 2020-10-20 06:05, Sebastiaan Couwenberg wrote:

Control: tags -1 unreproducible
Control: severity -1 important

Hi Jakob,

Thanks for reporting this issue, but unfortunately I cannot reproduce it.

Building 2.2-6 in a buster chroot works as expected:

  gbp clone \
  https://salsa.debian.org/nagios-team/pkg-monitoring-plugins.git
  git checkout -b buster debian/2.2-6
  gbp buildpackage --git-pbuilder \
   --git-dist=buster \
   --git-debian-branch=buster

Kind Regards,

Bas



Did your test include the use of backported packages, as stated?

When checking out from git, I didn't select any specific branch, as the
"please use the git source" message just said to clone the tree, thus HEAD.

Also, I notice that your build commands differ from mine, what is "gbp"?

As a local sysadmin, I don't have my own installs of automated build
daemons such as pbuilder.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Bug#970111: Bug#971989: unblock: thunderbird/1:78.3.2-1

[Michael Biebl]

Hi everyone

Am 20.10.20 um 15:49 schrieb Michael Biebl:
> Am 20.10.20 um 15:42 schrieb Carsten Schoenert:
>> Hello Michael,
>>
>> Am 20.10.20 um 14:54 schrieb Michael Biebl:
>>> Shouldn't we rather wait, until such an updated enigmail package is
>>> available? I see, that the enigmail package has a bug report with
>>> attached patches, maybe it's time to NMU (that said, I've explicitly
>>> CCed Daniel, maybe he can chime in here)
>>>
>>> I don't think forcing TB 78 into testing is the answer, your users would
>>> be quite unhappy.
>>
>> I personally think that we already break the user experience as we
>> released TB for buster through stable-security and some days ago also
>> for LTS users. So I see no need to wait any longer. Currently the
>> upgrade path for buster users is at least broken for Thunderbird.
> 
> I guess the solution for that is to upload enigmail 2.2 as quickly as
> possible to stable(-security).
> It is not justification to break more stuff.
> 
> Fwiw, I'm willing to NMU enigmail, if there is no progress on #970111.
> 

So I decided to do that, and NMU enigmail.
I used Gregors patches from [1] (thanks for that!) with some minor changes
- Updated to 2.2.4 (instead of 2.2.2)
- Marked the upload as NMU (versioned as 2:2.2.4-0.1) and removed Gregor
from Uploaders again. It seemed a bit controversial to add oneself to
Uploaders as part of an NMU
- Removed Files-Excluded from debian/copyright as the offending files
are no longer part of the dist tarball, so a repack is not necessary anymore

I gave the package some light testing and the migration wizard did
properly show up and import my private and public keys (it skipped one
public key, haven't investigated yet, why) and the account settings.

I've pushed my work to https://salsa.debian.org/biebl/enigmail and
uploaded to DELAYED/14.

Daniel, please holler if you want me to cancel the NMU.

Hopefully this helps, to unbreak the current situation a bit.

Regards,
Michael

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

P.S: This is my first message with TB 78. Let's see if it's properly
signed...



OpenPGP_signature
Description: OpenPGP digital signature

Bug#972577: spampd: support systemd service reloading via SIGHUP

[Kevin Locke]

Package: spampd
Version: 2.53-1
Severity: wishlist
Tags: patch

Dear Maintainer,

Attempting to `systemctl reload spampd.service` results in the error:

Failed to reload spampd.service: Job type reload is not applicable for unit 
spampd.service.

For a service to be reloaded, it must define ExecReload=, which
spampd.service does not currently do.  Since SpamPD supports reloading
via SIGHUP (see [mpaperno/spampd#20]), adding:

ExecReload=kill -HUP $MAINPID

(matching the example from systemd.service(5)) to the [Service] section
of spampd.service should be sufficient.  I've attached a patch for
reference.

Thanks for considering,
Kevin
>From 897e2d06b47c8d6975ecd75161defc086527412a Mon Sep 17 00:00:00 2001
Message-Id: 
<897e2d06b47c8d6975ecd75161defc086527412a.1603208436.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Tue, 20 Oct 2020 09:31:42 -0600
Subject: [PATCH] spampd.service: Support reload via ExecReload=

Attempting to `systemctl reload spampd.service` results in the error:

Failed to reload spampd.service: Job type reload is not applicable for unit 
spampd.service.

For a service to be reloaded, it must define ExecReload=.  Since SpamPD
supports reloading via SIGHUP (see [mpaperno/spampd#20]), define it to
do so.  Note: This matches the example in systemd.service(5) verbatim.

[mpaperno/spampd#20]: https://github.com/mpaperno/spampd/pull/20

Signed-off-by: Kevin Locke 
---
 debian/spampd.service | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/spampd.service b/debian/spampd.service
index 31293ff..0822a33 100644
--- a/debian/spampd.service
+++ b/debian/spampd.service
@@ -6,6 +6,7 @@ After=network.target local-fs.service
 EnvironmentFile=-/var/run/spampd/spampd.arguments
 ExecStartPre=/usr/share/spampd/process_arguments.sh
 ExecStart=/usr/sbin/spampd --setsid $SPAMPD_ARGS
+ExecReload=kill -HUP $MAINPID
 Restart=on-failure
 PIDFile=/var/run/spampd/spampd.pid
 
-- 
2.28.0

Bug#895851: gkrellweather: diff for NMU version 2.0.8-2.2

[Sudip Mukherjee]

Control: tags 895851 + pending
--

Dear maintainer,

I've prepared an NMU for gkrellweather (versioned as 2.0.8-2.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru gkrellweather-2.0.8/debian/changelog 
gkrellweather-2.0.8/debian/changelog
--- gkrellweather-2.0.8/debian/changelog2016-11-30 17:19:51.0 
+
+++ gkrellweather-2.0.8/debian/changelog2020-10-20 16:29:25.0 
+0100
@@ -1,3 +1,11 @@
+gkrellweather (2.0.8-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix prefix path. (Closes: #895851)
+- Thanks to Roland Hieber for the patch.
+
+ -- Sudip Mukherjee   Tue, 20 Oct 2020 16:29:25 
+0100
+
 gkrellweather (2.0.8-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gkrellweather-2.0.8/debian/patches/fix-prefix.patch 
gkrellweather-2.0.8/debian/patches/fix-prefix.patch
--- gkrellweather-2.0.8/debian/patches/fix-prefix.patch 1970-01-01 
01:00:00.0 +0100
+++ gkrellweather-2.0.8/debian/patches/fix-prefix.patch 2020-10-20 
16:07:59.0 +0100
@@ -0,0 +1,18 @@
+From: Roland Hieber 
+Subject: set PREFIX to /usr, not /usr/local
+ A distribution package should not need to refer to /usr/local at all.
+ Specifically, this default leads to GrabWeather being searched in /usr/local,
+ where it is obviously not installed.
+Forwarded: not-needed
+
+--- a/Makefile
 b/Makefile
+@@ -3,7 +3,7 @@
+ CFLAGS += -O2 -std=gnu99 -Wall -fPIC `pkg-config gtk+-2.0 --cflags`
+ LIBS = `pkg-config gtk+-2.0 --libs`
+ LDFLAGS += -shared
+-PREFIX = /usr/local
++PREFIX = /usr
+ 
+ LOCALEDIR := $(PREFIX)/share/locale
+ 
diff -Nru gkrellweather-2.0.8/debian/patches/series 
gkrellweather-2.0.8/debian/patches/series
--- gkrellweather-2.0.8/debian/patches/series   2016-11-30 17:19:51.0 
+
+++ gkrellweather-2.0.8/debian/patches/series   2020-10-20 16:10:48.0 
+0100
@@ -1,3 +1,4 @@
 debian-changes.patch
 fix-weather-url.patch
 build-flags.patch
+fix-prefix.patch

Bug#972576: virtualbox-dkms: Virtual box cant run after Kernel Update

[mrminetoons]

Package: virtualbox-dkms
Version: 6.1.14-dfsg-4
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
After update kernel linux to 5.9.0-1-amd64, virtualbox stop to
work and
virtualbox-dkms give-me a lot of erros
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to full remove and install virtualbox, installing and
reinstalling DKMS and dpkg. Also tried to reinstall linux-headers, but
didnt
worked!
   * What was the outcome of this action?
Didnt worked :(
   * What outcome did you expect instead?
A full and complete reinstallation of virtualbox to be able to
use it

thank for helping



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

Kernel: Linux 5.9.0-1-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virtualbox-dkms depends on:
ii  dkms  2.8.3-4

Versions of packages virtualbox-dkms recommends:
iu  virtualbox  6.1.14-dfsg-4

virtualbox-dkms suggests no packages.

-- no debconf information

Bug#972575: npm2deb should search node modules in virtual packages

[Xavier Guimard]

Package: npm2deb
Version: 0.3.0-5
Severity: important

npm2deb currently uses salsa repository to know if a package already
exists or not. This is a bad way because:
 * some node packages are not under pkg-js umbrella (node-almond,...)
 * lintian warns when a package does not declare its modules installed
   in nodejs root directories
 * some packages exists in js-team repo while they've been removed from
   archive

Then I think we should switch to (virtual) package search.

Cheers,
Xavier

Bug#960044: sway: would like to see contrib/grimshot installed

[Birger Schacht]

Hi,

On 10/20/20 2:26 PM, Jonas Smedegaard wrote:
> Package: sway
> Followup-For: Bug #960044
>

It seems the requested tool is already available in Debian package grim.


Nope, the bug report is about this script: 
https://github.com/swaywm/sway/blob/master/contrib/grimshot


I plan to make a separate grimshot binary package at some point

cheers,
Birger


OpenPGP_0xCB06EA7B78DBE151.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#972574: libgit2: consider providing a binary package with libgit2 fixtures for test purposes

[Cédric Boutillier]

Source: libgit2
Version: 1.0.0+dfsg.1-2
Severity: wishlist

Dear Maintainer,

I am in the process of preparing ruby-rugged to work with the new
libgit2 1.0 in experimental. The new upstream version of this package
has new tests relying on the availability of the fixtures provided in
the sourcetree of libgit2.

I was wondering if you would consider providing a binary package with
these fixtures in case other software relying on libgit2 would use them
as part of their testsuite.

Best regards,

Cédric

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

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


signature.asc
Description: PGP signature

Bug#970666: kcemu: Fresh installed package. Kcemu doesn't start.

[John Paul Adrian Glaubitz]

Hello Max!

On 10/20/20 4:47 PM, maX wrote:
>> just have a fresh install of kcemu from debian repositories. Kcemu
>> doesn't start. Error Output:
>>
>> "can't open file '/usr/share/kcemu/roms/kc85/'"
>>
> 
> the debian-package seems to be broken. I've found a port in FreeBSD ports,
> and after the build-process and installation of all dependencies I ran
> into the
> same problems. But I could open a profiles menu (that is available in the
> debian-package as well)
> 
> $ kcemu -P

Just as a heads-up: I cannot ship the ROMs with the Debian package itself as
this is would be against Debian's free software guidelines (DFSG).

As for the bugs with the package itself, I suggest opening a bug report 
upstream [1].

Adrian

> [1] https://github.com/t-paul/kcemu/issues

-- 
 .''`.  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#970666: kcemu: Fresh installed package. Kcemu doesn't start.

[maX]

Hi,


> just have a fresh install of kcemu from debian repositories. Kcemu
> doesn't start. Error Output:
>
> "can't open file '/usr/share/kcemu/roms/kc85/'"
>

the debian-package seems to be broken. I've found a port in FreeBSD ports,
and after the build-process and installation of all dependencies I ran
into the
same problems. But I could open a profiles menu (that is available in the
debian-package as well)

$ kcemu -P

I've found there is no working profile in the Debian package. In FreeBSD
ports
installation the Emulator can start with the VCS80 profile. But even
after loading
the preset ROM-file there is no Output on the emulated LCD-Display. So
there is
no way to see if the emulator is actually running. On any other profile
the result
is the same as described in the cited bug report.

> when giving a path using the -d option:
>
> $ kcemu -d 
>
> ** (kcemu:2547): ERROR **: 23:13:31:951: widget with name
> 'dialog_button_ok' not found!
> Trace/breakpoint trap
>
> when using any directory as , only the /usr/share/kcemu
> directory leads again to the first "can't open file" Error.

The directory given by option "-d" should be the directory of the kcemu
installation. That is not the "roms" directory but it's parent directory:

/usr/share/kcemu

Any other directory that doesn't contain a kcemu installation must fail.


Unresolved remains the error:

> "can't open file '/usr/share/kcemu/roms/kc85/'"

And other "can't open file '/usr/share/kcemu/roms" errors
when starting kcemu with any given profile in debian. Creating
custom profiles with given ROM-images and full path could not
resolve the issue.

I tried to install kcemu in three different environments so far:

 - Kali Linux (the debian package)

 - Arch Linux (build from source)

 - FreeBSD (ports package build from source)

Only the FreeBSD port is able to start an emulator environment.
But without any emulator output.

It seems that kcemu in it's current state is not working with any
system configuration that is up to date in 2020. I might test it
with older systems, when I find some time.

greets

-maX->

On Sun, 20 Sep 2020 23:31:31 + Max
 wrote:

> Package: kcemu
> Version: 0.5.1+git20141014+dfsg-2+b1
> Severity: important
> X-Debbugs-Cc: maximilian.grossm...@studium.fernuni-hagen.de
>
> Dear Maintainer,
>
> Installed the rom-files from sourceforge Package KCemu-0.5.1.tar.gz
> into the Directory /usr/share/kcemu/roms
>
> Still the same Error, although the Directory
>
> /usr/share/kcemu/roms/kc85
>
> is there with all the roms inside.
>
>
> I have no clue how to solve that problem. The file is there and it is an
> directory as it is shipped within the original sourceforge kcemu
source package.
>
> Greets
> -maX->
>
> -- System Information:
> Distributor ID: Kali
> Description: Kali GNU/Linux Rolling
> Release: 2020.3
> Codename: kali-rolling
> Architecture: i686
>
> Kernel: Linux 5.7.0-kali3-686 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_UNSIGNED_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages kcemu depends on:
> ii kcemu-common 0.5.1+git20141014+dfsg-2
> ii libc6 2.31-2
> ii libcairo2 1.16.0-4
> ii libgcc-s1 [libgcc1] 10.2.0-5
> ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5
> ii libglib2.0-0 2.64.4-1
> ii libgtk2.0-0 2.24.32-4

Bug#972573: RFP: crowdsec -- lightweight agent to detect and respond to bad behaviours. It also automatically benefits from our global community-wide IP reputation database

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: crowdsec
  Version : 0.3.5
  Upstream Author : Crowd Security
* URL : https://crowdsec.net/
* License : MIT/Expat?
  Programming Lang: Golang
  Description : lightweight agent to detect and respond to bad behaviours

Crowdsec is an open-source, lightweight software, detecting peers with
aggressive behaviors to prevent them from accessing your systems. Its
user friendly design and assistance offers a low technical barrier of
entry and nevertheless a high security gain.

Processing is done in 5 steps:

 1. Read Data sources (log files, streams, trails, messages ...),
normalize and enrich signals
 
 2. Matching those signals to behavior patterns, aka scenarios (*)
 
 3. If an unwanted behavior is detected, deal with it through a
bouncer : a software component integrated into your applicative
stack that supports various remediations such as block, return
403, and soon captcha, 2FA, etc.

 4. (ONLY) The aggressive IP, the scenario name triggered and a
timestamp is then sent to our curation platform (to avoid
poisoning & false positives)

 5. If verified, this IP is then integrated to the block list
continuously distributed to all CrowdSec clients (which is used as
an enrichment source in step 1)

By detecting, blocking and sharing the threat they faced, all clients
are reinforcing each-others (hence the name Crowd-Security). Crowdsec
is designed for modern infrastructures, with its "Detect Here, Remedy
There" approach, letting you analyse logs coming from several sources
in one place and block threats at various levels (applicative, system,
infrastructural) of your stack.

(*) CrowdSec ships by default with scenario (brute force, port scan,
web scan, etc.) adapted for most context, but you can easily extend it
by picking more of them from the hub. It is also very easy to adapt an
existing one or create one yourself.



This is similar to fail2ban and sshguard, but with the extra touch
that it allows for federation and distribution of blocklists. It also
integrates with Prometheus, also packaged in Debian.

I haven't tested it. I guess it could be maintained by the Go team?

Source code is available here: https://github.com/crowdsecurity/crowdsec

The software is free (MIT), but to get access to the crowd-sourced
reputation data, you must also share it. The server-side of things is
also non-free.

Bug#972572: emacs-gtk: scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

Note also that there is no such issue on Debian 10 (buster).

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

Bug#972572: emacs-gtk: scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

Package: emacs-gtk
Version: 1:27.1+1-1
Severity: normal

Create a file with:

  printf "%d\n" `seq 1000` > file

and open it with "emacs -q" (the issue is not reproducible with -Q).
Go to the end of the file with ESC > then scroll upward with the mouse
wheel (button 4) several times. When the cursor needs repositioning,
this actually scrolls downward, probably because Emacs tries to center
the mouse cursor instead of letting it at the bottom.

No such issue with the other way round, where the cursor remains at
the top.

No such issue with "emacs -Q", where the cursor remains at the bottom.
This should be how Emacs should behave with the site-wide startup file.

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common1:27.1+1-1
ii  emacs-common1:27.1+1-1
ii  libacl1 2.2.53-8
ii  libasound2  1.2.3.2-1
ii  libc6   2.31-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.20-1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-3
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libgif7 5.1.9-1
ii  libglib2.0-02.66.1-2
ii  libgmp102:6.2.0+dfsg-6
ii  libgnutls30 3.6.15-4
ii  libgpm2 1.20.7-6
ii  libgtk-3-0  3.24.23-2
ii  libharfbuzz0b   2.6.7-1
ii  libice6 2:1.0.10-1
ii  libjansson4 2.13.1-1
ii  libjpeg62-turbo 1:2.0.5-1.1
ii  liblcms2-2  2.9-4+b1
ii  libm17n-0   1.8.0-2
ii  libotf0 0.9.13-7
ii  libpango-1.0-0  1.46.2-1
ii  libpng16-16 1.6.37-3
ii  librsvg2-2  2.50.1+dfsg-1
ii  libselinux1 3.1-2+b1
ii  libsm6  2:1.2.3-1
ii  libsystemd0 246.6-2
ii  libtiff54.1.0+git191117-2
ii  libtinfo6   6.2+20200918-1
ii  libx11-62:1.6.12-1
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-2
ii  libxml2 2.9.10+dfsg-6.1
ii  libxrender1 1:0.9.10-1
ii  zlib1g  1:1.2.11.dfsg-2

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
ii  emacs-common-non-dfsg  1:26.3+1-1

-- no debconf information

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

Bug#972571: mmtarfilter triggers https://bugs.debian.org/606756

[Trent W. Buck]

Package: mmdebstrap
Version: 0.7.1-2
Severity: minor
Tags: upstream

Hi josch,

Per our IRC chat, I found tarfilter stuff[0] triggers a regression of old dash 
bug #606756.

[0] 
https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/465c0564345b456c41016abc6a4b1cb727125961

I narrowed it down with this test command:

git bisect start 0.7.1 0.6.1
git bisect run ./mmdebstrap --quiet --mode=unshare --variant=apt 
--dpkgopt=path-exclude='/usr/share/man/*' stable /dev/null

...that relies on mmtarfilter being in $PATH, so you will need mmdebstrap 0.7.x 
package installed.

Attached are some files:

  git-bisect.log - a log of the git bisect
  bad.log- a log of the actual error (from dpkg.postinst)
  workaround.log - a log of a minimal workaround
  tar-t.log  - a log of showing the final tarball's contents with different 
commits & options

I think the last one shows a clear difference between tarfilter and dpkg's 
built-in exclusions.

Note both your original "reinstall essential" strategy, and your newer
tarfilter strategy are THEMSELVES workarounds for THIS bug in dpkg:

https://bugs.debian.org/603700
twb@not-omega:~/mmdebstrap$ git bisect start 0.7.1 0.6.1
Bisecting: 50 revisions left to test after this (roughly 6 steps)
[112c0a5a6d36406439aadfa65b3e78a8ed02963e] add documentation about 
--{setup,extract,essential,customize}-hooks and --skip option, making them an 
official interface
twb@not-omega:~/mmdebstrap$ git bisect run ./mmdebstrap --quiet --mode=unshare 
--variant=apt --dpkgopt=path-exclude='/usr/share/man/*' stable /dev/null
running ./mmdebstrap --quiet --mode=unshare --variant=apt 
--dpkgopt=path-exclude=/usr/share/man/* stable /dev/null
Bisecting: 25 revisions left to test after this (roughly 5 steps)
[df18304449cc407f57f9dd50ec890ed52cf9fa6a] add a new pipe to communicate the 
number of blocks to the parent instead of abusing the hookhelper/listener
running ./mmdebstrap --quiet --mode=unshare --variant=apt 
--dpkgopt=path-exclude=/usr/share/man/* stable /dev/null
dpkg: error: unknown option --robot

Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or 'more' !
Bisecting: 12 revisions left to test after this (roughly 4 steps)
[7c752fa8a0291c38972f1ec5163c8a9c56b52916] print elapsed time after successful 
run
running ./mmdebstrap --quiet --mode=unshare --variant=apt 
--dpkgopt=path-exclude=/usr/share/man/* stable /dev/null
dpkg: error: unknown option --robot

Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or 'more' !
E: run_chroot failed: E: env --unset=APT_CONFIG --unset=TMPDIR /usr/sbin/chroot 
/tmp/mmdebstrap.dbUMQwTXj5 env --unset=TMPDIR dpkg --install --force-depends 
--status-fd=<$fd> /var/cache/apt/archives//sysvinit-utils_2.93-8_amd64.deb 
/var/cache/apt/archives//ncurses-base_6.1+20181013-2+deb10u2_all.deb 
/var/cache/apt/archives//libc-bin_2.28-10_amd64.deb 
/var/cache/apt/archives//init-system-helpers_1.56+nmu1_all.deb 
/var/cache/apt/archives//base-passwd_3.5.46_amd64.deb 
/var/cache/apt/archives//libdebconfclient0_0.249_amd64.deb 
/var/cache/apt/archives//apt_1.8.2.1_amd64.deb 
/var/cache/apt/archives//libseccomp2_2.3.3-4_amd64.deb 
/var/cache/apt/archives//libgnutls30_3.6.7-4+deb10u5_amd64.deb 
/var/cache/apt/archives//libtasn1-6_4.13-3_amd64.deb 
/var/cache/apt/archives//libp11-kit0_0.23.15-2_amd64.deb 
/var/cache/apt/archives//libffi6_3.2.1-9_amd64.deb 
/var/cache/apt/archives//libidn2-0_2.0.5-1+deb10u1_amd64.deb 
/var/cache/apt/archives//libunistring2_0.9.10-1_amd64.deb 
/var/cache/apt/archives//libhogweed4_3.4.1-1_amd64.deb 
/var/cache/apt/archives//libnettle6_3.4.1-1_amd64.deb 
/var/cache/apt/archives//libgmp10_2%3a6.1.2+dfsg-4_amd64.deb 
/var/cache/apt/archives//libapt-pkg5.0_1.8.2.1_amd64.deb 
/var/cache/apt/archives//libzstd1_1.3.8+dfsg-3_amd64.deb 
/var/cache/apt/archives//libstdc++6_8.3.0-6_amd64.deb 
/var/cache/apt/archives//debian-archive-keyring_2019.1_all.deb 
/var/cache/apt/archives//gpgv_2.2.12-1+deb10u1_amd64.deb 
/var/cache/apt/archives//adduser_3.118_all.deb 
/var/cache/apt/archives//passwd_1%3a4.5-1.1_amd64.deb 
/var/cache/apt/archives//libsemanage1_2.8-2_amd64.deb 
/var/cache/apt/archives//libsepol1_2.8-1_amd64.deb 
/var/cache/apt/archives//libsemanage-common_2.8-2_all.deb 
/var/cache/apt/archives//util-linux_2.33.1-0.1_amd64.deb 
/var/cache/apt/archives//fdisk_2.33.1-0.1_amd64.deb 
/var/cache/ap

Bug#972524: [Pkg-nagios-devel] Bug#972524: monitoring-plugins: FTBFS on buster (dh_compress)

[Sebastiaan Couwenberg]

On 10/20/20 1:55 PM, Jakob Bohm wrote:
> On 2020-10-20 06:05, Sebastiaan Couwenberg wrote:
>> Control: tags -1 unreproducible
>> Control: severity -1 important
>>
>> Hi Jakob,
>>
>> Thanks for reporting this issue, but unfortunately I cannot reproduce it.
>>
>> Building 2.2-6 in a buster chroot works as expected:
>>
>>   gbp clone \
>>   https://salsa.debian.org/nagios-team/pkg-monitoring-plugins.git
>>   git checkout -b buster debian/2.2-6
>>   gbp buildpackage --git-pbuilder \
>>    --git-dist=buster \
>>    --git-debian-branch=buster
>>
>> Kind Regards,
>>
>> Bas
>>
> 
> Did your test include the use of backported packages, as stated?

No, just plain buster.

Note that 2.2-6 still uses a deprecated debhelper compat level, this has
been changed in git.

If you need a backport for buster, you may need to cherry-pick some
unreleased commits from the master branch.

> When checking out from git, I didn't select any specific branch, as the
> "please use the git source" message just said to clone the tree, thus HEAD.
> 
> Also, I notice that your build commands differ from mine, what is "gbp"?

git-buildpackage, it's the tools we use to build packages from the git
repo. See:

 https://wiki.debian.org/PackagingWithGit

Or a more specific guide that includes setting up the cowbuilder chroots:

 https://debian-gis-team.pages.debian.net/policy/packaging.html#git-pbuilder

> As a local sysadmin, I don't have my own installs of automated build
> daemons such as pbuilder.

pbuilder & cowbuilder are not automated build daemons, they are chroot
environments to ensure that the package is built in a clear environment
just like on the official build daemons (which use sbuild instead of
pbuilder).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#972567: lintian: Fatal errors including 'Cannot run origtar check on package source'

[Felix Lechner]

Control: forcemerge 970750 -1

Hi Hugh,

On Tue, Oct 20, 2020 at 4:51 AM Hugh McMaster  wrote:
>
> Lintian exits with fatal errors when attempting to check Freetype 
> 2.10.2+dfsg-3

These serious internal errors relate to different conditions in the
packaging of upstream sources. We left the messages for the public to
catch all corner cases, but the errors are not fatal. You can see that
in the last two lines of your log:

N: 5 tags overridden (5 info)
Finished running lintian.

Since the issue affects only 5 checks out of 208 (and only a small
share of packages) Lintian is still usable, although the output is
admittedly confusing. Thanks for reporting the issue!

Kind regards,
Felix Lechner

Bug#971989: unblock: thunderbird/1:78.3.2-1

[Carsten Schoenert]

Hello Michael,

Am 20.10.20 um 14:54 schrieb Michael Biebl:
> Shouldn't we rather wait, until such an updated enigmail package is
> available? I see, that the enigmail package has a bug report with
> attached patches, maybe it's time to NMU (that said, I've explicitly
> CCed Daniel, maybe he can chime in here)
> 
> I don't think forcing TB 78 into testing is the answer, your users would
> be quite unhappy.

I personally think that we already break the user experience as we
released TB for buster through stable-security and some days ago also
for LTS users. So I see no need to wait any longer. Currently the
upgrade path for buster users is at least broken for Thunderbird.

I assume users of Debian testing are mostly more experienced than the
addressed users for stable. Besides of that TB 1:78.x has a breaks on
Enigmail << 2:2.2.0~ and the migration testing scripts currently doesn't
care about that. It might be that the control version handling needs
some more fine tuning, if so I'm happy to adjust that.

-- 
Regards
Carsten Schoeert

Bug#971989: unblock: thunderbird/1:78.3.2-1

[Michael Biebl]

Am 20.10.20 um 15:42 schrieb Carsten Schoenert:
> Hello Michael,
> 
> Am 20.10.20 um 14:54 schrieb Michael Biebl:
>> Shouldn't we rather wait, until such an updated enigmail package is
>> available? I see, that the enigmail package has a bug report with
>> attached patches, maybe it's time to NMU (that said, I've explicitly
>> CCed Daniel, maybe he can chime in here)
>>
>> I don't think forcing TB 78 into testing is the answer, your users would
>> be quite unhappy.
> 
> I personally think that we already break the user experience as we
> released TB for buster through stable-security and some days ago also
> for LTS users. So I see no need to wait any longer. Currently the
> upgrade path for buster users is at least broken for Thunderbird.

I guess the solution for that is to upload enigmail 2.2 as quickly as
possible to stable(-security).
It is not justification to break more stuff.

Fwiw, I'm willing to NMU enigmail, if there is no progress on #970111.

Bug#972570: node-lightgallery is built using minified files

[Xavier Guimard]

Package: node-lightgallery
Version: 1.6.11+dfsg-1
Severity: serious
Justification: 4

Hi,

debian/source/lintian-overrides overwrites some real problems: the
"concat" part of Gulpfile uses modules/* files which are all obfuscated
using minification (downloaded from distinct sources).
A possible solution could be to ignore modules/* files during import and
add related components using uscan components (with a build).

Bug#972483: patch (gentoo bug 747946)

[di dit]

Applying the patch referenced below to the last file only
(/usr/src/virtualbox-6.1.14/r0drv/linux/thread2-r0drv-linux.c) fixed the
issue for me:
  https://747946.bugs.gentoo.org/attachment.cgi?id=664933

Bug#972559: perl: please make the build mostly reproducible

[Niko Tyni]

On Tue, Oct 20, 2020 at 10:55:23AM +0100, Chris Lamb wrote:
> Source: perl
> Version: 5.30.3-4
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> Hi,
>  
> Whilst working on the Reproducible Builds effort [0] we noticed that
> perl could not be built reproducibly.
> 
> This is because it ships a number of build-related header files that
> include the build path in various guises. Assuming these files are
> actually useful in the binary package, a patch is attached that
> sanitises these in debian/rules prior to the final creation of the .deb.

Thanks! For some reason I thought this was a wider issue than
just those files.

The config.h and Config_heavy.pl files are definitely useful and
necessary. The config.sh.* files are part of our hacky cross build
support, and we seem to be stuck with them until somebody implements
cross build safe configure probes upstream. Mangling the build directory
in all of them should be fine, though I worry a bit about short build
paths potentially matching some other data in the files. But I guess
that's mostly theoretical.

I'm uneasy with using $(CURDIR) as a regexp in sed.  Similar usage in the
past led to #585678. Given '+' is not special in sed regexps, this is not
quite as bad, but still not ideal.  An option is to say
  $(PERL_TO_USE) -pi -e 's/\Q$(CURDIR)\E/.../'
like we do elsewhere in the rules already.

> To be clear, Perl is not entirely reproducible with this change — I
> need to address the variations added between a /usr-merged system and
> one that is not. That part should be incoming soon.

Cool, thanks again.

We're currently waiting for a transition slot for perl 5.32, so this
may have to wait until after that. Feel free to poke if nothing happens.
-- 
Niko

Bug#972568: systemd in buster has issues with kernel >= 5.8

[Andrei POPESCU]

Control: forcemerge 964926 -1
Control: affects 964926 ansible

On Ma, 20 oct 20, 14:18:09, Michael Biebl wrote:
> Am 20.10.20 um 13:58 schrieb Andrei POPESCU:
> 
> Duplicate of #964926 afaics.

Indeed, sorry for not noticing.

> Would you be willing to test the current changes in
> https://salsa.debian.org/systemd-team/systemd/-/commits/debian/buster/
> specifically 4bdc4f8c and efe7d941 and confirm they fix all issues you
> have with the new kernel?
 
Just installed 246.6-2~bpo10+1 and I can confirm it works as expected.

Didn't notice this as I got confused by the output of rmadison (which 
shows armhf still has 245.6, but the system in question is running 
arm64).

> Those changes are scheduled to be part of the next stable release.

\o/

I'll try to remember to test this as soon as available in 
-proposed-updates.

Kind regards and sorry again for the noise,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#971989: unblock: thunderbird/1:78.3.2-1

[Michael Biebl]

Am 11.10.20 um 10:21 schrieb Carsten Schoenert:

> So I'd like to suggest to remove (if this is possible) the auto
> migration testing of enigmail and jsunit against thunderbird. At least
> please allow the migration of the Thunderbird related packages into
> testing. I'm condidering removal requests for enigmail and jsunit in
> testing.

Shouldn't we rather wait, until such an updated enigmail package is
available? I see, that the enigmail package has a bug report with
attached patches, maybe it's time to NMU (that said, I've explicitly
CCed Daniel, maybe he can chime in here)

I don't think forcing TB 78 into testing is the answer, your users would
be quite unhappy.

Regards,
Michael

Bug#972566: python3-opencv: build python extensions for all supported python versions

[Jochen Sprickerhof]

Hi Drew,

* Drew Parsons  [2020-10-20 20:10]:
Not as simple as "Build-Depends: python3-all-dev", then.  Not built by 
pybuild.


pybuild has cmake support, you can set it using PYBUILD_SYSTEM=cmake. 
See ros-ros-comm for an example.


Ping me if you need help with it.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#971989: unblock: thunderbird/1:78.3.2-1

[Julien Cristau]

Hi Carsten,

can you explain the jsunit situation a bit more?  As far as I can tell the 
issue is:

(thunderbird:2216): Gtk-WARNING **: 09:59:23.024: Could not load a pixbuf from 
/org/gtk/libgtk/theme/Adwaita/assets/bullet-symbolic.svg.

showing up on stderr during the test, e.g. in 
https://ci.debian.net/data/autopkgtest/unstable/amd64/j/jsunit/6983431/log.gz

Is a bug tracking this issue?

Cheers,
Julien

On Sun, Oct 11, 2020 at 10:21:01AM +0200, Carsten Schoenert wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package thunderbird
> 
> The automatic migration testing for Thunderbird is containing some tests
> for the packages jsunit and enigmail which currently prevents the
> automatic migration of the thunderbird package to testing because the
> tests are failing.
> 
> The enigmail package needs to be available in at least version 2.2 to
> give a useful user experience. Thunderbird has included a version
> requirement on enigmail that 2.2 is required.
> This requirement can't get fulfilled currently in Debian unstable or
> testing because the maintainers of the Enigmail package didn't prepared
> and upoaded until now a new version.
> There is s wishlist bug for updating enigmail to the most recent
> version since a few weeks.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970111
> 
> The jsunit package is now also outdated and must fail against the
> current Thunderbird versions.
> 
> So far I've no feedback from the enigmail maintainers, they got involved
> within the communication with the security team while the upload of
> thunderbird for stable/security got prepared.
> 
> The currently also reported uninstallability for the package
> webext-exteditor/2.0.4-1 is intended as this version isn't working with
> Thunderbird >= 78.
> 
> So I'd like to suggest to remove (if this is possible) the auto
> migration testing of enigmail and jsunit against thunderbird. At least
> please allow the migration of the Thunderbird related packages into
> testing. I'm condidering removal requests for enigmail and jsunit in
> testing.
> 
> Regards
> Carsten
> 
> unblock thunderbird/1:78.3.2-1
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, aarch64, arm64
> 
> Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 

Bug#960044: sway: would like to see contrib/grimshot installed

[Jonas Smedegaard]

Package: sway
Followup-For: Bug #960044

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It seems the requested tool is already available in Debian package grim.

Am I missing something, or should this bugreport simply be closed?


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+O15MACgkQLHwxRsGg
ASGlWA//a4ayZbGB8aXxIHR8mUQ5VV9G5H7aZB+5g4fRg3bRvcSKY3xq0m0a6XWd
dW+2A0QvxtoHnjDP5O64prEUIwtndLt9Ak55+bidTmQd2KNDFeD9RUGoG8OR54vP
xngcRNPDkfpbcPgm+tANWc2ZPGqZOODksrd6zaror/u97KpPMTdDlGxumMBHViDY
3JfjELrtZOVP6WCFuob620Izjn489w2QhjodcysCjD+x9IdqtTpbKGqDpRkQT1+Z
BeXi8VvuCjW99iKobuei49i015F4SXuTI12SpI8vccsIDUCH+E6haO4eT3ogf8C+
hZx0XqPp6nHHf263cqObHlkelIW/RNP8DiGT6pkpvDTn0mJnC/H+npGaC662emcI
UjTscRaxoDfECR0tfc+n+w0ksmWgvUzHD0fmpM4sZP+vK54YFvoBCOXFIcUnHIl+
s2nUWnEY4OnZv31mgPCtKkHa/Qd6m5qyMuueAG+x2peA7HIX7l/1EpUp4GVPwLQx
aVXKiYHG+xoC6JFbc0UUwRqceS/D27y807X4lm6UsBCFln2YGeHLJAoFUW4JONG6
hU/c/TTgAxtLfziEEfNwFmJKlxgKgrz1vCrKOWBN7gYKoEk8ZjYNvGIplwkICaz3
YYzjPJO7WEBtuFLZGl3UZb4t55/0FlcdWXRqYPDlivPgotQGyLU=
=qi9e
-END PGP SIGNATURE-