Bug#981017: whipper: Whipper throws tracebacks

[Louis-Philippe Véronneau]

Thank you for reporting this bug.

Could you check if this still happens with the latest version in Debian
unstable (0.10.0-1)?

Upstream fixed quite a lot of bugs between 0.9.0 and 0.10.0 :)

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1009714: mplayer: new upstream release 1.5

[Yan Hetges]

Package: mplayer
Version: 2:1.4+ds1-3+b1
Severity: wishlist
Tags: upstream

Dear Maintainer,

This should probably close #1004579 and if somebody steps in it could also 
close #1005899

Cheers

  --Yan

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

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

Versions of packages mplayer depends on:
ii  liba52-0.7.4  0.7.4-20
ii  libaa11.4p5-50
ii  libasound21.2.6.1-2+b1
ii  libass9   1:0.15.2-1
ii  libaudio2 1.9.4-7
ii  libavcodec58  7:4.4.1-3+b2
ii  libavformat58 7:4.4.1-3+b2
ii  libavutil56   7:4.4.1-3+b2
ii  libbluray21:1.3.1-1
ii  libbs2b0  3.1.0+dfsg-5
ii  libc6 2.33-7
ii  libcaca0  0.99.beta19-2.2
ii  libcdio-cdda2 10.2+2.0.0-1+b2
ii  libcdio-paranoia2 10.2+2.0.0-1+b2
ii  libcdio19 2.1.0-3
ii  libdca0   0.0.7-2
ii  libdv41.0.0-14
ii  libdvdnav46.1.1-1
ii  libdvdread8   6.1.2-1
ii  libegl1   1.4.0-1
ii  libenca0  1.19-1+b1
ii  libfaad2  2.10.0-2
ii  libfontconfig12.13.1-4.4
ii  libfreetype6  2.11.1+dfsg-1
ii  libfribidi0   1.0.8-2.1
ii  libgif7   5.1.9-2
ii  libgl11.4.0-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.20~dfsg-1+b1
ii  libjpeg62-turbo   1:2.1.2-1
ii  liblirc-client0   0.10.1-6.3
ii  libmad0   0.15.1b-10
ii  libmng1   1.0.10+dfsg-3.1+b5
ii  libmpeg2-40.5.1-9
ii  libmpg123-0   1.29.3-1
ii  libogg0   1.3.4-0.1
ii  libopenal11:1.19.1-2
ii  libpng16-16   1.6.37-3
ii  libpostproc55 7:4.4.1-3+b2
ii  libpulse0 15.0+dfsg1-4
ii  libsdl1.2debian   1.2.15+dfsg2-6
ii  libsmbclient  2:4.16.0+dfsg-6
ii  libspeex1 1.2~rc1.2-3
ii  libswresample37:4.4.1-3+b2
ii  libswscale5   7:4.4.1-3+b2
ii  libtheora01.1.1+dfsg.1-15
ii  libtinfo6 6.3-2
ii  libvdpau1 1.5-1
ii  libvorbisidec11.2.1+git20180316-7
ii  libx11-6  2:1.7.5-1
ii  libx264-163   2:0.163.3060+git5db6aa6-2
ii  libxext6  2:1.3.4-1
ii  libxinerama1  2:1.1.4-3
ii  libxss1   1:1.2.3-1
ii  libxv12:1.0.11-1
ii  libxvidcore4  2:1.3.7-1
ii  libxvmc1  2:1.0.12-2
ii  libxxf86dga1  2:1.1.4-1+b3
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g1:1.2.11.dfsg-4

mplayer recommends no packages.

Versions of packages mplayer suggests:
ii  bzip2   1.0.8-5
ii  fontconfig  2.13.1-4.4
pn  fonts-freefont-ttf  
pn  mplayer-doc 
pn  netselect | fping   

-- no debconf information

Bug#1009668: Re: Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[zhenwei pi]

On 4/15/22 04:47, Chris Hofstaedtler wrote:

Hi Axel, zhenwei,

* Axel Beckert  [220414 15:08]:

Since you're asking, I allow myself to cite my reply to your inquiry
with me back then (June 2021):


Thanks!


-

Hmmm, do they do the same? Can I test that irqtop from util-linux
somewhere?

Since people seem to expect the irqtop tool from util-linux, I see
multiple options:

1) If the irqtop from util-linux is clearly superior: Drop building
the irqtop package from src:iptables-netflow and let util-linux
generate a transitional package. (Versions should be no problem
with 2.6 < 2.36.)

I more or less built that binary package, because that tool was in
the upstream sources and no such feature was present in Debian so
far and I didn't want to pull in ruby just for a DKMS kernel module.

2) If none of them is clearly superior and they have different feature
sets, using the alternatives system might be an option.

Since I expect both to be just TUI tools without having an API
being used by other tools, different commandline options should not
be an issue here.

3) Rename one of them, e.g. to irqtop-nf or irqtop-ul or so. (Renaming
both of them will be needed for variant 2 anyways.)

In case you intend to add lsirq for bullseye, you could also add
irqtop as irqtop-ul or so (i.e. variant 3b), too. That shouldn't cause
any disturbance IMHO.

-

As far as I can see, I didn't get a reply back from you on these
suggestions of mine. Maybe my mail fell through the cracks. But I
think we should take the discussion up again, probably in this bug
report.


Right. I think I forgot to reply back then - sorry.

Experimental should have util-linux-extra 2.38-4+exp1 very soon,
with irqtop installed. Obviously this can only be used for testing.

Personally I think we should have only one irqtop - from my point of
view it does not matter which one. Maybe the new version is
superior. In any case we should not confuse our users.

zhenwei, do you have input on the differences between the existing
irqtop and the new irqtop from util-linux?


Another point which comes to my mind now is that it might make sense
to rename the current irqtop package to irqtop-nf (or irqtop-ruby)
just to make clear that it does not contain the irqtop tool from
util-linux.


Might be an idea. But lets see what the differences are, first.


Thanks,
Chris


Hi, Chris & Axel

The main difference between the two versions:
- original irqtop shows separated interrupt information
- new irqtop shows aggregate interrupt information

Test env: Debian 10; 96 CPUs on a server, 230 characters per line in 
termial.


- irqtop (original version) shows uncompleted interrupts(31 / 96 CPUs).
n194-087-081 - irqtop - 2022-04-15 09:42:48 +0800
  CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   CPU6   CPU7 
CPU8   CPU9  CPU10  CPU11  CPU12  CPU13  CPU14  CPU15  CPU16  CPU17 
CPU18  CPU19  CPU20  CPU21  CPU22  CPU23  CPU24  CPU25  CPU26  CPU27 
CPU28  CPU29  CPU30  C
  cpuUtil: 0.00.00.40.01.30.00.00.2 
0.00.00.00.00.00.00.20.00.00.0 
0.00.00.00.00.00.00.00.20.20.2 
0.20.00.2
 %irq: 0.00.00.00.00.00.00.00.0 
0.00.00.00.00.00.00.00.00.00.0 
0.00.00.00.00.00.00.00.00.00.0 
0.00.00.0
%sirq: 0.00.00.00.00.00.00.00.0 
0.00.00.00.00.00.00.00.00.00.0 
0.00.00.00.00.00.00.00.00.00.0 
0.00.00.0
 irqTotal:  32293477  5 34  7  5   1805 
112 51  3  2 28  2   1901  1 13 16 
0  6  1 19  2  2 67 29 51 51 42 
 9 34
i   9:   .  2  0  0  0  .  .  . 
 .  .  .  .  .  .  .  .  .  . 
.  .  .  .  .  .  .  .  .  .  . 
 .  .
i  48:   .  .  .  .  .  .  0  . 
 .  .  .  .  .  .  .  .  .  . 
.  .  .  .  .  .  .  .  .  .  . 
 .  .
i  49:   .  .  .  .  .  .  .  . 
 .  .  .  .  .  .  .  .  .  . 
.  .  .  .  .  .  .  .  .  .  . 
 .  .
i  50:   .  .  .  .  .  .  .  . 
 .  .  .  .  .  .  .  .  .  . 
.  .  .  .  .  .  .  .  .  .  . 
 .  .
i  51:   .  .  .  .  .  .  .  . 
 .  .  

Bug#1009713: RFP: netavark -- A container network stack

[Reinhard Tartler]

Package: wnpp
Severity: wishlist

* Package name: netavark
  Version : 1.0.2
  Upstream Author : github.com/containers
* URL or Web page : https://github.com/containers/netavark
* License : MIT
  Description : A container network stack

Podman 4.0 recommends this and its compainion package
'https://github.com/containers/aardvark-dns'.  I'm not familiar with
rust packaging, and would really appreciate if someone would give me a
hand with updating required dependencies and packaging it properly.

Bug#985187: ffmpeg: reproducible builds: Embeds build path in binaries generated with cl2c

[Vagrant Cascadian]

On 2021-08-08, Sebastian Ramacher wrote:
> On 2021-03-13 20:05:47 -0800, Vagrant Cascadian wrote:
>> Source: ffmpeg
>> Severity: normal
>> Tags: patch
>> User: reproducible-bui...@lists.alioth.debian.org
>> Usertags: buildpath
>> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>> 
>> The build path is embedded in various files generated with tools/cl2c:
>> 
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ffmpeg.html
>> 
>>   avgblur.o (shipped in libavfilter.a)
>> 
>>   #line·1·"/build/1st/ffmpeg-4.3.2/libavfilter/opencl/avgblur.cl"
>>   vs.
>>   #line·1·"/build/2/ffmpeg-4.3.2/2nd/libavfilter/opencl/avgblur.cl"
>> 
>> 
>> The attached patch fixes this by patching tools/cl2c to use a basename
>> in the generated file rather than the full path.
>> 
>> 
>> It builds fine with this patch applied, but someone more familiar with
>> ffmpeg should ensure ffmpeg still functions correctly with the patch
>> applied.
>
> As this patch touches upstream's build system, please submit it
> upstream:
>
> https://ffmpeg.org/developer.html#Contributing

Did so, haven't really heard anything back:

  https://patchwork.ffmpeg.org/project/ffmpeg/patch/87sfwyotmg.fsf@yucca/

Any suggestions?

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1009380: sasl2-bin: make saslpluginviewer more accessible (clearer manpage, put it in /usr/bin)

[Bastian Germann]

On Tue, 12 Apr 2022 11:43:01 -0700 Daniel Kahn Gillmor  
wrote:

 - the manual page should also be updated as part of this rename -- it's
   installed as saslpluginviewer.8.gz, but internally it says
   "pluginviewer".


This will be fixed with the next release.


 - it should be available in /usr/bin/, not only in /usr/sbin/.  It's
   not uncommon for someone to want to investigate the state of
   installed tooling without having to be root, and /usr/sbin is not
   typically in the regular user path.

I will not change the location to a different path from upstream.
Please ask upstream for this change if it is important for you.

Bug#1009710: minor memory leaks

[Morel Bérenger]

The previous report was done after noticing a lot more of problems when
using the stack glfw3 + glm + epoxy + mesa with intel drivers.
Valgrind reports lot of memory problems notably when using
glCompileShader, when loading shared libraries (dlopen) and many more.
I can provide the source code that I'm writing which triggers those,
it's intended to be FOSS in any case, but it's very young and does
nothing interesting (taking my time to write code with every possible
error checking in the graphical stack).

I have not reported those information is original bug report, because
they do not belong directly to glfw3. Sending multiple reports would be
an option, but I'm not sure it's very productive, especially if this is
going to be ignored (problems are only seen with valgrind AFAIK and
some of those might be related to stuff I did in my code, notably the
shaders. I need to dig more to be confident enough there to send a
report.)

Bug#1009680: ghostscript breaks ocrmypdf autopkgtest: seemingly multiple issues

[Sean Whitton]

control: reassign -1 ghostscript
control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=705187
control: retitle -1 Ghostscript 9.56 removes hidden (e.g. OCR) text layers when 
refrying with NEWPDF=true

Hello,

On Thu 14 Apr 2022 at 11:13AM +02, Paul Gevers wrote:

> With a recent upload of ghostscript the autopkgtest of ocrmypdf fails in
> testing when that autopkgtest is run with the binary packages of
> ghostscript from unstable. It passes when run with only packages from
> testing. In tabular form:
>
> passfail
> ghostscriptfrom testing9.56.0~dfsg-1
> ocrmypdf   from testing13.4.0+dfsg-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 of ghostscript 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

It's a regression in Ghostscript.

OCRmyPDF has made a release including a workaround but the test suite
for that fails, so I can't upload it yet.  But in any case this bug is
not one in OCRmyPDF.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1009711: openqa: block migration to testing (awaiting availability of packaged shepherd.js)

[Philip Hands]

Package: openqa
Severity: serious

Recently upstream, openQA switched to using shepherd.js for its guided tour,
which is not yet packaged.

I'd prefer to avoid the current version getting into testing, to avoid it
somehow sneaking into stable if getting shepherd.js through NEW takes longer
than expected, so am reporting this bug to block it for now.

Cheers, Phil.

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

[Sean Whitton]

Hello Matthew,

On Thu 14 Apr 2022 at 04:47PM +01, Matthew Vernon wrote:

> ===Begin Resolution
>
> The Technical Committee resolves that util-linux's rename should be
> shipped in a binary package build from src:util-linux. If this package
> Conflicts with the rename package, then it should not contain any other
> binaries.
>
> The Technical Committee overrides the util-linux maintainer, and
> requires that this binary should be shipped as /usr/bin/rename.ul
>
> ===End Resolution
>
> A: Approve resolution, including override of util-linux maintainer
> B: Approve only first paragraph of resolution
> N: None of the above

I think that both of these involve overriding the maintainer, as the
restriction to not include any other binaries if the package Conflicts:
with bin:rename is also to override the maintainer?

> Matthew
> ps; my first TC resolution, please be gentle if I have the procedure wrong!

Thank you for coming up with this text.  Actually, the new procedure is
new to all of us; this is our first use of it.

In this case I believe you need to formally withdraw options A and
then propose another ballot.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1009710: libglfw3: valgrind finds memory leak

[Bérenger]

Package: libglfw3
Version: 3.3.2-1
Severity: minor
Tags: upstream
X-Debbugs-Cc: berengermore...@gmail.com

When writting a minimal C program with glfw3, valgrind find leaked
memory.

Code of the program:

```
#include 

int main()
{
glfwInit();
glfwTerminate();
}
```

Compiling and running with:
```
clang test.c $(pkg-config --libs glfw3)
valgrind --leak-check=full --show-leak-kinds=all --log-file=log  ./a.out
```

will generate the report showing the leaks. You will need to install
several dbgsym packages to see the whole stacks, though.

-- System Information:
Debian Release: 11.3
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
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: runit (via /run/runit.stopit)

Versions of packages libglfw3 depends on:
ii  libc6 2.31-13+deb11u3
ii  libgl11.3.2-1
ii  libx11-6  2:1.7.2-1

libglfw3 recommends no packages.

Versions of packages libglfw3 suggests:
ii  libegl1 1.3.2-1
ii  libgles11.3.2-1
ii  libgles21.3.2-1
ii  libosmesa6  20.3.5-1
ii  libvulkan1  1.2.162.0-1

-- no debconf information

Bug#996965: [rstudio/bslib] Please upgrade to bootstrap4 4.6.1 (Issue #422)

[Andreas Tille]

Am Thu, Apr 14, 2022 at 07:51:05AM -0700 schrieb Carson Sievert:
> Sorry, but come of think of it, even if we do upgrade, it won't change the 
> fact that we apply patches to the SCSS source code for BS4 and BS5 (to fix 
> bugs and add features). Technically you'll probably be fine replacing 
> `inst/lib/bs3` with whatever Debian bundles, but in generally this seems like 
> a dangerous practice that could lead to surprising and difficult to debug 
> regressions for end users (I hope you're not planning on doing the same for 
> other HTML dependencies in shiny as we also applies patches to source there 
> as well)

Thanks a lot for this hint.  Do you see any chance to distribute the 
uncompressed source of the JS files?  This would also help a lot.
Kind regards, Andreas.

Bug#1009709: RFS: nginx/1.0-2 [RC] -- small, powerful, scalable web/proxy server

[Thomas Ward]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name    : nginx
   Version : 1.18.0-9
   Upstream Author : Igor Sysoev
 * URL : https://nginx.org
 * License : BSD-4-clause, Expat, BSD-2-clause, BSD-3-clause
 * Vcs : https://salsa.debian.org/nginx-team/nginx
   Section : httpd

