Bug#995909: python3-fava: Fails to start with jinja2 3.0.1

2021-12-13 Thread intrigeri
Hi,

Dr. Tobias Quathamer (2021-12-13):
> thanks a lot for your work! I've added some more tweaks and uploaded the 
> new version to unstable.

Thanks!

> As a side note: in your local repository, there's probably a tag for 
> upstream/1.20.1, which is missing on salsa. Could you please push that 
> to salsa as well?

Done :)



Bug#1001681: sight: FTBFS in unstable

2021-12-13 Thread Steve Langasek
Source: sight
Version: 21.0.0-2
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Hi Flavien,

sight is failing to build in unstable right now with the following error:


cd /tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/io/dimse && /usr/bin/c++ 
-DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK 
-DBOOST_CHRONO_DYN_LINK -DBOOST_DATE_TIME_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK 
-DBOOST_IOSTREAMS_DYN_LINK -DBOOST_LOG_DYN_LINK -DBOOST_LOG_SETUP_DYN_LINK 
-DBOOST_REGEX_DYN_LINK -DBOOST_SPIRIT_USE_PHOENIX_V3 
-DBOOST_THREAD_DONT_PROVIDE_DEPRECATED_FEATURES_SINCE_V3_0_0 
-DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_PROVIDES_FUTURE -DBOOST_THREAD_VERSION=2 
-DIO_DIMSE_EXPORTS -Dio_dimse_EXPORTS 
-I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/io/dimse/include 
-I/tmp/sight-21.0.0/libs -I/tmp/sight-21.0.0/libs/core 
-I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/core/pch/pchData/include/pchData 
-I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/core/core/include 
-I/usr/include/libxml2 
-I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/core/data/include -g -O2 
-ffile-prefix-map=/tmp/sight-21.0.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -fPIC 
-fvisibility=hidden -fvisibility-inlines-hidden -march=sandybridge 
-mtune=generic -mfpmath=sse -fvisibility=hidden -fvisibility-inlines-hidden 
-Wall -Wextra -Wconversion -Wno-unused-parameter -Wno-ignored-qualifiers 
-std=gnu++17 -include "pch.hpp"  -Winvalid-pch -MD -MT 
libs/io/dimse/CMakeFiles/io_dimse.dir/SeriesEnquirer.cpp.o -MF 
CMakeFiles/io_dimse.dir/SeriesEnquirer.cpp.o.d -o 
CMakeFiles/io_dimse.dir/SeriesEnquirer.cpp.o -c 
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp: In member function 
'std::string sight::io::dimse::SeriesEnquirer::findSOPInstanceUID(const 
string&, unsigned int)':
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:5: error: 'OFIterator' 
was not declared in this scope; did you mean 'OF_error'?
  748 | OFIterator it= responses.begin();
  | ^~
  | OF_error
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:26: error: expected 
primary-expression before '*' token
  748 | OFIterator it= responses.begin();
  |  ^
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:27: error: expected 
primary-expression before '>' token
  748 | OFIterator it= responses.begin();
  |   ^
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:29: error: 'it' was not 
declared in this scope; did you mean 'io'?
  748 | OFIterator it= responses.begin();
  | ^~
  | io


I don't know where OFIterator is supposed to come from, but clearly
something has changed.

Cheers,
-- 
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#999169: cconv: missing required debian/rules targets build-arch and/or build-indep

2021-12-13 Thread gold holk

On Tue, 09 Nov 2021 22:28:16 +0100 Lucas Nussbaum  wrote:

> Source: cconv
> Version: 0.6.2-1.1
> Severity: important
> Justification: Debian Policy section 4.9
> Tags: bookworm sid
> User: debian...@lists.debian.org
> Usertags: missing-build-arch-indep
>
> Dear maintainer,
>
> Your package does not include build-arch and/or build-indep targets in
> debian/rules. This is required by Debian Policy section 4.9, since 2012.
> 
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

>
> Please note that this is also a sign that the packaging of this software
> could benefit from a refresh. For example, packages using 'dh' cannot be
> affected by this issue.
>
> This mass bug filing was discussed on debian-devel@ in
> https://lists.debian.org/debian-devel/2021/11/msg00052.html .
> The severity of this bug will be changed to 'serious' after a month.
>
> Best,
>
> Lucas
>
>

Hey, here is a patch to add build-arch target in debian/rules. I am not 
very familiar to debian packaging. Hope this may prevent auto removing 
of cconv.


Gold Holk

--- cconv-0.6.2/debian/rules~	2021-12-14 12:45:52.0 +0800
+++ cconv-0.6.2/debian/rules	2021-12-14 13:26:38.236383588 +0800
@@ -13,7 +13,9 @@
 		--infodir=\$${prefix}/share/info \
 		CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs"
 
-build: build-stamp
+build: build-arch
+
+build-arch: build-stamp
 
 build-stamp:  config.status 
 	dh_testdir
@@ -63,4 +65,4 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install 
+.PHONY: build-arch build clean binary-indep binary-arch binary install 


Bug#934258: Experimentations on packaging jupyterlab

2021-12-13 Thread Julien Puydt
Le jeudi 09 décembre 2021 à 20:52 +, Julian Gilbey a écrit :
> On Thu, Dec 09, 2021 at 07:49:18PM +, Julian Gilbey wrote:
> > On Sat, Nov 27, 2021 at 11:52:25AM +0100, Julien Puydt wrote:
> > > Hi,
> > > 
> > > I tried my hand at experimental packaging for jupyterlab.
> > 
> > Hi Julien,
> > 
> > Thanks for your work on this!
> 
> One more thing: the docs/environment.yml file lists jsx-lexer as a
> dependency; I packaged this when I looked at jupyterlab last year
> (but ran out of time to get much further).  I haven't made an ITP for
> it, but the draft package is available at
> https://salsa.debian.org/python-team/packages/jsx-lexer


I'm still struggling with the javascript part.

I have seven node-* packages waiting for a review in NEW, and my
current work-in-progress dependency line is:

- @jupyterlab/ui-components wants @blueprintjs/core ;

- @blueprintjs/core wants @blueprintjs/icons ;

- @blueprintjs/icons wants svgo ;

- svgo is annoying: an old version on salsa could be readily uploaded,
but a more recent version wants csso ;

- csso wants esbuild ;

- esbuild is interesting: a javascript in Debian hero, yadd, had his
own needs and has probably fixed the problem, but the change hasn't
been accepted and uploaded yet:
https://salsa.debian.org/go-team/packages/golang-github-evanw-esbuild/-/merge_requests/1


Once esbuild is clear, I'll see if that solves csso ; if it does, I'll
see if it solves svgo ; if it does, I'll see if it solves... you get
the point!

Cheers,

J.Puydt



Bug#1001680: O: libmp3-info-perl -- Perl MP3::Info - Manipulate / fetch info from MP3 audio files

2021-12-13 Thread Alexander Wirt
Package: wnpp
Severity: normal
Control: affects -1 src:libmp3-info-perl

I intend to orphan the libmp3-info-perl package. That was a dependency
for mp3burn and I don't need it anymore.

The package description is:
 This Perl library gives a set of function for manipulating info tags in MP3
 files and retrieving technical information from them.
 .
 This package was formerly known as MPEG::MP3Info and still has a wrapper
 for applications that refer to it using the old name.
 .
 The Debian package also provides a simple tool for editing MP3 tags - mp3id.



Bug#1001679: O: libmail-verify-perl -- Utility to verify an email address

2021-12-13 Thread Alexander Wirt
Package: wnpp
Severity: normal
Control: affects -1 src:libmail-verify-perl

I intend to orphan the libmail-verify-perl package. I don't do much
Perl this days and even less things with email.

The package description is:
 Mail::Verify provides a function CheckAddress function for verifying
 email addresses. First the syntax of the email address is checked, then
 it verifies that there is at least one valid MX server accepting email
 for the domain. Using Net::DNS and IO::Socket a list of MX records (or,
 falling back on a hosts A record) are checked to make sure at least one
 SMTP server is accepting connections.



Bug#1001678: O: mp3burn -- burn audio CDs directly from MP3, Ogg Vorbis, or FLAC files

2021-12-13 Thread Alexander Wirt
Package: wnpp
Severity: normal
Control: affects -1 src:mp3burn

I intend to orphan the mp3burn package. The last time I burned an audio CD was 
more than 10 years ago. Time to let it go.

The package description is:
 mp3burn is a Perl script that allows you to burn audio CDs composed
 of MP3, Ogg Vorbis, or FLAC tracks without an intermediate file conversion
 to .cdr or .wav.
 The .mp3/.ogg/.flac files *are* converted using a decoder, but are
 written to FIFOs so they don't consume filesystem space during the burn.



Bug#1001438: transition: glibc 2.33

