Bug#942654: Bug#940872: KDE Frameworks 5.62 coming to unstable

[Antonio]

I had already tried this approach for disable numlock but does not
work. I solved it only by running numlockx in the auto-start directory
(after the kde desktop was started).

Bug#933025: ldtp: Porting to python3, or removing?

[Kartik Mistry]

On Fri, Jul 26, 2019 at 1:48 AM Paul Gevers  wrote:
> On 25-07-2019 21:49, Samuel Thibault wrote:
> > python2 is being phased out, so something needs to be done for ldtp. The
> > upstream mailing list has been very inactive for a long time. Will there
> > really be interest in porting it to python3? Or should we just remove
> > ldtp from Debian? (it has no rdep)
>
> While this is true, Debian will carry Python 2 in bullseye if needed,
> see https://bugs.debian.org/931659#17. So don't remove it just yet (but
> investigating if it's worth porting is very valuable of course).

I have update. Upstream has no plan or time to port ldtp to Python3,
so I just did request for removal.

See: #943304

--
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com

Bug#943146: orca: Python2 removal in sid/bullseye

[Samuel Thibault]

Hello,

mo...@debian.org, le mer. 23 oct. 2019 02:33:30 +, a ecrit:
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests (the specific reason can be found searching this
> source package in
> https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ).

orca 3.34.0-2 ['Build-Depends->python-gi-dev']

This looks like a false positive:

$ dpkg -L python-gi-dev
/.
/usr
/usr/include
/usr/include/pygobject-3.0
/usr/include/pygobject-3.0/pygobject.h
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/pygobject-3.0.pc
/usr/share
/usr/share/doc
/usr/share/doc/python-gi-dev
/usr/share/doc/python-gi-dev/changelog.Debian.gz
/usr/share/doc/python-gi-dev/changelog.gz
/usr/share/doc/python-gi-dev/copyright

There is nothing python2-specific here.

Samuel

Bug#942768: lcl-units-2.0: file conflict with lazarus-src-2.0 (versin 2.0.2+dfsg-5)

[Alexander Kernozhitsky]

Package: lazarus
Version: 2.0.2+dfsg-6
Followup-For: Bug #942768

Hello, I was upgrading to 2.0.2+dfsg-6 and I am still getting the file
conflict:

dpkg: error processing archive /var/cache/apt/archives/lazarus-
src-2.0_2.0.2+dfsg-6_all.deb (--unpack):
 trying to overwrite
'/usr/lib/lazarus/2.0.2/components/IdeInspector/ideinspector.lpk', which is
also in package lcl-units-2.0 2.0.2+dfsg-6
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/vlc/lazvlc.lpk to
/usr/lib/lazarus/2.0.2/components/vlc/lazvlc.lpk.orig by lazarus-src-2.0', none
removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/externhelp/externhelp.lpk to
/usr/lib/lazarus/2.0.2/components/externhelp/externhelp.lpk.orig by lazarus-
src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/sparta/dockedformeditor/sparta_dockedformeditor.lpk
to
/usr/lib/lazarus/2.0.2/components/sparta/dockedformeditor/sparta_dockedformeditor.lpk.orig
by lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/sparta/mdi/sparta_mdi.lpk to
/usr/lib/lazarus/2.0.2/components/sparta/mdi/sparta_mdi.lpk.orig by lazarus-
src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/sparta/smartformeditor/sparta_smartformeditor.lpk
to
/usr/lib/lazarus/2.0.2/components/sparta/smartformeditor/sparta_smartformeditor.lpk.orig
by lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/sparta/toolsapi/sparta_toolsapi.lpk to
/usr/lib/lazarus/2.0.2/components/sparta/toolsapi/sparta_toolsapi.lpk.orig by
lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/sparta/generics/sparta_generics.lpk to
/usr/lib/lazarus/2.0.2/components/sparta/generics/sparta_generics.lpk.orig by
lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/lazdebuggergdbmi/lazdebuggergdbmi.lpk to
/usr/lib/lazarus/2.0.2/components/lazdebuggergdbmi/lazdebuggergdbmi.lpk.orig by
lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/lazdebuggergdbmi/test/gdbmitestutils/gdbmitestutils.lpk
to
/usr/lib/lazarus/2.0.2/components/lazdebuggergdbmi/test/gdbmitestutils/gdbmitestutils.lpk.orig
by lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/mouseandkeyinput/lazmouseandkeyinput.lpk to
/usr/lib/lazarus/2.0.2/components/mouseandkeyinput/lazmouseandkeyinput.lpk.orig
by lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/chmhelp/packages/idehelp/chmhelppkg.lpk to
/usr/lib/lazarus/2.0.2/components/chmhelp/packages/idehelp/chmhelppkg.lpk.orig
by lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/chmhelp/packages/help/lhelpcontrolpkg.lpk to
/usr/lib/lazarus/2.0.2/components/chmhelp/packages/help/lhelpcontrolpkg.lpk.orig
by lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/fppkg/src/fppkgpackagemanager.lpk to
/usr/lib/lazarus/2.0.2/components/fppkg/src/fppkgpackagemanager.lpk.orig by
lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/anchordocking/design/anchordockingdsgn.lpk to
/usr/lib/lazarus/2.0.2/components/anchordocking/design/anchordockingdsgn.lpk.orig
by lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/anchordocking/anchordocking.lpk to
/usr/lib/lazarus/2.0.2/components/anchordocking/anchordocking.lpk.orig by
lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/pas2js/pas2jsdsgn.lpk to
/usr/lib/lazarus/2.0.2/components/pas2js/pas2jsdsgn.lpk.orig by lazarus-
src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/fpweb/lazwebextra.lpk to
/usr/lib/lazarus/2.0.2/components/fpweb/lazwebextra.lpk.orig by lazarus-
src-2.0', none removed.
No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/fpweb/weblaz.lpk
to /usr/lib/lazarus/2.0.2/components/fpweb/weblaz.lpk.orig by lazarus-src-2.0',
none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/cairocanvas/cairocanvas_pkg.lpk to
/usr/lib/lazarus/2.0.2/components/cairocanvas/cairocanvas_pkg.lpk.orig by
lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/projecttemplates/projtemplates.lpk to
/usr/lib/lazarus/2.0.2/components/projecttemplates/projtemplates.lpk.orig by
lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/fpcunit/console/fpcunitconsolerunner.lpk to
/usr/lib/lazarus/2.0.2/components/fpcunit/console/fpcunitconsolerunner.lpk.orig
by lazarus-src-2.0', none removed.
No diversion 'diversion of
/usr/lib/lazarus/2.0.2/components/fpcunit/fpcunittestrunner.lpk to
/usr/lib/lazarus/2.0.2/components/fpcunit/fpcunittestrunner.lpk.orig 

Bug#943304: RM: ldtp -- ROM; Upstream has no plan to maintain, (Going to be) RC buggy

[Kartik Mistry]

Package: ftp.debian.org
Severity: normal

ldtp is Python2 only and after discussing with upstream it turned out
that they don't have any plan to port it to Python3. I don't have any
time to maintain it as upstream. So, it is better to remove ldtop from
Debian until someone ports. I can reintroduce package then.

Thanks.

-- 
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com

Bug#943300: xpra: Python2 removal in sid/bullseye

[Dmitry Smirnov]

On Wednesday, 23 October 2019 1:33:35 PM AEDT mo...@debian.org wrote:
> Source: xpra
> Usertags: py2removal
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests

Are you sure this is not a false-positive??
Xpra is already fully converted to Python3 and I can't find any references to 
Python2 whatsoever.

-- 
All the best,
 Dmitry Smirnov.

---

No snowflake in an avalanche ever feels responsible.
-- Stanisław Jerzy Lec



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

Bug#939091: ITP: libcore-java -- Core barcode encoding/decoding library

[tony mancill]

On Sun, Sep 01, 2019 at 10:06:31AM +0200, Mechtilde Stehmann wrote:
> Package: wnpp
> Severity: wishlist
> * Package name: libzxing-core-java
>   Version : 3.4.0
>   Upstream Author : Jeremias Maerki, ZXing authors
> * URL : http://central.maven.org/maven2/com/google/zxing/core

Hi Mechtilde,

Instead of using the sources.jar from Maven Central, is there a reason
that we shouldn't use this repo to build the core module?

  https://github.com/zxing/zxing

The project is active which could be useful for support.

Thanks,
tony


signature.asc
Description: PGP signature

Bug#943051: closed by Nicholas Breen (Re: [Debichem-devel] Bug#943051: gromacs: Python2 removal in sid/bullseye)

[Nicholas Breen]

On Tue, Oct 22, 2019 at 11:06:01PM -0400, Sandro Tosi wrote:
> Hello Nicholas,
> any specific reason to wait this long? it would be very helpful if
> there's a chance for you to speed up the upload to unstable, so that
> we can reduce the number of packages needing python2 in unstable soon,
> and better assess the situation we are in, and if we can actually
> remove py2 during bullseye development cycle. thanks for your
> understanding!

Hi Sandro,

Only that the fixes are in the beta branch for the next upstream
release, and it's scheduled for a stable release in January.  Also,
right now the experimental build fails on four release architectures
(and 11 port architectures!), so it's not quite ready for an upload to
unstable, if it can't later migrate to testing.

I haven't looked into the upstream code changes yet, but there was only
one specific part of the documentation build that relied on python2 in
the earlier versions - I'll see if I can backport that more quickly.


- Nicholas

Bug#940872: KDE Frameworks 5.62 coming to unstable

[Diederik de Haas]

On donderdag 26 september 2019 22:56:08 CEST Bob Weber wrote:
> Another trick that worked on 2 machines here is to set the numlock on in
> /etc/sddm.conf.
> 
> My general section of sddm.conf looks like this now:
> 
> [General]
> HaltCommand=
> RebootCommand=
> Numlock=on
> 
> Hope this helps.

This fixed the issue I had which I mentioned in the CC-ed bug reports.

Thanks :-)

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

Bug#943051: closed by Nicholas Breen (Re: [Debichem-devel] Bug#943051: gromacs: Python2 removal in sid/bullseye)

[Sandro Tosi]

Hello Nicholas,
any specific reason to wait this long? it would be very helpful if
there's a chance for you to speed up the upload to unstable, so that
we can reduce the number of packages needing python2 in unstable soon,
and better assess the situation we are in, and if we can actually
remove py2 during bullseye development cycle. thanks for your
understanding!

On Tue, Oct 22, 2019 at 10:59 PM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the src:gromacs package:
>
> #943051: gromacs: Python2 removal in sid/bullseye
>
> It has been closed by Nicholas Breen .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Nicholas Breen 
>  by
> replying to this email.
>
>
> --
> 943051: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943051
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Nicholas Breen 
> To: 943051-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 22 Oct 2019 19:48:26 -0700
> Subject: Re: [Debichem-devel] Bug#943051: gromacs: Python2 removal in 
> sid/bullseye
> Version: 2020~beta1-1
>
> On Wed, Oct 23, 2019 at 02:33:26AM +, mo...@debian.org wrote:
> > Source: gromacs
> > Version: 2019.4-1
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> >
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
>
> Fixed in experimental, will probably move to unstable in January.
>
>
> -- Forwarded message --
> From: mo...@debian.org
> To: mainto...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 23 Oct 2019 02:33:26 +
> Subject: gromacs: Python2 removal in sid/bullseye
> Source: gromacs
> Version: 2019.4-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
>
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests (the specific reason can be found searching this
> source package in
> https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ).
> Please stop using Python2, and fix this issue by one of the following
> actions.
>
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>
>   This is the preferred option.
>
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.  If the
>   package still has reverse dependencies, raise the severity to
>   "serious" and document the reverse dependencies with the BTS affects
>   command.  If the package has no reverse dependencies, confirm that
>   the package can be removed, reassign this issue to ftp.debian.org,
>   make sure that the bug priority is set to normal and retitle the
>   issue to "RM: PKG -- removal triggered by the Python2 removal".
>
> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
>
>   This is the least preferred option.
>
> If there are questions, please refer to the wiki page for the removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#942756: cme: please provide more description of the format of d/fix.scanned.copyright

[Ross Vandegrift]

Control: tags -1 patch

On Mon, Oct 21, 2019 at 05:17:59PM +0200, Dominique Dumont wrote:
> The data contained in debian/copyright is mapped to a tree structure inside 
> cme. You can have a view of this structure by running 'cme dump dpkg-
> copyright' or get a graphical view with 'cme edit dpkg-copyright'
> 
> The instructions specified in fix.scanned.copyright are steps to walk in that 
> tree and alter the values when specified.

Aha, now this is coming together.

> > Things that I'd find helpful:
> > - what is the general form of these lines?  If that's too complex, examples
> >   covering more use-cases would be helpful.
> 
> In fact, I've found that tweaking debian/fill.copyright.blanks.yml often 
> provide better results. All in all, I've found very few cases where tweaking 
> d/fix.scanned.copyright provided better results than tweaking debian/
> fill.copyright.blanks.yml 

Makes sense - though am I correct to think that fix.scanned.copyright is for
fixing extractions that include html entities, weird chars from upstream, etc?

> I understand that Config::Model::Loader synopsis is for only for Perl
> programmer. 
> 
> On the other hand, the "load string syntax" section was intended to provide
> instructions usable for non-perl programmers. Was that section overwhelming
> as well ?

It was originally, but after your message, it's much more clear.  There's not
nearly as much to learn as it originally looked like.

> In any case, I may need to split this man page... What do you think ?

No, I don't think that's necessary anymore.  Maybe a few more words of
description, and some pointers to the Config::Model::Loader section.  Possible
patches are attached that use the explanations you sent me.

Ross
diff --git a/lib/App/Cme/Command/update.pm b/lib/App/Cme/Command/update.pm
index b4a36ea..997cc3d 100644
--- a/lib/App/Cme/Command/update.pm
+++ b/lib/App/Cme/Command/update.pm
@@ -103,6 +103,13 @@ Update a configuration file. The update is done scanning external resource. For
 the update of dpkg-copyright is done by scanning the headers of source files. (Actually, only
 dpkg-copyright model currently supports updates)
 
+The data contained in debian/copyright is mapped to a tree structure inside cme. You can have
+a view of this structure by running 'cme dump dpkg-copyright' or get a graphical view with
+'cme edit dpkg-copyright'.
+
+Sometimes the output will need adjusting.  See the section "Tweak results" in
+Config::Model::Dpkg::Copyright for ways to control cme's output.
+
 Example:
 
cme update dpkg-copyright
diff --git a/lib/Config/Model/Dpkg/Copyright.pm b/lib/Config/Model/Dpkg/Copyright.pm
index 961cc360..272734c0 100644
--- a/lib/Config/Model/Dpkg/Copyright.pm
+++ b/lib/Config/Model/Dpkg/Copyright.pm
@@ -423,8 +423,14 @@ based on comments, the result is sometimes lackluster. Your may
 specify instruction to alter or set specific copyright entries in
 C file
 (or C<< debian/.fix.scanned.copyright >>).
-Each line of this file will be handled
-by L to modify copyright information.
+
+cme stores the copyright information in a tree.  Entries in
+fix.scanned.copyright provide instructions for traversing the cme tree
+and modifying entries.  You can have a view of debian/copyright file
+translated in this syntax by running 'cme dump --format cml
+dpkg-copyright'.  Each line of this file will be handled by
+L to modify copyright information; the full
+syntax is documented in the "load string syntax" section.
 
 =head2 Example
 
@@ -464,6 +470,12 @@ Here's another more complex example:
  # and modify the copyright entry with a Perl substitution
  ! Files:~/^3rdparty/ Copyright=~s/@/(at)/
 
+Sometimes, you might want to find an entry that spans multiple lines.
+You can do this by double quoting the whole value:
+
+ ! Files:"uulib/crc32.h
+ uulib/uustring.h" Copyright="2019 John Doe"
+
 =head1 Under the hood
 
 This section explains how cme merges the information from the existing

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Daniel Kahn Gillmor]

On Wed 2019-10-23 01:28:42 +0200, Thomas Schmitt wrote:
> Daniel Kahn Gillmor wrote:
>> but it's known to be relatively easy to find collisions in MD5.
>
> It is suspected that it is possible to construct byte strings which
> produce a desired particular MD5 value.

I think you're describing a preimage attack.  I was talking about a
collision attack, which is significantly easier to perform than a
preimage attack.  For MD5, it is not "suspected" to be a problem, it is
closer to "can be done in less than a second on scavenged hardware".

For more details, see https://eprint.iacr.org/2013/170.pdf

> But when matching the lines of two tables by a key you have to consider
> hash table theory and especially the birthday paradox. A short excursion
> on wikipedia lets me estimate that the chance for a MD5 collision among
> 1 billion .deb files is about 1 - e exp -1e-20.
> Regrettably i found no calculator which would not say 0 as result.

Sorry, i'm not following this argument.  We're not talking about random
chance -- we're talking about adversarial attack.

