Bug#1005090: ITP: node-zx -- Tool to launch modern Javascript scripts

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: node-zx
  Version : 4.3.0
  Upstream Author : Anton Medvedev 
* URL : https://github.com/google/zx
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Tool to launch modern Javascript scripts

Bash is great, but when it comes to writing scripts,
people usually choose a more convenient programming language.
JavaScript is a perfect choice, but standard Node.js library
requires additional hassle before using. The `zx` package provides
useful wrappers around `child_process`, escapes arguments and
gives sensible defaults.

This library is required to update node-core-js.

Will be maintained under JS Team umbrella.

Bug#1005089: [Pkg-javascript-devel] Bug#1005089: nodejs: Add node_modules links to nodejs

[Yadd]

On 07/02/2022 08:29, Yadd wrote:

Package: nodejs
Version: 16.13.2~dfsg-2
Severity: normal

Hi,

starting from version 14, nodejs is able to run .mjs files. However,
"import" method only works when dependency is available in node_modules
directories. To avoid having to create node_modules/* links in each
directory, it could be usefull to have node_modules links that points to
nodejs in each /usr/(share|lib|lib/${DEB_MULTIARCH})/nodejs directory.

Then only some links will be needed when a /usr/share/nodejs file tries
to "import" a /usr/li/x86_64*/nodejs module.

Alternative: modify nodejs to be able to search "import" modules in
process.config.variables.node_relative_path

Cheers,
Yadd


