Bug#951722: autopkgtest suite flaky on arm64

[Noah Meyerhans]

On Sun, May 10, 2020 at 11:06:26PM +0200, Michael Biebl wrote:
> > +echo "Waiting for the service to be available"
> > +c=0
> > +while ! nc -z -U /var/run/dovecot/auth-userdb; do
> > +   c=$(($c+1))
> > +   sleep 2
> > +   if [ $c -gt 30 ]; then
> > +   echo "Timed out waiting for the service to be available" >&2
> > +   exit 1
> > +   fi
> > +done
> 
> Looping until the service is ready appears to be a workaround/hack at
> best imho.

I agree, however...

> The dovecot service should only signal its readiness when the
> communication sockets are ready yet to accept connections. I.e. this
> autopkgtest appears to point at a real issue that should be fixed properly.

I do not believe that this is an RC issue.  In order to address the
stale upstream version and pending security updates in sid, and allow
the package to again enter bullseye, I propose the following:

I will upload a new upstream version to sid containing the workaround
for the test failures.  I will leave this bug open, but will reduce the
severity to 'normal'.  In a subsequent upload, I will apply a patch to
implement sd_notify and will resolve the bug.  Please feel free to send
a patch if you don't want to wait however long it'll take for me to get
around to putting one together.

Dovecot has been essentially unmaintained in Debian since August 2019,
and there's quite a backlog of work to do.  I'm going to work on getting
it back into shape, but it will be a little while before it's where it
should be.  It won't happen all at once.

noah

Bug#961253: libmecab-perl: Can't load Perl module

[OHURA Makoto]

Package: libmecab-perl
Version: 0.996-12
Severity: grave

Dear Maintainer,

I can't load and use mecab perl module.

I use the simlest perl script.

% cat /tmp/mecab.pl
#!/usr/bin/perl -w

use MeCab;

But, I fail to run this script.

% /tmp/mecab.pl
Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/MeCab/MeCab.so' for 
module MeCab: /usr/lib/x86_64-linux-gnu/perl5/5.30/auto/MeCab/MeCab.so: 
undefined symbol: _ZN5MeCab6Tagger6createEiPPc at 
/usr/lib/x86_64-linux-gnu/perl/5.30/DynaLoader.pm line 193.
 at /usr/lib/x86_64-linux-gnu/perl5/5.30/MeCab.pm line 11.
Compilation failed in require at /tmp/mecab.pl line 3.
BEGIN failed--compilation aborted at /tmp/mecab.pl line 3.

After downgrading libmecab-perl to 0.99.6-2+b4 (got from snapshot.debian.org), 
it's working fine.

  Thanks.

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

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

Versions of packages libmecab-perl depends on:
ii  libc6   2.30-8
ii  libgcc-s1 [libgcc1] 10.1.0-1
ii  libgcc1 1:10.1.0-1
ii  libmecab2   0.996-12
ii  libstdc++6  10.1.0-1
ii  perl5.30.2-1
ii  perl-base [perlapi-5.30.0]  5.30.2-1

libmecab-perl recommends no packages.

libmecab-perl suggests no packages.

-- no debconf information


  OHURA Makoto: oh...@debian.org(Debian Project)
oh...@netfort.gr.jp(LILO/Netfort)


pgpmzWBH_g5XU.pgp
Description: OpenPGP Digital Signature

Bug#961252: udisks2: incorrect exfat mount parameters

[Norbert Preining]

Package: udisks2
Version: 2.8.4-2
Severity: important

Hi all,

in
src/udiskslinuxfilesystem.c
there is
static const gchar *exfat_defaults[] = { "uid=", "gid=", 
"iocharset=utf8", "namecase=0", "errors=remount-ro", NULL };
which is unfortunately incorrect when using the kernel builtin exfat
driver, which does not support namecase. Thus mounting using udisks is
broken and the kernel log gives
[  699.400479] exfat: Unknown parameter 'namecase'

udisks next version will fix that with a rework of the mount options
handling. Unfortunately, that doesn't help those now.
https://github.com/storaged-project/udisks/issues/764

Best

Norbert


-- 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.7.0-rc6+ (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages udisks2 depends on:
ii  dbus   1.12.16-2
ii  libacl12.2.53-8
ii  libatasmart4   0.19-5
ii  libblockdev-fs22.23-2
ii  libblockdev-loop2  2.23-2
ii  libblockdev-part2  2.23-2
ii  libblockdev-swap2  2.23-2
ii  libblockdev-utils2 2.23-2
ii  libblockdev2   2.23-2
ii  libc6  2.30-8
ii  libglib2.0-0   2.64.2-1
ii  libgudev-1.0-0 233-1
ii  libmount1  2.35.2-1
ii  libpam-systemd 245.5-3
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libsystemd0245.5-3
ii  libudisks2-0   2.8.4-2
ii  parted 3.3-4
ii  udev   245.5-3

Versions of packages udisks2 recommends:
ii  dosfstools   4.1-2
ii  e2fsprogs1.45.6-1
ii  eject2.35.2-1
ii  exfat-utils  1.3.0-1
ii  libblockdev-crypto2  2.23-2
ii  ntfs-3g  1:2017.3.23AR.3-3
ii  policykit-1  0.105-26

Versions of packages udisks2 suggests:
ii  btrfs-progs  5.6-1
ii  f2fs-tools   1.11.0-1.1
ii  libblockdev-mdraid2  2.23-2
ii  mdadm4.1-5
ii  nilfs-tools  2.2.8-1
pn  reiserfsprogs
ii  udftools 2.2-1
pn  udisks2-bcache   
pn  udisks2-btrfs
pn  udisks2-lvm2 
pn  udisks2-vdo  
pn  udisks2-zram 
ii  xfsprogs 5.6.0-1+b1

-- no debconf information

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Michael Biebl]

Control: tags -1 + unreproducible

Am 22.05.20 um 01:44 schrieb Vincent Lefevre:
> On 2020-05-21 21:02:20 +0200, Michael Biebl wrote:

> To reproduce the issue (I've done the test after stopping the
> display manager in order to make sure that it does not interfere):
> 
> 1. Switch to VT 1 and log in.
> 
> 2. Start a systemd-inhibit lock.
> 
> 3. Close the lid.
> 
> 4. Log out (from VT 1).
> 
> 5. Wait a bit. Nothing happens.
> 
> 6. Switch to VT 2.
> 
> After 6, the system is suspended (with my last test, immediately,
> but with a similar test yesterday, this was after a few seconds).
> 

I can't reproduce the issue with those instructions.
Must be something specific to your hardware / software configuration.

To further debug this yourself, you might try running logind manually.
Stop the running instance, then run
SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-logind

Maybe you find any clues what's going on your system.




signature.asc
Description: OpenPGP digital signature

Bug#896978: ITP: node-http-proxy -- High performance event emitter for Node.js

[merkys]

Hi Harley,

On 2020-05-22 01:21, fancycade wrote:
> I plan to maintain this as part of the js-team, and am in need of a
> sponsor. This is blocked by node-eventemitter3, which is in the
> process of being packaged.

Am I right to assume you are now working on packaging this?

Best,
Andrius

Bug#961053: transition: mumps petsc slepc

[Drew Parsons]

On 2020-05-21 23:42, Sebastian Ramacher wrote:


Did you test if the reverse dependencies build with the new mumps, 
petsc

and slepc stack?



I've tested most of them,
coinor-ipopt  getfem++  rheolef  sdpa  dolfin  getdp  sundials.  Also 
freefem++.

All build fine.

I didn't test trilinos and deal.ii because of the long build time (3-10 
hours).


siconos has other problems, it's already not building.

Drew

Bug#367891: Utilisateur de courriel en ligne de Zimbra / Avis final !!