> The cryptographic check is to be done on .jigdo and .template before
> the run of jigdo-lite, and on .iso afterwards.

If "cryptographic check" means "OpenPGP signature verification" then i
agree that MD5 isn't relevant here.  But i don't think that jigdo
actually does that check, does it?

If "cryptographic check" refers to verification of the MD5sum, then it's
a mistake to use MD5 in 2019.

If the idea is that MD5 is used for speed, full SHA256 is indeed a bit
slower than MD5 ("openssl speed md5 sha256" suggests to me that SHA256
operations take roughly twice as long as MD5 operations).  But unless
you're on a blazing fast Internet connection, the delay of downloading
is likely much much larger than the computational cost of sha256.  (and
if you're on a blazing fast Internet connection, you probably don't need
jigdo anyway)

> Steve. You should now face your critics. I did what i could as lowly user
> of Debian and disorganized upstream of xorriso.

I don't think you're "lowly" at all, Thomas!  And i'm not a "critic" of
Steve's.  This discussion isn't meant to be personal in any way.

I really appreciate the work you've done (and continue to do) on
xorriso, and i appreciate the work Steve has done (and continues to do)
across the entire Debian project :)

But I'm concerned that jigdo's lack of maintenance has negative effects
on the rest of the debian ecosystem, and i'd really like to get that
cleaned up one way or another.

If there are a lot of active users of jigdo, then there needs to be
comparably active maintenance.  If there aren't a lot of users (or if
other techniques for mirroring optical media, like bittorrent, are
better-maintained), then maybe it's time to retire jigdo and let people
use their limited energies on other projects.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#942903: libbpf library is from kernel source

[Julia Kartseva]

Package: libbpf-dev
Version: 5.3.7-1
Severity: wishlist

Hi,

libbpf-dev is currently packaged from kernel sources.
Please consider switching to GH mirror [1] so there are following advantages:
- Versioning is consistent with ABI
- GH mirror has CI tests
- Be consistent w/ other distros, e.g. Fedora which has already switched
to GH mirror in [2]
The whole rationale is in [3]

Thanks!

[1] https://github.com/libbpf/libbpf
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1745478
[3] https://lore.kernel.org/netdev/3fbec3f8-5c3c-40f9-af6e-c355d8f62...@fb.com/

Bug#926896: sysvinit-utils: pidof is unreliable

[Hoyer, David]

We have also been experiencing this problem since moving to Buster.   We never 
saw this with Jessie.   I believe it comes down to the following code in 
readproc:

if ( (strchr(process_status, 'D') != NULL) ||
 (strchr(process_status, 'Z') != NULL) ){
   /* Ignore zombie processes or processes in
  disk sleep, as attempts
  to access the stats of these will
  sometimes fail. */
  if (p->argv0) free(p->argv0);
  if (p->argv1) free(p->argv1);
  if (p->statname) free(p->statname);
 free(p);
 continue;
}

Our scenario is similar although not with the same process that is described 
below.It seems like this makes pidof not as effective for finding the pid 
of a process if D states are skipped.   Are there alternatives to pidof?   (BTW 
the -z option does not appear to help since this code snippet will remove it 
from the process list).

-Original Message-
From: Thorsten Glaser  
Sent: Tuesday, October 22, 2019 6:26 PM
To: jsm...@resonatingmedia.com; 926...@bugs.debian.org
Subject: Bug#926896: sysvinit-utils: pidof is unreliable

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




On Tue, 22 Oct 2019, Jesse Smith wrote:

> >any ideas how it could be possible for process to be discovered by
> >ps(1), but not pidof(1)?

> I can think of a few possibilities, though they seem unlikely. One is 
> that the process could be crashing and restarting, making it a zombie

or in D state, doing disc I/O… more likely even.

> for brief periods of time. Testing pidof with the "-z" flag would fill 
> in the "holes" in the test output if that theory is correct.

Also: start-stop-daemon --status should probably be used ipv pidof.

(Even its manpage says so.)

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID 
(VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

--
To unsubscribe, send mail to 926896-unsubscr...@bugs.debian.org.

Bug#942902: gwyddion: Depends on pygtk

[Jeremy Bicha]

Source: gwyddion
Version: 2.52-1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid bullseye

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

As part of the Python2 removal, it is our intent that pygtk will be
removed from Testing before the release of Debian 11
"Bullseye". Therefore, I am bumping the severity of this bug to
Serious to ensure that there is plenty of warning before
the Debian 11 release and to make the eventual removal of pygtk as
smooth as possible.

If you have any questions don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#931540:

[Michael Hudson-Doyle]

This bug seems to be fixed, in as much as 0.9.0 has been in unstable for a
while. However, I think python 3.8 is going to require 0.10.1, as only
numpy 1.17 is compatible with 3.8 and statsmodel 0.10.1 is the first
release to support numpy 1.17 (as I read things anyway)

Bug#942901: torbrowser-launcher: Tor Browser 9.0 shows only black screens due to no write access to /dev/shm/org.mozilla.ipc.*.*

[Paul Wise]

Package: torbrowser-launcher
Version: 0.3.2-2
Severity: serious

Tor Browser 9.0 shows only black screens because the default apparmor
profile does not allow write access to /dev/shm/org.mozilla.ipc.*.*
like it does for /dev/shm/org.chromium.* and I was able to fix this
issue by adding this workaround:

==> /etc/apparmor.d/local/torbrowser.Browser.firefox <==
owner /{dev,run}/shm/org.mozilla.*.* rw,

Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.416:1642): 
apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" 
name="/dev/shm/org.mozilla.ipc.1935.0" pid=1935 comm="firefox.real" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.432:1643): 
apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" 
name="/dev/shm/org.mozilla.ipc.1935.1" pid=1935 comm="firefox.real" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.588:1644): 
apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" 
name="/dev/shm/org.mozilla.ipc.1935.2" pid=1935 comm="firefox.real" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.596:1645): 
apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" 
name="/dev/shm/org.mozilla.ipc.1935.3" pid=1935 comm="firefox.real" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.600:1646): 
apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" 
name="/dev/shm/org.mozilla.ipc.1935.4" pid=1935 comm="firefox.real" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.816:1647): 
apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" 
name="/dev/shm/org.mozilla.ipc.1935.5" pid=1935 comm="firefox.real" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Oct 23 09:32:01 kernel: audit: type=1400 audit(1571794321.296:1648): 
apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" 
name="/dev/shm/org.mozilla.ipc.1935.6" pid=1935 comm="firefox.real" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Oct 23 09:32:01 kernel: audit: type=1400 audit(1571794321.668:1649): 
apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" 
name="/dev/shm/org.mozilla.ipc.1935.7" pid=1935 comm="firefox.real" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

-- 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.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 torbrowser-launcher depends on:
ii  ca-certificates   20190110
ii  libdbus-glib-1-2  0.110-4
ii  python3   3.7.5-1
ii  python3-gpg   1.13.1-1
ii  python3-pyqt5 5.12.3+dfsg-2
ii  python3-requests  2.21.0-1
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.4.1.6-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.3-5+b1

-- Configuration Files:
/etc/apparmor.d/local/torbrowser.Browser.firefox changed:
owner /{dev,run}/shm/org.mozilla.* rw,

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#942900: python3-pluggy Depends: python3-importlib-metadata

[Drew Parsons]

Package: python3-pluggy
Version: 0.13.0-1
Severity: normal
Control: affects -1 python3-fiat

pluggy does import importlib_metadata, at least with python3.7

python3-pluggy should therefore Depends: python3-importlib-metadata

The bug can be seen in fiat tests,
https://ci.debian.net/data/autopkgtest/unstable/amd64/f/fiat/3230794/log.gz

autopkgtest [22:25:59]: test test-fiat:  - - - - - - - - - - stderr - - - - - - 
- - - -
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/pytest.py", line 8, in 
from _pytest.assertion import register_assert_rewrite
  File "/usr/lib/python3/dist-packages/_pytest/assertion/__init__.py", line 13, 
in 
from _pytest.assertion import rewrite
  File "/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py", line 24, 
in 
from _pytest.assertion import util
  File "/usr/lib/python3/dist-packages/_pytest/assertion/util.py", line 11, in 

import _pytest._code
  File "/usr/lib/python3/dist-packages/_pytest/_code/__init__.py", line 7, in 

from .code import Code  # noqa
  File "/usr/lib/python3/dist-packages/_pytest/_code/code.py", line 15, in 

import pluggy
  File "/usr/lib/python3/dist-packages/pluggy/__init__.py", line 16, in 
from .manager import PluginManager, PluginValidationError
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 11, in 
import importlib_metadata
ModuleNotFoundError: No module named 'importlib_metadata'


-- 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.3.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pluggy depends on:
ii  python3  3.7.5-1

python3-pluggy recommends no packages.

python3-pluggy suggests no packages.

-- no debconf information

Bug#942323: runit-helper: Use dot-symlinks to mark a service as disable

[Dmitry Bogatov]

[2019-10-22 01:43] Lorenz 
> > Sorry, don't follow. Previously no link in /etc/service was created
> > if dh-runit decides that service should not be enabled, now hidden
> > link is created instead. How it is more confusing?
>
> OK, from existing users there are no visible consequences and a bug is
> fixed.  I just meant that probably should be documented somewhere that
> runit uses .simlink to mark a service as disabled.

No doubt, documentation would be good.

I think the most apporiate medium would be introduction of README in
bin:runit and short entry in debian/NEWS, like sysvinit does it.

> > What buggy behaviour will this change cause for git-run users?
>
> git-daemon-run use 'update-service --remove' in its maint scripts, so
> after #942320 patch is applied, it will set git daemon as disabled on
> remove (as it was a user choice) and it will delete the setting on
> install.

As I remember, git still provides runscript in separate package and does
not use dh-runit. How complicated would it be to create patch for
src:git that would at least prevented regression due hidden link change?

Also, see comments on #942320.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#942320: update-service: use .symlink to mark a service as disabled

[Dmitry Bogatov]

[2019-10-14 16:40] Lorenzo Puliti 
> Hi,

Hi!

> this is to be consistent with a patch that I'm about to send
> for dh-runit.
> The attached patch here makes update-service create a .symlink
> rather than just removing the symlink to disable a service.
> This will help in preserving local admin choice to keep a service disabled.
> I've added some detail in the man page but I hope to provide some more
> detailed info in update-rc.d man page as runit support is merged there.

Looks good to me, but does not apply:

>  ln -s /var/lib/runit/log/supervise/"$sv" "$svdir"/log/supervise
 this line of context
>fi
>  fi
> +if [ -d "$servicedir"/."$sv" ]; then
> +rm "$servicedir"/."$sv"
> +fi

is nowhere to be found in "debian/contrib/update-service". I am looking
at commit [dae57fa82797b673ca9116a81048dedd5ab523db]. I guess you based
this your patch on pre-5d98b parent.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#885265: Bug#936299: chirp: Python2 removal in sid/bullseye

[Jeremy Bicha]

Please CC me on replies to the bug since it's not particularly easy
for me to subscribe to all of these emails.

Personally, I think porting away from pygtk (to GTK3 and GObject
Introspection) is more urgent than porting to python3, but yes you'll
ultimately need to do both.

Thanks,
Jeremy Bicha

Bug#938837: xapp: Python2 removal in sid/bullseye

[Norbert Preining]

Hi Nicolas,

On Tue, 22 Oct 2019, Nicolas Braud-Santoni wrote:
> How did you get rid of the B-D on Py2, given that python-gi-dev itself Depends
> on it?

Ok, the *indirect* B-D I cannot get rid off, but building the py2
version we did as follows:
--- xapp.git.orig/pygobject/meson.build
+++ xapp.git/pygobject/meson.build
@@ -3,7 +3,7 @@ pygobject = dependency('pygobject-3.0',
 required: true,
 )

-foreach exec : ['python2', 'python3']
+foreach exec : ['python3']
 r = run_command(exec, '-c', 'import gi;print(gi._overridesdir)')

 if r.returncode() == 0

That means as soon as python-gi-dev stops depending on py2, we don't
need it anymore.

Best

Norbert

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

Bug#942899: joblib 0.14.0 is required for Python 3.8 support

[Michael Hudson-Doyle]

Source: joblib
Version: 0.13.0-2
Severity: important

Dear Maintainer,

joblib 0.13.0 does not support Python 3.8. 0.14.0 does and builds fine
but for one wrinkle: some tests import threadpoolctl which is not (yet?)
packaged. For Ubuntu I just patched things to skip those tests.

Cheers,
mwh

-- System Information:
Debian Release: buster/sid
  APT prefers eoan
  APT policy: (500, 'eoan'), (400, 'eoan-proposed')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-18-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- a/joblib/test/test_parallel.py
+++ b/joblib/test/test_parallel.py
@@ -1646,8 +1646,8 @@
 
 @with_numpy
 @with_multiprocessing
-@skipif(sys.version_info < (3, 5),
-reason='threadpoolctl is a python3.5+ package')
+@skipif(True,
+reason='threadpoolctl is not yet packaged')
 @parametrize('n_jobs', [2, 4, -2, -1])
 def test_threadpool_limitation_in_child(n_jobs):
 # Check that the protection against oversubscription in workers is working
@@ -1670,8 +1670,8 @@
 
 @with_numpy
 @with_multiprocessing
-@skipif(sys.version_info < (3, 5),
-reason='threadpoolctl is a python3.5+ package')
+@skipif(True,
+reason='threadpoolctl is not yet packaged')
 @parametrize('inner_max_num_threads', [1, 2, 4, None])
 @parametrize('n_jobs', [2, -1])
 def test_threadpool_limitation_in_child_context(n_jobs, inner_max_num_threads):

Bug#942898: debcargo: reduce the impact of debcargo-built crates on the package index, and facilitate debian packaging of crates

[Daniel Kahn Gillmor]

Package: debcargo
Version: 2.4.0-1
Control: affects -1 ftp.debian.org

Hi!  I'm trying to summarize in this report the state of conversation i
had today between members of the FTP team (and others on #debian-ftp)
and members the debian Rust packaging team.

We seem to be in a bit of an impasse, and i'm hoping that we can use
this report to find a concrete way out of the impasse.  This report
explains my understanding of the problem and proposes one way forward.
I'd be very happy for constructive engagement with this report.  If you
think i'm wrong, help explain what would be better, or why my proposed
changes aren't acceptable.


Background
--

debcargo creates .deb packages corresponding to Rust crates.  I'm going
to focus here on the librust-* .deb binary packages, and ignore the
packages that ship tools that have, for example, a command-line
interface.

Each source package corresponds to a Rust crate, but it might produce
multiple librust-* binary packages -- one for each crate "flavor".

the librust-*.deb files contain mainly a distribution of .rs source
code in /usr/share/cargo/registry/…

Most of the "+flavor" .debs basically have an additional source
dependency on some other rust crate, and also ship a symlink back to the
folder of .rs source code from the standard (non "+flavor") .deb.

For each binary package shipped, it also defines a list of Provides:
that include version numbers in the name.



Problem Statement(s)


From talking with the FTP team, the concern appears to be that the large
number of packages, and the large number of Provides produced for some
of the packages is seen as a potential problem for the apt Packages
index.

In particular, a larger Packages index:

 * increases the cost of data transfer for every debian system that does
   updates

 * means that apt has to do more complicated dependency resolution

I have not yet gotten measurements of what kinds of costs we're talking
about with respect to this shared resource.  If someone could provide
some numbers and a methodology for getting them, that would be useful in
figuring out whether any proposed change contributes a substantial
solution to the problem.  Kinds of measurements that might make the
risks a bit clearer for leaning on this shared resource too heavily:

 - size of Packages file
 - RAM needed by aptitude to ingest the Packages file
 - CPU time taken by aptitude to do dependency resolution



Additionally, from the Rust team's perspective, when a crate upstream
proposes a feature, this creates a new binary .deb, which triggers
inclusion in the NEW queue.  The delay in the NEW queue causes friction
which makes packaging Rust-related projects harder to do.

I've experienced this myself, where i spend about an hour or two on rust
packaging, and then find myself waiting for weeks before i can do the
next hour of work -- this isn't conducive to effective maintenance.



Proposed Solutions
--

AIUI, the FTP team thinks that debcargo could reduce the impact on the
shared resource of the Packages index by adopting one or both of the
tactics described below:

 0) reduce the number of "+feature" .debs produced by each crate,
perhaps by creating two base .debs for each package: one with no
"features" and one that bundles together all of the features that
are not mutually-exclusive.  Any features that are mutually
exclusive would still get their own separate "+feature" .deb.

 1) drop version numbering from the Provides: entries for standard
packages -- this should reduce the number of Provides: by a
substantial fraction.  Given that crates are expected to hew to
semantic versioning, a generated version number range should be
sufficient to declare an API-compatible version dependency.



Concerns


