Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Felix Lechner]

Hi Russ,

On Wed, Jul 1, 2020 at 9:55 PM Russ Allbery  wrote:
>
> I'm not active and don't want to second-guess how
> you're handling things.

Thank you for writing that. I have likewise been reluctant to comment
on the good work of past maintainers.

> But I guess I'll say here that I think the point
> of a linter is externalized good taste.  It's a codification of good
> judgment calls about the way to construct a package.

I actually exercise relatively little judgment, at least by Debian
standards. On the contrary, I try to accommodate every bug filer, but
it is hard. People have so many expectations and styles. And often, my
solutions are not appreciated.

> I should have, and probably the answer is that I didn't read it in any
> detail.

It's never too late. I am happy to change the check, or to drop it
entirely, if you can figure out the original problem. It may involve
tools with which I am unfamiliar.

> That said, I think the way I would have interpreted that bug would have
> been to warn about symlinks inside /usr/lib to outside of /usr/lib.

That seems to be the consensus between Sergei, Chris and myself. It's
also what the check does now.

> looking at it now, I'm not sure what problem that would cause and
> therefore what purpose would be served by warning about it.

I am not sure, either. Perhaps a future bug report will tell.

> In general, I wouldn't assume that all the old bugs are valid or
> interesting.

After some reflection, I found that the most defensible way to close
feature requests is to implement them.

On a personal note, thanks for your book reviews. I serve as a library
commissioner in a town near you, and enjoyed reading them.

Kind regards
Felix Lechner

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Russ Allbery]

Felix Lechner  writes:
> On Wed, Jul 1, 2020 at 8:16 PM Russ Allbery  wrote:

>> I'm puzzled by why you would have changed Lintian in response to that
>> bug, given that the reported problem was only with Lintian and was
>> fixed sixteen years ago.

> I am just working through open bugs.

I didn't reply to an earlier discussion where you said something similar
because you're doing a ton of excellent work on Lintian and making a lot
of forward progress.  I'm not active and don't want to second-guess how
you're handling things.  But I guess I'll say here that I think the point
of a linter is externalized good taste.  It's a codification of good
judgment calls about the way to construct a package.  That means judgment
calls about whether a given suggestion is good taste or important always
felt to me like a significant part of the work.

> Why did you not voice your opposition as a maintainer during the past
> seventeen years, or close the bug?

I should have, and probably the answer is that I didn't read it in any
detail.  Lintian always had between 200 and 400 bugs when I was working on
it, and my work style was generally to pick a bug and work on it until I
could close it, rather than going through all of the bugs.  I also
prioritized newer bugs over older bugs.

That said, I think the way I would have interpreted that bug would have
been to warn about symlinks inside /usr/lib to outside of /usr/lib.  On
first glance, I might have thought that might be reasonable, although
looking at it now, I'm not sure what problem that would cause and
therefore what purpose would be served by warning about it.

In general, I wouldn't assume that all the old bugs are valid or
interesting.  I don't think I ever did a great job of triage, particularly
on older stuff.

-- 
Russ Allbery (r...@debian.org)  

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Felix Lechner]

Hi Russ,

On Wed, Jul 1, 2020 at 8:16 PM Russ Allbery  wrote:
>
> I'm puzzled by why you would have changed Lintian in response to that bug,
> given that the reported problem was only with Lintian and was fixed
> sixteen years ago.

I am just working through open bugs. Why did you not voice your
opposition as a maintainer during the past seventeen years, or close
the bug?

Kind regards
Felix Lechner

Bug#963605: ITP: python-language-server - Python implementation of the Language,Server Protocol

[Pablo Mestre]

Hi Drew Parsons,

I would be happy to take the task...

Im working already on this pkg

P.

Bug#964117: python3-pip: pip fails to list all outdated packages

[Vipul]

Package: python3-pip
Version: 18.1-5
Severity: normal

Dear Maintainer,