[Bureau d'aide]

Cher utilisateur, nous mettons à jour notre structure de stockage de base de 
données vers un nouveau et meilleur serveur, d'où la raison de la demande et de 
la notification. Une mise à jour automatique a été effectuée sur le système du 
serveur de sécurité en raison d'activités inhabituelles qui violent les 
dispositions de notre service. Tout utilisateur de messagerie qui ne met pas à 
jour son compte dans un certain délai après avoir reçu cette notification sera 
suspendu pour empêcher la suspension de son compte. [ 
http://ciamarketing.net/zimbrav.html |  ] 
Nous nous excusons pour la gêne occasionnée à nos utilisateurs de messagerie 
respectés. 

Copyright © Webmail 2020, Inc. Tous droits réservés. 
Services d'assistance Webmail. 

Bug#766441: RFA: scala-mode-el -- Emacs major mode for editing scala source code

[Nicholas D Steeves]

Hi,

Sławomir Wójcik  writes:

> Thanks for the quick reply,
>

You're welcome :-)  I'm happy I was able to--sometimes it may take a
while to reply.

> On 21.05.2020 01:30, Nicholas D Steeves wrote:
>> Sławomir Wójcik  writes:
[snip]
>> The issue isn't the "repo" so much as continuity with the existing
>> source package.  Two people's occasional contributions over three years
>> are valuable, and erasing them from Debian history would be unjust.
> I have imported from dsc by gbp-import-dsc in a new fresh repo, so I 
> should be able to merge my changes(basically replacing all debian/* files)

More or less, but it's a bit more involved than this, because a large
part of the work of maintaining a package is documenting that work.  At
a minimum, this means one must document changes from the previous
version in debian/changelog.  If you're maintaining the package in git
(highly recommended, and also generally expected for team packages),
then "good git hygiene" means each step is contained within a single
commit.

For example, updating a new upstream version should be one commit.
Adopting the package, or adopting it into the team, should be another.
Adding yourself to Uploaders should be another, etc.  As an example of
when it's ok to combine micro operations, I think it's ok to
combine changing debhelper to debhelper-compat and deleting
debian/compat in a "Switch to debhelper-compat $version" step.

Each of these actions must be documented in debian/changelog.

Your changelog entry (everything from the "package-name
(version-debian_revision)…" line at the top, to the " -- Your Name
 `date -R`" line should be appended to the top of the existing
changelog.  Generally I will use 'dch -v$upstream_version-1' for this.

" * Adopt package. (Closes: #ITA-bug-number)" should be the first line
of the entry.  Then "New upstream version." or "New upstream release.",
as you prefer, and additionally closing a bug if there's a bug
requesting a new version.  Then other items.

Finally, you're welcome to update the changelog all at once at the end,
as a separate commit.  Some people prefer to stage individual changelog
lines with the commit associated with the work.  You don't have to
follow that practise if you don't want to, but if you do then "magit"
can be used to do all your work at once, then stage and commit changes
into discrete commits.

All of this information should already be documented at:

  https://www.debian.org/doc/manuals/maint-guide
  https://www.debian.org/doc/manuals/debmake-doc

Please study those guides.  It's also recommended to look at other
packages from our team for hints, and to get a sense of what the
existing conventions are.  Fair warning: I was taught that " * Bump foo"
was an unacceptable practise.

If someone has a link in-hand to one of the conversations about
" * Bump foo" please share it!

>>> -if we want to adhere to EmacsenTeam Addons packaging policy
>>> (https://wiki.debian.org/EmacsenTeam) and I think we should for better
>>> collaboration and consistency then the package name should be changed to
>>> elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el
>>> should be marked as transitional dummy package installing new one, right?
>>>
>> The binary package name should be elpa-scala-mode, but the source
>> package should remain scala-mode-el.
> Actually upstream project name is 
> emacs-scala-mode(https://github.com/hvesalai/emacs-scala-mode 
> ) rather than 
> scala-mode-el, but I guess binary package name is more important for 
> debian users and if source package name will stay the same it won't be 
> such a big deal, right?

Exactly :-)  When I was a new member I also felt a strong inclination to
rename source packages to sate my desire for correctness, but after a
while I came to agree with more experienced developers; they expressed
to me the perspective that it was a waste of time, and after seeing my
packages wait for months in the "Debian NEW queue", waiting for an
ftpmaster to review the package, I came to understand that source
package renames burden the overworked/understaffed ftpmaster team with
extra work, for little gain.

For more info about why the binary package name is important, read the
dh-elpa and dh-make-elpa documentation, and feel free to ask for
clarification if anything there seems unclear.

>>> -upstream version in existing package and most of debian files are very old
>>> or outdated
>>>
>> Yup, that's part of the work of adopting a package that needs work ;-)
>>
>>> Please, let me know what should be done. As I pointed out here:
>>> https://lists.debian.org/debian-emacsen/2020/05/msg00039.html
>>> it would be the best if someone from Debian Emacsen Packaging Team will work
>>> with me on this and other packages but maybe someone else will be
>>> interested to
>>> give his/her opinion.
>>>
>> If you proceed with this ITP I'd like to work with you and/or comaintain
>> it, because it's a 

Bug#961251: golang-github-hanwen-go-fuse: Please package a new version

[Felix Lechner]

Package: golang-github-hanwen-go-fuse-dev
Severity: wishlist

Hi,

I would like to package a new version of gocryptfs, but it depends on
a newer version of your package. Will you please package it?

To make it easy for you, please find a Salsa MR for version 2.0.3 here:


https://salsa.debian.org/go-team/packages/golang-github-hanwen-go-fuse/-/merge_requests/9

Please have a look at the additional information there, too.

Kind regards
Felix Lechner

Bug#896978: ITP: node-http-proxy -- High performance event emitter for Node.js

[fancycade]

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

* Package name: node-http-proxy
  Version : 1.18.1
  Upstream Author : Charlie Robbins 
* URL : https://github.com/http-party/node-http-proxy#readme
* License : Expat
  Programming Lang: JavaScript
  Description : FIX_ME write the Debian package description

It is suitable for implementing components suhc as reverse proxies and load
balancers.
A new proxy is created by calling createProxyServer and passing an options
object as argument.
var httpProxy = require('http-proxy');
var proxy = httpProxy.createProxyServer(options);
.
This package is useful for Node.js web applications
that want to support websockets.

I plan to maintain this as part of the js-team, and am in need of a sponsor. 
This is blocked by node-eventemitter3, which is in the process of being 
packaged.

Work on the package can be found here:
https://salsa.debian.org/js-team/node-http-proxy

Bug#960963: status?

[Noah Meyerhans]

On Wed, May 20, 2020 at 12:55:08PM +0200, Tomas Pospisek wrote:
> What's the status of this problem? Is anybody working on dovecot to have
> this fixed in Debian stable?

It was fixed with DSA 4690: https://www.debian.org/security/2020/dsa-4690

Bug#961250: [Python-modules-team] Bug#961250: anorack: incorrect suggestion: a src package -> an src package

[Emmanuel Arias]

Hi,

I open the issue on upstream [0]

[0] https://github.com/jwilk/anorack/issues/5

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El jue., 21 de may. de 2020 a la(s) 22:21, Paul Wise (p...@debian.org) escribió:
>
> Package: anorack
> Version: 0.2.4-1
> Severity: normal
>
> The suggestion "an src" is incorrect since most people will be
> internally translating "src" to "source" and pronouncing that rather
> than pronouncing each individual character as in "an s.r.c.".
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
> LANGUAGE=en_AU:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages anorack depends on:
> ii  espeak-ng  1.50+dfsg-6
> ii  python33.8.2-3
>
> anorack recommends no packages.
>
> anorack suggests no packages.
>
> -- no debconf information
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#766441: RFA: scala-mode-el -- Emacs major mode for editing scala source code

[Sławomir Wójcik]

Thanks for the quick reply,

On 21.05.2020 01:30, Nicholas D Steeves wrote:

Hi Sławomir,

Thank you for your interest and initiative!

Sławomir Wójcik  writes:

[snip]

One issue is that I've created the repo from scratch because git repo is not
reachable, existing package have quite ancient upstream version and it's
debian
files(especially rules is obviously not using dh-elpa) are mostly outdated.

I can try to use gbp-import-dsc and recreate a new repo if it's really
necessary
or required but I don't see much value in it because:


The issue isn't the "repo" so much as continuity with the existing
source package.  Two people's occasional contributions over three years
are valuable, and erasing them from Debian history would be unjust.
I have imported from dsc by gbp-import-dsc in a new fresh repo, so I 
should be able to merge my changes(basically replacing all debian/* files)

-if we want to adhere to EmacsenTeam Addons packaging policy
(https://wiki.debian.org/EmacsenTeam) and I think we should for better
collaboration and consistency then the package name should be changed to
elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el
should be marked as transitional dummy package installing new one, right?


The binary package name should be elpa-scala-mode, but the source
package should remain scala-mode-el.
Actually upstream project name is 
emacs-scala-mode(https://github.com/hvesalai/emacs-scala-mode 
) rather than 
scala-mode-el, but I guess binary package name is more important for 
debian users and if source package name will stay the same it won't be 
such a big deal, right?

-upstream version in existing package and most of debian files are very old
or outdated


Yup, that's part of the work of adopting a package that needs work ;-)


Please, let me know what should be done. As I pointed out here:
https://lists.debian.org/debian-emacsen/2020/05/msg00039.html
it would be the best if someone from Debian Emacsen Packaging Team will work
with me on this and other packages but maybe someone else will be
interested to
give his/her opinion.


If you proceed with this ITP I'd like to work with you and/or comaintain
it, because it's a blocker for my smartparens ITP.

That would be great.


Best,
Nicholas

On 21.05.2020 01:49, Nicholas D Steeves wrote:

P.S.  Are you using the following as the new upstream source?:

   https://github.com/hvesalai/emacs-scala-mode

I've received confirmation this is the one smartparens requires.


Yes

Bug#942249: FWD: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

Hello TeX maintainers,

I'm forwarding my RFS advertisement for this package, which may be
of interest to some of you.

Thank you for your consideration,
Antonio



Dear mentors,

I am looking for a sponsor for my package "inkscape-textext"

 * Package name: inkscape-textext
   Version : 1.0.1-1
   Upstream Author : Jan Winkler 
 * URL : https://textext.github.io/textext
 * License : AGPL
 * Vcs : https://github.com/textext/textext
   Section : graphics
   Description : Re-editable LaTeX graphics for Inkscape

TexText is a Python plugin for the vector graphics editor Inkscape
providing the possibility to add and re-edit LaTeX generated SVG
elements to your drawing.

 Key features
 . Windows/Linux/MacOS support
 . LaTeX generated SVG elements can be re-edited later
 . Multi-line editor with syntax highlighting
 . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex
 . Interoperable scaling in TexText and Inkscape
 . Font size match with Inkscape text
 . Customizable TeX preamble (additional packages, parskip, parindent, etc.)
 . Colorization via TeX commands/Inkscape is kept after re-editing
 . Alignment anchor of the produced output
 . Preview images

Since my last upload, upstream has released 1.0 (and 1.0.1).  Now that
there is an upstream release, the package is suitable for unstable, rather
than experimental.  I've renamed the package to inkscape-textext, aligning
with the naming of other inkscape extensions I have found.

The package is lintian clean, with the exception of the warning about
upstream tarball signing (and tests) [1].  I'm currently interacting with
upstream to get signed releases [2].

The packaging is maintained in Debian salsa [3], and builds in pbuilder.

Best,
Antonio Russo

[1] https://mentors.debian.net/package/inkscape-textext
[2] https://github.com/textext/textext/issues/231
[3] https://salsa.debian.org/aerusso-guest/textext

Bug#961243: ITP: node-eventemitter3 -- High Performance Event Emitter For Node.js

[fancycade]

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

* Package name: node-eventemitter3
  Version : 4.0.4
  Upstream Author : Arnout Kazemier
* URL : https://github.com/primus/eventemitter3#readme
* License : Expat
  Programming Lang: JavaScript
  Description : FIX_ME write the Debian package description

Description: A high performance eventemitter for Node.js
It has been micro-optimized for various code paths making this, one of,
if not the fastest EventEmitter available for Node.js and browsers. The module
is API compatible with the EventEmitter that ships by default with Node.js but
there are some slight differences.
.
It's a drop in replacement for existing EventEmitters, but just faster.
Free performance, who wouldn't want that> The EventEmitter is written
in EcmaScript 3 so it will work in the oldest browsers and node versions that
you need to support.
.

I have most of the work done for the package, the only issue I've run into is 
with the tests. There is a dependency on assume, which has not been packaged 
yet.

Bug#961250: anorack: incorrect suggestion: a src package -> an src package

[Paul Wise]

Package: anorack
Version: 0.2.4-1
Severity: normal

The suggestion "an src" is incorrect since most people will be
internally translating "src" to "source" and pronouncing that rather
than pronouncing each individual character as in "an s.r.c.".

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages anorack depends on:
ii  espeak-ng  1.50+dfsg-6
ii  python33.8.2-3

anorack recommends no packages.

anorack suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#944965: debsums: Script accesses internal dpkg database

[Axel Beckert]

Control: tag -1 - moreinfo + confirmed

Hi Guillem,

Guillem Jover wrote:
> > Guillem Jover wrote:
> > > This package contains the «debsums» program, which directly accesses
> > > the dpkg internal database, instead of using one of the public
> > > interfaces provided by dpkg.
> > 
> > JFTR: This is not true. I didn't find a single place in the debsums
> > script where $admindir is accessed directly. Instead it is always
> > passed to a dpkg, dpkg-query or dpkg-divert call as you asked for.
> 
> Well I see in debsums the md5sums_path() function which does access
> it.

Granted. I just looked for $admindir, but not $DPKG. My fault. Thanks
for pointing out this detail.

> Ideally debsums would only pass the admindir if it has been specified.
> And then it would also only use --root on dpkg commands if that's what
> has been passed to it, which would imply no need for a hard-coded
> dpkg database pathname.

Being able to only use --root would be very preferable indeed.

> Of course one problem is that dpkg-query does not have a --root
> option! But I think I have a branch somewhere implementing that, so
> I'll add this to 1.20.1. :)

Much appreciated!

I though see one problem with this: IIRC, the piuparts guys sometimes
use debsums as backport on stable.

Cc'ing them if this is still the case and if they see any issues if a
debsums upload in the not-so-far future would depend on a very recent
dpkg version. (IIRC last time they needed a debsums backport, this was
because we fixed bugs they wanted to be fixed in their setups as soon
as they were found and fixed.)

> > Leaves the build-time configuration of the admindir: How can I query
> > dpkg for the build-time location of its admindir?
> > 
> > And how can I determine the admindir of a chroot with a call to an
> > external dpkg binary outside the chroot, which, as I understand you,
> > can have a different admindir.
> 
> So with the above, the idea would be that you do not need to.

Yep. --root for the win! :-D

That's definitely the way to go.

> > I just tried "dpkg-query --control-show sendfile md5sums" in a minimal
> > pbuilder chroot where I just installed sendfile to see how that error
> > looks like.
> > 
> > To my surprise, despite sendfile_2.1b.20080616-6_amd64.deb does not
> > contain a files with md5sums, "dpkg-query --control-show sendfile
> > md5sums" works and /var/lib/dpkg/info/sendfile.md5sums exists.
> > 
> > So it seems as if dpkg now automatically generates md5sums files if
> > not present. Just checked dpkg's changelog and this feature seems to
> > exist since 2012.
> > 
> > Which means that debsums_init is actually obsolete since 2012.
> > 
> > So I will happily remove debsums_init with the next upload.:-)
> 
> Yes, thanks. :)
> 
> > > If the file is missing an error will be returned.
> > 
> > So how can this file be missing if dpkg generates them?
> 
> That would be the case if a package had been installed with an ancient
> dpkg version and then never upgraded.

sendfile actually was a good candidate (the last maintainer upload
before 2020 was in 2011), but it got adopted recently and also had
some NMUs between 2012 and 2014. Of course this wouldn't have made a
difference in a just unpacked pbuilder chroot. :-)

> But as mentioned above «dpkg -C» will complain, so I'd leave it to
> the user to handle TBH. Also because generating the md5sums from the
> installed files is a bit misleading as if they have changed then
> they will be "bogus", I mean I guess this is better than nothing,
> but not ideal.

Full ack. debsums_init did the very same for the very same reason,
just about 5 years before dpkg did. (According to the changelog it got
introduced in 2007.) This also explains very nicely why the according
lintian warning is still important.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#960892: another fix

[Axel Beckert]

Hi Martin.

Martin Quinson wrote:
> I gave another try to this fix, and the current git version of po4a
> manages to build aptitude even with the recent patch removed. 
> 
> Could you please give it a try, just to ensure that I didn't mess up
> my verification?

Can confirm. Thanks for caring!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#961216: inkscape: symbol resolution problem

[Peter Eckersley]

However this somehow fixed the problem?

$ sudo apt-get build-dep inkscape
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  gir1.2-gdl-3 gir1.2-gtkspell3-3.0 googletest libaspell-dev
libatkmm-1.6-dev libcairomm-1.0-dev libcdr-dev libdbus-glib-1-dev
libdbus-glib-1-dev-bin
  libdjvulibre-dev libdouble-conversion-dev libenchant-2-dev libgc-dev
libgdl-3-dev libglibmm-2.4-dev libgmock-dev libgsl-dev libgtest-dev
libgtkmm-3.0-dev
  libgtkspell3-3-dev libjemalloc-dev libjemalloc2 liblcms2-dev
liblqr-1-0-dev libmagick++-6-headers libmagick++-6.q16-dev
libmagick++-dev
  libmagickcore-6-arch-config libmagickcore-6-headers
libmagickcore-6.q16-dev libmagickwand-6-headers
libmagickwand-6.q16-dev libopenjp2-7-dev
  libpangomm-1.4-dev libpoppler-private-dev libpotrace-dev
librevenge-dev librsvg2-dev libsigc++-2.0-dev libvisio-dev libwmf-dev
libwpd-dev libwpg-dev
  libxslt1-dev
The following packages will be upgraded:
  debhelper dh-python gir1.2-rsvg-2.0 libatkmm-1.6-1v5
libcairomm-1.0-1v5 libcdr-0.1-1 libdbus-glib-1-2 libdebhelper-perl
libdouble-conversion3
  libenchant-2-2 libglibmm-2.4-1v5 libgtkspell3-3-0 liblcms2-2
liblqr-1-0 libmagick++-6.q16-8 libmagickcore-6.q16-6
libmagickcore-6.q16-6-extra
  libmagickwand-6.q16-6 libpangomm-1.4-1v5 libpotrace0
librevenge-0.0-0 libsigc++-2.0-0v5 libvisio-0.1-1 libwmf0.2-7
libwpd-0.10-10 libwpg-0.3-3 libxslt1.1
27 upgraded, 44 newly installed, 0 to remove and 2032 not upgraded.
Need to get 29.5 MB of archives.
After this operation, 83.3 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.au.debian.org/debian sid/main amd64
libmagickcore-6-headers all 8:6.9.10.23+dfsg-2.1 [49.2 kB]
Get:2 http://ftp.au.debian.org/debian sid/main amd64
libmagickwand-6-headers all 8:6.9.10.23+dfsg-2.1 [10.5 kB]
Get:3 http://ftp.au.debian.org/debian sid/main amd64
libmagick++-6-headers all 8:6.9.10.23+dfsg-2.1 [47.5 kB]
Get:4 http://ftp.au.debian.org/debian sid/main amd64 liblcms2-2 amd64
2.9-4+b1 [146 kB]
Get:5 http://ftp.au.debian.org/debian sid/main amd64 liblqr-1-0 amd64
0.4.2-2.1 [29.1 kB]
Get:6 http://ftp.au.debian.org/debian sid/main amd64
libmagickcore-6.q16-6 amd64 8:6.9.10.23+dfsg-2.1+b2 [1,787 kB]
Get:7 http://ftp.au.debian.org/debian sid/main amd64
libmagickwand-6.q16-6 amd64 8:6.9.10.23+dfsg-2.1+b2 [446 kB]
Get:8 http://ftp.au.debian.org/debian sid/main amd64
libmagick++-6.q16-8 amd64 8:6.9.10.23+dfsg-2.1+b2 [278 kB]
Get:9 http://ftp.au.debian.org/debian sid/main amd64
libmagickcore-6-arch-config amd64 8:6.9.10.23+dfsg-2.1+b2 [164 kB]
Get:10 http://ftp.au.debian.org/debian sid/main amd64 libwmf0.2-7
amd64 0.2.8.4-17 [165 kB]
Get:11 http://ftp.au.debian.org/debian sid/main amd64
libmagickcore-6.q16-6-extra amd64 8:6.9.10.23+dfsg-2.1+b2 [206 kB]
Get:12 http://ftp.au.debian.org/debian sid/main amd64 libdjvulibre-dev
amd64 3.5.27.1-14 [2,398 kB]
Get:13 http://ftp.au.debian.org/debian sid/main amd64 libopenjp2-7-dev
amd64 2.3.1-1 [46.7 kB]
Get:14 http://ftp.au.debian.org/debian sid/main amd64 liblcms2-dev
amd64 2.9-4+b1 [9,103 kB]
Get:15 http://ftp.au.debian.org/debian sid/main amd64 liblqr-1-0-dev
amd64 0.4.2-2.1 [72.2 kB]
Get:16 http://ftp.au.debian.org/debian sid/main amd64 gir1.2-rsvg-2.0
amd64 2.48.4+dfsg-1 [23.9 kB]
Get:17 http://ftp.au.debian.org/debian sid/main amd64 librsvg2-dev
amd64 2.48.4+dfsg-1 [50.1 kB]
Get:18 http://ftp.au.debian.org/debian sid/main amd64 libwmf-dev amd64
0.2.8.4-17 [190 kB]
Get:19 http://ftp.au.debian.org/debian sid/main amd64
libmagickcore-6.q16-dev amd64 8:6.9.10.23+dfsg-2.1+b2 [1,116 kB]
Get:20 http://ftp.au.debian.org/debian sid/main amd64
libmagickwand-6.q16-dev amd64 8:6.9.10.23+dfsg-2.1+b2 [446 kB]
Get:21 http://ftp.au.debian.org/debian sid/main amd64
libmagick++-6.q16-dev amd64 8:6.9.10.23+dfsg-2.1+b2 [268 kB]
Get:22 http://ftp.au.debian.org/debian sid/main amd64 libmagick++-dev
all 8:6.9.10.23+dfsg-2.1 [1,360 B]
Get:23 http://ftp.au.debian.org/debian sid/main amd64 debhelper all
13.1 [1,012 kB]
Get:24 http://ftp.au.debian.org/debian sid/main amd64
libdebhelper-perl all 13.1 [187 kB]
Get:25 http://ftp.au.debian.org/debian sid/main amd64 dh-python all
4.20200315 [91.6 kB]
Get:26 http://ftp.au.debian.org/debian sid/main amd64 gir1.2-gdl-3
amd64 3.34.0-1 [32.3 kB]
Get:27 http://ftp.au.debian.org/debian sid/main amd64 libenchant-2-2
amd64 2.2.8-1 [50.4 kB]
Get:28 http://ftp.au.debian.org/debian sid/main amd64 libgtkspell3-3-0
amd64 3.0.10-1 [35.0 kB]
Get:29 http://ftp.au.debian.org/debian sid/main amd64
gir1.2-gtkspell3-3.0 amd64 3.0.10-1 [9,964 B]
Get:30 http://ftp.au.debian.org/debian sid/main amd64 googletest all
1.10.0-3 [626 kB]
Get:31 http://ftp.au.debian.org/debian sid/main amd64 libaspell-dev
amd64 0.60.8-1 [34.4 kB]
Get:32 http://ftp.au.debian.org/debian sid/main amd64
libsigc++-2.0-0v5 amd64 2.10.2-1 [64.0 kB]
Get:33 http://ftp.au.debian.org/debian sid/main amd64
libglibmm-2.4-1v5 amd64 

Bug#961216: inkscape: symbol resolution problem

[Peter Eckersley]

pde@graphene:~$ ls -l /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
lrwxrwxrwx 1 root root 22 Apr 16 07:01
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 -> libgio-2.0.so.0.6400.2
pde@graphene:~$ ls -l /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.2
-rw-r--r-- 1 root root 1920176 Apr 16 07:01
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.2
pde@graphene:~$ nm /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.2
nm: /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.2: no symbols
pde@graphene:~$ file /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.2
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.2: ELF 64-bit LSB
shared object, x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=1d09cb1069dbdc80bf696754b6fe9d67041c10d4, stripped
pde@graphene:~$ sudo apt-get reinstall libglib2.0-0
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and  not upgraded.
Need to get 0 B/2,757 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
(Reading database ... 444913 files and directories currently installed.)
Preparing to unpack .../libglib2.0-0_2.64.2-1_amd64.deb ...
Unpacking libglib2.0-0:amd64 (2.64.2-1) over (2.64.2-1) ...
Preparing to unpack .../libglib2.0-0_2.64.2-1_i386.deb ...
Unpacking libglib2.0-0:i386 (2.64.2-1) over (2.64.2-1) ...
Setting up libglib2.0-0:amd64 (2.64.2-1) ...
Setting up libglib2.0-0:i386 (2.64.2-1) ...
Processing triggers for libc-bin (2.30-4) ...
pde@graphene:~$ sha256sum /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.2
ffb67ca65a4c049bc8019a642727b31c064d715f6667cb41f889d75413103b9c
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.2
pde@graphene:~$ strings
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6400.2 | grep
set_option_context
g_application_set_option_context_parameter_string
g_application_set_option_context_summary
g_application_set_option_context_description
g_application_set_option_context_description
g_application_set_option_context_summary
g_application_set_option_context_parameter_string
pde@graphene:~$ inkscape
inkscape: symbol lookup error:
/usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so:
undefined symbol:
_ZN3Gio11Application35set_option_context_parameter_stringERKN4Glib7ustringE

On Fri, 22 May 2020 at 04:37, Mattia Rizzolo  wrote:
>
> Control: tag -1 moreinfo unreproducible
>
> On Thu, May 21, 2020 at 11:34:49PM +1000, Peter Eckersley wrote:
> > Package: inkscape
> > Version: 1.0-1
> > Severity: grave
> > Justification: renders package unusable
> >
> > $ inkscape
> > inkscape: symbol lookup error:
> > /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so:
> > undefined symbol:
> > _ZN3Gio11Application35set_option_context_parameter_stringERKN4Glib7ustringE
>
> I can't reproduce this.
>
> That symbol is
> Gio::Application::set_option_context_parameter_string(Glib::ustring 
> const&)
> which obviously comes from this library you are also listing:
>
> > libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
> > (0x7f7eda043000)
>
> Which seems to be installed:
>
> > ii  libglib2.0-0   2.64.2-1
>
>
> Regardless it's odd, obviously it works for me and many other people,
> such bug would have drawn many others to complain.
> Please double check your Glib installation…
>
> --
> 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  `-



-- 
Peter

Bug#944965: debsums: Script accesses internal dpkg database

[Guillem Jover]

Hi!

On Fri, 2020-05-22 at 01:06:51 +0200, Axel Beckert wrote:
> Control: tag -1 moreinfo

> Guillem Jover wrote:
> > This package contains the «debsums» program, which directly accesses
> > the dpkg internal database, instead of using one of the public
> > interfaces provided by dpkg.
> 
> JFTR: This is not true. I didn't find a single place in the debsums
> script where $admindir is accessed directly. Instead it is always
> passed to a dpkg, dpkg-query or dpkg-divert call as you asked for.

Well I see in debsums the md5sums_path() function which does access
it. And the debsums_init program does too indeed. :)

> The only script which accesses *.md5sums files and only to see if they
> exist, is debsums_init which is meant to be removed anyway, once
> https://lintian.debian.org/tags/no-md5sums-control-file.html is down
> to zero as it actually generates that file. But since there are
> currently over 60 packages on that list, this won't be anytime soon.

As you have noticed (down below), dpkg has been generating missing
md5sum on installation for some time, so this functionality does not
seem necessary anymore. Also «dpkg -C» will warn about packages that
are still missing such files so that they can be reinstalled.

> > The admindir can also be configured differently at dpkg build or
> > run-time.
> 
> Well, that's exactly what we do: We configure dpkg's admindir at
> run-time!

> W only use $admindir and provide it to dpkg as parameter because
> debsums supports to also check chroots. And since chroots might be of
> a different architecture (or for forensic purposes), we don't want to
> use the dpkg binary inside the chroot, i.e. we need to provide at
> least the location to dpkg. And for that, we need to know it.

My point is that if dpkg has been built with a different admindir
default (not the case in Debian, but perhaps a derivative system)
then debsums passing that pathname will make dpkg operate on an
invalid database (and with newer versions it will simply consider
that a bootstrapping installation and proceed as if it had 0 packages
installed).

Ideally debsums would only pass the admindir if it has been specified.
And then it would also only use --root on dpkg commands if that's what
has been passed to it, which would imply no need for a hard-coded
dpkg database pathname.

Of course one problem is that dpkg-query does not have a --root
option! But I think I have a branch somewhere implementing that, so
I'll add this to 1.20.1. :)

> Leaves the build-time configuration of the admindir: How can I query
> dpkg for the build-time location of its admindir?
> 
> And how can I determine the admindir of a chroot with a call to an
> external dpkg binary outside the chroot, which, as I understand you,
> can have a different admindir.

So with the above, the idea would be that you do not need to.

> > The debsums program should be switched to use something like:
> > 
> >   «dpkg-query --control-show $pkg md5sums»
> >
> > to get the md5sums file contents. If the file is missing an error
> > will be returned.
> 
> I just tried "dpkg-query --control-show sendfile md5sums" in a minimal
> pbuilder chroot where I just installed sendfile to see how that error
> looks like.
> 
> To my surprise, despite sendfile_2.1b.20080616-6_amd64.deb does not
> contain a files with md5sums, "dpkg-query --control-show sendfile
> md5sums" works and /var/lib/dpkg/info/sendfile.md5sums exists.
> 
> So it seems as if dpkg now automatically generates md5sums files if
> not present. Just checked dpkg's changelog and this feature seems to
> exist since 2012.
> 
> Which means that debsums_init is actually obsolete since 2012.
> 
> So I will happily remove debsums_init with the next upload.:-)

Yes, thanks. :)

> > If the file is missing an error will be returned.
> 
> So how can this file be missing if dpkg generates them?

That would be the case if a package had been installed with an ancient
dpkg version and then never upgraded. But as mentioned above «dpkg -C»
will complain, so I'd leave it to the user to handle TBH. Also because
generating the md5sums from the installed files is a bit misleading as
if they have changed then they will be "bogus", I mean I guess this is
better than nothing, but not ideal.

Thanks,
Guillem

Bug#960892: another fix

[Axel Beckert]

Hi Martin,

Martin Quinson wrote:
> I gave another try to this fix, and the current git version of po4a
> manages to build aptitude even with the recent patch removed.

Thanks, much appreciated!

> Could you please give it a try, just to ensure that I didn't mess up
> my verification?

Will do.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#961248: lsof: man lsof tries to find non-existent version file

[Craig Small]

Package: lsof
Version: 4.93.2+dfsg-1
Severity: normal

Hi,
  When you try to read the lsof manual, it gives an error.

$ man lsof
man: can't open /usr/share/man/./version: No such file or directory
No manual entry for lsof

This is because the first line has this:
.so ./version

Upstream has this as well, but the version file is there.

My guess is you'll need to programatically inject the version
file at the top of the lsof manual page. Actually that's probably
what upstream should do too.

 - Craig


-- 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.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
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)
LSM: AppArmor: enabled

Versions of packages lsof depends on:
ii  libc62.30-2
ii  libselinux1  3.0-1+b1

lsof recommends no packages.

Versions of packages lsof suggests:
ii  perl  5.30.0-9

-- no debconf information

Bug#960892: another fix

[Martin Quinson]

Hello,

I gave another try to this fix, and the current git version of po4a
manages to build aptitude even with the recent patch removed. 

Could you please give it a try, just to ensure that I didn't mess up
my verification?

Thanks in advance,
Mt.

-- 
Reject: The reference on the SimGrid toolkit is outdated.  
   -- Bastard Reviewer From Hell


signature.asc
Description: PGP signature

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

On 2020-05-21 21:02:20 +0200, Michael Biebl wrote:
> My point is: Only if I stop systemd-inhibit, the system will suspend on
> lid-close. As long as it is running, it does not.
 ^
This is not what I observe (see below).

> But it might very well be, that I misunderstand what you are trying to
> say. Please try to explain it better then, in more detail.

To reproduce the issue (I've done the test after stopping the
display manager in order to make sure that it does not interfere):

1. Switch to VT 1 and log in.

2. Start a systemd-inhibit lock.

3. Close the lid.

4. Log out (from VT 1).

5. Wait a bit. Nothing happens.

6. Switch to VT 2.

After 6, the system is suspended (with my last test, immediately,
but with a similar test yesterday, this was after a few seconds).

It should not, because the systemd-inhibit lock is still running
(and this can be checked after waking up the system).

I think that the issue occurs when the VT that currently corresponds
to the display is not the one from which the systemd-inhibit lock
has been started. I think that all suspend issues I've seen until
now are in this case (I'm not 100% sure because I initially did not
think that the closed lid was the issue as it does not appear in the
journalctl logs, so that I did not pay attention to the status of
the lid; but that could be the most plausible explanation).

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

Bug#961247: mutt -s'a b c' x < somefile sends post also to "b" and "c"

[Bjarni Ingi Gislason]

Package: mutt
Version: 1.14.0-1+b1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

mutt -s'Test the mailer' bg <  

  Answer from mailer-daemon:

...

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  the@localhost
Unrouteable address
  mailer@localhost
Unrouteable address

...


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

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

Versions of packages mutt depends on:
ii  libc6 2.30-8
ii  libgnutls30   3.6.13-2
ii  libgpg-error0 1.37-1
ii  libgpgme111.13.1-6
ii  libgssapi-krb5-2  1.17-7
ii  libidn11  1.33-2.2
ii  libncursesw6  6.2-1
ii  libsasl2-22.1.27+dfsg-2
ii  libtinfo6 6.2-1
ii  libtokyocabinet9  1.4.48-13
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages mutt recommends:
ii  libsasl2-modules  2.1.27+dfsg-2
ii  locales   2.30-8
ii  mime-support  3.64
ii  sensible-utils0.0.12+nmu1

Versions of packages mutt suggests:
ii  aspell 0.60.8-1
ii  ca-certificates20190110
ii  exim4-daemon-light [mail-transport-agent]  4.93-16
ii  gnupg  2.2.20-1
ii  ispell 3.4.00-8
pn  mixmaster  
ii  openssl1.1.1g-1
pn  urlview

Versions of packages mutt is related to:
ii  mutt  1.14.0-1+b1

-- no debconf information

-- 
Bjarni I. Gislason

Bug#944965: debsums: Script accesses internal dpkg database

[Axel Beckert]

Control: tag -1 moreinfo

Dear Guillem,

Guillem Jover wrote:
> This package contains the «debsums» program, which directly accesses
> the dpkg internal database, instead of using one of the public
> interfaces provided by dpkg.

JFTR: This is not true. I didn't find a single place in the debsums
script where $admindir is accessed directly. Instead it is always
passed to a dpkg, dpkg-query or dpkg-divert call as you asked for.

The only script which accesses *.md5sums files and only to see if they
exist, is debsums_init which is meant to be removed anyway, once
https://lintian.debian.org/tags/no-md5sums-control-file.html is down
to zero as it actually generates that file. But since there are
currently over 60 packages on that list, this won't be anytime soon.

> The admindir can also be configured differently at dpkg build or
> run-time.

Well, that's exactly what we do: We configure dpkg's admindir at
run-time!

W only use $admindir and provide it to dpkg as parameter because
debsums supports to also check chroots. And since chroots might be of
a different architecture (or for forensic purposes), we don't want to
use the dpkg binary inside the chroot, i.e. we need to provide at
least the location to dpkg. And for that, we need to know it.

Leaves the build-time configuration of the admindir: How can I query
dpkg for the build-time location of its admindir?

And how can I determine the admindir of a chroot with a call to an
external dpkg binary outside the chroot, which, as I understand you,
can have a different admindir.

> The debsums program should be switched to use something like:
> 
>   «dpkg-query --control-show $pkg md5sums»
>
> to get the md5sums file contents. If the file is missing an error
> will be returned.

I just tried "dpkg-query --control-show sendfile md5sums" in a minimal
pbuilder chroot where I just installed sendfile to see how that error
looks like.

To my surprise, despite sendfile_2.1b.20080616-6_amd64.deb does not
contain a files with md5sums, "dpkg-query --control-show sendfile
md5sums" works and /var/lib/dpkg/info/sendfile.md5sums exists.

So it seems as if dpkg now automatically generates md5sums files if
not present. Just checked dpkg's changelog and this feature seems to
exist since 2012.

Which means that debsums_init is actually obsolete since 2012.

So I will happily remove debsums_init with the next upload.:-)

> If the file is missing an error will be returned.

So how can this file be missing if dpkg generates them?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#961029: #961029 Request for new mailing list: debian-mlhwaccl

[Chris Lamb]

Hi all,

> Name: debian-mlhwaccl

Just to add a bit of personal experience, I very much regret that the
Lintian list was called "debian-lint-maint", a name that renders the
most simple search for the string "lintian" to return zero results.

As a result of this, I was not even aware of the list's existence
until many years after I was a regular contributor. The "boot" mailing
list — which is mostly concerned with the development of the Debian
Installer — is similarly affected by discoverability-related UX
issues.

Your "mhlhwaccl" suggested name unfortunately suffers from this
precise problem, and arguably more so. It risks excluding potential
contributors either by them not being able to locate the list in the
first place, or by them being deterred by an obscure acronym.

I do not have any concrete alternatives (and I would very much prefer
not to engage in an "okay, is X better?"-style exchange) but I would
humbly suggest you brainstorm an alternative name. However, I will add
that a suffix that does not attempt both to reference both "machine
learning" and "hardware acceleration" may actually be preferable in a
net sense, even at the expense of the term that you leave out.

(Needless to say, renaming the list later will come with numerous
cognitive and technical overheads.)


Regards,

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

Bug#958963: playonlinux's desktop file is missing the additional category 'Emulator'

[Joerg Schiermeier]

On Thursday, May 21, 2020 at 14:39:08
Bertrand Marc wrote:

> Hi Joerg,

> Thank you for submitting this bug. If I am not mistaken, the
> category Emulator is already there. Could you please check again and reopen 
> the bug if necessary?

> Best,
> Bertrand

I'm sorry Bertrand!

This was my fault. I mixed some package names by accident...
m(

-- 

Kind regards
Joerg Schiermeier
Bielefeld/Germany

Bug#961246: RFS: swapspace/1.17-1 -- dynamic swap space manager

[Jacob Adams]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: swapspace
   Version : 1.17-1
   Upstream Author : Jacob Adams 
 * URL : https://github.com/Tookmund/Swapspace
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/tookmund/swapspace-deb
   Section : admin

It builds those binary packages:

  swapspace - dynamic swap space manager

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/swapspace/swapspace_1.17-1.dsc

Changes since the last upload:

   * New upstream version
   * Bumped debhelper compat to 13
   * Move VCS to standard salsa namespace, instead of -guest

Regards,
Jacob



signature.asc
Description: OpenPGP digital signature

Bug#961245: mercurial-common: trying to overwrite '/usr/lib/python2.7/dist-packages/hgext/git/__init__.py', which is also in package mercurial-git 0.8.12-1.2

[Axel Beckert]

Package: mercurial-common
Version: 5.4-1
Severity: serious

Hi,

upgrading mercurial-common fails due to a file conflict with
mercurial-git as follows:

Preparing to unpack .../mercurial-common_5.4-1_all.deb ...
Unpacking mercurial-common (5.4-1) over (5.3.2-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/mercurial-common_5.4-1_all.deb (--unpack):
 trying to overwrite '/usr/lib/python2.7/dist-packages/hgext/git/__init__.py', 
which is also in package mercurial-git 0.8.12-1.2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/mercurial-common_5.4-1_all.deb

It seems as if the source package mercurial is overtaking the git
backend from the mercurial-git package (currently uninstallable due to
the removal of the python-dulwich package) of the hg-git source package.

So I'm only filing this against mercurial-common as Replaces and Breaks
headers seem missing. Another solution (which needs to come anyway
sometime soon) might be to switch this to Python 3.

In case hg-git is not about to being removed from unstable anyway and
this is a conflict which needs to be resolved on both sides, feel free
to reassign this bug against both packages until the conflict is
resolved.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: i386

Bug#961021: ITP: python-easysnmp -- A blazingly fast and Pythonic SNMP library based on the official Net-SNMP bindings

[Craig Small]

Hi Bernhard,
  I'm the net-snmp Debian package maintainer.

On Tue, 19 May 2020 at 22:36, Bernhard Schmidt  wrote:
> The old python-netsnmp bindings from src:net-snmp were Python2-only
> and are now dropped from Bullseye/Sid.
You could have also said the net-snmp python bindings were terrible
and deserved to be deleted, but that's a kinder way of putting it.
Really they suffered from bit-rot and had a lot of important features
missing, python 3 being the most obvious one.

> python3-pysnmp4 is a pure-python
> implementation that is said to be very slow and even the high-level API
> is not easy to use (see the examples at
I actually liked the API he used, but nothing is simple about SNMP.

> Note that the upstream project is looking for a new maintainer and
> appears to be quite dormant. There are issues with Python 3.7+, but a pull
> request is available and has been verified to work. I don't intend to
> upload to Debian until these issues have been resolved.
SNMP projects seem to be hard to maintain. It's a fiddly protocol for sure.

Anyway, if you need any help with the net-snmp library or just someone
to bounce ideas off, I'm here. I don't want to maintain easysnmp but
willing to help when it's needed.

Hopefully, the upstream issues get sorted! Until we have more snmp
libraries than IRC clients I say more the merrier!

 - Craig

Bug#667593: exists elsewhere Re: debcheck: check for obsolete transitional packages

[Rebecca N. Palmer]

debcheck processes a single release per run, so in its current form 
can't check this, or anything that requires comparing multiple releases. 
 (The oldlibs check looks for explicit Section: oldlibs labels.)


There is a separate tool on jenkins that does check this:
https://salsa.debian.org/qa/jenkins.debian.net/-/blob/master/bin/find_obsolete_transitional_packages.sh

It doesn't output to DDPO/tracker, but does allow semi-automated bug 
filing, which is being done:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=qa.debian@packages.debian.org;tag=transitional

Hence, I suggest closing this bug.

Bug#934923: clevis: [dracut-initqueue] cryptsetup: command not found

[Christoph Biedl]

Control: tags 934923 unreproducible

Christoph Biedl wrote...

> it's been a while, and I have reason to assume the issue has been fixed
> in upstream version 12. I can however not test on my own, I've already
> spend two days getting *anything* done with dracut and an encrypted
> root.

After finally sorting things out: Unlocking in early userland using
dracut works like a charm here, both with tang and tpm pins.

If you have other observations, let me know.

Christoph


signature.asc
Description: PGP signature

Bug#961244: spamassassin: autopkgtest fails with python3

[Bryce Harrington]

Source: spamassassin
Version: 3.4.4-1
Severity: normal

Dear Maintainer,

I've posted a merge request for a fix to allow autopkgtest to run on
systems with either python2 or python3 as the default python version.

https://salsa.debian.org/debian/spamassassin/-/merge_requests/4

This issue was discovered in Ubuntu during a distro-wide check of
python2 dependence, and the above fix is being carried in Ubuntu's
spamassassin package.  While this does not currently affect Debian's CI,
it may become a problem if/when Debian deprecates python2.

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

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

Bug#961092: reportbug-gtk: Crashes when after package selection when there is no internet connection

[Nis Martensen]

control: reassign 961092 reportbug
control: merge 919102 961092
control: tags 919102 patch

On 19 May 2020 Real Carbonneau wrote:
> reportbug-gtk crashes after package selection when there is no internet
> connection.  It works correctly as soon as an internet connection is present.

Thank you for the report. Merging this with a previous report of the
same issue. There is now a patch for this:
https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/59

Bug#961231: sane: No scanners identified on HP officejet Pro 8610 (all-in-one)

[loris]

Package: sane
Version: 1.0.14-15
Severity: normal

Dear Maintainer,

I have an HP Officejet Pro 8610 (all-in-one); after last upgrading I am not 
able to use my scanner: the printer works perfectly but launching xsane  I get 
an error message: 'no device has been found'.
As my printer is connected to router I try to connect it to my pc with usb 
cable:

With command '~$ sane-find-scanner' I get the the following output:
'found USB scanner (vendor=0x03f0 [HP], product=0x7112 [HP Officejet Pro 8610]) 
at libusb:005:011'

With command '~$ scanimage -L' I get the the following output:
No scanners were identified

Connecting a pen-drive to printer usb port and using the printer touch panel I 
am able to scan a document and save it to pen-drive.

On my old Pentium4 Fujitsu Siemens I am using xfce 4.14 as desktop environment,

dpkg -l cups*

ii  cups  2.3.3-1  i386 
ii  cups-browsed  1.27.4-1+b1  i386
ii  cups-bsd  2.3.3-1  i386
ii  cups-client   2.3.3-1  i386 
ii  cups-common   2.3.3-1  all   
ii  cups-core-drivers 2.3.3-1  i386 
ii  cups-daemon   2.3.3-1  i386   
ii  cups-filters  1.27.4-1+b1  i386  
ii  cups-filters-core-drivers 1.27.4-1+b1  i386 
ii  cups-ipp-utils2.3.3-1  i386   
ii  cups-pk-helper0.2.6-1+b1   i386 
ii  cups-ppdc 2.3.3-1  i386
ii  cups-server-common2.3.3-1  all 


dpkg -l hp*

ii  hplip  3.20.5+dfsg0-2 i386   
ii  hplip-data 3.20.5+dfsg0-2 all  




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

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

Versions of packages sane depends on:
ii  libc6 2.30-8
ii  libgimp2.02.10.18-1
ii  libglib2.0-0  2.64.2-1
ii  libgtk2.0-0   2.24.32-4
ii  libsane   1.0.27-3.2+b1

sane recommends no packages.

Versions of packages sane suggests:
ii  gimp  2.10.18-1

-- no debconf information

Bug#961241: python-django-compressor: Not compatible with Django 3.x

[Chris Lamb]

Source: python-django-compressor
Version: 2.2-5
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x
Control: affects -1 python-django-pyscss

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. For more
information, see:

http://bugs.debian.org/960890

Please use the above bug report for queries or questions regarding
Django 3.x that are not specific to this particular package in order
to reduce duplicated work across all of the bugs.

Whilst python-django-compressor itself builds from source, it causes
other packages (eg. python-django-pyscss) to FTBFS.

Here is the FTBFS from python-django-pyscss:

  […]

  output = self.handle(*args, **options)
File 
"/usr/lib/python3/dist-packages/django/core/management/commands/check.py", line 
59, in handle
  self.check(
File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
392, in check
  all_issues = self._run_checks(
File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
382, in _run_checks
  return checks.run_checks(**kwargs)
File "/usr/lib/python3/dist-packages/django/core/checks/registry.py", line 
72, in run_checks
  new_errors = check(app_configs=app_configs)
File "/usr/lib/python3/dist-packages/django/contrib/admin/checks.py", line 
76, in check_dependencies
  for engine in engines.all():
File "/usr/lib/python3/dist-packages/django/template/utils.py", line 90, in 
all
  return [self[alias] for alias in self]
File "/usr/lib/python3/dist-packages/django/template/utils.py", line 90, in 

  return [self[alias] for alias in self]
File "/usr/lib/python3/dist-packages/django/template/utils.py", line 81, in 
__getitem__
  engine = engine_cls(params)
File "/usr/lib/python3/dist-packages/django/template/backends/django.py", 
line 25, in __init__
  options['libraries'] = self.get_templatetag_libraries(libraries)
File "/usr/lib/python3/dist-packages/django/template/backends/django.py", 
line 43, in get_templatetag_libraries
  libraries = get_installed_libraries()
File "/usr/lib/python3/dist-packages/django/template/backends/django.py", 
line 108, in get_installed_libraries
  for name in get_package_libraries(pkg):
File "/usr/lib/python3/dist-packages/django/template/backends/django.py", 
line 123, in get_package_libraries
  raise InvalidTemplateLibrary(
  django.template.library.InvalidTemplateLibrary: Invalid template library 
specified. ImportError raised when trying to load 
'compressor.templatetags.compress': cannot import name 'six' from 
'django.utils' (/usr/lib/python3/dist-packages/django/utils/__init__.py)
  make[1]: *** [debian/rules:22: override_dh_auto_install] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517003052.wCc4MTmTYz.ags.lamby-debian-experimental.python3-django-pyscss/python-django-pyscss-2.0.2'
  make: *** [debian/rules:7: binary] Error 2
  dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2

  […]

The full build log is attached.


Regards,

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


python-django-pyscss.2.0.2-9.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961242: python-django-crispy-forms: Not compatible with Django 3.x

[Chris Lamb]

Source: python-django-crispy-forms
Version: 1.7.2-2
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x
Control: affects -1 django-filter

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. For more
information, see:

http://bugs.debian.org/960890

Please use the above bug report for queries or questions regarding
Django 3.x that are not specific to this particular package in order
to reduce duplicated work across all of the bugs.

Whilst python-django-crispy-forms itself builds from source, it causes
other packages (eg. django-filter) to FTBFS.

Here is the FTBFS from django-filter:

  […]

  --
  Traceback (most recent call last):
File 
"/home/lamby/temp/cdt.20200517001459.aCZ5FBFbhk.ags.lamby-debian-experimental.python3-django-filters/django-filter-2.1.0/tests/test_views.py",
 line 56, in test_view_with_model_no_filterset
  self.assertContains(response, b)
File "/usr/lib/python3/dist-packages/django/test/testcases.py", line 454, 
in assertContains
  self.assertTrue(real_count != 0, msg_prefix + "Couldn't find %s in 
response" % text_repr)
  AssertionError: False is not true : Couldn't find 'Enders Game' in 
response
  
  ==
  FAIL: test_view (tests.test_views.GenericFunctionalViewTests)
  --
  Traceback (most recent call last):
File 
"/home/lamby/temp/cdt.20200517001459.aCZ5FBFbhk.ags.lamby-debian-experimental.python3-django-filters/django-filter-2.1.0/tests/test_views.py",
 line 146, in test_view
  self.assertContains(response, b)
File "/usr/lib/python3/dist-packages/django/test/testcases.py", line 454, 
in assertContains
  self.assertTrue(real_count != 0, msg_prefix + "Couldn't find %s in 
response" % text_repr)
  AssertionError: False is not true : Couldn't find 'Enders Game' in 
response
  
  --
  Ran 487 tests in 0.688s
  
  FAILED (failures=5, errors=1, skipped=14, expected failures=3)
  Destroying test database for alias 'default'...
  System check identified no issues (0 silenced).
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 ./runtests.py
  dh_auto_test: error: pybuild --test -i python{version} -p 3.8 --system=custom 
"--test-args={interpreter} ./runtests.py" returned exit code 13
  make[1]: *** [debian/rules:21: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517001459.aCZ5FBFbhk.ags.lamby-debian-experimental.python3-django-filters/django-filter-2.1.0'
  make: *** [debian/rules:7: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


django-filter.2.1.0-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961240: python-django-pyscss: Not compatible with Django 3.x

[Chris Lamb]

Source: python-django-pyscss
Version: 2.0.2-9
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x
Control: affects -1 horizon

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. For more
information, see:

http://bugs.debian.org/960890

Please use the above bug report for queries or questions regarding
Django 3.x that are not specific to this particular package in order
to reduce duplicated work across all of the bugs.

Whilst python-django-pyscss itself builds from source, it causes
other packages (eg. horizon) to FTBFS.

Here is the FTBFS from horizon:


  […]

  raise ex[1].with_traceback(ex[2])
File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in 
_multicall
  res = hook_impl.function(*args)
File "/usr/lib/python3/dist-packages/pytest_django/plugin.py", line 335, in 
pytest_load_initial_conftests
  _setup_django()
File "/usr/lib/python3/dist-packages/pytest_django/plugin.py", line 223, in 
_setup_django
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 91, in 
populate
  app_config = AppConfig.create(entry)
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 90, in 
create
  module = import_module(entry)
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/django_pyscss/__init__.py", line 1, in 

  from .compiler import DjangoScssCompiler  # NOQA
File "/usr/lib/python3/dist-packages/django_pyscss/compiler.py", line 6, in 

  from django.utils.six.moves import StringIO
  ModuleNotFoundError: No module named 'django.utils.six'
  make[1]: *** [debian/rules:111: override_dh_auto_test] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517001922.IqiWOueXMa.ags.lamby-debian-experimental.python3-django-horizon/horizon-18.3.2'
  make: *** [debian/rules:6: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


horizon.3:18.3.2-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961239: python-django-registration: Not compatible with Django 3.x

[Chris Lamb]

Source: python-django-registration
Version: 2.2-3
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x
Control: affects -1 mini-buildd

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. For more
information, see:

http://bugs.debian.org/960890

Please use the above bug report for queries or questions regarding
Django 3.x that are not specific to this particular package in order
to reduce duplicated work across all of the bugs.

Whilst python-django-registration itself builds from source, it causes
other packages (eg. mini-buildd) to FTBFS.

Here is the FTBFS from mini-buildd:

  […]

File 
"/home/lamby/temp/cdt.20200517004829.Xc0msV8pPb.ags.lamby-debian-experimental.python3-mini-buildd/mini-buildd-1.1.31/src/mini_buildd/django_settings.py",
 line 168, in pseudo_configure
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in 
populate
  app_config.import_models()
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in 
import_models
  self.models_module = import_module(models_module_name)
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/registration/models.py", line 23, in 

  from django.utils.encoding import python_2_unicode_compatible
  ImportError: cannot import name 'python_2_unicode_compatible' from 
'django.utils.encoding' 
(/usr/lib/python3/dist-packages/django/utils/encoding.py)
  
  make[1]: *** [debian/rules:21: override_dh_auto_build] Error 2
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517004829.Xc0msV8pPb.ags.lamby-debian-experimental.python3-mini-buildd/mini-buildd-1.1.31'
  make: *** [debian/rules:4: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


mini-buildd.1.1.31.experimental.amd64.log.txt.gz
Description: Binary data

Bug#574292: resize2fs still risky

[Wilmer van der Gaast]

Hello Theodore,

Very interesting response, thank you! It all makes sense. And I realise
it's hard to make everyone happy yes.

On 21-05-2020 16:48, Theodore Y. Ts'o wrote:
> 
> In *general* things are mostly safe unless you need to do an
> overlapping move of the inode table, in which case it is very hard to
> make it be 100% safe.
> 
Interesting too. And this may be in line with what I ended up
experimenting with! Indeed I later realised I could just create LVM
snapshots and e2fsck them: Always came out clean, while saying
"filesystem with errors, check required".

Of course I don't know whether data *integrity* was correct, but I
presume that's "easy" to guarantee if everything's sequenced properly.

That testing was all during the pass 2 block relocations. Which I guess
is also the least risky pass then?

> If you would like to help, you could try running resize2fs -p on a
> test file system, and then try to randomly interrupt the resize at
> various points, and then run e2fsck -fy and during which phase of the
> resize you see things getting corrupted.
> 
So I've tried the above 6×, and never managed to get it to report
corruption, which is a great outcome as well!

Pass 3 I didn't spot in time, and these were the only passes actually
reported by the progress indicator.

> It's not a high priority for me, since I have way too many other
> things to worry about, if it is high priority for *you*, some
> contributions to the effort would be much appreciated.  After all,
> Open source means you get to help fix the things you care about.  :-)
> 
Hah, for sure. It's not super important to me either and I think it's
hard to do anything that *will* help some people while not being a
backward incompatible change to others.

Just like I presume telling people that interrupting is "probably" a
safe thing to do during block relocation is risky for the next time
someone does that and things *do* go wrong.

However, with tools like this I always wonder why the progress indicator
isn't on by default, and maybe in resize2fs' case a backward compatible
change, and similar to dd, would be to enable the progress indicator on
SIGUSR1?


Kind regards,

Wilmer v/d Gaast.

Bug#961238: RFP: python3-gi -- python3-gi for GTK+4 in experimental

[Sam Bull]

Package: wnpp
Severity: wishlist

I'd like to see a python3-gi version that supports GTK+4 in experimental.
There is already a gir1.2-gtk-4.0 package, but it errors in Python as the
python3-gi package has not been updated.


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

Bug#708060: debcheck: :$arch and :native always appear broken

[Rebecca N. Palmer]

Control: retitle -1 debcheck: :$arch and :native always appear broken

Since 
https://salsa.debian.org/qa/qa/-/commit/526d2319174cb15111bb2d6c702f8e23ee7bd0d7 
, arch-specific Depends don't crash debcheck, but do search for a 
package named literally $package:$arch not just $package.  As this does 
not exist, they hence always appear broken.  (E.g. 
https://qa.debian.org/debcheck.php?dist=sid=wine wine64-tools.)


:any and :native Build-Depends have the same problem.  (:any Depends are 
treated as plain Depends, by an explicit substitution at line 385.)


A potential fix is to extract the arch qualifier as a separate regex 
group, as is already done for the version.

Bug#961129: xscreensaver should not search for screensaver executables in PATH

[Tormod Volden]

Thanks for the report, this has been discussed in bug #816722 as well.

Tormod

Bug#961192: im-config: Remove imhangul support; packages removed since buster

[Changwoo Ryu]

Control: tags -1 + pending

Thanks for the fix!

Next time please include bug number in resolving commit message. Then
salsa webhook will automatically append "pending" tag.

Bug#960899: paramiko: autopkgtests failures

[Brian Murray]

I'm pretty sure its because the configs folder from usptream isn't
included in the package at all.

https://github.com/paramiko/paramiko/tree/master/tests/configs

--
Brian Murray @ubuntu.com

Bug#961130: ethtool can read DOM values

[Ben Hutchings]

On Thu, 2020-05-21 at 11:22 +0200, Bjørn Mork wrote:
> Ben Hutchings  writes:
> > On Wed, 2020-05-20 at 13:09 +, Yannis Aribaud wrote:
> > > Package: ethtool
> > > Version: 1:4.19-1
> > > Severity: important
> > > The command ethtool -m  is unable to read the transceiver DOM values.
> > 
> > Again, this is a driver or hardware issue, not a bug in ethtool.
> > 
> > [...]
> > > As you can see all mesuring values are zeros.
> > > I am using Debian GNU/Linux 10 (buster), kernel 4.19.0-9-amd64 #1 SMP
> > > Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux and libc6 2.28-10
> > > 
> > > FYI, I get correct values using SystemRescueCD 6 (ethtool 5.0, kernel
> > > 4.19.34-1-lts) on this same hardware, using the same command.
> > 
> > I see no changes to ethtool between 4.19 and 5.0 that would explain
> > that.
> 
> I assume you're aware of this, but there are some interesting changes in
> that driver between v4.19.34 and v4.19.118

I actually hadn't looked yet, so thanks for doing that.

> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=7da11d6a5d85ab3f4d28fa660d8c90566fdaa1e6
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=935f39807a7e95678e5bda50757af326691a211c
> 
> 
> The net effect seems to be that they removed the part that actually made
> DOM reading work.

Yes, these patches don't make sense.  If only the real EEPROM is
readable then the correct fix would be to change both type and size to
the SFF-8079 values.

> Makes me wonder what happens if you revert both those
> patches?  I don't have the hardware, so I can't test..
> 
> This issue might also be fixed in mainline with the more generic high
> page support for QSFP28 and QSFP+?

I don't know, I no longer keep track of networking stuff beyond what I
read in LWN.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.



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

Bug#961237: ITP: drop-seq -- analyzing Drop-seq data

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: drop-seq -- analyzing Drop-seq data 
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: drop-seq
  Version : 2.3.0
  Upstream Author : Broad Institute
* URL : https://github.com/broadinstitute/Drop-seq/
* License : MIT
  Programming Lang: Java
  Description : analyzing Drop-seq data 
 This software provide for core computational analysis of Drop-seq data,
 which shows you how to transform raw sequence data into an expression
 measurement for each gene in each individual cell.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/drop-seq

Bug#961236: re2: FTBFS on 32 bit archs

[stefanor]

Hi Sebastian (2020.05.21_19:53:01_+)
> re2 FTBFS on the 32 bit archs. See
> https://buildd.debian.org/status/fetch.php?pkg=re2=i386=20200501%2Bdfsg-2=1590088309=0
> for example.

Whoops. I guess I didn't check on the experimental builds...

Thanks for that.

SR


-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#959856: [Python-apps-team] Bug#959856: terminator: ships /usr/share/icons/hicolor/icon-theme.cache

[Markus Frosch]

On Mon, 2020-05-18 at 19:05 +0200, Adrian Vondendriesch wrote:
> I wasn't able to find any way to tell pybuild to pass any argument right
> after "python3 setup.py" and the action it should call (for instance
> "install"). Passing --install-args to pybuild doesn't work. Therefor I
> did the same thing as in commit 2271ffc9. Overwrite dh_auto_-install.

Thanks for the patch Adrian, but I think the best way for now is to purge the
file after dh_auto_install.

I want to remove the "feature" in 2.0 anyways:
https://github.com/gnome-terminator/terminator/issues/102

Thanks
Markus
-- 
lazyfro...@debian.org
https://lazyfrosch.de

Bug#952814: I made the sound work with libaudio-dev

[Thierry Vilmart]

You mention libfaudio0 and I mention libfaudio-dev with a missing f. ANd
also for a prebuilt Wine 5 not built from source. Sorry for the spelling
errors and the difference.

But I give the truth about my case because I really did make it work with
libfaudio-dev. But if you only need libaudio0, then you should only build
that one.

IF you use wine prebuilt you need the real package.

if you build from source, you need the -dev package or the wine build
complains that libraries are missing. The working of win5 depends a lot on
how it is built with what packages. It is possible that a backport require
package version that conflict with  versions in how win was built. I am not
sure but maybe.

Note however that libfaudio-dev includes libfaudio0 as a dependency.
https://packages.debian.org/sid/libfaudio-dev




On Thu, May 21, 2020 at 10:02 PM Thierry Vilmart 
wrote:

> I built wine from source and i have the sound. I used a unstable
> libaudio-dev built from source in 64 bit. For 32 one would need a chroot
> with alocal debian to not affect the system.
>
> --> build libfaudio-dev from source
> add unstable reposiry rules the the apt sources.list
> and add this to preferences.d/preferences
> Package: * Pin: release a=unstable Pin-Priority: -10
>
> sudo apt-src source libfaudio-dev
> sudo chown -R USER:USER FOLDER
> sudo apt-get build-dep libfaudio-dev
> sudo apt-get install devscripts
> cd in the subfolder of the subfolder
> debuild -b -uc -us
> one folder up (cd ..)
> sudo dpkg -i libfaudio-dev_19.12-1_amd64.deb libfaudio0_19.12-1_amd64.deb
>
> On Thu, May 21, 2020 at 9:58 PM Thierry Vilmart 
> wrote:
>
>> For your info, unless it is a tricky package liek a kernel, you can build
>> unstable from source and it will be better than a backport. THis is the way
>> t odo it but yo uare not allowed ot install directly unstable on debian.
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952814
>>
>> On Thu, May 21, 2020 at 9:55 PM Thierry Vilmart 
>> wrote:
>>
>>> I built wine from source. I and I have the sound working thanks to
>>> libaudio-dev.
>>>
>>> ANd I built libaudio-dev -t unstable from source. It was very simple,
>>> just build-dep and then the build command from the doc, What I say here is
>>> only valid for 64 bit.
>>>
>>> If one wants to build for 32 bit libaudio-dev, one needs to create a
>>> local debian in a chroot.
>>>
>>> --
>>> Med vänliga hälsingar,
>>> Thierry Vilmart
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Med vänliga hälsingar,
>> Thierry Vilmart
>>
>>
>>
>>
>>
>>
>>
>
> --
> Med vänliga hälsingar,
> Thierry Vilmart
>
>
>
>
>
>
>

-- 
Med vänliga hälsingar,
Thierry Vilmart

Bug#961225: shotwell: No video thumbails

[loris]

Package: shotwell
Version: 0.30.8-1
Severity: normal

Dear Maintainer,

importing video and/or photos, Shotwell shows me only photo thumbnails (video 
thumbnails are not visible).
Inside Shotwell thumbnail directory  '~/.cache/shotwell/thumbs', all jpg video 
thumbnails are generated but with the same identical standard image; it doesn't 
show me the real video content.
I have removed 'thumbs' directory inside  '~/.cache/shotwell/' and I have 
launched Shotwell again: it recreate thumbnails inside thumbs directory but 
with same problem described above.

On my old Pentium4 Fujitsu Siemens I am using xfce 4.14 as desktop environment.


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

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

Versions of packages shotwell depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  dconf-cli 0.36.0-1
ii  libc6 2.30-8
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libexif12 0.6.21-7
ii  libgcr-base-3-1   3.36.0-2
ii  libgcr-ui-3-1 3.36.0-2
ii  libgdata220.17.12-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libgee-0.8-2  0.20.3-1
ii  libgexiv2-2   0.12.0-2
ii  libglib2.0-0  2.64.2-1
ii  libgphoto2-6  2.5.24-1
ii  libgphoto2-port12 2.5.24-1
ii  libgstreamer-plugins-base1.0-01.16.2-4
ii  libgstreamer1.0-0 1.16.2-2
ii  libgtk-3-03.24.20-1
ii  libgudev-1.0-0233-1
ii  libjson-glib-1.0-01.4.4-2
ii  libpango-1.0-01.44.7-4
ii  libpangocairo-1.0-0   1.44.7-4
ii  libraw19  0.19.5-1
ii  librsvg2-common   2.48.4+dfsg-1
ii  libsoup2.4-1  2.70.0-1
ii  libsqlite3-0  3.31.1-5
ii  libwebkit2gtk-4.0-37  2.28.2-2
ii  libxml2   2.9.10+dfsg-5
ii  shotwell-common   0.30.8-1

shotwell recommends no packages.

shotwell suggests no packages.

-- no debconf information

Bug#934923: clevis: [dracut-initqueue] cryptsetup: command not found

[Christoph Biedl]

Control: tags 934923 moreinfo

David Heise wrote...

> During `dracut-initqueue` on boot I get an error in `clevis-luks-askpass`
> saying that
> `cryptsetup` cannot be found on lines 52 and 67. This is despite `cryptsetup`
> clearly
> being placed in `usr/sbin/cryptsetup` during `dracut -f`.
(...)

Hello,

it's been a while, and I have reason to assume the issue has been fixed
in upstream version 12. I can however not test on my own, I've already
spend two days getting *anything* done with dracut and an encrypted
root.

Long story short: Can you re-check with 13-1, currently in unstable?

Christoph


signature.asc
Description: PGP signature

Bug#952814: I made the sound work with libaudio-dev

[Thierry Vilmart]

I built wine from source and i have the sound. I used a unstable
libaudio-dev built from source in 64 bit. For 32 one would need a chroot
with alocal debian to not affect the system.

--> build libfaudio-dev from source
add unstable reposiry rules the the apt sources.list
and add this to preferences.d/preferences
Package: * Pin: release a=unstable Pin-Priority: -10

sudo apt-src source libfaudio-dev
sudo chown -R USER:USER FOLDER
sudo apt-get build-dep libfaudio-dev
sudo apt-get install devscripts
cd in the subfolder of the subfolder
debuild -b -uc -us
one folder up (cd ..)
sudo dpkg -i libfaudio-dev_19.12-1_amd64.deb libfaudio0_19.12-1_amd64.deb

On Thu, May 21, 2020 at 9:58 PM Thierry Vilmart  wrote:

> For your info, unless it is a tricky package liek a kernel, you can build
> unstable from source and it will be better than a backport. THis is the way
> t odo it but yo uare not allowed ot install directly unstable on debian.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952814
>
> On Thu, May 21, 2020 at 9:55 PM Thierry Vilmart 
> wrote:
>
>> I built wine from source. I and I have the sound working thanks to
>> libaudio-dev.
>>
>> ANd I built libaudio-dev -t unstable from source. It was very simple,
>> just build-dep and then the build command from the doc, What I say here is
>> only valid for 64 bit.
>>
>> If one wants to build for 32 bit libaudio-dev, one needs to create a
>> local debian in a chroot.
>>
>> --
>> Med vänliga hälsingar,
>> Thierry Vilmart
>>
>>
>>
>>
>>
>>
>>
>
> --
> Med vänliga hälsingar,
> Thierry Vilmart
>
>
>
>
>
>
>

-- 
Med vänliga hälsingar,
Thierry Vilmart

Bug#844750: fixed? Re: should link to tracker.d.o instead of packages.qa.d.o

[Rebecca N. Palmer]

This appears to be fixed, probably by
https://salsa.debian.org/qa/qa/-/commit/56fbe1b36e3a8ec9064cb9ce6cbcbfd5448feb61

(Fixed on qa.debian.org/dose/debcheck/...; 
qa.debian.org/debcheck.php?... doesn't have a tracker link at all. 
Should it?)

Bug#961236: re2: FTBFS on 32 bit archs

[Sebastian Ramacher]

Source: re2
Version: 20200501+dfsg-2
Severity: serious
Tags: ftbfs upstream fixed-upstream
Justification: fails to build from source (but built successfully in the past)
Control: forwarded -1 https://github.com/google/re2/issues/256

re2 FTBFS on the 32 bit archs. See
https://buildd.debian.org/status/fetch.php?pkg=re2=i386=20200501%2Bdfsg-2=1590088309=0
for example.

Upstream bug report https://github.com/google/re2/issues/256 and fix
https://github.com/google/re2/commit/bde1ea09550a61b4a092cdf0e3ba8dca4200947a

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#952814: I made the sound work with libaudio-dev

[Thierry Vilmart]

I built wine from source. I and I have the sound working thanks to
libaudio-dev.

ANd I built libaudio-dev -t unstable from source. It was very simple, just
build-dep and then the build command from the doc, What I say here is only
valid for 64 bit.

If one wants to build for 32 bit libaudio-dev, one needs to create a local
debian in a chroot.

-- 
Med vänliga hälsingar,
Thierry Vilmart

Bug#960493: linux-image-4.19.0-9-amd64: Audio regression on HP Pavilion laptop

[Salvatore Bonaccorso]

Hi Steven,

On Wed, May 13, 2020 at 10:48:27AM +0100, Steven Price wrote:
> Package: src:linux
> Version: 4.19.118-2
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> After installing linux-image-4.19-0-9-amd64 my desktop environment no longer
> detects the sound card (it reverts to the dummy output) and I get no sound.
> However "aplay -l" still lists it.
> 
> I bisected the kernel and found 44cc74947ce02283e4967aa92988b90ec7c25dee is 
> the
> first broken commit. It appears that 6cacf120de65f336d57bdfd41466b65ed1c569c6
> is a follow up commit fixing the problem and indeed v4.19.121 works fine (the
> regression is fixed).
> 
> Is it possible to update the package to a later stable release?

Yes, we work regularly for the point releases to rebase to latest
stable versions in the series, so I would expect this to see in 10.5
at latest.

Thanks for the bisecting work, I'm taking note to add a closer for
this bug when either picking up the commit or importing 4.19.121.

Regards,
Salvatore

Bug#961235: RFS: austin/1.0.1-1 -- Frame stack sampler for CPython

[Gabriele]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

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

It builds those binary packages:

  austin - Frame stack sampler for CPython

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

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

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

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

Changes since the last upload:

   * Fixed support for Python 3.8

Regards,

--
  Gabriele N. Tornetta

Bug#472477: this bug still exists

[Giacomo Mulas]

Hello.

I was just hit by this bug, when I temporarily added some ssh keys to do
some tests to find that it was impossible to remove them from the agent.
I am running an up to date debian sid system as of May 21, 2020.
And I can confirm that still "ssh-add -D" fails to remove keys from the
agent.

However, I found a way to manually remove/disable individual keys: the agent
writes them in a text file, located $HOME/.gnupg/sshcontrol.  Commenting
and/or deleting keys from that file, they are "forgotten" by the agent.

Of course, this is far from an optimal solution, this bug is still open and
still grave. But at least one can remove keys without neessarily disabling
the gnome keyring daemon ssh-agent component.

Best regards,
Giacomo Mulas

--
_

Giacomo Mulas 
_

INAF - Osservatorio Astronomico di Cagliari
via della scienza 5 - 09047 Selargius (CA)

tel.   +39 070 71180255
mob. : +39 329  6603810
_

"When the storms are raging around you, stay right where you are"
 (Freddy Mercury)
_

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Michael Biebl]

Am 21.05.20 um 20:41 schrieb Vincent Lefevre:
> On 2020-05-21 20:38:16 +0200, Michael Biebl wrote:
>> Am 21.05.20 um 00:26 schrieb Vincent Lefevre:
>>> The suspend also occurs if I switch to a VT.
>>>
>>> So it seems that if a "block" was triggered, it is cancelled once
>>> the login session that started it is no longer associated with the
>>> screen (something like that).
>>
>> fwiw, I can't reproduce this.
>> What I tried:
>> login on tty1, run systemd-inhibit
>> switch to tty2, close the lid -> no suspend
>> switch to tty1, kill systemd-inhibit
>> switch to tty2, close the lid -> suspend
> 
> You did not understand. I do *not* kill systemd-inhibit.
> But the system got suspended.
> 

My point is: Only if I stop systemd-inhibit, the system will suspend on
lid-close. As long as it is running, it does not.

But it might very well be, that I misunderstand what you are trying to
say. Please try to explain it better then, in more detail.



signature.asc
Description: OpenPGP digital signature

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

On 2020-05-21 20:38:16 +0200, Michael Biebl wrote:
> Am 21.05.20 um 00:26 schrieb Vincent Lefevre:
> > The suspend also occurs if I switch to a VT.
> > 
> > So it seems that if a "block" was triggered, it is cancelled once
> > the login session that started it is no longer associated with the
> > screen (something like that).
> 
> fwiw, I can't reproduce this.
> What I tried:
> login on tty1, run systemd-inhibit
> switch to tty2, close the lid -> no suspend
> switch to tty1, kill systemd-inhibit
> switch to tty2, close the lid -> suspend

You did not understand. I do *not* kill systemd-inhibit.
But the system got suspended.

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

Bug#961216: inkscape: symbol resolution problem

[Mattia Rizzolo]

Control: tag -1 moreinfo unreproducible

On Thu, May 21, 2020 at 11:34:49PM +1000, Peter Eckersley wrote:
> Package: inkscape
> Version: 1.0-1
> Severity: grave
> Justification: renders package unusable
> 
> $ inkscape
> inkscape: symbol lookup error:
> /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so:
> undefined symbol:
> _ZN3Gio11Application35set_option_context_parameter_stringERKN4Glib7ustringE

I can't reproduce this.

That symbol is
Gio::Application::set_option_context_parameter_string(Glib::ustring const&)
which obviously comes from this library you are also listing:

> libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
> (0x7f7eda043000)

Which seems to be installed:

> ii  libglib2.0-0   2.64.2-1


Regardless it's odd, obviously it works for me and many other people,
such bug would have drawn many others to complain.
Please double check your Glib installation…

-- 
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#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Michael Biebl]

Am 21.05.20 um 00:26 schrieb Vincent Lefevre:
> The suspend also occurs if I switch to a VT.
> 
> So it seems that if a "block" was triggered, it is cancelled once
> the login session that started it is no longer associated with the
> screen (something like that).

fwiw, I can't reproduce this.
What I tried:
login on tty1, run systemd-inhibit
switch to tty2, close the lid -> no suspend
switch to tty1, kill systemd-inhibit
switch to tty2, close the lid -> suspend





signature.asc
Description: OpenPGP digital signature

Bug#961234: r-cran-treescape: FTBFS on ppc64el:Segmentation fault

[Graham Inggs]

Source: r-cran-treescape
Version: 1.10.18+dfsg-1
Severity: serious
Tags: ftbfs bullseye sid

Hi Maintainer

In the recent rebuild for r-api4.0, r-cran-treescape FTBFS on ppc64el [1].
I've copied what I hope is the relevant part of the log below.

Upstream's homepage has a note:
Package ‘treescape’ was removed from the CRAN repository.
Formerly available versions can be obtained from the archive.
Archived on 2017-05-23 as requested by the maintainer
.
Consider using package ‘treespace’ instead.

Regards
Graham


[1] https://buildd.debian.org/status/logs.php?pkg=r-cran-treescape=ppc64el
[2] https://cran.r-project.org/web/packages/treescape/index.html


make[2]: Entering directory '/<>/src'
g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG
-I'/usr/lib/R/site-library/Rcpp/include'-fPIC  -g -O2
-fdebug-prefix-map=/build/r-base-BUYUMC/r-base-4.0.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -g  -c CPP_update_combinations.cpp -o
CPP_update_combinations.o
g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG
-I'/usr/lib/R/site-library/Rcpp/include'-fPIC  -g -O2
-fdebug-prefix-map=/build/r-base-BUYUMC/r-base-4.0.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -g  -c RcppExports.cpp -o RcppExports.o
g++ -std=gnu++11 -shared -L/usr/lib/R/lib -Wl,-z,relro -o treescape.so
CPP_update_combinations.o RcppExports.o -L/usr/lib/R/lib -lR
make[2]: Leaving directory '/<>/src'
make[2]: Entering directory '/<>/src'
make[2]: Leaving directory '/<>/src'
installing to 
/<>/debian/r-cran-treescape/usr/lib/R/site-library/00LOCK-r-cran-treescape-1.10.18+dfsg/00new/treescape/libs
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Creating a generic function for ‘toJSON’ from package ‘jsonlite’ in
package ‘googleVis’
Segmentation fault
ERROR: lazy loading failed for package ‘treescape’
* removing 
‘/<>/debian/r-cran-treescape/usr/lib/R/site-library/treescape’
dh_auto_install: error: xvfb-run --auto-servernum --server-num=20 -s
"-screen 0 1024x768x24 -ac +extension GLX +render -noreset" R CMD
INSTALL -l 
/<>/r-cran-treescape-1.10.18\+dfsg/debian/r-cran-treescape/usr/lib/R/site-library
--clean . "--built-timestamp='Thu, 21 May 2020 09:37:46 +'"
returned exit code 1
make[1]: *** [debian/rules:26: override_dh_auto_install] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:16: binary-arch] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess
returned exit status 2

Bug#961233: ITP: jsmn -- header-only JSON library

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : jsmn
  Version : 1.1.0
  Upstream Author : Serge A. Zaitsev
* URL : https://github.com/zserge/jsmn
* License : MIT
  Programming Lang: C
  Description : header-only JSON library
 Philosophy
 .
 Most JSON parsers offer you a bunch of functions to load JSON data,
 parse it and extract any value by its name. jsmn proves that checking
 the correctness of every JSON packet or allocating temporary objects
 to store parsed JSON fields often is an overkill.
 .
 JSON format itself is extremely simple, so why should we complicate it?
 .
 jsmn is designed to be robust (it should work fine even with erroneous
 data), fast (it should parse data on the fly), portable (no superfluous
 dependencies or non-standard C extensions). And of course, simplicity is
 a key feature - simple code style, simple algorithm, simple integration
 into other projects.
 .
 Features
 .
  * compatible with C89
  * no dependencies (even libc!)
  * highly portable (tested on x86/amd64, ARM, AVR)
  * about 200 lines of code
  * extremely small code footprint
  * API contains only 2 functions
  * no dynamic memory allocation
  * incremental single-pass parsing
  * library code is covered with unit-tests

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

Bug#961147: libcolor-calc-perl: broken by new libgraphics-colornames-perl

[Niko Tyni]

On Wed, May 20, 2020 at 10:22:31PM +0300, Niko Tyni wrote:
> Package: libcolor-calc-perl
> Version: 1.074-2
> Severity: grave
> Tags: bullseye sid
> X-Debbugs-Cc: libgraphics-colornames-p...@packages.debian.org
> 
> Color::Calc uses Graphics::ColorNames::HTML, which was recently dropped
> from the libgraphics-colornames-perl package in Debian.
> 
> Graphics::ColorNames::HTML is now available separately on CPAN, with a
> deprecation notice pointing users to Graphics::ColorNames::WWW (packaged
> in Debian as libgraphics-colornames-www-perl) instead.
> 
> So Color::Calc needs to adapt, or Graphics::ColorNames::HTML needs to be
> packaged separately despite the deprecation.
> 
> Also, libgraphics-colornames-perl should add a Breaks entry for the
> versions of libcolor-calc-perl it broke.

I had a look at making Color::Calc use Graphics::ColorNames::WWW instead.
The API is a drop-in replacement, but the test suite blows up because it
has more color names to choose from (17 in ::HTML vs 148 in ::WWW).

The module seems to be partly about these subtle differences between
different color schemes, so I'm a bit uneasy about patching it to use
::WWW by default and patching the test suite.

We could also inline the small ::HTML hash, but part of the Color::Calc
API is being able to choose a Graphics::ColorNames submodule, so we can't
really hide it very deep. And if it's going to be a public module, it's
cleaner to just package it separately I think.

So IMO we should either to package Graphics::ColorNames::HTML even though
it's deprecated, or drop Color::Calc from Debian.

libcolor-calc-perl has just one reverse dependency AFAICS:
libcgi-application-plugin-authentication-perl.

-- 
Niko Tyni   nt...@debian.org

Bug#816448: debcheck: Does not support build-profiles

[Rebecca N. Palmer]

Control: tags -1 patch

If you'd prefer to just fix this without (for now) the broader rewrite, 
https://salsa.debian.org/qa/qa/-/merge_requests/28 claims to do so; I 
haven't tried it but it looks plausible.


Weirdly, this bug doesn't seem to affect everything with build profiles: 
of my packages, snakemake, pandas and statsmodels all have profile 
build-depends, but only snakemake is affected.

Bug#961206: improve sphinx usage for cross building

[Simon McVittie]

On Thu, 21 May 2020 at 13:43:42 +0200, Helmut Grohne wrote:
> A very rough
> sketch for this would be moving sphinx-build and the other tools to a
> new binary package maybe called simply "sphinx". Of course "sphinx"
> would depend on python3-sphinx, but given that sphinx would only cover
> the command line interface, sphinx could be marked Multi-Arch: foreign.
> Does this make sense in principle when one ignores the transition cost?

This would be reversing the recent recommendation to
call `python3 -m sphinx` in preference to `sphinx-build` (e.g. in
 and
). I don't
fully understand what the reason for that recommendation was; does it
still apply?

smcv

Bug#960726: firefox: connection failure to most https websites

[Vincent Lefevre]

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1639914

On 2020-05-19 06:08:54 +0900, Mike Hommey wrote:
> On Sun, May 17, 2020 at 02:06:17AM +0200, Vincent Lefevre wrote:
> > On 2020-05-17 07:24:23 +0900, Mike Hommey wrote:
> > > Have you set security.OCSP.require to true in about:config?
> > 
> > Yes, as I've said in my other message.
> 
> Could you file an upstream bug?

Now done: https://bugzilla.mozilla.org/show_bug.cgi?id=1639914

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

Bug#961232: dose3: Please backport patch to handle M-A:same conflicts with virtual packages

[John Paul Adrian Glaubitz]

Source: dose3
Version: 5.0.1-14+b3
Severity: normal
Tags: upstream
User: debian-...@lists.debian.org
Usertags: m68k

Hello!

The upstream patch to handle M-A:same conflicts with virtual packages [1] is
necessary for at least Debian Ports to resolve conflicts in experimental.

Could it be applied to the dose3 package currently in unstable?

Thanks,
Adrian

> [1] 
> https://scm.gforge.inria.fr/anonscm/gitweb?p=dose/dose.git;a=commit;h=226e7eb544bd02b128c19be5e79a9b236439159f

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

Bug#961230: guile-2.2 FTBFS with make-dfsg/4.3-1: ERROR: alternatives priority expects min version < 1000.

[Helmut Grohne]

Source: guile-2.2
Version: 2.2.7+1-5
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

While bootstrap testing unstable, I noticed that guile-2.2 fails to
build from source (natively). A build now ends quicky:

| dpkg-buildpackage: info: source package guile-2.2
| dpkg-buildpackage: info: source version 2.2.7+1-5
| dpkg-buildpackage: info: source distribution unstable
| dpkg-buildpackage: info: source changed by Rob Browning 

|  dpkg-source --before-build .
| dpkg-buildpackage: info: host architecture amd64
|  fakeroot debian/rules clean
| /bin/bash: ${\#x}: bad substitution
| debian/rules:70: *** ERROR: alternatives priority expects min version < 1000. 
 Stop.
| dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned 
exit status 2

This only happens since make-dfsg/4.3-1, but I think the bug here
ultimately is with guile-2.2. The relevant code from debian/rules is:

| ifneq (ok,$(shell x='$(deb_src_min_ver)';  [ "$${\#x}" -lt 4 ] && echo ok;))
|   $(error ERROR: alternatives priority expects min version < 1000)
| endif

It is surprising that this didn't fail with earlier versions of make.
The shell substitution is clearly wrong. It is unclear what it is
supposed to achieve. In any case, deleting these lines makes the build
proceed.

Helmut

Bug#961222: "/usr/bin/ucf: 85: local: root.root: bad variable name" when showing differences

[Christoph Biedl]

Control: tags 961222 patch

Christoph Biedl wrote...

> Reverting to "#!/bin/bash" yields
> the expected behaviour, too.

So this is something, one I didn't know about:

In bash and dash,

var=$(something)

works as expected even if that ``something`` contains spaces, like in

var=$(date '+%F %T')

Things are however different in dash if you're within a function and
want to limit the scope, i.e.

local var=$(date '+%F %T')

Quite frankly, I haven't checked which shell implementation does not
follow the specification, if any, or if this is just another bashism.
Quoting fixes this, see below

Christoph

--- /usr/bin/ucf.broken
+++ /usr/bin/ucf.fixed
@@ -82,8 +82,8 @@
 local new_file="$4"
 
 # Note: get_file_metadata not in quotes to ignore "\n" characters
-local old_file_label=$(get_file_metadata "$old_file")
-local new_file_label=$(get_file_metadata "$new_file")
+local old_file_label="$(get_file_metadata "$old_file")"
+local new_file_label="$(get_file_metadata "$new_file")"
 
 [ -e "$old_file" ] || old_file=/dev/null
 [ -e "$new_file" ] || new_file=/dev/null


signature.asc
Description: PGP signature

Bug#933934: unmount bash completion complains about "awk: line 18: function gensub never defined"

[Étienne Mollier]

Hi Guilem,

Thanks for the ping, I must admit I left this issue aside for
quite a while, I didn't have a Github account to forward it
myself until recently...

Guillem Jover, on 2020-05-21 14:05:21 +0200:
> On Mon, 2019-08-05 at 14:02:31 +0200, Chris Hofstaedtler wrote:
> > I'm not sure if, for bash-completion, a Depends: gawk is warranted
> > from Package: mount, which has Priority: required. This would pull
> > in gawk on pretty much every system (...).
> 
> While the package ended up with a Recommends instead of a Depends,
> which is indeed better, it still seems weird that mount being a
> required package, will pull in an awk implementation (which is part
> of the essential set, via the awk virtual through base-files) where
> our current preferred implementation is mawk (also required), while
> gawk is optional. This change seems to be fighting our current
> defaults somehow?
> 
> > Carrying a local patch to revert the change doesn't sound
> > sustainable. I'm not an awk expert to come up with a patch that
> > would implement the same functionality for mawk.
> 
> Etienne could you try to submit this upstream, so that there's no need
> to carry such patch in Debian?

Sure, let's put that brand new Github account of mine to some
use!  :D

The patch is now forwarded upstream; CI is ongoing, hopefully I
haven't broke anything in the process:

https://github.com/karelzak/util-linux/pull/1045

Will see how the issue evolves...

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


signature.asc
Description: PGP signature

Bug#961229: libnfc: New upstream version: 1.7.2

[Ludovic Rousseau]

Package: libnfc
Severity: normal

Hello,

A new upstream version of libnfc is now available (after 5 years).
https://github.com/nfc-tools/libnfc/releases/tag/libnfc-1.7.2

Maybe it is a good time to package it.

Thanks

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

Bug#961153: tech-ctte: Call for votes on TC membership of Sean Whitton

[Gunnar Wolf]

David Bremner dijo [Wed, May 20, 2020 at 05:03:16PM -0300]:
> ===BEGIN
> The Technical Committee recommends that Sean Whitton  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> S: Recommend to Appoint Sean Whitton 
> F: Further Discussion
> ===END

I am happy to vote:

S > F


signature.asc
Description: PGP signature

Bug#961156: tech-ctte: Call for votes on TC membership of Elana Hashman

[Gunnar Wolf]

David Bremner dijo [Wed, May 20, 2020 at 05:10:26PM -0300]:
> ===BEGIN
> The Technical Committee recommends that Elana Hashman  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> S: Recommend to Appoint Elana Hashman 
> F: Further Discussion
> ===END

I am happy to vote:

S > F


signature.asc
Description: PGP signature

Bug#961228: libopencv-imgcodecs4.2: opencv4.2 in unstable still depend on libopenexr23 that is no more instalable

[Eric Valette]

Package: libopencv-imgcodecs4.2
Version: 4.2.0+dfsg-6
Severity: important

Please rebuild with libopenexr24. Trying to compile experimental digikam fais 
becasue of unresolved.

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

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

Versions of packages libopencv-imgcodecs4.2 depends on:
ii  libc6 2.31-0experimental2
ii  libgcc-s1 10.1.0-2
ii  libgdal27 3.1.0+dfsg-1~exp1
ii  libgdcm3.03.0.5-1.1
ii  libjpeg62-turbo   1:2.0.4-1~exp1
ii  libopencv-core4.2 4.2.0+dfsg-6
ii  libopencv-imgproc4.2  4.2.0+dfsg-6
ii  libopenexr24  2.5.0-1
ii  libpng16-16   1.6.37-2
ii  libstdc++610.1.0-2
ii  libtiff5  4.1.0+git191117-2
ii  libwebp6  0.6.1-2+b1

libopencv-imgcodecs4.2 recommends no packages.

libopencv-imgcodecs4.2 suggests no packages.

-- no debconf information

Bug#961210: RFS: opendkim/2.11.0~beta2-3 [ITP] -- DomainKeys Identified Mail (DKIM) signing and verifying milter

[David Bürgin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opendkim
   Version : 2.11.0~beta2-3
   Upstream Author : The Trusted Domain Project
 * URL : http://www.opendkim.org/
 * License : BSD-3-clause and SOSL
 * Vcs : https://salsa.debian.org/debian/opendkim
   Section : mail

It builds those binary packages:

  opendkim - DomainKeys Identified Mail (DKIM) signing and verifying milter
  opendkim-tools - DomainKeys Identified Mail (DKIM) utilities
  libopendkim11 - DomainKeys Identified Mail (DKIM) library
  libopendkim-dev - DomainKeys Identified Mail (DKIM) library (development 
files)
  libvbr2 - Vouch By Reference (VBR) library
  libvbr-dev - Vouch By Reference (VBR) library (development files)
  librbl1 - Real-time Blacklist (RBL) query library
  librbl-dev - Real-time Blacklist (RBL) query library (development files)
  miltertest - utility for testing milter applications

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opendkim/opendkim_2.11.0~beta2-3.dsc

Changes since the last upload:

   * Move miltertest into a separate binary package (Closes: #947324).
   * miltertest: Add a patch that moves the man page to section 1.
   * Use dh_auto_configure instead of ./configure directly, in order to install
 libraries and pkg-config files in the multiarch path /usr/lib/*/.
   * Mark shared library packages as "Multi-Arch: same" in d/control.
   * Silence a debhelper warning by renaming d/opendkim.service.generate.
   * Bump Standards-Version to 4.5.0 without further changes.

I’ve included [ITP] in the subject because this introduces a new binary
package miltertest. miltertest is part of OpenDKIM, but can be used
independently.

Thank you!

-- 
David

Bug#961227: pbuilder misparses build dependencies specifying a version range that have multiple profiles

[Adrian Bunk]

Package: pbuilder
Version: 0.230.4
Severity: important
Control: affects -1 src:libsoup2.4

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/libsoup2.4.html

...
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: apache2 (>= 2.4), curl, debhelper-compat (= 12), dh-sequence-gir, 
dh-sequence-gnome, glib-networking (>= 2.32.0), gtk-doc-tools, 
libapache2-mod-php (, libapache2-mod-php (>= 2:7), libbrotli-dev, 
libgirepository1.0-dev (>= 0.9.5), libglib2.0-dev (>= 2.58), libkrb5-dev, 
libnss-myhostname, libpsl-dev (>= 0.20), libsqlite3-dev, libxml2-dev, meson (>= 
0.48), php (, php (>= 2:7), php-xmlrpc, python3, valac, libglib2.0-doc
dpkg-deb: warning: parsing file 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control' 
near line 8 package 'pbuilder-satisfydepends-dummy':
 'Depends' field, reference to 'libapache2-mod-php':
 implicit exact match on version number, suggest using '=' instead
dpkg-deb: warning: parsing file 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control' 
near line 8 package 'pbuilder-satisfydepends-dummy':
 'Depends' field, reference to 'libapache2-mod-php':
 version value starts with non-alphanumeric, suggest adding a space
dpkg-deb: error: parsing file 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control' 
near line 8 package 'pbuilder-satisfydepends-dummy':
 'Depends' field, reference to 'libapache2-mod-php': version contains ' '
E: pbuilder-satisfydepends failed.


The build dependencies are:
Build-Depends: apache2 (>= 2.4)  ,
   curl  ,
   debhelper-compat (= 12),
   dh-sequence-gir,
   dh-sequence-gnome,
   glib-networking (>= 2.32.0),
   gtk-doc-tools,
   libapache2-mod-php (<< 2:8)  ,
   libapache2-mod-php (>= 2:7)  ,
   libbrotli-dev,
   libgirepository1.0-dev (>= 0.9.5),
   libglib2.0-dev (>= 2.58),
   libkrb5-dev,
   libnss-myhostname [linux-any] ,
   libpsl-dev (>= 0.20),
   libsqlite3-dev,
   libxml2-dev,
   meson (>= 0.48),
   php (<< 2:8)  ,
   php (>= 2:7)  ,
   php-xmlrpc  ,
   python3,
   valac

Simple build dependencies with 2 profiles are handled fine
by pbuilder (apache2, php-xmlrpc).

The failures are on the double libapache2-mod-php and php build
dependencies that specify a range and each have 2 profiles.

Bug#961226: grcompiler: new upstream version

[Bastian Germann]

Package: grcompiler
Severity: wishlist

Please consider packaging the new grcompiler 5.2. I created a merge
request with all necessary changes at
https://salsa.debian.org/fonts-team/grcompiler/-/merge_requests/1

Bug#961223: gnome-terminal: New terminal button default settting does not work, always in a tab.

[Matthijs Melchior]

Package: gnome-terminal
Version: 3.36.2-1
Severity: normal
Tags: upstream

Dear Maintainer,

The "Preferences-General" dialogue offers the option
"Open new terminal in:" with choises "Window" or "Tab".
This setting is not used when clicking the "+" button
at the left top.

My expectation was that it would invert the action of
the "ctrl" key while clicking the "+" button:
click to get a new window and ctrl-click to get a new tab.

Thanks.



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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  dconf-gsettings-backend [gsettings-backend]   0.36.0-1
ii  gnome-terminal-data   3.36.2-1
ii  gsettings-desktop-schemas 3.36.1-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-8
ii  libdconf1 0.36.0-1
ii  libglib2.0-0  2.64.2-1
ii  libgtk-3-03.24.20-1
ii  libpango-1.0-01.44.7-4
ii  libuuid1  2.35.1-5
ii  libvte-2.91-0 0.60.2-1
ii  libx11-6  2:1.6.9-2+b1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.44.1-1
ii  nautilus-extension-gnome-terminal  3.36.2-1
ii  yelp   3.36.0-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#961224: python-cobra: test failures on s390x

[peter green]

Source: python-cobra
Version: 0.18.0-1
Severity: serious

Three of the last four builds of python-cobra on s390x have failed with.


=== FAILURES ===
___ test_model_summary_to_frame_with_fva[optlang-glpk-0.95] 

model = , opt_solver = 'optlang-glpk'
fraction = 0.95

 @pytest.mark.parametrize("fraction", [0.95])
 def test_model_summary_to_frame_with_fva(model, opt_solver, fraction):
 """Test model summary.to_frame() (using FVA)."""
 if opt_solver == "optlang-gurobi":
 pytest.xfail("FVA currently buggy")
 # test non-fva version (these should be fixed for textbook model)
 expected_in_fluxes = ['o2_e', 'glc__D_e', 'nh4_e', 'pi_e', np.nan,
   np.nan, np.nan, np.nan, np.nan, np.nan, np.nan,
   np.nan]
 expected_out_fluxes = ['h2o_e', 'co2_e', 'h_e', 'for_e', 'ac_e', 
'acald_e',
'pyr_e', 'etoh_e', 'lac__D_e', 'succ_e', 
'akg_e',
'glu__L_e']
 
 model.solver = opt_solver

 solution = model.optimize()
 out_df = model.summary(solution, fva=fraction).to_frame()
 
 assert out_df[('IN_FLUXES', 'ID')].tolist() == expected_in_fluxes

>   assert out_df[('OUT_FLUXES', 'ID')].tolist() == expected_out_fluxes
E   AssertionError: assert ['h2o_e', 'co... 'pyr_e', ...] == ['h2o_e', 
'co2...acald_e', ...]
E At index 5 diff: 'pyr_e' != 'acald_e'
E Use -v to get the full diff

Bug#960360: transition: re2

[Sebastian Ramacher]

Control: forwarded -1 https://release.debian.org/transitions/html/auto-re2.html
Control: tags -1 confirmed
Control: block -1 by 960361

On 2020-05-11 17:57:42 -0700, Stefano Rivera wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Public ABI Breakage:
> Types changed from maps to vectors in a couple of functions. Nothing in
> Debian uses them.
> 
> Public API Breakage:
> The deprecated RE2::Options::set_utf8 and RE2::Options::utf8 helper
> functions were removed from re2.h.
> 
> https://github.com/google/re2/commit/58141dc9c92189ed8d046f494f5e034d5db91bea
> https://github.com/google/re2/commit/ac65d4531798ffc9bf807d1f7c09efb0eec70480
> 
> Reverse Dependencies:
> * Updated ruby-re2 to 1.2.0 to support this.
> * Chromium needs a patch:
>   
> https://github.com/chromium/chromium/commit/ede390a0b18e4565abf8ac1e1ff717e1d43fc320
> * Others build without error.

Go ahead.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#961153: tech-ctte: Call for votes on TC membership of Sean Whitton

[David Bremner]

David Bremner  writes:

> ===BEGIN
> The Technical Committee recommends that Sean Whitton  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> S: Recommend to Appoint Sean Whitton 
> F: Further Discussion
> ===END

I vote S > F


signature.asc
Description: PGP signature

Bug#961156: tech-ctte: Call for votes on TC membership of Elana Hashman

[David Bremner]

David Bremner  writes:

> ===BEGIN
> The Technical Committee recommends that Elana Hashman  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> S: Recommend to Appoint Elana Hashman 
> F: Further Discussion
> ===END

I vote S > F



signature.asc
Description: PGP signature

Bug#961053: transition: mumps petsc slepc

[Sebastian Ramacher]

Control: tags -1 + moreinfo

Hi Drew

On 2020-05-20 00:48:48 +0800, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> I think the joint mumps 5.3.1 / petsc 3.13 / slepc 3.13 transition is
> ready to proceed.  Packages seem well behaved in experimental.

Did you test if the reverse dependencies build with the new mumps, petsc
and slepc stack?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#961222: "/usr/bin/ucf: 85: local: root.root: bad variable name" when showing differences

[Christoph Biedl]

Package: ucf
Version: 3.0041
Severity: important

Dear Maintainer,

starting with 3.0041 (3.0039 was okay), ucf breaks with an error from
the shell interpreter when selecting to show the differences between two
files.

How to repeat:

echo one >config
echo two >config.new
ucf config.new config

The well-known dialog comes up. Select "show the differences between the
versions".

Expected: A diff of the two files.

Got:

| /usr/bin/ucf: 85: local: root.root: bad variable name
(where root.root are user and group of the file).

Also abort of dpkg/apt, possibly leaving the system in a half-configured
state.

Using the ucf script from 3.0039 works fine. A quick glance into the
diff reveals the interpreter was changed to /bin/sh from /bin/bash, and
/bin/dash isn't happy with that line. Reverting to "#!/bin/bash" yields
the expected behaviour, too.

Cheers,

Christoph

PS: ucf --purge config

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

Kernel: Linux 5.4.41 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages ucf depends on:
ii  coreutils   8.30-3+b1
ii  debconf 1.5.74
ii  sensible-utils  0.0.12+nmu1

ucf recommends no packages.

ucf suggests no packages.

-- debconf information excluded



signature.asc
Description: PGP signature

Bug#961188: src:postgis: autopkgtests fail on 32bit ARM, due to missing sfcgal

[Sebastiaan Couwenberg]

On 5/21/20 4:29 PM, stefa...@debian.org wrote:
> The autopkgtests aren't declared as skippable, so exiting 77 is a
> failure.

Also fixed in git, thanks!

Kind Regards,

Bas

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

Bug#956694: package should install usable headers by default

[Matthias Klose]

This also makes sopt ftbfs.  Please patch ./include/spdlog/tweakme.h to set the
expected default.

Bug#961221: broken lintian report link on packages overview

[Ryan Kavanagh]

Package: qa.debian.org
Severity: normal

The "Lintian" reports link on packages overview pages are broken. For
example, clicking on "Lintian" on my packages overview page [0] brings
you to the following non-existing page [1]. It looks like the page may
have moved to [2].

[0] https://qa.debian.org/developer.php?login=rak=yes
[1] https://lintian.debian.org/reports/maintainer/rak%40debian.org.html
[2] 
https://lintian.debian.org/maintainer/ryan%20kavanagh%20%3c...@debian.org%3E.html

-- 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.5.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#574292: resize2fs still risky

[Theodore Y. Ts'o]

On Thu, May 21, 2020 at 10:04:54AM +0200, Wilmer van der Gaast wrote:
> I just started a downsizing resize2fs operation over an SSH session
> without screen and then realised how bad an idea that was..
> 
> Then found this bug as a confirmation. :-)
> 
> It looks like resize2fs (still) doesn't install any signal handlers so
> I've just disabled auto-suspend on my laptop and will hope for the best.
> 
> tytso@ mentions the danger of -M by the way, I guess that danger applies
> to *any* downsizing operation, not just to bare-minimum resizes done by -M?

The reason why we've never bothered with signal handlers is because it
won't help against unclean/uncommanded shutdowns --- for example such
as auto-suspend on your laptop.

In *general* things are mostly safe unless you need to do an
overlapping move of the inode table, in which case it is very hard to
make it be 100% safe.

You can use resize2fs -z undo_file, but that's currently not
super-safe, because we aren't forcing a flush between every I/O
operation --- because that would disastrous in terms of performance,
and users would then be complaining about how slow the resize
operation was, and how it was increasing their SSD write wear.

Basically, it's hard to keep everyone happy.

If you would like to help, you could try running resize2fs -p on a
test file system, and then try to randomly interrupt the resize at
various points, and then run e2fsck -fy and during which phase of the
resize you see things getting corrupted.

It's not a high priority for me, since I have way too many other
things to worry about, if it is high priority for *you*, some
contributions to the effort would be much appreciated.  After all,
Open source means you get to help fix the things you care about.  :-)

  - Ted

Bug#961188: src:postgis: autopkgtests fail on 32bit ARM, due to missing sfcgal

[stefanor]

Hi Sebastiaan (2020.05.21_04:44:04_+)
> Thank for reporting this issue with a patch. Instead of applying your
> patch I chose to skip the autopkgtests entirely on arm{el,hf} like we do
> for other problematic architectures.

That works for me too.

But you raise a good point, I missed something:
The autopkgtests aren't declared as skippable, so exiting 77 is a
failure.

So, more patches:

diff -Nru postgis-3.0.1+dfsg/debian/tests/control 
postgis-3.0.1+dfsg/debian/tests/control
--- postgis-3.0.1+dfsg/debian/tests/control 2020-04-17 11:30:49.0 
-0700
+++ postgis-3.0.1+dfsg/debian/tests/control 2020-05-21 07:23:19.0 
-0700
@@ -1,3 +1,3 @@
 Depends: @, postgresql-server-dev-all, postgresql-all
 Tests: test-extension-creation regress
-Restrictions: allow-stderr
+Restrictions: allow-stderr, skippable

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#961200: ITP: nfq -- The NFQUEUE based IDN/punicode DNS filter to mitigate homograph phishing attacks

[Joachim Bauernberger]

Package: wnpp
Severity: wishlist
Owner: Joachim Bauernberger 

* Package name: nfq
  Version : 1.0.6
  Upstream Author : Name 
* URL : https://gitlab.com/jbauernberger/nfq/
* License : GPLv3
  Programming Lang: C
  Description : The NFQUEUE based IDN/punicode DNS filter to mitigate
homograph phishing attacks

NFQ is a DNS packet filter that interfaces with the libnetfilter_queue Linux
kernel subsystem. It identifies any punicode domain names by matching the
string "xn--" in DNS questions or answers. NFQ stops all homograph phishing
attacks for lookalike domains. NFQ can run either directly on a Linux based
workstation, and before your DNS cache and/or on a gateway.

NFQ is not replacement for /etc/hosts: E.g. NFQ is not for blacklisting which
would be a poor security guarantee for homograph attacks. Instead NFQ blocks
all punicode domains by default and uses an (optional) whitelist to explicitly
allow certain selected IDN domains which you know are safe.

   NFQ is for environments with strict anti-phishing policies. We assume:

   •   you are using some kind of dnscache (e.g. djbdns, dnsmasq, unbound,
etc ...) which then forwards any queries to an upstream DNS server (e.g.
8.8.8.8 or 1.1.1.1 etc), and ...

   •   you have configured your browser to use your DNS cache instead of
resolving directly via upstream reolver over DoH. (nfq works on the kernel
queue so you can still use DoH for outgoing forwarded queries as part with
dnsmasq or unbound etc ... nfq doesn't prevent you from using DoH)

   •   you will be adding the iptables manually so that nfq can intercept
packages, this is outside the scope of the nfq installer, see the README and
examples how to do this.

Bug#958934: bind9: named fails to start after upgrade to 9.16.2

[Scott Bailey]

I think I'm using ifupdown (it's installed, anyway -- version 0.8.35+b1) but I 
also believe this is not the root cause of the problem.

It took me awhile to think it through, but if you revisit the problem report, 
I'm reproducing the problem by running named interactively (on steady-state 
system) -- so the problem can't be boot-related, as everything else 
(particularly all of the filesystems, and also all of the network interfaces) 
is up and running well before the point I attempted to start the daemon.

You'd think with all this COVID-19 stay-home stuff going on I would have had 
time to retest with tracing, but I'm still trying to get a window where I have 
free time and the rest of my household is willing to take the DNS hit.

Thanks,
Scott

-Original Message-
From: Michael Biebl  
Sent: Tuesday, May 19, 2020 8:43 AM
To: 958...@bugs.debian.org; Scott Bailey 
Subject: Re: bind9: named fails to start after upgrade to 9.16.2

Could you share your network configuration?
Are you using ifupdown?

I wonder if this is a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960594

where I suspect the if-up.d hook breaking the dependency resolution
causing bind9 to be started way too early.

Bug#961220: dovecot: lda: Fatal: Plugin 'push_notifications' not found from directory /usr/lib/dovecot/modules

[Joseph Nahmias]

Package: dovecot-core
Version: 1:2.3.4.1-5+deb10u2
Severity: important
File: /usr/lib/dovecot/dovecot-lda

Hello,

I was trying to set up push_notification, but when I add it to the config, I 
start getting errors like this:

dovecot: lda: Fatal: Plugin 'push_notifications' not found from directory 
/usr/lib/dovecot/modules

I do see the file:

$ locate push_notification
/usr/lib/dovecot/modules/lib20_push_notification_plugin.so
/usr/lib/dovecot/modules/lib22_push_notification_lua_plugin.so


Is there some misconfiguration of the package somewhere?

Thanks,
--Joe


-- Package-specific info:

dovecot configuration
-
# 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.4 ()
# OS: Linux 4.19.0-9-686-pae i686 Debian 10.4 ext4
auth_mechanisms = plain login
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
mail_location = maildir:/srv/mail/%n:INBOX=/srv/mail/%n/Inbox:LAYOUT=fs
mail_privileged_group = mail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date index ihave duplicate 
mime foreverypart extracttext spamtest spamtestplus
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
auto = subscribe
special_use = \Drafts
  }
  mailbox Junk {
auto = subscribe
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox Trash {
auto = subscribe
special_use = \Trash
  }
  prefix = 
}
passdb {
  driver = pam
}
plugin {
  sieve = file:/srv/sieve/%n;active=/srv/sieve/ACTIVE/%u.sieve
  sieve_extensions = +spamtest +spamtestplus
  sieve_spamtest_max_value = 5.0
  sieve_spamtest_status_header = X-Spam-Score: [[:alnum:]]+, 
score=(-?[[:digit:]]+\.[[:digit:]])
  sieve_spamtest_status_type = score
}
protocols = " imap lmtp sieve"
service auth {
  unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
  }
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
  }
}
ssl = required
ssl_cert = 
ii  dovecot-imapd 1:2.3.4.1-5+deb10u2
pn  dovecot-ldap  
ii  dovecot-lmtpd 1:2.3.4.1-5+deb10u2
pn  dovecot-lucene
ii  dovecot-managesieved  1:2.3.4.1-5+deb10u2
pn  dovecot-mysql 
pn  dovecot-pgsql 
pn  dovecot-pop3d 
ii  dovecot-sieve 1:2.3.4.1-5+deb10u2
pn  dovecot-solr  
pn  dovecot-sqlite
pn  dovecot-submissiond   
ii  ntp   1:4.2.8p12+dfsg-4

