Bug#1004719: shotdetect: FTBFS with ffmpeg 5.0

2022-01-31 Thread Sebastian Ramacher
Source: shotdetect
Version: 1.0.86-6
Severity: important
X-Debbugs-Cc: sramac...@debian.org
Tags: ftbfs sid bookworm
Usertags: ffmpeg5.0

shotdetect FTBFS with ffmpeg 5.0 (available in experimental):
| g++ -DHAVE_CONFIG_H -I.  -Iinclude -Iresources/   
-I/usr/include/x86_64-linux-gnu -I/usr/include/libxml2 -I/usr/include/libxml2 
-Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o main.o `test -f 
'src/main.cpp' || echo './'`src/main.cpp
| src/film.cpp: In member function ‘void film::update_metadata()’:
| src/film.cpp:146:61: error: ‘AVStream’ {aka ‘struct AVStream’} has no member 
named ‘codec’
|   146 |   this->height = int 
(pFormatCtx->streams[videoStream]->codec->height);
|   | ^
| src/film.cpp:147:60: error: ‘AVStream’ {aka ‘struct AVStream’} has no member 
named ‘codec’
|   147 |   this->width = int 
(pFormatCtx->streams[videoStream]->codec->width);
|   |^
| src/film.cpp:149:76: error: ‘AVStream’ {aka ‘struct AVStream’} has no member 
named ‘codec’
|   149 |   avcodec_string (buf, sizeof (buf), 
pFormatCtx->streams[videoStream]->codec, 0);
|   |   
 ^
| src/film.cpp: In member function ‘int film::process()’:
| src/film.cpp:213:3: error: ‘av_register_all’ was not declared in this scope
|   213 |   av_register_all ();
|   |   ^~~
| src/film.cpp:241:39: error: ‘AVStream’ {aka ‘struct AVStream’} has no member 
named ‘codec’
|   241 |   switch (pFormatCtx->streams[j]->codec->codec_type)
|   |   ^
| src/film.cpp:269:58: error: ‘AVStream’ {aka ‘struct AVStream’} has no member 
named ‘codec’
|   269 |   pCodecCtxAudio = pFormatCtx->streams[audioStream]->codec;
|   |  ^
| src/film.cpp:270:42: error: invalid conversion from ‘const AVCodec*’ to 
‘AVCodec*’ [-fpermissive]
|   270 |   pCodecAudio = avcodec_find_decoder (pCodecCtxAudio->codec_id);
|   | ~^~
|   |  |
|   |  const AVCodec*
| src/film.cpp:284:53: error: ‘AVStream’ {aka ‘struct AVStream’} has no member 
named ‘codec’
|   284 |   pCodecCtx = pFormatCtx->streams[videoStream]->codec;
|   | ^
| src/film.cpp:285:37: error: invalid conversion from ‘const AVCodec*’ to 
‘AVCodec*’ [-fpermissive]
|   285 |   pCodec = avcodec_find_decoder (pCodecCtx->codec_id);
|   |~^
|   | |
|   | const AVCodec*
| src/film.cpp:302:18: error: ‘avpicture_get_size’ was not declared in this 
scope
|   302 |   numBytes = avpicture_get_size (AV_PIX_FMT_RGB24, width, height);
|   |  ^~
| src/film.cpp:310:24: error: ‘AVPicture’ was not declared in this scope; did 
you mean ‘AVPictureType’?
|   310 |   avpicture_fill ((AVPicture *) pFrameRGB, buffer, 
AV_PIX_FMT_RGB24, width, height);
|   |^
|   |AVPictureType
| src/film.cpp:310:35: error: expected primary-expression before ‘)’ token
|   310 |   avpicture_fill ((AVPicture *) pFrameRGB, buffer, 
AV_PIX_FMT_RGB24, width, height);
|   |   ^
| src/film.cpp:310:7: error: ‘avpicture_fill’ was not declared in this scope
|   310 |   avpicture_fill ((AVPicture *) pFrameRGB, buffer, 
AV_PIX_FMT_RGB24, width, height);
|   |   ^~
| src/film.cpp:312:35: error: expected primary-expression before ‘)’ token
|   312 |   avpicture_fill ((AVPicture *) pFrameRGBprev, buffer2, 
AV_PIX_FMT_RGB24, width, height);
|   |   ^
| src/film.cpp:339:25: warning: ‘void av_init_packet(AVPacket*)’ is deprecated 
[-Wdeprecated-declarations]
|   339 |   av_init_packet(&avpkt);
|   |   ~~^~~~
| In file included from /usr/include/x86_64-linux-gnu/libavcodec/avcodec.h:45,
|  from include/film.h:21,
|  from src/film.cpp:18:
| /usr/include/x86_64-linux-gnu/libavcodec/packet.h:506:6: note: declared here
|   506 | void av_init_packet(AVPacket *pkt);
|   |  ^~
| src/film.cpp:346:11: error: ‘avcodec_decode_video2’ was not declared in this 
scope; did you mean ‘avcodec_decode_subtitle2’?
|   346 |   avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, 
&avpkt);
|   |   ^
|   |   avcodec_decode_subtitle2
| src/film.cpp:407:9: error: ‘av_free

Bug#1004718: opencv: FTBFS with ffmpeg 5.0

2022-01-31 Thread Sebastian Ramacher
Source: opencv
Version: 4.5.4+dfsg-9
Severity: important
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm ftbfs
Usertags: ftbfs5.0

opencv FTBFS with ffmpeg 5.0 (available in experimental):
| [569/1071] /usr/lib/ccache/c++ -DCVAPI_EXPORTS -DENABLE_PLUGINS 
-DHAVE_CAMV4L2 -DHAVE_DC1394_2 -DHAVE_FFMPEG -DHAVE_GPHOTO2 -DHAVE_GSTREAMER 
-D_USE_MATH_DEFINES -D__OPENCV_BUILD=1 -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/<>/obj-x86_64-linux-gnu 
-I/<>/modules/videoio/include 
-I/<>/obj-x86_64-linux-gnu/modules/videoio 
-I/<>/modules/core/include 
-I/<>/modules/imgproc/include 
-I/<>/modules/imgcodecs/include -isystem /usr/include/gdal 
-isystem /usr/include/eigen3 -isystem /usr/include/gstreamer-1.0 -isystem 
/usr/include/glib-2.0 -isystem /usr/lib/x86_64-linux-gnu/glib-2.0/include 
-isystem /usr/include/orc-0.4 -isystem /usr/include/CL -isystem 
/usr/include/gphoto2 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2   -fsigned-char -W -Wall -Werror=return-type 
-Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat 
-Werror=format-security -Wmissing-declarations -Wundef -Winit-self 
-Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized -Wsuggest-override 
-Wno-delete-non-virtual-dtor -Wno-comment -Wimplicit-fallthrough=3 
-Wno-strict-overflow -fdiagnostics-show-option -Wno-long-long -pthread 
-fomit-frame-pointer -ffunction-sections -fdata-sections  -msse -msse2 
-fvisibility=hidden -fvisibility-inlines-hidden -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security  -DNDEBUG -fPIC -std=c++11 -MD -MT 
modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_ffmpeg.cpp.o -MF 
modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_ffmpeg.cpp.o.d -o 
modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_ffmpeg.cpp.o -c 
/<>/modules/videoio/src/cap_ffmpeg.cpp
| FAILED: modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_ffmpeg.cpp.o 
| /usr/lib/ccache/c++ -DCVAPI_EXPORTS -DENABLE_PLUGINS -DHAVE_CAMV4L2 
-DHAVE_DC1394_2 -DHAVE_FFMPEG -DHAVE_GPHOTO2 -DHAVE_GSTREAMER 
-D_USE_MATH_DEFINES -D__OPENCV_BUILD=1 -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/<>/obj-x86_64-linux-gnu 
-I/<>/modules/videoio/include 
-I/<>/obj-x86_64-linux-gnu/modules/videoio 
-I/<>/modules/core/include 
-I/<>/modules/imgproc/include 
-I/<>/modules/imgcodecs/include -isystem /usr/include/gdal 
-isystem /usr/include/eigen3 -isystem /usr/include/gstreamer-1.0 -isystem 
/usr/include/glib-2.0 -isystem /usr/lib/x86_64-linux-gnu/glib-2.0/include 
-isystem /usr/include/orc-0.4 -isystem /usr/include/CL -isystem 
/usr/include/gphoto2 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2   -fsigned-char -W -Wall -Werror=return-type 
-Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat 
-Werror=format-security -Wmissing-declarations -Wundef -Winit-self 
-Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized -Wsuggest-override 
-Wno-delete-non-virtual-dtor -Wno-comment -Wimplicit-fallthrough=3 
-Wno-strict-overflow -fdiagnostics-show-option -Wno-long-long -pthread 
-fomit-frame-pointer -ffunction-sections -fdata-sections  -msse -msse2 
-fvisibility=hidden -fvisibility-inlines-hidden -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security  -DNDEBUG -fPIC -std=c++11 -MD -MT 
modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_ffmpeg.cpp.o -MF 
modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_ffmpeg.cpp.o.d -o 
modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_ffmpeg.cpp.o -c 
/<>/modules/videoio/src/cap_ffmpeg.cpp
| In file included from /<>/modules/videoio/src/cap_ffmpeg.cpp:50:
| /<>/modules/videoio/src/cap_ffmpeg_impl.hpp:537:5: error: 
‘AVBSFContext’ does not name a type; did you mean ‘AVIOContext’?
|   537 | AVBSFContext* bsfc;
|   | ^~~~
|   | AVIOContext
| /<>/modules/videoio/src/cap_ffmpeg_impl.hpp: In member function 
‘void CvCapture_FFMPEG::init()’:
| /<>/modules/videoio/src/cap_ffmpeg_impl.hpp:583:5: error: ‘bsfc’ 
was not declared in this scope
|   583 | bsfc = NULL;
|   | ^~~~
| /<>/modules/videoio/src/cap_ffmpeg_impl.hpp: In member function 
‘void CvCapture_FFMPEG::close()’:
| /<>/modules/videoio/src/cap_ffmpeg_impl.hpp:613:34: error: 
‘AVStream’ {aka ‘struct AVStream’} has no member named ‘codec’
|   613 | avcodec_close( video_st->codec );
|   |  ^
| /<>/modules/videoio/src/cap_ffmpeg_impl.hpp:648:9: error: ‘bsfc’ 
was not declared in this scope
|   648 | if (bsfc)
|   | ^~~~
| /<>/modules/videoio/src/cap_ffmpeg_impl.hpp:651:9: error: 
‘av_bsf_free’ was not declared in this scope; did you mean ‘av_opt_free’?
|   651 | av_bsf_free(&bsfc);
|   | ^~~
|   | av_opt_free
| /<>/modules/videoio/sr

Bug#1004717: transition: libkiwix and libzim

2022-01-31 Thread Kunal Mehta
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lego...@debian.org

Hello,

libkiwix and libzim have new major versions with SONAME bumps, requiring
a transition. Both are maintained by the same upstream and basically in
sync with each other, so it makes sense to do as one transition.

All reverse dependencies have new upstream versions as well,
which I've prepared and tested in experimental.

Ben file:

title = "libkiwix and libzim";
is_affected = .depends ~ /(libzim6|libkiwix9)/ | .depends ~ 
/(libzim7|libkiwix10)/;
is_good = .depends ~ /(libzim7|libkiwix10)/;
is_bad = .depends ~ /(libzim6|libkiwix9)/;


Thanks,
-- Kunal



Bug#961551: partitionmanager: Does not start - "Session bus not found"

2022-01-31 Thread Aurélien COUDERC




Le 1 février 2022 02:49:24 GMT+01:00, scott092...@aol.com a écrit :
>I am curious about something...
>
>I thought the rationale of using PolicyKit over sudo was, that with sudo, the 
>entire time an app was running,
>it was with administrative rights, thus there was a longer time for someone to 
>try and take over in some way...

The main idea is not to have privileges for a shorter time but to do *less* as 
a privileged user.
And the first reason to do the change is so that the *UI* doesn't need to run 
as root which has been discouraged for a long time because it offers a huge 
attack surface.

I've not looked at the code but I guess partition manager may need root for 
scanning the disks and partitions, thus asking right away.
Or just for simplicity and not to have to do the polkit transaction from 
various places in the code.



Bug#1004488: Update grpc to new upstream version 1.37

2022-01-31 Thread GCS
Hi Pirate,

On Fri, Jan 28, 2022 at 10:21 PM Pirate Praveen
 wrote:
> While trying to update ruby-gitlab-labkit I got this error
> Could not find 'grpc' (>= 1.37) - did find: [grpc-1.30.2]
> (Gem::MissingSpecVersionError)
>
> Please update grpc to 1.37. I'd be happy to help with the update too.
 A work in progress packaging is available [1]. It's mostly OK, but
the Ruby bindings still need work.
Would it be better to split that out and you can update that as a
standalone package whenever you need?

Regards,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/grpc_1.43.2-1.dsc



Bug#1004685: [Debichem-devel] Bug#1004685: openstructure: upgrade failed

2022-01-31 Thread Andrius Merkys
Control: tags -1 + confirmed

Hi Patrice,

On 2022-01-31 20:31, Patrice DUROUX wrote:
> Here is what I am facing:
> 
> Setting up openstructure (2.3.1-1) ...
> dpkg: error processing package openstructure (--configure):
>  installed openstructure package post-installation script subprocess returned 
> error exit status 1
> Errors were encountered while processing:
>  openstructure
> needrestart is being skipped since dpkg has failed
> E: Sub-process /usr/bin/dpkg returned an error code (1)

I see the same outcome. I will fix this in a short while. Thanks for
reporting.

Andrius



Bug#1003972: marked as done (libphonenumber: New upstream release - please update)

2022-01-31 Thread tony mancill
On Mon, Jan 31, 2022 at 06:49:45AM -0700, Neil Mayhew wrote:
> On 2022-01-29 08:59, Neil Mayhew wrote:
> > On 2022-01-28 22:33, tony mancill wrote:
> > > I noticed that 8.12.42 was released a couple days ago [4].
> > > My thought was to let 8.12.41 transition to testing (5 days) before
> > > uploading to unstable again, in case that impacts whether/when Ubuntu
> > > picks up the update. Let me know if you know otherwise.
> > 
> > That sounds like the best approach. I don't know the details of how
> > Ubuntu picks up the updates, but I have a bug report open with Ubuntu
> > and I'll follow up there once 8.12.41 reaches testing. I'll mention that
> > you're planning to package 8.12.42 as well.
> 
> Ubuntu already picked up 8.12.41 automatically, so I think you could go
> ahead and package 8.12.42 now.

Great.  I plan to do so this week.



Bug#1001610: Gbonds

2022-01-31 Thread Richard Laager

On 1/31/22 19:37, Trey Glover wrote:

I had no idea that the treasury was doing this. Is there a code fix in place 
yet?


In unstable, yes; it's fixed in 2.0.3-17. I wrote code to use the 
Treasury API to generate old-style sbMM.asc files which are stored 
(as always) in ~/.gbonds/


In stable, no; see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002563

--
Richard


OpenPGP_signature
Description: OpenPGP digital signature


Bug#981446: RFA: logcheck -- mails anomalies in the system logfiles to the administrator

2022-01-31 Thread Charles

Dear Jose

> So who want to help me ... ?

I want to help you.

> Does the email address logch...@packages.debian.org still work?

From https://www.debian.org/contact "If you simply want to communicate 
with the maintainer of a Debian package, then you can use the special 
mail aliases set up for each package. Any mail sent to name>@packages.debian.org will be forwarded to the maintainer 
responsible for that package".


Best

Charles


On 01/02/2022 03:20, Jose M Calhariz wrote:

Hi,

I have found some time to work on logcheck, sorry for my delay.  My
plan is to do a quick upload to update Uploaders field before doing
more work on the package.  I do not pretend to exclude anyone or their
work.  So who want to help me and want to be in Uploaders field?