2021-12-13 Thread Sebastian Ramacher
On 2021-12-13 20:21:52 +0100, Aurelien Jarno wrote:
> On 2021-12-13 00:11, Aurelien Jarno wrote:
> > On 2021-12-12 22:18, Paul Gevers wrote:
> > > Hi Aurelien,
> > > 
> > > On 12-12-2021 12:37, Aurelien Jarno wrote:
> > > > > Thanks, I'll add the necessary hints once the glibc upload is old
> > > > > enough.
> > > > 
> > > > Those false positives are due to the fact that glibc from experimental
> > > > is used, and I do not expect them to appear for glibc in sid. In
> > > > addition a few of them after cruft got removed from experimental.
> > > > 
> > > > All that said, we so many reverse dependencies, there might get more
> > > > issues appearing.
> > > 
> > > I just started to have a look, most issues I've checked so far look false
> > > positives. But aribas on i386 wasn't tested for the glibc in experimental
> > > (don't know why) but it fails now in unstable and tested with glibc from
> > > unstable in testing with stack smashing:
> > > https://ci.debian.net/data/autopkgtest/testing/i386/a/aribas/17507755/log.gz
> > 
> > It's likely an issue on the package, but without further investigating,
> > I can't confirm. I'll try to do that tomorrow.
> 
> I have opened bug#1001653 about it.

I've filed bugs for the remaining autopkgtest regressions that were not
caused by glibc (flaky tests, etc.) and then added a force-skiptest hint
for glibc. Unless new issues pop up, it should migrate once it reaches 5
days.

Cheers

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



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#1001677: lintian: check for: "cd ... py3versions -r" in autopkgtest scripts

2021-12-13 Thread Julian Gilbey
Package: lintian
Version: 2.114.0
Severity: wishlist

I discovered that in several of my autopkgtest scripts, and in various
other packages in the archive, the following pattern appears:

...
cd somewhere
...
for py in $(py3versions -r 2>/dev/null)
...

Unfortunately, this silently fails, as no python versions are returned
when py3versions -r is run from anywhere other than the top directory
of an unpacked source, and only the error message:

py3versions: error parsing Python3-Version attribute

is given.  The "2>/dev/null" is nevertheless usually required even
when run from the correct directory to silence the warning:

py3versions: no X-Python3-Version in control file, using supported versions

which appears on most packages.

The corrected script should read something like:

...
for py in $(py3versions -r 2>/dev/null); do
cd somewhere
...

or

...
python3_versions=$(py3versions -r 2>/dev/null)
cd somewhere
...
for py in $python3_versions; do
   ...

A regex such as /\bcd\b.*py3versions\s+-r/s applied to the entire
content of debian/tests/control and every other file in debian/tests
should catch this issue.

Best wishes,

   Julian



Bug#1001676: RM: gnupg2/experimental -- ROM; Clear the space for experimental uploads of the 2.2 series

2021-12-13 Thread Christoph Biedl
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Debian GnuPG-Maintainers 
,

Greetings,

please remove gnupg2 2.3.1-1 from Debian experimental.

In experimental, there's currently a version of the 2.*3* series of
gnugp2 - however it introduced many regressions that need more time to
address. Therefore I want to stick to the 2.*2* series in unstable for
the time being.

For some uploads however, it will be sensible to go via experimental
first. As this however is currently blocked by 2.3.1-1, I am asking you
to remove that newer version there.

Kind regards,

Christoph



signature.asc
Description: PGP signature


Bug#996997: marked as done (buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster"))

2021-12-13 Thread Christoph Biedl
Adam D. Barratt wrote...

> Apparently we missed this on review, but please don't close release.d.o
> bugs in your uploads.
> 
> The bug will get closed once the fix is actually released, which for
> (old)stable updates is once the package is in (old)stable.

ACK. Sorry for disturbing that.

Christoph


signature.asc
Description: PGP signature


Bug#982407: mark libfabric1 Multi-Arch: same

2021-12-13 Thread tony mancill
On Tue, Feb 09, 2021 at 09:25:09PM +0100, Helmut Grohne wrote:
> Package: libfabric1
> Version: 1.11.0-2
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: cross-satisfiability
> 
> The affected packages cannot satisfy their cross Build-Depends, because
> they request coinstalling libfabric1, but libfabric1 is not marked
> Multi-Arch: same. It can be thus marked, because it does not have any
> conflicting files. Please consider applying the attached patch.

Hi Debian HPC,

Any concerns with an NMU or team upload of this change?  I don't work in
HPC and came across this bug via Debian Med (it affects the abyss
package), so when I say "team" upload, I merely keeping the packaging
repo updated.  I have requested team access via Salsa.  

Thanks,
tony


signature.asc
Description: PGP signature


Bug#1001675: libgcrypt20 FTBFS on armhf: error: ‘asm’ operand has impossible constraints

2021-12-13 Thread Helmut Grohne
Package: libgcrypt20
Version: 1.9.4-4
Severity: serious
Tags: ftbfs

Likely, you already know, but I'd it would help to have a bug number
here to track things: libgcrypt20 fails to build from source on armhf on
the buildds. The relevant excerpt is:

| ../../cipher/poly1305.c: In function ‘poly1305_blocks’:
| ../../cipher/poly1305.c:302:7: error: ‘asm’ operand has impossible constraints
|   302 |   __asm__ ("adds %0, %0, %5\n" \
|   |   ^~~
| ../../cipher/poly1305.c:425:7: note: in expansion of macro ‘ADD_1305_32’
|   425 |   ADD_1305_32(h4, h3, h2, h1, h0, m4, m3, m2, m1, m0);
|   |   ^~~

Helmut



Bug#1001649: [debian-mysql] Bug#1001649: mariadb-10.6: Inverted architecture qualifier for libaio-dev BD

2021-12-13 Thread Otto Kekäläinen
Hello!

Yes, you are referring to
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/control#L12

Indeed, libaio-dev only exists on Linux:
https://packages.debian.org/sid/libaio-dev

This change is related to using uring-io on Linux. The correct
solution here I guess would be to simply remove libaio-dev completely.



Bug#1001385: [debian-mysql] Bug#1001385: mariadb-client-10.5: authentification fails while the credentials are ok

2021-12-13 Thread Otto Kekäläinen
On Mon, Dec 13, 2021 at 2:59 AM Anthony Bourguignon
 wrote:
>
> Le dimanche 12 décembre 2021 à 20:54 -0800, Otto Kekäläinen a écrit :
> > Hello!
> >
> > > On Thu, Dec 9, 2021 at 5:00 AM Anthony Bourguignon
> > >  wrote:
> > > ...
> > > > I’m having an issue with the mariadb-client in bullseye. I can’t connect
> > > > to a local server using the mariadb client.
> > > >
> > > > To reproduce the bug :
> > > >   - Install bullseye
> > > >   - Install mariadb-server and mariadb-client
> > > >   - connect as root and create a database and a user :
> > > > create database testbug;
> > > > grant all privileges on testbug.* to 'testbug'@'127.0.0.1'
> > > > identified by 's3cr3t';
> > > >   - exit the client
> > > >   - try to connect with those credentials :
> > > > mariadb -h 127.0.0.1 -u testbug -p testbug
> > > >
> > > > You can’t connect and get an error :
> > > >   ERROR 1045 (28000): Access denied for user 'testbug'@'localhost' 
> > > > (using password: YES)
> > >
> > > You granted permissions to 'testbug'@'127.0.0.1' but you are
> > > connecting from 'testbug'@'localhost'. Grant permissions to the
> > > hostname (not IP) and try again. Also report back here if that solved
> > > it for you, so we can close the bug report.
> >
> > Did you try this? I am waiting for your comment on the above, thanks.
>
> Hi. I’ve already replied to this, this is not the issue at all. There is an 
> upstream bug, which has been confirmed :
>   https://jira.mariadb.org/browse/MDEV-27215
>
> So I think we should wait for the upstream patch to close this bug.

Upstream will only fix the error message to tell about truncation.
There is no point in passwords beyond maybe 20 characters, let alone
80. I don't think massively long passwords will ever be supported,
there is no benefit in doing so.



Bug#986368: mutt: Add support for client certificate without AUTH in smtp

2021-12-13 Thread Kevin J. McCarthy

On Sun, 4 Apr 2021 15:32:59 +0200 Adam Majer  wrote:

Current implementation of mutt always seems to ask for SMTP username
even if one is not set in the config (smtp_url) and AUTH is not
an allowed option of submit server. This then results in an email
send failure

  SMTP server does not support authentication

The patch that fixes this issue is at and also attached.

https://gitlab.com/muttmua/mutt/-/commit/191b0513b43d5e603f99292faa5f8ebcc1be3823.patch

I've tested this patch in the tagged version and the problem is solved.
Please consider adding it to mutt for next upload.


With 2.1.3 uploaded now, I think we can close this ticket now.

-Kevin


signature.asc
Description: PGP signature


Bug#838992: mutt: using mutt, will not default to home mail directory: "c", "?" with "set folder" remains in /var/mail

2021-12-13 Thread Kevin J. McCarthy

On Tue, 27 Sep 2016 09:56:38 -0400 jackson  wrote:

Package: mutt
Version: 1.7.0-6
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
 Upgrading from older version
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 No change, as of yet, in config file ameliorates this behavior
   * What was the outcome of this action?
No change 
   * What outcome did you expect instead?

 "set folder" has changed

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


-- Package-specific info:
NeoMutt 20160916 (1.7.0)



The emails in this ticket all actually show NeoMutt in the "package 
specific info" section.


I can't reproduce the bug, so perhaps it was a temporary NeoMutt bug?

Would someone confirm they can produce this with the latest *Mutt* 
release.  If not, perhaps we can close this ticket.


-Kevin


signature.asc
Description: PGP signature


Bug#1001616: opencc: fails to build reproducibly's root case is not Identifier: build_id_differences_only

2021-12-13 Thread 肖盛文

Hi Gunnar,


在 2021/12/14 上午2:17, Gunnar Hjalmarsson 写道:
When talking to upstream, please keep in mind that we have a Debian 
patch which alters the related part of README.md:


https://salsa.debian.org/debian/opencc/-/blob/master/debian/patches/0004-no-remote-images-when-reading-docs-on-disk.patch 


Thanks for your remind.

I disable this patch and run reprotest agian, still get error.

The detail info please see the attachment.

The doxygen default add the id in html code.

id="md__tmp_reprotest_ilsJd0_build_experiment_1_README">


I also discuss it whit upstream use telegram group 
https://t.me/open_chinese_convert,


one of group admin feedback that it is the bug of doxygen.

The config file of doxygen in opencc is doc/opencc.doxy.in, it has:

 wc -l opencc.doxy.in
1841 opencc.doxy.in

It's so many config item, I don't know whether if exist one config item 
can fix this question.



Regards,

--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat):atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page:https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB

--- /tmp/opencc-no-readme.patch/control
+++ /tmp/opencc-no-readme.patch/experiment-1
│   --- /tmp/opencc-no-readme.patch/control/libopencc-doc_1.1.3+ds1-5_all.deb
├── +++ 
/tmp/opencc-no-readme.patch/experiment-1/libopencc-doc_1.1.3+ds1-5_all.deb
│ ├── file list
│ │ @@ -1,3 +1,3 @@
│ │  -rw-r--r--   0004 2021-10-27 07:39:59.00 
debian-binary
│ │  -rw-r--r--   000 7560 2021-10-27 07:39:59.00 
control.tar.xz
│ │ --rw-r--r--   000   168796 2021-10-27 07:39:59.00 
data.tar.xz
│ │ +-rw-r--r--   000   168800 2021-10-27 07:39:59.00 
data.tar.xz
│ ├── control.tar.xz
│ │ ├── control.tar
│ │ │ ├── ./md5sums
│ │ │ │ ├── ./md5sums
│ │ │ │ │┄ Files differ
│ ├── data.tar.xz
│ │ ├── data.tar
│ │ │ ├── file list
│ │ │ │ @@ -169,15 +169,15 @@
│ │ │ │  -rw-r--r--   0 root (0) root (0)  597 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/folderopen.png
│ │ │ │  -rw-r--r--   0 root (0) root (0)10220 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/functions.html
│ │ │ │  -rw-r--r--   0 root (0) root (0)10108 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/functions_func.html
│ │ │ │  -rw-r--r--   0 root (0) root (0)18187 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/group__opencc__c__api.html
│ │ │ │  -rw-r--r--   0 root (0) root (0)13728 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/group__opencc__cpp__api.html
│ │ │ │  -rw-r--r--   0 root (0) root (0) 4039 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/group__opencc__simple__api.html
│ │ │ │  -rw-r--r--   0 root (0) root (0)19556 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/hierarchy.html
│ │ │ │ --rw-r--r--   0 root (0) root (0)22238 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/index.html
│ │ │ │ +-rw-r--r--   0 root (0) root (0)22240 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/index.html
│ │ │ │  -rw-r--r--   0 root (0) root (0)   175457 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/jquery.js
│ │ │ │  -rw-r--r--   0 root (0) root (0) 3222 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/menu.js
│ │ │ │  -rw-r--r--   0 root (0) root (0) 2951 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/menudata.js
│ │ │ │  -rw-r--r--   0 root (0) root (0) 3960 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/modules.html
│ │ │ │  -rw-r--r--   0 root (0) root (0)  153 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/nav_f.png
│ │ │ │  -rw-r--r--   0 root (0) root (0)   95 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/nav_g.png
│ │ │ │  -rw-r--r--   0 root (0) root (0)   98 2021-10-27 
07:39:59.00 ./usr/share/doc/opencc/html/nav_h.png
│ │ │ ├── ./usr/share/doc/opencc/html/index.html
│ │ │ │ @@ -63,15 +63,15 @@
│ │ │ │  
│ │ │ │  
│ │ │ │  
│ │ │ │
│ │ │ │  Open Chinese Convert 開放中文轉換   
│ │ │ │  
│ │ │ │  
│ │ │ │ - https://travis-ci.org/BYVoid/OpenCC";>https://img.shields.io/travis/BYVoid/OpenCC.svg"; alt="Travis" 
style="pointer-events: none;" class="inline"/> https://ci.appveyor.com/project/Carbo/OpenCC";>https://img.shields.io/appveyor/ci/Carbo/OpenCC.svg"; alt="AppVeyor" 
style="pointer-events: none;" class="inline"/> https://github.com/BYVoid/OpenCC/actions/workflows/cmake.yml";>https://github.com/BYVoid/OpenCC/actions/workflows/cmake.yml/badge.svg"; 
alt="C/C++ CI" style="pointer-events: none;" class="inline"/> https://github.com/BYVoid/OpenCC/actions/workflows/nodejs.yml";>https://github.com/BYVoid/OpenCC/actions/work

Bug#1001616: opencc: fails to build reproducibly's root case is not Identifier: build_id_differences_only

2021-12-13 Thread 肖盛文

Hi Vagrant,

在 2021/12/14 上午1:31, Vagrant Cascadian 写道:

Thanks for looking into this! Indeed, there appear to be more issues.

Thanks for your instant reply.

[...]
This is an embedded build path; reprotest builds in
/tmp/reprotest-X/const_build_path/ and
/tmp/reprotest-X/build-experiment-1/ between two builds.

If you pass the argument to reprotest --vary=-build_path, does it build
reproducibly?

Yes, it build reproducibly !

[...]

Although, on i386 and armhf, there are still outstanding issues even in
bookworm:

   https://tests.reproducible-builds.org/debian/history/i386/opencc.html
   https://tests.reproducible-builds.org/debian/history/armhf/opencc.html

These architectures also systematically run one build with a 32-bit
kernel and one build with a 64-bit kernel. The build may be
inappropriately capturing the kernel architecture:

   $ git grep os.uname
   setup.py:_, _, _, _, machine = os.uname()
   setup.py:_, _, _, _, machine = os.uname()
  
Either there, or somewhere else...


This need to forward to upstream, patch is welcome.

Thanks for add Identifier: captures_build_arch [1].


This and the rest of the differences looks like a small offset that is
possibly related to the build path being a different length
(e.g. const_build_path vs. build_experiment-1). If you do two builds
with a build-path of the same length, but different (e.g. /build/1/2 and
/build/3/4 instead of /build/1/2 and /build/3/4/5) you might get the
same result.

By passing build-id=none, it may just drop the build-id, but the effect
that triggers the change of build-id is still there. My educated guess
here is probably build path related.


Your educated guess is very right!

Thanks for add Identifier: 
build_path_identifiers_in_documentation_generated_by_doxygen [2]



[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/opencc.html


[2] 
https://tests.reproducible-builds.org/debian/issues/unstable/build_path_identifiers_in_documentation_generated_by_doxygen_issue.html





live well,
   vagrant

live well,

--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat):atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#694068: wireless fail after stretch^H^H^H^H^H^H^Hbuster^H^H^H^H^H^Hbullseye installation

2021-12-13 Thread David Wright
Having just swatted away this bug while installing bullseye
on a laptop that has 1xUSB3, 2xUSB-C and no ethernet, I thought
I should share the workaround here. This is only necessary,
I'm led to believe, when installing by WiFi without the
installation of a Desktop.

Before tearing down the WiFi interface at the very end of
the installation, the d-i should simply copy the existing
/target/etc/network/interfaces file to /target/root/, perhaps
named as etc-network-interfaces-at-installation, with its
permissions set to 600.

When the machine is rebooted, it is now straightforward for
the sysadmin to login and simply:

  # mv /root/etc-network-interfaces-at-installation /etc/network/interfaces
  # ifup w

to give themselves WiFi connectivity (using sudo if necessary).

This workaround has the benefit of being fail-safe: the file has
no effect on the system if the sysadmin ignores it and leaves it
in /root, but if they do move it as above, then they've taken
responsibility for its effects on any software they install later.

Naturally, it would require a note in the Installation Guide for
this method to be useful if the sysadmin is not one to make use
of root's home directory.

Cheers,
David.



Bug#995881: mutt: displays text/html raw instead of using mailcap

2021-12-13 Thread Kevin J. McCarthy

On Thu, 07 Oct 2021 18:04:53 +0200 Anton Ertl 
 wrote:

Package: mutt
Version: 2.0.5-4.1
Severity: normal

Dear Maintainer,

I viewed a text/html email, shown as plain text.  Selecting v to view
attachments, and then selecting the text/html part and typing Enter
also showed the plain text.

I expected that lynx would be invoked when I type Enter when viewing
attachments, like in Debian 9.  /etc/mailcap contains several lines
for dealing with text/html, and adding such a line to ~/.mailcap did
not make a difference.

This seems to be a new incarnation of bug 823971.  Fortunately the
same workaround of using "m" instead of Enter in the attachment
viewing mode works.


Sorry, using "m" isn't a "workaround".  The default bindings in upstream 
Mutt have *always* been  =>  and "m" => 
.


At one point, Debian's version carried an external patch changing the 
default keybinding, but Debian is now using a minimally changed version 
of Mutt.


Antonio can pipe in about his intentions with respect to the Debian 
package, but personally I have no plans on changing the default in 
upstream.


Of course, you are free to rebind to your tastes yourself!  :-)

-Kevin


signature.asc
Description: PGP signature


Bug#961247: mutt -s'a b c' x < somefile sends post also to "b" and "c"

2021-12-13 Thread Kevin J. McCarthy

On Thu, 21 May 2020 23:08:03 + Bjarni Ingi Gislason  
wrote:

Package: mutt
Version: 1.14.0-1+b1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

mutt -s'Test the mailer' bg <  


The '-s' argument requires a space between it and the subject to be 
used.


Mutt uses the standard function getopt() for argument parsing.  With it, 
you can combine more than one option letter behind a single hyphen.  So, 
e.g. 'mutt -vv' is the same as 'mutt -v -v'.


I believe the documentation shows the usage correctly.  If there is some 
place showing the usage incorrectly, please let me know.


Otherwise I believe this ticket can be closed.

-Kevin


signature.asc
Description: PGP signature


Bug#1001674: x11-common: Multiple monitors and starting app with window maximized

2021-12-13 Thread David Lehrian

Package: x11-common
Version: 1:7.7+22
Severity: important

Dear Maintainer,

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


   * What led up to the situation?
I have a windows computer with multiple monitors. I typically run 
applications on Raspbian via X windows. I recently installed Raspbian 
Bullseye on a Pi 4 and launched Libreoffice Calc via X windows. It 
launched but it kept flickering on the screen. It would go full screen 
and then get smaller and then go full screen and then get smaller. It 
flashed back and forth between these two sizes and I had to kill it.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I booted to the Raspbian desktop with a directly connected single 
monitor and launched Calc and it worked fine but I noticed it was full 
screen. I made it not full screen and closed it. I then launched it via 
X windows and it ran just fine when not full screen. I went back to the 
directly connected monitor and launched it and made it full screen and 
closed it.  Again I launched it via X windows and experienced the same 
flashing behavior. I tested this scenario on Raspbian Buster and it 
worked fine regardless if it was full screen or not.

   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Kernel: Linux 5.10.63-v7l+ (SMP w/4 CPU threads)
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

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

Versions of packages x11-common depends on:
ii  lsb-base  11.1.0+rpi1


Bug#958903: mutt: Broken file name in attachment if file name has cyrillic symbols (file name charset is UTF-8)

2021-12-13 Thread Kevin J. McCarthy

On Sun, 26 Apr 2020 16:34:57 +0300 Andrey Stankevich 
 wrote:

Package: mutt
Version: 1.10.1-2.1
Severity: normal

Dear Maintainer,

I attached file to outgoing mail in mutt.
File name has cyrillic symbols.
Number of cyrillic symbols in file name is bigger than approximately forty 
symbols.

In this case attached file has broken name in attachment in mutt (the file name 
is truncated to approximately forty symbols).
So recipient's MUA receive broken file name in attachment.
For example google mail named that attachment file as "noname".

It is expected nontruncated file name in attachment or warning message in case 
of file name truncating or warning message in status line should be in this 
case.


This was fixed in Mutt 1.12.0.  I believe this ticket can be closed.

-Kevin


signature.asc
Description: PGP signature


Bug#899992: mutt: allow spaces in "Open mailbox" prompt

2021-12-13 Thread Kevin J. McCarthy

Would it be possible to support mailboxes with spaces (and/or some
syntactic sugar to not have to type "notmuch://?query=" all the time)?


There are a couple solutions within your control.  You can rebind the 
editor menu  function to another key (or to noop): it 
defaults to space.  Alternatively, you can invoke , which 
defaults to control-v, before each space character.


-Kevin


signature.asc
Description: PGP signature


Bug#988390: gnome-gmail: test_body2html fails with Python 3.9.5