The source builds the following binary packages:

  nginx - small, powerful, scalable web/proxy server
  nginx-doc - small, powerful, scalable web/proxy server - documentation
  nginx-common - small, powerful, scalable web/proxy server - common files
  nginx-core - nginx web/proxy server (standard version)
  nginx-full - nginx web/proxy server (standard version with 3rd parties)
  nginx-light - nginx web/proxy server (basic version)
  nginx-extras - nginx web/proxy server (extended version)
  libnginx-mod-http-geoip - GeoIP HTTP module for Nginx
  libnginx-mod-http-geoip2 - GeoIP2 HTTP module for Nginx
  libnginx-mod-http-image-filter - HTTP image filter module for Nginx
  libnginx-mod-http-xslt-filter - XSLT Transformation module for Nginx
  libnginx-mod-mail - Mail module for Nginx
  libnginx-mod-stream - Stream module for Nginx
  libnginx-mod-stream-geoip - GeoIP Stream module for Nginx
  libnginx-mod-stream-geoip2 - GeoIP2 Stream module for Nginx
  libnginx-mod-http-perl - Perl module for Nginx
  libnginx-mod-http-auth-pam - PAM authentication module for Nginx
  libnginx-mod-http-lua - Lua module for Nginx
  libnginx-mod-http-ndk - Nginx Development Kit module
  libnginx-mod-nchan - Fast, flexible pub/sub server for Nginx
  libnginx-mod-http-echo - Bring echo and more shell style goodies to Nginx
  libnginx-mod-http-upstream-fair - Nginx Upstream Fair Proxy Load Balancer
  libnginx-mod-http-headers-more-filter - Set and clear input and 
output headers for Nginx

  libnginx-mod-http-cache-purge - Purge content from Nginx caches
  libnginx-mod-http-fancyindex - Fancy indexes module for the Nginx
  libnginx-mod-http-uploadprogress - Upload progress system for Nginx
  libnginx-mod-http-subs-filter - Substitution filter module for Nginx
  libnginx-mod-http-dav-ext - WebDAV missing commands support for Nginx
  libnginx-mod-rtmp - RTMP support for Nginx

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nginx/nginx_1.18.0-9.dsc


While we are at it, can a sponsor or DD please push a dak command to 
ftp-master so that I can use my Debian Maintainer status to push nginx 
directly to ftp-master without needing sponsorship?



Changes since the last upload:


 nginx (1.18.0-9) unstable; urgency=medium
 .
   [ Jan Mojžíš ]
   * http-lua: Downgrade to 0.10.13 (Closes: #1008787).
   * http-lua: Backport upstream bugfix for segfault in nginx core >= 
1.15.0

 when libnginx-mod-http-lua is loaded and init_worker_by_lua* is used.
   * d/control: Add mips64el,ppc64,kfreebsd-amd64 to list of luajit 
platforms.

   * d/control: fix Homepage nginx.net -> nginx.org (Closes: #976158)
 .
   [ Thomas Ward ]
   * d/watch: Update watch syntax to match all even versions of NGINX 
releases

 rather than use a watch syntax that is static to one specific version.
 This will fix the untracked "New upstream stable versions" problem.
   * d/control: Update 'uploaders' as Thomas Ward is now a maintainer in
 the Salsa repository.


Regards,
--
  Thomas Ward

Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[Chris Hofstaedtler]

Hi Axel, zhenwei,

* Axel Beckert  [220414 15:08]:
> Since you're asking, I allow myself to cite my reply to your inquiry
> with me back then (June 2021):

Thanks!

> -
> 
> Hmmm, do they do the same? Can I test that irqtop from util-linux
> somewhere?
> 
> Since people seem to expect the irqtop tool from util-linux, I see
> multiple options:
> 
> 1) If the irqtop from util-linux is clearly superior: Drop building
>the irqtop package from src:iptables-netflow and let util-linux
>generate a transitional package. (Versions should be no problem
>with 2.6 < 2.36.)
> 
>I more or less built that binary package, because that tool was in
>the upstream sources and no such feature was present in Debian so
>far and I didn't want to pull in ruby just for a DKMS kernel module.
> 
> 2) If none of them is clearly superior and they have different feature
>sets, using the alternatives system might be an option.
> 
>Since I expect both to be just TUI tools without having an API
>being used by other tools, different commandline options should not
>be an issue here.
> 
> 3) Rename one of them, e.g. to irqtop-nf or irqtop-ul or so. (Renaming
>both of them will be needed for variant 2 anyways.)
> 
> In case you intend to add lsirq for bullseye, you could also add
> irqtop as irqtop-ul or so (i.e. variant 3b), too. That shouldn't cause
> any disturbance IMHO.
> 
> -
> 
> As far as I can see, I didn't get a reply back from you on these
> suggestions of mine. Maybe my mail fell through the cracks. But I
> think we should take the discussion up again, probably in this bug
> report.

Right. I think I forgot to reply back then - sorry.

Experimental should have util-linux-extra 2.38-4+exp1 very soon,
with irqtop installed. Obviously this can only be used for testing.

Personally I think we should have only one irqtop - from my point of
view it does not matter which one. Maybe the new version is
superior. In any case we should not confuse our users.

zhenwei, do you have input on the differences between the existing
irqtop and the new irqtop from util-linux?

> Another point which comes to my mind now is that it might make sense
> to rename the current irqtop package to irqtop-nf (or irqtop-ruby)
> just to make clear that it does not contain the irqtop tool from
> util-linux.

Might be an idea. But lets see what the differences are, first.


Thanks,
Chris

Bug#1009691: libusb-1.0-0: Some USB microphone takes sounds as very low volume

[Aurelien Jarno]

Hi,

On 2022-04-14 19:41, Hideki Yamane wrote:
> Package: libusb-1.0-0
> Version: 2:1.0.26-1
> Severity: normal
> X-Debbugs-Cc: henr...@debian.org
> 
> Dear Maintainer,
> 
>  With upgrading libusb-1.0-0 package from 2:1.0.25-1 to 2:1.0.26-1,
>  my USB microphone (marantz PROFESSIONAL pod pack1, "C-Media Electronics, Inc.
>  Blue Snowball" with lsusb) just takes sounds as very low volume. However,
>  Other USB mic (logicool webcam) just works fine with both versions.

Could you please point me to which software you use with this
microphone? Very few softwares use libusb to grab the audio.

>  Downgrading to 2:1.0.25-1 solves this problem.
>  
>  USB microphone's info via lsusb is attached.
>  Please let me know if you need more information to investigate this issue.
>  Thanks.

Could you please run your application with the LIBUSB_DEBUG environment
variable set to 99 for both versions 2:1.0.25-1 and 2:1.0.26-1, and send
me the output?

Thanks
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#999620: pktanon: autopkgtest regression on armhf

[Steve Langasek]

On Thu, Apr 14, 2022 at 09:09:53AM +0200, Sascha Steinbiss wrote:
> Many thanks for reproducing this and for offering a the detailed
> explanation. I would be happy to forward your findings to upstream (however,
> my previous issues/PRs on upstream's GitHub have gone unanswered). For the
> time being, I must admit I unfortunately do not have the time to fix it via
> a patch.

> Do you think we should wait for this to be fixed? As I said before I (just
> from my practical point of view) would be in favor of just removing the
> problematic architectures.

I have no opinion on this.  But if you want the package to be releasable,
you will need to change it so that it is not building a (completely broken
and useless) package on armhf, then get agreement with the ftp team to
remove the existing armhf binaries.

> On 13.04.22 22:39, Steve Langasek wrote:
> > Note that this will consistently fail alignment checks on architectures
> > which require alignment, because the initial buffer is allocated with
> > reasonable alignment (32bit) but the ethernet header is 14 bytes long, so
> > the TCP header fields will always be unaligned within the buffer.
> > 
> > On Wed, Apr 13, 2022 at 01:20:49PM -0700, Steve Langasek wrote:
> > > Here is a backtrace of the armhf SIGBUS.
> > > 
> > > Note that not all ARM implementations return SIGBUS which is probably why
> > > this was not reproducible on the porter machine.
> > > 
> > > # gdb --args pktanon -c 
> > > /usr/share/doc/pktanon/examples/profiles/profile.xml 
> > > ./profiles/sample.pcap ./out.pcap
> > > [...]
> > > Reading symbols from pktanon...
> > > Reading symbols from 
> > > /usr/lib/debug/.build-id/af/1ac53f46ae133c8898358966960cba95ac7a70.debug...
> > > (gdb) run
> > > Starting program: /usr/bin/pktanon -c 
> > > /usr/share/doc/pktanon/examples/profiles/profile.xml 
> > > ./profiles/sample.pcap ./out.pcap
> > > [Thread debugging using libthread_db enabled]
> > > Using host libthread_db library 
> > > "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> > > ---
> > > pktanon --- profile-based traffic anonymization
> > > ---
> > > initializing PktAnon,  configuration = 
> > > /usr/share/doc/pktanon/examples/profiles/profile.xml
> > > unknown element: pktanon-config: 37
> > > unknown element: anonymizations: 102
> > > istream: opened file ./profiles/sample.pcap
> > > ostream: opened output file ./out.pcap
> > > initialized
> > > 
> > > Program received signal SIGBUS, Bus error.
> > > pktanon::TcpPacketTransformation::transform (this=, 
> > > source_buffer=, destination_buffer=0xfffef35a 
> > > "\212y\262X\335\300l\221", max_packet_length=40) at 
> > > transformations/TcpPacketTransformation.cpp:88
> > > 88  hton32 (output_header->ack_num);
> > > (gdb) bt
> > > #0  pktanon::TcpPacketTransformation::transform (this=,
> > >  source_buffer=,
> > >  destination_buffer=0xfffef35a "\212y\262X\335\300l\221",
> > >  max_packet_length=40) at 
> > > transformations/TcpPacketTransformation.cpp:88
> > > #1  0x0040b77c in pktanon::IPv4PacketTransformation::transform 
> > > (this=0x4b4eb0,
> > >  source_buffer=, destination_buffer=0xfffef346 "E",
> > >  max_packet_length=)
> > >  at transformations/IPv4PacketTransformation.cpp:153
> > > #2  0x0040af64 in pktanon::EthernetPacketTransformation::transform (
> > >  this=0x4ad780, source_buffer=,
> > >  destination_buffer=0xfffef338 
> > > "\376\212\a\213\001\254\303\341\372DI\355\b", max_packet_length=74) at 
> > > transformations/EthernetPacketTransformation.cpp:53
> > > #3  0x00416862 in pktanon::transform_packet (stats=...,
> > >  packet_len=,
> > >  transformed_packet=0xfffef338 
> > > "\376\212\a\213\001\254\303\341\372DI\355\b", original_packet=0xfffef438 
> > > "", record_header=...) at Utils.h:26
> > > #4  pktanon::IstreamInput::read_packets (this=0x4b3ce0)
> > >  at IstreamRecordsHandler.cpp:121
> > > #5  0x00415130 in pktanon::PktAnonRuntime::run () at PktAnonRuntime.cpp:37
> > > #6  0x00405bfa in main (argc=, argv=)
> > >  at src/Main.cpp:73
> > > (gdb)
> > > 
> > > So, this is trying to do an hton32() operation on a field that is not 
> > > 4-byte
> > > aligned.
> > > 
> > > -- 
> > > Steve Langasek   Give me a lever long enough and a Free OS
> > > Debian Developer   to set it on, and I can move the world.
> > > Ubuntu Developer   https://www.debian.org/
> > > slanga...@ubuntu.com vor...@debian.org
> > 

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1008668: bug #1008668: tomcat9: logrotated is not able to truncate catalina.out

[Evren Yurtesen]

Hi Markus,


You are quite right. The root cause of the issue is Ubuntu dropping privileges 
of rsyslogd to `syslog` user. This change was done way back in ~2009 in Ubuntu 
package.


https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/388608 (which does not 
explain the benefits very clearly, but my assumption is an attempt at improving 
security).


As you put it adequately. There are other Debian packages also use rsyslogd. 
This change in Ubuntu's rsyslog configuration should be effecting those also. I 
had a quick look using apt-file for packages which put configurations to 
/etc/rsyslog.d. The ones I checked does not seem to specify a certain 
user/group in rsyslog config.  This cause files to be owned as root:adm and 640 
permission in Debian which is the default according to `/etc/rsyslog.conf` and 
in Ubuntu they would be owned by Ubuntu's default settings automatically as 
well.


Could it be more acceptable if the 'fileOwner="tomcat"' setting was simply 
removed from rsyslog config of tomcat9? In addition,  'create 640 tomcat adm' 
and ' su tomcat adm' settings could be removed from logrotate config of tomcat9?


One advantage for Debian is that `tomcat` itself can't read the log files 
anymore. This could be considered more secure. But not that it would help much, 
as tomcat9 package triple-logs everything. First through syslog to 
catalina.out, then directly to catalina.-MM-DD.log in a different format. 
Of course nowadays a third time through journald. :)


Thanks,
Evren


From: Markus Koschany 
Sent: Thursday, April 14, 2022 5:31:49 PM
To: Utkarsh Gupta; Evren Yurtesen
Cc: 1008...@bugs.debian.org
Subject: Re: bug #1008668: tomcat9: logrotated is not able to truncate 
catalina.out

Am Donnerstag, dem 14.04.2022 um 16:23 +0530 schrieb Utkarsh Gupta:
> Hi Emmanuel,
>
> We have bug #1008668 that's causing problems on the Ubuntu side and is
> also reproducible via the Debian package (essentially, it's the same
> in both places).

Hi Utkarsh,

I have been trying to reproduce this problem but on an up-to-date Debian system
running tomcat9 version 9.0.58-1 I cannot reproduce it. catalina.out is
truncated when I run

logrotate -f /etc/logrotate.d/tomcat9

The logrotate file changes the permissions to "su tomcat adm" which is
sufficient to operate on tomcat9 log files. I'm not familiar with the Ubuntu
differences when it comes to logrotate and rsyslogd but I suppose that is the
underlying issue here. It would be strange if we had to change the permissions
to syslog adm because other Debian packages also own log files with their
specific users and then does not cause any problems too.

Thus said I am not against fixing this for Ubuntu but the current approach
seems wrong to me.

Regards,

Markus

Bug#1009707: RFP: fonts-newscycle -- News Cycle is a "realist, sans-serif typeface based primarily on a revival of the 1908-era News

[Eric Brown]

Package: wnpp 
Severity: wishlist
X-Debbugs-Cc: e...@ericebrown.com 

* Package name : fonts-newscycle Version : 0.5.2 Upstream Author : Nathan Wilis 
nwil...@glyphography.com * URL : https://launchpad.net/newscycle * License 
: SIL OFL 1.1
  Programming Lang: n/a Description : News Cycle is a "realist, sans-serif 
typeface based primarily on a 
  revival of the 1908-era News Gothic."


This package is a Google Web Font and is a dependency of bootstrap themes and 
packages that use them, such as r-cran-bslib.

It would be appropriate for the Debian Fonts team to maintain this package.

Bug#985105: kexec-tools: CVE-2021-20269

[Khalid Aziz]

On 3/12/21 13:40, Salvatore Bonaccorso wrote:

Source: kexec-tools
Version: 1:2.0.20-2.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for kexec-tools.

CVE-2021-20269[0]:
| incorrect permissions on kdump dmesg file

Could you check the details here? [2] is slight short on information
if "known upstream" etc.

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-20269
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20269
[1] https://www.openwall.com/lists/oss-security/2021/03/11/2

Please adjust the affected versions in the BTS as needed.

As I explained in my previous update to this bug, this security issue 
does not apply to debian package. This security issue was introduced by 
the scripts added in Fedora/Redhat packages. I will close this bug now.


--
Khalid

Bug#1008421: golang-github-traefik-yaegi: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 -timeout 1h github.com/traefik/yaegi github.com/traefik/yaegi/cmd/yaegi github.com/traefik/y

[Nilesh Patra]

Thanks Lucas, for reporting this bug!

As it looks, yaegi currently does not support go-1.18 properly[1] - atleast
support for generics is missing.
I could maybe circumvent these tests somehow but that does not look the most
optimal thing to do atleast for now. So I will get the ball rolling once 
go-1.19 is out
and yaegi adds proper support.

That said, looking at these bug reports I really feel we(go-team maints)
should do proper rebuilds and testing before going YOLO on updating to new 
golang version. Bumping
golang-defaults in a single shot causes problems like these.

[1]: https://github.com/traefik/yaegi/issues/1363

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1009680: ghostscript breaks ocrmypdf autopkgtest: seemingly multiple issues

[james]

Ghostscript 9.56.0 introduced a serious bug from ocrmypdf’s perspective. 
Upgrading to ocrmypdf 13.4.2 would work or a newer Ghostscript if that’s been 
released. 