I'm was trying to list all outdated packages using `pip3 list
--outdated` command, but I'm getting following error message:

$ pip3 list --outdated
Exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 
143, in main
status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line 
138, in run
packages = self.get_outdated(packages, options)
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line 
149, in get_outdated
dist for dist in self.iter_packages_latest_infos(packages, options)
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line 
150, in 
if dist.latest_version > dist.parsed_version
TypeError: '>' not supported between instances of 'Version' and 'Version'

I cannot reproduce this issue on latest version of pip (i.e. 20.1.1,
source https://pypa.org), but haven't tested it on Testing's (aka
Bullseye) pip3 package (i.e. 20.1.1). From error message it looks like
problem is in package itself.


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

Versions of packages python3-pip depends on:
ii  ca-certificates20200601~deb10u1
ii  python-pip-whl 18.1-5
ii  python33.7.3-1
ii  python3-distutils  3.7.3-1

Versions of packages python3-pip recommends:
ii  build-essential 12.6
ii  python3-dev 3.7.3-1
ii  python3-setuptools  40.8.0-1
ii  python3-wheel   0.32.3-2

python3-pip suggests no packages.

-- no debconf information

Bug#964116: mailman3-web: mailman-web.py config file falsely says you can enable Django admin documentation

[AJ Jordan]

Package: mailman3-web
Version: 0+20180916-8
Severity: normal

/etc/mailman/mailman-web.py contains the following snippet in
INSTALLED_APPS:

# Uncomment the next line to enable admin documentation:
#'django.contrib.admindocs',

but the comment is inaccurate. Uncommenting it does not produce a
documentation link in the upper-right hand corner of the Django admin
interface.

Installing the `python3-docutils` Debian package does not help.

See https://docs.djangoproject.com/en/3.0/ref/contrib/admin/admindocs/
for requirements for this mechanism.

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

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

Versions of packages mailman3-web depends on:
ii  dbconfig-mysql 2.0.11+deb10u1
ii  debconf [debconf-2.0]  1.5.71
ii  lsb-base   10.2019051400
ii  node-less  1.6.3~dfsg-3
ii  python33.7.3-1
ii  python3-django-hyperkitty  1.2.2-1
ii  python3-django-postorius   1.2.4-1
ii  python3-mysqldb1.3.10-2
ii  python3-psycopg2   2.7.7-1
ii  python3-whoosh 2.7.4+git6-g9134ad92-4
ii  sassc  3.5.0-1
ii  ucf3.0038+nmu1
ii  uwsgi  2.0.18-1
ii  uwsgi-plugin-python3   2.0.18-1

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.4.38-3+deb10u3

Versions of packages mailman3-web suggests:
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.22-0+deb10u1
ii  postgresql  11+200+deb10u3

-- Configuration Files:
/etc/mailman3/uwsgi.ini changed [not included]

-- debconf information:
  mailman3-web/pgsql/authmethod-user: password
  mailman3-web/upgrade-error: abort
  mailman3-web/remove-error: abort
  mailman3-web/pgsql/authmethod-admin: ident
  mailman3-web/dbconfig-remove: true
  mailman3-web/remote/host: localhost
* mailman3-web/emailname: lists.strugee.net
  mailman3-web/pgsql/method: TCP/IP
  mailman3-web/remote/port: 3306
  mailman3-web/passwords-do-not-match:
  mailman3-web/remote/newhost:
  mailman3-web/pgsql/manualconf:
  mailman3-web/missing-db-package-error: abort
* mailman3-web/dbconfig-reinstall: false
  mailman3-web/db/app-user: mailman3web@localhost
* mailman3-web/mysql/admin-user: debian-sys-maint
* mailman3-web/superuser-mail: a...@strugee.net
  mailman3-web/db/dbname: mailman3web
  mailman3-web/db/basepath: /var/lib/mailman3/web
* mailman3-web/dbconfig-install: true
* mailman3-web/restart-webserver: false
  mailman3-web/mysql/method: Unix socket
  mailman3-web/internal/skip-preseed: false
  mailman3-web/pgsql/admin-user: postgres
  mailman3-web/pgsql/changeconf: false
* mailman3-web/database-type: mysql
  mailman3-web/purge: false
  mailman3-web/dbconfig-upgrade: true
* mailman3-web/superuser-name: alex
* mailman3-web/configure-webserver: apache2
  mailman3-web/nginx-choice:
  mailman3-web/internal/reconfiguring: false
  mailman3-web/pgsql/no-empty-passwords:
  mailman3-web/upgrade-backup: true
  mailman3-web/install-error: abort

Bug#964115: Web browser video playback broken in bullseye

[Ryan Goodfellow]

Package: bugs.debian.org
Severity: important

Dear Maintainer,

Video playback does not seem to be working in any browser in Debian
Bullseye.

   * What led up to the situation?

apt update
apt dist-upgrade

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

Attempted to play YouTube videos from any browser.

   * What was the outcome of this action?

- Chromium crashes, which seems to be related to ffmpeg 4.3
  (https://bugs.chromium.org/p/chromium/issues/detail?id=1095962)
- Chrome and Firefox play video at an infinitesimal rate

   * What outcome did you expect instead?

YouTube videos play without crashing and at a normal rate.



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

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

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Russ Allbery]

Felix Lechner  writes:
> On Wed, Jul 1, 2020 at 1:33 AM Sergei Golovan  wrote:

>> Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
>> so I would say that this warning is spurious.

> I am not sure who is right, but the warning is not spurious from the
> perspective of the original requestor. Bug#243158 cited a scenario very
> much like yours as the reason for why the dynamic linker was confused.

> Those links also never left /usr/lib.

I'm puzzled by why you would have changed Lintian in response to that bug,
given that the reported problem was only with Lintian and was fixed
sixteen years ago.

What problem is this tag trying to address?

-- 
Russ Allbery (r...@debian.org)  

Bug#964113: RFS: materia-kde/20200614-1 [ITP] -- Port of the popular GTK theme Materia for Plasma 5

[Leandro Cunha]

Dear mentors,

The code is in my Salsa repository until the creation of the mentioned VCS
and I am not allowed to access the project file. After that, the work will
be centered on the informed VCS.

[0] https://salsa.debian.org/leandrocunha/materia-kde

Regards,
 --
Leandro Cunha

Em qua., 1 de jul. de 2020 às 22:27, Leandro Cunha <
leandrocunha...@gmail.com> escreveu:

> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "materia-kde"
>
>  * Package name: materia-kde
>Version : 20200614-1
>Upstream Author : Alexey Varfolomeev 
>  * URL : https://github.com/PapirusDevelopmentTeam/materia-kde
>  * License : GPL-3
>  * Vcs : https://salsa.debian.org/debian/materia-kde
>Section : kde
>
> It builds those binary packages:
>
>   materia-kde - Port of the popular GTK theme Materia for Plasma 5
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/materia-kde
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/m/materia-kde/materia-kde_20200614-1.dsc
>
> Changes since the last upload:
>
>* Initial release (Closes: #944829).
>* debian/control:
>  - Multiarch metadata for this package.
>
> Regards,
>
> --
>   Leandro Cunha
>
>

Bug#964114: replace make output parsing with remake

[Joey Hess]

Package: debhelper
Version: 13.1
Severity: wishlist

I learned of remake today. remake --targets simply lists all the
explicit targets of a makefile.

debhelper contains a much more ugly and fragile way to do it, in
rules_explicit_target. I have never been happy about that, and if I were
maintaining debhelper today, I'd replace that with a use of remake.

It might also work out to replace exists_make_target with remake. That
function is even more horrible (see long comment above it). But, remake
only lists *explict* targets, which could be a problem if some makefile
has an implicit target for "install" or "test" or "clean". I'm stuggling
to imagine a reasonable makefile that does, but it's at least
theoretically possible.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#964113: RFS: materia-kde/20200614-1 [ITP] -- Port of the popular GTK theme Materia for Plasma 5

[Leandro Cunha]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "materia-kde"

 * Package name: materia-kde
   Version : 20200614-1
   Upstream Author : Alexey Varfolomeev 
 * URL : https://github.com/PapirusDevelopmentTeam/materia-kde
 * License : GPL-3
 * Vcs : https://salsa.debian.org/debian/materia-kde
   Section : kde

It builds those binary packages:

  materia-kde - Port of the popular GTK theme Materia for Plasma 5

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

  https://mentors.debian.net/package/materia-kde

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/materia-kde/materia-kde_20200614-1.dsc

Changes since the last upload:

   * Initial release (Closes: #944829).
   * debian/control:
 - Multiarch metadata for this package.

Regards,

--
  Leandro Cunha

Bug#964112: collectd: [patch] update debian/watch

[McIntyre, Vincent (CASS, Marsfield)]

Source: collectd
Version: [patch] update debian/watch
Severity: minor
Tags: patch

The naming scheme for github tags seems to differ from collectd.org.

diff --git a/debian/watch b/debian/watch
index 5ba76a4..a07f606 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,2 @@
 version=3
-https://github.com/collectd/collectd/tags 
/collectd/collectd/archive/stable-([0-9.-]+).tar.gz
+https://github.com/collectd/collectd/tags 
/collectd/collectd/archive/(collectd|stable)-([0-9.-]+).tar.gz

% uscan -v
uscan info: uscan (version 2.19.5+deb10u1) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="collectd" version="5.11.0-3" (as seen in debian/changelog)
uscan info: package="collectd" version="5.11.0" (no epoch/revision)
uscan info: ./debian/changelog sets package="collectd" version="5.11.0"
uscan info: Process watch file at: debian/watch
package = collectd
version = 5.11.0
pkg_dir = .
uscan info: Last orig.tar.* tarball version (from debian/changelog): 5.11.0
uscan info: Last orig.tar.* tarball version (dversionmangled): 5.11.0
uscan info: Requesting URL:
   https://github.com/collectd/collectd/tags
uscan info: Matching pattern:
   
(?:(?:https://github.com)?\/collectd\/collectd\/tags)?/collectd/collectd/archive/(collectd|stable)-([0-9.-]+).tar.gz
uscan info: Found the following matching hrefs on the web page (newest first):
   /collectd/collectd/archive/collectd-5.11.0.tar.gz (collectd.5.11.0) 
index=collectd.5.11.0-1
   /collectd/collectd/archive/collectd-5.10.0.tar.gz (collectd.5.10.0) 
index=collectd.5.10.0-1
   /collectd/collectd/archive/collectd-5.9.2.tar.gz (collectd.5.9.2) 
index=collectd.5.9.2-1
   /collectd/collectd/archive/collectd-5.9.1.tar.gz (collectd.5.9.1) 
index=collectd.5.9.1-1
   /collectd/collectd/archive/collectd-5.9.0.tar.gz (collectd.5.9.0) 
index=collectd.5.9.0-1
   /collectd/collectd/archive/collectd-5.8.1.tar.gz (collectd.5.8.1) 
index=collectd.5.8.1-1
   /collectd/collectd/archive/collectd-5.8.0.tar.gz (collectd.5.8.0) 
index=collectd.5.8.0-1
   /collectd/collectd/archive/collectd-5.6.3.tar.gz (collectd.5.6.3) 
index=collectd.5.6.3-1
   /collectd/collectd/archive/collectd-2.0.1.tar.gz (collectd.2.0.1) 
index=collectd.2.0.1-1
uscan info: Looking at $base = https://github.com/collectd/collectd/tags with
$filepattern = 
/collectd/collectd/archive/(collectd|stable)-([0-9.-]+).tar.gz found
$newfile = /collectd/collectd/archive/collectd-5.11.0.tar.gz
$newversion  = collectd.5.11.0 which is newer than
$lastversion = 5.11.0
uscan info: Matching target for downloadurlmangle: 
https://github.com/collectd/collectd/archive/collectd-5.11.0.tar.gz
uscan info: Upstream URL(+tag) to download is identified as
https://github.com/collectd/collectd/archive/collectd-5.11.0.tar.gz
uscan info: Filename (filenamemangled) for downloaded file: 
collectd-5.11.0.tar.gz
uscan: Newest version of collectd on remote site is collectd.5.11.0, local 
version is 5.11.0
uscan:=> Newer package available from
  https://github.com/collectd/collectd/archive/collectd-5.11.0.tar.gz
uscan info: Downloading upstream package: collectd-5.11.0.tar.gz
uscan info: Requesting URL:
   https://github.com/collectd/collectd/archive/collectd-5.11.0.tar.gz
uscan info: Successfully downloaded package: collectd-5.11.0.tar.gz
uscan info: Start checking for common possible upstream OpenPGP signature files
uscan info: End checking for common possible upstream OpenPGP signature files
uscan info: Missing OpenPGP signature.
uscan info: New orig.tar.* tarball version (oversionmangled): collectd.5.11.0
uscan info: Launch mk-origtargz with options:
   --package collectd --version collectd.5.11.0 --compression default 
--directory .. --copyright-file debian/copyright ../collectd-5.11.0.tar.gz
Successfully symlinked ../collectd-5.11.0.tar.gz to 
../collectd_collectd.5.11.0.orig.tar.gz.
uscan info: New orig.tar.* tarball version (after mk-origtargz): collectd.5.11.0
uscan info: Scan finished

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

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


--

Bug#963995: uget: Crashes under XFCE when trying to sort on column "Added on"

[Elías Alejandro]

Hi,
I have the same message but since it can't be
reproducible more than once it could be another
issue.
Remember you can also report your bugs with the
upstream author web[1]
This bug will be still open for a while until we
can get more information to fix it.

[1]https://ugetdm.com/qa/

Thanks!

On Wed, Jul 1, 2020 at 5:39 PM waxhead  wrote:
>
> Hi again,
>
> I am afraid I updated a bit since the report and I can no longer
> reproduce. However I get this from the terminal
>
> (uget-gtk:2544): Gdk-CRITICAL **: 00:36:47.413:
> gdk_window_thaw_toplevel_updates: assertion
> 'window->update_and_descendants_freeze_count > 0' failed
>
> Maybe this can be some pointer to why... who knows...
>
> Elías Alejandro wrote:
> > Hello,
> > Firstly thanks for your report.
> > I wasn't able to reproduce your bug. Could you please reproduce once again
> > but this time running Uget from the command line with uget-gtk and paste
> > the output from the terminal?
> >
> > Thanks.
> >
> > On Mon, Jun 29, 2020 at 5:57 PM waxhead  wrote:
> >>
> >> Package: uget
> >> Version: 2.2.3-1
> >> Severity: important
> >>
> >> Dear Maintainer,
> >>
> >> *** Reporter, please consider answering these questions, where appropriate 
> >> ***
> >>
> >> * What led up to the situation?
> >>
> >> Tried to download some files..
> >>
> >> * What exactly did you do (or not do) that was effective (or
> >>   ineffective)?
> >>
> >> I clicked the "added on" column to sort my downloads. uGet just 
> >> "exits" without warning.
> >> My added downloads are not saved, and not resumable so the URL's have 
> >> to be added again.
> >>
> >> * What was the outcome of this action?
> >>
> >> I "lost data" e.g. I lost my added URL's.
> >>
> >> * What outcome did you expect instead?
> >>
> >> First of all that uGet should not crash, second that my URL's remains 
> >> saved so it would be resumeable.
> >>
> >> *** End of the template - remove these template lines ***
> >>
> >>
> >> -- System Information:
> >> Debian Release: bullseye/sid
> >>APT prefers testing
> >>APT policy: (500, 'testing')
> >> Architecture: amd64 (x86_64)
> >> Foreign Architectures: i386
> >>
> >> Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores)
> >> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> >> TAINT_UNSIGNED_MODULE
> >> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> >> LANGUAGE=en_US:en (charmap=UTF-8)
> >> Shell: /bin/sh linked to /usr/bin/dash
> >> Init: systemd (via /run/systemd/system)
> >> LSM: AppArmor: enabled
> >>
> >> Versions of packages uget depends on:
> >> ii  libc62.30-8
> >> ii  libcairo21.16.0-4
> >> ii  libcurl4 7.68.0-1
> >> ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
> >> ii  libglib2.0-0 2.64.3-1
> >> ii  libgstreamer1.0-01.16.2-2
> >> ii  libgtk-3-0   3.24.20-1
> >> ii  libnotify4   0.7.9-1
> >> ii  libpango-1.0-0   1.44.7-4
> >> ii  libpangocairo-1.0-0  1.44.7-4
> >> ii  libssl1.11.1.1g-1
> >>
> >> uget recommends no packages.
> >>
> >> uget suggests no packages.
> >>
> >> -- no debconf information

Bug#900739: crashing in toke.c, keyword plugin pointer is left pointing to an XS module that's been unloaded

[Dean Hamstead]

My preference would be to apply the patch as its a genuine bug fix from 
upstream.

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

Hi 

I am really sorry to bother you, but I am a bit lost. 


I created a .deb file (see
https://github.com/grosjo/tomboy-reborn/tree/master/packages ) so I
should now create a deb-src package, right ? 


The wiki page you mentioned does not really explain how to do so. Is
there a simple, step-by-step, process described somewhere ? 

THank you so much 


On 2020-07-01 18:46, Andrey Rahmatullin wrote:

On Wed, Jul 01, 2020 at 05:35:21PM +0100, Joan Moreau wrote: 


This is not a "source package" as the source is in Pascal (using Lazarus
compiler package). Should I include the Pascal source also ?

You need to create a Debian source package that can be built to produce a
Debian binary package.
It doesn't really matter what language is used or what should be contained
in the binary package. The workflow is the same.
https://wiki.debian.org/Packaging/SourcePackage

Bug#964070: Upgrading freehep to latest upstream (needed by cdk and probably others)

[Emmanuel Bourg]

Hi all,

Le 01/07/2020 à 09:46, Giovanni Mascellani a écrit :

>> I have successfully tested rebuilding of FreeHEP reverse dependencies
>> [1]. All but GeoGebra builds fine with FreeHEP 2.4. So if you are really
>> OK with having GeoGebra removed, could you please file the removal request?
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956845
> 
> Sorry, I completely lost track of this thread. Here is the RM bug:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964070

Sorry for the late reply I'm noticing this thread only now. Even if the
geogebra package is outdated it's still fairly popular. Would it be
possible to package an older version of FreeHEP so we can preserve geogebra?

Emmanuel Bourg

Bug#228692: Bug#962384: Support for systemd-sysusers

[Holger Levsen]

On Tue, Jun 30, 2020 at 07:07:50PM +0200, Michael Biebl wrote:
> It's my understanding, that there is no clear consensus what should
> happen on package purge. Some packages do manually remove system users
> and go to some length to find files/directories owned by a system
> user/group and remove them.
> Some maintainers are of the opinion, that a system user once created
> should not be removed again.
> I think both viewpoints are valid, but the never-remove-a-system-user is
> probably the safer approach.

I actually thought we had consensus that system users should not be removed,
but couldnt find this documented neither in policy nor developers-reference
nor developers-reference's bugs or wiki.d.o pages with the the word user in
them. so, then I checked policy's bugs and found

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228692#33

which is a nice description of the 2018 consensus about the bug from 2004
titled "User/group creation/removal in package maintainer scripts".

And to quote Russ from bug=228692#33: 'I think Policy should say something
like "created users and groups should not be removed by default, but may be
removed on purge if the local administrator explicitly requests this, either
for that package or as a system-wide default."

voila.

I'm bcc-ing #228692 as a ping (and so it won't get unneeded cc:s later.)


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Felix Lechner]

Hi Sergei,

On Wed, Jul 1, 2020 at 1:33 AM Sergei Golovan  wrote:
>
> Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
> so I would say that this warning is spurious.

I am not sure who is right, but the warning is not spurious from the
perspective of the original requestor. Bug#243158 cited a scenario
very much like yours as the reason for why the dynamic linker was
confused.

Those links also never left /usr/lib.

Like so many bugs in Debian, however, the feature was requested 17
years ago. At that point, Lua had already been around for ten years
(having arrived in 1993). Do you know when Lua adopted the current
shared object hierarchy and resolution method?

Kind regards
Felix Lechner

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Chris Lamb]

Hi Sergei,

> Since it points to a higher location in the file system, lintian shows a
> warning. Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
> so I would say that this warning is spurious.

Thanks for your report and it sounds like you are right. (Mostly
replying so you don't make changes to your package while you wait for
a fix to land.)


Regards,

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

Bug#964111: dpkg-source: False positive 'points outside source root'

[Felix Lechner]

Control: retitle -1 dpkg-source: False positive 'points outside source root'
Control: severity -1 serious

Hi,

The initial filing said the three packages contained link targets
outside of the package root, but that is not so. This is not right:

dpkg-source: error: pathname
'testsuite-general-1.0/debian/tests/self1' points outside source root

One of the affected test packages is attached to this message.

When issuing the false positive, dpkg-source also exits with status
25. Everything goes away when the patch is applied, but in the
meantime this bug breaks the Lintian testsuite.

Accordingly, I upgraded the severity to prevent migration until the
bug is fixed.

Kind regards
Felix Lechner


testsuite-general_1.0.dsc
Description: Binary data


testsuite-general_1.0.tar.xz
Description: Binary data

Bug#963995: uget: Crashes under XFCE when trying to sort on column "Added on"

[waxhead]

Hi again,

I am afraid I updated a bit since the report and I can no longer 
reproduce. However I get this from the terminal


(uget-gtk:2544): Gdk-CRITICAL **: 00:36:47.413: 
gdk_window_thaw_toplevel_updates: assertion 
'window->update_and_descendants_freeze_count > 0' failed


Maybe this can be some pointer to why... who knows...

Elías Alejandro wrote:

Hello,
Firstly thanks for your report.
I wasn't able to reproduce your bug. Could you please reproduce once again
but this time running Uget from the command line with uget-gtk and paste
the output from the terminal?

Thanks.

On Mon, Jun 29, 2020 at 5:57 PM waxhead  wrote:


Package: uget
Version: 2.2.3-1
Severity: important

Dear Maintainer,

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

* What led up to the situation?

Tried to download some files..

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

I clicked the "added on" column to sort my downloads. uGet just "exits" 
without warning.
My added downloads are not saved, and not resumable so the URL's have to be 
added again.

* What was the outcome of this action?

I "lost data" e.g. I lost my added URL's.

* What outcome did you expect instead?

First of all that uGet should not crash, second that my URL's remains saved 
so it would be resumeable.

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


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

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

Versions of packages uget depends on:
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcurl4 7.68.0-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.3-1
ii  libgstreamer1.0-01.16.2-2
ii  libgtk-3-0   3.24.20-1
ii  libnotify4   0.7.9-1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libssl1.11.1.1g-1

uget recommends no packages.

uget suggests no packages.

-- no debconf information

Bug#963548: Apparently resolved in 83.0.4103.106-2

[Felipe Sologuren]

Hello,
   Today I had 81.0.4044.92-1 installed, update ffmpeg: amd64 (7: 4.2.2-1 +
b1, 7: 4.3-2) and the error appeared.
   After updating Chrome to 83.0.4103.106-2, the problem disappeared.
Thank you.

Bug#964111: dpkg-source: Uninitialized value $canon_pathname

[Felix Lechner]

Package: dpkg-source
Severity: minor
Tags: patch
X-Debbugs-CC: debian-lint-ma...@lists.debian.org

Hi,

The new version of dpkg-source recently caused the failures of three
Lintian tests. All had link targets pointing outside the source root,
which caused the failures, but there was an additional warning:

Use of uninitialized value $canon_pathname in pattern match (m//)
at /usr/share/perl5/Dpkg/Source/Package.pm line 555.

Here are the tests:

checks/files/encoding/testsuite-in-western-encoding
checks/testsuite/national-encoding
checks/testsuite/testsuite-general

The patch below caused the warning to disappear. Thank you for your
hard work on Dpkg.

Kind regards
Felix Lechner

* * *

--- Package.pm2020-07-01 21:35:04.978251308 +
+++ /usr/share/perl5/Dpkg/Source/Package.pm2020-07-01
21:35:42.846687621 +
@@ -552,6 +552,7 @@
 my $canon_newdir = realpath($newdirectory);
 my $check_symlinks = sub {
 my $canon_pathname = realpath($_);
+return unless length $canon_pathname;
 return if $canon_pathname =~ m/^\Q$canon_newdir\E/;

 error(g_("pathname '%s' points outside source root"), $_);

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Evangelos Ribeiro Tzaras]

Hi,

I originally got started with [1], however you should probably consult the new
version [2]. This should hopefully help you figure things out.

[1] https://www.debian.org/doc/manuals/maint-guide/index.html
[2] https://www.debian.org/doc/devel-manuals#debmake-doc

On 7/1/20 9:20 PM, Joan Moreau wrote:
> Hi
> 
> I am really sorry to bother you, but I am a bit lost.
> 
> I created a .deb file (see
> https://github.com/grosjo/tomboy-reborn/tree/master/packages ) so I should now
> create a deb-src package, right ?
> 
> The wiki page you mentioned does not really explain how to do so. Is there a
> simple, step-by-step, process described somewhere ?
> 
> THank you so much
> 
> 
>  
> 
> 
> On 2020-07-01 18:46, Andrey Rahmatullin wrote:
> 
>> On Wed, Jul 01, 2020 at 05:35:21PM +0100, Joan Moreau wrote:
>>> This is not a "source package" as the source is in Pascal (using Lazarus
>>> compiler package). Should I include the Pascal source also ?
>> You need to create a Debian source package that can be built to produce a
>> Debian binary package.
>> It doesn't really matter what language is used or what should be contained
>> in the binary package. The workflow is the same.
>> https://wiki.debian.org/Packaging/SourcePackage

---

Evangelos Ribeiro Tzaras

Bug#964095: RFS: z80dasm/1.1.6-1 -- disassembler for the Zilog Z80 microprocessor

[Tomaž Šolc]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: z80dasm
   Version : 1.1.6-1
   Upstream Author : Tomaž Šolc (tomaz.s...@tablix.org)
 * URL : https://www.tablix.org/~avian/blog/articles/z80dasm/
 * License : GPL-2+
 * Vcs : https://www.tablix.org/~avian/git/z80dasm.git
   Section : devel

z80dasm currently has around 70 installs on popcon. z80dasm 1.1.6 upstream
release fixes a segfault related to symbol handling and adds an option to
define the order of symbols written to the symbol file. Compared to 1.1.5
Debian packaging didn't require any major changes.

It builds those binary packages:

  z80dasm - disassembler for the Zilog Z80 microprocessor

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

  https://www.tablix.org/~avian/blog/articles/z80dasm/
  https://www.tablix.org/~avian/blog/archives/2019/09/z80dasm_1_1_6/

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

  dget -x https://www.tablix.org/~avian/z80dasm/debian/z80dasm_1.1.6-1.dsc

Changes since the last upload:

  * New upstream release.
  * Dropped format hardening patch that was included upstream.
  * Added patch to fix compiler warnings with -Wformat-overflow.
  * Added upstream README to package.
  * Updated dates in d/copyright.
  * Updated standards-version to 4.5.0.
- No changes required.
  * Updated debhelper compatibility level to 10.

Regards,
Tomaž Šolc

Bug#964110: eccodes FTBFS on 32bit

[Adrian Bunk]

Source: eccodes
Version: 2.18.0-1
Severity: serious
Tags: ftbfs

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

...
/<>/fortran/grib_type_interfaces.f90:55:26:

   55 |subroutine check_int_i4(a,b,n) bind(C, name='check_int_')
  |  1
..
   61 |subroutine check_int_i8(a,b,n) bind(C, name='check_int_')
  |  2
Error: Ambiguous interfaces in generic interface 'check_int' for ‘check_int_i4’ 
at (1) and ‘check_int_i8’ at (2)
/<>/fortran/grib_type_interfaces.f90:76:29:

   76 |subroutine check_size_t_i4(a,b,n) bind(C, name='check_size_t_')
  | 1
..
   82 |subroutine check_size_t_i8(a,b,n) bind(C, name='check_size_t_')
  | 2
Error: Ambiguous interfaces in generic interface 'check_size_t' for 
‘check_size_t_i4’ at (1) and ‘check_size_t_i8’ at (2)
/<>/fortran/grib_type_interfaces.f90:22:25:

   22 |subroutine f_sizeof_i4(a,b,n) bind(C, name='f_sizeof_')
  | 1
..
   28 |subroutine f_sizeof_i8(a,b,n) bind(C, name='f_sizeof_')
  | 2
Error: Ambiguous interfaces in generic interface 'f_sizeof' for ‘f_sizeof_i4’ 
at (1) and ‘f_sizeof_i8’ at (2)
make[3]: *** [fortran/CMakeFiles/grib_types.dir/build.make:66: 
fortran/CMakeFiles/grib_types.dir/grib_type_interfaces.f90.o] Error 1


debian/patches/gfortran-10.patch assumes long is 8 byte,
which is not true on 32bit architectures.

Bug#879014: gpgme1.0: FTBFS on some arches: Qt needs a compile with -fPIC (PIE is not enough), hardening downgrades to PIE

[Daniel Kahn Gillmor]

Control: affects 879014 + dpkg src:qtbase-opensource-src
Control: tags 879014 + patch

Hi folks--

Further conversation about problems compiling and linking against Qt and
GPGME in debian suggest that the problem might be related to dpkg's
default spec files, and confused by Qt's compiler warnings.

I'm attaching a patch to dpkg which (i think) reflects the fix proposed
by Guillem Jover (in cc):

From 8d01f1419c62e24b662abc2e1ec708a7c63fbbfe Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Wed, 1 Jul 2020 17:00:02 -0400
Subject: [PATCH] Use +self_spec: instead of *self_spec:

After discussion with NIIBE Yutaka on https://dev.gnupg.org/T4982 and
Guillem Jover on IRC, I think this is the correct fix for problems
when compiling Qt/GPGME code in debian systems.

I don't fully understand the implications of this change, but i
believe it is related to #870383 and #879014 (in the debian BTS) as
well.
---
 data/no-pie-compile.specs | 2 +-
 data/no-pie-link.specs| 2 +-
 data/pie-compile.specs| 2 +-
 data/pie-link.specs   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/data/no-pie-compile.specs b/data/no-pie-compile.specs
index 2277b97ef..70cb36095 100644
--- a/data/no-pie-compile.specs
+++ b/data/no-pie-compile.specs
@@ -1,2 +1,2 @@
-*self_spec:
++self_spec:
 + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fno-PIE}}
diff --git a/data/no-pie-link.specs b/data/no-pie-link.specs
index 54db649b1..fa4162793 100644
--- a/data/no-pie-link.specs
+++ b/data/no-pie-link.specs
@@ -1,2 +1,2 @@
-*self_spec:
++self_spec:
 + %{!shared:%{!r:%{!fPIE:%{!pie:-fno-PIE -no-pie
diff --git a/data/pie-compile.specs b/data/pie-compile.specs
index 74d82155c..c1ee08c71 100644
--- a/data/pie-compile.specs
+++ b/data/pie-compile.specs
@@ -1,2 +1,2 @@
-*self_spec:
++self_spec:
 + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:%{!fno-PIE:%{!no-pie:-fPIE
diff --git a/data/pie-link.specs b/data/pie-link.specs
index 94c122fd3..9b401e34a 100644
--- a/data/pie-link.specs
+++ b/data/pie-link.specs
@@ -1,2 +1,2 @@
-*self_spec:
++self_spec:
 + %{!static:%{!shared:%{!r:%{!fno-PIE:%{!no-pie:-fPIE -pie}
-- 
2.27.0


gniibe also identified a problem in how Qt reports compilation warnings
related to the PIE/PIC mismatch.  I've tried to address that in the
following patch to qtbase-opensource-src:

From 107f387ea625a67ef03b916ef965761f36de2bf4 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Wed, 1 Jul 2020 17:15:12 -0400
Subject: [PATCH] Clarify warning message about PIC/PIE

As noted in discussion at https://dev.gnupg.org/T4982#135524, the
warning message produced when there is a mismatch between
position-independence of the Qt library and other compilations, the
warning produced by Qt is confusing.

This is an attempt to express a warning that is more closely aligned
with the actual test used.
---
 src/corelib/global/qglobal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/corelib/global/qglobal.h b/src/corelib/global/qglobal.h
index fe8e8e8..971ee56 100644
--- a/src/corelib/global/qglobal.h
+++ b/src/corelib/global/qglobal.h
@@ -1280,7 +1280,7 @@ Q_CORE_EXPORT int qrand();
 #if !defined(QT_BOOTSTRAPPED) && defined(QT_REDUCE_RELOCATIONS) && defined(__ELF__) && \
 (!defined(__PIC__) || (defined(__PIE__) && defined(Q_CC_GNU) && Q_CC_GNU >= 500))
 #  error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\
- "Compile your code with -fPIC (-fPIE is not enough)."
+ "Compile your code with -fPIC (and not with -fPIE unless you have a very old version of GCC)."
 #endif
 
 namespace QtPrivate {
-- 
2.27.0


If either of these two fixes are not appropriate to help resolve the
problem, i'd appreciate help in figuring out what the right fixes are.

I am not an expert in either Qt or dpkg, so pointers and explanations
are welcome.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#964108: pyscanfcs FTBFS

[Adrian Bunk]

Source: pyscanfcs
Version: 0.3.6+ds-1
Severity: serious
Tags: ftbfs

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

...
   debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install
cp --reflink=auto -a ./debian/pyscanfcs.desktop 
debian/pyscanfcs/usr/share/applications//
install -d debian/pyscanfcs/usr/share/doc/pyscanfcs/examples
cp --reflink=auto -a ./misc/ 
debian/pyscanfcs/usr/share/doc/pyscanfcs/examples/
install -d debian/.debhelper/generated/pyscanfcs
mv /<>/debian/pyscanfcs/usr/bin/pyscanfcs \
   /<>/debian/pyscanfcs/usr/lib/pyscanfcs/pyscanfcs_run
cd /<>/debian/pyscanfcs/usr/bin/; \
ln -s ../lib/pyscanfcs/pyscanfcs_run pyscanfcs; cd -
/<>
mv debian/pyscanfcs.xpm \
debian/pyscanfcs/usr/share/pixmaps
chmod -R 644 debian/pyscanfcs/usr/share/doc/pyscanfcs/examples/misc
chmod: cannot access 
'debian/pyscanfcs/usr/share/doc/pyscanfcs/examples/misc/setup.py': Permission 
denied
chmod: cannot access 
'debian/pyscanfcs/usr/share/doc/pyscanfcs/examples/misc/dat2csv.py': Permission 
denied
chmod: cannot access 
'debian/pyscanfcs/usr/share/doc/pyscanfcs/examples/misc/binningc.pyx': 
Permission denied
chmod: cannot access 
'debian/pyscanfcs/usr/share/doc/pyscanfcs/examples/misc/README.md': Permission 
denied
chmod: cannot access 
'debian/pyscanfcs/usr/share/doc/pyscanfcs/examples/misc/MakeTestDat_SFCS.py': 
Permission denied
chmod: cannot access 
'debian/pyscanfcs/usr/share/doc/pyscanfcs/examples/misc/ExampleFunc_Exp_correlated_noise.txt':
 Permission denied
make[1]: *** [debian/rules:53: override_dh_install] Error 1

Bug#964109: flint: FTBFS on 32 bit archs

[Sebastian Ramacher]

Source: flint
Version: 2.6.0~rc3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

flint fails to build on 32 bit architectures. For example:
| mul_johnsonPASS
| push_term_fq_nmod_fmpzPASS
| push_term_fq_nmod_uiPASS
| push_term_fq_nmod_uiPASS
| reversePASS
| scalar_mul_uiPASS
| sort_termsPASS
| total_degreePASS
| univarPASS
| PASS
| E: Build killed with signal TERM after 150 minutes of inactivity

https://buildd.debian.org/status/fetch.php?pkg=flint=i386=2.6.0-2=1592647407=0

| refinePASS
| make[3]: *** [../Makefile.subdirs:97: 
../build/fmpz_factor/test/t-pollard_brent_single_RUN] Aborted
| make[3]: *** Waiting for unfinished jobs
| PASS
| PASS
| make[3]: Leaving directory '/<>/fmpz_factor'
| make[2]: *** [Makefile:217: check] Error 2

https://buildd.debian.org/status/fetch.php?pkg=flint=armel=2.6.0-2=1592639203=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#963387: [request-tracker-maintainers] Bug#963387: Bug#963387: Bug#963387: request-tracker4: FTBFS: CORE missing dependencies: Plack::Handler::Starlet ...MISSING

[Dominic Hargreaves]

Control: reassign -1 libmojolicious-perl
Control: retitle -1 libmojolicious-perl: Invalid selectors (breaks RT)
Control: found -1 8.54+dfsg-1
Control: fixed -1 8.55+dfsg-1
Control: affects -1 request-tracker4

On Tue, Jun 23, 2020 at 12:19:03AM +0100, Dominic Hargreaves wrote:
> > Almost certainly triggered by the recent uploads of libmojolicious-perl.
> > It happens with both 8.55+dfsg-1 (sid) and 8.54+dfsg-1 (bullseye).
> 
> Confirmed it doesn't happen with 8.53. Forwarded upstream.

I got this wrong, 8.55 is fine - it's only 8.54 that's broken. See
changelog entry:

8.55  2020-06-18
  - Fixed a regression in Mojo::DOM::CSS that caused some selectors to not be 
valid anymore.

Bug#964094: Video playback broken with AMD 5700 XT using amdgpu drivers

[Ski-lleR]

Package: libva-drm2
Version: 2.8.0-1

After upgrading VA API to 2.8.0-1, i rebooted, and video playback was 
completely broken in mpv and firefox. Also firefox almost crashed my session 
because before reboot i have an opened tab with video playing.
Every video, no matter of the resolution / bitrate / codec run at less than 1 
frame per second.

I downgraded this package :
va-driver-all_2.7.1-1_amd64.deb va-driver-all_2.7.1-1_i386.deb 
libva-dev_2.7.1-1_amd64.deb libva-dev_2.7.1-1_i386.deb libva2_2.7.1-1_amd64.deb 
libva2_2.7.1-1_i386.deb libva-x11-2_2.7.1-1_amd64.deb 
libva-x11-2_2.7.1-1_i386.deb libva-wayland2_2.7.1-1_amd64.deb 
libva-wayland2_2.7.1-1_i386.deb libva-drm2_2.7.1-1_amd64.deb 
libva-drm2_2.7.1-1_i386.deb libva-glx2_2.7.1-1_amd64.deb 
libva-glx2_2.7.1-1_i386.deb

After reboot, video playback was fine like before.

I re-upgraded VA API to 2.8.0-1 / rebooted to be sure that's not some one time 
bad boot, and the problem was back again, so it's clearly the upgrade to 
2.8.0-1 who cause the problem. Let me know if you need more information.
Kernel version: 5.7.0-1
GPU: Sapphire Nitro+ RX 5700 XT 8G Special Edition (not overclocked)
Drives in use: amdgpu 19.1.0-1

Sent with ProtonMail Secure Email.

publickey - ski_ller@protonmail.ch - 0xC8010ECA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#946727: interimap: typo in html documentation: though → through

[guilhem]

Control: done -1 0.5-1

On Sat, 14 Dec 2019 at 21:50:34 +0100, Guilhem Moulin wrote:
> Control: tag -1 pending
> Control: retitle -1 interimap: typo in documentation: though → through

Forgot to mark this as closed earlier, doing it now :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#947351: buster-pu: package cloud-init/20.2-2+deb10u1

[Noah Meyerhans]

On Wed, Jul 01, 2020 at 12:56:17PM +0100, Adam D. Barratt wrote:
> > Let's try to finally get something done with this cloud-init update.
> > The request is to update to upstream version 20.2 in buster.  This
> > version is currently in both testing and buster-backports.  It has
> > been tested by the cloud team and others in common cloud environments
> > including Microsoft Azure, AWS, and OpenStack.  It contains fixes for
> > bugs including #936030, and implements support for the IMDSv2 API in
> > Amazon EC2.
> > 
> > It backports cleanly from testing to buster, with no changes beyond
> > the debian/changelog update.
> 
> Have the changes been tested on buster using this proposed package, or
> just with the unstable/testing/backports versions?

Most of the tests have used the version from bpo.  I have performed
tests with the proposed build on Amazon EC2.

> What does a binary debdiff between the current stable package and the
> proposed package look like?

See attached.

> 
> > Full debdiff against buster's 18.3-6 is attached.
> 
> fwiw, that debdiff was large enough (even compressed) that the mail
> didn't make it to debian-release.

I'm not surprised... You can find it at
https://people.debian.org/~noahm/cloud-init-buster-pu/src.debdiff

If you want to skip to only the debian/ changes, I've extracted them to
https://people.debian.org/~noahm/cloud-init-buster-pu/debian.debdiff

> +cloud-init (20.2-2+deb10u1) buster; urgency=medium
> 
> The version needs to be /lower/ than the package in unstable, so a
> backported version is 20.2-2~deb10u1, similarly to bpo.

Ack! Updated to 20.2-2~deb10u1

noah

[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloud_init-20.2.egg-info/PKG-INFO
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloud_init-20.2.egg-info/dependency_links.txt
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloud_init-20.2.egg-info/entry_points.txt
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloud_init-20.2.egg-info/requires.txt
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloud_init-20.2.egg-info/top_level.txt
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/cloudinit/cmd/cloud_id.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/cmd/devel/net_convert.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/cmd/devel/render.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/cloudinit/cmd/query.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/config/cc_ubuntu_drivers.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/cloudinit/conftest.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/distros/amazon.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/cloudinit/distros/bsd.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/distros/bsd_utils.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/distros/netbsd.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/distros/openbsd.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/cloudinit/event.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/handlers/jinja_template.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/cloudinit/net/bsd.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/cloudinit/net/freebsd.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/cloudinit/net/netbsd.py
-rw-r--r--  root/root   /usr/lib/python3/dist-packages/cloudinit/net/openbsd.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceExoscale.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceOracle.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceRbxCloud.py
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/sources/helpers/netlink.py
-rw-r--r--  root/root   /usr/share/bash-completion/completions/cloud-init
-rw-r--r--  root/root   
/usr/share/doc/cloud-init/examples/cloud-config-chef.txt.gz
-rwxr-xr-x  root/root   /usr/bin/cloud-id

Files in first .deb but not in second
-
-rw-r--r--  root/root   /etc/bash_completion.d/cloud-init
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloud_init-18.3.egg-info/PKG-INFO
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloud_init-18.3.egg-info/dependency_links.txt
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloud_init-18.3.egg-info/entry_points.txt
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloud_init-18.3.egg-info/requires.txt
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloud_init-18.3.egg-info/top_level.txt
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/cloudinit/config/cc_snap_config.py

Bug#964107: xf86-input-wacom: Please update the homepage information

[Boyuan Yang]

Source: xf86-input-wacom
Version: 0.34.99.1-1
Tags: sid

Dear Debian xf86-input-wacom maintainer,

It seems that the new homepage for this project is now 
https://linuxwacom.github.io/ . Visiting the old 
http://linuxwacom.sf.net/ will automatically redirect to the new
website.

Please consider updating the homepage information in the debian/control
file. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#963681: primus-vk: please don't require bumblebee-nvidia on Ubuntu/ppc64el

[Andreas Beckmann]

Control: reassign -1 src:bumblebee 3.2.1-23

On 6/25/20 10:21 AM, Gianfranco Costamagna wrote:

Source: primus-vk



trivial patch attached:
(bumblebee-nvidia is not built on ppc64el)


Let's rather fix this in bumblebee than work around it in primus-vk.

Andreas

Bug#942545: gitlab: Issue still present in 13.1.1-1+fto10+1

[Maximilian Stein]

Source: gitlab
Version: 13.1.1-1+fto10+1
Followup-For: Bug #942545

Dear Maintainer,

After upgrading to 13.1.1-1+fto10+1 I noticed that this issue is still
present. I had to change owner and group of the directories `cache`
and `uploads` in /var/lib/gitlab/shared/artifacts/tmp manually in
order to make artifacts in CI work again.

Best,
Maximilian

Bug#963560: main.pdf: openBinaryFile: does not exist

[ael]

On Wed, Jul 01, 2020 at 05:30:12PM +0200, Georges Khaznadar wrote:
> Dear Dirk,
> 
> promoting packages from Recommended to straigt dependencies deserves
> always some discussion.
> 
> I suppose that the excerpt:
> 
> .BR -b ", " --epub
> Output epub file.
> 
> Can be enhanced by mentioning calibre, for instance:
> 
> .BR -b ", " --epub
> Output epub file. This feature relies on the recommended package calibre.
> 
> Also, when options -b or --epub are triggered, and calibre is not found,
> mediawiki2latex might issue some warning, or some "rtfm" stance.

I was going to suggest something very similar. Dirk has been very
generous with his time suggesting various ways to achieve what I need,
but I don't think that the current man page gives any clue about how
to select and configure the options in fairly sophisticated ways
if one is not already familiar with Wikipedia & wikibooks internals.

I am still being lazy, well busy with other things really, so haven't
yet looked at the source or tried to follow the Wiki mechanisms.

ael

Bug#964106: xf86-input-wacom: Please package new upstream release (0.39)

[Boyuan Yang]

Source: xf86-input-wacom
Version: 0.34.99.1-1
Tags: sid

Dear Debian xf86-input-wacom maintainer,

I just found that one of my new wacom tablets does not work well under
Debian. It looks like the X input driver for wacom tablets in Debian is
quite old and is missing some new features and bugfixes.

According to https://github.com/linuxwacom/xf86-input-wacom/releases ,
a new upstream release of v0.39.0 is now available. Please consider
packaging it. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#963614: stretch-pu: package nfs-utils/1:1.3.4-2.1+deb9u1

[Salvatore Bonaccorso]

hi Adam,

On Wed, Jul 01, 2020 at 09:06:40PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2020-06-24 at 16:14 +0200, Salvatore Bonaccorso wrote:
> > nfs-utils in stretch is affected by CVE-2019-3689, cf. #940848 the
> > fix was now exposed for a while in unstable and I would like fix the
> > issue ass well in stretch. I have picked those changes and adjusted
> > the version in the postinst accordingly.
> > 
> 
> Please go ahead, thanks.

Thanks for the review and ack'ing it, just uploaded.

Regards,
Salvatore

Bug#963595: buster-pu: package nfs-utils/1:1.3.4-2.5+deb10u1

[Salvatore Bonaccorso]

Hi Adam,

On Wed, Jul 01, 2020 at 09:07:19PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2020-06-24 at 10:14 +0200, Salvatore Bonaccorso wrote:
> > nfs-utils in buster is affected by CVE-2019-3689, cf. #940848 the fix
> > was now exposed for a while in unstable and I would like fix the
> > issue ass well in buster. I have picked those changes and adjusted
> > the version in the postinst accordingly.
> > 
> 
> Please go ahead.

Thanks for the review and acking it, have just uploaded.

Regards,
Salvatore

Bug#956697: mercurial: Skip test-wireproto-exchangev2-shallow.t

[Brian Murray]

Package: mercurial
Version: 5.4.1-1
Followup-For: Bug #956697
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Dear Maintainer,

In Ubuntu's autopkgtest infrastructure I also noticed that the
test-wireproto-exchangev2-shallow.t is flaky as the ordering of the
output changes. Its worth mentioning that the test fails more frequently
on armhf. Here are some logs of it failing:

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/armhf/m/mercurial/20200630_044520_38521@/log.gz
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/armhf/m/mercurial/20200523_005337_84d39@/log.gz
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/armhf/m/mercurial/20200524_200914_c544f@/log.gz
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/armhf/m/mercurial/20200524_200914_c544f@/log.gz

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

  * Blacklist for test-wireproto-exchangev2-shallow.t for occasional failures.

Thanks for considering the patch.
diff -Nru mercurial-5.4.1/debian/mercurial.test_blacklist 
mercurial-5.4.1/debian/mercurial.test_blacklist
--- mercurial-5.4.1/debian/mercurial.test_blacklist 2020-06-25 
08:48:40.0 -0700
+++ mercurial-5.4.1/debian/mercurial.test_blacklist 2020-07-01 
11:12:41.0 -0700
@@ -37,3 +37,4 @@
 test-commandserver.t
 test-largefiles.t
 test-wireproto-exchangev2.t
+test-wireproto-exchangev2-shallow.t

Bug#964105: RFH: album-data -- themes, plugins and translations for album

[David Ljung Madison]

Package: wnpp
Severity: important

The package 'album-data' is a data package for 'album'

I am the author of album and album-data.

It has an incorrect dependency on "libjs-swfobject" which I recently
noticed because, since libjs-swfobject has been removed, has caused
album-data to also be removed.

album-data does not depend on libjs-swfobject.

I'm not sure if this still has a maintainer, or if someone else can
take over maintaining this, or if I need to go through the process
of becoming a maintainer.  Whatever needs to be done to bring 'album'
back up to date (and actually the packages could probably just be
combined into one at this point, since 'album' is generally not
used without the data package, which is relatively small anyways).

Thanks,

Dave

---
Dave Madison Stellarhttp://GetDave.com/415.341.
-- I love deadlines.  I love the whooshing sound they make as they go by --
- Douglas Adams

Bug#960452: mount: Editing fstab in a valid way causes silent failure to mount

[Chris Hofstaedtler]

* John Goerzen  [200625 00:39]:
> 
> On Tue, Jun 23 2020, Chris Hofstaedtler wrote:
> 
> > Okay, that would match the suggestion. In this case I'd think this
> > is more a systemd issue than a mount issue - mount passes your mount
> > request to the kernel, and the kernel mounts it. Then something else
> > (probably systemd) unmounts it immediately.
> 
> I think that is absolutely plausible.  I'm not sure if it would help,
> since I can no longer reproduce this, but a guess a reassignment to
> systemd might be relevant.  But I agree that adding content to fstab(5)
> would be helpful in any case (and perhaps also mount(8)).

I've filed #963573 to add a hint to the /etc/fstab template, so new
installs get this info directly in the file.

I'll keep this bug around to add text to fstab(5) and maybe
mount(8) - both man pages are shipped by the mount binary package.

For the underlying issue, this bug could perhaps be cloned to
systemd, indeed.

Thanks!
Chris

Bug#963614: stretch-pu: package nfs-utils/1:1.3.4-2.1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-06-24 at 16:14 +0200, Salvatore Bonaccorso wrote:
> nfs-utils in stretch is affected by CVE-2019-3689, cf. #940848 the
> fix was now exposed for a while in unstable and I would like fix the
> issue ass well in stretch. I have picked those changes and adjusted
> the version in the postinst accordingly.
> 

Please go ahead, thanks.

Regards,

Adam

Bug#963595: buster-pu: package nfs-utils/1:1.3.4-2.5+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-06-24 at 10:14 +0200, Salvatore Bonaccorso wrote:
> nfs-utils in buster is affected by CVE-2019-3689, cf. #940848 the fix
> was now exposed for a while in unstable and I would like fix the
> issue ass well in buster. I have picked those changes and adjusted
> the version in the postinst accordingly.
> 

Please go ahead.

Regards,

Adam

Bug#964097: gitlab: "git push" fails with a stacktrace in gitlab code due to outdated ruby version

[Pirate Praveen]

Control: fixed -1 13.1.1-1+fto10+2

On Wed, 01 Jul 2020 19:27:43 +0200 Maximilian Stein  
wrote:

> Source: gitlab
> Version: 13.1.1-1+fto10+1
> Severity: important
>
> Dear Maintainer,
>
> After upgrade to above mentioned version, `git push`es started to 
fail

> on my repositories (while `git pull`s continued working).
> Investigating the issue I noticed that there were stack traces logged
> into /var/log/gitlab/exceptions_json.log every time I tried pushing.
>
> The stack traces pointed to 
lib/gitlab/gl_repository/identifier.rb:52,

> where apparently a string is converted to an integer. The excetion
> message reads "wrong number of arguments (given 3, expected 1..2)".
> According to the documentation of ruby, there were only two arguments
> to `Integer` in 2.5.1
> (https://ruby-doc.org/core-2.5.1/Kernel.html#method-i-Integer), while
> there was a third one added later (e.g. present in 2.7). However,
> since my system is based on buster, I have ruby 2.5.1 installed.
>
> I could work around my issue by removing the third `exception: false`
> parameter to `Integer` in
> /usr/share/gitlab/lib/gitlab/gl_repository/identifier.rb:52.
>

Thanks for troubleshooting and suggesting a fix. I have included the 
fix in the package.


> Since there is no newer ruby version available in backports or
> fasttrack, I'd prefer to stick to the stable version. What solution
> can you recommend? Do you need any more information?

We discussed this in the ruby team [1] and preferred method is to patch 
gitlab to work with ruby 2.5, but we will need some volunteers for 
that. I will try add ruby 2.7 in fasttrack if we see a lot of issues 
with ruby 2.5.


]1] https://lists.debian.org/debian-ruby/2020/06/msg00018.html

> Relevant package versions:
>
> gitlab: 13.1.1-1+fto10+1
> gitlab-common: 13.1.0+dfsg-1~bpo10+1
> gitaly: 13.1.0+dfsg-1~bpo10+1
> gitlab-shell: 13.3.0+debian-1~bpo10+1
>
> Best,
> Maximilian
>
>

Bug#951537: Resolved in 2.1.5-1 for unstable

[Mike Gabriel]

Control: close -1
Control: fixed -1 2.1.5-1

This issue has now been also resolved in Debian unstable via upload of  
php-horde-2.1.5-1. Unfortunately, closing this bug via d/changelog has  
been left out.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp3YcaOdqpW2.pgp
Description: Digitale PGP-Signatur

Bug#963607: [Pkg-xen-devel] Bug#963607: xen-hypervisor-4.11-amd64: Xen Hypervisor kernel fails to load arcmsr module with "arcmsr0: dma_alloc_coherent got error" message.

[Alex Sanderson]

Hi,

On 1/07/2020 02:05, Hans van Kranenburg wrote:
> Hi,
>
> On 6/25/20 1:44 PM, Alex Sanderson wrote:
>> Hi Hans,
>>
>> Thank you for your assistance with this.  I hesitated to log this with
>> xen-dev but thought I should wait for a response here first. 
>>
>>
>> On 25/06/2020 01:30, Hans van Kranenburg wrote:
>>> Hi Alex,
>>>
>>> On 6/24/20 12:31 PM, Alex Sanderson wrote:
 Package: xen-hypervisor-4.11-amd64
 Version: 4.11.3+24-g14b62ab3e5-1~deb10u1
 Severity: important

 Dear Maintainer,

 After updating to Buster and Xen 4.11 our machine no longer boots the Xen 
 kernel.  The default kernel 4.19.118-2+deb10u1 boots normally.
>>> When booting with Xen, the computer first starts the Xen hypervisor
>>> code. This is the part where you see all the lines with (XEN) at the
>>> beginning appear.
>>>
>>> Afterwards, it starts the same 4.19.118-2+deb10u1 Linux kernel that is
>>> used when running without Xen, but it's started as the first virtual
>>> machine, that has extra privileges to access all hardware.
>>>
>>> So, Linux vs. Xen + Linux.
>>>
 The machine has an Areca 1882IX-16 card in it when the arcmsr module
 tries to load the following error appears. 

Areca RAID Controller0: Model ARC-1882, F/W V1.56 2019-07-30
arcmsr0: dma_alloc_coherent got error

 No drives are discovered and the initramfs prompt is shown.
>>> Ok, so booting the Xen part succeeded, but apparently, when starting the
>>> Linux kernel inside, there's apparently a problem with accessing the
>>> raid controller hardware. Interesting.
>>>
>>> This likely means it's not a problem in the Debian packaging part, it's
>>> a problem somewhere in the upstream Xen or Linux code. That means that I
>>> cannot solve this for you, but I can help with tips to gather the right
>>> information, and help finding out what the best place is where we can
>>> report the issue.
>>>
 The machine:
  * Supermicro X9DRW 
  * Dual Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz
  * 128G RAM
  * Areca ARC-1882IX-16 (1G onboard cache)

 Nothing I have tried is effective:
  * Turning on BIOS above 4G decoding stops the Intel 10GBE ixgbe driver 
 from functioning and doesn't fix the arcmsr
  * Unloading and reloading the arcmsr module from initramfs prompt
  * Downgrading the Areca 1882 bios to v1.52 as per 
 http://faq.areca.com.tw/index.php?action=artikel=7=902=en
  * Kernel parameters
  ** pci=nocrs 
  ** dom0_mem=8G 
  ** mem=3072M
  ** mem2048M cma=1024M
  ** cma=2048
  ** cma=3076@512M
  ** iommu=1 intel_iommu=1 
  ** arcmsr.host_can_queue=64 as per 
 http://faq.areca.com.tw/index.php?action=artikel=15=387=en

 I expected the arcmsr module to load and detect disks as it does with
 the stock kernel.

 I can provide sysctl and dmesg output if it helps.
>>> Yes. The first thing needed is full startup logs, and for the Xen part
>>> preferably extra logging. In /etc/default/grub.d/xen.cfg in the
>>> GRUB_CMDLINE_XEN_DEFAULT setting, you can add loglvl=all, and then run
>>> update-grub and try to boot Xen+Linux again.
>>>
>>> Do you have a way to capture the logging during boot? Like, a working
>>> serial console or something similar?
>>>
>>> The output of dmesg when starting Linux without Xen is of course also
>>> interesting, so we can compare both scenarios.
>>>
>>> Hans
>> I tried using debian's paste https://paste.debian.net but it always
>> thought it was spam.
>>
>> dmesg output Xen Hypervisor 4.11 https://pastebin.com/3wUyYg0P
> This one shows a Linux kernel boot, not the Xen Hypervisor, which should
> go first (with all the (XEN) lines). By default the Xen output should
> show up on your (serial) console. If you do dmesg after starting Linux
> as dom0 after starting Xen, then you just get the Linux part of it.
>
> If it actually boots and it's usable to login and get a shell prompt
> etc, then you can immediately use xl dmesg to see the xen part, and if
> it doesn't, then you need to make sure you have some sort of serial
> console to capture the lines.
>
> To do a bug report upstream, we'll need that information.

Sorry, completely misunderstood.   Here is the output from the serial
terminal as Xen started.

https://paste.debian.net/1154644

Alex

>
>> dmesg output Debian Kernel 4.19.118-2+deb10u1 https://pastebin.com/GHzzW3vi
> K

Bug#964104: src:pbcopper: fails to migrate to testing for too long

[Paul Gevers]

Source: pbcopper
Version: 1.3.0+dfsg-3
Severity: serious
Control: close -1 1.6.0+dfsg-4
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:pbcopper in
unstable has been trying to migrate since 2020-04-19 [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=pbcopper




signature.asc
Description: OpenPGP digital signature

Bug#964103: pdns-recursor: CVE-2020-14196: Access restriction bypass

[Salvatore Bonaccorso]

Source: pdns-recursor
Version: 4.3.1-1
Severity: important
Tags: security upstream
Control: found -1 4.1.11-1+deb10u1
Control: found -1 4.1.11-1

Hi,

The following vulnerability was published for pdns-recursor.

CVE-2020-14196[0]:
| In PowerDNS Recursor versions up to and including 4.3.1, 4.2.2 and
| 4.1.16, the ACL restricting access to the internal web server is not
| properly enforced.


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-14196
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14196
[1] https://www.openwall.com/lists/oss-security/2020/07/01/1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#963980: bumblebee-nvidia: Bumblebee daemon reported: error: [XORG] (EE) Unable to locate/open config directory

[Andreas Beckmann]

Control: tag -1 moreinfo unreproducible

On 7/1/20 8:15 PM, Vincas Dargis wrote:
And after reinstalling driver and all other bumbleblee-related packages, 
it started to work again.


Thanks for this "solution". You probably can't tell what changed (likely 
in /etc) after purge+reinstall?
Anyway, I'll keep this bug open as unreproducible in case someone else 
stumbles upon it ...


Andreas

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

[Ronny Bachmann]

No, I have only tested with the version from Debian Testing so far. I
am currently on holiday. As soon as I'm back I will test it. It would
be great if it would work that way!

Ronny

Bug#964102: gle-graphics should build depend on libqt5opengl5-desktop-dev instead of libqt5opengl5-dev

[Adrian Bunk]

Source: gle-graphics
Version: 4.2.5-8
Severity: important
Tags: ftbfs

gle-graphics FTBFS on armel and armhf:

https://buildd.debian.org/status/package.php?p=gle-graphics=sid

...
3dviewer.cpp: In destructor ‘virtual QGLE3DWidget::~QGLE3DWidget()’:
3dviewer.cpp:56:6: error: ‘glDeleteLists’ was not declared in this scope
   56 |  glDeleteLists(object, 1);
  |  ^
...

The root cause is that on armel/armhf
Qt5 is compiled with OpenGL ES instead of OpenGL.

Ideally it should be fixed to build and work with OpenGL ES,
changing the build dependency from libqt5opengl5-dev to
libqt5opengl5-desktop-dev would at least stop trying to
build on armel/armhf.

Bug#908694: album-data: please remove dependency on libjs-swfobject, which is going away

[David Ljung Madison]

I am the author of album / album-data


Is this being maintained anymore?  If not, how can I take over the
maintenance of this package and/or find a Debian Maintainer who can?

Because this dependency has not been removed, the package has
now been dropped.

Dave

---
Dave Madison Stellarhttp://GetDave.com/415.341.
---

Bug#964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup

[Helmut Grohne]

Hi Luca,

On Wed, Jul 01, 2020 at 05:23:05PM +0100, Luca Boccassi wrote:
> This is how upstream generates the pkg-config files for all components
> of util-linux - and it's how most libraries with optional features that
> I've come across do as well. If a feature is not built, and thus the
> binary does not link to the library, the dependency is not listed in
> pkg-config. And to me it would appear the correct thing to do - the
> point of pkg-config is to list what is needed to link against that
> library, not a hypotethical version with everything enabled - so I
> don't see upstream changing that any time soon.

This is not an upstream aspect. Upstream can provide different
interfaces under the same name, but we're talking about the Debian
package name "libmount-dev" as an interface here. What means
"libmount-dev" mostly is a decision of the respective package
maintainer. The meaning can change over time and we have a version to
account for this. A major cause for RC bugs is when a package maintainer
changes (removes) an interface that other packages previously relied
upon.

The thing is, other packages depend on "libmount-dev" and they expect to
get the same thing no matter how you build it. So what makes up
"libmount-dev" should be independent of which build profiles you use to
build it. However, certain build profiles can result in libmount-dev not
being built at all.

Compare this with hurd. There is hurd-dev and during bootstrap, we need
a stripped-down version of it. So we invented hurd-headers-dev.
Normally, hurd-dev provides hurd-headers-dev and a real hurd-headers-dev
package is not build. Only during bootstrap, there is a hurd-headers-dev
package that does not provide hurd-dev. Now when you need hurd
development stuff, you need to decide whether you just need the headers
or whether you need the full hurd-dev.

Another example is lighttpd-modules-*. What these packages contain is
explicitly left unspecified. If you need a particular module, you must
depend on the particular lighttpd-mod-* package provided by some of the
real module packages. This wasn't made up by upstream. It's about how
the package is maintained and about how other packages interface with
it.

Does that make more sense to you now?

> For libmount for example you get the exact same result w.r.t.
> libselinux.

That doesn't make it any better. I guess that's why the Debian package
makes libselinux-dev a mandatory dependency. Indeed, we build libselinux
quite early during bootstrap.

> I'll likely provide a backported patch as soon as the PR is merged -
> I'd really like to get more stress-test under way long before the
> bullseye freeze.

I think experimental would be a good target for such a feature. I admit
that it gets way less testing there. I'm looking forward to seeing it
included in Debian bullseye.

Helmut

Bug#964101: tiddit: generates extremely large file during autopkgtesting

[Paul Gevers]

Source: tiddit
Version: 2.12.0+dfsg-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: -1 issue

Dear maintainer(s),

In the last upload of the tiddit package, an autopkgtest was added,
great. However, the package seems to generate files, and one file is
growing to at least 29 GB. Maybe bigger, but with that size, the VM as
runs on several of our arm64 workers is full (total size is 40 GB).

root@ci-182-f37c0a21:/tmp/autopkgtest-lxc.mk9f7rok/downtmp/autopkgtest_tmp#
ls -alh
total 29G
drwxr-xr-x 2 debci debci 4.0K Jun 30 22:29 .
drwxrwxrwx 5 root  root  4.0K Jun 30 22:29 ..
-rw-r--r-- 1 debci debci 1.4M Jun 30 22:19 normal.bam
-rw-r--r-- 1 debci debci 5.8M Jun 28 10:11 normal.sam
-rw-r--r-- 1 debci debci  11M Jun 28 10:10 ref.fa
-rw-r--r-- 1 debci debci0 Jun 30 22:29 test1.db
-rw-r--r-- 1 debci debci0 Jun 30 22:29 test1.gc.wig
-rw-r--r-- 1 debci debci  29G Jun 30 22:22 test1.sample.bam
-rw-r--r-- 1 debci debci0 Jun 30 22:29 test1.signals.tab
-rw-r--r-- 1 debci debci0 Jun 30 22:29 test1.wig
-rw-r--r-- 1 debci debci 1.1M Jun 30 22:19 tumor.bam
-rw-r--r-- 1 debci debci 4.5M Jun 28 10:12 tumor.sam

Please be a bit more gentle with your tests for our infrastructure. I'll
have the ci infrastructure ignore tests on arm64 for now until you close
this bug.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#964098: [pkg-crosswire-devel] Bug#964098: xiphos: package new upstream release: 4.2.1

[Teus Benschop]

On Wed, 1 Jul 2020 at 20:39, Roberto C. Sánchez  wrote:

> On Wed, Jul 01, 2020 at 08:34:39PM +0200, Teus Benschop wrote:
> >Yes, that would be good.
> >There's some patches and bugs too.
> >It would be good if the new release would fix those issues.
> >I was thinking of working on this after a week or so time permitting.
>
> That would be excellent.  Do you intend to start by reviewing Bastian's
> MR in Salsa?  If you can't get to it by the end of next week, please let
> me know and I will take care of it.
>
>
> I wasn't sure yet where to start, but certainly Bastian's merge requests
are welcome and would be considered.
I can't tell for sure when I will get to working on those, also because
there's lots of work to do for me on a youtube channel for teens.
Please feel free to merge them if and when you like to do so.

Bug#964098: [pkg-crosswire-devel] Bug#964098: xiphos: package new upstream release: 4.2.1

[Roberto C . Sánchez]

On Wed, Jul 01, 2020 at 08:34:39PM +0200, Teus Benschop wrote:
>Yes, that would be good.
>There's some patches and bugs too.
>It would be good if the new release would fix those issues.
>I was thinking of working on this after a week or so time permitting.

That would be excellent.  Do you intend to start by reviewing Bastian's
MR in Salsa?  If you can't get to it by the end of next week, please let
me know and I will take care of it.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Bug#964017: Acknowledgement (grep-excuses)

[Ian Jackson]

control: retitle -1 Dpkg::Source::Package:new require_valid_signature => 0

-- 
Ian JacksonThese opinions are my own.  

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

Bug#964098: [pkg-crosswire-devel] Bug#964098: xiphos: package new upstream release: 4.2.1

[Teus Benschop]

Yes, that would be good.
There's some patches and bugs too.
It would be good if the new release would fix those issues.
I was thinking of working on this after a week or so time permitting.

Met vriendelijke groeten,
With kind regards,

Teus Benschop


On Wed, 1 Jul 2020 at 20:15, Roberto C. Sanchez  wrote:

> Package: xiphos
> Version: 4.1.0.1+dfsg1-1
> Severity: wishlist
>
> It would be good if we could package the new upstream release 4.2.1
> fairly soon.
>
> Regards,
>
> -Roberto
>
> ___
> pkg-crosswire-devel mailing list
> pkg-crosswire-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-crosswire-devel
>

Bug#964100: iputils-arping should use alternatives to remove conflict with arping

[Boian Bonev]

Package: iputils-arping
Version: 3:20190709-3
Severity: wishlist

Hi,

I would like to propose a patch with alternatives support.

Before doing this there are some things to confirm:

- are you willing to accept such a patch?

- iputils-arping installs /usr/bin/arping while arping installs
/usr/sbin/arping - I do not think it is a good idea to resolve this by
linking /usr/bin/arping to /usr/sbin/iputils-arping, because it will
create an ambiguity that depends on PATH. Maybe it is a better idea to
make /usr/bin/arping a link to the alternative /usr/sbin/arping?

>From the implementation point of view, in order to have some backward
compatibility, maybe it will be best to make it using the built-in way
of debhelper 13.1 but keep arping.alternatves as disabled and use the
dh_installalternatives generated products in the package instead.

With best regards,
b.

Bug#964099: konversation: tries to join channel before finishing identification

[Vincas Dargis]

Package: konversation
Version: 1.7.5-3
Severity: normal

Dear Maintainer,

Recently I've noticed that I a missing some channels after
(auto-)connecting to chat.freenode.net.

Log shows this:

[21:13] [Pastabos] -NickServ- This nickname is registered. Please choose a 
different nickname, or identify via /msg NickServ identify .
[21:13] [Kanalas] Cannot join channel (+r) - you need to be identified with 
services - see https://freenode.net/kb/answer/registration
[21:13] [Kanalas] Cannot join channel (+r) - you need to be identified with 
services - see https://freenode.net/kb/answer/registration
[21:13] [Pastabos] -NickServ- You are now identified for Talkless.

So, identification, as specified in server settings, does work, but it
"misses" few channels that require identified users, as it seems it
tries to join channels before finishing "nickserv identify"..?

-- 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.7.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8), LANGUAGE=lt 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages konversation depends on:
ii  kio5.70.1-1
ii  konversation-data  1.7.5-3
ii  libc6  2.30-8
ii  libkf5archive5 5.70.0-1
ii  libkf5bookmarks5   5.70.0-1
ii  libkf5codecs5  5.70.0-1
ii  libkf5completion5  5.70.0-1
ii  libkf5configcore5  5.70.0-1
ii  libkf5configgui5   5.70.0-1
ii  libkf5configwidgets5   5.70.0-1
ii  libkf5coreaddons5  5.70.0-1
ii  libkf5crash5   5.70.0-1
ii  libkf5dbusaddons5  5.70.0-1
ii  libkf5emoticons-bin5.70.0-1
ii  libkf5emoticons5   5.70.0-1
ii  libkf5globalaccel-bin  5.70.0-1
ii  libkf5globalaccel5 5.70.0-1
ii  libkf5i18n55.70.0-1
ii  libkf5iconthemes5  5.70.0-1
ii  libkf5idletime55.70.0-1
ii  libkf5itemviews5   5.70.0-1
ii  libkf5kiocore5 5.70.1-1
ii  libkf5kiofilewidgets5  5.70.1-1
ii  libkf5kiowidgets5  5.70.1-1
ii  libkf5notifications5   5.70.0-1
ii  libkf5notifyconfig55.70.0-1
ii  libkf5parts5   5.70.0-1
ii  libkf5service-bin  5.70.0-1
ii  libkf5service5 5.70.0-1
ii  libkf5textwidgets5 5.70.0-1
ii  libkf5wallet-bin   5.70.0-1
ii  libkf5wallet5  5.70.0-1
ii  libkf5widgetsaddons5   5.70.0-1
ii  libkf5windowsystem55.70.0-1
ii  libkf5xmlgui5  5.70.0-1+b1
ii  libphonon4qt5-44:4.11.1-3
ii  libqca-qt5-2   2.2.1-2
ii  libqt5core5a   5.14.2+dfsg-4
ii  libqt5dbus55.14.2+dfsg-4
ii  libqt5gui5 5.14.2+dfsg-4
ii  libqt5network5 5.14.2+dfsg-4
ii  libqt5widgets5 5.14.2+dfsg-4
ii  libqt5xml5 5.14.2+dfsg-4
ii  libstdc++6 10.1.0-4
ii  phonon4qt5 4:4.11.1-3

konversation recommends no packages.

konversation suggests no packages.

-- no debconf information

Bug#963980: bumblebee-nvidia: Bumblebee daemon reported: error: [XORG] (EE) Unable to locate/open config directory

[Vincas Dargis]

I just this:

sudo apt purge --autoremove nvidia*
sudo apt install nvidia-driver bumblebee-nvidia primus-nvidia primus-vk-nvidia

And after reinstalling driver and all other bumbleblee-related packages, it 
started to work again.

Bug#964098: xiphos: package new upstream release: 4.2.1

[Roberto C. Sanchez]

Package: xiphos
Version: 4.1.0.1+dfsg1-1
Severity: wishlist

It would be good if we could package the new upstream release 4.2.1
fairly soon.

Regards,

-Roberto

Bug#634005: arping should use alternatives to remove conflict with iputils-arping

[Boian Bonev]

Hi,

I would like to propose a patch with alternatives support.

Before doing this there are some things to confirm:

- are you willing to accept such a patch?

- are /usr/sbin/arping-arping and /usr/share/man/man8/arping-
arping.8.gz good name choices for the files installed by this package?

- iputils-arping installs /usr/bin/arping while arping installs
/usr/sbin/arping - I do not think it is a good idea to resolve this by
linking /usr/bin/arping to /usr/sbin/iputils-arping, because it will
create an ambiguity that depends on PATH. Maybe it is a better idea to
make /usr/bin/arping a link to the alternative /usr/sbin/arping?

>From the implementation point of view, in order to have some backward
compatibility, maybe it will be best to make it using the built-in way
of debhelper 13.1 but keep arping.alternatves as disabled and use the
dh_installalternatives generated products in the package instead.

With best regards,
b.

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Andrey Rahmatullin]

On Wed, Jul 01, 2020 at 05:35:21PM +0100, Joan Moreau wrote:
> This is not a "source package" as the source is in Pascal (using Lazarus
> compiler package). Should I include the Pascal source also ?
You need to create a Debian source package that can be built to produce a
Debian binary package.
It doesn't really matter what language is used or what should be contained
in the binary package. The workflow is the same.
https://wiki.debian.org/Packaging/SourcePackage

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#908814: origtargz: handle .asc upstream signatures

[Xavier]

Le 01/07/2020 à 17:04, Mattia Rizzolo a écrit :
> On Wed, Jul 01, 2020 at 04:34:32PM +0200, Xavier wrote:
>> --- a/scripts/origtargz.pl
>> +++ b/scripts/origtargz.pl
>> @@ -343,6 +343,7 @@ sub unpack_tarball (@) {
>>
>>  for my $origtar (@origtar) {
>>  my $tmpdir = File::Temp->newdir(DIR => ".", CLEANUP => 1);
>> +next if $origtar =~ /\.(?:asc|sig)$/;
>>  print "Unpacking $origtar\n";
>>  my $cmp = ($origtar =~ /orig(?:-([\w\-]+))?\.tar/)[0] || '';
>>  if ($cmp) {
> 
> 
> Mh, but I doubt it does what this bug is about: it should *extract* the
> .asc files from pristine-tar if they matches the version.  I suppose it
> needs to somehow check whether the .asc is present and if it pass it via
> the -s option of `pristine-tar checkout` (at line 255).
> 
> Perhaps indeed we also need this bit you proposed, though I admit I
> never used --unpack :D

In a previous comment, the bug was related to --path option (which
currently fail with a .asc file since it tries to extract it)

Bug#963689: How may I collect information for debugging this problem?

[Giuseppe Sacco]

Hello kernel developers,
I wish to collect more information about this problem. How may I
achieve it? I tried many boot parameters but no more messages have been
printed. Is there anything I may do? Should I use specially crafted
initrd images?

Thank you,
Giuseppe

Bug#960084: Fixed bug ?

[Thomas Nemeth]

   Hi.

   I have the same problem about ff not taking into account the installed
   langpack each time there is a ff upgrade. I just switched from ff77 to
   ff78 and the interface switched back to english so I had to manually
   select and install my language from the preferences page.

   That's when I saw this "fixed" bug. It doesn't seems fixed in my point
   of view because when I opened ff it was again in english. Reading the
   last message in the ticket, I started ff with a new profile and indeed
   the new profile opened in my language.

   There are 3 observations that I could make at the moment :
   1. first there were 3 profiles :
  - mine (default)
  - another (default_release)
  - the newly created (tests)
   2. that behavior (re-installing locales after each upgrade) appeared
  when I switched from ff-esr to ff
   3. it seams that my default profile (holding my configuration and
  everything I need for day-to-day use) is not linked with the
  system's langpack, but only the one I install from the preferences.

   Is there a mean to connect my profile with the system l10n package
   instead of the one installed from the preferences page ?

Bug#964097: gitlab: "git push" fails with a stacktrace in gitlab code due to outdated ruby version

[Maximilian Stein]

Source: gitlab
Version: 13.1.1-1+fto10+1
Severity: important

Dear Maintainer,

After upgrade to above mentioned version, `git push`es started to fail
on my repositories (while `git pull`s continued working).
Investigating the issue I noticed that there were stack traces logged
into /var/log/gitlab/exceptions_json.log every time I tried pushing.

The stack traces pointed to lib/gitlab/gl_repository/identifier.rb:52,
where apparently a string is converted to an integer. The excetion
message reads "wrong number of arguments (given 3, expected 1..2)".
According to the documentation of ruby, there were only two arguments
to `Integer` in 2.5.1
(https://ruby-doc.org/core-2.5.1/Kernel.html#method-i-Integer), while
there was a third one added later (e.g. present in 2.7). However,
since my system is based on buster, I have ruby 2.5.1 installed.

I could work around my issue by removing the third `exception: false`
parameter to `Integer` in
/usr/share/gitlab/lib/gitlab/gl_repository/identifier.rb:52.

Since there is no newer ruby version available in backports or
fasttrack, I'd prefer to stick to the stable version. What solution
can you recommend? Do you need any more information?

Relevant package versions:

gitlab: 13.1.1-1+fto10+1
gitlab-common: 13.1.0+dfsg-1~bpo10+1
gitaly: 13.1.0+dfsg-1~bpo10+1
gitlab-shell: 13.3.0+debian-1~bpo10+1

Best,
Maximilian

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

Package: sponsorship-requests

Severity: normal [important for RC bugs, wishlist for new packages]



Dear mentors,



I am looking for a sponsor for my package "tomboy-reborn"



 * Package name: tomboy-reborn

   Version : 1.0-1

   Upstream Author : Joan Moreau 

 * URL :  https://github.com/grosjo/

 * License : GPL




It builds those binary packages:



  tomboy-reborn - A drop in replacement of legacy Gnome Tomboy, with
network sync (Owncloud/Nextcloud) fully implemented


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

https://github.com/grosjo/tomboy-reborn



Regards,



Joan Moreau

Bug#947351: buster-pu: package cloud-init/20.2-2+deb10u1

[R hertoric]

Adam I'm not sure what's going on or whats my role role in Debian. Please
if someone could tell me what is happening I deciphered
Pubian on March 5 2020 I tried to send you a message from
rhetoricb...@gmail.com and the profile says Pete Y. My emails are being
erased so if you don't get this I'm not surprised but if you could you send
a text or call 5045038792.

 Thank you, Mark Reddin

On Wed, Jul 1, 2020 at 7:00 AM Adam D. Barratt 
wrote:

> On Tue, 2020-06-30 at 17:45 -0700, Noah Meyerhans wrote:
> > Control: retitile -1 buster-pu: package cloud-init/20.2-2+deb10u1
> > Control: tags +
> > patch
>
> I'm not sure that tagging pu bugs "patch" makes much sense, fwiw. Any
> pu bug that doesn't have a patch attached is by definition incomplete.
>
> > Let's try to finally get something done with this cloud-init update.
> > The request is to update to upstream version 20.2 in buster.  This
> > version is currently in both testing and buster-backports.  It has
> > been tested by the cloud team and others in common cloud environments
> > including Microsoft Azure, AWS, and OpenStack.  It contains fixes for
> > bugs including #936030, and implements support for the IMDSv2 API in
> > Amazon EC2.
> >
> > It backports cleanly from testing to buster, with no changes beyond
> > the debian/changelog update.
>
> Have the changes been tested on buster using this proposed package, or
> just with the unstable/testing/backports versions?
>
> What does a binary debdiff between the current stable package and the
> proposed package look like?
>
> > Full debdiff against buster's 18.3-6 is attached.
>
> fwiw, that debdiff was large enough (even compressed) that the mail
> didn't make it to debian-release.
>
> +cloud-init (20.2-2+deb10u1) buster; urgency=medium
>
> The version needs to be /lower/ than the package in unstable, so a
> backported version is 20.2-2~deb10u1, similarly to bpo.
>
> Regards,
>
> Adam
>
>

Bug#964096: mesa: SIGSEGV in iris_dri.so using mpv/ffplay/vlc, Intel HD Graphics 530

[Ben Wiederhake]

Package: libgl1-mesa-dri
Version: 20.1.2-1
Severity: normal

mesa: SIGSEGV in iris_dri.so using mpv/ffplay/vlc, Intel HD Graphics 530

Dear Maintainer,

This is different from #959400.

I have a particular file [1] ripped from youtube, and trying to open it with
*any* of mpv, ffplay, or vlc results in the same few first seconds on audio,
and then a crash (SIGSEGV).
This bugs seems to happen with *every* Video I have available, no matter
whether it's webm or flv or mkv or mp4. Note that firefox has no trouble.

gdb points to stream_state in iris_blorp.c:62, which effectively dereferences
res=0x0. See backtrace below.

This is a different backtrace than #959400.
Before you ask: Yes, I can trigger #959400 by running glxgears. Again, this
seems to be a different bug from that.

Here's the relevant part of iris_blorp.c, function stream_state:
   struct pipe_resource *res = NULL;
   // …
   u_upload_alloc(…, …, …, …, …, , …);
   struct iris_bo *bo = iris_resource_bo(res);

The function iris_resource_bo() basically just reads from the given pointer.

My best guess: The function stream_state forgets to check from errors during
u_upload_alloc(). No idea why that would fail, but it does.
The function u_upload_alloc (u_upload_mgr.c:238) has two paths to return
nullptr, so this should be checked by stream_state.

Cheers,
Ben

EXAMPLE FILE

https://www.youtube.com/watch?v=D8EeWgXRYFc
Again, this seems to happen with basically every file, but just in case:
$ sha256sum 'Max Cooper - Supine Official video by Tom
Geraedts-D8EeWgXRYFc.mkv'
dbb4257a69ade0f888f10ebe86b5512e291c62f5b5dce33c989bade02496897b

GDB BACKTRACE

#0  stream_state (batch=0x5580c0f0, uploader=, size=12,
alignment=alignment@entry=64, out_offset=out_offset@entry=0x7fffce9c,
out_bo=out_bo@entry=0x0)
at ../src/gallium/drivers/iris/iris_blorp.c:62
#1  0x7fffe7d70251 in blorp_alloc_dynamic_state
(blorp_batch=0x7fffd7b0, blorp_batch=0x7fffd7b0, offset=0x7fffce9c,
alignment=64, size=)
at ../src/gallium/drivers/iris/iris_blorp.c:138
#2  blorp_emit_blend_state (params=0x7fffd050, batch=0x7fffd7b0) at
../src/intel/blorp/blorp_genX_exec.h:1080
#3  blorp_emit_pipeline (params=0x7fffd050, batch=0x7fffd7b0) at
../src/intel/blorp/blorp_genX_exec.h:1271
#4  blorp_exec (params=0x7fffd050, batch=0x7fffd7b0) at
../src/intel/blorp/blorp_genX_exec.h:2015
#5  iris_blorp_exec (blorp_batch=0x7fffd7b0, params=0x7fffd050) at
../src/gallium/drivers/iris/iris_blorp.c:310
#6  0x7fffe7f3b5a4 in blorp_clear (batch=batch@entry=0x7fffd7b0,
surf=surf@entry=0x7fffd7e0, format=ISL_FORMAT_B8G8R8X8_UNORM, swizzle=...,
swizzle@entry=..., level=level@entry=0, start_layer=0, num_layers=1, x0=0,
y0=0, x1=1280, y1=560, clear_color=..., color_write_disable=0x7fffd7d0)
at ../src/intel/blorp/blorp_clear.c:548
#7  0x7fffe7d4bb4d in clear_color
(ice=ice@entry=0x5580bc70, p_res=, level=, box=box@entry=0x7fffd8d0,
render_condition_enabled=render_condition_enabled@entry=true, format=, swizzle=..., color=...) at ../src/gallium/drivers/iris/iris_clear.c:389
#8  0x7fffe7d4c8bb in iris_clear (ctx=0x5580bc70, buffers=4,
scissor_state=, p_color=0x557d8e24, depth=,
stencil=)
at ../src/gallium/drivers/iris/iris_clear.c:680
#9  0x7fffe72dc2bb in st_Clear (ctx=0x557c6b20, mask=2) at
../src/mesa/state_tracker/st_cb_clear.c:540
#10 0x75cf601a in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#11 0x75ce9911 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#12 0x75cef0bd in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#13 0x5556659c in  ()
#14 0x5556c9cf in  ()
#15 0xc7f0 in main ()
(gdb) bt full
#0  stream_state (batch=0x7fffc81b8fe0, uploader=, size=12,
alignment=alignment@entry=64, out_offset=out_offset@entry=0x7fffcf7fbc5c,
out_bo=out_bo@entry=0x0)
at ../src/gallium/drivers/iris/iris_blorp.c:62
res = 0x0
ptr = 0x0
bo = 
#1  0x7fffcdc40251 in blorp_alloc_dynamic_state
(blorp_batch=0x7fffcf7fc570, blorp_batch=0x7fffcf7fc570, offset=0x7fffcf7fbc5c,
alignment=64, size=)
at ../src/gallium/drivers/iris/iris_blorp.c:138
ice = 
batch = 
blend =
  {YDitherOffset = 0, XDitherOffset = 0, ColorDitherEnable = false,
AlphaTestFunction = COMPAREFUNCTION_ALWAYS, AlphaTestEnable = false,
AlphaToCoverageDitherEnable = false, AlphaToOneEnable = false,
IndependentAlphaBlendEnable = false, AlphaToCoverageEnable = false}
state = 
offset = 4294967295
size = 
pos = 
blend_state_offset = 0
urb_deref_block_size = GEN_URB_DEREF_BLOCK_SIZE_32
ice = 0x7fffc81b8b60
batch = 0x7fffc81b8fe0
scale = 
skip_bits = 



-- Package-specific info:
glxinfo:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:

Bug#964092: [pkg-cryptsetup-devel] Bug#964092: cryptsetup: annotate test-only Build-Depends with

[guilhem]

Control: tag -1 pending

Hi Helmut!

On Wed, 01 Jul 2020 at 17:33:52 +0200, Helmut Grohne wrote:
> I've figured a number of dependencies that can quite simply be dropped
> with DEB_BUILD_OPTIONS=nocheck.

Ah right, we added these Build-Depends in 265287ec and a032158c after we
started running the upstream test-suite during non-nocheck builds.  I
confess I wasn't aware of , thanks for the info :-)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#963560: main.pdf: openBinaryFile: does not exist

[Dirk Hünniger]

Hi,

the -k option is not intended to be used on Wikibooks. For Wikibooks you 
usually start with the print version. For some Wikibooks using -m or -i 
can be useful when creating LaTeX version. The option -k was intended 
for books in Wikipedia Book namespace like


https://en.wikipedia.org/wiki/Book:River_martin

The idea is to denote which subpages a book consists of and their order. 
On Wikipedia Book namespace it is a list of wikilinks to page on Wikipedia.


On Wikibooks it mediawikis template transclusion mechanism, that you 
will understand when viewing the source of the printable version of a 
wikibook.


Yours Dirk

On 7/1/20 4:41 PM, ael wrote:

On Wed, Jul 01, 2020 at 08:52:51AM +0200, Dirk Hünniger wrote:

Hi,

thats strange. I got an epub with

mediawiki2latex -u https://en.wikibooks.org/wiki/Haskell/Type_basics -o
Haskell.epub -b

what command line did you use.

I tried again with -i and this time the error was

Error downloading the lemma "zh:Haskell" form the url "Just (URL {url_type = Absolute (Host {protocol = HTTP True, host = "en.wikibooks.org", port = 
Nothing}), url_path = "wiki/Haskell", url_params = []},[URL {url_type = Absolute (Host {protocol = HTTP True, host = "en.wikibooks.org", port = Nothing}), 
url_path = "wiki", url_params = []},URL {url_type = Absolute (Host {protocol = HTTP True, host = "en.wikibooks.org", port = Nothing}), url_path = "", 
url_params = []},URL {url_type = Absolute (Host {protocol = HTTP True, host = "commons.wikimedia.org", port = Nothing}), url_path = "wiki", url_params = 
[]}])"

But it ran for a substantial time before hitting that error.

So that was with a command line of:
   mediawiki2latex -u https://en.wikibooks.org/wiki/Haskell -o 
/tmp/Haskell.epub -b -k -i

ael

Bug#964093: kombu: please drop python3-importlib-metadata dependency

[Gianfranco Costamagna]

Source: kombu
Version: 4.6.11-2
Severity: normal
tags: patch

>From Ubuntu:
kombu (4.6.7-1ubuntu1) focal; urgency=medium

  * d/control: Move python3-importlib-metadata to Suggests since
/usr/lib/python3.8/importlib/metadata.py is provided by the Python 3.8
standard library and Python 3.8 will be the default for Ubuntu Focal.
The python3-importlib-metadata dependency can be dropped entirely once
Python 3.8 is the minimum available python version (LP: #1851393).

 -- Corey Bryant   Mon, 10 Feb 2020 09:18:35 -0500


Can you please apply too?

./requirements/default.txt:importlib-metadata>=0.18; python_version<"3.8"
./extra/requirements/default.txt:importlib-metadata>=0.18; python_version<"3.8"


trivial patch:
diff -Nru kombu-4.6.11/debian/control kombu-4.6.11/debian/control
--- kombu-4.6.11/debian/control 2020-07-01 07:14:18.0 +0200
+++ kombu-4.6.11/debian/control 2020-07-01 18:31:32.0 +0200
@@ -20,7 +20,6 @@
  python3-botocore ,
  python3-case ,
  python3-django ,
- python3-importlib-metadata ,
  python3-mock ,
  python3-msgpack ,
  python3-pymongo ,
@@ -70,7 +69,6 @@
 Depends:
  python3-amqp (>= 1.4.6),
  python3-anyjson (>= 0.3.3),
- python3-importlib-metadata,
  ${misc:Depends},
  ${python3:Depends},
 Recommends:

Bug#937009: [Python-apps-team] Bug#937009: mercurial: Python2 removal in sid/bullseye

[Julien Cristau]

On Sat, Jun 27, 2020 at 22:13:10 -0400, Sandro Tosi wrote:

> Hey Julien,
> 
> On Thu, Apr 9, 2020 at 5:47 AM Julien Cristau  wrote:
> >
> > On Thu, Apr  9, 2020 at 01:17:06 -0400, Sandro Tosi wrote:
> >
> > > Hello Julien,
> > >
> > > On Tue, Feb 18, 2020 at 12:33 PM Julien Cristau  
> > > wrote:
> > > > Before switching in sid I'd want to:
> > > > - be able to use the python3 version myself
> > > > - give extensions some time to figure out their own switch
> > > > - ideally not regress significant functionality; e.g. python-subversion
> > > >   is still not available for python3
> > > >
> > > > I don't know what that means in terms of timeframe, it may or may not
> > > > happen in time for bullseye, but I'm also not in a rush and I'd rather
> > > > not break stuff by switching too early.
> > >
> > > I see that python3-enabled mercurial has been in experimental for a 3
> > > weeks now, how's it going? it would greatly help progress with the
> > > overall py2removal effort if we could start planning to upload that
> > > mercurial release to sid.
> > >
> > > Can you share with us your plans here?
> > >
> > Still need to coordinate with packaged extensions.
> 
> what happened to the python3 port that was uploaded in experimental as
> part of 5.4-1+exp1 ? it seems it got lost when 5.4-2 was uploaded to
> unstable? (btw debian/experimental in git doesnt seem to be up-to-date
> with what reached the archived)
> 
Yeah basically fixing the RC bug in sid took priority and then I ran out
of steam before merging back to experimental.  I also want to figure out
how to deal with #961245 there going forward.

> Do you need any help in coordinating with the packaged extensions,
> testing changes, preparing patches? a lot of time has passed since we
> started asking about mercurial and python3 and it is becoming the only
> reverse-dependency of several packages that could be removed if
> mercurial switched to py3k.
> 
Getting an uptodate list of extensions and their status wrt porting both
upstream and in Debian would be useful.  I've spent some time looking at
hgsubversion a few weeks ago but there's a ton of work and I don't
actually use it so I've kind of given up on that; I forget what the
status is on others.

Cheers,
Julien

Bug#964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup

[Chris Hofstaedtler]

Control: tags -1 + pending

Hi Helmut,

thank you for your input.

* Helmut Grohne  [200701 17:06]:
> Source: util-linux
> Version: 2.35.2-6
> Severity: important
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> Until recently, util-linux wasn't involved with cryptsetup and we could
> build it quite early. Now libmount-dev Depends on libcryptsetup-dev.
> That means src:cryptsetup must be built before src:util-linux. However
> libcryptsetup Build-Depends on uuid-dev, which is built from
> src:util-linux. This doesn't work as is and needs more work.
> 
> Therefore, I ask you to revert the dependency on cryptsetup right now. I
> acknowledge that doing so reopens #951048, but trading a wishlist bug
> for an important regression seems reasonable to me. 

As said in the other bug that is caused by this feature, my plan is
to revert the change for now. However, I'm waiting for bsdmainutils
to pass through NEW, as it depends on util-linux 2.35.2-7 in a
complicated transition.


> I'm not trying to
> block that feature permanently, but merely gaining some time to figure
> it out properly. It is important to solve this quickly as this
> regression makes other problems elsewhere in essential invisible. In
> doing so, they become harder to track down. Just waiting causes damage.

If NEW processing takes time, we all will have to wait.
Quick actions make the bsdmainutils transition harder than it
already is, and I don't intend to make to go this route.

> One thing that bothers me is that src:util-linux Build-Depends on
> libcryptsetup-dev with a  while libmount-dev unconditionally
> Depends on libcryptsetup-dev.
> 
> If you don't need libcryptsetup-dev for building libmount-dev, then the
> dependency should be unnecessary. However, as #963704 turned up. We do
> need that dependency. Simply marking it with  is not a good
> idea. Then you have two different packages both called "libmount-dev"
> with differing contents. There is no sane way to depend on libmount-dev
> with dm-verity support or libmount-dev without dm-verity support. So
> that's not an option.
> 
> Essentially, this means that the  profile needs to be dropped
> from the libcryptsetup-dev build dependency. That in turn causes a
> direct dependency cycle with src:cryptsetup. We don't want that either.
> 
> So this doesn't work either. It's not that easy. Can you maybe shed some
> light on how libmount-dev integrates with cryptsetup?

I think Luca has already replied to you for this.

> Given that util-linux has a history of being maintained with NMUs, I
> intend to continue that trend barring a timely response. I'm positive
> that we'll find a permanent solution in time for bullseye.

I'm positive about the bullseye permanent solution, BUT:
util-linux now has an active maintainer (hi!), and I intend to NAK
your NMU if you upload one. Sorry.

I'll upload a version reverting the cryptsetup thing once
bsdmainutils has passed NEW.

> Right now, I'm going to look into cryptsetup and will try reducing its
> Build-Depends to make it easier to include in architecture bootstrap.

Great.

I'm looking forward to working with you on solving this rebootstrap
cycle :-)

Chris

Bug#964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup

[Luca Boccassi]

On Wed, 2020-07-01 at 18:14 +0200, Helmut Grohne wrote:
> Hi Luca,
> 
> On Wed, Jul 01, 2020 at 04:42:14PM +0100, Luca Boccassi wrote:
> > The dependency is hard-coded right now, but as far as I can see it
> > doesn't have to be - it could be generated at build time, depending on
> > the stage. This could be done immediately as far as I can see - what
> > about something like the following in d/rules:
> > 
> > ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
> > ...
> > else
> > LIBMOUNT_DEPENDS=libcrypsetup-dev
> > ...
> > endif
> > ...
> > override_dh_gencontrol:
> > dh_gencontrol -- -V"libmount-dev:Depends=$(LIBMOUNT_DEPENDS)"
> > 
> > 
> > and ${libmount-dev:Depends} in d/control instead of the hard-coded dep.
> 
> On a technical level, you can achieve the same effect by writing
> 
> Depends: libcryptsetup-dev 
> 
> in debian/control. dpkg will evaluate the profile restriction at build
> time. The question is not how to suppress the dependency, but whether
> doing so is correct.

Nice! For some reason I thought only Build-Depends* supported profiles.
TIL.

> > The dependency is only needed if the pkg-config file Requires.private
> > mentions libcrypsetup, which won't be the case in a stage1-built
> > package.
> 
> This doesn't look right to me. If libmoun-dev's pkg-config file lists
> libcrypsetup, then it should do so unconditionally. Otherwise you get
> two different libmount-dev that are slightly API-incompatible. Reducing
> functionality is ok, but you need to change the binary package name in
> such cases. Compare hurd-dev vs hurd-headers-dev. hurd-headers-dev kinda
> is a subset of hurd-dev and not built by default. In a regular build,
> hurd-dev simply provides hurd-headers-dev.
> 
> For libmount-dev that'd likely amount to providing something like
> libmount+dm-verity-dev and somehow ensuring that anyone who needs the
> dm-verity feature depends on that virtual package.
> 
> Does that make sense to you? It still makes libmount-dev unreproducible,
> but it seems like we cannot have everything.

This is how upstream generates the pkg-config files for all components
of util-linux - and it's how most libraries with optional features that
I've come across do as well. If a feature is not built, and thus the
binary does not link to the library, the dependency is not listed in
pkg-config. And to me it would appear the correct thing to do - the
point of pkg-config is to list what is needed to link against that
library, not a hypotethical version with everything enabled - so I
don't see upstream changing that any time soon.

For libmount for example you get the exact same result w.r.t.
libselinux.

> > Then in the near future, I've proposed the following changes, which
> > look like will be accepted for 2.36: 
> > https://github.com/karelzak/util-linux/pull/1084
> > That means the dependency can be removed entirely, as pkg-config will
> > no longer list libcrypsetup in its Requires.private when using --with-
> > cryptsetup=dlopen.
> 
> That sounds like we can quite simply solve the whole mess by waiting. We
> can revert libcryptsetup now and put it back when uploading 2.36. Does
> that work for you?
> 
> In the mean time, I've filed #964092, but I don't think it's going to
> cut it here.
> 
> Helmut

As far as I can see in the repo on Salsa it's already been reverted,
and waiting for some binary-new to be processed before upload.

I'll likely provide a backported patch as soon as the PR is merged -
I'd really like to get more stress-test under way long before the
bullseye freeze.

-- 
Kind regards,
Luca Boccassi


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

Bug#964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup

[Helmut Grohne]

Hi Luca,

On Wed, Jul 01, 2020 at 04:42:14PM +0100, Luca Boccassi wrote:
> The dependency is hard-coded right now, but as far as I can see it
> doesn't have to be - it could be generated at build time, depending on
> the stage. This could be done immediately as far as I can see - what
> about something like the following in d/rules:
> 
> ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
> ...
> else
> LIBMOUNT_DEPENDS=libcrypsetup-dev
> ...
> endif
> ...
> override_dh_gencontrol:
> dh_gencontrol -- -V"libmount-dev:Depends=$(LIBMOUNT_DEPENDS)"
> 
> 
> and ${libmount-dev:Depends} in d/control instead of the hard-coded dep.

On a technical level, you can achieve the same effect by writing

Depends: libcryptsetup-dev 

in debian/control. dpkg will evaluate the profile restriction at build
time. The question is not how to suppress the dependency, but whether
doing so is correct.

> The dependency is only needed if the pkg-config file Requires.private
> mentions libcrypsetup, which won't be the case in a stage1-built
> package.

This doesn't look right to me. If libmoun-dev's pkg-config file lists
libcrypsetup, then it should do so unconditionally. Otherwise you get
two different libmount-dev that are slightly API-incompatible. Reducing
functionality is ok, but you need to change the binary package name in
such cases. Compare hurd-dev vs hurd-headers-dev. hurd-headers-dev kinda
is a subset of hurd-dev and not built by default. In a regular build,
hurd-dev simply provides hurd-headers-dev.

For libmount-dev that'd likely amount to providing something like
libmount+dm-verity-dev and somehow ensuring that anyone who needs the
dm-verity feature depends on that virtual package.

Does that make sense to you? It still makes libmount-dev unreproducible,
but it seems like we cannot have everything.

> Then in the near future, I've proposed the following changes, which
> look like will be accepted for 2.36: 
> https://github.com/karelzak/util-linux/pull/1084
> That means the dependency can be removed entirely, as pkg-config will
> no longer list libcrypsetup in its Requires.private when using --with-
> cryptsetup=dlopen.

That sounds like we can quite simply solve the whole mess by waiting. We
can revert libcryptsetup now and put it back when uploading 2.36. Does
that work for you?

In the mean time, I've filed #964092, but I don't think it's going to
cut it here.

Helmut

Bug#963560: main.pdf: openBinaryFile: does not exist

[Dirk Hünniger]

Sorry *won't* face problems with that of course

On 7/1/20 5:57 PM, Dirk Hünniger wrote:

Hi,

I think just changing the manpage is Ok. I was unaware that rec 
dependencies are installed by default, but since this is the case most 
people will face problems with that.


Yours Dirk

On 7/1/20 5:30 PM, Georges Khaznadar wrote:

Dear Dirk,

promoting packages from Recommended to straigt dependencies deserves
always some discussion.

I have been prompted more than once by people who wanted to build the
smallest possible machine or container, for a particular feature; they
raised bugreports to ask for a downgrade from Depends to Recommends. 
As a

matter of fact, one can wish to build a web service to print parts of
wikipedia, so it is sensible to minimize the footprint of 
mediawiki2latex

(m2l).

If generating EPUB files is not demanded by many m2l users, just let the
package Calibre remain as a recommendation, because it has a heavy
footprint, by the means of his own dependencies.

Ordinary users do not want to tune their Debian system, so they let APT
settings as they come by default, and the default is currently to
download recommended additional packages.

The discussion about missing calibre could arise with ael, because he is
a power user, who did not keep the default settings for APT.

An alternative to promoting calibre from recommended to a dependency is
to check whether mediawiki2latex' manpage (and other documents about it)
have a section about features, and packages necessary to provide those
features. I had a look at the file mediawiki2latex.1.in

I suppose that the excerpt:

.BR -b ", " --epub
Output epub file.

Can be enhanced by mentioning calibre, for instance:

.BR -b ", " --epub
Output epub file. This feature relies on the recommended package 
calibre.


Also, when options -b or --epub are triggered, and calibre is not found,
mediawiki2latex might issue some warning, or some "rtfm" stance.

Best regards,    Georges.

Dirk Hünniger a écrit :

Hi,

in deed calibre is requierd to generate epub files. As is 
libreoffice for

odt files.

latex2rtf or something like that was needed to make raster image 
form latex

formulas, although I am currently unsure about the exact detail.

Georges: Could you please make a new package replacing all rec 
dependencies

with dep dependencies.

Yours Dirk

On 01.07.20 14:59, ael wrote:

On Wed, Jul 01, 2020 at 09:03:33AM +0200, Dirk Hünniger wrote:

oh and you you check if calibre is installed?

No, it wasn't. I see that it is a "Recommends". I now wonder whether I
might also need latex2rtf, although that isn't so obvious.

ael

Bug#963560: main.pdf: openBinaryFile: does not exist

[Dirk Hünniger]

Hi,

I think just changing the manpage is Ok. I was unaware that rec 
dependencies are installed by default, but since this is the case most 
people will face problems with that.


Yours Dirk

On 7/1/20 5:30 PM, Georges Khaznadar wrote:

Dear Dirk,

promoting packages from Recommended to straigt dependencies deserves
always some discussion.

I have been prompted more than once by people who wanted to build the
smallest possible machine or container, for a particular feature; they
raised bugreports to ask for a downgrade from Depends to Recommends. As a
matter of fact, one can wish to build a web service to print parts of
wikipedia, so it is sensible to minimize the footprint of mediawiki2latex
(m2l).

If generating EPUB files is not demanded by many m2l users, just let the
package Calibre remain as a recommendation, because it has a heavy
footprint, by the means of his own dependencies.

Ordinary users do not want to tune their Debian system, so they let APT
settings as they come by default, and the default is currently to
download recommended additional packages.

The discussion about missing calibre could arise with ael, because he is
a power user, who did not keep the default settings for APT.

An alternative to promoting calibre from recommended to a dependency is
to check whether mediawiki2latex' manpage (and other documents about it)
have a section about features, and packages necessary to provide those
features. I had a look at the file mediawiki2latex.1.in

I suppose that the excerpt:

.BR -b ", " --epub
Output epub file.

Can be enhanced by mentioning calibre, for instance:

.BR -b ", " --epub
Output epub file. This feature relies on the recommended package calibre.

Also, when options -b or --epub are triggered, and calibre is not found,
mediawiki2latex might issue some warning, or some "rtfm" stance.

Best regards,   Georges.

Dirk Hünniger a écrit :

Hi,

in deed calibre is requierd to generate epub files. As is libreoffice for
odt files.

latex2rtf or something like that was needed to make raster image form latex
formulas, although I am currently unsure about the exact detail.

Georges: Could you please make a new package replacing all rec dependencies
with dep dependencies.

Yours Dirk

On 01.07.20 14:59, ael wrote:

On Wed, Jul 01, 2020 at 09:03:33AM +0200, Dirk Hünniger wrote:

oh and you you check if calibre is installed?

No, it wasn't. I see that it is a "Recommends". I now wonder whether I
might also need latex2rtf, although that isn't so obvious.

ael

Bug#963560: main.pdf: openBinaryFile: does not exist

[Dirk Hünniger]

Hi,

I got an epub that looks Ok using the following command line

mediawiki2latex -u https://en.wikibooks.org/wiki/Haskell/Print_version 
-b -o Haskell.epub


Yours Dirk

On 7/1/20 4:41 PM, ael wrote:

On Wed, Jul 01, 2020 at 08:52:51AM +0200, Dirk Hünniger wrote:

Hi,

thats strange. I got an epub with

mediawiki2latex -u https://en.wikibooks.org/wiki/Haskell/Type_basics -o
Haskell.epub -b

what command line did you use.

I tried again with -i and this time the error was

Error downloading the lemma "zh:Haskell" form the url "Just (URL {url_type = Absolute (Host {protocol = HTTP True, host = "en.wikibooks.org", port = 
Nothing}), url_path = "wiki/Haskell", url_params = []},[URL {url_type = Absolute (Host {protocol = HTTP True, host = "en.wikibooks.org", port = Nothing}), 
url_path = "wiki", url_params = []},URL {url_type = Absolute (Host {protocol = HTTP True, host = "en.wikibooks.org", port = Nothing}), url_path = "", 
url_params = []},URL {url_type = Absolute (Host {protocol = HTTP True, host = "commons.wikimedia.org", port = Nothing}), url_path = "wiki", url_params = 
[]}])"

But it ran for a substantial time before hitting that error.

So that was with a command line of:
   mediawiki2latex -u https://en.wikibooks.org/wiki/Haskell -o 
/tmp/Haskell.epub -b -k -i

ael

Bug#964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup

[Luca Boccassi]

On Wed, 2020-07-01 at 17:23 +0200, Helmut Grohne wrote:
> Hi Luca,
> 
> On Wed, Jul 01, 2020 at 04:16:22PM +0100, Luca Boccassi wrote:
> > Forgive the naive question, but aren't build profiles and stages
> > supposed to be used in these cases, to help with bootstrapping? Eg: do
> > a stage1 build with reduced features/dependencies, then rebuild
> > everything again. Is my understanding wrong?
> 
> Yes, that's the idea. However profiles are not a silver bullet and they
> don't magically solve all of your problems. A stage1 build of util-linux
> still produces a libmount-dev that Depends on libcryptsetup-dev. How do
> you envision to solve this?
> 
> Helmut

The dependency is hard-coded right now, but as far as I can see it
doesn't have to be - it could be generated at build time, depending on
the stage. This could be done immediately as far as I can see - what
about something like the following in d/rules:

ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
...
else
LIBMOUNT_DEPENDS=libcrypsetup-dev
...
endif
...
override_dh_gencontrol:
dh_gencontrol -- -V"libmount-dev:Depends=$(LIBMOUNT_DEPENDS)"


and ${libmount-dev:Depends} in d/control instead of the hard-coded dep.
The dependency is only needed if the pkg-config file Requires.private
mentions libcrypsetup, which won't be the case in a stage1-built
package.

Then in the near future, I've proposed the following changes, which
look like will be accepted for 2.36: 
https://github.com/karelzak/util-linux/pull/1084
That means the dependency can be removed entirely, as pkg-config will
no longer list libcrypsetup in its Requires.private when using --with-
cryptsetup=dlopen.

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#958169: lxterminal doesn't recognize URLs anymore

[mattia]

Hi,

On Fri, May 15, 2020 at 08:11:21PM +0300, Andriy Grytsenko wrote:
> >Upstream LXTerminal has fixed this issue in the following commit:
> >https://github.com/lxde/lxterminal/commit/b1e3db193651b33db1e112a71ccc1e9868f37093
> 
> Thank you very much for pointing on that.
> Then it will be fixed on next upload which I hope happens soon.

This bug is quite very annoying to me, and it had a fix available for
quite some time.
Would you please consider doing an upload with this fix?  Else, would
you mind if I did a NMU of lxterminal?

Thanks for maintaining my terminal emulator of choice! ;)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#964092: cryptsetup: annotate test-only Build-Depends with

[Helmut Grohne]

Source: cryptsetup
Version: 2:2.3.3-1
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

util-linux recently introduced a dependency cycle with cryptsetup. For
that reason, I was looking into reducing crypsetup's Build-Depends. I
don't have a lot yet, but I've figured a number of dependencies that can
quite simply be dropped with DEB_BUILD_OPTIONS=nocheck. Please consider
applying the attached patch even though it doesn't solve the dependency
cycle.

Helmut
diff --minimal -Nru cryptsetup-2.3.3/debian/changelog 
cryptsetup-2.3.3/debian/changelog
--- cryptsetup-2.3.3/debian/changelog   2020-06-04 01:41:44.0 +0200
+++ cryptsetup-2.3.3/debian/changelog   2020-07-01 17:03:19.0 +0200
@@ -1,3 +1,10 @@
+cryptsetup (2:2.3.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate Build-Depends with . (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 01 Jul 2020 17:03:19 +0200
+
 cryptsetup (2:2.3.3-1) unstable; urgency=medium
 
   [ Guilhem Moulin ]
diff --minimal -Nru cryptsetup-2.3.3/debian/control 
cryptsetup-2.3.3/debian/control
--- cryptsetup-2.3.3/debian/control 2020-06-04 01:41:44.0 +0200
+++ cryptsetup-2.3.3/debian/control 2020-07-01 17:03:19.0 +0200
@@ -14,7 +14,7 @@
docbook-xml,
docbook-xsl,
gettext,
-   jq,
+   jq ,
libargon2-dev,
libblkid-dev,
libdevmapper-dev,
@@ -26,10 +26,10 @@
libtool,
pkg-config,
po-debconf,
-   procps,
+   procps ,
uuid-dev,
xsltproc,
-   xxd
+   xxd ,
 Standards-Version: 4.5.0
 Homepage: https://gitlab.com/cryptsetup/cryptsetup
 Vcs-Browser: https://salsa.debian.org/cryptsetup-team/cryptsetup

Bug#963560: main.pdf: openBinaryFile: does not exist

[Georges Khaznadar]

Dear Dirk,

promoting packages from Recommended to straigt dependencies deserves
always some discussion.

I have been prompted more than once by people who wanted to build the
smallest possible machine or container, for a particular feature; they
raised bugreports to ask for a downgrade from Depends to Recommends. As a
matter of fact, one can wish to build a web service to print parts of
wikipedia, so it is sensible to minimize the footprint of mediawiki2latex
(m2l).

If generating EPUB files is not demanded by many m2l users, just let the
package Calibre remain as a recommendation, because it has a heavy
footprint, by the means of his own dependencies.

Ordinary users do not want to tune their Debian system, so they let APT
settings as they come by default, and the default is currently to
download recommended additional packages.

The discussion about missing calibre could arise with ael, because he is
a power user, who did not keep the default settings for APT.

An alternative to promoting calibre from recommended to a dependency is
to check whether mediawiki2latex' manpage (and other documents about it)
have a section about features, and packages necessary to provide those
features. I had a look at the file mediawiki2latex.1.in

I suppose that the excerpt:

.BR -b ", " --epub
Output epub file.

Can be enhanced by mentioning calibre, for instance:

.BR -b ", " --epub
Output epub file. This feature relies on the recommended package calibre.

Also, when options -b or --epub are triggered, and calibre is not found,
mediawiki2latex might issue some warning, or some "rtfm" stance.

Best regards,   Georges.

Dirk Hünniger a écrit :
> Hi,
> 
> in deed calibre is requierd to generate epub files. As is libreoffice for
> odt files.
> 
> latex2rtf or something like that was needed to make raster image form latex
> formulas, although I am currently unsure about the exact detail.
> 
> Georges: Could you please make a new package replacing all rec dependencies
> with dep dependencies.
> 
> Yours Dirk
> 
> On 01.07.20 14:59, ael wrote:
> > On Wed, Jul 01, 2020 at 09:03:33AM +0200, Dirk Hünniger wrote:
> > > oh and you you check if calibre is installed?
> > No, it wasn't. I see that it is a "Recommends". I now wonder whether I
> > might also need latex2rtf, although that isn't so obvious.
> > 
> > ael
> > 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#964091: psi-plus-plugins: Can't receive omemo messages from profanity users

[Matthias Heinz]

Package: psi-plus-plugins
Version: 1.4.1451-1
Severity: normal

Hi,

since profanity updated their omemo implementation to use an IV of 12 byte I'm
unable to receive messages from profanity users.

Since sending omemo messages from profanity to other xmpp clients works this
seems to be a bug in the omemo plugin for psi-plus.

I've tried this with 1.4.554-4 from unstable, 1.4.1231-1 from experimental and
even built myself 1.4.1451 to see if it's fixed.


Best regards
Matthias



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

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

Versions of packages psi-plus-plugins depends on:
ii  libc6  2.30-8
ii  libgcc-s1  10.1.0-4
ii  libgcrypt201.8.5-5
ii  libotr54.1.1-3+b1
ii  libqt5core5a   5.14.2+dfsg-4
ii  libqt5dbus55.14.2+dfsg-4
ii  libqt5gui5 5.14.2+dfsg-4
ii  libqt5network5 5.14.2+dfsg-4
ii  libqt5printsupport55.14.2+dfsg-4
ii  libqt5sql5 5.14.2+dfsg-4
ii  libqt5widgets5 5.14.2+dfsg-4
ii  libqt5x11extras5   5.14.2-2
ii  libqt5xml5 5.14.2+dfsg-4
ii  libsignal-protocol-c2.3.2  2.3.3-1
ii  libssl1.1  1.1.1g-1
ii  libstdc++6 10.1.0-4
ii  libtidy5deb1   2:5.6.0-11
ii  libx11-6   2:1.6.9-2+b1
ii  libxcb11.14-2
ii  psi-plus   1.4.1451-1
ii  psi-plus-webkit1.4.1451-1

psi-plus-plugins recommends no packages.

psi-plus-plugins suggests no packages.

-- no debconf information

Bug#964090: Error when converting from "jpg" to "pdf" since security upgrade "8:6.9.10.23+dfsg-2.1+deb10u1"

[Alex ARNAUD]

Package: imagemagick
Version: 8:6.9.10.23+dfsg-2.1+deb10u1
Severity: important
Tags: ||buster||

Hello,

Since the upgrade from imagemagick from "8:6.9.10.23+dfsg-2.1" to 
"8:6.9.10.23+dfsg-2.1+deb10u1" I obtain an error when converting an 
image from jpg to pdf.


I execute the following command-line:

convert /tmp/37fkw0k6.jpg -density 300 /tmp/37fkw0k6.pdf


And I obtain the following error:
convert-im6.q16: attempt to perform an operation not allowed by the 
security policy `PDF' @ error/constitute.c/IsCoderAuthorized/408.