2021-12-13 Thread David Steele
Note that the released v2.8 has code to address this issue, but it has
not been tested against Python 3.9.5.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE



Bug#632570: fails to join RFC 2231 continuations

2021-12-13 Thread Kevin J. McCarthy

On Mon, 04 Jul 2011 00:59:46 +0900 Akihiro Terasaki  wrote:

mutt fails to join continuations.

Content-Disposition: attachment;
filename*0=foo;
filename*1=.;
filename*2=txt

mutt prints `footxt.', rather than the expected `foo.txt'.


I believe this was fixed in Mutt 1.6.0, and this ticket can be closed.

-Kevin


signature.asc
Description: PGP signature


Bug#1001013: mutt: 2.1.x regression - SMTP AUTH mandated if available

2021-12-13 Thread Kevin J. McCarthy

On Mon, 13 Dec 2021 19:00:47 -0800 "Kevin J. McCarthy"  wrote:
2.0.4 just came out, so I likely won't release 2.0.5 for at least a few 
weeks.


However, Antonio if you get around to packaging 2.0.4 before the 
release, feel free to grab the patch file.


Sigh... it's been a long day.  That should be 2.1.5 and 2.1.4.

-Kevin


signature.asc
Description: PGP signature


Bug#978457: phing: Not compatible with php8.0

2021-12-13 Thread Adrian Bunk
On Sun, Dec 27, 2020 at 03:25:49PM -0400, David Prévot wrote:
> Package: phing
> Version: 2.16.1-1
> Severity: important
> Tags: upstream
> Control: block 976811 by -1
> 
> phing is not compatible (at all) with PHP 8. A version 3 is on its way,
> but has been in alpha stage for months. It will hopefully be PHP 8
> compatible.

It is now at -rc3, and there are commits in git after that indicating 
that upstream is testing also PHP 8.1.

cu
Adrian



Bug#1001013: mutt: 2.1.x regression - SMTP AUTH mandated if available

2021-12-13 Thread Kevin J. McCarthy

On Mon, 13 Dec 2021 15:21:19 -0800 "Kevin J. McCarthy"  wrote:
I'll add a commit to the stable branch for 2.0.5, reverting the behavior 
to have either the smtp username or a client cert set before attempting 
authentication when AUTH is advertised.


I've added 
 
to the stable branch.


2.0.4 just came out, so I likely won't release 2.0.5 for at least a few 
weeks.


However, Antonio if you get around to packaging 2.0.4 before the 
release, feel free to grab the patch file.


-Kevin


signature.asc
Description: PGP signature


Bug#1001647:

2021-12-13 Thread Anja
Hi Jakub!

- VisiData fetching the list of startup messages he first time each day
that VisiData is used is documented in the privacy policy:
https://www.visidata.org/privacy/.
-
- As noted in the privacy policy, the network request can be turned off by
adding `options.motd_url=None` to your `~/.visidatarc`.
There is definitely a bug in v2.2.1 and earlier, where VisiData will access
the website each time it is used, in order to grab the list of plugins.
This bug was fixed in v2.3:
https://github.com/saulpw/visidata/blob/stable/CHANGELOG.md#bugfixes-5. I
have not updated the VisiData on debian yet post v2.2.1, because I wanted
to be certain of a stable candidate on debian. v2.8 coming up will have
that fix, and is a candidate for updating the Debian package. I can leave
this bug open as unresolved until that is done.

For now, you can set `options.plugins_url=None` to your `~/.visidatarc` to
turn that off. `open-plugins` will not work, but if you do not want your
software making network requests, you probably would not want that feature.

For a detailed explanation on why the author chose to have the network
requests on by default, please see this discussion:
https://github.com/saulpw/visidata/discussions/940


Bug#1001190: tracker.debian.org: news: emails: show Message-ID header, link to lists.d.o/msgid-search

2021-12-13 Thread Paul Wise
On Tue, 2021-12-07 at 09:44 +0800, Paul Wise wrote:

> When the List-Archive header exists and contains a URL, the link could
> be to that URL. This works for Debian lists and mailman lists and
> probably other types of lists too.

PS: I note that the mailman3 archiver uses Archived-At for the message
archive and List-Archive for the general list archive.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1001303: alure: FTBFS: -pthread: not found

2021-12-13 Thread Bastian Germann

On Tue, 7 Dec 2021 17:39:26 -0800 Steve Langasek  
wrote:

I don't know what is causing this misbehavior of the build system; if I look
at obj-x86_64-linux-gnu/CMakeCache.txt I see other variables using similar
separators but these only seem to leak onto the commandline for the
fluidsynth cflags:

FLUIDSYNTH_CFLAGS:INTERNAL=-D_REENTRANT;-pthread;-D_REENTRANT;-D_DEFAULT_SOURCE;-D_XOPEN_SOURCE=600;-I/usr/include/dbus-1.0;-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include;-I/usr/include/libinstpatch-2;-I/usr/include/glib-2.0;-I/usr/lib/x86_64-linux-gnu/glib-2.0/include;-I/usr/include/opus;-I/usr/include/SDL2


fluidsynth's current version 2.2.4 introduced the pkg-config field Requires.private in commit 
https://github.com/FluidSynth/fluidsynth/commit/de05ef2a1c89bd100a9a94e62bb44cf791094f87


It should be checked if this is a fluidsynth or alure bug.



Bug#1001536: cinnamon-control-center-goa: Online Accounts crashes when trying to add account with web login

2021-12-13 Thread Alejandro Morales Lepe
Hello! thanks for your reply! I'm very happy to see the commit on the
bullseye branch. 

I have been trying to test, however I am not familiar with the
desktop's code structure, so I couldn't build it. I looked around for
building instructions but I couldn't find something helpful. Is there
any documenation that could help me with that? 

I would appreciate any pointer to that. 

Cheers!
- Alejandro

On Sat, 2021-12-11 at 22:51 +0100, Fabio Fantoni wrote:
> Control: reassign -1 cinnamon 4.8.6-2
> 
> Il 11/12/2021 21:27, Alejandro Morales Lepe ha scritto:
> > Package: cinnamon-control-center-goa
> > Version: 4.8.2-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > When an user attempts to add an online account that requires
> > logging in through
> > a web component, such as, Google, Facebook, Microsoft and/or
> > Foursquare,
> > cinnamon-control-center crashes and quits without any further
> > prompt or
> > message. This behaviour is not present in accounts that do not need
> > a web
> > login, such as Nextcloud or IMAP/SMTP, which log in correctly and
> > sync with
> > other applications, such as being able to browse Nextcloud storage
> > from Nemo or
> > receiving and sending emails from Evolution. Accounts such as
> > Google, Facebook
> > and/or Microsoft should work in the same way.
> > 
> > This has been patched in upstream
> > (https://github.com/linuxmint/cinnamon/commit/77ed66050f7df889fcb7a10b702c7b8bcdeaa130
> > )
> > and included in release version 5.2.1 however since this affects
> > stable in its
> > current iteration, please consider backporting the patch into
> > stable to restore
> > functionality to a 100%
> > 
> > Let me know if I there is something I can do to help fixing this
> > issue in
> > current stable without having to wait until 5.2.1
> > 
> > Thank you very much!
> > Cheers!
> 
> thanks for report it, I did a fast commits with the upstream patch
> but I 
> not have time to test it today, if you want test it you can build
> from 
> source:
> 
> https://salsa.debian.org/cinnamon-team/cinnamon/-/tree/bullseye
> 
> or manually install auto tests packages (I never used but should
> works 
> FWIK):
> 
> https://salsa.debian.org/cinnamon-team/cinnamon/-/jobs/2268748/artifacts/browse/debian/output/
> 
> 



Bug#1001673: ITP: golang-github-icza-gox -- Minimalistic extension to Go. It means to be a complement to the standard library.

2021-12-13 Thread Stephen Gelman
Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-icza-gox
  Version : 0.0~git20210726.cd40a3f-1
  Upstream Author : András Belicza
* URL : https://github.com/icza/gox
* License : Apache-2.0
  Programming Lang: Go
  Description : Minimalistic extension to Go. It means to be a complement 
to the standard library.

 The gox module is a minimalistic, lightweigt extension to Go. It
 contains constants, helpers and utilities which could have been part of
 Go itself.

This package will be maintained by the go team



Bug#1001672: ITP: certinfo -- print x509 certificate info

2021-12-13 Thread Stephen Gelman
Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: certinfo
  Version : 1.0.6-1
  Upstream Author : Peter Reisinger
* URL : https://github.com/pete911/certinfo
* License : Expat
  Programming Lang: Go
  Description : Print x509 certificate info

 Print x509 certificate info
 .
 Similar to openssl x509 -in  -text command, but handles chains,
 multiple files and TCP addresses. TLS/SSL version prints as well when
 using TCP address argument.

This package will be maintained by the go packaging team



Bug#1001671: RM: xfstt -- ROM; low utility in Debian

2021-12-13 Thread Guillem Jover
Package: ftp.debian.org
Severity: normal

Hi!

I'm both the upstream and the maintainer in Debian. The X servers in
Debian have disabled X Font Server support for a long time now, so
this package is mostly of use to serve fonts for other non-Debian (or
derivative) systems. In addition I've since fully switched to Wayland
and I even run very few X11 native applications (expecting to lower
that to 0 soon enough). As such I'm going to put the project upstream
in low maintenance mode, and eventually even mark it as unmaintained.

Even though I've got some attachment to this package, as it was the
first that I started maintaining in Debian (almost 20 years ago!), I
think the time to remove it from the archive has come. :)

Thanks,
Guillem



Bug#1001666: stress-ng: flaky autopkgtest

2021-12-13 Thread Colin King (gmail)

Hi Sebastian,

thanks for reporting this. Is is OK to ask a few questions as I've never 
seen this before on a wide range of kit that I test this on.


1. Is this failure repeatable? (I'm not sure how it occurs since there 
is a SIGSEGV handler for these cases).

2. Does it fail on specific machines?
3. What CPU model is the machine it fails on?

I've tried to understand this failure, but so far I'm quite perplexed by 
it, so maybe it's a CPU specific caching behavior that I have misunderstood.


Any assistance with the questions above would be most useful,

Regards,

Colin


On 13/12/2021 21:48, Sebastian Ramacher wrote:

Source: stress-ng
Version: 0.13.08-1
Severity: important
X-Debbugs-Cc: sramac...@debian.org

The autopkgtests of stress-ng fail from time to time:
| stress-ng: 20:49:12.58 info:  [1091] unsuccessful run completed in 0.51s
| stress-ng: 20:49:12.58 fail:  [1091] cache instance 3 corrupted bogo-ops 
counter, 2 vs 0
| stress-ng: 20:49:12.58 fail:  [1091] cache instance 3 hash error in bogo-ops 
counter and run flag, 796547380 vs 0
| stress-ng: 20:49:12.58 fail:  [1091] metrics-check: stressor metrics 
corrupted, data is compromised
| cache FAILED
...
| zlib PASSED
| 42 PASSED
| 1 FAILED, cache
| 0 SKIPPED

See
https://ci.debian.net/data/autopkgtest/testing/amd64/s/stress-ng/17550292/log.gz
for a recent failure

Cheers





Bug#1001013: mutt: 2.1.x regression - SMTP AUTH mandated if available

2021-12-13 Thread Kevin J. McCarthy

On Thu, 2 Dec 2021 18:51:39 +0100 Andreas Metzler  wrote:

After todays mutt upgrade (from 2.0) mutt suddenly *requires* successful
SMTP AUTH when sending mail, at least when the SMTP server advertises
AUTH support. (My server=localhost offers AUTH, but does not require it).
There does not seem to be a way to configure mutt to send without
successful SMTP AUTH.
With
smtp_url="smtp://localhost"
and unset smtp_pass now mutt prompts for user/password. Changing
smtp_authenticators to an value not offered by the server yields
SASL authentication failed
and setting smtp_authenticators="invalid" yields
No authenticators available


Sorry this was a mistake in fixing client-certificate authentication.  I 
incorrectly assumed if the server was advertising AUTH at that point it 
was required.


I'll add a commit to the stable branch for 2.0.5, reverting the behavior 
to have either the smtp username or a client cert set before attempting 
authentication when AUTH is advertised.


-Kevin


signature.asc
Description: PGP signature


Bug#1001669: openvpn-auth-ldap: flaky autopkgtest on amd64

2021-12-13 Thread Sebastian Ramacher
Source: openvpn-auth-ldap
Version: 2.0.4-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

The autopkgtests of openvpn-auth-ldap are flaky and fail with:
| This is going to take a long time
| 
.++..+...+...+..+...+.+.+.+...+..+..+.+..+..+++..+.+.+.++...+.+..+..+.+..+...+.+...+.+..++*++*++*++*
|
| Server started, sleeping 3 seconds...
| User not connected to VPN.
| autopkgtest [02:24:01]: test openldap-connect.sh: ---]

For a failing test, see
https://ci.debian.net/data/autopkgtest/testing/amd64/o/openvpn-auth-ldap/16855997/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#948674: RFP: otter-browser -- Fast and configurable web browser inspired by Opera 12

2021-12-13 Thread Gürkan Myczko

Hi Ritesh

Did you mean to work on this, do you already have something? Would you 
like

to form a team to work on it?

I've got a working package that needs more d/copyright tuning here:
https://mentors.debian.net/package/otter-browser/

Best,



Bug#1001655: Avoid hardcoding depends on specific lzip implementations

2021-12-13 Thread Felix Lechner
Hi Daniel,

On Mon, Dec 13, 2021 at 2:00 PM Daniel Baumann
 wrote:
>
> all of them, except lzd, do implement --test.

Looking at your documentation [1] does that mean Lintian can only
offer the alternatives except lzd?

Or, is there another way to assess the actual nature or integrity of a
file named like *.lz? Thanks!

Kind regards
Felix Lechner

[1] https://sources.debian.org/src/lzip/1.22-4/debian/lzip.README.Debian/



Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

2021-12-13 Thread Moritz Muehlenhoff
On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:
> On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:
> > Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> > Exactly that.
> > 
> > I'd suggest anyone who's interested in seeing Chromium supported to first
> > update it in unstable (and then work towards updated in bullseye-security).
> 
> I started doing just that: https://salsa.debian.org/dilinger/chromium (v96
> and misc-fixes branches).

