date:20211213

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


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


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


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"


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)


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


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


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


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


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


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

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

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

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

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

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

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

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

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

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

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