This will also decrease lnks needed by typescript (#930268)

Bug#1003963: libunistring: New upstream release (1.0, 2022 Jan 04)

[Jörg Frings-Fürst]

Hello,

the version 1.0-1 is uploaded into unstable. 

Closed.

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D


Jörg Frings-Fürst
D-54470 Lieser

git:  https://jff.email/cgit/


Threema: SYR8SJXB
Skype: joergpenguin
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1005089: nodejs: Add node_modules links to nodejs

[Yadd]

Package: nodejs
Version: 16.13.2~dfsg-2
Severity: normal

Hi,

starting from version 14, nodejs is able to run .mjs files. However,
"import" method only works when dependency is available in node_modules
directories. To avoid having to create node_modules/* links in each
directory, it could be usefull to have node_modules links that points to
nodejs in each /usr/(share|lib|lib/${DEB_MULTIARCH})/nodejs directory.

Then only some links will be needed when a /usr/share/nodejs file tries
to "import" a /usr/li/x86_64*/nodejs module.

Alternative: modify nodejs to be able to search "import" modules in
process.config.variables.node_relative_path

Cheers,
Yadd

Bug#1005088: RM: homer-api [armhf mips64el mipsel s390x] -- RoQA; Blocks perl transition

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-voip-maintain...@lists.alioth.debian.org
Control: block -1 by 1005087

Please remove homer-api from armhf, mips64el, mipsel, and s390x to
unblock the removal of kamailio and by extension the perl transition.

kamailio FTBFS on armhf & s390x, and on mips*el its secsipidx build
dependency cannot be installed because it FTFBS.

Kind Regards,

Bas

Bug#1005087: RM: kamailio [armhf mips64el mipsel s390x] -- RoQA; FTBFS/BD-Uninstallable (blocks perl transition)

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-voip-maintain...@lists.alioth.debian.org

Please remove kamailio from armhf, mips64el, mipsel, and s390x where to
unblock the perl transition.

kamailio FTBFS on armhf & s390x, and on mips*el its secsipidx build
dependency cannot be installed because it FTFBS.

Kind Regards,

Bas

Bug#1002527: postinst ignores USER from /etc/default/milter-greylist when invoking chown ... /var/lib/milter-greylist

[Adrian Bunk]

On Sat, Jan 22, 2022 at 05:22:29PM -0500, Marvin Renich wrote:
> retitle 1002527 milter-greylist -u user does not correctly ensure user can 
> update greylist.db
> quit
> 
> * Adrian Bunk  [220120 21:43]:
> > On Thu, Dec 23, 2021 at 02:12:04PM -0500, Marvin Renich wrote:
> > >...
> > > With an existing installation of milter-greylist set up to work with
> > > chrooted postfix (i.e. USER="postfix" in /etc/default/milter-greylist),
> > > every upgrade sets the owner of the directory /var/lib/milter-greylist
> > > to "greylist" regardless of the setting of USER.  This effectively
> > > breaks postfix, as it will no longer deliver mail until the problem is
> > > resolved.
> > > 
> > > Note that the particular system hosting my mail server is still running
> > > sysvinit, not systemd.  I do not know how milter-greylist configures the
> > > user under systemd, but the postinst has "greylist" hardcoded, so I
> > > suspect that if the sysadmin has configured a different user, this will
> > > break under systemd, as well.
> > >...
> > 
> > With systemd the problem likely doesn't exist since the user is 
> > hardcoded also in the service file:
> > 
> > /lib/systemd/system/milter-greylist.service:
> >   ExecStart=/usr/sbin/milter-greylist -u greylist
> 
> I'm not sure how that fixes anything.
>...
> milter-greylist had a documented way to run it as a different user by
> setting USER="postfix" in the above file.
> 
> I don't have milter-greylist running with postfix on a systemd system,
> so I can't test this, but I suspect that if I copied
> /lib/systemd/system/milter-greylist.service to /etc/systemd/system/ and
> edited it to use -u postfix, and corrected the ownership and permissions
> on /var/lib/milter-greylist, the next upgrade would still clobber the
> ownership, thus breaking postfix.
>...

Changing milter-greylist.service would not really be supported,
my reading of the code is that USER="postfix" is honored in the
init script but for systemd users the user cannot be changed.

Which explains why there aren't more people running into this bug.

> ...Marvin

cu
Adrian

Bug#1005086: Please package Perl::Critic::Community

[Russ Allbery]

Package: libperl-critic-freenode-perl
Version: 0.033-1
Severity: normal
X-Debbugs-Cc: r...@debian.org

Perl::Critic::Freenode has become Perl::Critic::Community, which
also means that all of the policies that it installs have been
renamed to Community::* from Freenode::*.

Unfortunately, perlcritic produces a mandatory warning when one
suppresses an unknown policy in perlcriticrc, which makes this
awkward.  Since Debian unstable has the old package and old policy
names, but installing Perl::Critic::Freenode from CPAN (in CI, for
instance) will install the current version with the Community names,
there is no way to write a perlcriticrc suppressing those policies
and have it work in both environments right now.

Could you therefore prioritize packaging Perl::Critic::Community?
I can then switch to the Community::* names when developing on
Debian unstable/testing.

Thanks!


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

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

Versions of packages libperl-critic-freenode-perl depends on:
ii  libpath-tiny-perl0.122-1
ii  libperl-critic-perl  1.140-1
ii  libperl-critic-policy-variables-prohibitlooponhash-perl  0.008-1
ii  libperl-critic-pulp-perl 99-1
ii  libppi-perl  1.271-1
ii  perl 5.32.1-6
ii  perl-base [libscalar-list-utils-perl]5.32.1-6

libperl-critic-freenode-perl recommends no packages.

libperl-critic-freenode-perl suggests no packages.

-- no debconf information

Bug#1005043: lintian: check that Python version numbers are not 0.0.0

[Julian Gilbey]

On Sun, Feb 06, 2022 at 04:46:53PM +, Stefano Rivera wrote:
> Hi Julian (2022.02.06_12:19:54_+)
> > In the couple of cases I've looked at so far, it is due to the
> > upstream version using use_scm_version in setup.py.  This works fine
> > for a version that is in a Git repository, but it doesn't work for
> > Debian packages, as the Git version lookup fails.  So this needs to be
> > patched.
> 
> Or export SETUPTOOLS_SCM_PRETEND_VERSION.
> https://github.com/pypa/setuptools_scm#environment-variables
> 
> pybuild does this for you.

Hi Stefano,

I'm a little confused by this.  Have a look at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005039 against
python3-iniconfig.  It has a very straightforward debian/rules, using
pybuild, and its setup.py script has "use_scm_version=True", but it
still produces a python package with version number 0.0.0.

I have tried this in an environment where I have
python3-setuptools-scm installed, by the way (even though the package
does not Build-Depends on it).  I'm using dh-python version 5.20220119

Best wishes,

   Julian

Bug#1004986: icmake: Fails to build bobcat on s390x

[tony mancill]

On Fri, Feb 04, 2022 at 09:44:26PM +, Daniel Bungert wrote:
> Package: icmake
> Version: 10.01.01-2
> Severity: normal
> X-Debbugs-Cc: daniel.bung...@canonical.com

Hi Daniel, hi Frank:

I have access to a s390x porterbox and can reproduce the build failure,
even with a patched version of icmake.  Thus, I have reopened the bug
and I do think that the issue lies with icmake, although I think it's
something else.  It's not even attempting to start the build.

I added the -V switch to bobcat's top-level ./build shebang to see how
far it's getting, and the answer is "not very."  The next line of output
below should be the build starting but instead it exits with with return
code 0.

(sid_s390x-dchroot)tmancill@zelenka:~/bobcat/bobcat-5.09.01$ ./build libraries 
all
calling `/usr/libexec/icmake/icm-pp ./build /tmp/6393usq56W'
calling `/usr/libexec/icmake/icm-comp /tmp/6393usq56W /tmp/6393.bim.6QGCyE'
calling `/usr/libexec/icmake/icm-exec /tmp/6393.bim.6QGCyE'

I'm attaching the output of an strace of the same command above in case
something stands out to either of you.  My next step is to install
debugging symbols for icmake and run under gdb, but I won't be able to
try that until tomorrow.

Cheers,
tony


bobcat_icmake_strace.out.gz
Description: application/gzip

Bug#1005084: linux-image-5.10.0-10-amd64: USB-c screen flickers

[Antoni Villalonga]

Package: src:linux
Version: 5.10.84-1
Severity: normal
X-Debbugs-Cc: ant...@friki.cat

Dear Maintainer,

I've noticed periodic screen flickering when using adb software.
My usb-c screen is connected directly to the main board (Intel NUC). An other
screen (not affected) is connected using DisplayPort.

After a quick strace it shows up that this syscall turns my usb-c screen black
for around one second:
  openat(AT_FDCWD, "/dev/bus/usb/004/001", O_RDONLY|O_CLOEXEC);

A small C program can reproduce the issue.

This kernel message is logged:
  usb usb4: root hub lost power or was reset


More users have noticed similar problems before:
  
https://www.reddit.com/r/androiddev/comments/hvwn1p/adb_causing_external_monitor_to_flicker/


Please note that root is not needed to reproduce the problem.


Best regards,

Bug#932568: ITP: fontbakery -- Font quality checker

[Paulo]

Hello,

My name is Paulo (kretcheu) [1]

I want to help in efforts to put Fontbakery at the Debian archive.

I was working on some dependency packages.

## ITPs

### commandlines
https://bugs.debian.org/1004969
### glyphsets
https://bugs.debian.org/1004942
### glyphtools
https://bugs.debian.org/1004991
### sre-yield
https://bugs.debian.org/1005076

Packaging is not all ready yet, but you can see the state of work at:

## Repos:

https://salsa.debian.org/kretcheu/sre-yield
https://salsa.debian.org/kretcheu/glyphsets
https://salsa.debian.org/kretcheu/glyphtools
https://salsa.debian.org/kretcheu/commandlines

[1] https://qa.debian.org/developer.php?login=kretcheu%40gmail.com

Thanks
kretcheu
:x




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005068: transition (unplanned?): libwacom9

[Simon McVittie]

On Mon, 07 Feb 2022 at 00:51:08 +, Marius Gripsgard wrote:
> The ABI/API breakage is not *too* bad, see [0]. just hope none use those 
> deprecated APIs
> 
> [0] 
> https://github.com/linuxwacom/libwacom/commit/b4f3c3f855a68e35b5ebfc305bc67c565f9146c7

Thanks. Looks like nobody should have been using those symbols anyway
(the commit message says they were private and not mentioned in any public
header files), and codesearch.debian.net does not find any references
outside src:libwacom, so it should be safe to binNMU dependent packages.

smcv

Bug#1005068: (no subject)

[Marius Gripsgard]

This is blocking a libinput causing a quite wide uninstability. (example is 
qt) 

libkf5xmlgui-dev depends on:
- libqt5gui5:amd64 (>= 5.15.2~) | libqt5gui5-gles:amd64 (>= 5.15.2~)
libqt5gui5-gles depends on:
- libinput10:amd64 (>= 0.15.0)
libinput10 depends on:
- libwacom2:amd64 (>= 1.1)
libwacom2 depends on missing:
- libwacom-common:amd64 (= 1.12-1)

The ABI/API breakage is not *too* bad, see [0]. just hope none use those 
deprecated APIs

[0] https://github.com/linuxwacom/libwacom/commit/
b4f3c3f855a68e35b5ebfc305bc67c565f9146c7

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

Bug#1005082: Exporting to .opus impossible

[Peter Mueller]

> starting audacity out of a terminal window will give you > some more 
> information. But OggOpus export doesn't seem > to work here either. Thanks, 
> Klaumi, I get the following messages in the console when trying to export and 
> the aforementioned alert window appears: “ 01:20:17: Debug: FFmpeg : Audio 
> Output Codec Frame Size: 960 samples. 01:20:17: Debug: Log: [opus @ 
> 0x7eff30f598e0] Using AVStream.codec to pass codec parameters to muxers is 
> deprecated, use AVStream.codecpar instead. ” This could be more for a 
> developer rather than for me as a user, and perhaps the time has come to let 
> Audacity 3 enter Debian. Peter

Bug#1005082: Exporting to .opus impossible

[Klaumi Klingsporn]

Am / On Sun, 06 Feb 2022 23:45:24 +
schrieb / wrote "Peter Mueller" :

> I use debian stable. When trying to export an audio track
> to OggOpus, I get an error message, “FFmpeg: Kodieren des
> Frames fehlgeschlagen”. The message occurrs right at the
> very beginning; I presume that no conversion has taken
> place so far. This failure message, though succint, is in
> reality not very useful because I don't know whether it's
> a program bug or whether (and how) to recover from it. I
> expect that instead, the exporting either just works or
> that a message is output that helps me to make it work or
> to abandon my attempts. Is it a real bug? 

Hi Peter,

starting audacity out of a terminal window will give you
some more information. But OggOpus export doesn't seem
to work here either.

Klaumi


---
Klaumi Klingsporn 
mail: klaumi...@gmx.de
web: www.klaumikli.de

Bug#1005082: Exporting to .opus impossible

[Peter Mueller]

Package: audacity
Version:  2.4.2~dfsg0-5
I use debian stable. When trying to export an audio track to OggOpus, I get an 
error message, “FFmpeg: Kodieren des Frames fehlgeschlagen”. The message 
occurrs right at the very beginning; I presume that no conversion has taken 
place so far. This failure message, though succint, is in reality not very 
useful because I don't know whether it's a program bug or whether (and how) to 
recover from it. I expect that instead, the exporting either just works or that 
a message is output that helps me to make it work or to abandon my attempts. Is 
it a real bug? Has such a conversion been implemented at all? Are 
audacity-ffmpeg communication logs stored anywhere?

Bug#1005081: RM: scmxx -- RoQA; Upstream Dead; Orphaned; Useless; Low Popcon

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,

Package scmxx ( https://tracker.debian.org/pkg/scmxx ) was orphaned since 2017
and received no package upload since then. The last upstream activity was back
in 2005, and the upstream is now defunct. It is intended to support Siemens
mobile phones that was last released back in 2001, which is now useless 20
years later. As a result, I am requesting to have it removed from Debian
archive.

Package scmxx has no reverse dependencies and build-dependencies. Its popcon
value is low (14).

Regards,
Boyuan Yang


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

Bug#1000031: Obsolete pcre3 library

[Alan DeKok]

  You can build the server without PCRE, even if the PCRE libraries are on the 
system.  Just do:

./configure  --with-pcre=no

  and it will fall back to Posix regular expressions.

Bug#1005080: RFP: emacs-libvterm -- fully-fledged terminal emulator inside GNU Emacs based on libvterm

[Martin]

Package: wnpp
X-Debbugs-Cc: Debian Emacsen team 
Severity: wishlist

* Package name: emacs-libvterm
  Version : git master
  Upstream Author : Lukas Fürmetz 
* URL : https://github.com/akermu/emacs-libvterm
* License : GPL-2+, GPL-3
  Programming Lang: C, Elisp
  Description : fully-fledged terminal emulator inside GNU Emacs based on 
libvterm

>From README.md:

> Emacs-libvterm (vterm) is fully-fledged terminal emulator inside GNU
> Emacs based on libvterm, a C library. As a result of using compiled
> code (instead of elisp), emacs-libvterm is fully capable, fast, and
> it can seamlessly handle large outputs.

Bug#1003860: RFS: makemkv-oss/1.16.5-1 [ITP] -- Convert video that you own into free format that can be played everywhere

[Ben Westover]

Hello Mathias, thank you for going through my packages in-depth.


   * The typical pattern for new source packages in Debian is to have an
ITP filed, which is then closed on the first upload. Right now you have
an ITP that's covering both source packages. I'd suggest modifying the
existing ITP you have to be specific to makemkv-oss or makemkv-bin, and
then creating a new ITP for the other. Then you can cleanly close an
ITP for each new source package.


Got it, I have modified the current ITP for makemkv-oss and created a 
new one for makemkv-bin. Added the "closes" in bin's changelog as well.



   * The changelog entry for a new package should consist solely of a
line similar to "Initial release (Closes: #)". All the
work and changes prior to upload aren't specifically called out in the
package's changelog. Also, the version number should always end in "-
1".


This actually came to my attention last week and I fixed my packages 
accordingly. I uploaded the updated packages to Mentors, but forgot to 
push the changes to git (they were committed, but I never pushed).



   * You may want to consider having two separate git repos for the two
different source packages. I realize that they are released in
lockstep, but having different repos may make life easier.


Having them in the same repo works well for now because some fixes I 
make to one apply to the other often so I can commit and push at the 
same time, but once the packages are more mature and in Debian It'll 
probably make sense to move to two separate repos.



   * You may want to look into setting up/using git-buildpackage(1)
(`gbp`), which can help make building packages much easier. Of course,
the trade-off is a bit of a learning curve, but I think it's worth it
in the long run.


My current setup works well for me, and that looks like it has a 
learning curve like you mentioned. When I'm more experienced packaging 
for Debian, I'll look into it. This also connects with having separate 
repos for makemkv-oss and makemkv-bin.



   makemkv-oss specific notes:

   * d/control: Consider setting the Architecture field for the various
lib* binary packages to match that of the makemkv binary package.


The libraries can be used in any architecture. While the main makemkv 
binary can be compiled for any architecture, it can't be used for much 
because it depends on makemkvcon that's limited to certain arches. 
Attempting to build makemkv-oss on an architecture not supported by 
makemkv just builds the two libraries and nothing else. Is this bad 
practice? Should I limit the libraries' architectures even though they 
can be used outside of makemkv on any arch?



   * d/makemkv.lintian-overrides: Can probably be deleted. Binaries
should have a manpage; sometimes if one doesn't exist as a packager you
have to write a basic one. Also, this is one of the things noted in the
Reject FAQ for NEW [1], which lists several things that may cause
ftpmaster to reject a package. The other override is desktop-entry-
lacks-keywords-entry; that can easily be fixed with a simple patch to
add some keywords to the .desktop file.


What should I put in the manpage though? There's not really any command 
line flags that can be used by the program, everything's done in the 
GUI. I haven't written any manpages before outside of simple programs 
with easy to document command line usage.

As for the .desktop file, that's now fixed.


   * d/README.source: Add this file to describe the issue(s) requiring
the shipping of bundled copies of libraries. Right off hand I know
about libebml and libmatroska, but there may be others. This informs
others who may review/work on the package in the future.


Alright, I've cut down the comment in the unused patch file so now it 
points to README.source for an explanation of why the patch is not used.



   * d/source/metadata: Add this file; see [2] for more information.


Added. I think it was in your original package but I deleted it because 
from what I read in the DEP it seemed like it was optional for now and 
this source is a bit trickier than others to document.



   * d/watch: Is incorrectly looking at the makemkv-bin source file.
Also, add a comment that the URL doesn't change, even though it looks
like it might.


Fixed.


   makemkv-bin specific notes:

   * d/copyright: There is an important difference between code that is
licensed as "GPL-2" and "GPL-2+" (for example). If a license doesn't
have "or any later version" (or similar phrasing), it's incorrect to
describe it with a "+" (or vise-versa). Admittedly, this is an issue in
my original packaging not getting that correct, but it should be fixed
in your packaging work. :)


Fixed.


   * d/makemkvcon.lintian-overrides: Same comment as before with
binaries needing a manpage to be provided.


Just like the last one, I don't really know what to write for it.


   * d/rules: No need to have empty override_* targets.


I needed to stop debhelper from running `make` and `make 

Bug#1005079: RFS: memtest86+/5.31b+dfsg-4 [ITA] -- thorough real-mode memory tester

[Fabio Fantoni]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "memtest86+":

 * Package name    : memtest86+
   Version : 5.31b+dfsg-4
   Upstream Author : Samuel Demeulemeester 
 * URL : https://www.memtest.org/
 * License : GPL-2 and Expat, GPL-2
 * Vcs : https://salsa.debian.org/debian/memtest86plus
   Section : misc

It builds those binary packages:

  memtest86+ - thorough real-mode memory tester

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


  https://mentors.debian.net/package/memtest86+/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/memtest86+/memtest86+_5.31b+dfsg-4.dsc


Changes since the last upload:

 memtest86+ (5.31b+dfsg-4) unstable; urgency=medium
 .
   [ Fabio Fantoni ]
   * New maintainer (Closes: #969191)
   * another changes to makeiso.sh to make the build reproducible:
 - add -uid and -gid to 0 to xorriso options
 - replaced "echo -e" with printf
   * d/postinst: don't run update-grub if in a container
   * d/control: remove mention of lpia arch
 .
   [ Debian Janitor ]
   * Trim trailing whitespace.
   * Use secure URI in Homepage field.
   * Bump debhelper from old 12 to 13.
   * Update renamed lintian tag names in lintian overrides.

Regards,
--
  Fabio Fantoni



OpenPGP_signature
Description: OpenPGP digital signature

Bug#968196: fping: postinst fails when dpkg-statoverride is already used

[Axel Beckert]

Control: tag -1 + pending

Hi Paul,

sorry for the late reply. Seems I had forgotton about this sole bug
report against the usually not much maintenance needing fping. :-/

Paul Slootman wrote:
> Setting up fping (4.2-3) ...
> Failed to set capabilities on file `/usr/bin/fping' (Operation not supported)
> The value of the capability argument is not permitted for a file. Or the file 
> is not a regular (non-symlink) file
> WARNING: 'setcap cap_net_raw+ep /usr/bin/fping' failed.
> /usr/bin/fping is already setuid root. Not trying to fix anything.
> WARNING: Making /usr/bin/fping setuid instead. Use dpkg-statoverride(1) to 
> change that if you're unhappy with it.
> dpkg-statoverride: error: an override for '/usr/bin/fping' already exists; 
> aborting
> dpkg: error processing package fping (--configure):
>  installed fping package post-installation script subprocess returned error 
> exit status 2
> Errors were encountered while processing:
>  fping
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> The script first says "Not trying to fix anything" and then goes on
> and tries to fix something.

Indeed, thanks for the bug report.

> The problem is that there is an "else" missing:

Correct. Took me quite a moment to understand what goes wrong, but
there is indeed the else clause missing around these two lines.

> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers oldoldstable
>   APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable')

Weird combination. :-)

And surprising that this bug was in there since 2017 and nobody
complained before the current 5.0-1 upload which happened just a few
days before your bug report against fping in (back then) oldstable
(now oldoldstable).

Will apply your patch for the upcoming 5.1-1 upload.

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

Bug#995161: linux-image-5.14.0-1-amd64: SMART error with update to 5.14 and Samsung nvme

[Howard Cox]

I experienced this with 5.14 and also now in 5.15.0-0.bpo.2-amd64

Bug#1005078: RFS: libfilezilla/0.36.0-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

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

It builds those binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla24 - build high-performing platform-independent programs (runtime 
lib)

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

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

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

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

Changes since the last upload:

 libfilezilla (0.36.0-1) unstable; urgency=medium
 .
   * New upstream version 0.36.0
   * Soname bump rename package to libfilezilla24
   * Update d/copyright date and data

Notes:

1) This is a NEW package because of soname bump and needs to be a source only 
upload for migration
from unstable to testing.

2) Version will be imported into salsa once uploaded.

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1005067: I suspect this bug is caused by having CONFIG_SND_VERBOSE_PROCFS not set. Fixed upstream

[Eric Valette]

https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/1148

-- eric

Bug#1003810: libxml-libxml-perl: getElementById is broken (regression)

[Vincent Lefevre]

Control: retitle -1 libxml-libxml-perl: when XML::LibXML::Parser validation is 
set to 1, the DTD is not read

Hi,

On 2022-02-06 21:15:29 +0100, gregor herrmann wrote:
> What I see in the upstream Changes file are some behaviour changes,
> eg.
> - Disable loading external DTDs or external entities by default
> maybe they are related to the problems you're experiencing?

Indeed, this is caused by this change: I've looked at the strace
output, and the DTD is read only with the old libxml-libxml-perl
version (2.0134+dfsg-2). But in my script, I do:

  my $parser = XML::LibXML->new();
  $parser->validation(1);
  my $movies = $parser->parse_file($mfile);

and since I request validation, the DTD should be read.

FYI, the XML::LibXML::Parser(3pm) man page says:

validation
/parser, reader/

validate with the DTD; possible values are 0 and 1
^

So this is a major breakage for users who want validation.

This issue can be solved by adding

  $parser->load_ext_dtd(1);

But the XML::LibXML::Parser(3pm) man page still says:

  Creating a Parser Instance
[...]
new
[...]
[...] Unless specified otherwise, the options "load_ext_dtd", and
"expand_entities" are set to 1. [...]
[...]
load_ext_dtd
/parser, reader/

load the external DTD subset while parsing; possible values are 0
and 1. Unless specified, XML::LibXML sets this option to 1.

So it looks like there is something inconsistent.

I've updated the bug title concerning my issue with validation set to 1,
but there's also this inconsistency with the man page.

BTW, I wonder whether this also breaks XML::LibXSLT, which needs the
DTD to be read.

Note also that if upstream really wants to change the default behavior
(e.g. without setting validation to 1 -- I've checked that the DTD was
loaded in this case with the old libxml-libxml-perl version), this is
also likely to break even more existing scripts, possibly in obscure
ways, as users were following a documented behavior.

I suggest to set the severity back to grave, at least until the
clarification of this mess.

If the final choice is likely to break existing scripts, this must
absolutely be announced in the NEWS.Debian file.

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

Bug#1005077: RFS: mptcpd/0.9-1 [ITP] -- Multipath TCP Daemon

[Matthieu Baerts]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: mptcpd
   Version : 0.9-1
   Upstream Author : mp...@lists.linux.dev
 * URL : https://github.com/intel/mptcpd
 * License : BSD-3-Clause, GPL-2.0+, PERMISSIVE, __AUTO_PERMISSIVE__
 * Vcs : https://gitlab.com/matttbe/mptcpd-debian
   Section : net

It builds those binary packages:

  mptcpd - Multipath TCP Daemon
  libmptcpd3 - Multipath TCP Daemon Library
  libmptcpd3-dev - Multipath TCP Daemon Library - Development files
  libmptcpd3-doc - Multipath TCP Daemon Library - documentation
  mptcpd-plugins - Multipath TCP Daemon Plug-ins
  mptcpize - Multipath TCP Converter
  libmptcpwrap0 - Multipath TCP Converter Library

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/m/mptcpd/mptcpd_0.9-1.dsc

Changes for the initial release:

 mptcpd (0.9-1) unstable; urgency=low
 .
   * Initial release. Closes: #1005012

Regards,
-- 
  Matthieu Baerts

Bug#1005076: ITP: sre-yield -- Expands a regular expression to its possible matches

[Paulo]

Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: sre-yield
  Version : 1.2
  Upstream Author : Google Inc.
* URL : https://github.com/google/sre_yield
* License : Apache-2.0
  Programming Lang: Python
  Description : Expands a regular expression to its possible matches

 The goal of sre_yield is to efficiently generate all values that can match a
 given regular expression, or count possible matches efficiently. It uses the
 parsed regular expression, so you get a much more accurate result than trying
 to just split strings.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005043: lintian: check that Python version numbers are not 0.0.0

[Sandro Tosi]

> Or export SETUPTOOLS_SCM_PRETEND_VERSION.
> https://github.com/pypa/setuptools_scm#environment-variables
>
> pybuild does this for you.

i dont remember the exact details, but sometimes that doesnt work:
even just building the source package (which runs dh clean, which
invokes setup.py clean) the build fails because "something something
SCM something".

It could be the specific package is doing things in a funky way but
that's my experience at least

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

Bug#1005075: ITP: makemkv-bin -- Proprietary components of makemkv

[Ben Westover]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Ben Westover 
X-Debbugs-Cc: kwestover...@gmail.com
Severity: wishlist

* Package name: makemkv-bin
  Version : 1.16.5
  Upstream Author : GuinpinSoft inc.
* URL : https://makemkv.com/
* License : GPL-2, custom
  Programming Lang: C++
  Description : Proprietary components of makemkv

This package contains the various proprietary and closed-source 
components of MakeMKV.


makemkv-bin is a sister package to makemkv-oss that contains proprietary 
components required for it to function.
I have already completed the package and am filing this ITP because it 
was previously one ITP that covered both packages and I need this one as 
a bug for makemkv-bin to close.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003548: transition: libwebp

[Jeff Breidenbach]

The package has been corrected with version 1.2.1-6 which has
been uploaded to experimental.

Please let us know if we can proceed with the upload to unstable. Also
a binNMU rebuild of reverse dependencies would be required afterwards.

Bug#1005074: plasma-workspace: please provide some default MIME-handling application associations

[Simon McVittie]

Package: plasma-workspace
Version: 4:5.23.5-1
Severity: normal
X-Debbugs-Cc: debian-desk...@lists.debian.org

Steps to reproduce:

- Install task-kde-desktop
- Also install gimp, nautilus and libglib2.0-bin
- Have a PDF file (if you're testing in a VM like I was, there's one in
  /usr/share/doc/shared-mime-info)
- Log in to a KDE Plasma session
- Run Dolphin
- Double-click the PDF file in Dolphin
- Close whatever viewer opens
- Run Nautilus
- Double-click the PDF file again, this time in Nautilus
- Close whatever viewer opens
- In a terminal, run: gio mime application/pdf

Expected result:

- From both file managers, the PDF opens in some reasonable KDE viewer,
  like Okular
- `gio mime` says the default is the same KDE viewer

Actual result (in my testing, but might be non-deterministic):

- From Dolphin, the PDF opens in Okular as expected
- From Nautilus, the PDF opens in GIMP
- `gio mime` says the default is gimp.desktop

Workaround: sysadmins can put this in /etc/xdg/kde-mimeapps.list or
/usr/local/share/applications/kde-mimeapps.list:

[Default Applications]
application/pdf=okularApplication_pdf.desktop;

or individual users can configure this in ~/.config/kde-mimeapps.list
or ~/.config/mimeapps.list.

This can be resolved in the KDE/Plasma packaging by providing a
/usr/share/applications/kde-mimeapps.list, analogous to the
gnome-mimeapps.list in gnome-session-common.

More details


The way this fits together is:

- The Shared Mime Info spec (implemented by the shared-mime-info package
  in Debian) is used to detect content-types (MIME types) from content
  and extensions.

- The Desktop Entry spec (.desktop files) allows applications to declare
  which content-types they can open. It deliberately does not allow
  application maintainers to mark their application as preferred or a
  default, to avoid an "arms race" where every maintainer says their
  app should be the default.
  https://specifications.freedesktop.org/desktop-entry-spec/latest/

- The MIME apps spec allows distros, desktop environments, sysadmins
  and/or users to choose which application they want to use for each
  content-type, in a way that depends on the desktop environment they
  logged into (but does not depend on the application from which the
  file was opened - Dolphin and Nautilus should behave the same).
  https://specifications.freedesktop.org/mime-apps-spec/latest/

If nobody has expressed a preference, then the fallback behaviour of
the MIME apps spec is to choose an arbitrary one of the apps that can
open the appropriate content-type. For some file types, like PDF, this
leads to unexpected behaviour: there are several apps, including GIMP
and Calibre, that technically *can* open PDFs but are probably not what
you want as a PDF viewer.

Perhaps the Qt/KDE libraries used by Dolphin have some built-in way to
choose a "better" implementation as an extension of the MIME apps spec,
but GLib just follows the spec (and I suspect its arbitrary choice might
just be the first possible handler in alphabetical order).

The intended design seems to be that in a well-integrated desktop
environment, there should usually be an opinionated configuration for
that desktop environment in some central "data" package, installed
to /usr/share/applications/$desktop-mimeapps.list, where $desktop
is the desktop environment's value of $XDG_CURRENT_DESKTOP,
case-folded to lower case. For example, GNOME installs
/usr/share/applications/gnome-mimeapps.list via the gnome-session-common
package, which configures GNOME sessions to prefer GNOME or GNOME-adjacent
applications like eog, evince and firefox.

As with #1004906 in XFCE, I think it would be appropriate for some
"central" KDE/Plasma package (plasma-workspace-data?) to install
/usr/share/applications/kde-mimeapps.list with Okular as the preferred
PDF handler, and perhaps other PDF viewers like qpdfview as a fallback:

[Default Applications]
application/pdf=okularApplication_pdf.desktop;qpdfview.desktop;

Similarly, KDE should probably configure viewers for image/photo file
types that would fit well into an KDE environment, to avoid JPEGs
accidentally getting loaded into GIMP, a web browser, or sometimes
even Wine.

Default URL handlers can also be configured in the same way, by configuring
associations for the pseudo-MIME-types x-scheme-handler/http and
x-scheme-handler/https (or any other URL scheme of interest, such as
x-scheme-handler/mailto).

It would be technically possible for the Debian desktop team to set
defaults on a distro-wide basis, by providing
/usr/share/applications/mimeapps.list in the desktop-base package. However,
the choice of defaults is opinionated, so the desktop team would not
necessarily find it straightforward to choose something useful: I expect
it to be difficult to choose defaults that are appropriate for everyone,
because every desktop environment team will probably want their
applications to be the default.

As a result, it's probably 

Bug#1004832: ITP: hyx -- minimalistic but powerful vim-like hex editor

[Russell Hernandez Ruiz]

On Sun, 2022-02-06 at 16:43 +0100, Geert Stappers wrote:
> Yes,  and I could create a git repository at Salsa.
> ( https://salsa.debian.org )
> 
> So, that means there are (at least) two paths to a git repository
> where the debian tarball for hyx can live.
> 
> Both paths are fine with me.
> 
> @Russell   I make it your call.

Stappers: git repo at Salsa sounds good.

I'd like to create it/set it up myself if that's okay/possible.
Plan would be to have a tagged upstream branch, with packaging
living in master.

If you have to do it, then go ahead.

I've just signed-up there with username `qrpnxz`.

> > The original project has no version control.
> 
> That is fine.  Upstream provides tarballs.
> 
> Thing that could be improved is that https://yx7.cc/code/hyx/
> would has an index. Something that allows to see that a new
> upstream version is available. (It is what debian utility `uscan`
> does.)

I did read about a way to check for upstream. It looks like Lorenz
has unblocked us here, so I'll see about doing that.

Bug#1003810: libxml-libxml-perl: getElementById is broken (regression)

[gregor herrmann]

Control: severity -1 normal
Control: tag -1 + moreinfo

On Sun, 16 Jan 2022 04:17:30 +0100, Vincent Lefevre wrote:

> Package: libxml-libxml-perl
> Version: 2.0207+dfsg-2
> Severity: grave
> Justification: renders package unusable
> 
> getElementById no longer works.
> 
> There were no issues up to version 2.0134+dfsg-2+b1.

I'm sorry to hear that you have issues with the current libxml-libxml-perl
version.

In the diff against the previous version I see no mention of
getElementById; also there are no related bug reports in the Debian
BTS, in the CPAN RT, or in the upstream Github issues.

What I see in the upstream Changes file are some behaviour changes,
eg.
- Disable loading external DTDs or external entities by default
maybe they are related to the problems you're experiencing?


Could you please provide some more information and/or examples of
what doesn't work for you?


In the meantime I'm tagging the bug "moreinfo" and lowering the
severity.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Supertramp: Don't Leave Me Now


signature.asc
Description: Digital Signature

Bug#1005073: RM: libnzb-- RoM; Upstream Dead; Useless; Unmaintained; RC-Buggy

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: mnord...@debian.org

Dear FTP Masters,

As discussed in https://bugs.debian.org/1004567 , the package maintainer of
libnzb ( https://tracker.debian.org/pkg/libnzb ) agrees that it has no
upstream activity, is RC-Buggy, becomes useless in Debian and should be
removed from Debian.

Package libnzb has no reverse dependencies and build-dependencies.

Regards,
Boyuan Yang


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

Bug#1005072: mate-tweak: Unpleasant transition from mate-compton to mate-picom

[Mihai Hanor]

Package: mate-tweak
Version: 22.04.1-1
Severity: normal
File: /usr/bin/mate-tweak
X-Debbugs-Cc: quake2i...@gmail.com

Dear Maintainer,

After upgrading the packages and restarting the system (which was configured
with compton as window manager in Mate Tweak), after logging in lightdm, all
the windows were missing their decorations and normal window controls, while
window management was impossible.

** To fix it, start MATE Tweak and select another window manager (current
selection
is shown as empty).

** Excerpts taken from .xsession-errors:

x-session-manager[1897]: WARNING: Unable to find provider 'marco-compton'
of required component 'windowmanager'

(mate-settings-daemon:2063): Gtk-WARNING **: 20:55:39.286:
gtk_widget_size_allocate(): attempt to allocate widget with width -1 and
height 27
Window Manager is: Unknown



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

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

Versions of packages mate-tweak depends on:
ii  dconf-cli  0.40.0-2
ii  gir1.2-gtk-3.0 3.24.31-1
ii  gir1.2-notify-0.7  0.7.9-3
ii  mate-panel 1.26.2-1
ii  mesa-utils 8.4.0-1+b2
ii  python33.9.7-1
ii  python3-distro 1.6.0-2
ii  python3-gi 3.42.0-3
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-psutil 5.8.0-2+b1
ii  python3-setproctitle   1.2.2-2+b1
ii  x11-xserver-utils  7.7+9

Versions of packages mate-tweak recommends:
ii  mate-indicator-applet  1.26.0-1
ii  picom  8.2-1

Versions of packages mate-tweak suggests:
pn  ayatana-indicator-application | indicator-application  
pn  ayatana-indicator-datetime | indicator-datetime
pn  ayatana-indicator-messages | indicator-messages
pn  ayatana-indicator-power | indicator-power  
pn  ayatana-indicator-session | indicator-session  
pn  ayatana-indicator-sound | indicator-sound  

-- no debconf information

Bug#969324: support autocrypt support in Debian and Ubuntu

[Richard Z.]

Imho this "feature" promotes a very unsafe key exchange method where
an attacker can easily exchange trusted and verified keys by any keys
he likes. 

Thunderbird support has been dropped although it does support
some kind of key exchange that is in some aspect "compatible" with
autocrypt. Last time I looked K9 mail had bigger problems than
autocrypt support.

This is even more broken than the problem it tries to solve and a waste
of electrons.

Bug#1005070: gcc-10-plugin-dev: fail to install

[Muhammad Usama Anjum]

Package: gcc-10-plugin-dev
Version: 10.2.1-6
Severity: important
Tags: a11y




-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gcc-10-plugin-dev depends on:
ii  gcc-10   10.2.1-6
ii  gcc-10-base  10.2.1-6
ii  libc62.31-13+deb11u2
pn  libgmp-dev   
pn  libmpc-dev   

gcc-10-plugin-dev recommends no packages.

Installation of libgmp-dev and libmpc-dev fails:
sudo apt install -y gcc-10-plugin-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libgmp-dev libgmpxx4ldbl libmpc-dev libmpfr-dev
Suggested packages:
  gmp-doc libgmp10-doc libmpfr-doc
The following NEW packages will be installed:
  gcc-10-plugin-dev libgmp-dev libgmpxx4ldbl libmpc-dev libmpfr-dev
0 upgraded, 5 newly installed, 0 to remove and 33 not upgraded.
Need to get 980 kB/2,584 kB of archives.
After this operation, 12.9 MB of additional disk space will be used.
Err:1 http://deb.debian.org/debian bullseye/main amd64 libgmpxx4ldbl amd64
2:6.2.1+dfsg-1
  404  Not Found [IP: 199.232.82.132 80]
Err:2 http://deb.debian.org/debian bullseye/main amd64 libgmp-dev amd64
2:6.2.1+dfsg-1
  404  Not Found [IP: 199.232.82.132 80]
E: Failed to fetch
http://deb.debian.org/debian/pool/main/g/gmp/libgmpxx4ldbl_6.2.1%2bdfsg-1_amd64.deb
404  Not Found [IP: 199.232.82.132 80]
E: Failed to fetch http://deb.debian.org/debian/pool/main/g/gmp/libgmp-
dev_6.2.1%2bdfsg-1_amd64.deb  404  Not Found [IP: 199.232.82.132 80]
E: Unable to fetch some archives, maybe run apt-get update or try with
--fix-
missing?

Bug#1005069: tracker: Unable to easily disable tracker

[Bruce Momjian,,,]

Package: tracker
Version: 2.3.6-2
Severity: normal
Tags: patch

Dear Maintainer,

I have 2TB of images in the 'Pictures' directory in my home directory.  Since 
upgrading to Bullseye, I found that 'tracker' was using significant CPU, even 
after days, though the Pictures directory content
was unchanged.  I can't remove tracker since gnome-flashback-common and 
gnome-panel depend on it.  I tried disabling tracker via systemctl disable and 
systemctl mask, but it was still running.  I tried
several suggested gsettings options, but the only one I found that worked was 
'gsettings set org.freedesktop.Tracker.Miner.Files index-recursive-directories 
"[]"'.

Tracker wasn't using a huge amoutn of CPU, but on my idle system, it was using 
the most CPU.  I feel it should be easier to disable tracker.

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

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

Versions of packages tracker depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  dconf-gsettings-backend [gsettings-backend]   0.38.0-2
ii  libc6 2.31-13+deb11u2
ii  libglib2.0-0  2.66.8-1
ii  libglib2.0-bin2.66.8-1
ii  libicu67  67.1-7
ii  libsqlite3-0  3.34.1-3
ii  libstemmer0d  2.1.0-1
ii  libtracker-control-2.0-0  2.3.6-2
ii  libtracker-sparql-2.0-0   2.3.6-2
ii  shared-mime-info  2.0-1

Versions of packages tracker recommends:
ii  tracker-miner-fs  2.3.5-2.1

tracker suggests no packages.

-- no debconf information

Bug#473379: Recommendation to remove the check and the warning

[Marc Haber]

On Sun, Feb 06, 2022 at 11:22:56AM -0500, Jason Franklin wrote:
> Third, I believe that this is a case of "deluser" being a bit too
> helpful. We should only be worried about whether a group is empty or not
> when deleting a group. Otherwise, it is on the sysadmin to check for
> empty groups if they are not desired.
> 
> Is my reasoning sound here?

Yes, go ahead with removing that warning please.

Greetings
Marc

Bug#1005038: oidc-agent: Backport for bullseye

[Micha Lenk]

Hi Peter,

I've just uploaded a backport to bullseye-backports. It will need some 
time to get processed by the Backports archive team.


Kind regards,
Micha

Bug#1005067: looking at apt history, it seems 0.3.44 was working and upgrading to 0.3.45 broke the audio.

[Eric Valette]

Did not downgrade to confirm as I need audio ATM.

-- eric

Bug#1004956: graphviz: FTBFS: These bindings need PHP7

[Sebastiaan Couwenberg]

Control: tags -1 patch

On Fri, 4 Feb 2022 12:06:55 +0100 Sebastiaan Couwenberg wrote:

On Fri, 4 Feb 2022 10:41:23 + Niko Tyni  wrote:
> Looking at the build history there, the PHP 8.1 transition seems to fit
> the timeline.

It's actually swig that doesn't support PHP 8 yet, see:

  https://bugs.debian.org/1003479


The PHP extension will need to be dropped until swig supports PHP 8.

The attached patch does so.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1diff -Nru graphviz-2.42.2/debian/changelog graphviz-2.42.2/debian/changelog
--- graphviz-2.42.2/debian/changelog2021-05-08 11:09:59.0 +0200
+++ graphviz-2.42.2/debian/changelog2022-02-06 18:20:03.0 +0100
@@ -1,3 +1,11 @@
+graphviz (2.42.2-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't build PHP extension, swig doesn't support PHP 8 yet.
+(closes: #1004956)
+
+ -- Bas Couwenberg   Sun, 06 Feb 2022 18:20:03 +0100
+
 graphviz (2.42.2-5) unstable; urgency=high
 
   * Fix CVE-2020-18032: out of bounds write on invalid label
diff -Nru graphviz-2.42.2/debian/control graphviz-2.42.2/debian/control
--- graphviz-2.42.2/debian/control  2020-04-26 07:25:24.0 +0200
+++ graphviz-2.42.2/debian/control  2022-02-06 18:18:52.0 +0100
@@ -29,7 +29,6 @@
  libargon2-dev,
  libsodium-dev,
  libxml2-dev,
- php-dev,
  python3-dev,
  libcairo2-dev,
  libpango1.0-dev,
@@ -105,17 +104,6 @@
  .
  This package contains the Perl bindings.
 
-Package: libgv-php7
-Architecture: any
-Multi-Arch: same
-Section: php
-Depends: ${shlibs:Depends}, ${php:Depends}, ${misc:Depends}
-Description: PHP7 bindings for graphviz
- Graphviz is a set of graph drawing tools. See the description of the graphviz
- package for a full description.
- .
- This package contains the PHP7 bindings.
-
 Package: python3-gv
 Architecture: any
 Section: python
diff -Nru graphviz-2.42.2/debian/libgv-php7.install 
graphviz-2.42.2/debian/libgv-php7.install
--- graphviz-2.42.2/debian/libgv-php7.install   2019-10-09 18:24:32.0 
+0200
+++ graphviz-2.42.2/debian/libgv-php7.install   1970-01-01 01:00:00.0 
+0100
@@ -1,3 +0,0 @@
-usr/lib/*/graphviz/php
-usr/share/php/gv.php
-usr/share/man/man3/gv.3php
diff -Nru graphviz-2.42.2/debian/libgv-php7.README.Debian 
graphviz-2.42.2/debian/libgv-php7.README.Debian
--- graphviz-2.42.2/debian/libgv-php7.README.Debian 2018-02-25 
15:26:18.0 +0100
+++ graphviz-2.42.2/debian/libgv-php7.README.Debian 1970-01-01 
01:00:00.0 +0100
@@ -1,17 +0,0 @@
-README for libgv-php5:
---
-
-  * This PHP extension contains two parts: gv.php and gv.so.
-  * Since the search path isn't recursive, one has to use the following
-to use this extension (filename relative to /usr/share/php):
-  include('libgv-php5/gv.php');
-  * Since this extension contains a loadable module, it seems needed to
-enable them in the PHP configuration. At the time of this writing, it
-can be done by switching enable_dl from Off to On in the following
-configuration file:
-  /etc/php5/cli/php.ini
-  * This particular file contains comments about possible security issues
-when enabling loadable modules. Those comments probably should be
-taken into account.
-
- -- Cyril Brulebois , Mon, 28 Jul 2008 05:09:59 +0200
diff -Nru graphviz-2.42.2/debian/rules graphviz-2.42.2/debian/rules
--- graphviz-2.42.2/debian/rules2019-10-09 18:24:32.0 +0200
+++ graphviz-2.42.2/debian/rules2022-02-06 18:19:24.0 +0100
@@ -29,9 +29,6 @@
 SO_GVPR= 2
 SO_LAB-GAMUT   = 1
 
-PHP_EXTENSION_DIR = $(shell php-config --extension-dir)
-PHP_PACKAGE   = $(CURDIR)/debian/libgv-php7
-
 override_dh_clean:
dh_clean
rm -f $(patsubst %, debian/%, ${AUTOGENERATED})
@@ -73,7 +70,6 @@
--disable-go \
--enable-guile \
--enable-lua \
-   --enable-php \
--enable-ruby \
--enable-tcl \
--disable-java \

Bug#1005068: transition (unplanned?): libwacom9

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: libwa...@packages.debian.org
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-libwacom.html

src:libwacom was recently updated from libwacom2 to libwacom9, starting
a transition. I don't see any indication that this was approved by the
release team, so I'm opening this transition tracking bug (my apologies
if there is already a transition-tracker that I missed).

https://release.debian.org/transitions/html/auto-libwacom.html looks like
it is tracking this transition correctly.

Because libwacom2 and libwacom9 both depend on a matching libwacom-common,
this makes affected packages such as mutter uninstallable in unstable.

How big are the API/ABI breaks? Are dependent packages expected to compile
and work successfully without code changes?

In addition to rebuilding reverse-dependencis, src:libwacom will need a
source-only upload to unstable so that it will be allowed to migrate.

It is usually best for transitions to happen by uploading NEW packages
to experimental, then opening a transition-tracking bug like this one
and getting release team approval, and finally re-uploading to unstable
after approval has been received, particularly if the transition is an
all-or-nothing one like this.

smcv

Bug#1005066: capnproto 0.9.1 FTBFS on armel

[Tom Lee]

If I'm reading right I *think* it's more likely to be just an
oversight/bug. Atomic operations are basically intrinsics on some
architectures (most notably x86) so no need to link another library. Other
architectures need a little more of a lift. I'll have a patch we can try
soon.

tom@debian-bullseye-arm64:~$ apt-cache show libatomic1
Package: libatomic1
Source: gcc-11
Version: 11.2.0-13
Installed-Size: 48
Maintainer: Debian GCC Maintainers 
Architecture: arm64
Depends: gcc-11-base (= 11.2.0-13), libc6 (>= 2.17)
Description-en: support library providing __atomic built-in functions
 library providing __atomic built-in functions. When an atomic call cannot
 be turned into lock-free instructions, GCC will make calls into this
library.
Description-md5: 16938852526fc26bdbcb46c18435ed08
Multi-Arch: same
Homepage: http://gcc.gnu.org/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/g/gcc-11/libatomic1_11.2.0-13_arm64.deb
Size: 9468
MD5sum: ecc8ec0485239764081a18816ad03c99
SHA256: c75dea8b3d70d994a90cc180779b4d531220d3566d38a5081ef2e4c3f9df3664

...snip...

On Sun, Feb 6, 2022 at 8:45 AM tony mancill  wrote:

> On Sun, Feb 06, 2022 at 08:12:12AM -0800, tony mancill wrote:
> > Source: capnproto
> > Version: 0.9.1-1
> > Severity: important
> >
> > This bug is for tracking the armel build failure [1]:
>
> And it's the same on mipsel.  Did upstream drop support for 32-bit
> architectures other than x86?
>
> https://buildd.debian.org/status/logs.php?pkg=capnproto=0.9.1-1
>


-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#969191: O: memtest86+ -- thorough real-mode memory tester

[Fabio Fantoni]

control: retitle -1 ITA: memtest86+ -- thorough real-mode memory tester
control: owner -1 !

Thanks to Yann Dirson for his works on package.

I have been using memtest86+ for many years for both work and not, 
version 5.01 in debian stable/testing/unstable as I saw in latest years 
on major of cases was not working, I did some QA uploads to update and 
improve it but I not adopted one month ago wating for a new maintainer 
with more knowledge and/or time but now I was suggested to adopt it 
because most likely another maintainer will not arrive.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005067: pipewire-pulse/wireplumber breaks kde audio

[Eric Valette]

Package: pipewire-pulse
Version: 0.3.45-1
Severity: important

Today, wanted to liusten some music and discovered, I had no devices seen by kde
audio. Looked at the log.
got a bunch of:
 1) /var/log/user.log.1:Feb  5 10:46:15 tri-yann4 pipewire-pulse[1824]: 
mod.protocol-pulse: client 0x557b90aba260 [kwin_killer_helper]: ERROR 
command:-1 (invalid) tag:106 error:25 (Input/output error)
 2) /var/log/user.log.1:Feb  2 09:20:43 tri-yann4 pipewire-pulse[9372]: 
mod.rt: could not make thread 9380 realtime using RTKit: Permission denied


removed pipewire-pulse and rebooted. Got back my audio devices. Looked at 
debian page
for pipewire, reinstalled pipewire-pulse, wireplumber did the user space 
command to start
it via systemd, also rmove /etc/pipewire as suggested.

Rebooted. Still no audio.

aplay -L list the devices correctly but they are not acessible ...


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

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

Versions of packages pipewire-pulse depends on:
ii  init-system-helpers  1.61
ii  pipewire 0.3.45-1

pipewire-pulse recommends no packages.

pipewire-pulse suggests no packages.

Bug#1001489: twodict: (autopkgtest) needs update for python3.10: 'collections' has no attribute 'KeysView'

[Andrey Rahmatullin]

I was looking at this bug report and while the patch is provided (and is
trivial), the package had its only maintainer upload in 2018, the last
upstream release was in 2016 (though one can say the software is perfect,
as it's just 270 lines of code), and it has popcon 9. So maybe it's better
to not spend effort on it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1005043: lintian: check that Python version numbers are not 0.0.0

[Stefano Rivera]

Hi Julian (2022.02.06_12:19:54_+)
> In the couple of cases I've looked at so far, it is due to the
> upstream version using use_scm_version in setup.py.  This works fine
> for a version that is in a Git repository, but it doesn't work for
> Debian packages, as the Git version lookup fails.  So this needs to be
> patched.

Or export SETUPTOOLS_SCM_PRETEND_VERSION.
https://github.com/pypa/setuptools_scm#environment-variables

pybuild does this for you.

SR

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

Bug#1005066: capnproto 0.9.1 FTBFS on armel

[Tom Lee]

Looks like we might need -latomic on armel

On Sun, Feb 6, 2022 at 8:15 AM tony mancill  wrote:

> Source: capnproto
> Version: 0.9.1-1
> Severity: important
>
> This bug is for tracking the armel build failure [1]:
>
> > libtool: link: g++  -fPIC -DPIC -shared -nostdlib
> /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/crti.o
> /usr/lib/gcc/arm-linux-gnueabi/11/crtbeginS.o
> src/capnp/compiler/.libs/type-id.o
> src/capnp/compiler/.libs/error-reporter.o
> src/capnp/compiler/.libs/lexer.capnp.o src/capnp/compiler/.libs/lexer.o
> src/capnp/compiler/.libs/grammar.capnp.o src/capnp/compiler/.libs/parser.o
> src/capnp/compiler/.libs/generics.o
> src/capnp/compiler/.libs/node-translator.o
> src/capnp/compiler/.libs/compiler.o src/capnp/.libs/schema-parser.o
> src/capnp/.libs/serialize-text.o   -Wl,-rpath -Wl,/<>/.libs
> ./.libs/libcapnp.so ./.libs/libkj.so -lpthread
> -L/usr/lib/gcc/arm-linux-gnueabi/11
> -L/usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi
> -L/usr/lib/gcc/arm-linux-gnueabi/11/../../.. -L/lib/arm-linux-gnueabi
> -L/usr/lib/arm-linux-gnueabi -lstdc++ -lm -lc -lgcc_s
> /usr/lib/gcc/arm-linux-gnueabi/11/crtendS.o
> /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/crtn.o
> -pthread -g -O2 -fstack-protector-strong -pthread -Wl,-z -Wl,relro -Wl,-z
> -Wl,now   -pthread -Wl,-soname -Wl,libcapnpc-0.9.1.so -o .libs/
> libcapnpc-0.9.1.so
> > libtool: link: g++ -I./src -I./src -DKJ_HEADER_WARNINGS
> -DCAPNP_HEADER_WARNINGS -DCAPNP_INCLUDE_DIR=\"/usr/include\" -pthread -g
> -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -DNDEBUG -pthread -DKJ_HAS_ZLIB -DKJ_HAS_OPENSSL
> -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/capnpc-c++
> src/capnp/compiler/capnpc-c++.o  ./.libs/libcapnp.so ./.libs/libkj.so
> -lpthread -pthread
> > /usr/bin/ld: ./.libs/libcapnp.so: undefined reference to
> `__atomic_load_8'
> > /usr/bin/ld: ./.libs/libcapnp.so: undefined reference to
> `__atomic_store_8'
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [Makefile:2111: capnpc-c++] Error 1
>
> Cheers,
> tony
>
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=capnproto=armel=0.9.1-1=1644104535=log
>


-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#1005066: capnproto 0.9.1 FTBFS on armel

[tony mancill]

On Sun, Feb 06, 2022 at 08:12:12AM -0800, tony mancill wrote:
> Source: capnproto
> Version: 0.9.1-1
> Severity: important
> 
> This bug is for tracking the armel build failure [1]:

And it's the same on mipsel.  Did upstream drop support for 32-bit
architectures other than x86?

https://buildd.debian.org/status/logs.php?pkg=capnproto=0.9.1-1

Bug#473379: Recommendation to remove the check and the warning

[Jason Franklin]

Greetings:

I thought I would go ahead and confirm this one. I noticed it myself
today, and I wanted to follow up here.

I recommend that we remove the check and the warning entirely.

First, the warning is already incorrect. It may mislead someone into
thinking that they can remove a group that still as members.

Second, an empty group is in many if not most cases NOT an error. There
are several standard groups that may be empty on a given system (e.g.,
"cdrom" or "adm").

Third, I believe that this is a case of "deluser" being a bit too
helpful. We should only be worried about whether a group is empty or not
when deleting a group. Otherwise, it is on the sysadmin to check for
empty groups if they are not desired.

Is my reasoning sound here?

If so, I'll work on this one after I finish the bug I'm working on
currently. It should be an easy win!

-- 
Jason Franklin

Bug#1003039: [Pkg-javascript-devel] Bug#1003039: Bug#1003039: node-terser: Please update node-commander dependency to version 8

[Jonas Smedegaard]

Quoting Yadd (2022-02-06 17:02:08)
> On 06/02/2022 17:01, Jonas Smedegaard wrote:
> > Quoting Yadd (2022-02-06 13:18:10)
> >> On 06/02/2022 12:35, Jonas Smedegaard wrote:
> >>> Quoting Yadd (2022-01-03 08:08:31)
>  node-commander 8 changed option parsing. Here is a proposed patch 
>  to be used in replacement of 1001_use_commander_4.patch
> >>>
> >>> Thanks for the patch!
> >>>
> >>> If I understand correctly, the patch is not backwards-compatible 
> >>> with node-commander currently in Debian unstable/testing.  I will 
> >>> therefore do nothing until node-commander enters unstable.
> > 
> >> Thanks to look at this. Yes, we have to coordinate this because I 
> >> have to add a 'Breaks: node-terser (<< XXX)'
> > 
> > Could you please clarify: Which range of node-commander releases 
> > should the proposed patch support?
> 
> AFAIK, it is for commander >= 7

Thanks for clarifying - much appreciated.

For future sake, the long description indented lines in DEP-3 patch 
header is an excellent place to mention such details about the scope of 
the patch - and it is less helpful to write "same patch than uglifyjs" 
there, because such note require external knowledge: uglifyjs module? 
uglifyjs rpm package? which version? same how?

I.e. DEP-3 headers should be equally sensible to other distros and to 
upstream - notes specific to a distro should explicitly state that (e.g. 
using Bug-Debian: hint).

 - 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#1005066: capnproto 0.9.1 FTBFS on armel

[tony mancill]

Source: capnproto
Version: 0.9.1-1
Severity: important

This bug is for tracking the armel build failure [1]:

> libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
> /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/crti.o 
> /usr/lib/gcc/arm-linux-gnueabi/11/crtbeginS.o  
> src/capnp/compiler/.libs/type-id.o src/capnp/compiler/.libs/error-reporter.o 
> src/capnp/compiler/.libs/lexer.capnp.o src/capnp/compiler/.libs/lexer.o 
> src/capnp/compiler/.libs/grammar.capnp.o src/capnp/compiler/.libs/parser.o 
> src/capnp/compiler/.libs/generics.o 
> src/capnp/compiler/.libs/node-translator.o 
> src/capnp/compiler/.libs/compiler.o src/capnp/.libs/schema-parser.o 
> src/capnp/.libs/serialize-text.o   -Wl,-rpath -Wl,/<>/.libs 
> ./.libs/libcapnp.so ./.libs/libkj.so -lpthread 
> -L/usr/lib/gcc/arm-linux-gnueabi/11 
> -L/usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi 
> -L/usr/lib/gcc/arm-linux-gnueabi/11/../../.. -L/lib/arm-linux-gnueabi 
> -L/usr/lib/arm-linux-gnueabi -lstdc++ -lm -lc -lgcc_s 
> /usr/lib/gcc/arm-linux-gnueabi/11/crtendS.o 
> /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/crtn.o  -pthread 
> -g -O2 -fstack-protector-strong -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now   
> -pthread -Wl,-soname -Wl,libcapnpc-0.9.1.so -o .libs/libcapnpc-0.9.1.so
> libtool: link: g++ -I./src -I./src -DKJ_HEADER_WARNINGS 
> -DCAPNP_HEADER_WARNINGS -DCAPNP_INCLUDE_DIR=\"/usr/include\" -pthread -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -DNDEBUG -pthread -DKJ_HAS_ZLIB -DKJ_HAS_OPENSSL 
> -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/capnpc-c++ 
> src/capnp/compiler/capnpc-c++.o  ./.libs/libcapnp.so ./.libs/libkj.so 
> -lpthread -pthread
> /usr/bin/ld: ./.libs/libcapnp.so: undefined reference to `__atomic_load_8'
> /usr/bin/ld: ./.libs/libcapnp.so: undefined reference to `__atomic_store_8'
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:2111: capnpc-c++] Error 1

Cheers,
tony

[1] 
https://buildd.debian.org/status/fetch.php?pkg=capnproto=armel=0.9.1-1=1644104535=log


signature.asc
Description: PGP signature

Bug#906752: sudo, pam_keyinit, what to do?

[Chris Hofstaedtler]

Hello Marc,
Hello Andreas (added to CC:),

* Marc Haber  [220206 12:36]:
> in sudo, we have currently the situation whether to add calls to
> pam_keyinit in our pam configuration files. There is quite a number of
> packages doing this, but the pam_keyinit documentation advises "programs
> like su" against doing so. However, in Debian, /etc/pam.d/su-l
> references pam_keyinit, while /etc/pam.d/su doesn't. On the other hand,
> doas doesnt seem to reference pam_keyinit at all.
> 
> If sudo goes the way to mimic what su does, we would reference
> pam_keyinit in /etc/pam.d/sudo-i which is our form of giving the caller
> an interactive session, but not in /etc/pam.d/sudo.
> 
> May I ask for you rationale to do things the way you did them for su and
> pam_keyinit? Your insights might help us to take a wise decision for
> sudo.

I do not know why this was done for su-l and not su. My speculation
would be that we have inherited the su-l PAM config from Fedora, and
the su PAM config from src:shadow before 2018. Maybe the distinction
is an accident.

Andreas, you worked on the su takeover from src:shadow. Do you have
insights to share?

> On Sat, Feb 27, 2021 at 06:38:00PM +0100, Hilko Bengen wrote:
> > The pam_keyring(8) manpage advises against adding pam_keyinit 
> > 
> > ,
> > | This module should not, generally, be invoked by programs like su,
> > | since it is usually desirable for the key set to percolate through to
> > | the alternate context. The keys have their own permissions system to
> > | manage this.
> > `
> > 
> > However, there's no mentioning of the issue described here.
> > 
> > For what it's worth, RHEL/CentOS 7 ships an /etc/pam.d/sudo which
> > contains a line.
> > 
> > ,
> > | sessionoptional pam_keyinit.so revoke
> > `
> > 
> > and they also seem to have different intended behavior for interactive
> > usage – there's a separate /etc/pam.d/sudo-i which contains
> > 
> > ,
> > | sessionoptional pam_keyinit.so force revoke
> > `

I will note that our runuser(-l) PAM config also mirrors this:

runuser:
session  optionalpam_keyinit.so revoke

runuser-l:
sessionoptionalpam_keyinit.so force revoke


It would appear to me that keyutils and pam_keyinit, and most of the
util-linux PAM config originate in Fedora(/RH). The Fedora folks
are probably the ones to ask how all of this is supposed to work.

> Thanks for your help, which is greatly appreciated.

Sorry that I cannot add much useful info here.

Chris

Bug#1003039: [Pkg-javascript-devel] Bug#1003039: Bug#1003039: node-terser: Please update node-commander dependency to version 8

[Jonas Smedegaard]

Quoting Yadd (2022-02-06 13:18:10)
> On 06/02/2022 12:35, Jonas Smedegaard wrote:
> > Quoting Yadd (2022-01-03 08:08:31)
> >> node-commander 8 changed option parsing. Here is a proposed patch 
> >> to be used in replacement of 1001_use_commander_4.patch
> > 
> > Thanks for the patch!
> > 
> > If I understand correctly, the patch is not backwards-compatible 
> > with node-commander currently in Debian unstable/testing.  I will 
> > therefore do nothing until node-commander enters unstable.

> Thanks to look at this. Yes, we have to coordinate this because I have 
> to add a 'Breaks: node-terser (<< XXX)'

Could you please clarify: Which range of node-commander releases should 
the proposed patch support?

 - 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#1003039: [Pkg-javascript-devel] Bug#1003039: Bug#1003039: node-terser: Please update node-commander dependency to version 8

[Yadd]

On 06/02/2022 17:01, Jonas Smedegaard wrote:

Quoting Yadd (2022-02-06 13:18:10)

On 06/02/2022 12:35, Jonas Smedegaard wrote:

Quoting Yadd (2022-01-03 08:08:31)

node-commander 8 changed option parsing. Here is a proposed patch
to be used in replacement of 1001_use_commander_4.patch


Thanks for the patch!

If I understand correctly, the patch is not backwards-compatible
with node-commander currently in Debian unstable/testing.  I will
therefore do nothing until node-commander enters unstable.



Thanks to look at this. Yes, we have to coordinate this because I have
to add a 'Breaks: node-terser (<< XXX)'


Could you please clarify: Which range of node-commander releases should
the proposed patch support?


AFAIK, it is for commander >= 7

Bug#1004832: ITP: hyx -- minimalistic but powerful vim-like hex editor

[Geert Stappers]

On Wed, Feb 02, 2022 at 07:09:56AM -0600, Russell Hernandez Ruiz wrote:
> On Wed, 2022-02-02 at 14:02 +0100, Geert Stappers wrote:
> > Is there a VCS,  Version Control System,  that has hyx debian
> > packaging?  (Please recieve that yes-no-question as a conversation starter)
> 
> No.

OK


> Should I upload this as a git somewhere?

Yes,  and I could create a git repository at Salsa.
( https://salsa.debian.org )

So, that means there are (at least) two paths to a git repository
where the debian tarball for hyx can live.

Both paths are fine with me.

@Russell   I make it your call.
Please respond with an option from something along:
* Stappers: Yes, a git repo at Salsa is fine. Create one
* There is now   ${GIT_REPO_URL}
* I prefer the old days approach when the debian directory
  was "maintainer pet thing". (AFAIK this is still valid)
* I choose ..


> The original project has no version control.

That is fine.  Upstream provides tarballs.

Thing that could be improved is that https://yx7.cc/code/hyx/
would has an index. Something that allows to see that a new
upstream version is available. (It is what debian utility `uscan`
does.)


Regards
Geert Stappers
* Tried (the packaged) `hyx`
* Willing to upload it into Debian
* Discussing if and where a hyx debian directory VCS repository
* Added upstream author, Lorenz Panny, to 'To: '
* Referenced https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004832 for 
Lorenz
-- 
Silence is hard to parse

Bug#1005005: linux-image-5.15.0-3-amd64: suspend failure with admgpu

[Dominique Dumont]

On Saturday, 5 February 2022 21:25:03 CET Salvatore Bonaccorso wrote:
> Does the issue persist if you upgrade to the most recent 5.16.y
> version? 5.16.4-1~exp1

yes

> (5.16.7-1 should land soon as well). 

I'll try it when it's available

> Any chance
> you can bisect the commit introducing the issue?

It's been a while since I've compiled my own kernel. 

Do you have a documentation that explains the process to compile a kernel (or 
only module amdgpu) using Debian config ?

All the best

Bug#1003406: RFS: simple-scan/40.7-1 -- Simple Scanning Utility

[Jörg Frings-Fürst]

tags 1003406 - moreinfo
thanks


Hello,

I have uploaded a new version with 2 new patches to fix the build
errors.

CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D


Jörg Frings-Fürst
D-54470 Lieser

git:  https://jff.email/cgit/


Threema: SYR8SJXB
Skype: joergpenguin
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.




Am Samstag, dem 22.01.2022 um 15:31 +0100 schrieb Bastian Germann:
> Control: tags -1 moreinfo
> 
> On Fri, 14 Jan 2022 02:56:46 +0100 Adam Borowski
>  wrote:
> > On Sun, Jan 09, 2022 at 06:49:08PM +0100, Jörg Frings-Fürst wrote:
> > >    Package name    : simple-scan
> > >    Version : 40.7-1
> > 
> > >  simple-scan (40.7-1) unstable; urgency=medium
> > >  .
> > >    * New upstream release.
> > >    * debian/copyright:
> > >  - Add year 2022 to myself.
> > >    * Declare compliance with Debian Policy 4.6.0.1 (No changes
> > > needed).
> > >    * New .gitignore.
> > 
> > Hi!
> > It fails to build:
> > 
> > ../data/meson.build:11:5: ERROR: Function does not take positional
> > arguments.
> 
> Please untag moreinfo when you have provided a fixed version.
> 




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

Bug#1005064: RFS: libunistring/1.0-1 -- Unicode string library for C

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name: libunistring
   Version : 1.0-1
   Upstream Author : Bruno Haible 
   URL : https://www.gnu.org/software/libunistring/
   License : GPL-3+, LGPL-3+ or GPL-2+, GPL-2+ with 
 distribution exception, GPL-3+ or GFDL-1.2+,
 FreeSoftware, MIT, GPL-2+
   Vcs : https://jff.email/cgit/libunistring.git
   Section : libs

It builds those binary packages:

  libunistring-dev - Unicode string library for C - development files
  libunistring2 - Unicode string library for C

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/libu/libunistring/libunistring_1.0-1.dsc

or from 

 git https://jff.email/cgit/libunistring.git/?h=release%2Fdebian%2F1.0-1




Changes since the last upload:

 libunistring (1.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Declare compliance with Debian Policy 4.6.0.1 (No changes needed).
   * Refresh debian/libunistring2.symbols.
   * debian/copyright:
 - Refresh uploader copyright years.
 - Add 2022 to myself.
   * debian/patches:
 - Refresh 0700-multiarch-libc.patch.
 - In series comment out:
   + 0005-fix_build_musl.patch
   + 0705-gcc-9.patch
   + 0010-AC_INIT.patch


CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D


Jörg Frings-Fürst
D-54470 Lieser

git:  https://jff.email/cgit/


Threema: SYR8SJXB
Skype: joergpenguin
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1003039: [Pkg-javascript-devel] Bug#1003039: Bug#1003039: node-terser: Please update node-commander dependency to version 8

[Jonas Smedegaard]

Quoting Yadd (2022-02-06 14:55:28)
> On 06/02/2022 14:51, Jonas Smedegaard wrote:
> > Quoting Yadd (2022-02-06 14:24:02)
> >> On 06/02/2022 13:36, Jonas Smedegaard wrote:
> >>> Quoting Yadd (2022-02-06 13:18:10)
>  On 06/02/2022 12:35, Jonas Smedegaard wrote:
> > Quoting Yadd (2022-01-03 08:08:31)
> >> node-commander 8 changed option parsing. Here is a proposed patch
> >> to be used in replacement of 1001_use_commander_4.patch
> >
> > Thanks for the patch!
> >
> > If I understand correctly, the patch is not backwards-compatible
> > with node-commander currently in Debian unstable/testing.  I will
> > therefore do nothing until node-commander enters unstable.
> >>>
>  Thanks to look at this. Yes, we have to coordinate this because I
>  have to add a 'Breaks: node-terser (<< XXX)'
> >>>
> >>> Only coordination needed is, I think, is to bump severity of this
> >>> bugreport when new node-commander enters unstable.
> >>>
> >>>
>  I think the same patch should be applied to uglifyjs
> >>>
> >>> node-uglifyjs stopped using node-commander since release 3.10.1-1,
> >>> so it seems to me that no new Breaks is needed compared to the one
> >>> in node-commander 6.2.1-2, and that even that can be dropped when
> >>> buster stops being supported.
> >>>
> >>>- Jonas
> >>
> >> OK, for now node-commander breaks yarnpkg < 1.22.10+~cs22.25.14-6~ and
> >> cleancss < 5.2.2+~5.5.0~. I'm ready to push these 3 packages. Do I
> >> have to add "terser (<< 4.1.2-9~)" ?
> > 
> > I think this is better: "Breaks: uglifyjs.terser (<= 4.1.2-9+)"
> 
> This forbid 4.1.2-9 which doesn't exist yet, isn't it ?

According to https://tracker.debian.org/pkg/node-terser I successfully 
released uglifyjs.terser 4.1.2-9 2021-11-05.

...but I think you are right that ~ is more correct, so use this:

  Breaks: uglifyjs.terser (<< 4.1.2-10~)


 - 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#1003039: [Pkg-javascript-devel] Bug#1003039: Bug#1003039: node-terser: Please update node-commander dependency to version 8

[Yadd]

On 06/02/2022 14:51, Jonas Smedegaard wrote:

Quoting Yadd (2022-02-06 14:24:02)

On 06/02/2022 13:36, Jonas Smedegaard wrote:

Quoting Yadd (2022-02-06 13:18:10)

On 06/02/2022 12:35, Jonas Smedegaard wrote:

Quoting Yadd (2022-01-03 08:08:31)

node-commander 8 changed option parsing. Here is a proposed patch
to be used in replacement of 1001_use_commander_4.patch


Thanks for the patch!

If I understand correctly, the patch is not backwards-compatible
with node-commander currently in Debian unstable/testing.  I will
therefore do nothing until node-commander enters unstable.



Thanks to look at this. Yes, we have to coordinate this because I
have to add a 'Breaks: node-terser (<< XXX)'


Only coordination needed is, I think, is to bump severity of this
bugreport when new node-commander enters unstable.



I think the same patch should be applied to uglifyjs


node-uglifyjs stopped using node-commander since release 3.10.1-1,
so it seems to me that no new Breaks is needed compared to the one
in node-commander 6.2.1-2, and that even that can be dropped when
buster stops being supported.

   - Jonas


OK, for now node-commander breaks yarnpkg < 1.22.10+~cs22.25.14-6~ and
cleancss < 5.2.2+~5.5.0~. I'm ready to push these 3 packages. Do I
have to add "terser (<< 4.1.2-9~)" ?


I think this is better: "Breaks: uglifyjs.terser (<= 4.1.2-9+)"


This forbid 4.1.2-9 which doesn't exist yet, isn't it ?

Bug#1003039: [Pkg-javascript-devel] Bug#1003039: Bug#1003039: node-terser: Please update node-commander dependency to version 8

[Jonas Smedegaard]

Quoting Yadd (2022-02-06 14:24:02)
> On 06/02/2022 13:36, Jonas Smedegaard wrote:
> > Quoting Yadd (2022-02-06 13:18:10)
> >> On 06/02/2022 12:35, Jonas Smedegaard wrote:
> >>> Quoting Yadd (2022-01-03 08:08:31)
>  node-commander 8 changed option parsing. Here is a proposed patch 
>  to be used in replacement of 1001_use_commander_4.patch
> >>>
> >>> Thanks for the patch!
> >>>
> >>> If I understand correctly, the patch is not backwards-compatible 
> >>> with node-commander currently in Debian unstable/testing.  I will 
> >>> therefore do nothing until node-commander enters unstable.
> > 
> >> Thanks to look at this. Yes, we have to coordinate this because I 
> >> have to add a 'Breaks: node-terser (<< XXX)'
> > 
> > Only coordination needed is, I think, is to bump severity of this 
> > bugreport when new node-commander enters unstable.
> > 
> > 
> >> I think the same patch should be applied to uglifyjs
> > 
> > node-uglifyjs stopped using node-commander since release 3.10.1-1, 
> > so it seems to me that no new Breaks is needed compared to the one 
> > in node-commander 6.2.1-2, and that even that can be dropped when 
> > buster stops being supported.
> > 
> >   - Jonas
> 
> OK, for now node-commander breaks yarnpkg < 1.22.10+~cs22.25.14-6~ and 
> cleancss < 5.2.2+~5.5.0~. I'm ready to push these 3 packages. Do I 
> have to add "terser (<< 4.1.2-9~)" ?

I think this is better: "Breaks: uglifyjs.terser (<= 4.1.2-9+)"

That rejects current unsupported terser in unstable, and also potential 
well-versioned derivatives, but not the next one.

It fails to reject current unsupported _experimental_ package, but you 
should not care about experimental when targeting unstable.

When you have released, then I will release package with patch applied, 
to unstable and also to experimental.

Makes sense, or do you suspect I missed something?


 - 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#1003039: [Pkg-javascript-devel] Bug#1003039: Bug#1003039: node-terser: Please update node-commander dependency to version 8

[Yadd]

On 06/02/2022 13:36, Jonas Smedegaard wrote:

Quoting Yadd (2022-02-06 13:18:10)

On 06/02/2022 12:35, Jonas Smedegaard wrote:

Quoting Yadd (2022-01-03 08:08:31)

node-commander 8 changed option parsing. Here is a proposed patch
to be used in replacement of 1001_use_commander_4.patch


Thanks for the patch!

If I understand correctly, the patch is not backwards-compatible
with node-commander currently in Debian unstable/testing.  I will
therefore do nothing until node-commander enters unstable.



Thanks to look at this. Yes, we have to coordinate this because I have
to add a 'Breaks: node-terser (<< XXX)'


Only coordination needed is, I think, is to bump severity of this
bugreport when new node-commander enters unstable.



I think the same patch should be applied to uglifyjs


node-uglifyjs stopped using node-commander since release 3.10.1-1, so it
seems to me that no new Breaks is needed compared to the one in
node-commander 6.2.1-2, and that even that can be dropped when buster
stops being supported.

  - Jonas


OK, for now node-commander breaks yarnpkg < 1.22.10+~cs22.25.14-6~ and 
cleancss < 5.2.2+~5.5.0~. I'm ready to push these 3 packages. Do I have 
to add "terser (<< 4.1.2-9~)" ?

Bug#1005063: lxpanel: Keyboard layout switching is broken

[Maksim Dmitrichenko]

Package: lxpanel
Version: 0.10.1-2+rpt11
Severity: important
Tags: l10n
X-Debbugs-Cc: dmitr...@gmail.com

Dear Maintainer,

When you configure keyboard layouts via taskbar applet, you can't switch to any 
layout except the first one.
You can notice that for a fraction of second layout is switched but then 
something triggers a switch to the first layout.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: armv7l

Kernel: Linux 5.10.92-v7l+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to ru_RU.UTF-8), LANGUAGE=ru_RU.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxpanel depends on:
ii  libasound2   1.2.4-1.1+rpt2
ii  libc62.31-13+rpt2+rpi1+deb11u2
ii  libcairo21.16.0-5+rpt1
ii  libcurl3-gnutls  7.74.0-1.3+deb11u1
ii  libfm-gtk4   1.3.2-1+rpt3
ii  libfm-modules1.3.2-1+rpt3
ii  libfm4   1.3.2-1+rpt3
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+rpt3
ii  libiw30  30~pre9-13.1
ii  libkeybinder-3.0-0   0.3.2-1.1
ii  libmenu-cache3   1.1.0-1.1
ii  libpango-1.0-0   1.46.2-3
ii  libwnck-3-0  3.36.0-1
ii  libx11-6 2:1.7.2-1
ii  libxml2  2.9.10+dfsg-6.7
ii  lxmenu-data  0.1.5-2.1
ii  lxpanel-data 0.10.1-2+rpt11

Versions of packages lxpanel recommends:
ii  libnotify-bin 0.7.9-3
ii  lxterminal [x-terminal-emulator]  0.4.0-1+rpt2
ii  notification-daemon   3.20.0-4
ii  pavucontrol   4.0-2
ii  xkb-data  2.29-2

Versions of packages lxpanel suggests:
ii  chromium-browser [www-browser]  95.0.4638.78-rpt6
ii  dillo [www-browser] 3.0.5-7+rpt1
ii  menu2.1.48

-- no debconf information

Bug#1003039: [Pkg-javascript-devel] Bug#1003039: Bug#1003039: node-terser: Please update node-commander dependency to version 8

[Jonas Smedegaard]

Quoting Yadd (2022-02-06 13:18:10)
> On 06/02/2022 12:35, Jonas Smedegaard wrote:
> > Quoting Yadd (2022-01-03 08:08:31)
> >> node-commander 8 changed option parsing. Here is a proposed patch 
> >> to be used in replacement of 1001_use_commander_4.patch
> > 
> > Thanks for the patch!
> > 
> > If I understand correctly, the patch is not backwards-compatible 
> > with node-commander currently in Debian unstable/testing.  I will 
> > therefore do nothing until node-commander enters unstable.

> Thanks to look at this. Yes, we have to coordinate this because I have 
> to add a 'Breaks: node-terser (<< XXX)'

Only coordination needed is, I think, is to bump severity of this 
bugreport when new node-commander enters unstable.


> I think the same patch should be applied to uglifyjs

node-uglifyjs stopped using node-commander since release 3.10.1-1, so it 
seems to me that no new Breaks is needed compared to the one in 
node-commander 6.2.1-2, and that even that can be dropped when buster 
stops being supported.

 - 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#1005062: looking-glass: Bundles library that is present in Debian

[Gard Spreemann]

Source: looking-glass
Version: 0+b4+dfsg.1-1
Severity: normal

Dear Maintainer,

looking-glass's upstream bundles some external code as git submodules,
and the Debian package uses these. In the time since looking-glass
entered the archive, one of those bundled libraries – relacy – also
became part of Debian as librelacy-dev.

The version of relacy provided by librelacy-dev and the one bundled in
looking-glass seem to be identical, and looking-glass should therefore
use the Debian package.


 -- Gard

Bug#1005004: lots of missing entries in debian/copyright

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/16928

I sent an upstream PR to add the missing node_modules/ copyrights. If there is
anything else wrong, I'll need more information (see my previous reply).

Thanks!

Martin

Bug#1005043: lintian: check that Python version numbers are not 0.0.0

[Julian Gilbey]

On Sat, Feb 05, 2022 at 04:42:57PM -0500, Sandro Tosi wrote:
> > The test for this bug (and it should probably be recorded as an error,
> > not just a warning, as no Python package should have a version number
> > of 0.0.0)
> 
> what exactly is the problem that would make it an 'error'?

When a package uses pkg_resources to determine the version number of
some package, it is returned the wrong information.  This is certainly
a packaging error: the upstream package, as installed by pip,
announces "this is version 1.2.3" but the Debian package announces
"this is version 0.0.0".

In the couple of cases I've looked at so far, it is due to the
upstream version using use_scm_version in setup.py.  This works fine
for a version that is in a Git repository, but it doesn't work for
Debian packages, as the Git version lookup fails.  So this needs to be
patched.

Perhaps a better way would be for dh_python3 to handle this by
"teaching" use_scm_version to look at debian/changelog, as this would
save 30+ packages having to continually update a setup.py patch.

What do you think?

Best wishes,

   Julian

Bug#1003039: [Pkg-javascript-devel] Bug#1003039: node-terser: Please update node-commander dependency to version 8

[Yadd]

On 06/02/2022 12:35, Jonas Smedegaard wrote:

Hi Yadd,

Quoting Yadd (2022-01-03 08:08:31)

node-commander 8 changed option parsing. Here is a proposed patch to
be used in replacement of 1001_use_commander_4.patch


Thanks for the patch!

If I understand correctly, the patch is not backwards-compatible with
node-commander currently in Debian unstable/testing.  I will therefore
do nothing until node-commander enters unstable.


Hi,

Thanks to look at this. Yes, we have to coordinate this because I have 
to add a 'Breaks: node-terser (<< XXX)'


I think the same patch should be applied to uglifyjs


If I am mistaken, or am missing other options, then please help
enlighten me. :-)

Btw, sorry for wrongly including this unrelated bugreport in a request
for help upgrading terser.


Best regards,
Yadd

Bug#768073: [pkg-lxc-devel] Bug#768073: ITP: lxd - The Linux Container Daemon

[Pierre-Elliott Bécue]

Mathias Gibbens  wrote on 06/02/2022 at 03:38:03+0100:

> [[PGP Signed Part:No public key for 29EEE2D6ECF442F9 created at 
> 2022-02-06T03:38:03+0100 using RSA]]
>   For those following this ITP, the end is in sight! I have whittled
> down the huge list of missing dependencies to just nine packages, all
> of which are ready for upload. They're just waiting on sponsorship
> and/or other dependencies to make it through into unstable.
>
>   The packaging work for LXD is also largely complete. The git repo is
> available on salsa [1], and I would invite interested parties to take a
> look and provide any feedback. This is the most complicated package
> I've created to date, so I'm sure there's room for improvement.

I can do the sponsorship, send me the list of things to review by mail!
:)

-- 
PEB


signature.asc
Description: PGP signature

Bug#1005061: looking-glass-client: Please package new upstream version

[Gard Spreemann]

Package: looking-glass-client
Severity: wishlist

Dear Maintainer,

Upstream has released the "b5" version. It would be great if the
package could be updated to that version.

PS: It seems that something is broken with the package's d/watch, as
uscan seems to think the "b5-rc1" version is the latest upstream.

 -- Gard

Bug#1003039: [Pkg-javascript-devel] Bug#1003039: node-terser: Please update node-commander dependency to version 8

[Jonas Smedegaard]

Hi Yadd,

Quoting Yadd (2022-01-03 08:08:31)
> node-commander 8 changed option parsing. Here is a proposed patch to 
> be used in replacement of 1001_use_commander_4.patch

Thanks for the patch!

If I understand correctly, the patch is not backwards-compatible with 
node-commander currently in Debian unstable/testing.  I will therefore 
do nothing until node-commander enters unstable.

If I am mistaken, or am missing other options, then please help 
enlighten me. :-)