Does the email address logch...@packages.debian.org still work?

Kind regards
Jose M Calhariz


On Wed, Dec 08, 2021 at 08:18:30PM +0530, Charles wrote:

This RFA is progressing slowly.  Do I rightly understand that it is Hannes'
who is to choose the new maintainers?  It must be difficult to choose,
knowing little about us volunteers.  Can we progress by having each of the
volunteers work on one of the current bugs?  That would usefully fix some
bugs, give us volunteers experience of the work and inform Hannes about our
capabilities.







Bug#989384: acpi-call-dkms: new version of linux-call-dkms in https://github.com/nix-community/acpi_call

2022-01-31 Thread Víctor Cuadrado Juan
In addition, applying the workaround fixed suspend on my
Thinkpad T450s.

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


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


Bug#1004715: ITP: obs-transition-table -- plugin for OBS Studio to create a transition table control

2022-01-31 Thread Joao Eriberto Mota Filho
Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, Exeldro 

* Package name: obs-transition-table
  Version : 0.2.1
  Upstream Author : Exeldro 
* URL : 
https://obsproject.com/forum/resources/transition-table.1174/
* License : GPL-2
  Programming Lang: C++
  Description : plugin for OBS Studio to create a transition table control

 This plugin adds a Transition Table to the tools menu. This table is useful
 to program several transitions between scenes. E.g. is possible to program
 a transition from "Any Scene" to "Scene 1" using the transition effect
 "Cut" and with a duration of the "2000ms".
 .
 This plugin, inspired by OBS Transition Matrix, is user-friendly and adds a
 nice professional touch when moving between scenes. This a best way to create
 complex OBS setups.



Bug#1001610: Gbonds

2022-01-31 Thread Trey Glover
I had no idea that the treasury was doing this. Is there a code fix in place 
yet?



Bug#995071: Correction: bug 995071: Libusb?

2022-01-31 Thread Wyatt Ward
Sorry for the hasty email. I just tried it again, and realized it was only
working because of *another* change I made while investigating. It still fails
with my suggested fix. The thing that was working was setting USE_LIBUSB=true
either in the Jamfile or on the command line. It is my understanding that
Argyll normally uses its own code for interacting with the colorimeters; is
that correct?

Since the Libusb support seems to be something the project wants to move away
from, I think this might be worth considering.



Bug#995071: argyll: USB devices not found on big-endian (powerpc)

2022-01-31 Thread Wyatt Ward
I have finally had some time to verify; by adding the byte-swapped version of
my colorimeter's USB Vendor and Product ID's, Argyll enumerates it and lets me
use it. 0765:5020 became 6507:2050.

Spotread appears to be giving correct results, given that they are about the
same on average as when I run it on an x86 system. This makes me believe that
this may be the only big endian issue, but there is plenty I have not tested
(including all other colorimeters and spectrometers Argyll supports).

In summary, Argyll needs to either change how it retrieves the VID and PID to
avoid things like memcpy(), or it needs to swap the bytes internally for big
endian platforms.



Bug#1004689: xterm: CVE-2022-24130

2022-01-31 Thread Thomas Dickey
On Mon, Jan 31, 2022 at 08:37:03PM +0100, Salvatore Bonaccorso wrote:
> Source: xterm
> Version: 370-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for xterm.
> 
> CVE-2022-24130[0]:
> | xterm through Patch 370, when Sixel support is enabled, allows
> | attackers to trigger a buffer overflow in set_sixel in
> | graphics_sixel.c via crafted text.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

changelog as usual reflects the actual report, not a succession of
secondhand information.

I applied a fix for the issue yesterday, which will be in #371.
For backports, do as suggested here:

http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/x11/xterm/patches/patch-graphics__sixel.c

derived from

https://github.com/ThomasDickey/xterm-snapshots/blob/master/graphics_sixel.c

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature


Bug#989384: acpi-call-dkms: new version of linux-call-dkms in https://github.com/nix-community/acpi_call

2022-01-31 Thread Víctor Cuadrado Juan
severity 989384 critical


Raising severity to critical, as failure to fix this bug makes the
system unbootable.

It starts with system freezes, kernel errors, errors on machine boot
from efivars partition full, and then, failure to boot completely. 


For more info, see:
https://gist.github.com/roadkell/9e98db6656e28fbbf1bf51082040f67f



-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


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


Bug#1004714: iotop: Falsely reports CONFIG_TASK_DELAY_ACCT not enabled in kernel

2022-01-31 Thread Matthew Gabeler-Lee
Package: iotop
Version: 0.6-24-g733f3f8-1.1
Severity: normal

With recent bookwork kernel builds, iotop incorrectly reports
`CONFIG_TASK_DELAY_ACCT not enabled in kernel`. This seems to have been
fixed upstream: 
https://repo.or.cz/iotop.git/commit/ab35334d374e588bec12d201fb8869c536f0545d

Workaround: sudo sysctl -w kernel.task_delayacct=1

Other workaround: uninstall this package and install iotop-c instead

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable'), 
(490, 'unstable')
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 iotop depends on:
ii  python3  3.9.2-3

iotop recommends no packages.

iotop suggests no packages.

-- no debconf information



Bug#989384: acpi-call-dkms: new version of linux-call-dkms in https://github.com/nix-community/acpi_call

2022-01-31 Thread Víctor Cuadrado Juan
I can confirm too that I was affected by this issue,
and bumping to 1.2.2 solved it for me.



-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


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


Bug#994833: OpenCL programs abort when intel-opencl-icd is installed

2022-01-31 Thread Andreas Beckmann

On 22/09/2021 15.59, Giuseppe Bilotta wrote:

On Wed, Sep 22, 2021 at 8:32 AM Andreas Beckmann  wrote:

So if it does matter abi-wise for intel-opencl-icd which version of llvm
libigfoo1 was compiled against, we should model this in the dependency
chain.


To be able to confirm this, I would need a version of all the libig*
stuff correctly
compiled against LLVM12 (rather than the mix-up we currently have for
libigdfcl1).
I can then test against intel-opencl-icd version 20.x, which is built
with LLVM11,
and (most probably) confirm that the setup is broken.


I'm no longer convinced that this is an issue of llvm mixing. 
intel-opencl-icd does not have any relation llvm, and can be built fine 
after dropping the corresponding build-depends.
Around the time you reported the problem there was also the switch of 
the default compiler from GCC 10 to GCC 11.


I've prepared three builds of intel-graphics-compiler 1.0.8744:
* in sid against llvm-11 and libopencl-clang11
* in sid against llvm-12 and libopencl-clang12
* in sid against llvm-12 and libopencl-clang13

You can find them here:
https://people.debian.org/~anbe/994833/
directories: igc-llvm*
the corresponding binaries from src:intel-opencl-clang and 
src:spirv-llvm-translator built against llvm-11 and lvm-12 are in the 
misc/ folder.


There are no new binaries for src:intel-compute-runtime, the ones from 
sid and stable should work ;-)


Unfortunately I cannot test this without supported hardware ...

It would be great if you could run some tests with these packages and 
tell me which combination breaks ...


Andreas

PS: mixing llvm versions is still not a good idea and I'll tighten the 
dependencies, but that's going to happen on the 
src:intel-graphics-compiler side, not src:intel-compte-runtime


PPS: switching everything to llvm-13 does not work, yet, as it needs new 
upsteam releases and something does not work yet, and it's a nightmare 
to debug with the full software stack getting new upstream versions and 
the compiler being exchanged at the same time ...




Bug#1004713: GenericName= (empty string) is wrong; just remove it

2022-01-31 Thread Trent W. Buck
Package: torus-trooper
Version: 0.22.dfsg1-12
Severity: minor

Hi, when fiddling with show-generic-names in xfce4-panel,
I noticed Torus Trooper ended up with empty menu label.

I think the line "GenericName=" can and should simply be removed from here:


https://sources.debian.org/src/torus-trooper/0.22.dfsg1-12/debian/torus-trooper.desktop/#L4


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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



Bug#853915:

2022-01-31 Thread Gina Roberts
feport spam


Bug#1004712: sssd is noisy on apparmor messages

2022-01-31 Thread Daniele Palumbo
Package: sssd
Version: 2.4.1-2
Severity: normal
X-Debbugs-Cc: dani...@retaggio.net

Dear Maintainer,

As reported also in
https://bugs.launchpad.net/apparmor/+bug/1910611

dmesg/messages file are filled by messages like:
[603515.147835] audit: type=1400 audit(1643670927.471:17588): 
apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_nss" 
name="/proc/742076/cmdline" pid=423 comm="sssd_nss" requested_mask="r" 
denied_mask="r" fsuid=0 ouid=0

The ubuntu bug report also the fix.
If i'm not wrong, this is also fixed in the unstable version.

The patch is quite straightforward, and affecting only apparmor-profile.
Is possible to backport it?

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-11-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, 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 sssd depends on:
ii  python3-sss  2.4.1-2
ii  sssd-ad  2.4.1-2
ii  sssd-common  2.4.1-2
ii  sssd-ipa 2.4.1-2
ii  sssd-krb52.4.1-2
ii  sssd-ldap2.4.1-2
ii  sssd-proxy   2.4.1-2

sssd recommends no packages.

sssd suggests no packages.

-- no debconf information



Bug#1004711: gimp uses ebook-viewer (from calibre package) for print preview

2022-01-31 Thread Eric Cooper
Package: gimp
Version: 2.10.30-1
Severity: normal

I have both mupdf and calibre installed. When I choose File > Print,
and then Print Preview, gimp launches the ebook-viewer program from
calibre rather than mupdf, which appears before ebook-viewer in
/etc/mailcap (if that matters).

Here's an example of what it runs:
/usr/bin/python3.9 /usr/bin/ebook-viewer /tmp/previewGA5NG1.pdf

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_WARN
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 gimp depends on:
ii  gimp-data2.10.30-1
ii  graphviz 2.42.2-5+b1
ii  libaa1   1.4p5-50
ii  libbabl-0.1-01:0.1.88-1
ii  libbz2-1.0   1.0.8-5
ii  libc62.33-5
ii  libcairo21.16.0-5
ii  libfontconfig1   2.13.1-4.3
ii  libfreetype6 2.11.1+dfsg-1
ii  libgcc-s111.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libgegl-0.4-01:0.4.34-1
ii  libgexiv2-2  0.14.0-1
ii  libgimp2.0   2.10.30-1
ii  libglib2.0-0 2.70.3-1
ii  libgs9   9.55.0~dfsg-3
ii  libgtk2.0-0  2.24.33-2
ii  libgudev-1.0-0   237-2
ii  libharfbuzz0b2.7.4-1
ii  libheif1 1.12.0-2+b3
ii  libilmbase25 2.5.7-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  liblcms2-2   2.12~rc1-2
ii  liblzma5 5.2.5-2
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-2
ii  libopenexr25 2.5.7-1
ii  libopenjp2-7 2.4.0-6
ii  libpango-1.0-0   1.50.3+ds1-4
ii  libpangocairo-1.0-0  1.50.3+ds1-4
ii  libpangoft2-1.0-01.50.3+ds1-4
ii  libpng16-16  1.6.37-3
ii  libpoppler-glib8 20.09.0-3.1
ii  librsvg2-2   2.52.5+dfsg-3+b1
ii  libstdc++6   11.2.0-14
ii  libtiff5 4.3.0-3
ii  libwebp6 0.6.1-2.1
ii  libwebpdemux20.6.1-2.1
ii  libwebpmux3  0.6.1-2.1
ii  libwmf0.2-7  0.2.8.4-17+b1
ii  libx11-6 2:1.7.2-2+b1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages gimp recommends:
ii  ghostscript  9.55.0~dfsg-3

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
pn  gvfs-backends 
ii  libasound21.2.6.1-1

-- no debconf information



Bug#1004710: passwd: 4.11.1 breaks mmdebstrap testsuite by empty directories in /var/mail and /var/spool/mail

2022-01-31 Thread Johannes Schauer Marin Rodrigues
Package: passwd
Version: 1:4.11.1+dfsg1-1
Severity: normal
X-Debbugs-Cc: jo...@debian.org
Control: affects -1 mmdebstrap

Hi,

steps to reproduce:

$ sudo debootstrap unstable debian-unstable-good 
https://snapshot.debian.org/archive/debian/20220131T090427Z/
$ sudo debootstrap unstable debian-unstable-bad 
https://snapshot.debian.org/archive/debian/20220131T160201Z/

when diffing both directories one sees:

Only in debian-unstable-bad/var/mail: _apt
Only in debian-unstable-bad/var/mail: systemd-network
Only in debian-unstable-bad/var/mail: systemd-resolve
Only in debian-unstable-bad/var/spool/mail: _apt
Only in debian-unstable-bad/var/spool/mail: systemd-network
Only in debian-unstable-bad/var/spool/mail: systemd-resolve

The only packages that differ between both chroots are the versions of
login and passwd, hence I'm filing this bug here.

The problem is, that this breaks the testsuite and autopkgtest of
mmdebstrap. Notably, a chroot created with mmdebstrap does not include
these directories.

Is this change indeed related to passwd?

Is the creation of these empty directories intended?

Do you have an explanation why they are only created with debootstrap?

Thanks!

cheers, josch



Bug#990522: libtpms: CVE-2021-3623

2022-01-31 Thread Bastian Germann

Please update to the latest version, which has this CVE fixed.



Bug#1004709: update-ieee-data URLs need updating

2022-01-31 Thread Richard Laager

Package: ieee-data
Version: 20210605.1

I ran into this on 20180805.1 on Ubuntu 20.04, but I verified that the 
same URLs are present in Debian's 20210605.1.


update-ieee-data references URLs (see the files_to_get variable near the 
top) which which no longer work.


For example, this 404s:
https://standards.ieee.org/develop/regauth/oui/oui.txt

I found Ubuntu's bug on this:
https://bugs.launchpad.net/ubuntu/+source/ieee-data/+bug/1796047

That suggests this URL, which works (note http only; https hangs):
http://standards-oui.ieee.org/oui/oui.txt

--
Richard



Bug#1004708: ITP: primecountpy -- Python interface to primecount

2022-01-31 Thread Tobias Hansen
Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Tobias Hansen 
Severity: wishlist

* Package name: primecountpy
  Version : 0.1.0
  Upstream Author : Dima Pasechnik 
* URL : https://github.com/dimpase/primecountpy
* License : GPL
  Programming Lang: Python
  Description : Python interface to primecount

This is a Cython interface to the C++ library primecount.

It is a dependency of sagemath >= 9.5. I am planning to maintain it within the
Debian Math Team.



Bug#990855: sudo: enable python plugin support

2022-01-31 Thread Michael Prokop
* Marc Haber [Mon Jan 31, 2022 at 09:14:07PM +0100]:
> On Fri, Jul 09, 2021 at 03:04:09PM +0200, Michael Prokop wrote:

> > since sudo v1.9.0 it's possible to write sudo plugins in Python 3,
> > see e.g. https://blog.sudo.ws/posts/2020/01/whats-new-in-sudo-1.9-python/
> > 
> > This requires to build the package with --enable-python though,
> > to provide the according python_plugin.so.

> I'd like to give this a shot, at least for experimental. Do you have an
> example plugin that I could try and probably even base an autopkgtest
> on, maybe with some explanation how I would use it?

Well, there's an example available at
https://www.sudo.ws/posts/2020/01/whats-new-in-sudo-1.9-python/
that should work?

regards
-mika-


signature.asc
Description: PGP signature


Bug#1004687: systemd: When NFS filesystems are mounted, systemctl actions (ex: daemon-reload) are exceedingly slow

2022-01-31 Thread Michael Biebl

Control: tags -1 moreinfo unreproducible

Am 31.01.22 um 20:15 schrieb Brandon Applegate:

Package: systemd
Version: 247.3-6
Severity: normal

Dear Maintainer,

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

* What led up to the situation?