It makes the program I use to read my mail through OCR (I'm 
visual-impaired) failed at the mentioned command. I was forced to 
downgrade to make it working again.


Best regards,
Alex.

Bug#964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup

[Helmut Grohne]

Hi Luca,

On Wed, Jul 01, 2020 at 04:16:22PM +0100, Luca Boccassi wrote:
> Forgive the naive question, but aren't build profiles and stages
> supposed to be used in these cases, to help with bootstrapping? Eg: do
> a stage1 build with reduced features/dependencies, then rebuild
> everything again. Is my understanding wrong?

Yes, that's the idea. However profiles are not a silver bullet and they
don't magically solve all of your problems. A stage1 build of util-linux
still produces a libmount-dev that Depends on libcryptsetup-dev. How do
you envision to solve this?

Helmut

Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup

[Luca Boccassi]

On Tue, 30 Jun 2020 12:12:34 +0200 Chris Hofstaedtler 
wrote:
> * Simon McVittie  [200630 11:23]:
> > On Tue, 30 Jun 2020 at 10:51:39 +0200, Chris Hofstaedtler wrote:
> > > I'm not sure it was a good idea before. Is static linking something
> > > you actively want to support for glib?
> > 
> > It has worked in the past, Policy says the static library "is usually
> > provided", and we occasionally get bug reports from people who want to
> > link random libraries statically, so I didn't feel comfortable with
> > unilaterally disabling it for no particular reason. The autopkgtest
> > is there partly because things we don't test usually don't work, and
> > partly because static linking to libmount regressed during GLib's move
> > from Autotools to Meson (the pkg-config metadata in GLib was wrong);
> > I added it to confirm that the regression fix had been effective.
> > 
> > If I'm disabling the static library because dependencies no longer
> > support it, then I can redirect bug reporters to the dependency and
> > let them argue their case there if they want to (as with libdbus, which
> > can't be linked statically any more due to libsystemd).
> 
> Understood.
> 
> Feel free to point people at libmount/src:util-linux.
> 
> I'll see about removing libmount's static library in the -dev
> package.
> 
> > People occasionally try to change Policy to say that static equivalents
> > of shared libraries are definitely optional, or even that they are
> > discouraged, but this never reaches consensus, because someone always
> > appears and says "well actually, I rely on Debian shipping shared libfoo
> > and libbar for armhf so that I can statically link them into a binary
> > for my embedded frobnicator device, which
> > (has glibc from 2005|doesn't have glibc|doesn't have space for glibc|...)".
> > The obvious counterpoint that solving this is not really Debian's job
> > is rarely effective.
> > 
> > It is technically possible to link just the top of a dependency stack
> > statically (for example a GLib program with static GLib and libmount,
> > but dynamic libcryptsetup and glibc), but pkg-config doesn't make this
> > straightforward and in practice it requires hard-coding paths to static
> > libraries, so the autopkgtest in GLib doesn't attempt to exercise this.
> 
> Thanks for the explanation!
> 
> Best,
> Chris

Hi,

Note that with this change: 
https://github.com/karelzak/util-linux/pull/1084
we'll be able to use dlopen instead of linking, so the current problem
will go away. The broader issue of availability of static libraries
down the stack is a different matter of course - if it doesn't happen
for this, it will happen for something else and so on.

-- 
Kind regards,
Luca Boccassi


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

Bug#964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup

[Luca Boccassi]

On Wed, 1 Jul 2020 17:02:24 +0200 Helmut Grohne  wrote:
> Source: util-linux
> Version: 2.35.2-6
> Severity: important
> User: helm...@debian.org

> Usertags: rebootstrap
> 
> Until recently, util-linux wasn't involved with cryptsetup and we could
> build it quite early. Now libmount-dev Depends on libcryptsetup-dev.
> That means src:cryptsetup must be built before src:util-linux. However
> libcryptsetup Build-Depends on uuid-dev, which is built from
> src:util-linux. This doesn't work as is and needs more work.
> 
> Therefore, I ask you to revert the dependency on cryptsetup right now. I
> acknowledge that doing so reopens #951048, but trading a wishlist bug
> for an important regression seems reasonable to me. I'm not trying to
> block that feature permanently, but merely gaining some time to figure
> it out properly. It is important to solve this quickly as this
> regression makes other problems elsewhere in essential invisible. In
> doing so, they become harder to track down. Just waiting causes damage.
> 
> One thing that bothers me is that src:util-linux Build-Depends on
> libcryptsetup-dev with a  while libmount-dev unconditionally
> Depends on libcryptsetup-dev.
> 
> If you don't need libcryptsetup-dev for building libmount-dev, then the
> dependency should be unnecessary. However, as #963704 turned up. We do
> need that dependency. Simply marking it with  is not a good
> idea. Then you have two different packages both called "libmount-dev"
> with differing contents. There is no sane way to depend on libmount-dev
> with dm-verity support or libmount-dev without dm-verity support. So
> that's not an option.
> 
> Essentially, this means that the  profile needs to be dropped
> from the libcryptsetup-dev build dependency. That in turn causes a
> direct dependency cycle with src:cryptsetup. We don't want that either.
> 
> So this doesn't work either. It's not that easy. Can you maybe shed some
> light on how libmount-dev integrates with cryptsetup?
> 
> Given that util-linux has a history of being maintained with NMUs, I
> intend to continue that trend barring a timely response. I'm positive
> that we'll find a permanent solution in time for bullseye.
> 
> Right now, I'm going to look into cryptsetup and will try reducing its
> Build-Depends to make it easier to include in architecture bootstrap.
> 
> Helmut

Hello Helmut,

Forgive the naive question, but aren't build profiles and stages
supposed to be used in these cases, to help with bootstrapping? Eg: do
a stage1 build with reduced features/dependencies, then rebuild
everything again. Is my understanding wrong?

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#849012: /usr/bin/spectacle: kde-spectacle: no longer works under VNC (ksnapshot did)

[Pino Toscano]

In data mercoledì 1 luglio 2020 16:23:49 CEST, Thorsten Glaser ha scritto:
> >Anyhow: please report this at https://bugs.kde.org, "spectacle" product,
> >so it can be properly tracker and acted upon by spectacle developers.
> 
> Could you please just forward it, as DevRef says… I don’t think
> users are happy about having to create accounts on hundreds of
> upstream bugtrackers.

Considering that:
- this is definitely not your first bug related to KDE software
- you are a technical person
I'm pretty sure you can be helpful and report this bug yourself to
upstream, so to ease a bit the work of an already well overloaded
packaging team. Right?

-- 
Pino Toscano

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

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

[Felix Lechner]

[This is the policy bug.]

Hi,

On Mon, Jun 15, 2020 at 5:18 PM Sean Whitton  wrote:
>
> the relevant sentence of Policy ...  was intended to be
> informative, not normative.

Just a brief post scriptum: I had to disable a test in Lintian due to
new restrictions on version strings in Dpkg. The commit message has
more documentation:


https://salsa.debian.org/lintian/lintian/-/commit/5f0333ebc6e3ba144717eca1ef0bddfd39413df0

Kind regards
Felix Lechner

Bug#959075: Still not working on Debian testing

[Di Domizio Daniele]

Hello,
bonding still not going up on the latest ifenslave 2.10+nmu2.

My problem seems to be the IFUPDOWN_$IFACE variable on line 84, which is not 
null and makes the script skip the interface enslaving.

I changed line 84 to

if ifquery --state $slave 2>/dev/null; then

and now the bond comes up correctly.

Daniele

Bug#964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup

[Helmut Grohne]

Source: util-linux
Version: 2.35.2-6
Severity: important
User: helm...@debian.org
Usertags: rebootstrap

Until recently, util-linux wasn't involved with cryptsetup and we could
build it quite early. Now libmount-dev Depends on libcryptsetup-dev.
That means src:cryptsetup must be built before src:util-linux. However
libcryptsetup Build-Depends on uuid-dev, which is built from
src:util-linux. This doesn't work as is and needs more work.

Therefore, I ask you to revert the dependency on cryptsetup right now. I
acknowledge that doing so reopens #951048, but trading a wishlist bug
for an important regression seems reasonable to me. I'm not trying to
block that feature permanently, but merely gaining some time to figure
it out properly. It is important to solve this quickly as this
regression makes other problems elsewhere in essential invisible. In
doing so, they become harder to track down. Just waiting causes damage.

One thing that bothers me is that src:util-linux Build-Depends on
libcryptsetup-dev with a  while libmount-dev unconditionally
Depends on libcryptsetup-dev.

If you don't need libcryptsetup-dev for building libmount-dev, then the
dependency should be unnecessary. However, as #963704 turned up. We do
need that dependency. Simply marking it with  is not a good
idea. Then you have two different packages both called "libmount-dev"
with differing contents. There is no sane way to depend on libmount-dev
with dm-verity support or libmount-dev without dm-verity support. So
that's not an option.

Essentially, this means that the  profile needs to be dropped
from the libcryptsetup-dev build dependency. That in turn causes a
direct dependency cycle with src:cryptsetup. We don't want that either.

So this doesn't work either. It's not that easy. Can you maybe shed some
light on how libmount-dev integrates with cryptsetup?

Given that util-linux has a history of being maintained with NMUs, I
intend to continue that trend barring a timely response. I'm positive
that we'll find a permanent solution in time for bullseye.

Right now, I'm going to look into cryptsetup and will try reducing its
Build-Depends to make it easier to include in architecture bootstrap.

Helmut

Bug#908814: origtargz: handle .asc upstream signatures

[Mattia Rizzolo]

On Wed, Jul 01, 2020 at 04:34:32PM +0200, Xavier wrote:
> --- a/scripts/origtargz.pl
> +++ b/scripts/origtargz.pl
> @@ -343,6 +343,7 @@ sub unpack_tarball (@) {
> 
>  for my $origtar (@origtar) {
>  my $tmpdir = File::Temp->newdir(DIR => ".", CLEANUP => 1);
> +next if $origtar =~ /\.(?:asc|sig)$/;
>  print "Unpacking $origtar\n";
>  my $cmp = ($origtar =~ /orig(?:-([\w\-]+))?\.tar/)[0] || '';
>  if ($cmp) {


Mh, but I doubt it does what this bug is about: it should *extract* the
.asc files from pristine-tar if they matches the version.  I suppose it
needs to somehow check whether the .asc is present and if it pass it via
the -s option of `pristine-tar checkout` (at line 255).

Perhaps indeed we also need this bit you proposed, though I admit I
never used --unpack :D
-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

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

[Felix Lechner]

Hi,

On Mon, Jun 15, 2020 at 5:18 PM Sean Whitton  wrote:
>
> the relevant sentence of Policy ...  was intended to be
> informative, not normative.

Just a brief post scriptum: I had to disable a test in Lintian due to
new restrictions on version strings in Dpkg. The commit message has
more documentation:


https://salsa.debian.org/lintian/lintian/-/commit/5f0333ebc6e3ba144717eca1ef0bddfd39413df0

Kind regards

Felix Lechner

Bug#908814: origtargz: handle .asc upstream signatures

[Xavier]

Hi,

this seems enough to fix the bug:

--- a/scripts/origtargz.pl
+++ b/scripts/origtargz.pl
@@ -343,6 +343,7 @@ sub unpack_tarball (@) {

 for my $origtar (@origtar) {
 my $tmpdir = File::Temp->newdir(DIR => ".", CLEANUP => 1);
+next if $origtar =~ /\.(?:asc|sig)$/;
 print "Unpacking $origtar\n";
 my $cmp = ($origtar =~ /orig(?:-([\w\-]+))?\.tar/)[0] || '';
 if ($cmp) {

Bug#963560: main.pdf: openBinaryFile: does not exist

[ael]

On Wed, Jul 01, 2020 at 08:52:51AM +0200, Dirk Hünniger wrote:
> Hi,
> 
> thats strange. I got an epub with
> 
> mediawiki2latex -u https://en.wikibooks.org/wiki/Haskell/Type_basics -o
> Haskell.epub -b
> 
> what command line did you use.

I tried again with -i and this time the error was

Error downloading the lemma "zh:Haskell" form the url "Just (URL {url_type = 
Absolute (Host {protocol = HTTP True, host = "en.wikibooks.org", port = 
Nothing}), url_path = "wiki/Haskell", url_params = []},[URL {url_type = 
Absolute (Host {protocol = HTTP True, host = "en.wikibooks.org", port = 
Nothing}), url_path = "wiki", url_params = []},URL {url_type = Absolute (Host 
{protocol = HTTP True, host = "en.wikibooks.org", port = Nothing}), url_path = 
"", url_params = []},URL {url_type = Absolute (Host {protocol = HTTP True, host 
= "commons.wikimedia.org", port = Nothing}), url_path = "wiki", url_params = 
[]}])"

But it ran for a substantial time before hitting that error.

So that was with a command line of:
  mediawiki2latex -u https://en.wikibooks.org/wiki/Haskell -o /tmp/Haskell.epub 
-b -k -i

ael