Btw, sorry for wrongly including this unrelated bugreport in a request 
for help upgrading terser.

Regards,

 - 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#906752: sudo, pam_keyinit, what to do?

[Marc Haber]

X-Debbugs-Cc: util-li...@packages.debian.org

Dear Util-Linux Maintainers,

in sudo, we have currently the situation whether to add calls to
pam_keyinit in our pam configuration files. There is quite a number of
packages doing this, but the pam_keyinit documentation advises "programs
like su" against doing so. However, in Debian, /etc/pam.d/su-l
references pam_keyinit, while /etc/pam.d/su doesn't. On the other hand,
doas doesnt seem to reference pam_keyinit at all.

If sudo goes the way to mimic what su does, we would reference
pam_keyinit in /etc/pam.d/sudo-i which is our form of giving the caller
an interactive session, but not in /etc/pam.d/sudo.

May I ask for you rationale to do things the way you did them for su and
pam_keyinit? Your insights might help us to take a wise decision for
sudo.

On Sat, Feb 27, 2021 at 06:38:00PM +0100, Hilko Bengen wrote:
> The pam_keyring(8) manpage advises against adding pam_keyinit 
> 
> ,
> | This module should not, generally, be invoked by programs like su,
> | since it is usually desirable for the key set to percolate through to
> | the alternate context. The keys have their own permissions system to
> | manage this.
> `
> 
> However, there's no mentioning of the issue described here.
> 
> For what it's worth, RHEL/CentOS 7 ships an /etc/pam.d/sudo which
> contains a line.
> 
> ,
> | sessionoptional pam_keyinit.so revoke
> `
> 
> and they also seem to have different intended behavior for interactive
> usage – there's a separate /etc/pam.d/sudo-i which contains
> 
> ,
> | sessionoptional pam_keyinit.so force revoke
> `

Thanks for your help, which is greatly appreciated.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1004471: help needed to prepare upgrade of terser

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2022-02-06 12:26:08)
> One known blocker for upgrading terser is that the executable has 
> changed name.  I should have adjusted all packages in the Javascript 
> team and filed bugreports against packages outside the team, and now in 
> theory all packages should succesfully build with terser v4.8 available 
> in experimental.
> 
> Next step in upgrading terser to v4.8 is to test if that theory holds 
> true.  I have not found time for testing that for some time, and also 
> don't have the experience in that task so I guess others in the team are 
> more efficient in doing it than me.
> 
> So consider this an invitation to help modernizing terser package:
> 
>  1.  Test-build all reverse-build-dependencies of terser
>  in a build environment with experimental terser 4.8.0-1 installed
>  2a. if many builds fail, report that to 988...@bugs.debian.org
>  2b. if few builds fail, file bugreport against those packages
>  3.  report summary of tests made to 988...@bugs.debian.org

Forgot to mention: Please reply only to 988...@bugs.debian.org

 - 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#1003039: help needed to prepare upgrade of terser

[Jonas Smedegaard]

One known blocker for upgrading terser is that the executable has 
changed name.  I should have adjusted all packages in the Javascript 
team and filed bugreports against packages outside the team, and now in 
theory all packages should succesfully build with terser v4.8 available 
in experimental.

Next step in upgrading terser to v4.8 is to test if that theory holds 
true.  I have not found time for testing that for some time, and also 
don't have the experience in that task so I guess others in the team are 
more efficient in doing it than me.

So consider this an invitation to help modernizing terser package:

 1.  Test-build all reverse-build-dependencies of terser
 in a build environment with experimental terser 4.8.0-1 installed
 2a. if many builds fail, report that to 988...@bugs.debian.org
 2b. if few builds fail, file bugreport against those packages
 3.  report summary of tests made to 988...@bugs.debian.org

Thanks for considering!

 - Jonas

P.S.  If noone else does this, I will do it myself at some point, just 
not sure when...

-- 
 * 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#1002143: xserver-xorg-video-qxl: FTBFS: xf86Opt.h:44:10: error: two or more data types in declaration specifiers

[John Paul Adrian Glaubitz]

Hello!

There is an upstream fix available which fixes the FTBFS, see [1].

Adrian

> [1] 
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-qxl/-/merge_requests/6

-- 
 .''`.  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#1005060: transition: ace