Installed fresh Bullseye (amd64).  At some point experienced extreme 
delay with systemctl operations.

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

Increased systemd log level to debug.  Through trial and error 
determined unmounting all NFS alleviates this condition.

* What was the outcome of this action?

"systemctl daemon-reload" can now be ran normally with no delay.



This sounds like an issue with your NFS setup.
Calling systemctl will cause NFS mounts to be stated, but that shouldn't 
take too long.

In a test bed here I couldn't reproduce the problem.
Thus marking accordingly.

Please provide more information how this issue can be reproduced.


Michael





OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004707: hydra: FTBFS against openssl 3.0

2022-01-31 Thread Dan Bungert
Package: hydra
Version: 9.2-1
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Dear Maintainer,

This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1959622

Hydra will FTBFS when building against openssl 3.0 for want of a INT_MAX
definition.  I confirmed this in a sid container with openssl from
experimental.

In file included from hydra-mod.c:8:
/usr/include/openssl/err.h: In function ‘ERR_GET_LIB’:
/usr/include/openssl/err.h:243:9: error: ‘INT_MAX’ undeclared
(first use in this function)
243 | if (ERR_SYSTEM_ERROR(errcode))
/usr/include/openssl/err.h:31:1: note: ‘INT_MAX’ is defined in header
‘’; did you forget to ‘#include ’?

limits.h does get included, but a conflict between the hydra configure file and
the de-facto package layout of libmemcached-dev means that the wrong limits.h
file, then one from memcached, is included.

Also sent upstream - https://github.com/vanhauser-thc/thc-hydra/pull/718

See attached patch.

-Dan
diff -Nru hydra-9.2/debian/patches/10_memcached_include.diff 
hydra-9.2/debian/patches/10_memcached_include.diff
--- hydra-9.2/debian/patches/10_memcached_include.diff  1969-12-31 
17:00:00.0 -0700
+++ hydra-9.2/debian/patches/10_memcached_include.diff  2022-01-31 
14:45:37.0 -0700
@@ -0,0 +1,28 @@
+Description: Adjust memcached include dir lookup to not shadow limits.h
+ Compilation against openssl 3.0 causes a failure to find INT_MAX, despite the
+ openssl headers including limits.h.  However, the fact that the
+ libmemcached-dev package provides both /usr/include/libmemcached{,-1.0}
+ directories, both of which contain memcached.h, mean that MCACHED_IPATH ends
+ up set to the libmemcached-1.0 one, which contains a limits.h, which shadows
+ /usr/include/limits.h.
+ Don't do that.
+Author: Dan Bungert 
+Bug-Ubuntu: https://launchpad.net/bugs/1959622
+Forwarded: https://github.com/vanhauser-thc/thc-hydra/pull/718
+Last-Update: 2022-01-31
+--- a/configure
 b/configure
+@@ -998,11 +998,9 @@
+ if [ "X" = "X$MCACHED_IPATH" ]; then
+ if [ -f "$i/memcached.h" ]; then
+ MCACHED_IPATH="$i"
+-fi
+-if [ -f "$i/libmemcached/memcached.h" ]; then
++elif [ -f "$i/libmemcached/memcached.h" ]; then
+ MCACHED_IPATH="$i/libmemcached"
+-fi
+-if [ -f "$i/libmemcached-1.0/memcached.h" ]; then
++elif [ -f "$i/libmemcached-1.0/memcached.h" ]; then
+ MCACHED_IPATH="$i/libmemcached-1.0"
+ fi
+ fi
diff -Nru hydra-9.2/debian/patches/series hydra-9.2/debian/patches/series
--- hydra-9.2/debian/patches/series 2021-11-12 17:52:58.0 -0700
+++ hydra-9.2/debian/patches/series 2022-01-31 14:02:53.0 -0700
@@ -5,3 +5,4 @@
 03_use_bin_path.diff
 06_show_xhydra_build_output.diff
 07_remove_troubled_files.diff
+10_memcached_include.diff


Bug#1004705: qtfeedback: contains flawed auto-generated cmake config file

2022-01-31 Thread Mike Gabriel
Control: retitle -1 qtfeedback: contains flawed auto-generated cmake config file
Control: reassing -1 src:qtfeedback-opensource-src