Versions of packages dovecot-core is related to:
ii  dovecot-core [dovecot-common]  1:2.3.4.1-5+deb10u2
pn  dovecot-dev
pn  dovecot-gssapi 
ii  dovecot-imapd  1:2.3.4.1-5+deb10u2
pn  dovecot-ldap   
ii  dovecot-lmtpd  1:2.3.4.1-5+deb10u2
ii  dovecot-managesieved   1:2.3.4.1-5+deb10u2
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
ii  dovecot-sieve  1:2.3.4.1-5+deb10u2
pn  dovecot-sqlite 

-- debconf information excluded

Bug#961219: www.debian.org: A very minor typo

[Brian Potkin]

Package: www.debian.org
Severity: minor

In Adding new entries with "reportbug", https://www.debian.org/devel/wnpp/
has

  If your request type is ITP (1) or RFP (4) you are asked for...

(4) should be (5).

Cheers,

Brian.

Bug#961218: RFP: ipp-usb -- Daemon for IPP over USB printer support

[Brian Potkin]

Package: wnpp
Severity: wishlist

* Package name: ipp-usb
  Version : 0.9.3+34.1
  Upstream Author : Alexander Pevzner 
* URL : https://github.com/alexpevzner/ipp-usb
* License : BSD 2-Clause "Simplified" License
  Programming Lang: Go
  Description : Daemon for IPP-over-USB printer support