[Sudip Mukherjee]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Hi,

Small transition with only two affected packages: diagnostics, ivtools,
ivtools builds fine with ace 7.0.6+dfsg-1 version in experimental.
diagnostics already has a FTBFS #984031 and I could not verify it.

The autogenerated ben tracker looks good. Please consider 'ace' for
transition.
Thanks in advance.


--
Regards
Sudip

Bug#1005058: dnsperf: python3/-pcapy dependencies

[Daniel Baumann]

Hi Bastian,

thank you for your report.

On 2/6/22 11:52, Bastian Germann wrote:
> dnsperf's pcap-queryparse depends on python3 and python3-pcapy. Please
> make them dependencies (which is also hinted by the lintian error),
> remove that binary from the package, or create an additional binary
> package from it (if you want to keep the possibility to install the
> dnsperf package without the python3 dependency).

right, or: have the python3/python3-pcapy in Suggests (or Recommends),
which is appropriate for a non-essential additional utility in the
package and a common scenario in Debian.

Since this is what is currently already implemented by the package, I
don't think there's anything to do except for debating if Suggests or
Recommends are more appropriate here.

Regards,
Daniel

Bug#1005058: dnsperf: python3/-pcapy dependencies

[Bastian Germann]

Package: dnsperf
Version: 2.9.0-1

