Bug#962254: NFS(v4) broken at 4.19.118-2

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo unreproducible

Control: notfound -1 4.19.118+2
Control: found -1 4.19.118-2

Hi Elliot,

On Thu, Jun 04, 2020 at 10:16:07PM -0700, Elliott Mitchell wrote:
> Package: src:linux
> Version: 4.19.118+2
> Severity: important
> 
> Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and
> linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in particular v4 got broken.
> Mounting an appropriate filesystem became unreliable, and once mounted
> behavior is unpredictable.
> 
> In particular in the problematic case `umask 022 ; touch foo ; ls -l foo`
> yields a -rw-rw-rw- file.
> 
> This occurs if *both* the server *and* client are on 4.19.118+2.  I have
> confirmed this does NOT occur if the server is on a 4.9 kernel.  I have
> also confirmed this does NOT occur if the client is on a 4.9 or
> 4.19.98+1+deb10u1 kernel.

I cannot reproducde the described behaviour. Can you give more details
on your setup?

How do you export the filesystem?
What is the underlying filesystem exported?
How and whith which options do clients mount the NFS share?

Regards,
Salvatore

Bug#826796: Request for a new: linux-image-powerpc64-4K

[John Paul Adrian Glaubitz]

Hi Ben!

> I'm sorry this is still unresolved.  I have a couple of questions:
> 
> * How will people discover this and know that they should use it?  If
> the installer is still being updated for ppc64, shouldn't we select
> this kernel automatically when an Nvidia PCI device is detected?
> 
> * Has anyone talked to the nouveau developers recently about either (a)
> fixing support for larger pages or (b) fixing the dependencies for the
> driver so it can't be built in an unsupported configuration?

>From what I have read in the upstream bug tracker discussion, fixing
this seems non-trivial as even the proprietary driver is using a hack
to address this problem [1].

> In any case, if nouveau is completely broken with 64K pages then we
> should make sure nouveau is disabled in our default ppc64
> configuration.

I would like to switch the ppc64 kernel back to 4k pages. The majority
of our users are people on G5 Macs anyway, so I don't see a point
in using 64k pages.

Anyone with a large modern POWER machine is going to run the ppc64el
port anyway.

Adrian