Re-assigning to qtfeedback-opensource-src. The fix is to remove
/usr/lib/*/cmake/Qt5Feedback/Qt5Feedback_.cmake.

Mike

-- 

mike gabriel aka sunweaver (Debian Developer)
fon: +49 (1520) 1976 148

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



signature.asc
Description: PGP signature


Bug#1004557: man-db: please make index.db installations reproducible

2022-01-31 Thread Johannes Schauer Marin Rodrigues
Quoting Johannes Schauer Marin Rodrigues (2022-01-31 22:23:53)
> I talked with Guillem about the possibility of changing update-alternatives
> to produce reproducible mtimes. I'm adding debian-d...@lists.debian.org to
> discuss having a reproducible index.db by changing unattended-upgrades.
> 
> Reading the commit you quote above it seems that using the symlink's mtime is
> on purpose? I think the problem would not exist if the mtime of the link 
> target
> would be used. But there is probably a reason why this is not done already?
> 
> Guillem also brought up that using SOURCE_DATE_EPOCH is wrong in this context
> because this is about runtime behaviour. I disagree with that assessment. The
> idea would be to check whether SOURCE_DATE_EPOCH is set in unattended-upgrades
> and only if it is, then change its behaviour. That means that the current
> behaviour of unattended-upgrades would be unchanged without SOURCE_DATE_EPOCH
> set. Only when building something that needs to be reproducible like a chroot
> tarball or system image, SOURCE_DATE_EPOCH would be set. Since building a
> chroot tarball or system images is essentially compiling a final artifact from
> some other input I think this is completely in line with the idea that
> SOURCE_DATE_EPOCH is there to allow creating reproducible build output. In 
> that
> sense, unattended-upgrades would be in line with many other tools that respect
> SOURCE_DATE_EPOCH and thus differentiate between the scenario where they are
> used in the context of some build process (here: creating a chroot tarball) or
> normal operation. I don't think that it makes a difference that the input to
> the build process here are binary packages and not sources. During normal
> package building, build dependencies also do not always provide some human
> readable source that is then recompiled but also just binary material that is
> then integrated into the final build output.
> 
> Guillem was thinking about introducing a new variable in addition to
> SOURCE_DATE_EPOCH to indicate that some software should produce reproducible
> output in scenarios like this. This would mean that software that already
> supports SOURCE_DATE_EPOCH and is called by maintainer scripts now has to be
> patched to do the special casing for SOURCE_DATE_EPOCH as well as for the new
> variable. I also don't think a new variable is a good idea because I think 
> that
> building a reproducible chroot tarball can be well described as some sort of
> build process for which SOURCE_DATE_EPOCH makes perfect sense.
> 
> We also thought about letting unattended-upgrades use the mtime of the symlink
> target as the mtime of the symlink. But this would be a bad idea because 
> backup
> software will likely not notice a change of the symlink in case the symlink
> switches to a target with a lower mtime.

And of course all mentions of unattended-upgrades above should've been
update-alternatives instead. Sorry for that.

signature.asc
Description: signature


Bug#1004706: opentsne: FTBFS on i386, test failure

2022-01-31 Thread Graham Inggs
Source: opentsne
Version: 0.6.1-2
Severity: serious
Tags: ftbfs

Hi Maintainer

opentsne FTBFS on i386 [1] and this currently blocks migration to
testing. I've copied what I hope is the relevant part of the log
below.

Regards
Graham


[1] https://buildd.debian.org/status/logs.php?pkg=opentsne&arch=i386


=== FAILURES ===
_ TestTSNECorrectnessUsingPrecomputedDistanceMatrix.test_iris __

self = 

def test_iris(self):
x = datasets.load_iris().data
x += np.random.normal(0, 1e-3, x.shape)  # iris contains duplicate rows

distances = squareform(pdist(x))
params = dict(initialization="random", random_state=0)
embedding1 = TSNE(metric="precomputed", **params).fit(distances)
embedding2 = TSNE(metric="euclidean", **params).fit(x)

>   np.testing.assert_almost_equal(embedding1, embedding2)
E   AssertionError:
E   Arrays are not almost equal to 7 decimals
E
E   Mismatched elements: 300 / 300 (100%)
E   Max absolute difference: 3.4794089
E   Max relative difference: 19.31117662
Ex: TSNEEmbedding([[ -8.8343696,  14.5389743],
E  [ -6.5431559,  15.9090961],
E  [ -7.3407737,  16.6576344],...
Ey: TSNEEmbedding([[ -8.8276681,  14.0647152],
E  [ -6.1690237,  14.5453917],
E  [ -6.8637968,  15.4036782],...

tests/test_correctness.py:299: AssertionError
=== short test summary info 
FAILED 
tests/test_correctness.py::TestTSNECorrectnessUsingPrecomputedDistanceMatrix::test_iris



Bug#1004557: man-db: please make index.db installations reproducible

2022-01-31 Thread Johannes Schauer Marin Rodrigues
Quoting Colin Watson (2022-01-31 03:28:07)
> > But if that's the wrong approach, lets think of the alternative: making
> > sure that the mtimes of manual pages is reproducible. If I use gdbm_dump on
> > the index.db of two different chroots, then it looks like the following
> > manual pages have differing timestamps:
> > 
> > bash-builtins, which, dash, mawk, pager, awk, sh, more, nawk, builtins
> > 
> > Most of those seem to be symlinks into /etc/alternatives and those symlinks 
> > get
> > created by maintainer scripts using update-alternatives. Are you suggesting
> > that update-alternatives should gain support for setting the mtime of the 
> > files
> > it creates to SOURCE_DATE_EPOCH?
> 
> I think that would at least be worth considering.  It doesn't seem any
> less obvious a thing to do for reproducible installs than hacking mandb
> would be, and it would deal with the problem closer to its source: for
> instance, it would get you closer to being able to produce
> bitwise-identical reproducible images by e.g. tarring up the filesystem,
> which would preserve filesystem mtimes in the image.  (Though I guess
> --clamp-mtime deals with that, but maybe not all image archiving tools
> have something like that?)

I don't think we will ever not need --clamp-mtime when producing reproducible
chroot tarballs. It would mean that every maintainer script would have to be
extended so that every time after a file is created or changed its mtime is
adjusted. I don't think that can fly.

> Another approach might be to modify filesystem timestamps after postinsts
> have finished running but before mandb runs to clamp timestamps to
> SOURCE_DATE_EPOCH; a bit like your proposed patch, but actually modifying the
> filesystem timestamps as well.  I'm not sure where that could go, though.  It
> can't be in mandb because the postinst deliberately doesn't run mandb as
> root; and of course mandb is itself run from a postinst.  Maybe some kind of
> dpkg hook, or maybe it would be simplest to just run a post-processing step
> that clamps all the filesystem timestamps and then runs the equivalent of
> "sudo -u man mandb -cq"?  (This might be more palatable with man-db 2.10.0,
> where this will take more like 10 seconds rather than several minutes; see
> #1003089.)

I don't like the idea of moving functionality like that into chroot-creating
scripts. If we want the chroot to have a certain property, we should add that
to the packages involved using declarative methods.

So another way to fix this would be to add a "touch" call to every maintainer
script calling update-alternatives involving man pages and let them set the
symlink mtime to SOURCE_DATE_EPOCH if that variable is set. But I think that's
a bad idea and we should rather do this centrally.

> > I'm puzzled by bash-builtins though because that one is not a symlink. So I
> > don't understand why the timestamp differs there.
> 
> This puzzled me for a while too, but it's because
> /usr/share/man/man7/builtins.7.gz is a symlink created by
> update-alternatives and references bash-builtins in its NAME, which
> provoked https://bugs.debian.org/691643.  I've now fixed that upstream:
> 
>   
> https://gitlab.com/cjwatson/man-db/-/commit/37ab864354c1d0ac09e27d2346a1221bf4628509
> 
> This may cause your comparisons to show more differences, but it should
> mean that they're more reliably the *same* differences.  Previously, the
> behaviour depended on directory iteration order (actually usually the
> location of the first physical extent of each file on disk, since mandb sorts
> by that for improved performance on rotational disk drives).

Thanks for the fix!

I talked with Guillem about the possibility of changing update-alternatives to
produce reproducible mtimes. I'm adding debian-d...@lists.debian.org to discuss
having a reproducible index.db by changing unattended-upgrades.

Reading the commit you quote above it seems that using the symlink's mtime is
on purpose? I think the problem would not exist if the mtime of the link target
would be used. But there is probably a reason why this is not done already?

Guillem also brought up that using SOURCE_DATE_EPOCH is wrong in this context
because this is about runtime behaviour. I disagree with that assessment. The
idea would be to check whether SOURCE_DATE_EPOCH is set in unattended-upgrades
and only if it is, then change its behaviour. That means that the current
behaviour of unattended-upgrades would be unchanged without SOURCE_DATE_EPOCH
set. Only when building something that needs to be reproducible like a chroot
tarball or system image, SOURCE_DATE_EPOCH would be set. Since building a
chroot tarball or system images is essentially compiling a final artifact from
some other input I think this is completely in line with the idea that
SOURCE_DATE_EPOCH is there to allow creating reproducible build output. In that
sense, unattended-upgrades would be in line with many other tools that respect
SOURCE_DATE_EPOCH and thus differenti

Bug#1004704: socat: spurious backslashes in man page references

2022-01-31 Thread Jakub Wilk

Package: socat
Version: 2.0.0~beta9-1

The "SEE ALSO" section of the socat man page looks like this:

  nc\(1), netcat6\(1), sock\(1), ...

I don't think these backslashes should be there.

--
Jakub Wilk



Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-31 Thread Helmut Grohne
Hi Chris,

On Mon, Jan 31, 2022 at 09:39:40PM +0100, Chris Hofstaedtler wrote:
> * Helmut Grohne  [220131 17:09]:
> > > #966468 & #982944 asked for rename.ul to return (though the latter rather
> > > confuses the removal vs alternatives issue)
> > 
> > I think it is relatively uncontroversial to return rename.ul in some
> > non-essential form. Chris vaguely offered including it in bsdextrautils
> > (without a clear plan on how). How about adding rename as
> > /usr/bin/rename.ul to bsdextrautils without participating in
> > alternatives?
> > Would you, Chris, agree to that? I think doing so would
> > please some users and reduce the conflict.
> 
> With conflict I assume you mean the Conflicts relationship on the
> involved packages.

I see how you can come to this interpretation, but it is not what I
meant to say. It is true that the proposal avoids the need for a
Conflicts declaration on the package metadata level, but here I was
referring to the differing opinions on how util-linux' rename
implementation should be packaged as "conflict". My thinking was that by
providing the requested tool as an installable executable under some
(non-standard) path, you solve half of the practical problems.

> I believe we (as a distro) should make a choice what /usr/bin/rename
> should be, and ship -that-. Today this is prename, with an aborted
> effort to make rename.ul possible instead. Given this previous
> effort, and some earlier discussion here, I think it is valid to say
> "/usr/bin/rename should be rename.ul" - but then it should be that,
> and prename should be prename.
> Otherwise I would like to keep the status quo: our choice for
> /usr/bin/rename is prename.

Sure. I was aiming at an incremental improvement here. This is not all
black and white. Giving those who need util-linux' rename a way to
obtain it is half the story. Making it the default is a separate step.
Whether that step is to be taken is an interesting question, but I think
that those who are in favour of it, should present a transition plan to
debian-de...@lists.debian.org.

> I however believe that Debian should make choices, for our users and
> in their interest. Shipping both (or maybe all rename-like tools)
> and having that user-configurable is IMO not a good technical choice
> and IMO also not in the interest of the larger community.

I think there is a difference between making that choice prominent and
making it possible. For instance, I am in favour of removing the debconf
choice for /bin/sh. Doing so makes the choice for /bin/sh a lot less
prominent. I am not in favour of removing support for using dpkg-divert
to change what /bin/sh points to. A consequence of that is that if you
encounter a dashism in some shell script, that's still a bug. In that
regard, yes, Debian should make choices for defaults. At the same time,
it should not unnecessarily alienate people who think otherwise. If the
cost for that choice is deemed to high (or not covered by those who are
in favour of it), dropping the choice may become necessary. Given that
practically nothing in the Debian archive uses /usr/bin/rename, I think
that deferring the choice where it points to to users (in a
non-prominent way) is a reasonable thing to do, precisely because
/usr/bin/rename is presently not consistent accross different Linux
distributions.

> It appears "we" cannot make up our mind about this very small
> utility. Why should we delegate this to our users then? If they are
> interested, they will sink even more time into it and maybe create a
> configuration that possibly causes problems in the future.

I believe that those who exercise their choice are a very small
minority. The majority will stick with whatever Debian chooses.

A non-prominent choice would be dpkg-divert. As soon as bsdextrautils
ships rename.ul, anyone can use dpkg-divert to change /usr/bin/rename.
The only other piece is requiring that no package uses /usr/bin/rename.
That task can be deferred to choice-proponents by having them send
patches.

Does that make more sense to you now?

Helmut



Bug#1004703: ruby-pygments.rb: autopkgtest regression: No such file or directory

2022-01-31 Thread Paul Gevers

Source: ruby-pygments.rb
Version: 2.3.0+ds-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of ruby-pygments.rb the autopkgtest of 
ruby-pygments.rb fails in testing when that autopkgtest is run with the 
binary packages of ruby-pygments.rb from unstable. It passes when run 
with only packages from testing. It fails in the same way in a pure 
unstable environment, so it's not version skew. In tabular form:


   passfail
ruby-pygments.rb   from testing2.3.0+ds-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-pygments.rb

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-pygments.rb/18819910/log.gz


┌──┐
│ Checking Rubygems dependency resolution on ruby2.7 
   │

└──┘

GEM_PATH= ruby2.7 -e gem\ \"pygments.rb\"

┌──┐
│ Run tests for ruby2.7 from debian/ruby-tests.rake 
   │

└──┘

mv lib ./.gem2deb.lib
RUBYLIB=. GEM_PATH= ruby2.7 -S rake -f debian/ruby-tests.rake
/usr/bin/ruby2.7 -w -I"test" 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
"test/test_pygments.rb" -v
/tmp/autopkgtest-lxc.9r2fsd4_/downtmp/build.ktY/src/test/test_pygments.rb:13:in 
`read': No such file or directory @ rb_sysopen - 
/tmp/autopkgtest-lxc.9r2fsd4_/downtmp/build.ktY/src/test/../lib/pygments/mentos.py 
(Errno::ENOENT)
	from 
/tmp/autopkgtest-lxc.9r2fsd4_/downtmp/build.ktY/src/test/test_pygments.rb:13:in 
`'
	from 
/tmp/autopkgtest-lxc.9r2fsd4_/downtmp/build.ktY/src/test/test_pygments.rb:10:in 
`'
	from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in 
`require'
	from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in 
`require'
	from 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:21:in 
`block in '
	from 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in 
`select'
	from 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in 
`'

rake aborted!
Command failed with status (1): [ruby -w -I"test" 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
"test/test_pygments.rb" -v]
/usr/share/rubygems-integration/all/gems/rake-13.0.6/exe/rake:27:in 
`'

Tasks: TOP => default
(See full trace by running task with --trace)
mv ./.gem2deb.lib lib
autopkgtest [01:10:58]: test gem2deb-test-runner



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004702: libtorrent-rasterbar: b-d on python3-all-dev, but not built for all supported Python3 versions

2022-01-31 Thread Graham Inggs
Source: libtorrent-rasterbar
Version: 2.0.5-3
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10 python3-all-dev

Hi Maintainer

This package build-depends on python3-all-dev, but does not build
extensions/libraries for all supported python3 versions.  This is seen
on the transition tracker for adding python3.10 support [1] and
creates false positives.

Please either replace the b-d python3-all-dev with python3-dev, or
build for all supported Python3 versions.  With the former solution
yet get later exposure to a new python3 version, with the latter
solution you get early exposure.

Regards
Graham


[1] https://release.debian.org/transitions/html/python3.10-add.html



Bug#1004701: ima-evm-utils: Backport for bullseye

2022-01-31 Thread Bastian Germann

Source: ima-evm-utils
Version: 1.4-1.2
Severity: wishlist

Please provide a bullseye-backport for the current ima-evm-utils version, which has significant feature additions to 
1.1-1 in bullseye. I can offer to upload a backport (as you cannot upload to the NEW queue).




Bug#1004700: barcode man page: undocumented encoding types

2022-01-31 Thread Jakub Wilk

Package: barcode
Version: 0.99-5

The barcode manual page says:

To get a list of supported encoding type names, please call the program 
with "-h" option.


Please document the encoding types directly in the manual page.

--
Jakub Wilk



Bug#1004699: libdigest-bcrypt-perl breaks libdancer2-plugin-passphrase-perl autopkgtest: Bcrypt needs encoded text

2022-01-31 Thread Paul Gevers

Source: libdigest-bcrypt-perl, libdancer2-plugin-passphrase-perl
Control: found -1 libdigest-bcrypt-perl/1.212-1
Control: found -1 libdancer2-plugin-passphrase-perl/3.3.4-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of libdigest-bcrypt-perl the autopkgtest of 
libdancer2-plugin-passphrase-perl fails in testing when that autopkgtest 
is run with the binary packages of libdigest-bcrypt-perl from unstable. 
It passes when run with only packages from testing. In tabular form:


  passfail
libdigest-bcrypt-perl from testing1.212-1
libdancer2-plugin-passphrase-perl from testing3.3.4-1
all othersfrom testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of 
libdigest-bcrypt-perl to testing [1]. Due to the nature of this issue, I 
filed this bug report against both packages. Can you please investigate 
the situation and reassign the bug to the right package?


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

Paul

[1] https://qa.debian.org/excuses.php?package=libdigest-bcrypt-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/libd/libdancer2-plugin-passphrase-perl/18819128/log.gz

t/001_basics.t .. 1..1
ok 1 - use Dancer2::Plugin::Passphrase;
ok
t/003_default_settings.t  1..3
ok 1 - RFC compliant hash generated
ok 2 - Match plaintext to hash
ok 3 - Incorrect passwords should be rejected
ok
t/004_all_algorithm_matching.t .. 1..26
ok 1 - With Salt - Match plaintext to hash => MD5
ok 2 - With Salt - Incorrect passwords should be rejected => MD5
ok 3 - With Salt - Match plaintext to hash => SHA-1
ok 4 - With Salt - Incorrect passwords should be rejected => SHA-1
ok 5 - With Salt - Match plaintext to hash => SHA-224
ok 6 - With Salt - Incorrect passwords should be rejected => SHA-224
ok 7 - With Salt - Match plaintext to hash => SHA-256
ok 8 - With Salt - Incorrect passwords should be rejected => SHA-256
ok 9 - With Salt - Match plaintext to hash => SHA-384
ok 10 - With Salt - Incorrect passwords should be rejected => SHA-384
ok 11 - With Salt - Match plaintext to hash => SHA-512
ok 12 - With Salt - Incorrect passwords should be rejected => SHA-512
ok 13 - With Salt - Match plaintext to hash => Bcrypt
ok 14 - With Salt - Incorrect passwords should be rejected => Bcrypt
ok 15 - No Salt - Match plaintext to hash => MD5
ok 16 - No Salt - Incorrect passwords should be rejected => MD5
ok 17 - No Salt - Match plaintext to hash => SHA-1
ok 18 - No Salt - Incorrect passwords should be rejected => SHA-1
ok 19 - No Salt - Match plaintext to hash => SHA-224
ok 20 - No Salt - Incorrect passwords should be rejected => SHA-224
ok 21 - No Salt - Match plaintext to hash => SHA-256
ok 22 - No Salt - Incorrect passwords should be rejected => SHA-256
ok 23 - No Salt - Match plaintext to hash => SHA-384
ok 24 - No Salt - Incorrect passwords should be rejected => SHA-384
ok 25 - No Salt - Match plaintext to hash => SHA-512
ok 26 - No Salt - Incorrect passwords should be rejected => SHA-512
ok
t/005_random_passphrase.t ... 1..3
ok 1 - Basic password generation
ok 2 - Custom password length
ok 3 - Custom chracter set
ok
t/006_return_object.t ... 1..20
ok 1 - An object of class 'Dancer2::Plugin::Passphrase::Hashed' isa 
'Dancer2::Plugin::Passphrase::Hashed'

ok 2 - Contains RFC 2307 representation
ok 3 - Contains correct scheme
ok 4 - Contains correct cost
ok 5 - Contains raw salt
ok 6 - Contains hex hash
ok 7 - Contains base64 hash
ok 8 - Contains raw salt
ok 9 - Contains hex salt
ok 10 - Contains base64 salt
ok 11 - Contains correct plaintext
ok 12 - Extracted raw salt is the same as the defined raw salt
ok 13 - Extracted base64 salt is the same as the defined base64 salt
ok 14 - Extracted hex salt is the same as the defined hex salt
ok 15 - Extracted raw hash is the same as the defined raw hash
ok 16 - Extracted base64 hash is the same as the defined base64 hash
ok 17 - Extracted hex hash is the same as the defined hex hash
ok 18 - Contains a defined, but empty raw salt
ok 19 - Contains a defined, but empty hex salt
ok 20 - Contains a defined, but empty base64 salt
ok
t/007_no_salt.t . 1..2
ok 1 - Match plaintext to it's pre-computed hash
ok 2 - Match plaintext to it's generated hash
ok
t/008_unicode_matching.t  1..8
ok 1 - UTF8 matches UTF8 for SHA-1
ok 2 - SHA-1 needs encoded text
ok 3 - UTF8 matches UTF8 for SHA-256
ok 4 - SHA-256 needs encoded text
ok 5 - UTF8 matches UTF8 for MD5
ok 6 - MD5 needs encoded text
ok 7 - UTF8 matches UTF8 for Bcrypt
not ok 8 - Bcrypt needs encoded text

#   Failed test 'Bcrypt needs encoded text'
#   at t/

Bug#1004698: Package: stunnel4

2022-01-31 Thread Andreas Hasenack
Package: stunnel4
Version: 3:5.60+dfsg-1
Severity: normal

Dear Maintainer,

please consider updating stunnel to the latest upstream version, which
is 5.62 at the moment. Of note is that at least version 5.61 is
required to build with openssl 3, which is currently in Debian
Experimental.

Thanks!



Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-31 Thread Chris Hofstaedtler
Hello Helmut,

Thank you for the very detailed research (which I have removed
in my reply below).

* Helmut Grohne  [220131 17:09]:
> > #966468 & #982944 asked for rename.ul to return (though the latter rather
> > confuses the removal vs alternatives issue)
> 
> I think it is relatively uncontroversial to return rename.ul in some
> non-essential form. Chris vaguely offered including it in bsdextrautils
> (without a clear plan on how). How about adding rename as
> /usr/bin/rename.ul to bsdextrautils without participating in
> alternatives?
> Would you, Chris, agree to that? I think doing so would
> please some users and reduce the conflict.

With conflict I assume you mean the Conflicts relationship on the
involved packages.
>From a technical perspective: sure, that could be done. I also agree
it avoids new relationships on the involved packages.

> Those people could then ln -s
> /usr/bin/rename.ul /usr/local/bin/rename on their systems. It may not be
> as convenient as installing a package or using update-alternatives, but
> it isn't that hard either.

I believe we (as a distro) should make a choice what /usr/bin/rename
should be, and ship -that-. Today this is prename, with an aborted
effort to make rename.ul possible instead. Given this previous
effort, and some earlier discussion here, I think it is valid to say
"/usr/bin/rename should be rename.ul" - but then it should be that,
and prename should be prename.
Otherwise I would like to keep the status quo: our choice for
/usr/bin/rename is prename.

There are a number of very good "distribution builders" out there,
plus a number of distributions which seem to subscribe to "ship
everything that exists".
I however believe that Debian should make choices, for our users and
in their interest. Shipping both (or maybe all rename-like tools)
and having that user-configurable is IMO not a good technical choice
and IMO also not in the interest of the larger community.

It appears "we" cannot make up our mind about this very small
utility. Why should we delegate this to our users then? If they are
interested, they will sink even more time into it and maybe create a
configuration that possibly causes problems in the future.

Best,
Chris



Bug#1004697: bugs.debian.org: Desktop sometimes fails to respond after idling for long periods

2022-01-31 Thread Sebastian Crane
Package: bugs.debian.org
Severity: important

Dear Maintainer,

I am running a Debian 11 system that I installed on my desktop PC in
October 2021. On three occasions, all within the last month, I have
returned to my desktop after a couple of hours of it idling to find it
unresponsive. When this happens, my two displays cannot detect a signal
and do not find one after being restarted. USB power is still
operational, but peripherals are clearly not communicating with the PC -
the NumLock, CapsLock and ScrollLock status can not be changed and the
'magic' REISUB process doesn't work as it usually does. This issue isn't
related to suspend mode, which I have disabled.

The system is running conventional desktop software; the only 'unusual'
program that was running on all occasions was a Docker daemon.

Here's the output from Neofetch:

seabass@seabass-debian
--
OS: Debian GNU/Linux 11 (bullseye) x86_64
Kernel: 5.10.0-11-amd64
Uptime: 8 mins
Packages: 2843 (dpkg), 18 (flatpak)
Shell: bash 5.1.4
Resolution: 1920x1080, 1920x1080
DE: Xfce 4.16
WM: Xfwm4
WM Theme: Default
Theme: Adwaita [GTK2/3]
Terminal: xfce4-terminal
CPU: Intel i3-3220 (4) @ 3.300GHz
GPU: Intel HD Graphics
Memory: 1979MiB / 15701MiB

I had to force-restart the system by using the motherboard's power
button - explaining the low uptime listed in the data above!
Unfortunately, I cannot reproduce this bug.

Best wishes,

Sebastian



Bug#1004696: barcode man page: undocumented -p, -s

2022-01-31 Thread Jakub Wilk

Package: barcode
Version: 0.99-5

barcode's help message reads:

   -p  page size (refer to the man page)
   -s   streaming mode (refer to the man page)

But there's no additional information in the manual page, besides this:

"Please refer to texinfo doc for more information."

--
Jakub Wilk



Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long

2022-01-31 Thread Paul Gevers

Hi YunQiang,

On Sun, 12 Dec 2021 21:51:28 +0100 Paul Gevers  wrote:
Your package src:gcc-defaults-mipsen has been trying to 
migrate for 62 days [2]. Hence, I am filing this bug.


Any progress? It has been 1.5 months and I haven't seen anything 
happening. This is NOK. gcc-defaults-mipsen is a key package, so I can't 
just remove it. Please ensure the package can migrate. It seems to me 
that your failing to build all kind of required packages, although it's 
not clear if those should come from e.g. gcc-11 (which apparently 
started to build again itself on mipsel and mips64el. I'm not versed 
enough in how this piece of toolchain should work. If you need my help 
as a Release Team member, don't hesitate to reach out, but I don't want 
to spend time on reverse engineering this *.


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004695: stunnel4: DEP8 failure with python 3.10

2022-01-31 Thread Andreas Hasenack
Package: stunnel4
Version: 3:5.60+dfsg-1
Severity: normal

Dear Maintainer,

the upcoming python 3.10 deprecates SSL.PROTOCOL_TLS[1]:

Deprecated since version 3.10: TLS clients and servers require
different default settings for secure communication. The generic TLS
protocol constant is deprecated in favor of PROTOCOL_TLS_CLIENT and
PROTOCOL_TLS_SERVER.

This is used in debian/tests/python/struntime/__main__.py:437:[2]

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS)

With python3.10, the above line will cause this warning to be printed to stderr:

debian/tests/python/struntime/__main__.py:437: DeprecationWarning:
ssl.PROTOCOL_TLS is deprecated

Which will break the test since `allow-stderr` is not used.

We could, of course, allow stderr, but let's take the opportunity to
fix the warning and not use a deprecated value. Given the context,
this should probably be replaced with PROTOCOL_TLS_CLIENT, but that
brings in another change[3]:

...
The protocol enables CERT_REQUIRED and check_hostname by default.

Namely, the `check_hostname` bit being set to True. And that fails a
test a bit later:

Failed to connect to 127.0.0.1:6503: [SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed: IP address
mismatch, certificate is not valid for '127.0.0.1'. (_ssl.c:1129)

Since the test certificate only has a commonName of "localhost".

I propose:
a) this patch:
--- a/debian/tests/python/struntime/__main__.py
+++ b/debian/tests/python/struntime/__main__.py
@@ -434,7 +434,7 @@ async def test_connect(cfg: Config, conn:
TestConnection) -> None:
 try:
 if conn.encrypted:
 print(f"[{tag}] Creating an SSL context")
-ctx = ssl.SSLContext(ssl.PROTOCOL_TLS)
+ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
 print(f"[{tag}] - cert required")
 ctx.verify_mode = ssl.CERT_REQUIRED
 print(f"[{tag}] - load_verify_locations()")

b) regenerate the test certificate with an extra -addext
"subjectAltName = IP:127.0.0.1". Something like:

openssl req -new -x509 -days 3650 -nodes -out
debian/tests/certs/certificate.pem -keyout debian/tests/certs/key.pem
-addext "subjectAltName = IP:127.0.0.1"


Alternatively, one could set check_hostname to False in the ssl
context, restoring the behavior of the deprecated ssl.PROTOCOL_TLS
value.

Thanks for any comments, and please let me know if you would like to
have a salsa PR with the above.

Cheers!

1. https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS
2. 
https://salsa.debian.org/debian/stunnel/-/blob/master/debian/tests/python/struntime/__main__.py#L437
3. https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS_CLIENT



Bug#996414: python-fastimport: autopkgtest regression: 2 failures + lots of RuntimeError: maximum recursion depth exceeded

2022-01-31 Thread Paul Gevers

Hi Jelmer, all,

On Wed, 13 Oct 2021 21:30:36 +0200 Paul Gevers  wrote:

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


I see that pypy support was dropped, the offending test is when run with 
pypy and uses the dropped pypy-fastimport package. I believe it was just 
an oversight that the test wasn't dropped.


If nobody beats me to it, I'll upload an NMU dropping the pypy based 
autopkgtest in a couple of days.


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#334419: wish: "sudo -v command" feature

2022-01-31 Thread Marc Haber
On Wed, Oct 12, 2005 at 11:36:34PM -0700, Karl Chen wrote:
> Currently, "sudo -v" will check the timestamp, and prompt
> for the password if necessary.
> 
> I would like a command "sudo -v command" that will prompt
> for the password only if "sudo command" would prompt for the
> password.  I.e., if the user has NOPASSWD access to that
> command, just exit with a 0 return code without prompting.

Can you check whether the -l option will probably do what you intend to
do?

Greetings
Marc



Bug#990855: sudo: enable python plugin support

2022-01-31 Thread Marc Haber
Hi Mika,

On Fri, Jul 09, 2021 at 03:04:09PM +0200, Michael Prokop wrote:
> since sudo v1.9.0 it's possible to write sudo plugins in Python 3,
> see e.g. https://blog.sudo.ws/posts/2020/01/whats-new-in-sudo-1.9-python/
> 
> This requires to build the package with --enable-python though,
> to provide the according python_plugin.so.

I'd like to give this a shot, at least for experimental. Do you have an
example plugin that I could try and probably even base an autopkgtest
on, maybe with some explanation how I would use it?

Greetings
Marc



Bug#1004694: samba: CVE-2022-0336

2022-01-31 Thread Salvatore Bonaccorso
Source: samba
Version: 2:4.13.14+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14950
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.13.13+dfsg-1~deb11u2
Control: found -1 2:4.9.5+dfsg-5+deb10u2

Hi,

The following vulnerability was published for samba.

CVE-2022-0336[0]:
| Samba AD users with permission to write to an account can impersonate
| arbitrary services

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0336
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0336
[1] https://www.samba.org/samba/security/CVE-2022-0336.html
[2] https://bugzilla.samba.org/show_bug.cgi?id=14950

Regards,
Salvatore



Bug#1004693: samba: CVE-2021-44142

2022-01-31 Thread Salvatore Bonaccorso
Source: samba
Version: 2:4.13.14+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14914
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.13.13+dfsg-1~deb11u2
Control: found -1 2:4.9.5+dfsg-5+deb10u2

Hi,

The following vulnerability was published for samba.

CVE-2021-44142[0]:
| Out-of-bounds heap read/write vulnerability in VFS module vfs_fruit
| allows code execution

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-44142
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44142
[1] https://www.samba.org/samba/security/CVE-2021-44142.html
[2] https://bugzilla.samba.org/show_bug.cgi?id=14914

Regards,
Salvatore



Bug#1004692: samba: CVE-2021-44141

2022-01-31 Thread Salvatore Bonaccorso
Source: samba
Version: 2:4.13.14+dfsg-1
Severity: grave
Tags: security upstream
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14911
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.13.13+dfsg-1~deb11u2
Control: found -1 2:4.9.5+dfsg-5+deb10u2

The following vulnerability was published for samba.

CVE-2021-44141[0]:
| Information leak via symlinks of existance of files or directories
| outside of the exported share

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-44141
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44141
[1] https://www.samba.org/samba/security/CVE-2021-44141.html
[2] https://bugzilla.samba.org/show_bug.cgi?id=14911

Regards,
Salvatore



Bug#1004691: samba: CVE-2021-43566

2022-01-31 Thread Salvatore Bonaccorso
Source: samba
Version: 2:4.13.14+dfsg-1
Severity: grave
Tags: security upstream
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=13979
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.13.13+dfsg-1~deb11u2
Control: found -1 2:4.9.5+dfsg-5+deb10u2

Hi,

The following vulnerability was published for samba.

CVE-2021-43566[0]:
| All versions of Samba prior to 4.13.16 are vulnerable to a malicious
| client using an SMB1 or NFS race to allow a directory to be created in
| an area of the server file system not exported under the share
| definition. Note that SMB1 has to be enabled, or the share also
| available via NFS in order for this attack to succeed.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-43566
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43566
[1] https://www.samba.org/samba/security/CVE-2021-43566.html
[2] https://bugzilla.samba.org/show_bug.cgi?id=13979

Regards,
Salvatore



Bug#1004690: samba: CVE-2021-20316

2022-01-31 Thread Salvatore Bonaccorso
Source: samba
Version: 2:4.13.14+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14842
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.13.13+dfsg-1~deb11u2
Control: found -1 2:4.9.5+dfsg-5+deb10u2

Hi,

The following vulnerability was published for samba.

CVE-2021-20316[0]:
| Symlink race error can allow metadata read and modify outside of the
| exported share.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-20316
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20316
[1] https://www.samba.org/samba/security/CVE-2021-20316.html
[2] https://bugzilla.samba.org/show_bug.cgi?id=14842

Regards,
Salvatore



Bug#517979: xttitle: titles with umlauts or characters like É cannot be set

2022-01-31 Thread Paulo

Hi, in version 1.1~git20181024.b52256 the bug is fixed.

thanks


On Tue, 03 Mar 2009 11:57:46 +0100 "Axel K. Stammler" 
 wrote:

Package: xttitle
Version: 1.0-5
Severity: important

Even in a "uxterm" the title may only contain 7-bit ASCII characters and are 
cut off at
the first nonconformist character:

$ xttitle "RTÉ Radio 1"

displays only "RT" as the title.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24.4 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xttitle depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries

xttitle recommends no packages.

Versions of packages xttitle suggests:
ii  aterm-ml [x-terminal-em 1.0.1-4  Afterstep XVT - a VT102 emulator f
ii  eterm [x-terminal-emula 0.9.5-1  Enlightened Terminal Emulator
ii  gnome-terminal [x-termi 2.22.3-3 The GNOME 2 terminal emulator appl
ii  konsole [x-terminal-emu 4:3.5.9.dfsg.1-6 X terminal emulator for KDE
ii  kterm [x-terminal-emula 6.2.0-46 Multi-lingual terminal emulator fo
ii  mlterm [x-terminal-emul 2.9.4-5  MultiLingual TERMinal
ii  rxvt [x-terminal-emulat 1:2.6.4-14   VT102 terminal emulator for the X 
ii  rxvt-ml [x-terminal-emu 1:2.6.4-14   multi-lingual VT102 terminal emula
ii  wterm-ml [x-terminal-em 6.2.9-8  lightweight multilingual terminal 
ii  xterm [x-terminal-emula 235-2X terminal emulator


-- debconf-show failed





OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004689: xterm: CVE-2022-24130

2022-01-31 Thread Salvatore Bonaccorso
Source: xterm
Version: 370-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for xterm.

CVE-2022-24130[0]:
| xterm through Patch 370, when Sixel support is enabled, allows
| attackers to trigger a buffer overflow in set_sixel in
| graphics_sixel.c via crafted text.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24130
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24130
[1] https://www.openwall.com/lists/oss-security/2022/01/30/2
[3] https://www.openwall.com/lists/oss-security/2022/01/30/3

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#1004688: shadow: Improved version of manual page chfn

2022-01-31 Thread Markus Hiereth
Source: shadow
Version: 4.8.1
Severity: normal

Hi Serge,

attached here, the edited xml file of the manual page and a diff file. In
the first phrase of the description section I introduced/mentioned the
file /etc/passwd to help understanding why we refer to the input data
as "fields". I hope this is OK.

Best regards
Markus

---

"Serge E. Hallyn"  schrieb am 31. Januar 2022 um 05:03

> On Tue, Jan 25, 2022 at 03:47:09PM +0100, Markus Hiereth wrote:
> > Hi Serge,
> > 
> > attached four strings from chfn. There is one error, the others are
> > minor points where things could be improved when eliminating the error in 
> > the xml file for the manpage.
> > 
> > Best regards
> > Markus
> 
> > #MH111 As "real name" is only used once and even the command's description
> > #uses "full name" instead of "real name" and chfn focusses on the GECOS 
> > field:
> > s/real user name and information /full user name and other GECOS data
> 
> Good point, and switching 'real name' for 'full name' seems sensible
> given that 'chfn' (AFAIK) stands for 'change full name' :)
> 
> Many users won't know what GECOS means, so in the command's description
> I'd rather leave it as "and information".

OK


> > #MH170:
> > #Called by any user with the exeption of the system administrator, chfn 
> > expects
> > #authentification with the user's password, therefore: add somewhere 
> > #"A normal user needs to authentficate himself to change personal data."
> > #Called by the system administrator without specifying an account, changes 
> > affect his own account
> > #Called by the system adiminstrator and with a specified username, changes 
> > will affect this users account
> > #FIXME
> > #s/Without options, /Without LOGIN as argument.
> 
> I would prefer "If LOGIN is not specified,"

Just the phrase dealing with no LOGIN has gone up to the section DESCRIPTION


 
> > #MH
> > #move this paragraph which does not deal with options away from section
> > #OPTIONS towards section DESCRIPTION
> > #: chfn.1.xml:181(para)
> > msgid ""
> > "If none of the options are selected, chfn operates in 
> > an "
> > "interactive fashion, prompting the user with the current values for all of 
> > "
> > "the fields. Enter the new value to change the field, or leave the line 
> > blank "
> > "to use the current value. The current value is displayed between a pair of 
> > "
> > "[ ] marks. Without options, 
> > chfn > "command> prompts for the current user account."
> 
> If you move that, please make it "If no options are specified,"

The rest remained at place with no changes except starting for "If
none of the options IS selected ..." I assumed none needs singular
form of the verb.


http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [




]>

  
  

  Julianne Frances
  Haugh
  Creation, 1990


  Thomas
  Kłoczko
  kloc...@pld.org.pl
  shadow-utils maintainer, 2000 - 2007


  Nicolas
  François
  nicolas.franc...@centraliens.net
  shadow-utils maintainer, 2007 - now

  
  
chfn
1
User Commands
shadow-utils
&SHADOW_UTILS_VERSION;
  
  
chfn
change full user name and information
  

  

  chfn
  
options
  
  
LOGIN
  

  

  
DESCRIPTION

  The chfn command changes the user's full name,
  office room number, office phone number, and home phone number information
  for an account in the respective fields of 
/etc/passwd.
  This information is typically printed by
  
finger1
   and similar programs. A normal user may only change
  the fields for her own account, subject to the restrictions in
  /etc/login.defs. (The default configuration is to
  prevent users from changing their fullname.) The superuser may change
  any field for any account. Additionally, only the superuser may use
  the -o option to change the undefined portions of the
  GECOS field.



  These fields must not contain any colons. Except for the
  other field, they should not contain
  any comma or equal sign. It is also recommended to avoid
  non-US-ASCII characters, but this is only enforced for the phone
  numbers. The other field is used to
  store accounting information used by other applications.


  If LOGIN is not specified, 
chfn
  prompts for the current user account.

  

  
OPTIONS

  The options which apply to the chfn command are:


  

  -f, 
--full-name FULL_NAME


  Change the user's full name.

  
  

  -h, 
--home-phone HOME_PHONE


  Change the user's home phone number.

  
  

  -o, 
--other OTHER


  
Change the user's other GECOS information. This field is used to
store accounting information used by other applications, an

Bug#1004682: src:pure-ftpd: fails to migrate to testing for too long: uploader built arch:all binaries

2022-01-31 Thread Stefan Hornburg (Racke)

On 31/01/2022 19:39, Paul Gevers wrote:

Source: pure-ftpd
Version: 1.0.49-4.1
Severity: serious
Control: close -1 1.0.50-2
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing and 
unstable for more than 60 days as having a Release Critical bug in testing [1]. 
Your package src:pure-ftpd has been trying to migrate for 61 days [2]. Hence, I 
am filing this bug.

If a package is out of sync between unstable and testing for a longer period, 
this usually means that bugs in the package in testing cannot be fixed via 
unstable. Additionally, blocked packages can have impact on other packages, 
which makes preparing for the release more difficult. Finally, it often exposes 
issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that hamper the 
migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new bugs, 
there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if that 
version or a later version migrates, this bug will no longer affect testing. I 
have also tagged this bug to only affect sid and bookworm, so it doesn't affect 
(old-)stable.

Your package is only blocked because the arch:all binary package(s) aren't 
built on a buildd. Unfortunately the Debian infrastructure doesn't allow 
arch:all packages to be properly binNMU'ed. Hence, I will shortly do a 
no-changes source-only upload to DELAYED/15, closing this bug. Please let me 
know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=pure-ftpd



Hello Paul,

I will do a source-only upload in the next few days. Thanks for the report.

Regards
Racke


--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004686: broker: unnecessary X-Python3-Version field in control file

2022-01-31 Thread Julian Gilbey
Source: broker
Version: 1.4.0+ds1-1
Severity: normal
Tags: patch

This package has the line:

X-Python3-Version: ${python3:Versions}

in debian/control in the binary package python3-broker.  This is
unnecessary: the X-Python3-Version field only has meaning in the
source package section (and in this case, it is not needed there
either).

Patch: remove this line from debian/control.

Best wishes,

   Julian



Bug#1004658: [Pkg-javascript-devel] Bug#1004658: Bug#1004658: Help to compile a wasm package

2022-01-31 Thread Yadd

On 31/01/2022 19:23, Jonas Smedegaard wrote:

Quoting Jan Niehusmann (2022-01-31 18:01:58)

On Mon, Jan 31, 2022 at 05:29:23PM +0100, Geert Stappers wrote:

At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004658#35
is adviced:

   source-map-mappings should be packaged separately,
   and then build-depended on from package node-source-map.


Would this really solve the issue?


No.

But it would shift the issue from being handled as some asset needed by
a NodeJS module, to being handled as the primary prupose of a Rust
library.



The artifact needed by node-source-map is a WASM binary of
source_map_mappings_wasm_api. What kind of deb package would provide
that file?

The description of source-map-mappings says:
"This is intended to be compiled to WebAssembly and eventually used from
the mozilla/source-map library. This is not a general purpose source
maps library."

It seems to be a integral part of node-source-map, and only
distributed separately because it's written in a different language.

So I wonder if a debian package of source-map-mappings would be useful
at all.

Is this a good reason to include it in the debian source package of
node-source-map?


It might arguably be sensible to package both projects together, if done
in a way that ensured that both parts were treated carefully
(Debian-specific compiler options applied, Debian-specific install paths
used, Debian-specific test tricks applied, etc.).

So mybe if done by a maintainer knowledgeable on both NodeJS and
Rust and bold enough to invent some tooling to compete with pkg-js-tools
and debcargo (because at least debcargo is not fit for use outside the
Rust team).  Personally I do not recommend to reinvent CDBS...

...or that one single package could contain all the custom rules to
handle things correctly *without* custom tooling.  Then the maintainer
would need to keep track of what wisdom evolves in the related unused
tools and reimplement that for this one single package.


No need to do this, the only goal of source-map-mapping is to produce 
mapping.wasm which is then embedded in JS package (package isn't publish 
anywhere else). The job is done (see debian/rules), we just have to find 
the good dependencies and fix the build since built wasm isn't exactly 
what upstream embeds in node-source-map, maybe some unpublished work...




Bug#1004685: openstructure: upgrade failed

2022-01-31 Thread Patrice DUROUX
Package: openstructure
Version: 2.3.1-1
Severity: normal

Dear Maintainer,

Here is what I am facing:

Setting up openstructure (2.3.1-1) ...
dpkg: error processing package openstructure (--configure):
 installed openstructure package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 openstructure
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Thanks,
Patrice

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

Kernel: Linux 5.14.0-1-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 openstructure depends on:
ii  libboost-filesystem1.74.0   1.74.0-14
ii  libboost-iostreams1.74.01.74.0-14
ii  libboost-program-options1.74.0  1.74.0-14
ii  libc6   2.33-5
ii  libgcc-s1   11.2.0-14
ii  libost-base2.3  2.3.1-1
ii  libost-conop2.3 2.3.1-1
ii  libost-gui2.3   2.3.1-1
ii  libost-io2.32.3.1-1
ii  libost-mol-alg2.3   2.3.1-1
ii  libost-mol2.3   2.3.1-1
ii  libpython3.93.9.10-1
ii  libqt5core5a5.15.2+dfsg-14
ii  libqt5gui5  5.15.2+dfsg-14
ii  libqt5widgets5  5.15.2+dfsg-14
ii  libstdc++6  11.2.0-14
ii  python3 3.9.8-1
ii  python3-ost 2.3.1-1

openstructure recommends no packages.

openstructure suggests no packages.

-- no debconf information



Bug#1004524: Fwd: Bug#1004524: additional logs

2022-01-31 Thread Kamil Jońca
David Bauer  writes:

> Hi Andrej
>
> On 1/31/22 18:49, Andrej Shadura wrote:
>> Hi,
>> I have received this bug report for wpa-supplicant 2.10.
>
> Please see this thread [0] and this patch. [1]
>
> [0] http://lists.infradead.org/pipermail/hostap/2022-January/040178.html
> [1] http://lists.infradead.org/pipermail/hostap/2022-January/040185.html
>
> Best
> David
>

Thanks. I can confirm that after applied changes from [1] recompiled 
wpa_supplicant
started to work.

KJ


-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html



Bug#1004684: src:ddnet: fails to migrate to testing for too long: FTBFS on armel and mipsel

2022-01-31 Thread Paul Gevers

Source: ddnet
Version: 15.6.2-1
Severity: serious
Control: close -1 15.8.1-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ddnet has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package fails to build from 
source on armel and mipsel built there in the past. The error seems to 
be: undefined reference to `__atomic_store_8', which I recollect from 
having seen before in other packages recently so might be a toolchain 
change than requires explicit linking to atomic or something.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=ddnet



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004683: gcc-12: cross-no-locale-include.diff no longer applies

2022-01-31 Thread Helmut Grohne
Source: gcc-12
Version: 12-20220126-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

cross-no-locale-include.diff no longer applies, because the target file
cppdefault.c was renamed to cppdefault.cc. This is easily fixed:

sed -i -e 's/cppdefault\.c/&c/' debian/patches/cross-no-locale-include.diff

Helmut



Bug#1004682: src:pure-ftpd: fails to migrate to testing for too long: uploader built arch:all binaries

2022-01-31 Thread Paul Gevers

Source: pure-ftpd
Version: 1.0.49-4.1
Severity: serious
Control: close -1 1.0.50-2
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:pure-ftpd has been trying to migrate for 
61 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=pure-ftpd



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004522: debian-policy: Proposing new virtual package: wayland-session

2022-01-31 Thread Andrei POPESCU
On Lu, 31 ian 22, 10:57:04, Stephan Lachnit wrote:
> On Mon, Jan 31, 2022 at 10:38 AM Bill Allombert  wrote:
> >
> > On Mon, Jan 31, 2022 at 10:13:19AM +0100, Stephan Lachnit wrote:
> > >
> > > Actually, just out of curiosity: the folder is called
> > > "wayland-sessions", but the files are all called "*.desktop". Are
> > > there other possibilities than "*.desktop", and if so what is the
> > > difference?
> >
> > .desktop is just a standard file format used to register applications
> > with desktop environment, see
> > 
> 
> Ah thanks! I somehow didn't expect it to be the same as the usual
> .desktop file format as for applications.
> 
> Then I agree on the "wayland-session" name. But maybe the description
> should remove the word "desktop" then.

Well, a more generic option would be "Wayland graphical session", though
it's a bit of a tautology :)

Would "Graphical session using the Wayland display protocol" be too
long?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Bug#1004658: [Pkg-javascript-devel] Bug#1004658: Help to compile a wasm package

2022-01-31 Thread Jonas Smedegaard
Quoting Jan Niehusmann (2022-01-31 18:01:58)
> On Mon, Jan 31, 2022 at 05:29:23PM +0100, Geert Stappers wrote:
> > At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004658#35
> > is adviced:
> > 
> >   source-map-mappings should be packaged separately,
> >   and then build-depended on from package node-source-map.
> 
> Would this really solve the issue?

No.

But it would shift the issue from being handled as some asset needed by 
a NodeJS module, to being handled as the primary prupose of a Rust 
library.


> The artifact needed by node-source-map is a WASM binary of
> source_map_mappings_wasm_api. What kind of deb package would provide
> that file?
> 
> The description of source-map-mappings says:
> "This is intended to be compiled to WebAssembly and eventually used from
> the mozilla/source-map library. This is not a general purpose source
> maps library."
> 
> It seems to be a integral part of node-source-map, and only
> distributed separately because it's written in a different language.
> 
> So I wonder if a debian package of source-map-mappings would be useful 
> at all.
> 
> Is this a good reason to include it in the debian source package of 
> node-source-map?

It might arguably be sensible to package both projects together, if done 
in a way that ensured that both parts were treated carefully 
(Debian-specific compiler options applied, Debian-specific install paths 
used, Debian-specific test tricks applied, etc.).

So mybe if done by a maintainer knowledgeable on both NodeJS and 
Rust and bold enough to invent some tooling to compete with pkg-js-tools 
and debcargo (because at least debcargo is not fit for use outside the 
Rust team).  Personally I do not recommend to reinvent CDBS...

...or that one single package could contain all the custom rules to 
handle things correctly *without* custom tooling.  Then the maintainer 
would need to keep track of what wisdom evolves in the related unused 
tools and reimplement that for this one single package.

Simpler and easier maintainable is to not do such custom hack but 
maintain a NodeJS package and a Rust library package as two separate 
things, using separate tooling.  It is hard enough to link the Rust 
library with the NodeJS code without dealing with the tedious common 
parts of integrating the Rust library with Debian 
libraries-are-in-shared-locations-not-on-the-web structure.

See also Debian Policy § 4.13: 
https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies


 - 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#1004680: upgrade-reports: beep when selecting logout

2022-01-31 Thread Paul Gevers

Control: tags -1 moreinfo

Dear Roger,

On 31-01-2022 18:50, Roger wrote:

My previous release was: Buster
I upgraded to: Bullseye
Archive date: 
Upgrade date: January 2022
uname -a before upgrade: 
uname -a after upgrade: Linux Roger 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1
(2021-12-08) x86_64 GNU/Linux
Method: I edited the sources lists and used sudo apt.

Contents of /etc/apt/sources.list:
deb http://ftp.us.debian.org/debian/ bullseye main contrib non-free
deb http://security.debian.org/ bullseye-security contrib non-free main
deb http://ftp.us.debian.org/debian/ bullseye-updates contrib non-free main
# deb
http://ftp.ca.debian.org/debian/pool/main/k/keepassxc/keepassxc_2.6.6+dfsg.1-1_amd64.deb
bullseye main


- Were there any non-Debian packages installed before the upgrade?  If
   so, what were they? Yes, but unknown.

- Was the system pre-update a pure sarge system? If not, which packages
   were not from sarge?  It was a Buster system.

- Did any packages fail to upgrade?  Not that I know of.

- Were there any problems with the system after upgrading?  Not that I know of.


I'm failing to see what upgrade problem you are reporting. What is it 
that you think is going wrong during the upgrade?


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#964199: nsjail: Package ready for review/submission

2022-01-31 Thread Russell Hernandez Ruiz
Howdy, I created a package for `nsjail`, then noticed it's already been
worked on, but this bug has been open a while. There any way I can help?
Or I'm happy to take over as well.

Thanks.



Bug#1003899: wavemon: New upstream release (v0.9.4, 2021 Sep 18)

2022-01-31 Thread Samuel Henrique
Hello Jonathan,

I have interest in the wavemon package, as I use the scan mode a lot.

I would like to co-maintain the package with you, put it under a team, or
take over the maintenance , also putting it over a team (if you don't want
to keep maintaining it).

This new release is a good opportunity to upload the packaging to salsa as
well.

Please let me know what you think about this, in the case of no response I
will go ahead and add myself as an Uploader (without removing you) and push
the new release.

Thank you,

-- 
Samuel Henrique 


Bug#1003969: sudo: FQDN option not overridable early on.

2022-01-31 Thread Sven Mueller
Hi Marc.

Any chance of an upload of a new sudo package any time soon, so that
the fix to this bug is available?

I would love to upgrade from 1.9.5 to >=1.9.8 because of some of the
fixes, but currently can't due to the issue in this bug.
I saw that you updated the repo on alioth to 1.9.9, which means the
patch I mentioned before has been integrated.

Cheers,
Sven

Am Sa., 22. Jan. 2022 um 16:13 Uhr schrieb Marc Haber
:
>
> tags 1003969 confirmed pending - patch
> thanks
>
> On Wed, Jan 19, 2022 at 01:29:19PM +0100, Sven Mueller wrote:
> > Tags 1003969 + fixed-upstream patch confirmed
>
> Only the package maintainer should set the "confirmed" tag. Please
> refrain from doing this in the future. See
> https://www.debian.org/Bugs/Developer
>
> > https://www.sudo.ws/repos/sudo/rev/8c6eaa503793 has the upstream patch.
>
> Thanks for spotting this. I have written an autopkgtest that fails
> without this patch and succeeds with this patch, and have pushed both
> the test and the fix. Will be in the next package.
>
> 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#1004681: ITP: wcag-contrast-ratio -- Library computing contrast ratios required by WCAG 2.0

2022-01-31 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: wcag-contrast-ratio
  Version : 0.9
  Upstream Author : Geoffrey Sneddon 
* URL : https://github.com/gsnedders/wcag-contrast-ratio
* License : MIT
  Programming Lang: Python
  Description : Library computing contrast ratios required by WCAG 2.0

 This package provides a Python library that calculates the contrast ratio of
 colors based on the Web Content Accessibility Guidelines (WCAG) 2 standard,
 published by the Web Accessibility Initiative (WAI). The actual WCAG technical
 documents are created by the Accessibility Guidelines Working Group (AG WG),
 which are part of the WAI.
 .
 This library also provides some checking if contrast meets the required level.

This packge is a new build dependency for recent versions of pygments.

It will be maintained within the Python Team.



Bug#1004524: Fwd: Bug#1004524: additional logs

2022-01-31 Thread Andrej Shadura
Hi,

I have received this bug report for wpa-supplicant 2.10.

-- 
Cheers,
  Andrej

- Original message -
From: Kamil Jonca 
To: Debian Bug Tracking System 
Subject: Bug#1004524: wpasupplicant: After upgrading cannot connect to wifi
Date: Saturday, 29 January 2022 22:18

Package: wpasupplicant
Version: 2:2.10-1
Severity: important
X-Debbugs-Cc: kjo...@poczta.onet.pl

I have upgraded some packages on my laptop with

24:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43228 
802.11a/b/g/n

controller. After I was not able to up wlan interface and in logs I have 
entries like:

=
2022-01-29T21:54:57.996370+01:00 bambus wpa_supplicant[22258]: wlan0: 
CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
=
When I downgrade to 2:2.9.0-22+b1 (and only this package was downgraded)
everything started to work.


(I make this report on different machine that wpasupplicant is installed)
some info below.

~%uname -a
Linux bambus 5.15.0-3-amd64 #1 SMP Debian 5.15.15-1 (2022-01-18) x86_64 
GNU/Linux

%dpkg -l broadcom-sta-dkms
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture Description
+++-=-===--
ii  broadcom-sta-dkms 6.30.223.271-17 all  dkms source for the Broadcom 
STA Wireless driver

- Original message -
From: kjo...@poczta.onet.pl
To: "1004...@bugs.debian.org" <1004...@bugs.debian.org>
Subject: Bug#1004524: additional logs
Date: Monday, 31 January 2022 18:33

Sorry, but I use (now deprecated) method with /etc/network/interfaces
I added -dd to wpa supplicant and extracted wpa_supllicant log from 
syslog
 
grep 36696 /var/log/syslog|gzip -9v - > /tmp/wpa.wlan0.gz
 
result are in attachment.
Hope this is enough.
Another thing  I forgot to mention.
When I use usb card based on "Qualcomm Atheros Communications AR9271 802.11n"  
this work flawelessly regardless of wpa_supplicant version.


wpa.wlan0.gz
Description: application/gzip


Bug#1004524: Fwd: Bug#1004524: additional logs

2022-01-31 Thread Andrej Shadura
Hi,

I have received this bug report for wpa-supplicant 2.10.

-- 
Cheers,
  Andrej

- Original message -
From: Kamil Jonca 
To: Debian Bug Tracking System 
Subject: Bug#1004524: wpasupplicant: After upgrading cannot connect to wifi
Date: Saturday, 29 January 2022 22:18

Package: wpasupplicant
Version: 2:2.10-1
Severity: important
X-Debbugs-Cc: kjo...@poczta.onet.pl

I have upgraded some packages on my laptop with

24:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43228 
802.11a/b/g/n

controller. After I was not able to up wlan interface and in logs I have 
entries like:

=
2022-01-29T21:54:57.996370+01:00 bambus wpa_supplicant[22258]: wlan0: 
CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
=
When I downgrade to 2:2.9.0-22+b1 (and only this package was downgraded)
everything started to work.


(I make this report on different machine that wpasupplicant is installed)
some info below.

~%uname -a
Linux bambus 5.15.0-3-amd64 #1 SMP Debian 5.15.15-1 (2022-01-18) x86_64 
GNU/Linux

%dpkg -l broadcom-sta-dkms
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture Description
+++-=-===--
ii  broadcom-sta-dkms 6.30.223.271-17 all  dkms source for the Broadcom 
STA Wireless driver

- Original message -
From: kjo...@poczta.onet.pl
To: "1004...@bugs.debian.org" <1004...@bugs.debian.org>
Subject: Bug#1004524: additional logs
Date: Monday, 31 January 2022 18:33

Sorry, but I use (now deprecated) method with /etc/network/interfaces
I added -dd to wpa supplicant and extracted wpa_supllicant log from 
syslog
 
grep 36696 /var/log/syslog|gzip -9v - > /tmp/wpa.wlan0.gz
 
result are in attachment.
Hope this is enough.
Another thing  I forgot to mention.
When I use usb card based on "Qualcomm Atheros Communications AR9271 802.11n"  
this work flawelessly regardless of wpa_supplicant version.


wpa.wlan0.gz
Description: application/gzip


Bug#1004524: additional logs

2022-01-31 Thread kjonca
Sorry, but I use (now deprecated) method with /etc/network/interfaces
I added -dd to wpa supplicant and extracted wpa_supllicant log from 
syslog
 
grep 36696 /var/log/syslog|gzip -9v - > /tmp/wpa.wlan0.gz
 
result are in attachment.
Hope this is enough.
Another thing  I forgot to mention.
When I use usb card based on "Qualcomm Atheros Communications AR9271 802.11n"  
this work flawelessly regardless of wpa_supplicant version.

wpa.wlan0.gz
Description: application/gzip


Bug#859279: Updating the ygl Uploaders list

2022-01-31 Thread Mattia Rizzolo
On Mon, 31 Jan 2022, 6:02 pm Nilesh Patra,  wrote:

> Since this package was last uploaded in 2009 (~13 years ago) and the
> maintainer stated that they have no bandwidth to keep maintaining it
> plus Uploader has retired, and this had 3 RC bugs opened (for a long
> time), I fixed the RC bugs, and made the "Debian QA Team" as the package
> maintainer (effectively orphaning it) and did a upload for this package.
> The said bug that I am replying to right now has been open for 4+ years
> (almost 5) and hence from a pragmatic pov, I found it right to do.
>

Yes, this is perfectly fine, thank you.

Unless Kumar has plans of stepping in, do you think we should close this
> bug report too?
>

Rather, instead of closing it please reassign to wnpp and retitle it to
match the O bugs template title.


Bug#859279: Updating the ygl Uploaders list

2022-01-31 Thread Nilesh Patra

Hi Mattia, Kumar,

Kumar, would you have any plans to adopt this?

On Wed, 12 Apr 2017 09:27:20 +0200 Mattia Rizzolo  wrote:

On Wed, Apr 12, 2017 at 12:55:35PM +0530, Prabhu Ramachandran wrote:
> I am afraid I don't exactly know what to do or have the bandwidth for stepping
> in as a maintainer.  However, Kumar Appaiah (CC'd) said that he would be able 
to
> help.

Well, techinically you are already the maintainer.  From the current
package:

Source: ygl
Priority: extra
Maintainer: Prabhu Ramachandran  
Uploaders: Ramakrishnan Muthukrishnan 



In that case, probably this package should be orphaned instead?
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#orphaning


Since this package was last uploaded in 2009 (~13 years ago) and the 
maintainer stated that they have no bandwidth to keep maintaining it 
plus Uploader has retired, and this had 3 RC bugs opened (for a long 
time), I fixed the RC bugs, and made the "Debian QA Team" as the package 
maintainer (effectively orphaning it) and did a upload for this package.
The said bug that I am replying to right now has been open for 4+ years 
(almost 5) and hence from a pragmatic pov, I found it right to do.


Unless Kumar has plans of stepping in, do you think we should close this 
bug report too?


Let me know.

Regards,
Nilesh



Bug#1004679: [Pkg-deepin-devel] Bug#1004679: papirus-icon-theme 20220101-2 fails to install and hangs indefinitly

2022-01-31 Thread Boyuan Yang
Control: tags -1 +moreinfo +unreproducible
Control: severity -1 normal

I could not reproduce this issue. Depending on your computer's performance,
installation may take up to **one hour** due to icon cache refreshing. Please
try again and wait patiently. Please let me know if it does take more than one
hour, and also let me know your PC's model.

Thanks,
Boyuan Yang

在 2022-01-31星期一的 17:09 +0100,Michael Tatge写道:
> Package: papirus-icon-theme
> Version: 20220101-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
>    Trying to upgrade from 20220101-1 to 20220101-2
> 
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>    apt full-upgrade
> 
>    * What was the outcome of this action?
>    upgrade process hangs indefinitly an package
> 
>    * What outcome did you expect instead?
>    clean install
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages papirus-icon-theme depends on:
> ii  hicolor-icon-theme  0.17-2
> 
> papirus-icon-theme recommends no packages.
> 
> papirus-icon-theme suggests no packages.
> 
> -- no debconf information
> 
> ___
> Pkg-deepin-devel mailing list
> pkg-deepin-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-deepin-devel



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


Bug#1004658: Help to compile a wasm package

2022-01-31 Thread Geert Stappers
control: tag -1 -pending
I might be wrong about the removal of that tag, do feel free to re-add it.


On Mon, Jan 31, 2022 at 03:11:00PM +0100, Yadd wrote:
(fully quoted because I'm adding 1004...@bugs.debian.org to the loop)
> On 31/01/2022 15:00, Geert Stappers wrote:
> > On Mon, Jan 31, 2022 at 01:09:43PM +0100, Yadd wrote:
> > > Hi all,
> > > 
> > > to update a nodejs package,
> > 
> > Which package is that? Please provide an URL.
> 
> Hi
> 
> thanks for your answer. Here is the working package:
> https://salsa.debian.org/js-team/node-source-map
> 
> (embedded component source-map-mappings)

At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004658#35
is adviced:

  source-map-mappings should be packaged separately,
  and then build-depended on from package node-source-map.
 

> > > I need to build a wasm file using cargo. I succeed to do it
> > 
> > OKay, nice.
> > 
> > 
> > > but it downloads some package during build process:
> > >   * libc-0.2.116
> > >   * rand-0.4.6
> > >   * vlq-0.5.1
> > > 
> > > Which package do I have to install as dependency to avoid this ?
> > 
> > Some how I do read "How to avoid dependency?"
> > 
> > Please elaborate your question. Because I don't understand it,
> > but want to understand it.
> 
> With network enabled, "cargo build" downloads these 3 packages and stores
> them in ~/.cargo
> 
> > > PS: sorry, I don't know anything about rust packaging,
> > >  neither rust/cargo themselves...
> > > 
> > 
> > Some how I do read "I fear the yet unknown rust and unknown cargo world"
> > 
> > Just tell more about "starting point"
> > > to update a nodejs package,
> 
> https://salsa.debian.org/js-team/node-source-map
> 
> Cheers,
> Yadd
> 

Now I understand the

} } }  it builds
} } }  there are dependencies  (they are fetched by Cargo)

the problem^Wchallenge in my words

} } }  It builds when Internet access is allowed.
} } }  During "debian build" is Internet access not allowed
} } }  (to prevent unreproduceable builds).
} } }  How to get the missing build dependencies?


Rust packages / crates needs to packaged for Debian.

> > >   * libc-0.2.116
With 
https://packages.debian.org/search?suite=stable§ion=all&arch=any&searchon=all&keywords=libc+rust
did I found `librust-libc-dev`.

> > >   * rand-0.4.6
There is Debian package `librust-rand+libc-dev`.


> > >   * vlq-0.5.1
That one seems to be missing.



Groeten
Geert Stappers
DD
-- 
Silence is hard to parse



Bug#1004676: [Pkg-javascript-devel] Bug#1004676: node-istanbul: please make the build reproducible

2022-01-31 Thread Yadd

Control: fixed -1 0.4.5+repack10+~cs97.25.57-3

On 31/01/2022 16:48, Chris Lamb wrote:

Source: node-istanbul
Version: 0.4.5+repack10+~cs97.25.57-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
node-istanbul could not be built reproducibly.

This is because it embedded the current working directory in the
generated manpage, which means that the current working directory
is embedded.

A patch is attached that strips this out.

  [0] https://reproducible-builds.org/


Hi,

I always fixed that some hours ago with another patch: 
https://salsa.debian.org/js-team/node-istanbul/-/commit/a696d49


Cheers,
Yadd



Bug#1004667: linux-signed-arm64: Please enable CONFIG_TASK_DELAY_ACCT

2022-01-31 Thread Salvatore Bonaccorso
Control: tags -1 + moreinfo

Hi,

On Mon, Jan 31, 2022 at 03:18:49PM +0100, Matthias Urlichs wrote:
> Package: linux-signed-arm64
> Version: 5.10.46+4
> Severity: minor
> X-Debbugs-Cc: sm...@smurf.noris.de
> 
> "iotop" complains:
> 
> CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %
> 
> As ARM64 machines with swap space aren't exactly uncommon and it's useful
> to figure out which process is actually swapping: please enable this option.
> 
> It's enabled on amd64, if that helps.

CONFIG_TASK_DELAY_ACCT is already (in fact quite a while back in the
versions) in Debian. Thus closing the bugreport but adding a moreinfo
tag. As I have to assume you are not running a own kernel, what is
special about your setup?

Regards,
Salvatore



Bug#826045: systemd: New kernels are not booted

2022-01-31 Thread Andre Heider

On 30/01/2022 21:51, Michael Biebl wrote:

For anyone interested, I've submitted
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/138

Which also ships some very basic /etc/kernel hooks and a simplistic 
postinst.


Would welcome feedback / follow-up fixes if needed.


That looks nice, thanks for working on this!

I'm still using the very same scripts I posted above, it's still working 
like a charm after 5 years with all the kernel updates and whatnot :)


I haven't tested your PR, and I lack the confirmed account on salsa to 
comment there, so I'll add it here, including answers to questions over 
there:


- removing sd-boot from the root fs won't render the system unbootable, 
since sd-boot needs to be installed to the efi partition. There's 
`bootctl remove` for that


- likewise with updating it. `bootctl status` reports "systemd-boot 
247.9-4" here, while the systemd package is already at 250.3-2, I'd have 
to `bootctl update` it to update it to that version


- checking if sd-boot is used can be checked via bootctl and should 
probably be used by the containing scripts instead of test -d /boot/efi:

$ bootctl is-installed; echo $?
yes
0

- contrary to the comments on salsa `kernel-install` is not part of your 
new package and I think it makes sense to move there. While it's using 
the "Boot Loader Specification", it's only used for stuff that's already 
part of this package. Even if there's a need for it without using 
sd-boot, one can install the sd-boot package without actually using it 
for booting the box (assuming the package scripts don't enforce it)


Regards,
Andre



Bug#1004674: libnss-systemd: SIGABRT on getgrent pass 2 ( with dynamic user)

2022-01-31 Thread Michael Biebl


Control: tags -1 + moreinfo

Am 31.01.22 um 16:31 schrieb Antonio Russo:


I discovered this issue when running "metastore -s":

Assertion 'name' failed at src/basic/strv.c:22, function strv_find(). Aborting.


..


I don't know if this reproduces on other non-Debian systems. The only related 
upstream bug I could find
is [1] which is resolved by [2], and is apparently included as of 247.3-6 (by 
inspection of source).



Since we don't ship any Debian specific modifications in that regard, it 
would be great if you can try with systemd v250 from unstable/testing 
and if it's still reproducible there, report the issue at

https://github.com/systemd/systemd/issues

Thanks,
Michael


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004679: papirus-icon-theme 20220101-2 fails to install and hangs indefinitly

2022-01-31 Thread Michael Tatge
Package: papirus-icon-theme
Version: 20220101-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   Trying to upgrade from 20220101-1 to 20220101-2

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   apt full-upgrade

   * What was the outcome of this action?
   upgrade process hangs indefinitly an package

   * What outcome did you expect instead?
   clean install

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

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

Versions of packages papirus-icon-theme depends on:
ii  hicolor-icon-theme  0.17-2

papirus-icon-theme recommends no packages.

papirus-icon-theme suggests no packages.

-- no debconf information



Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-31 Thread Helmut Grohne
Hi,

On Mon, Jan 31, 2022 at 10:11:19AM +, Matthew Vernon wrote:
> The two renames have substantially different CLI syntax, making them
> unsuitable for an alternatives arrangement

I think that much of the discussion has taken this point for granted,
but it is one of the aspects that the submitter takes issue with. I
question: Is it really the case that incompatible interfaces make a tool
unsuitable for alternatives?

Maybe we should consider some similar cases? There are two that come to
my mind.

python3 is sufficiently different to python2 that it was deemed unfit to
fill the name /usr/bin/python in general. Yet, we have packages
python-is-python2 and python-is-python3. This is not using alternatives,
but it is an example where it is useful to allow a name to be taken by
different tools with substantially different interfaces. At the same
time, we have a policy that nothing in Debian may make use of
/usr/bin/python to allow this flexibility.

Another is renames. When nodejs was first introduced, it was denied
using the name /usr/bin/node. That other use of the name has since been
faded out and the name has been given to nodejs. Again, not using
alternatives, but a substantially changed interface.

I wasn't able to find cases where alternatives were used with
substantial interface differences. Often times it seems to be used for
changing the implementation of some command which is used by other
packages (popular example: awk).

Another way to look at it is figuring what uses /usr/bin/rename.
Searching for it is not easy as the term is so generic. I've found some
uses.

All of these use the file-rename syntax:
https://sources.debian.org/src/duplicity/0.8.21-1/testing/manual/run-coverage.sh/?hl=58#L58
https://sources.debian.org/src/gdcm/3.0.10-1/Utilities/gdcmjpeg/dcmtk.sh/?hl=18#L18
https://sources.debian.org/src/firebird3.0/3.0.8.33535.ds4-1/debian/make_packages.sh/?hl=185#L185
https://sources.debian.org/src/caveexpress/2.5.2-1/contrib/scripts/fontmerge.sh/?hl=22#L22
https://sources.debian.org/src/caveexpress/2.5.2-1/contrib/scripts/convert-layer.sh/?hl=63#L63
Most of them seem to be utility scripts for development.

A particular entertaining one is this:
https://sources.debian.org/src/rclone-browser/1.8.0-1.2/scripts/release_AppImage.sh/?hl=150#L150
It uses both syntaxes in the same source.

Beyond that, no package depends on rename and only xymon suggests it.

So maybe changing /usr/bin/rename to something else is not the worst of
options, but using alternatives for that task likely is the wrong tool.

As such, it does not seem too absurd to add some policy forbidding the
use of /usr/bin/rename (deferring in-archive users to
implementation-specific names). Once that is in place, the decision of
what /usr/bin/rename points to can be deferred to administrators (which
seems to be what the ctte filing is about) by some means other than
alternatives. Perhaps, we need file-is-file-rename and
file-is-rename.ul?

In any case, what I sketched here is a larger transition that shouldn't
be dumped on the util-linux maintainer somehow.

Dirk, would you be interested in working on a transition plan?

> #966468 & #982944 asked for rename.ul to return (though the latter rather
> confuses the removal vs alternatives issue)

I think it is relatively uncontroversial to return rename.ul in some
non-essential form. Chris vaguely offered including it in bsdextrautils
(without a clear plan on how). How about adding rename as
/usr/bin/rename.ul to bsdextrautils without participating in
alternatives? Would you, Chris, agree to that? I think doing so would
please some users and reduce the conflict. Those people could then ln -s
/usr/bin/rename.ul /usr/local/bin/rename on their systems. It may not be
as convenient as installing a package or using update-alternatives, but
it isn't that hard either.

In any case, I fear we may run counter to §6.3.5 (no detailed design
work). It seems pretty clear that the issue is in large part a
communication issue. As such, maybe we can wind this down already?

Helmut



Bug#1004678: git-lfs: allow offline operation

2022-01-31 Thread Barak A. Pearlmutter
Package: git-lfs
Version: 3.0.2-1
Severity: wishlist
X-Debbugs-Cc: none, Barak A. Pearlmutter 

I have a repo whose only remote is on a gitlab instance. I'm using
git-lfs to manage large binary files in this repo. The remote goes down.
Now "git add foo.pdf / git commit", when *.pdf files are tracked by lfs,
freezes! Waits forever for the remote when trying to transfer the big
blobs.

This violates what I consider a central concept of git, namely that
operations are local unless you explicitly fetch or push. It means you
cannot work with lfs while offline, like on an aeroplane, or even (as
above) when the gitlab instance is offline for maintenance.

There is also a potential security issue. Users might reasonably assume
they can safely do "git add/commit/rebase" operations locally, with
intermediate steps exposing secret information that is later removed
before doing a push. Nope!

Anyway: I *wish* git-lfs allowed remote operation, like git-annex does.
It seems like it should be technically possible to wait until an
lfs-tracked file (well, its https://git-lfs.github.com/spec/v1 smudge
stub) is actually pushed before transferring the associated big binary
blob. Or at the very least, giving up and remembering to try again later
if there's a big binary blob transfer problem.

-- System Information:
Versions of packages git-lfs depends on:
ii  git1:2.34.1-1
ii  libc6  2.33-5



Bug#1004677: dh-golang: Please support skipping specific tests

2022-01-31 Thread Benjamin Drung
Package: dh-golang
Version: 1.53
Severity: normal

Hi,

golang-github-mdlayher-netlink ships test cases in several directories.
Running the package build, dh_auto_test is running this go test command:

   dh_auto_test -O--builddirectory=_build -O--buildsystem=golang
   cd _build && go test -vet=off -v -p 12
   github.com/mdlayher/netlink
   github.com/mdlayher/netlink/internal/integration
   github.com/mdlayher/netlink/nlenc
   github.com/mdlayher/netlink/nltest

I want to disable running the internal integration tests since they
would introduce circular dependencies. According to the man page, there
is no way to specify tests to exclude. It would be nice if dh-golang
would support excluding tests, e.g. by specifying:

export DH_GOLANG_TEST_EXCLUDES := internal/integration/

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations Cloud

IONOS SE | Revaler Str. 30 | 10245 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Britta Schmidt, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet


Bug#1004676: node-istanbul: please make the build reproducible

2022-01-31 Thread Chris Lamb
Source: node-istanbul
Version: 0.4.5+repack10+~cs97.25.57-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
node-istanbul could not be built reproducibly.

This is because it embedded the current working directory in the
generated manpage, which means that the current working directory
is embedded.

A patch is attached that strips this out.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2022-01-31 07:33:34.236984222 -0800
--- b/debian/rules  2022-01-31 07:45:32.099399485 -0800
@@ -9,6 +9,7 @@
 
 override_dh_auto_build:
help2man -N -n 'istanbul command line interface' nyc/bin/nyc.js >nyc.1
+   sed -i -e 's@default: "/.*"@default: current dir@g' nyc.1
 
 override_dh_fixperms:
dh_fixperms


Bug#1004673: dh-make-perl: Debian::Dependency should not fail on additional commas

2022-01-31 Thread Yadd
Package: dh-make-perl
Version: 0.116
Severity: normal
Tags: patch

Hi,

dpkg tools accepts additional commas in dependencies but not
Debian::Dependency:

  Build-Depends: , debhelper-compat (=13)

Easy to fix:

  --- a/lib/Debian/Dependency.pm
  +++ b/lib/Debian/Dependency.pm
  @@ -352,7 +352,7 @@ sub parse {
   }
   );
   }
  -else {
  +elsif ($str) {
   die "Unable to parse '$str'";
   }
   }



Bug#1004467: libostree-1-1: flatpak crashes when creating a bundle

2022-01-31 Thread Philipp Huebner
Am 28.01.22 um 11:44 schrieb Simon McVittie:
> On Fri, 28 Jan 2022 at 08:27:19 +0100, Philipp Huebner wrote:
>> On Debian Bullseye, flatpak crashes when trying to create a bundle.
> 
> Is this specific to being in an ecryptfs directory, or some other special
> filesystem configuration?

Yes, it hangs/crashes when $HOME is ecrypfs encrypted. On a simple clean
Debian 11 without ecryptfs the bundling finishes successfully.


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004672: libdebian-copyright-perl: Debian::Copyright should accept Files-Included and Files-Excluded-

2022-01-31 Thread Yadd
Package: libdebian-copyright-perl
Version: 0.2-4
Severity: important

Hi,

debian/copyright accepts some fields for mk-origtargz including:
 * Files-Included
 * Files-Excluded-
 * Files-Included-

For now Debian::Copyright fails. It is easy to add "Files_Included" in
Debian/Copyright/Stanza/Header.pm but handling Files-Excluded-
requires to change more things.



Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

2022-01-31 Thread Marcel Partap



Dear Guillem et al.,
don't know whether there already has been that called-for discussion on debian-devel 
about the technical burden of zstd support in dpkg. But obviously, ubuntu's move to 
compress debs with zstd by default in July last year (in favor of better UX) has made 
picking packages from their (or any third-party) repository (like their rtl8821ce-dkms) 
"a bit more difficult". And it seems somewhat unlikely they will roll back that 
decision..

So here's the patch rebased again on current git tip.
https://salsa.debian.org/mpartap-guest/dpkg/-/tree/zstd-rebased

Best Regards
Marcel 😅



Bug#1004670: [Pkg-javascript-devel] Bug#1004670: pkg-js-tools: restrictive regex for d/nodejs/component_links

2022-01-31 Thread Yadd

Control: tags -1 + wontfix

On 31/01/2022 15:37, Gordon Ball wrote:

Package: pkg-js-tools
Version: 0.11.7
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

Lines in the file `debian/nodejs/component_links` are checked for the
regex `/^([\w\-\.\/]+)\s+([\w\-\.\/]+)$/` and otherwise reported as
malformed.

This means that components named in the typescript style (@foo/bar)
can't be used with this file.


Hi,

don't confuse component name and module name. Component name should 
follow this regex else dpkg will fail. Try


  add-node-component @foo/bar

component will be named "foo-bar" but dh-sequence-nodejs will install it 
in /.../nodejs/@foo/bar


Cheers,
Yadd



Bug#1004671: incompatible with current biblatex version

2022-01-31 Thread Ryan Kavanagh
Package: biber
Version: 2.17-1
Severity: grave
Justification: Renders package unusable
X-Debbugs-Cc: r...@debian.org

I'm not sure if this should instead be filed against
texlive-bibtex-extra, but the current version of biber is incompatible
with the biblatex package currently in Debian unstable. This effectively
renders biber useless and makes it impossible to compile documents that
use biblatex.

Attempting to compile the following MWE

\documentclass{article}
\usepackage[backend=biber]{biblatex}
\begin{document}
\printbibliography
\end{document}

results in

ERROR - Error: Found biblatex control file version 3.7, expected version 
3.8.
This means that your biber (2.17) and biblatex (3.16) versions are 
incompatible.

Here is the complete log:

This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2022/dev/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./mwe.tex
LaTeX2e <2021-11-15> patch level 1
L3 programming layer <2021-11-22>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2021/10/04 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/biblatex/biblatex.sty
(/usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
(/usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty)
(/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty)
(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty))
(/usr/share/texlive/texmf-dist/tex/latex/etoolbox/etoolbox.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
(/usr/share/texlive/texmf-dist/tex/generic/kvsetkeys/kvsetkeys.sty))
(/usr/share/texlive/texmf-dist/tex/latex/logreq/logreq.sty
(/usr/share/texlive/texmf-dist/tex/latex/logreq/logreq.def))
(/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty)
(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty)
(/usr/share/texlive/texmf-dist/tex/latex/biblatex/blx-dm.def)
(/usr/share/texlive/texmf-dist/tex/latex/biblatex/blx-compat.def)
(/usr/share/texlive/texmf-dist/tex/latex/biblatex/biblatex.def)
(/usr/share/texlive/texmf-dist/tex/latex/biblatex/bbx/numeric.bbx
(/usr/share/texlive/texmf-dist/tex/latex/biblatex/bbx/standard.bbx))
(/usr/share/texlive/texmf-dist/tex/latex/biblatex/cbx/numeric.cbx)
(/usr/share/texlive/texmf-dist/tex/latex/biblatex/biblatex.cfg))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(./mwe.aux) (/usr/share/texlive/texmf-dist/tex/latex/biblatex/lbx/english.lbx)
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty)
(/usr/share/texlive/texmf-dist/tex/latex/biblatex/blx-case-expl3.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty))
(./mwe.bbl)

LaTeX Warning: Empty bibliography on input line 5.

(./mwe.aux) )
No pages of output.
Transcript written on mwe.log.
Use of uninitialized value in quotemeta at /usr/share/perl5/Biber/Config.pm 
line 228.
Use of uninitialized value $tool in concatenation (.) or string at 
/usr/share/perl5/Biber/Config.pm line 307.
INFO - This is Biber 2.17
INFO - Logfile is 'mwe.blg'
INFO - Reading 'mwe.bcf'
ERROR - Error: Found biblatex control file version 3.7, expected version 3.8.
This means that your biber (2.17) and biblatex (3.16) versions are incompatible.
See compat matrix in biblatex or biber PDF documentation.
INFO - ERRORS: 1

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

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

Versions of packages biber depends on:
ii  libautovivification-perl  0.18-1+b3
ii  libbusiness-isbn-perl 3.006-1
ii  libbusiness-ismn-perl 1.202-1
ii  libbusiness-issn-perl 1.004-1
ii  libclass-accessor-perl0.51-1
ii  libdata-compare-perl  1.27-1
ii  libdata-dump-perl 1.25-1
ii  libdata-uniqid-perl   0.12-1.1
ii  libdate-simple-perl   3.0300-3+b1
ii  libdatetime-calendar-julian-perl  0.106-1
ii  libdatetime-format-builder-perl   0.8300-1
ii  libdatetime-perl  2:1.55-1
ii  libencode-eucjpms-perl0.07-3+b9
ii  libencode-hanextra-perl   0.23-5+b3
ii  libencode-jis2k-perl  0.03-1+b7
ii  libfile-slurper-perl  0.013-1
ii  libipc-run3-perl  0.048-2
ii  liblingua-translit-perl   0.28-1
ii  liblist-allutils-perl 0.19-1
ii  liblist-moreutils-perl0.430-2
ii  liblog-log4perl-perl  1.54-1
ii  liblwp-protocol-

Bug#1004669: ifupdown: ifdown does not found xargs

2022-01-31 Thread Santiago Ruano Rincón
Hi,

El 31/01/22 a las 15:28, Jerome Benoit escribió:
> Package: ifupdown
> Version: 0.8.36
> Severity: normal
> 
> Dear Maintainer,
> 
> if I run `ifdown wlan0` I get three times the message
> 
>   /usr/sbin/invoke-rc.d: 1: xargs: not found
> 
> hence my report.
...

Thanks! However, I am wondering how this is caused by ifupdown.
Maybe I am too sleepy today, but I am unable to find any call to xargs
in the ifupdown code.

What are the contents of your /e/n/interfaces? Haven't you any call to
invoke-rc.d in a `down` command in your iface wlan0 stanza?

Cheers,

 -- S


signature.asc
Description: PGP signature


Bug#1004670: pkg-js-tools: restrictive regex for d/nodejs/component_links

2022-01-31 Thread Gordon Ball
Package: pkg-js-tools
Version: 0.11.7
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

Lines in the file `debian/nodejs/component_links` are checked for the
regex `/^([\w\-\.\/]+)\s+([\w\-\.\/]+)$/` and otherwise reported as
malformed.

This means that components named in the typescript style (@foo/bar)
can't be used with this file.

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

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

Versions of packages pkg-js-tools depends on:
ii  debhelper 13.6
ii  libdebian-copyright-perl  0.2-4
ii  libdebian-source-perl 0.116
ii  libipc-run-perl   20200505.0-1
ii  libjson-perl  4.04000-1
ii  libyaml-perl  1.30-1
ii  nodejs12.22.9~dfsg-1
ii  perl  5.32.1-6

Versions of packages pkg-js-tools recommends:
ii  devscripts2.22.1
ii  libdpkg-perl  1.21.1

Versions of packages pkg-js-tools suggests:
ii  autodep8   0.25
ii  autopkgtest5.19
ii  git-buildpackage   0.9.25
pn  libconfig-inifiles-perl
ii  libconfig-model-dpkg-perl  2.156
ii  libconfig-model-perl   2.149-1
ii  lintian2.114.0
ii  node-semver7.3.5+~7.3.8-1
ii  npm8.4.0~ds-1

-- no debconf information



Bug#1004658: [Pkg-javascript-devel] Bug#1004658: node-source-map: please package new upstream release 0.7.3

2022-01-31 Thread Jonas Smedegaard
Quoting Yadd (2022-01-31 15:16:04)
> On 31/01/2022 15:13, Jonas Smedegaard wrote:
> > [ adding back bugreport as recipient ]
> > 
> > Quoting Yadd (2022-01-31 14:55:57)
> >> On 31/01/2022 14:51, Jonas Smedegaard wrote:
> >>> Quoting Yadd (2022-01-31 14:38:46)
>  And my median delay in NEW queue is around 130 days, so too long 
>  for such test
> >>>
> >>> Feel free to circumvent the need for NEW queue _outside_ of 
> >>> Debian.
> >>>
> >>> In Debian, use the NEW queue when introducing new projects.
> >>>
> >>> Time required for processing NEW queue is *NOT* an argument for 
> >>> circumventing NEW queue, but instead an argument for vounteering 
> >>> as ftp trainee.
> >>
> >> I applied 3 years ago and never received any response.
> > 
> > I see no package still hanging in NEW queue uploaded 3 years ago: 
> > https://ftp-master.debian.org/new.html
> > 
> > What am I missing, or what am I misunderstanding in what you are 
> > saying?
> 
> Sorry, "I applied..." was a response to "argument for vounteering as 
> ftp trainee"

Ah, cool!

Perhaps that email simply went unnoticed.  I can suggest to try ping 
ftpmasters on irc.

And regardless, it is still no argument for circumventing NEW queue.


 - 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#1004669: ifupdown: ifdown does not found xargs

2022-01-31 Thread Jerome Benoit
Package: ifupdown
Version: 0.8.36
Severity: normal

Dear Maintainer,

if I run `ifdown wlan0` I get three times the message

/usr/sbin/invoke-rc.d: 1: xargs: not found

hence my report.

I can fix this issue by setting a link of xargs in /bin/xargs

Note that my box is a sysvinit box.

hth,
Jerome




-- System Information:
Debian Release: Bullseye*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  5.10.0-4
ii  libc6 2.31-13+deb11u2
ii  lsb-base  11.1.0

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2.3

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- no debconf information



Bug#1004668: python3-metakernel: Should not depend on jupyter-notebook

2022-01-31 Thread Gordon Ball
Package: python3-metakernel
Version: 0.27.5-3
Severity: minor
X-Debbugs-Cc: gor...@chronitis.net

python3-metakernel adds a manual dependency on jupyter-notebook, which
should probably not be a hard dependency. The library doesn't import
from notebook anywhere I can see, so it's only being added as a possible
frontend for whatever kernel metakernel is implementing. However, other
frontends exist (jupyter-console, nbclient, kernel gateways, etc), so
a hard dependency on the most heaviweight frontend seems unnecessary.

I would either demote this to Suggests: or drop it completely.

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

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

Versions of packages python3-metakernel depends on:
ii  jupyter-notebook   6.4.8-1
ii  python33.9.8-1
ii  python3-ipykernel  6.7.0-1
ii  python3-pexpect4.8.0-2

Versions of packages python3-metakernel recommends:
ii  python3-pydot  1.4.2-1

python3-metakernel suggests no packages.

-- no debconf information



  1   2   >