ipp-usb is a userland driver for USB devices (printers, scanners, MFDs),
supporting the IPP-over-USB protocol. It enables these USB devices to
be seen as regular network printers.
.
It is designed to be a replacement for the ippusbxd daemon, previously
used for this purpose. It has a greatly rethought architecture in
comparison with ippusbxd, and fixes all of its major flaws and issues.


Dear Prospective Packager,

Bug #909564 has been attended to in avahi 0.8-1 and Avahi now handles
the loopback device lo for local services. Therefore, local-only
IPP-over-USB printers now get advertised. Thank you to Trent Lloyd and
Till Kamppeter.

By all accounts, ipp-usb is a better ippusbxd. Please see slide #12 at

  
https://ftp.pwg.org/pub/pwg/liaison/openprinting/presentations/cups-filters-ippusbxd-2020.pdf

In

 https://github.com/alexpevzner/sane-airscan/issues/29#issuecomment-629628416

Alexander Pevzner says:

  ippusbxd has serious problems, and these problems are by design, not
  by implementation. All these problems are fixed in ipp-usb, it uses
  very different design, so it works absolutely reliable (this is Till's
  words, not mine).

It seems to me that Chrome OS not accepting software in Go hasn't any
relevance when packaging for Debian. In any case, Alexander Pevzner
would dispute the claim:

  Frankly speaking, I don't quite understand ChromeOS reasoning. I've
  recently measured memory consumption of ipp-usb vs ippusbxd. To my
  surprise, RSS (Resident Set Size, i.e. amount of memory really used)
  of ipp-usb is even slightly less. If there are more that 1 devices
  connected, ipp-usb will handle them all in a single process, adding
  a small amount of memory per device, while ippusbxd requires a process
  per device.