As a side note: If any of the system/* patches cause issues, feel free to switch
to the vendored copies. Vendoring in general is frowned upon since it requires 
that
a fix in a libraries spreads out to all vendored copies, but for Chromium 
there's
a steady stream of Chromium-internal security issues anyway, so for all
practical purposes it doesn't make a difference if the Chromium security 
releases
also include a fix for a vendored lib like ICU.

Cheers,
Moritz



Bug#1001668: timew: autopkgtest failure on ppc64el

2021-12-13 Thread Sebastian Ramacher
Source: timew
Version: 1.4.3+ds.1-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

timew's autopkgtest fails on ppc64el from time to time:
| not ok 2 - gaps.t: Add one interval, with exclusions
| # ERROR: CommandError on file 
/tmp/autopkgtest-lxc.k_0e724b/downtmp/autopkgtest_tmp/test/gaps.t line 60 in 
test_single_unobstructed_interval_with_exclusions: 
'self.t.configure_exclusions((time(18, 0, 0), time(9, 0, 0)))':
| #Command 
'('/tmp/autopkgtest-lxc.k_0e724b/downtmp/autopkgtest_tmp/src/timew', ':yes', 
'config', 'exclusions.saturday', '<09:00:00 >18:00:00')' was SIGABRT'ed. 
SIGABRT usually means program timed out.
| #
| #*** Start STDOUT ***
| #
| #*** End STDOUT ***
| #
| #*** Start STDERR ***
| #
| #*** End STDERR ***

See
https://ci.debian.net/data/autopkgtest/testing/ppc64el/t/timew/16796747/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#1001625: python3-script-but-no-python3-dep unoverridable

2021-12-13 Thread Felix Lechner
Hi Marc,

On Mon, Dec 13, 2021 at 4:33 AM Marc Haber
 wrote:
>
> I wondering whether the missing leading backslash in the path is
> correct.

You probably meant a regular slash, and not a backslash. Lintian has
used such relative-looking path names since before it found me. The
only exception I know of is the hint annotation, which is usually
taken verbatim from your code. It can include leading slashes (for
conffiles, for example, which are absolute).

The path you asked about is part of a pointed hint. It includes file
information that will soon be a live link on our website. [1] Those
paths are taken straight from Lintian's in-memory copy of the file
index. [2]

[1] https://bugs.debian.org/743226
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Index.pm#L393-396

> debian/sudo-ldap.lintian-overrides:sudo-ldap: 
> python3-script-but-no-python3-dep /usr/bin/python3 
> [usr/share/apport/package-hooks/*]

Our Git version already moved past your 2.114.0 with respect to
override treatments. We now allow globbing patterns [3] using
Text::Glob. [4] Unfortunately, the square bracket I recently selected
for file pointers is cumbersome to escape. The backslash \[ does not
work, while [[] (from bash) and the question mark ? both work. You
could leave out the ending ] or use the even more awkward-looking []].
None of that is great for users.

Overrides are currently in flux. Maybe overrides should be in a more
capable format, such as Deb822. In your case, that would probably look
something like:

Tag: python3-script-but-no-python3-dep
Note: /usr/bin/python3
Pointer: usr/share/apport/package-hooks/*

Perhaps I should also add a tool for users to generate or modify
overrides interactively. I have used something similar for years in
Lintian's test suite to recalibrate tests for sweeping changes.

Kind regards
Felix Lechner

[3] 
https://salsa.debian.org/lintian/lintian/-/commit/139009d5a54225ebff4509ec37b979cb898c17fe
[4] https://metacpan.org/pod/Text::Glob



Bug#1001331: [pkg-gnupg-maint] Bug#1001331: gpg: Provide interface to inspect (detached) signatures

2021-12-13 Thread Werner Koch
Hi!

> I cannot stop using as I do not know of a publicly supported interface
> to inspect a (detached) signature to get its issuer fingerprint or
> keyid.

You can do this:

  gpg --verify --status-fd 1 x.asc /dev/null 2>/dev/null \
| awk '$1=="[GNUPG:]" && $2=="BADSIG" { print $3}'

which greps for 

[GNUPG:] BADSIG 19CC1C9E085B107A w...@gnupg.org

This shows the keyid but not the newer fingerprint.  Adding something
for the fingerprint would be easy, but it takes some time before it will
be widely enough deployed.  


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature


Bug#1001655: Avoid hardcoding depends on specific lzip implementations

2021-12-13 Thread Daniel Baumann

Hi Felix

On 12/13/21 21:18, Felix Lechner wrote:

We only use the '--test' functionality. Is that implemented by all
alternatives?


all of them, except lzd, do implement --test.


Also, do we still need to determine the proper name of the executable,
as introduced in this commit?


there are alternatives in place since jessie,
you can just call /usr/bin/lzip:

$ update-alternatives --list lzip
/usr/bin/lzip.clzip
/usr/bin/lzip.lunzip
/usr/bin/lzip.lzd
/usr/bin/lzip.lzip
/usr/bin/lzip.lziprecover
/usr/bin/lzip.minilzip
/usr/bin/lzip.pdlzip
/usr/bin/lzip.plzip
$

Regards,
Daniel



Bug#1001667: flam3: flaky autopkgtest on ppc64el

2021-12-13 Thread Sebastian Ramacher
Source: flam3
Version: 3.1.1-5
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

flam3's autopkgtest on ppc64el fails from time to time with:
| autopkgtest [21:29:50]: test genome.sh: [---
| Segmentation fault
| autopkgtest [21:29:51]: test genome.sh: ---]
| genome.shFAIL non-zero exit status 139
| autopkgtest [21:29:51]: test genome.sh:  - - - - - - - - - - results - - - - 
- - - - - -

See
https://ci.debian.net/data/autopkgtest/testing/ppc64el/f/flam3/17548224/log.gz

The failure is indepentend of the package triggering the autopkgtest.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#1001666: stress-ng: flaky autopkgtest

2021-12-13 Thread Sebastian Ramacher
Source: stress-ng
Version: 0.13.08-1
Severity: important
X-Debbugs-Cc: sramac...@debian.org

The autopkgtests of stress-ng fail from time to time:
| stress-ng: 20:49:12.58 info:  [1091] unsuccessful run completed in 0.51s
| stress-ng: 20:49:12.58 fail:  [1091] cache instance 3 corrupted bogo-ops 
counter, 2 vs 0
| stress-ng: 20:49:12.58 fail:  [1091] cache instance 3 hash error in bogo-ops 
counter and run flag, 796547380 vs 0
| stress-ng: 20:49:12.58 fail:  [1091] metrics-check: stressor metrics 
corrupted, data is compromised
| cache FAILED
...
| zlib PASSED
| 42 PASSED
| 1 FAILED, cache
| 0 SKIPPED

See
https://ci.debian.net/data/autopkgtest/testing/amd64/s/stress-ng/17550292/log.gz
for a recent failure

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#1001665: silx: autopkgtests failures

2021-12-13 Thread Sebastian Ramacher
Source: silx
Version: 0.15.2+dfsg-3
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

The autopkgtests of silx fail with:
|  [7 8 9]]
| Abscissa Ordinate1 ['%d', '%.2f'] 2 [1 2 3] [4 5 6]
| Abscissa Ordinate2 ['%d', '%.2f'] 2 [1 2 3] [7 8 9]
| Abscissa Ordinate1 ['%d', '%.2f'] 2 [1 2 3] [4 5 6]
| x y ['%d', '%.2f'] 2 [1] [1.1]
| x y ['%d', '%.2f'] 2 [1] [1.1]
| 
./usr/lib/python3/dist-packages/silx/math/fit/test/test_fit.py:54:
 RuntimeWarning: invalid value encountered in multiply
|   return numpy.exp(x*numpy.less(abs(x), 250)) - \
| 
sss...WARNING:silx.opencl.common:Last
 chance to get an OpenCL device ... probably not the one requested
| Segmentation fault

See
https://ci.debian.net/data/autopkgtest/testing/arm64/s/silx/17544040/log.gz

The failure seems to be independet of the packages that trigger the
autopkgtest run.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#1001661: notcurses: flaky autopkgtests on armhf

2021-12-13 Thread nick black
Thanks for the heads-up. I believe/hope that this is the same issue that 
affected our ARM MacOS builds and Alpine i686/ARMHF builds through the 3.0.0 
release, and which has been fixed in the 3.0.1 release:

 https://github.com/dankamongmen/notcurses/issues/2420

3.0.0 is currently in the NEW queue, uploaded to experimental, pending approval 
from the FTPteam (new SONAME -> libnotcurses3). Once it is approved, I will 
upload 3.0.1 (or a newer release, if one exists) to unstable, and I expect that 
this will address this problem.

In the meantime, since the fix is small and precise, I could easily prepare a 
patch for 2.4.9. I think I will go ahead and do so, both to support/disabuse 
the notion that this is the same issue, and since FTPteam + TransitionTeam 
could take significant time.


signature.asc
Description: PGP signature


Bug#992361: [Python-modules-team] Bug#992361: O: python-slip

2021-12-13 Thread Michael Biebl
On Mon, 8 Nov 2021 18:34:55 +0100 Laurent Bigonville 
wrote:
> On Fri, 20 Aug 2021 11:59:20 +0200 Michael Biebl  wrote:
>  > Am 19.08.21 um 22:29 schrieb Emmanuel Arias:
> 
>  >
>  > As bigon mentioned earlier though, selinux-{dbus, python} will drop
this
>  > dependency in a few months. At that point, there will be no remaining
>  > rdeps of python-slip.
>  >
>  > > Also I look in the popcon, but I don't know how to interpret it, I 
> mean,
>  > > for example,
>  > > how many downloads are a "good number".
>  > >
>  > > So, what is your recommendation? Take python-slip and other package 
> mark
>  > > as orphan?
>  > > or it's a good idea to leave it for newcomers?
>  >
>  > I have no opinion on whether it is useful to keep python-slip or not.
> 
> For the record, I just uploaded today the new version of the two selinux 
> related package.
> 
> There is nothing in the archive should depend on python-slip anymore
> 
> I also don't really have an opinion on whether we need to keep 
> python-slip or not.

Fwiw, I've asked for the removal of the package now.
See #1001662



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


Bug#1001663: r-cran-satellite: autopkgtest failure on ppc64el

2021-12-13 Thread Sebastian Ramacher
Source: r-cran-satellite
Version: 1.0.4-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

r-cran-satellite's autopkgtest fails on ppc64el:
| == Failed tests 

| -- Error (test-extend.R:9:1): (code run outside of `test_that()`) 
--
| Error in `(function (classes, fdef, mtable) 
| {
| methods <- .findInheritedMethods(classes, fdef, mtable)
| if (length(methods) == 1L) 
| return(methods[[1L]])
| else if (length(methods) == 0L) {
| cnames <- paste0("\"", vapply(classes, as.character, 
| ""), "\"", collapse = ", ")
| stop(gettextf("unable to find an inherited method for function %s for 
signature %s", 
| sQuote(fdef@generic), sQuote(cnames)), domain = NA)
| }
| else stop("Internal error in finding inherited methods; didn't return a 
unique method", 
| domain = NA)
| })(list(structure("Satellite", package = "satellite")), 
new("standardGeneric", 
| .Data = function (x, y, ...) 
| standardGeneric("extend"), generic = structure("extend", package = 
"terra"), 
| package = "terra", group = list(), valueClass = character(0), 
| signature = c("x", "y"), default = NULL, skeleton = (function (x, 
| y, ...) 
| stop("invalid call in method dispatch to 'extend' (no default method)", 
| domain = NA))(x, y, ...)), )`: unable to find an 
inherited method for function 'extend' for signature '"Satellite"'
| Backtrace:
| x
|  1. \-terra::extend(sat, ext_ggs) test-extend.R:9:0
|  2.   \-(function (classes, fdef, mtable) ...
|
| [ FAIL 1 | WARN 0 | SKIP 12 | PASS 139 ]
| Error: Test failures
| Execution halted

See
https://ci.debian.net/data/autopkgtest/testing/ppc64el/r/r-cran-satellite/17550288/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#1001664: olm: CVE-2021-44538: buffer overflow in olm_session_describe

2021-12-13 Thread Salvatore Bonaccorso
Source: olm
Version: CVE-2021-44538
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for olm.

CVE-2021-44538[0]:
| buffer overflow in olm_session_describe

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-44538
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44538
[1] 
https://matrix.org/blog/2021/12/13/disclosure-buffer-overflow-in-libolm-and-matrix-js-sdk

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#947179: linux-image-5.3.0-3-amd64: Please provide CoreBoot (Google) firmware drivers

2021-12-13 Thread Uwe Kleine-König
Hello Tobias,

On Sun, Dec 22, 2019 at 04:45:12PM +0100, Tobias Gruetzmacher wrote:
> Package: src:linux
> Version: 5.3.15-1
> Severity: wishlist
> 
> it would be nice if the Debian kernel would provide drivers to interact
> with CoreBoot. As far as I can see, those are "hidden" behind
> CONFIG_GOOGLE_FIRMWARE ...
> 
> These seem to be all available as modules, so it won't hurt to switch
> them on, right? (If I understand drivers/firmware/google/Makefile
> correctly)
> 
> For reference:
> 
> CONFIG_GOOGLE_FIRMWARE=y
> CONFIG_GOOGLE_SMI=m
> CONFIG_GOOGLE_COREBOOT_TABLE=m
> CONFIG_GOOGLE_MEMCONSOLE=m
> CONFIG_GOOGLE_MEMCONSOLE_X86_LEGACY=m
> CONFIG_GOOGLE_FRAMEBUFFER_COREBOOT=m
> CONFIG_GOOGLE_MEMCONSOLE_COREBOOT=m
> CONFIG_GOOGLE_VPD=m

The helptext for GOOGLE_FIRMWARE reads:

  These firmware drivers are used by Google's servers.  They are
  only useful if you are working directly on one of their
  proprietary servers.  If in doubt, say "N".

Is this text wrong, or are you working on Google's servers? In case
you're not on Google's servers: Did you verify these settings are
beneficial on your machine?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature


Bug#1001662: RM: python-slip -- ROM; dead upstream, no more reverse dependencies

2021-12-13 Thread Michael Biebl
Package: ftp.debian.org
Severity: normal

Hi,

please consider removing python-slip from the archive.

It was a dependency of firewalld and selinux in the past, but this is no
longer the case.
The package is also basically dead upstream (last significant changes in
2015).

I've orphaned the package in [1] but failed to find a new maintainer.
So I think it's best to remove src:python-slip from the archive.

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992361



Bug#1001661: notcurses: flaky autopkgtests on armhf

2021-12-13 Thread Sebastian Ramacher
Source: notcurses
Version: 2.4.9+dfsg.1-1
Severity: important
X-Debbugs-Cc: sramac...@debian.org

notcurses' autopkgtest fail from time to time on armhf:
| bash: line 1:  5188 Segmentation fault  bash -ec 'TERM=xterm-256color 
notcurses-demo -d0 -c' 2> >(tee -a 
/tmp/autopkgtest-lxc.w6ikw2j4/downtmp/demo-stderr >&2) > >(tee -a 
/tmp/autopkgtest-lxc.w6ikw2j4/downtmp/demo-stdout)
| autopkgtest [23:46:21]: test demo: ---]
| autopkgtest [23:46:21]: test demo:  - - - - - - - - - - results - - - - - - - 
- - -
| demo FAIL non-zero exit status 139

For a recent failure see
https://ci.debian.net/data/autopkgtest/testing/armhf/n/notcurses/17505950/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#999041: libimage-base-bundle-perl: diff for NMU version 1.0.7-3.3

2021-12-13 Thread gregor herrmann
Control: tags 999041 + patch
Control: tags 999041 + pending


Dear maintainer,

I've prepared an NMU for libimage-base-bundle-perl (versioned as 1.0.7-3.3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Donovan: Dignity Of Man
diff -u libimage-base-bundle-perl-1.0.7/debian/changelog libimage-base-bundle-perl-1.0.7/debian/changelog
--- libimage-base-bundle-perl-1.0.7/debian/changelog
+++ libimage-base-bundle-perl-1.0.7/debian/changelog
@@ -1,3 +1,12 @@
+libimage-base-bundle-perl (1.0.7-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": add targets in debian/rules.
+(Closes: #999041)
+
+ -- gregor herrmann   Mon, 13 Dec 2021 22:11:34 +0100
+
 libimage-base-bundle-perl (1.0.7-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libimage-base-bundle-perl-1.0.7/debian/rules libimage-base-bundle-perl-1.0.7/debian/rules
--- libimage-base-bundle-perl-1.0.7/debian/rules
+++ libimage-base-bundle-perl-1.0.7/debian/rules
@@ -50,7 +50,7 @@
 	touch $@
 
 
-build: unpack patch $(foreach foo,$(DEB_PACKAGES),build-$(foo)-stamp)
+build-indep: unpack patch $(foreach foo,$(DEB_PACKAGES),build-$(foo)-stamp)
 build-%-stamp:
 	dh_testdir
 
@@ -61,6 +61,11 @@
 
 	touch $@
 
+# do nothing
+build-arch:
+
+build: build-indep
+
 clean:
 	dh_testdir
 	dh_testroot
@@ -104,7 +109,7 @@
 	dh_builddeb
 
 binary: binary-indep
-.PHONY: unpack build clean binary-indep binary-arch binary install
+.PHONY: unpack build-indep build-arch build clean binary-indep binary-arch binary install
 
 
 


signature.asc
Description: Digital Signature


Bug#1001651: lintian: changelog-file-missing-explicit-entry: false positives with successive stable uploads

2021-12-13 Thread Felix Lechner
Control: forcemerge 941656 -1
Control: severity 941656 important

Hi,

On Mon, Dec 13, 2021 at 11:00 AM Cyril Brulebois  wrote:
>
> W: debian-installer source: changelog-file-missing-explicit-entry 
> 20210731+deb11u1 -> 20210731 (missing) -> 20210731+deb11u2

Your case from stable was already mentioned in the other bug. [1] Merging.

A better course of action might have been to retitle the bug to
describe the failure better. I did that now.

I also upgraded the priority to your requested level of 'important'.

On a side note, version parsing is one of the more complex subjects in
Debian. Thanks!

Kind regards
Felix Lechner

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941656#20



Bug#1001660: bcolz: autopkgtest python3-bcolz fails to run any tests

2021-12-13 Thread Julian Gilbey
Source: bcolz
Version: 1.2.1+ds2-7
Severity: normal
Tags: patch

In the script debian/tests/python3-bcolz, it reads:

cd /
for py in $(py3versions -r 2>/dev/null); do

However, py3versions -r fails to return any python versions if it is
not run from the top of the source tree, and this error is invisible.

The correction is simple: run the cd command after the py3versions -r:

#!/bin/sh
set -e
for py in $(py3versions -r 2>/dev/null); do
cd /
echo "[*] testing $py:"
$py -c 'import bcolz; bcolz.test(verbose=True)' 2>&1
done

Best wishes,

   Julian



Bug#1001656: rust-quickcheck: new upstream release 1.0.3

2021-12-13 Thread peter green

The quickcheck crate has released version 1.0 a while back.


Looking at the git history, it seems the changes between 0.9.3
and 1.0.0 were fairly minor, so in most cases I suspect this can
be addressed by patching dependencies.



This new version itself depends on:

 - rand 0.8 (unstable only has version 0.7.3-3)


In general when looking at dependency bumps, I often use the blame feature on 
github
and similar sites (which IME are far easier to use than the command line git 
blame) to
see if any other changes were made at the same time as the dependency bump 
upstream.

The changes for rand 0.8 look relatively small and easy to back out to me.

https://github.com/BurntSushi/quickcheck/commit/319145dfb9e8e1f2d405276bb88ac03b7f56aca3

I think it probably makes sense to do a rust-rand 0.8.x transition at some 
point in the not too
distant future , but I would personally wait until other transitions such as 
futures/tokio
and the rust gtk stack are over.


 - env_logger 0.8.2 (unstable already has 0.9.0-1)


rust-quickcheck was already patched in Unstable by a NMU to use env_logger 0.9, 
so I can't see
this being a problem.

  librust-im-rc+quickcheck-dev 15.0.0-1 depends on librust-quickcheck-0.9+default-dev, 
  librust-petgraph+all-dev 0.5.0-1  depends on librust-quickcheck-0.9-dev | librust-quickcheck-0.8-dev, 
  librust-petgraph+quickcheck-dev  0.5.0-1  depends on librust-quickcheck-0.9-dev | librust-quickcheck-0.8-dev,


It doesn't look like these feature packages have any reverse dependencies, so 
worst
case, they could be dropped if they can't reasonablly be fixed.
(I suspect they will be easy enough to fix though)


Source packages in unstable whose autopkgtests are triggered by rust-quickcheck:


rust packages in Debian generally have "skip if uninstallable" set on their 
autopkgtests.
So these aren't directly blockers (though it would be nice to fix them if 
possible).


This might be a kind of messy transition, so i'm opening this ticket to
keep track of it.


It doesn't look that bad to me.



Bug#1001655: Avoid hardcoding depends on specific lzip implementations

2021-12-13 Thread Felix Lechner
Hi Daniel,

On Mon, Dec 13, 2021 at 11:36 AM Daniel Baumann
 wrote:
>
>if only decompression is used:
>'lzip | lzip-decompressor'

We only use the '--test' functionality. [1] Is that implemented by all
alternatives?

Also, do we still need to determine the proper name of the executable,
as introduced in this commit? [2] Thanks!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/Compressed/Lz.pm#L61
[2] 
https://salsa.debian.org/lintian/lintian/-/commit/bc64d63c4ecd293687524086b6966e30e9c48ae0



Bug#990877: Proposed patch upstream

2021-12-13 Thread Mathieu Parent
Proposed an MR: https://gitlab.com/ita1024/waf/-/merge_requests/2336

Regards
-- 
Mathieu Parent


Bug#968162: ITP: toybox -- BSD-licensed Linux command line utilities

2021-12-13 Thread Bastian Germann

On Wed, 27 Oct 2021 12:11:36 + Antoni Villalonga  wrote:

You are very welcome to sponsor the package.
Let me update my git repo at salsa with last upstream version and Debian Policy
related changes.


Hi Antoni,

I am sorry for not having had a better look at the package.
Can you please update to 0.8.6 that was released recently and check if it has 
the 0.8.5 issues fixed?
I will make sure to have a look at it in this year.

Thanks,
Bastian



Bug#988044: linux-image-5.10.0-0.bpo.4-amd64: Kernel panic due nfsd error: refcount_t: addition on 0; use-after-free

2021-12-13 Thread Salvatore Bonaccorso
Hi Olivier,

On Mon, Nov 22, 2021 at 09:27:26AM +, Olivier Monaco wrote:
> Hi Salvatore,
> 
> Sorry for my very very late answer.
> 
> I tried many actions to reproduce and/or fix this problem. We
> upgraded our kernel to the lastest backport version for Buster but
> the issue was still there. We upgraded to Bullseye at the end of
> October but today this issue occurred again. 
> 
> I think it related to 
> https://lore.kernel.org/linux-nfs/yv3vdqopvgxc%2f...@eldamar.lan/
> 
> I just send an email to this thread. 
> 
> Something that may be important: our groups of servers are used to
> host websites, some with only one website, some with many. For now,
> this issue only occurred on NFS servers part of a group with many
> websites. But one of the most loaded NFS server is also used only
> for one website and has never had this issue. May be this issue
> occurs only when the NFS server is serving many different files.

I was never able to reliably reproduce the issue myself, but upstream
now thinks to have isolated the issue and should be fixed with:

https://git.kernel.org/linus/548ec0805c399c65ed66c6641be467f717833ab5

Fixes are as well queued to stable series.

Regards,
Salvatore



Bug#1001659: python-pomegranate: autopkgtest run-tests doesn't actually do anything

2021-12-13 Thread Julian Gilbey
Source: python-pomegranate
Version: 0.13.5-2
Severity: normal
Tags: patch

The current autopkgtest script reads:

cd "$AUTOPKGTEST_TMP"
for py in $(py3versions -r 2>/dev/null)
do ${py} -m nose -v tests
done

But after the cd "$AUTOPKGTEST_TMP", py3versions -r fails to return
any python version, so the loop is never run.

A corrected version is obtained by running the cd after the
py3versions:

for py in $(py3versions -r 2>/dev/null)
cd "$AUTOPKGTEST_TMP"
do ${py} -m nose -v tests
done

Best wishes,

   Julian



Bug#993876: Crash after recent glibc update

2021-12-13 Thread Marc Haber
tags #993876 confirmed pending
thanks

On Sun, Oct 31, 2021 at 11:16:41AM +0100, Marc Haber wrote:
> It is my recommendation to all users experiencing these issues to
> replace aide with aide-dynamic for the time being and report any
> issues that might arise with the dynamically linked binary. The aide
> Debian team will provide a supported upgrade path both from statically
> linked aide.deb and dynamically linked aide-dynamic.deb to the new (not
> yet existing) dynamically linked aide.deb, if possible.

This upgrade path is now present in Debian unstable. Existing
installations of both aide-dynamic and the static aide will automatally
be migrated to a new dynamic aide package.

Please report any issues you might encounter.

I will keep this bug open until end of January 2022 for reference.

Greetings
Marc



Bug#996875: aide: 31_aide_spamassassin needs update for SpamAssassin 3.4.6

2021-12-13 Thread Marc Haber
tags #996875 confirmed pending
thanks

On Wed, Oct 20, 2021 at 09:15:00AM +0300, Rimas Kudelis wrote:
> SpamAssassin stores its files in a version-dependent subdirectory of 
> /var/lib/spamassassin.
> Currently, 31_aide_spamassassin contains the following line:
> @@define SABASE var/lib/spamassassin/3.004002
> 
> This line targets SpamAssassin 3.4.2 specifically, however, the package has 
> already been updated to a newer version in several Debian releases:
> - buster-backports has 3.4.4
> - bullseye, bookworm and sid has 3.4.6
> - experimental has 4.0.0 (let's ignore this for now)

I have committed the change to git.

Unfortunately, the Debian aide maintainers not not have the capacity to
keep all package rules current in time. Usually, we notice changes in
packages after the release, which is too late.

It would be a good idea if the packages would deliver their own aide
rules, as they are probably easier to update for the respective package
maintainers. A file /etc/aide/aide.conf.d/31_spamassassin delivered by
the spamassassin package will automatically be used by aide. See
/usr/share/doc/aide-common/README.Debian.gz for details.

Greetings
Marc



Bug#1001658: singular: cannot upgrade to 1:4.2.1-p2+ds-3

2021-12-13 Thread Patrice Duroux
Package: singular
Version: 1:4.1.1-p2+ds-4+b3
Severity: wishlist

Dear Maintainer,

Here is what I am getting:

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

The following packages have unmet dependencies:
 libsingular4m1 : Breaks: libsingular
E: Broken packages

I do not know also why apt transaction is aborted while there are some
other package to upgrade. Is this also a trouble in apt?

Thanks,
Patrice

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

Kernel: Linux 5.14.0-1-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages singular depends on:
ii  singular-data 1:4.1.1-p2+ds-4
pn  singular-modules  
pn  singular-ui   

singular recommends no packages.

singular suggests no packages.

-- no debconf information



Bug#1001657: ball: binary-any FTBFS

2021-12-13 Thread Adrian Bunk
Source: ball
Version: 1.5.0+git20180813.37fc53c-9
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=ball&ver=1.5.0%2Bgit20180813.37fc53c-9

...
dh_installdocs
install -d debian/libball1.5/usr/share/doc/libball1.5
install -p -m0644 debian/copyright 
debian/libball1.5/usr/share/doc/libball1.5/copyright
install -d debian/libball1.5-dev/usr/share/doc/libball1.5-dev
install -p -m0644 debian/copyright 
debian/libball1.5-dev/usr/share/doc/libball1.5-dev/copyright
install -d debian/libballview1.5/usr/share/doc/libballview1.5
install -p -m0644 debian/copyright 
debian/libballview1.5/usr/share/doc/libballview1.5/copyright
install -d debian/libballview1.5-dev/usr/share/doc/libballview1.5-dev
install -p -m0644 debian/copyright 
debian/libballview1.5-dev/usr/share/doc/libballview1.5-dev/copyright
install -d debian/python3-ball/usr/share/doc/python3-ball
install -p -m0644 debian/copyright 
debian/python3-ball/usr/share/doc/python3-ball/copyright
install -p -m0644 debian/copyright 
debian/ballview/usr/share/doc/ballview/copyright
install -d debian/ballview/usr/share/doc-base/
install -p -m0644 debian/ballview.doc-base 
debian/ballview/usr/share/doc-base/ballview.ballview
find debian/*/usr/share -type d -empty -delete
find debian/*/usr/share -name jquery.js -delete
find debian/*/usr/share -name license.txt -delete
mv debian/libball1.5-data/usr/share/BALL-1.5/BALLView/html 
debian/libball1.5-data/usr/share/doc/libball1.5-data/BALLView
mv: cannot stat 'debian/libball1.5-data/usr/share/BALL-1.5/BALLView/html': No 
such file or directory
make[1]: *** [debian/rules:158: override_dh_installdocs] Error 1