A concern I've heard about tactic (0) is that this approach might result
in dependency loops, as in:

https://github.com/sfackler/cargo-tree/issues/34#issuecomment-394266843

It's conceivable that apt could figure out how to deal with those loops,
and given that these librust-*-dev .debs are basically just sourcecode,
these loops will only affect Rust developers (who might be expected to
have beefier machines than regular end users).

Such a change would also reduce the number of packages


A concern i've heard about tactic (1) is that it makes it harder to ship
a two versions of a crate in a given debian distro.  For example, we
might want to ship librust-foo-dev version 1.x alongside librust-foo-dev
version 2.x.  If they have the same package name (librust-foo-dev) then
they can't both be in the archive at once.

We currently do ship librust-foo-dev (meaning "the latest version"), and
we create a new package librust-foo-1-dev for when we intend to maintain
a stable API for an older release.  I don't think anyone wants that to
change (many C library packages use the same pattern based on their
SONAMEs).

The use of Provides: makes it so that a 

Bug#942275: libmoox-options-perl: test failure

[Jonas Smedegaard]

Quoting intrigeri (2019-10-14 11:29:02)
> Control: retitle -1 libmoox-options-perl: test regression with 
> librole-tiny-perl 2.001003-1
> Control: forwarded -1 https://github.com/celogeek/MooX-Options/pull/69
> 
> Hi again,
> 
> intrigeri:
> >> Maybe yesterday's upload of libnamespace-autoclean-perl?
> 
> > Hmm, AFAICT libmoox-options-perl does not depend (even transitively)
> > on libnamespace-autoclean-perl, so I have a doubt. But who knows :)
> 
> The test suite still passes after upgrading
> libnamespace-autoclean-perl, but it starts failing once I upgrade
> librole-tiny-perl from 2.001001-1 to 2.001003-1 (both with
> libnamespace-autoclean-perl 0.28-1 and 0.29-1, so that one is
> definitely not the culprit).
> 
> I've implemented a workaround, sent it in a RFC PR upstream, and I'll
> apply it to our package now in order to mitigate a bit the impact of
> this bug. But I'm not convinced at all that it's the correct place to
> fix this: I suspect this problem is merely a symptom of a regression
> in librole-tiny-perl, but the codebase of that one is far outside of
> my comfort zone.
> 
> In passing, I see that this newer librole-tiny-perl also breaks the
> test suite of libattean-perl:
> https://ci.debian.net/data/autopkgtest/testing/amd64/liba/libattean-perl/3157349/log.gz
> But that seems to be another problem and I did not dive into it.

Seems there's now a fix for Attean upstream which might be enlightening 
for how to address same/similar issue in other modules: 
https://github.com/kasei/attean/pull/142

>From that fix:

> Moo::Role and Role::Tiny shouldn't be 'use'd in the same package.
>
> Moo::Roles shouldn't be applied using Role::Tiny.
>
> Role::Tiny should be loaded explicitly in the locations using its
> subs/methods directly.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#942897: antennavis: Outdated documentation references for nec2

[Reynaldo H. Verdejo Pinochet]

Package: antennavis
Version: 0.3.1-4+b1
Severity: minor

Dear Maintainer,

The documentation at /usr/share/doc/antennavis/README references no longer 
available nec2 binary sources:

>> In case you can't meet these requirements, you can download a
>> statically linked nec2 version from:
>> http://www.qsl.net/pg4i/download/nec2bin-11.tar.gz
>> or: http://pg4i.mattsnetwork.co.uk/download/nec2bin-11.tar.gz


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

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

Versions of packages antennavis depends on:
ii  dpkg1.19.7
ii  libc6   2.29-2
ii  libgl1  1.1.0-1+b1
ii  libgl1-mesa-glx 19.2.1-1
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libtcl8.6   8.6.9+dfsg-2+b1
ii  libtk8.68.6.9-2+b1
ii  libx11-62:1.6.8-1
ii  libxmu6 2:1.1.2-2+b3

Versions of packages antennavis recommends:
pn  nec  

antennavis suggests no packages.

-- no debconf information

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Thomas Schmitt]

Hi,

Antoine Beaupré wrote:
> I mean "broken" as in "DVD as are not available as normal ISOs over HTTP
> or bittorrent but only jigdo".

Afaik, that's because jigdo uses the package mirror servers as source of
the bulk of its downloads. Those servers experience the same as with a
generously sized installation of a Debian system.


> jigdo is the reason MD5sums are still in the Packages files, according
> to ftp-masters. It's not a theory I just came up with just for kicks.

I really wonder where this dependency should come from. Is there any
public background info to motivate this claim ?

... one only needs to wish:
Ansgar  writes in 942...@bugs.debian.org and on
debian...@lists.debian.org:
> From looking, I believe it is debian-cd's tools/grab_md5 that is using
> the MD5sum from Packages (and Sources) to avoid having to compute all
> these checksums itself.

So it's about lazyness of debian-cd. That's an implementation detail.
One should probably talk to Steve McIntyre directly.

> - writing MD5sum in a separate file only used by debian-cd

Why that ? debian-cd has copies of the .deb files to pack them up in the
ISO. There is no jigdo production without seeing the packages.
md5sum is not really slow, nowadays.

>  - using a (truncated) sha256sum; this requires that the jigdo client
>   only uses the "md5sum" as an opaque identifier for a file.

It is used as opaque identifier, but this identifier is at some occasions
also interpreted as MD5 which has to match the package file.


Antoine Beaupré wrote:
> In my experience, jigdo never worked,

I tested the whole procedure shown in
  https://wiki.debian.org/JigdoOnLive
with the non-standard situation to have an old Desktop with the filesystem
of an inconscious Debian 6 host of the Debian Live system.

Since i assume that you have a Debian system running, be invited to
join in at

  
https://wiki.debian.org/JigdoOnLive#If_needed.2C_work_around_a_shortcoming_of_older_jigdo-lite

in order to download e.g.
  
https://cdimage.debian.org/cdimage/release/current/amd64/jigdo-dvd/debian-10.1.0-amd64-DVD-4.jigdo
  
https://cdimage.debian.org/cdimage/release/current/amd64/jigdo-dvd/debian-10.1.0-amd64-DVD-4.template

Verify them properly and run jigdo-lite with URL
  
https://cdimage.debian.org/cdimage/release/current/amd64/jigdo-dvd/debian-10.1.0-amd64-DVD-4.jigdo

Finally verify the emerged debian-10.1.0-amd64-DVD-4.iso by the proposed
means.


> The CMU Software Engineering Institute considers MD5 essentially
> "cryptographically broken and unsuitable for further use"

Yes. But jigdo-lite does not use MD5 for cryptographical purposes except
for an initial check of .template and a final check of .iso.
Both are outdated. But both get re-assured by GPG and SHA512 if you
follow the procedure which is outlined above.


> The problem is *every* bug report (e.g. #772110) that tries to document
> serious issues about jigdo *all* get downgraded to "normal", saying
> "this is not a problem".

But the diagnosis by Steve McIntyre tells why:
> > Sorry, but this bug is hardly grave. Important, maybe... jigdo-lite
> > works most of the time for most people.

jigdo-lite even noticed the problem before the overall check of the .iso
could be run to finally report a damaged ISO, too.

Now what would you do if a directly downloaded ISO turns out to be
damaged ? I'd advise download from a different source. In case of jigdo
this is mainly a different package mirror.


Daniel Kahn Gillmor wrote:
> I'm unaware of the meaning of "cross-table key matching",

You have one table with keys and values and another table with keys and
values. Lines in both tables, where the keys are the same, are considered
to be in relation. Like in a data base.


> but it's known to be relatively easy to find collisions in MD5.

It is suspected that it is possible to construct byte strings which
produce a desired particular MD5 value.
But when matching the lines of two tables by a key you have to consider
hash table theory and especially the birthday paradox. A short excursion
on wikipedia lets me estimate that the chance for a MD5 collision among
1 billion .deb files is about 1 - e exp -1e-20.
Regrettably i found no calculator which would not say 0 as result.


> If the adversary can convince any DD to upload an obviously harmless
> package of the adversary's choice into the archive, then the adversary
> can also craft another package with a matching MD5sum.

The cryptographic check is to be done on .jigdo and .template before
the run of jigdo-lite, and on .iso afterwards.

What is a security risk is that you need much contact with debian-cd and
its environment in order to know how to do it. The info is scattered on
the Debian web appearance.


> You probably don't mean it this way, but this sounds it will make what
> should be the software author's problem into the user's problem.
> [...]
> Thanks for your attention to (and efforts on behalf of) jigdo,

Steve. You should now face your critics. I did what i 

Bug#926896: sysvinit-utils: pidof is unreliable

[Thorsten Glaser]

On Tue, 22 Oct 2019, Jesse Smith wrote:

> >any ideas how it could be possible for process to be discovered by
> >ps(1), but not pidof(1)?

> I can think of a few possibilities, though they seem unlikely. One is
> that the process could be crashing and restarting, making it a zombie

or in D state, doing disc I/O… more likely even.

> for brief periods of time. Testing pidof with the "-z" flag would fill
> in the "holes" in the test output if that theory is correct.

Also: start-stop-daemon --status should probably be used ipv pidof.

(Even its manpage says so.)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Antoine Beaupré]

On 2019-10-22 23:10:19, Julien Cristau wrote:
> Control: severity -1 normal
>
> On Tue, Oct 22, 2019 at 03:29:54PM -0400, Antoine Beaupré wrote:
>> Control: severity 887831 grave
>> 
> That is entirely unjustified afaict, and doesn't help your case.

I would have thought I made a pretty explicit justification, while you
just said "entirely unjustified" without any sort of explanation. Not
sure I understand what case you're bringing forward.

I guess I should be thankful: without your intervention, I might have
considered continuing to monitor that bug report and maybe get involved
in trying to fix that problem in the long run, across the project. But
now you're destroyed the last shred of motivation I had to ever work
again on jigdo.

So thanks, in a bizarre, unfortunately-so-typical-in-Debian, way.

A.

-- 
No animal has more liberty than the cat; but it buries the mess it
makes. The cat is the best anarchist. Until they learn that from the cat
I cannot respect them.
- For whom the bell tolls, Ernest Hemingway

Bug#926896: sysvinit-utils: pidof is unreliable

[Jesse Smith]

> Jesse,
>any ideas how it could be possible for process to be discovered by
>ps(1), but not pidof(1)?
>

I can think of a few possibilities, though they seem unlikely. One is
that the process could be crashing and restarting, making it a zombie
for brief periods of time. Testing pidof with the "-z" flag would fill
in the "holes" in the test output if that theory is correct.

Alternatively, if the executable is on a remote network share, like NFS,
that might explain the gaps.

While it doesn't explain the gaps in output, I am curious if the gaps
also appear if the pidof test is run without the "-s" flag. So instead
of "pidof -s apcupsd" what happens if you run "pidof -z apcupsd"?

- Jesse

Bug#942881: Confirming bug on Dell XPS 13 9360R

[Wilhelm Westermark]

Can confirm that this bug affects more people. Same symptoms and same 
message in syslog


Platform: Dell XPS 13 9360R running the same kernel

Can be reverted by shutting down and booting in to an older kernel 
(5.2.17-1+b1)

Bug#937926: python-pbr has been removed

[Daniel Schepler]

severity 937926 serious
thanks

The latest upload of src:python-pbr has now removed the python[2]-pbr
binary package, thus making the build dependencies of src:python-mock
uninstallable, and raising the urgency of dropping that build
dependency.  (Unless you install an older binary package of python-pbr
from the archive; but in any case, either this will block python-pbr
from migrating to testing, or else in testing the source package for
python-mock will be truly unbuildable.)
-- 
Daniel Schepler

Bug#942875: debootstrap does not overwrite existing files even if adviced to do

[Holger Levsen]

severity 942875 normal
# thanks

Hi,

thanks for reporting this bug. however...

> I suppose this a bug, since debootstrap did warn before it would
> overwrite files!
 
yes, it's a bug. but not even important one according to
https://www.debian.org/Bugs/Developer#severities


-- 
cheers,
Holger

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



signature.asc
Description: PGP signature

Bug#932971: ITP: squashfs-tools-ng -- A new set of tools for working with SquashFS images

[Johannes Schauer]

Hi László,

Quoting László Böszörményi (GCS) (2019-10-22 21:15:19)
> On Wed, Oct 16, 2019 at 9:45 PM Johannes Schauer  wrote:
> > On Thu, 25 Jul 2019 11:51:00 +0200 László Böszörményi (GCS) 
> >  wrote:
> > > * Package name: squashfs-tools-ng
> > I see the package is still waiting in NEW.
> >
> > Where did you put the packaging VCS? I'd like to play around with it before 
> > ftp
> > master manages to approve it. :)
>  You can get the updated, 0.7-1 release[1],

thanks!