> On Apr 14, 2022, at 02:15, Paul Gevers  wrote:
> 
> Source: ghostscript, ocrmypdf
> Control: found -1 ghostscript/9.56.0~dfsg-1
> Control: found -1 ocrmypdf/13.4.0+dfsg-1
> Severity: serious
> Tags: sid bookworm
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of ghostscript the autopkgtest of ocrmypdf fails in 
> testing when that autopkgtest is run with the binary packages of ghostscript 
> from unstable. It passes when run with only packages from testing. In tabular 
> form:
> 
>   passfail
> ghostscriptfrom testing9.56.0~dfsg-1
> ocrmypdf   from testing13.4.0+dfsg-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 of ghostscript 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=ghostscript
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/o/ocrmypdf/20818050/log.gz
> 
> === FAILURES 
> ===
>  test_force_ocr 
> 
> 
> resources = 
> PosixPath('/tmp/autopkgtest-lxc.zdbcipww/downtmp/build.V8r/src/tests/resources')
> outpdf = PosixPath('/tmp/pytest-of-debci/pytest-0/test_force_ocr0/out.pdf')
> 
>def test_force_ocr(resources, outpdf):
>out = check_ocrmypdf(
>resources / 'graph_ocred.pdf',
>outpdf,
>'-f',
>'--plugin',
>'tests/plugins/tesseract_cache.py',
>)
>pdfinfo = PdfInfo(out)
>>  assert pdfinfo[0].has_text
> E   assert False
> E+  where False =  7.573"x6.16" rotation=0 dpi=400.00x400.00 
> has_text=False>.has_text
> 
> tests/test_main.py:83: AssertionError
> - Captured stderr call 
> -
> 
> Scanning contents:   0%|  | 0/1 [00:00 Scanning contents: 100%|██| 1/1 [00:00<00:00, 62.30page/s]
> 
> OCR:   0%|  | 0.0/1.0 [00:00 OCR:  50%|█ | 0.5/1.0 [00:02<00:02,  5.47s/page]
> OCR: 100%|██| 1.0/1.0 [00:02<00:00,  2.75s/page]
> 
> PDF/A conversion:   0%|  | 0/1 [00:00 
> Recompressing JPEGs: 0image [00:00, ?image/s]
> Recompressing JPEGs: 0image [00:00, ?image/s]
> 
> 
> Deflating JPEGs:   0%|  | 0/1 [00:00 Deflating JPEGs: 100%|██| 1/1 [00:00<00:00, 74.34image/s]
> 
> 
> JBIG2: 0item [00:00, ?item/s]
> JBIG2: 0item [00:00, ?item/s]
> -- Captured log call 
> ---
> INFO ocrmypdf._pipeline:_pipeline.py:275 page already has text! - 
> rasterizing text and running OCR anyway
> INFO ocrmypdf._sync:_sync.py:301 Postprocessing...
> WARNING  ocrmypdf._pipeline:_pipeline.py:776 Some input metadata could not be 
> copied because it is not permitted in PDF/A. You may wish to examine the 
> output PDF's XMP metadata.
> INFO ocrmypdf.optimize:optimize.py:665 Optimize ratio: 1.52 savings: 34.1%
> INFO ocrmypdf._sync:_sync.py:399 Output file is a PDF/A-2B (as expected)
> WARNING  ocrmypdf._validation:_validation.py:381 The output file size is 
> 2.45× larger than the input file.
> Possible reasons for this include:
> The argument --force-ocr was issued, causing transcoding.
> The optional dependency 'jbig2' was not found, so some image optimizations 
> could not be attempted.
> PDF/A conversion was enabled. (Try `--output-type pdf`.)
> Plugins were used.
> --- Captured stderr teardown 
> ---
> 
> PDF/A conversion: 100%|██| 1/1 [00:01<00:00,  1.20s/page]
>  test_skip_ocr 
> _
> 
> resources = 
> PosixPath('/tmp/autopkgtest-lxc.zdbcipww/downtmp/build.V8r/src/tests/resources')
> outpdf = PosixPath('/tmp/pytest-of-debci/pytest-0/test_skip_ocr0/out.pdf')
> 
>def test_skip_ocr(resources, outpdf):
>out = check_ocrmypdf(
>resources / 'graph_ocred.pdf',
>outpdf,
>'-s',
>'--plugin',
>'tests/plugins/tesseract_cache.py',
>)
>pdfinfo = PdfInfo(out)
>>  assert pdfinfo[0].has_text
> E   assert False
> E+  where False =  7.573"x6.16" rotation=0 dpi=150.00x150.00 

Bug#1008426: h2o: diff for NMU version 2.2.5+dfsg2-6.2

[Anton Gladky]

I do not have this tag as I did not repack a tarball.

Anton

Am Mi., 13. Apr. 2022 um 22:47 Uhr schrieb Chris Hofstaedtler :
>
> Hi Anton,
>
> * Anton Gladky  [220412 19:18]:
> > thanks a lot for NMU! Feel free to upload immediately,
> > but please commit your changes into the git. Thanks!
>
> okay, can/will do. Could you push the tag tags/upstream/2.2.5+dfsg2 into
> git?
>
> I have cancelled the NMU in the meantime.
>
> Thanks,
> Chris
>

Bug#1009703: grafx2: Grafx2 text tool true-type font rendering is garbled

[Ryan Armstrong]

On Thu, 2022-04-14 at 17:30 +, Adrien Destugues wrote:
> 14 avril 2022 18:22 "Ryan Armstrong"  a écrit:
> 
> > When I attempt to use the text tool in recent versions of Grafx2,
> > the
> > font rendering is garbled for all True-Type fonts. If I press OK,
> > the
> > resulting brush is the same way. See attachment for an example.
> > 
> > I previously used the text tool in December 2021 and did not have
> > the
> > problem then.
> 
> Thanks for reporting, I'll see if I can reproduce this.
> 
> > As an aside, the upstream bug tracker appears to be misconfigured
> > and
> > the Google login reports "Error 400: redirect_uri_mismatch".
> 
> This happens when you are not using https. Please use https to access
> the bugtracker.
> 

Ah, it seems the URL that Debian points to is just for HTTP (e.g.
from https://tracker.debian.org/pkg/grafx2). Let me know if you'd like
me to raise anything in the upstream tracker.

Ryan

Bug#1009705: RM: socat/experimental -- ROM; abandoned version

[GCS]

Package: ftp.debian.org
Severity: normal

Hi FTP Masters,

Upstream started experimenting with new features with version number
2.0.0~beta. Then this numbering was abandoned and only 1.7.x versions
continued with development.
Please remove socat/2.0.0~beta9-1 from experimental as it's just
confusing users.

Thanks,
Laszlo/GCS

Bug#965418: asql: diff for NMU version 1.6-1.2

[Joao Eriberto Mota Filho]

Package: asql
Version: 1.6-1.1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for asql (versioned as 1.6-1.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

diff -Nru asql-1.6/debian/changelog asql-1.6/debian/changelog
--- asql-1.6/debian/changelog   2021-01-05 14:29:40.0 -0300
+++ asql-1.6/debian/changelog   2022-04-14 13:40:34.0 -0300
@@ -1,3 +1,18 @@
+asql (1.6-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Using new DH level format. Consequently:
+  - debian/compat: removed.
+  - debian/control: changed from 'debhelper' to 'debhelper-compat' in
+Build-Depends field and bumped level to 13.
+  - debian/rules: using 'dh_prep' instead of 'dh_clean -k' because the
+'-k' option is not supported since compat 12.
+  - Closes: #965418
+  * debian/rules: added missing targets build-arch and build-indep.
+(Closes: #999113)
+
+ -- Joao Eriberto Mota Filho   Thu, 14 Apr 2022 13:40:34 
-0300
+
 asql (1.6-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru asql-1.6/debian/compat asql-1.6/debian/compat
--- asql-1.6/debian/compat  2010-10-04 17:19:07.0 -0300
+++ asql-1.6/debian/compat  1969-12-31 21:00:00.0 -0300
@@ -1 +0,0 @@
-5
diff -Nru asql-1.6/debian/control asql-1.6/debian/control
--- asql-1.6/debian/control 2010-10-04 17:19:07.0 -0300
+++ asql-1.6/debian/control 2022-04-14 13:40:34.0 -0300
@@ -2,7 +2,7 @@
 Section: admin
 Priority: optional
 Maintainer: Steve Kemp 
-Build-Depends: debhelper (>> 5.0.0)
+Build-Depends: debhelper-compat (= 13)
 Standards-Version: 3.8.4
 Homepage: http://www.steve.org.uk/Software/asql/
 
diff -Nru asql-1.6/debian/rules asql-1.6/debian/rules
--- asql-1.6/debian/rules   2010-10-04 17:19:07.0 -0300
+++ asql-1.6/debian/rules   2022-04-14 13:40:34.0 -0300
@@ -25,7 +25,7 @@
 install: build
dh_testdir
dh_testroot
-   dh_clean -k
+   dh_prep
dh_installdirs
make install PREFIX=`pwd`/debian/asql
mkdir -p `pwd`/debian/asql/usr/share/man/man8/
@@ -51,4 +51,6 @@
 # We have nothing to do here
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install 
+build-arch: build
+build-indep: build
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary 
install

Bug#1009704: RM: company-lsp -- ROM; obsolete

[Thomas Koch]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: tho...@koch.ro

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

company-lsp is no longer supported by emacs-lsp:

"Dropped support for company-lsp, the suggested provider is company-capf."
https://emacs-lsp.github.io/lsp-mode/page/CHANGELOG/#release-701
https://github.com/emacs-lsp/lsp-mode/commit/e80282163ac162f1d6ae813636037f37a91e001a

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAmJYVLQACgkQB/xIkQQr
plqr4g//ZzVJiK21wB6R8+ZqXTe6lYDDgdblQjiBiRWnwhoIE0Cw1Oa47ldkg3nt
7XRFunX1YfQH7IZcBPyRZFO7AADTI/pQJzrpbIoJsCf1QUqvyxvCUZ28daLJZmBx
bBhtZRqFkqxuOUR69bn1q65h3cWRpZagHYOVSqSEEe4kHT+1wkd0jJ2XLl1fKcCS
o66Hk9+dhSo7VXQzOHti9wEnbDRBCrL1Vum6/rZWBvSR2xk5WaCTiD9HgWHiEs31
4vZ+dNdb/THXvYh9ORu2bEADMd20tSX9pYdozrUTkf1rb/oZ4fsNmzctzQrwf6rJ
D/VGwRFlVii8GtHsyc6UMrAWi20zNsA+Nd0lYps8n7sy60NEV6YQFsOUpTAo/+Ve
fg7+4pIRm9r47L9GEMm3t2m1TdofU767nnMoNmttuR1A1aef34YN3aUSr1/nuE8R
/nsjMVqfcO/cm1E4nRTO6MBFEH4IRiITk+HEyp6NfCwpoI2CRBdiH+1XUBMziTuU
mOmacvgjgeyAUCrwkVXJq3AmsDyecHyhn+DFRrVVhT9u1H3G2xmpw5VlvQNGU2k4
yXuHY5ECh6mOz+r7HVI8v84Hd9//2THpNYjhv5MdGSQTjIKJdHpN0ncvlulTS3hm
u91Fjdd1499j/IDUtYWeuJm8OkwynwA7acytr3LB1WRSr+btA+w=
=P6s+
-END PGP SIGNATURE-

Bug#1009014: installation-reports: Successful install on Pine64 Rock64 using serial console

[Vagrant Cascadian]

On 2022-04-05, Vagrant Cascadian wrote:
> I should see if it works via HDMI sometime...

HDMI support required tracking down two modules already enabled in the
linux kernel but not present in the udebs used by debian-installer. This
should be fixed in the next linux upload:

  
https://salsa.debian.org/kernel-team/linux/-/commit/72be9f5b88b49b73dfd1461fdfd3c6ae1792db81


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1009703: grafx2: Grafx2 text tool true-type font rendering is garbled

[Adrien Destugues]

14 avril 2022 18:22 "Ryan Armstrong"  a écrit:

> When I attempt to use the text tool in recent versions of Grafx2, the
> font rendering is garbled for all True-Type fonts. If I press OK, the
> resulting brush is the same way. See attachment for an example.
> 
> I previously used the text tool in December 2021 and did not have the
> problem then.

Thanks for reporting, I'll see if I can reproduce this.

> As an aside, the upstream bug tracker appears to be misconfigured and
> the Google login reports "Error 400: redirect_uri_mismatch".

This happens when you are not using https. Please use https to access the 
bugtracker.

-- 
Adrien.

Bug#1008312: clementine: diff for NMU version 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1

[Florian Ernst]

Control: tags 1008312 + patch
Control: tags 1008312 + pending

Dear maintainer,

I've prepared an NMU for clementine (versioned as
1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1) and uploaded it to DELAYED/7.
Please feel free to tell me if I should delay it longer.

I have verified that adding an explicit Depends on libqt5sql5-sqlite
allows clementine to start again and play some stuff as follows:
- create minimal chroot and enter
- install clementine via "apt install --no-install-recommends clementine"
- start clementine -> fails as reported
- install libqt5sql5-sqlite
- start clementine -> starts and allows to play music

Please note that this bug also affects current stable, i.e. bullseye, and
should be fixed there as well, as per
.

Best regards,
Flo
diff -Nru clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog	2022-02-12 18:15:45.0 +0100
+++ clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog	2022-04-14 18:00:57.0 +0200
@@ -1,3 +1,10 @@
+clementine (1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add explicit Depends on libqt5sql5-sqlite (Closes: #1008312)
+
+ -- Florian Ernst   Thu, 14 Apr 2022 18:00:57 +0200
+
 clementine (1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2) unstable; urgency=medium
 
   [ Pino Toscano ]
diff -Nru clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control
--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control	2020-10-27 11:47:50.0 +0100
+++ clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control	2022-04-14 17:26:41.0 +0200
@@ -38,6 +38,7 @@
 Package: clementine
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
+ libqt5sql5-sqlite,
  gstreamer1.0-plugins-base,
  gstreamer1.0-plugins-good,
  gstreamer1.0-plugins-ugly


signature.asc
Description: PGP signature

Bug#1009703: grafx2: Grafx2 text tool true-type font rendering is garbled

[Ryan Armstrong]

Package: grafx2
Version: 2.8+ds-2
Severity: normal
Tags: upstream

Dear Maintainer,

When I attempt to use the text tool in recent versions of Grafx2, the
font rendering is garbled for all True-Type fonts. If I press OK, the
resulting brush is the same way. See attachment for an example.

I previously used the text tool in December 2021 and did not have the
problem then.

As an aside, the upstream bug tracker appears to be misconfigured and
the Google login reports "Error 400: redirect_uri_mismatch".

Ryan

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

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

Versions of packages grafx2 depends on:
ii  fonts-tuffy  20120614-2.1
ii  libc62.33-7
ii  libfontconfig1   2.13.1-4.4
ii  liblua5.3-0  5.3.6-1
ii  libpng16-16  1.6.37-3
ii  libsdl2-2.0-02.0.20+dfsg-2
ii  libsdl2-image-2.0-0  2.0.5+dfsg1-3+b1
ii  libsdl2-ttf-2.0-02.0.18+dfsg-2
ii  libtiff5 4.3.0-6
ii  libx11-6 2:1.7.5-1
ii  zlib1g   1:1.2.11.dfsg-4

grafx2 recommends no packages.

grafx2 suggests no packages.

-- no debconf information

Bug#1009068: xcalib: diff for NMU version 0.8.dfsg1-3

[Boyuan Yang]

Control: tags -1 +patch  +pending


Dear maintainer,

I've prepared an NMU for xcalib (versioned as 0.8.dfsg1-3) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru xcalib-0.8.dfsg1/debian/changelog xcalib-0.8.dfsg1/debian/changelog
--- xcalib-0.8.dfsg1/debian/changelog   2022-04-14 11:55:34.0 -0400
+++ xcalib-0.8.dfsg1/debian/changelog   2022-04-14 11:35:33.0 -0400
@@ -1,3 +1,17 @@
+xcalib (0.8.dfsg1-3) unstable; urgency=medium
+
+  * QA upload.
+  * Take over package maintenance via ITS process. (Closes: 1009068)
+  * debian/control:
++ Bump Standards-Version to 4.6.0.
++ Bump debhelper compat to v13. (Closes: #965887)
++ Convert package to "3.0 (quilt)" format.
+  * debian/rules: Convert to dh sequencer.
+  * debian/patches/0001-use-autoconf.patch: Add patch to use autoconf
+and automake instead of manually-written Makefile.
+
+ -- Boyuan Yang   Thu, 14 Apr 2022 11:35:33 -0400
+
 xcalib (0.8.dfsg1-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xcalib-0.8.dfsg1/debian/compat xcalib-0.8.dfsg1/debian/compat
--- xcalib-0.8.dfsg1/debian/compat  2022-04-14 11:55:34.0 -0400
+++ xcalib-0.8.dfsg1/debian/compat  1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-5
diff -Nru xcalib-0.8.dfsg1/debian/control xcalib-0.8.dfsg1/debian/control
--- xcalib-0.8.dfsg1/debian/control 2022-04-14 11:55:34.0 -0400
+++ xcalib-0.8.dfsg1/debian/control 2022-04-14 11:15:35.0 -0400
@@ -1,9 +1,9 @@
 Source: xcalib
 Section: x11
 Priority: optional
-Maintainer: Jorge Salamero Sanz 
-Build-Depends: debhelper (>= 5), libxxf86vm-dev, libxext-dev
-Standards-Version: 3.8.0
+Maintainer: Debian QA Group 
+Build-Depends: debhelper-compat (= 13), libxxf86vm-dev, libxext-dev
+Standards-Version: 4.6.0
 Homepage: http://xcalib.sourceforge.net/
 
 Package: xcalib
diff -Nru xcalib-0.8.dfsg1/debian/dirs xcalib-0.8.dfsg1/debian/dirs
--- xcalib-0.8.dfsg1/debian/dirs2022-04-14 11:55:34.0 -0400
+++ xcalib-0.8.dfsg1/debian/dirs1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/usr/bin
diff -Nru xcalib-0.8.dfsg1/debian/patches/0001-use-autoconf.patch xcalib-
0.8.dfsg1/debian/patches/0001-use-autoconf.patch
--- xcalib-0.8.dfsg1/debian/patches/0001-use-autoconf.patch 1969-12-31
19:00:00.0 -0500
+++ xcalib-0.8.dfsg1/debian/patches/0001-use-autoconf.patch 2022-04-14
11:35:33.0 -0400
@@ -0,0 +1,77 @@
+From: Boyuan Yang 
+Date: Thu, 14 Apr 2022 11:32:38 -0400
+Subject: use autoconf
+
+---
+ Makefile.am |  9 +
+ configure.ac| 40 
+ m4/.placeholder |  0
+ 3 files changed, 49 insertions(+)
+ create mode 100644 Makefile.am
+ create mode 100644 configure.ac
+ create mode 100644 m4/.placeholder
+
+diff --git a/Makefile.am b/Makefile.am
+new file mode 100644
+index 000..096b39a
+--- /dev/null
 b/Makefile.am
+@@ -0,0 +1,9 @@
++ACLOCAL_AMFLAGS = -I m4
++
++bin_PROGRAMS = xcalib
++
++xcalib_SOURCES = xcalib.c
++xcalib_CFLAGS = @X_CFLAGS@
++# AX_PATH_XTRA only specify the root of X11
++# we still have to include -lX11 ourselves
++xcalib_LDFLAGS = @X_LIBS@ -lX11 -lm -lXxf86vm -lXext
+diff --git a/configure.ac b/configure.ac
+new file mode 100644
+index 000..0a0e624
+--- /dev/null
 b/configure.ac
+@@ -0,0 +1,40 @@
++#   -*- Autoconf -*-
++# Process this file with autoconf to produce a configure script.
++
++AC_PREREQ([2.69])
++AC_INIT([xcalib], [0.8], [http://xcalib.sourceforge.net/])
++AC_DEFINE([XCALIB_VERSION], ["0.8"], [XCalib version])
++
++AC_CONFIG_SRCDIR([xcalib.c])
++AC_CONFIG_HEADERS([config.h])
++AC_CONFIG_AUX_DIR([build-aux])
++AC_CONFIG_MACRO_DIR([m4])
++
++AM_INIT_AUTOMAKE([foreign])
++
++# Checks for programs.
++AC_PROG_CC
++
++# Checks for libraries.
++AC_PATH_XTRA
++AS_IF([test "X$no_x" = "Xyes"],
++  [AC_MSG_ERROR([Could not find X11])])
++AC_CHECK_LIB([X11], [XOpenDisplay], , [AC_MSG_ERROR([Could not find X11])])
++AC_CHECK_LIB([Xext], [XextAddDisplay], , [AC_MSG_ERROR([Could not find
Xext])])
++AC_CHECK_LIB([Xxf86vm], [XF86VidModeQueryExtension], , [AC_MSG_ERROR([Could
not find Xxf86vm])])
++# No FGLRX support for now
++AC_CHECK_LIB([m], [sin])
++
++# Checks for header files.
++AC_PATH_X
++AC_CHECK_HEADERS([fcntl.h])
++
++# Checks for typedefs, structures, and compiler characteristics.
++
++# Checks for library functions.
++AC_FUNC_ERROR_AT_LINE
++AC_FUNC_MALLOC
++AC_CHECK_FUNCS([pow])
++
++AC_CONFIG_FILES([Makefile])
++AC_OUTPUT
+diff --git a/m4/.placeholder b/m4/.placeholder
+new file mode 100644
+index 000..e69de29
diff -Nru xcalib-0.8.dfsg1/debian/patches/0002-xcalib.c-Include-config.h.patch
xcalib-0.8.dfsg1/debian/patches/0002-xcalib.c-Include-config.h.patch
--- xcalib-0.8.dfsg1/debian/patches/0002-xcalib.c-Include-
config.h.patch  1969-12-31 19:00:00.0 -0500
+++ xcalib-0.8.dfsg1/debian/patches/0002-xcalib.c-Include-

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

[Matthew Vernon]

Hi,

Thanks to everyone for your contributions to this discussion. I think 
we're at the point where voting is appropriate.


I propose a ballot as follows - if no-one suggests further options in 
the mean time, I will call for a vote on this ballot on Tuesday, after 
the weekend of public holidays.


===Rationale

There are two "rename" programs - the perl rename, and the util-linux 
rename. Debian and its derivatives have shipped the perl rename as 
/usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped 
the util-linux rename thus. The two implementations are incompatible. 
Users might reasonably desire both implementations to be available on 
the same system.


Backwards-compatibility (and the lack of a compelling argument that 
util-linux's rename is significantly superior to the perl rename) means 
that /usr/bin/rename in Debian should remain the perl rename.


Prior to bullseye, util-linux's rename was shipped as 
/usr/bin/rename.ul; Debian's users who wish to use util-linux's rename 
will expect it to be in this location.


===End Rationale

===Begin Resolution

The Technical Committee resolves that util-linux's rename should be 
shipped in a binary package build from src:util-linux. If this package 
Conflicts with the rename package, then it should not contain any other 
binaries.


The Technical Committee overrides the util-linux maintainer, and 
requires that this binary should be shipped as /usr/bin/rename.ul


===End Resolution

A: Approve resolution, including override of util-linux maintainer
B: Approve only first paragraph of resolution
N: None of the above

Regards,

Matthew
ps; my first TC resolution, please be gentle if I have the procedure wrong!

Bug#1009702: NEWS file is not included in binary packages

[Sébastien Villemot]

Source: python-mkdocs
Version: 1.3.0+dfsg-1
Severity: minor

Dear Maintainer,

The source package includes a NEWS file (debian/python-mkdocs.NEWS), but it is
not included in binary packages.

It should be renamed to either debian/NEWS or debian/mkdocs.NEWS.

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#996965: shiny-server in debian

[Andreas Tille]

Hi,

Am Thu, Apr 14, 2022 at 11:26:58AM +0200 schrieb Andreas Tille:
> I did a next step in
> 
>
> https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/commit/7d066e14383753156d851e81b0db9e21665ce861
>  
> 
> where I simply try the patience of ftpmaster to accept binary fonts.
> I'll now try to sort out the licenses of the different bootstrap
> versions and hope to upload soon to new.

I've managed to exclude bootstrap3 but there are issues with the
Debian packaged bootstrap4 which I've reported upstream[1].  I'm now
checking what I can do for boostrap5 (besides removing it completely
for the moment and hoping that we can go with boostrap[34] as long
as version 5 is not packaged yet (I do not have a better idea right
now :-()

So far for the status of bslib

Andreas.

[1] https://github.com/rstudio/bslib/issues/422 

-- 
http://fam-tille.de

Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Antoine Beaupré]

On 2022-04-13 17:26:27, Gabriel Filion wrote:
> Hi there,
>
> For what it's worth, upstream puppet does not yet suppport ruby 3.0.
>
> see: https://puppet.com/docs/puppet/7/release_notes_puppet.html
>
> puppet 7 added support for ruby 2.7 but 2.9 and 3.0 were never there 
> upstream. I'm guessing they'll bump to 3.x for the puppet 8 cycle only.

That's actually not quite correct: Puppet 7.8 added support for Ruby 3,
so we should be able to jump there.

It is my hope that we can ship Puppet agent 6 and Puppet server 7 in
bookworm to fix all of those issues in one fell swoop. See:

https://alioth-lists.debian.net/pipermail/pkg-puppet-devel/2022-April/012681.html

I don't think it's worth fixing the Puppet 5.5 packages to be honest,
our energy is better spent updating to upstream packages.

-- 
That's the kind of society I want to build. I want a guarantee - with
physics and mathematics, not with laws - that we can give ourselves
real privacy of personal communications.
 - John Gilmore

Bug#1008818: needrestart: creates root-owned .rpmdb in non-root user $HOME, possibly corrupting existing one

[Thorsten Glaser]

reassign 1008818 rpm
found 1008818 4.16.1.2+dfsg1-3
affects 1008818 needrestart
thanks

Patrick Matthäi dixit:

> Since this file also comes from rpm itself I think you agree this is not a bug
> in needrestart?

Not sure.

On one side, “rpm -qa” will create the directory in my home directory as
myself, but “sudo rpm -qa” will do the wrong thing. On the other hand,
it’s needrestart that calls it…

I agree it’s probably worth trying to reassign to rpm to get this fixed
also for the normal “sudo rpm -qa” use case first, before adding extra
workarounds in needrestart.

(Unsure if either fix would make it into stable…)

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#1008668: bug #1008668: tomcat9: logrotated is not able to truncate catalina.out

[Thorsten Glaser]

On Thu, 14 Apr 2022, Utkarsh Gupta wrote:

> The submitter has provided a debdiff, too:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1008668;filename=tomcat9_9.0.58-1ubuntu1.debdiff;msg=5.

This will break other syslog implementations, though.

What is the problem with logrotate? It happily rotates files
owned by anyone in Debian.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1008668: bug #1008668: tomcat9: logrotated is not able to truncate catalina.out

[Markus Koschany]

Am Donnerstag, dem 14.04.2022 um 16:23 +0530 schrieb Utkarsh Gupta:
> Hi Emmanuel,
> 
> We have bug #1008668 that's causing problems on the Ubuntu side and is
> also reproducible via the Debian package (essentially, it's the same
> in both places).

Hi Utkarsh,

I have been trying to reproduce this problem but on an up-to-date Debian system
running tomcat9 version 9.0.58-1 I cannot reproduce it. catalina.out is
truncated when I run 

logrotate -f /etc/logrotate.d/tomcat9

The logrotate file changes the permissions to "su tomcat adm" which is
sufficient to operate on tomcat9 log files. I'm not familiar with the Ubuntu
differences when it comes to logrotate and rsyslogd but I suppose that is the
underlying issue here. It would be strange if we had to change the permissions
to syslog adm because other Debian packages also own log files with their
specific users and then does not cause any problems too.

Thus said I am not against fixing this for Ubuntu but the current approach
seems wrong to me.

Regards,

Markus




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

Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020

[Antoine Beaupré]

Control: severity -1 serious

Justification: this package depends on ruby 2.7, gone from bookworm. See
below.

On 2022-04-14 10:12:25, Gabriel Filion wrote:
> in current debian testing, ruby has been transitioned to 3.0 and judging 
> from the release history, puppet has not added support for ruby 3.0 
> until 7.8.0:
>
> https://puppet.com/docs/puppet/7/release_notes_puppet.html#enhancements_puppet_x-7-8-0-pup-11076
>
> and also, as was noted in #1009643 the puppet tests fail on 3.0 which 
> seems to indicate that supporting puppet 5.5 in debian testing will be 
> quite difficult.
>
> Because of that information I think we should aim for removing puppet 5 
> from testing and then move on to the discussion of packaging future 
> versions.
>
> that same argument about ruby 3.0 support would lead me to believe that 
> aiming for puppet 6 would be a mistake (that and the EOL date for puppet 
> 6 which will be very close to a debian release).

Agreed. Let's remove it for now. When we land a Puppet agent 7 here,
this bug can be closed and the package will migrate down to bookworm
again.

> in the #puppet channel on chat.libera.net, a couple poeple told me that 
> since puppet 4.x the differences in terms of manifests are mostly 
> additive and don't see many breakage at all between major versions, and 
> that would be true until at least puppet 7. so it should be possible for 
> users to jump from 5 to 7 directly

I proposed as much in the "policy" thread, so I think that would really
make a lot of sense. Worst case, this fails and we *also* need to
package Puppet server 6 in fasttrack.

Thanks for the heads up.

a.

-- 
Le péché est né avant la vertu, comme le moteur avant le frein.
 - Jean-Paul Sartre

Bug#999912: libpython3.10-stdlib,python3-gdbm: both ship /usr/lib/python3.10/lib-dynload/_dbm.cpython-310-x86_64-linux-gnu.so

[Samuel Hym]

Control: reassign 12 python3-gdbm 3.10.0~b1-3
Control: notfound 12 3.9.12-1

Hi,

You reported a conflict between a package in unstable
(libpython3-stdlib) and a package in experimental
(python3-gdbm/3.10.0~b1-3).
Surely the bug should be reported against the package in experimental,
if at all, shouldn’t it?

Anyway, at least right now, there is no conflict between the packages
in unstable.

Cheers,

-- 
Samuel

Bug#830904: a proposal to salvage Puppet Debian packages

[Antoine Beaupré]

On 2022-03-30 11:28:09, Antoine Beaupré wrote:
> Hi,

Following up on my own thread, two weeks later.

> TL:DR; (1) I want to join the team (2) let's package puppet agent 6
> clean, then puppetserver 6 and/or 7 for bookworm.

It seems I was granted access to the Puppet team on salsa, thanks! :)

And since then, I noticed some critical information that I hadn't
noticed before: Ruby 2.7 was removed from bookworm.

https://tracker.debian.org/news/1311269/ruby27-removed-from-testing/

This means that any Puppet version before Puppet 7.8 will likely not run
in Debian bookworm at all, since that's the first version which added
support for Ruby 3+:

https://puppet.com/docs/puppet/7/release_notes_puppet.html#release_notes_puppet_7-8-0

I still think my proposal makes sense. We should focus on upgrading the
client to Puppet agent 6, which should hopefully survive that transition
regardless. Then we could focus on packaging Puppet Server *seven*,
since it *will* be compatible with the Puppet agent 6. We would, in
effect, be skipping Puppet Server 6.

This has a few implications for our users. They will either need to:

 * upgrade everything at once, that is: upgrade the server from Puppet
   master 5 to Puppet server 7, and *simultaneously* upgrade from Puppet
   agent 5 to Puppet agent 6 (an alternative would be to setup a
   different Puppet server 7 and migrate machines over to that server
   progressively, but this could be messy with exported resources)

 * use the upstream packages for Puppet server 6 while the fleet is
   upgraded to Puppet agent 6, then switch back to the Debian package
   for Puppet server 7

I don't really see another way around this, because Puppet server 6
can't possibly work in Debian bookworm and above anymore, because of the
Ruby 2.7 removal.

The Puppet Server 7 work could happen in th Clojure team sprint in May,
which would land us a Puppet server ready for the bookworm freeze.

We *could* also work on Puppet server 6 and "fast track" it to bullseye:

https://fasttrack.debian.net/

But that feels like duplication of work a little. If I would have to
choose between Puppet server 6 and 7, I would choose the latter. And
given how much availability we all seem to have to work on this problem,
it *does* seem like we need to choose.

If there are no objections, I'll start working on the agent 6 in the
next few weeks/months.

Thanks for any feedback,

A.
-- 
In serious work commanding and discipline are of little avail.
 - Peter Kropotkin

Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020

[Gabriel Filion]

Hi there,

I'm just chiming in to add yet another object on the scale:

in current debian testing, ruby has been transitioned to 3.0 and judging 
from the release history, puppet has not added support for ruby 3.0 
until 7.8.0:


https://puppet.com/docs/puppet/7/release_notes_puppet.html#enhancements_puppet_x-7-8-0-pup-11076

and also, as was noted in #1009643 the puppet tests fail on 3.0 which 
seems to indicate that supporting puppet 5.5 in debian testing will be 
quite difficult.


Because of that information I think we should aim for removing puppet 5 
from testing and then move on to the discussion of packaging future 
versions.



that same argument about ruby 3.0 support would lead me to believe that 
aiming for puppet 6 would be a mistake (that and the EOL date for puppet 
6 which will be very close to a debian release).



in the #puppet channel on chat.libera.net, a couple poeple told me that 
since puppet 4.x the differences in terms of manifests are mostly 
additive and don't see many breakage at all between major versions, and 
that would be true until at least puppet 7. so it should be possible for 
users to jump from 5 to 7 directly


On Thu, 31 Mar 2022 11:24:34 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= 
 wrote:

On 2022-03-31 17:05:19, Thomas Goirand wrote:
> On 3/29/22 21:08, Antoine Beaupré wrote:
>> On 2020-02-02 13:06:42, Thomas Goirand wrote:
>> 
>> [...]
>> 
>>> FYI, I packaged and uploaded the first 2 so far, but can't push to Git.

>>> Please set me as maintainer or owner, so I can do that.
>>>
>>> Note that I'm doing a git based workflow, packaging upstream tags,
>>> rather than using pristine-tar. If this bothers anyone, please let me
>>> know (but please only complain about the workflow if you really have the
>>> intention to contribute to the packaging, otherwise you're just getting
>>> on my way to be efficient for no reason).
>> 
>> Not sure I'm picking the right message to reply to here, but here we go.
>> 
>> I see that you uploaded 6.16.0-1 to experimental back in December 2020:
>> 
>> https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/
>> 
>> Is that package in any shape to ship with bookworm? It would be great to

>> start this transition to get the package down into testing soon...
>
> Uploading it will break current puppet-master. Unless we have a solution 
> to replace it, I don't want to do that...


I understand that, but my perspective is that we *want* to break the
current, 5.5 puppet master. We do *not* want to ship that in
bookworm. So breaking it is acceptable in that sense, to me.

But I guess it's pointless to keep arguing that same point. :)

--
The survival of humans and other species on planet Earth in my view can
only be guaranteed via a timely transition towards a stationary
state, a world economy without growth.
 - Peter Custers

Bug#954883: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug because I can not reproduce it anymore on actual Kodi 
versions.

I just installed Unity skin for test and the installation went smoothly.
This proves the repository is working as expected.

Please feel free to re-open it if the issue remains in 19.x or 20.0 Alpha 
releases.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#935088: giflib: diff for NMU version 5.2.1-2.2

[Mattia Rizzolo]

Control: tags 935088 + patch
Control: tags 935088 + pending


Dear maintainer,

I've prepared an NMU for giflib (versioned as 5.2.1-2.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
diffstat for giflib-5.2.1 giflib-5.2.1

 changelog |9 +
 libgif7.symbols   |1 +
 patches/giflib_quantize.patch |   22 ++
 patches/series|1 +
 4 files changed, 33 insertions(+)

diff -Nru giflib-5.2.1/debian/changelog giflib-5.2.1/debian/changelog
--- giflib-5.2.1/debian/changelog	2021-06-07 14:41:34.0 +0200
+++ giflib-5.2.1/debian/changelog	2022-04-14 16:06:15.0 +0200
@@ -1,3 +1,12 @@
+giflib (5.2.1-2.2) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Fedora (giflib_quantize.patch) to reinstate
+GifQuantizeBuffer into giflib.so.  Closes: #935088
+  * Re-add the symbols in libgif7.symbols.
+
+ -- Mattia Rizzolo   Thu, 14 Apr 2022 16:06:15 +0200
+
 giflib (5.2.1-2.1) experimental; urgency=medium
 
   * Non-maintainer upload.
diff -Nru giflib-5.2.1/debian/libgif7.symbols giflib-5.2.1/debian/libgif7.symbols
--- giflib-5.2.1/debian/libgif7.symbols	2019-08-18 11:55:51.0 +0200
+++ giflib-5.2.1/debian/libgif7.symbols	2022-04-14 16:06:15.0 +0200
@@ -54,6 +54,7 @@
  GifFreeSavedImages@Base 5.1
  GifMakeMapObject@Base 5.1
  GifMakeSavedImage@Base 5.1
+ GifQuantizeBuffer@Base 5.1
  GifUnionColorMap@Base 5.1
  _ClearHashTable@Base 5.1
  _ExistsHashTable@Base 5.1
diff -Nru giflib-5.2.1/debian/patches/giflib_quantize.patch giflib-5.2.1/debian/patches/giflib_quantize.patch
--- giflib-5.2.1/debian/patches/giflib_quantize.patch	1970-01-01 01:00:00.0 +0100
+++ giflib-5.2.1/debian/patches/giflib_quantize.patch	2022-04-14 16:05:56.0 +0200
@@ -0,0 +1,22 @@
+Description: Move quantize.c back into libgif.so
+Origin: other, fedora https://src.fedoraproject.org/rpms/giflib/c/109bf038d703a471b857aba44af673be103d7079
+Bug: https://sourceforge.net/p/giflib/bugs/142/
+Bug-Debian: https://bugs.debian.org/935088
+
+diff -rupN giflib-5.2.1/Makefile giflib-5.2.1-new/Makefile
+--- giflib-5.2.1/Makefile	2019-06-24 18:08:57.0 +0200
 giflib-5.2.1-new/Makefile	2019-10-01 13:02:33.227952230 +0200
+@@ -29,11 +29,11 @@ LIBPOINT=0
+ LIBVER=$(LIBMAJOR).$(LIBMINOR).$(LIBPOINT)
+ 
+ SOURCES = dgif_lib.c egif_lib.c gifalloc.c gif_err.c gif_font.c \
+-	gif_hash.c openbsd-reallocarray.c
++	gif_hash.c openbsd-reallocarray.c quantize.c
+ HEADERS = gif_hash.h  gif_lib.h  gif_lib_private.h
+ OBJECTS = $(SOURCES:.c=.o)
+ 
+-USOURCES = qprintf.c quantize.c getarg.c 
++USOURCES = qprintf.c getarg.c
+ UHEADERS = getarg.h
+ UOBJECTS = $(USOURCES:.c=.o)
+ 
diff -Nru giflib-5.2.1/debian/patches/series giflib-5.2.1/debian/patches/series
--- giflib-5.2.1/debian/patches/series	2019-08-25 18:10:35.0 +0200
+++ giflib-5.2.1/debian/patches/series	2022-04-14 16:06:08.0 +0200
@@ -1 +1,2 @@
 30_link_utils_dynamically.diff
+giflib_quantize.patch


signature.asc
Description: PGP signature

Bug#860486: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug because the solution is documented on Kodi Wiki and
I update it accordingly to new Debian releases.

Please feel free to re-open it if the issue remains in 19.x or 20.0 Alpha 
releases.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#919627: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug because I can not reproduce it anymore on actual Kodi 
versions.
Please feel free to re-open it if the issue remains in 19.x or 20.0 Alpha 
releases.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1009701: opencpn: Wrong gtk linkage causes plugin incompatibility

[Alec Leamas]

Upstream bug: https://github.com/OpenCPN/OpenCPN/issues/2612

Bug#998128: giflib: diff for NMU version 5.1.9-2.1

[Mattia Rizzolo]

Control: tags 998128 + pending


Dear maintainer,

I've prepared an NMU for giflib (versioned as 5.1.9-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
diffstat for giflib-5.1.9 giflib-5.1.9

 changelog   |9 +
 control |3 ++-
 libgif-dev.install  |1 +
 pkgconfig/libgif7.pc.in |   10 ++
 rules   |   18 +-
 5 files changed, 39 insertions(+), 2 deletions(-)

diff -Nru giflib-5.1.9/debian/changelog giflib-5.1.9/debian/changelog
--- giflib-5.1.9/debian/changelog	2020-12-20 22:07:35.0 +0100
+++ giflib-5.1.9/debian/changelog	2022-04-14 15:59:53.0 +0200
@@ -1,3 +1,12 @@
+giflib (5.1.9-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Ship pkg-config information.
+  * Mark libgif-dev as Multi-Arch:same.  (Closes: #998128)
+  * Bump standards version to 4.6.0, no changes required.
+
+ -- Vasyl Gello   Thu, 14 Apr 2022 15:59:53 +0200
+
 giflib (5.1.9-2) unstable; urgency=medium
 
   * New Debian version.
diff -Nru giflib-5.1.9/debian/control giflib-5.1.9/debian/control
--- giflib-5.1.9/debian/control	2020-12-20 22:07:35.0 +0100
+++ giflib-5.1.9/debian/control	2022-04-14 15:56:51.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: David Suárez 
 Build-Depends: debhelper-compat (= 13), xmlto
-Standards-Version: 4.5.0
+Standards-Version: 4.6.0
 Homepage: http://giflib.sourceforge.net/
 Vcs-Git: https://salsa.debian.org/deiv-guest/giflib.git
 Vcs-Browser: https://salsa.debian.org/deiv-guest/giflib
@@ -36,6 +36,7 @@
 Package: libgif-dev
 Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends: libgif7 (= ${binary:Version}), ${misc:Depends}
 Description: library for GIF images (development)
  GIFLIB is a package of portable tools and library routines for working with GIF
diff -Nru giflib-5.1.9/debian/libgif-dev.install giflib-5.1.9/debian/libgif-dev.install
--- giflib-5.1.9/debian/libgif-dev.install	2020-12-20 22:07:35.0 +0100
+++ giflib-5.1.9/debian/libgif-dev.install	2022-04-14 15:56:51.0 +0200
@@ -1,3 +1,4 @@
 /usr/include/*
 /usr/lib/*/*.a
 /usr/lib/*/*.so
+/usr/lib/*/pkgconfig/*
diff -Nru giflib-5.1.9/debian/pkgconfig/libgif7.pc.in giflib-5.1.9/debian/pkgconfig/libgif7.pc.in
--- giflib-5.1.9/debian/pkgconfig/libgif7.pc.in	1970-01-01 01:00:00.0 +0100
+++ giflib-5.1.9/debian/pkgconfig/libgif7.pc.in	2022-04-14 15:56:51.0 +0200
@@ -0,0 +1,10 @@
+prefix=/usr
+exec_prefix=${prefix}
+libdir=${prefix}/lib/@DEB_TARGET_MULTIARCH@
+includedir=${prefix}/include
+
+Name: libgif
+Description: Loads and saves GIF files
+Version: @VERSION@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lgif
diff -Nru giflib-5.1.9/debian/rules giflib-5.1.9/debian/rules
--- giflib-5.1.9/debian/rules	2020-12-20 22:07:35.0 +0100
+++ giflib-5.1.9/debian/rules	2022-04-14 15:56:51.0 +0200
@@ -1,6 +1,12 @@
 #!/usr/bin/make -f
 
-export DEB_BUILD_MAINT_OPTIONS := hardening=+bindnow
+# Include /usr/share/dpkg/pkg-info.mk to get DEB_{SOURCE,VERSION}
+include /usr/share/dpkg/pkg-info.mk
+
+# Include /usr/share/dpkg/architecture.mk to get DEB_HOST_{MULTI,}ARCH
+include /usr/share/dpkg/architecture.mk
+
+export DEB_BUILD_MAINT_OPTIONS := hardening=+all
 export DPKG_GENSYMBOLS_CHECK_LEVEL := 4
 
 doc_html = \
@@ -27,6 +33,16 @@
 		LIBDIR=/usr/lib/$(DEB_TARGET_MULTIARCH)
 
 override_dh_auto_install:
+	# Installing pkgconfig information
+	mkdir -p debian/tmp/usr/lib/$(DEB_TARGET_MULTIARCH)/pkgconfig
+	sed -e "s/@DEB_TARGET_MULTIARCH@/$(DEB_TARGET_MULTIARCH)/" \
+		-e "s/@VERSION@/$(DEB_VERSION_UPSTREAM)/" \
+		debian/pkgconfig/libgif7.pc.in \
+		1>debian/tmp/usr/lib/$(DEB_TARGET_MULTIARCH)/pkgconfig/libgif7.pc
+	ln -sf /usr/lib/$(DEB_TARGET_MULTIARCH)/pkgconfig/libgif7.pc \
+		debian/tmp/usr/lib/$(DEB_TARGET_MULTIARCH)/pkgconfig/libgif.pc
+
+	# Performing an installation step
 	dh_auto_install -- PREFIX=/usr \
 		LIBDIR=/usr/lib/$(DEB_TARGET_MULTIARCH)
 


signature.asc
Description: PGP signature

Bug#979880: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug because I can not reproduce it anymore on actual Kodi 
versions.
Please feel free to re-open it if the issue remains in 19.x or 20.0 Alpha 
releases.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#881286: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug because I can not reproduce it anymore on actual Kodi 
versions.
Please feel free to re-open it if the issue remains in 19.x or 20.0 Alpha 
releases.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1009682: ghostscript breaks openscad autopkgtest

[Torsten Paul]

Hi!

Seems to be caused by bad quoting in the testing script which older ghostscript 
versions ignored.

Upstream issue: https://github.com/openscad/openscad/issues/4218

ciao,
  Torsten.

Bug#1009701: opencpn: Wrong gtk linkage causes plugin incompatibility

[Alec Leamas]

Package: opencpn
Version: 5.6.0+dfsg0-1~bpo10+1
Severity: important

Being a simple backport, current buster-sloppy version is linked against
gtk3 exactly as more recent versions. However, plugins which are 
available for Buster are linked against gtk2. This causes bad crashes 
when trying to load any plugin using available GUI mechanisms.


Trimming down the dependency list since the culprit is known.


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

Kernel: Linux 5.10.103-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) 
(ignored: LC_ALL set to en_US.UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages opencpn depends on:
[...]
ii  libwxbase3.0-0v5  3.0.4+dfsg-8
ii  libwxgtk-webview3.0-gtk3-0v5  3.0.4+dfsg-8
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-8
[...]
~

Bug#709117: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug after I verified CD/DVD tray gets injected after I ask 
Kodi to eject it via JSON-RPC:

'{"id":1,"jsonrpc":"2.0","method":"System.EjectOpticalDrive","params":{}}'

The prerequisite is that user running Kodi must be in "cdrom" group.
However, it is documented in Kodi wiki anyway.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#998419: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug since it is fixed in unstable, testing and stable and
the Security Team decided not to issue a separate DSA for it.

Feel free to re-open the bug if necessary.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#786989: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug after I verified CD/DVD tray gets injected after I ask 
Kodi to eject it via JSON-RPC:

'{"id":1,"jsonrpc":"2.0","method":"System.EjectOpticalDrive","params":{}}'

The prerequisite is that user running Kodi must be in "cdrom" group.
However, it is documented in Kodi wiki anyway.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1009700: qalculate-gtk: restore Russian and Belarus flags

[Antoine Beaupré]

On 2022-04-14 19:47:32, Damir R. Islamov wrote:
> Dear Maintainer,
>
> Due to the political views of the developer Russian and Belarus flags
> were removed from the flag list in qalculate-gtk.
> In addition, the flag of Ukraine is displayed instead or results on every
> first app launch after installing or updating the package.
> The issue is dussscused here 
> https://github.com/Qalculate/qalculate-gtk/issues/389
>
> I find this behavior unacceptable.
>
> The patch restores the normal operation of the application without political 
> overtones.

Considering that upstream rejected that proposal, I'd be very careful at
implementing this in Debian. First, it would set a precedent at Debian
taking position in that political space and second it would mean
carrying that patch around for ourselves, which is extra work for us.

So I don't think we should do this, but I will let other maintainers
weigh in before I close this issue.

a.

Bug#994208: "not implemented" while exporting a track from ardour

[Antoine Beaupré]

On 2022-04-14 10:46:07, Dylan Aïssi wrote:
> Hi Antoine,
>
> Latest pipewire versions fixed several issues with ardour and the "not
> implemented" message.
>
> https://gitlab.freedesktop.org/pipewire/pipewire/-/issues?scope=all=all=ardour+not+implemented
>
> It would be nice, if you could try with a more recent version.

I would be very happy to see those issues fixed, but unfortunately I do
not plan on upgrading to bookworm for at least a few months. We're still
in the middle of a major bullseye upgrade (~50 machines to go) so it
could take a little longer.

-- 
The problem is not a lack of highly educated workers, the problem is a
lack of highly educated workers willing to work for the minimum wage or
lower in the U.S. Costs are driving outsourcing, not the quality of
American schools.   - Scott Kirwin, IT Professionals Association

Bug#711482: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug because I can not reproduce it anymore on actual Kodi 
versions.
Please feel free to re-open it if the issue remains in 19.x or 20.0 Alpha 
releases.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#711482: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug after I verified CD/DVD tray gets injected after I ask 
Kodi to eject it via JSON-RPC:

'{"id":1,"jsonrpc":"2.0","method":"System.EjectOpticalDrive","params":{}}'

The prerequisite is that user running Kodi must be in "cdrom" group.
However, it is documented in Kodi wiki anyway.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#754186: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug because I can not reproduce it anymore on actual Kodi 
versions.
Please feel free to re-open it if the issue remains in 19.x or 20.0 Alpha 
releases.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1009679: lintian: False positive for OCaml info files

[Felix Lechner]

Hi Rafael,

On Thu, Apr 14, 2022 at 2:09 AM Rafael Laboissière  wrote:
>
> See
> https://salsa.debian.org/ocaml-team/dh-ocaml/-/commit/eae9dc26

What is the purpose of those files, please? Are they used in the oCaml
Lintian check?

Kind regards
Felix Lechner

Bug#998856: libvte-2.91-0: Same bug in 0.68.0-1

[Jasmin68k]

Package: libvte-2.91-0
Version: 0.68.0-1
Followup-For: Bug #998856
X-Debbugs-Cc: jasmin...@noreply.com

Dear Maintainer,

bug still exists in 0.68.0-1.

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

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

Versions of packages libvte-2.91-0 depends on:
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libfribidi0  1.0.8-2
ii  libgcc-s112-20220319-1
ii  libglib2.0-0 2.72.0-1+b1
ii  libgnutls30  3.7.3-4+b1
ii  libgtk-3-0   3.24.33-1
ii  libicu67 67.1-7
ii  libpango-1.0-0   1.50.6+ds-2
ii  libpangocairo-1.0-0  1.50.6+ds-2
ii  libpcre2-8-0 10.39-4
ii  libstdc++6   12-20220319-1
ii  libsystemd0  250.4-1
ii  libvte-2.91-common   0.68.0-1
ii  zlib1g   1:1.2.11.dfsg-4

libvte-2.91-0 recommends no packages.

libvte-2.91-0 suggests no packages.

-- no debconf information

Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[Axel Beckert]

Hi Chris, hi zhenwei,

Chris Hofstaedtler wrote:
> > The irqtop(from util-linux) command has better user experience:
> >  - aggregate interrupt information seems clear on a morden server(128
> >CPUs or more).
> >  - sort by several rules, include IRQ, TOTAL, DELTA and NAME.
> >  - specify cpus in list format to monitor.
> >  - specify output columns to print.
> 
> thanks for the reminder. For irqtop, I had some discussion with the
> maintainer of the current irqtop package (CC'ed now). I cannot
> remember if we came to a conclusion though. Axel, maybe you can
> remind me...

Since you're asking, I allow myself to cite my reply to your inquiry
with me back then (June 2021):

-

Hmmm, do they do the same? Can I test that irqtop from util-linux
somewhere?

Since people seem to expect the irqtop tool from util-linux, I see
multiple options:

1) If the irqtop from util-linux is clearly superior: Drop building
   the irqtop package from src:iptables-netflow and let util-linux
   generate a transitional package. (Versions should be no problem
   with 2.6 < 2.36.)

   I more or less built that binary package, because that tool was in
   the upstream sources and no such feature was present in Debian so
   far and I didn't want to pull in ruby just for a DKMS kernel module.

2) If none of them is clearly superior and they have different feature
   sets, using the alternatives system might be an option.

   Since I expect both to be just TUI tools without having an API
   being used by other tools, different commandline options should not
   be an issue here.

3) Rename one of them, e.g. to irqtop-nf or irqtop-ul or so. (Renaming
   both of them will be needed for variant 2 anyways.)

In case you intend to add lsirq for bullseye, you could also add
irqtop as irqtop-ul or so (i.e. variant 3b), too. That shouldn't cause
any disturbance IMHO.

-

As far as I can see, I didn't get a reply back from you on these
suggestions of mine. Maybe my mail fell through the cracks. But I
think we should take the discussion up again, probably in this bug
report.

Another point which comes to my mind now is that it might make sense
to rename the current irqtop package to irqtop-nf (or irqtop-ruby)
just to make clear that it does not contain the irqtop tool from
util-linux.

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

Bug#993798: icedtea-netx: upgrade to Debian 11 makes an Exception rise ...

[MAG4 Piemonte]

Dear Maintainer, we have the same general situation (upgrade from Debian 10 to 
11 wiht a 
remote Java application that stops running but runs perfectly on a virtualized 
Debian 10) 
but with a different error:
org.xml.sax.SAXException: SAX2 driver class org.apache.xerces.parsers.SAXParser 
not 
found 
java.lang.ClassNotFoundException: org.apache.xerces.parsers.SAXParser 
  at org.xml.sax.helpers.XMLReaderFactory.loadClass(XMLReaderFactory.java:230) 
  at 
org.xml.sax.helpers.XMLReaderFactory.createXMLReader(XMLReaderFactory.java:191) 
  at finanze.IDAC.gui.MainWin.startApp(MainWin.java:445) 
  at finanze.IDAC.guiIVP.MainWinIVP18.main(MainWinIVP18.java:46) 
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
43) 
  at java.lang.reflect.Method.invoke(Method.java:498) 
  at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:576) 
  at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:945) 
Caused by: java.lang.ClassNotFoundException: 
org.apache.xerces.parsers.SAXParser 
  at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1644)
 
  at org.xml.sax.helpers.NewInstance.newInstance(NewInstance.java:82) 
  at org.xml.sax.helpers.XMLReaderFactory.loadClass(XMLReaderFactory.java:228) 
  ... 9 more
Regards!
Guido

Bug#849272: Close

[Vasyl Gello]

Control: close -1

Dear colleagues,

I am closing this bug due to inabiluty to reproduce it in newer versions of 
Kodi.
Feel free to re-open it if you experience the issue on 19.4 and 20.0 Alpha.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1006656: Intel NUC 11: kodi doesn't show

[Vasyl Gello]

Hi Harald!

Today 2:19.4+dfsg1-2 migrated to testing.
Do you still experience the issue or I can close the bug?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1009695: does not follow symlinks

[Joseph Nahmias]

Package: eyed3
Version: 0.8.10-4
Severity: normal
File: /usr/bin/eyeD3
X-Debbugs-Cc: j...@nahmias.net

Hello,

eyeD3 works properly when given a direct path to an MP3 file. However, if you
have a symlink to an MP3, eyeD3 fails to follow the symlink and doesn't read
the data from the linked to MP3 file.  For example:

$ eyeD3 -Q test.mp3
/tmp/foobar/test.mp3[ 7.30 MB ]

Time: 03:02 MPEG1, Layer III[ 320 kb/s @ 44100 Hz - Joint stereo ]

ID3 v2.3: 7 frames

$ ln -s test.mp3 link.mp3
$ ls -laFq link.mp3
lrwxrwxrwx 1 joe joe 8 Apr 14 07:59 link.mp3 -> test.mp3
$ eyeD3 -l debug link.mp3
eyed3:DEBUG: command line args: Namespace(log_level=[['debug']], 
debug_profile=False, debug_pdb=False, excludes=None, fs_encoding='utf-8', 
paths=['link.mp3'], list_plugins=False, plugin=, config=None, backup=False, quiet=False, no_color=False, 
no_config=False, artist=None, album=None, album_artist=None, title=None, 
track=None, track_total=None, track_offset=None, composer=None, disc_num=None, 
disc_total=None, genre=None, non_std_genres=False, release_year=None, 
simple_comment=None, rename_pattern=None, tag_version=(3, None, None), 
convert_version=None, release_date=None, orig_release_date=None, 
recording_date=None, encoding_date=None, tagging_date=None, publisher=None, 
play_count=None, bpm=None, unique_file_ids=[], comments=[], remove_comment=[], 
remove_all_comments=False, lyrics=[], remove_lyrics=[], 
remove_all_lyrics=False, text_frames=[], user_text_frames=[], url_frames=[], 
user_url_frames=[], images=[], remove_image=[], remove_all_images=False, 
write_images_dir=None, objects=[], remove_object=[], write_objects_dir=None, 
remove_all_objects=False, popularities=[], remove_popularity=[], 
remove_v1=False, remove_v2=False, remove_all=False, remove_fids=[], 
max_padding=True, text_encoding=None, force_update=False, verbose=False, 
preserve_file_time=False)
eyed3:DEBUG: plugin is: 
eyed3.core:DEBUG: Loading file: /tmp/foobar/link.mp3
eyed3.core:DEBUG: File mime-type: inode/symlink
Nothing to do
$


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

Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
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 eyed3 depends on:
ii  python33.9.2-3
ii  python3-eyed3  0.8.10-4
ii  python3-pkg-resources  52.0.0-4

eyed3 recommends no packages.

eyed3 suggests no packages.

-- no debconf information

Bug#1009668: Re: Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[zhenwei pi]

On 4/14/22 19:00, Chris Hofstaedtler wrote:

Hi zhenwei pi,

* zhenwei pi  [220414 03:39]:

util-linux supports two new commands irqtop/lsirq since v2.36.
The related release note: https://lwn.net/Articles/826866/

The irqtop(from util-linux) command has better user experience:
  - aggregate interrupt information seems clear on a morden server(128
CPUs or more).
  - sort by several rules, include IRQ, TOTAL, DELTA and NAME.
  - specify cpus in list format to monitor.
  - specify output columns to print.

The lsirq command supports:
  - specify output columns to print.
  - sort result.
  - raw/json/KV format to show.


thanks for the reminder. For irqtop, I had some discussion with the
maintainer of the current irqtop package (CC'ed now). I cannot
remember if we came to a conclusion though. Axel, maybe you can
remind me...

lsirq - right, will probably put it into util-linux-extra soon. Or
do you think it should be part of the util-linux Essential API?

Chris


Hi, Chris

lsirq reads /proc/interrupts and shows the basic IRQ information of an 
OS, it's a common and standard function. From the point of my view, to 
be part of util-linux seems better. Please correct me if I misunderstand 
the difference between util-linux and util-linux-extra package. Thanks!


--
zhenwei pi

Bug#1009694: debsecan: Support for jessie

[Tom Fernandes]

Package: debsecan
Version: 0.4.20.1
Severity: normal

Dear Maintainer,

debsecan does not seem to work for jessie anymore:

$ debsecan --suite jessie
error: while downloading https://security-
tracker.debian.org/tracker/debsecan/release/1/jessie:
HTTP Error 404: Not Found
Are you sure 'jessie' is a Debian codename?

Is it because jessie is not officially supported anymore but only by LTS
Exended?

Warm regards, Tom

Bug#1009693: keepassxc: data loss when adding subgroups from 2 PC to the shared file

[Sergey Spiridonov]

Package: keepassxc
Version: 2.6.2+dfsg.1-1
Severity: normal

Steps to reproduce:

1. Put password file on samba shared folder.

2. 2 users open the file, choose a group and start adding 10 subgroups to
that group simulteneously, also adding 1 password entry in each subgroup

>From time to time users are asked to merge the file - that is expected.

But at the end I get 3 added subgroups lost!

We also performed same test with keepassxc 2.7.1 appimage. Bug is there too!


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

Kernel: Linux 5.15.0-0.bpo.2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages keepassxc depends on:
ii  libargon2-10~20171227-0.2
ii  libc6  2.31-13+deb11u3
ii  libgcrypt201.8.7-6
ii  libqrencode4   4.1.1-1
ii  libqt5concurrent5  5.15.2+dfsg-9
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5svg5 5.15.2-3
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libqt5x11extras5   5.15.2-2
ii  libsodium231.0.18-1
ii  libstdc++6 10.2.1-6
ii  libx11-6   2:1.7.2-1
ii  libxi6 2:1.7.10-1
ii  libxtst6   2:1.2.3-1
ii  libykpers-1-1  1.20.0-3
ii  libzxcvbn0 2.4+dfsg-2
ii  zlib1g 1:1.2.11.dfsg-2+deb11u1

Versions of packages keepassxc recommends:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1

Versions of packages keepassxc suggests:
pn  webext-keepassxc-browser  
pn  xclip 

-- no debconf information

Bug#927012: Redesign of libravatar.cgi and testing

[Oliver Falk]

Hi!

Yes, libravatar never had the option to query with the plaintext identity
for good reasons.

Again, if there is anything I can do, please let me know!

Oliver

On Sat, Apr 9, 2022 at 6:09 AM Don Armstrong  wrote:

> On Fri, 08 Apr 2022, Oliver Falk wrote:
> > When I checked it yesterday, the script was still called with the mail
> > address !?
>
> The script is, but libravatar and gravatar are no longer called with the
> mail address; they're all using the md5 of the e-mail address now. [The
> script caches responses from libravatar and gravatar and serves them
> directly, so there's limited leakage of information on who is visiting a
> specific page.]
>
> > Let me know if I can help you in some way, I'm happy to do so if I
> > know what exactly is required.
>
> Thanks! To be honest, I haven't looked at the issue recently, so I'll
> have to dig in to see what was failing. [It's probably time to just have
> it use mod_perl directly instead of the CGI-based mod_perl.]
>
> --
> Don Armstrong  https://www.donarmstrong.com
>
> If you wish to strive for peace of soul, then believe; if you wish to
> be a devotee of truth, then inquire.
>  -- Friedrich Nietzsche
>
> --
> To unsubscribe, send mail to 927012-unsubscr...@bugs.debian.org.
>
>

-- 

Oliver Falk, RHCE

He/Him/His

Manager Customer Success - Germany

Red Hat 

fa...@redhat.com

M: +436641665645 IM: ofalk
@RedHat    Red Hat
  Red Hat



Red Hat Austria GmbH, Legal form: Limited company ("Gesellschaft mit
beschränkter Haftung") Registered seat: Vienna
Commercial registry file: FN 479668w, Commercial Court ("Handelsgericht") Vienna

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Brian Klemm

Bug#878126: ntopng: privacy breach: checks upstream for new releases

[Gianfranco Costamagna]

Hello,

The code looks like called here:
scripts/lua/modules/lua_utils.lua:function check_latest_major_release()
scripts/lua/modules/toasts/predicates_defined_toasts.lua:local message = 
check_latest_major_release()

but I'm not ntopng user and lua confident to disable it without risks of 
breaking something else.

G.

On Tue, 10 Oct 2017 10:34:02 +0200 =?utf-8?q?IOhannes_m_zm=C3=B6lnig?= 
 wrote:

Package: ntopng
Version: 2.4+dfsg1-4
Severity: wishlist

Dear Maintainer,

Logging into the ntop-ng webinterface, i get a warning on each page:

~~~
A new ntopng (v.3.0.0) is available for download: please upgrade.
~~~

I conclude that ntop-ng is "calling home" to check for new upstreams.
Please remove the relevant code from the Debian package, as it
constitutes a privacy breach.
https://lintian.debian.org/tags/privacy-breach-generic.html


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ntopng depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libcurl3-gnutls  7.52.1-5+deb9u1
ii  libgcc1  1:6.3.0-18
ii  libgeoip11.6.9-4
ii  libhiredis0.13   0.13.3-2
ii  libjson-c3   0.12.1-1.1
ii  libluajit-5.1-2  2.0.4+dfsg-1+b1
ii  libmariadbclient18   10.1.26-0+deb9u1
ii  libndpi4 1.8-1
ii  libpcap0.8   1.8.1-3
ii  librrd8  1.6.0-1+b2
ii  libsqlite3-0 3.16.2-5
ii  libstdc++6   6.3.0-18
ii  libzmq5  4.2.1-4
ii  lsb-base 9.20161125
ii  ntopng-data  2.4+dfsg1-4
ii  redis-server 3:3.2.6-1
ii  zlib1g   1:1.2.8.dfsg-5

ntopng recommends no packages.

Versions of packages ntopng suggests:
pn  geoip-database-contrib  

-- Configuration Files:
/etc/ntopng.conf changed [not included]

-- no debconf information

Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[Chris Hofstaedtler]

Hi zhenwei pi,

* zhenwei pi  [220414 03:39]:
> util-linux supports two new commands irqtop/lsirq since v2.36.
> The related release note: https://lwn.net/Articles/826866/
> 
> The irqtop(from util-linux) command has better user experience:
>  - aggregate interrupt information seems clear on a morden server(128
>CPUs or more).
>  - sort by several rules, include IRQ, TOTAL, DELTA and NAME.
>  - specify cpus in list format to monitor.
>  - specify output columns to print.
> 
> The lsirq command supports:
>  - specify output columns to print.
>  - sort result.
>  - raw/json/KV format to show.

thanks for the reminder. For irqtop, I had some discussion with the
maintainer of the current irqtop package (CC'ed now). I cannot
remember if we came to a conclusion though. Axel, maybe you can
remind me...

lsirq - right, will probably put it into util-linux-extra soon. Or
do you think it should be part of the util-linux Essential API?

Chris

Bug#1008653: backintime-qt broken in sid after python upgrade

[Fabio Fantoni]

Control: tags -1 + bookworm sid
severity -1 grave
thanks

Increased severity as it don't start in testing and unstable, need to be 
updated to latest upstream version (1.3.2)






OpenPGP_signature
Description: OpenPGP digital signature

Bug#996326: musl: static PIE does not work

[Josh Triplett]

tags 996326 + patch
thanks

On Wed, 13 Oct 2021 03:07:50 +0200 Thorsten Glaser  wrote:
> Supposedly, all versions since stretch/bionic should be able
> to do static PIE, at least as far as my research shows me, but
> I either can’t seem to figure it out, or it’s plain broken.
> 
> Both of…
>  musl-gcc -fPIE -static-pie -o foo foo.c -v -fno-lto
>  musl-gcc -fPIE -static -static-pie -o foo foo.c -v -fno-lto
> … fail, as the -v shows, it passes -dynamic-linker and doesn’t
> pick rcrt0. (The -fno-lto makes the output marginally more
> legible so I included it in an otherwise minimal example.)
> 
> The first generates a dynamically linked(?) PIE executable that
> lintian detects as a shared library not linked against (g)libc,
> the second is… I don’t even know; file says static but it doesn’t
> have the right crt objects but *has* -dynamic-linker…
> 
> So how can we get static PIE with musl on Debian, and in which
> releases?

There's a patch available at
https://src.fedoraproject.org/rpms/musl/blob/rawhide/f/musl-1.2.0-Support-static-pie-with-musl-gcc-specs.patch
that should make static-pie work.

Bug#1009691: libusb-1.0-0: Some USB microphone takes sounds as very low volume

[Hideki Yamane]

Package: libusb-1.0-0
Version: 2:1.0.26-1
Severity: normal
X-Debbugs-Cc: henr...@debian.org

Dear Maintainer,

 With upgrading libusb-1.0-0 package from 2:1.0.25-1 to 2:1.0.26-1,
 my USB microphone (marantz PROFESSIONAL pod pack1, "C-Media Electronics, Inc.
 Blue Snowball" with lsusb) just takes sounds as very low volume. However,
 Other USB mic (logicool webcam) just works fine with both versions.

 Downgrading to 2:1.0.25-1 solves this problem.
 
 USB microphone's info via lsusb is attached.
 Please let me know if you need more information to investigate this issue.
 Thanks.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 libusb-1.0-0 depends on:
ii  libc6 2.33-7
ii  libudev1  250.4-1

libusb-1.0-0 recommends no packages.

libusb-1.0-0 suggests no packages.

-- no debconf information
Bus 003 Device 014: ID 0d8c:0005 C-Media Electronics, Inc. Blue Snowball
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize016
  idVendor   0x0d8c C-Media Electronics, Inc.
  idProduct  0x0005 Blue Snowball
  bcdDevice1.00
  iManufacturer   1 MICE MICROPHONE
  iProduct2 USB MICROPHONE
  iSerial 3 201308
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x009f
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass 1 Audio
  bInterfaceSubClass  1 Control Device
  bInterfaceProtocol  0 
  iInterface  0 
  AudioControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdADC   1.00
wTotalLength   0x002e
bInCollection   1
baInterfaceNr(0)1
  AudioControl Interface Descriptor:
bLength12
bDescriptorType36
bDescriptorSubtype  2 (INPUT_TERMINAL)
bTerminalID 2
wTerminalType  0x0201 Microphone
bAssocTerminal  0
bNrChannels 1
wChannelConfig 0x0001
  Left Front (L)
iChannelNames   0 
iTerminal   0 
  AudioControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  3 (OUTPUT_TERMINAL)
bTerminalID 7
wTerminalType  0x0101 USB Streaming
bAssocTerminal  0
bSourceID   8
iTerminal   0 
  AudioControl Interface Descriptor:
bLength 7
bDescriptorType36
bDescriptorSubtype  5 (SELECTOR_UNIT)
bUnitID 8
bNrInPins   1
baSourceID(0)  10
iSelector   0 
  AudioControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  6 (FEATURE_UNIT)
bUnitID10
bSourceID   2
bControlSize1
bmaControls(0)   0x03
  Mute Control
  Volume Control
bmaControls(1)   0x00
iFeature0 
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass 1 Audio
  bInterfaceSubClass  2 Streaming
  bInterfaceProtocol  0 
  iInterface  0 
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   1
  bNumEndpoints   1
  bInterfaceClass 1 Audio
  bInterfaceSubClass  2 Streaming
  bInterfaceProtocol  0 
  iInterface  0 
  AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType36
bDescriptorSubtype  1 (AS_GENERAL)
bTerminalLink   7
bDelay

Bug#1009367: Additional info

[erlenmayr]

After some additional tests, there is some more information.

Test I have run:

1. Installed fresh Debian Bullseye. It has Evolution 3.38.3-1 and
libnss3 3.61-1+deb11u2.

2. Created a new user.

3. Added a GMail account. The inbox contains a signed email. The
certificate was issued by a known CA. Note that no CA was manually
added to the system store (/usr/share/ca-certificates) or Evolution.
-> Preferences/Certificates/Authorities are populated with a long list
of CAs.
-> The signed mail is trusted.

4. Installed Evolution 3.44.0-1 from bookworm.
-> Preferences/Certificates/Authorities are still populated.
-> The signed mail is still trusted.

5. Installed libnss 3.77-1 from bookworm.
-> Preferences/Certificates/Authorities no longer populated. It only
displays a handful authorities that it extracted from e-mails, but not
the full system store.
-> The signed mail is no longer trusted.



Ubuntu 22.04 (beta) has no problems. It uses libnss3 version 3.68.2-
0ubuntu1.

Regards

Bug#1009679: lintian: False positive for OCaml info files

[Rafael Laboissière]

Control: tags -1 + patch

Merge request regarding this bug: 
https://salsa.debian.org/lintian/lintian/-/merge_requests/391


Best,

Rafael

* Rafael Laboissière  [2022-04-14 10:46]:


Package: lintian
Version: 2.114.0
Severity: normal

Dear Maintainer,

Litian issues the warning 
package-contains-documentation-outside-usr-share-doc for *.info files 
installed in the directory /var/lib/ocaml/lintian/.  These files are 
not documentation and are installed, on purpose, by dh-ocaml. See 
https://salsa.debian.org/ocaml-team/dh-ocaml/-/commit/eae9dc26


These are false positive cases.

Best,

Rafael Laboissière

Bug#1009690: git-sizer: autopkgtest regression on ppc64el: An error is expected but got nil.

[Paul Gevers]

Source: git-sizer
Version: 1.5.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
git-sizer  from testing1.5.0-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=git-sizer

https://ci.debian.net/data/autopkgtest/testing/ppc64el/g/git-sizer/20831344/log.gz

=== CONT  TestLittleEPIPE
=== CONT  TestBigEPIPE
pipeline_test.go:327:   Error Trace:pipeline_test.go:327
Error:  An error is expected but got nil.
Test:   TestBigEPIPE
--- FAIL: TestBigEPIPE (0.03s)
=== CONT  TestPipelineCanceled
--- PASS: TestPipelineWithFunction (0.03s)
=== CONT  TestPipelineInterrupted
--- PASS: TestIgnoredSIGPIPE (0.04s)
=== CONT  TestPipelineStderr
--- PASS: TestPipelineCanceled (0.01s)
=== CONT  TestPipelineExit
--- PASS: TestPipelineStderr (0.01s)
=== CONT  TestPipelineDir
--- PASS: TestPipelineDir (0.01s)
=== CONT  TestPipelineTwoCommandsPiping
--- PASS: TestPipelineInterrupted (0.02s)
=== CONT  TestPipelineReadFromSlowly2
--- PASS: TestPipelineExit (0.02s)
=== CONT  TestPipelineReadFromSlowly
--- PASS: TestPipelineTwoCommandsPiping (0.01s)
=== CONT  TestNontrivialPipeline
--- PASS: TestNontrivialPipeline (0.01s)
=== CONT  TestPipelineSingleCommandWithStdout
--- PASS: TestPipelineSingleCommandWithStdout (0.01s)
=== CONT  TestPipelineSingleCommandOutput
--- PASS: TestPipelineSingleCommandOutput (0.01s)
=== CONT  TestPipelineSecondStageFailsToStart
--- PASS: TestPipelineSecondStageFailsToStart (0.00s)
=== CONT  TestErrors/pipe-then-error-then-finish-early
=== CONT  TestErrors/error-then-pipe-then-finish-early
=== CONT  TestErrors/finish-early-then-pipe
=== CONT  TestErrors/pipe-then-finish-early-with-gap
=== CONT  TestErrors/two-pipe-then-finish-early
=== CONT  TestErrors/pipe-then-two-finish-early
=== CONT  TestErrors/pipe-then-finish-early
=== CONT  TestErrors/error-after-finish-early
=== CONT  TestErrors/error-before-finish-early
=== CONT  TestErrors/finish-early-ignored
=== CONT  TestErrors/two-spaced-errors
=== CONT  TestErrors/error-then-pipe
=== CONT  TestErrors/pipe-then-error
=== CONT  TestErrors/two-consecutive-errors
=== CONT  TestErrors/error
=== CONT  TestErrors/lonely-error
--- PASS: TestErrors (0.00s)
--- PASS: TestErrors/no-error (0.00s)
--- PASS: TestErrors/pipe-then-error-then-finish-early (0.00s)
--- PASS: TestErrors/error-then-pipe-then-finish-early (0.00s)
--- PASS: TestErrors/finish-early-then-pipe (0.00s)
--- PASS: TestErrors/pipe-then-finish-early-with-gap (0.00s)
--- PASS: TestErrors/two-pipe-then-finish-early (0.00s)
--- PASS: TestErrors/pipe-then-two-finish-early (0.00s)
--- PASS: TestErrors/pipe-then-finish-early (0.00s)
--- PASS: TestErrors/error-after-finish-early (0.00s)
--- PASS: TestErrors/error-before-finish-early (0.00s)
--- PASS: TestErrors/finish-early-ignored (0.00s)
--- PASS: TestErrors/two-spaced-errors (0.00s)
--- PASS: TestErrors/error-then-pipe (0.00s)
--- PASS: TestErrors/pipe-then-error (0.00s)
--- PASS: TestErrors/two-consecutive-errors (0.00s)
--- PASS: TestErrors/error (0.00s)
--- PASS: TestErrors/lonely-error (0.00s)
--- PASS: TestPipelineReadFromSlowly (0.30s)
--- PASS: TestPipelineReadFromSlowly2 (0.69s)
--- PASS: TestLittleEPIPE (1.02s)
FAIL
FAILgithub.com/github/git-sizer/internal/pipe   1.042s
?   github.com/github/git-sizer/internal/refopts[no test files]
?   github.com/github/git-sizer/internal/testutils  [no test files]
?   github.com/github/git-sizer/isatty  [no test files]
?   github.com/github/git-sizer/meter   [no test files]
?   github.com/github/git-sizer/sizes   [no test files]
FAIL
dh_auto_test: error: cd _build && go test -vet=off -v -p 4 
github.com/github/git-sizer github.com/github/git-sizer/counts 
github.com/github/git-sizer/git 
github.com/github/git-sizer/internal/pipe 
github.com/github/git-sizer/internal/refopts 
github.com/github/git-sizer/internal/testutils 
github.com/github/git-sizer/isatty github.com/github/git-sizer/meter 
github.com/github/git-sizer/sizes returned exit code 1

make[1]: *** [debian/rules:12: override_dh_auto_test] Error 25
make[1]: Leaving directory 
'/tmp/autopkgtest-lxc.kztxna7v/downtmp/autopkgtest_tmp'

make: *** 

Bug#1009689: playlist recursive expansion not working

[Eduard Bloch]

Package: vlc
Version: 3.0.17.3-1
Severity: normal

For details, see:

https://forum.videolan.org/viewtopic.php?p=480711

I have the same or similar issue again.

Setting the "Expand" behavior in the settings of Playlist does not fix it.

Command line like:

vlc --recursive expand audio

does not solve it either. It always opens the playlist in non-expanded
mode, which heavily influences the likelyhood of the song selection in
Shuffle mode (i.e. if you have many files in the top folder and then
another couple of folders with even more files inside, then it will keep
selecting songs in the main folder only, until it once hits a folder,
only then it is expanded and the content there gets a chance to be
played).

Best regards,
Eduard.

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

Kernel: Linux 5.17.2+ (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 vlc depends on:
ii  vlc-bin  3.0.17.3-1
ii  vlc-plugin-base  3.0.17.3-1
ii  vlc-plugin-qt3.0.17.3-1
ii  vlc-plugin-video-output  3.0.17.3-1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.17.3-1
pn  vlc-plugin-access-extra
ii  vlc-plugin-notify  3.0.17.3-1
pn  vlc-plugin-samba   
ii  vlc-plugin-skins2  3.0.17.3-1
ii  vlc-plugin-video-splitter  3.0.17.3-1
ii  vlc-plugin-visualization   3.0.17.3-1

Versions of packages vlc suggests:
pn  vlc-plugin-fluidsynth  
pn  vlc-plugin-jack
pn  vlc-plugin-svg 

Versions of packages libvlc-bin depends on:
ii  libc62.33-7
ii  libvlc5  3.0.17.3-1

Versions of packages libvlc5 depends on:
ii  libc62.33-7
ii  libvlccore9  3.0.17.3-1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.17.3-1

Versions of packages vlc-bin depends on:
ii  libc6   2.33-7
ii  libvlc-bin  3.0.17.3-1
ii  libvlc5 3.0.17.3-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libarchive13 3.6.0-1
ii  libaribb24-0 1.0.3-dmo2
ii  libasound2   1.2.6.1-2+b1
ii  libass9  1:0.15.2-1
ii  libavahi-client3 0.8-5
ii  libavahi-common3 0.8-5
ii  libavc1394-0 0.5.4-5
ii  libavcodec58 7:4.4.1-3+b2
ii  libavformat587:4.4.1-3+b2
ii  libavutil56  7:4.4.1-3+b2
ii  libbluray2   1:1.3.1-1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libcddb2 1.3.2-7
ii  libchromaprint1  1.5.1-2
ii  libdav1d50.9.2-1+b1
ii  libdbus-1-3  1.14.0-1
ii  libdc1394-25 2.2.6-4
ii  libdca0  0.0.7-2
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.1-1
ii  libdvdread8  6.1.2-1
ii  libebml5 1.4.2-2
ii  libfaad2 2.10.0-2
ii  libflac8 1.3.4-1
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.11.1+dfsg-1
ii  libfribidi0  1.0.8-2.1
ii  libgcc-s112-20220319-1
ii  libgcrypt20  1.10.1-2
ii  libglib2.0-0 2.72.0-1+b1
ii  libgnutls30  3.7.3-4+b1
ii  libgpg-error01.43-3
ii  libharfbuzz0b2.7.4-1
ii  libixml101:1.8.4-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  libkate1 0.4.1-11
ii  liblirc-client0  0.10.1-6.3
ii  liblua5.2-0  5.2.4-2
ii  libmad0  0.15.1b-10
ii  libmatroska7 1.6.3-2
ii  libmpcdec6   2:0.1~r495-2
ii  libmpeg2-4   0.5.1-9
ii  libmpg123-0  1.29.3-1
ii  libmtp9  1.1.19-1
ii  libncursesw6 6.3-2
ii  libnfs13 4.0.0-1
ii  libogg0  1.3.4-0.1
ii  libopenmpt-modplug1  0.8.9.0-openmpt1-2
ii  libopus0 1.3.1-0.1
ii  libpng16-16  1.6.37-3
ii  

Bug#805310: libsasl2-modules: Annoying message "DIGEST-MD5 common mech free" with svn in systemd journal

[Vincent Lefevre]

On 2022-04-14 11:41:30 +0200, Bastian Germann wrote:
> Am 14.04.22 um 11:12 schrieb Vincent Lefevre:
> > This is not fixed. Or the bug has reappeared:
> 
> Frédéric's patch is essentially the same that IOhannes proposed.
> I do not see how the logcheck regex rule does not match your posted log.
> But I am not familiar with logcheck regex evaluation. It should be standard 
> Perl regexes...
> Or is there something wrong with introducing the group (...)?
> 
> Does anyone familiar with logcheck see the problem and can propose a working 
> patch?
> I am happy to take it.

I think that logcheck is unrelated:

Package: logcheck
Version: 1.3.23
[...]
Description-en: mails anomalies in the system logfiles to the administrator
 Logcheck helps spot problems and security violations in your logfiles
 automatically and will send the results to you in e-mail.
 .
 Logcheck was part of the Abacus Project of security tools, but this
 version has been rewritten.

This package isn't even installed on my machine (I don't need/want
such mail).

The problem here is that the message is in the systemd journal
(not that I've received a mail with such a line).

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

Bug#805310: libsasl2-modules: Annoying message "DIGEST-MD5 common mech free" with svn in systemd journal

[Bastian Germann]

Am 14.04.22 um 11:12 schrieb Vincent Lefevre:

This is not fixed. Or the bug has reappeared:


Frédéric's patch is essentially the same that IOhannes proposed.
I do not see how the logcheck regex rule does not match your posted log.
But I am not familiar with logcheck regex evaluation. It should be standard 
Perl regexes...
Or is there something wrong with introducing the group (...)?

Does anyone familiar with logcheck see the problem and can propose a working 
patch?
I am happy to take it.

Bug#1009687: release.debian.org: Please drop node-openid from testing

[Yadd]

Package: release.debian.org
Severity: wishlist

Hi,

node-openid is RC-buggy (#1008170) and block pkg-js-tools migration.
Could you remove it from testing ?
This package is also useless (no reverse dependencies) and implements an
obsolete protocol (OpenID 1.0/2.0), replaced for a while by
OpenID-Connect

Cheers,
Yadd

Bug#1009686: uuid-runtime: uuidd.service: Failed to set up mount namespacing: /run/systemd/unit-root/var/lib/libuuid: No such file or directory

[Youhei SASAKI]

Package: uuid-runtime
Version: 2.38-3
Severity: normal
X-Debbugs-Cc: none, Youhei SASAKI 

Dear Maintainer,

When I upgrade my system, uuidd.service can't start.
$ systemctl status uuidd.service
× uuidd.service - Daemon for generating UUIDs
 Loaded: loaded (/lib/systemd/system/uuidd.service; indirect; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Thu 2022-04-14 18:22:17 JST; 
14min ago
TriggeredBy: ● uuidd.socket
   Docs: man:uuidd(8)
Process: 3328 ExecStart=/usr/sbin/uuidd --socket-activation (code=exited, 
status=226/NAMESPACE)
   Main PID: 3328 (code=exited, status=226/NAMESPACE)
CPU: 21ms

 4月 14 18:22:17 gerbera systemd[1]: Started Daemon for generating UUIDs.
 4月 14 18:22:17 gerbera systemd[3328]: uuidd.service: Failed to set up mount 
namespacing: /run/systemd/unit-root/var/lib/libuuid: No such file or directory
 4月 14 18:22:17 gerbera systemd[3328]: uuidd.service: Failed at step NAMESPACE 
spawning /usr/sbin/uuidd: No such file or directory
 4月 14 18:22:17 gerbera systemd[1]: uuidd.service: Main process exited, 
code=exited, status=226/NAMESPACE
 4月 14 18:22:17 gerbera systemd[1]: uuidd.service: Failed with result 
'exit-code'.

What's wrong?

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

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages uuid-runtime depends on:
ii  adduser  3.121
ii  init-system-helpers  1.62
ii  libc62.33-7
ii  libsmartcols12.38-3
ii  libsystemd0  250.4-1
ii  libuuid1 2.38-3

uuid-runtime recommends no packages.

uuid-runtime suggests no packages.

-- no debconf information

Bug#1009685: opm-grid: autopkgtest regression: No rule to make target '/usr/lib/x86_64-linux-gnu/libpython3.10.so'

[Paul Gevers]

Source: opm-grid
Version: 2021.10-3
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
opm-grid   from testing2021.10-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. The issue 
*seems* related to the fact that the python3.10-as-default-python3 
transition is ongoing. Somehow it seems the default version of unstable 
is hardcoded in the test and fails in testing because python3 is a 
different version there and this is not covered by versioned (test) 
dependencies.


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=opm-grid

https://ci.debian.net/data/autopkgtest/testing/amd64/o/opm-grid/20820431/log.gz

-- Configuring done
CMake Warning (dev) in CMakeLists.txt:
  Policy CMP0087 is not set: Install CODE|SCRIPT allow the use of generator
  expressions.  Run "cmake --help-policy CMP0087" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: 
/tmp/autopkgtest-lxc.x71vsvog/downtmp/autopkgtest_tmp/dune-autopkgtest/build-cmake

--- calling make for dune-autopkgtest ---
build directory: build-cmake
cmake --build . -- [ 50%] Building CXX object 
src/CMakeFiles/dune-autopkgtest.dir/dune-autopkgtest.cc.o
gmake[2]: *** No rule to make target 
'/usr/lib/x86_64-linux-gnu/libpython3.10.so', needed by 
'src/dune-autopkgtest'.  Stop.
gmake[1]: *** [CMakeFiles/Makefile2:1181: 
src/CMakeFiles/dune-autopkgtest.dir/all] Error 2

gmake: *** [Makefile:146: all] Error 2
--- Failed to build dune-autopkgtest ---
Terminating dunecontrol due to previous errors!
E: Building the package failed.
autopkgtest [10:13:46]: test basic



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009684: openmw: FTBFS with glibc 2.34

[Graham Inggs]

Source: openmw
Version: 0.47.0-1
Severity: important
Tags: ftbfs fixed-upstream

Hi Maintainer

Your package FTBFS once glibc is upgraded to 2.34 due to MINSIGSTKSZ
and SIGSTKSZ no longer being defined as constants.

This was already fixed upstream [1].

Regards
Graham


[1] 
https://gitlab.com/OpenMW/openmw/-/commit/98a7d90ee258ceef9c70b0b2955d0458ec46f048

Bug#1009683: pkg-js-tools breaks node-openid autopkgtest: isStream is not a function

[Paul Gevers]

Source: pkg-js-tools, node-openid
Control: found -1 pkg-js-tools/0.14.18
Control: found -1 node-openid/2.0.10+~2.0.2-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
pkg-js-tools   from testing0.14.18
node-openidfrom testing2.0.10+~2.0.2-3
all others from testingfrom testing

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

Currently this regression is blocking the migration of pkg-js-tools 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=pkg-js-tools

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-openid/20821607/log.gz

# Using ./package.(json|yaml)
# Node module name is openid
# Build files found: # Test files found: test
# Files/dir to be installed from source: test # Copy test files
# Copy debian/tests/pkg-js content
'debian/tests/pkg-js' -> 
'/tmp/autopkgtest-lxc.m2o2ugfs/downtmp/autopkgtest_tmp/smokeqJzQdw/debian/tests/pkg-js'
'debian/tests/pkg-js/test' -> 
'/tmp/autopkgtest-lxc.m2o2ugfs/downtmp/autopkgtest_tmp/smokeqJzQdw/debian/tests/pkg-js/test'

'@types/openid' linked into node_modules
# Searching module in /usr/lib/nodejs/openid
# Searching module in /usr/lib/*/nodejs/openid
# Searching module in /usr/share/nodejs/openid
# Found /usr/share/nodejs/openid
# Searching files to link in /usr/share/nodejs/openid
'./http.js' -> '/usr/share/nodejs/openid/http.js'
'./lib' -> '/usr/share/nodejs/openid/lib'
'./openid.js' -> '/usr/share/nodejs/openid/openid.js'
'./package.json' -> '/usr/share/nodejs/openid/package.json'
# Launch debian/tests/pkg-js/test with sh -ex
+ NODE_ENV=test node --trace-warnings /usr/bin/jest --ci -u
TypeError: isStream is not a function
at validateInputSync (/usr/share/nodejs/execa/lib/stream.js:86:6)
at Function.module.exports.sync 
(/usr/share/nodejs/execa/index.js:170:2)

at /usr/share/nodejs/jest-runtime/build/index.js:250:24
at Object. 
(/usr/share/nodejs/jest-runtime/build/index.js:255:3)

at Module._compile (internal/modules/cjs/loader.js:1085:14)
at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:1114:10)

at Module.load (internal/modules/cjs/loader.js:950:32)
at Function.Module._load (internal/modules/cjs/loader.js:790:12)
at Module.require (internal/modules/cjs/loader.js:974:19)
at require (internal/modules/cjs/helpers.js:101:18)
autopkgtest [11:23:22]: test pkg-js-autopkgtest



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009682: ghostscript breaks openscad autopkgtest

[Paul Gevers]

Source: ghostscript, openscad
Control: found -1 ghostscript/9.56.0~dfsg-1
Control: found -1 openscad/2021.01-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
ghostscriptfrom testing9.56.0~dfsg-1
openscad   from testing2021.01-4
all others from testingfrom testing

I copied some of the output at the bottom of this report. The output is 
a little dense.


Currently this regression is blocking the migration of ghostscript 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=ghostscript

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openscad/20818051/log.gz

1040/1311 Test #1068: pdfexporttest_centered 
...***Failed0.54 sec



[...]

1046/1311 Test #1069: pdfexporttest_simple-pdf 
.***Failed0.71 sec


[...]

99% tests passed, 2 tests failed out of 1311

Total Test time (real) =  22.61 sec

The following tests FAILED:
1068 - pdfexporttest_centered (Failed)
1069 - pdfexporttest_simple-pdf (Failed)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009681: libsasl2-modules: the changelog file is out-of-date

[Vincent Lefevre]

Package: libsasl2-modules
Version: 2.1.28+dfsg-2+b1
Severity: minor

The /usr/share/doc/libsasl2-modules/changelog.gz file is out-of-date:

2016-10-18  Ken Murchison 
* Fixed potential DoS attack on saslauthd/doors (from Oracle)

2016-06-30  Ken Murchison 
* plugins/ntlm.c, otp.c: support OpenSSL 1.1

2016-06-14  Ken Murchison 
* plugins/digestmd5.c: Fix memory leak in client step 2

2016-03-24  Ken Murchison 
* auth_rimap.c: Don't hang when IMAP server closes connection

2016-01-29  Ken Murchison 
* Build fixes from Ignacio Casal Quinteiro

2015-12-26  Ken Murchison 
* Build fixes from Ignacio Casal Quinteiro
[...]
2001-06-27  Rob Siemborski 
* Version 2.0.0-ALPHA Released

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

Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 libsasl2-modules depends on:
ii  libc6  2.33-7
ii  libssl1.1  1.1.1n-1

libsasl2-modules recommends no packages.

Versions of packages libsasl2-modules suggests:
pn  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal  
pn  libsasl2-modules-ldap  
pn  libsasl2-modules-otp   
pn  libsasl2-modules-sql   

-- no debconf information

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

Bug#805310: libsasl2-modules: Annoying message "DIGEST-MD5 common mech free" with svn in systemd journal

[Vincent Lefevre]

Control: reopen -1
Control: found -1 2.1.28+dfsg-2

On 2022-04-14 10:13:10 +0200, Bastian Germann wrote:
> This was resolved by Frédéric Brière.

This is not fixed. Or the bug has reappeared:

Apr 14 11:06:57 zira svn[1862693]: DIGEST-MD5 common mech free
Apr 14 11:07:32 zira svn[1862770]: DIGEST-MD5 common mech free
Apr 14 11:07:39 zira svn[1862771]: DIGEST-MD5 common mech free
Apr 14 11:07:52 zira svn[1862797]: DIGEST-MD5 common mech free
Apr 14 11:08:03 zira svn[1862798]: DIGEST-MD5 common mech free
Apr 14 11:08:06 zira svn[1862839]: DIGEST-MD5 common mech free
Apr 14 11:08:07 zira svn[1862840]: DIGEST-MD5 common mech free
Apr 14 11:08:07 zira svn[1862869]: DIGEST-MD5 common mech free
Apr 14 11:08:11 zira svn[1862870]: DIGEST-MD5 common mech free
Apr 14 11:08:36 zira svn[1862934]: DIGEST-MD5 common mech free

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

Bug#1009680: ghostscript breaks ocrmypdf autopkgtest: seemingly multiple issues

[Paul Gevers]

Source: ghostscript, ocrmypdf
Control: found -1 ghostscript/9.56.0~dfsg-1
Control: found -1 ocrmypdf/13.4.0+dfsg-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
ghostscriptfrom testing9.56.0~dfsg-1
ocrmypdf   from testing13.4.0+dfsg-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 of ghostscript 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=ghostscript

https://ci.debian.net/data/autopkgtest/testing/amd64/o/ocrmypdf/20818050/log.gz

=== FAILURES 
===
 test_force_ocr 



resources = 
PosixPath('/tmp/autopkgtest-lxc.zdbcipww/downtmp/build.V8r/src/tests/resources')

outpdf = PosixPath('/tmp/pytest-of-debci/pytest-0/test_force_ocr0/out.pdf')

def test_force_ocr(resources, outpdf):
out = check_ocrmypdf(
resources / 'graph_ocred.pdf',
outpdf,
'-f',
'--plugin',
'tests/plugins/tesseract_cache.py',
)
pdfinfo = PdfInfo(out)

  assert pdfinfo[0].has_text

E   assert False
E+  where False = 7.573"x6.16" rotation=0 
dpi=400.00x400.00 has_text=False>.has_text


tests/test_main.py:83: AssertionError
- Captured stderr call 
-


Scanning contents:   0%|  | 0/1 [00:00-- Captured log call 
---
INFO ocrmypdf._pipeline:_pipeline.py:275 page already has text! - 
rasterizing text and running OCR anyway

INFO ocrmypdf._sync:_sync.py:301 Postprocessing...
WARNING  ocrmypdf._pipeline:_pipeline.py:776 Some input metadata could 
not be copied because it is not permitted in PDF/A. You may wish to 
examine the output PDF's XMP metadata.
INFO ocrmypdf.optimize:optimize.py:665 Optimize ratio: 1.52 savings: 
34.1%

INFO ocrmypdf._sync:_sync.py:399 Output file is a PDF/A-2B (as expected)
WARNING  ocrmypdf._validation:_validation.py:381 The output file size is 
2.45× larger than the input file.

Possible reasons for this include:
The argument --force-ocr was issued, causing transcoding.
The optional dependency 'jbig2' was not found, so some image 
optimizations could not be attempted.

PDF/A conversion was enabled. (Try `--output-type pdf`.)
Plugins were used.
--- Captured stderr teardown 
---


PDF/A conversion: 100%|██| 1/1 [00:01<00:00,  1.20s/page]
 test_skip_ocr 
_


resources = 
PosixPath('/tmp/autopkgtest-lxc.zdbcipww/downtmp/build.V8r/src/tests/resources')

outpdf = PosixPath('/tmp/pytest-of-debci/pytest-0/test_skip_ocr0/out.pdf')

def test_skip_ocr(resources, outpdf):
out = check_ocrmypdf(
resources / 'graph_ocred.pdf',
outpdf,
'-s',
'--plugin',
'tests/plugins/tesseract_cache.py',
)
pdfinfo = PdfInfo(out)

  assert pdfinfo[0].has_text

E   assert False
E+  where False = 7.573"x6.16" rotation=0 
dpi=150.00x150.00 has_text=False>.has_text


tests/test_main.py:95: AssertionError
- Captured stderr call 
-


Scanning contents:   0%|  | 0/1 [00:00-- Captured log call 
---
INFO ocrmypdf._pipeline:_pipeline.py:287 skipping all processing on 
this page

INFO ocrmypdf._sync:_sync.py:301 Postprocessing...
WARNING  ocrmypdf._pipeline:_pipeline.py:776 Some input metadata could 
not be copied because it is not permitted in PDF/A. You may wish to 
examine the output PDF's XMP metadata.
INFO ocrmypdf.optimize:optimize.py:665 Optimize ratio: 1.14 savings: 
12.6%

INFO ocrmypdf._sync:_sync.py:399 Output file is a PDF/A-2B (as expected)
--- Captured stderr teardown 
---


PDF/A conversion: 100%|██| 1/1 [00:00<00:00,  4.16page/s]
 test_redo_ocr 

Bug#1000527:

[Dylan Aïssi]

Hi,

Is this issue still present with latest pipewire/wireplumber versions?
If yes, can you report it to the upstream devs?

Best,
Dylan

Bug#1009679: lintian: False positive for OCaml info files

[Rafael Laboissière]

Package: lintian
Version: 2.114.0
Severity: normal

Dear Maintainer,

Litian issues the warning 
package-contains-documentation-outside-usr-share-doc for *.info files 
installed in the directory /var/lib/ocaml/lintian/.  These files are 
not documentation and are installed, on purpose, by dh-ocaml. See 
https://salsa.debian.org/ocaml-team/dh-ocaml/-/commit/eae9dc26

These are false positive cases.

Best,

Rafael Laboissière

Bug#1004016: pipewire 0.3.43 upgrade automatically selects broken profile

[Dylan Aïssi]

Hi Alexander,

Is this issue still present with latest pipewire/wireplumber versions?
If yes, can you report it to the upstream devs?

Best,
Dylan

Bug#994208: "not implemented" while exporting a track from ardour

[Dylan Aïssi]

Hi Antoine,

Latest pipewire versions fixed several issues with ardour and the "not
implemented" message.

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues?scope=all=all=ardour+not+implemented

It would be nice, if you could try with a more recent version.

Best,
Dylan

Bug#1009678: haskell-aeson: CVE-2021-41119 - JSON DoS Vulnerability in Haskell's Aeson library

[Neil Williams]

Source: haskell-aeson
Version: 1.4.7.1-2
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 



Hi,

The following vulnerability was published for haskell-aeson.

CVE-2021-41119[0]:
| Wire-server is the system server for the wire back-end services.
| Releases prior to v2022-03-01 are subject to a denial of service
| attack via a crafted object causing a hash collision. This collision
| causes the server to spend at least quadratic time parsing it which
| can lead to a denial of service for a heavily used server. The issue
| has been fixed in wire-server 2022-03-01 and is already deployed on
| all Wire managed services. On premise instances of wire-server need to
| be updated to 2022-03-01, so that their backends are no longer
| affected. There are no known workarounds for this issue.

The vulnerable code is in the Aeson library, used by wire-server.

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-41119
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41119

Please adjust the affected versions in the BTS as needed.



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

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

Bug#1009677: python-django: CVE-2022-28346

[Chris Lamb]

Package: python-django
Version: 1:1.10.7-2+deb9u15
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for python-django.

CVE-2022-28346[0]:
| An issue was discovered in Django 2.2 before 2.2.28, 3.2 before
| 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and
| extra() methods are subject to SQL injection in column aliases via a
| crafted dictionary (with dictionary expansion) as the passed **kwargs.

There was another CVE as part of this release:
https://www.djangoproject.com/weblog/2022/apr/11/security-releases/

However, the CVE in question (CVE-2022-28347), does not apply in
buster, stretch or jessie; the .explain(...) functionality was added
later versions.

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-28346
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28346


Regards,

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

Bug#1009103: network-manager-iodine-gnome: GTK 4 version needed for gnome-control-center 42

[Guido Günther]

Hi,
On Thu, Apr 07, 2022 at 10:19:16AM +0100, Simon McVittie wrote:
> Package: network-manager-iodine-gnome
> Version: 1.2.0-3.1
> Severity: important
> Tags: upstream sid bookworm
> Control: affects -1 + gnome-control-center
> 
> GNOME Control Center version 42 has moved from GTK 3 to GTK 4, which means
> it can't load VPN configuration plugins that don't have a GTK 4 version.
> 
> The approach used in the plugins that have been ported so far, such as
> network-manager-openvpn-gnome, was to build both a GTK 3 version (for
> network-manager-gnome) and a GTK 4 version (for gnome-control-center),
> resulting in a binary package that depends on both GTK 3 and GTK 4.
> 
> The GNOME team would like to get GNOME Control Center 42 into unstable,
> because it's one of the last GNOME 41 components we're using, and upstream
> does not really support mixing components of GNOME 41 with components
> of GNOME 42. Please could you look into providing a GTK 4 version?

I'll have a look. I would be fine to have network-manager-iodine-gnome
removed from testing temporarily to not block g-c-c 42 in case that
helps.
Cheers,
 -- Guido

> 
> Related:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007242
> https://bugzilla.redhat.com/show_bug.cgi?id=2057719
> 
> Thanks,
> smcv
> 

Bug#1009663: pipewire: Stream properties `lfe-cutoff` and `upmix` don't work.

[Dylan Aïssi]

Hi,

Le mer. 13 avr. 2022 à 23:00, Mladen Mijatov  a écrit :
>
> Configuring `lfe-cutoff` and `upmix` in stream properties it's suppose to
> generate audio for subwoofer speaker on 5.1 sound card configuration. This
> doesn't happen. No matter if configuration is made in
> ~/.config/pipewire/client.conf or /usr/share/pipewire/client.conf it simply
> won't generate LFE channel.
>

I just uploaded pipewire 0.3.50 to unstable, it should be available soon.
This new version includes some changes that could fix your issue.
Can you check if it works? Otherwise, can you forward this issue to
upstream devs?

Best,
Dylan

Bug#1009676: grunt: CVE-2022-0436 - Path Traversal in grunt prior to 1.5.2

[Neil Williams]

Source: grunt
Version: 1.4.1-2
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for grunt.

CVE-2022-0436[0]:
| Path Traversal in GitHub repository gruntjs/grunt prior to 1.5.2.


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-0436
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0436

Please adjust the affected versions in the BTS as needed.


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

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