Bug#1001643: Acknowledgement (sdaps: fails to setup a project with texlive-latex-extra/unstable (2021.2021127-1))

2021-12-13 Thread Vincent-Xavier JUMEL
Bug reported upstream, since there a version mismatch between sdaps-class
(1.9.10) and sdaps (1.9.9)

I've filled a bug : https://github.com/sdaps/sdaps/issues/238

Meanwhile, Debian could version bump the package to 1.9.9

Le 13 déc. à 18:39 Debian Bug Tracking System a écrit
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1001643: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001643.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian Edu Packaging Team 
> 
> If you wish to submit further information on this problem, please
> send it to 1001...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 1001643: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001643
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

-- 
Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net

Société Libre, Logiciel Libre http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org



Bug#1001656: rust-quickcheck: new upstream release 1.0.3

2021-12-13 Thread Daniel Kahn Gillmor
Package: src:rust-quickcheck
Version: 0.9.2-1.1
Control: affects -1 src:rust-rand src:rust-env-logger src:rust-sequoia-openpgp

The quickcheck crate has released version 1.0 a while back.

Some crates are starting to depend on that semver bump (in particular,
i noticed this becausei've just uploaded rust-xxhash-rust to NEW, and it
depends on version 1.0).

This new version itself depends on:

 - rand 0.8 (unstable only has version 0.7.3-3)
 - env_logger 0.8.2 (unstable already has 0.9.0-1)

here's the list-rdeps result, showing that this might require a lot of
tweaks:

$ ./dev/list-rdeps.sh quickcheck
Versions of rust-quickcheck in unstable:
  librust-quickcheck+default-dev   0.9.2-1.1   
  librust-quickcheck-dev   0.9.2-1.1   
  librust-quickcheck+env-logger-dev0.9.2-1.1   
  librust-quickcheck+log-dev   0.9.2-1.1   
  librust-quickcheck+regex-dev 0.9.2-1.1   
  librust-quickcheck+use-logging-dev   0.9.2-1.1   

Versions of rdeps of rust-quickcheck in unstable, that also exist in testing:
  librust-im-rc+quickcheck-dev 15.0.0-1 depends on  
   librust-quickcheck-0.9+default-dev, 
  librust-petgraph+all-dev 0.5.0-1  depends on  
   librust-quickcheck-0.9-dev | librust-quickcheck-0.8-dev, 
  librust-petgraph+quickcheck-dev  0.5.0-1  depends on  
   librust-quickcheck-0.9-dev | librust-quickcheck-0.8-dev, 
  librust-quickcheck+default-dev   0.9.2-1.1depends on  
   librust-quickcheck+regex-dev (= 0.9.2-1.1), 
librust-quickcheck+use-logging-dev (= 0.9.2-1.1), 

Source packages in unstable whose autopkgtests are triggered by rust-quickcheck:
  rust-bumpalo 3.7.0-3  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-bytecount   0.6.0-1  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-bzip2   0.4.1-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-cast0.2.3-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-diff0.1.12-1 triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-half1.6.0-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-libsystemd  0.2.1-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-muldiv  0.2.1-1  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-quickcheck-macros   0.9.1-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-yaml-rust   0.4.5-1  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-zmq 0.9.2-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-byteorder   1.4.3-2  triggered 
by librust-quickcheck-dev=0.9.2-1.1
  rust-flate2  1.0.22-1 triggered 
by librust-quickcheck-dev=0.9.2-1.1
  rust-itertools   0.10.1-1 triggered 
by librust-quickcheck-dev=0.9.2-1.1
  rust-regex   1.3.9-1  triggered 