> but please note that its
> self-testing is constantly failing:
> FAIL: test_fstree_init
> ==
> 
> test_fstree_init: tests/fstree_init.c:32: main: Assertion
> `fs.defaults.st_mtime == 0' failed.
> FAIL test_fstree_init (exit status: 134)
> 
> Can you check it David? I've tried it on three machines. Two of these
> are running on amd64 and one is on i386 architecture.

I can confirm that this test fails also over here.

You might also want to update your packaging a bit. I get rather problematic
Lintian warnings and errors here:

W: squashfs-tools-ng: package-name-doesnt-match-sonames libsquashfs0
E: squashfs-tools-ng: non-empty-dependency_libs-in-la-file 
usr/lib/x86_64-linux-gnu/libsquashfs.la
W: squashfs-tools-ng: non-dev-pkg-with-shlib-symlink 
usr/lib/x86_64-linux-gnu/libsquashfs.so.0.0.0 
usr/lib/x86_64-linux-gnu/libsquashfs.so

And sometimes ftp-master will not accept a package with Lintian errors.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#926896: sysvinit-utils: pidof is unreliable

[Dmitry Bogatov]

control: tags -1 +help

[ Adding to thread "apcupsd" Debian maintainer and "pidof" upstream
  maintainer. ]

[2019-10-21 14:27] Martin von Wittich 
> Am 20.10.19 um 20:59 schrieb Dmitry Bogatov:
> > 
> > That sounds explainable. pidof() scans /proc directory, and it takes some
> > time for kernel to create entry there.
> [...]
> Even if there were, that wouldn't explain how ps is able to see the 
> process, while pidof is not. As far as I know, ps also gets this 
> information from /proc.

True.

> To verify my assumptions, I've adapted my test script as follows:

I adjusted script slightly (added -d option to first ls and replaced
"systectl" with "/etc/init.d" like following:

#!/bin/bash

set -eu
/etc/init.d/apcupsd restart
START=$SECONDS

ps -f -C apcupsd
PID="$(ps -o pid -C apcupsd --noheaders)"
ls -d /proc/"$PID"

while true
do
   echo -n "pidof: "
   pidof -s apcupsd || echo
   echo -n "ls: "
   ls -d /proc/"$PID"
   [ $((SECONDS - START)) -ge 2 ] && break
   sleep 0.01
done
ps -f -C apcupsd

> So the /proc/26476 is there even when pidof doesn't see the process.
> >> But there are almost always holes in the output further on, so it's
> >> also slightly unreliabl afterwards.

and wasn't able to reproduce holes in the middle, but I did observed hole
at the beginning:

Stopping UPS power management: apcupsd.
Starting UPS power management: apcupsd.
UIDPID  PPID  C STIME TTY  TIME CMD
root 24352 1  0 22:51 ?00:00:00 /sbin/apcupsd
/proc/24352
pidof: 
ls: /proc/24352
pidof: 24352
[... all below is as expected ...]

Hole in beginning happened reproducibly, 100% of time.

> I had assumed that the problem should be easily reproducible with any
> other recently-started process, but that is apparently not the case:
> [...]
>
> Maybe systemd is somehow involved?

I tried to replace apcupsd with another servers on my box (tor,
apt-cacher-ng), but no holes happened with them.

I can't exclude that systemd is somehow related to holes in the middle
you observe, but hole in beginning is mysterious enough. Personally, I
am out of ideas: as far as I know (and I just web-searched), there is
only one way to get list of processes: scan /proc.

Jesse,
   any ideas how it could be possible for process to be discovered by
   ps(1), but not pidof(1)?

Dear apcupsd maintainer,
any suggestions how "apcupsd" server process could be special, that
it is not discovered by pidof(1) for some time after restart and,
reportedly, even once in a while server is running?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")

[Tomas Janousek]

Hi,

On Tue, Oct 22, 2019 at 09:47:32PM +0300, Josh Triplett wrote:
> After upgrading to linux-image-5.3.0-1-amd64, I get messages like those
> seen in the log ("No response from codec, resetting bus" and "Unable to
> sync register"), and eventually a WARN. The mixer doesn't show the audio
> device at all.
> 
> This didn't happen with the previous kernel, namely:
> Oct 21 21:04:28 s kernel: Linux version 5.2.0-3-amd64 
> (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-23)) #1 SMP 
> Debian 5.2.17-1 (2019-10-06)

I can confirm the same behaviour with ThinkPad T25.

There seems to be a workaround:

options snd_hda_intel probe_mask=1

I'm not getting errors with this and audio works. I have a feeling that HDMI
audio will not work, however, because there's no "input: HDA Intel PCH HDMI"
in dmesg any more. :-(

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/

Bug#942883: closed by Alf Gaida (Re: libqt5xdgiconloader3: Dependency upon qtbase-abi-5-11-3 prevents installation)

[Alf Gaida]

On Tue, 22 Oct 2019 13:58:13 -0700 Felicia P wrote:
> Thank you for the transition information


Hi,

when running sid the transition tracker is the best friend one can have.
Second best friend is apt - i might sound old fashioned, but GUI tools
don't give so much hints about not wanted package removals or reasons
for not installing certain packages - so in case apt want to remove x
packages - just hit  and find out the reason - on my work horse
currently 106 packages are to be removed :D - the key word is patience.
And while waiting one can use the time to gather some additional
knowledge. (I learned it the very hard way years ago :P)


Cheers Alf

Bug#887837: jigdo-lite: Final statement about verified ISO is too affirmative

[Daniel Kahn Gillmor]

On Sat 2018-01-20 14:10:28 +0100, Thomas Schmitt wrote:
> as described in
>   https://lists.debian.org/debian-cd/2018/01/msg00021.html
> jigdo-file verifies the .template file and the resulting ISO image only
> by MD5 checksums which stem from the .jigdo or from the .template file.
> The .jigdo file is not verified at all.
>
> Both issues have own bug reports (#887831 and #887830). This one proposes
> a preliminary fix by simply telling the user that it's not safe yet.
>
> The final message after the MD5 check of the finished ISO image is
> overly affirmative:
>   "OK: Checksums match, image is good!"
> It stems from jigdo-file and it might be used by automated callers of
> jigdo-lite as indication of successful download.
>
> But after this message, jigdo-lite could point to the advised verification
> by GPG and a more secure checksum type like SHA512.

Please let's not ask the user to do something that the software can do
automatically for them.  If the user used jigdo, and the author(s) of
jigdo know how to do the appropriate checks, then jigdo should just do
the checks and report the result, not tell users how to do the checks
and expect them to actually follow through.  We know in practice that
won't happen.

Let's make our tools usable.

--dkg


signature.asc
Description: PGP signature

Bug#942896: tellico test rely on the network

[Matthias Klose]

Package: src:tellico
Version: 3.2.1-2
Severity: serious
Tags: sid bullseye patch


tellico access the network during the build. please don't do this.

http://launchpadlibrarian.net/374519251/tellico_3.1.2-2ubuntu4_3.1.2-2ubuntu5.diff.gz

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Daniel Kahn Gillmor]

On Tue 2019-10-22 23:03:49 +0200, Thomas Schmitt wrote:
> It does so for cross-table key matching, where MD5 suffices by all means
> of hash table theory.

I'm unaware of the meaning of "cross-table key matching", but it's known
to be relatively easy to find collisions in MD5.

If the adversary can convince any DD to upload an obviously harmless
package of the adversary's choice into the archive, then the adversary
can also craft another package with a matching MD5sum.

As a DD, i don't want my signature authorizing a specific upload to be
used to distribute some other file to our users.

> There is bug #887837 where i propose to add a reminder message at the end
> of the jigdo-lite run.

You probably don't mean it this way, but this sounds it will make what
should be the software author's problem into the user's problem.  i
think we should be more user-friendly than that.  I've followed up on
that bug report separately.

> Debian could really need a end-user comprehensable description of the
> credible verification from GPG to SHA512 to ISO. This is completely
> independent of jigdo and applies to all download methods for ISOs.

I agree that this kind of separate documentation would be great to have,
and is independent of this bug report.

Thanks for your attention to (and efforts on behalf of) jigdo,

--dkg


signature.asc
Description: PGP signature

Bug#942893: ftp.debian.org: please drop MD5sum lines from Packages

[Ansgar]

Daniel Kahn Gillmor writes:
> The Packages file is growing, and we would like to keep it smaller.
>
> The MD5sum lines are vestigial at this point.  Anything that they do
> can be done better with the data from the SHA256sum lines.

I agree it would be nice to remove MD5sum from Packages; there are a few
other fields that might also not be that useful (e.g. Maintainer).

> #887831 suggests that jigdo may currently still be broken if MD5sum
> goes away, but perhaps that's more of a reflection on the unmaintained
> state of jigdo than it is on the state of the archive.

>From looking, I believe it is debian-cd's tools/grab_md5 that is using
the MD5sum from Packages (and Sources) to avoid having to compute all
these checksums itself.

We could look into either

 - writing MD5sum in a separate file only used by debian-cd (if present,
   otherwise debian-cd should fall back to using Packages), or

 - using a (truncated) sha256sum; this requires that the jigdo client
   only uses the "md5sum" as an opaque identifier for a file.

I've CC'ed debian-cd@ for input.

Ansgar

Bug#931737: kdepim-runtime: Imap session login cancelled

[Diederik de Haas]

On woensdag 16 oktober 2019 03:54:45 CEST you wrote:
> you can change the config of OpenSSL to allow lower TLS versions to work.
> Better would be to urge that mail provider to upgrade their mail software as
> TLS < 1.2 really isn't secure.

>From https://lists.debian.org/debian-kde/2018/11/msg1.html :
Changing back the defaults in /etc/ssl/openssl.cnf to previous system wide 
defaults can be done using:
   MinProtocol = None
   CipherString = DEFAULT
It's recommended that you contact the remote site in case the defaults cause 
problems.

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

Bug#942895: CVE-2019-18224

[Moritz Muehlenhoff]

Source: libidn2
Severity: grave
Tags: security

This was assigned CVE-2019-18224: 
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12420

Patch: 
https://github.com/libidn/libidn2/commit/e4d1558aa2c1c04a05066ee8600f37603890ba8c

Cheers,
Moritz

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Antoine Beaupré]

On 2019-10-22 23:03:49, Thomas Schmitt wrote:
> Hi,
>
> Antoine Beaupré wrote:
>> Severity set to 'grave' from 'normal'
>
> This is really overdone.
>
> See jigdo as a peculiar way of downloading the ISO with a MD5 check
> where e.g. wget has none at all.
> And as said, for now jigdo seems indispensible for the fat ISO sets.
>
>
>> If the ISO image generation is broken, it should be fixed.
>
> My bug report does not say that ISO production is broken or that jigdo
> is the reason for any of the checksums in the package management.
> I doubt both theories.

I mean "broken" as in "DVD as are not available as normal ISOs over HTTP
or bittorrent but only jigdo".

jigdo is the reason MD5sums are still in the Packages files, according
to ftp-masters. It's not a theory I just came up with just for kicks.

>> In the meantime, I think it's perfectly acceptable to remove MD5sums
>> from the archive, at the cost of breaking jigdo.
>
> I agree to this plan, if you afterwards verify that debian-cd still can
> produce a pair of .jigdo and .template which jigdo-lite then can use
> to create the identical ISO by help of a package mirror.

In my experience, jigdo never worked, so I don't expect I will be able
to do this after the removal, nor before. I have long given up on doing
anything with jigdo.

[...]

>> Or, to put it another way, it's completely unacceptable that jigdo uses
>> MD5 to authenticate checksums,
>
> It does so for cross-table key matching, where MD5 suffices by all means
> of hash table theory.

To quote wikipedia:

> The CMU Software Engineering Institute considers MD5 essentially
> "cryptographically broken and unsuitable for further use"

I would consider using MD5 in any software a serious engineering
mistake, in any case. It might still be useful as a hash table
component, but I would suspect it is still a mistake.

[...]

It's really unfortunate that this bug has been downgraded. I was hoping
to take this as an opportunity to remove jigdo from our workflows, but I
guess we will need to tackle this (namely that jigdo is completely
abandoned and broken) head on, in separate bug reports.

The problem is *every* bug report (e.g. #772110) that tries to document
serious issues about jigdo *all* get downgraded to "normal", saying
"this is not a problem".

I think this is an unfair way to treat your users. Sure, it will keep
jigdo in Debian forever, but it will give a false sense of security (in
case of this bug) and reliability (in the case of #772110), which will
hurt Debian's adoption.

Is anyone still seriously thinking that jigdo is a reliable and useful
way to download Debian nowadays?

A.

-- 
A lot of people never use their initiative because no-one told them to.
- Banksy

Bug#942894: CVE-2019-15587

[Moritz Muehlenhoff]

Package: ruby-loofah
Severity: important
Tags: security

Please see https://www.openwall.com/lists/oss-security/2019/10/22/1

Cheers,
Moritz
 

Bug#942893: ftp.debian.org: please drop MD5sum lines from Packages

[Daniel Kahn Gillmor]

Package: ftp.debian.org
Severity: normal

The Packages file is growing, and we would like to keep it smaller.

The MD5sum lines are vestigial at this point.  Anything that they do
can be done better with the data from the SHA256sum lines.

Removal of the MD5sum lines would reduce the size of the gzip'ed
Packages file by ~13%, a significant win for a frequently-downloaded
file:

$ grep -v ^MD5sum < 
/var/lib/apt/lists/ftp.debian.org_debian_dists_sid_main_binary-amd64_Packages | 
gzip -9 | wc -c
9541056
0 dkg@alice:~$ cat < 
/var/lib/apt/lists/ftp.debian.org_debian_dists_sid_main_binary-amd64_Packages | 
gzip -9 | wc -c
10913735
0 dkg@alice:~$ echo $(( 100 - 100 * 9541056 / 10913735 ))
13
0 dkg@alice:~$ 

This removal was attempted once before, as documented in #818463, and
all of the subsequent blocking bugs appear to have been fixed in the
archive for several years.

#887831 suggests that jigdo may currently still be broken if MD5sum
goes away, but perhaps that's more of a reflection on the unmaintained
state of jigdo than it is on the state of the archive.

--dkg

Bug#608023: (no subject)

[Kevin Atkinson]

This should be fixed in Aspell 0.60.8 as aspell 0.60.8 increased the score of
suggestions with a ' ', '-' so they no longer appear near the start of the 
list.


The first suggestion is now 'transferred'

Bug#942892: RM: neutron-lbaas -- ROM; Deprecated, replaced by Octavia

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Dear FTP masters,

neutron-lbaas is deprecated upstream, and replaced by Octavia, which we have
in Buster already (and which I've been using in production). Therefore, we
should remove neutron-lbaas from Sid/Testing, as it's supposed to be
completely gone from this last release of OpenStack I've uploaded this week
and last week.

Cheers,

Thomas Goirand (zigo)

Bug#401120: fixed

[Kevin Atkinson]

This should be fixed in Aspell 0.60.8 as aspell 0.60.8 increased the score of 
suggestions with a ' ', '-' so they no longer appear near the start of the list.

Bug#942883: closed by Alf Gaida (Re: libqt5xdgiconloader3: Dependency upon qtbase-abi-5-11-3 prevents installation)

[Felicia P]

Thank you for the transition information


On 10/22/19 1:12 PM, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the libqt5xdgiconloader3 package:
>
> #942883: libqt5xdgiconloader3: Dependency upon qtbase-abi-5-11-3 prevents 
> installation
>
> It has been closed by Alf Gaida .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Alf Gaida 
>  by
> replying to this email.
>
>


0xCEC1B8C7E51FC983.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#942891: cracklib2: fails to build Python 3.8 extensions

[Michael Hudson-Doyle]

Source: cracklib2
Version: 2.9.6-2
Severity: important
Tags: patch

Dear Maintainer,

When Python 3.8 is supported, as in Ubuntu focal or Debian experimental,
the 3.8 extensions are not built because of this error in the configure
process:

checking for python script directory... Traceback (most recent call last):
  File "", line 20, in 
  File "/usr/lib/python3.8/sysconfig.py", line 512, in get_path
return get_paths(scheme, vars, expand)[name]
  File "/usr/lib/python3.8/sysconfig.py", line 502, in get_paths
return _expand_vars(scheme, vars)
  File "/usr/lib/python3.8/sysconfig.py", line 172, in _expand_vars
_extend_dict(vars, get_config_vars())
  File "/usr/lib/python3.8/sysconfig.py", line 550, in get_config_vars
_init_posix(_CONFIG_VARS)
  File "/usr/lib/python3.8/sysconfig.py", line 421, in _init_posix
_temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
ModuleNotFoundError: No module named '_sysconfigdata_m_linux_x86_64-linux-gnu'

Simply unsetting the _PYTHON_HOST_PLATFORM / _PYTHON_SYSCONFIGDATA_NAME
variables in debian/rules as in this patch:

http://launchpadlibrarian.net/447772089/cracklib2_2.9.6-2build1_2.9.6-2ubuntu1.diff.gz

fixes this. It seems to me that dh-python itself now does a better job
of setting these variables when needed.

Cheers,
mwh

-- System Information:
Debian Release: buster/sid
  APT prefers eoan
  APT policy: (500, 'eoan'), (400, 'eoan-proposed')
Architecture: amd64 (x86_64)

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

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Julien Cristau]

Control: severity -1 normal

On Tue, Oct 22, 2019 at 03:29:54PM -0400, Antoine Beaupré wrote:
> Control: severity 887831 grave
> 
That is entirely unjustified afaict, and doesn't help your case.

Cheers,
Julien

Bug#942069: ITP: python-opentracing

[Fabrice BAUZAC-STEHLY]

retitle 942069 ITP: python-opentracing -- Python interface to the 
OpenTracing.io API
owner 942069 !
thanks

I think I'm ready to package it.

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Thomas Schmitt]

Hi,

Antoine Beaupré wrote:
> Severity set to 'grave' from 'normal'

This is really overdone.

See jigdo as a peculiar way of downloading the ISO with a MD5 check
where e.g. wget has none at all.
And as said, for now jigdo seems indispensible for the fat ISO sets.


> If the ISO image generation is broken, it should be fixed.

My bug report does not say that ISO production is broken or that jigdo
is the reason for any of the checksums in the package management.
I doubt both theories.


> In the meantime, I think it's perfectly acceptable to remove MD5sums
> from the archive, at the cost of breaking jigdo.

I agree to this plan, if you afterwards verify that debian-cd still can
produce a pair of .jigdo and .template which jigdo-lite then can use
to create the identical ISO by help of a package mirror.

I place my bet on no problems, but i may be wrong.


> Or, to put it another way, it's completely unacceptable that jigdo uses
> MD5 to authenticate checksums,

It does so for cross-table key matching, where MD5 suffices by all means
of hash table theory.

It does so for verifying internally what can be verified externally by
the best means which Debian offers for its ISOs. I advise to do the
external check of .jigdo and .template before the run of jigdo-lite and
the external check of .iso afterwards.

There is bug #887837 where i propose to add a reminder message at the end
of the jigdo-lite run.

Debian could really need a end-user comprehensable description of the
credible verification from GPG to SHA512 to ISO. This is completely
independent of jigdo and applies to all download methods for ISOs.


Have a nice day :)

Thomas

Bug#942890: openssh-server: daemon slow to start

[Julien-Benjamin]

Package: openssh-server
Version: 1:7.9p1-10+deb10u1
Severity: normal

Dear Maintainer,

After a fresh installation of Debian Buster stable on a HP Proliant Microserver 
Gen8,
I found out that the ssh daemon was slow to start after a (re)boot.

It manifests by the fact that the connection is refused by the server.

I could take several minutes for the daemon to start and that I can connect to 
the server.

Actually, it is always the slowest process to start ; when using systemd-analyze
blame to monitor it, I discovered it was taken at least 60s.

I think it might be a problem with minimal entropy needed; indeed, when I 
connect a keyboard to
the machine and typing random characters without login in, the daemon would 
start after 10-20
characters typed.

For the record, the OS is installed on an SSD.

Regards,

JB


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libcom-err21.44.5-1+deb10u2
ii  libgssapi-krb5-2   1.17-3
ii  libkrb5-3  1.17-3
ii  libpam-modules 1.3.1-5
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux12.8-1+b1
ii  libssl1.1  1.1.1d-0+deb10u2
ii  libsystemd0241-7~deb10u1
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  openssh-client 1:7.9p1-10+deb10u1
ii  openssh-sftp-server1:7.9p1-10+deb10u1
ii  procps 2:3.3.15-2
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  241-7~deb10u1
ii  ncurses-term 6.1+20181013-2+deb10u1
ii  xauth1:1.0.10-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- debconf information excluded

Bug#909223: libwxbase3.0-0v5: crash in wxFont::Create with gnuplot-qt: corrupted double-linked list

[Olly Betts]

Control: tags -1 +unreproducible

The original report says "This is not reproducible" so tagging as such.

On Fri, Sep 21, 2018 at 01:20:37PM +0200, Vincent Lefevre wrote:
> On 2018-09-21 05:49:19 +0100, Olly Betts wrote:
> > If it's something that happens sporadically I'd suggest you try
> > habitually running gnuplot under a malloc debugger (e.g. valgrind if the
> > slowdown is tolerable), and hope that catches the corruption as it
> > happens.
> 
> I can see lots of "Conditional jump or move depends on uninitialised
> value(s)", and also:
> 
> ==32184== Invalid read of size 32
> ==32184==at 0x790FFD1: __wcsnlen_avx2 (strlen-avx2.S:62)
> ==32184==by 0x78578C1: wcsrtombs (wcsrtombs.c:104)
> ==32184==by 0x5B12FAF: wcsrtombs (wchar2.h:519)

This looks like valgrind lacking a suppression for an optimised version
of wcslen() for AVX-capable CPUs which deliberately overreads the
string.  I don't think it's connected to this bug report.

Cheers,
Olly

Bug#942889: tuxpaint: FTBFS on several architectures in experimental

[Andreas Beckmann]

Source: tuxpaint
Version: 1:0.9.24~git20190922-f7d30d-1~exp2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

tuxpaint/experimental FTBFS on several architectures where tuxpaint/sid
builds:
https://buildd.debian.org/status/package.php?p=tuxpaint=experimental

Andreas

Bug#939354: buster-pu: package capistrano/3.11.0-3+deb10u1

[Samuel Henrique]

Thanks Julien,

> Looks ok, go ahead.  It would have been helpful to note that and when
> this was fixed in sid, since there's no corresponding debian bug.

I changed d/changelog to mention that this was fixed in upstream's 3.11.1
sid and testing currently have 3.11.2, I hope that helps clear it up.

Uploaded.

capistrano_3.11.0-3+deb10u1_source.changes ACCEPTED into
proposed-updates->stable-new

--
Samuel Henrique 

Bug#906060: Coordinate overflow when rendering

[Olly Betts]

Control: tags -1 +moreinfo

On Mon, Aug 13, 2018 at 09:28:53PM +0200, Simon Richter wrote:
> This is a major showstopper for linking KiCad 5 against GTK3, so this
> requires us to keep GTK2 around longer.

The debian kicad package has now using the GTK3 flavour of wxwidgets3.0
for many months, so has this bug been solved (at least as far as kicad
and wxwidgets3.0 are concerned)?

If so, I think we can at least unassign this from wx and kicad.

If not, I'm very unclear what (as a maintainer of wxwidgets3.0) I'm
expected to do given that the problem clearly seem to lie lower down the
stack:

> Quick debugging has shown that the coordinates given to Cairo still make
> sense, even if the zoom level makes them numerically large. As I'd need
> significant time to debug into optimized drawing routines, I'd like to pass
> this on. I suspect that this is mostly an interaction between Cairo and
> Pixman, with an overflow happening somewhere in a conversion from double to
> an integer type.

Cheers,
Olly

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Thomas Schmitt]

Hi,

Daniel Kahn Gillmor wrote:
> If jigdo would use the SHA256sum entries instead of the MD5 entries when
> it is doing ISO assembly, then everyone could still fetch full DVD sets
> or BD sized installation ISOs

I am kindof the second-last jigdo export, but not at all with .deb
entrails.
Are you sure that Debian package management is involved other than
maybe with generating the input file for xorrisofs option -md5-list ?

In the .jigdo file, which controls the package download operations
of jigdo-lite, the MD5 is a key which connects the package file path
with a matchable descriptor entry in the .template file bearing the
same MD5.
A gunzipped .jigdo file bears for example
  
FexKzYyIVG2rRb1UjUKj8Q=Debian:pool/contrib/b/biomaj-watcher/biomaj-watcher_1.2.2-4_all.deb
which is the MD5 as base64, "=Debian:" representing the individual part
of the mirror URL chosen at download time, and "pool/.../...deb" to depict
the invariant package path part on the mirror server.
The matching descriptor entry in .template bears the same MD5 and by
its position marks the place where to patch the .deb file into the .iso.

Maybe Steve McIntyre can say more about how the -md5-list file gets created
before xorrisofs is run.


> AFAICT, jigdo's last maintenance release (debian version) was nearly two
> years ago.

Steve seems busy with other stuff.


> The last upsteam release (0.7.3) was produced in 2006.

This one is dead. At that time, the .jigdo and .template files were
generated from existing .iso images by matching the submitted MD5 list
against block sequences in the ISO.
Steve then taught genisoimage how to produce .jigdo and .template on
the fly while producing the .iso image.
Before xorriso could take over the job, George Danchev and i extracted
Steve's jigdo code into a library named libjte which is then used by
xorriso to produce the desired companion files of the .iso.

For restoring .iso from jigdo, only jigdo-lite from package jigdo-file
is left. Because there is no supported tool for Mac or MS-Windows,
i began to describe a jigdo download procedure via a Debian Live ISO:
  https://wiki.debian.org/JigdoOnLive

Main open questions are about how to get a Debian Live connected to the
internet if there is non-free firmware needed, and how to access the
foreign OS'es filesystems for writing the .jigdo, .template, and .iso
files. (I am neither sysadmin nor MS/Mac user.)


> Do you have any suggestions to offer to make jigdo work using a modern
> cryptographic digest?

We would have to team up with Steve to fix the remaining moderate
security concerns about the jigdo download process.

There are no security concerns about the matching of .template block
ranges with package paths, because no man-in-the-middle can alter
this mapping, once .jigdo and .template files are verified.
MD5 with its 128 bits should be very safe against false identifications
if the file count in a .jigdo file stays well below 2 exp 30.

The resolution of bug #887830 fixed the most dangerous security gap of
using a totally untrusted .jigdo file and a then only MD5-checked
.template file. A cautious user can now verify both files before running
jigdo-lite. (jigdo-lite will not download again if it finds the files
already in the current work directory.)

This bug here, #887831, only tries to bring the internal checks of
jigdo-lite on the downloaded .template and resulting .iso to the security
standard which is recommended but not enforced for download of .jigdo
or direct download of .iso.

Steve once announced to publish a straightforward instruction of the
verification steps from SHA512SUMS.sign, to SHA512SUMS and then to
possibly .jigdo and always .iso.
I hope he still knows where the draft for this is ... :))


Have a nice day :)

Thomas

Bug#941093: ping!

[Paul Gevers]

Hi Dmitry,

On 22-10-2019 22:19, Dmitry Shachnev wrote:
> On Tue, Oct 22, 2019 at 09:57:16PM +0200, Paul Gevers wrote:
>> I have scheduled those. First build failures are appearing. Can you
>> please check?
>>
>> https://buildd.debian.org/status/package.php?p=deepin-qt5dxcb-plugin
>> https://buildd.debian.org/status/package.php?p=xdg-desktop-portal-kde
>> https://buildd.debian.org/status/package.php?p=libfm-qt
>> https://buildd.debian.org/status/package.php?p=pyqt5
> 
> Oh! I will fix xdg-desktop-portal-kde and pyqt5 myself, and file bugs for
> the other two.
> 
> For deepin-qt5dxcb-plugin there was #935105 but the new failure is different,
> so I think a new bug is better.

Please make sure that all FTBFS bugs are tagged with the ftbfs tag. That
will have them show up on the buildd pages and eases our review work.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#942768: lcl-units-2.0: file conflict with lazarus-src-2.0 (versin 2.0.2+dfsg-5)

[Abou Al Montacir]

Hi Jan, Hi Andreas,
> both contains the same file, namely 
>   /usr/lib/lazarus/2.0.2/components/IdeInspector/ideinspector.lpk
> and removing it from one of them would fix the issue.
That is not a bug, but rather a feature that is solving previous bugs [1] and
[2]
The issue is that I copied some code from the Debian policy manual [3] and that
code was wrong:
The given example is missing closing bracket. I should noticed it before, but
for some obscure reason it is passing on my computer:if [ upgrade != "$1 || dpkg
--compare-versions "$2" lt 1.0-2; then
I've checked it again and I've fixed it. Will upload soon.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823706
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898310
[3] https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html-- 
Cheers,
Abou Al Montacir


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

Bug#941093: ping!

[Dmitry Shachnev]

On Tue, Oct 22, 2019 at 09:57:16PM +0200, Paul Gevers wrote:
> I have scheduled those. First build failures are appearing. Can you
> please check?
>
> https://buildd.debian.org/status/package.php?p=deepin-qt5dxcb-plugin
> https://buildd.debian.org/status/package.php?p=xdg-desktop-portal-kde
> https://buildd.debian.org/status/package.php?p=libfm-qt
> https://buildd.debian.org/status/package.php?p=pyqt5

Oh! I will fix xdg-desktop-portal-kde and pyqt5 myself, and file bugs for
the other two.

For deepin-qt5dxcb-plugin there was #935105 but the new failure is different,
so I think a new bug is better.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#942885: isdnactivecards: FTBFS in sid: icnctrl.c:75:10: fatal error: linux/isdn.h: No such file or directory

[Christoph Biedl]

Control: tag 942885 confirmed wontfix

Andreas Beckmann wrote...

> Package: isdnactivecards
> Version: 1:3.12.2007-11-27-1
> Severity: serious
> Tags: sid bullseye ftbfs

Haven't checked, but bullseye /should/ still build. Not for
long, though.

> isdnactivecards cannot be built in sid any longer:

Jepp, isdn4linux is history. RM will follow in a few days, intent to
remove is at #934358.

Christoph

PS: Same for isdnutils, no need to file a bug report.


signature.asc
Description: PGP signature

Bug#936585: gbirthday: Python2 removal in sid/bullseye

[Jérôme]

Hi.

Last gbirthday maintainer speaking.

The gbirthday package is more or less dead upstream, unless someone
volunteers to take it over.

I ported gbirthday to qt. Here is qbirthday:

https://github.com/lafrech/qbirthday
https://pypi.org/project/qbirthday/

There are a few changes from GBirthday but the idea and the look
remain the same.

I don't have time and knowledge to package it for Debian myself, but
I'd be willing to help.

The fact that I created a setup.py could help building the package.

-- 
Jérôme

Bug#939259: webcheck: Python2 removal in sid/bullseye

[Arthur de Jong]

On Mon, 2019-09-02 at 15:09 +0200, Stefano Rivera wrote:
> Your package either build-depends, depends on Python2, or uses
> Python2 in the autopkg tests.  Please stop using Python2, and fix
> this issue by one of the following actions.
> 
> - Convert your Package to Python3.

I would like to do this but it requires some time that I don't have a
lot of available at the moment. Any help will we appreciated.

The upstream repo has a lot of changes relative to the latest release
because there was a plan to improve performance and make the tool a bit
more lightweight (most of that was done). While the code in the repo
should be reasonably stable it is not as nice as it could be and I
would also like to switch to using requests and a few other things but
it kind of lost focus on it :(

Anyway, help is very welcome.

I'm also not too adverse to removal from testing to help the Python 2
migration along.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



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

Bug#942415: transition: meta-kde

[Sandro Knauß]

 Control: tags -1 -moreinfo

Hi Paul,
 
> On 15-10-2019 23:53, Sandro Knauß wrote:
> > I'm not sure, what ben rules you want, I can create ben rules for all
> > 38 packages, but as the 57 packages are get a new upload anyways,
> > those get recompiled anyways.
> 
> This sounds like one transition, so I think we want *one* ben file.
> Don't you want all is_affected/is_good/is_bad or-ed together?

Well I can merge those is_affected/is_bad/is_good lines together, but from my 
point of view that means, that the status is not tracked correctly. As a 
reverse dependency may depend on two or more packages in KDEPIM and the 
is_good line would be true if the package get built against any of those 
packages. But maybe this is normal for transitions because in the end it is 
only a question of when to request the binnmu.

> > So I decided to start with those 18 packages, that affects by the
> > external packages, those are:
> > blogilo (broken in sid anyways / upstream is dead)
> > calligra
> > calligraplan
> > kio-gdrive
> > kjots
> > kmymoney
> > kraft
> > zanshin
> 
> I'm not sure I understand what you meant. Let me rephrase what I think
> you wanted to say. You created the ben files for 18 source packages.
> Those 18 source packages provide the 8 listed source packages above with
> (build) dependencies. The other KDEPIM source packages in this
> transition don't have reverse dependencies that need rebuilding outside
> of the KDEPIM packages?

Right, all others don't have any (build) reverse dependencies outside KDEPIM.
> 
> Paul



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

Bug#942888: libsystemd-dev 243-3 depends on libsystemd0 = 242-7, not installable

[Felicia]

Package: libsystemd-dev
Version: 243-3
Severity: normal

Dear Maintainer,

libsystemd-dev 243-3 depends on libsystemd0 242-7 and cannot therefore install.


$ sudo apt install libsystemd-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libsystemd-dev : Depends: libsystemd0 (= 242-7)
E: Unable to correct problems, you have held broken packages.



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

Versions of packages libsystemd-dev depends on:
ii  libsystemd0  243~rc2-1

libsystemd-dev recommends no packages.

libsystemd-dev suggests no packages.

Bug#941093: ping!

[Paul Gevers]

Hi Dmitry,

On 22-10-2019 17:49, Dmitry Shachnev wrote:
> You can start scheduling binNMUs already. An extra build-dependency on
> qtbase5-dev (>= 5.12) is enough to make sure it builds against the new
> version. For qtcreator, please also add qbs-dev (>= 1.13).

I have scheduled those. First build failures are appearing. Can you
please check?

https://buildd.debian.org/status/package.php?p=deepin-qt5dxcb-plugin
https://buildd.debian.org/status/package.php?p=xdg-desktop-portal-kde
https://buildd.debian.org/status/package.php?p=libfm-qt
https://buildd.debian.org/status/package.php?p=pyqt5

Paul



signature.asc
Description: OpenPGP digital signature

Bug#942887: python-fabio: autopkgtest failure.

[peter green]

Package: python-fabio
Version: 0.9.0+dfsg-2
Severity: serious

Python-fabio's autopkgtest is failing,


==
ERROR: testFullFormatName (fabio.test.testfabioconvert.TestFabioConvert)
--
Traceback (most recent call last):
   File "/usr/lib/python3/dist-packages/fabio/test/testfabioconvert.py", line 
135, in testFullFormatName
 image = fabio.open("output/03.npy")
   File "/usr/lib/python3/dist-packages/fabio/openimage.py", line 159, in 
openimage
 obj = obj.read(obj.filename, frame)
   File "/usr/lib/python3/dist-packages/fabio/numpyimage.py", line 161, in read
 self.dataset = numpy.load(infile)
   File "/usr/lib/python3/dist-packages/numpy/lib/npyio.py", line 447, in load
 pickle_kwargs=pickle_kwargs)
   File "/usr/lib/python3/dist-packages/numpy/lib/format.py", line 696, in 
read_array
 raise ValueError("Object arrays cannot be loaded when "
ValueError: Object arrays cannot be loaded when allow_pickle=False

--

This appears to be happening during both the unstable->testing migration tests 
and the pure unstable tests, but not during the pure testing tests.

Bug#942537: Please package newer version

[Iustin Pop]

On 2019-10-21 10:01:43, Sven Hoexter wrote:
> On Sun, Oct 20, 2019 at 02:38:28PM +0200, Sven Hoexter wrote:
> 
> Hi,
> 
> > > 2) You can also update it to fio 3.16 and upload that. I would be okay
> > > with an NMU.
> > 
> > I currently look into this option. Since we set it up on Salsa in the
> > Debian group, I can update the package. But let me see if it builds here.
> 
> I just uploaded 3.16 and pushed everything to salsa. Had to add a small
> oneline fix from upstream to get the gfio stuff to build. The patch can
> be removed with 3.17+.
> 
> Hope that helps for now, didn't do any polishing of typos.

Thank you very much!

Bug#942886: linux-image-5.3.0-1-amd64: Can not modprobe "snd_hda_codec_hdmi"

[John Wong]

Package: src:linux
Version: 5.3.7-1
Severity: important

Dear Maintainer,
 After upgrade kernel to linux-image-5.3.0-1-amd64, I can not
 modprobe "snd_hda_codec_hdmi" any more, it show the error message,
 modprobe: ERROR: could not insert 'snd_hda_codec_hdmi': Key was
 rejected by service
 and my monitor no sound output.
 Please help, thank you.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
** Version:
Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 (2019-10-19)

** Command line:
BOOT_IMAGE=/vmlinuz-5.3.0-1-amd64 root=/dev/mapper/nvme0n1p1_crypt ro 
rootflags=subvol=rootfs apparmor=1 security=apparmor nosmt rootfstype=btrfs 
rootflags=subvol=rootfs quiet

** Not tainted

** Kernel log:
[7.126154] bridge: filtering via arp/ip/ip6tables is no longer available by 
default. Update your scripts to load br_netfilter if you need this.
[7.127219] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: 
line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line
[7.127221] snd_hda_codec_generic hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[7.127222] snd_hda_codec_generic hdaudioC0D0:hp_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[7.127222] snd_hda_codec_generic hdaudioC0D0:mono: mono_out=0x0
[7.127223] snd_hda_codec_generic hdaudioC0D0:dig-out=0x3/0x0
[7.127223] snd_hda_codec_generic hdaudioC0D0:inputs:
[7.127667] input: HDA Intel HDMI HDMI as 
/devices/pci:00/:00:03.0/sound/card0/input17
[7.153862] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: 
(null)
[7.181175] Rounding down aligned max_sectors from 4294967295 to 4294967288
[7.181662] db_root: cannot open: /etc/target
[7.245336] Adding 1952764k swap on /dev/mapper/swap.  Priority:-2 extents:1 
across:1952764k SSFS
[7.279906] bcache: bch_journal_replay() journal replay done, 177 keys in 12 
entries, seq 6365286
[7.289114] bcache: bch_cached_dev_attach() Caching sda1 as bcache0 on set 
3ec1b954-b969-438d-b264-91a36d2a1a4c
[7.289136] bcache: register_cache() registered cache device dm-5
[7.298596] intel_rapl_common: Found RAPL domain package
[7.298598] intel_rapl_common: Found RAPL domain core
[7.298598] intel_rapl_common: Found RAPL domain uncore
[7.298599] intel_rapl_common: Found RAPL domain dram
[   11.171939] BTRFS: device fsid b6b55d64-9811-4f26-9d77-f5af7750193f devid 1 
transid 2690791 /dev/dm-8
[   11.189503] BTRFS info (device dm-8): enabling ssd optimizations
[   11.189504] BTRFS info (device dm-8): turning on discard
[   11.189507] BTRFS info (device dm-8): use lzo compression, level 0
[   11.189508] BTRFS info (device dm-8): disk space caching is enabled
[   11.189509] BTRFS info (device dm-8): has skinny extents
[   11.269858] audit: type=1400 audit(1571773003.787:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/tcpdump" pid=949 
comm="apparmor_parser"
[   11.270455] audit: type=1400 audit(1571773003.787:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="transmission" pid=950 
comm="apparmor_parser"
[   11.270943] audit: type=1400 audit(1571773003.787:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/gpicview" pid=948 
comm="apparmor_parser"
[   11.272458] audit: type=1400 audit(1571773003.787:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="un-archiver" pid=951 
comm="apparmor_parser"
[   11.272475] audit: type=1400 audit(1571773003.787:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/wget" pid=952 
comm="apparmor_parser"
[   11.274990] audit: type=1400 audit(1571773003.791:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/xarchiver" pid=953 
comm="apparmor_parser"
[   11.275621] audit: type=1400 audit(1571773003.791:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="rsyslogd" pid=954 
comm="apparmor_parser"
[   11.276773] audit: type=1400 audit(1571773003.791:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/filezilla" pid=955 
comm="apparmor_parser"
[   11.277188] audit: type=1400 audit(1571773003.795:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=956 comm="apparmor_parser"
[   11.278016] audit: type=1400 audit(1571773003.795:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/pavucontrol" 
pid=957 comm="apparmor_parser"
[   11.463897] new mount options do not match the existing superblock, will be 

Bug#942885: isdnactivecards: FTBFS in sid: icnctrl.c:75:10: fatal error: linux/isdn.h: No such file or directory

[Andreas Beckmann]

Package: isdnactivecards
Version: 1:3.12.2007-11-27-1
Severity: serious
Tags: sid bullseye ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

isdnactivecards cannot be built in sid any longer:

[...]
make[3]: Entering directory '/build/isdnactivecards-3.12.2007-11-27/icn'
gcc -g -O2 -fdebug-prefix-map=/build/isdnactivecards-3.12.2007-11-27=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time 
-D_FORTIFY_SOURCE=2 -I.   -c -o icnctrl.o icnctrl.c
icnctrl.c:75:10: fatal error: linux/isdn.h: No such file or directory
   75 | #include 
  |  ^~
compilation terminated.
make[3]: *** [Makefile:34: icnctrl.o] Error 1
make[3]: Leaving directory '/build/isdnactivecards-3.12.2007-11-27/icn'
[...]


Andreas


isdnactivecards_1:3.12.2007-11-27-1.log.gz
Description: application/gzip

Bug#942415: transition: meta-kde

[Paul Gevers]

Control: tags -1 moreinfo

Hi Sandro,

On 15-10-2019 23:53, Sandro Knauß wrote:
> I'm not sure, what ben rules you want, I can create ben rules for all
> 38 packages, but as the 57 packages are get a new upload anyways,
> those get recompiled anyways.

This sounds like one transition, so I think we want *one* ben file.
Don't you want all is_affected/is_good/is_bad or-ed together?

> So I decided to start with those 18 packages, that affects by the
> external packages, those are:
> blogilo (broken in sid anyways / upstream is dead)
> calligra
> calligraplan
> kio-gdrive
> kjots
> kmymoney 
> kraft
> zanshin

I'm not sure I understand what you meant. Let me rephrase what I think
you wanted to say. You created the ben files for 18 source packages.
Those 18 source packages provide the 8 listed source packages above with
(build) dependencies. The other KDEPIM source packages in this
transition don't have reverse dependencies that need rebuilding outside
of the KDEPIM packages?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#942884: RFS: zipios/2.2.5.0-1 -- small C++ library for reading zip files (development)

[François Mazen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: zipios
   Version : 2.2.5.0-1
   Upstream Author : Thomas Sondergaard 
 * URL : http://zipios.sourceforge.net/
 * License : LGPL-2+
 * Vcs : https://salsa.debian.org/mzf-guest/zipios
   Section : devel

It builds those binary packages:

  libzipios-dev - small C++ library for reading zip files (development)
  libzipios2 - small C++ library for reading zip files (library)
  libzipios-doc - small C++ library for reading zip files (documents)
  libzipios++0v5 - transitional package

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zipios/zipios_2.2.5.0-1.dsc

Changes since the last upload:

   * Import new upstream release (Closes: #834171)
   * Add watch file
   * Fix reproducible issue with doxygen documentation
   * Rename to Zipios from Zipios++
   * Rename to libzipios2 from libzipios0v5 and create a transition
package.
   * Add autopkgtest
   * Add upstream metadata
   * Bump standard version to 4.4.1

Regards,

Bug#935969: linux-image-5.2.0-2-amd64: Missing firmware for new driver rtwpci

[Andrea Palazzi]

Package: firmware-realtek
Version: 20190717-2
Followup-For: Bug #935969

Hi,

The cause of the bug is that the rules.gen file does not include the rtw88
firmware files.
The attached patch solves the problem (at least for me).

Kind regards,
Andrea Palazzi



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

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

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

-- no debconf information
--- rules.gen.orig  2019-10-22 21:14:32.320024105 +0200
+++ rules.gen   2019-10-22 21:13:07.251925642 +0200
@@ -46,7 +46,7 @@
 binary-indep::
$(MAKE) -f debian/rules.real binary-indep 
FILES='cbfw-3.2.3.0.bin:cbfw-3.2.3.0.bin cbfw-3.2.5.1.bin:cbfw-3.2.5.1.bin 
ct2fw-3.2.3.0.bin:ct2fw-3.2.3.0.bin ct2fw-3.2.5.1.bin:ct2fw-3.2.5.1.bin 
ctfw-3.2.3.0.bin:ctfw-3.2.3.0.bin ctfw-3.2.5.1.bin:ctfw-3.2.5.1.bin 
qed/qed_init_values_zipped-8.10.10.0.bin:qed/qed_init_values_zipped-8.10.10.0.bin
 
qed/qed_init_values_zipped-8.33.1.0.bin:qed/qed_init_values_zipped-8.33.1.0.bin 
qed/qed_init_values_zipped-8.33.11.0.bin:qed/qed_init_values_zipped-8.33.11.0.bin
 
qed/qed_init_values_zipped-8.37.2.0.bin:qed/qed_init_values_zipped-8.37.2.0.bin 
qlogic/1040.bin:qlogic/1040.bin qlogic/1280.bin:qlogic/1280.bin 
qlogic/12160.bin:qlogic/12160.bin qlogic/sd7220.fw:qlogic/sd7220.fw 
ql2100_fw.bin:ql2100_fw.bin ql2200_fw.bin:ql2200_fw.bin 
ql2300_fw.bin:ql2300_fw.bin ql2322_fw.bin:ql2322_fw.bin 
ql2400_fw.bin:ql2400_fw.bin ql2500_fw.bin:ql2500_fw.bin' LINKS='' 
PACKAGE='qlogic'
 binary-indep::
-   $(MAKE) -f debian/rules.real binary-indep 
FILES='RTL8192E/boot.img:RTL8192E/boot.img RTL8192E/data.img:RTL8192E/data.img 
RTL8192E/main.img:RTL8192E/main.img 
rtl_bt/rtl8192ee_fw.bin:rtl_bt/rtl8192ee_fw.bin 
rtl_bt/rtl8812ae_fw.bin:rtl_bt/rtl8812ae_fw.bin 
rtl_bt/rtl8761a_fw.bin:rtl_bt/rtl8761a_fw.bin 
rtl_bt/rtl8821a_fw.bin:rtl_bt/rtl8821a_fw.bin 
rtl_bt/rtl8192eu_fw.bin:rtl_bt/rtl8192eu_fw.bin 
rtl_bt/rtl8723a_fw.bin:rtl_bt/rtl8723a_fw.bin 
rtl_bt/rtl8723b_fw.bin:rtl_bt/rtl8723b_fw.bin 
rtl_bt/rtl8723d_config.bin:rtl_bt/rtl8723d_config.bin 
rtl_bt/rtl8723d_fw.bin:rtl_bt/rtl8723d_fw.bin 
rtl_bt/rtl8821c_config.bin:rtl_bt/rtl8821c_config.bin 
rtl_bt/rtl8821c_fw.bin:rtl_bt/rtl8821c_fw.bin 
rtl_bt/rtl8822b_config.bin:rtl_bt/rtl8822b_config.bin 
rtl_bt/rtl8822b_fw.bin:rtl_bt/rtl8822b_fw.bin 
rtl_bt/rtl8822cu_fw.bin:rtl_bt/rtl8822cu_fw.bin 
rtl_nic/rtl8105e-1.fw:rtl_nic/rtl8105e-1.fw 
rtl_nic/rtl8106e-1.fw:rtl_nic/rtl8106e-1.fw 
rtl_nic/rtl8106e-2.fw:rtl_nic/rtl8106e-2.fw 
rtl_nic/rtl8107e-1.fw:rtl_nic/rtl8107e-1.fw 
rtl_nic/rtl8107e-2.fw:rtl_nic/rtl8107e-2.fw 
rtl_nic/rtl8168d-1.fw:rtl_nic/rtl8168d-1.fw 
rtl_nic/rtl8168d-2.fw:rtl_nic/rtl8168d-2.fw 
rtl_nic/rtl8168e-1.fw:rtl_nic/rtl8168e-1.fw 
rtl_nic/rtl8168e-2.fw:rtl_nic/rtl8168e-2.fw 
rtl_nic/rtl8168e-3.fw:rtl_nic/rtl8168e-3.fw 
rtl_nic/rtl8168f-1.fw:rtl_nic/rtl8168f-1.fw 
rtl_nic/rtl8168f-2.fw:rtl_nic/rtl8168f-2.fw 
rtl_nic/rtl8168g-1.fw:rtl_nic/rtl8168g-1.fw 
rtl_nic/rtl8168g-2.fw:rtl_nic/rtl8168g-2.fw 
rtl_nic/rtl8168g-3.fw:rtl_nic/rtl8168g-3.fw 
rtl_nic/rtl8168h-1.fw:rtl_nic/rtl8168h-1.fw 
rtl_nic/rtl8168h-2.fw:rtl_nic/rtl8168h-2.fw 
rtl_nic/rtl8402-1.fw:rtl_nic/rtl8402-1.fw 
rtl_nic/rtl8411-1.fw:rtl_nic/rtl8411-1.fw 
rtl_nic/rtl8411-2.fw:rtl_nic/rtl8411-2.fw 
rtlwifi/rtl8188efw.bin:rtlwifi/rtl8188efw.bin 
rtlwifi/rtl8188eufw.bin:rtlwifi/rtl8188eufw.bin 
rtlwifi/rtl8192cfw.bin:rtlwifi/rtl8192cfw.bin 
rtlwifi/rtl8192cfwU_B.bin:rtlwifi/rtl8192cfwU_B.bin 
rtlwifi/rtl8192cfwU.bin:rtlwifi/rtl8192cfwU.bin 
rtlwifi/rtl8192cufw_A.bin:rtlwifi/rtl8192cufw_A.bin 
rtlwifi/rtl8192cufw_B.bin:rtlwifi/rtl8192cufw_B.bin 
rtlwifi/rtl8192cufw_TMSC.bin:rtlwifi/rtl8192cufw_TMSC.bin 
rtlwifi/rtl8192cufw.bin:rtlwifi/rtl8192cufw.bin 
rtlwifi/rtl8192defw.bin:rtlwifi/rtl8192defw.bin 
rtlwifi/rtl8192eefw.bin:rtlwifi/rtl8192eefw.bin 
rtlwifi/rtl8192eu_nic.bin:rtlwifi/rtl8192eu_nic.bin 
rtlwifi/rtl8192eu_wowlan.bin:rtlwifi/rtl8192eu_wowlan.bin 
rtlwifi/rtl8192sefw.bin:rtlwifi/rtl8192sefw.bin 
rtlwifi/rtl8712u.bin:rtlwifi/rtl8712u.bin 
rtlwifi/rtl8723aufw_A.bin:rtlwifi/rtl8723aufw_A.bin 
rtlwifi/rtl8723aufw_B.bin:rtlwifi/rtl8723aufw_B.bin 
rtlwifi/rtl8723aufw_B_NoBT.bin:rtlwifi/rtl8723aufw_B_NoBT.bin 
rtlwifi/rtl8723befw_36.bin:rtlwifi/rtl8723befw_36.bin 
rtlwifi/rtl8723befw.bin:rtlwifi/rtl8723befw.bin 
rtlwifi/rtl8723bs_bt.bin:rtlwifi/rtl8723bs_bt.bin 
rtlwifi/rtl8723bs_nic.bin:rtlwifi/rtl8723bs_nic.bin 
rtlwifi/rtl8723bs_wowlan.bin:rtlwifi/rtl8723bs_wowlan.bin 
rtlwifi/rtl8723bu_nic.bin:rtlwifi/rtl8723bu_nic.bin 

Bug#942883: libqt5xdgiconloader3: Dependency upon qtbase-abi-5-11-3 prevents installation

[Felicia]

Package: libqt5xdgiconloader3
Version: 3.3.1-2
Severity: important

Dear Maintainer,

A dependency issue is preventing installation of this package, causing 
lxqt-core components to uninstall, thus breaking existing lxqt installation.  
See output below:

$ sudo apt install lxqt-core
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 lxqt-core : Depends: lxqt-config but it is not going to be installed
 Depends: lxqt-notificationd but it is not going to be installed
 Depends: lxqt-globalkeys but it is not going to be installed
 Depends: lxqt-panel but it is not going to be installed
 Depends: lxqt-policykit but it is not going to be installed
 Depends: lxqt-qtplugin but it is not going to be installed
 Depends: lxqt-runner but it is not going to be installed
 Depends: lxqt-session but it is not going to be installed
 Depends: pcmanfm-qt but it is not going to be installed


$ sudo apt install lxqt-notificationd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 lxqt-notificationd : Depends: liblxqt0 (>= 0.14.1~) but it is not going to be 
installed
  Depends: libqt5xdg3 (>= 1.0.0) but it is not going to be 
installed



$ sudo apt install libqt5xdg3
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libqt5xdg3 : Depends: libqt5xdgiconloader3 (>= 3.0.0) but it is not going to 
be installed
E: Unable to correct problems, you have held broken packages.



$ sudo apt install libqt5xdgiconloader3
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libqt5xdgiconloader3 : Depends: qtbase-abi-5-11-3 but it is not installable
E: Unable to correct problems, you have held broken packages.






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

Versions of packages libqt5xdgiconloader3 depends on:
ii  libc6  2.29-2
ii  libqt5core5a   5.12.5+dfsg-2
ii  libqt5gui5 5.12.5+dfsg-2
ii  libstdc++6 9.2.1-9
pn  qtbase-abi-5-11-3  

Versions of packages libqt5xdgiconloader3 recommends:
ii  gtk-update-icon-cache  3.24.12-1

libqt5xdgiconloader3 suggests no packages.

Bug#941018: ibus 1.5.21-1 does not work with qt5 applications

[Gunnar Hjalmarsson]

On 2019-10-22 20:58, Simon McVittie wrote:

On Tue, 22 Oct 2019 at 19:30:51 +0200, Gunnar Hjalmarsson wrote:

@Simon: Any thoughts on the status of your glib MR? Is it safe
enough to patch glib2.0 in Debian, and with that fix this bug?


I don't think we should be applying changes this significant to code
this important (it's at a security boundary) without proper review.

If you consider my proposed code changes to be correct (apart from
the memory leak that I just spotted, which I'll fix when I get a
chance), please say so on the upstream merge request.


Those changes are over my head, so I'm not able to tell whether they are 
"correct". But I added a comment with the purpose of encouraging reviews 
soon. :)


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

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Antoine Beaupré]

Control: severity 887831 grave

On 2019-10-22 12:39:47, Daniel Kahn Gillmor wrote:
> I would even posit that temporarily breaking jigdo would be better than
> keeping this additional bandwidth cost in play.

Yes. In fact, right now, I can't think of any use case for Jigdo. It's
been totally superseded by bittorrent, which is standardized, widely
available and much more popular, with multiple client implementations.

Fedora stopped shipping their releases with Jigdo in 2011, according to
wikipedia:

https://en.wikipedia.org/wiki/Jigdo

WP also says development has stopped since 2006.

On 2019-10-22 19:15:51, Thomas Schmitt wrote:
> To my knowledge, jigdo is the only way to get full DVD sets or any BD sized
> installation ISO from
>   https://cdimage.debian.org/cdimage/release/current/amd64/
>
> bt-* seems t have what iso-* has. Biggest is the 5.3 GB
> debian-edu-10.1.0-amd64-BD-1.iso which would fit on a DVD+R DL, too.
> Only the first three DVDs are offered by iso-* and bt-*.

If the ISO image generation is broken, it should be fixed. I don't see
why we should depend on jigdo for anything anymore.

In the meantime, I think it's perfectly acceptable to remove MD5sums
from the archive, at the cost of breaking jigdo.

Or, to put it another way, it's completely unacceptable that jigdo uses
MD5 to authenticate checksums, and if it keeps doing so, we shouldn't
ship Debian with it. That is a release-critical bug, severity "grave"
with justification "introduces a security hole allowing access to the
accounts of users who use the package".

A.
-- 
Gods don't like people not doing much work. People who aren't busy all
the time might start to think.
- Terry Pratchett, Small Gods


signature.asc
Description: PGP signature

Bug#407722: Job Offer For You.

[Mr. Wen Li Zhang]

We have a job offer for you. Reply to this email for more details. 

Wen Li Zhang 

Bug#932971: ITP: squashfs-tools-ng -- A new set of tools for working with SquashFS images

[GCS]

On Wed, Oct 16, 2019 at 9:45 PM Johannes Schauer  wrote:
> On Thu, 25 Jul 2019 11:51:00 +0200 László Böszörményi (GCS)  
> wrote:
> > * Package name: squashfs-tools-ng
> I see the package is still waiting in NEW.
>
> Where did you put the packaging VCS? I'd like to play around with it before 
> ftp
> master manages to approve it. :)
 You can get the updated, 0.7-1 release[1], but please note that its
self-testing is constantly failing:
FAIL: test_fstree_init
==

test_fstree_init: tests/fstree_init.c:32: main: Assertion
`fs.defaults.st_mtime == 0' failed.
FAIL test_fstree_init (exit status: 134)