dnsperf's pcap-queryparse depends on python3 and python3-pcapy. Please make them dependencies (which is also hinted by 
the lintian error), remove that binary from the package, or create an additional binary package from it (if you want to 
keep the possibility to install the dnsperf package without the python3 dependency).

Bug#1005057: RFS: sane-backends/1.1.1-1 -- API library for scanners

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sane-backends":

   Package name: sane-backends
   Version : 1.1.1-1
   Upstream Author : sane-de...@alioth-lists.debian.net
   URL : http://www.sane-project.org
   License : GFDL-1.1, Artistic, LGPL-2.1+, GPL-2, 
 GPL-2+ with sane exception, GPL-2+, GPL-3+
   Vcs : https://jff.email/cgit/sane-backends.git
   Section : graphics

It builds those binary packages:

  sane-utils - API library for scanners -- utilities
  libsane-common - API library for scanners -- documentation and support files
  libsane1 - API library for scanners
  libsane-dev - API development library for scanners [development files]
  libsane - API library for scanners [transitional package]

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

  https://mentors.debian.net/package/sane-backends/

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

 dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.1.1-1.dsc

or from 

 git https://jff.email/cgit/sane-backends.git/?h=release%2Fdebian%2F1.1.1-1


Changes since the last upload:

 sane-backends (1.1.1-1) unstable; urgency=medium
 .
   * New upstream release.
 - Remove not longer needed patches:
   + 0180-gt68xx_fix_use-after-free_two_memleaks.patch
   + 0600-scanimage_manpage.patch
 - Refresh patches:
   + 0605-fix_groff-warnings.patch
   + 0100-source_spelling.patch
 - Closes: #920216, #998616.
   * debian/copyright:
 - Refresh to the new upstream release.
 - Add 2022 to myself.
   * Remove *.lintian-overrides.
   * debian/sane-utils.postinst:
 - Add home dir for user/group saned (Closes: #995732).
   * debian/sane-utils.postrm:
 - Use --remove-home instead --remove-all-files (Closes: #1001960).
   * Reactivate debian/patches/0125-multiarch_dll_search_path.patch
 (Closes: #1002704).


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D


Jörg Frings-Fürst
D-54470 Lieser

git:  https://jff.email/cgit/


Threema: SYR8SJXB
Skype: joergpenguin
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1005001: kernel: traps: boinccmd/boincmgr trap invalid opcode […] error:0 in libboinc.so.7.18.1/boincmgr

[R. Strack]

i can confirm this bug
since update to 7.18.1 boinc client does not start any more

systemd[1]: boinc-client.service: Main process exited, code=killed, status=4/ILL
traps: boinc[436] trap invalid opcode ip:557a0e20bcf4 sp:7fffaf68e300
error:0 in boinc[557a0e203000+c]
systemd[1]: boinc-client.service: Failed with result 'signal'.

Bug#1005056: linux-headers-4.19.0-14-all: On x86 cpu can not access on symbols.

[Corcodel Marian]

Package: linux-headers-4.19.0-14-all
Severity: critical
Justification: breaks unrelated software

Hi i m not expect  kernel to have access to alls symbols from kernel but ,many
symbols is out of games in real mode.
See /boot/Sytem-map-4.19.0-14-all for more info and check symbolls need to be
under 1Mbyte limit on address.



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

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

Versions of packages linux-headers-4.19.0-14-all depends on:
pn  linux-headers-4.19.0-14-all-amd64  

linux-headers-4.19.0-14-all recommends no packages.

linux-headers-4.19.0-14-all suggests no packages.

Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

[Anton Khirnov]

Quoting Santiago Garcia Mantinan (2022-02-05 22:56:09)
> Well, having IPv6 addresses attached to those ports can also be undesirable,

Could you please explain why do you think so? It would be good to have
the reason documented somewhere, as this behavior was quite surprising
to me.

> I really think that those addresses should be allowed with an explicit
> config not by default.

I suppose adding an option won't be too hard. I'll send a new patch.

-- 
Anton Khirnov