by librust-quickcheck-dev=0.9.2-1.1
  rust-sequoia-openpgp 1.1.0-3  triggered 
by librust-quickcheck-dev=0.9.2-1.1
  rust-sequoia-openpgp 1.3.0-4  triggered 
by librust-quickcheck-dev=0.9.2-1.1

This might be a kind of messy transition, so i'm opening this ticket to
keep track of it.

  --dkg


signature.asc
Description: PGP signature


Bug#977340: spip: Not compatible with php8.0

2021-12-13 Thread Adrian Bunk
On Mon, Dec 14, 2020 at 03:23:24AM -0400, David Prévot wrote:
> Package: spip
> Version: 3.2.8-1
> Severity: important
> Tags: upstream
> Control: block 976811 by -1
> 
> SPIP 3.3 is expected to be released “soon” (it has already been delayed
> for months), but is only expected to be compatible with PHP 7.4, so not
> sure we’ll be able to make it work on PHP 8.0 before the freeze (or even
> the release) of Bullseye.

SPIP 4.4.0 with support for PHP 8.0 has been released,
I cannot judge whether it also supports PHP 8.1

cu
Adrian



Bug#1001655: Avoid hardcoding depends on specific lzip implementations

2021-12-13 Thread Daniel Baumann

Package: lintian
Version: 2.114.0
Severity: wishlist

Hi,

in #967083, someone requested that the lintian depends on lzip should be 
changed into an alternative depends on 'lzip | clzip' with the 
justification, that the submitter prefered clzip as his 
lzip-implementation-of-choice (for memory footprint reasons).


I'm maintaining all lzip related packages in Debian and there's a set of 
provides by all lzip compressors/decompressors packages since the jessie 
release in place.


May I therefore ask to have the current 'lzip | clzip' depends to be 
changed into either one of these:


  if only decompression is used:
  'lzip | lzip-decompressor'

  if only compression is used:
  'lzip | lzip-compressor'

  if both copmression and decompression is used:
  'lzip | lzip-alternative'

This will smoothly allow using any of the packages of the lzip family to 
be used, most notably the one I prefer: plzip (fully parallel version)


Regards,
Daniel



Bug#999068: libmp3-info-perl: diff for NMU version 1.24-1.4

2021-12-13 Thread gregor herrmann
Control: tags 999068 + patch
Control: tags 999068 + pending


Dear maintainer,