Can you check it David? I've tried it on three machines. Two of these
are running on amd64 and one is on i386 architecture.

Regards,
Laszlo/GCS
[1] http://www.barcikacomp.hu/gcs/squashfs-tools-ng_0.7-1.dsc

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Daniel Kahn Gillmor]

On Tue 2019-10-22 19:15:51 +0200, Thomas Schmitt wrote:
> Daniel Kahn Gillmor wrote:
>> I would even posit that temporarily breaking jigdo would be better than
>> keeping this additional bandwidth cost in play.
>
> To my knowledge, jigdo is the only way to get full DVD sets or any BD sized
> installation ISO from
>   https://cdimage.debian.org/cdimage/release/current/amd64/

I understand what you're saying (though i haven't used optical media to
install debian in over a decade).

If jigdo would use the SHA256sum entries instead of the MD5 entries when
it is doing ISO assembly, then everyone could still fetch full DVD sets
or BD sized installation ISOs, without every single debian user
expending the extra 13% bandwidth on fetching the Packages file when
they "apt get update".

AFAICT, jigdo's last maintenance release (debian version) was nearly two
years ago.

The last upsteam release (0.7.3) was produced in 2006.

Its homepage is http://atterer.org/jigdo/devel.html , which was last
updated in 2010, and points to a CVS server i cannot access.