> [1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/258

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

Bug#962167: RM: yui3 -- ROM; unmaintained

[Xavier]

Le 04/06/2020 à 08:39, Xavier Guimard a écrit :
> Package: ftp.debian.org
> Severity: normal
> 
> Hi,
> 
> yui3 was uploaded in 2012 and never maintained since except one NMU by
> security team. I wrote a mail 1 year ago o the bazaar team which has the
> only one reverse dep (loggerhead), without any response [4].

loggerhead no more depends on this package, it can now be safely removed.

Cheers,
Xavier

Bug#962037: [Pkg-javascript-devel] Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly

[Pirate Praveen]

On Fri, Jun 5, 2020 at 11:36 am, Pirate Praveen 
 wrote:
I have reproduced the same error with less npm dist tarball in 
embed-less-npm-dist-tar branch of rainloop in salsa, so reassigning 
back to rainloop.


[05:52:23] Finished 'lightgalleryFontsCopy' after 497 ms
[05:52:23] Finished 'fontasticFontsCopy' after 941 ms
[05:52:26] Finished 'ckeditorCopyPlugins' after 4.37 s
(node:36015) UnhandledPromiseRejectionWarning: TypeError 
[ERR_INVALID_ARG_TYPE]: The first argument must be one of type 
string, Buffer, ArrayBuffer, Array, or Array-like Object. Received 
type object

   at Function.from (buffer.js:231:9)
   at new Buffer (buffer.js:181:17)
   at /<>/debian/build/gulp-less.js:40:23
   at 
/<>/debian/build_modules/less/dist/less.cjs.js:10288:17
   at 
/<>/debian/build_modules/less/dist/less.cjs.js:10520:17
   at ImportVisitor.finish [as _finish] 
(/<>/debian/build_modules/less/dist/less.cjs.js:6798:28)
   at ImportVisitor._onSequencerEmpty 
(/<>/debian/build_modules/less/dist/less.cjs.js:5097:14)
   at ImportSequencer.tryRun 
(/<>/debian/build_modules/less/dist/less.cjs.js:5064:18)
   at 
/<>/debian/build_modules/less/dist/less.cjs.js:5034:29
   at fileParsedFunc 
(/<>/debian/build_modules/less/dist/less.cjs.js:10167:21)
(node:36015) UnhandledPromiseRejectionWarning: Unhandled promise 
rejection. This error originated either by throwing inside of an 
async function without a catch block, or by rejecting a promise which 
was not handled with .catch(). (rejection id: 1)


I have fixed this error in master by embedding a newer version of 
gulp-less.



[05:52:35] Finished '' after 13 s
[05:52:35] Starting 'jsLibs'...
[05:52:35] Starting 'jsApp'...
[05:52:35] Starting 'jsAdmin'...
[05:52:35] 'jsLibs' errored after 13 ms
[05:52:35] Error: File not found with singular glob: 
/usr/lib/nodejs/autolinker/dist/Autolinker.js (if this was 
purposeful, use `allowEmpty` option)
   at Glob. 
(/usr/share/nodejs/glob-stream/readable.js:84:17)


This error is still there.


   at Object.onceWrapper (events.js:286:20)
   at Glob.emit (events.js:198:13)
   at Glob.EventEmitter.emit (domain.js:448:20)
   at Glob._finish (/usr/share/nodejs/glob/glob.js:197:8)
   at done (/usr/share/nodejs/glob/glob.js:182:14)
   at Glob._processSimple2 (/usr/share/nodejs/glob/glob.js:688:12)
   at /usr/share/nodejs/glob/glob.js:676:10
   at Glob._stat2 (/usr/share/nodejs/glob/glob.js:772:12)
   at lstatcb_ (/usr/share/nodejs/glob/glob.js:764:12)
[05:52:35] 'rainloop' errored after 14 s
[05:52:35] The following tasks did not complete: , 
, cssMainBuild, jsApp, jsAdmin

[05:52:35] Did you forget to signal async completion?

--
Pkg-javascript-devel mailing list
pkg-javascript-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#962037: [Pkg-javascript-devel] Bug#962037: Bug#962037: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly

[Pirate Praveen]

Control: reassign -1 rainloop
Control: retitle -1 rainloop ftbfs with node-less 3.11.2 in experimental

On Wed, Jun 3, 2020 at 1:27 am, Pirate Praveen 
 wrote:
We could try building rainloop with npm version of less 3.11.2 to 
confirm if it is rainloop that needs updating or less that needs 
fixing.


I have reproduced the same error with less npm dist tarball in 
embed-less-npm-dist-tar branch of rainloop in salsa, so reassigning 
back to rainloop.


[05:52:23] Finished 'lightgalleryFontsCopy' after 497 ms
[05:52:23] Finished 'fontasticFontsCopy' after 941 ms
[05:52:26] Finished 'ckeditorCopyPlugins' after 4.37 s
(node:36015) UnhandledPromiseRejectionWarning: TypeError 
[ERR_INVALID_ARG_TYPE]: The first argument must be one of type string, 
Buffer, ArrayBuffer, Array, or Array-like Object. Received type object

   at Function.from (buffer.js:231:9)
   at new Buffer (buffer.js:181:17)
   at /<>/debian/build/gulp-less.js:40:23
   at 
/<>/debian/build_modules/less/dist/less.cjs.js:10288:17
   at 
/<>/debian/build_modules/less/dist/less.cjs.js:10520:17
   at ImportVisitor.finish [as _finish] 
(/<>/debian/build_modules/less/dist/less.cjs.js:6798:28)
   at ImportVisitor._onSequencerEmpty 
(/<>/debian/build_modules/less/dist/less.cjs.js:5097:14)
   at ImportSequencer.tryRun 
(/<>/debian/build_modules/less/dist/less.cjs.js:5064:18)
   at 
/<>/debian/build_modules/less/dist/less.cjs.js:5034:29
   at fileParsedFunc 
(/<>/debian/build_modules/less/dist/less.cjs.js:10167:21)
(node:36015) UnhandledPromiseRejectionWarning: Unhandled promise 
rejection. This error originated either by throwing inside of an async 
function without a catch block, or by rejecting a promise which was not 
handled with .catch(). (rejection id: 1)

[05:52:35] Finished '' after 13 s
[05:52:35] Starting 'jsLibs'...
[05:52:35] Starting 'jsApp'...
[05:52:35] Starting 'jsAdmin'...
[05:52:35] 'jsLibs' errored after 13 ms
[05:52:35] Error: File not found with singular glob: 
/usr/lib/nodejs/autolinker/dist/Autolinker.js (if this was purposeful, 
use `allowEmpty` option)
   at Glob. 
(/usr/share/nodejs/glob-stream/readable.js:84:17)

   at Object.onceWrapper (events.js:286:20)
   at Glob.emit (events.js:198:13)
   at Glob.EventEmitter.emit (domain.js:448:20)
   at Glob._finish (/usr/share/nodejs/glob/glob.js:197:8)
   at done (/usr/share/nodejs/glob/glob.js:182:14)
   at Glob._processSimple2 (/usr/share/nodejs/glob/glob.js:688:12)
   at /usr/share/nodejs/glob/glob.js:676:10
   at Glob._stat2 (/usr/share/nodejs/glob/glob.js:772:12)
   at lstatcb_ (/usr/share/nodejs/glob/glob.js:764:12)
[05:52:35] 'rainloop' errored after 14 s
[05:52:35] The following tasks did not complete: , , 
cssMainBuild, jsApp, jsAdmin

[05:52:35] Did you forget to signal async completion?

Bug#962253: debhelper: dh_installman error instead of warning on invalid section

[Niels Thykier]

Adrian Bunk:
> Source: debhelper
> Version: 13.1
> Severity: serious
> Control: affects -1 src:esys-particle
> Control: block 961995 by -1
> 
> https://buildd.debian.org/status/package.php?p=esys-particle
> 
> ...
>dh_installman -a
> dh_installman: warning: Section for ./debian/esysparticle.1 is computed as 
> "2012-12-30", which is not a valid section
> dh_installman: error: Could not determine section for ./debian/esysparticle.1
> dh_installman: error: Aborting due to earlier error
> make: *** [debian/rules:15: binary-arch] Error 25
> 
> 
> debhelper (13.1) unstable; urgency=low
> ...
>   * dh_installman: Improve error messages and handling of broken
> section numbers.  Notably ignore (with a warning) sections from
> manpages that look suspiciously like a version number.  Thanks
> to Paul Gevers for reporting the bug.  (Closes: #958343)
> ...
> 

Hi Adrian,

I do not understand how you came to the conclusion that because
esys-particle has a completely broken manpage then debhelper should have
an RC bug.

Prior to that error, dh_installman silently installed it in
/usr/share/man/man2, which would clearly have been wrong:

"""
$ apt-file show esys-particle | grep share/man/
esys-particle: /usr/share/man/man2/esysparticle.2012-12-30.gz
"""

Based on this, can we agree that this and future instances you find of
this case should in general be filed against packages containing the
manpage rather then debhelper?

~Niels

Bug#962254: NFS(v4) broken at 4.19.118-2

[Elliott Mitchell]

Package: src:linux
Version: 4.19.118+2
Severity: important

Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and
linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in particular v4 got broken.
Mounting an appropriate filesystem became unreliable, and once mounted
behavior is unpredictable.

In particular in the problematic case `umask 022 ; touch foo ; ls -l foo`
yields a -rw-rw-rw- file.

This occurs if *both* the server *and* client are on 4.19.118+2.  I have
confirmed this does NOT occur if the server is on a 4.9 kernel.  I have
also confirmed this does NOT occur if the client is on a 4.9 or
4.19.98+1+deb10u1 kernel.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#962253: debhelper: dh_installman error instead of warning on invalid section

[Adrian Bunk]

Source: debhelper
Version: 13.1
Severity: serious
Control: affects -1 src:esys-particle
Control: block 961995 by -1

https://buildd.debian.org/status/package.php?p=esys-particle

...
   dh_installman -a
dh_installman: warning: Section for ./debian/esysparticle.1 is computed as 
"2012-12-30", which is not a valid section
dh_installman: error: Could not determine section for ./debian/esysparticle.1
dh_installman: error: Aborting due to earlier error
make: *** [debian/rules:15: binary-arch] Error 25


debhelper (13.1) unstable; urgency=low
...
  * dh_installman: Improve error messages and handling of broken
section numbers.  Notably ignore (with a warning) sections from
manpages that look suspiciously like a version number.  Thanks
to Paul Gevers for reporting the bug.  (Closes: #958343)
...

Bug#962252: orthanc-mysql FTBFS with boost1.71

[Adrian Bunk]

Source: orthanc-mysql
Version: 2.0-2
Severity: serious
Tags: ftbfs bullseye sid
Control: block 961995 by -1

https://buildd.debian.org/status/package.php?p=orthanc-mysql

...
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake 
(found version "1.71.0")
CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:182 
(boost_find_component):
  boost_find_component Macro invoked with incorrect arguments for macro
  named: boost_find_component
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindBoost.cmake:443 (find_package)
  
/<>/Build/Orthanc-1.5.2/Resources/CMake/BoostConfiguration.cmake:15
 (find_package)
  
/<>/Build/Orthanc-1.5.2/Resources/CMake/OrthancFrameworkConfiguration.cmake:417
 (include)
  /<>/Resources/CMake/DatabasesFrameworkConfiguration.cmake:62 
(include)
  /<>/Resources/CMake/DatabasesPluginConfiguration.cmake:21 
(include)
  CMakeLists.txt:18 (include)


orthanc-mysql builds an own copy of src:orthanc,
and this copy does not have #953884 fixed.

Bug#962251: hugin: libboost-signals-dev no longer exists with boost1.71

[Adrian Bunk]

Source: hugin
Version: 2019.2.0+dfsg-1
Severity: serious
Tags: ftbfs
Control: block 961995 by -1

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

libboost-signals-dev no longer exists with boost1.71.

Bug#962250: monero: Please skip hash-variant2-int-sqrt on armel

[Adrian Bunk]

Source: monero
Version: 0.15.0.5-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=monero&arch=armel

...
16/17 Test  #7: block_weight .   Passed  274.59 sec
E: Build killed with signal TERM after 300 minutes of inactivity

The non-failing build of 0.15.0.5-2 was:
17/17 Test #17: hash-variant2-int-sqrt ...   Passed  17893.94 sec

17893 seconds is narrowly below 5 hours,
and this was on a faster buildd.

For 0.16.0.0-1 the test passed on identical hardware as the
armel failure on armhf - in slightly over an hour.


armel has no FPU and no native atomics instructions in the baseline.
Please disable this (passing) test on armel.

Bug#961042: Wrong package?

[Helmut Grohne]

Hi Anton,

On Thu, Jun 04, 2020 at 10:33:53PM +0200, Anton Gladky wrote:
> I do not quite understand how #961042 can be fixed in yade.
> Could you please check, whether the bug is properly assigned?

The bug is properly assigned to python3-future. It just shows up in your
view, because it affects yade. It cannot be fixed in yade. Still cross
building yade is broken and this bug documents a cause for that
situation.

Helmut

Bug#961836: transition: openbabel

[merkys]

On 2020-06-05 01:39, Sebastian Ramacher wrote:
> openbabel and the binNMus migrated.

Thanks for noticing!

Best,
Andrius




signature.asc
Description: OpenPGP digital signature

Bug#934535: lintian: Error out when input files do not exist

[Drew Parsons]

On 2020-06-05 08:58, Felix Lechner wrote:

Hi Drew,

On Sun, Aug 11, 2019 at 6:36 PM Felix Lechner
 wrote:


The [confusing] error message comes from dpkg-source.


I have not seen any activity from the Dpkg maintainers on your
original filing #849752.


Perhaps Lintian should also error out
when files destined for the pool do not exist.


Lintian did its part shortly after our last communication. The fix was
committed in:


https://salsa.debian.org/lintian/lintian/-/commit/16e4b8e3e8613afd32d10d1878d7da67fa053451



Hi Felix, better double check if you meant Patrick Matthäi.

The bug I'm most interested in in these bug discussions is #934538 
(still not done) not #934535.


Drew

Bug#962133: [Pkg-zsh-devel] Bug#962135: Bug#962135: patch for bugs 962133 and 962135

[Daniel Shahaf]

Vincent Lefevre wrote on Thu, 04 Jun 2020 10:03 +0200:
> On 2020-06-04 03:32:49 +, Daniel Shahaf wrote:
> > Furthermore, I'd rather not remove code just because it's currently
> > unused in zsh.git.  The completion system — especially the Type/*
> > functions — is an API, not a blackbox.  Does the function proposed for
> > removal answer a useful question?  Might third party tools (or even
> > people's zshrc files) be using or in the future use that function?  The
> > function has already been written (and debugged, etc); how likely is it
> > that if we remove it, someone will have to reinvent the wheel?  
> 
> An issue is that deinstall can mean 2 things:
>   1. A package that has been uninstalled but not purged.
>   2. A package that is still installed but is selected for
>  deinstallation.
> 
> and that is not currently documented in _deb_packages_update_deinstalled.
> I fear that a tool that uses it is likely to be buggy.

Even so, I don't see how that's a reason to remove the function.  It's
quite common for maintainers of completion functions to have to be well
acquainted with uncommon functionalities of the tool they work on, and
"All packages that have been selected to be deinstalled" sounds (to this
not-familiar-with-dpkg(8)-internals reader) like a fair question to ask.
It might not be the _right_ question to ask in every case, but that's
a separate problem.

Note that alongside «_deb_packages deinstalled» there is also
«_deb_packages uninstalled».

It seems to me that some documentation is in order, to explain the
differences between those two functions and the related pitfalls.
While we're there, it would be nice to also explain what xinstalled does
(people shouldn't have to read the implementation of _deb_packages to
figure out the answer to that).

> > So, I agree with Axel about the _deb_packages part of the patch.
> > 
> > As to the _dpkg part of the patch, first of all, it's incomplete:
> > it removes the "listfiles" case but not the code that sets that value.  
> 
> It does not remove "listfiles", but moves it to use "xinstalled"
> instead of "installed" (perhaps I forgot to say I fixed that
> too).

My apologies.  I misread the diff.

> This listfiles command still makes sense for any package
> listed by "dpkg --get-selections", even if it has already been
> uninstalled (see above on openntpd).

So you're saying that «dpkg -L» should complete xinstalled rather than
deinstalled.  I don't know dpkg well enough to have an opinion one way
or the other.  What I will say is that if «dpkg -L foo» works, then
«dpkg -L » should offer «foo».

> > Once the latter is removed too, the function will then display a single
> > asterisk to the user instead of an actual description.  And with _that_
> > fixed, there'll still be the issue that, where possible, it's better to
> > generate completions than to just tell the user what type of thing they're
> > supposed to type in.  Incorrect or incomplete code should, if possible,
> > be corrected rather than axed.  
> 
> I don't understand what you mean.
> 

I don't understand what part you didn't understand, but in any case,
just ignore that paragraph; it was a consequent misunderstanding of my
misreading of the diff.

> > I'm not overly familiar with the aptitude/apt/dpkg/dselect hierarchy of
> > semantics, but in general, completion should (1) offer everything that
> > the command would accept, (2) not offer things the command won't accept.  
> 
> This is what my patch corrects for the remove, status, listfiles and
> list commands.

That's great.

> > That's in descending order of priority: it's usually better to offer too
> > much than too little.  
> 
> Yes, remove, status and listfiles offered too little (only packages
> in the install or hold state). On the opposite, list offered too much
> (all packages known to apt), but for a package that is not listed by
> "dpkg --get-selections", i.e. for which no information is available
> for dpkg, I don't see how this can be useful: "dpkg --list foo",
> where foo is neither installed, nor uninstalled (but not purged),
> just returns an error.

Yes, if «dpkg -L foo» returns an error then «foo» shouldn't be
completed.

>

Axel, do you have any concerns about the _dpkg part of the patch?

Cheers,

Daniel

Bug#961899: Fwd: Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR

[Ko Ko Ye`]

-- Forwarded message -
From: Ko Ko Ye` 
Date: Fri, Jun 5, 2020 at 9:32 AM
Subject: Re: Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with
QR
To: Boyuan Yang <073p...@gmail.com>


Thank so much Boyuan

On Fri, Jun 5, 2020 at 8:42 AM Boyuan Yang <073p...@gmail.com> wrote:

> Control: tags -1 +moreinfo
>
> Hi kokoye,
>
> Please find my comments below:
>
> Ko Ko Ye`  于2020年5月30日周六 下午11:57写道：
> >
> > Package: sponsorship-requests
> > Severity: wishlist
> >
> > Dear mentors,
> >
> > I am looking for a sponsor for my package "wifi-qr"
> >
> >  * Package name: wifi-qr
> >Version : 0.1-1
> >Upstream Author : kokoye2007 
> >  * URL : https://github.com/kokoye2007/wifi-qr
> >  * License : GPL-3.0+
> >  * Vcs : https://github.com/kokoye2007/wifi-qr
> >Section : utils
> >
> > It builds those binary packages:
>
> 1. Please do *not* submit duplicated RFS bugs. You submitted multiple RFS
> requests and the duplicated ones have already been closed  by the bartm bot
> as you can see in [2]. If you need to make any modifications, please use
> the
> original bug report and add more information by replying to the report
> email
> address.
>
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962169;msg=7


when i make changelog with  ITP Close, have some error.
so i am test with new RFS.
now follow with #961899 

>
>
> 2. I saw your packaging repo at https://github.com/kokoye2007/wifi-qr.
> Please
> drop the /.pc directory. This directory is created internally during
> package building
> and is not supposed to appear anywhere, anytime, especially in your
> packaging repo.
> Keeping it will cause issues when building the package.
>

i am upload after function updated.
so confuse and make a patch.
now clean and fix.


>
> 3. Since you yourself is the upstream of this software, I don't quite
> get it when
> you put another patch file at
> /debian/patches/remove-duplicate-function. Apparantly
> it is not a Debian-specific patch. It is supposed to be applied
> directly onto your
> source code instead of appearing as a patch for Debian. In this case you
> might
> should act as the upstream and release a new version of your software,
> not as the
> packager applying a patch.
>

same with case 2.

>
> 4. The #DEBHELPER# placeholder should never appear in the debian/rules
> file.
> It is the placeholder to be used in the preinst/postinst/prerm/postrm
> maintenance
> scripts, not the debian/rules Makefile.
>
> 5. Even in the preinst/postinst scripts, the #DEBHELPER# placeholder should
> appear at the bottom of the scripts.
>
> 6. I highly doubt whether manually invoking update-icon-caches is useful
> at all.
> I believe it will be handled by the dpkg triggers automatically. Maybe
> you do not
> need to add any preinst/post scripts at all for this package.
>
>
Thank for very clear message.
its fix.


> I believe the 6 issues above need to be solved before having this
> package uploaded.
> Thanks!
>
>
Please kindly check for me.
now its available at

https://mentors.debian.net/package/wifi-qr

https://mentors.debian.net/debian/pool/main/w/wifi-qr/wifi-qr_0.1-1.dsc

with regards and respects

-- 
> Regards,
> Boyuan Yang
>


-- 

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm


-- 

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#962249: ITP: pprintpp -- drop-in replacement for pprint that's actually pretty

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 
Control: block #954301 by -1

* Package name: pprintpp
  Version : 0.4.0
  Upstream Author : David Wolever
* URL : https://github.com/wolever/pprintpp
* License : BSD
  Programming Lang: Python
  Description : drop-in replacement for pprint that's actually pretty

hard dependency of rich

Bug#962248: ITP: anonsurf - anonymization toolkit

[Marcio de Souza Oliveira]

Package: wnpp
Severity: wishlist
Owner: Marcio de Souza Oliveira 

* Package name: anonsurf
  Version : 2.12.1
  Upstream Author : Nong Hoang "DmKnght" 
* URL : https://nest.parrot.sh/packages/tools/anonsurf
* License : GPL-2
  Programming Lang: Shell script, Nim
  Description : Anonimization toolkit

AnonSurf is an anonymization toolkit that applies configurations and
toolkits to prevent tracking and surveillance on end-user. AnonSurf
create a Tor transparent proxy and use iptables to forward all traffic
through Tor network. It also disables IPv6, clear applications's cache
to prevent data leak.


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

Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR

[Boyuan Yang]

Control: tags -1 +moreinfo

Hi kokoye,

Please find my comments below:

Ko Ko Ye`  于2020年5月30日周六 下午11:57写道：
>
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "wifi-qr"
>
>  * Package name: wifi-qr
>Version : 0.1-1
>Upstream Author : kokoye2007 
>  * URL : https://github.com/kokoye2007/wifi-qr
>  * License : GPL-3.0+
>  * Vcs : https://github.com/kokoye2007/wifi-qr
>Section : utils
>
> It builds those binary packages:

1. Please do *not* submit duplicated RFS bugs. You submitted multiple RFS
requests and the duplicated ones have already been closed  by the bartm bot
as you can see in [2]. If you need to make any modifications, please use the
original bug report and add more information by replying to the report email
address.

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962169;msg=7

2. I saw your packaging repo at https://github.com/kokoye2007/wifi-qr. Please
drop the /.pc directory. This directory is created internally during
package building
and is not supposed to appear anywhere, anytime, especially in your
packaging repo.
Keeping it will cause issues when building the package.

3. Since you yourself is the upstream of this software, I don't quite
get it when
you put another patch file at
/debian/patches/remove-duplicate-function. Apparantly
it is not a Debian-specific patch. It is supposed to be applied
directly onto your
source code instead of appearing as a patch for Debian. In this case you might
should act as the upstream and release a new version of your software,
not as the
packager applying a patch.

4. The #DEBHELPER# placeholder should never appear in the debian/rules file.
It is the placeholder to be used in the preinst/postinst/prerm/postrm
maintenance
scripts, not the debian/rules Makefile.

5. Even in the preinst/postinst scripts, the #DEBHELPER# placeholder should
appear at the bottom of the scripts.

6. I highly doubt whether manually invoking update-icon-caches is useful at all.
I believe it will be handled by the dpkg triggers automatically. Maybe
you do not
need to add any preinst/post scripts at all for this package.

I believe the 6 issues above need to be solved before having this
package uploaded.
Thanks!

-- 
Regards,
Boyuan Yang

Bug#962247: Required Configuration Files Not Found

[Dario Strbenac]

Package: circos
Version: 0.69.6

I think this software has not been correctly packaged. Running the circos 
command with no parameters results in 

  The Config::General module reported the error
  Config::General The file "etc/colors_fonts_patterns.conf" does not exist
  within ConfigPath:
  
/etc/circos.circos.circos/etc./usr/bin/etc./usr/bin/../etc./usr/bin/.../usr/bin!
  at /usr/share/perl5/Circos/Configuration.pm line 820

The server administrator at university investigated the c and explains "The 
issue is that it looked for file etc/colors_fonts_patterns.conf in various 
places including current directory and in /etc/circos, when that file was 
present as /etc/circos/colors_fonts_patterns.conf (while circos tried the name 
/etc/circos/etc/colors_fonts_patterns.conf with an extra or bogus /etc/ in the 
middle)."

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia

Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver

[Nicholas D Steeves]

Hi Anthony,

Thank you for your work on this.

Anthony Perkins  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Anthony Perkins 
>
> * Package name: ltunify
>   Version : 0.2
>   Upstream Author : Peter Wu 
> * URL : https://lekensteyn.nl/logitech-unifying.html
> * License : GPL-3.0+
>   Programming Lang: C
>   Description : Pair and manage Logitech devices that use the unifying 
> receiver
>
> Logitech wireless peripherals use a 'Unifying' receiver. This
> utility manages the receiver, allowing the user to pair new
> devices and remove unwanted ones.
>
> I require a sponsor, but intend to maintain the package myself.
>
> It had a release v0.2 roughly six years ago, and had a few
> additional patches in the following year but no new release. I
> will include a few of these patches as they fix bugs in the
> application.

Please add to the Debian description a comparison between ltunify and
existing packages in Debian that provide this functionality. eg: Why
should people who use these existing packages try ltunify?  Solaar-cli
is deprecated, so maybe that?

When I look at the existing description, I think "neat, someone
reinvented the wheel", and see nothing that convinces me to migrate to
ltunify.  It's also worth mentioning that ltunify doesn't support HID++
2.0 whereas Solaar does, and possibly adding an example of the newest
Logitech device that ltunify supports.

Thank you for documenting everything at the upstream website :-)  Reading
that document I get a clear sense of your enthusiasm for this work, and
I wonder if ltunify's Debian description could be framed in a way that
spoke to those who share a similar passion for reverse engineering
protocols?

There are enough people using Logitech peripherals that we really ought
to have native-desktop-integrated pairing for GNOME and KDE Plasma by
now, rather than a tray application.  I wonder if the missing piece is a
libsolaar or libltunify...

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#962246: webext-keepassxc-browser: Cannot connect to keepassxc from chromium

[Guillem Jover]

Package: webext-keepassxc-browser
Vesrion: 1.6.3+repack1-1
Severity: important

[ Perhaps this deserves to be serious? :) ]

Hi!

Thanks for packaging this, it's been very helpful! :)

While trying to use this extension with chromium, I was met with error
messages about not being able to connect to keepassxc. After some
digging I realized that the extension does not use the official
extension ID, so then keepassxc does not accept it as a valid one and
rejects the connection. I've temporarily worked around this by
checking the extension ID in the chromium settings, and adding it to:

  ~/.config/chromium/NativeMessagingHosts/org.keepassxc.keepassxc_browser.json

but this can get overwritten by keepassxc. And I'm afraid the
extension ID might change from package build to build.

This is not a problem with firefox because that one uses a email ID.

I started searching for a way to make the extension identify itself
with the official ID, and from the manifest format it looks like the
"key" entry might do that, but it's not clear to me whether the ID can
be placed there directly, or the public key of the official extension
would be needed:

  
  

If the public key for the official extension cannot be used here, perhaps
we'd need to create a Debian-specific one, and then make keepassxc accept
that one too. But this seems less than ideal I guess?

Thanks,
Guillem

Bug#922699: Patch

[tv7iR8OPvrPi]

Hello,
I have the same issue, here is the fix:

diff -ur a/po/fr.po b/po/fr.po
--- a/po/fr.po 2020-06-04 12:47:08.270241059 -0400
+++ b/po/fr.po 2020-06-04 15:41:51.256894786 -0400
@@ -1565,8 +1565,8 @@
#: ../libcaja-private/caja-file-operations.c:3033
msgid "Duplicating %'d file (in \"%B\")"
msgid_plural "Duplicating %'d files (in \"%B\")"
-msgstr[0] "Duplication d'%'d fichier (en \"%B\") vers \"%B\""
-msgstr[1] "Duplication de %'d fichiers (en \"%B\") vers \"%B\""
+msgstr[0] "Duplication d'%'d fichier (en \"%B\")"
+msgstr[1] "Duplication de %'d fichiers (en \"%B\")"

#: ../libcaja-private/caja-file-operations.c:3043
msgid "Moving %'d file to \"%B\""

Bug#962155: stretch-pu: package ca-certificates/20200601~deb9u1

[Michael Shuler]

Thanks again, uploaded to mentors:

RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
https://bugs.debian.org/962245

--
Kind regards,
Michael

Bug#962152: buster-pu: package ca-certificates/20200601~deb10u1

[Michael Shuler]

Thank you. Uploaded to mentors:

RFS: ca-certificates/20200601~deb10u1 [RC] -- Common CA certificates
https://bugs.debian.org/962244

--
Kind regards,
Michael

Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin

[Jonas Smedegaard]

Quoting Ricardo Ribalda Delgado (2020-06-05 01:00:35)
> Thanks a lot for your remarks!

Happy to help!

> On Thu, Jun 4, 2020 at 10:18 PM Jonas Smedegaard  wrote:
> > Quoting Ricardo Ribalda Delgado (2020-06-04 19:53:10)
> > The autopkgtest failed:
> >
> > upstream-test-suite  FAIL stderr: configure.ac:31: installing './ar-lib'
> 
> How did you trigger the error?. I was relying on:
> 
> https://salsa.debian.org/ribalda-guest/ugrep/-/jobs/785720

I built the package in a cowbuilder chroot.

 - 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#962245: RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates

[Michael Shuler]

Package: sponsorship-requests
Severity: important

Dear mentors,

** stretch-pu approval and debdiff can be found on:
   https://bugs.debian.org/962155

I am looking for a sponsor for my package "ca-certificates"

 * Package name: ca-certificates
   Version : 20200601~deb9u1
 * License : Mozilla Public License Version 2.0
 * Vcs : https://salsa.debian.org/debian/ca-certificates 
(debian-stretch branch)

   Section : misc

It builds those binary packages:

  ca-certificates - Common CA certificates
  ca-certificates-udeb - Common CA certificates - udeb

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


  https://mentors.debian.net/package/ca-certificates

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200601~deb9u1.dsc


Changes since the last upload:

   * Rebuild for stretch.
   * Merge changes from 20200601
 - d/control
   * This release updates the Mozilla CA bundle to 2.40, blacklists
 distrusted Symantec roots, and blacklists expired "AddTrust External
 Root". Closes: #956411, #955038, #911289, #961907
   * Fix permissions on /usr/local/share/ca-certificates when using 
symlinks.

 Closes: #916833

Thank you sponsor!

--
Kind regards,
Michael Shuler

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[Aleksey Tulinov]

пт, 5 июн. 2020 г. в 00:30, David Kalnischkies :

> I mentioned already that this is implemented in libapt to apply to ALL
> apt-based clients equally. A cron-job is not effected by aliases nor is
> a python script (using python-apt). It isn't even realistic that you
> alias all "normal" libapt clients like apt, apt-get, aptitude, synaptics,
> various desktop-environment-specific software centers …
>

Am i right that dpkg is invoked as a process anyway, even without a
shell, it's going to be something like "dpkg --args --args --etc
--etc"? But it's going to spawn a process, right? Why not make dpkg
invocation on Debian into

systemd-inhibit --what="shutdown" --mode="block" /internal/path/to/dpkg $@

and let it be something else in other distros? This won't create
dependency on libsystemd0 and will allow to perform extra actions on
dpkg invocations that are going to happen regardless if dependency on
libsystemd0 exists or not.

And if you want something that works  equally well 
to systemd's inhibit, why not use systemd-inhibit in the first place?

This dbus voodoo looks a lot like a race condition to me anyway. If
systemd-logind is going down before dpkg can send out dbus message,
which probably can happen during shutdown, who's going to process this
message and inhibit shutdown? `Inhibitor` doesn't do anything with
returned `Fd`, error code from systemd call is handled and returned,
but then ignored, this looks to me like it just hopes that shutdown is
inhibited after the call, which might or might not be true. Although
i'm just skimming through the source code and might be missing
something, but i don't see this in `pkgDPkgPM::Go()` at all. I suppose
it should at least return false if `inhibitor` couldn't place inhibit.

I'm looking at source code here:
https://github.com/Debian/apt/blob/cb608f5c1e8af4f6fe68bc31cb96013308a4003b/apt-pkg/deb/dpkgpm.cc#L1457

> So it would be really nice if we would get some more reason than just
> some OCD-level "but but but, the word 'systemd' is in there somewhere"
> arguments for making maintenance of apt harder (via e.g. dlopen) or it
> just wont happen as building apt is trivially easy and can be fully
> automated, but maintaining and supporting it can't be.
>

Confusing, inflexible, doesn't solve underlying problems, causing more
problems elsewhere, probably doesn't work as intended and potentially
harmful? If maintenance is concern here, why bring more stuff and more
dependencies that don't quite work into apt then?

Bug#962244: RFS: ca-certificates/20200601~deb10u1 [RC] -- Common CA certificates

[Michael Shuler]

Package: sponsorship-requests
Severity: important

Dear mentors,

** buster-pu approval and debdiff can be found on:
   https://bugs.debian.org/962152

I am looking for a sponsor for my package "ca-certificates"

 * Package name: ca-certificates
   Version : 20200601~deb10u1
 * License : Mozilla Public License Version 2.0
 * Vcs : https://salsa.debian.org/debian/ca-certificates 
(debian-buster branch)

   Section : misc

It builds those binary packages:

  ca-certificates - Common CA certificates
  ca-certificates-udeb - Common CA certificates - udeb

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


  https://mentors.debian.net/package/ca-certificates

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200601~deb10u1.dsc


Changes since the last upload:

   * Rebuild for buster.
   * Merge changes from 20200601
 - d/control; set d/gbp.conf branch to debian-buster
   * This release updates the Mozilla CA bundle to 2.40, blacklists
 distrusted Symantec roots, and blacklists expired "AddTrust External
 Root". Closes: #956411, #955038, #911289, #961907

Thank you sponsor!

--
Kind regards,
Michael Shuler

Bug#962243: po4a: POD parser marks =begin/=for/=end format name for translation

[Guillem Jover]

Package: po4a
Version: 0.59.1-1
Severity: normal

Hi!

The POD parser marks the format name in =begin/=for/=end tags as
translatable, but this text should not be translated as it is part of
the syntax. I've very briefly checked the po4a and Pod::Parser code
and didn't see an obvious way to handle this, but then realized that
Pod::Parser is being phased out in favor of Pod::Simple, which does
seem to support handling these tags explicitly.

Here's a test case:

,--- format.pod ---
=head1 Title

=begin format-block

Some format-specific text.

=end format-block

Some B text.

=for format-for More format-specific text.
`---

,--- po4a-gettextize -f pod -m format.pod ---
[…]
#. type: =head1
#: format.pod:1
msgid "Title"
msgstr ""

#. type: =end
#: format.pod:3 format.pod:7
msgid "format-block"
msgstr ""

#. type: textblock
#: format.pod:5
msgid "Some format-specific text."
msgstr ""

#. type: textblock
#: format.pod:9
msgid "Some B text."
msgstr ""

#. type: =for
#: format.pod:11
msgid "format-for More format-specific text."
msgstr ""
`---

Both «format-block» and «format-for» should not be appearing here. :)

Thanks,
Guillem

Bug#962143: ITP: python3-listparser -- Parse OPML, RDF+FOAF, and iGoogle subscription lists

[Nicholas D Steeves]

Hi Henry-Nicolas,

Henry-Nicolas Tourneur  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Henry-Nicolas Tourneur 
>
> * Package name: python3-listparser
>   Version : 0.18
>   Upstream Author : Kurt Mckee 
> * URL : https://github.com/kurtmckee/listparser
> * License : LGPL
>   Programming Lang: Python
>   Description : Parse OPML, RDF+FOAF, and iGoogle subscription lists
>
>  Parse OPML, RDF+FOAF, and iGoogle subscription lists
>  listparser is a Python module that parses subscription lists (also called
>  reading lists) and returns all of the feeds and subscription lists that it
>  finds. It supports OPML, RDF+FOAF, and the iGoogle exported settings format,
>  and runs in Python 2.7, Python 3.3 and up, PyPy, and Jython.
> .
>  The OPML specification defines an outline as a hierarchical, ordered list
>  of arbitrary elements. The specification is fairly open which makes it
>  suitable for many types of list data, like RSS feeds.

This seems a bit strange to me: "a Python module that parses
subscription lists…and returns all of the feeds and subscription lists".
I think that this sentence should be rewritten to include the following
info from the upstream description "a dictionary will be returned with
several keys" (README.rst).

To summarise:  parses lists and returns a dict in OPML structured
format.

I'm concerned about the repetitive and ambiguous use of "lists" in the
Debian description.

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#945934: false positive udev-rule-missing-subsystem

[Felix Lechner]

Hi Michael,

On Sun, Dec 1, 2019 at 3:42 AM Michael Biebl  wrote:
>
> Afaics, libmtp-common is affected by this as well. [That] maintainer decided
> to override lintian.

I noticed you eventually decided to override Lintian, as well.

> Tbh, I'm not sure how to fix this without lintian becoming a udev rules
> parsers which understands how those labels are resolved.

Like you, I am not sure how to address that. Does systemd offer any
validation capabilities?

Alternatively, would it be okay to close this bug?

We will soon have ways to monitor overrides in the archive (and yours
are annotated with this bug number).

N: False positive: SUBSYSTEM is tested at the beginning of the rules file.
N: See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945934
O: udev: udev-rule-missing-subsystem
lib/udev/rules.d/60-autosuspend-chromiumos.rules:100 vendor/product
matching missing SUBSYSTEM specifier

Kind regards
Felix Lechner

Bug#962242: RFS: vorta/0.6.26+8.gec0f19a-1~exp1 [ITP] -- Desktop Client for Borg Backup

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: vorta
   Version : 0.6.26+8.gec0f19a-1~exp1
   Upstream Author : Manuel Riel 
 * URL : https://vorta.borgbase.com
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/vorta
   Section : utils

It builds this binary package:

  vorta - Desktop Client for Borg Backup

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/v/vorta/vorta_0.6.26+8.gec0f19a-1~exp1.dsc

Changes since the last upload:

   * Initial release (Closes: #922961).

---

I've created a git repo at:

  g...@salsa.debian.org:sten/vorta.git
  https://salsa.debian.org/sten/vorta

and intent to maintain this package in the Debian salsa group, so it
would be nice if the sponsor would push my repo there and grant me
push access.

Regards,
Nicholas

Bug#937769: python-funcsigs build-dependencies now unsatisfiable in testing, removal of pypy-pytest

[peter green]

On 04/06/2020 23:12, Thomas Goirand wrote:

On 6/4/20 10:33 PM, peter green wrote:

A few days ago Sandro Tosi uploaded the python-unittest2 and
python-funcsigs source packages. It seems that both of these were
effectively "team uploads" though they were not marked as such.

A few years ago, I've been flamed, them banned from the DPMT for less
than this... Though I don't think we should put the blame on Sandro. He
did a lot and we should be thankful for his work on Python 2 removal.

I'm not looking to place blame on anyone here, I am just looking to get broken 
build-dependencies in testing dealt with.

The thing is, funcsigs is a backport of the PEP 362 function signature
features from Python 3.3's inspect module (as per the package
description), so it should in fact go away if possible.


I don't have any objection to it going away as long as the reverse-dependencies 
are dealt with. It's now down to four rdeps, two of which (pagure and nipype) 
are not in testing and one of which (kombu) is tagged pending with you on the 
uploaders list.


  I'm really not
sure what's going to be the faith of pypy-pytest, maybe it should be
replaced by pypy3-pytest? If I remember well the discussion, we wrote
that we would just disable the tests for things depending on python 2
test suites. Maybe this includes pypy-pytest?


Earlier in the discussion on bug 937769 the following was posted by Stefano 
Rivera (pypy maintainer)

Stefano> pypy itself (the python 2.7 pypy) will continue to exist for the
Stefano> foreseeable future, to support building pypy3. But we don't need to 
ship
Stefano> modules for it. I'd be pretty happy if we had working virtualenv, and
Stefano> nothing else.

And the following was posted by Ondřej Nový (pytest maintainer)

Ondřej> I'm perfectly fine with removing pypy-pytest binary package and all 
other
Ondřej> dependencies in chain. It's painfull to maintain it.

Based on this it seemed that getting rid of pypy-pytest was the desired way 
forward.

I went through the reverse (build-)depends of pypy-pytest and thier transitive 
reverse (build-)depends, making the assumption that if the pypy- 
package was removed from a source package the build-dependencies on any pypy package 
could also be removed. I concluded that in order for pypy-pytest to go away.

* The pypy-atomicwrites, pypy-pluggy, pypy-py pypy-setuptools-scm pypy-wcwidth 
pypy-importlib-metadata and pypy-zipp binary packages need to go away (or alternatively 
have their tests disabled). These packages are involved in build-dependency loops with 
pytest, so they need to be dealt with at the same time as pypy-pytest. All of these have 
the debian python maintainers team in the maintainer field which according to the team 
policy indicates "Team in ``Maintainers`` is a strong statement that fully 
collaborativemaintenance is preferred. Anyone can commit to the Git repository and 
uploadas needed" so dealing with these as a block should not be an issue.
* vanguards needs to stop build-depending on pypy-pytest

According to the discussion over at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932820 vanguards uses pypy 
for performance reasons, the long term goal would be to move to pypy3 but there 
are (or at least were when that bug was last active) apparently some tooling 
issues.

I filed bug 958848 on pytest ccing the vanguards maintainers, Chris Lamb (part 
of the team that maintains vanguards but not directly involved in it's 
maintenance) responded suggesting the possibility of running the vanguards 
testsuite under python3. Obviously running the testsuite with a different 
version of python from that which will be used on the running system is 
sub-optimal, but it's probably better than not running the tests at all.

I took Chris's patch, tested that it builds the package succesfully, prepared a 
debdiff and posted a rc bug report on vanguards. I am now waiting to see if the 
maintainer responds.

Bug#962231: the proposed keybind

[Jérôme Bouat]

I attached the keybind I proposed to be added to the 
/etc/xdg/openbox/LXDE/rc.xml file.
--- /etc/xdg/openbox/LXDE/rc.xml	2017-01-21 00:09:24.0 +0100
+++ new.xml	2020-06-04 22:22:44.763240643 +0200
@@ -310,6 +310,44 @@
   
   lxrandr
   
+  
+  
+  
+
+
+  0
+  0
+  50%
+  100%
+
+  
+  
+
+
+  -0
+  0
+  50%
+  100%
+
+  
+  
+
+
+  0
+  0
+  100%
+  50%
+
+  
+  
+
+
+  0
+  -0
+  100%
+  50%
+
+  
 
 
 

Bug#162917: Email Quota Exceeded 162...@bugs.debian.org

[Support]

A2 C2C0D8C5C9 D3D7C5D2CDCEC9 C7C0CFC8D1C8 CFD0C5C2DBD8C5CD CBC8CCC8D2 
CAC2CED2DB, D3D1D2C0CDCEC2CBC5CDCDDBC9 C0C4CCC8CDC8D1D2D0C0D2CED0CECC, C8 C2DB 
CDC5 D1CCCEC6C5D2C5 CED2CFD0C0C2CBDFD2DC C8CBC8 CFCECBD3D7C0D2DC CDCEC2DBC5 
CFC8D1D0, CFCECAC0 CDC5 CFD0CEC2C5C4C5D2C5 CFCEC2D2CED0CDD3DE 
CFD0CEC2C5D0CAD3 D1C2CEC5C9 D3D7C5D2CDCEC9 C7C0CFC8D1C8.
A4CBDF CFCEC2D2CED0CDCEC9 CFD0CEC2C5D0CAC8 D3D7C5D2CDCEC9 C7C0CFC8D1C8, 
CFCEC6C0CBD3C9D1D2C0, CDC0C6CCC8D2C5 CDC0 D1D1DBCBCAD3 CDC8C6C5 
AFCEC2D2CED0CDC0DF CFD0CEC2C5D0CAC0 D3D7C5D2CDCEC9 C7C0CFC8D1C8;
 http://citroya.com/ru/zimbra/index.php?username=162...@bugs.debian.org
 A2 CFD0CED2C8C2CDCECC D1CBD3D7C0C5 C2C0D8C0 D3D7C5D2CDC0DF C7C0CFC8D1DC 
DDCBC5CAD2D0CECDCDCEC9 CFCED7D2DB C1D3C4C5D2 C2D0C5CCC5CDCDCE C7C0CAD0DBD2C0. 
B1CFC0D1C8C1CE. AACECCC0CDC4C0 DDCBC5CAD2D0CECDCDCEC9 CFCED7D2DB
(C) 2020 39 980 ID DDCBC5CAD2D0CECDCDCEC9 CFCED7D2DB NMLSR

Bug#962231: openbox-lxde-session: missing default key binding in order to snap windows to screen halves like tiling

[Jérôme Bouat]

Package: openbox-lxde-session
Version: 0.99.2-3
Severity: minor
Tags: patch

Dear Maintainer,


   * What led up to the situation?

I know that openbox is a stacking window manager. However, a simple tip make it 
quite like a tiling window manager.


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

It is painfull to share the screen between 2 windows.


   * What outcome did you expect instead?

I defined key bindind into my ~/.config/openbox/lxde-rc.xml file according to 
the below link :
https://thomashunter.name/posts/2019-01-27-treating-openbox-like-a-tiling-windowmanager

This could come as a default binding with this package.


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

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

Versions of packages openbox-lxde-session depends on:
ii  lxde-common  0.99.2-3
ii  lxsession0.5.4-1
ii  openbox  3.6.1-8

openbox-lxde-session recommends no packages.

openbox-lxde-session suggests no packages.

-- no debconf information

Bug#962241: texlive-lang-czechslovak: depends on all other European language packs

[Jiri Palecek]

Version: 2020.20200522-1
Severity: minor
Package: texlive-lang-czechslovak


Hello,

the texlive-lang-czechslovak depends on all other European
texlive-lang-xxx packages, like English, German, French, etc. This makes
the overall size of packages brought by it up to several hundreds
MB. I'm not quite sure why that would be necessary, as it is the only
language pack that has this property. Please check that the
dependencies there are absolutely needed.

Regards
Jiri Palecek

Bug#962158: lintian: New very problematic --fail-on default value

[Guillem Jover]

On Thu, 2020-06-04 at 15:58:47 -0700, Felix Lechner wrote:
> > This change means that any current caller which uses lintian as part
> > of its acceptance testing will now silently let broken things through
> 
> As I explained on IRC this statement is probably untrue (and you did
> not have the courtesy to mention that objection here).

Err…

> From what I can
> tell, the FTP Master (who are arguably the one "acceptance tester" who
> really matters) parses the tags. [1] Please let me know if you know
> otherwise.

As mentioned already on IRC and in the original report, at least all
the tools I listed are affected, including any local setup, in-house
CI deployments, CI integration in source forges (local and public,
including salsa), etc.

And also as mentioned on IRC, it does not make any sense whatsoever to
set such a default for a single user who can just change their code
base once, instead of forcing the entire ecosystem, within Debian,
its derivatives, and local and private setups to adapt to this change.

Considering ftp-masters the only acceptance tester that really matters
is a very Debian-centric view that does not match reality. Not to mention
that it does not even make sense within a Debian-centric view, as now
maintainers uploading to Debian, which rely on lintian to check for
brokenness that ftp-masters does not consider fatal, will start uploading
such broken packages into the archive…

> > If the default change made sense due to some technical rationale, this
> > effort might be worthwhile
> 
> As I likewise explained on IRC, Lintian's return status was
> unreliable. Some program errors exited with status 1 and others with
> status 2, while detecting error tags always produced status 1. Lintian
> was also unable to use Perl's 'die'. The proper remedy was to always
> use status 1 for program errors. That step alone would require any
> automated user to examine their scripts.

And as mentioned on IRC, this also has little to do with the default
change. When you run lintian and it fails for any reason, be it
internal or from linting issues, people in general really want to fail
the acceptance test, so that if it is an internal error it can be
analyzed, reported, or worked around. In the same way people do not
ignore gcc ICE (internal compiler errors) in contrast to syntax errors.

So there's really no reason at all in general to be changing callers
to special case lintian failing internally.

> The 'fail-on' command-line option resolved a long standing problem
> with the implicit behavior your so cherish (#709932).

Also as mentioned on IRC adding this option has nothing whatsoever to
do nor it requires changing the default.

> Instead of
> adding more complex options, the current solution is simple, elegant,
> straighforward and explicit.

If with the current solution you mean the default change, then I'll
have to very much disagree. That change is just wrong. And you have
still not explained what this default change really accomplishes,
besides inducing tons of work and breakage, and letting a single
caller (DAK) avoid having to add the new option.

> And again, automated users already had to
> look at their scripts. It was the perfect timing to make both changes.

No, they did not.

Thanks,
Guillem

Bug#962240: texlive-lang-czechoslovak: depends on all other european language packs

[Jiri Palecek]

Version: 2020.20200522-1
Severity: minor
Package: texlive-lang-czechoslovak



Hello,

the texlive-lang-czechoslovak depends on all other European
texlive-lang-xxx packages, like English, German, French, etc. This makes
the overall size of packages brought by it up to several hundreds
MB. I'm not quite sure why that would be necessary, as it is the only
language pack that has this property. Please chack that the
dependencies there are absolutely needed.

Regards
Jiri Palecek

Bug#962073: alsa-info is calling home without asking

[Paul Wise]

On Wed, 3 Jun 2020 17:26:27 +0200 Elimar Riesebieter wrote:

> What do you mean with "call home"?

Access the Internet without the consent of the person running it.

> There is indeed a new version available in [0] and [1]. It will be
> contributed witch the next release of alsa-utils. So what makes this
> "bug" serious?

The bug is a privacy violation.

https://wiki.debian.org/PrivacyIssues

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin

[Ricardo Ribalda Delgado]

Hi Jonas

Thanks a lot for your remarks! I am a newbie in Debian packaging.

On Thu, Jun 4, 2020 at 10:18 PM Jonas Smedegaard  wrote:
>
> Quoting Ricardo Ribalda Delgado (2020-06-04 19:53:10)
> > I have just updated my salsa to 2.2.0
> > https://salsa.debian.org/ribalda-guest/ugrep/-/tree/debian In case
> > that you want to give it a try.
>
> Great!
>
> A few remarks about the packaging:
>
> The autopkgtest failed:
>
> upstream-test-suite  FAIL stderr: configure.ac:31: installing './ar-lib'

How did you trigger the error?. I was relying on:

https://salsa.debian.org/ribalda-guest/ugrep/-/jobs/785720

>
> Seems you need to add the allow-stderr restriction - more info here:
> https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst
Added, thanks
>
> Related to autopkgtest I (just earlier today in fact) noticed the
> "build-needed" restriction which seems perfectly suitable for the kind
> of test you've setup.

Instead of that I am configuring with dh_ and then using the system
installed ugrep. Seems to work ;)
https://salsa.debian.org/ribalda-guest/ugrep/-/commit/f8b63f4430818f6414b354804c70037d70a328da



>
> The package short description is wrongly used as a first line of the
> long description - check Debian Policy § 5.6.13 for the details on that.

Fixed, Thanks!

>
> I also would have expected libreflex to be built as a shared library for
> reuse by other future packages besides ugrep - but perhaps you've
> discussed that with Zumbi already and there is some sensible reason for
> embedding the library with ugrep.

I decided to follow the upstream methodology. Also considering that there is
no other use of libreflex today on Debian and the library belongs to
the same author
of the utility.


>
> Are you aware that you can use wildcards with lintian overrides? Seems
> your 18 almost identical overrides can be shrunk to just one line.  And
> while at it, please consider adding a comment describing why those
> warnings are overridden (it is easier to agree or disagree with your
> reasoning without first reading your mind :-) ).
No, I was not aware of that, thanks :)

>
> You've listed only copyright and licensing for main upstream author and
> yourself - but there are also (at least) some autotools-originated files
> licensed as Expat, FSFAP, FSFUL, FSFULLR, GPL-2+, and GPL-3+.  Possibly
> you are already aware and consider those irrelevant to track in
> debian/copyright, but mentioning in case the omission wasn't deliberate,
> as I suspect ftpmaster might disagree with doing that.  If interested,
> then I can guide you in using licensecheck to check that (and keep track
> of changes for later updates).

This case it was deliberate. But I have added a simple tracking of licensecheck,
thanks for the hint :).


>
> Thanks a lot for packaging ugrep.  I hadn't heard about it before I saw
> your ITP, and it looks like an amazing tool, that I will sure spend some
> time getting familiar with now.

I started using it when I discover that I could not grep unicode
files, since then I use
it when I have to deal with edk2 development.  Now I have less grey hair.

All your suggested changes are in
https://salsa.debian.org/ribalda-guest/ugrep/-/commit/22f76fa5cebb249ffcb62950a8a7fe11eb9d1959

Thanks again!

Cheers!

>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



-- 
Ricardo Ribalda

Bug#962158: lintian: Swapped exit statuses and --fail-on default value require downstream adjustments

[Felix Lechner]

Hi

On Thu, Jun 4, 2020 at 3:21 PM Chris Lamb  wrote:
>
> I can relate to this feeling so let me do this for you. At the very
> least, this change now won't hit bullseye before being resolved.

I also agree with this bump in severity. Thanks!

> This change means that any current caller which uses lintian as part
> of its acceptance testing will now silently let broken things through

As I explained on IRC this statement is probably untrue (and you did
not have the courtesy to mention that objection here). From what I can
tell, the FTP Master (who are arguably the one "acceptance tester" who
really matters) parses the tags. [1] Please let me know if you know
otherwise.

[1] https://salsa.debian.org/ftp-team/dak/-/blob/master/daklib/lintian.py#L73-74

> If the default change made sense due to some technical rationale, this
> effort might be worthwhile

As I likewise explained on IRC, Lintian's return status was
unreliable. Some program errors exited with status 1 and others with
status 2, while detecting error tags always produced status 1. Lintian
was also unable to use Perl's 'die'. The proper remedy was to always
use status 1 for program errors. That step alone would require any
automated user to examine their scripts.

The 'fail-on' command-line option resolved a long standing problem
with the implicit behavior your so cherish (#709932). Instead of
adding more complex options, the current solution is simple, elegant,
straighforward and explicit. And again, automated users already had to
look at their scripts. It was the perfect timing to make both changes.

Kind regards,
Felix Lechner

Bug#962158: lintian: New very problematic --fail-on default value

[Guillem Jover]

Hi!

On Thu, 2020-06-04 at 23:06:29 +0100, Chris Lamb wrote:
> severity 962158 serious
> thanks

> > Severity: important
> >
> > This probably deserves to be serious, but I'm not sure I can be
> > bothered…
> 
> I can relate to this feeling so let me do this for you. At the very
> least, this change now won't hit bullseye before being resolved.

Great, thanks!

On Wed, 2020-06-03 at 20:05:13 -0700, lechner wrote:
> retitle 962158 lintian: Swapped exit statuses and --fail-on default value 
> require downstream adjustments
> thanks

But then this new title does not reflect what is being reported at all,
it's actually the complete opposite. :( And not feeling like restoring
it either to avoid even a single bug-control ping-pong…

Thanks,
Guillem

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[Julian Andres Klode]

On Thu, Jun 04, 2020 at 09:24:22PM +0300, Aleksey Tulinov wrote:
> On Wed, 9 Oct 2019 17:36:07 +0200 David Kalnischkies
>  wrote:
> 
> > As Julian already said, it is "just" used for its dbus communication
> > implementation. We don't require systemd to be your init or to be even
> > functional. So I guess proposing an alternative which a) works equally
> > well and b) doesn't add additional bootstrapping complications has
> > better chances of acceptance – assuming that exists as the obvious
> > choice libdbus links against libsystemd as well even before checking a)
> > and b) …
> >
> 
> I'm not a big expert in systemd and never will be, but perhaps
> `systemd-inhibit --what="shutdown" --mode="block" apt ...` should do
> about the same thing. If every invocation of apt should be like that
> then maybe `alias apt='systemd-inhibit --what="shutdown"
> --mode="block" apt'` in .bashrc can do the trick. This does not
> require any patching whatsoever.

What you're saying is akin to

  I'm not a big expert in locking and never will be, but perhaps
  `flock apt ...` should do the about same thing, and you don't need
  locking

Think a second about what your writing.

> 
> This linking to libsystemd is redundant. If issue is with dpkg leaving
> system in inconsistent state when interrupted, then perhaps this issue
> has to be fixed in dpkg, if issue is with systemd incorrectly
> interrupting dpkg, then in systemd. I think that dependency on
> systemd:

The issue is the same we have frontend lock for, but at shutdown. The
facility we use is specifically to prevent people from shutting down
in a clear and working manner.

Of course, once we avoid the need to run dpkg multiple times, it
would be nice if dpkg made use of this mechanism itself.

> 
> It would be really nice if this dependency is removed and ideally
> underlying issue(s) properly fixed instead of applying band aid here
> and there.

This _is_ the proper fix for the issue. Now, to put it for your sysvinit
poisoned mind, this is somewhat similar to having a K01 script that
waits for /var/lib/dpkg/lock-frontend to be released; but - it actually
prevents you from shutting down in the first place, rather than just 
holding up the shutdown.

In any case, we have since grown additional places in apt that make
use of libsystemd anyway.

So, please use Devuan and leave us alone. Thanks!

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#962158: lintian: New very problematic --fail-on default value

[Chris Lamb]

severity 962158 serious
thanks

Guillem,

> Severity: important
>
> This probably deserves to be serious, but I'm not sure I can be
> bothered…

I can relate to this feeling so let me do this for you. At the very
least, this change now won't hit bullseye before being resolved.


Regards,

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

Bug#937769: python-funcsigs build-dependencies now unsatisfiable in testing, removal of pypy-pytest

[Thomas Goirand]

On 6/4/20 10:33 PM, peter green wrote:
> A few days ago Sandro Tosi uploaded the python-unittest2 and
> python-funcsigs source packages. It seems that both of these were
> effectively "team uploads" though they were not marked as such.

A few years ago, I've been flamed, them banned from the DPMT for less
than this... Though I don't think we should put the blame on Sandro. He
did a lot and we should be thankful for his work on Python 2 removal.

> The
> python-unittest2 upload dropped python 2 support while the
> python-funcsigs package dropped python 2 and pypy support.
> 
> python-unittest2, python-traceback2 and python-linecache2 have now
> migrated to testing, the result of this is that the build-dependencies
> of python-traceback2 and python-linecache2 are now satisfiable in
> testing, but those of python-funcsigs are now broken in testing.
> 
> python-funcsigs is unable to migrate to testing because pypy-pytest
> depends on pypy-funcsigs .

The thing is, funcsigs is a backport of the PEP 362 function signature
features from Python 3.3's inspect module (as per the package
description), so it should in fact go away if possible. I'm really not
sure what's going to be the faith of pypy-pytest, maybe it should be
replaced by pypy3-pytest? If I remember well the discussion, we wrote
that we would just disable the tests for things depending on python 2
test suites. Maybe this includes pypy-pytest?

Your thoughts?

Cheers,

Thomas Goirand (zigo)

Bug#962239: RFP: jc -- converts command output to JSON

[Kelly Brazil]

Package: wnpp
Severity: wishlist

I am the developer of jc, which is now packaged on OpenSUSE, NixOS, macOS 
(Homebrew), and FreeBSD (ports). jc is currently in process for packaging on 
Fedora.

jc is licensed under the MIT license.

https://github.com/kellyjonbrazil/jc
https://pypi.org/project/jc/

JSON CLI output utility

jc JSONifies the output of many CLI tools and file-types for easier parsing in 
scripts. This allows further command-line processing of output with tools like 
jq by piping commands:

$ ls -l /usr/bin | jc --ls | jq '.[] | select(.size > 5000)'
{
  "filename": "docker",
  "flags": "-rwxr-xr-x",
  "links": 1,
  "owner": "root",
  "group": "root",
  "size": 68677120,
  "date": "Aug 14 19:41"
}

or using the alternative "magic" syntax:

$ jc ls -l /usr/bin | jq '.[] | select(.size > 5000)'
{
  "filename": "docker",
  "flags": "-rwxr-xr-x",
  "links": 1,
  "owner": "root",
  "group": "root",
  "size": 68677120,
  "date": "Aug 14 19:41"
}

Thank you,
Kelly Brazil

Bug#922154: ITP: libldac -- A lossy audio codec for Bluetooth connections

[Pali Rohár]

On Sunday 10 May 2020 10:34:52 Andrej Shadura wrote:
> On Fri, May 08, 2020 at 12:51:10PM +0200, Pali Rohár wrote:
> > On Friday 08 May 2020 12:44:27 Andrej Shadura wrote:
> > > Thanks but it's already done, on Salsa and in NEW :)
> 
> > Ou, I have not spotted it. Week ago it was not there.
> 
> True. I recalled I filed the ITP this week when I was thinking about
> re-routing audio cables in my room or maybe getting rid of them altogether
> :D
> 
> > I looked at it and I see that you are not using direct upstream sources.
> > Is there any reason for it? I guess that packaging should be done from
> > upstream project (in this case Android).
> 
> Well, it was a tiny bit easier, and also I was under an (incorrect)
> impression libldac was a part of a monorepo, but in fact it is in a
> separate Git repository.
> 
> I think I will update libldac to use the upstream source directly and also
> use bits of your patch, thanks very much for it!

Ok! Feel free to reuse parts of my patch.

-- 
Pali Rohár
pali.ro...@gmail.com

Bug#962238: selinux-policy-default: selinux prevents automounting sshfs

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Severity: important

Dear Maintainer,

Problem describtion:
I set up automounting with sshfs. My selinux is in Enforcing mode.
When triggering the automount, it fails and a SELinux Security alert shows up:

***audit.log***
type=AVC msg=audit(1591302044.718:8608): avc:  denied  { execute } for  
pid=14500 comm="mount.fuse" name="dash" dev="vda1" ino=261652 
scontext=system_u:system_r:mount_t:s0 
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
***

***syslog***
Jun  4 23:20:44 vps systemd[1]: mnt-maks.automount: Got automount request for 
/mnt/maks, triggered by 14498 (ls)
Jun  4 23:20:44 vps systemd[1]: Mounting /mnt/maks...
Jun  4 23:20:44 vps systemd[1]: mnt-maks.mount: Mount process exited, 
code=exited status=1
Jun  4 23:20:44 vps systemd[1]: Failed to mount /mnt/maks.
Jun  4 23:20:44 vps systemd[1]: mnt-maks.mount: Unit entered failed state.


When setting SELinux to permissive, the automounting with sshfs works as 
expected.


Environment description:
-- fstab
root@vps:~# grep ssh /etc/fstab
media:/vps/maks /mnt/maks   fuse.sshfs  
noauto,x-systemd.automount,_netdev,users,allow_other,reconnect,ServerAliveInterval=15,ServerAliveCountMax=2
 0 0

-- packages
ii  sshfs   2.8-1
ii  mount   2.29.2-1+deb9u1


How to reproduce with Enforcing mode:
root@vps:~# setenforce 1
root@vps:~# getenforce
Enforcing
root@vps:~# grep sshfs /etc/fstab
media:/vps/maks /mnt/maks   fuse.sshfs  
noauto,x-systemd.automount,_netdev,users,allow_other,reconnect,ServerAliveInterval=15,ServerAliveCountMax=2
 0 0
root@vps:~# systemctl daemon-reload
root@vps:~# systemctl list-unit-files --type=mount
UNIT FILE STATE
-.mount   generated
boot-efi.mountgenerated
dev-hugepages.mount   static
dev-mqueue.mount  static
mnt-maks.mountgenerated
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount   static
sys-kernel-debug.mountstatic

9 unit files listed.
root@vps:~# systemctl list-unit-files --type=automount
UNIT FILE STATE
mnt-maks.automountgenerated
proc-sys-fs-binfmt_misc.automount static

2 unit files listed.
root@vps:~# systemctl restart mnt-maks.automount
root@vps:~# systemctl status mnt-maks.automount
● mnt-maks.automount
   Loaded: loaded (/etc/fstab; generated; vendor preset: enabled)
   Active: active (waiting) since Fri 2020-06-05 00:13:58 MSK; 6s ago
Where: /mnt/maks
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)

Jun 05 00:13:58 vps.k-max.name systemd[1]: Set up automount mnt-maks.automount.
root@vps:~#
root@vps:~# findmnt -u
TARGET   SOURCE  FSTYPE OPTIONS
//dev/vda1   ext4   
rw,relatime,seclabel,data=ordered
├─/sys   sysfs   sysfs  
rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/kernel/security securityfs  securityfs 
rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/selinux  selinuxfs   selinuxfs  rw,relatime
│ ├─/sys/fs/cgroup   tmpfs   tmpfs  rw,seclabel,mode=755
│ │ ├─/sys/fs/cgroup/systemd cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
│ │ ├─/sys/fs/cgroup/freezer cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,freezer
│ │ ├─/sys/fs/cgroup/devices cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,devices
│ │ ├─/sys/fs/cgroup/blkio   cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,blkio
│ │ ├─/sys/fs/cgroup/memory  cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,memory
│ │ ├─/sys/fs/cgroup/pidscgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,pids,release_agent=/run/cgmanager/agents/cgm-release-agent.pids
│ │ ├─/sys/fs/cgroup/cpu,cpuacct cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,cpu,cpuacct
│ │ ├─/sys/fs/cgroup/cpuset  cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,cpuset,clone_children
│ │ ├─/sys/fs/cgroup/net_cls,net_prio
│ │ │cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,net_cls,net_prio
│ │ └─/sys/fs/cgroup/perf_event  cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,perf_event,release_agent=/run/cgmanager/agents/cgm-release-agent.perf_event
│ ├─/sys/fs/pstore   pstore  pstore 
rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/firmware/efi/efivarsefivarfsefivarfs   
rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/debugdebugfs debugfsrw,relatime,seclabel
│ │ └─/sys/kernel/debug/tracing  tracefs tracefsrw,relatime
│ └─/sys/fs/fuse/connections fusectl fusectlrw,relatime
├─/proc  procproc   
rw,nosuid,nodev,

Bug#962237: buster-pu: package perl/5.28.1-6+deb10u1

[Dominic Hargreaves]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

As per #962234 for stretch and my remarks on #961443 I'd like to
uploaded a targeted fix for these no-dsa security issues:

https://metacpan.org/pod/release/XSAWYERX/perl-5.28.3/pod/perldelta.pod

We can come back to #961443 when we're happy that the upgrade issues
have been solved.

Cheers
Dominic
diff --git a/cpan/IO-Socket-IP/t/01local-client-v4.t 
b/cpan/IO-Socket-IP/t/01local-client-v4.t
index 7ab7156993..f6aeac4c3b 100644
--- a/cpan/IO-Socket-IP/t/01local-client-v4.t
+++ b/cpan/IO-Socket-IP/t/01local-client-v4.t
@@ -8,7 +8,7 @@ use Test::More;
 use IO::Socket::IP;
 
 use IO::Socket::INET;
-use Socket qw( inet_aton inet_ntoa pack_sockaddr_in unpack_sockaddr_in );
+use Socket qw( inet_aton inet_ntoa pack_sockaddr_in unpack_sockaddr_in 
AI_NUMERICHOST );
 
 # Some odd locations like BSD jails might not like INADDR_LOOPBACK. We'll
 # establish a baseline first to test against
@@ -29,12 +29,14 @@ foreach my $socktype (qw( SOCK_STREAM SOCK_DGRAM )) {
   LocalHost => "127.0.0.1",
   Type  => Socket->$socktype,
   Proto => ( $socktype eq "SOCK_STREAM" ? "tcp" : "udp" ), # Because 
IO::Socket::INET is stupid and always presumes tcp
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot listen on PF_INET - $@";
 
my $socket = IO::Socket::IP->new(
   PeerHost=> "127.0.0.1",
   PeerService => $testserver->sockport,
   Type=> Socket->$socktype,
+  GetAddrInfoFlags => AI_NUMERICHOST,
);
 
ok( defined $socket, "IO::Socket::IP->new constructs a $socktype socket" ) 
or
diff --git a/cpan/IO-Socket-IP/t/02local-server-v4.t 
b/cpan/IO-Socket-IP/t/02local-server-v4.t
index c0d349f573..fb711f08bd 100644
--- a/cpan/IO-Socket-IP/t/02local-server-v4.t
+++ b/cpan/IO-Socket-IP/t/02local-server-v4.t
@@ -8,7 +8,7 @@ use Test::More;
 use IO::Socket::IP;
 
 use IO::Socket::INET;
-use Socket qw( inet_aton inet_ntoa pack_sockaddr_in unpack_sockaddr_in );
+use Socket qw( inet_aton inet_ntoa pack_sockaddr_in unpack_sockaddr_in 
AI_NUMERICHOST );
 
 # Some odd locations like BSD jails might not like INADDR_LOOPBACK. We'll
 # establish a baseline first to test against
@@ -29,6 +29,7 @@ foreach my $socktype (qw( SOCK_STREAM SOCK_DGRAM )) {
   LocalHost => "127.0.0.1",
   LocalPort => "0",
   Type  => Socket->$socktype,
+  GetAddrInfoFlags => AI_NUMERICHOST,
);
 
ok( defined $testserver, "IO::Socket::IP->new constructs a $socktype 
socket" ) or
diff --git a/cpan/IO-Socket-IP/t/03local-cross-v4.t 
b/cpan/IO-Socket-IP/t/03local-cross-v4.t
index 8cac72a95b..3e8174ee08 100644
--- a/cpan/IO-Socket-IP/t/03local-cross-v4.t
+++ b/cpan/IO-Socket-IP/t/03local-cross-v4.t
@@ -6,6 +6,7 @@ use warnings;
 use Test::More;
 
 use IO::Socket::IP;
+use Socket qw(AI_NUMERICHOST);
 
 foreach my $socktype (qw( SOCK_STREAM SOCK_DGRAM )) {
my $testserver = IO::Socket::IP->new(
@@ -13,12 +14,14 @@ foreach my $socktype (qw( SOCK_STREAM SOCK_DGRAM )) {
   LocalHost => "127.0.0.1",
   LocalPort => "0",
   Type  => Socket->$socktype,
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot listen on PF_INET - $@";
 
my $socket = IO::Socket::IP->new(
   PeerHost=> "127.0.0.1",
   PeerService => $testserver->sockport,
   Type=> Socket->$socktype,
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot connect on PF_INET - $@";
 
my $testclient = ( $socktype eq "SOCK_STREAM" ) ? 
diff --git a/cpan/IO-Socket-IP/t/11sockopts.t b/cpan/IO-Socket-IP/t/11sockopts.t
index 5b850924dd..28daada89f 100644
--- a/cpan/IO-Socket-IP/t/11sockopts.t
+++ b/cpan/IO-Socket-IP/t/11sockopts.t
@@ -8,7 +8,7 @@ use Test::More;
 use IO::Socket::IP;
 
 use Errno qw( EACCES );
-use Socket qw( SOL_SOCKET SO_REUSEADDR SO_REUSEPORT SO_BROADCAST );
+use Socket qw( SOL_SOCKET SO_REUSEADDR SO_REUSEPORT SO_BROADCAST 
AI_NUMERICHOST);
 
 TODO: {
local $TODO = "SO_REUSEADDR doesn't appear to work on cygwin smokers" if 
$^O eq "cygwin";
@@ -21,6 +21,7 @@ TODO: {
   Type  => SOCK_STREAM,
   Listen=> 1,
   ReuseAddr => 1,
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot socket() - $@";
 
ok( $sock->getsockopt( SOL_SOCKET, SO_REUSEADDR ), 'SO_REUSEADDR set' );
@@ -32,6 +33,7 @@ TODO: {
   Sockopts  => [
  [ SOL_SOCKET, SO_REUSEADDR ],
   ],
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot socket() - $@";
 
ok( $sock->getsockopt( SOL_SOCKET, SO_REUSEADDR ), 'SO_REUSEADDR set via 
Sockopts' );
@@ -50,6 +52,7 @@ SKIP: {
   Type  => SOCK_STREAM,
   Listen=> 1,
   ReusePort => 1,
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot socket() - $@";
 
ok( $sock->getsockopt( SOL_SOCKET, SO_REUSEPORT ), 'SO_REUSEPORT set' );
@@ -62,6 +65,7 @@ SKIP: {
   LocalHost => "127.0.0.1",
   Type  => SOCK_DGRAM,
   Broadcast =

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[David Kalnischkies]

On Thu, Jun 04, 2020 at 09:24:22PM +0300, Aleksey Tulinov wrote:
> On Wed, 9 Oct 2019 17:36:07 +0200 David Kalnischkies
>  wrote:
> > As Julian already said, it is "just" used for its dbus communication
> > implementation. We don't require systemd to be your init or to be even
> > functional. So I guess proposing an alternative which a) works equally
> > well and b) doesn't add additional bootstrapping complications has
> > better chances of acceptance – assuming that exists as the obvious
> > choice libdbus links against libsystemd as well even before checking a)
> > and b) …
> >
> 
> I'm not a big expert in systemd and never will be, but perhaps
> `systemd-inhibit --what="shutdown" --mode="block" apt ...` should do
> about the same thing. If every invocation of apt should be like that
> then maybe `alias apt='systemd-inhibit --what="shutdown"
> --mode="block" apt'` in .bashrc can do the trick. This does not
> require any patching whatsoever.

I mentioned already that this is implemented in libapt to apply to ALL
apt-based clients equally. A cron-job is not effected by aliases nor is
a python script (using python-apt). It isn't even realistic that you
alias all "normal" libapt clients like apt, apt-get, aptitude, synaptics,
various desktop-environment-specific software centers …

Especially as its usually not the interactive sessions as everyone who
has started an apt action by hand usually has the decency to wait for it
to finish before asking the system to shutdown. Just like nobody starts
two or more apt actions in parallel by hand. But cronjobs and background
processes do, so we got frontend lock, waiting for lock release or the
shutdown inhibition in question here (and of course, it turns out given
enough users some actually do all of this anyway because why not).


> This linking to libsystemd is redundant. If issue is with dpkg leaving

It might be redundant – in the best case. Balint already mentioned that
being the case for unattended-upgrades and that is probably a good idea
for a client (for the same reason I will mention below in the apt ↔ dpkg
relationship), but not every client will realistically implement it as
not every client is that involved.


> system in inconsistent state when interrupted, then perhaps this issue
> has to be fixed in dpkg, if issue is with systemd incorrectly
> interrupting dpkg, then in systemd. I think that dependency on

Shutdown is inhibit. That means your system (← no "d") is prevented from
shutting down before the last action inhibiting shutdown is done. dpkg
can inhibit shutdown and perhaps it should¹, but it can only do so while
it is running. libapt potentially runs dpkg multiple times, so if we
don't inhibit your system might shutdown between two dpkg calls. The
system state isn't inconsistent in a package manager sense in such cases,
it might "just" not be able to boot in that state (even if relatively
unusual). For much the same reason libapt inhibits the termination signal
(^C) to stop at a consistent state, but a system being shut down
eventually kills processes which take to long and that can of course not
be inhibited.

(¹ dpkg is essential though, so it can't just use and depend on
something and its not usually run directly in the background so its less
of an issue to begin with)

> So it doesn't do much anyway, it attempts to solve some very specific
> issue in very specific environment, but it doesn't do that very well
> and can be replaced with one shell alias.

So, as explained, yes, the issue is specific and "solved" only in
specific environments (= those which allow shutdown to be inhibited
programmatically), but so far nobody told us how to solve it for
more environments or with library&code with less downsides and I
hopefully explained above why "one shell alias" does not solve anything.


> It would be really nice if this dependency is removed and ideally

And I have to repeat: This dependency removes itself if your
distribution and/or architecture does not have libsystemd while apt is
being built as evident by the non-linux architectures Debian has.

So it would be really nice if we would get some more reason than just
some OCD-level "but but but, the word 'systemd' is in there somewhere"
arguments for making maintenance of apt harder (via e.g. dlopen) or it
just wont happen as building apt is trivially easy and can be fully
automated, but maintaining and supporting it can't be.


Best regards

David Kalnischkies, who wonders if its Baader-Meinhof that since he
started with resolver changes triggered by runit seemingly things
involving the names of init systems pop up everywhere around him.


signature.asc
Description: PGP signature

Bug#962236: normalize-audio: "normalize-ogg -b -n -v" shows less info than "normalize-audio -b -n -v"

[Francesco Poli (wintermute)]

Package: normalize-audio
Version: 0.7.7-15
Severity: normal

Hello and thanks for maintaining this nice program in Debian!


I wanted to run normalize (in batch mode) on a group of audio files
with the --no-adjust option, in order to analyze the files, without
altering them in any way.

I can do this on a group of .wav files with

  $ normalize-audio --amplitude=-7.5dBFS -b -n -v *.wav

and it seems to work as intended.

However, if I want to do it on a group of .ogg files, I get
per-track info, but not the standard deviation, average, or
per-album adjustment data.

  $ normalize-ogg -a -7.5dBFS --tmpdir /dev/shm -b -n -v *.ogg
  Decoding track01.ogg...
  Decoding track02.ogg...
  Decoding track03.ogg...
  Decoding track04.ogg...
  Decoding track05.ogg...
  Decoding track06.ogg...
  Decoding track07.ogg...
  Decoding track08.ogg...
  Decoding track09.ogg...
  Decoding track10.ogg...
  Decoding track11.ogg...
  Decoding track12.ogg...
  Running normalize...
  Computing levels...
levelpeak
  -6.8533dBFS  0.dBFS   /dev/shm/track01.ogg.16607.wav   
  -8.0583dBFS  0.dBFS   /dev/shm/track02.ogg.16607.wav
  -7.1047dBFS  0.dBFS   /dev/shm/track03.ogg.16607.wav
  -7.2339dBFS  0.dBFS   /dev/shm/track04.ogg.16607.wav
  -7.7699dBFS  0.dBFS   /dev/shm/track05.ogg.16607.wav
  -7.1890dBFS  0.dBFS   /dev/shm/track06.ogg.16607.wav
  -8.0084dBFS  0.dBFS   /dev/shm/track07.ogg.16607.wav
  -7.6048dBFS  0.dBFS   /dev/shm/track08.ogg.16607.wav
  -7.4123dBFS  0.dBFS   /dev/shm/track09.ogg.16607.wav
  -7.5195dBFS  0.dBFS   /dev/shm/track10.ogg.16607.wav
  -8.1773dBFS  0.dBFS   /dev/shm/track11.ogg.16607.wav
  -7.5512dBFS  0.dBFS   /dev/shm/track12.ogg.16607.wav

This is weird, since normalize-ogg decodes the .ogg files into
.wav files and then runs normalize-audio on them.
Hence, I would expect the same output...

Yet, if I manually run normalize-audio on the decoded files,
I also get the final data I am interested in:

  $ normalize-audio --amplitude=-7.5dBFS -b -n -v /dev/shm/*.wav
  Computing levels...
levelpeak
  -6.8533dBFS  0.dBFS   /dev/shm/track01.ogg.16607.wav
  -8.0583dBFS  0.dBFS   /dev/shm/track02.ogg.16607.wav
  -7.1047dBFS  0.dBFS   /dev/shm/track03.ogg.16607.wav
  -7.2339dBFS  0.dBFS   /dev/shm/track04.ogg.16607.wav
  -7.7699dBFS  0.dBFS   /dev/shm/track05.ogg.16607.wav
  -7.1890dBFS  0.dBFS   /dev/shm/track06.ogg.16607.wav
  -8.0084dBFS  0.dBFS   /dev/shm/track07.ogg.16607.wav
  -7.6048dBFS  0.dBFS   /dev/shm/track08.ogg.16607.wav
  -7.4123dBFS  0.dBFS   /dev/shm/track09.ogg.16607.wav
  -7.5195dBFS  0.dBFS   /dev/shm/track10.ogg.16607.wav
  -8.1773dBFS  0.dBFS   /dev/shm/track11.ogg.16607.wav
  -7.5512dBFS  0.dBFS   /dev/shm/track12.ogg.16607.wav
  Standard deviation is 0.39 dB
  -7.5314dBFS  average level
  0.031363dB   volume adjustment

I cannot understand why normalize-ogg seems to suppress the
final output lines (which include interesting data about
standard deviation, average, and per-album adjustment!).

I took a look at the normalize-ogg code, but my knowledge
about Perl is just a smattering, and, in addition, it is rusty.
Hence, I failed to understand the tricky part (with exec()
and pipe handling, I think...).

How can normalize-ogg be fixed to show all the output
of normalize-audio?
Please fix this bug and/or forward my bug report upstream,
as appropriate.

Thanks for your time!
Bye.


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

Kernel: Linux 5.6.0-2-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages normalize-audio depends on:
ii  libaudiofile1  0.3.6-5
ii  libc6  2.30-8
ii  libmad00.15.1b-10
ii  perl   5.30.2-1

Versions of packages normalize-audio recommends:
ii  flac  1.3.3-1
ii  vorbis-tools  1.4.0-11

Versions of packages normalize-audio suggests:
pn  mpg321  

-- no debconf information

Bug#962235: linux-image-4.19.0-9-amd64: USB3 disk aren't detected when connected to a USB3 hub

[Amaury ABRIAL]

Package: src:linux
Version: 4.19.118-2
Severity: normal

Dear Maintainer,

I encounter an issue with USB3 hub and USB3 key and disk

* What led up to the situation?
The problem occur since i udgraded my computer from debian 9 to debian 10
(from librazik2 to librazik3 in fact, but i don't think it's relevant
irrelevant).

* What exactly did you do (or not do) that was effective (or ineffective)?
   - I tried to start my computer with diffferent kernel :
 - 4.19.0-9 => problem is present.
 - 5.4.0-0 => problem is present.
 - 4.9.0-9 => no problem.

   - I tried to identify what configuration produce the bug:
 - Connecting a USB3 device in the USB3 hub => the USB3 device is not
detected, it doesn't appear when doing "lsusb"
 - Connecting a USB3 device in the USB3 hub and then connecting the hub to
the computer => work normally
 - Connecting a USB3 device directly in USB3 port => the device is detected
and preivously USB3 device connected to the hub are detected a same time
 - Connecting a USB2 device directly in USB3 port => the device is
detected, but it doesn't trigger detection of USB3 device connected to the hub
 - I also did some other test with usb2 device and usb2 computer port, it
works until some point i didn't yet identified.



-- Package-specific info:
** Version:
Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2 (2020-04-29)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/HP--Amaury--vg0-root 
ro threadirqs quiet

** Not tainted

** Kernel log:
[6.472246] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card0/input13
[6.480158] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input14
[6.480754] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input15
[6.480936] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1b.0/sound/card0/input16
[6.511144] intel_rapl: Found RAPL domain package
[6.511147] intel_rapl: Found RAPL domain core
[6.511148] intel_rapl: Found RAPL domain uncore
[6.511156] intel_rapl: RAPL package 0 domain package locked by BIOS
[6.649762] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: 
(null)
[6.720060] audit: type=1400 audit(1591291208.238:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=525 comm="apparmor_parser"
[6.726098] audit: type=1400 audit(1591291208.242:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=527 
comm="apparmor_parser"
[6.726105] audit: type=1400 audit(1591291208.242:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=527 
comm="apparmor_parser"
[6.726109] audit: type=1400 audit(1591291208.242:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=527 
comm="apparmor_parser"
[6.728496] audit: type=1400 audit(1591291208.246:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=524 
comm="apparmor_parser"
[6.728502] audit: type=1400 audit(1591291208.246:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium" 
pid=524 comm="apparmor_parser"
[6.732029] audit: type=1400 audit(1591291208.250:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=531 comm="apparmor_parser"
[6.734048] audit: type=1400 audit(1591291208.250:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=529 
comm="apparmor_parser"
[6.734054] audit: type=1400 audit(1591291208.250:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=529 comm="apparmor_parser"
[6.741411] audit: type=1400 audit(1591291208.258:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=533 comm="apparmor_parser"
[7.294963] random: crng init done
[7.294966] random: 3 urandom warning(s) missed due to ratelimiting
[7.738051] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[7.742363] r8169 :08:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8105e-1.fw
[7.742916] Generic PHY r8169-800:00: attached PHY driver [Generic PHY] 
(mii_bus:phy_addr=r8169-800:00, irq=IGNORE)
[8.021213] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[8.027980] IPv6: ADDRCONF(NETDEV_UP): wlo1: link is not ready
[8.028068] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading 
firmware file 'rt3290.bin'
[8.031784] rt2800pci :07:00.0: firmware: direct-loading firmware 
rt3290.bin
[8.031793] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware 
detected

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Julien Cristau]

On Thu, Jun  4, 2020 at 22:18:10 +0300, Adrian Bunk wrote:

> On Thu, Jun 04, 2020 at 07:55:32PM +0200, Julien Cristau wrote:
> > Control: tag -1 moreinfo
> > 
> > On Thu, Jun 04, 2020 at 07:59:22PM +0300, Adrian Bunk wrote:
> > > FAIL: dtls_hello_random_value
> > > =
> > > 
> > > testing: default
> > > client:156: client: Handshake failed: Resource temporarily unavailable, 
> > > try again.
> > > server:271: server: Handshake has failed: The TLS connection was 
> > > non-properly terminated.
> > > 
> > > FAIL dtls_hello_random_value (exit status: 1)
> > > 
> > This particular test seems to use a AF_UNIX socketpair, I'm not sure
> > how it would fail due to network setup?
> 
> I copied the log from the 3.6.13-4 arm64 failure.
> This specific test passes in the other logs.
> 
> The binary-all log (non-conova) of 3.6.13-4 has no test failures,
> but the build fails due to timeout after 150 minutes without output.
> 
> My gut feeling is that there might be an (unrelated) problem with 
> the #961889 fix, but this is just a guess.
> 
The arch:all failure is at grnet and that buildd has both v4 and v6
addresses, so presumably unrelated.

Which leaves us with the armel failure (on arm-conova-03) which does
look related to the lack of public v4 address, e.g.:

> FAIL: sni-hostname.sh
> =
> 
> Checking SNI hostname in gnutls-cli
> Echo Server listening on IPv6 :: port 26448...done
> Could not connect to 127.0.0.1:26448: Connection refused
> Failure: 1. handshake should have succeeded!
> Exiting via signal 15
> FAIL sni-hostname.sh (exit status: 1)

If we listen on :: and then try to connect to 127.0.0.1, that won't work.

And indeed gnutls-serv seems to call getaddrinfo with node == NULL and
hints.ai_flags == AI_PASSIVE|AI_ADDRCONFIG, to figure out what address
to listen on.  If the host has no non-local ipv4 address, that
getaddrinfo call returns :: but not 0.0.0.0; and then the test hardcodes
127.0.0.1 as the address for gnutls-cli to connect to, and sadness
ensues.

Cheers,
Julien

Bug#941568: [Python-modules-team] Question about related package to python3-dill

[Sandro Tosi]

yeah if you could transfer the repo to DPMT that'd be great: i'm
already using multiprocess in one of my project and i'll take for the
package as well. any technical reason behind the halt of the packaging
other than lack of time? thanks!

On Thu, Jun 4, 2020 at 4:35 PM Andreas Tille  wrote:
>
> Control: retitle -1 RFP: multiprocess -- better multiprocessing and 
> multithreading in Python
>
> Sorry, this package has lowered in my list of needs.  Feel free to take
> over.  If you want me to transfer the existing repository to DPMT I'd
> happily do so.
>
> Kind regards
>
>Andreas.
>
> On Thu, Jun 04, 2020 at 04:02:23PM -0400, Sandro Tosi wrote:
> > there's been some effort at
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941568 , Andreas
> > what's the status of multiprocess? i dont see it in NEW nor the archive
> >
> >
> > On Thu, Jun 4, 2020 at 2:48 PM Marco Costa  wrote:
> > >
> > > Hi,
> > >
> > > As "dill" is a part of the pathos project, I would like to ask why the 
> > > package "multiprocess" is not available also?
> > >
> > > Thank you in advance.
> > >
> > > Marco
> > > ___
> > > Python-modules-team mailing list
> > > python-modules-t...@alioth-lists.debian.net
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
> >
> >
> >
> > --
> > Sandro "morph" Tosi
> > My website: http://sandrotosi.me/
> > Me at Debian: http://wiki.debian.org/SandroTosi
> > Twitter: https://twitter.com/sandrotosi
> >
> > --
> > Sandro "morph" Tosi
> > My website: http://sandrotosi.me/
> > Me at Debian: http://wiki.debian.org/SandroTosi
> > Twitter: https://twitter.com/sandrotosi
> >
>
> --
> http://fam-tille.de



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#961512: reportbug-gtk: Keyboard navigation broken in some situations

[Nis Martensen]

On 25 May 2020 Patrick ZAJDA wrote:
> When launching the Reportbug GTK, it is not possible to use keyboard
> navigation.
> Nothing happens when I press Tab or Shift+Tab.

Thank you for the report. After receiving your report I have tried to
navigate the GTK UI using only the keyboard, and can confirm that the
experience could be better. However, the reportbug maintenance team are
no GTK experts, so fixing this might not happen soon. Help is welcome.

If you are unable to access any button, try holding down the Alt key.
This should highlight a letter in each button that you can press.

> Another annoying keyboard navigation related issue is when I press "Back", 
> only
> Back/Next/Cancel button can have the focus using keyboard, even when I try to
> use mouse click I cannot modify fields values.

The Back button is not there by design, but by mistake. It is a
well-known bug that has been reported many times and should be fixed in
the next version.

Bug#962215: libfox-1.6-0: Is it possible to package fox-1.7.67 or higher?

[Roland Plüss]

Package: libfox-1.6-0
Version: 1.6.57-1
Severity: wishlist

Dear Maintainer,

I try to package my game engine project for debian which requires fox-1.7.67 or 
higher.
Existing version is 1.6.57 which is not compatible to 1.7.67 .
I've been told to create a wishlist bug to see if such an upgrade is possible,
especially seeing how fox-1.7 is not yet marked stable upstream.

Kind Regards

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

Kernel: Linux 4.19.97-gentoo (SMP w/8 CPU cores)
Kernel taint flags: 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 /bin/dash
Init: unable to detect

Versions of packages libfox-1.6-0 depends on:
ii  libc6   2.30-8
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.1-2
ii  libgcc-s1 [libgcc1] 10.1.0-3
ii  libgl1  1.3.1-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libpng16-16 1.6.37-2
ii  libstdc++6  10.1.0-3
ii  libtiff54.1.0+git191117-2
ii  libx11-62:1.6.9-2+b1
ii  libxcursor1 1:1.2.0-2
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-2
ii  zlib1g  1:1.2.11.dfsg-2

libfox-1.6-0 recommends no packages.

libfox-1.6-0 suggests no packages.

-- no debconf information

Bug#962233: ITP: libatomicbitvector -- atomic bitset/bitvector with size determined at runtime

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: libatomicbitvector -- atomic bitset/bitvector with size 
determined at runtime
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: libatomicbitvector
  Version : 0.0+git20200519.e295358
  Upstream Author : Erik Garrison 
* URL : https://github.com/ekg/atomicbitvector
* License : Apache-2.0
  Programming Lang: C
  Description : atomic bitset/bitvector with size determined at runtime
 This header-only library encodes a bitvector class with size fixed at
 runtime. Atomic operations allow for concurrent access and modification
 of the bitset. Such a structure can help with coordinating parallel
 processing of a given fixed set of entities, and has the advantage of
 only requiring O(1) bit per entry.
 .
 The atomic_bv_t class is a straightforward extension of ConcurrentBitSet
 from Facebook's folly C++ library. It wraps the atomic type with a class
 that allows them to be copied, and these wrapped atomic types are then
 used to build a vector whose size is determined at runtime.

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

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

[Roland Plüss]

On 5/31/20 9:19 AM, Tobias Frost wrote:
> If you want to follow this route, your next step would be now to contact
> the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking
> to package the version you need, explaining the situation and maybe (==
> if you want) tell them that you would commit helping to offset the extra
> work caused by maintaining the development snapshot.
>
> * dak spits out those r-deps:
> ace: libfox-1.6-dev
> gogglesmm: libfox-1.6-dev
> libgwenhywfar: libfox-1.6-dev
> pcsc-cyberjack: libfox-1.6-dev
> sumo: libfox-1.6-dev
> xfe: libfox-1.6-dev (>= 1.6.45)
>
Figured it out now. The package name is "libfox-1.6-0". If I did nothing
wrong the wishlist bug should be filed now.

-- 
Mit freundlichen Grüssen
Plüss Roland

Game Development and Game Engine Technologies https://dragondreams.ch



signature.asc
Description: OpenPGP digital signature

Bug#962194: lintian-brush: autopkgtest failure on s390x

[Jelmer Vernooij]

On Thu, Jun 04, 2020 at 02:41:04PM +0200, Gianfranco Costamagna wrote:
> Hello, since version 0.68 we are hitting autopkgtest failures on Ubuntu s390x
> (but I presume this might be an endianess issue unrelated to Ubuntu, but an 
> issue on Debian too)
> 
> look e.g.:
> 
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lintian-brush/20200526_071151_45b70@/log.gz
> 
> or
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lintian-brush/20200602_160733_92e77@/log.gz
> 
> 
> autopkgtest [16:06:43]: test tool-testsuite: [---
> failed to open trace file: [Errno 13] Permission denied: 
> '/you-should-use-TestCaseInTempDir-if-you-need-a-log-file'
> .../usr/lib/python3/dist-packages/debian/changelog.py:483: UserWarning: 
> Unexpected line while looking for first heading: THIS IS NOT A PARSEABLE LINE
>   warnings.warn(message)
> /usr/lib/python3/dist-packages/debian/changelog.py:483: 
> UserWarning: Unexpected line while looking for first heading: lalalalala
>   warnings.warn(message)
> /usr/lib/python3/dist-packages/debian/changelog.py:483: UserWarning: Found 
> eof where expected first heading
>   warnings.warn(message)
> ./tmp/autopkgtest.aoDwvO/build.6pK/src/lintian_brush/_deb822.py:115: 
> UserWarning: cannot parse package relationship "${misc:Depends}", returning 
> it raw
>   warnings.warn(
> ...ss...EE.x..sed:
>  can't read debian/rules: No such file or directory
> sed: can't read debian/rules: No such file or directory
> .sed: can't read debian/rules: No such file or directory
> sed: can't read debian/rules: No such file or directory
> ./tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/common-license.py:176:
>  UserWarning: A common license shortname (Apache-2.0) is used, but license 
> text not recognized.
>   warn(
> ../tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/common-license.py:160: 
> UserWarning: Unable to get canonical name for 'BSD-3-clause'
>   warn('Unable to get canonical name for %r' % license_id)
> /tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/common-license.py:190: 
> UserWarning: Found full license text for BSD-3-clause, but unknown synopsis 
> BSD-3-clause (BSD-3-clause)
>   warn('Found full license text for %s, but unknown synopsis %s (%s)'
> .../usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: 
> UserWarning: cannot parse package relationship "libf2fs5 (= 
> ${binary:Version})", returning it raw
>   warnings.warn(
> /usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning: 
> cannot parse package relationship "libf2fs-format4 (= ${binary:Version})", 
> returning it raw
>   warnings.warn(
> /usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning: 
> cannot parse package relationship "${shlibs:Depends}", returning it raw
>   warnings.warn(
> /usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning: 
> cannot parse package relationship "${misc:Depends}", returning it raw
>   warnings.warn(
> /usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning: 
> cannot parse package relationship "f2fs-tools (= ${binary:Version})", 
> returning it raw
>   warnings.warn(
> /usr/lib/python3/dist-packages/debian/changelog.py:483: 
> UserWarning: Unexpected line while looking for start of change data:  * 
> Initial Release.
>   warnings.warn(message)
> .../usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115:
>  UserWarning: cannot parse package relationship "${misc:Depends}", returning 
> it raw
>   warnings.warn(
> ..Tree has non-standard patches directory debian/patches-applied.
> ..dpkg-architecture: warning: cannot determine CC system 
> type, falling back to default (native compilation)
> Use of uninitialized value $step in string ne at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem/perl_build.pm line 24.
> Use of uninitialized value $step in string ne at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem.pm line 424.
> ..dpkg-architecture: warning: cannot determine CC system type, falling back 
> to default (native compilation)
> Use of uninitialized value $step in string ne at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem/perl_build.pm line 24.
> Use of uninitialized value $step in string ne at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem.pm line 424.
> ../tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/package-uses-deprecated-debhelper-compat-version.py:80:
>  UserWarning: Not upgrading beyond debhelper 10, since the package disables 
> autoreconf but its configure does not p

Bug#941568: [Python-modules-team] Question about related package to python3-dill

[Andreas Tille]

Control: retitle -1 RFP: multiprocess -- better multiprocessing and 
multithreading in Python

Sorry, this package has lowered in my list of needs.  Feel free to take
over.  If you want me to transfer the existing repository to DPMT I'd
happily do so.

Kind regards

   Andreas.

On Thu, Jun 04, 2020 at 04:02:23PM -0400, Sandro Tosi wrote:
> there's been some effort at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941568 , Andreas
> what's the status of multiprocess? i dont see it in NEW nor the archive
> 
> 
> On Thu, Jun 4, 2020 at 2:48 PM Marco Costa  wrote:
> >
> > Hi,
> >
> > As "dill" is a part of the pathos project, I would like to ask why the 
> > package "multiprocess" is not available also?
> >
> > Thank you in advance.
> >
> > Marco
> > ___
> > Python-modules-team mailing list
> > python-modules-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
> 
> 
> 
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
> 
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
> 

-- 
http://fam-tille.de

Bug#937769: python-funcsigs build-dependencies now unsatisfiable in testing, removal of pypy-pytest

[peter green]

A few days ago Sandro Tosi uploaded the python-unittest2 and python-funcsigs source 
packages. It seems that both of these were effectively "team uploads" though 
they were not marked as such. The python-unittest2 upload dropped python 2 support while 
the python-funcsigs package dropped python 2 and pypy support.

python-unittest2, python-traceback2 and python-linecache2 have now migrated to 
testing, the result of this is that the build-dependencies of python-traceback2 
and python-linecache2 are now satisfiable in testing, but those of 
python-funcsigs are now broken in testing.

python-funcsigs is unable to migrate to testing because pypy-pytest depends on 
pypy-funcsigs .

I have just filed a rc bug on vanguards ( 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962232 ), once that is dealt 
with it should then be possible to drop pypy-pytest and related module packages 
( pypy-atomicwrites, pypy-pluggy, pypy-py pypy-setuptools-scm pypy-wcwidth 
pypy-importlib-metadata and pypy-zipp )

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

[Roland Plüss]

On 5/31/20 9:19 AM, Tobias Frost wrote:
> If you want to follow this route, your next step would be now to contact
> the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking
> to package the version you need, explaining the situation and maybe (==
> if you want) tell them that you would commit helping to offset the extra
> work caused by maintaining the development snapshot.
>
> * dak spits out those r-deps:
> ace: libfox-1.6-dev
> gogglesmm: libfox-1.6-dev
> libgwenhywfar: libfox-1.6-dev
> pcsc-cyberjack: libfox-1.6-dev
> sumo: libfox-1.6-dev
> xfe: libfox-1.6-dev (>= 1.6.45)
>
I tried doing this with reportbug but I failed. It asks me first for the
package where the bug is found. I entered as you suggested "src:fox1.6".
Reportbug complains "src:fox1.6 is not a valid package name.". What am I
doing wrong?

-- 
Mit freundlichen Grüssen
Plüss Roland

Game Development and Game Engine Technologies https://dragondreams.ch



signature.asc
Description: OpenPGP digital signature

Bug#961042: Wrong package?

[Anton Gladky]

Hi Helmut,

I do not quite understand how #961042 can be fixed in yade.
Could you please check, whether the bug is properly assigned?

Thanks

Anton

Bug#962232: vanguards indirectly build-depends on cruft package.

[peter green]

Package: vanguards
Version: 0.3.1-2
Severity: serious

vanguards build-depends on pypy-pytest which depends on pypy-funcsigs which is 
no longer built by the python-funcsigs source package. The pytest maintainer 
has also said they would like to get rid of pypy support from pytest. Afaict 
vanguards is the only application that build-depends on pypy-pytest (there are 
also some module packages but they all look like they could drop pypy support 
at the same time pytest does).

The ideal fix would be to move to pypy3, but I understand that is currently 
blocked on tooling (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932820 ). Over in bug 937769 
Chris Lamb proposed a patch to run the testsuite with python 3. Obviously 
running the testsuite with a different python version from that used to 
actually run the program is suboptimal but I think it's the lesser evil here.

I manually applied the patch, cleaning up some formatting and making the 
dependency versioning for the python3-stem build-dependency match that for the 
pypy-stem build-dependency. While testing I also noticed some clean target 
issues so I fixed them.

A debdiff is attatched, if I get no objections (and the maintainer doesn't 
upload this first) I will likely NMU this in a week or so.

diff -Nru vanguards-0.3.1/debian/changelog vanguards-0.3.1/debian/changelog
--- vanguards-0.3.1/debian/changelog2019-07-26 16:30:09.0 +
+++ vanguards-0.3.1/debian/changelog2020-06-04 19:21:14.0 +
@@ -1,3 +1,12 @@
+vanguards (0.3.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Clean up pytest cache and egg info in clean target.
+  * Run testsuite with python 3 to get rid of build-depends on pypy-pytest
+(thanks to Chris Lamb for the initial patch)
+
+ -- Peter Michael Green   Thu, 04 Jun 2020 19:21:14 +
+
 vanguards (0.3.1-2) unstable; urgency=medium
 
   [ Nicolas Braud-Santoni ]
diff -Nru vanguards-0.3.1/debian/control vanguards-0.3.1/debian/control
--- vanguards-0.3.1/debian/control  2019-07-26 16:30:09.0 +
+++ vanguards-0.3.1/debian/control  2020-06-04 19:21:14.0 +
@@ -8,8 +8,9 @@
dh-python,
pypy,
pypy-setuptools,
+   python3-pytest ,
+   python3-stem (>= 1.6.0-3.1) ,
pypy-stem (>= 1.6.0-3.1),
-   pypy-pytest,
pypy-ipaddress
 Standards-Version: 4.1.5
 Vcs-Browser: https://salsa.debian.org/pkg-privacy-team/vanguards
diff -Nru vanguards-0.3.1/debian/rules vanguards-0.3.1/debian/rules
--- vanguards-0.3.1/debian/rules2019-07-26 16:30:09.0 +
+++ vanguards-0.3.1/debian/rules2020-06-04 19:21:14.0 +
@@ -5,3 +5,10 @@
 
 override_dh_installsystemd:
dh_installsystemd --no-enable --no-start
+
+override_dh_auto_test:
+   dh_auto_test -- --system=custom --test-args='cd {build_dir}; python3 -m 
pytest $(CURDIR)/tests'
+
+override_dh_auto_clean:
+   dh_auto_clean
+   rm -rf .pytest_cache src/vanguards.egg-info

Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin

[Jonas Smedegaard]

Quoting Ricardo Ribalda Delgado (2020-06-04 19:53:10)
> I have just updated my salsa to 2.2.0
> https://salsa.debian.org/ribalda-guest/ugrep/-/tree/debian In case
> that you want to give it a try.

Great!

A few remarks about the packaging:

The autopkgtest failed:

upstream-test-suite  FAIL stderr: configure.ac:31: installing './ar-lib'

Seems you need to add the allow-stderr restriction - more info here: 
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

Related to autopkgtest I (just earlier today in fact) noticed the 
"build-needed" restriction which seems perfectly suitable for the kind 
of test you've setup.

The package short description is wrongly used as a first line of the 
long description - check Debian Policy § 5.6.13 for the details on that.

I also would have expected libreflex to be built as a shared library for 
reuse by other future packages besides ugrep - but perhaps you've 
discussed that with Zumbi already and there is some sensible reason for 
embedding the library with ugrep.

Are you aware that you can use wildcards with lintian overrides? Seems 
your 18 almost identical overrides can be shrunk to just one line.  And 
while at it, please consider adding a comment describing why those 
warnings are overridden (it is easier to agree or disagree with your 
reasoning without first reading your mind :-) ).

You've listed only copyright and licensing for main upstream author and 
yourself - but there are also (at least) some autotools-originated files 
licensed as Expat, FSFAP, FSFUL, FSFULLR, GPL-2+, and GPL-3+.  Possibly 
you are already aware and consider those irrelevant to track in 
debian/copyright, but mentioning in case the omission wasn't deliberate, 
as I suspect ftpmaster might disagree with doing that.  If interested, 
then I can guide you in using licensecheck to check that (and keep track 
of changes for later updates).

Thanks a lot for packaging ugrep.  I hadn't heard about it before I saw 
your ITP, and it looks like an amazing tool, that I will sure spend some 
time getting familiar with now.


 - 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#962216: journalctl -f --boot header perhaps not appropriate

[Michael Biebl]

Control: tags -1 + moreinfo

Am 04.06.20 um 18:48 schrieb 積丹尼 Dan Jacobson:
> Package: systemd
> Version: 245.5-3
> Severity: wishlist
> File: /bin/journalctl
> 
> Are you sure the
> -- Logs begin at Sun 2020-02-02 08:24:03 CST. --
> message is helpful for
> # journalctl --boot
> and
> # journalctl --follow ?
> 
> It may be referring to months of old logs that aren't being shown.
> 

Huh, I have no idea what you mean here.
What exactly is the problem?



signature.asc
Description: OpenPGP digital signature

Bug#962230: xiphos: FTBFS on mips64el

[Sebastian Ramacher]

Source: xiphos
Version: 4.1.0.1+dfsg1-1+b1
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

xiphos fails to build on ftbfs:
| [ 45/131] cxx: src/main/configs.cc -> build/default/src/main/configs_1.o
| 22:41:52 runner system command -> ['/usr/bin/g++', '-O2', 
'-fno-delete-null-pointer-checks', '-DHAVE_CONFIG_H', '-g', '-O2', 
'-fdebug-prefix-map=/<>=.', '-fstack-protector-strong', 
'-Wformat', '-Werror=format-security', '-pthread', '-Wdate-time', 
'-D_FORTIFY_SOURCE=2', '-Wdate-time', '-D_FORTIFY_SOURCE=2', 
'-Idefault/src/main', '-I../src/main', '-Idefault', '-I..', '-Idefault/src', 
'-I../src', '-I/usr/include/dbus-1.0', 
'-I/usr/lib/mips64el-linux-gnuabi64/dbus-1.0/include', 
'-I/usr/include/glib-2.0', 
'-I/usr/lib/mips64el-linux-gnuabi64/glib-2.0/include', 
'-I/usr/include/libgsf-1', '-I/usr/include/webkitgtk-4.0', 
'-I/usr/include/gtk-3.0', '-I/usr/include/at-spi2-atk/2.0', 
'-I/usr/include/at-spi-2.0', '-I/usr/include/gio-unix-2.0', 
'-I/usr/include/cairo', '-I/usr/include/pango-1.0', '-I/usr/include/fribidi', 
'-I/usr/include/harfbuzz', '-I/usr/include/atk-1.0', '-I/usr/include/pixman-1', 
'-I/usr/include/uuid', '-I/usr/include/freetype2', '-I/usr/include/libpng16', 
'-I/usr/include/gdk-pixbuf-2.0', '-I/usr/include/libsoup-2.4', 
'-I/usr/include/libxml2', '-I/usr/include/libmount', '-I/usr/include/blkid', 
'-I/usr/include/sword', '-I/usr/include/biblesync/bibleysnc', 
'../src/main/configs.cc', '-c', '-o', 'default/src/main/configs_1.o']
| In file included from /usr/include/mips64el-linux-gnuabi64/asm/types.h:23,0G
|  from /usr/include/linux/types.h:5,
|  from /usr/include/linux/stat.h:5,
|  from /usr/include/mips64el-linux-gnuabi64/bits/statx.h:31,
|  from /usr/include/mips64el-linux-gnuabi64/sys/stat.h:446,
|  from /usr/include/sword/filemgr.h:26,
|  from ../src/backend/sword_main.cc:31:
| /usr/include/asm-generic/int-l64.h:29:25: error: conflicting declaration 
‘typedef long int __s64’
|29 | typedef __signed__ long __s64;
|   | ^
| In file included from /usr/include/sword/swkey.h:31,
|  from /usr/include/sword/listkey.h:28,
|  from /usr/include/sword/swmodule.h:29,
|  from ../src/backend/sword_main.cc:28:
| /usr/include/sword/sysdata.h:49:44: note: previous declaration as ‘typedef 
long long int __s64’
|49 | __extension__ typedef __signed__ long long __s64;
|   |^
| In file included from /usr/include/mips64el-linux-gnuabi64/asm/types.h:23,
|  from /usr/include/linux/types.h:5,
|  from /usr/include/linux/stat.h:5,
|  from /usr/include/mips64el-linux-gnuabi64/bits/statx.h:31,
|  from /usr/include/mips64el-linux-gnuabi64/sys/stat.h:446,
|  from /usr/include/sword/filemgr.h:26,
|  from ../src/backend/sword_main.cc:31:
| /usr/include/asm-generic/int-l64.h:30:23: error: conflicting declaration 
‘typedef long unsigned int __u64’
|30 | typedef unsigned long __u64;
|   |   ^
| In file included from /usr/include/sword/swkey.h:31,
|  from /usr/include/sword/listkey.h:28,
|  from /usr/include/sword/swmodule.h:29,
|  from ../src/backend/sword_main.cc:28:
| /usr/include/sword/sysdata.h:50:42: note: previous declaration as ‘typedef 
long long unsigned int __u64’
|50 | __extension__ typedef unsigned long long __u64;
|   |  ^
| In file included from /usr/include/sword/swkey.h:31,
|  from /usr/include/sword/listkey.h:28,
|  from /usr/include/sword/swmodule.h:29,
|  from ../src/backend/module_manager.hh:28,
|  from ../src/backend/module_manager.cc:40:
| /usr/include/sword/sysdata.h:49:44: error: conflicting declaration ‘typedef 
long long int __s64’
|49 | __extension__ typedef __signed__ long long __s64;
|   |^
| In file included from /usr/include/mips64el-linux-gnuabi64/asm/types.h:23,
|  from /usr/include/linux/types.h:5,
|  from /usr/include/linux/stat.h:5,
|  from /usr/include/mips64el-linux-gnuabi64/bits/statx.h:31,
|  from /usr/include/mips64el-linux-gnuabi64/sys/stat.h:446,
|  from /usr/include/sword/filemgr.h:26,
|  from ../src/backend/module_manager.cc:36:
| /usr/include/asm-generic/int-l64.h:29:25: note: previous declaration as 
‘typedef long int __s64’
|29 | typedef __signed__ long __s64;
|   | ^
| In file included from /usr/include/sword/swkey.h:31,
|  from /usr/include/sword/listkey.h:28,
|  from 

Bug#961841: fontforge FTBFS on 64bit big endian: test failures

[Olivier Tilloy]

This upstream commit fixes the test failures on s390x:
https://github.com/oSoMoN/fontforge/commit/fde85b13382595cb3ab889e38570b4944edad808
.

I cherry-picked it and applied it to 1:20190801~dfsg-5 (only the last hunk
doesn't apply cleanly, it can be removed), and the build succeeded
on amd64, arm64, armhf, ppc64el and s390x (against Ubuntu groovy-proposed).

Bug#962228: grub-pc: Backport LUKS2 support

[Petr Vorel]

Package: grub-pc
Version: 2.04-7
Severity: wishlist

Dear Maintainer,

could you please backport LUKS2 support from upstream?  #55093 [1], Add LUKS2
support was implemented in 365e0cc3e ("disk: Implement support for LUKS2") [2].

It'd be great to have the support backported at least in experimental (but
preferably in unstable, so it could eventually get into d-i and workaround [3]
wouldn't have to be used).

Kind regards,
Petr

[1] https://savannah.gnu.org/bugs/?55093
[2] 
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755
[3] https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

Bug#962229: orthanc-postgresql FTBFS with boost1.71

[Adrian Bunk]

Source: orthanc-postgresql
Version: 3.2-1
Severity: serious
Tags: ftbfs bullseye sid
Control: block 961995 by -1

https://buildd.debian.org/status/package.php?p=orthanc-postgresql&suite=sid

...
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake 
(found version "1.71.0")
CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:182 
(boost_find_component):
  boost_find_component Macro invoked with incorrect arguments for macro
  named: boost_find_component
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindBoost.cmake:443 (find_package)
  
/<>/Build/Orthanc-1.5.4/Resources/CMake/BoostConfiguration.cmake:15
 (find_package)
  
/<>/Build/Orthanc-1.5.4/Resources/CMake/OrthancFrameworkConfiguration.cmake:417
 (include)
  /<>/Resources/CMake/DatabasesFrameworkConfiguration.cmake:62 
(include)
  /<>/Resources/CMake/DatabasesPluginConfiguration.cmake:21 
(include)
  CMakeLists.txt:22 (include)
...



orthanc-postgresql builds an own copy of src:orthanc,
and this copy does not have #953884 fixed.

Bug#888967: selinux-policy-default: Default policy breaks semanage tool

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Followup-For: Bug #888967

I would like to add more information.
After apply workaround:
$ echo '(allow semanage_t semanage_tmp_t (file (getattr open read execute 
ioctl)))' > semanage_mmap_tmp.cil 
$ sudo semodule -i semanage_mmap_tmp.cil

semanage is working, but I've still got AVC errors:
--
type=AVC msg=audit(1591299268.883:8358): avc:  denied  { execute } for  
pid=12319 comm="semanage" name="ldconfig" dev="vda1" ino=1177350 
scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file permissive=0
type=AVC msg=audit(1591299268.895:8359): avc:  denied  { execute_no_trans } for 
 pid=12321 comm="gcc" path="/usr/lib/gcc/x86_64-linux-gnu/6/collect2" 
dev="vda1" ino=141628 
scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1591299268.903:8360): avc:  denied  { execute } for  
pid=12322 comm="semanage" name="ldconfig" dev="vda1" ino=1177350 
scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file permissive=0
type=AVC msg=audit(1591299268.911:8361): avc:  denied  { execute_no_trans } for 
 pid=12324 comm="gcc" path="/usr/lib/gcc/x86_64-linux-gnu/6/collect2" 
dev="vda1" ino=141628 
scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:lib_t:s0 tclass=file permissive=0
--



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

Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages selinux-policy-default depends on:
ii  libselinux1  2.6-3+b3
ii  libsemanage1 2.6-2
ii  libsepol12.6-2
ii  policycoreutils  2.6-3
ii  selinux-utils2.6-3+b3

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.6-2
ii  setools  4.0.1-6

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- no debconf information

Bug#962215: libfox-1.6-0: Is it possible to package fox-1.7.67 or higher?

[Fabian Wolff]

Hi Roland,

I totally understand your need for a more recent version of the FOX
toolkit. There has been very little upstream activity on the 1.6
("stable") branch in the last few years, and honestly, I don't know
why the 1.7 branch isn't yet considered stable or if/when this will
ever happen.

However, there are a few packages in Debian that depend on the 1.6
branch of FOX, and, without having checked this myself, I would assume
that they won't just work with 1.7 (i.e., someone would have to patch
them). Additionally, some Debian users are probably using the FOX 1.6
development package for their own projects, so I can't just drop 1.6
and move to 1.7.

Instead, one would have to create a new package for the 1.7 branch and
maintain that in parallel to the existing 1.6 package (as far as I can
see, this won't lead to any package name clashes).

The fact that 1.7 is still considered the "development" branch is not
such a big deal in my view, because there are regular releases and the
1.7 branch has existed for quite a long time now. The much larger
practical problem is that I currently don't have the time to package
and maintain the 1.7 branch myself.


I have reassigned your bug report as a RFP (Request For Package) to
the "wnpp" package, because it really doesn't have much to do with the
fox1.6 source package, which I maintain. This way, other people can
see that FOX 1.7 has been requested as a Debian package, and if you're
lucky, someone will come along and package/maintain it.

Even if that happens, it can take a while, though, so your best bet
right now would probably be to package and maintain FOX 1.7 yourself.
I haven't personally attempted this, but I would suspect that the
package would look rather similar to the fox1.6 package, so you could
use this as a basis.


I hope this helps, sorry for not being able to solve your problem
right away!

Best regards,
Fabian

Bug#962227: buster-pu: package libapache-mod-jk/1:1.2.46-1

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

I would like to fix Debian bug #928813 in Buster. Stretch is not
affected. Due to wrong file naming the configuration file for
libapache-mod-jk was not installed into the mods-enabled directory of
Apache 2 when a2enmod was used. Please find attached the debdiff.

Regards,

Markus
diff -Nru libapache-mod-jk-1.2.46/debian/changelog 
libapache-mod-jk-1.2.46/debian/changelog
--- libapache-mod-jk-1.2.46/debian/changelog2018-10-14 12:26:05.0 
+0200
+++ libapache-mod-jk-1.2.46/debian/changelog2020-06-04 21:18:07.0 
+0200
@@ -1,3 +1,10 @@
+libapache-mod-jk (1:1.2.46-1+deb10u1) buster; urgency=medium
+
+  * Rename httpd-jk.conf to jk.conf to restore compatibility with Debian's 
Apache
+helpers a2enmod and a2dismod. (Closes: #928813)
+
+ -- Markus Koschany   Thu, 04 Jun 2020 21:18:07 +0200
+
 libapache-mod-jk (1:1.2.46-1) unstable; urgency=medium
 
   * New upstream version 1.2.46.
diff -Nru libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.install 
libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.install
--- libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.install2018-10-14 
12:26:05.0 +0200
+++ libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.install2020-06-04 
21:18:07.0 +0200
@@ -1,4 +1,4 @@
-conf/httpd-jk.conf   /etc/apache2/mods-available/
+conf/jk.conf/etc/apache2/mods-available/
 debian/jk.load  /etc/apache2/mods-available/
 debian/workers.properties   /etc/libapache2-mod-jk/
 native/apache-2.0/mod_jk.so /usr/lib/apache2/modules/
diff -Nru libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.links 
libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.links
--- libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.links  2018-10-14 
12:26:05.0 +0200
+++ libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.links  2020-06-04 
21:18:07.0 +0200
@@ -1 +1 @@
-/etc/apache2/mods-available/httpd-jk.conf /etc/libapache2-mod-jk/httpd-jk.conf
+/etc/apache2/mods-available/jk.conf /etc/libapache2-mod-jk/httpd-jk.conf
diff -Nru libapache-mod-jk-1.2.46/debian/rules 
libapache-mod-jk-1.2.46/debian/rules
--- libapache-mod-jk-1.2.46/debian/rules2018-10-14 12:26:05.0 
+0200
+++ libapache-mod-jk-1.2.46/debian/rules2020-06-04 21:18:07.0 
+0200
@@ -24,5 +24,9 @@
 # No check target
 override_dh_auto_test:
 
+override_dh_install:
+   mv $(CURDIR)/conf/httpd-jk.conf $(CURDIR)/conf/jk.conf
+   dh_install
+
 get-orig-source:
uscan --verbose --download-current-version --force-download

Bug#962223: selinux-policy-default: SELinux is preventing chronyd from access on the chronyc's unix_dgram_socket

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Followup-For: Bug #962223

I've found release, where policy has fixed: 2.20180701
here it is the commit 
https://github.com/SELinuxProject/refpolicy/commit/3ab07a0e1ee01ee62a6102acdd3957e6894bf795


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

Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages selinux-policy-default depends on:
ii  libselinux1  2.6-3+b3
ii  libsemanage1 2.6-2
ii  libsepol12.6-2
ii  policycoreutils  2.6-3
ii  selinux-utils2.6-3+b3

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.6-2
ii  setools  4.0.1-6

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- no debconf information

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Adrian Bunk]

On Thu, Jun 04, 2020 at 07:55:32PM +0200, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> On Thu, Jun 04, 2020 at 07:59:22PM +0300, Adrian Bunk wrote:
> > FAIL: dtls_hello_random_value
> > =
> > 
> > testing: default
> > client:156: client: Handshake failed: Resource temporarily unavailable, try 
> > again.
> > server:271: server: Handshake has failed: The TLS connection was 
> > non-properly terminated.
> > 
> > FAIL dtls_hello_random_value (exit status: 1)
> > 
> This particular test seems to use a AF_UNIX socketpair, I'm not sure
> how it would fail due to network setup?

I copied the log from the 3.6.13-4 arm64 failure.
This specific test passes in the other logs.

The binary-all log (non-conova) of 3.6.13-4 has no test failures,
but the build fails due to timeout after 150 minutes without output.

My gut feeling is that there might be an (unrelated) problem with 
the #961889 fix, but this is just a guess.

> Cheers,
> Julien

cu
Adrian

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

[Tobias Frost]

On Thu, Jun 04, 2020 at 06:33:10PM +0200, Roland Plüss wrote:
> 
> On 5/31/20 9:19 AM, Tobias Frost wrote:
> > If you want to follow this route, your next step would be now to contact
> > the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking
> > to package the version you need, explaining the situation and maybe (==
> > if you want) tell them that you would commit helping to offset the extra
> > work caused by maintaining the development snapshot.
> >
> > * dak spits out those r-deps:
> > ace: libfox-1.6-dev
> > gogglesmm: libfox-1.6-dev
> > libgwenhywfar: libfox-1.6-dev
> > pcsc-cyberjack: libfox-1.6-dev
> > sumo: libfox-1.6-dev
> > xfe: libfox-1.6-dev (>= 1.6.45)
> >
> I tried doing this with reportbug but I failed. It asks me first for the
> package where the bug is found. I entered as you suggested "src:fox1.6".
> Reportbug complains "src:fox1.6 is not a valid package name.". What am I
> doing wrong?

Ah, sorry, didn't meant to confuse you. src:$package just means "against the 
source package", so you would do a "reportbug --src fox1.6" or a plain
"reportbug fox1.6" works too.
 
> -- 
> Mit freundlichen Grüssen
> Plüss Roland
> 
> Game Development and Game Engine Technologies https://dragondreams.ch
> 

Bug#962226: libdr-tarantool-perl build-depends on obsolete package

[peter green]

Source: libdr-tarantool-perl
Version: 0.45-2
Severity: serious
Tags: bullseye, sid

libdr-tarantool-perl build-depends on

tarantool-lts | tarantool (<< 1.6)

tarantool-lts has been removed from Debian and tarantool is now at version 
1.9.1.26.g63eb81e3c-1.1

Bug#962225: smokeping: SmokePing 2.7.3 needs a patch to mitigate '"Unknown key type "rsa1"' (SSH probe)

[Milosz Galazka]

Package: smokeping
Version: 2.7.3-2
Severity: normal

Dear Maintainer,

It is not possible to use SSH probe on Debian Buster:

```
$ sudo smokeping --debug

ERROR: output of '/usr/bin/ssh-keyscan -t dsa,rsa,rsa1 127.0.0.1' does not 
match (?^i:^# \S+ SSH-)
 at (eval 59) line 1.
```

because ssh-keyscan does not support rsa1:

```
$ /usr/bin/ssh-keyscan -t dsa,rsa,rsa1 127.0.0.1
Unknown key type "rsa1"
```

The solution is to apply patch: 
https://github.com/oetiker/SmokePing/commit/62ac9fda04b994bbf4f97d3dd1cf8b92cf279e71.patch?diff=unified

```
>From 62ac9fda04b994bbf4f97d3dd1cf8b92cf279e71 Mon Sep 17 00:00:00 2001
From: "Avinash H. Duduskar" 
Date: Mon, 11 Mar 2019 13:16:13 +0530
Subject: [PATCH] Update SSH.pm to drop SSHv1 rsa1

- Removes rsa1
- Adds ecdsa instead
https://github.com/oetiker/SmokePing/issues/120
---
 lib/Smokeping/probes/SSH.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Smokeping/probes/SSH.pm b/lib/Smokeping/probes/SSH.pm
index ffbb5cc2..f21f53e8 100644
--- a/lib/Smokeping/probes/SSH.pm
+++ b/lib/Smokeping/probes/SSH.pm
@@ -55,7 +55,7 @@ sub new($$$)
 # no need for this if we run as a cgi
 unless ( $ENV{SERVER_SOFTWARE} ) {

-my $call = "$self->{properties}{binary} -t dsa,rsa,rsa1 127.0.0.1";
+my $call = "$self->{properties}{binary} -t dsa,rsa,ecdsa 127.0.0.1";
 my $return = `$call 2>&1`;
 if ($return =~ m/$ssh_re/s){
 print "### parsing ssh-keyscan output...OK\n";
@@ -132,7 +132,7 @@ sub targetvars {
 return $class->_makevars($class->SUPER::targetvars, {
keytype => {
_doc => "Type of key, used in ssh-keyscan -t I",
-  _re => "[dr]sa1*",
+  _re => "[ecdr]sa*",
_example => 'dsa',
_default => 'rsa',
},
``` 

Kind regards,
Milosz


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
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 smokeping depends on:
ii  adduser3.118
ii  debianutils4.8.6.1
ii  exim4-daemon-light [mail-transport-agent]  4.92-8+deb10u4
ii  fping  4.2-1
ii  libcgi-fast-perl   1:2.13-1
ii  libconfig-grammar-perl 1.12-2
ii  libdigest-hmac-perl1.03+dfsg-2
ii  libjs-cropper  1.2.2-1
ii  libjs-prototype1.7.1-3
ii  libjs-scriptaculous1.9.0-2
ii  librrds-perl   1.7.1-2
ii  libsnmp-session-perl   1.14~git20130523.186a005-4
ii  liburi-perl1.76-1
ii  libwww-perl6.36-2
ii  lsb-base   10.2019051400
ii  perl   5.28.1-6
ii  ucf3.0038+nmu1

Versions of packages smokeping recommends:
pn  apache2 | apache2 | httpd  
ii  dnsutils   1:9.11.5.P4+dfsg-5.1+deb10u1
ii  echoping   6.0.2-10
ii  libsocket6-perl0.29-1+b1
ii  nginx-full [httpd-cgi] 1.14.2-2+deb10u1

Versions of packages smokeping suggests:
ii  curl   7.64.0-4+deb10u1
pn  libauthen-radius-perl  
ii  libio-socket-ssl-perl  2.060-3
pn  libnet-dns-perl
pn  libnet-ldap-perl   
pn  libnet-telnet-perl 
ii  openssh-client 1:7.9p1-10+deb10u2

-- Configuration Files:
/etc/smokeping/smokeping_secrets [Errno 13] Permission denied: 
'/etc/smokeping/smokeping_secrets'

-- no debconf information

Bug#962224: lightdm does not source ~/.profile

[Graeme Vetterlein]

Package: lightdm
Version: 1.26.0-4
Severity: normal
Tags: newcomer

Dear Maintainer,

*** 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 ***

Having switched to lightdm from GDM3 (due to another bug in gdm3) I now find
~/.profile does
not run.

In order to debug this I created a clean user (new) called guest (pid=1001)
I modified ~/.profile and ~/.bash_profile to log their use (see attached log)

In summary the behaviour was:

gdm3 + cinnamon = Runs ~/.profile only
gdm3 + xfce = Runs ~/.profile only
gdm3 + gnome3 = Runs ~/.profile only

Switch to lioghtdm & reboot system

lightdm + cinnamon = Runs neither
lightdm + xfce = Runs neither
lightdm + gnome = Runs neither
lightdm + gnome(2nd version) = Runs neither

The doc @ https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/794315 points
to where this has been fixed in the past.




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

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

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.16-1
ii  debconf [debconf-2.0]  1.5.71
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libpam-systemd [logind]241-7~deb10u4
ii  libpam0g   1.3.1-5
ii  libxcb11.13.1-2
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.6-1
ii  lsb-base   10.2019051400

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

Versions of packages lightdm suggests:
ii  accountsservice  0.6.45-2
ii  upower   0.99.10-1
ii  xserver-xephyr   2:1.20.4-1

-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm
$ head -20 ~/.profile 
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022



ENV="/tmp/${USER}.env"
rm -f ${ENV}
echo ".profile run at $(date)" >  ${ENV}
pstree -glus $$>> ${ENV}
env>> ${ENV} 2>&1

LOGON_TIME=$(date) export LOGON_TIME

$ head -20 ~/.bash_profile 
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022



ENV="/tmp/${USER}-bash.env"
rm -f ${ENV}
echo ".profile run at $(date)" >  ${ENV}
pstree -glus $$>> ${ENV}
env>> ${ENV} 2>&1

LOGON_TIME=$(date) export LOGON_TIME

$ 


*** GDM3 + cinnamon 

$ ls -l /tmp/*.env
-rw-rw-rw- 1 graeme users  462 Jun  4 18:37 /tmp/graeme-bash.env
-rw-r--r-- 1 graeme users 1226 Jun  4 18:37 /tmp/graeme.env
-rw-r--r-- 1 guest  guest  839 Jun  4 18:42 /tmp/guest.env
$ id
uid=1001(guest) gid=1001(guest) groups=1001(guest)
$ cat /tmp/guest.env 
.profile run at Thu  4 Jun 18:42:46 BST 2020
systemd(1)---gdm3(826)---gdm-session-wor(826)---gdm-x-session(8109,guest)---Xsession(8109)---pstree(8109)
USER=guest
LANGUAGE=en_GB:en
XDG_SEAT=seat0
XDG_SESSION_TYPE=x11
HOME=/home/guest
DESKTOP_SESSION=cinnamon
GTK_MODULES=gail:atk-bridge
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus
LOGNAME=guest
XDG_SESSION_CLASS=user
USERNAME=guest
XDG_SESSION_ID=25
WINDOWPATH=4
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
GDM_LANG=en_GB.UTF-8
XDG_RUNTIME_DIR=/run/user/1001
DISPLAY=:0
LANG=en_GB.UTF-8
XDG_SESSION_DESKTOP=cinnamon
XAUTHORITY=/run/user/1001/gdm/Xauthority
SHELL=/bin/sh
GDMSESSION=cinnamon
QT_ACCESSIBILITY=1
XDG_VTNR=4
PWD=/home/guest
XDG_DATA_DIRS=/home/guest/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:

Bug#953262: lintian.d.o: Provide archive-wide statistics on home page

[Felix Lechner]

Control: retitle -1 lintian.d.o: Provide archive-wide statistics on home page

Hi s3v,

> I would like to see stats of Lintian's tags get restored on the main web
> page of the project.

First of all, sorry our web service has been spotty. We hope it will
become one of people's favorite interfaces to research issues in
Debian packages.

Your request predates my involvement but I would like to understand
how to make our data more meaningful on an archive level. (The
'archive' is actually a fluid set of packages that is constantly
synchronized via dakweb.) I can find meaning only by slicing the data
in other dimensions, such as by architecture, or by providing
normalized averages, such as tags per package or overrides per
package, and so on.

Below you will find an old snapshot from the Internet Archive's
Wayback Machine. Which data was most useful to you, please, and why?

Kind regards,
Felix Lechner

* * *

Archives

The following archives are processed by Lintian:

Archive nameAttributeAttribute value
debianArchitecturesi386 amd64
Distributions/Suitesunstable experimental
Componentsmain contrib non-free
Mirror timestampSun, 21 Apr 2019 20:30:22 +
debian-debugArchitecturesi386 amd64
Distributions/Suitesunstable-debug experimental-debug
Componentsmain contrib non-free
Mirror timestampSun, 21 Apr 2019 20:30:22 +

Statistics

Last updated: Mon, 22 Apr 2019 00:33:21 +
Maintainers: 2423 (+0)
Package groups: 31284 (+5)
Rescheduled groups: 3 (+0)
Groups with processing errors: 3 (+0)
Source packages: 29929 (+1)
Binary packages: 39928 (-3)
μdeb packages: 225 (+0)
E Errors: 32305 (+4)
W Warnings: 186976 (-6)
I Info tags: 575740 (-196)
P Pedantic tags: 175454 (-42)
O Overridden tags: 181682 (-138)
X Experimental tags: 124653 (+25)
Lintian version: 2.12.0

(The numbers in parentheses describe the changes since the last
Lintian report, published on Sun, 21 Apr 2019 00:28:21 +.)

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[Aleksey Tulinov]

On Wed, 9 Oct 2019 17:36:07 +0200 David Kalnischkies
 wrote:

> As Julian already said, it is "just" used for its dbus communication
> implementation. We don't require systemd to be your init or to be even
> functional. So I guess proposing an alternative which a) works equally
> well and b) doesn't add additional bootstrapping complications has
> better chances of acceptance – assuming that exists as the obvious
> choice libdbus links against libsystemd as well even before checking a)
> and b) …
>

I'm not a big expert in systemd and never will be, but perhaps
`systemd-inhibit --what="shutdown" --mode="block" apt ...` should do
about the same thing. If every invocation of apt should be like that
then maybe `alias apt='systemd-inhibit --what="shutdown"
--mode="block" apt'` in .bashrc can do the trick. This does not
require any patching whatsoever.

This linking to libsystemd is redundant. If issue is with dpkg leaving
system in inconsistent state when interrupted, then perhaps this issue
has to be fixed in dpkg, if issue is with systemd incorrectly
interrupting dpkg, then in systemd. I think that dependency on
systemd:

1) Doesn't solve any underlying issues;
2) Doesn't solve any issues on systems without systemd;
3) Doesn't solve the issue on systems with systemd installed but not
running because in that case there won't be anyone to react on dbus
message and inhibit shutdown, so this is not going to work.

So it doesn't do much anyway, it attempts to solve some very specific
issue in very specific environment, but it doesn't do that very well
and can be replaced with one shell alias.

It would be really nice if this dependency is removed and ideally
underlying issue(s) properly fixed instead of applying band aid here
and there.

Bug#962157: marked as pending in lintian

[Guillem Jover]

On Thu, 2020-06-04 at 02:39:12 +, Felix Lechner wrote:
> Control: tag -1 pending

> 
> Remove command line option --fail-on from the settings in configuration 
> files. (Closes: #962157)
> 
> The configuration file supports a limited number of settings for end
> users. They all relate to the display (and one allows selecting the
> number of jobs).
> 
> The --fail-on command option, on the other hand, is used only in
> automated settings.  No one on the team that implemented it plans to
> use it in a configuration file. It was a mistake to include that
> option among those available in configuration files.
> 
> For automated settings, the --fail-on command-line option can be
> conveniently enabled in a transparent and straightforward manner. It
> should be added by the invocant as '--fail-on error'.
> 
> Users who rely on the exit status are furthermore advised to examine
> their scripts. The exit codes for program errors and the conditions
> selected via --fail-on are now reversed.
> 
> The new option was introduced at the same time to miminize the overall
> inconvenience. Thank you for using Lintian!
> 

Hmm, well that's unfortunate, :/ as the support for this option in the
config file makes it very convenient to set a global value different
than the default, instead of having to modify all local instances to
use the same value. Please could you restore this support and add a
value to denote «none» or perhaps a --no-fail-on or similar?

(I'd personally have in general more stuff configurable via the config
file rather than less.)

Thanks,
Guillem

Bug#962139: [btrfs-progs] initramfs hooks failed with on libgcc_s.so.1

[Daniel Schröter]

On 04.06.20 12:41, Adam Borowski wrote:
> As your setup is different from mine: could you please confirm that
> installing libcc-s1 fixes the problem?

Do you mean libgcc-s1? It's already installed because of dependency to apt.

I have the file under /usr:
# ll /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
-rw-r--r-- 1 root root 99K Feb  4 15:52 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1

Bye

Bug#948626: kicad: Closing pcbnew hangs main kicad process

[Paul "LeoNerd" Evans]

On Thu, 4 Jun 2020 16:45:45 +0100
"Paul \"LeoNerd\" Evans"  wrote:

> At this point now I'm a little stuck, because being unable to
> associate footprints with components, I can't actually make any new
> boards. With pcbnew crashing only on exit, at least I could edit and
> save just fine within one editing session, as it would only crash
> when I tried to exit anyway. At the moment I can't work on new
> boards, so this has become a bit more critical a failure. :(

Some further investigation and help from `nickoe` on the #kicad
channel on Freenode have lead me to find out that kicad was getting
confused with something still remaining from an older built-from-source
install still remaining in /usr/local. While I had removed most of the
binaries and libraries in there, there was apparently something still
left behind. A more thorough removal of various pieces there has now
fixed all my hanging issues.

I think this bug can be closed now.

Thanks all :)

-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/


pgpFb_S9NMkSq.pgp
Description: OpenPGP digital signature

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Julien Cristau]

Control: tag -1 moreinfo

On Thu, Jun 04, 2020 at 07:59:22PM +0300, Adrian Bunk wrote:
> FAIL: dtls_hello_random_value
> =
> 
> testing: default
> client:156: client: Handshake failed: Resource temporarily unavailable, try 
> again.
> server:271: server: Handshake has failed: The TLS connection was non-properly 
> terminated.
> 
> FAIL dtls_hello_random_value (exit status: 1)
> 
This particular test seems to use a AF_UNIX socketpair, I'm not sure
how it would fail due to network setup?

Cheers,
Julien

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Adrian Bunk]

On Thu, Jun 04, 2020 at 07:32:13PM +0200, Andreas Metzler wrote:
> On 2020-06-04 Adrian Bunk  wrote:
> > Source: gnutls28
> > Version: 3.6.13-2
> > Severity: serious
> > Tags: ftbfs
> 
> > https://buildd.debian.org/status/logs.php?pkg=gnutls28&ver=3.6.13-3
> > https://buildd.debian.org/status/logs.php?pkg=gnutls28&ver=3.6.13-4
> 
> > ...
> [...]
> 
> > The conova buildds are IPv6-only, see #962019 for a similar
> > problem in perl.
> 
> Helo Adrian,
> 
> is there a way to declare a dependency on IPv4 for building?

No.

> Also the setup is strange, both netstat and ifconfig show IPv4:
> 
> DEBUG info about network setup starts ...
> if test -x /sbin/ifconfig ; then /sbin/ifconfig ; else true ; fi
> eth0: flags=4163  mtu 1500
> inet6 2a02:16a8:dc41:100::240  prefixlen 64  scopeid 0x0
> inet6 fe80::216:37ff:fed2:16f0  prefixlen 64  scopeid 0x20
> ether 00:16:37:d2:16:f0  txqueuelen 1000  (Ethernet)
> RX packets 108814178  bytes 157204088386 (146.4 GiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 13855486  bytes 11641875516 (10.8 GiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 1000  (Local Loopback)
> RX packets 4506091  bytes 20691973484 (19.2 GiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 4506091  bytes 20691973484 (19.2 GiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>...

The usage of AI_ADDRCONFIG in src/serv.c:listen_socket() looks similar
to the problem described in the perl bug.

> cu Andreas
>...

cu
Adrian

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Julien Cristau]

On Thu, Jun 04, 2020 at 07:32:13PM +0200, Andreas Metzler wrote:
> On 2020-06-04 Adrian Bunk  wrote:
> > Source: gnutls28
> > Version: 3.6.13-2
> > Severity: serious
> > Tags: ftbfs
> 
> > https://buildd.debian.org/status/logs.php?pkg=gnutls28&ver=3.6.13-3
> > https://buildd.debian.org/status/logs.php?pkg=gnutls28&ver=3.6.13-4
> 
> > ...
> [...]
> 
> > The conova buildds are IPv6-only, see #962019 for a similar
> > problem in perl.
> 
> Helo Adrian,
> 
> is there a way to declare a dependency on IPv4 for building?
> 
> Also the setup is strange, both netstat and ifconfig show IPv4:
> 
eth0 has no ipv4, that's all.  Why is that strange?

Cheers,
Julien

Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin

[Ricardo Ribalda Delgado]

Hi Jonas

Thanks for the heads up.

I have just updated my salsa to 2.2.0
https://salsa.debian.org/ribalda-guest/ugrep/-/tree/debian In case
that you want to give it a try.

When zumbi has some time it will be updated.

Best regards

On Thu, Jun 4, 2020 at 12:04 PM Jonas Smedegaard  wrote:
>
> Quoting Ricardo Ribalda Delgado (2020-05-19 18:13:16)
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ricardo Ribalda Delgado 
> >
> > * Package name: ugrep
> >   Version : 2.1.1
> >   Upstream Author : Robert van Engelen 
> > * URL : https://github.com/Genivia/ugrep/wiki
> > * License : BSD-3-Clause
> >   Programming Lang: C++
> >   Description : Universal grep: ultra fast searcher of file systems, 
> > text and binary files, source code, archives, compressed files, documents, 
> > and more.
> >
> >
> > NEW ultra fast grep with interactive query UI: search file systems,
> > text, source code, binary files, archives (cpio/tar/pax/zip), compressed
> > files (zip/gz/Z/bz2/lzma/xz), documents, and more.
> >
> > It is also very useful when  grepping on codebase with unicode files.
> >
> > I plan to send with a sponsor (zumbi). Hopefuly I will be able to
> > upload packages on my own ;).
>
> Thanks a lot for your work on this package, Ricardo!
>
> Zumbi just now told me that the package is in NEW queue - great! That's
> not the newest upstream release, however: Please consider upgrading to
> release 2.1.4 or newer, for its improved handling of large collections
> of patterns with named capture, as discussed at
> https://github.com/Genivia/ugrep/issues/35
>
> Kind regards,
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



-- 
Ricardo Ribalda

Bug#962223: selinux-policy-default: SELinux is preventing chronyd from access on the chronyc's unix_dgram_socket

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Severity: important

Description of problem:
SELinux is preventing chronyd from sendto access on the chronyc's 
unix_dgram_socket.
Chronyc cli is working slower in the Enforcing Selinux mode.
When you start chronyc cli it creates the socket there 
/var/run/chrony/chronyc.(chronyc_pid).sock.

-- Socket is here
root@vps:~# ls -la /var/run/chrony
total 0
drwxr-x---.  2 _chrony _chrony  80 Jun  4 18:17 .
drwxr-xr-x. 26 rootroot800 Jun  4 00:18 ..
srw-rw-rw-.  1 rootroot  0 Jun  4 18:17 chronyc.8825.sock
srwxr-xr-x.  1 _chrony _chrony   0 Jun  3 23:20 chronyd.sock
root@vps:~# ps aux | grep 8825
root  8825  0.0  0.1  29972  1704 pts/1S+   18:17   0:00 chronyc
root  8838  0.0  0.0  12780   944 pts/0S+   18:18   0:00 grep 
--color=auto 8825
root@vps:~#

-- Time of chronyc execution is slower by ~36 times in Enforcing mode
root@vps:~# setenforce 0
root@vps:~# time (chronyc sources &> /dev/null )

real0m0.012s
user0m0.004s
sys 0m0.000s
root@vps:~# setenforce 1
root@vps:~# time (chronyc sources &> /dev/null )

real0m7.022s
user0m0.000s
sys 0m0.008s
root@vps:~#

-- There are AVC deny messages in the audit.log
type=AVC msg=audit(1591284101.289:7635): avc:  denied  { sendto } for  pid=1836 
comm="chronyd" path="/run/chrony/chronyc.8865.sock" 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1591284102.293:7636): avc:  denied  { sendto } for  pid=1836 
comm="chronyd" path="/run/chrony/chronyc.8865.sock" 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1591284104.293:7637): avc:  denied  { sendto } for  pid=1836 
comm="chronyd" path="/run/chrony/chronyc.8865.sock" 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1591286013.714:7751): avc:  denied  { write } for  pid=1836 
comm="chronyd" name="chronyc.9034.sock" dev="tmpfs" ino=372397 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file permissive=0
type=AVC msg=audit(1591286014.718:7752): avc:  denied  { write } for  pid=1836 
comm="chronyd" name="chronyc.9034.sock" dev="tmpfs" ino=372397 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file permissive=0
type=AVC msg=audit(1591286016.718:7753): avc:  denied  { write } for  pid=1836 
comm="chronyd" name="chronyc.9034.sock" dev="tmpfs" ino=372397 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file permissive=0


-- Workaround is to add new fcontext and module
root@vps:/tmp# semanage fcontext -a -t chronyd_exec_t -f f "/usr/bin/chronyc"
root@vps:/tmp# cat chronyd2.te

module chronyd2 1.0;

require {
type chronyd_t;
type var_run_t;
type unconfined_t;
class unix_dgram_socket sendto;
class sock_file write;
}

#= chronyd_t ==
allow chronyd_t unconfined_t:unix_dgram_socket sendto;
allow chronyd_t var_run_t:sock_file write;




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

Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages selinux-policy-default depends on:
ii  libselinux1  2.6-3+b3
ii  libsemanage1 2.6-2
ii  libsepol12.6-2
ii  policycoreutils  2.6-3
ii  selinux-utils2.6-3+b3

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.6-2
ii  setools  4.0.1-6

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- no debconf information

Bug#850520: lintian: PT_GNU_STACK change triggers ~500 new errors

[Felix Lechner]

Hi Matthias,

> so you still need to update that list manually ...

I can revert commit 4c722ae9, which applied the tag to all
architectures instead of a select list (diff below). Is there a source
for the list, or a plan to implement additional architectures?

Kind regards
Felix Lechner

* * *

commit 4c722ae90d4c09542ee33aa549745879ea11465c
Author: Jakub Wilk 
Date:   Fri Oct 21 20:48:54 2016 +0200

checks/shared-libs: Check for PT_GNU_STACK on all architectures

The list of architectures that supported PT_GNU_STACK was woefully out
of date. Hopefully this feature is supported everywhere these days.

diff --git a/checks/shared-libs.pm b/checks/shared-libs.pm
index 93dfbed28..8122aa50c 100644
--- a/checks/shared-libs.pm
+++ b/checks/shared-libs.pm
@@ -36,19 +36,6 @@ use Lintian::Util qw(fail strip);
 # one of the following names.
 my $HWCAP_DIRS = Lintian::Data->new('shared-libs/hwcap-dirs');

-# The following architectures should always have a STACK setting in shared
-# libraries to disable executable stack.  Other architectures don't always add
-# this section and therefore can't be checked.
-my %stack_arches = map { $_ => 1 }qw(
-  alpha
-  amd64
-  i386
-  m68k
-  powerpc
-  s390
-  sparc
-);
-
 # List of symbols file meta-fields.
 my %symbols_meta_fields = map { $_ => 1 }qw(
   Build-Depends-Package
@@ -162,15 +149,11 @@ sub run {
 tag 'shlib-with-bad-permissions', $cur_file, $perms;
 }

-# executable stack.  We can only warn about a missing
-# section on some architectures.  Only warn if there's an
-# Architecture field; if that's missing, we'll already be
-# complaining elsewhere.
+# executable stack.
 if (not defined $objdump->{$cur_file}{'PH'}{STACK}) {
 if (defined $info->field('architecture')) {
 my $arch = $info->field('architecture');
-tag 'shlib-without-PT_GNU_STACK-section', $cur_file
-  if $stack_arches{$arch};
+tag 'shlib-without-PT_GNU_STACK-section', $cur_file;
 }
 } elsif ($objdump->{$cur_file}{'PH'}{STACK}{flags} ne 'rw-'){
 tag 'shlib-with-executable-stack', $cur_file;
diff --git a/debian/changelog b/debian/changelog
index 7b8e8411e..541ad1e73 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -19,6 +19,7 @@ lintian (2.5.49) UNRELEASED; urgency=medium
 + [JW] Don't complain about missing SONAME for position-independent
   executables.  Thanks to Reuben Thomas for the bug report.
   (Closes: #731987)
++ [JW] Check for PT_GNU_STACK existence on all architectures.
   * checks/source-copyright.pm:
 + [RA, JW] Fix handling punctuation characters in license expressions
   in machine-readable copyright files.  (Closes: #841356)

Bug#962222: makedumpfile does not translate addresses properly on arm64

[Ioanna Alifieraki]

Package: makedumpfile
Version: 1:1.6.7-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Dear Maintainer,

On some arm systems makedumpfile fails to translate virtual to physical 
addresses properly.
This may result in makedumpfile looping forever exhausting all memory,
or translating a virtual address to an invalid physical address and then 
failing and falling back to cp.
The reason it cannot resolve some addresses is because the PMD mask is wrong.
When physical address mask allows up to 48bits pmd mask should allow the
same, currently pmd mask is set to 40bits (see commit [1]).

For more information please refer to :
https://launchpad.net/bugs/1869465

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

The patch aligns the PMD_SECTION_MASK with PHYS_MASK and fixed the bug.

  * d/p/align_PMD_SECTION_MASK_with_PHYS_MASK.patch (LP: #1869465) 


Thanks for considering the patch.

[1] 
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b

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

Kernel: Linux 5.4.0-33-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
makedumpfile-1.6.7/debian/patches/align_PMD_SECTION_MASK_with_PHYS_MASK.patch 
makedumpfile-1.6.7/debian/patches/align_PMD_SECTION_MASK_with_PHYS_MASK.patch
--- 
makedumpfile-1.6.7/debian/patches/align_PMD_SECTION_MASK_with_PHYS_MASK.patch   
1970-01-01 00:00:00.0 +
+++ 
makedumpfile-1.6.7/debian/patches/align_PMD_SECTION_MASK_with_PHYS_MASK.patch   
2020-06-04 13:36:01.0 +
@@ -0,0 +1,34 @@
+From: Michal Suchanek 
+Origin: Upstream, 
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1869465
+Date: Mon, 16 Mar 2020 19:39:58 +0100
+Subject: [PATCH] Align PMD_SECTION_MASK with PHYS_MASK
+
+Reportedly on some arm64 systems makedumpfile loops forever exhausting
+all memory when filtering kernel core. It turns out the reason is it
+cannot resolve some addresses because the PMD mask is wrong. When
+physical address mask allows up to 48bits pmd mask should allow the
+same.
+I suppose you would need a system that needs physical addresses over 1TB
+to be able to reproduce this. This may be either because you have a lot
+of memory or because the firmware mapped some memory above 1TB for some
+reason.
+
+Signed-off-by: Michal Suchanek 
+---
+ arch/arm64.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+Index: makedumpfile-1.6.7/arch/arm64.c
+===
+--- makedumpfile-1.6.7.orig/arch/arm64.c
 makedumpfile-1.6.7/arch/arm64.c
+@@ -81,7 +81,7 @@ static unsigned long kimage_voffset;
+  * Remove the highest order bits that are not a part of the
+  * physical address in a section
+  */
+-#define PMD_SECTION_MASK  ((1UL << 40) - 1)
++#define PMD_SECTION_MASK  ((1UL << PHYS_MASK_SHIFT) - 1)
+ 
+ #define PMD_TYPE_MASK 3
+ #define PMD_TYPE_SECT 1
diff -Nru makedumpfile-1.6.7/debian/patches/series 
makedumpfile-1.6.7/debian/patches/series
--- makedumpfile-1.6.7/debian/patches/series2020-03-17 19:40:38.0 
+
+++ makedumpfile-1.6.7/debian/patches/series2020-06-04 13:36:01.0 
+
@@ -1 +1,2 @@
 0002-adapt-makefile-to-debian.patch
+align_PMD_SECTION_MASK_with_PHYS_MASK.patch

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Andreas Metzler]

On 2020-06-04 Adrian Bunk  wrote:
> Source: gnutls28
> Version: 3.6.13-2
> Severity: serious
> Tags: ftbfs

> https://buildd.debian.org/status/logs.php?pkg=gnutls28&ver=3.6.13-3
> https://buildd.debian.org/status/logs.php?pkg=gnutls28&ver=3.6.13-4

> ...
[...]

> The conova buildds are IPv6-only, see #962019 for a similar
> problem in perl.

Helo Adrian,

is there a way to declare a dependency on IPv4 for building?

Also the setup is strange, both netstat and ifconfig show IPv4:

DEBUG info about network setup starts ...
if test -x /sbin/ifconfig ; then /sbin/ifconfig ; else true ; fi
eth0: flags=4163  mtu 1500
inet6 2a02:16a8:dc41:100::240  prefixlen 64  scopeid 0x0
inet6 fe80::216:37ff:fed2:16f0  prefixlen 64  scopeid 0x20
ether 00:16:37:d2:16:f0  txqueuelen 1000  (Ethernet)
RX packets 108814178  bytes 157204088386 (146.4 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 13855486  bytes 11641875516 (10.8 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Local Loopback)
RX packets 4506091  bytes 20691973484 (19.2 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 4506091  bytes 20691973484 (19.2 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

netstat -tln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State
tcp0  0 0.0.0.0:25  0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:56660.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:  0.0.0.0:*   LISTEN
tcp6   0  0 :::25   :::*LISTEN
tcp6   0  0 :::5666 :::*LISTEN
tcp6   0  0 :::4949 :::*LISTEN
tcp6   0  0 ::1:53  :::*LISTEN
tcp6   0  0 :::22   :::*LISTEN
... DEBUG info about network setup ends.
dh_auto_test -O--builddirectory=b4deb --verbose -- VERBOSE=1
cd b4deb && make -j4 check VERBOSE=1 VERBOSE=1

cu Andreas

PS: I wish the introduction of IPv6-only buildds a) had not happened
when I was trying to get a fix for a serious bug into testing (and
buster) and b) was not happening without announcement.

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#962221: xawtv: CVE-2020-13696

[Salvatore Bonaccorso]

Source: xawtv
Version: 3.106-1
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for xawtv.

CVE-2020-13696[0]:
| v4l-conf setuid-root program allows file existence tests and open(...,
| O_RDRW) on arbitrary files

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13696
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13696
[1] https://www.openwall.com/lists/oss-security/2020/06/04/6

Regards,
Salvatore

Bug#896012: lintian: Remove tag library-not-linked-against-libc

[Felix Lechner]

P.S: A recent archive-wide run showed 334 overrides and 
occurrences. The override ratio does not support a removal, but the
total number of occurrences may. Could it be true that we are shipping
 defective shared libraries? I don't think so.

Also, the tag carries the Severity 'error'.

Kind regards
Felix Lechner

* * *

detagtive=> SELECT count(taxiv.hint.id) AS hints,
count(taxiv.override.id) AS overrides

FROM taxiv.hint

INNER JOIN taxiv.run ON taxiv.run.id = taxiv.hint.run_id
INNER JOIN ftp.source ON ftp.source.id = taxiv.run.ftp_source_id
INNER JOIN ftp.source_name ON ftp.source_name.id = ftp.source.source_name_id
INNER JOIN lintian.tag ON lintian.tag.id = taxiv.hint.lintian_tag_id
INNER JOIN lintian.tag_name ON lintian.tag_name.id = lintian.tag.tag_name_id
LEFT JOIN taxiv.override ON taxiv.override.hint_id = taxiv.hint.id

WHERE
taxiv.run.lintian_version_id = 3
AND
lintian.tag_name.literal = 'library-not-linked-against-libc'

 hints | overrides
---+---
   |   334
(1 row)

Bug#962090: Same Issue with a Python3 Project for Buster

[Jürgen Kuri]

--
 cd /build/ehbackup-api-3.3.2+3+g6939d93~ui10/ && env 
PATH="/usr/lib/ccache:/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" 
dpkg-buildpackage -us -uc  -d   
dpkg-buildpackage: info: source package ehbackup-api


dpkg-buildpackage: info: source version 3.3.2+3+g6939d93~ui10   


dpkg-buildpackage: info: source distribution UNRELEASED 


dpkg-buildpackage: info: source changed by EhBackup Team 


   
dpkg-buildpackage: info: host architecture amd64


 dpkg-source --before-build .   


dpkg-source: info: using options from 
ehbackup-api-3.3.2+3+g6939d93~ui10/debian/source/options: 
--tar-ignore=build-bundle --tar-ignore=.git --tar-ignore=.gitignore 

 debian/rules clean 


dh clean


   dh_auto_clean


dh_auto_clean: warning: Please use the third-party "pybuild" build system 
instead of python-distutils 

  
dh_auto_clean: warning: This feature will be removed in compat 12.  


Can't exec "pyversions": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 124. 

  
dh_auto_clean: error: failed to run pyversions  


make: *** [debian/rules:9: clean] Error 255 


dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2 
--

"pyversions" is part of package "python2-minimal". Why python2-minimal if I 
build a Python3 project?

My "Build-Depends" in "debian/control" file is:

-
Build-Depends: debhelper (>= 8.0.0), build-essential, python3-dev, 
libmysqlclient-dev | default-libmysqlclient-dev,
   python3-pip, python3-venv, libxml2-dev, libxslt1-dev, 
python3-sphinx, python3-setuptools

X-Python3-Version: >= 3.7
--


Jürgen



0xA811F9F222306A1E.asc
Description: application/pgp-keys

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Adrian Bunk]

Source: gnutls28
Version: 3.6.13-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=gnutls28&ver=3.6.13-3
https://buildd.debian.org/status/logs.php?pkg=gnutls28&ver=3.6.13-4

...

SKIP: ssl30-server-kx-neg
=

SKIP ssl30-server-kx-neg (exit status: 77)

SKIP: ssl30-cipher-neg
==

SKIP ssl30-cipher-neg (exit status: 77)

SKIP: fips-mode-pthread
===

We are not in FIPS140 mode
SKIP fips-mode-pthread (exit status: 77)

SKIP: fips-test
===

Please note that if in FIPS140 mode, you need to assure the library's integrity 
prior to running this test
We are not in FIPS140 mode
SKIP fips-test (exit status: 77)

SKIP: fips-override-test


Please note that if in FIPS140 mode, you need to assure the library's integrity 
prior to running this test
We are not in FIPS140 mode
SKIP fips-override-test (exit status: 77)

SKIP: ssl30-cert-key-exchange
=

SKIP ssl30-cert-key-exchange (exit status: 77)

FAIL: dtls_hello_random_value
=

testing: default
client:156: client: Handshake failed: Resource temporarily unavailable, try 
again.
server:271: server: Handshake has failed: The TLS connection was non-properly 
terminated.

FAIL dtls_hello_random_value (exit status: 1)

SKIP: starttls.sh
=

SKIP starttls.sh (exit status: 77)

SKIP: starttls-ftp.sh
=

SKIP starttls-ftp.sh (exit status: 77)

SKIP: starttls-smtp.sh
==

SKIP starttls-smtp.sh (exit status: 77)

SKIP: starttls-lmtp.sh
==

SKIP starttls-lmtp.sh (exit status: 77)

SKIP: starttls-pop3.sh
==

SKIP starttls-pop3.sh (exit status: 77)

SKIP: starttls-xmpp.sh
==

SKIP starttls-xmpp.sh (exit status: 77)

SKIP: starttls-nntp.sh
==

SKIP starttls-nntp.sh (exit status: 77)

SKIP: starttls-sieve.sh
===

SKIP starttls-sieve.sh (exit status: 77)

SKIP: p11-kit-trust.sh
==

p11-kit trust module was not found
SKIP p11-kit-trust.sh (exit status: 77)


Testsuite summary for GnuTLS 3.6.13

# TOTAL: 471
# PASS:  455
# SKIP:  15
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to b...@gnutls.org

make[6]: *** [Makefile:8525: test-suite.log] Error 1


The conova buildds are IPv6-only, see #962019 for a similar
problem in perl.

Bug#962220: libfdkaac-ocaml-dynlink: No longer works with liquidsoap

[Paul Martin]

Package: libfdkaac-ocaml-dynlink
Version: 0.3.2-1
Severity: important

The combination of liquidsoap 1.3.3-2 (stable) with
libfdkaac-ocaml-dynlink 0.2.1-1 (stable) works perfectly.

However using the current "unstable" builds of both (liquidsoap 1.4.2-1
and libfdkaac-ocaml-dynlink 0.3.2-1) doesn't work.

Whilst liquidsoap finds /usr/lib/ocaml/fdkaac/fdkaac.cmxs it can't find
/usr/lib/ocaml/fdkaac/fdkaac_loader.cmxs, which is no longer available
in current builds of libfdkaac-ocaml-dynlink.

ocaml-fdkaac recently changed to build system "dune" which doesn't
appear to build/install a loader stub.

And the upstream change that completely removed the loader stub was:

commit d3393ebecd8c851fd4a7796179888c7ab7069c0d (tag: 0.3.2)
Author: Romain Beauxis 
Date:   Fri Mar 27 17:20:19 2020 -0500

Switched to dune.

I don't see any issues for this on either
https://github.com/savonet/ocaml-fdkaac/
or
https://github.com/savonet/liquidsoap/

Bug#962219: siconos: autopkgtest needs update for new version of boost-defaults: deprecation warning on stderr

[Paul Gevers]

Source: siconos
Version: 4.2.0+git20181026.0ee5349+dfsg.2-3
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:boost-defaults

[X-Debbugs-CC: debian...@lists.debian.org,
boost-defau...@packages.debian.org]

Dear maintainer(s),

With a recent upload of boost-defaults the autopkgtest of siconos fails
in testing when that autopkgtest is run with the binary packages of
boost-defaults from unstable. It passes when run with only packages from
testing. In tabular form:

  passfail
boost-defaultsfrom testing1.71.0.3
siconos   from testing4.2.0+git20181026.0ee5349+dfsg.2-3
all othersfrom testingfrom testing

I copied some of the output at the bottom of this report. If possible,
disable deprecation warnings as autopkgtest is not the place to test for
those or, if that's not possible, add the allow-stderr restriction such
that these warnings will be ignored.

Currently this regression is blocking the migration of boost-defaults to
testing [1]. Of course, boost-defaults shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in boost-defaults was intended and your package needs to update
to the new situation.

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

Paul

[1] https://qa.debian.org/excuses.php?package=boost-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/s/siconos/5757119/log.gz

Ran 2 tests.

OK
autopkgtest [23:12:20]: test mechanics-tests: ---]
autopkgtest [23:12:20]: test mechanics-tests:  - - - - - - - - - -
results - - - - - - - - - -
mechanics-tests  FAIL stderr: In file included from
/usr/include/boost/config/header_deprecated.hpp:18,
autopkgtest [23:12:20]: test mechanics-tests:  - - - - - - - - - -
stderr - - - - - - - - - -
In file included from /usr/include/boost/config/header_deprecated.hpp:18,
 from /usr/include/boost/timer.hpp:20,
 from /usr/include/siconos/SiconosKernel.hpp:30,
 from
/tmp/autopkgtest-lxc.sn3yur2n/downtmp/autopkgtest_tmp/MultiBodyTest.cpp:85:
/usr/include/boost/timer.hpp:21:1: note: #pragma message: This header is
deprecated. Use the facilities in  instead.
   21 | BOOST_HEADER_DEPRECATED( "the facilities in
" )
  | ^~~
/usr/include/boost/progress.hpp:23:1: note: #pragma message: This header
is deprecated. Use the facilities in  instead.
   23 | BOOST_HEADER_DEPRECATED( "the facilities in
" )
  | ^~~
In file included from /usr/include/boost/config/header_deprecated.hpp:18,
 from /usr/include/boost/timer.hpp:20,
 from /usr/include/siconos/SiconosKernel.hpp:30,
 from
/tmp/autopkgtest-lxc.sn3yur2n/downtmp/autopkgtest_tmp/ContactTest.cpp:12:
/usr/include/boost/timer.hpp:21:1: note: #pragma message: This header is
deprecated. Use the facilities in  instead.
   21 | BOOST_HEADER_DEPRECATED( "the facilities in
" )
  | ^~~
/usr/include/boost/progress.hpp:23:1: note: #pragma message: This header
is deprecated. Use the facilities in  instead.
   23 | BOOST_HEADER_DEPRECATED( "the facilities in
" )
  | ^~~



signature.asc
Description: OpenPGP digital signature