I've prepared an NMU for libmp3-info-perl (versioned as 1.24-1.4) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Donovan: Dignity Of Man
diff -u libmp3-info-perl-1.24/debian/changelog libmp3-info-perl-1.24/debian/changelog
--- libmp3-info-perl-1.24/debian/changelog
+++ libmp3-info-perl-1.24/debian/changelog
@@ -1,3 +1,12 @@
+libmp3-info-perl (1.24-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": add target to debian/rules.
+(Closes: #999068)
+
+ -- gregor herrmann   Mon, 13 Dec 2021 20:29:57 +0100
+
 libmp3-info-perl (1.24-1.3) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u libmp3-info-perl-1.24/debian/rules libmp3-info-perl-1.24/debian/rules
--- libmp3-info-perl-1.24/debian/rules
+++ libmp3-info-perl-1.24/debian/rules
@@ -2,7 +2,8 @@
 
 package := $(shell egrep '^Package: ' debian/control | sed 's/^Package: //')
 
-build: build-stamp
+build: build-indep
+build-indep: build-stamp
 build-stamp:
 	dh_testdir
 	perl -I. Makefile.PL INSTALLDIRS=vendor
@@ -11,6 +12,9 @@
 	perl eg/mp3tocddb.PL
 	touch build-stamp
 
+build-arch:
+	# nothing to do here
+
 clean:
 	dh_testdir
 	dh_testroot
@@ -42,4 +46,4 @@
 
 
 binary: binary-indep
-.PHONY: build clean binary-indep binary
+.PHONY: build-indep build clean binary-indep binary


signature.asc
Description: Digital Signature


Bug#749339: ITA: cflow -- Analyze control flow in C source files

2021-12-13 Thread Marcos Talau
Hi there!

Please, are you still interested in this package?
Because if you don't have it, I'll adopt it and upload it right away.


Regards,
mt


signature.asc
Description: PGP signature


Bug#1001438: transition: glibc 2.33

2021-12-13 Thread Aurelien Jarno
On 2021-12-13 00:11, Aurelien Jarno wrote:
> On 2021-12-12 22:18, Paul Gevers wrote:
> > Hi Aurelien,
> > 
> > On 12-12-2021 12:37, Aurelien Jarno wrote:
> > > > Thanks, I'll add the necessary hints once the glibc upload is old
> > > > enough.
> > > 
> > > Those false positives are due to the fact that glibc from experimental
> > > is used, and I do not expect them to appear for glibc in sid. In
> > > addition a few of them after cruft got removed from experimental.
> > > 
> > > All that said, we so many reverse dependencies, there might get more
> > > issues appearing.
> > 
> > I just started to have a look, most issues I've checked so far look false
> > positives. But aribas on i386 wasn't tested for the glibc in experimental
> > (don't know why) but it fails now in unstable and tested with glibc from
> > unstable in testing with stack smashing:
> > https://ci.debian.net/data/autopkgtest/testing/i386/a/aribas/17507755/log.gz
> 
> It's likely an issue on the package, but without further investigating,
> I can't confirm. I'll try to do that tomorrow.

I have opened bug#1001653 about it.

Aurelien

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


signature.asc
Description: PGP signature


Bug#1001654: Can't load/execute several python scripts

2021-12-13 Thread Yuri D'Elia
Package: weechat-python
Version: 3.3-1+b1
Severity: normal

With the recent updates of python3-async-timeout/python3-aiohttp
packages, I cannot load the weechat-matrix python plugin anymore (among
others). Weechat either crashes with an illegal instruction during
start, gets stuck forever while loading, and/or crashes with SIGSEGV
while quitting. It became unusable.

I initially reported the issue against python3-async-timeout, but it's
likely these two modules are not directly responsible. There's for sure
though some new ABI difference somewhere which is causing problems and
leading to crashes.

As a test, I rebuilt weechat 3.3 directly from upstream sources using
the current version of python3.9-dev (3.9.9-1) and I can now run
weechat-matrix without any other problem or change (all dependent python
packages such as python3-matrix-nio unchanged).

Is a forced rebuild possible in such a scenario?

I didn't retry to rebuild the weechat package itself, I compiled from
upstream sources.

-- System Information:
Versions of packages weechat-python depends on:
ii  libc6   2.33-1
ii  libpython3.93.9.9-1
ii  weechat-curses  3.3-1+b1

weechat-python recommends no packages.

weechat-python suggests no packages.



Bug#1001653: aribas: autopkgtest fails with glibc >= 2.33: stack smashing detected

2021-12-13 Thread Aurelien Jarno
Source: aribas
Version: 1.64-6
Severity: serious
Tags: patch upstream

Dear maintainer,

The aribas autopkgtests fails when run on an i386 system with glibc 2.33
installed. Here is the relevant part of the tests: 

| Preparing to unpack .../aribas_1.64-6_i386.deb ...
| Unpacking aribas (1.64-6) ...
| Setting up aribas (1.64-6) ...
| Setting up autopkgtest-satdep (0) ...
| (Reading database ... 13148 files and directories currently installed.)
| Removing autopkgtest-satdep (0) ...
| autopkgtest [21:14:39]: test upstream: [---
| *** stack smashing detected ***: terminated
| Aborted
| autopkgtest [21:14:40]: test upstream: ---]
| autopkgtest [21:14:40]: test upstream:  - - - - - - - - - - results - -
| - - - - - - - -
| upstream FAIL non-zero exit status 1
| autopkgtest [21:14:40]: test upstream:  - - - - - - - - - - stderr - - -
| - - - - - - -
| *** stack smashing detected ***: terminated
| Aborted
| autopkgtest [21:14:40]:  summary
| upstream FAIL non-zero exit status 1

The full autopkgtest log is available there:
https://ci.debian.net/data/autopkgtest/testing/i386/a/aribas/17524130/log.gz

After investigation it appears that aribas contains i386 assembly code
which doesn't follow the calling convention with regard to the direction
flag. The divarr and modarr function modifies it to the "backward"
direction with the STD instruction, but fails to modify it back to the
"forward" direction upon exit as required in the System V ABI [1]:

| EFLAGS  
|
| The flags register contains the system flags, such as the direction
| flag and the carry flag. The direction flag must be set to the
| "forward" (that is, zero) direction before entry and upon exit from
| a function. Other user flags have no specified role in the standard
| calling sequence and are not preserved.

The patch below fixes that, and is enough to get the autopkgtest
working.

Regards,
Aurelien


[1] http://www.sco.com/developers/devspecs/abi386-4.pdf


--- aribas-1.64.orig/src/LINUX/arito386.S
+++ aribas-1.64/src/LINUX/arito386.S
@@ -211,6 +211,7 @@ divarr:
popl%edi
popl%ebx
popl%ebp
+   cld
ret
 
 /*-*/
@@ -266,5 +267,6 @@ mod4arr:
popl%esi
popl%ebx
popl%ebp
+   cld
ret
 /*-*/



Bug#1001652: Package new version of Rapid Photo Downloader (0.9.27)

2021-12-13 Thread Damon Lynch
Package: rapid-photo-downloader
Version:0.9.26-2
Severity: important

Hello Dr. Tobias Quathamer and Antoine Beaupré,

Rapid Photo Downloader 0.9.27 is the minimum version that will run on
Python 3.10. Earlier versions of Rapid Photo Downloader crash on
Python 3.10.

Primary new features:
 - enabling downloading from iOS devices
 - running under WSL 2

New package requirements:

 - https://github.com/damonlynch/showinfilemanager (not yet packaged in Debian)
 - libimobiledevice-utils
 - ifuse
 - fuse

These changes are detailed in the change log:
https://github.com/damonlynch/rapid-photo-downloader/blob/main/CHANGES.md
, which I encourage you to read.

(I neglected to mention the packages libimobiledevice-utils, ifuse &
fuse in the README.md included in the 0.9.27 tarball, sorry about
that).

Note: although the project code development takes place using GitHub,
Launchpad is used to mirror the source code and still hosts all
releases: https://launchpad.net/rapid

I plan to try to resurrect a PPA package for Rapid Photo Downloader.
If I get it going, perhaps that will be useful to you.

If you have any questions please do not hesitate to ask. I will do my
best to respond ASAP.


Best,
Damon


-- 
https://damonlynch.net



Bug#998926: libaudio-scrobbler-perl: diff for NMU version 0.01-2.4

2021-12-13 Thread gregor herrmann
Control: tags 998926 + patch
Control: tags 998926 + pending


Dear maintainer,

I've prepared an NMU for libaudio-scrobbler-perl (versioned as 0.01-2.4) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Donovan: Dignity Of Man
diff -u libaudio-scrobbler-perl-0.01/debian/changelog libaudio-scrobbler-perl-0.01/debian/changelog
--- libaudio-scrobbler-perl-0.01/debian/changelog
+++ libaudio-scrobbler-perl-0.01/debian/changelog
@@ -1,3 +1,13 @@
+libaudio-scrobbler-perl (0.01-2.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep":
+Use dh(1) in debian/rules, and add debian/libaudio-scrobbler-perl.docs.
+(Closes: #998926)
+
+ -- gregor herrmann   Mon, 13 Dec 2021 20:13:15 +0100
+
 libaudio-scrobbler-perl (0.01-2.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libaudio-scrobbler-perl-0.01/debian/rules libaudio-scrobbler-perl-0.01/debian/rules
--- libaudio-scrobbler-perl-0.01/debian/rules
+++ libaudio-scrobbler-perl-0.01/debian/rules
@@ -1,66 +1,4 @@
 #!/usr/bin/make -f
-export PERL_MM_USE_DEFAULT=1
 
-PACKAGE=$(shell dh_listpackages)
-
-ifndef PERL
-PERL = /usr/bin/perl
-endif
-
-TMP =$(CURDIR)/debian/$(PACKAGE)
-
-build: build-stamp
-build-stamp:
-	dh_testdir
-
-	# Add commands to compile the package here
-	$(PERL) Makefile.PL INSTALLDIRS=vendor
-	$(MAKE) 
-
-	touch build-stamp
-
-clean:
-	dh_testdir
-	dh_testroot
-
-	# Add commands to clean up after the build process here
-	[ ! -f Makefile ] || $(MAKE) realclean
-
-	dh_clean build-stamp install-stamp
-
-install: build install-stamp
-install-stamp:
-	dh_testdir
-	dh_testroot
-	dh_clean -k
-
-	$(MAKE) test
-	$(MAKE) install DESTDIR=$(TMP) PREFIX=/usr
-	[ ! -d $(TMP)/usr/lib/perl5 ] || rmdir --ignore-fail-on-non-empty --parents $(TMP)/usr/lib/perl5
-
-	touch install-stamp
-
-binary-arch: build install
- # nothing to do
-
-binary-indep: build install
-	dh_testdir
-	dh_testroot
-	dh_installdocs README
-	dh_installchangelogs Changes
-	dh_installexamples
-	dh_perl
-	dh_link
-	dh_strip
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
-
-source diff:  
-	@echo >&2 'source and diff are obsolete - use dpkg-source -b'; false
-
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary binary-arch
+%:
+	dh $@
only in patch2:
unchanged:
--- libaudio-scrobbler-perl-0.01.orig/debian/libaudio-scrobbler-perl.docs
+++ libaudio-scrobbler-perl-0.01/debian/libaudio-scrobbler-perl.docs
@@ -0,0 +1 @@
+README


signature.asc
Description: Digital Signature


Bug#1001651: lintian: changelog-file-missing-explicit-entry: false positives with successive stable uploads

2021-12-13 Thread Cyril Brulebois
Package: lintian
Version: 2.104.0
Severity: important

Hi,

This is similar to #941656, but I wanted to have it tracked separately,
with a slightly higher priority, as that's affecting people performing
regular uploads to stable.

I would expect this to apply to backports and security as well but I
didn't perform any checks there.

Anyway, in this particular case, preparing the debian-installer upload
for bullseye, I received:

W: debian-installer source: changelog-file-missing-explicit-entry 
20210731+deb11u1 -> 20210731 (missing) -> 20210731+deb11u2

while the changelog is clearly what it should be:

,---
| debian-installer (20210731+deb11u2) bullseye; urgency=medium
| 
|   * Bump Linux kernel ABI to 5.10.0-10.
| 
|  -- Cyril Brulebois   Mon, 13 Dec 2021 16:23:43 +0100
| 
| debian-installer (20210731+deb11u1) bullseye; urgency=medium
| 
|   * Set USE_PROPOSED_UPDATES=1 for the bullseye stable branch.
|   * Update USE_UDEBS_FROM default from unstable to bullseye, so that
| users don't have to know about the debian/rules heuristics when
| performing manual, local builds.
|   * Bump Linux kernel ABI to 5.10.0-9.
| 
|  -- Cyril Brulebois   Mon, 04 Oct 2021 10:07:27 +0200
| 
| debian-installer (20210731) unstable; urgency=medium
| 
|   [ Cyril Brulebois ]
|   * Update translation-status for the release.
| 
|   [ Steve McIntyre ]
|   * Make mini.iso work with UEFI boot
|   * Bump Linux kernel ABI to 5.10.0-8
| 
|  -- Cyril Brulebois   Sat, 31 Jul 2021 06:20:00 +0200
`---


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant



Bug#1001650: src:clutter-1.0: fails to migrate to testing for too long: FTBFS on mips64el

2021-12-13 Thread Paul Gevers

Source: clutter-1.0
Version: 1.26.4+dfsg-2
Severity: serious
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:clutter-1.0 has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. There are segfaults during 
some of its tests that are part of its build on mip64el for the latest 
upload.


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


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


I have tagged this bug to only affect sid and bookworm, so it doesn't 
affect (old-)stable.


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1001043: rustc-mozilla 1.51.0+dfsg1-1~deb10u1 flagged for acceptance

2021-12-13 Thread Adam D Barratt
package release.debian.org
tags 1001043 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: rustc-mozilla
Version: 1.51.0+dfsg1-1~deb10u1

Explanation: new source package to support building of newer firefox-esr and 
thunderbird versions



Bug#1001649: mariadb-10.6: Inverted architecture qualifier for libaio-dev BD

2021-12-13 Thread Laurent Bigonville
Source: mariadb-10.6
Version: 1:10.6.5-1
Severity: important

Hello,

The debian/control contains the following build-dependency

  libaio-dev [!linux-any]

But libaio-dev ONLY exists in linux-any architectures, I guess that the
qualifier should be [linux-any] instead?

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy



Bug#1001589: libgsl25: Can't be upgraded to 2.7+dfsg-2

2021-12-13 Thread Alexandre Lymberopoulos
Hi, Tobias and Dirk.

Thanks to both of you for maintaing packages (no matter size and
complexity) in our beloved Debian. I would love to contribute but my
programming skills are a bit outdated. If I may help in any way, please
don't hesitate in writing me (there will be a learning curve from my
side).

Best, Alexandre

On Dec 13 2021, Dirk Eddelbuettel wrote:
> 
> Hi Tobias,
> 
> Thanks for piping in!
> 
> On 13 December 2021 at 16:42, Tobias Hansen wrote:
> | On 12/13/21 4:30 PM, Dirk Eddelbuettel wrote:
> | > Hi Alexandre,
> | >
> | > On 13 December 2021 at 09:08, Alexandre Lymberopoulos wrote:
> | > | Hi there, Dirk!
> | > | 
> | > | I see that, libgslblasc0 is upgradable to version 2.7.1+dfsg-3 here, but
> | > | the upgrade available version of libgsl25 (2.6+dfsg-2 -> 2.7+dfsg-2)
> | > | requires libgslbalsc0 2.7.1+dfsg-2, which is unavailable.
> | > | 
> | > | Digging around here, I noticed that the only package that still depends
> | > | on libgsl25 after a supposed upgrade is sagemath. Is there a way to let
> | > | them know this and try tu upgrade their dependency to libgsl27? Or is it
> | > | better to bugreport them?
> | >
> | > That is is a bit of grey zone to me too. Sometimes the ftpmasters help 
> nudge
> | > this, or even do a 'binary build' (unchanged package rebuilt under new 
> dependencies).
> | > I am CCing Sebastian who has been very helpful for the GSL update / 
> informal
> | > transition.  He may be able to suggest a next step.
> | >
> | > Otherwise you could start with a simple email to the maintainer.
> | >
> | > Cheers, Dirk
> | 
> | sagemath maintainer here. The sagemath 9.2 package is broken at the moment 
> and does not build and I wouldn't expect it to work very well either. I am 
> working on a big update but that may still need some days until it's 
> finished. In the meantime I wouldn't mind if sagemath 9.2 breaks further.
> 
> Thanks for maintaining such a large and complex package. It looks like things
> are being addressed and Alexandre should be back to complete setup soon too.
> 
> Cheers, Dirk
> 
> | Best,
> | 
> | Tobias
> | 
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
===
Alexandre Lymberopoulos - lym...@gmail.com
===



Bug#1001616: opencc: fails to build reproducibly's root case is not Identifier: build_id_differences_only

2021-12-13 Thread Gunnar Hjalmarsson

On 2021-12-13 09:45, xiao sheng wen (肖盛文) wrote:

One is /usr/share/doc/opencc/html/index.html diff.
This also can find from:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/opencc.html
I had forwrded to upsteam[1] .


When talking to upstream, please keep in mind that we have a Debian 
patch which alters the related part of README.md:


https://salsa.debian.org/debian/opencc/-/blob/master/debian/patches/0004-no-remote-images-when-reading-docs-on-disk.patch

--
Rgds,
Gunnar Hjalmarsson



Bug#1001647: visidata phones home

2021-12-13 Thread Jakub Wilk

Package: visidata
Version: 2.2.1-1

visidata downloads stuff from https://visidata.org/ behind my back.
Please don't do that.

Traceback (from a crash provoked by syscall tampering[*]):

  File "/usr/lib/python3/dist-packages/visidata/urlcache.py", line 25, in 
urlcache
with urlopen(req) as fp:
  File "/usr/lib/python3/dist-packages/visidata/plugins.py", line 68, in reload
self.source = urlcache(options.plugins_url or vd.fail(), days=0)  # for 
VisiDataMetaSheet.reload()
  File "/usr/lib/python3/dist-packages/visidata/threads.py", line 235, in _func
func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/visidata/threads.py", line 215, in 
_toplevelTryFunc
t.status = func(*args, **kwargs)
  File "/usr/lib/python3.9/threading.py", line 910, in run
self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.9/threading.py", line 973, in _bootstrap_inner
self.run()
  File "/usr/lib/python3.9/threading.py", line 930, in _bootstrap
self._bootstrap_inner()


[*] strace -f -o /dev/null --inject=connect:signal=SIGABRT visidata /etc/fstab


-- System Information:
Architecture: i386

Versions of packages visidata depends on:
ii  python3-dateutil  2.8.1-6
ii  python3   3.9.8-1

--
Jakub Wilk



Bug#1001646: libgeoip1 can't determine the country of an ipaddress, but www.maxmind.com does report it

2021-12-13 Thread Frank B. Brokken
Package: libgeoip1
Version: 1.6.12-8
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Our Internet provider assigned us address 185.202.110.161. The following
minimal C++ program reports: 

'185.202.110.161 not found in GeopIP database':

int main()
{
char const *ip = "185.202.110.161";

GeoIP *gi = GeoIP_open("/usr/share/GeoIP/GeoIP.dat", 
GEOIP_MEMORY_CACHE); 
if (!gi)
return 1;

char const *country = GeoIP_country_code_by_addr(gi, ip);
if (!country)
cout << ip << " not found in GeopIP database\n";
}


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

Since libgeoip1 lists www.maxmind.com] as its 'External Resource', I entered
the above address at https://www.maxmind.com/en/home

   * What was the outcome of this action?

The page https://www.maxmind.com/en/geoip2-precision-demo was opened and
showed the correct country and ISP.

   * What outcome did you expect instead?

Since www.maxmind.com correctly reported details like the address's country
and ISP, I had expected that libgeoip1 would also produce the correct
country. I tried several other (existing) addresses using the above program,
and it correctly produced the countries of those addresses


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

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

Versions of packages libgeoip1 depends on:
ii  libc6  2.32-5

Versions of packages libgeoip1 recommends:
ii  geoip-database  20191224-3

Versions of packages libgeoip1 suggests:
ii  geoip-bin  1.6.12-8

-- no debconf information



Bug#1001645: pulseaudio: My system has no sound at all, after upgrading

2021-12-13 Thread alireza
Package: pulseaudio
Version: 15.0+dfsg1-2
Severity: important
X-Debbugs-Cc: alireza...@gmail.com

Dear Maintainer,

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

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

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


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.61
ii  libasound2   1.2.5.1-1
ii  libasound2-plugins   1.2.5-2
ii  libc62.32-5
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-3
ii  libfftw3-single3 3.3.8-2
ii  libgcc-s111.2.0-12
ii  libglib2.0-0 2.70.2-1
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse015.0+dfsg1-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-2
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   11.2.0-12
ii  libsystemd0  249.7-1
ii  libtdb1  1.4.3-1+b1
ii  libudev1 249.7-1
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 15.0+dfsg1-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-3
ii  libpam-systemd [logind]  249.7-1
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
pn  pavucontrol  
pn  pavumeter
ii  udev 249.7-1

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = n

Bug#1001644: libpam-sss: OTP-enabled users do not recieve OTP prompts from pam_sss.so

2021-12-13 Thread Sam Morris
Package: libpam-sss
Version: 2.6.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In the default configuration, /etc/pam.d/common-auth contains:

  auth  [success=2 default=ignore]  pam_unix.so nullok
  auth  [success=1 default=ignore]  pam_sss.so use_first_pass
  authrequisite   pam_deny.so

This means that pam_unix has the first & only change to prompt the user
for authentication, and the user gets a single 'Password:' prompt.

In the Red Hat world, /etc/pam.d/password-auth contains:

  authrequired pam_env.so
  authrequired pam_faildelay.so 
delay=200
  auth[default=1 ignore=ignore success=ok] pam_usertype.so 
isregular
  auth[default=1 ignore=ignore success=ok] pam_localuser.so
  authsufficient   pam_unix.so nullok
  auth[default=1 ignore=ignore success=ok] pam_usertype.so 
isregular
  authsufficient   pam_sss.so 
forward_pass
  authrequired pam_deny.so

A local user will hit pam_unix. A non-local user will skip over it and
be prompted by pam_sss.so.

An easy fix is to increase the Priority in /usr/share/pam-configs/sss to
some value > 256. That way, pam-auth-update puts pam_sss before
pam_unix.

I tested this, and 'su - localuser' still works.

Unfortunately I don't know of a way for a user to override this value
other than by editing that file, which is owned by libpam-sss.

Is there a good reason that pam_unix has to be first in the module
stack? If not, could we make this change?

- -- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 
'unstable'), (500, 'stable-security'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-sss depends on:
ii  libc6 2.32-5
ii  libgssapi-krb5-2  1.18.3-7
ii  libpam-pwquality  1.4.4-1
ii  libpam-runtime1.4.0-9+deb11u1
ii  libpam0g  1.4.0-11

Versions of packages libpam-sss recommends:
ii  sssd  2.6.1-1

libpam-sss suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCYbeFXRIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIpR9gEAldojCYmY4mvOcns5k9wcfXpTN324+MUx
wiiKCeGy5PgBAKsWW6nGrvuFyQggaQADHH5O1p+bdr5q35Bp4suL0w0A
=ldXe
-END PGP SIGNATURE-



Bug#1001643: sdaps: fails to setup a project with texlive-latex-extra/unstable (2021.2021127-1)

2021-12-13 Thread Vincent-Xavier JUMEL
Package: sdaps
Version: 1.9.8-0.1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I've sought to use sdaps instead of auto-multiple-choice, but, while
setting up the project, I've hit a bug :

Steps to reproduce
1. sdaps setup /tmp/projet /usr/share/doc/sdaps/examples/example.tex

Excepted output :
+ a generated pdf file
+ Question on the output
+ see https://sdaps.org/getting-started/setup/

Outcome :
+ questionnaire.pdf doesn't exist
+ sdaps setup fails
+ pdflatex questionnaire.tex fails

The main raison is that /usr/share/sdaps/tex/ and
/usr/share/texlive/texmf-dist/tex/latex/sdaps/ differs (I've attached a
diff).
If I copy files from /usr/share/texlive/texmf-dist/tex/latex/sdaps/ into
/tmp/projet and then run pdlfatex against questionnaire.tex, the
questionnaire.pdf is generated.

This bug may belongs to upstream.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (100, 'buster-fasttrack'), (100, 
'buster-backports'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages sdaps depends on:
ii  gir1.2-poppler-0.18  20.09.0-3.1
ii  libc62.33-1
ii  libcairo21.16.0-5
ii  libglib2.0-0 2.70.2-1
ii  libtiff5 4.3.0-2
ii  python3  3.9.8-1
ii  python3-cairo1.20.1-3
ii  python3-gi   3.42.0-2+b1
ii  python3-gi-cairo 3.42.0-2+b1
ii  python3-opencv   4.5.4+dfsg-9+b1
ii  python3-zbar 0.23.92-4
ii  zbar-tools   0.23.92-4

Versions of packages sdaps recommends:
ii  gir1.2-gtk-3.0 3.24.30-4
ii  python3-pil8.4.0-1
ii  python3-reportlab  3.6.2-1
ii  texlive2021.20211127-1
ii  texlive-latex-extra2021.20211127-1
ii  texlive-latex-recommended  2021.20211127-1
ii  texlive-plain-generic  2021.20211127-1
ii  texlive-science2021.20211127-1

sdaps suggests no packages.

-- no debconf information

-- 
Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net

Société Libre, Logiciel Libre http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org
--- /usr/share/sdaps/tex/
+++ /usr/share/texlive/texmf-dist/tex/latex/sdaps/
├── file list
│ @@ -1,14 +1,13 @@
│  sdapsarray.sty
│  sdapsbase.sty
│  sdapsclassic.cls
│  sdapscode128.tex
│  sdapslayout.sty
│  sdapspdf.sty
│ -sdapsreport.cls
│  translator-sdaps-dictionary-Brazilian.dict
│  translator-sdaps-dictionary-Dutch.dict
│  translator-sdaps-dictionary-English.dict
│  translator-sdaps-dictionary-Finnish.dict
│  translator-sdaps-dictionary-French.dict
│  translator-sdaps-dictionary-German.dict
│  translator-sdaps-dictionary-Italian.dict
├── stat {}
│ @@ -1,8 +1,8 @@
│  
│Size: 4096 Blocks: 8  IO Block: 4096   directory
│  Links: 2
│  Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
│  
│ -Modify: 2020-11-24 10:10:36.384018304 +
│ +Modify: 2021-12-01 21:44:37.538686925 +
│   --- /usr/share/sdaps/tex/sdapsarray.sty
├── +++ /usr/share/texlive/texmf-dist/tex/latex/sdaps/sdapsarray.sty
│ @@ -582,19 +582,19 @@
│\dim_set:Nn \l_tmpa_dim { \linewidth - \coffin_wd:N \l_tmpa_coffin - 
2\l_sdaps_sdapsarray_colsep_dim }
│\tl_gset:Nx \g_sdaps_array_local_data_new_tl { \dim_use:N \l_tmpa_dim }
│  
│% TODO: The \hfil here is a hack to prevent a warning if the vbox is empty.
│%   Unfortunately checking for an empty box does not work for some 
reason.
│\dim_set:Nn \l_tmpb_dim { \box_ht:N #1 }
│\sdaps_if_rtl:TF {
│ -\hcoffin_set:Nn \l_tmpb_coffin { \hbox_to_wd:nn \l_tmpa_dim { \hfil 
\vbox:n { \vbox_unpack_clear:N #1 } } \skip_horizontal:n { 
\l_sdaps_sdapsarray_colsep_dim } }
│ +\hcoffin_set:Nn \l_tmpb_coffin { \hbox_to_wd:nn \l_tmpa_dim { \hfil 
\vbox:n { \vbox_unpack_drop:N #1 } } \skip_horizontal:n { 
\l_sdaps_sdapsarray_colsep_dim } }
│  \tl_set:Nn \l_tmpa_tl { l }
│  \tl_set:Nn \l_tmpb_tl { r }
│} {
│ -\hcoffin_set:Nn \l_tmpb_coffin { \skip_horizontal:n { 
\l_sdaps_sdapsarray_colsep_dim } \hbox_to_wd:nn \l_tmpa_dim { \hfil \vbox:n { 
\vbox_unpack_clear:N #1 } } }
│ +\hcoffin_set:Nn \l_tmpb_coffin { \skip_horizontal:n { 
\l_sdaps_sdapsarray_colsep_dim } \hbox_to_wd:nn \l_tmpa_dim { \hfil \vbox:n { 
\vbox_unpack_drop:N #1 } } }
│  \tl_set:Nn \l_tmpa_tl { r }
│  \tl_set:Nn \l_tmpb_tl { l }
│}
│\dim_set:Nn \l_tmpa_dim { \coffin_ht:N \l_tmpb_coffin }
│  
│% If the first/last baseline differ then center the vbox, otherwise align 
the
│% baseline with the cells
│ ├── stat {}
│ │ @@ -1,8

Bug#1001616: opencc: fails to build reproducibly's root case is not Identifier: build_id_differences_only

2021-12-13 Thread Vagrant Cascadian
On 2021-12-13, xiao sheng wen(肖盛文) wrote:
> In
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/opencc.html
>
> say:"The Build ID differs, but there are no other differences."
>
> In fact, there are two root cases cause FTBR at least.

Thanks for looking into this! Indeed, there appear to be more issues.


> One is /usr/share/doc/opencc/html/index.html diff.
> This also can find from:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/opencc.html
> I had forwrded to upsteam[1] .
...
> [1] https://github.com/BYVoid/OpenCC/issues/649
...
> │ │ │ ├── ./usr/share/doc/opencc/html/index.html
> │ │ │ │ @@ -63,15 +63,15 @@
> │ │ │ │  
> │ │ │ │  
> │ │ │ │  
> │ │ │ │
> │ │ │ │  Open Chinese Convert 開放中文轉換   
> │ │ │ │  
> │ │ │ │  
> │ │ │ │ - id="md__tmp_reprotest_qC7aP9_const_build_path_README"> [ href="https://travis-ci.org/BYVoid/OpenCC";>Travis] [ href="https://ci.appveyor.com/project/Carbo/OpenCC";>AppVeyor] [ href="https://github.com/BYVoid/OpenCC/actions/workflows/cmake.yml";>C/C++ 
> CI] [ href="https://github.com/BYVoid/OpenCC/actions/workflows/nodejs.yml";>Node.js 
> CI] [ href="https://github.com/BYVoid/OpenCC/actions/workflows/python.yml";>Python 
> CI]
> │ │ │ │ + id="md__tmp_reprotest_qC7aP9_build_experiment_1_README"> [ href="https://travis-ci.org/BYVoid/OpenCC";>Travis] [ href="https://ci.appveyor.com/project/Carbo/OpenCC";>AppVeyor] [ href="https://github.com/BYVoid/OpenCC/actions/workflows/cmake.yml";>C/C++ 
> CI] [ href="https://github.com/BYVoid/OpenCC/actions/workflows/nodejs.yml";>Node.js 
> CI] [ href="https://github.com/BYVoid/OpenCC/actions/workflows/python.yml";>Python 
> CI]

This is an embedded build path; reprotest builds in
/tmp/reprotest-X/const_build_path/ and
/tmp/reprotest-X/build-experiment-1/ between two builds.

If you pass the argument to reprotest --vary=-build_path, does it build
reproducibly?

Looking at the history on amd64, it seems to build reproducibly except
when building unstable (e.g. bookworm and bullseye seem to build
reproducibly):

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/opencc.html

Build paths are only varied when building unstable or experimental, so
this would suggest the issues are related to build paths.


Although, on i386 and armhf, there are still outstanding issues even in
bookworm:

  https://tests.reproducible-builds.org/debian/history/i386/opencc.html
  https://tests.reproducible-builds.org/debian/history/armhf/opencc.html

These architectures also systematically run one build with a 32-bit
kernel and one build with a 64-bit kernel. The build may be
inappropriately capturing the kernel architecture:

  $ git grep os.uname
  setup.py:_, _, _, _, machine = os.uname()
  setup.py:_, _, _, _, machine = os.uname()
 
Either there, or somewhere else...


> The another is not has relation to build-id.
> I do the following debug:
>
> 1.add the --build-id=none to LDFLAGS in debian/rules:
>
> export DEB_LDFLAGS_MAINT_APPEND = -Wl,--build-id=none
>
> 2. run reprotest
>
> 3. still get fails to build reproducibly
> The errors output please see attachment.
> It has not the build-id diff in it.
>
> IMHO, It's other reason to cause the FTBR, need to investigate more.
...
> │ │ │ ├── ./usr/bin/opencc
> │ │ │ │ ├── readelf --wide --program-header {}
> │ │ │ │ │ @@ -4,15 +4,15 @@
> │ │ │ │ │  There are 11 program headers, starting at offset 64
> │ │ │ │ │  
> │ │ │ │ │  Program Headers:
> │ │ │ │ │Type   Offset   VirtAddr   PhysAddr   
> FileSiz  MemSiz   Flg Align
> │ │ │ │ │PHDR   0x40 0x0040 0x0040 
> 0x000268 0x000268 R   0x8
> │ │ │ │ │INTERP 0x0002a8 0x02a8 0x02a8 
> 0x1c 0x1c R   0x1
> │ │ │ │ │[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
> │ │ │ │ │ -  LOAD   0x00 0x 0x 
> 0x008568 0x008568 R   0x1000
> │ │ │ │ │ +  LOAD   0x00 0x 0x 
> 0x008570 0x008570 R   0x1000
> │ │ │ │ │LOAD   0x009000 0x9000 0x9000 
> 0x0100dd 0x0100dd R E 0x1000
> │ │ │ │ │LOAD   0x01a000 0x0001a000 0x0001a000 
> 0x0035af 0x0035af R   0x1000
> │ │ │ │ │LOAD   0x01e0a8 0x0001f0a8 0x0001f0a8 
> 0x000f98 0x0014d8 RW  0x1000
> │ │ │ │ │DYNAMIC0x01eaf0 0x0001faf0 0x0001faf0 
> 0x000240 0x000240 RW  0x8
> │ │ │ │ │NOTE   0x0002c4 0x02c4 0x02c4 
> 0x20 0x20 R   0x4
> │ │ │ │ │GNU_EH_FRAME   0x01aa90 0x0001aa90 0x0001aa90 
> 0x00047c 0x00047c R   0x4
> │ │ │ │ │GNU_STACK  0x00 0x 0x 
> 0x00 0x00 RW  0x10

This and the rest of the differences looks like a small offset that is
possibly related to the build path being a diffe

Bug#1001316: gnome-gmail: 2.8 to stable-updates

2021-12-13 Thread David Steele
Control: severity -1 normal
Control: tags -1 moreinfo unreproducible
thanks

On Wed, Dec 8, 2021 at 4:48 AM Martin-Éric Racine
 wrote:
>
> Package: gnome-gmail
> Version: 2.8-1
> Severity: important
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> The version of gnome-mail currently in Stable fails to connect to GMail with 
> an API error.
>

I spun up a new and created a new draft with gnome-gmail with no API
errors. Can you provide more information on how you came across this
issue?

Note that the API requires a fully-qualified email address
("gnome-gmail j...@example.com" vs. "gnome-gmail joe").

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE



Bug#941656: lintian: changelog-file-missing-explicit-entry false positive for 2 consecutive NMUs (-X.1, -X.2)

2021-12-13 Thread Shengjing Zhu
On Sun, Oct 06, 2019 at 06:55:39AM +0200, Andreas Metzler wrote:
> > I just uploaded ddd_3.3.12-5.2.dsc and I get this warning:
> > W: ddd source: changelog-file-missing-explicit-entry 1:3.3.12-5.1 -> 
> > 1:3.3.12-5 (missing) -> 1:3.3.12-5.2
> 
> > Yet the changelog file has all the entries and in the expected order:
> > $ grep ^ddd debian/changelog |head -n 3
> > ddd (1:3.3.12-5.2) unstable; urgency=medium
> > ddd (1:3.3.12-5.1) unstable; urgency=medium
> > ddd (1:3.3.12-5) unstable; urgency=low
> 
> Hello,
> 
> This also applies if one of the NMUs uploads a new upstream version.
> 
> W: xplanet source: changelog-file-missing-explicit-entry 1.3.0-5.1 -> 1.3.1-0 
> (missing) -> 1.3.1-0.1
> 
> (sid)ametzler@argenau:/tmp/XPLANET/xplanet-1.3.1$ grep ^xplanet 
> debian/changelog | head -n3
> xplanet (1.3.1-0.1) UNRELEASED; urgency=medium
> xplanet (1.3.0-5.1) unstable; urgency=medium
> xplanet (1.3.0-5) unstable; urgency=low
> 
> 

This also applies for stable uploads.

W: golang-1.15 source: changelog-file-missing-explicit-entry 1.15.15-1~deb11u1 
-> 1.15.15-1 (missing) -> 1.15.15-1~deb11u2

debian/changelog looks like:

golang-1.15 (1.15.15-1~deb11u2) bullseye; urgency=medium

  * XX

 -- Shengjing Zhu   Sat, 04 Dec 2021 17:37:57 +0800

golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium

  * XX

 -- Shengjing Zhu   Sat, 11 Sep 2021 15:54:07 +0800

golang-1.15 (1.15.15-1) unstable; urgency=medium

  * XX

 -- Anthony Fok   Sun, 15 Aug 2021 16:44:15 -0600



Bug#1001589: libgsl25: Can't be upgraded to 2.7+dfsg-2

2021-12-13 Thread Dirk Eddelbuettel


Hi Tobias,

Thanks for piping in!

On 13 December 2021 at 16:42, Tobias Hansen wrote:
| On 12/13/21 4:30 PM, Dirk Eddelbuettel wrote:
| > Hi Alexandre,
| >
| > On 13 December 2021 at 09:08, Alexandre Lymberopoulos wrote:
| > | Hi there, Dirk!
| > | 
| > | I see that, libgslblasc0 is upgradable to version 2.7.1+dfsg-3 here, but
| > | the upgrade available version of libgsl25 (2.6+dfsg-2 -> 2.7+dfsg-2)
| > | requires libgslbalsc0 2.7.1+dfsg-2, which is unavailable.
| > | 
| > | Digging around here, I noticed that the only package that still depends
| > | on libgsl25 after a supposed upgrade is sagemath. Is there a way to let
| > | them know this and try tu upgrade their dependency to libgsl27? Or is it
| > | better to bugreport them?
| >
| > That is is a bit of grey zone to me too. Sometimes the ftpmasters help nudge
| > this, or even do a 'binary build' (unchanged package rebuilt under new 
dependencies).
| > I am CCing Sebastian who has been very helpful for the GSL update / informal
| > transition.  He may be able to suggest a next step.
| >
| > Otherwise you could start with a simple email to the maintainer.
| >
| > Cheers, Dirk
| 
| sagemath maintainer here. The sagemath 9.2 package is broken at the moment 
and does not build and I wouldn't expect it to work very well either. I am 
working on a big update but that may still need some days until it's finished. 
In the meantime I wouldn't mind if sagemath 9.2 breaks further.

Thanks for maintaining such a large and complex package. It looks like things
are being addressed and Alexandre should be back to complete setup soon too.

Cheers, Dirk

| Best,
| 
| Tobias
| 

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#1001608: udev: /usr/lib/udev/rules.d/50-libxtrxll0.rules:1 Unknown group 'usb', ignoring

2021-12-13 Thread Michael Biebl

On Mon, 13 Dec 2021 09:24:01 +0100 Michael Biebl  wrote:

Control: reassign -1 libxtrxll0

On 13.12.21 05:37, Francois Marier wrote:
> Package: udev
> Version: 249.7-1
> Severity: normal
> 
> I don't have a `usb` group on my system and I see the following in my logs:
> 
>Dec 12 06:28:26 hostname systemd-udevd[407]: /usr/lib/udev/rules.d/50-libxtrxll0.rules:1 Unknown group 'usb', ignoring

>Dec 12 06:29:05 hostname systemd-udevd[407]: 
/usr/lib/udev/rules.d/50-libxtrxll0.rules:1 Unknown group 'usb', ignoring
> 
> Not sure where the bug lies, but perhaps the udev package is expecting a

> group that's not guaranteed to be present on Debian systems?


$ apt-file search /lib/udev/rules.d/50-libxtrxll0.rules
libxtrxll0: /lib/udev/rules.d/50-libxtrxll0.rules

Reassigning accordingly.


Fwiw, instead of using a dedicated, static system group, maybe setting 
an ACL via the uaccess mechanism is a better alternative.




Bug#1001642: python3-aiohttp: Needs explicit versioned dependency: python3-async-timeout (>= 4.0.1)

2021-12-13 Thread Boyuan Yang
Package: python3-aiohttp
Severity: important
Version: 3.8.1-3
X-Debbugs-CC: pi...@debian.org

Hi Piotr,

As we previously discussed in https://bugs.debian.org/1000680 , we want to
handle the mess around python-aiohttp and make the new versions migrate to
Debian Testing.

Currently there are many autopkgtest regressions on
https://tracker.debian.org/pkg/python-aiohttp and
https://tracker.debian.org/pkg/python-async-timeout . I looked into them, and
it seems that the root cause is the missing versioned dependency between
python-aiohttp and python-async-timeout. We need to explicitly tell ci.d.n
instance that they need to be migrated to Testing together.

I am not 100% sure about the solution, but probably the following restriction
is needed:

* python3-aiohttp: Depends: python3-async-timeout (>= 4.0.1)

I am not sure if we need the following restriction as well:

* python3-async-timeout: Breaks: python3-aiohttp (<< 3.8)

Could you please take a look and make necessary uploads? If you need any help
from my side, please feel free to let me know.

-- 
Regards,
Boyuan Yang


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


Bug#1001589: libgsl25: Can't be upgraded to 2.7+dfsg-2

2021-12-13 Thread Tobias Hansen
On 12/13/21 4:30 PM, Dirk Eddelbuettel wrote:
> Hi Alexandre,
>
> On 13 December 2021 at 09:08, Alexandre Lymberopoulos wrote:
> | Hi there, Dirk!
> | 
> | I see that, libgslblasc0 is upgradable to version 2.7.1+dfsg-3 here, but
> | the upgrade available version of libgsl25 (2.6+dfsg-2 -> 2.7+dfsg-2)
> | requires libgslbalsc0 2.7.1+dfsg-2, which is unavailable.
> | 
> | Digging around here, I noticed that the only package that still depends
> | on libgsl25 after a supposed upgrade is sagemath. Is there a way to let
> | them know this and try tu upgrade their dependency to libgsl27? Or is it
> | better to bugreport them?
>
> That is is a bit of grey zone to me too. Sometimes the ftpmasters help nudge
> this, or even do a 'binary build' (unchanged package rebuilt under new 
> dependencies).
> I am CCing Sebastian who has been very helpful for the GSL update / informal
> transition.  He may be able to suggest a next step.
>
> Otherwise you could start with a simple email to the maintainer.
>
> Cheers, Dirk

sagemath maintainer here. The sagemath 9.2 package is broken at the moment and 
does not build and I wouldn't expect it to work very well either. I am working 
on a big update but that may still need some days until it's finished. In the 
meantime I wouldn't mind if sagemath 9.2 breaks further.

Best,

Tobias



Bug#999172: toppler: missing required debian/rules targets build-arch and/or build-indep

2021-12-13 Thread Bill Allombert
On Tue, Nov 09, 2021 at 10:28:21PM +0100, Lucas Nussbaum wrote:
> Source: toppler
> Version: 1.1.6-3
> Severity: important
> Justification: Debian Policy section 4.9
> Tags: bookworm sid
> User: debian...@lists.debian.org
> Usertags: missing-build-arch-indep
> 
> Dear maintainer,
> 
> Your package does not include build-arch and/or build-indep targets in
> debian/rules. This is required by Debian Policy section 4.9, since 2012.
> https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules
> 
> Please note that this is also a sign that the packaging of this software
> could benefit from a refresh. For example, packages using 'dh' cannot be
> affected by this issue.
> 
> This mass bug filing was discussed on debian-devel@ in
> https://lists.debian.org/debian-devel/2021/11/msg00052.html .
> The severity of this bug will be changed to 'serious' after a month.

Hello Lucas,

Would you mind give me one more month, we are working on a new upstream
version...

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



  1   2   >