Its debian packaging doesn't have a Vcs-* field (though i've just
created https://salsa.debian.org/debian/jigdo and uploaded what i could
get from "gbp import-dscs --pristine-tar --debsnap" to it).

This looks like it might be a moribund software project, and it should
not be holding back the rest of the project from making other
improvements.  Making the Packages file smaller is a concrete advantage
for every debian user.

Do you have any suggestions to offer to make jigdo work using a modern
cryptographic digest?

--dkg


signature.asc
Description: PGP signature

Bug#602788: read /sys/class/tty/console/active

[Łukasz Stelmach]

Control: tag -1 +patch

Hi,

The attached patch should (I will test it tomorrow) fix the problem.

-- 
Łukasz Stelmach
Samsung R Institute Poland
Samsung Electronics
--- live-config-getty-generator.orig	2019-10-22 21:06:50.858966292 +0200
+++ live-config-getty-generator	2019-05-19 10:11:26.0 +0200
@@ -73,9 +73,9 @@
 	# Configure autologin
 	if [ -n "${LIVE_USERNAME}" ]
 	then
-		for TTY in tty1 tty2 tty3 tty4 tty5 tty6 $(cat /sys/class/tty/console/active)
+		for NUMBER in $(seq 1 6)
 		do
-			GETTY_SERVICE_D=$SYSTEMD_DIR/getty@${TTY}.service.d
+			GETTY_SERVICE_D=$SYSTEMD_DIR/getty@tty${NUMBER}.service.d
 			CONF=$GETTY_SERVICE_D/live-config_autologin.conf
 			mkdir -p $GETTY_SERVICE_D
 