The remainder of his argument is at

 https://github.com/alexpevzner/sane-airscan/issues/29#issuecomment-630438806

It would be good to see ipp-usb enter unstable alongside ippusbxd.

Regards,

Brian.

Bug#961217: cups: “Cannot assign requested address” on VPS after hibernation

[Axel Stammler]

Package: cups
Version: 2.2.10-6+deb10u3
Severity: important

Dear Maintainer,

remote printing fails silently on shared printer. Local printing works. 
“systemctl restart
cups” makes the problem go away (until the next hibernation cycle).

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

Versions of packages cups depends on:
ii  cups-client2.2.10-6+deb10u3
ii  cups-common2.2.10-6+deb10u3
ii  cups-core-drivers  2.2.10-6+deb10u3
ii  cups-daemon2.2.10-6+deb10u3
ii  cups-filters   1.21.6-5
ii  cups-ppdc  2.2.10-6+deb10u3
ii  cups-server-common 2.2.10-6+deb10u3
ii  debconf [debconf-2.0]  1.5.71
ii  ghostscript9.27~dfsg-2+deb10u3
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10
ii  libcups2   2.2.10-6+deb10u3
ii  libcupsimage2  2.2.10-6+deb10u3
ii  libgcc11:8.3.0-6
ii  libstdc++6 8.3.0-6
ii  libusb-1.0-0   2:1.0.22-2
ii  poppler-utils  0.71.0-5
ii  procps 2:3.3.15-2

Versions of packages cups recommends:
ii  avahi-daemon 0.7-4+b1
ii  colord   1.4.3-4
ii  cups-filters [ghostscript-cups]  1.21.6-5
ii  printer-driver-gutenprint5.3.1-7

Versions of packages cups suggests:
ii  cups-bsd   2.2.10-6+deb10u3
ii  foomatic-db-compressed-ppds [foomatic-db]  20181217-2
ii  hplip  3.18.12+dfsg0-2
ii  printer-driver-cups-pdf [cups-pdf] 3.0.1-5
ii  printer-driver-hpcups  3.18.12+dfsg0-2
pn  smbclient  
ii  udev   241-7~deb10u4

-- debconf-show failed