Bug#941018: ibus 1.5.21-1 does not work with qt5 applications

[Simon McVittie]

On Tue, 22 Oct 2019 at 19:30:51 +0200, Gunnar Hjalmarsson wrote:
> Simon has prepared a fix of this issue via a glib merge request:
> 
> https://gitlab.gnome.org/GNOME/glib/merge_requests/1176
> 
> I applied the diff from that MR on top of glib2.0 2.62.1-1, and based on my
> limited tests it appears to fix the issue with IBus in Qt apps.
> 
> @Simon: Any thoughts on the status of your glib MR? Is it safe enough to
> patch glib2.0 in Debian, and with that fix this bug?

I don't think we should be applying changes this significant to code
this important (it's at a security boundary) without proper review.

If you consider my proposed code changes to be correct (apart from the
memory leak that I just spotted, which I'll fix when I get a chance),
please say so on the upstream merge request.

smcv

Bug#942882: moving things around with PYBUILD_EXT_DESTDIR_* doesn't seem to work

[Matthias Klose]

Package: dh-python
Version: 4.20191017

The handling of the changed extension names in 3.8 is a little bit tricky, and 
you suggested to use PYBUILD_NAME and PYBUILD_EXT_DESTDIR_*.  Here is a try to 
do that The changed packaging has other bugs, but it show that the extensions 
are not moved into the -lib packages.
diff -Nru pytables-3.5.2/debian/changelog pytables-3.5.2/debian/changelog
--- pytables-3.5.2/debian/changelog	2019-08-16 19:53:28.0 +0200
+++ pytables-3.5.2/debian/changelog	2019-10-22 13:04:06.0 +0200
@@ -1,3 +1,25 @@
+pytables (3.5.2-3ubuntu2) UNRELEASED; urgency=medium
+
+  [ Michael Hudson-Doyle ]
+  * Fix build with Python 3.8 in a way that does not break Python 2.7. 
+
+  [ Matthias Klose ]
+  * Fix installation of Python 3.8 extensions.
+
+ -- Matthias Klose   Tue, 22 Oct 2019 13:04:06 +0200
+
+pytables (3.5.2-3ubuntu1) focal; urgency=medium
+
+  * Fix build with Python3.8.
+
+ -- Matthias Klose   Mon, 21 Oct 2019 11:25:19 +0200
+
+pytables (3.5.2-3build1) focal; urgency=medium
+
+  * No-change rebuild to build with python3.8.
+
+ -- Matthias Klose   Fri, 18 Oct 2019 18:33:41 +
+
 pytables (3.5.2-3) unstable; urgency=medium
 
   * debian/rules:
diff -Nru pytables-3.5.2/debian/control pytables-3.5.2/debian/control
--- pytables-3.5.2/debian/control	2019-08-16 19:53:28.0 +0200
+++ pytables-3.5.2/debian/control	2019-10-22 13:04:06.0 +0200
@@ -1,5 +1,6 @@
 Source: pytables
-Maintainer: Debian Science Maintainers 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian Science Maintainers 
 Uploaders: Antonio Valentino ,
Yaroslav Halchenko 
 Section: python
diff -Nru pytables-3.5.2/debian/patches/python3.8-fix.diff pytables-3.5.2/debian/patches/python3.8-fix.diff
--- pytables-3.5.2/debian/patches/python3.8-fix.diff	1970-01-01 01:00:00.0 +0100
+++ pytables-3.5.2/debian/patches/python3.8-fix.diff	2019-10-22 13:04:06.0 +0200
@@ -0,0 +1,51 @@
+--- a/tables/index.py
 b/tables/index.py
+@@ -23,7 +23,11 @@
+ import tempfile
+ import warnings
+ 
+-from time import time, clock
++from time import time
++try:
++from time import perf_counter
++except ImportError:
++from time import clock
+ 
+ import numpy
+ 
+@@ -847,7 +851,7 @@
+ 
+ if self.verbose:
+ t1 = time()
+-c1 = clock()
++c1 = perf_counter()
+ ss = self.slicesize
+ tmp = self.tmp
+ ranges = tmp.ranges[:]
+@@ -953,7 +957,7 @@
+ self.compute_overlaps(self.tmp, "do_complete_sort()", self.verbose)
+ if self.verbose:
+ t = round(time() - t1, 4)
+-c = round(clock() - c1, 4)
++c = round(perf_counter() - c1, 4)
+ print("time: %s. clock: %s" % (t, c))
+ 
+ def swap(self, what, mode=None):
+@@ -968,7 +972,7 @@
+ 
+ if self.verbose:
+ t1 = time()
+-c1 = clock()
++c1 = perf_counter()
+ if what == "chunks":
+ self.swap_chunks(mode)
+ elif what == "slices":
+@@ -982,7 +986,7 @@
+ rmult = len(mult.nonzero()[0]) / float(len(mult))
+ if self.verbose:
+ t = round(time() - t1, 4)
+-c = round(clock() - c1, 4)
++c = round(perf_counter() - c1, 4)
+ print("time: %s. clock: %s" % (t, c))
+ # Check that entropy is actually decreasing
+ if what == "chunks" and self.last_tover > 0. and self.last_nover > 0:
diff -Nru pytables-3.5.2/debian/patches/series pytables-3.5.2/debian/patches/series
--- pytables-3.5.2/debian/patches/series	2019-08-16 19:53:28.0 +0200
+++ pytables-3.5.2/debian/patches/series	2019-10-21 11:24:20.0 +0200
@@ -4,3 +4,4 @@
 0004-remove-gtags.patch
 0005-Drop-mock-for-requirements.txt.patch
 0006-Skip-index-backcompat-tests-on-bingendian.patch
+python3.8-fix.diff
diff -Nru pytables-3.5.2/debian/python3-tables-dbg.install pytables-3.5.2/debian/python3-tables-dbg.install
--- pytables-3.5.2/debian/python3-tables-dbg.install	2019-08-16 19:53:28.0 +0200
+++ pytables-3.5.2/debian/python3-tables-dbg.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/python3*/*-packages/tables/*.cpython-3?dm*.so
diff -Nru pytables-3.5.2/debian/python3-tables.install pytables-3.5.2/debian/python3-tables.install
--- pytables-3.5.2/debian/python3-tables.install	2019-08-16 19:53:28.0 +0200
+++ pytables-3.5.2/debian/python3-tables.install	1970-01-01 01:00:00.0 +0100
@@ -1,8 +0,0 @@
-usr/lib/python3*/dist-packages/tables/*.py
-usr/lib/python3*/dist-packages/tables/misc/*.py
-usr/lib/python3*/dist-packages/tables/nodes/*.py
-usr/lib/python3*/dist-packages/tables/nodes/tests/*.py
-usr/lib/python3*/dist-packages/tables/scripts/*.py
-usr/lib/python3*/dist-packages/tables/tests/*.py
-usr/lib/python3*/dist-packages/tables*.egg-info
-usr/bin/*
diff -Nru pytables-3.5.2/debian/python3-tables-lib.install pytables-3.5.2/debian/python3-tables-lib.install
--- 

Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")

[Josh Triplett]

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

After upgrading to linux-image-5.3.0-1-amd64, I get messages like those
seen in the log ("No response from codec, resetting bus" and "Unable to
sync register"), and eventually a WARN. The mixer doesn't show the audio
device at all.

This didn't happen with the previous kernel, namely:
Oct 21 21:04:28 s kernel: Linux version 5.2.0-3-amd64 
(debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-23)) #1 SMP 
Debian 5.2.17-1 (2019-10-06)

-- Package-specific info:
** Version:
Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 (2019-10-19)

** Command line:
BOOT_IMAGE=/vmlinuz-5.3.0-1-amd64 
root=UUID=121586a4-bf8c-49a4-9a72-ed70fcf72772 ro quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[   59.442968] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20170500
[   60.448988] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270500
[   61.454722] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370500
[   62.460306] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[   63.493654] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20170500
[   64.498615] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270500
[   65.507773] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370500
[   66.516498] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[   67.557305] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20170500
[   68.569978] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270500
[   69.578573] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370500
[   70.587072] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[   71.627548] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20170500
[   72.635462] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270500
[   73.639361] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370500
[   74.651383] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[   75.687274] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20170500
[   76.691051] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270500
[   77.694902] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370500
[   78.702874] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[   79.734778] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20170500
[   80.738684] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270500
[   81.742564] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370500
[   82.746472] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[   83.786414] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20170500
[   84.798403] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270500
[   85.810293] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370500
[   86.822260] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[   87.862207] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20170500
[   88.866163] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270500
[   89.874103] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370500
[   90.885985] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[   91.926013] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20170500
[   92.929911] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270500
[   93.938042] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370500
[   94.945841] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[   95.981858] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370740
[   96.985920] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370740
[   97.997872] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270d80
[   97.997891] snd_hda_codec_generic hdaudioC0D2: Unable to sync register 
0x2f0d00. -11
[   99.009847] snd_hda_intel 

Bug#883194: please convert mountstats and nfsiostat scripts to Python3

[Laurent Bigonville]

On Thu, 30 Nov 2017 16:37:52 +0100 Matthias Klose  wrote:

>
> the changelog reads:
>
> - nfs-common: Add Recommends python for mountstats and nfsiostat
>
> Please convert these scripts to python3, and recommend Python3 instead.
>

I think they should already be compatible with python3 since 1.2.9 (or 
1.3.1) if I'm looking at upstream git repository:


http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=9f9289efda1a7eff26cd046997efc56c2de40534

http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=1df82a36df74a59f55eea99d08612564fa22cbef

So it's just a matter of changing the shebang and the dependency.

Question, why is this a recommends? The executable is using python(3) 
without any fallback mechanism I can understand that this is a "not 
often use binary", but shouldn't that be changed to a Depends?

Bug#942880: mate-session-manager: A dialog box says at-spi-bus-launcher is 'not responding' on reboot/shutdown

[athmoss]

Package: mate-session-manager
Version: 1.22.2-1
Severity: normal

Dear Maintainer,

I'm running the MATE desktop on Sid and everytime I want to reboot or shutdown 
my laptop, a dialog box pops up saying the at-spi-bus-launcher is not 
responding. When clicking 'Reboot/Shutdown anyway' there's a timeout (around 30 
sec) and only after that the system proceeds with the reboot/shutdown.

This behavior has been already reported with some other distributions:
https://bugs.launchpad.net/ubuntu/+source/mate-session-manager/+bug/1846987
https://bugs.archlinux.org/task/63995

The Arch Linux link then points to
https://github.com/mate-desktop/mate-session-manager/pull/200 and
https://github.com/mate-desktop/mate-session-manager/pull/223

Please could you re-build the package as the fix already seems to be in 
upstream? Thank you and have a great day!

Regards,
athmoss


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

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

Versions of packages mate-session-manager depends on:
ii  dbus-x11 1.12.16-2
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  debian-mate-default-settings 1.22.2-1
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.16-2
ii  libdbus-glib-1-2 0.110-4
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libglib2.0-0 2.62.1-1
ii  libgtk-3-0   3.24.12-1
ii  libice6  2:1.0.9-2
ii  libsm6   2:1.2.3-1
ii  libsystemd0  242-7
ii  libx11-6 2:1.6.8-1
ii  libxau6  1:1.0.8-1+b2
ii  libxext6 2:1.3.3-1+b2
ii  libxrender1  1:0.9.10-1
ii  libxtst6 2:1.2.3-1
ii  mate-desktop-common  1.22.2-1

Versions of packages mate-session-manager recommends:
ii  caja  1.22.2-1
ii  marco 1.22.3-1
ii  mate-panel1.22.2-1
ii  mate-polkit   1.22.0-1
ii  mate-settings-daemon  1.22.1-1

mate-session-manager suggests no packages.

-- no debconf information

Bug#942725: interimap: please support name to appear in log lines

[Jonas Smedegaard]

Quoting Guilhem Moulin (2019-10-22 19:15:27)
> On Mon, 21 Oct 2019 at 00:26:58 +0200, Jonas Smedegaard wrote:
> > I syncronize multiple accounts into subdirs below ~/Maildir and 
> > track them as a whole using a single notmuch database.
> 
> AFAIK notmuch doesn't speak IMAP so unfortunately that approach breaks 
> layering.  I'm unsure how well IMAP servers cope with other processes 
> messing up with the storage backend.

Yes.  That's *exactly* why I don't elaborate further about my setup, but 
eagerly awaits your next release to hopefully get an epiphany on how to 
do it Properly(tm).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#922162: Fixed with v19.2.1-1

[ccaccb]

Dear maintainer,

this bug seems to be fixed after updating mesa to v19.2.1-1.

Bug#942799: Stretch: Wrong startup under gdb

[Christophe DELAHAYE]

A few details about the error: when running
"bash -x /usr/bin/thunderbird -g",

the command trace ends as follows:
-
+ output_info 'Starting Thunderbird with GDB ...'
+ echo 'INFO  -> Starting Thunderbird with GDB ...'
INFO  -> Starting Thunderbird with GDB ...
+ output_info 'LANG= /usr/bin/gdb -ex handle SIG38 nostop -ex handle
SIGPIPE nostop -ex run /usr/lib/thunderbird/thunderbird '
+ echo 'INFO  -> LANG= /usr/bin/gdb -ex handle SIG38 nostop -ex handle
SIGPIPE nostop -ex run /usr/lib/thunderbird/thunderbird '
INFO  -> LANG= /usr/bin/gdb -ex handle SIG38 nostop -ex handle SIGPIPE
nostop -ex run /usr/lib/thunderbird/thunderbird
+ LANG=
+ exec '/usr/bin/gdb -ex handle SIG38 nostop -ex handle SIGPIPE nostop
-ex run /usr/lib/thunderbird/thunderbird '
/usr/bin/thunderbird: line 249: /usr/bin/gdb -ex handle SIG38 nostop -ex
handle SIGPIPE nostop -ex run /usr/lib/thunderbird/thunderbird : No such
file or directory
-

It seems that the whole command line is interpreted as the filename to
load.  I did not recorded the shell exit status, but I believe that I
saw 127, the usual code for "command not found". I also think that I
experimented some problems with the "-ex" options when I tried to split
this long exec argument into filename and arguments.

Hence the proposed patch replaces this complex command line with a
simple one and a temporary file containing the commands for Gdb.

Note: the crash mentioned in the initial report is not the problem, only
the motivation to run Thunderbird under Gdb.

Regards.

Bug#942879: libbrotli-dev: Please add static version of libraries (.a)

[Tim Rühsen]

Package: libbrotli-dev
Version: 1.0.7-3
Severity: normal

Dear Maintainer,

I tried to build a static version of a binary (wget2).

There is no static version of the brotli libraries.

Regards, Tim


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

Versions of packages libbrotli-dev depends on:
ii  libbrotli1  1.0.7-3

libbrotli-dev recommends no packages.

libbrotli-dev suggests no packages.

-- no debconf information

Bug#942593: b2backend: fails with "can only concatenate str (not "bytes") to str"

[Graham Cobb]

Package: duplicity
Version: 0.8.05-1
Followup-For: Bug #942593

The bug still exists in the new version, although in a slightly different form:
(during "duplicity full" command)
Backtrace of previous error: Traceback (innermost last):
  File "/usr/lib/python3/dist-packages/duplicity/backend.py", line 371, in 
inner_retry
return fn(self, *args)
  File "/usr/lib/python3/dist-packages/duplicity/backend.py", line 606, in 
_do_delete
self.backend._delete(filename)
  File "/usr/lib/python3/dist-packages/duplicity/backends/b2backend.py", line 
138, in _delete
log.Log(u"Delete: %s" % self.path + filename, log.INFO)
 TypeError: can only concatenate str (not "bytes") to str

In this case the problem is the use of filename in _delete.

>From my earlier investigation (which may be wrong, of course, as I am no 
>expert on either Python or this code),
I believe the following references also have to be "decoded", in addition to 
the changes already made:

In _get: the use of local_path.name
In _put: the use of source_path.name
In _delete: the two uses of filename
In _query: the two uses of filename

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.utf8), LANGUAGE=en_GB (charmap=UTF-8) (ignored: LC_ALL set to 
en_IE.utf8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages duplicity depends on:
ii  gnupg  2.2.17-3
ii  libc6  2.29-2
ii  librsync2  2.0.2-1
ii  python33.7.5-1
ii  python3-fasteners  0.12.0-5
ii  python3-future 0.16.0-1
ii  python3-lockfile   1:0.12.2-2

Versions of packages duplicity recommends:
ii  python3-oauthlib  2.1.0-2
ii  python3-paramiko  2.6.0-1
ii  python3-pexpect   4.6.0-1
ii  python3-urllib3   1.24.1-1
ii  rsync 3.1.3-8

Versions of packages duplicity suggests:
pn  lftp 
pn  ncftp
pn  par2 
pn  python3-boto 
ii  python3-pip  18.1-5
pn  python3-swiftclient  
pn  tahoe-lafs   

-- no debconf information

Bug#942878: /usr/bin/lwr: "Fails" to download some base packages (btrfs-progs)

[Witold Baryluk]

Package: live-wrapper
Version: 0.10
Severity: important
File: /usr/bin/lwr

Dear Maintainer,

019:10:22T17:27:38ZUTC Calculate some file system statistics ...
2019:10:22T17:27:39ZUTC Size before compression: 20357 MiB
2019:10:22T17:27:41ZUTC Number of files: 547743
2019:10:22T17:27:41ZUTC Number of directories: 47625
DEBUG vmdebootstrap completed, see vmdebootstrap.log for details
INFO Downloading helper files from debian-installer team...
DEBUG Starting new HTTPS connection (1): d-i.debian.org:443
DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/ 
HTTP/1.1" 200 0
DEBUG Starting new HTTPS connection (1): d-i.debian.org:443
DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/vmlinuz 
HTTP/1.1" 200 0
DEBUG Starting new HTTPS connection (1): d-i.debian.org:443
DEBUG https://d-i.debian.org:443 "HEAD 
/daily-images/amd64/daily/cdrom/initrd.gz HTTP/1.1" 200 0
INFO Created GRUB directory at /tmp/tmpCYuhyP/boot/grub
DEBUG runcmd: ['mcopy', '-i', '/tmp/tmpCYuhyP/boot/grub/efi.img', '-s', 
'::/efi/*', '/tmp/tmpCYuhyP/EFI'] None {}
INFO Downloading installer files from debian-installer team...
DEBUG Created d-i kernel and ramdisk directory at /tmp/tmpCYuhyP/d-i
DEBUG Created d-i GTK kernel and ramdisk directory at /tmp/tmpCYuhyP/d-i/gtk
DEBUG Starting new HTTPS connection (1): d-i.debian.org:443
DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/ 
HTTP/1.1" 200 0
DEBUG Starting new HTTPS connection (1): d-i.debian.org:443
DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/vmlinuz 
HTTP/1.1" 200 0
DEBUG Starting new HTTPS connection (1): d-i.debian.org:443
DEBUG https://d-i.debian.org:443 "HEAD 
/daily-images/amd64/daily/cdrom/initrd.gz HTTP/1.1" 200 0
DEBUG Starting new HTTPS connection (1): d-i.debian.org:443
DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/gtk/ 
HTTP/1.1" 200 0
DEBUG Starting new HTTPS connection (1): d-i.debian.org:443
DEBUG https://d-i.debian.org:443 "HEAD 
/daily-images/amd64/daily/cdrom/gtk/vmlinuz HTTP/1.1" 200 0
DEBUG Starting new HTTPS connection (1): d-i.debian.org:443
DEBUG https://d-i.debian.org:443 "HEAD 
/daily-images/amd64/daily/cdrom/gtk/initrd.gz HTTP/1.1" 200 0
INFO Downloading udebs for Debian Installer...
DEBUG Updating local cache...
Fetching Debian Installer
Downloading udebs for Debian Installer...
Updating a local cache for amd64 bullseye ...
Get:1 acpi-modules-5.2.0-3-amd64-di_5.2.17-1_amd64.udeb [5312 B]
Fetched 5312 B in 0s (0 B/s)
...
Get:1 btrfs-modules-5.2.0-3-amd64-di_5.2.17-1_amd64.udeb [594 kB]   
Fetched 594 kB in 0s (0 B/s)
Get:1 btrfs-progs-udeb_5.2.1-1_amd64.udeb [378 kB]  
Fetched 378 kB in 0s (0 B/s)
...
Get:1 partman-btrfs_49_all.udeb [15.3 kB]   
Fetched 15.3 kB in 0s (0 B/s)   
...
Get:1 wide-dhcpv6-client-udeb_20080615-22_amd64.udeb [63.0 kB]  
Fetched 63.0 kB in 0s (0 B/s)
INFO ... completed udeb downloads
CRITICAL Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 193, in _run
self.process_args(args)
  File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 143, in process_args
self.start_ops()
  File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 304, in start_ops
handler.download_base_debs(pkg_list)
  File "/usr/lib/python2.7/dist-packages/lwr/apt_udeb.py", line 164, in 
download_base_debs
self.download_apt_file(pkg_name, pool_dir, True)
  File "/usr/lib/python2.7/dist-packages/lwr/apt_udeb.py", line 128, in 
download_apt_file
raise cliapp.AppException('Not able to download %s' % pkg_name)
AppException: Not able to download btrfs-progs

ERROR: Not able to download btrfs-progs
 
Get:1 wireless-tools-udeb_30~pre9-13+b1_amd64.udeb [12.2 kB]
Fetched 12.2 kB in 0s (0 B/s)   
...
Get:1 zlib1g-udeb_1.2.11.dfsg-1+b1_amd64.udeb [50.1 kB] 
Fetched 50.1 kB in 0s (0 B/s)   
... completed udeb downloads
Command exited with non-zero status 1
14828.96user 401.94system 37:09.79elapsed 683%CPU (0avgtext+0avgdata 
15040780maxresident)k
8294inputs+0outputs (57major+214336066minor)pagefaults 0swaps
+ ls -lh debian-live-testing-amd64-mate+tools+nonfree_2019-10-22T17:01:23.iso
ls: cannot access 
'debian-live-testing-amd64-mate+tools+nonfree_2019-10-22T17:01:23.iso': No such 
file or directory
#

Error message doesn't make much sense to me, but btrfs-progs and
btrfs-progs-udeb do exist in testing, and should be downloaded just fine.

Inspecting the code, it looks like it is finding versions, and newest
version, but not URI to it? The error message is 

Bug#941018: ibus 1.5.21-1 does not work with qt5 applications

[Gunnar Hjalmarsson]

Simon has prepared a fix of this issue via a glib merge request:

https://gitlab.gnome.org/GNOME/glib/merge_requests/1176

I applied the diff from that MR on top of glib2.0 2.62.1-1, and based on 
my limited tests it appears to fix the issue with IBus in Qt apps.


@Simon: Any thoughts on the status of your glib MR? Is it safe enough to 
patch glib2.0 in Debian, and with that fix this bug?


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

Bug#942877: goattracker sliently quits wiht exit code 1 on Debian Bullseye

[Svein Engelsgjerd]

Package: goattracker
Version: 2.75-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   Trying to start goattracker

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   run it under gdb. Goattracker quits with exit code 1

   * What was the outcome of this action?
   Goattracker did not start

   * What outcome did you expect instead?
   An error message explaining to me why goattracker does not start (and 
preferably a working goattracker)



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

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

Versions of packages goattracker depends on:
ii  libc62.29-2
ii  libgcc1  1:9.2.1-8
ii  libsdl1.2debian  1.2.15+dfsg2-5
ii  libstdc++6   9.2.1-8

goattracker recommends no packages.

Versions of packages goattracker suggests:
ii  milkytracker 1.02.00+dfsg-1
pn  opencubicplayer  
pn  schism   

-- no debconf information

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Pirate Praveen]

On Tue, Oct 22, 2019 at 19:02, Romain Bignon  wrote:

On 22/Oct - 19:18, Pirate Praveen wrote:
 This is building fine on my system. So uploaded binary included as 
work

 around.


Note that I see a newer version of gitlb available:

 root@weboob ~ # apt-cache policy gitlab
gitlab:
  Installed: 12.1.14-1
  Candidate: 12.1.14-1
  Version table:
 12.2.8-1 1
  1  experimental/contrib 
amd64 Packages

 *** 12.1.14-1 100
100 /var/lib/dpkg/status
 11.8.10+dfsg-1 -1
 -1  unstable/contrib amd64 
Packages


But it is not possible to install it as there are broken dependencies:

 root@weboob ~ # apt install gitlab/experimental
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '12.2.8-1' (Debian:experimental [all]) for 'gitlab'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gitlab : Depends: ruby-invisible-captcha (>= 0.12.1~) but it is not 
installable
  Depends: ruby-gitlab-sidekiq-fetcher (>= 0.5.1~) but 
0.4.0-2 is to be installed

  Depends: ruby-redis (>= 4.0~) but 3.3.5-1 is to be installed
  Depends: ruby-gitlab-labkit (>= 0.4.2-2~) but 0.4.2-1 is to 
be installed

  Depends: ruby-statistics but it is not installable
  Depends: ruby-gitaly (>= 1.58~) but 1.37.0+dfsg-1 is to be 
installed

E: Unable to correct problems, you have held broken packages.

Do you think you'll be able to upload a newer fixed version of gitaly 
soon? Or

is there any workaround?

All those packages are available in experimental. I have updated 
https://wiki.debian.org/gitlab with these packages added to the list of 
pcakges needed from experimental.



Romain

Bug#942114: cache fails to store capabilities correctly

[Antoine Beaupré]

On 2019-10-10 11:17:24, Antoine Beaupré wrote:
> Control: tags -1 +patch
>
> Here's a patch to fix this, also available in:
>
> https://salsa.debian.org/ganeti-team/ganeti-instance-debootstrap/merge_requests/1

I'm thinking of doing a NMU of this patch to unstable within the next
month if no one else comments here.

From there, if/when the package trickles down to testing, I'll ask the
release team to get the update down into stable as well.

A.

-- 
La nature n'a créé ni maîtres ni esclaves
Je ne veux ni donner ni recevoir de lois.
- Denis Diderot


signature.asc
Description: PGP signature

Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5

[Thomas Schmitt]

Hi,

Daniel Kahn Gillmor wrote:
> I would even posit that temporarily breaking jigdo would be better than
> keeping this additional bandwidth cost in play.

To my knowledge, jigdo is the only way to get full DVD sets or any BD sized
installation ISO from
  https://cdimage.debian.org/cdimage/release/current/amd64/

bt-* seems t have what iso-* has. Biggest is the 5.3 GB
debian-edu-10.1.0-amd64-BD-1.iso which would fit on a DVD+R DL, too.
Only the first three DVDs are offered by iso-* and bt-*.


Have a nice day :)

Thomas

Bug#942874: cross-gcc: Please make it source-only when making new uploads

[Boyuan Yang]

Source: cross-gcc
Version: 234
Severity: normal
X-Debbugs-CC: dko...@debian.org

Dear cross-gcc maintainer,

I noticed that all recent uploads of package cross-gcc were made with
maintainer-built binary packages, according to history information in 
https://tracker.debian.org/pkg/cross-gcc page.

As previously announced in 
https://lists.debian.org/debian-devel-announce/2019/07/msg2.html , britney
will reject migration when there are maintainer-built binary packages in the
upload. As a result, all cross-gcc builds after version 230 did not migrate to
testing. Please refer to https://wiki.debian.org/SourceOnlyUpload on how to
generate source-only uploads and make a source-only one with next upload.

Best,
Boyuan Yang